aic7xxx and 2.4.3 failures

aic7xxx and 2.4.3 failures

[Jim Studt]

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}

-- 
                                     Jim Studt, President
                                     The Federated Software Group, Inc.

Re: aic7xxx and 2.4.3 failures

[Alan Cox]

> 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

Re: aic7xxx and 2.4.3 failures

[Jim Studt]

> > 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...
> 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 (rgooch@atnf.csiro.au)
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.

-- 
                                     Jim Studt, President
                                     The Federated Software Group, Inc.

Re: aic7xxx and 2.4.3 failures

[Gérard Roudier]

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.

On Mon, 9 Apr 2001, Jim Studt wrote:

> > > 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...
> > 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 (rgooch@atnf.csiro.au)
> 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.
> 
> -- 
>                                      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 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: aic7xxx and 2.4.3 failures - fix, it is interrupt routing

[Jim Studt]

G*rard Roudier insightfully opined..
> 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!

-- 
                                     Jim Studt, President
                                     The Federated Software Group, Inc.

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

[Gérard Roudier]

On Mon, 9 Apr 2001, Jim Studt wrote:

> G*rard Roudier insightfully opined..
> > 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.  

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.

Re: aic7xxx and 2.4.3 failures

[lists]

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


On Mon, Apr 09, 2001 at 03:33:47PM -0500, Jim Studt wrote:
> > > 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...
> > 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 (rgooch@atnf.csiro.au)
> 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.
> 
> -- 
>                                      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 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: aic7xxx and 2.4.3 failures

[Vivek Dasmohapatra]

On Mon, 9 Apr 2001, Alan Cox wrote:

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

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

Re: aic7xxx and 2.4.3 failures

[J . A . Magallon]

On 04.10 Vivek Dasmohapatra wrote:
> On Mon, 9 Apr 2001, Alan Cox wrote:
> 
> > > 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. 
> 

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

-- 
J.A. Magallon                                          #  Let the source
mailto:jamagallon@able.es                              #  be with you, Luke... 

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