Re: aic7xxx driver v6.2.5 freezes the kernel

[Andrey Slepuhin]

On Wed, Apr 17, 2002 at 08:54:11AM -0600, Justin T. Gibbs wrote:
> >All other changes were successfully merged without any problems.
> >BTW, version 6.2.6 of the driver from 2.4.19-pre7 freezes the system too.
> 
> What motherboard is this again?

P3TDER with dual channel U160 aic7899 controller onboard:

00:05.0 SCSI storage controller: Adaptec 7899P (rev 01)
        Subsystem: Unknown device 9d15:0001
        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: 40 min, 25 max, 64 set, cache line size 04
        Interrupt: pin A routed to IRQ 26
        BIST result: 00
        Region 0: I/O ports at d000 [disabled] [size=256]
        Region 1: Memory at feafc000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at feaa0000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:05.1 SCSI storage controller: Adaptec 7899P (rev 01)
        Subsystem: Unknown device 9d15:0001
        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: 40 min, 25 max, 64 set, cache line size 04
        Interrupt: pin B routed to IRQ 27
        BIST result: 00
        Region 0: I/O ports at d800 [disabled] [size=256]
        Region 1: Memory at feaff000 (64-bit, non-prefetchable) [size=4K]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- AuxPwr- DSI- D1- D2- PME-
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

>  Perhaps your PCI bus is running just
> a hair bit faster than 66MHz?

I doubt it. 

>  A similar issue was discovered with the
> U320 controllers running at 133MHz PCI-X where some amount of delay is
> required prior to accessing chip registers again after setting
> CHIPRST.
> 
> The code was flipped so that the delay was acurate.  In PCI, you
> are only guaranteed that the write has been flushed all the way to the
> device by performing a read to that device.  I guess we'll just have to
> hope that our write transaction isn't stalled.
> 
> I'll make a 6.2.7 <sigh> drop later today.

Ok, I'll test it.

Andrey.

-- 
A right thing should be simple (tm)