aic7xxx and 2.4.3 failures

DISCUSSION Jim Studt 6 participants 9 messages Apr 9, 2001 – Apr 10, 2001

Share & tools

Jim Studt

author

2001-04-09 19:33 UTC #0 lore raw

I've got a trio of identical PIII machines all failing with aic7xxx under 2.4.3. I've tried both aic7xxx 6.1.9 and 6.1.10 in addition to the one in 2.4.3 (6.1.5?). These machines work fine under 2.2.18pre21.

I'm looking for any ideas or suggestions on how to fix this. (Ok, honestly I'm hoping someone will say `you fool, read this message', but I don't have high hopes for that.)

A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)

SCSI subsystem driver Revision: 1.00 request_module[scsi_hostadapter]: Root fs not mounted request_module[scsi_hostadapter]: Root fs not mounted
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
scsi0 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
<Adaptec aic7896/97 Ultra2 SCSI adapter> aic7896/97: Wide Channel A, SCSI Id=7, 32/255 SCBs

scsi1 : Adaptec AIC7XXX EISA/VLB/PCI SCSI HBA DRIVER, Rev 6.1.9
<Adaptec aic7896/97 Ultra2 SCSI adapter> aic7896/97: Wide Channel B, SCSI Id=7, 32/255 SCBs

scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:0:0: Attempting to queue an ABORT message
scsi0:0:0:0: Device is active, asserting ATN
Recovery code sleeping
Recovery code awake
Timer Expired
aic7xxx_abort returns 8195
scsi0:0:0:0: Attempting to queue a TARGET RESET message
aic7xxx_dev_reset returns 8195
Recovery SCB completes
scsi0:0:0:0: Attempting to queue an ABORT message
ahc_intr: HOST_MSG_LOOP bad phase 0x0
scsi0:0:0:0: Cmd aborted from QINFIFO
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 0 lun 0

It repeats this for each ID for which a device exists. There actually is a unit 0 and 1 on this bus. The error stream is slightly different for unused IDs...

scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue a TARGET RESET message
scsi0:0:2:0: Is not an active device
aic7xxx_dev_reset returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi0:0:2:0: Attempting to queue an ABORT message
scsi0:0:2:0: Command already completed
aic7xxx_abort returns 8194
scsi: device set offline - not ready or command retry failed after bus reset: host 0 channel 0 id 2 lun 0

After failing on all 32 potential IDs at something like 47 seconds per ID the boot proceeds and fails to mount the root partition which is on these disks.

Other potentially useful information gathered from 2.2.18pre21... /proc/pci says....
00:0c.1 SCSI storage controller: Adaptec 7896
Subsystem: Adaptec: Unknown device 0053
Flags: bus master, medium devsel, latency 64, IRQ 11 BIST result: 00
I/O ports at 2800
Memory at f4102000 (64-bit, non-prefetchable)
Capabilities: [dc] Power Management version 1

dotdot-new:~# cat /proc/scsi/aic7xxx/0
Adaptec AIC7xxx driver version: 5.1.31/3.2.4
Compile Options:
  TCQ Enabled By Default : Disabled
  AIC7XXX_PROC_STATS     : Enabled
  AIC7XXX_RESET_DELAY    : 15

Adapter Configuration:
SCSI Adapter: Adaptec AIC-7896/7 Ultra2 SCSI host adapter
Ultra-2 LVD/SE Wide Controller Channel A at PCI 0/12/0
PCI MMAPed I/O Base: 0xf4101000
Adapter SEEPROM Config: SEEPROM found and used.

      Adaptec SCSI BIOS: Enabled
                    IRQ: 11
                   SCBs: Active 0, Max Active 2,
                         Allocated 15, HW 32, Page 255
             Interrupts: 3366
      BIOS Control Word: 0x18a6
   Adapter Control Word: 0x1c5e
   Extended Translation: Enabled
Disconnect Enable Flags: 0xffff
     Ultra Enable Flags: 0x0000

Tag Queue Enable Flags: 0x0000
Ordered Queue Tag Flags: 0x0000
Default Tag Queue Depth: 8
Tagged Queue By Device array for aic7xxx host instance 0:
{255,255,255,255,255,255,255,255,255,255,255,255,255,255,255,255}
Actual queue depth per device for aic7xxx host instance 0:
{1,1,1,1,1,1,1,1,1,1,1,1,1,1,1,1}

Signature · 2 lines

                                     Jim Studt, President
                                     The Federated Software Group, Inc.

Alan Cox

2001-04-09 20:18 UTC #1 lore raw

Quoted 4 lines

A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)

Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it

Jim Studt

author

2001-04-09 20:34 UTC #2 lore raw

Quoted 5 lines

Quoted 4 lines
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)

Alan Cox directs...

Quoted 4 lines

Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it

Using AIC7XXX_OLD does not work either. Different output....

SCSI subsystem driver Revision: 1.00
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
...

Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement.

There is an unrecognized PCI bridge resource in the boot messages...

CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0. CPU serial number disabled.
CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX [8086/7110] at 00:12.0

# lspci
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:0c.0 SCSI storage controller: Adaptec 7896
00:0c.1 SCSI storage controller: Adaptec 7896
00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23)
01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)

I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me.

Signature · 2 lines

                                     Jim Studt, President
                                     The Federated Software Group, Inc.

Gérard Roudier

2001-04-09 21:26 UTC #3 lore raw

Looks like an IRQ problem to me.
I mean the kernel wants to change IRQ routing and just do the wrong job.

Ingo reported me a similar problem a couple of week ago that made failed the sym53c8xx driver. Looks very similar to this one with the kernel PCI code wanting to assign IRQ 11 to almost everything.

Btw, I donnot know the cause of the problem since I am still expecting some reply following some suggestions from me. :-)

Gerard.

Quoted 95 lines · Jim Studt

Quoted 5 lines
Quoted 4 lines
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)
Alan Cox directs...
Quoted 4 lines
Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it
Using AIC7XXX_OLD does not work either. Different output....
SCSI subsystem driver Revision: 1.00
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
..
Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement.
There is an unrecognized PCI bridge resource in the boot messages...
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0. CPU serial number disabled.
CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX [8086/7110] at 00:12.0
# lspci
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:0c.0 SCSI storage controller: Adaptec 7896
00:0c.1 SCSI storage controller: Adaptec 7896
00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23)
01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)
I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me.
Signature · 7 lines
                                     Jim Studt, President
                                     The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Jim Studt

author

2001-04-09 22:12 UTC #4 lore raw

Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing

G*rard Roudier insightfully opined..

Quoted 2 lines

Looks like an IRQ problem to me.
I mean the kernel wants to change IRQ routing and just do the wrong job.

Give the man a prize!

After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I enabled X86_UP_IOAPIC to stir up the interrupt code and it works.

I'll keep one of these servers set aside for testing and see if I can't figure out a little more specifically what the problem is, but IOAPIC is fine.

Thanks for the help all!

Signature · 2 lines

                                     Jim Studt, President
                                     The Federated Software Group, Inc.

Gérard Roudier

2001-04-10 18:24 UTC #5 lore raw

Re: aic7xxx and 2.4.3 failures - fix, it is interrupt routing

Quoted 4 lines · Jim Studt

G*rard Roudier insightfully opined..
Quoted 2 lines
Looks like an IRQ problem to me.
I mean the kernel wants to change IRQ routing and just do the wrong job.

Quoted 8 lines

Give the man a prize!
After failing to work with 2.4.0, 2.4.1, 2.4.3, and 2.4.3-ac3 I enabled X86_UP_IOAPIC to stir up the interrupt code and it works.
I'll keep one of these servers set aside for testing and see if I can't figure out a little more specifically what the problem is, but IOAPIC is fine.

Probably because the code that messes with IRQs isn't involved when IOAPIC is used. If I had to guess I would point "arch/i386/kernel/pci-irq.c", function "pcibios_lookup_irq()".

Gérard.

[email protected]

2001-04-09 20:55 UTC #6 lore raw

In reply to Alan Cox

I confirm similar problems (see my message from yesterday). AIC7XXX_OLD also failed for me. I have tried aic 6.1.8 as well as 6.1.10.

Both 2.4.0 under redhat 7.0 and 2.4.1 as shipped by redhat wolverine work. As have all earlier versions going back to 2.3.xx and 2.2.x

Quoted 94 lines · Jim Studt

Quoted 5 lines
Quoted 4 lines
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)
Alan Cox directs...
Quoted 4 lines
Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works. This is important both because it might solve your problem for now but also because if the old driver works we can be fairly sure the bug is in the new adaptec driver and not elsewhere and triggered on it
Using AIC7XXX_OLD does not work either. Different output....
SCSI subsystem driver Revision: 1.00
PCI: Assigned IRQ 11 for device 00:0c.0
PCI: The same IRQ used for device 00:0c.1
PCI: Found IRQ 11 for device 00:0c.1
PCI: The same IRQ used for device 00:0c.0
(scsi0) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/0
(scsi0) Wide Channel A, SCSI ID=7, 32/255 SCBs
(scsi0) Downloading sequencer code... 392 instructions downloaded
(scsi1) <Adaptec AIC-7896/7 Ultra2 SCSI host adapter> found at PCI 0/12/1
(scsi1) Wide Channel B, SCSI ID=7, 32/255 SCBs
(scsi1) Downloading sequencer code... 392 instructions downloaded
scsi0 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi1 : Adaptec AHA274x/284x/294x (EISA/VLB/PCI-Fast SCSI) 5.2.1/5.2.0
<Adaptec AIC-7896/7 Ultra2 SCSI host adapter>
scsi : aborting command due to timeout : pid 0, scsi0, channel 0, id 0, lun 0 Inquiry 00 00 00 ff 00 SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 channel 0 reset (pid 0) timed out - trying harder
SCSI bus is being reset for host 0 channel 0.
SCSI host 0 abort (pid 0) timed out - resetting
SCSI bus is being reset for host 0 channel 0.
...
Since we are looking elsewhere now... I have tried PCI access mode BIOS and Direct with no improvement.
There is an unrecognized PCI bridge resource in the boot messages...
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0. CPU serial number disabled.
CPU: Intel Pentium III (Coppermine) stepping 06 Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Checking 'hlt' instruction... OK.
POSIX conformance testing by UNIFIX
mtrr: v1.37 (20001109) Richard Gooch ([email protected])
mtrr: detected mtrr type: Intel
PCI: Using configuration type 1
PCI: Probing PCI hardware
Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent Unknown bridge resource 0: assuming transparent Unknown bridge resource 1: assuming transparent Unknown bridge resource 2: assuming transparent
PCI: Discovered primary peer bus ff [IRQ]
PCI: Using IRQ router PIIX [8086/7110] at 00:12.0
# lspci
00:00.0 Host bridge: Intel Corporation 440GX - 82443GX Host bridge
00:01.0 PCI bridge: Intel Corporation 440GX - 82443GX AGP bridge
00:0c.0 SCSI storage controller: Adaptec 7896
00:0c.1 SCSI storage controller: Adaptec 7896
00:0e.0 Ethernet controller: Intel Corporation 82557 [Ethernet Pro 100] (rev 08)
00:12.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
00:12.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
00:12.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
00:12.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
00:14.0 VGA compatible controller: Cirrus Logic GD 5480 (rev 23)
01:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21150 (rev 06)
I will go back and try 2.4.0 and 2.4.3-ac3 and see where that gets me.
Signature · 7 lines
                                     Jim Studt, President
                                     The Federated Software Group, Inc.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Vivek Dasmohapatra

2001-04-09 22:34 UTC #7 lore raw

In reply to Alan Cox

Quoted 5 lines · Alan Cox

Quoted 3 lines
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)
Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that works.

I had similar problems w. 2.4.3 on an SMP aic7xx PII, box: new driver never managed to mount the root partition - always panicked first. Old driver worked fine.

Signature · 2 lines

"Aren't you ashamed of yourself?"
"No, I have people to do that for me."

J . A . Magallon

2001-04-09 23:38 UTC #8 lore raw

In reply to Alan Cox

Quoted 6 lines · On 04.10 Vivek Dasmohapatra wrote:

Quoted 4 lines · Alan Cox
Quoted 3 lines
A typical startup with 6.1.9 proceeds like this... (6.1.10 hangs silently after emitting the scsi0 and scsi1 adapter summaries, maybe it is going through the same gyrations silently.)

Quoted 7 lines

Quoted 1 line
Try saying N to the AIC7xxx driver and Y to AIC7XXX_OLD and see if that
works.
I had similar problems w. 2.4.3 on an SMP aic7xx PII, box: new driver never managed to mount the root partition - always panicked first. Old driver worked fine.

I am using 2.4.3-ac3 successfully with 6.1.8, 9 and 10, and now building with 11.

Signature · 4 lines

J.A. Magallon                                          #  Let the source
mailto:[email protected]                              #  be with you, Luke... 

Linux werewolf 2.4.3-ac3 #1 SMP Thu Apr 5 00:28:45 CEST 2001 i686