Re: aic7xxx driver v6.2.5 freezes the kernel

Andrey Slepuhin (pooh@msu.ru)
Wed, 17 Apr 2002 19:31:57 +0400


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