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 PS/2 mouse.
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.