On Tue, 19 Mar 2013, Julius Werner wrote:
> > Yes, okay, that's true. If a new USB device is plugged in while the
> > lid is shut, and then the lid is opened very briefly, it's possible
> > that the system could suspend again before the new device's "persist"
> > attribute is updated. Does that
> Yes, okay, that's true. If a new USB device is plugged in while the
> lid is shut, and then the lid is opened very briefly, it's possible
> that the system could suspend again before the new device's "persist"
> attribute is updated. Does that case really matter? The device isn't
> likely to b
On Tue, 19 Mar 2013, Vincent Palatin wrote:
> > The races mentioned above don't seem to be very dangerous. How likely
> > is it that the system will be suspended within a few milliseconds of
> > probing a new USB device?
>
> For laptops, if the suspend/resume is triggered by the lid open/close
>
On Tue, Mar 19, 2013 at 7:56 AM, Alan Stern wrote:
>
> On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote:
>
> > On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote:
> > > > Why can't you just revert this in userspace? Isn't that easier than
> > > > doing a kernel patch and providing an opti
On Mon, 18 Mar 2013, Greg Kroah-Hartman wrote:
> On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote:
> > > Why can't you just revert this in userspace? Isn't that easier than
> > > doing a kernel patch and providing an option that we need to now
> > > maintain for pretty much forever?
> What drivers/devices don't work with persist? We need to know that now,
> otherwise all other distros and users have problems, right?
We have seen a problem with the LTE modem in the Chromebook Pixel
using the usb/serial/option.c driver, but we are not quite sure of the
root cause yet. It occas
On Mon, Mar 18, 2013 at 05:02:19PM -0700, Julius Werner wrote:
> > Why can't you just revert this in userspace? Isn't that easier than
> > doing a kernel patch and providing an option that we need to now
> > maintain for pretty much forever?
>
> I could solve it in userspace, but that really feel
> Why can't you just revert this in userspace? Isn't that easier than
> doing a kernel patch and providing an option that we need to now
> maintain for pretty much forever?
I could solve it in userspace, but that really feels like a hacky
workaround and not a long term solution. It would mean tha
On Wed, Mar 13, 2013 at 03:57:31PM -0700, Julius Werner wrote:
> Commit 9214d1d8 set the USB persist flag as a default for all devices.
> This might be desirable for some distributions, but it certainly has its
> trade-offs... most importantly, it can significantly increase system
> resume time, be
Commit 9214d1d8 set the USB persist flag as a default for all devices.
This might be desirable for some distributions, but it certainly has its
trade-offs... most importantly, it can significantly increase system
resume time, because the kernel blocks on resuming (and sometimes
resetting) USB devic
10 matches
Mail list logo
