so i'll file a bug against usb saying it should allow suspend of devices that are not present.
should i also file a new bug against X in the same cat/subcat as 6844148? ed On Tue, Mar 23, 2010 at 01:05:48PM -0700, Edward Pilatowicz wrote: > On Tue, Mar 23, 2010 at 12:50:24PM -0700, Alan Coopersmith wrote: > > Edward Pilatowicz wrote: > > > so one of my coworkers pointed out what seems to be a bug with X, usb, > > > and suspend/resume. i was wondering if this was a known issue. > > > specifically, if i start up X on my laptop it opens the default mouse > > > device: > > > > > > ---8<--- > > > edp at squee$ pfexec pfiles 101044 | grep mouse > > > /devices/pseudo/consms at 0:mouse > > > ---8<--- > > > > Presumably for the trackpad or equivalent built in pointer device that's > > coming in via PS/2 instead of USB. > > > > > subsequently if i plug in a usb mouse X opens that as well: > > > > > > ---8<--- > > > edp at squee$ pfexec pfiles 101044 | grep mouse > > > /devices/pseudo/consms at 0:mouse > > > /devices/pci at 0,0/pci1179,1 at 1d,2/mouse at 2:mouse > > > ---8<--- > > > > > > unfortunately, if i unplug the usb mouse X never closes the associated > > > usb mouse device, which seems to break suspend/resume: > > > > > > ---8<--- > > > genunix: [ID 535284 kern.notice] System is being suspended > > > genunix: [ID 122848 kern.warning] WARNING: Unable to suspend device mouse > > > at 2. > > > genunix: [ID 537702 kern.warning] WARNING: Device is busy or does not > > > support suspend/resume. > > > ---8<--- > > > > I don't know why it would affect suspend/resume, and don't know off hand of > > any > > current bugs there, but we should close now when we get ENODEV because the > > mouse was removed without hald noticing (since 6844148 was fixed in 132), > > as well as when we get notification from hald that the mouse has been > > unplugged. > > > > so i saw this problem while running b135, which seems like it should > have the fix for 6844148? > > i think it's affecting suspend/resume because usb is failing to suspend > a device which is not there. (perhaps this is a bug in itself, if a > device isn't there why not just report success for suspend, after all > there is no hardware state to update.) > > wrt hald, i'm guessing that hald wouldn't send any notification of > device removal because from the device tree perspective, the device > hasn't actually been removed. ie, the physical device has been > unplugged, but the kernel device node for that device is still in the > kernel device tree and will remain there until X closes it (at which > point it's ref count goes to 0 and it can be destroyed.) > > ed
