aic7xxx driver v6.2.4 "queue abort message" questions

aic7xxx driver v6.2.4 "queue abort message" questions

[Richard Harman]

I've got a box that will nolonger boot off it's scsi disk anymore, (but dual booting to windows works just fine...) did anyone ever get to the bottom of what caused the "attempting to queue an abort message" bug was?  I've tried booting my normal 2.4.16+preempt and a 2.4.2 kernel known to work previously and neither get pass trying to identify the devices on both channels.

Richard G Harman Jr <rharman+nospam@xabean.net>

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Justin T. Gibbs]

>I've got a box that will nolonger boot off it's scsi disk anymore, (but dual b
>ooting to windows works just fine...) did anyone ever get to the bottom of wha
>t caused the "attempting to queue an abort message" bug was?

Those messages don't usually indicate bugs.  Without knowing more about
your system, the devices attached to it, if you happen to have one of
those broken VIA chipsets, etc. its hard to diagnose your problem.

--
Justin

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Richard Harman]

It's a dual P3 600/100 with 512mb of ram, tyan thunder 100 gx (s1836dulan model) with an onboard aic-7895 dual channel UW SCSI.  I'm booting off channel B (the 68pin only channel) Id 1, which is my seagate 36g SCA drive in a 5 bay sca enclosure.  Id 0 is a ultraplex 40x. Channel A has a 50pin 8x2x20 plexwriter.  The motherboard has a PIIX4 (GX) chipset.  (http://www.tyan.com/products/html/a_thunder100gx.html)

I've hand copied down what I could of the v6.2.4 driver's debug messages, but wasn't able to catch all of it.  (I hope to switch to serial console as soon as I find a null modem cable and log it that way.)  Shall I send the screenfull to the list or you directly?

Thanks,
Richard G Harman Jr <rharman+nospam@xabean.net>

  Quoted from "Justin T. Gibbs":
> >I've got a box that will nolonger boot off it's scsi disk anymore, (but dual b
> >ooting to windows works just fine...) did anyone ever get to the bottom of wha
> >t caused the "attempting to queue an abort message" bug was?
> 
> Those messages don't usually indicate bugs.  Without knowing more about
> your system, the devices attached to it, if you happen to have one of
> those broken VIA chipsets, etc. its hard to diagnose your problem.
> 
> --
> Justin
> 

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Len Sorensen]

On Wed, Jan 16, 2002 at 11:01:11AM -0500, Richard Harman wrote:
> It's a dual P3 600/100 with 512mb of ram, tyan thunder 100 gx (s1836dulan model) with an onboard aic-7895 dual channel UW SCSI.  I'm booting off channel B (the 68pin only channel) Id 1, which is my seagate 36g SCA drive in a 5 bay sca enclosure.  Id 0 is a ultraplex 40x. Channel A has a 50pin 8x2x20 plexwriter.  The motherboard has a PIIX4 (GX) chipset.  (http://www.tyan.com/products/html/a_thunder100gx.html)
> 
> I've hand copied down what I could of the v6.2.4 driver's debug messages, but wasn't able to catch all of it.  (I hope to switch to serial console as soon as I find a null modem cable and log it that way.)  Shall I send the screenfull to the list or you directly?

I was having this problem as well on an iBM M-Pro P2 450 with the aic7895
onboard (dual channel), while an identical P2 400 did not seem to have
the same problem with the same kernel build.

I think the problem started around 2.4.13 or so.  I can boot from warn
reboot, but not cold reboot.

I just tried applying the aic7xxx 6.2.5 driver patch to replace 6.2.4
that is in 2.4.18, and it actually appears to have removed the problem.
I know the new version asks in the config if you want to probe for
EISA/VLB cards, which I set to no, so either that fixed it (I should
try aic7xxx=no_probe with the other kernel), or something else in the
changes in the code has fixed it.  I personally suspect a marginal timing
issue during init given the 400mhz machine is fine and the 450mhz machine
was not.  Having not read through all the code changes in the patch,
I am not sure.

Len Sorensen

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Justin T. Gibbs]

>I just tried applying the aic7xxx 6.2.5 driver patch to replace 6.2.4
>that is in 2.4.18, and it actually appears to have removed the problem.

This was a known issue that was corrected in 6.2.5.  The driver was
referencing an uninitialized register on the card, which cause the
parity error.  The uninitialized reference was harmless as the value
was ignored in the cases that it was uninitialized, but the panic it
created was a bit rough on users. 8-)

--
Justin

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Andrey Slepuhin]

On Fri, Mar 15, 2002 at 12:31:22PM -0700, Justin T. Gibbs wrote:
> >I just tried applying the aic7xxx 6.2.5 driver patch to replace 6.2.4
> >that is in 2.4.18, and it actually appears to have removed the problem.
> 
> This was a known issue that was corrected in 6.2.5.  The driver was
> referencing an uninitialized register on the card, which cause the
> parity error.  The uninitialized reference was harmless as the value
> was ignored in the cases that it was uninitialized, but the panic it
> created was a bit rough on users. 8-)

This weekend I ran into exactly the same problem with parity errors,
but after updating to 6.2.5 driver version, kernel completely stalls just
after the line
  SCSI subsystem driver Revision: 1.00

The system in problem is:

Dual PIII-1266,
SuperMicro P3TDER motherboard,
onboard aic7899 SCSI controller:
  Bus  0, device   5, function  1:
    SCSI storage controller: Adaptec 7899P (#2) (rev 1).
      IRQ 27.
      Master Capable.  Latency=64.  Min Gnt=40.Max Lat=25.
      I/O at 0xd800 [0xd8ff].
      Non-prefetchable 64 bit memory at 0xfeaff000 [0xfeafffff].
  Bus  0, device   5, function  0:
    SCSI storage controller: Adaptec 7899P (rev 1).
      IRQ 26.
      Master Capable.  Latency=64.  Min Gnt=40.Max Lat=25.
      I/O at 0xd000 [0xd0ff].
      Non-prefetchable 64 bit memory at 0xfeafc000 [0xfeafcfff].


I tried both updating driver for kernel 2.4.18-ac3 and switching to
kernel 2.4.19-pre3-ac1 - the same effect. Though on another computer with
Asus P2B-DS motherboard (onboard aic7890) kernel 2.4.19-pre3-ac1 works fine.

Regards,
Andrey.

-- 
A right thing should be simple (tm)

aic7xxx driver v6.2.5 freezes the kernel

[Andrey Slepuhin]

On Mon, Mar 18, 2002 at 03:58:32PM +0300, Andrey Slepuhin wrote:
> On Fri, Mar 15, 2002 at 12:31:22PM -0700, Justin T. Gibbs wrote:
> > >I just tried applying the aic7xxx 6.2.5 driver patch to replace 6.2.4
> > >that is in 2.4.18, and it actually appears to have removed the problem.
> > 
> > This was a known issue that was corrected in 6.2.5.  The driver was
> > referencing an uninitialized register on the card, which cause the
> > parity error.  The uninitialized reference was harmless as the value
> > was ignored in the cases that it was uninitialized, but the panic it
> > created was a bit rough on users. 8-)
> 
> This weekend I ran into exactly the same problem with parity errors,
> but after updating to 6.2.5 driver version, kernel completely stalls just
> after the line
>   SCSI subsystem driver Revision: 1.00

[snip]

I tracked the problem down to ahc_read_seeprom(), which hangs in
CLOCK_PULSE() at aic7xxx_93cx6.c:161. But I have no idea what happens,
because this code is the same as in 6.2.4 version of the driver.

Regards,
Andrey.

-- 
A right thing should be simple (tm)

Re: aic7xxx driver v6.2.5 freezes the kernel

[Justin T. Gibbs]

>I tracked the problem down to ahc_read_seeprom(), which hangs in
>CLOCK_PULSE() at aic7xxx_93cx6.c:161. But I have no idea what happens,
>because this code is the same as in 6.2.4 version of the driver.

Is the driver using memory mapped I/O with the new driver but I/O
mapped in the old?  I will add a timeout to the CLOCK_PULSE() code,
but that still doesn't explain why the hang is happening now.

--
Justin

Re: aic7xxx driver v6.2.4 "queue abort message" questions

[Justin T. Gibbs]

>The system in problem is:
>
>Dual PIII-1266,
>SuperMicro P3TDER motherboard,

BTW, I have done extensive testing on a P3TDE6 which uses the
same chipset.  Can you send me your kernel configuration in private
email so I can try to reproduce this?

--
Justin