Sean Johnson wrote: > > I get the same exact results with my PPro system (Intel 440FX chipset) and > Maxtor 7.2GB UDMA drive. This even happens under the developmental kernel > 2.1.122 which I use for the better SMP handling. I've asked questions > before on newsgroups and such as to what could be causing this behavior, or > if anybody else had even seen this kind of behavior, but never got any > response. I'm using 2.34 and have not recieved a problem yet. My machine is a Cyrix 200MMX with a VIA VP3 chipset and a Maxtor 4.3 Gig UDMA33. I don't have the UDMA feature of the kernel in use, I use the standard IDE driver. Maybe this is a hardware problem, a result of too low of bandwidth (since Win probably never tries to use the full bandwidth capacity of these drives)?
Mark Panzer > > Sean > > > > >MORE INFO > > > >WHat I mean to say is that if you install a DMA/33 drive that claimes to > >be compatable with IDE, I get a ton of errors that look like this: > > > >hd<whatever>: multwrite_intr: status=0x51 { DriveReady SeekComplete Error } > >hd<whatever>: multwrite_intr: error=0x04 { DriveStatusError } > >hd<whatever>: status timeout: status=0xd0 { Busy } > >hd<whatever>: no DRQ after issuing WRITE > >ide1: reset: success > > > >I get MANY fewer with 2.0.32. In fact, I get many per minute with > >2.0.3(3-5) yet only a few per day with 2.0.32. This is with plain vanilla > >hdparm settings (i.e. the defaults) > > > >Also, with 2.0.35 I kept getting errors for illegal blocks, accesses > >beyond the end of the device, fsck failures due to illegal blocks in > >inodes requiring manual repair, etc. None of these problems with 2.0.32. > >I first noticed this earlier this year when I installed an 8G drive on a > >2.0.33 box. I could not keep the bux running more than a day until I > >reverted to 2.0.32 and put the large disk as the slave on the primary IDE. > > > >These are two different brands of motherboards with two different chipsets > >that show the same results. > > > > -- > Unsubscribe? mail -s unsubscribe [EMAIL PROTECTED] < /dev/null