2.4.8 aic7xxx -- continuous bus resets

2.4.8 aic7xxx -- continuous bus resets

[Andrew Scott]

I thought I'd look at the 2.4.8 kernel while I figure out what's 
wrong with my 2.2.18 installation. The kernel loading gets stuck with 
errors from the aic7xxx driver, which keeps timeing out querying the 
bus looking for non-existant drives, and when it finaly tries to 
query a drive that exists it claims to see bus errors. End result is 
that Linux 2.4.8 never mounts any drives or finishes loading.

The system is an IBM 704 with a built in adaptec aic-7880U 
controller, with two drives on first scsi buss. 

2.2.18 has no problems with the adaptec controllers, but has other 
issues, which seem to be timer related.



                      _
                     / \   / ascott@casdn.neu.edu
                    / \ \ /
                   /   \_/

Re: 2.4.8 aic7xxx -- continuous bus resets

[Justin T. Gibbs]

>
>I thought I'd look at the 2.4.8 kernel while I figure out what's 
>wrong with my 2.2.18 installation. The kernel loading gets stuck with 
>errors from the aic7xxx driver, which keeps timeing out querying the 
>bus looking for non-existant drives, and when it finaly tries to 
>query a drive that exists it claims to see bus errors. End result is 
>that Linux 2.4.8 never mounts any drives or finishes loading.
>
>The system is an IBM 704 with a built in adaptec aic-7880U 
>controller, with two drives on first scsi buss. 
>
>2.2.18 has no problems with the adaptec controllers, but has other 
>issues, which seem to be timer related.

2.4.9 has the latest aic7xxx driver in it.  Can you see if that changes
things for you?  If not, can you hook up a serial console to the machine
and provide all of the messages from an aic7xxx=verbose boot?

Thanks,
Justin

Re: 2.4.8 aic7xxx -- continuous bus resets

[David Ford]

IIRC, the fix for this in my situation was due to the pci irq routing on 
that particular motherboard and using noapic solved it.

Has the irq routing been fixed to date?

David

Justin T. Gibbs wrote:

>>I thought I'd look at the 2.4.8 kernel while I figure out what's 
>>wrong with my 2.2.18 installation. The kernel loading gets stuck with 
>>errors from the aic7xxx driver, which keeps timeing out querying the 
>>bus looking for non-existant drives, and when it finaly tries to 
>>query a drive that exists it claims to see bus errors. End result is 
>>that Linux 2.4.8 never mounts any drives or finishes loading.
>>
>>The system is an IBM 704 with a built in adaptec aic-7880U 
>>controller, with two drives on first scsi buss. 
>>
>>2.2.18 has no problems with the adaptec controllers, but has other 
>>issues, which seem to be timer related.
>>
>
>2.4.9 has the latest aic7xxx driver in it.  Can you see if that changes
>things for you?  If not, can you hook up a serial console to the machine
>and provide all of the messages from an aic7xxx=verbose boot?
>

2.4.10pre10 aic7xxx problem

[Benjamin Herrenschmidt]

Hi Justin !

I'm having a problem with the aic7xxx driver in 2.4.10pre10, it used to
work fine with 2.4.10pre8. The card is a 2960 single channel SCSI2, the
drive is a SEAGATE ST34520N rev. 1444.
Weirdly, the 2 drivers have the same rev. (maybe you didn't change it ?),
the other difference between those kernels is that I compiled 2.4.10pre10
SMP. The machine is a PowerMac dual G4/450

Basically, when probing for disks, my external <> gets stuck (activity
led on) and the driver displays those messages after a longer than usual
pause:

Attampting to queue an ABORT message
Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer expired
aic7xxx_abort returns 8195
Attempting to queue a TARGET RESET
aic7xxx_dev_reset returns 8195
Recovery SCB completes

and then more of it... the drive is not detected.

Any clue ?

Regards,
Ben.

Re: 2.4.10pre10 aic7xxx problem

[Justin T. Gibbs]

>Hi Justin !
>
>I'm having a problem with the aic7xxx driver in 2.4.10pre10, it used to
>work fine with 2.4.10pre8. The card is a 2960 single channel SCSI2, the
>drive is a SEAGATE ST34520N rev. 1444.
>Weirdly, the 2 drivers have the same rev. (maybe you didn't change it ?),

If the version number didn't change, then the kernels are using the same
driver.  I haven't been tracking the 2.4.10pre series, so I don't even
know what version is in there.

Please upgrade to v6.2.3.  By default it will dump lots of interesting
debug info when a timeout occurs.  You may need to use a serial console
to catch all of it.  The driver can be found here:

http://people.FreeBSD.org/~gibbs/linux/

--
Justin

Re: 2.4.8 aic7xxx -- continuous bus resets

[Andrew Scott]

On 16 Aug 2001, at 18:01, Justin T. Gibbs wrote:

> >
> >I thought I'd look at the 2.4.8 kernel while I figure out what's 
> >wrong with my 2.2.18 installation. The kernel loading gets stuck with 
> >errors from the aic7xxx driver, which keeps timeing out querying the 
> >bus looking for non-existant drives, and when it finaly tries to 
> >query a drive that exists it claims to see bus errors. End result is 
> >that Linux 2.4.8 never mounts any drives or finishes loading.
> >
> >The system is an IBM 704 with a built in adaptec aic-7880U 
> >controller, with two drives on first scsi buss. 
> >
> >2.2.18 has no problems with the adaptec controllers, but has other 
> >issues, which seem to be timer related.
> 
> 2.4.9 has the latest aic7xxx driver in it.  Can you see if that changes
> things for you?  If not, can you hook up a serial console to the machine
> and provide all of the messages from an aic7xxx=verbose boot?

Downloading now, will try this afternoon and let you know. 

Another person mentioned that there might be an irq routing problem, 
and using 'noapic' might fix the problem also. The machine has two 
ioapics, and it is possible to disable one through the bios setup. I 
have noticed that interrupt routeing is quite different with both 
ioapics enabled than with just one. 

Is there any benefit to enableing both, and will enableing just one 
fix the issue?




                      _
                     / \   / ascott@casdn.neu.edu
                    / \ \ /
                   /   \_/

Re: 2.4.8 aic7xxx -- continuous bus resets

[Justin T. Gibbs]

>Downloading now, will try this afternoon and let you know. 
>
>Another person mentioned that there might be an irq routing problem, 
>and using 'noapic' might fix the problem also. The machine has two 
>ioapics, and it is possible to disable one through the bios setup. I 
>have noticed that interrupt routeing is quite different with both 
>ioapics enabled than with just one. 
>
>Is there any benefit to enableing both, and will enableing just one 
>fix the issue?

I don't know the details of the Linux interrupt routing code.  You'd
have to ask those responsible for that portion of Linux's PCI support.
If playing with APIC settings fixes your problems, then we can safely
say that the aic7xxx driver is not at fault.

--
Justin

Re: 2.4.8 aic7xxx -- continuous bus resets

[Andrew Scott]

On 16 Aug 2001, at 18:01, Justin T. Gibbs wrote:

> >
> >I thought I'd look at the 2.4.8 kernel while I figure out what's 
> >wrong with my 2.2.18 installation. The kernel loading gets stuck with 
> >errors from the aic7xxx driver, which keeps timeing out querying the 
> >bus looking for non-existant drives, and when it finaly tries to 
> >query a drive that exists it claims to see bus errors. End result is 
> >that Linux 2.4.8 never mounts any drives or finishes loading.
> >
> >The system is an IBM 704 with a built in adaptec aic-7880U 
> >controller, with two drives on first scsi buss. 
> >
> >2.2.18 has no problems with the adaptec controllers, but has other 
> >issues, which seem to be timer related.
> 
> 2.4.9 has the latest aic7xxx driver in it.  Can you see if that changes
> things for you?  If not, can you hook up a serial console to the machine
> and provide all of the messages from an aic7xxx=verbose boot?

Ok, tried 2.4.9. With 1 ioapic the machine boots just fine. With the 
second ioapic enabled the behavior I previously described still 
occurs.

attempting to Queue abort
aic7xxx_abort returns 8194

These are the only error messages I copied down, I believe that there 
was another, will reboot and check later.




                      _
                     / \   / ascott@casdn.neu.edu
                    / \ \ /
                   /   \_/

Re: 2.4.8 aic7xxx -- continuous bus resets

[Justin T. Gibbs]

>> 2.4.9 has the latest aic7xxx driver in it.  Can you see if that changes
>> things for you?  If not, can you hook up a serial console to the machine
>> and provide all of the messages from an aic7xxx=verbose boot?
>
>Ok, tried 2.4.9. With 1 ioapic the machine boots just fine. With the 
>second ioapic enabled the behavior I previously described still 
>occurs.
>
>attempting to Queue abort
>aic7xxx_abort returns 8194
>
>These are the only error messages I copied down, I believe that there 
>was another, will reboot and check later.

Yup.  The driver is not seeing interrupts.

--
Justin

RE: 2.4.10pre10 aic7xxx problem

[Cress, Andrew R]

Benjamin,

I've seen some pretty heinous bugs in Big Bear firmware of that vintage.
I'll bet that the aic debug info will indicate that the disk goes out to
lunch.  I used to support a large customer who had a large population of
these disks and we went through a lot of pain debugging these drives with
Seagate.
The solution will likely be one or both of these changes:
  1) Upgrade the disk firmware to 1497 or later 
         (I have a copy if it's not readily available to you.)
     The servo should also be 6246 or later.
  2) Turn off SMART in mode page 1C (88 00).  Also the default number of
retries for the factory settings are way too high.  The mode page settings
for ST34520W should look like this:
pg len ....
-- --  
01 0a c4 20 79 00 00 00 20 00 ff ff
02 0e e0 e0 00 00 00 00 00 00 00 00 00 00 00 00
03 16 00 00 1f 61 00 00 00 00 00 f6 02 00 00 01 00 24 00 34 40 00 00 00
04 16 00 23 2e 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 20 00 00
07 0a 0c 20 79 00 00 00 00 00 ff ff
08 12 90 00 ff ff 00 00 ff ff ff ff 80 01 00 00 00 00 00 00
0a 0a 00 00 00 00 00 00 ff ff 00 00
1c 0a 88 00 00 00 00 00 00 00 00 01

Let me know if you need more info.

Andy

-----Original Message-----
From: Justin T. Gibbs [mailto:gibbs@scsiguy.com]
Sent: Thursday, September 20, 2001 1:11 PM
To: Benjamin Herrenschmidt
Cc: linux-kernel@vger.kernel.org
Subject: Re: 2.4.10pre10 aic7xxx problem 


>Hi Justin !
>
>I'm having a problem with the aic7xxx driver in 2.4.10pre10, it used to
>work fine with 2.4.10pre8. The card is a 2960 single channel SCSI2, the
>drive is a SEAGATE ST34520N rev. 1444.
>Weirdly, the 2 drivers have the same rev. (maybe you didn't change it ?),

If the version number didn't change, then the kernels are using the same
driver.  I haven't been tracking the 2.4.10pre series, so I don't even
know what version is in there.

Please upgrade to v6.2.3.  By default it will dump lots of interesting
debug info when a timeout occurs.  You may need to use a serial console
to catch all of it.  The driver can be found here:

http://people.FreeBSD.org/~gibbs/linux/

--
Justin
-
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: 2.4.10pre10 aic7xxx problem

[Benjamin Herrenschmidt]

>I've seen some pretty heinous bugs in Big Bear firmware of that vintage.
>I'll bet that the aic debug info will indicate that the disk goes out to
>lunch.  I used to support a large customer who had a large population of
>these disks and we went through a lot of pain debugging these drives with
>Seagate.
>The solution will likely be one or both of these changes:
>  1) Upgrade the disk firmware to 1497 or later 
>         (I have a copy if it's not readily available to you.)
>     The servo should also be 6246 or later.
>  2) Turn off SMART in mode page 1C (88 00).  Also the default number of
>retries for the factory settings are way too high.  The mode page settings
>for ST34520W should look like this:
>pg len ....
>-- --  
>01 0a c4 20 79 00 00 00 20 00 ff ff
>02 0e e0 e0 00 00 00 00 00 00 00 00 00 00 00 00
>03 16 00 00 1f 61 00 00 00 00 00 f6 02 00 00 01 00 24 00 34 40 00 00 00
>04 16 00 23 2e 04 00 00 00 00 00 00 00 00 00 00 00 00 00 00 1c 20 00 00
>07 0a 0c 20 79 00 00 00 00 00 ff ff
>08 12 90 00 ff ff 00 00 ff ff ff ff 80 01 00 00 00 00 00 00
>0a 0a 00 00 00 00 00 00 ff ff 00 00
>1c 0a 88 00 00 00 00 00 00 00 00 01

Ok, thanks. I don't have the firmwares not I know how to update it on
those disks. I can try hacking the mode pages however.

The "weird" thing is that this same disk works perfectly well on MacOS
with the same HW config, and used to work fine in linux until very
recently.

Justin suggested an interrupt problem. I'll look into it in more detail,
but I don't think there's anything like that. This box (PowerMac G4) has
a quite clean interrupt mapping provided by the firmware with no interrupt
sharing, and things related to parsing that firmware didn't evolve lately
(there have been no significant change to PPC OpenPIC interrupt management
since a long time).

Regards,
Ben.