DMA Nightlmare on SuSE 10.x Revisited
Unlike on SuSE 10.0 where I could at least manually force SuSE to set DMA for my DVD ROM and the DVD burner, on SuSE 10.1 even this avenue of irriatation has been taken away from me :-( . I now cannot set the DMA for either unit at all - period! I have a LG GDR8164B, using UDMA 2, as the DVD/CD reader and a PIONEER 110 as the burner - both no more than 6 months or so old. The are installed as /dev/hdb and /dev/hdd, respectively (hda and hdb are Maxtor HDs). Doing /sbin/hdparm for both produces the following reault and error: hdb hdd IO_support = 1 (32-bit) IO_support = 1 (32-bit) unmasking = 1 (on) unmasking = 1 (on) using_dma = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readonly = 0 (off) readahead = 1024 (on) readahead = 1024 (on) HDIO_GETGEO failed: Inappropriate ioctl for device [Same error <-- here] In /etc/sysconfig/ide I have the FORCE DMA for both these devices set - but this has no affect, the stetement is ignored. Going to Yast Control Centre and setting the DMA for these devices produces the error message(s): QUOTE Cannot set required mode '%1 for device %2' UNQUOTE In SuSE 10.0 at least I didn't get this error message(s) and I was able to force the DMA before using the DVD reader but now, in 10.1, I cannot. Does SuSE/Novell have an explanation for this and a solution? Cheers. -- All answers questioned here.
El Jueves, 25 de Mayo de 2006 08:08, Basil Chupin escribió: | Unlike on SuSE 10.0 where I could at least manually force SuSE to set | DMA for my DVD ROM and the DVD burner, on SuSE 10.1 even this avenue of | irriatation has been taken away from me :-( . I now cannot set the DMA | for either unit at all - period! [---- SNIP ----] | Cannot set required mode '%1 for device %2' | | UNQUOTE | | In SuSE 10.0 at least I didn't get this error message(s) and I was able | to force the DMA before using the DVD reader but now, in 10.1, I cannot. | | Does SuSE/Novell have an explanation for this and a solution? Same problem here with Pioneer DVR-108. Regards. Ventura
Basil Chupin wrote:
I have a LG GDR8164B, using UDMA 2, as the DVD/CD reader and a PIONEER 110 as the burner - both no more than 6 months or so old. The are installed as /dev/hdb and /dev/hdd, respectively (hda and hdb are Maxtor HDs).
Doing /sbin/hdparm for both produces the following reault and error:
hdb hdd
IO_support = 1 (32-bit) IO_support = 1 (32-bit) unmasking = 1 (on) unmasking = 1 (on) using_dma = 0 (off) using_dma = 0 (off) keepsettings = 0 (off) keepsettings = 0 (off) readonly = 0 (off) readonly = 0 (off) readahead = 1024 (on) readahead = 1024 (on) HDIO_GETGEO failed: Inappropriate ioctl for device [Same error <-- here]
Which version of hdparm do you have? It looks like it's trying to get the drive geometry for your CD drives, which is indeed "Inappropriate" ... I'm using hdparm-6.3-9, but my workstation isn't quite 10.1 - probably one of the betas or an RC.
In SuSE 10.0 at least I didn't get this error message(s) and I was able to force the DMA before using the DVD reader but now, in 10.1, I cannot. Does SuSE/Novell have an explanation for this and a solution?
Did you check bugzilla and/or report the problem? (ok, I checked bugzilla and didn't see much hdparm related). I would just report the problem if I were you. /Per Jessen, Zürich
Per Jessen wrote:
Which version of hdparm do you have? It looks like it's trying to get the drive geometry for your CD drives, which is indeed "Inappropriate" ...
I'm using hdparm-6.3-9, but my workstation isn't quite 10.1 - probably one of the betas or an RC.
OK, I've moved up to 6.3-11 which is 10.1GM. Doing hdparm /dev/hdc (my CD-burner), I also see the HDIO_GETGEO error. But "hdparm -dx /dev/hdc" works fine. Do you get any errors from "hdparm -dx /dev/hdx" ? /Per Jessen, Zürich
Per Jessen wrote:
Per Jessen wrote:
Which version of hdparm do you have? It looks like it's trying to get the drive geometry for your CD drives, which is indeed "Inappropriate" ...
I'm using hdparm-6.3-9, but my workstation isn't quite 10.1 - probably one of the betas or an RC.
OK, I've moved up to 6.3-11 which is 10.1GM.
Doing hdparm /dev/hdc (my CD-burner), I also see the HDIO_GETGEO error. But "hdparm -dx /dev/hdc" works fine.
Do you get any errors from "hdparm -dx /dev/hdx" ?
I am using the hdparm which comes with 10.1: 6.3-11 Doing hdparm -dx /dev/hdx does not produce the error but it also does not give me the same results- I only get- using_dma = 0 (off) busstate = 1 (1) and that's all. Cheers. -- All answers questioned here.
Basil Chupin wrote:
I am using the hdparm which comes with 10.1: 6.3-11
I suspect you can ignore the error with HDIO_GETGEO - it is odd for hdparm to try lok up the geometry of a CDROM-drive, but it doesn't really cause a problem, does it?
Doing hdparm -dx /dev/hdx does not produce the error but it also does not give me the same results- I only get-
using_dma = 0 (off) busstate = 1 (1)
and that's all.
I would not expect the same results as for the display command, just the change in the DMA setting. What happens when you do the following: hdparm -d0 /dev/hdx hdparm /dev/hdx hdparm -d1 /dev/hdx hdparm /dev/hdx If DMA is not enabled now, something isn't working. Which I believe is what you reported initially? /Per Jessen, Zürich
Per Jessen wrote:
Basil Chupin wrote:
I am using the hdparm which comes with 10.1: 6.3-11
I suspect you can ignore the error with HDIO_GETGEO - it is odd for hdparm to try lok up the geometry of a CDROM-drive, but it doesn't really cause a problem, does it?
Doing hdparm -dx /dev/hdx does not produce the error but it also does not give me the same results- I only get-
using_dma = 0 (off) busstate = 1 (1)
and that's all.
I would not expect the same results as for the display command, just the change in the DMA setting.
What happens when you do the following:
hdparm -d0 /dev/hdx
I get: setting using_dma to 0 (off)
hdparm /dev/hdx
the same blurb with the HDIO_GETGEO failed error I mentioned in my original post.
hdparm -d1 /dev/hdx
setting using_dma to 1 (on) using_dma = 1 (on)
hdparm /dev/hdx
IO_support = 1 (32-bit) unmasking = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 1024 (on) HDIO_GETGEO failed: Inappropriate ioctl for device
If DMA is not enabled now, something isn't working. Which I believe is what you reported initially?
The DMA is now set by looking in Control Centre (which, BTW is spelt a Control CENTER even though I have selected British English to use and NOT <shudder> that unknown pretend-language, 'US English'). BUT, I also just noticed that even though the DMA is now set for all the devices (hda, hdb, hdc and hdd) there is still one anomaly in what is shown in Control Centre/Hardware/DMA. Devices hda and hdc are identical Maxtor drives, from the same batch as far as I am concerned, only separated by small number of digits in the serial numbers. However, Control Centre reports that hda has Ultra set to 100 and hdd is set to 133! So I now have: hda UDMA100 (WRONG) hdb DMA33 (Correct) hdc UDMA133 (Correct) hdd DMA66 (Correct) Cheers. -- All answers questioned here.
Basil Chupin wrote:
hdparm /dev/hdx
IO_support = 1 (32-bit) unmasking = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 1024 (on) HDIO_GETGEO failed: Inappropriate ioctl for device
So DMA is now enabled for that drive. That means hdparm is doing what's supposed to. If the setting does not survive a reboot, your BIOS is resetting it. But you also said FORCE_DMA is not working - which is probably worth reporting as hdparm is ok.
BUT, I also just noticed that even though the DMA is now set for all the devices (hda, hdb, hdc and hdd) there is still one anomaly in what is shown in Control Centre/Hardware/DMA.
Devices hda and hdc are identical Maxtor drives, from the same batch as far as I am concerned, only separated by small number of digits in the serial numbers. However, Control Centre reports that hda has Ultra set to 100 and hdd is set to 133! So I now have:
hda UDMA100 (WRONG) hdb DMA33 (Correct) hdc UDMA133 (Correct) hdd DMA66 (Correct)
I don't use the YaST control centre much - but maybe it just displays the current setting - what are you comparing to when you say UDMA100 for hda is wrong? What does "hdparm -i /dev/hdx" say? /Per
Per Jessen wrote:
Basil Chupin wrote:
hdparm /dev/hdx IO_support = 1 (32-bit) unmasking = 1 (on) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 1024 (on) HDIO_GETGEO failed: Inappropriate ioctl for device
So DMA is now enabled for that drive. That means hdparm is doing what's supposed to. If the setting does not survive a reboot, your BIOS is resetting it. But you also said FORCE_DMA is not working - which is probably worth reporting as hdparm is ok.
The setting survives reboots so it is now OK. The FORCE_DMA didn't work as per my original post and since receiving the advice from you, Silviu and Carlos, and fiddling with different settings, I have found that doing anything in /etc/sysconfig/ide does NOT work. The only way to get the DMAs set correctly here is to use Silviu's solution of putting the statement into /etc/init.d/boot.local. See my response to Carlos.
BUT, I also just noticed that even though the DMA is now set for all the devices (hda, hdb, hdc and hdd) there is still one anomaly in what is shown in Control Centre/Hardware/DMA.
Devices hda and hdc are identical Maxtor drives, from the same batch as far as I am concerned, only separated by small number of digits in the serial numbers. However, Control Centre reports that hda has Ultra set to 100 and hdd is set to 133! So I now have:
hda UDMA100 (WRONG) hdb DMA33 (Correct) hdc UDMA133 (Correct) hdd DMA66 (Correct)
I don't use the YaST control centre much - but maybe it just displays the current setting - what are you comparing to when you say UDMA100 for hda is wrong? What does "hdparm -i /dev/hdx" say?
This gives same results for most parameters EXCEPT for DMA modes and UDMA modes where for hda I get- mda0 mda1 mda2 udma0 udma1 udma2 but for hdd these go all the way to dma6 and udma6. However, even this is weird because in Control Centre/Harware/IDE DMA mode hda is showing as UltraDMA/100 but this should only read UltraDMA/33 because the hdparm is showing udma2 as its top possible setting :-) . (SuSE is weird :-) .) What am I comparing the results to? Firstly, both HDs are identical. Secondly, in Widnows the dma is set to same value for both HDs (ie, udma6 = udma/133). Cheers. -- Ignorance can be corrected. Stupidity is permanent.
Basil Chupin wrote:
supposed to. If the setting does not survive a reboot, your BIOS is resetting it. But you also said FORCE_DMA is not working - which is probably worth reporting as hdparm is ok.
The setting survives reboots so it is now OK.
The FORCE_DMA didn't work as per my original post and since receiving the advice from you, Silviu and Carlos, and fiddling with different settings, I have found that doing anything in /etc/sysconfig/ide does NOT work.
/etc/sysconfig/ide will set the variable DEVICES_FORCE_IDE_DMA, which in 10.0 was used by the boot.idedma init-script. This functionality has been moved to a udev script. It seems to have happened in 10.1, probably as a result of https://bugzilla.novell.com/show_bug.cgi?id=117683
What am I comparing the results to? Firstly, both HDs are identical.
Yes, but that is a matter of specifications, not current settings. Of course, if YaST shows a drive set to an unsupported DMA-mode, something isn't quite right :-) /Per Jessen, Zürich
Per Jessen wrote:
Basil Chupin wrote:
supposed to. If the setting does not survive a reboot, your BIOS is resetting it. But you also said FORCE_DMA is not working - which is probably worth reporting as hdparm is ok. The setting survives reboots so it is now OK.
The FORCE_DMA didn't work as per my original post and since receiving the advice from you, Silviu and Carlos, and fiddling with different settings, I have found that doing anything in /etc/sysconfig/ide does NOT work.
/etc/sysconfig/ide will set the variable DEVICES_FORCE_IDE_DMA, which in 10.0 was used by the boot.idedma init-script. This functionality has been moved to a udev script.
It seems to have happened in 10.1, probably as a result of https://bugzilla.novell.com/show_bug.cgi?id=117683
I've looked at that bugzilla listing. Methinks that it wasn't done correctly - a on-the-run fix which did not produce the right result for the majority of people, only for those which have a CD ROM which is /dev/hdg :-( .
What am I comparing the results to? Firstly, both HDs are identical.
Yes, but that is a matter of specifications, not current settings. Of course, if YaST shows a drive set to an unsupported DMA-mode, something isn't quite right :-)
I now have a bit more knowldge about hdparm and now know that there are 2 options for it which happen to produce 2 different results. These options are -i and -I. I used on all the 4 devices I have (just to review: hda=Maxtor 250GB; hdb=CD ROM; hdc=Maxtor 250GB; hdd=Pioneer 110) and ran hdparm -i and then hdparm -I on all 4 devices. I won't bother with giving results for hdb and hdd but for hda and hdc are shown below because as I said they are identical HDs but are treated differently by SuSE. hdarm -i hdparm -I hda mdma0 to mdma2 mdma0 to mdma2 udma0 to udma2 udma0 to udma6 (5 set) <============= hdc mdma0 to mdam2 mdma0 to mdma2 udma0 to udma6 (6 set) <===== udma0 to udma6 (6 set) <============ Whatever all this means I don't know, but something is not kosher somewhere especially when Windows recognises everything correctly :-) . Cheers. -- Ignorance can be corrected. Stupidity is permanent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 01:01 +1000, Basil Chupin wrote:
hdparm /dev/hdx
the same blurb with the HDIO_GETGEO failed error I mentioned in my original post.
Just ignore that line. It is been produced for cdrom drives for years; look at my 9.3: /dev/hdc: IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Invalid argument It correspond to the geometry of the device. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEd0jstTMYHG2NR9URAhrSAJ9qztTGlN7hnVNSfJXA8Zo6wB1wwgCglMue oaDcr3NR4hBkO3GPv3GdlDA= =8LkQ -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Saturday 2006-05-27 at 01:01 +1000, Basil Chupin wrote:
hdparm /dev/hdx the same blurb with the HDIO_GETGEO failed error I mentioned in my original post.
Just ignore that line. It is been produced for cdrom drives for years; look at my 9.3:
/dev/hdc: IO_support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) readonly = 0 (off) readahead = 256 (on) HDIO_GETGEO failed: Invalid argument
It correspond to the geometry of the device.
Ignored :-) . Didn't like the way it looked at me anyway. Thanks for the info. Cheers. -- Ignorance can be corrected. Stupidity is permanent.
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error:
Does this work? hdparm -d1c1U1 /dev/hdb If it works, you can put it in /etc/init.d/boot.local Not quite proper, but it does the job and you don't have to worry anymore.
On Thursday 25 May 2006 03:28, Silviu Marin-Caea wrote:
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error:
Does this work?
hdparm -d1c1U1 /dev/hdb
If it works, you can put it in /etc/init.d/boot.local
Not quite proper, but it does the job and you don't have to worry anymore. ==========
No need to mess with boot.local, just go in /etc/sysconfig/ide and edit that to force dma on the devices you wish to maintain that way. Also YaST2 gives you another place to turn on or off DMA on supported devices. Those would be the preferred spots. regards, Lee
BandiPat wrote:
On Thursday 25 May 2006 03:28, Silviu Marin-Caea wrote:
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error: Does this work?
hdparm -d1c1U1 /dev/hdb
If it works, you can put it in /etc/init.d/boot.local
Not quite proper, but it does the job and you don't have to worry anymore. ==========
No need to mess with boot.local, just go in /etc/sysconfig/ide and edit that to force dma on the devices you wish to maintain that way. Also YaST2 gives you another place to turn on or off DMA on supported devices.
Those would be the preferred spots.
regards, Lee
You're obviously coming in late on the discussion and haven't read what I wrote in the original message. I had already tried/done all of the above you mention - and they don't work :-(. However doing (with a slight but absolutely crucial modification) what Silviu states has fixed the problem for me (?until the next time boot the computer :-)). Cheers. -- All answers questioned here.
Silviu Marin-Caea wrote:
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error:
Does this work?
hdparm -d1c1U1 /dev/hdb
I think that there is one whopping big typo in this statement. The '-d1c1U1' should be with the 'U' as a lower case letter (u). I did use the above with the capital U and my computer locked up and it took hitting the big red button to get it going. Also, I "lost" hdc and hdc from the list of devices in Control Centre/Hardware/DMA, and they were not displayed on the Desktop under My Computer. (Man hdparm comments on the 'U' parameter as being DANGEROUS and possibly causing damage to the hardware and to the system.) However, altering the parameter to '-d1c1u1' produced the right result and now I have DMA set on the DVD/CD reader. Thanks for that.
If it works, you can put it in /etc/init.d/boot.local
(This is where I put the above statement and, as I said, it works. For those who will try this to get their DMAs set, you have to reboot for the above parameters to work.)
Not quite proper, but it does the job and you don't have to worry anymore.
It works. Thanks. But there is a question: the above 'fix' is for /dev/hdb. How does one go about also doing it for /dev/hdd? Does one simply add another line in boot.local for hdd? ( I have to add here that this question is really theoretical because the fix above somehow also fixed the problem with hdd which now shows the correct UDMA and this I am assuming is being picked up from the entry I made in /etc/sysconfig/ide.) Again, thanks for the fix, but the question still remains as to why SuSE 10.1 cannot correctly handle the DMA on these 2 devices. I dual-boot with <shudder> Win and it has no problems in recognising and automatically setting the DMA on all the 4 IDE devises. Cheers. -- All answers questioned here.
On Thursday 25 May 2006 17:16, Basil Chupin wrote:
Silviu Marin-Caea wrote:
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error:
Does this work?
hdparm -d1c1U1 /dev/hdb
I think that there is one whopping big typo in this statement. The '-d1c1U1' should be with the 'U' as a lower case letter (u).
Sorry about that. A huge difference indeed. U unregisters the interface. As a general rule, don't just run stuff from a mailing list without reading documentation first. :-)
However, altering the parameter to '-d1c1u1' produced the right result and now I have DMA set on the DVD/CD reader. Thanks for that.
If it works, you can put it in /etc/init.d/boot.local
(This is where I put the above statement and, as I said, it works.
For those who will try this to get their DMAs set, you have to reboot for the above parameters to work.)
Not quite proper, but it does the job and you don't have to worry anymore.
The proper way would be to put in /etc/sysconfig/ide DEVICES_FORCE_IDE_DMA="/dev/hdb:on /dev/hdd:on" but if that doesn't work, the hdparm -c1d1u1 it's even better: enables 32 bit access and unmask irq.
But there is a question: the above 'fix' is for /dev/hdb. How does one go about also doing it for /dev/hdd? Does one simply add another line in boot.local for hdd?
Add an identical line for hdd.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Friday 2006-05-26 at 18:02 +0300, Silviu Marin-Caea wrote:
The proper way would be to put in /etc/sysconfig/ide DEVICES_FORCE_IDE_DMA="/dev/hdb:on /dev/hdd:on" but if that doesn't work, the hdparm -c1d1u1 it's even better: enables 32 bit access and unmask irq.
You can use then: DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:-d1-u1 /dev/hdd:-c1:-d1-u1" - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEd0hLtTMYHG2NR9URApn/AJ418YkIaB6P6IZvbssjQRQwKPVNvwCcCOrY s6hmH6e+iYN4X9j8FvSnpUI= =I21C -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Friday 2006-05-26 at 18:02 +0300, Silviu Marin-Caea wrote:
The proper way would be to put in /etc/sysconfig/ide DEVICES_FORCE_IDE_DMA="/dev/hdb:on /dev/hdd:on" but if that doesn't work, the hdparm -c1d1u1 it's even better: enables 32 bit access and unmask irq.
You can use then:
DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:-d1-u1 /dev/hdd:-c1:-d1-u1"
Sorry, but this does NOT work :-( . In fact, SuSE automatically reformats this statement into- .......="/dev/hdb:udma2" and even drops the reference to /dev/hdd. And after the reformat the DMA for hdb is still not set :-( . I thought for a moment that the additional " : " after the "-c1" were typos so left them out but while SuSE didn't reformat the statement (it left it as is) the DMAs were not set. In fact, the ONLY way I can get the DMAs set correctly is to use what Silviu suggested which is to put the statement into /etc/init.d/boot.local. Once put there the DMAs are set correctly (UltraDMA/33 for hdb and UltraDMA/66 for hdd). (SuSE is weird :-) .) Cheers. -- Ignorance can be corrected. Stupidity is permanent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Saturday 2006-05-27 at 13:25 +1000, Basil Chupin wrote:
You can use then:
DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:-d1-u1 /dev/hdd:-c1:-d1-u1"
Sorry, but this does NOT work :-( .
It certainly does in 9.3: I've been using it for months. I was told about it here, somebody using 10.0. My line is: DEVICES_FORCE_IDE_DMA="/dev/hda:-c1:-m16:-u1 /dev/hdb:-c1:-m16:-u1 /dev/hdd:-c1:-m16:-u1 /dev/hdc:on"
In fact, SuSE automatically reformats this statement into-
.......="/dev/hdb:udma2"
Use a text editor to directly edit the file. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEeCA3tTMYHG2NR9URAmrsAJ9UIX+576s7iemMVNRjjgR13jpnowCeO7eQ Qeg3CqSKuX5+k/zwAoS1/Y8= =jyAA -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Saturday 2006-05-27 at 13:25 +1000, Basil Chupin wrote:
You can use then:
DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:-d1-u1 /dev/hdd:-c1:-d1-u1" Sorry, but this does NOT work :-( .
It certainly does in 9.3: I've been using it for months. I was told about it here, somebody using 10.0. My line is:
DEVICES_FORCE_IDE_DMA="/dev/hda:-c1:-m16:-u1 /dev/hdb:-c1:-m16:-u1 /dev/hdd:-c1:-m16:-u1 /dev/hdc:on"
Yeah, but we are talking here about v10.1 which is an animal of a different kind... OK, this is what I tried and the results. Firstly, the comment that the params you show above are not the same as you gave in an earlier response so I'll ignore the above and use what you gave before EXCEPT that you shown above an additional set of " : " after the '-m16' parameter and these " : " were not shown in the earlier response - so, I did a test using both "methods": with and without the extra " : ". A. To begin, I cleared /etc/init.d/boot.local. Then I did 2 separate tests by putting into /etc/sysconfig/ide these: DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:d1u1 /dev/hdd:-c1:d1u1" DEVICES_FORCE_IDE_DMA="/dev/hdb:-c1:-d1:-u1 /dev/hdd:-c1:-d1:u1" and then rebooted after making each entry in ../../ide. On both occasions the above statements in /ide were ALTERED to read: ..._DMA="" In Control Centre (from now referred to simply as CC) /dev/hdb was NOT set to a DMA of any kind but /dev/hdd was correctly set (to Udma/66). Trying to alter in CC the dma for hdb produced the error message "Cannot set required mode '%1 for device %2' ". Doing hdparm -I /dev/hdx showed that hdb had a setting of udma2 and hdd had udma4. Now, rebooting the system at this point(s) resulted in this change in /ide file: .._DMA="/dev/hdb:udma2" but CC still showed that hdb had no dma set, but hdd was set to udma/66 and hdparm -I still showed the same results as just mentioned. B. I then used the approach which Silviu provided which was to use /etc/init.d/boot.local. I first altered /etc/sysconfig/ide to read .._DMA="" and then inserted in /boot.local hdparm -d1c1u1 /dev/hdb hdparm -d1c1u1 /dev/hdd and rebooted the system. Now CC is showing correctly that the hdb is set to udma/33 and hdd is set to udma/66 (with hdparm -I still showing that both devices have their udma set). This information is now static after each reboot. The statement in ../ide remains unaltered with DMA="".
In fact, SuSE automatically reformats this statement into-
.......="/dev/hdb:udma2"
Use a text editor to directly edit the file.
Doesn't appear that using anything will stop from something in SuSE amending ../ide to whatever it is "programmed" to do (against your will in fact). All these things above I found after much time in typing/rebooting/typing/rebooting/typing/ad finitum :-) . I'll never be same... Cheers. -- Ignorance can be corrected. Stupidity is permanent.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Monday 2006-05-29 at 00:35 +1000, Basil Chupin wrote:
DEVICES_FORCE_IDE_DMA="/dev/hda:-c1:-m16:-u1 /dev/hdb:-c1:-m16:-u1 /dev/hdd:-c1:-m16:-u1 /dev/hdc:on"
Yeah, but we are talking here about v10.1 which is an animal of a different kind...
True.
OK, this is what I tried and the results.
Firstly, the comment that the params you show above are not the same as you gave in an earlier response so I'll ignore the above and use what you gave
Well, my first one I created for you, taking my real line and leaving only the parameters I thought you needed. Posibly I misstyped something. The second one is the one that I'm actually using.
On both occasions the above statements in /ide were ALTERED to read:
..._DMA=""
Oh, my! :-(
I then used the approach which Silviu provided which was to use /etc/init.d/boot.local.
Yes, that one must work. Time ago, I created my own "/etc/init.d/boot.localhw" service script instead. I'm not using it now, but I might use it again when I install 10.1. Basicly, I run hdparm.
Use a text editor to directly edit the file.
Doesn't appear that using anything will stop from something in SuSE amending ../ide to whatever it is "programmed" to do (against your will in fact).
It must be something in hald/devfs/subfs/whatever.
All these things above I found after much time in typing/rebooting/typing/rebooting/typing/ad finitum :-) . I'll never be same...
You sure have saved a lot of time for many of us ;-) - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEefAhtTMYHG2NR9URAo2JAJwI3F3TyWtm4TONRifjAUnBVHgQwgCbBxxQ u4pITTFipT4u6kKHq51pLvY= =mAQ9 -----END PGP SIGNATURE-----
Carlos E. R. wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
The Monday 2006-05-29 at 00:35 +1000, Basil Chupin wrote:
DEVICES_FORCE_IDE_DMA="/dev/hda:-c1:-m16:-u1 /dev/hdb:-c1:-m16:-u1 /dev/hdd:-c1:-m16:-u1 /dev/hdc:on" Yeah, but we are talking here about v10.1 which is an animal of a different kind...
True.
OK, this is what I tried and the results.
Firstly, the comment that the params you show above are not the same as you gave in an earlier response so I'll ignore the above and use what you gave
Well, my first one I created for you, taking my real line and leaving only the parameters I thought you needed. Posibly I misstyped something. The second one is the one that I'm actually using.
On both occasions the above statements in /ide were ALTERED to read:
..._DMA=""
Oh, my! :-(
I then used the approach which Silviu provided which was to use /etc/init.d/boot.local.
Yes, that one must work. Time ago, I created my own "/etc/init.d/boot.localhw" service script instead. I'm not using it now, but I might use it again when I install 10.1. Basicly, I run hdparm.
Use a text editor to directly edit the file. Doesn't appear that using anything will stop from something in SuSE amending ../ide to whatever it is "programmed" to do (against your will in fact).
It must be something in hald/devfs/subfs/whatever.
All these things above I found after much time in typing/rebooting/typing/rebooting/typing/ad finitum :-) . I'll never be same...
You sure have saved a lot of time for many of us ;-)
A bit off the mark I am afraid, sorry :-( . I just spent the last 3 days re-installing and re-installing and re-installing 10.1 trying to get that *STUPID* new (or even the old!) software updater to work. It stuffed my system each time so I had to re-install. (And PLEASE, Andreas, don't ask me to put in a bug report 'cause I don't remember all the things I had to do and not do and what worked up to a point - which point? - and what didn't.) Anyway, I am now in a situation where I have got the system running again but without all that crap updating thingie so thta I can at least get back online and "talk" to people. Which now leads me to the comment I just made above.... The setting of DMA now does NOT work. Period. No matter what I do - either what Silviu said or what you said (re using /etc/sysconfig/ide - just doesn't work. It did after the first install of 10.1 and when I wrote the comments earlier in this thread but now, when I went to view a DVD earlier today, I discovered that nothing that I do in putting parameters in control files sets the DMA for the one device that needs the setting to be able to view DVDs correctly - namely, HDB. The ONLY way to have DMA set and working correctly is to to use hdparm on a command line (as root) and only then will the DMA be set and show up as being set in Control Centre/Harware/IDE DMA Mode. The wackiest thing about all this is that even if using 'hdparm -I /dev/hdb' shows that the DMA *is* set (to udma2 in my cse) but unless the DMA is shown as being set in CC/Harware/DAM Mode then the device behaves as a device without DMA. ONLY when CC/Hardware/IDE DMA Mode shows that the DMA is set *then* the device works correctly with DMA set. I have a DVD which starts with a man walking slowly and the camera pans slowly as he is walking and I use this to test whether the DMA is working or not: if the panning/walking is jerky then I know that the DMA is not set. During the re-installation of 10.1 over the past 3 days something did get updated during the first call to the "home base" server so something now has been corrupted, and DMA for hdb cannot be set using /etc/sysconfig/ide or /etc/init.d/boot.local. Command line use of hdparm is only way I can do it - just like I had to do in 10.0. So, we are making progress..... backwards. Cheers. -- Ignorance can be corrected. Stupidity is permanent. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Basil Chupin wrote:
I just spent the last 3 days re-installing and re-installing and re-installing 10.1 trying to get that *STUPID* new (or even the old!) software updater to work. It stuffed my system each time so I had to re-install.
I've just this morning installed 10.1 on yet another system - no problems. I guess I didn't touch the software updater ....
The setting of DMA now does NOT work. Period. No matter what I do - either what Silviu said or what you said (re using /etc/sysconfig/ide - just doesn't work. It did after the first install of 10.1 and when I wrote the comments earlier in this thread but now, when I went to view a DVD earlier today, I discovered that nothing that I do in putting parameters in control files sets the DMA for the one device that needs the setting to be able to view DVDs correctly - namely, HDB.
That sounds worthy of a bugreport. The boot.idedma script was replaced by a different mechanism in 10.1, so maybe something was missed.
The wackiest thing about all this is that even if using 'hdparm -I /dev/hdb' shows that the DMA *is* set (to udma2 in my cse) but unless the DMA is shown as being set in CC/Harware/DAM Mode then the device behaves as a device without DMA.
I haven't checked, but I think it's relatively safe to assume that CC/Hardware/DMA uses 'hdparm' under the covers. Are you saying that what "hdparm -I" says does not match what you see in CC/Hardware/DMA ? /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 The Thursday 2006-06-08 at 17:41 +0200, Per Jessen wrote:
That sounds worthy of a bugreport. The boot.idedma script was replaced by a different mechanism in 10.1, so maybe something was missed.
Aparently by /etc/udev/rules.d/56-idedma.rules: # start idedma script for each added IDE device KERNEL=="hd*[!0-9]", ACTION=="add", RUN+="/lib/udev/idedma.sh /dev/%k" Looking at that script (/lib/udev/idedma.sh), it reads DEVICES_FORCE_IDE_DMA, and should accept a syntax like: # The setting e.g. "/dev/hda:69:-c1:-m16:-u1:-W1:-A1" should be # expanded as "hdparm -d 1 -X 69 -c1 -m16 -u1 -W1 -A1 /dev/hda" Ie, each device is separated by a space, and for each device the options are separated by commas. It would be possible to run that script by hand and check its workings. I can't, because I don't have 10.1 installed yet, I'll have to wait till next month, perhaps. - -- Cheers, Carlos Robinson -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.0 (GNU/Linux) Comment: Made with pgp4pine 1.76 iD8DBQFEiYVmtTMYHG2NR9URAlTSAJ0UIBe7lBIWkX0qQOYXgaIzm6g2ugCff+rm 0q+qnO6WzZzD6O2P7xEY14M= =U76l -----END PGP SIGNATURE----- -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Per Jessen wrote:
Basil Chupin wrote:
I just spent the last 3 days re-installing and re-installing and re-installing 10.1 trying to get that *STUPID* new (or even the old!) software updater to work. It stuffed my system each time so I had to re-install.
I've just this morning installed 10.1 on yet another system - no problems. I guess I didn't touch the software updater ....
The setting of DMA now does NOT work. Period. No matter what I do - either what Silviu said or what you said (re using /etc/sysconfig/ide - just doesn't work. It did after the first install of 10.1 and when I wrote the comments earlier in this thread but now, when I went to view a DVD earlier today, I discovered that nothing that I do in putting parameters in control files sets the DMA for the one device that needs the setting to be able to view DVDs correctly - namely, HDB.
That sounds worthy of a bugreport. The boot.idedma script was replaced by a different mechanism in 10.1, so maybe something was missed.
The wackiest thing about all this is that even if using 'hdparm -I /dev/hdb' shows that the DMA *is* set (to udma2 in my cse) but unless the DMA is shown as being set in CC/Harware/DAM Mode then the device behaves as a device without DMA.
I haven't checked, but I think it's relatively safe to assume that CC/Hardware/DMA uses 'hdparm' under the covers. Are you saying that what "hdparm -I" says does not match what you see in CC/Hardware/DMA ?
Yes. Please see my earlier reply to Carlos where I give a detailed list of the results I got when doing some tests. If you can't find that msg I can FWD a copy to you. Cheers. -- Indecision is the key to flexibility. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Basil Chupin wrote:
The setting of DMA now does NOT work. Period.
https://bugzilla.novell.com/show_bug.cgi?id=177959 https://bugzilla.novell.com/show_bug.cgi?id=182885 /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Per Jessen wrote:
Basil Chupin wrote:
The setting of DMA now does NOT work. Period.
https://bugzilla.novell.com/show_bug.cgi?id=177959 https://bugzilla.novell.com/show_bug.cgi?id=182885
Thanks for these links. I've read them now but putting thru the suggested fix (ie the symlink) does not solve the problem- the DMA for /dev/hdb still remains OFF. Only way to get it set is to use hdparm -d1c1u1 /dev/hdb as root from a command line. Cheers. Indecision is the key to flexibility. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Basil Chupin wrote:
Per Jessen wrote:
Basil Chupin wrote:
The setting of DMA now does NOT work. Period.
https://bugzilla.novell.com/show_bug.cgi?id=177959 https://bugzilla.novell.com/show_bug.cgi?id=182885
Thanks for these links. I've read them now but putting thru the suggested fix (ie the symlink) does not solve the problem- the DMA for /dev/hdb still remains OFF. Only way to get it set is to use hdparm -d1c1u1 /dev/hdb as root from a command line.
Just on the off chance that it's some use, I had one disk refusing to set DMA when booting after I installed 10.1. It turns out DMA had been switched off for /dev/hdb in the system BIOS. After hitting DEL on a reboot and changing the detect DMA setting to auto, everything worked fine. -- JDL -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
John D Lamb wrote:
Basil Chupin wrote:
Per Jessen wrote:
Basil Chupin wrote:
The setting of DMA now does NOT work. Period. https://bugzilla.novell.com/show_bug.cgi?id=177959 https://bugzilla.novell.com/show_bug.cgi?id=182885 Thanks for these links. I've read them now but putting thru the suggested fix (ie the symlink) does not solve the problem- the DMA for /dev/hdb still remains OFF. Only way to get it set is to use hdparm -d1c1u1 /dev/hdb as root from a command line.
Just on the off chance that it's some use, I had one disk refusing to set DMA when booting after I installed 10.1. It turns out DMA had been switched off for /dev/hdb in the system BIOS. After hitting DEL on a reboot and changing the detect DMA setting to auto, everything worked fine.
Thanks for this John. I'll check this out at the next boot. The problem with this is that Windows recognises all the devices correctly. When I do 'hdparm -I /dev/hdx' all the 4 devices have the correct udma set - except that hda is set to udma5 when it should be the same as for hdc - udma6 - because both are identical HDs. When one looks at Control Centre/Hardware/IDE DMA Mode, udma is shown as set for hda, hdc and hdd but not for hdb and unless the udma is shown as set here then the device operates with no udma. That is, SuSE depends on what is shown in CC/Hdware/IDE DMA for the dma to be applied to the device. And the only way I can get the dma/udma set for hdb is to use 'hdparm -d1c1u1 /dev/hdb' from a command line. There is a bug report about dma not working correctly on a device hdg I think which Per pointed me at but doing the 'fix' suggested there doesn't do anything. Only the command line approach works (for me). Cheers. -- Indecision is the key to flexibility. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Basil Chupin wrote:
There is a bug report about dma not working correctly on a device hdg I think which Per pointed me at but doing the 'fix' suggested there doesn't do anything. Only the command line approach works (for me).
It's probably worth updating the bugreport with a quick note about this. /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Per Jessen wrote:
Basil Chupin wrote:
There is a bug report about dma not working correctly on a device hdg I think which Per pointed me at but doing the 'fix' suggested there doesn't do anything. Only the command line approach works (for me).
It's probably worth updating the bugreport with a quick note about this.
/Per Jessen, Zürich
I'm still trying out a few "variations on a theme" to see what may or may not work. I am getting different results after reboots and I don't know what is affecting what. Sometimes I get hdb recognised and the next time it is not. Buggered if I know what keeps changing. What I need to do is to open a new clean page in my notebook and start (again!) taking notes :-( . When I have finished then I'll decide if I am in the mood to spend more time in writing up a bug report - which may or may not be acted on for years for all I know (how long has the current bug report been in the pipeline?). Cheers. -- Indecision is the key to flexibility. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Basil Chupin wrote:
What I need to do is to open a new clean page in my notebook and start (again!) taking notes :-( .
Yeah, that is critical for tracking down something like this.
When I have finished then I'll decide if I am in the mood to spend more time in writing up a bug report - which may or may not be acted on for years for all I know
One important thing to realise about bugzilla and reporting - it is not a support system. Which means it's a two-way thing - usually reports get acted on very quickly, especially when the proper information is provided etc. /Per Jessen, Zürich -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Per Jessen wrote:
Basil Chupin wrote:
What I need to do is to open a new clean page in my notebook and start (again!) taking notes :-( .
Yeah, that is critical for tracking down something like this.
When I have finished then I'll decide if I am in the mood to spend more time in writing up a bug report - which may or may not be acted on for years for all I know
One important thing to realise about bugzilla and reporting - it is not a support system. Which means it's a two-way thing - usually reports get acted on very quickly, especially when the proper information is provided etc.
OK, after several reboots it seems that I finally "cracked" this problematic nut and I now am getting the correct reading in Control Centre/Hardware/IDE DMA Mode showing that DMA is correctly set for all my 4 IDE devices. The way to achieve this seems to be to have DMA forced to be set for ALL devices and not just the devices which show up as not being set in CC/HW/IDM. For example, in my case CC/HW/IDM was showing this: hda set hdb not set hdc set hdd set and it was getting hdb set which was the subject of the discussion in this thread for sometime now. Up this point in time, /etc/sysconfig/ide had this: DEVICES_FORCE_IDE_DMA="/dev/hdb:udma2" and this didn't work. Doing what Silviu suggested - putting 'hdparm -d1c1u1 /dev/hdb' in /etc/init.d/boot.local - also didn't work although on the first reboot after doing so it appeared that it was working. What I did (as a "stab in the dark" I must add) is alter /etc/sysconfig/ide to read: DEVICES_FORCE_IDE_DMA="/dev/hda:udma5 /dev/hdb:udma2 /dev/hdc:udma5 /dev/hdd:udma4" and now the DMA is correctly set for hdb. Just trying to force the DMA for hdb on its own did nothing but forcing it for all 4 devices did the trick (although I suspect that forcing it for both devices on the same IDE channel/cable [0] would also have done the trick but I am not going to start playing around with this idea as I've spent enough time on this hassle already. It now works and "If it ain't broke, don't fix it".) Cheers. -- Indecision is the key to flexibility. -- Check the headers for your unsubscription address For additional commands send e-mail to suse-linux-e-help@suse.com Also check the archives at http://lists.suse.com Please read the FAQs: suse-linux-e-faq@suse.com
Silviu Marin-Caea wrote:
On Thursday 25 May 2006 17:16, Basil Chupin wrote:
Silviu Marin-Caea wrote:
On Thursday 25 May 2006 09:08, Basil Chupin wrote:
Doing /sbin/hdparm for both produces the following reault and error: Does this work?
hdparm -d1c1U1 /dev/hdb I think that there is one whopping big typo in this statement. The '-d1c1U1' should be with the 'U' as a lower case letter (u).
Sorry about that. A huge difference indeed. U unregisters the interface.
As a general rule, don't just run stuff from a mailing list without reading documentation first. :-)
So I am finding out :-) .
However, altering the parameter to '-d1c1u1' produced the right result and now I have DMA set on the DVD/CD reader. Thanks for that.
If it works, you can put it in /etc/init.d/boot.local (This is where I put the above statement and, as I said, it works.
For those who will try this to get their DMAs set, you have to reboot for the above parameters to work.)
Not quite proper, but it does the job and you don't have to worry anymore.
The proper way would be to put in /etc/sysconfig/ide DEVICES_FORCE_IDE_DMA="/dev/hdb:on /dev/hdd:on" but if that doesn't work, the hdparm -c1d1u1 it's even better: enables 32 bit access and unmask irq.
Well, using /etc/sysconfig/ide does NOT work - see my repsonse to Carlos. Only way it works is to use the /etc/init.d/boot.local way.
But there is a question: the above 'fix' is for /dev/hdb. How does one go about also doing it for /dev/hdd? Does one simply add another line in boot.local for hdd?
Add an identical line for hdd.
Thanks for this. I have now did just that in boot.local. Cheers. -- Ignorance can be corrected. Stupidity is permanent.
participants (7)
-
BandiPat -
Basil Chupin -
Carlos E. R. -
John D Lamb -
Per Jessen -
Silviu Marin-Caea -
Ventura Valderrábano Ornedo