2.6.14: aic7xxx broken with blktool
Begin forwarded message:
Date: Fri, 28 Oct 2005 12:03:12 +0300 (EEST)
From: Meelis Roos <[email protected]>
To: Linux Kernel list <[email protected]>
Subject: 2.6.14: aic7xxx broken with blktool
I'm using blktool to find info about installed disks. With Debian's 2.6.8, "blktool /dev/sda id" worked fine. With 2.6.14 it's broken (see below). Adaptec 2940UW with a 4.5G Quantum Viking II disk.
It outputs random data from memory as a response to the scsi command, different recent strings different times.
Otherwise the disk works OK.
blktools is from Debian Sarge, package version 4-2, and works fine with 2.6.8-2-686-smp kernel from Debian.
dmesg:
[...]
SCSI subsystem initialized
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:0f.0[A] -> Link [LNKB] -> GSI 11 (level, low) -> IRQ 11 scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 7.0
<Adaptec 2940 Ultra SCSI adapter>
aic7880: Ultra Wide Channel A, SCSI Id=7, 16/253 SCBs
Vendor: QUANTUM Model: VIKING II 4.5WLS Rev: 3506
Type: Direct-Access ANSI SCSI revision: 02
scsi0:A:6:0: Tagged Queuing enabled. Depth 8
target0:0:6: Beginning Domain Validation
target0:0:6: wide asynchronous.
target0:0:6: Domain Validation skipping write tests target0:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8) target0:0:6: Ending Domain Validation
target0:0:6: FAST-10 WIDE SCSI 20.0 MB/s ST (100 ns, offset 8)
SCSI device sda: 8910423 512-byte hdwr sectors (4562 MB)
SCSI device sda: drive cache: write back
SCSI device sda: 8910423 512-byte hdwr sectors (4562 MB)
SCSI device sda: drive cache: write back
sda: sda1 sda2 sda4 < sda5 sda6 >
Attached scsi disk sda at scsi0, channel 0, id 6, lun 0
[...]
(scsi0:A:6:0): No or incomplete CDB sent to device. (scsi0:A:6:0): Protocol violation in Message-in phase. Attempting to abort. (scsi0:A:6:0): Abort Tag Message Sent
(scsi0:A:6:0): SCB 3 - Abort Tag Completed.
(scsi0:A:6:0): No or incomplete CDB sent to device. (scsi0:A:6:0): Protocol violation in Message-in phase. Attempting to abort. (scsi0:A:6:0): Abort Tag Message Sent
(scsi0:A:6:0): SCB 2 - Abort Tag Completed.
Signature · 6 lines
Meelis Roos ([email protected]) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 13 lines · Andrew Morton
Begin forwarded message:
Date: Fri, 28 Oct 2005 12:03:12 +0300 (EEST)
From: Meelis Roos <[email protected]>
To: Linux Kernel list <[email protected]>
Subject: 2.6.14: aic7xxx broken with blktoolI'm using blktool to find info about installed disks. With Debian's 2.6.8, "blktool
/dev/sdaid" worked fine. With 2.6.14 it's broken (see below). Adaptec 2940UW with a 4.5G Quantum Viking II disk.
Quoted 7 lines
It outputs random data from memory as a response to the scsi command, different recent strings different times.
Otherwise the disk works OK.
blktools is from Debian Sarge, package version 4-2, and works fine with 2.6.8-2-686-smp kernel from Debian.
As the log indicated, a command was aborted, possibly the INQUIRY. blktool (version 4.2) doesn't seem to do any SG_IO error processing, so if an error was returned then it would not have known and just assumed the INQUIRY response buffer had been filled. sdparm is a little more rigorous in the error checking area and it has been burnt by the block layer SG_IO yielding a false positive. So I now prefill the INQUIRY response buffer with 0x7f in buf[0] and zero in the rest.
My guess is that the kernel problem is with the aic7xxx driver in lk 2.6.14 .
While glancing at blktool scsi.c (version 4.2) I was surprised by the brevity of handle_scsi_wcache() which implements "wcache on|off" for SCSI disks. It ain't that simple and a test indicated that version doesn't work.
Doug Gilbert
Quoted 8 lines · Andrew Morton
I'm using blktool to find info about installed disks. With Debian's 2.6.8, "blktool
/dev/sdaid" worked fine. With 2.6.14 it's broken (see below). Adaptec 2940UW with a 4.5G Quantum Viking II disk.It outputs random data from memory as a response to the scsi command, different recent strings different times.
Otherwise the disk works OK.
This is a bug in blktool, so please refile appropriately.
The change is that we now believe hdr->cmd_len if it's set and block tool is setting it wrongly. aic7xxx detects the mismatch between the actual command length and the set length in its sequencer and barfs.
James
Quoted 4 lines
Quoted 2 lines
It outputs random data from memory as a response to the scsi command, different recent strings different times.
This is a bug in blktool, so please refile appropriately.
Yes, I see. blktools seems to buggy, yes.
But blktool outputs memory fragments that seems to come from other processes. I saw string "bash", "lled with unallocated bl" and other strings that do not appear in blktools image. Without further investigation it seems that in case of the error, soma data ise leaked from kernel to the buggy program in userspace (blktool in this case).
Signature · 1 line
Meelis Roos ([email protected]) http://www.cs.ut.ee/~mroos/
Quoted 8 lines · Meelis Roos
Quoted 5 lines
Quoted 2 lines
It outputs random data from memory as a response to the scsi command, different recent strings different times.
This is a bug in blktool, so please refile appropriately.
Yes, I see. blktools seems to buggy, yes.
May I suggest that you try sdparm for SCSI devices until blktool is fixed.
Quoted 5 lines
But blktool outputs memory fragments that seems to come from other processes. I saw string "bash", "lled with unallocated bl" and other strings that do not appear in blktools image. Without further investigation it seems that in case of the error, soma data ise leaked from kernel to the buggy program in userspace (blktool in this case).
After analysing the blktool code (4.2), and having a similar worrying report concerning sdparm, what you may have seen was the uninitialized contents of a auto variable (buf[128]) in blktool. As James B. pointed out, the failure in the aic7xxx driver was due to an INQUIRY command issued with a cdb length set to 12 bytes (it should be 6). Given that failure there should have been no DMA from the device back to the kernel memory. If kernel memory was still moved back to the user space then that is an issue.
The sg driver zeroes its kernel buffers for all non-root users before data is moved through them as a safeguard. There can also be "short" DMA transfer back from a device, indicated by resid>0 that should be considered in this context.
Doug Gilbert
Quoted 5 lines
Quoted 5 lines
But blktool outputs memory fragments that seems to come from other processes. I saw string "bash", "lled with unallocated bl" and other strings that do not appear in blktools image. Without further investigation it seems that in case of the error, soma data ise leaked from kernel to the buggy program in userspace (blktool in this case).
Meanwhile I have identified that "lled ..." message is contained in glibc. Don't know about "bash" but it might have come from environment or other places since it's my login shell. So there need not be a kernel leak.
Signature · 1 line
Meelis Roos ([email protected])