Fwd: Re: [opensuse-kernel] PATA devices being configured with wrong UDMA
![](https://seccdn.libravatar.org/avatar/b150acea6b2203078d2a9d30bedeee91.jpg?s=120&d=mm&r=g)
-------- Original Message -------- Subject: Re: [opensuse-kernel] PATA devices being configured with wrong UDMA Date: Mon, 23 May 2011 17:47:48 +1000 From: Basil Chupin <blchupin@iinet.net.au> To: opensuse-kernel@opensuse.org On 21/05/11 01:35, Jean Delvare wrote:
Hi Basil,
Le vendredi 20 mai 2011 16:36, Basil Chupin a écrit :
(Won't go into reasons, but it has to do with openSUSE and audio and pulseaudio and getting different results when installing the same copy of 11.4/KDE on the same system.......but let's not get into this one right now, OK? :-D .) Don't tell me about sound and pulseaudio :(
I won't ever again, I promise (until the next time) :-) .
More seriously, comparisons like this are very difficult to establish, and are often biased by personal experience.
Out of curiosity, did you try a different operating system on the same hardware, to see if it was doing any better with UDMA speed detection?
I had no intention of this going into some sort of a bun-fight over what seems to be a simple matter - and I still have no intention of this going into such a state. I asked a simple question which was about what was the correct format to use in the "libata.force" statement to get both PATA channels working with an 80-wire cable; to show why I was asking the question I gave an extract from the boot.msg log file as well as making the comment that this hassle with the kernel incorrectly deciding that the machine was using a 40-wire cable has been known since at least 2008. I received from you the answer as to what was the correct format to use for this over-riding kernel parameter. Wonderful! But then the (unintended) "fight" started :-D . To save space and time what I deliberately omitted from my original post was that I had the following configuration a couple of weeks before I posted my question: PATA #1 : WD HD with UDMA 133 LG CDROM with UDMA 33 PATA #2: Seagate with UDMA 100 Pioneer DVD-RW UDMA 100 and the kernel was giving me the correct UDMA settings for PATA #1 (UDMA 133/33) [NOTE: 133/33] *without* any "libata fix" but I had to use "libata.force=2:80c" to get the correct UDMA set for PATA #2. This was all fine until I had to replace the LG CDROM (UDMA 33) with the new Pioneer DVD-RW which has UDMA 100. (And this one is for Stefan: NOTE that the UDMA was set correctly on PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working fine, right?) When I did replace the LG CDROM on PATA #1 with a new Pioneer DVD-RW - so that I now had the Maxtor UDMA 133 with the DVD-RW UDMA 100 - the kernel decided that I had a 40-wire cable connected on PATA #1 and made both devices UDMA 33. PATA #2 was still correctly set (to 100/100) by the entry of "libata.force=2:80c".) This is when I posted my message of help for the correct format of the wording to get BOTH channels set to the correct UDMA by the kernel. Now, 2 things are associated with this: (1) how did I learn that the kernel required the fiddle of "libata.force=..."? because I searched the net and found many references to this problem but the one which gave me the most acceptable solution (others where to recompile the kernel after setting the appropriate parameter already existing in the kernel, and applying a patch to the kernel) was the one I found here: http://viktorbalogh.net/blog/other/libata-workaround-limited-to-udma33-due-t... ; (2) why did I ask my question here and not in some "kernel upstream" list? I did so because there is a self-appointed "mail list cop" who inhabits opensuse help mail list and told me off for asking the question about KDE in the opensuse help list but which have been asked in the KDE mail list - which meant that "as good little soldier" I should ask my question about the kernel in *this* mail list to avoid the wrath of that "list cop" :-) . And, secondly, I don't know any "upstream kernel" list nor did I think that I needed to do so just to have a simple question about the correct wording format to use to get the "fix" working. My real problem was in adding my comments about this kernel problem being known for at least 3 years and for which I shall now go and put on my hair-shirt, kneel on a bed of hot ashes and flagellate myself for......oh, I don't know - perhaps several nano seconds or so? :-) . Lastly, you asked if I had this hassle on other distros. The answer is YES - and at least one uses a more up-to-date version of the kernel (eg, Ubuntu). In all cases the only "libata fix" I had to use was to set PATA #2 to be correct, because I still had the LG CDROM on PATA #1 and the UDMA for devices on PATA #1 were being set correctly. However, since getting the new RW on #1 I have not used the other distros so cannot say what the results would be if I did. (I wouldn't be having this drawn out discussion to justify my results/question if I hadn't had to replace the LG CDROM on PATA #1 with the Pioneer DVD-RW :'( . But life wouldn't be so interesting without such little PITAs, would it? :-D ) BC -- "The time has been That, when the brains were out, the man would die," "Macbeth", Shakespeare -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/44913c011f93e7be71fcdd4764bbeac9.jpg?s=120&d=mm&r=g)
On 05/25/2011 08:19 AM, Basil Chupin wrote:
-------- Original Message -------- Subject: Re: [opensuse-kernel] PATA devices being configured with wrong UDMA Date: Mon, 23 May 2011 17:47:48 +1000 From: Basil Chupin <blchupin@iinet.net.au> To: opensuse-kernel@opensuse.org
On 21/05/11 01:35, Jean Delvare wrote:
Hi Basil,
Le vendredi 20 mai 2011 16:36, Basil Chupin a écrit :
(Won't go into reasons, but it has to do with openSUSE and audio and pulseaudio and getting different results when installing the same copy of 11.4/KDE on the same system.......but let's not get into this one right now, OK? :-D .) Don't tell me about sound and pulseaudio :(
I won't ever again, I promise (until the next time) :-) .
More seriously, comparisons like this are very difficult to establish, and are often biased by personal experience.
Out of curiosity, did you try a different operating system on the same hardware, to see if it was doing any better with UDMA speed detection?
I had no intention of this going into some sort of a bun-fight over what seems to be a simple matter - and I still have no intention of this going into such a state.
I asked a simple question which was about what was the correct format to use in the "libata.force" statement to get both PATA channels working with an 80-wire cable; to show why I was asking the question I gave an extract from the boot.msg log file as well as making the comment that this hassle with the kernel incorrectly deciding that the machine was using a 40-wire cable has been known since at least 2008.
I received from you the answer as to what was the correct format to use for this over-riding kernel parameter. Wonderful! But then the (unintended) "fight" started :-D .
To save space and time what I deliberately omitted from my original post was that I had the following configuration a couple of weeks before I posted my question:
PATA #1 : WD HD with UDMA 133 LG CDROM with UDMA 33
PATA #2: Seagate with UDMA 100 Pioneer DVD-RW UDMA 100
and the kernel was giving me the correct UDMA settings for PATA #1 (UDMA 133/33) [NOTE: 133/33] *without* any "libata fix" but I had to use "libata.force=2:80c" to get the correct UDMA set for PATA #2.
This was all fine until I had to replace the LG CDROM (UDMA 33) with the new Pioneer DVD-RW which has UDMA 100.
(And this one is for Stefan: NOTE that the UDMA was set correctly on PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working fine, right?)
When I did replace the LG CDROM on PATA #1 with a new Pioneer DVD-RW - so that I now had the Maxtor UDMA 133 with the DVD-RW UDMA 100 - the kernel decided that I had a 40-wire cable connected on PATA #1 and made both devices UDMA 33.
PATA #2 was still correctly set (to 100/100) by the entry of "libata.force=2:80c".)
This is when I posted my message of help for the correct format of the wording to get BOTH channels set to the correct UDMA by the kernel.
I would advise getting in touch with Tejun Heo <tj@kernel.org>. He probably knows more about ATA/IDE intrinsics than anybody else cares to. And he'll be most qualified to fix this issue, seeing that this is an upstream defect, too. Cheers, Hannes -- Dr. Hannes Reinecke zSeries & Storage hare@suse.de +49 911 74053 688 SUSE LINUX Products GmbH, Maxfeldstr. 5, 90409 Nürnberg GF: J. Hawn, J. Guild, F. Imendörffer, HRB 16746 (AG Nürnberg) -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/ed90d0132a4f59f2d3a1cf82a1b70915.jpg?s=120&d=mm&r=g)
Am Wed, 25 May 2011 16:19:28 +1000 schrieb Basil Chupin <blchupin@iinet.net.au>:
(And this one is for Stefan: NOTE that the UDMA was set correctly on PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working fine, right?)
This actually hints even more at a flaky / broken (maybe by design) chip, which reports more or less random results depending on the drive configuration. But AFAICT we still don't even know which chipset we are talking about... -- Stefan Seyfried "Dispatch war rocket Ajax to bring back his body!" -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
![](https://seccdn.libravatar.org/avatar/dcaea5e8a6fad867936a40a9c21e8ff3.jpg?s=120&d=mm&r=g)
On Wednesday 25 May 2011 08:19:28 am Basil Chupin wrote:
I received from you the answer as to what was the correct format to use for this over-riding kernel parameter. Wonderful! But then the (unintended) "fight" started :-D .
If it really wasn't intended, then at least it was very awkward. Claiming that a known kernel bug has been left unfixed for 3 years isn't the best way to avoid replies.
To save space and time what I deliberately omitted from my original post was that I had the following configuration a couple of weeks before I posted my question:
PATA #1 : WD HD with UDMA 133 LG CDROM with UDMA 33
PATA #2: Seagate with UDMA 100 Pioneer DVD-RW UDMA 100
and the kernel was giving me the correct UDMA settings for PATA #1 (UDMA 133/33) [NOTE: 133/33] *without* any "libata fix" but I had to use "libata.force=2:80c" to get the correct UDMA set for PATA #2.
This was all fine until I had to replace the LG CDROM (UDMA 33) with the new Pioneer DVD-RW which has UDMA 100.
(And this one is for Stefan: NOTE that the UDMA was set correctly on PATA #1 *without* any "libata" fiddles for #1 - so, the chip is working fine, right?)
When I did replace the LG CDROM on PATA #1 with a new Pioneer DVD-RW - so that I now had the Maxtor UDMA 133 with the DVD-RW UDMA 100 - the kernel decided that I had a 40-wire cable connected on PATA #1 and made both devices UDMA 33.
PATA #2 was still correctly set (to 100/100) by the entry of "libata.force=2:80c".)
This is when I posted my message of help for the correct format of the wording to get BOTH channels set to the correct UDMA by the kernel.
The above contains very interesting technical details, the kind that is needed to actually fix bugs. The only thing missing is the PATA controller vendor and model (PCI IDs.) My summary of the above would be: everything is fine without the Pioneer DVD-RW, but as soon as you connect one such drive, the PATA controller is suddenly unable to detect the cable. So I would diagnose an incompatibility between the PATA controller and the Pioneer DVD-RW. Whether this is a hardware issue or a driver bug, I can't tell. As you said your wife had the same problem, is her system also using a similar Pioneer DVD-RW?
Now, 2 things are associated with this:
(1) how did I learn that the kernel required the fiddle of "libata.force=..."? because I searched the net and found many references to this problem but the one which gave me the most acceptable solution (others where to recompile the kernel after setting the appropriate parameter already existing in the kernel, and applying a patch to the kernel) was the one I found here:
http://viktorbalogh.net/blog/other/libata-workaround-limited-to-udma3 3-due-to-40-wire-cable ;
In this report the person is using driver ata_piix. Is it also your case? And your wife's system as well? It is easiest to get a kernel bug fixed if you are able to figure out the exact set of conditions it takes to reproduce. This will let you find who is responsible for the driver in question, and then give that maintainer a chance to reproduce the problem. Problem reproduction is half way to problem fixing.
(...) Lastly, you asked if I had this hassle on other distros.
This was not my actual question. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (4)
-
Basil Chupin
-
Hannes Reinecke
-
Jean Delvare
-
Stefan Seyfried