aic7xxx 6.1.10 and 2.4.4-pre1

I used 5000ms. I still freeze up with 2.4.3 + 6.1.10.

Unfortunately i could not see any messages and nothing got logged. This time an fsck allowed me to boot back to 2.4.1.

The visible symptoms were the same as before (2.4.3 + 6.1.8) but this time I was unable to flip virtual consoles before the freeze so I dont even know 100% what is causing it - it boots fine - and the scsi driver makes no complaints - it all looks normal. X starts up and I can login. it starts ok and windows start popping up - shortly thereafter it freezes
- just like before.

I will try investigate further and see if I can get any more log messages.

Is there any debug boot option or compile flag that will help me find out more what is going on?

/var/log/messages says this about scsi.

Apr  7 19:56:13 snap kernel: scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.10
Apr  7 19:56:13 snap kernel:         <Adaptec 2940 Ultra2 SCSI adapter>
Apr  7 19:56:13 snap kernel:         aic7890/91: Wide Channel A, SCSI Id=7, 32/255 SCBs
Apr  7 19:56:13 snap kernel: 
Apr  7 19:56:13 snap kernel:   Vendor: YAMAHA    Model: CRW8424S          Rev: 1.0d
Apr  7 19:56:13 snap kernel:   Type:   CD-ROM                             ANSI SCSI revision: 02
Apr  7 19:56:13 snap kernel:   Vendor: SEAGATE   Model: ST318275LW        Rev: 0001
Apr  7 19:56:13 snap kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Apr  7 19:56:13 snap kernel: (scsi0:A:5): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Apr  7 19:56:13 snap kernel:   Vendor: SEAGATE   Model: ST318275LW        Rev: 0001
Apr  7 19:56:13 snap kernel:   Type:   Direct-Access                      ANSI SCSI revision: 02
Apr  7 19:56:13 snap kernel: (scsi0:A:6): 80.000MB/s transfers (40.000MHz, offset 15, 16bit)
Apr  7 19:56:13 snap kernel: scsi0:0:5:0: Tagged Queuing enabled.  Depth 253
Apr  7 19:56:13 snap kernel: scsi0:0:6:0: Tagged Queuing enabled.  Depth 253

Well my aicxxx problems continue:

I did it again and indeed verified similar error messages as I had under stock 2.4.3 and 2.4.3+aic 6.1.8. This time it died during boot itself starting with complaints from ssh/xinet et al - then I started seeing the scsi errors. (I believe I had also tried ac26 with similar problems hwhich IIRC is 6.1.5).

Anyway, it goes around in a loop with stuff like:

SCB 1 ...
scsi ...

  scsi   ... recovery complete ..
  scsi   ... code aweke ..
  scsi   ... aic7xxx_abort returns 8194

or somwething similar. The aic7xxx_abort returns 8194 i remember exactly the others I'm a bit shaky on. Anyway it seems to loop with the recovery/abort thing.

What can I do to help track down the problem?

Regards,

Gene/

-------------------------------------------------------------------

I enclose output of ver_linux - I note that it incorrectly reports util-linux becuase it uses mount --version. On my redhat system mount is 2.10r while util-linux is 2.10s-11.

Linux snap 2.4.1-0.1.9 #1 Wed Feb 14 22:15:15 EST 2001 i686 unknown

Gnu C                  2.96
Gnu make               3.79.1
binutils               2.10.91.0.2
util-linux             2.10r
modutils               2.4.5
e2fsprogs              1.19
reiserfsprogs          3.x.0b
pcmcia-cs              3.1.22
PPP                    2.4.0
Linux C Library        2.2.2
Dynamic linker (ldd)   2.2.2
Procps                 2.0.7
Net-tools              1.57
Console-tools          0.3.3
Sh-utils               2.0
Modules Loaded         emu10k1 soundcore autofs joydev hid input 3c59x ipchains ide-scsi ide-cd cdrom usb-uhci usbcore aic7xxx sd_mod scsi_mod

-------------------------------------------------------------------

I seem to recall this being a very buggy firmware version. You should check with Seagate to see if they have something new. If this is the firmware I'm thinking of, the driver should perform correctly if you disable write caching. You can do this via the SCSI-Select menu for the controller.

--
Justin

Justin:

Ya think very buggy? I checked seagate web page and unfortunately was unable to find any firmware updates for the barracuda drives.

Curious tho that this has worked flawlessly for well over a year with all prior version of linux and win2000 as well. Also a few other folks seem to have similar problems with newer kernels.

Do the newer drivers put a bigger demand on the drives that might start to uncover the problems previously not seen?

I did find newer firmware for the adaptec 2940u2w card tho so perhaps I should upgrade that?

I will try turning off write cache - kernel config option right?

Will report back.

Thanks for your help - it sure would be nice to be able to run with the newer kernels again!

Regards,

Gene/

I'm pretty sure you need to be up to at leaset 0005 of the firmware to stabilize this drive.

It all depends on the access pattern. The drive will only fail if you fill its write cache. At that point, it will fall off the bus, never to return.

Depends on your settings. If you are using the default, we run a much larger number of concurrent transactions when compared to the old driver.

If you aren't having problems with your BIOS today, there is no reason to flash the BIOS on teh 2940U2W.

SCSI-Select option.

--
Justin

FYI, I contacted seagate and they say the firmware is the latest.

Regards,

Gene/