2002-10-24 22:25:14

by Hanna Linder

[permalink] [raw]
Subject: more aic7xxx boot failure


> 2.5 Kernel Problem Reports as of 22 Oct
> Status Discussion Problem Title
>
> open 04 Oct 2002 AIC7XXX boot failure
> 1. http://marc.theaimsgroup.com/?l=linux-kernel&m=103356254615324&w=2
>


This may be a different problem but it is related to the aic7xxx
driver. My system is a 2-way PIII 500MHz 2.5GB RAM box. It boots
if I remove the aic7xxx driver. This is on 2.5.44 btw. Works fine
on 2.4.x.

Here is the output from lspci -v -v:


00:06.0 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 (rev 04)
Subsystem: Adaptec AHA-2940U/2940UW Dual AHA-394xAU/AUW/AUWD AIC-7895B
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 80 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 15
Region 0: I/O ports at 2200 [disabled] [size=256]
Region 1: Memory at febfe000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at <unassigned> [disabled] [size=64K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.1 SCSI storage controller: Adaptec AHA-2940U/UW / AHA-39xx / AIC-7895 (rev 04)
Subsystem: Adaptec AHA-2940U/2940UW Dual AHA-394xAU/AUW/AUWD AIC-7895B
Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV+ VGASnoop- ParErr+ Stepping- SERR- FastB2B-
Status: Cap+ 66Mhz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
Latency: 80 (2000ns min, 2000ns max)
Interrupt: pin B routed to IRQ 10
Region 0: I/O ports at 2300 [disabled] [size=256]
Region 1: Memory at febfd000 (32-bit, non-prefetchable) [size=4K]
Capabilities: [dc] Power Management version 1
Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-)
Status: D0 PME-Enable- DSel=0 DScale=0 PME-




2002-10-24 22:42:31

by Philippe Troin

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

Hanna Linder <[email protected]> writes:

> > 2.5 Kernel Problem Reports as of 22 Oct
> > Status Discussion Problem Title
> >
> > open 04 Oct 2002 AIC7XXX boot failure
> > 1. http://marc.theaimsgroup.com/?l=linux-kernel&m=103356254615324&w=2
> >
>
>
> This may be a different problem but it is related to the aic7xxx
> driver. My system is a 2-way PIII 500MHz 2.5GB RAM box. It boots
> if I remove the aic7xxx driver. This is on 2.5.44 btw. Works fine
> on 2.4.x.

What error do you get on boot?

Have you tried booting with "noapic"?

Phil.

2002-10-24 23:12:53

by Hanna Linder

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

--On Thursday, October 24, 2002 15:46:56 -0700 Philippe Troin <[email protected]> wrote:

>
> Have you tried booting with "noapic"?

Just did, That solves the problem too.


> What error do you get on boot?

a kernel panic and scsi_abort error 0x2 (from what
I remember flying by)

Would have to hookup with a serial cable to get all
the data. Here is what I can see on the screen:

LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x0
SSTAT0 = 0x0, SSTAT1 = 0x8
STACK == 0x17, 0x0, 0x0, 0x0
SCB count = 4
Kernel NEXQSCB = 3
Card NEXTQSCB = 0
QINFIFO entries: 3 2
a list of Waiting Queue entries
and a list of Disconnected Queue entries.
QUOTFIFI entries:
Sequencer Free SCB List: 0 to 31
Pending list: 2
Kernel Free SCB list: 1 0
Untagged Q(0): 2
DevQ(0:0:0):0 waiting
qinpos = 0, SCB index = 3
Kernel panic: Loop 1


Hanna


2002-10-24 23:14:30

by Philippe Troin

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

Hanna Linder <[email protected]> writes:

> --On Thursday, October 24, 2002 15:46:56 -0700 Philippe Troin <[email protected]> wrote:
>
> >
> > Have you tried booting with "noapic"?
>
> Just did, That solves the problem too.
>
>
> > What error do you get on boot?
>
> a kernel panic and scsi_abort error 0x2 (from what
> I remember flying by)
>
> Would have to hookup with a serial cable to get all
> the data. Here is what I can see on the screen:
>
> LASTPHASE = 0x1, SCSISIGI = 0x0, SXFRCTL0 = 0x0
> SSTAT0 = 0x0, SSTAT1 = 0x8
> STACK == 0x17, 0x0, 0x0, 0x0
> SCB count = 4
> Kernel NEXQSCB = 3
> Card NEXTQSCB = 0
> QINFIFO entries: 3 2
> a list of Waiting Queue entries
> and a list of Disconnected Queue entries.
> QUOTFIFI entries:
> Sequencer Free SCB List: 0 to 31
> Pending list: 2
> Kernel Free SCB list: 1 0
> Untagged Q(0): 2
> DevQ(0:0:0):0 waiting
> qinpos = 0, SCB index = 3
> Kernel panic: Loop 1

Had the same problem.

Booted noapic, problem solved...

Now, if the driver could be fixed, that would be nicer...

Phil.

2002-10-24 23:47:12

by SL Baur

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

Philippe Troin writes:

> Now, if the driver could be fixed, that would be nicer...

I've forward ported the aic7xxx driver in 2.4.20-pre11 (which works
excellently for me) to 2.5.44. I'll post the patches later this morning.

2002-10-25 00:33:12

by Philippe Troin

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

SL Baur <[email protected]> writes:

> Philippe Troin writes:
>
> > Now, if the driver could be fixed, that would be nicer...
>
> I've forward ported the aic7xxx driver in 2.4.20-pre11 (which works
> excellently for me) to 2.5.44. I'll post the patches later this morning.

I've seen the problem Hanna was talking about in 2.4.19 and
2.4.20-pre11.

Phil.

2002-10-25 03:46:33

by Doug Ledford

[permalink] [raw]
Subject: Re: more aic7xxx boot failure

On Thu, Oct 24, 2002 at 04:20:38PM -0700, Philippe Troin wrote:
> Hanna Linder <[email protected]> writes:
>
> > Pending list: 2
> > Kernel Free SCB list: 1 0
> > Untagged Q(0): 2
> > DevQ(0:0:0):0 waiting
> > qinpos = 0, SCB index = 3
> > Kernel panic: Loop 1
>
> Had the same problem.
>
> Booted noapic, problem solved...
>
> Now, if the driver could be fixed, that would be nicer...

If noapic solves the problem then the driver isn't where the bug is, it's
in the SMP irq table or ACPI irq routing or PCI interrupt routing, but it
is *not* the driver.

I will repeat, if "noapic" ever solves a driver bug, then the problem
wasn't a driver bug in the first place!

/me has been listening to people wrongly accuse drivers of IRQ routing
bugs for going on three years now, ever since the MP table parsing and
IO-APIC code was first put into the linux kernel and now tends to be a bit
testy when people make the mistake of calling an IRQ routing bug a driver
bug.

--
Doug Ledford <[email protected]> 919-754-3700 x44233
Red Hat, Inc.
1801 Varsity Dr.
Raleigh, NC 27606