Fw: UDMA on 815e chipset

Fw: UDMA on 815e chipset

[quintaq]

Greetings Gurus,

Have I found a tiny, perhaps irrelevant, bug ?

I have recently installed SuSE 7.0 with the supplied 2.2.16 kernel on my
homebuilt dual-boot machine, which has an 815e chipset (Asus CuSL2 board), plus
30GB IBM Deskstar 75GXP HDD (hda).  As I understand it both of these support UDMA modes4 and 5 / ATA 66 and 100.

The bios will not allow UDMA mode 5 to be set unless the correct cable is
detected.  At boot-time under Windows the bios reports that UDMA Mode 5
has been set.

I decided to tweak the HDD performance under linux.  I began with ATA 33 by adding the following to my boot.local : /sbin/hdparm -c1 -m16 -d1 -X66 /dev/hda

This line causes no problems and hparm reports UDMA mode 2 set with cache reads at 139.13 MB/sec and disk reads at 12.87 MB/sec.

I then try increasing to ATA 66 by substituting -X68 for X66.

At linux boot-time I now see that XF68 has been set, but then I see the error
message : "ide0: speed warning UDMA /3/4/5 is not functional".  As I understand it, this means that the kernel has tested for the correct cable, but sees a negative response.

Even though I see the error message, I think that UDMA 4 / ATA 66 must actually have been set, because hdparm now reports cache reads at 143.82 MB/sec and disk reads at 15.76 MB/Ssec. hdparm also reports that the HDD is in UDMA mode 4.

Much the same thing happens if I try for ATA 100 / UDMA 5 by substituting -X69.  hdparm now reports that the drive is in UDMA mode 5, but I do not see any improvement in transfer speeds, from which I assume that my kernel cannot go higher than ATA 66.

I assume (unwisely ?), from all this that for some reason the kernel's
check for the correct UDMA cabling on this chipset / motherboard is
failing, but that it is actually succeding in setting UDMA mode 5 and is happily running at ATA 66. Hence my "possibly irrelevant" bug report.

I have carried out all of the tests I mention above with a substitute cable, but the results are the same. I have not (yet) suffered any loss of data or other problems by ignoring the speed warning.

I am not subscribed to this list (perhaps I have revealed enough ignorance
above to explain why not), but I do not know where else I should report
the "problem", or where else I might get some feedback.  If anyone can be
bothered to respond, then I would be very grateful if you could CC the reply
to me.

Thanks

Geoff

"Scattered we were when the long night was breaking:
But in bright morning converse again"

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fw: UDMA on 815e chipset

[Mike Dresser]

> Even though I see the error message, I think that UDMA 4 / ATA 66 must actually have been set, because hdparm now reports cache reads at 143.82 MB/sec and disk reads at 15.76 MB/Ssec. hdparm also reports that the HDD is in UDMA mode 4.

This seems low, I have a pair of IBM DJNA-352030 20 gig's in a machine at home, that cache reads at 86.49(celeron 300@450, probably a slower machine than yours, would account for the lower numbers), disk reads score at 14.78, in Ultra/33 mode.(my mb
doesn't support ultra/66).
 It's been so long since i bought the hard drives, that i can't remember if they're 5400 rpm or 7200.  Either way, it's doing better than that controller is running your 7200 rpm 30'er.

> Much the same thing happens if I try for ATA 100 / UDMA 5 by substituting -X69.  hdparm now reports that the drive is in UDMA mode 5, but I do not see any improvement in transfer speeds, from which I assume that my kernel cannot go higher than ATA 66.

Don't forget that no IDE drive out there, at this time, can saturate even Ultra/66.  Unless you've got the newest and greatest, even Ultra/33 is wide enough for a single drive, unless you take into account the fact the cache can dump that whole
512k/2048k/whathaveyou at double the speed.
Granted, once you get two drives on the channel, Ultra/66 and 100 start making a difference, if they can share the channel efficiently.

Mike


-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/

Re: Fw: UDMA on 815e chipset

[quintaq]

Mike / Mark,

Thank-you very much for your replies.

With regard to Mike, (a) I am using a PIII 800, so I really should be seeing better results than your Celeron.  It seems, therefore, that my setup may be defective in more fundamental ways than I had imagined.  (b) I do appreciate that I may not see any real benefit from Ultra/66 at this stage - I was just keen to experiment and see that the hardware was working.

In reply to Mark : (a) my HDD was certainly sold as UDMA 5 capable, and hdparm reports that it is.  (b) I do not think you meant to suggest that I would solve the problem by deleting the -c and -m switches, but I deleted them anyway and the problem remains. (c) I wish I knew why the hell SuSE would include an obsolete kernel in their relatively new, flagship, v7 "Professional".  So far as I can see, kernel 2.4 is not even an option on their ftp site.  I use this machine for my business and cannot afford a major crash precipitated by a piece of inept kernel-tinkering on my part.

I do have a spare machine (bx board though),and I suppose that the way ahead is to play around installing the current kernel on that until I have the confidence to put it in this box.

One final thought.  When I installed the OS I was offered the option to "use DMA", which I accepted. I see this set at an early stage in the boot-process (long before my boot.local executes).  Is there any way this could be obstructing the subsequent instruction to use UDMA ?

Thanks again,

Geoff

_________________________________________________________
Do You Yahoo!?
Get your free @yahoo.com address at http://mail.yahoo.com

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
Please read the FAQ at http://www.tux.org/lkml/