[opensuse-kernel] PATA devices being configured with wrong UDMA
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. 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. 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 :-( . Here is an extract from boot.msg showing this: 1.482242] ata1: PATA max UDMA/133 cmd 0x1f0 ctl 0x3f6 bmdma 0xf000 irq 14 1.482246] ata2: PATA max UDMA/133 cmd 0x170 ctl 0x376 bmdma 0xf008 irq 15 1.617516] usb 2-1: New USB device found, idVendor=03f0, idProduct=bb02 1.617520] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 1.617523] usb 2-1: Product: Photosmart 8400 series 1.617525] usb 2-1: Manufacturer: HP 1.617527] usb 2-1: SerialNumber: CN52N211850469 1.620813] scsi2 : usb-storage 2-1:1.2 1.688318] ata1.00: HPA unlocked: 490232639 -> 490234752, native 490234752 1.688324] ata1.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133 <===========XXXXXXXXXXXXXX 1.688328] ata1.00: 490234752 sectors, multi 16: LBA48 1.688335] ata1.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100 <======XXXXXXXXXXXXXX 1.688344] ata1: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f) 1.688347] ata1.00: limited to UDMA/33 due to 40-wire cable 1.688352] ata1: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000 (0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f) 1.688355] ata1.01: limited to UDMA/33 due to 40-wire cable 1.695812] ata1.00: configured for UDMA/33 <==============XXXXXXXXXXXXXX 1.717242] ata1.01: configured for UDMA/33 <==============XXXXXXXXXXXXXX 1.717784] scsi 0:0:0:0: Direct-Access ATA Maxtor 6L250R0 BAH4 PQ: 0 ANSI: 5 1.721008] sd 0:0:0:0: [sda] 490234752 512-byte logical blocks: (251 GB/233 GiB) 1.721070] scsi 0:0:1:0: CD-ROM PIONEER DVD-RW DVR-118L 1.02 PQ: 0 ANSI: 5 1.721335] sd 0:0:0:0: [sda] Write Protect is off 1.721339] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 1.721368] sd 0:0:0:0: [sda] Write cache: disabled, read cache: enabled, doesn't support DPO or FUA 1.808862] sda: sda1 sda2 < sda5 sda6 sda7 sda8 sda9 sda10 > 1.809367] sd 0:0:0:0: [sda] Attached SCSI disk 1.878316] ata2: FORCE: cable set to 80c <=============ZZZZZZZZZZZZZZZZZZZ 1.879907] ata2.00: ATA-7: Maxtor 6L250R0, BAH41G10, max UDMA/133 <===ZZZZZZZZZZZZZZZZZZZ 1.879910] ata2.00: 490234752 sectors, multi 16: LBA48 1.879917] ata2.01: ATAPI: PIONEER DVD-RW DVR-118L, 1.02, max UDMA/100 <==ZZZZZZZZZZZZZZZZ 1.879925] ata2: nv_mode_filter: 0x7f39f&0x7f39f->0x7f39f, BIOS=0x7f000 (0xc7c6c7c6) ACPI=0x7f01f (15:20:0x1f) 1.879930] ata2: nv_mode_filter: 0x3f39f&0x3f39f->0x3f39f, BIOS=0x3f000 (0xc7c6c7c6) ACPI=0x3f01f (15:20:0x1f) 1.881012] usb 2-2: new low speed USB device using ohci_hcd and address 3 1.887783] ata2.00: configured for UDMA/133 <===========ZZZZZZZZZZZZZZZ 1.909241] ata2.01: configured for UDMA/100 <===========ZZZZZZZZZZZZZZZ Could someone please tell me what the correct words to use to get both all the devices configured with the correct UDMA? 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?) BTW, HDPARM for /dev/sda and sdb supports the results shown above in boot.msg BC -- "The older the violin the sweeter the music." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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?
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.
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 ?
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? -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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.
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? 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.
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. 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. BC -- "The older the violin the sweeter the music." -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
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
On 14/05/11 19:35, Jean Delvare wrote:
Hi Basil,
Sorry for the late reply.
And, in my turn, I am sorry for MY delayed reply. (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 .)
On Tuesday 10 May 2011 01:58:00 pm Basil Chupin wrote:
[pruned]
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.
Didn't mean to sound 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.
Sorry to ask: but aren't you somehow connected with the kernel development?
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.
And I thank you again for providing me with the correct format for this command line 'instruction' to the kernel.
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.
I see no requirement to provide any "technical details" about my system because what my system is all about I have already described, and it matters not a pinch of horse manure as to what it is because it has been identified that the kernel has a problem and this problem has not been resolved since some 3 years ago. What "my system" has or not in common "with similar stories [I] found on the web" has absolutely nothing to do with the price of fish. It doesn't matter which Linux distro I install on my system, or my wife's, I get the same message showing that the UDMA has been incorrectly set because of this "40-wire cable" BS identification by the kernel. You ask me why I didn't notice this before, right? Simple answer is that I never bothered to look before, and accepted that Linux was "the ants pants" when it comes to being "with it". I now know different - and to make this knowledge worse is that contrary to what the "geek" people claim that it takes M$ months or longer to get right is takes Linux KERNEL people YEARS to get resolved. Rather sad I would think.
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.
<Sigh> I am not going to get into a pointless discussion with you about the above. You are giving the typical "support desk" response for which you have been trained to give. Read my original post, read your response, read my response (above), do a search on the search parameter(s) I already gave you, read what is contained in those search results. Then after you have done so, then come back and tell me that "...what you have is faulty hardware". (I have counted to 20 so far.....am holding on to my temper....and so I shall now finish this post :-) .) 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
On Sat, 21 May 2011 00:36:01 +1000
Basil Chupin
I see no requirement to provide any "technical details" about my system because what my system is all about I have already described, and it matters not a pinch of horse manure as to what it is because it has been identified that the kernel has a problem and this problem has not been resolved since some 3 years ago.
What "my system" has or not in common "with similar stories [I] found on the web" has absolutely nothing to do with the price of fish.
Yes it has something to do with it. Because it is not like it is broken on all the systems out there. It is something about your system. Probably the specific IDE chip your system is using. Either the chip, the board design or the driver has an issue. It might simply be the chip not being able to detect an 80 pin cable and the kernel thus defaulting to a safe value. It might be the board design, that disallows the chip, even though it would be able to detect an 80 pin cable if hooked up correctly, to detect the cable. It might be the driver, simply not having implemented the function to detect the cable. Believe me: I still have ~8 machines with IDE drives. All of them run with UDMA >=66 and none of them needs such a kernel parameter.
pants" when it comes to being "with it". I now know different - and to make this knowledge worse is that contrary to what the "geek" people claim that it takes M$ months or longer to get right is takes Linux KERNEL people YEARS to get resolved. Rather sad I would think.
That's unrelated. For a Microsoft OS you probably have to install the "Vendor drivers" from your motherboard vendor anyway, and they have probably just hardwired that value. At least they could have solved it that way. Would be interesting if a plain Windows installation with stock drivers does work as well.
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.
100% agree with Jean
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.
<Sigh>
I am not going to get into a pointless discussion with you about the above.
It's not pointless. It's like taking your car to a mechanic and telling him "it does not drive nicely". When he asks in which way it does "not drive nicely", you tell "search for other stories of not nicely driving cars on google". Not helpful.
Read my original post, read your response, read my response (above), do a search on the search parameter(s) I already gave you, read what is contained in those search results.
If 3 People on 3 places on the world place the same search terms into google, they will get three different sets of results. This is only one of the problems with your approach.
(I have counted to 20 so far.....am holding on to my temper....and so I shall now finish this post :-) .)
Wow, if this is how you write a polite post, I don't want to see an impolite one. Just for the record: I found your mails to be pretty impolite and normally I probably would have just mumbled "What an a..." to myself and have hit Shift-Delete. -- 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
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 :(
On 14/05/11 19:35, Jean Delvare wrote:
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.
Sorry to ask: but aren't you somehow connected with the kernel development?
I am. But that doesn't mean I am fully familiar with each of the 13174877 lines of code the sources of the openSUSE 11.4 kernel are made of. In particular, storage is not my area.
(...) 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.
I see no requirement to provide any "technical details" about my system because what my system is all about I have already described, and it matters not a pinch of horse manure as to what it is because it has been identified that the kernel has a problem and this problem has not been resolved since some 3 years ago.
It is actually very needed.
What "my system" has or not in common "with similar stories [I] found on the web" has absolutely nothing to do with the price of fish.
It is actually totally relevant, and I shall prove it. I've just booted and connected to 2 of the 4 machines I own that still have an IDE or PATA drive in them (the other two have no power at the moment, otherwise I would have checked them too.) I've looked at the kernel logs for both of them. Here's what I found: [First system, laptop with Intel ICH3 controller] hda: ST96812A, ATA DISK drive hda: host max PIO4 wanted PIO255(auto-tune) selected PIO4 hda: UDMA/100 mode selected [Second system, desktop board with Intel ICH5 controller] ata2.00: ATAPI: PLEXTOR CD-ROM PX-54TA, 1.00, max UDMA/33 ata1.00: ATA-7: Maxtor 6Y080L0, YAR41BW0, max UDMA/133 ata2.00: configured for UDMA/33 ata1.00: configured for UDMA/100 As you can see, both of them get UDMA/100 working, and I did not have to pass any kernel parameter for this. So, all my systems work, all yours fail. Either you are cursed, or your systems have something in common which mine don't.
It doesn't matter which Linux distro I install on my system, or my
Not surprising as they are all based on the same upstream kernel project. OTOH, if you acknowledge that the problem is not specific to openSUSE, then why are you reporting it on an opensuse list rather than to upstream kernel developers?
wife's, I get the same message showing that the UDMA has been incorrectly set because of this "40-wire cable" BS identification by the kernel.
Again, I presume your system and your wife's system have something in common which causes the problem.
You ask me why I didn't notice this before, right?
No, I don't.
Simple answer is that I never bothered to look before, and accepted that Linux was "the ants pants" when it comes to being "with it". I now know different - and to make this knowledge worse is that contrary to what the "geek" people claim that it takes M$ months or longer to get right is takes Linux KERNEL people YEARS to get resolved. Rather sad I would think.
Maybe this has to do with the fact that M$ engineers don't spend time answering user questions for free? ;) 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'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.
<Sigh>
I am not going to get into a pointless discussion with you about the above.
Actually you have just done that :p
You are giving the typical "support desk" response for which you have been trained to give.
I have not even been trained. I actually do support for a living, but not as a support desk agent. I _do_ a lot of user support on open-source projects though, for free. But thankfully, most of the time users trust my expertise and provide the information I ask for.
Read my original post, read your response, read my response (above), do a search on the search parameter(s) I already gave you, read what is
Again (as you either did not read or did not understand): you are the one asking for help, you are the one doing the homework. When you get help from professionals for free, you have to make things as easy as possible for them.
contained in those search results. Then after you have done so, then come back and tell me that "...what you have is faulty hardware".
This would indeed be my preliminary and unreliable conclusion, based on the very succinct information you provided. -- Jean Delvare Suse L3 -- To unsubscribe, e-mail: opensuse-kernel+unsubscribe@opensuse.org For additional commands, e-mail: opensuse-kernel+help@opensuse.org
participants (3)
-
Basil Chupin -
Jean Delvare -
Stefan Seyfried