Red Hat Bugzilla – Bug 32533
Dell L at C600 USB Mouse S2D qa0319
Last modified: 2007-03-26 23:42:38 EDT
When a usb mouse is connected to Lat C600 the system will suspend, but a
few seconds after resuming the on-board kb will stop functioning, the
hotkeys that are controlled by bios will still work. This only happens
with a usb mouse if a usb kb is connected the system resumes as expected.
What if *no* USB peripherals are connected?
the system has no problem if no USB peripheral is attached
still happenning in qa0322
Bill Notting was able to reproduce the problem on C600.
Good thing we had one...
Update - on our L C600 BIOS A06, if we go to Setup (F2), page 3,
then set "Pointing Device:" from "Touch Pad-PS/2 Mouse"
to "Serial Mouse", the problem disappears.
-I think- L C600 may be using this e-cheapo controllerless keyboard
and the port 0x60 emulator gets confused if Linux does not enable
Created attachment 14023 [details]
Ugly workaround for the bug.
One can do what BIOS ought to do in kernel, I attached a
patch for that. Personally, I would rather not see anything
like that in a mainstream kernel. What if it breaks some
obscure box that depends on current behaviour...
I wonder if we may ask Dell to fix their BIOS.
They are reasonable people.
I talked to Mike T. offline and he mentioned that 2.2.x works.
If so, it may be easier to integrate a fix into mainstream.
Reopening so that I won't forget to work on this...
Mike, does the 2.2.x really work? I looked at 2.2.x driver
and it looks absolutely identical to 2.4.x. Try to touch
the mousepad after resume.
You are right, my mistake, it does not work with 2.2.x kernel as well. I
might have gotten confused with other issues.
sorry and thanks. would there be a mainstream fix as well?
I can tidy up the patch, add stubs for non-x86 platforms and
repush it to Linus, or at least Alan.
I'd rather see Dell fix the bios bug personally. It shouldnt be that hard to fix
their APM suspend code to save/restore mouse state properly.
I agree that Dell should fix this in their BIOS; we shouldn't
clutter the generic kernel with ugly workarounds when it is
assuredly the wrong place to deal with the problem. This one
fails the slippery slope test.
Resolving "NOTABUG" as the closest resolution to "NOTOURBUG"...
See also bug 64799: same problem on Inspiron 5000e, only worse,
because it happens all the time, even before sleep.