On Thursday 31 August 2006 4:01 am, Rodolfo Giometti wrote:
> On Thu, Aug 31, 2006 at 03:36:42AM -0700, David Brownell wrote:
> > But in general, userspace should be assuming that all removable
> > media will have been removed by the time the system comes back up,
> > and have prepared for it. Un
On Wed, 13 Sep 2006, Rodolfo Giometti wrote:
> If you can give me some suggestion on how I should proceed I can start
> looking at this problem by myself. :)
That's easy. Proceed by trying out the patch I sent you:
http://marc.theaimsgroup.com/?l=linux-kernel&m=115747057302603&w=2
Alan Stern
On Fri, Sep 01, 2006 at 11:07:14AM -0400, Alan Stern wrote:
> On Fri, 1 Sep 2006, Rodolfo Giometti wrote:
>
> > I see but:
> >
> > 1) the system may use the vendor & product ID, the product string and
> > serial number to identify the device reducing conflicts.
> >
> > 2) this could be a kernel
On Fri, 1 Sep 2006, Rodolfo Giometti wrote:
> I see but:
>
> 1) the system may use the vendor & product ID, the product string and
> serial number to identify the device reducing conflicts.
>
> 2) this could be a kernel option so the user, before enabling it, is
> warned.
I like the idea of mak
On Fri, Sep 01, 2006 at 10:30:41AM -0400, Alan Stern wrote:
>
> That's not possible. As far as the computer is concerned, after the
> resume there is a _new_ key plugged in. The old name is still in use,
> because it is mounted, so the new device _cannot_ be assigned the old
> name.
But it co
On Fri, 1 Sep 2006, Rodolfo Giometti wrote:
> > Also, isn't this exactly what happens now? If you leave a USB key plugged
> > in as /dev/sda and mounted, then suspend and resume, don't you find the
> > key has moved to /dev/sdb? So what do you want to change?
>
> I'd like the system (mass-sto
On Fri, Sep 01, 2006 at 10:06:02AM -0400, Alan Stern wrote:
>
> I don't understand what you are asking.
>
> usb-storage _does_ know when the system is resuming. It does not assign
> device names (sda, sdb, etc.) -- the SCSI disk driver does that.
> Remember, usb-storage handles all sorts of ma
On Fri, 1 Sep 2006, Rodolfo Giometti wrote:
> On Thu, Aug 31, 2006 at 10:34:51AM -0400, Alan Stern wrote:
> >
> > Not if the USB ports lose power during the suspend. That's equivalent to
> > keeping your rootfs on a USB key and then unplugging the key. It just
> > won't work.
>
> Ok, I see.
On Thu, Aug 31, 2006 at 10:34:51AM -0400, Alan Stern wrote:
>
> Not if the USB ports lose power during the suspend. That's equivalent to
> keeping your rootfs on a USB key and then unplugging the key. It just
> won't work.
Ok, I see. So the devices must be re-enumerated, but in this situation
> > > do better than that; see how ohci-at91.c will keep USB active during
> > > "standby" sleep, that's the best in-tree example today.
> >
> > It disables only the clocks... it seems a "poor" suspend/resume
> > support...
>
> Better than nothing. What else would you like to disable?
More to th
On Thu, 31 Aug 2006, Rodolfo Giometti wrote:
> On Thu, Aug 31, 2006 at 03:36:42AM -0700, David Brownell wrote:
> >
> > USB on many system-on-chip processors also has less aggressive sleep
> > states, where for example USB port power might be maintained, and
> > the root hub clocked enough to dete
On Thu, Aug 31, 2006 at 03:36:42AM -0700, David Brownell wrote:
>
> USB on many system-on-chip processors also has less aggressive sleep
> states, where for example USB port power might be maintained, and
> the root hub clocked enough to detect simple events like "remote
> wakeup", "connect new de
> Date: Thu, 31 Aug 2006 11:24:17 +0200
> From: Rodolfo Giometti <[EMAIL PROTECTED]>
>
> When I put the system to sleep and then it wakes up everything works
> well _if_ the USB key is not mounted before the sleep. For instance,
> if I mount partition "/dev/sda1" (first USB key partition) and then
Hello,
I'm working on sleep for USB host on au1x00 CPUs and I have the
following problem.
When I put the system to sleep and then it wakes up everything works
well _if_ the USB key is not mounted before the sleep. For instance,
if I mount partition "/dev/sda1" (first USB key partition) and then g
drivers/usb/inode.c:usbdevfs_root_readdir()
read_lock_irq(&usb_bus_list_lock) then calls filldir callback with
that held, which touches userspace.
Franks a lot,
David S. Miller
[EMAIL PROTECTED]
___
[EMAIL PROTECTED]
To unsubscribe, use the last fo
15 matches
Mail list logo
