more aic7xxx boot failure

more aic7xxx boot failure

[Hanna Linder]

>                                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-

Re: more aic7xxx boot failure

[Philippe Troin]

Hanna Linder <hannal@us.ibm.com> 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.

Re: more aic7xxx boot failure

[Hanna Linder]

--On Thursday, October 24, 2002 15:46:56 -0700 Philippe Troin <phil@fifi.org> 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

Re: more aic7xxx boot failure

[Philippe Troin]

Hanna Linder <hannal@us.ibm.com> writes:

> --On Thursday, October 24, 2002 15:46:56 -0700 Philippe Troin <phil@fifi.org> 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.

Re: more aic7xxx boot failure

[SL Baur]

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.

Re: more aic7xxx boot failure

[Philippe Troin]

SL Baur <steve@kbuxd.necst.nec.co.jp> 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.

Re: more aic7xxx boot failure

[Doug Ledford]

On Thu, Oct 24, 2002 at 04:20:38PM -0700, Philippe Troin wrote:
> Hanna Linder <hannal@us.ibm.com> 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 <dledford@redhat.com>     919-754-3700 x44233
         Red Hat, Inc. 
         1801 Varsity Dr.
         Raleigh, NC 27606