Re: USB harddisk drive fails on 2.6.23-rc3 (regression)

On Mon, 20 Aug 2007, Oliver Neukum wrote:

> Am Sonntag 19 August 2007 schrieb Jean Delvare:
> > > There are lots of possible ways to address this.  Worth trying is
> > > to enable the "allow_restart" attribute for the drive.  The attribute
> > > file appears in the sysfs directory for the disk; you may have to
> > > search around a little to find exactly where it is.  Also you may have
> > > to use the blockdev command to force the system to read the partition
> > > table after turning on allow_restart.
> > 
> > Yes, that worked. After writing 1 to allow_restart and running
> > "blockdev --rereadpt /dev/sda", the partition table can be read with
> > "fdisk -l /dev/sda" again.
> > 
> > Am I supposed to add these commands to my init scripts, or is there
> > another way to make the effect permanent?
> 
> Doesn't that defeat the stated purpose of autosuspend to be transparent
> to the user?

I have come to the conclusion that there are too many buggy USB devices 
for the kernel to try and cope.  Now maybe this just giving up too 
easily, but thing about it...  The idle-time autosuspend delay has 
to be controlled from userspace anyway; why shouldn't enabling 
autosuspend in the first place also be decided by the user?

In other words, I think the initial autosuspend_delay value should be
set to -1 for all devices other than hubs.  Rules can be added to udev
if that's how people want to enable autosuspend for devices where it
works, but a better approach would be to have HAL take care of it.  
Centralized databases, user-specific databases, pop-up windows whenever
a new device is plugged in, whatever...  There are lots of ways to
handle it.

To be honest, I'm afraid that the increasing number of bug reports
we've been seeing as 2.6.23 comes closer to final release will just
explode once a really large group of people start using the new code.  
And look at the table of quirks entries; these things don't belong in
the kernel -- they belong in a user-configurable table.

It's relatively easy (in most cases) for a user to test whether a 
device will survive being suspended -- although there has been at least 
one bug report about a device that worked most of the time but would 
occasionally fail!  But it's not so easy for the kernel, and it's even 
harder for the kernel to remember the result of the test from one 
session to the next.

In short, autosuspenc configuration _can't_ be transparent to the user, 
because the kernel is unable to handle it unassisted.  We should move 
responsibility for the whole thing out of the kernel and be done with 
it.

Alan Stern


-------------------------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >>  http://get.splunk.com/
_______________________________________________
[email protected]
To unsubscribe, use the last form field at:
https://lists.sourceforge.net/lists/listinfo/linux-usb-devel