Messages in this thread |  | | Date | Sat, 31 Aug 2002 01:57:30 -0500 (CDT) | From | Mike Isely <> | Subject | Re: 2.4.20-pre4-ac1 trashed my system |
| |
On Fri, 30 Aug 2002, Andre Hedrick wrote:
> On Sat, 31 Aug 2002, Mike Isely wrote: > > > On Fri, 30 Aug 2002, Andre Hedrick wrote: > > > > Okay that sounds more like it. The driver did not damage the data, only > user space forced down the driver trashed it. Regardless of the > definition of "is" you system was wrecked.
No permanent harm. It was a workstation, and most of the 160GB drive was being used primarily as a backup device for a separate file server machine. Obviously I'd like to get that "backup device" up and running again.
> > > > > > Linux failed to understand cut off partitions. > > > > ??? > > This was a great concern of mine when 48-bit was introduced.
Ah, a riddle answered with another riddle. I know what 48 bit addresing is; I'm just curious to understand why my system seems to have run afoul of it, especially since things were ok before. (but read on...)
> > What are the "rules of Promise" or where may I find such information? > > You do not want to sign the NDA's to get the data sheets, aquire all the > hardware to test, generate tables of irregularities, query Promise, and > then scratch your head why.
OK, Uncle! I detect a lot of pain here and perhaps I'm exacerbating it by asking. The technical side of me just wants to understand. I write code for a living and have had my share of pain with crappy hardware (though nothing even close to the scale at which you are working). I hate I2C, by the way, and don't ever ask me about the P.O.S. Philips pcf8584.
> > I have a FastTrak 100 TX4 the BIOS fails to see beyond 128GB, but in > practice it does. > > The PDC20267 will puke in 48-bit DMA, but run clean in 48-bit PIO :-/ > Oh but that is the primary channel, Seconday Channel is clean both ways :-\
Oh goodie. This can't be by design, but rather by stupid implementation. But I'll stop now before aggravating your ulcer :-)
> > PDC20262 works in 48-bit DMA every where. > > PDC20265 similar to PDC20267 except yours.
But I'd still like to understand why my PDC20265 seems unique. Earlier hardware rev? Later hardware rev? Promise BIOS issue? The Asus A7V-266E motherboard was purchased December 2001. If it's any help, I'm staring at the chip on the board now. The label shows:
PROMISE (R) TECHNOLOGY INC. PDC20265R (C) 2000-0113
Maybe there is another cleaner way to go at this problem.
> > Rules are emperical tests and rants back at the OEM, and .... >
Sounds to me like you need a vacation ;-)
> > > > But this wasn't a problem in 2.4.19-ac4; what confounding factor now is > > making it difficult? > > Cause there were reports of PDC20265/PDC20267 comming in as deadlocking. > Thanks for the wrinkle in the fabric of ruleless world. :-) >
You're welcome :-)
-Mike
| Mike Isely | PGP fingerprint POSITIVELY NO | | 03 54 43 4D 75 E5 CC 92 UNSOLICITED JUNK MAIL! | isely @ pobox (dot) com | 71 16 01 E2 B5 F5 C1 E8 | (spam-foiling address) |
- 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/
|  |