AIC7902 lockups

AIC7902 lockups

[Thomas Beutin]

Hi,

sorry for asking again, but my problem with two disks connected
to an Adaptec AIC7902 still exists. Any help to solve the
annoying problem or hints are greatly appreciated.

Actually i'm using a vanilla linux kernel (2.4.21) with the
aic79xx-1.3.10 source unpacked on the right place in the kernel
sources. The kernel is compiled with SMP support (a complete
.config from the running kernel is available at
http://laokoon.in-berlin.de/~beutin/kernel-config.gz).

Three disks are connected to the first channel of the onboard
Adaptec AIC7902 of the Intel SE7501HG2 board (/proc/scsi/scsi):
Host: scsi0 Channel: 00 Id: 00 Lun: 00
  Vendor: IBM      Model: IC35L036UCPR15-0 Rev: S70H
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 01 Lun: 00
  Vendor: FUJITSU  Model: MAP3367NC        Rev: 0105
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 02 Lun: 00
  Vendor: FUJITSU  Model: MAP3367NC        Rev: 0105
  Type:   Direct-Access                    ANSI SCSI revision: 03
Host: scsi0 Channel: 00 Id: 06 Lun: 00
  Vendor: ESG-SHV  Model: SCA HSBP M15     Rev: 0.10
  Type:   Processor                        ANSI SCSI revision: 02

The first disk works perfect and the system starts up fine (only the
first disks file systems are in /etc/fstab). dmesg output looks
ok (is pretty long, You can find it on 
http://laokoon.in-berlin.de/~beutin/dmesg-after-boot.log.gz)

After accessing one of the FUJITSU disks the system hangs and the
dmesg output shows a lot of "DevQ(0:?:0): 0 waiting" and
card state dumps (the output is long, You can find it on
http://laokoon.in-berlin.de/~beutin/dmesg-mount-try.gz).

What can i do? Do i have any chance to get a stable system with
all three disks useable?

Thanks for reading and any suggestions!

Greetings,
-tb
-- 
Thomas Beutin                             tb@laokoon.IN-Berlin.DE
Beam me up, Scotty. There is no intelligent live down in Redmond.

Re: AIC7902 lockups

[Justin T. Gibbs]

> Hi,
> 
> sorry for asking again, but my problem with two disks connected
> to an Adaptec AIC7902 still exists. Any help to solve the
> annoying problem or hints are greatly appreciated.

The messages are not complete... the top is clipped.  Were you
using a serial console to capture this log?

Can you compile your kernel with register pretty printing enabled
in the driver?  It is a config time menu option.  This greatly
simplifies understanding the logs.

Can you also provide the output of "lspci -vv -n" from the
system as well as the output from "dmesg" right after boot.

--
Justin

Re: AIC7902 lockups

[Thomas Beutin]

Justin,

On Mon, Aug 11, 2003 at 11:27:50AM -0600, Justin T. Gibbs wrote:
> > 
> > sorry for asking again, but my problem with two disks connected
> > to an Adaptec AIC7902 still exists. Any help to solve the
> > annoying problem or hints are greatly appreciated.
> 
> The messages are not complete... the top is clipped.  Were you
> using a serial console to capture this log?
No, i did a "dmesg > file", but it seems the buffer is full after
booting so the first parts are lost. I've put syslog files on the web:
http://laokoon.in-berlin.de/~beutin/messages.gz
http://laokoon.in-berlin.de/~beutin/syslog.gz
http://laokoon.in-berlin.de/~beutin/debug.gz

And i tried to catch more dmesg output in a startup script. The result
is here: http://laokoon.in-berlin.de/~beutin/dmesg-boot.log.gz

The dmesg output from a shell right after complete boot is here:
http://laokoon.in-berlin.de/~beutin/dmesg-start.log.gz

And the dmesg output after trying to use one of the fujitsu drives
is here: http://laokoon.in-berlin.de/~beutin/dmesg-hd-access.log.gz

If You need more logs please tell me, i'll provide it.


> Can you compile your kernel with register pretty printing enabled
> in the driver?  It is a config time menu option.  This greatly
> simplifies understanding the logs.
The logs mentioned above are generated after reboot with a new kernel
compiled with CONFIG_AIC79XX_REG_PRETTY_PRINT=y

> Can you also provide the output of "lspci -vv -n" from the
> system as well as the output from "dmesg" right after boot.
For dmesg output please see above; the lspci output is here:
http://laokoon.in-berlin.de/~beutin/lspci.log.gz

Any help welcome, thanks for reading!
-tb
-- 
Thomas Beutin                             tb@laokoon.IN-Berlin.DE
Beam me up, Scotty. There is no intelligent live down in Redmond.

Re: AIC7902 lockups

[Justin T. Gibbs]

>> The messages are not complete... the top is clipped.  Were you
>> using a serial console to capture this log?
> No, i did a "dmesg > file", but it seems the buffer is full after
> booting so the first parts are lost. I've put syslog files on the web:

...

The logs are still not complete.  As best I can tell, the controller
is seeing CRC errors when talking to the Fujitsu drives, but these
drives are hanging up the bus instead of responding to our ATN condition.
I believe that these drives have newer firmware available that might
aid in CRC error recovery, but you should also double check your
cable, termination, etc.

--
Justin

Re: AIC7902 lockups

[Thomas Beutin]

Hi Justin,

thanks for Your answer!

On Wed, Aug 13, 2003 at 12:37:19PM -0600, Justin T. Gibbs wrote:
> >> The messages are not complete... the top is clipped.  Were you
> >> using a serial console to capture this log?
> > No, i did a "dmesg > file", but it seems the buffer is full after
> > booting so the first parts are lost. I've put syslog files on the web:
> 
> ...
> 
> The logs are still not complete.  As best I can tell, the controller
> is seeing CRC errors when talking to the Fujitsu drives, but these
> drives are hanging up the bus instead of responding to our ATN condition.
> I believe that these drives have newer firmware available that might
> aid in CRC error recovery, but you should also double check your
> cable, termination, etc.
I've put another syslog file on the web. IMHO it shows all the errors
with the scsi system. It's on
http://laokoon.in-berlin.de/~beutin/syslog.gz
If i can increase the debug level i will do it if it helps!

I cannot imagine a cabling problem, because the drives are in a hot
swap backplane and i changed the places of the drives (but having
the IBM drive every time as the first drive).
Or is it possible to have a bad cable from the board to the backplane,
beeing ok for the U160 IBM drive but not for a U360 drive? I'm using
the SCSI cable coming with the board, but i will try another next
time i've access to the machine.
Do You think, it could help to set the controller maximum to U160 on
the expected SCSI-IDs for the fujitsu drives?

Do You have any idea where to find the firmware an an update tool
for fujitsu drives?

Any hints or help welcome!

Thanks for reading!
-tb
-- 
Thomas Beutin                             tb@laokoon.IN-Berlin.DE
Beam me up, Scotty. There is no intelligent live down in Redmond.

Re: AIC7902 lockups

[Justin T. Gibbs]

>> The logs are still not complete.  As best I can tell, the controller
>> is seeing CRC errors when talking to the Fujitsu drives, but these
>> drives are hanging up the bus instead of responding to our ATN condition.
>> I believe that these drives have newer firmware available that might
>> aid in CRC error recovery, but you should also double check your
>> cable, termination, etc.
>
> I've put another syslog file on the web. IMHO it shows all the errors
> with the scsi system.

This confirms that it is a CRC error that causes the wedge.  You should
contact Fujitsu for a firmware update.

> I cannot imagine a cabling problem, because the drives are in a hot
> swap backplane and i changed the places of the drives (but having
> the IBM drive every time as the first drive).

Not all backplanes are rated for U320 operation.  Does the chassis
claim to be U320 capable?

> Or is it possible to have a bad cable from the board to the backplane,
> beeing ok for the U160 IBM drive but not for a U360 drive?

Yes.

> Do You think, it could help to set the controller maximum to U160 on
> the expected SCSI-IDs for the fujitsu drives?

You may have to run without packetized protocol in order for them
to function correctly.  This is different than just running at U160
speeds since U320 drives can operate in packetized mode at speeds
lower than U320.

--
Justin