# USB mouse must first be unplugged to be recognized. [SOLVED]

## Budoka

Subject says it all. Just started recently not sure why. If I start my laptop with my USB mouse plugged in it isn't recognized. Same behavior if I suspend or sleep. I must unplug and re-plug it for it to be recognized.

$ dmesg |wgetpaste

Your paste can be seen here: https://bpaste.net/show/d2ab198e7dfc

I don't know if they are related but this started happening the exact same time the mouse started  being problematic.

https://forums.gentoo.org/viewtopic-t-1006074-highlight-.htmlLast edited by Budoka on Thu Feb 05, 2015 9:44 am; edited 1 time in total

----------

## Bloss

can you print the output of lsusb before and after?

Also what version of udev are you using, and what are your use flags for xorg-drivers

----------

## Budoka

 *Bloss wrote:*   

> can you print the output of lsusb before and after?
> 
> Also what version of udev are you using, and what are your use flags for xorg-drivers

 

Thanks.

lsusb before:

 *Quote:*   

> # lsusb
> 
> Bus 002 Device 004: ID 8086:0189 Intel Corp. 
> 
> Bus 002 Device 003: ID 0d62:a100 Darfon Electronics Corp. Optical Mouse
> ...

 

lsusb after (unplug/replug):

 *Quote:*   

> # lsusb
> 
> Bus 002 Device 004: ID 8086:0189 Intel Corp. 
> 
> Bus 002 Device 005: ID 0d62:a100 Darfon Electronics Corp. Optical Mouse
> ...

 

I am using eudev so can I escape systemd.

 *Quote:*   

> # eix -I xorg-drivers
> 
> [I] x11-base/xorg-drivers
> 
>      Available versions:  1.9 1.10 1.11 1.12 1.13 1.14 1.15 ~1.16 {INPUT_DEVICES="acecad aiptek elographics evdev fpit hyperpen joystick keyboard mouse mutouch penmount synaptics tslib vmmouse void wacom" VIDEO_CARDS="apm ark ast chips cirrus dummy epson fbdev fglrx freedreno geode glint i128 i740 impact intel mach64 mga modesetting neomagic newport nouveau nv nvidia omap omapfb qxl r128 radeon radeonsi rendition s3 s3virge savage siliconmotion sis sisusb sunbw2 suncg14 suncg3 suncg6 sunffb sunleo suntcx tdfx tga trident tseng v4l vesa via virtualbox vmware voodoo"}
> ...

 

 *Quote:*   

> # eix -I udev
> 
> [I] sys-fs/eudev
> 
>      Available versions:  *1.3 *1.5.3-r1 1.9-r2 1.10-r2 ~2.1.1 **9999 {doc gudev (+)hwdb introspection (+)keymap (+)kmod +modutils +openrc +rule-generator selinux static-libs test ABI_MIPS="n32 n64 o32" ABI_PPC="32 64" ABI_S390="32 64" ABI_X86="32 64 x32"}
> ...

 

----------

## Bloss

Did you try emerging gpm and seeing if it would detect the mouse in a framebuffer? If gpm can use it then it's an issue with xorg.

----------

## Budoka

 *Bloss wrote:*   

> Did you try emerging gpm and seeing if it would detect the mouse in a framebuffer? If gpm can use it then it's an issue with xorg.

 

I'm sorry but can you clarify how you want me to test this? I already have gpm installed and the mouse is not active at console or in a terminal as well...unless I unplug it and re-plug it in. It is the same behavior. But I am not sure if that is what you mean by "framebuffer" thus my confusion.

Thanks.

----------

## Bloss

you can access your terminal via initial framebuffers via ctrl-alt-f1 through f6

and xorg is usually started on f7.

you start gpm by 

```

/etc/init.d/gpm start

```

so you can select data to be copied and pasted.

but if gpm is reflecting the same behavior I would try updating eudev as I think that might be the culprit.

----------

## Budoka

 *Bloss wrote:*   

> you can access your terminal via initial framebuffers via ctrl-alt-f1 through f6
> 
> and xorg is usually started on f7.
> 
> you start gpm by 
> ...

 

I have to be honest I am not clear what it is you are asking me to do. Am I doing this before logging into DE or after? As I indicated I already have GPM installed and it is running.

The mouse does not work in any window, terminal or otherwise, or in the DE at all unless I disconnect it and reconnect it. On any of my USB ports.

I updated eudev and it didn't fix anything. This is recent behavior so clearly something was changed on my system in an update.

Although not a huge problem it is ridiculous that I have to keep disconnecting and reconnecting my mouse to use it. Any other ideas??? I suspect you may be right about eudev but not sure how to troubleshoot it.

This person seems to be having the same issue but it is with a wireless mouse so not sure if the cause is the same. https://forums.gentoo.org/viewtopic-t-1007844-highlight-.html

----------

## albright

do you have power management activated for your mouse

usb port?

I have to disable that or get the same symptoms you report ...

----------

## digifuzzy

I have seen a rare situation where a weak USB device can cause problems.

The only fix was to unplug and replug as you have done.

If its an older device (USB 1.0 days), this may be a hardware issue and can be confirmed by checking /var/log/messages and/or dmesg for USB errors.

----------

## Budoka

 *digifuzzy wrote:*   

> I have seen a rare situation where a weak USB device can cause problems.
> 
> The only fix was to unplug and replug as you have done.
> 
> If its an older device (USB 1.0 days), this may be a hardware issue and can be confirmed by checking /var/log/messages and/or dmesg for USB errors.

 

Thanks. That would kind of make sense and is entirely possible, but I am not sure that is going on with my mouse. Although an older mouse it is the only one I have used with Gentoo for a couple of years now without issue. So not sure why suddenly it would behave the way it is. That and in conjunction with some other problems that started occurring about the same time after n update leads me to believe it is something else that I can't figure out. Anyway here is my log and dmesg. Is there anything obvious?

 *Quote:*   

> $ sudo cat /var/log/messages |grep -i mouse
> 
> Jan 10 04:33:39 TL_Samsung kernel: usb 3-1: Product: USB Optical Mouse
> 
> Jan 10 04:33:39 TL_Samsung kernel: input: Darfon USB Optical Mouse as /devices/pci0000:00/0000:00:1c.4/0000:04:00.0/usb3/3-1/3-1:1.0/0003:0D62:A100.0005/input/input17
> ...

 

----------

## digifuzzy

This mouse wouldn't happen to be plugged into a hub would it?

How old is the hub?

In the dmesg log I see the optical mouse entered twice. One at usb 3-1 and then usb 2-1.2. Makes me wonder if there is udev issue here.

----------

## Budoka

 *digifuzzy wrote:*   

> This mouse wouldn't happen to be plugged into a hub would it?
> 
> How old is the hub?
> 
> In the dmesg log I see the optical mouse entered twice. One at usb 3-1 and then usb 2-1.2. Makes me wonder if there is udev issue here.

 

No hub as far as I know. Plugged directly into a USB port on laptop. Always the same.

The 3-1 and then 2-1,2 entry was me trying the other usb ports to see if the behavior was the same...it was. I have 3 usb ports. Two 2.1's and one 3.1.  I suspect eudev as well but am out of my epth so don't know how to troubleshoot it. Thanks for helping me out everyone. Hope to solve this.

 *Quote:*   

> $ sudo lspci |grep -i usb
> 
> 00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
> 
> 00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
> ...

 

----------

## digifuzzy

Other than ensuring you have evdev in the INPUT_DEVICE stanza in your make.conf and updating emerge, I'm kind of at a loss at what to suggest next.

----------

## Budoka

 *digifuzzy wrote:*   

> Other than ensuring you have evdev in the INPUT_DEVICE stanza in your make.conf and updating emerge, I'm kind of at a loss at what to suggest next.

 I just checked. I don't see any INPUT_DEVICE input my make.conf. Should I add INPUT_DEVICE=evdev and see if that solves it?I also assume that is a type-o and is eudev?

Also, how do I "update emerge"?

----------

## digifuzzy

See

1) Gentoo Wiki evdev

2)  Updating emerge/portage 

----------

## Budoka

 *digifuzzy wrote:*   

> Seein
> 
> 1) Gentoo Wiki evdev
> 
> 2)  Updating emerge/portage 

 

Thanks. I am sorry for the confusion. I actually thought that was what you were indicating but sometimes have language issues. It was the "update emerge" that threw me me off.

Anyway, I made the changes to make.conf and did the update. No change. The behavior is the same. 

To be certain it isn't a hardware or mouse issue I booted from both the RescueCD and another distro and the mouse doesn't behave as it does now in Gentoo. Also booted into Win7 partition and it is fine.

Any other ideas? It is really frustrating because this is just one of a number of quirky annoying things that ALL seem to have started after a world update.

I have to say I really love Gentoo but this has happened enough times that I am seriously considering dumping it. It is starting to affect productivity. I sometimes think I should just not update when my system is "stable" but then I see a host of threads on forum by those that didn't update for a long period of time and when they finally do have more breakage than if they just did so on a regular schedule.

----------

## davidm

 *Budoka wrote:*   

> 
> 
> To be certain it isn't a hardware or mouse issue I booted from both the RescueCD and another distro and the mouse doesn't behave as it does now in Gentoo. Also booted into Win7 partition and it is fine.
> 
> Any other ideas? It is really frustrating because this is just one of a number of quirky annoying things that ALL seem to have started after a world update.
> ...

 

Just as a data point about a month ago (this was on Arch Linux then)  I had a weird problem where suddenly I had to plug and unplug my mouse to get it recognized (it would freeze) seemingly at random as you sort of are describing.  Upon further investigation in one of the logs I found messages like this:

```

hub 2-1.5.1:1.0: port 2 disabled by hub (EMI?), re-enabling...

```

I noted that when using the kernel 3.17.x I had to physically unplug and then plug back in the mouse to get it to work.  However, curiously with the lts kernel (either 3.16.x or 3.14.x, I forget which one) I did not have to do this and instead for about half a second the mouse would just be unresponsive for a while.  

I found out eventually that in the LTS kernel the same error messages (although slightly different) were occuring and the difference was that in the lts kernel it was able to gracefully re-initialize without manual plugging and unplugging while in 3.17.x it would freeze without unplugging it.

Eventually I discovered the reason for this:

The mouse was faulty and there was a loose connection somewhere.  Upon bumping it I could trigger the behaviour.  The difference was that somehow the kernels handled this condition differently.

tl/dr: Don't be too sure that because it seems to work in another distro or kernel that it is not a hardware problem.  Sometimes strange things occur.

----------

## NeddySeagoon

Budoka,

Pastebin your dmesg after power up, when the device is not working.

Unplug and replug it. Take care to use the same USB port, check it works, then post the new lines in dmesg.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> Pastebin your dmesg after power up, when the device is not working.
> 
> Unplug and replug it. Take care to use the same USB port, check it works, then post the new lines in dmesg.

 

Thanks Neddy. Here they are. I diffed them as well. 

After powerup: https://bpaste.net/show/dfaccddb1933

Unplug/replug: https://bpaste.net/show/08d9df8897a1

 *Quote:*   

> # diff dmesgbroke.txt dmesgworks.txt 
> 
> 1,10d0
> 
> < [    1.181379]  sdb: sdb1
> ...

 

----------

## NeddySeagoon

Budoka,

Next time you build your kernel, maxe the dmesg buffer bigger. The first 2 sec of dmesg have been lost.

While thats interesting, its not important right now.

From the beginning.

```
[    1.197299] usb 2-1: New USB device found, idVendor=8087, idProduct=0024

[    1.197371] usb 2-1: New USB device strings: Mfr=0, Product=0, SerialNumber=0

[    1.197865] hub 2-1:1.0: USB hub found

[    1.198047] hub 2-1:1.0: 6 ports detected
```

Your USB bus 2 has a hub conneced to it.  This doesn't tell if its internal or external.

Some devices do not play nicely with hubs.

Then your mouse if found attached to the hub

```
[    1.864894] usb 2-1.2: New USB device found, idVendor=0d62, idProduct=a100

[    1.864965] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0

[    1.865036] usb 2-1.2: Product: USB Optical Mouse

[    1.865102] usb 2-1.2: Manufacturer: Darfon

[    1.890327] input: PS/2 Logitech Wheel Mouse as /devices/platform/i8042/serio1/input/input8
```

Do you have a PS/2 mouse connected too or is that your USB mouse being wronly identified?

No USB driver claims the mouse, which is a bad sign, that comes along later.

```
[    2.758155] input: Darfon USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:0D62:A100.0001/input/input9

[    2.758396] hid-generic 0003:0D62:A100.0001: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:00:1d.0-1.2/input0

[    2.758441] usbcore: registered new interface driver usbhid
```

After the replug

```
[ 2167.973409] usb 2-1.2: USB disconnect, device number 3

[ 2171.234446] usb 2-1.2: new low-speed USB device number 5 using ehci-pci

[ 2171.324012] usb 2-1.2: New USB device found, idVendor=0d62, idProduct=a100

[ 2171.324015] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0

[ 2171.324017] usb 2-1.2: Product: USB Optical Mouse

[ 2171.324018] usb 2-1.2: Manufacturer: Darfon

[ 2171.327788] input: Darfon USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:0D62:A100.0002/input/input14

[ 2171.328184] hid-generic 0003:0D62:A100.0002: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:00:1d.0-1.2/input0
```

The first time round 

```
new low-speed USB device number 5 using ehci-pci
```

is missing. 

The 

```
usbcore: registered new interface driver usbhid
```

is missing the second time as subhid is already loaded.

Where is the ehci support in your kernel, as a module or built in?

When the mouse is not working are ehci-pci and ehci-hcd loaded?

Look is lsmod before and after a replug.

----------

## krinn

I think NeddySeaggon got it  :Smile: 

with usb hid build as module:

-> found usb device

-> udev found a mouse but no hid handling

-> loading hid handling

= mouse not working.

If you unplug the mouse, now that hid handling is loaded when you replug it, udev make the hid link, and mouse works.

force hid support loading prior to detecting usb devices / prior to udev loading (include it in kernel should made it)

```
[    2.758155] input: Darfon USB Optical Mouse as /devices/pci0000:00/0000:00:1d.0/usb2/2-1/2-1.2/2-1.2:1.0/0003:0D62:A100.0001/input/input9

[    2.758396] hid-generic 0003:0D62:A100.0001: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:00:1d.0-1.2/input0

[    2.758441] usbcore: registered new interface driver usbhid <- should comes before the mouse detection

[    2.758442] usbhid: USB HID core driver

```

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> Next time you build your kernel, maxe the dmesg buffer bigger. The first 2 sec of dmesg have been lost.
> 
> While thats interesting, its not important right now.
> ...

 

Thanks for the tip. I will definitely increase the buffer next compile but can you give me an idea where it is in the kernel config? I only see this when searching for DMESG.

 *Quote:*   

>  $ zgrep DMESG /proc/config.gz 
> 
> # CONFIG_SECURITY_DMESG_RESTRICT is not set
> 
> 

 

The machine is a laptop so the hub must be internal. I need to do some homework on that though because not really sure what that means. I'm assuming since it is hardware there isn't much I can do about that? Or is there a way to get the hub to play nice?

There is no PS/2 mouse or device connected so it is being misidentified. How can I change it?

This is how my kernel is currently configured for EHCI. It looks like pci is compiled in the kernel and hcd is a module. Should they both be compiled in the kernel?

 *Quote:*   

> $ zgrep EHCI /proc/config.gz 
> 
> CONFIG_USB_EHCI_HCD=y
> 
> # CONFIG_USB_EHCI_ROOT_HUB_TT is not set
> ...

 

Thanks as always for the assistance and your patience.

----------

## Budoka

 *krinn wrote:*   

> I think NeddySeaggon got it 
> 
> with usb hid build as module:
> 
> -> found usb device
> ...

 

krinn, Thanks for the input. This is my HID stuff in the kernel. SHould I change it?

 *Quote:*   

> $ zgrep HID /proc/config.gz 
> 
> CONFIG_BT_HIDP=y
> 
> # HID support
> ...

 

----------

## Budoka

Neddy et al,

Here is my lsmod when mouse isn't functional and after unplug/re-plug. I don't see any difference but I might be missing it.

Before: https://bpaste.net/show/479cb2d90bc5

After: https://bpaste.net/show/518d9ddc2f96

----------

## NeddySeagoon

Budoka,

usbhid is listed at line 86.  There are no entries for your USB root hub drivers, so we can conclude that they are built into the kernel.

The plugging/unpluggitg your mouse didi not load any new modules the last loaded module is at the top of the output. 

Post your lspci and pastebin your kernel .config file.  I have one or two more ideas left but they are bit of a long shot.

----------

## Princess Nell

Very interested in a resolution. I have the same problem, in addition to https://forums.gentoo.org/viewtopic-t-1007844.html.

No additional modules are loaded during replug. dmes is very similar to Budoka's, except the module used is xhci_hcd. All USB_*HCI options are loaded as modules and not built into the kernel. I'm using eudev but haven't quite figured out how it fits into this.

The dmesg buffer can be increased without kernel rebuild - simply add 

```
log_buf_len=N
```

 to the kernel line in grub.conf. The genkernel default is N=15 (32k), and with dmesg output after boot some 50k, N=16 should be sufficient, making the buffer 64k.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> usbhid is listed at line 86.  There are no entries for your USB root hub drivers, so we can conclude that they are built into the kernel.
> 
> The plugging/unpluggitg your mouse didi not load any new modules the last loaded module is at the top of the output. 
> ...

 

 *Quote:*   

> # lspci
> 
> 00:00.0 Host bridge: Intel Corporation 2nd Generation Core Processor Family DRAM Controller (rev 09)
> 
> 00:01.0 PCI bridge: Intel Corporation Xeon E3-1200/2nd Generation Core Processor Family PCI Express Root Port (rev 09)
> ...

 

linux # cat .config |wgetpaste

Your paste can be seen here: https://bpaste.net/show/6d18ac0073e6

----------

## krinn

you should enable # CONFIG_USB_EHCI_ROOT_HUB_TT is not set

it won't kill you and may fix your issue.

----------

## NeddySeagoon

Budoka,

Thats interesting,

```
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04) 

00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04) 

04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller 
```

No USB 1 support, two USB 2 root hubs and a USB 3 root hub.

Your mouse is a USB1 device. 

The options 

```
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set

# CONFIG_USB_EHCI_TT_NEWSCHED is not set
```

allow USB2 root hubs to drive USB1 devices.

The USB2 root hubs have to support Transaction Translation, so as Krinn says, these options are well worth turning on even if your hardware does it another way.

We know it works eventually as dmesg says

```
new low-speed USB device number 5 using ehci-pci
```

You don't have any hardware that needs 

```
CONFIG_USB_OHCI_HCD=y

CONFIG_USB_OHCI_HCD_PCI=y

CONFIG_USB_OHCI_HCD_PLATFORM=y

CONFIG_USB_UHCI_HCD=y
```

UHCI is for Intel/VIA USB1 root hubs, OHCI is for all the other USB1 root hubs in the world.

Either turn those options off or make them as modules.

You have both USB2 and USB3 support built in.  

```
CONFIG_USB_XHCI_HCD=y

CONFIG_USB_EHCI_HCD=y
```

This is mostly harmless but some systems are really picky about the USB2 and 3 module load order. 

As you are not using your USB3 yet, you could turn off USB3 support and see what happens?

USB3 supports both USB1 and USB2 too.  Does the mouse work if you connect it to a USB3 root hub?

----------

## Budoka

 *Princess Nell wrote:*   

> Very interested in a resolution. I have the same problem, in addition to https://forums.gentoo.org/viewtopic-t-1007844.html.
> 
> No additional modules are loaded during replug. dmes is very similar to Budoka's, except the module used is xhci_hcd. All USB_*HCI options are loaded as modules and not built into the kernel. I'm using eudev but haven't quite figured out how it fits into this.
> 
> The dmesg buffer can be increased without kernel rebuild - simply add 
> ...

 

Princess, Thanks for the buffer tip.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> Thats interesting,
> 
> ```
> ...

 

OK so I have made the requested kernel changes except for the one dealing with USB3. I am a little confused about that one because the mouse is plugged into the USB3 port not the USB2 so I assumed it was being used. Would that not not the case?

Still no change in behavior.

Part of my confusion is that although these kernel changes are necessary why did it work before? I haven't made any changes to my kernel config recently.

Anyway, still banging my head against a wall. Any other suggestions? I was half thinking about buying a new mouse and seeing if it works but would like to wait since at least one other person is having the same problem, same kernel, occurring the same time...that is using a new mouse albeit wireless.

----------

## NeddySeagoon

Budoka,

You posted 

```
$ sudo lsusb

Bus 002 Device 010: ID 8086:0189 Intel Corp.

Bus 002 Device 013: ID 0d62:a100 Darfon Electronics Corp. Optical Mouse

Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 002 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub

Bus 001 Device 003: ID 2232:1018 Silicon Motion

Bus 001 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub 
```

Which shows your mouse plugged into Bus 002, which has a 

```
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
```

This is supported by your dmesg 

```
[    1.864894] usb 2-1.2: New USB device found, idVendor=0d62, idProduct=a100

[    1.864965] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0

[    1.865036] usb 2-1.2: Product: USB Optical Mouse

[    1.865102] usb 2-1.2: Manufacturer: Darfon 
```

which also shows  the mouse on bus 2.

Your USB3 is Bus 4 but your ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller also provides a USB2 hub as Bus 3 too.

Thats the two entries 

```
Bus 004 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub

Bus 003 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
```

Either you are mistaken, or you have moved the mouse off of USB Bus 2.

If you remove the USB3 driver from the kernel, your USB bus 4 won't work but the above lsusb shows its not used anyway.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> You posted 
> 
> ```
> ...

 

Thanks Neddy. I guess I was confused. This is my laptop. http://www.samsung.com/us/computer/laptops/NP700Z5B-S01UB-specs

I have 3 USB ports. 2 on the left side of the box and 1 on the right side. My understanding was that the 2 ports on the left were "regular" USB2 slots and that the 1 on the right was a "high speed" USB3 slot.

I only plug the mouse into what I thought was the USB3 port on the right side of the box.

So was I mistaken or are the ports being misread by something I did or did not do in the kernel? I am quite confused now.

Thanks again and I really appreciate your help.

I'll remove usb3 driver and see what happens.

----------

## NeddySeagoon

Budoka,

Plug your mouse into eacd USB port in turn, then run lsusb.  That will show which port is which USB Bus.

Post the output.

I suspect that not all of your USB busses are brought out.  The card reader ad the webcam are likely to be USB, even if they are internal devices. 

Its not quite that simple as its possible that your USB3 port is connected to the USB 2 port on the ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller.

To test that you will need a USB 2 and a USB 3 device to connect to the USB3 port alternately and see if they appear on different USB busses. 

Your link says you have two USB3 ports and one USB2 port.

Two ports usually make a single USB root hub.  On a desktop, thats a stacked pair of USB connectors.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> Plug your mouse into eacd USB port in turn, then run lsusb.  That will show which port is which USB Bus.
> 
> Post the output.
> ...

 

OK the story is getting better but at least I feel like I am making progress.

I removed USB3 from the kernel. Now when I power-up the mouse works for about 20 seconds on the login (KDM/XDM) screen and then goes dead again. After that the behavior is the same as before. Unplug/Replug all good. To make sure it isn't an anomaly I powered down and started up again 5 times. It happens every time.

Plugged in mouse in sequence and checked lsusb. First thing I noticed is that the 2 ports on the left of the box are totally dead so can only assume that they are USB3 or at least affected by that driver because that is the only change I made to the kernel.

 *Quote:*   

> # cat NoUSBDevices.txt 
> 
> Bus 002 Device 004: ID 8086:0189 Intel Corp. 
> 
> Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub
> ...

 

I see that the one port that it worked on showed  *Quote:*   

> Bus 002 Device 006: ID 0d62:a100 Darfon Electronics Corp. Optical Mouse

  added. So it is Bus 002 but not sure what to do with that info.

Card reader and webcam are indeed internal.

I will wait to re-enable usb3 for the two other ports until I get additional feedback from you guys.

Thanks

----------

## NeddySeagoon

Budoka,

OK, lets play with the module load order.

Make both the USB2 and USB3 drivers as modules.

Find the modules in /lib/modules/'uname -r'/ ... and change the *.ko file names, so that they do not auto load.

Module blacklisting probably works too.

Reboot into the new kernel.

Now you will have no mouse suppert and replugging won't fix it.  Please test that.

Plug the mouse into Bus 2.

Rename the ehci-hcd module correctly, then modprobe it.  The mouse should begin to work.

Rename the xhci-hcd module correctly, then modprobe it.  The mouse should still work.

Rename the xhci-hcd module incorrectly and reboot.  Does the mouse just work now?

Rename the xhci-hcd module correctly and rename the ehci-hcd module incorrectly.

Plug the mouse into a USB3 port

Reboot.

What happens to the mouse now?

If its all good so far, name the modules correctly, so they both load. Plug the mouse into Bus 2 aging and reboot.

What we are trying to test is the effect of the module load order on mouse operation.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> OK, lets play with the module load order.
> 
> Make both the USB2 and USB3 drivers as modules.
> ...

 

Thanks Neddy. I've run into a slight snag most likely due to something I am doing incorrectly.

I changed the kernel options for USB2 and USB3 to module.

 *Quote:*   

> CONFIG_USB_XHCI_HCD=m
> 
> CONFIG_USB_EHCI_HCD=m
> 
> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> ...

  Entire output can be seen here: $ zgrep USB /proc/config.gz |wgetpaste

Your paste can be seen here: https://bpaste.net/show/158e4fef6f09

I could only find the .ko files you referenced deeper in the directory. Specifically at  *Quote:*   

> /lib/modules/3.17.7-gentoo/kernel/drivers/usb/host 

  which contains  *Quote:*   

> $ ls
> 
> ehci-hcd.ko.bak  ehci-pci.ko  ehci-platform.ko  isp116x-hcd.ko  r8a66597-hcd.ko  sl811_cs.ko  sl811-hcd.ko  ssb-hcd.ko  u132-hcd.ko  xhci-hcd.ko.bak

 

I renamed ehci-hcd.ko and xhci-hcd.ko by appending .bak and rebooted.

However my mouse still works if I unplug/replug when it shouldn't. Am I renaming the wrong files? There aren't any .ko's at  /lib/modules/'uname -r'/

Thanks and once again I appreciate your patience.

----------

## NeddySeagoon

Budoka,

Your USB is using some other driver then.  That may be the problem, since two drivers loaded for the same hardwarre usually doesn't work.

dmesg will show what in going on.  Please put it onto a pastebin.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> Your USB is using some other driver then.  That may be the problem, since two drivers loaded for the same hardwarre usually doesn't work.
> 
> dmesg will show what in going on.  Please put it onto a pastebin.

 

$ dmesg |wgetpaste

Your paste can be seen here:https://bpaste.net/show/4b82b0232aaf

I'm trying to decipher this stuff on my own as well. Am I correct that dmesg is indicating that ehci and xhci are being picked up from someplace else?

 *Quote:*   

> [  119.698647] usb 2-1.2: USB disconnect, device number 5
> 
> [  123.237975] usb 3-1: new low-speed USB device number 2 using xhci_hcd
> 
> [  123.446643] usb 3-1: New USB device found, idVendor=0d62, idProduct=a100
> ...

 

Thanks as always.

----------

## NeddySeagoon

Budoka,

```
[ 123.237975] usb 3-1: new low-speed USB device number 2 using xhci_hcd 
```

shows that xhci_hcd (USB3) is still present.

```
[ 136.797718] usb 2-1.2: new low-speed USB device number 6 using ehci-pci 
```

This shows that ehci-pci is in use, not ehci-hcd, which was nte module I asked you to rename.

So yes, xhci_hcd (USB3) is still there.  This can happen if you messed up installing the kernel lo boot.

The old kernel has xhci_hcd built in, the new one has it as a module, or you would not have found xhci_hcd.ko to rename.

Look at the output of 

```
uname -a
```

Linux NeddySeagoon_Static 3.18.0-gentoo #1 SMP PREEMPT Sat Dec 20 13:52:25 GMT 2014 x86_64 AMD Phenom(tm) II X6 1090T Processor AuthenticAMD GNU/Linux

The date and time Sat Dec 20 13:52:25 GMT 2014 are the build date and time of the runnitg kernel.  Does your build time look correct? 

Also, the build number, here  #1, in incremented every build.

--- edit ---

Another inconsistancy can be detected in lsmod.  If USB3 works and xhci-hcd is not listed, you are running the old kernel with the new kernels modules.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> ```
> [ 123.237975] usb 3-1: new low-speed USB device number 2 using xhci_hcd 
> ```
> ...

 

uname -a looks fine to me as far as date and time.

 *Quote:*   

> Linux TL_Samsung 3.17.7-gentoo #1 SMP Sun Jan 18 04:14:50 JST 2015 x86_64 Intel(R) Core(TM) i7-2675QM CPU @ 2.20GHz GenuineIntel GNU/Linux
> 
> 

 

$ lsmod |wgetpaste

Your paste can be seen here: https://bpaste.net/show/bf14758388a1

I triple checked my kernel to make sure I changed usb2 and usb3 to module.

I don't see xhci-hcd in lsmod and mouse is working. But I am not clear about the old kernel/new modules bit. 3.17.7 is the newest kernel on my box.

Should I change  *Quote:*   

> CONFIG_USB_EHCI_ROOT_HUB_TT=y
> 
> CONFIG_USB_EHCI_TT_NEWSCHED=y 

 to module as well?

----------

## NeddySeagoon

Budoka,

```
xhci_hcd               88905  0 
```

is in lsmod, at line 82.

That shows your kernel and modules are correct ... but how did it load?

If you 

```
modprobe -r xhci_hcd  
```

your mouse will not work on USB3.

```
CONFIG_USB_EHCI_ROOT_HUB_TT=y

CONFIG_USB_EHCI_TT_NEWSCHED=y 
```

cannot be set as modules.  They are options for the EHCI USB2 driver and can only be on or off.

The code they control is built into EHCI_HCD, whicdh you don't seem te be using.  

Your USB2 uses the ehci-pci driver.

Its ehci-pci and xhci_hcd that we need to test.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> ```
> xhci_hcd               88905  0 
> ```
> ...

 

OK. I understand. I'll try to sort it out and write back again shortly.

----------

## Budoka

 *NeddySeagoon wrote:*   

> Budoka,
> 
> ```
> xhci_hcd               88905  0 
> ```
> ...

 

OK. I am absolutely stumped. Some driver somewhere is loading but I can't figure what or how.

I see a number of threads now with others having USB problems on the same kernel all occurring about the same time and at least one confirming that it happened after a world update. 

eg: https://forums.gentoo.org/viewtopic-t-1008746-highlight-.html, https://forums.gentoo.org/viewtopic-t-1007844-highlight-.html

So kernel stuff aside, it leads me to believe that SOMETHING came down and borked it. eudev? Power management? I haven't any idea and am frustrated because not sure how to continue trouble shooting this. Everything up until now has been kernel related and I hadn't changed my kernel config at all for sometime and it worked just fine.

Here is some additional information since last post. May be related or not.

If I take my laptop off of AC power and run on battery the mouse will continue to work. When I plug it back into AC power the mouse dies forcing me to unplug/replug. This problem, https://forums.gentoo.org/viewtopic-t-1006074-highlight-.html, started at the exact same time as the USB issue and after the same world update. Could they be related?

Could it be 

```
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
```

 that is loading it?

 *Quote:*   

> grep '[XEOU]HCI' /usr/src/linux/.config 
> 
> CONFIG_USB_OHCI_LITTLE_ENDIAN=y
> 
> CONFIG_USB_XHCI_HCD=m
> ...

 

Can also say with 98 percent certainty it isn't a hardware failure. Windows partition works just fine and in addition to RescueCD I have tried two other distros via CD and USB and the behavior is not there.

----------

## jezaustin

 *Quote:*   

> If I take my laptop off of AC power and run on battery the mouse will continue to work. When I plug it back into AC power the mouse dies forcing me to unplug/replug.

 

sounds like udev rules. Looking for packages that may have changed them, I tried:

```
$ for f in `grep -il power /lib/udev/rules.d/*`; do equery b $f; done

 * Searching for /lib/udev/rules.d/42-usb-hid-pm.rules ...

sys-fs/udev-216 (/lib/udev/rules.d/42-usb-hid-pm.rules)

 * Searching for /lib/udev/rules.d/77-mm-usb-device-blacklist.rules ... 

net-misc/modemmanager-1.4.0 (/lib/udev/rules.d/77-mm-usb-device-blacklist.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-dell.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-dell.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-fujitsu.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-gateway.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-gateway.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-ibm.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-ibm.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-lenovo.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-lenovo.rules)

 * Searching for /lib/udev/rules.d/95-upower-battery-recall-toshiba.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-battery-recall-toshiba.rules)

 * Searching for /lib/udev/rules.d/95-upower-csr.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-csr.rules)

 * Searching for /lib/udev/rules.d/95-upower-hid.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-hid.rules)

 * Searching for /lib/udev/rules.d/95-upower-wup.rules ... 

sys-power/upower-pm-utils-0.9.23-r2 (/lib/udev/rules.d/95-upower-wup.rules)

 * Searching for /lib/udev/rules.d/97-hid2hci.rules ... 

net-wireless/bluez-5.25 (/lib/udev/rules.d/97-hid2hci.rules)

 * Searching for /lib/udev/rules.d/99-laptop-mode.rules ... 

app-laptop/laptop-mode-tools-1.66 (/lib/udev/rules.d/99-laptop-mode.rules)
```

Of those files, 77-mm-usb-device-blacklist.rules, 97-hid2hci.ruls and 99-laptop-mode.rules were most recently changed, so I'd be investigating net-misc/modemmanager, net-wireless/bluez and app-laptop/laptop-mode-tools. But try it on your own system, obviously.  :Wink: 

However, I wouldn't worry about it being a kernel-based fix to a problem triggered by a user-land change. It looks like your problem (and mine, I suspect) arose from the USB module loading order, and although a user-land change may have altered the boot process in this way, it seems unreasonable to make every package worry about things like module loading order; kernel config would be a better place to defend against this kind of thing.

Jez.

----------

## Budoka

 *jezaustin wrote:*   

>  *Quote:*   If I take my laptop off of AC power and run on battery the mouse will continue to work. When I plug it back into AC power the mouse dies forcing me to unplug/replug. 
> 
> sounds like udev rules. Looking for packages that may have changed them, I tried:
> 
> ```
> ...

 

 *Quote:*   

> $ for f in `grep -il power /lib/udev/rules.d/*`; do equery b $f; done
> 
>  * Searching for /lib/udev/rules.d/42-usb-hid-pm.rules ... 
> 
> sys-fs/eudev-1.10-r2 (/lib/udev/rules.d/42-usb-hid-pm.rules)
> ...

 

Thanks. So I am looking at app-laptop/laptop-mode-tools-1.66 , net-wireless/bluez-5.25, and sys-power/upower-pm-utils-0.9.23-r2? I guess sys-power/upower-pm-utils-0.9.23-r2 would be the most likely culprit right?

So are you saying I now have to start manually configuring udev rules??? I have NEVER had to do that before!!! 

Reading through UDEV Wiki now but really not sure what is suppose to be populating these.

These are the non battery recall udev rules as best I can tell:

$ cat /lib/udev/rules.d/99-laptop-mode.rules |wgetpaste

Your paste can be seen here: https://bpaste.net/show/fd20ca0b4091

$ cat /lib/udev/rules.d/97-hid2hci.rules |wgetpaste

Your paste can be seen here: https://bpaste.net/show/a55867ea17c7

$ cat /lib/udev/rules.d/95-upower-wup.rules |wgetpaste

Your paste can be seen here: https://bpaste.net/show/8506ac24e808

$ cat /lib/udev/rules.d/95-upower-hid.rules |wgetpaste

Your paste can be seen here: https://bpaste.net/show/e0f1e1554828

$ cat /lib/udev/rules.d/95-upower-csr.rules |wgetpaste

Your paste can be seen here: https://bpaste.net/show/1eadbbc22d0a

I see some references in here to mouse stuff but really don't know what it is SUPPOSE to be.

 *Quote:*   

> $ cat /lib/udev/rules.d/97-hid2hci.rules 
> 
> # do not edit this file, it will be overwritten on update
> 
> ACTION=="remove", GOTO="hid2hci_end"
> ...

 

----------

## Princess Nell

Removal of laptop-mode-tools solves it for me. So, some change between 1.64 and 1.66 triggers this behaviour. I didn't suspect at first because, as I said in https://forums.gentoo.org/viewtopic-t-1007844.html, USB autosuspend is disabled by default. That's actually documented in the ChangeLog:

```

  30 Aug 2014; Alon Bar-Lev <alonbl@gentoo.org>

  +files/laptop-mode-tools-1.65-usb-autosuspend.patch,

  +laptop-mode-tools-1.65-r1.ebuild:

  Disable usb-autosuspend per default, use newer runtime-pm withi udev,

  bug#520124, thanks to  Ted Tanberry

```

----------

## Princess Nell

Back on laptop-mode-tools ... here's the solution. Problem has been known (https://forums.gentoo.org/viewtopic-t-994070.html) and solved (https://bugs.gentoo.org/show_bug.cgi?id=520124) for a while, but the ebuild should really warn about this IMHO.

The usb-autosuspend module is now deprecated and the functionality moved to runtime-pm. If you have a file /etc/laptop-mode/conf.d/usb-autosuspend.conf, remove it. Secondly, if you have problems with particular devices, simply blacklist them to avoid autosuspend. In my case, I changed /etc/laptop-mode/conf.d/runtime-pm.conf like this:

```

# The list of device driver types that should not use autosuspend.  The driver

# type is given by "DRIVER=..." in a device's uevent file.

# Example: AUTOSUSPEND_DEVID_BLACKLIST="usbhid usb-storage"

AUTOSUSPEND_RUNTIME_DEVTYPE_BLACKLIST="usbhid"

```

Note that this depends on the value of AUTOSUSPEND_USE_WHITELIST (default 0 is fine).

@NeddySeagoon, thanks for the excellent debug guide. My .config is probably a little bit more consistent now  :Smile: 

References: http://mailman.samwel.tk/pipermail/laptop-mode/2014-June/000726.html, http://mailman.samwel.tk/pipermail/laptop-mode/2014-July/000727.html, http://mailman.samwel.tk/pipermail/laptop-mode/2014-July/000728.html.

----------

## Budoka

 *Princess Nell wrote:*   

> Removal of laptop-mode-tools solves it for me. So, some change between 1.64 and 1.66 triggers this behaviour. I didn't suspect at first because, as I said in https://forums.gentoo.org/viewtopic-t-1007844.html, USB autosuspend is disabled by default. That's actually documented in the ChangeLog:
> 
> ```
> 
>   30 Aug 2014; Alon Bar-Lev <alonbl@gentoo.org>
> ...

 

Wow! OK. So I rolled back to laptop-mode-tools 1.64 and now the quirky USB behavior is gone. I didn't want to remove it totally because since I am running a laptop assume I need it.

Anyway, you clearly nailed the cause of the problem on the head. A little frustrating because I would have never been able to figure that out on my own. So is this a configuration issue or a bug in laptop-mode-tools-1.66 that should be filed?

As to the kernel...what is the best way for it to be configured? Should I leave the USB stuff as modules.  I was instructed to change it to such to troubleshoot the problem. Or is it safe/advisable to revert to compiling it in the kernel as before?

I've learned a lot in this thread but must confess it is all fuzzy to me.

Maybe I should ask this in a separate thread but is there a way to rollback from a previous state after a world update? This has happened to me enough times now that I am starting to think it is par the course.

----------

## Budoka

 *Princess Nell wrote:*   

> Back on laptop-mode-tools ... here's the solution. Problem has been known (https://forums.gentoo.org/viewtopic-t-994070.html) and solved (https://bugs.gentoo.org/show_bug.cgi?id=520124) for a while, but the ebuild should really warn about this IMHO.
> 
> The usb-autosuspend module is now deprecated and the functionality moved to runtime-pm. If you have a file /etc/laptop-mode/conf.d/usb-autosuspend.conf, remove it. Secondly, if you have problems with particular devices, simply blacklist them to avoid autosuspend. In my case, I changed /etc/laptop-mode/conf.d/runtime-pm.conf like this:
> 
> ```
> ...

 

We were posting the same time. I'll read the links you posted and see if I can understand better. Thank you everyone. This forum really is fantastic.

----------

## Budoka

Should I add laptop-mode-tools 1.64 to my accept keywords file? Will that freeze it at that version?

----------

## Princess Nell

That should not be required. Just follow the instructions in my previous posting to get 1.65 and newer to work.

This is just a configuration issue. The ebuild could have warned, I don't read the upstream ChangeLog for everything I emerge.

----------

## Budoka

 *Princess Nell wrote:*   

> That should not be required. Just follow the instructions in my previous posting to get 1.65 and newer to work.
> 
> This is just a configuration issue. The ebuild could have warned, I don't read the upstream ChangeLog for everything I emerge.

 

OK. I'll give it a shot and get back to everyone. Thanks.

----------

## Budoka

 *davidtran wrote:*   

> My laptop had this problem three months ago. The mouse could not connect and be recognized, so I checked the motherboard to make sure that the USB HUD and other components were fine and then, I re-installed the OS. Finally, the problem was solved. Therefore, I think you should check both your mouse and your motherboard.

 

Thanks. It is 99 percent certain it is not a hardware issue. Princess Nell was able to pin down what the cause was. Take a look at the links she posted in this thread.

As a side note, you really shouldn't ever have to re-install the OS. Generally problems can be sorted out on the forum without such a drastic action.

----------

## khayyam

 *Budoka wrote:*   

>  *davidtran wrote:*   My laptop had this problem three months ago. The mouse could not connect and be recognized, so I checked the motherboard to make sure that the USB HUD and other components were fine and then, I re-installed the OS. Finally, the problem was solved. Therefore, I think you should check both your mouse and your motherboard. 
> 
> Thanks. It is 99 percent certain it is not a hardware issue. Princess Nell was able to pin down what the cause was. Take a look at the links she posted in this thread. As a side note, you really shouldn't ever have to re-install the OS. Generally problems can be sorted out on the forum without such a drastic action.

 

Budoka ... you don't think it's odd that someone would sign up to provide such a generic answer to your most specific question/problem? How would you go about "checking your USB HUD [sic]"? What might the "OS" be here? By all accounts re-installing it "solved" the issue.

Sometimes you have to be suspicious about "the first post", the above triggers alarm bells suggesting that the account was created in order to spam (at a later date they can come back and 'edit' the post adding links or what-have-you). The above is just a technique to get them under the radar ... and a very good try it was too ... however, I reported it already this afternoon.

hello david, are you with us?

best ... khay

----------

## Budoka

 *khayyam wrote:*   

>  *Budoka wrote:*    *davidtran wrote:*   My laptop had this problem three months ago. The mouse could not connect and be recognized, so I checked the motherboard to make sure that the USB HUD and other components were fine and then, I re-installed the OS. Finally, the problem was solved. Therefore, I think you should check both your mouse and your motherboard. 
> 
> Thanks. It is 99 percent certain it is not a hardware issue. Princess Nell was able to pin down what the cause was. Take a look at the links she posted in this thread. As a side note, you really shouldn't ever have to re-install the OS. Generally problems can be sorted out on the forum without such a drastic action. 
> 
> Budoka ... you don't think it's odd that someone would sign up to provide such a generic answer to your most specific question/problem? How would you go about "checking your USB HUD [sic]"? What might the "OS" be here? By all accounts re-installing it "solved" the issue.
> ...

 

OH!!! I see what you are saying khay about first post. I'm sorry my bad!!! I'll be more cautious in the future. Should I delete my reply to clean up the thread?

----------

## khayyam

 *Budoka wrote:*   

> OH!!! I see what you are saying khay about first post. I'm sorry my bad!!! I'll be more cautious in the future. Should I delete my reply to clean up the thread?

 

Budoka ... sometimes they are easy to detect, but it seems that recently they actually have a real live human on the other end, so more difficult. I wouldn't worry about it ... I just wanted to clue you in to whats happening.

best ... khay

----------

