Bug 32533 - Dell L at C600 USB Mouse S2D qa0319
Summary: Dell L at C600 USB Mouse S2D qa0319
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: kernel   
(Show other bugs)
Version: 7.1
Hardware: i386 Linux
Target Milestone: ---
Assignee: Pete Zaitcev
QA Contact: Brock Organ
Depends On:
TreeView+ depends on / blocked
Reported: 2001-03-21 15:25 UTC by Rogelio Noriega
Modified: 2007-03-27 03:42 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2001-04-02 19:57:33 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Ugly workaround for the bug. (2.75 KB, patch)
2001-03-28 20:54 UTC, Pete Zaitcev
no flags Details | Diff

Description Rogelio Noriega 2001-03-21 15:25:06 UTC
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.

Comment 1 Bill Nottingham 2001-03-21 17:48:50 UTC
What if *no* USB peripherals are connected?

Comment 2 Mick Tantasirikorn 2001-03-21 21:12:42 UTC
the system has no problem if no USB peripheral is attached

Comment 3 Mick Tantasirikorn 2001-03-26 14:16:02 UTC
still happenning in qa0322

Comment 4 Pete Zaitcev 2001-03-28 00:17:45 UTC
Bill Notting was able to reproduce the problem on C600.
Good thing we had one...

Comment 5 Pete Zaitcev 2001-03-28 18:42:29 UTC
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.

Comment 6 Pete Zaitcev 2001-03-28 20:54:59 UTC
Created attachment 14023 [details]
Ugly workaround for the bug.

Comment 7 Pete Zaitcev 2001-03-28 20:58:11 UTC
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.

Comment 8 Pete Zaitcev 2001-03-31 04:58:01 UTC
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...

Comment 9 Pete Zaitcev 2001-04-01 02:37:05 UTC
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.

Comment 10 Mick Tantasirikorn 2001-04-02 13:53:56 UTC
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?

Comment 11 Pete Zaitcev 2001-04-02 19:37:50 UTC
I can tidy up the patch, add stubs for non-x86 platforms and
repush it to Linus, or at least Alan.

Comment 12 Alan Cox 2001-04-02 19:57:29 UTC
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.

Comment 13 Michael K. Johnson 2001-04-04 18:31:26 UTC
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"...

Comment 14 Pete Zaitcev 2002-06-04 04:48:20 UTC
See also bug 64799: same problem on Inspiron 5000e, only worse,
because it happens all the time, even before sleep.

Note You need to log in before you can comment on or make changes to this bug.