Hi Basil, Sorry for the late reply. On Tuesday 10 May 2011 01:58:00 pm Basil Chupin wrote:
On 10/05/11 19:07, Jean Delvare wrote:
On Tuesday 10 May 2011 08:28:57 am Basil Chupin wrote:
I am running 32-bit openSUSE 11.4 (have both KDE and Gnome installed on separate sets of HDs); installed as fresh installations. The kernel used is the one installed by 11.4.
I am using both ATA controllers each with same model HDs and same model DVDRWs sitting on 80-wire cables and set for Cable Select.
Before I do a "fiddle" - see below - the HDs and the DVDRWs on both channels are set during boot to UDMA 33 because the kernel decides that I am using a 40-wire cable on each controller.
And you are certain you aren't?
Having been using 80-wire cables for some 7 years now on all computers I can safely state that, YES, I am positively certain - and this includes replacing both cables with new ones so as not to leave any doubt about the state of the cables.
OK, good.
I found a reference going back to 2008 that this is a known problem in the kernel and that adding "libata.force=X:80c" to the kernel parameters in menu.lst works around this annoyance.
Please be specific. If it was always safe to pass this parameter then it would be the default.
I don't understand.
Of course it is "safe to pass this parameter" because not only I had done so but hundreds of other people have also done so -- because we HAVE to do it in order to get the UDMA configured correctly.
Putting in "libata.force=1:80c" gives me the correct UDMAs for what is on controller #1 but what is on #2 is set to UDMA 33.
So I put in "libata.force=1,2:80c" 'cause I read that one uses a comma as a separator in such "libata" statement but this don't work and only the second controller is configured correctly :-( . (...) Could someone please tell me what the correct words to use to get both all the devices configured with the correct UDMA?
Did you try: libata.force=1:80c,2:80c ?
Of course not otherwise I wouldn't be asking my question about what the correct words to use, would I?
No need to be aggressive. I had no idea if that would work, I never needed these parameters and did not go read the documentation either before suggesting it. Simply, it is what _I_ would have tried next. And I'm glad it worked.
But many thanks for the above because having now the correct format for the words to type in menu.lst the UDMA for both controllers is now set correctly (to UDMA 133/100 on both channels for both devices on each cable). Thanks again.
You're welcome.
Perhaps there is another way of doing this other than what was provided way back 3 years ago? (Such a bug in the kernel still around after 3 years?)
How can we comment on this when you did not provide any pointer to your findings?
Sorry, I don't understand?
What "pointers to [my] findings" are you looking for?
Oh, you think that I came up with my claims in my dreams.
No, I don't. I think (and, in fact, I am eve certain) that you did not provide enough technical details about your system, and what it as in common with the similar stories you found on the web.
Well, why not do a search on google using the search words, "limited to UDMA/33 due to 40-wire cable". You should get some ~11,500 hits, and in at least 2 of them is where I found the "fix" of using 'libata.force=X:80c" (including one which gave a patch for the kernel to get this annoyance fixed) - and this goes back to 2008.
I'm not the one doing the google search, because _you_ are the one asking for help. So you are the one who should be summarizing your findings, and giving enough details for us to help you. In this specific case, what you should have told us was: what your hardware (IDE controller) is, and what your system has in common with the many similar reports you found by googling. I guess that the common point is the IDE controller chip, but to properly help you, it's better to start with facts rather than guesses. And maybe there are other factors, such as the hard disk drives you're using, or some kernel configuration option, or the brand of the motherboard. You claim that there is a bug in the kernel for over 3 years. You can't expect it to get fixed if people affected by it just pass the proper module parameter and don't make proper bug reports. My guess if that what you have is faulty hardware, and the kernel can't work around this, and that's why the "bug" was never fixed - because it's not a kernel bug. But again, this is just a guess, by lack of technical details. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org