Disabling IRQ #18 error message and non-working USB ports

I have a ThinkPad X120e installed with opensuse 11.4 kernel 2.6.37.6-0.11-desktop.

The USB ports stop working correctly after I suspend to RAM, resume, suspend to disk
(hibernate) and resume again. In the terminals I get the error message:

Message from syslog …
kernel: 529.928653] Disabling IRQ #18

If I switch with Ctrl-Alt-F10 I see in the resume log:

irq 18: nobody cared (try booting with the “irqpoll” option)
Pid: 12154, comm: startproc Tainted: P 2.6.37.6-0.11-desktop #1
Call Trace:

handlers
(usb_hcd_irq+0x0/0x70)
Disabling IRQ #18

By not working correctly, I mean that USB flash drives still work and I can read and
write data to/from them. However, other devices that require power, like a USB mouse
or a USB remote control do not work. They all work fine after a fresh reboot. The problem
only occurs if I suspend to RAM, thaw, then hibernate and then resume. I can hibernate and
resume as many times as I want, but if I suspend to RAM only once and then hibernate,
then after resuming the error message appears and the USB ports do not work correctly.
Also, right before the error message appears, I hear a little “click” sound coming from the
laptop as if something was turned off.

Thanks!

I don’t have a definite solution to this, and a bug report may be required.

FWIW, your problem reads similar to this thread:

http://forums.opensuse.org/english/get-technical-help-here/hardware/467080-wacom-devices-lost-after-resume-11-4-a.html

You might try adding a simple text file in /etc/pm/config.d/

SUSPEND_MODULES="uhci_hcd"
  • Uoi may want to see what *_hcd modules you have loaded (if any) with
lsmod |grep hcd

Read this guide for more info

SDB:Pm-utils - openSUSE

Thanks for the links.

There are no modules with “hcd”, neither uhci or ehci. I read somewhere that starting with one of the later kernel versions
USB drivers are built into the kernel and not provided as modules, thus they cannot be reloaded.

All kernel drivers are built as modules that can be added, upgraded, replaced, loaded and unloaded on demand. Not everthing in the kernel is a module, but when taking about most anything to do with hardware, it is a module. I found this short description:

What exactly is a kernel module? Modules are pieces of code that can be loaded and unloaded into the kernel upon demand. They extend the functionality of the kernel without the need to reboot the system. For example, one type of module is the device driver, which allows the kernel to access hardware connected to the system. Without modules, we would have to build monolithic kernels and add new functionality directly into the kernel image. Besides having larger kernels, this has the disadvantage of requiring us to rebuild and reboot the kernel every time we want new functionality.

On my system I find the module called “xhci_hcd” which includes hcd and may be for USB 3 drives, but I did not look it up. You can see all loaded modules with my bash script skim. You can find it here:

http://forums.opensuse.org/blogs/jdmcdaniel3/s-k-i-m-suse-kernel-installed-modules-lsmod-replacement-creates-alphabetized-module-listing-48/

Thank You,

I’m really surprised. I downloaded S.K.I.M. from your blog and launched it on my openSUSE 11.4 installation.

skim | grep hcd returns no modules and skim | grep usb returns:


bluetooth 285559 5 rfcomm,bnep,btusb,
btusb      17819   0 -

Interestingly, if I execute modprobe ehci_hcd and then lsmod | grep ehci the module is not there.

However, it I attach a USB mouse or a USB flash drive they both work perfectly even if I do not see the modules (I ran S.K.I.M. while the USB flash drive was mounted).

Does this behaviour exist with other operating systems? (If you don’t dual boot with Windows, maybe you have a Live CD/DVD distro to try). A possible BIOS issue perhaps? This thread prompted this idea.

The acpid package contains the acpid daemon, and handles any hardware quirks that may need to be handled specifically. It may be that you’ve encountered a bug which needs to be reported.

The standard openSUSE kernel configuration has

CONFIG_USB_XHCI_HCD=m
CONFIG_USB_EHCI_HCD=y
CONFIG_USB_OHCI_HCD=y

The USB 1.1 and USB 2.0 drivers are built in while the USB 3.0 driver is a module.

My case is a bit different, since everything works on my laptop after a fresh reboot. It happens sporadically after resuming. I haven’t tested hibernating/resuming in windows, but I will tomorrow since I don’t have my laptop with me right now.

The acpid package contains the acpid daemon, and handles any hardware quirks that may need to be handled specifically. It may be that you’ve encountered a bug which needs to be reported.

Yes, I suspect that this is a bug. How can I report it? Is there a way that I can manually change the hardware quirks?

Another thing I noticed also is that the laptop cuts power to the USB ports during resuming. In fact, I get the message in the resume logs:


usb root hub lost power or was reset
\CODE]

However, this might not be related to the problem of "IRQ #18 disabled" because the USB ports still work after resuming even when I get the message about the usb hub losing power, as long as IRQ #18 was not disabled.

Is there still a way to reset the drivers for my USB 2.0 ports? Maybe something similar as this example to restart the mouse:

SDB:Pm-utils - openSUSE

Yes, I suspect that this is a bug. How can I report it?

You could report it here:
https://bugzilla.novell.com/index.cgi

I found an old Ubuntu bug report, where in post #10, it was suggested

Fixed by creating /etc/pm/config.d/usb_suspend_workaround with the contents:

SUSPEND_MODULES="ehci_hcd uhci_hcd usbcore"

Tested with multiple suspend/restarts.

However as the ehci_hcd and uhci_hcd are built-in to the kernel, this will not work for you, (assuming this is the crux of the problem you’re experiencing anyway).

A bug report is the most realistic way of progressing this IMHO.

I’m curious to know why the decision was made to have the USB drivers compiled into the kernel. Just out of curiosity.

On 05/10/2012 01:16 PM, gianluca4 wrote:
>
> I’m curious to know why the decision was made to have the USB drivers
> compiled into the kernel. Just out of curiosity.

You would have to ask the kernel packagers, who do not read these lists. For USB
boot disks, they have to be available when the kernel is loaded; however, having
them in initrd would be sufficient.

Yeah. It seems that my only option is to file a bug report and hope that it will be solved in the next kernel update.

It’s annoying because actually the problem already appears by hibernating and resuming twice in a row. I mostly use my laptop without a mouse, but sometimes I give talks where a remote control is handy.

Of course you could custom buiild your own kernel, but not a feasible option for most.