a wild guess: does uninstalling ksynaptics (and re-logging in) help? (I would really wonder if this helps, but you never know. The symptoms look matching.)

Besides that: It would be helpful to provide a sniplet of /var/log/messages (at least from plugging out/in the mouse, maybe better from some time before KDE startup.

Created attachment 65797 [details]
/var/log/messages

Most of the stuff starts around Jan 30 18:31:31. This is a copy of the /var/log/messages just had to rename it to to cpmessages so i did not have to log out and log in as root.

do you have ksynaptics installed?

I have no idea, I did not install ksynaptics. I did go into yast and then went to the package install and ran a search on ksynaptics and nothing showed up. So I will assume no, but if there is a better way to check let me know. Does it come with the default install of suse if you just click the radio button to use kde?

no, it shouldn't be installed by default. to double check, look at the output of the command: 

rpm -q ksynaptics

I guess this is a xorg.conf generation problem lacking better explanations. Markus, any idea?

linux:/home/daniel # rpm -q ksynaptics
package ksynaptics is not installed

Hmm, sounds weird. Could you send me your xorg.conf file

  /etc/X11/xorg.conf

Thanks

Created attachment 66036 [details]
my xorg.conf file

My xorg.conf file as requested

That xorg.conf file was from after I unplugged the mouse and repluged it in. Will it be different after I do that? I mean should I try and get a copy of it while the mouse does not work?

you are using a standard mouse configuration:

Section "InputDevice"
  Driver       "mouse"
  Identifier   "Mouse[1]"
  Option       "Buttons" "5"
  Option       "Device" "/dev/input/mice"
  Option       "Name" "Logitech Optical Wheel Mouse"
  Option       "Protocol" "explorerps/2"
  Option       "Vendor" "Sysp"
  Option       "ZAxisMapping" "4 5"
EndSection

This section is correct I cannot see a X bug

thanks, reassigning to kernel-maintainers then. 

If I left something open and shut off the computer and then restart it and log back in. I get to use the mouse just log enough to close that tip window then it just stops.

Also if I restart the computer the mouse will not work not even at the log in screen. When I just shut it down and reboot it will work at the log in screen.

Can you try passing acpi=off on the kernel command line?

Ok I went into yast and went to system and then boot loader and i clicked edit on SUSE LINUX 10.0 and under other kernel parameters I put in acpi=off so it looks something like this:

selinux=0    resume=/dev/hda1  splash=silent showopts acpi=off

When I turn the computer back on I get the same problem. Is there a sure way to verify I did this correctly?

Well, a look at the output of 'dmesg' on the running system will show whether
ACPI was active or not.

Created attachment 66091 [details]
dump of dmesg

Dump of dmesg it says in there that stuff is disabled but there are also some errors in there.

Ok, ACPI is not interfering, which is good.

I see from the log you unplugged and replugged the mouse. Does it work
fine after you do that, or does it stop again after some time? Does it
work OK with another OS or machine? 

Tried with a different logitech mouse and it works fine. And tried mouse that on the Linux machine on a windows machine and it works fine.

OK. This looks like the clear_halt problem.

Can you try this patch:?

http://marc.theaimsgroup.com/?l=linux-usb-devel&m=113822473507514&q=raw

This may sound dumb, but how do I install that?

You'd install the kernel source rpm, then apply the patch using 'patch -p1 < patch', etc, but it'll be easier if you just install the KOTD (Kernel
Of The Day) from ftp.suse.com:

ftp://ftp.suse.com/pub/projects/kernel/kotd/i386/HEAD/kernel-default-2.6.16_rc2_git8-20060210184420.i586.rpm

I installed the KOTD now how do I patch it?

The KOTD should already contain the patch.

from yast /proc/version This is what it says

Linux version 2.6.16-rc2-git11-20060212162949-default (geeko@buildhost) (gcc version 4.1.0 20060210 (prerelease) (SUSE Linux)) #1 Sun Feb 12 16:29:49 UTC 2006

I installed kernel-default-2.6.16_rc2_git11-20060212162949.i586.rpm

And I am still having the same problem

I can reproduce the problem with 2.6.16-rc4-4-smp

Great, Dirk. Can you try to find what's being run at the time the mouse stops
working? Could be eg. powersaved, or a similar program. Much of what we used
to do early in the boot is now delayed, because it's not needed for the login
screen. And running that *after* the mouse is detected can confuse the mouse.

nothing is run, the system already finished booting. I can "fix" the mouse by switching to console and then going back to X server, but after a few seconds it stops again. No dmesg output. 

if I replugin the mouse it permanently works until the next reboot. the lsusb -v diff of broken vs working is: 

--- /tmp/broken 2006-02-27 13:55:31.000000000 +0100
+++ /tmp/works  2006-02-27 13:55:44.000000000 +0100
@@ -1,5 +1,5 @@
 
-Bus 004 Device 003: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
+Bus 004 Device 004: ID 046d:c00c Logitech, Inc. Optical Wheel Mouse
 Device Descriptor:
   bLength                18
   bDescriptorType         1

Can you check with 'evtest' whether the mouse also stops working there, or
it's just X that stops talking to it?

how am I supposed to do that?

# evtest /dev/input/mice
evtest: can't get version: Inappropriate ioctl for device

open("/dev/input/mice", O_RDONLY)       = 3
ioctl(3, EVIOCGVERSION, 0xbfa69154)     = -1 ENOTTY (Inappropriate ioctl for device)

(same happens for /dev/input/mouse1 (which is the one we're talking about))

vojtech@shadow:~> cat /proc/bus/input/devices 
I: Bus=0003 Vendor=046d Product=c004 Version=0120
N: Name="Logitech USB-PS/2 Mouse"
P: Phys=usb-0000:00:10.1-1/input0
S: Sysfs=/class/input/input0
H: Handlers=mouse0 event0 ts0 
B: EV=7
B: KEY=70000 0 0 0 0
B: REL=3

I: Bus=0003 Vendor=0430 Product=0005 Version=0101
N: Name="HID 0430:0005"
P: Phys=usb-0000:00:10.1-2/input0
S: Sysfs=/class/input/input1
H: Handlers=kbd event1 
B: EV=120003
B: KEY=1000000000007 ff800000000007ff f2beffdf73cfffff fffffffffffffffe
B: LED=1f

I: Bus=0010 Vendor=001f Product=0001 Version=0100
N: Name="PC Speaker"
P: Phys=isa0061/input0
S: Sysfs=/class/input/input2
H: Handlers=kbd event2 
B: EV=40001
B: SND=6

[use the event device corresponding to your mouse]

vojtech@shadow:~> evtest /dev/input/event0 
Input driver version is 1.0.0
Input device ID: bus 0x3 vendor 0x46d product 0xc004 version 0x120
Input device name: "Logitech USB-PS/2 Mouse"
Supported events:
  Event type 0 (Sync)
  Event type 1 (Key)
    Event code 272 (LeftBtn)
    Event code 273 (RightBtn)
    Event code 274 (MiddleBtn)
  Event type 2 (Relative)
    Event code 0 (X)
    Event code 1 (Y)
Testing ... (interrupt to exit)

ah, d'oh. ok, I read the --help now. rebooting..

evtest stops as well when the mouse hangs. last lines of output are: 

vent: time 1141049675.053197, type 2 (Relative), code 0 (X), value -1
Event: time 1141049675.053208, -------------- Report Sync ------------
Event: time 1141049675.061194, type 2 (Relative), code 1 (Y), value 1
Event: time 1141049675.061205, -------------- Report Sync ------------

interestingly, I cannot "reanimate" the mouse by switching console/X while evtest is running. I have to stop evtest, then do console/X switch, and then it works again (but only for a few seconds). 

Good, that's a clue. It means all users of the mouse need to close all its interfaces to revive the mouse. I'll look at what chain of functions that triggers.

diff of /proc/bus/input/devices before/after USB replugging:

--- /tmp/brokendev      2006-02-27 15:18:30.000000000 +0100
+++ /tmp/worksdev       2006-02-27 15:18:39.000000000 +0100
@@ -27,8 +27,8 @@

 I: Bus=0003 Vendor=046d Product=c00c Version=0610
 N: Name="Logitech USB Mouse"
-P: Phys=usb-0000:00:1d.3-1/input0
-S: Sysfs=/class/input/input3
+P: Phys=usb-0000:00:1d.3-2/input0
+S: Sysfs=/class/input/input4
 H: Handlers=mouse1 event3
 B: EV=7
 B: KEY=70000 0 0 0 0 0 0 0 0


/sys/class/input/input3 does not exist afterwards anymore, only input1, input2 and input4. 

I see this on a 10.1 beta 5.5 :)

Created attachment 70422 [details]
Adding some debug info to HID irq routine

Can you try this patch? It won't help, but may spew
some useful info into 'dmesg'.

*** Bug 151719 has been marked as a duplicate of this bug. ***

drivers/usb/input/hid-core.c: fatal irq status -2 received

When did that happen? It's supposed to happen upon removing the module or
removing the device, but not during normal operation.

Can you supply the surrounding lines of 'dmesg'?

*** Bug 94064 has been marked as a duplicate of this bug. ***

hmm, I was wrong. the -2 only happens once during boot, and afterwards I usually get status 0, only sometimes -84. the -84 resembles the point when the mouse stops working. 

Feb 28 11:33:30 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:33:30 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:33:30 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:33:36 oldboy kernel: drivers/usb/input/hid-core.c: fatal irq status -84 received
Feb 28 11:36:30 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:36:31 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:36:31 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:36:31 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:36:31 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received
Feb 28 11:36:31 oldboy kernel: drivers/usb/input/hid-core.c: OK irq status 0 received

Thanks. The -84 is a CRC error (or timeout). It's a hardware problem talking
to the device. Please check that your mouse works elsewhere and whether using
a different mouse fixes your problem. This can be caused by a broken mouse cable,
for example.

Anyway, we'll need to implement a workaround for this, as a number of people are
affected, and all of them having bad mouse cables or connectors is unlikely.

I'll post a patch that keeps the input irq urb running even if there was an error,
it may fix this. Alternately we might need a usb_clear_halt() on that endpoint, but that'd be far from easy to implement, since it can't be used from the urb callback routine.

Created attachment 70614 [details]
A patch that both adds debugging and tries to fix the problem.

Please try this one.

Well, I doubt that it is a hardware problem, because the mouse worked fine (== weeks/months) before that, and it also works perfectly for long time (several hours at least) after the first re-plugin of the hardware. 

Therefore I don't think that this is a hardware problem, because for the mouse it shouldn't matter if it is initialized while the kernel just has booted or at an arbitrary time later. 

patch works for me: 

drivers/usb/input/hid-core.c: OK irq status 0 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: error irq status -84 received
drivers/usb/input/hid-core.c: OK irq status 0 received
drivers/usb/input/hid-core.c: OK irq status 0 received
drivers/usb/input/hid-core.c: OK irq status 0 received
drivers/usb/input/hid-core.c: OK irq status 0 received


Ok, now fix the same issue for my usb modem :)

Created attachment 70930 [details]
A cleaned patch

Ok, this patch should fix the issue without spewing
a lot of messages into the log. Can you please test
that your mouse still works with this one? Thanks.

I think you'll need to submit a new bug for your modem. ;)
I've looked at the sources and it doesn't have the same problem
that HID did have, so it's probably something else. 

I already filed one for the usb modem ;) Thanks, I'll test the patch without the printk's, but I don't expect any surprises..

Thanks. Please also attach the output of 'lspci', so that I know
what USB controller exactly this is (for submitting the fix to mainline).

00:00.0 Host bridge: Intel Corporation 915G/P/GV/GL/PL/910GL Express Memory Controller Hub (rev 04)
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Express Chipset Family Graphics Controller (rev 04)
00:02.1 Display controller: Intel Corporation 82915G Express Chipset Family Graphics Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 1 (rev 03)
00:1c.1 PCI bridge: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) PCI Express Port 2 (rev 03)
00:1d.0 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #1 (rev 03)
00:1d.1 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #2 (rev 03)
00:1d.2 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #3 (rev 03)
00:1d.3 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB UHCI #4 (rev 03)
00:1d.7 USB Controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) USB2 EHCI Controller (rev 03)
00:1e.0 PCI bridge: Intel Corporation 82801 PCI Bridge (rev d3)
00:1e.2 Multimedia audio controller: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) AC'97 Audio Controller (rev 03)
00:1f.0 ISA bridge: Intel Corporation 82801FB/FR (ICH6/ICH6R) LPC Interface Bridge (rev 03)
00:1f.1 IDE interface: Intel Corporation 82801FB/FBM/FR/FW/FRW (ICH6 Family) IDE Controller (rev 03)
00:1f.2 IDE interface: Intel Corporation 82801FB/FW (ICH6/ICH6W) SATA Controller (rev 03)
40:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5751 Gigabit Ethernet PCI Express (rev 01)

I did not install any patches (from this site), all I did was install the KOTD on 2-12-06 (there was the first patch in there). Now my problem is gone. I have the same mouse, the same usb port. I do not think anything else got changed. It was fixed about 2 days ago. The only recent stuff I installed off the cd was G++ (and all its dependencies) and I was going to install the KOTD for 2-28-06 but it required perl-bootloader, so I messed around with trying to install that. The version of perl-bootloader I have installed is 0.2-37.2. However, when I tried to install the kernel it kept saying I needed a higher version so I said forget it. If I can be of any assistance please let me know. 

... disregard the above, while in the middle of typing this message the mouse stopped working. But it now works at start up but then dies in the middle. So I guess that is an improvement. So I guess my question is, how do I install that patch, and/or how do I get a later version of the perl-bootloader so I can install the latest kernel?

The patch will be added to our kernel CVS, then again installing the KOTD should
be enough.

Dirk, can do you have any results with the cleaned up patch?

it works fine, as expected :)

with the plain kotd I still have mouse not working after boot (though working for infinite amount of time after re-plugging in). 

I didn't push the patch to CVS yet. I'll do so over the weekend, hopefully.

How do I install the KOTD, because it ask about the perl-bootloader think So I guess my question is where can I go to update that so I can now install the KOTD?

The you update tool contains updates for perl-bootloader, so hopefully using
it will update it enough for KOTD. Alternately, a (hopefully enough) recent
version of the perl-bootloader RPM is here: 

ftp://ftp.suse.com/pub/suse/i386/update/10.0/rpm/i586/perl-Bootloader-0.2-37.2.i586.rpm

Another possibility is to install the kernel source RPM, apply the patch, recompile, install.

Does it work?

The problem still remains for me in RC1 both in installer and after installation. Mouse dies in about 1 min.

I tried the final version for suse 10.1 - same problem. 
Then installed KOTD - problem not solved, mouse still stops working after a few minutes.

Any chance of this being resolved? Since originally reporting this problem for 10.1 Beta 4 I got the same problem in 10.1 final and also the currently available SLED RC3. Also I changed the mouse model, currently Logitech LX5 cordless mouse (cennected through USB), with no success. Which probably means its more of an USB problem than mouse problem. The MB is Nvidia nForce but the Linux drivers they provide are unfortunately only for audio and ethernet.

I do apologize for repeatedly posting this here, but I really want to use SUSE and/or SLED, but without a working mouse it is impossible.

Is this bug still reproducible in current products? Error handling in HID was refactored in 2.6.17-rc1 (aef4e2), so I guess that openSuSE 10.2 with 2.6.18 kernel makes this problem go away, right?

There has been no activity/response for more than a month, I will close this bug as resolved. Please feel free to reopen it if you still experience the problem even on products based on the >= 2.6.18 kernels.