Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
USB mouse must first be unplugged to be recognized. [SOLVED]
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3  Next  
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
Princess Nell
l33t
l33t


Joined: 15 Apr 2005
Posts: 768

PostPosted: Wed Jan 14, 2015 11:57 pm    Post subject: Reply with quote

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
Code:
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.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Thu Jan 15, 2015 4:38 pm    Post subject: Reply with quote

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.

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.


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)
00:02.0 VGA compatible controller: Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller (rev 09)
00:16.0 Communication controller: Intel Corporation 6 Series/C200 Series Chipset Family MEI Controller #1 (rev 04)
00:1a.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #2 (rev 04)
00:1b.0 Audio device: Intel Corporation 6 Series/C200 Series Chipset Family High Definition Audio Controller (rev 04)
00:1c.0 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 1 (rev b4)
00:1c.3 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 4 (rev b4)
00:1c.4 PCI bridge: Intel Corporation 6 Series/C200 Series Chipset Family PCI Express Root Port 5 (rev b4)
00:1d.0 USB controller: Intel Corporation 6 Series/C200 Series Chipset Family USB Enhanced Host Controller #1 (rev 04)
00:1f.0 ISA bridge: Intel Corporation HM65 Express Chipset Family LPC Controller (rev 04)
00:1f.2 SATA controller: Intel Corporation 6 Series/C200 Series Chipset Family 6 port SATA AHCI Controller (rev 04)
00:1f.3 SMBus: Intel Corporation 6 Series/C200 Series Chipset Family SMBus Controller (rev 04)
01:00.0 VGA compatible controller: Advanced Micro Devices, Inc. [AMD/ATI] Seymour [Radeon HD 6400M/7400M Series] (rev ff)
02:00.0 Network controller: Intel Corporation Centrino Advanced-N 6230 [Rainbow Peak] (rev 34)
03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06)
04:00.0 USB controller: ASMedia Technology Inc. ASM1042 SuperSpeed USB Host Controller



linux # cat .config |wgetpaste
Your paste can be seen here: https://bpaste.net/show/6d18ac0073e6
Back to top
View user's profile Send private message
krinn
Watchman
Watchman


Joined: 02 May 2003
Posts: 7197

PostPosted: Thu Jan 15, 2015 5:36 pm    Post subject: Reply with quote

you should enable # CONFIG_USB_EHCI_ROOT_HUB_TT is not set
it won't kill you and may fix your issue.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Thu Jan 15, 2015 7:12 pm    Post subject: Reply with quote

Budoka,

Thats interesting,
Code:
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
Code:
# 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
Code:
new low-speed USB device number 5 using ehci-pci


You don't have any hardware that needs
Code:
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.
Code:
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?
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 16, 2015 3:32 pm    Post subject: Reply with quote

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
Code:
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.


Princess, Thanks for the buffer tip.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 16, 2015 3:37 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Budoka,

Thats interesting,
Code:
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
Code:
# 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
Code:
new low-speed USB device number 5 using ehci-pci


You don't have any hardware that needs
Code:
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.
Code:
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?


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.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Fri Jan 16, 2015 8:22 pm    Post subject: Reply with quote

Budoka,

You posted
Code:
$ 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
Code:
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

This is supported by your dmesg
Code:
[    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
Code:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 16, 2015 8:37 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Budoka,

You posted
Code:
$ 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
Code:
Bus 002 Device 002: ID 8087:0024 Intel Corp. Integrated Rate Matching Hub

This is supported by your dmesg
Code:
[    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
Code:
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.


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.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Fri Jan 16, 2015 8:51 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 16, 2015 9:31 pm    Post subject: Reply with quote

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.
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.


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
Bus 002 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

# cat RightUSBMouse.txt
Bus 002 Device 004: ID 8086:0189 Intel Corp.
Bus 002 Device 006: 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 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

# cat LeftBackUSBMouse.txt
Bus 002 Device 004: ID 8086:0189 Intel Corp.
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 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

# cat LeftFrontUSBMouse.txt
Bus 002 Device 004: ID 8086:0189 Intel Corp.
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 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


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
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Fri Jan 16, 2015 10:04 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sat Jan 17, 2015 8:20 pm    Post subject: Reply with quote

NeddySeagoon wrote:
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.


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
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
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.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Sat Jan 17, 2015 8:35 pm    Post subject: Reply with quote

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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sat Jan 17, 2015 8:37 pm    Post subject: Reply with quote

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
[ 123.446647] usb 3-1: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 123.446649] usb 3-1: Product: USB Optical Mouse
[ 123.446650] usb 3-1: Manufacturer: Darfon
[ 123.446818] usb 3-1: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 123.451033] 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.0003/input/input15
[ 123.451221] hid-generic 0003:0D62:A100.0003: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:04:00.0-1/input0
[ 127.198272] usb 3-1: USB disconnect, device number 2
[ 129.207079] usb 3-2: new low-speed USB device number 3 using xhci_hcd
[ 129.416198] usb 3-2: New USB device found, idVendor=0d62, idProduct=a100
[ 129.416202] usb 3-2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 129.416204] usb 3-2: Product: USB Optical Mouse
[ 129.416206] usb 3-2: Manufacturer: Darfon
[ 129.416439] usb 3-2: ep 0x81 - rounding interval to 64 microframes, ep desc says 80 microframes
[ 129.420734] input: Darfon USB Optical Mouse as /devices/pci0000:00/0000:00:1c.4/0000:04:00.0/usb3/3-2/3-2:1.0/0003:0D62:A100.0004/input/input16
[ 129.421110] hid-generic 0003:0D62:A100.0004: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:04:00.0-2/input0
[ 133.485816] usb 3-2: USB disconnect, device number 3
[ 136.797718] usb 2-1.2: new low-speed USB device number 6 using ehci-pci
[ 136.887061] usb 2-1.2: New USB device found, idVendor=0d62, idProduct=a100
[ 136.887064] usb 2-1.2: New USB device strings: Mfr=2, Product=1, SerialNumber=0
[ 136.887066] usb 2-1.2: Product: USB Optical Mouse
[ 136.887068] usb 2-1.2: Manufacturer: Darfon
[ 136.890632] 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.0005/input/input17
[ 136.890854] hid-generic 0003:0D62:A100.0005: input,hidraw0: USB HID v1.10 Mouse [Darfon USB Optical Mouse] on usb-0000:00:1d.0-1.2/input0


Thanks as always.
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Sat Jan 17, 2015 10:32 pm    Post subject: Reply with quote

Budoka,

Code:
[ 123.237975] usb 3-1: new low-speed USB device number 2 using xhci_hcd
shows that xhci_hcd (USB3) is still present.

Code:
[ 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
Code:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sat Jan 17, 2015 10:53 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Budoka,

Code:
[ 123.237975] usb 3-1: new low-speed USB device number 2 using xhci_hcd
shows that xhci_hcd (USB3) is still present.

Code:
[ 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
Code:
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.


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?
Back to top
View user's profile Send private message
NeddySeagoon
Administrator
Administrator


Joined: 05 Jul 2003
Posts: 44178
Location: 56N 3W

PostPosted: Sat Jan 17, 2015 11:11 pm    Post subject: Reply with quote

Budoka,

Code:
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
Code:
modprobe -r xhci_hcd 
your mouse will not work on USB3.

Code:
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.
_________________
Regards,

NeddySeagoon

Computer users fall into two groups:-
those that do backups
those that have never had a hard drive fail.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sun Jan 18, 2015 5:58 pm    Post subject: Reply with quote

NeddySeagoon wrote:
Budoka,

Code:
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
Code:
modprobe -r xhci_hcd 
your mouse will not work on USB3.

Code:
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.


OK. I understand. I'll try to sort it out and write back again shortly.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 23, 2015 2:21 am    Post subject: Reply with quote

NeddySeagoon wrote:
Budoka,

Code:
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
Code:
modprobe -r xhci_hcd 
your mouse will not work on USB3.

Code:
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.


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
Code:
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
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
CONFIG_USB_EHCI_PCI=m
CONFIG_USB_EHCI_HCD_PLATFORM=m
# CONFIG_USB_OHCI_HCD is not set
# CONFIG_USB_UHCI_HCD is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set


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.
Back to top
View user's profile Send private message
jezaustin
Tux's lil' helper
Tux's lil' helper


Joined: 22 Sep 2006
Posts: 96
Location: england

PostPosted: Fri Jan 23, 2015 10:05 am    Post subject: Reply with quote

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:
Code:
$ 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. ;)

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.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Fri Jan 23, 2015 5:32 pm    Post subject: Reply with quote

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:
Code:
$ 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. ;)

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.




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)
* 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)


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"
SUBSYSTEM!="usb*", GOTO="hid2hci_end"

# Variety of Dell Bluetooth devices - match on a mouse device that is
# self powered and where a HID report needs to be sent to switch modes
# Known supported devices: 413c:8154, 413c:8158, 413c:8162
ATTR{bInterfaceClass}=="03", ATTR{bInterfaceSubClass}=="01", ATTR{bInterfaceProtocol}=="02", \
ATTRS{bDeviceClass}=="00", ATTRS{idVendor}=="413c", ATTRS{bmAttributes}=="e0", \
RUN+="hid2hci --method=dell --devpath=%p", ENV{HID2HCI_SWITCH}="1"

# Logitech devices
KERNEL=="hiddev*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[5e]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"
# Logitech, Inc. RAW communicating devices
KERNEL=="hidraw*", ATTRS{idVendor}=="046d", ATTRS{idProduct}=="c70[34abc]|c71[34bc]", \
RUN+="hid2hci --method=logitech-hid --devpath=%p"

ENV{DEVTYPE}!="usb_device", GOTO="hid2hci_end"

# When a Dell device recovers from S3, the mouse child needs to be repoked
# Unfortunately the only event seen is the BT device disappearing, so the mouse
# device needs to be chased down on the USB bus.
ATTR{bDeviceClass}=="e0", ATTR{bDeviceSubClass}=="01", ATTR{bDeviceProtocol}=="01", ATTR{idVendor}=="413c", \
ENV{REMOVE_CMD}="/sbin/udevadm trigger --action=change --subsystem-match=usb --property-match=HID2HCI_SWITCH=1"

# CSR devices
ATTR{idVendor}=="0a12|0458|05ac", ATTR{idProduct}=="1000", RUN+="hid2hci --method=csr --devpath=%p"

LABEL="hid2hci_end"
Back to top
View user's profile Send private message
Princess Nell
l33t
l33t


Joined: 15 Apr 2005
Posts: 768

PostPosted: Fri Jan 23, 2015 10:51 pm    Post subject: Reply with quote

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:
Code:

  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
Back to top
View user's profile Send private message
Princess Nell
l33t
l33t


Joined: 15 Apr 2005
Posts: 768

PostPosted: Sat Jan 24, 2015 12:09 am    Post subject: Reply with quote

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:
Code:

# 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 :)

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.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sat Jan 24, 2015 12:28 am    Post subject: Reply with quote

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:
Code:

  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


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.
Back to top
View user's profile Send private message
Budoka
l33t
l33t


Joined: 03 Jun 2012
Posts: 693
Location: Tokyo, Japan

PostPosted: Sat Jan 24, 2015 12:33 am    Post subject: Reply with quote

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:
Code:

# 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 :)

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.


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.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Goto page Previous  1, 2, 3  Next
Page 2 of 3

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum