Hi All,
Please keep me CC-ed as I'm not subscribed.
Some time ago a mail about turning of the leds on usb pendrives once unmounted
by hal was send to the fedora-devel list:
https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01807.html
This mail talked about echo 2 > power/state for usb devices.
I tested the method described in the mail to turn of the drive light and it
worked well.
As I think that turning of the drive led (as windows does) would be good visual
feedback to the end user that its safe to remove the device I've written a
patch for hal which does the power state change automatically when the last
partition of a usb massstorage device gets unmounted.
However when testing the patch I found out that my now newer kernel no longer
has power/state for usb devices, it only has power/level. I can send suspend to
power/level, but then remounting the device won't work and me syslog fills
itself with:
sd 2:0:0:0: [sdc] READ CAPACITY failed
sd 2:0:0:0: [sdc] Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK,SUGGEST_OK
sd 2:0:0:0: [sdc] Sense not available.
sd 2:0:0:0: [sdc] Write Protect is off
sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00
sd 2:0:0:0: [sdc] Assuming drive cache: write through
Because hal keeps polling the device.
So this leads me to a couple of questions:
1) Would it be possible to funtionality to the kernel to suspend a device in
such a way that it will automatically unsuspend when used again?
2) Would it be possible to still make the polls succeed then with out
unsuspending the device (or atleast without doing something that would make
the led light again, what makes the led light exactly is unknown), or should
hal stop polling then?
Note I'm aware that some usb devices may not like being suspended, but thats a
problem for later, if this cannot be made to work with devices which do handle
suspend properly, then thinking about white and/or blacklisting it irrelevant.
Regards,
Hans
(linux-usb-devel needs CC)
On Fri, 21 Sep 2007, Hans de Goede wrote:
> 1) Would it be possible to funtionality to the kernel to suspend a device in
> such a way that it will automatically unsuspend when used again?
It is possible - USB now supports autosuspend. After a long debate, it was
however devcided that it is explicitly turned off, and userspace is free
to turn it on via sysfs interface for whatever devices the user likes to
do so.
This is mainly because there is a huge load of USB devices out there that
don't support this feature correctly, and we will break them if we perform
autosuspend automatically.
> 2) Would it be possible to still make the polls succeed then with out
> unsuspending the device (or atleast without doing something that
> would make the led light again, what makes the led light exactly is
> unknown), or should hal stop polling then?
How would you know how exactly respond to poll() that no userspace program
gets confused? There are many different kinds of USB devices.
--
Jiri Kosina
<please use reply to all to keep me cc-ed, I'm not subscribed>
Jiri Kosina wrote:
> On Fri, 21 Sep 2007, Hans de Goede wrote:
>
>> 1) Would it be possible to funtionality to the kernel to suspend a device in
>> such a way that it will automatically unsuspend when used again?
>
> It is possible - USB now supports autosuspend. After a long debate, it was
> however devcided that it is explicitly turned off, and userspace is free
> to turn it on via sysfs interface for whatever devices the user likes to
> do so.
>
Thats not what I had in mind, autosuspend doesn't work (presumably because hal
keeps polling for media change) maybe I should fix hal to not keep polling for
devices which don't have removable media?
What one was able todo some time ago when there still was a power/state sysfs
entry for usb devices, was suspend the device without changing the autosuspend
state and then it would wake automatically when used again, I think it would be
easiest for hal to see this behaviour back.
Note I'm not saying that this behaviour should be brought back, currently I'm
mainly trying to find out what hal may / may not expect from the kernel with
regards to usb suspend in the future so that I can write a hal patch based on that.
Regards,
Hans
On Fri, 21 Sep 2007, Jiri Kosina wrote:
> (linux-usb-devel needs CC)
>
> On Fri, 21 Sep 2007, Hans de Goede wrote:
>
> > 1) Would it be possible to funtionality to the kernel to suspend a device in
> > such a way that it will automatically unsuspend when used again?
>
> It is possible - USB now supports autosuspend. After a long debate, it was
> however devcided that it is explicitly turned off, and userspace is free
> to turn it on via sysfs interface for whatever devices the user likes to
> do so.
>
> This is mainly because there is a huge load of USB devices out there that
> don't support this feature correctly, and we will break them if we perform
> autosuspend automatically.
>
> > 2) Would it be possible to still make the polls succeed then with out
> > unsuspending the device (or atleast without doing something that
> > would make the led light again, what makes the led light exactly is
> > unknown), or should hal stop polling then?
The correct answer is that HAL should top polling while the device is
suspended.
In kernels starting with 2.6.23-rc6, the correct way to enable
autosuspend for a USB device is basically like this:
echo D >/sys/bus/usb/devices/.../power/autosuspend
echo auto >/sys/bus/usb/devices/.../power/level
where D is the time (in seconds) the device should remain idle before
it is autosuspended. An autosuspended device will be woken up to
respond to polls. (Note however that in this kernel, autosuspend
support for USB mass-storage devices was removed because it can
cause problems related to spinning down disk drives.)
If instead you do
echo suspend >/sys/bus/usb/devices/.../power/level
it will simply suspend the device immediately. The device will not be
woken up automatically and attempts to poll it (or do anything else)
will fail.
Alan Stern
On Fri, 21 Sep 2007, Hans de Goede wrote:
> Thats not what I had in mind, autosuspend doesn't work (presumably
> because hal keeps polling for media change) maybe I should fix hal to
> not keep polling for devices which don't have removable media?
Hi Hans,
I think the correct solution is that HAL stops polling the device as soon
as it sees that it got autosuspended.
--
Jiri Kosina
Am Freitag 21 September 2007 schrieb Hans de Goede:
> Thats not what I had in mind, autosuspend doesn't work (presumably because hal
> keeps polling for media change) maybe I should fix hal to not keep polling for
> devices which don't have removable media?
If you find a way to tell which devices fall into that class.
Regards
Oliver
Alan Stern wrote:
> The correct answer is that HAL should top polling while the device is
> suspended.
>
> In kernels starting with 2.6.23-rc6, the correct way to enable
> autosuspend for a USB device is basically like this:
>
> echo D >/sys/bus/usb/devices/.../power/autosuspend
> echo auto >/sys/bus/usb/devices/.../power/level
>
I'm afraid that that doesn't work for usb mass-storage devices.
Here is what I did:
1) kill hal
2) insert usb stick -> led lights
3):
echo -n 1 > /sys/bus/usb/devices/.../power/autosuspend
echo -n auto > /sys/bus/usb/devices/.../power/level
4) wait
Nothing happens, where as sending "suspend" to power/level does turn the led
off. Now call me naive, but I would expect a mass-storage devices with no
partitions mounted to autosuspend when autosuspend is enabled for that device.
And yes I'm pretty sure nothing else is talking to the device.
As usual keep please me CC-ed as I'm not on the list.
Regards,
Hans
On Sat, 22 Sep 2007, Hans de Goede wrote:
> I'm afraid that that doesn't work for usb mass-storage devices.
>
> Here is what I did:
> 1) kill hal
> 2) insert usb stick -> led lights
> 3):
> echo -n 1 > /sys/bus/usb/devices/.../power/autosuspend
> echo -n auto > /sys/bus/usb/devices/.../power/level
>
> 4) wait
>
> Nothing happens, where as sending "suspend" to power/level does turn the led
> off.
I don't know what went wrong. It works fine on my systems. You did
fill in the correct device path for the "...", right? And you don't
need the "-n" -- adding it shouldn't matter, but you should try reading
back the contents of those files to make sure the values did get
written correctly.
> Now call me naive, but I would expect a mass-storage devices with no
> partitions mounted to autosuspend when autosuspend is enabled for that device.
Yes, that is naive. The driver has no way to tell whether or not any
partitions are mounted. Furthermore, you might very well want to
access the raw device without mounting any partitions (database
managers frequently do such things to reduce I/O overhead), in which
case you certainly would not the device to be autosuspended.
> And yes I'm pretty sure nothing else is talking to the device.
You can be absolutely certain by using usbmon (see
Documentation/usb/usbmon.txt). It will also show whether any suspends
or resumes are actually being sent.
Alan Stern
Alan Stern wrote:
> On Sat, 22 Sep 2007, Hans de Goede wrote:
>
>> I'm afraid that that doesn't work for usb mass-storage devices.
>>
>> Here is what I did:
>> 1) kill hal
>> 2) insert usb stick -> led lights
>> 3):
>> echo -n 1 > /sys/bus/usb/devices/.../power/autosuspend
>> echo -n auto > /sys/bus/usb/devices/.../power/level
>>
>> 4) wait
>>
>> Nothing happens, where as sending "suspend" to power/level does turn the led
>> off.
>
> I don't know what went wrong. It works fine on my systems. You did
> fill in the correct device path for the "...", right?
Yes, the one that comes and goes as I plug in one of the USB-sticks I ue for
testing.
> And you don't
> need the "-n" -- adding it shouldn't matter, but you should try reading
> back the contents of those files to make sure the values did get
> written correctly.
>
I did read them back and it did get written correctly.
>> Now call me naive, but I would expect a mass-storage devices with no
>> partitions mounted to autosuspend when autosuspend is enabled for that device.
>
> Yes, that is naive. The driver has no way to tell whether or not any
> partitions are mounted. Furthermore, you might very well want to
> access the raw device without mounting any partitions (database
> managers frequently do such things to reduce I/O overhead), in which
> case you certainly would not the device to be autosuspended.
>
How does this relate to your "It works fine on my systems" remark, do I need to
do anything other the unmounting the paritions to make the device eligible for
autosuspend, like unbind the sd driver or even the usb-storage driver?
If so I must say I find that a little counter intuitive.
Regards,
Hans
p.s.
As always, please keep me CC-ed, not on the list.
On Sat, 22 Sep 2007, Hans de Goede wrote:
> >> Now call me naive, but I would expect a mass-storage devices with no
> >> partitions mounted to autosuspend when autosuspend is enabled for that device.
> >
> > Yes, that is naive. The driver has no way to tell whether or not any
> > partitions are mounted. Furthermore, you might very well want to
> > access the raw device without mounting any partitions (database
> > managers frequently do such things to reduce I/O overhead), in which
> > case you certainly would not the device to be autosuspended.
> >
>
> How does this relate to your "It works fine on my systems" remark, do I need to
> do anything other the unmounting the paritions to make the device eligible for
> autosuspend, like unbind the sd driver or even the usb-storage driver?
You shouldn't have to do anything. Mounted or unmounted, bound to sd
or not bound, it shouldn't matter. Provided the device isn't being
used, it ought to autosuspend.
I repeat: To find out what is really happening, you should use usbmon.
Alan Stern
Am Freitag 21 September 2007 schrieb Jiri Kosina:
> On Fri, 21 Sep 2007, Hans de Goede wrote:
>
> > Thats not what I had in mind, autosuspend doesn't work (presumably
> > because hal keeps polling for media change) maybe I should fix hal to
> > not keep polling for devices which don't have removable media?
>
> Hi Hans,
>
> I think the correct solution is that HAL stops polling the device as soon
> as it sees that it got autosuspended.
And how would we notice a medium change then? If there's an alternative
way to notice it or we know it cannot happen there's no reason to poll at all.
Regards
Oliver
Oliver Neukum wrote:
> Am Freitag 21 September 2007 schrieb Jiri Kosina:
>> On Fri, 21 Sep 2007, Hans de Goede wrote:
>>
>>> Thats not what I had in mind, autosuspend doesn't work (presumably
>>> because hal keeps polling for media change) maybe I should fix hal to
>>> not keep polling for devices which don't have removable media?
>> Hi Hans,
>>
>> I think the correct solution is that HAL stops polling the device as soon
>> as it sees that it got autosuspended.
>
> And how would we notice a medium change then? If there's an alternative
> way to notice it or we know it cannot happen there's no reason to poll at all.
>
It looks like hal is currently polling device of which it knows the medium is
not removable, like USB-pens.
Regards,
Hans
Am Montag 24 September 2007 schrieb Hans de Goede:
> Oliver Neukum wrote:
> > Am Freitag 21 September 2007 schrieb Jiri Kosina:
> >> On Fri, 21 Sep 2007, Hans de Goede wrote:
> >>
> >>> Thats not what I had in mind, autosuspend doesn't work (presumably
> >>> because hal keeps polling for media change) maybe I should fix hal to
> >>> not keep polling for devices which don't have removable media?
> >> Hi Hans,
> >>
> >> I think the correct solution is that HAL stops polling the device as soon
> >> as it sees that it got autosuspended.
> >
> > And how would we notice a medium change then? If there's an alternative
> > way to notice it or we know it cannot happen there's no reason to poll at all.
> >
>
> It looks like hal is currently polling device of which it knows the medium is
> not removable, like USB-pens.
It doesn't, which is the point. The overwhelming number of USB devices
don't bother to correctly declare themselves not removable SCSI devices.
The discrimination will have to happen on a product:vendor basis, which
means that a large database has to be built and maintained.
Regards
Oliver
Hans de Goede wrote:
> Hi All,
>
> Please keep me CC-ed as I'm not subscribed.
>
> Some time ago a mail about turning of the leds on usb pendrives once
> unmounted by hal was send to the fedora-devel list:
> https://www.redhat.com/archives/fedora-devel-list/2007-August/msg01807.html
>
> This mail talked about echo 2 > power/state for usb devices.
>
> I tested the method described in the mail to turn of the drive light and
> it worked well.
>
> As I think that turning of the drive led (as windows does) would be good
> visual feedback to the end user that its safe to remove the device I've
> written a patch for hal which does the power state change automatically
> when the last partition of a usb massstorage device gets unmounted.
>
> However when testing the patch I found out that my now newer kernel no
> longer has power/state for usb devices, it only has power/level. I can
> send suspend to power/level, but then remounting the device won't work
> and me syslog fills itself with:
> sd 2:0:0:0: [sdc] READ CAPACITY failed
> sd 2:0:0:0: [sdc] Result: hostbyte=DID_ERROR
> driverbyte=DRIVER_OK,SUGGEST_OK
> sd 2:0:0:0: [sdc] Sense not available.
> sd 2:0:0:0: [sdc] Write Protect is off
> sd 2:0:0:0: [sdc] Mode Sense: 00 00 00 00
> sd 2:0:0:0: [sdc] Assuming drive cache: write through
>
> Because hal keeps polling the device.
What did power/state do, and can that capability be easily recovered?
Being able to turn off the lights is desirable, but it may be that
standby is the only way to do that, with all the issue already discussed
in this thread. But if there's another way, it would be useful.
--
Bill Davidsen <[email protected]>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot