Re: hdparm for lib_pata
>>> = Stephen Clark >> = Adam Richter > = Patrick Ale >> Do you know if these drives were advertising less capability >> than they were spec-ed at? Do you recall if the IDE driver without >> kernel arguments printed its rationale for reverting to the slower >> setting? [...] >Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started >seeing things like: >"Drive not ready" >"DMA timeout on ..." I was not asking about Patrick's desktop computer, which was already established to be hardware problem that was fixed by replacing a broken fan. I was asking about Stephen Clark's two laptop computers, which seemed like they might be examples of a need for user level hdparm DMA setting, which is why I prefaced my question with the following quotation: >>On 2007-02-04 Stephen Clark wrote: >>>I have had two different laptops that had to have boot time command line >>>overrides to get the >>>driver to allow the hardware work at what it was spec-ed at. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I can only speak for myself of course. On boot time the libsata driver detected my harddisks were capable of UDMA100, and used it. Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started seeing things like: "Drive not ready" "DMA timeout on ..." After this, I saw a bus reset, the master disk (the one with problems) reverted to UDMA/44 and the slave (no problems appearantly staid (stayed?) at UDMA100. Then, after literaly some minutes, same messages, "Drive not ready" , "DMA timeout". And it went to an even lower UDMA mode, till the point it was out of UDMA modes, switched to PIO, and when it dropped to the lowest PIO mode, it just said how it couldnt go any lower I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Please note: I DID have problems, major ones, So yes, libsata does fall back to slower transfer modes, but as far of my experience concerned, not without a reason which should be addressed. Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2007-02-04 Stephen Clark wrote: >I have had two different laptops that had to have boot time command line >overrides to get the >driver to allow the hardware work at what it was spec-ed at. Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Adam Richter - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2007-02-04 Stephen Clark wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? I can only speak for myself of course. On boot time the libsata driver detected my harddisks were capable of UDMA100, and used it. Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started seeing things like: Drive not ready DMA timeout on ... After this, I saw a bus reset, the master disk (the one with problems) reverted to UDMA/44 and the slave (no problems appearantly staid (stayed?) at UDMA100. Then, after literaly some minutes, same messages, Drive not ready , DMA timeout. And it went to an even lower UDMA mode, till the point it was out of UDMA modes, switched to PIO, and when it dropped to the lowest PIO mode, it just said how it couldnt go any lower I ask because I'd like to know if this sort of thing can ever happen with libata. If so, then that is yet another reason to have the ability to override DMA settings from user level in libata. Please note: I DID have problems, major ones, So yes, libsata does fall back to slower transfer modes, but as far of my experience concerned, not without a reason which should be addressed. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
= Stephen Clark = Adam Richter = Patrick Ale Do you know if these drives were advertising less capability than they were spec-ed at? Do you recall if the IDE driver without kernel arguments printed its rationale for reverting to the slower setting? [...] Then, after 2 hours, and resyncing RAID1 MD 1 devices, I started seeing things like: Drive not ready DMA timeout on ... I was not asking about Patrick's desktop computer, which was already established to be hardware problem that was fixed by replacing a broken fan. I was asking about Stephen Clark's two laptop computers, which seemed like they might be examples of a need for user level hdparm DMA setting, which is why I prefaced my question with the following quotation: On 2007-02-04 Stephen Clark wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Adam Richter - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Bill Davidsen wrote: Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a "serious driver problem," which is why it should be under user control. Point is, if the DMA's not working such that the system decides to turn it off, it's obviously having some issues, and thus turning it back on without fixing the problem could cause problems or even cause data corruption. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Bill Davidsen wrote: I think deciding to turn off DMA which works fine in old kernels qualifies as a "serious driver problem," which is why it should be under user control. For PATA, perhaps. For SATA, turning off DMA can often -cause- additional problems. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
re: hdparm -d Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a "serious driver problem," which is why it should be under user control. Fair enough. The original reason for that functionality in the drivers/ide stuff, was that I wanted a way to be able to continue to test the IDE driver in PIO mode, despite all of my own devices having good DMA support. If there's no way to force the driver to use a particular transfer method, then it becomes difficult to (re)test the driver over time. Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: Stephen Clark wrote: Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a "serious driver problem," which is why it should be under user control. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Mark Lord wrote: Robert Hancock wrote: .. Only some of the hdparm functionality is supported in libata, That's not true. MOST hdparm functionality is supported in libata. Only a very few things are not supported, including -d and -X, for reasons already pointed out. Nearly everything else works. Agreed, I've already had problems typing faster than I think, twice, as as I hit ENTER saying "wait, that's a SCSI device" and then "wow, it worked anyway!" Nice job on the whole, but setting transfer modes is desirable, still. -- Bill Davidsen <[EMAIL PROTECTED]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Mark Lord wrote: Robert Hancock wrote: .. Only some of the hdparm functionality is supported in libata, That's not true. MOST hdparm functionality is supported in libata. Only a very few things are not supported, including -d and -X, for reasons already pointed out. Nearly everything else works. Agreed, I've already had problems typing faster than I think, twice, as as I hit ENTER saying wait, that's a SCSI device and then wow, it worked anyway! Nice job on the whole, but setting transfer modes is desirable, still. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: Stephen Clark wrote: Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a serious driver problem, which is why it should be under user control. -- Bill Davidsen [EMAIL PROTECTED] We have more to fear from the bungling of the incompetent than from the machinations of the wicked. - from Slashdot - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
re: hdparm -d Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a serious driver problem, which is why it should be under user control. Fair enough. The original reason for that functionality in the drivers/ide stuff, was that I wanted a way to be able to continue to test the IDE driver in PIO mode, despite all of my own devices having good DMA support. If there's no way to force the driver to use a particular transfer method, then it becomes difficult to (re)test the driver over time. Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Bill Davidsen wrote: I think deciding to turn off DMA which works fine in old kernels qualifies as a serious driver problem, which is why it should be under user control. For PATA, perhaps. For SATA, turning off DMA can often -cause- additional problems. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Bill Davidsen wrote: Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. I think deciding to turn off DMA which works fine in old kernels qualifies as a serious driver problem, which is why it should be under user control. Point is, if the DMA's not working such that the system decides to turn it off, it's obviously having some issues, and thus turning it back on without fixing the problem could cause problems or even cause data corruption. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Alan wrote: Userspace PIO mode changes are NOT a good idea, I would disagree there, but they are not high priority. We do need to allow set_features/xfer but we need to snoop it and mode set properly around it. There are cases you want to control this, more so admittedly for DMA speeds. *Bingo* That's the entire reason why libata does not support hdparm changing modes, etc.: there is a lot involved in allowing random SET FEATURES - XFER MODE commands from userspace. In some cases you have to stop all traffic on ports B,C,D,... in order to change the speed on port A. Jeff - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
\ Userspace PIO mode changes are NOT a good idea, and I doubt that libata would want to support that feature. The "-d" flag (enable/disable DMA) is currently not implemented by libata, though there may be a /sys/.. attribute for it (?). Okay but... the driver itself does implement the calls, maybe in another way but it does switch from DMA to PIO. At boot time it uses UDMA100 and after some transfer speed downgrades even tells me how there is no lower mode available (which means its running in PIO mode 1 I guess). I agree that its not a good idea, and in normal cases, you wont even need it cause your hardware works properly. I had a closer look at my old kernel logs, and different from the old ata drivers, the new libsata drivers probe every disk for its UDMA capabilities and sets them per drive, also on a bus reset, rather than resetting the entire bus and using the same transfer setting for all drives on that bus (which is what i saw happening with my promise IDE card and the old IDE drivers. So, with the new drivers, one failing disk doesnt drag the other disk with him into PIO mode, at least, this is how I see things on my screen and how I experience it. The disk that does fall back to PIO mode probably does have a serious problem or, in my case, the entire southbridge is overheated causing lots of PCI problems (thanks Robert, for the point out, I changed the powersuply and the southbridge fan and all works great now). So, yeah, in general I like the idea of being in control of my machine, how dangerous that might be, but in the case of libsata and my experience with the new pata drivers so far, the driver knows what's best for me and acts like it and building some overriding controls for userspace just will break things, if not totaly destroy it. Actually all problems I had so far with libsata were pointable to my stupidity (hello CONFIG_DEV_SD) or hardware that was totaly failing. So, I give two thumbs up to the new libsata/pata drivers, I really like the way they work and I truely see advantages using them over the old IDE drivers, not in the last place cause it is much easier to see disk/bus problems now since I find the ATA messages in the kernel log regarding what is done with my disks way more clear. So Alan, Robert, everybody else who helped me with migrating to libsata from the old IDE drivers, thanks a lot, your help was and is highly appriciated. Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
> Userspace PIO mode changes are NOT a good idea, I would disagree there, but they are not high priority. We do need to allow set_features/xfer but we need to snoop it and mode set properly around it. There are cases you want to control this, more so admittedly for DMA speeds. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: .. Only some of the hdparm functionality is supported in libata, That's not true. MOST hdparm functionality is supported in libata. Only a very few things are not supported, including -d and -X, for reasons already pointed out. Nearly everything else works. -ml - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? It already works fine with libata. .. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk Userspace PIO mode changes are NOT a good idea, and I doubt that libata would want to support that feature. The "-d" flag (enable/disable DMA) is currently not implemented by libata, though there may be a /sys/.. attribute for it (?). Cheers - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/5/07, Robert Hancock <[EMAIL PROTECTED]> wrote: Patrick Ale wrote: The southbridge usually runs the PCI bus connected to the slots, so it's possible that PCI bus issues were causing problems.. Explains a lot then yeah... okay, if the error occures again I will let you know, I am booting up as we speak :) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: Good morning all, About the reason as of why it drops to PIO mode, I might have found the reason for this, I am just not sure if what i found is related. When I opened my Athlon XP machine, took the cables out and replaced them for new cables, I found out that my southbridge fan wasnt spinning anymore, at all. So my guess is that this chip is overheated at some point and starts causing problems. Now, it was always my comprehension that the southbridge does indeed control the ATA controller but only the onboard one, so even if the chip is having heat problems, my PCI add-on cards should still work on full UDMA100 speed, right? The southbridge usually runs the PCI bus connected to the slots, so it's possible that PCI bus issues were causing problems.. I am re-assembling my athlon board again today, and as soon as I get the falling back to PIO mode errors again in dmesg I'll forward you the messages, like you asked :) If someone could shine a light on my question about the southbridge, I'd really appriciate it, email me privately if you prefer. Thanks! Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Good morning all, About the reason as of why it drops to PIO mode, I might have found the reason for this, I am just not sure if what i found is related. When I opened my Athlon XP machine, took the cables out and replaced them for new cables, I found out that my southbridge fan wasnt spinning anymore, at all. So my guess is that this chip is overheated at some point and starts causing problems. Now, it was always my comprehension that the southbridge does indeed control the ATA controller but only the onboard one, so even if the chip is having heat problems, my PCI add-on cards should still work on full UDMA100 speed, right? I am re-assembling my athlon board again today, and as soon as I get the falling back to PIO mode errors again in dmesg I'll forward you the messages, like you asked :) If someone could shine a light on my question about the southbridge, I'd really appriciate it, email me privately if you prefer. Thanks! Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Good morning all, About the reason as of why it drops to PIO mode, I might have found the reason for this, I am just not sure if what i found is related. When I opened my Athlon XP machine, took the cables out and replaced them for new cables, I found out that my southbridge fan wasnt spinning anymore, at all. So my guess is that this chip is overheated at some point and starts causing problems. Now, it was always my comprehension that the southbridge does indeed control the ATA controller but only the onboard one, so even if the chip is having heat problems, my PCI add-on cards should still work on full UDMA100 speed, right? I am re-assembling my athlon board again today, and as soon as I get the falling back to PIO mode errors again in dmesg I'll forward you the messages, like you asked :) If someone could shine a light on my question about the southbridge, I'd really appriciate it, email me privately if you prefer. Thanks! Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: Good morning all, About the reason as of why it drops to PIO mode, I might have found the reason for this, I am just not sure if what i found is related. When I opened my Athlon XP machine, took the cables out and replaced them for new cables, I found out that my southbridge fan wasnt spinning anymore, at all. So my guess is that this chip is overheated at some point and starts causing problems. Now, it was always my comprehension that the southbridge does indeed control the ATA controller but only the onboard one, so even if the chip is having heat problems, my PCI add-on cards should still work on full UDMA100 speed, right? The southbridge usually runs the PCI bus connected to the slots, so it's possible that PCI bus issues were causing problems.. I am re-assembling my athlon board again today, and as soon as I get the falling back to PIO mode errors again in dmesg I'll forward you the messages, like you asked :) If someone could shine a light on my question about the southbridge, I'd really appriciate it, email me privately if you prefer. Thanks! Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/5/07, Robert Hancock [EMAIL PROTECTED] wrote: Patrick Ale wrote: The southbridge usually runs the PCI bus connected to the slots, so it's possible that PCI bus issues were causing problems.. Explains a lot then yeah... okay, if the error occures again I will let you know, I am booting up as we speak :) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? It already works fine with libata. .. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk Userspace PIO mode changes are NOT a good idea, and I doubt that libata would want to support that feature. The -d flag (enable/disable DMA) is currently not implemented by libata, though there may be a /sys/.. attribute for it (?). Cheers - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: .. Only some of the hdparm functionality is supported in libata, That's not true. MOST hdparm functionality is supported in libata. Only a very few things are not supported, including -d and -X, for reasons already pointed out. Nearly everything else works. -ml - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Userspace PIO mode changes are NOT a good idea, I would disagree there, but they are not high priority. We do need to allow set_features/xfer but we need to snoop it and mode set properly around it. There are cases you want to control this, more so admittedly for DMA speeds. - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
\ Userspace PIO mode changes are NOT a good idea, and I doubt that libata would want to support that feature. The -d flag (enable/disable DMA) is currently not implemented by libata, though there may be a /sys/.. attribute for it (?). Okay but... the driver itself does implement the calls, maybe in another way but it does switch from DMA to PIO. At boot time it uses UDMA100 and after some transfer speed downgrades even tells me how there is no lower mode available (which means its running in PIO mode 1 I guess). I agree that its not a good idea, and in normal cases, you wont even need it cause your hardware works properly. I had a closer look at my old kernel logs, and different from the old ata drivers, the new libsata drivers probe every disk for its UDMA capabilities and sets them per drive, also on a bus reset, rather than resetting the entire bus and using the same transfer setting for all drives on that bus (which is what i saw happening with my promise IDE card and the old IDE drivers. So, with the new drivers, one failing disk doesnt drag the other disk with him into PIO mode, at least, this is how I see things on my screen and how I experience it. The disk that does fall back to PIO mode probably does have a serious problem or, in my case, the entire southbridge is overheated causing lots of PCI problems (thanks Robert, for the point out, I changed the powersuply and the southbridge fan and all works great now). So, yeah, in general I like the idea of being in control of my machine, how dangerous that might be, but in the case of libsata and my experience with the new pata drivers so far, the driver knows what's best for me and acts like it and building some overriding controls for userspace just will break things, if not totaly destroy it. Actually all problems I had so far with libsata were pointable to my stupidity (hello CONFIG_DEV_SD) or hardware that was totaly failing. So, I give two thumbs up to the new libsata/pata drivers, I really like the way they work and I truely see advantages using them over the old IDE drivers, not in the last place cause it is much easier to see disk/bus problems now since I find the ATA messages in the kernel log regarding what is done with my disks way more clear. So Alan, Robert, everybody else who helped me with migrating to libsata from the old IDE drivers, thanks a lot, your help was and is highly appriciated. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Alan wrote: Userspace PIO mode changes are NOT a good idea, I would disagree there, but they are not high priority. We do need to allow set_features/xfer but we need to snoop it and mode set properly around it. There are cases you want to control this, more so admittedly for DMA speeds. *Bingo* That's the entire reason why libata does not support hdparm changing modes, etc.: there is a lot involved in allowing random SET FEATURES - XFER MODE commands from userspace. In some cases you have to stop all traffic on ports B,C,D,... in order to change the speed on port A. Jeff - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Well, I am sure that someone will at least take the problem I have serious and will give me a good alternative to get things working, which isnt always the case with mickeysoft :D But again, yes, I do agree that if someone/something decides to reduce my transferspeed I should have an option to override that decision or tell the thing not to make that decision. Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick My point is that the driver can't be tested on every combination of hardware, so if the user doesn't have the capability to override assumptions the driver makes then he is stuck. I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Steve -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/4/07, Stephen Clark <[EMAIL PROTECTED]> wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Stephen Clark wrote: Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark A lot of those hdparm commands are legacy cruft from the old drivers/ide setup and just aren't needed with libata. For example, I think a major use for the enable/disable DMA option was for screwy distro setups where all the IDE drivers were built modular and the IDE core would load some generic support for the controller, then the device-specific driver module would get loaded and then you'd have to switch DMA on manually afterwards. (The old IDE drivers never really seemed to play well with being built as modules, probably a big reason why Red Hat/Fedora have always built them into the kernel.) Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get "Inappropriate iotcl for device" and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark -- "They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety." (Ben Franklin) "The course of history shows that as a government grows, liberty decreases." (Thomas Jefferson) - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get "Inappropriate iotcl for device" and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On Saturday 03 February 2007 09:55:52 Patrick Ale wrote: > Hi, > > The problem is even worse, the drive falls back to PIO mode and there > is no way I can get it back to dma mode (like I could by using > hdparm). The only thing i can do is reboot the machine so it will see > the drive is UDMA capable. > > If there is some beta/gamma software around or something you'd like to > have tested, you can mail me directly, my machine is your private > prostitute at the moment, it's not like i have something important to > do with the machine anyway (not related to this problem):) The libata expoted disls have a SCSI ioctl interface, sdparm should work on those. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Hi, The problem is even worse, the drive falls back to PIO mode and there is no way I can get it back to dma mode (like I could by using hdparm). The only thing i can do is reboot the machine so it will see the drive is UDMA capable. If there is some beta/gamma software around or something you'd like to have tested, you can mail me directly, my machine is your private prostitute at the moment, it's not like i have something important to do with the machine anyway (not related to this problem):) Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hdparm for lib_pata
Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get "Inappropriate iotcl for device" and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Patrick - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
hdparm for lib_pata
Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get Inappropriate iotcl for device and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Hi, The problem is even worse, the drive falls back to PIO mode and there is no way I can get it back to dma mode (like I could by using hdparm). The only thing i can do is reboot the machine so it will see the drive is UDMA capable. If there is some beta/gamma software around or something you'd like to have tested, you can mail me directly, my machine is your private prostitute at the moment, it's not like i have something important to do with the machine anyway (not related to this problem):) Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On Saturday 03 February 2007 09:55:52 Patrick Ale wrote: Hi, The problem is even worse, the drive falls back to PIO mode and there is no way I can get it back to dma mode (like I could by using hdparm). The only thing i can do is reboot the machine so it will see the drive is UDMA capable. If there is some beta/gamma software around or something you'd like to have tested, you can mail me directly, my machine is your private prostitute at the moment, it's not like i have something important to do with the machine anyway (not related to this problem):) The libata expoted disls have a SCSI ioctl interface, sdparm should work on those. -- René Rebe - ExactCODE GmbH - Europe, Germany, Berlin http://exactcode.de | http://t2-project.org | http://rene.rebe.name +49 (0)30 / 255 897 45 - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get Inappropriate iotcl for device and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Robert Hancock wrote: Hi guys, Me again, sorry. Is it possible to make hdparm work with libata? I have some drives that for some reason fall back to lower UDMA settings (like UDMA/44) while the drive is UDMA/100. I blame the way I set-up my raid arrays for this and the bus not being able to handle all the data that goes trough it but that isnt really the case now. Anyway, I used to be able to force the drive back with using hdparm -X68 -d 1 /dev/sdk But with the new lib_pata drivers I get Inappropriate iotcl for device and HD_IO_DRIVE_CMD Input/Output errors. Or! Is there some other way to force the drive not to failback to lower UDMA settings? (Yep, I know, if this is answer, it's my risk, I cant and wont blame you for destructing my pr0n or severe trauma I suffer from losing data) Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Stephen Clark wrote: Only some of the hdparm functionality is supported in libata, which is partially by design. Presently there's no way to override the DMA settings in libata, it starts out at the fastest supported settings and falls back if it gets too many errors of certain types. You shouldn't be seeing errors like this unless you have bad IDE cables or are using 40-wire cables with high UDMA modes. Can you post the output you're seeing? Ok, But why are we taking away the users capability to control his/her own hardware. Sounds like windows. My $.02 Steve Clark A lot of those hdparm commands are legacy cruft from the old drivers/ide setup and just aren't needed with libata. For example, I think a major use for the enable/disable DMA option was for screwy distro setups where all the IDE drivers were built modular and the IDE core would load some generic support for the controller, then the device-specific driver module would get loaded and then you'd have to switch DMA on manually afterwards. (The old IDE drivers never really seemed to play well with being built as modules, probably a big reason why Red Hat/Fedora have always built them into the kernel.) Support for that ioctl could likely be added, but these days I don't think there's much use for it. I can't see how anybody in their right mind would want to disable DMA on a modern drive, and if libata turns it off automatically then there's likely some serious hardware or driver problem that will end up biting you some other way if you force it back on. -- Robert Hancock Saskatoon, SK, Canada To email, remove nospam from [EMAIL PROTECTED] Home Page: http://www.roberthancock.com/ - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/4/07, Stephen Clark [EMAIL PROTECTED] wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
Patrick Ale wrote: On 2/4/07, Stephen Clark [EMAIL PROTECTED] wrote: Robert Hancock wrote: But why are we taking away the users capability to control his/her own hardware. Sounds like windows. I wouldn't go as far as making that comparsion, most of all cause it's totaly invalid, with all respect. In my opinion the new pata drivers are work in progress, they only appear in the latest kernel and snapshots so please, let's allow the drivers to evolve, I am no kernel hacker or coder, nor does my interest lay here at the moment to be honest, I am a system administrator working with Unix and Linux and am interested in helping out where I can. By using the new pata drivers in favor of the old IDE drivers I took a risk, well calculated and with the very thought of encountering these kind of problems and reporting them to make things better. However, I do have to agree with the point that if the drivers/kernel, for whatever reason they might have, to switch to a lower UDMA mode, and when none is left, even to PIO mode, I should have at least the chance to switch back to a higher level of datatransfer speed. How it looks now is that the kernel and its drivers treat the devices as ATA devices with their features, but the userland programs like hdparm and sdparm and blkutil see the devices as SCSI/SATA devices, and dont allow the ioctl commands which are valid for ATA drives. Just my two euros/canadian dollars/croatian kunas in the pocket :) Patrick My point is that the driver can't be tested on every combination of hardware, so if the user doesn't have the capability to override assumptions the driver makes then he is stuck. I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Steve -- They that give up essential liberty to obtain temporary safety, deserve neither liberty nor safety. (Ben Franklin) The course of history shows that as a government grows, liberty decreases. (Thomas Jefferson) - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: hdparm for lib_pata
On 2/4/07, Stephen Clark [EMAIL PROTECTED] wrote: I have had two different laptops that had to have boot time command line overrides to get the driver to allow the hardware work at what it was spec-ed at. Well, I am sure that someone will at least take the problem I have serious and will give me a good alternative to get things working, which isnt always the case with mickeysoft :D But again, yes, I do agree that if someone/something decides to reduce my transferspeed I should have an option to override that decision or tell the thing not to make that decision. Patrick - To unsubscribe from this list: send the line unsubscribe linux-kernel in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/