Fw: 2.6.14: aic7xxx broken with blktool

Fw: 2.6.14: aic7xxx broken with blktool

[Andrew Morton]

Begin forwarded message:

Date: Fri, 28 Oct 2005 12:03:12 +0300 (EEST)
From: Meelis Roos <mroos@linux.ee>
To: Linux Kernel list <linux-kernel@vger.kernel.org>
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.

-- 
Meelis Roos (mroos@linux.ee)
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: Fw: 2.6.14: aic7xxx broken with blktool

[Douglas Gilbert]

Andrew Morton wrote:
> 
> Begin forwarded message:
> 
> Date: Fri, 28 Oct 2005 12:03:12 +0300 (EEST)
> From: Meelis Roos <mroos@linux.ee>
> To: Linux Kernel list <linux-kernel@vger.kernel.org>
> 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.

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

Re: Fw: 2.6.14: aic7xxx broken with blktool

[James Bottomley]

On Fri, 2005-10-28 at 04:02 -0700, Andrew Morton wrote:
> 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.

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

Re: Fw: 2.6.14: aic7xxx broken with blktool

[Meelis Roos]

>> 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).

-- 
Meelis Roos (mroos@ut.ee)      http://www.cs.ut.ee/~mroos/

Re: Fw: 2.6.14: aic7xxx broken with blktool

[Douglas Gilbert]

Meelis Roos wrote:
>>> 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.

> 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

Re: Fw: 2.6.14: aic7xxx broken with blktool

[Meelis Roos]

>> 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.

-- 
Meelis Roos (mroos@linux.ee)