Sergei Shtylyov wrote:
Then it's probably the same issue as here:
http://bugzilla.kernel.org/show_bug.cgi?id=7703
What's really strange is that my HPT370 is working fine. However,
the chip marking says it's HPT370A despite the revision ID is 3 (which
should correspond to HPT370)...
Unfortunately, I'm unable to compile a 2.4.18 kernel (my gcc is probably
too new) for testing.
But anyways - do you think there's hope for fixing this? If I can
provide you with any more helpful information, please tell me.
My controller is:
http://www.michael-bueker.de/files/hpt370/
01:09.0 Mass storage controller: Triones Technologies, Inc.
HPT366/368/370/370A/372/372N (rev 03)
Subsystem: Triones Technologies, Inc. HPT370 UDMA100
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: 120 (2000ns min, 2000ns max)
Interrupt: pin A routed to IRQ 11
Region 0: I/O ports at 9000 [size=8]
Region 1: I/O ports at 9400 [size=4]
Region 2: I/O ports at 9800 [size=8]
Region 3: I/O ports at 9c00 [size=4]
Region 4: I/O ports at a000 [size=256]
Expansion ROM at da020000 [disabled] [size=128K]
~Mik
--
Hey Fred, did you save that posting about restoring filesystems
with vi and a toothpick? More importantly, did you print it out?
- From "101 Things You Don't Want To Hear Your Admin Say"
-
To unsubscribe from this list: send the line "unsubscribe linux-ide" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
