Messages in this thread | | | Date | Wed, 17 Apr 2002 19:31:57 +0400 | From | Andrey Slepuhin <> | Subject | Re: aic7xxx driver v6.2.5 freezes the kernel |
| |
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/
| |