Alan Stern writes: > On Fri, 25 Sep 2009, Mikael Pettersson wrote: > > > Alan Stern writes: > > > On Thu, 24 Sep 2009, Mikael Pettersson wrote: > > > > > > > I'm trying to tune a tickless 2.6.31 kernel for an ARM box > > > > (arch/arm/mach-iop32x/n2100.c). Looking at /proc/timer_stats > > > > I see that > > > > > > > > usb_hcd_poll_rh_status (rh_timer_func) > > > > > > > > is now the #1 cause of timeouts, which prevents the tickless > > > > kernel from extending the periods between timer interrupts. > > > > > > > > The machine has VIA EHCI and UHCI controllers. The polling timer > > > > appears if UHCI_HCD is enabled; enabling only EHCI_HCD does not > > > > case the timer to appear. > > > > > > What USB devices are on the UHCI buses? > > > > There are no devices on the UHCI buses. > > > > > > Is a polling timer really necessary? If it is, why? UHCI bug or > > > > kernel limitation/shortcut? > > > > > > It is necessary if the the bus is not suspended. This is a UHCI design > > > limitation, not a bug and not a kernel limitation. > > > > > > Even if the bus is suspended, the timer sometimes is necessary. This > > > is because of bugs in some UHCI implementations and bugs in some > > > motherboard designs. However these bugs are specific to Intel and > > > Genesys Logic controllers and Asus motherboards, so they shouldn't > > > affect you. > > > > So an empty bus should be suspended, and thus not need the timer? > > It should be. Unless you have turned off the "wakeup" attribute under > /sys/bus/usb/devices/usbN/power. > > If you want to get more information about what's happening, build a > kernel with CONFIG_USB_DEBUG enabled and see what shows up in the dmesg > log. I rebuilt with CONFIG_USB_DEBUG=y but no /sys/bus/usb/devices/usbN/power appeared (apparently it depends on CONFIG_PM). The kernel boot log indicated that it knew the UHCI bus was empty, but it didn't stop the timer: usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb pci 0000:00:01.0: calling quirk_usb_early_handoff+0x0/0x600 pci 0000:00:02.0: calling quirk_usb_early_handoff+0x0/0x600 pci 0000:00:03.0: calling quirk_usb_early_handoff+0x0/0x600 pci 0000:00:04.0: calling quirk_usb_early_handoff+0x0/0x600 pci 0000:00:04.0: uhci_check_and_reset_hc: legsup = 0x2000 pci 0000:00:04.1: calling quirk_usb_early_handoff+0x0/0x600 pci 0000:00:04.1: uhci_check_and_reset_hc: legsup = 0x2000 pci 0000:00:04.2: calling quirk_usb_early_handoff+0x0/0x600 uhci_hcd: USB Universal Host Controller Interface driver uhci_hcd 0000:00:04.0: calling quirk_via_vlink+0x0/0xd4 uhci_hcd 0000:00:04.0: Found HC with no IRQ. Check BIOS/PCI 0000:00:04.0 setup! uhci_hcd 0000:00:04.0: init 0000:00:04.0 fail, -19 (don't worry about the controller at 04.0, its irq line has been deliberatly reassigned to the console UART via a jumper on the mobo) uhci_hcd 0000:00:04.1: calling quirk_via_vlink+0x0/0xd4 uhci_hcd 0000:00:04.1: UHCI Host Controller uhci_hcd 0000:00:04.1: new USB bus registered, assigned bus number 1 uhci_hcd 0000:00:04.1: detected 2 ports uhci_hcd 0000:00:04.1: uhci_check_and_reset_hc: cmd = 0x0000 uhci_hcd 0000:00:04.1: Performing full reset uhci_hcd 0000:00:04.1: irq 27, io base 0x90000820 usb usb1: default language 0x0409 usb usb1: udev 1, busnum 1, minor = 0 usb usb1: New USB device found, idVendor=1d6b, idProduct=0001 usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber=1 usb usb1: Product: UHCI Host Controller usb usb1: Manufacturer: Linux 2.6.31 uhci_hcd usb usb1: SerialNumber: 0000:00:04.1 usb usb1: uevent usb usb1: usb_probe_device usb usb1: configuration #1 chosen from 1 choice usb usb1: adding 1-0:1.0 (config #1, interface 0) usb 1-0:1.0: uevent hub 1-0:1.0: usb_probe_interface hub 1-0:1.0: usb_probe_interface - got id hub 1-0:1.0: USB hub found hub 1-0:1.0: 2 ports detected hub 1-0:1.0: standalone hub hub 1-0:1.0: no power switching (usb 1.0) hub 1-0:1.0: individual port over-current protection hub 1-0:1.0: power on to power good time: 2ms hub 1-0:1.0: local power source is good hub 1-0:1.0: trying to enable port power on non-switchable hub Initializing USB Mass Storage driver... usbcore: registered new interface driver usb-storage USB Mass Storage support registered. uhci_hcd 0000:00:04.1: port 1 portsc 008a,00 uhci_hcd 0000:00:04.1: port 2 portsc 008a,00 hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000 usb usb1: suspend_rh (auto-stop) I had a look in drivers/usb/, and this suspend_rh (auto-stop) means that hub told uhci that the bus is empty. There is some code in suspend_rh() to determine if the timer should be stopped or not, but apparently that code didn't decide to stop the timer. Next I rebuilt with CONFIG_PM and CONFIG_USB_SUSPEND. That made a significant difference: @@ -19,6 +19,7 @@ uhci_hcd 0000:00:04.1: detected 2 ports uhci_hcd 0000:00:04.1: uhci_check_and_reset_hc: cmd = 0x0000 uhci_hcd 0000:00:04.1: Performing full reset +uhci_hcd 0000:00:04.1: supports USB remote wakeup uhci_hcd 0000:00:04.1: irq 27, io base 0x90000820 usb usb1: default language 0x0409 usb usb1: udev 1, busnum 1, minor = 0 @@ -49,3 +50,6 @@ uhci_hcd 0000:00:04.1: port 2 portsc 008a,00 hub 1-0:1.0: state 7 ports 2 chg 0000 evt 0000 usb usb1: suspend_rh (auto-stop) +hub 1-0:1.0: hub_suspend +usb usb1: bus auto-suspend +usb usb1: suspend_rh And now the timer doesn't show up in /proc/timer_stats any more. Nice. The platform doesn't have any firmware support for power management, suspend to ram, or anything like that, so kernels are typically built without CONFIG_PM enabled (like many other embedded systems). Shouldn't that timer be halted also in the !CONFIG_PM case? /Mikael -- To unsubscribe from this list: send the line "unsubscribe linux-usb" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
