Re: Bug: SCSI driver hangs in 2.6.6 and 2.6.7

Re: Bug: SCSI driver hangs in 2.6.6 and 2.6.7

[Kai OM]

The particular issue I'm having appears not to be a compiler issue; it's
happened when compiled using several versions of GCC, unless it's a
problem occuring in a range of versions of GCC.

My drive should be running in 32 bit synch, as well, but the newer
driver seems to force it into asynch.

I can't infer a lot about this issue, since I'm not a programmer or SCSI
expert, but I can observe and correlate.

Another person I know of has this issue as well, appended are links to
some log files of his.

http://ronmon.shacknet.nu/configs/scsi_boot_error

http://ronmon.shacknet.nu/configs/dmesg_good-2.6.7-rc3

http://ronmon.shacknet.nu/phpsysinfo/

http://ronmon.shacknet.nu/configs/lspci-vvx

----- Original message -----
From: "Thomas Greve" <thomas.greve@gmx.de>
To: "Kai OM" <epimetreus@fastmail.fm>
Date: Wed, 30 Jun 2004 01:46:54 +0200 (MEST)
Subject: Bug: SCSI driver hangs in 2.6.6 and 2.6.7

Hi Kai.

I encountered the same problem here, the kernel being caught in an
endless
loop during domain validation in scsi_transport_spi.c:spi_dv_retrain().

Interesting enough, this happens only while validating the 2nd of my two
hard disks (IBM DPSS-318350N on a Dawi Control sym80c875 host adapter).

The mm patches seem to contain a fix for this; since i did not get any
"dropping back" error messages after patching the file, this might as
well
be an optimisation problem with gcc 3.3.3.

After applying that patch, i got my kernel booting again, but the driver
reports / configures the hard disk as "asynchronous", what i suspect
might
be an unnecessary bottle neck:

<6>scsi(0:0:2:0): Beginning Domain Validation
<6>sym0:2: wide asynchronous.
<6>sym0:2: FAST-20 WIDE SCSI 40.0 MB/s ST (50.0 ns, offset 16)
<6>scsi(0:0:2:0): Ending Domain Validation

Hope this helps,

-- 
- Thomas

Bug: SCSI driver hangs in 2.6.6 and 2.6.7

[Kai OM]

It looks like there is some kind of bug in sym 2.1.18j that
prevents booting on some SCSI controllers.

I've tested my SCSI controller (LSIU160) against 2.6.7 and 2.6.6, and
both are proneto this bug. All kernel versions prior to this work
perfectly, as does Windows. The hard drive on that controller is a
Quantum ATLAS10K2-TY734J, in case it's pertinent.

I have no clue what the issue is, precisely, or if there's some obscure
bug in the firmware I'm using(LSI Logic's 4.19 - the latest version I
was able to find). Some Googling returned no results, so I have to
assume otherwise.

[PATCH] sym 2.1.18j sym 2.1.18j: 
- Add SPI
transport attributes (James Bottomley) 
- Use generic code to do Domain Validation (James Bottomley) 
- Stop using scsi_to_pci_dma_dir() (Christoph Hellwig) 
- Change some constants to their symbolic names (Grant Grundler) 
- Handle a race between a postponed command completing and the EH
retrying it (James Bottomley)
- If the auto request sense fails, issue a device reset (James
Bottomley) 

I'm not any fool's expert on SCSI, nor coding, so I can't really guess
what changes that weremade are the culprit, and since I don't know where
to get a copy of the patch that was submitted, I can't try reversing the
changes it made. If someone wants to link me to this patch, I'd be
interested to try that and see if it has any effect. 

I've already posted about this once, but I suspect it might have looked
a little like begging for "tech support", instead of reporting an actual
bug to some people, so I am guessing it was largely ignored. 

Anyway, I'd really like to, you know, use kernel versions after 2.6.5,
because that would rather severely
limit my ability to stay up-to-date in the Linux world after awhile.

 Thanks for any consideration this gets.