Re: FYI: DMA/33 and kernels
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 debian-user-request@lists.debian.org < /dev/null
Reply to: