2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

After reboot with 2.6.17 dmesg is overflowed with the above. 2.6.16.20 was OK. 
Please let me know what additional information may be useful; for now I 
simply commented out this printk. dmesg, lsusb and lspci follow.

00:00.0 0600: 10b9:1644 (rev 01)
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ >SERR- <PERR+
        Latency: 0
        Region 0: Memory at f0000000 (32-bit, prefetchable) [size=64M]
        Capabilities: [b0] AGP version 2.0
                Status: RQ=28 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=<none>
        Capabilities: [a4] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:01.0 0604: 10b9:5247
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=slow >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
        Memory behind bridge: f7f00000-fdffffff
        Prefetchable memory behind bridge: 3c000000-3c0fffff
        Secondary status: 66MHz+ FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort+ <SERR- <PERR+
        BridgeCtl: Parity- SERR- NoISA- VGA+ MAbort- >Reset- FastB2B-

00:02.0 0c03: 10b9:5237 (rev 03) (prog-if 10)
        Subsystem: 1179:0004
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (20000ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7eff000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:04.0 0101: 10b9:5229 (rev c3) (prog-if f0)
        Subsystem: 1179:0004
        Control: I/O+ Mem- BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (500ns min, 1000ns max)
        Interrupt: pin A routed to IRQ 255
        Region 4: I/O ports at eff0 [size=16]
        Capabilities: [60] Power Management version 2
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:06.0 0401: 10b9:5451 (rev 01)
        Subsystem: 1179:0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR+ <PERR+
        Latency: 64 (500ns min, 6000ns max)
        Interrupt: pin A routed to IRQ 11
        Region 0: I/O ports at ed00 [size=256]
        Region 1: Memory at f7efe000 (32-bit, non-prefetchable) [size=4K]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:07.0 0601: 10b9:1533
        Subsystem: 1179:0004
        Control: I/O+ Mem+ BusMaster+ SpecCycle+ MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 0
        Capabilities: [a0] Power Management version 1
                Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

00:08.0 0680: 10b9:7101
        Subsystem: 1179:0001
        Control: I/O- Mem- BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-

00:0a.0 0200: 8086:1229 (rev 08)
        Subsystem: 1179:0003
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 64 (2000ns min, 14000ns max), Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7efd000 (32-bit, non-prefetchable) [size=4K]
        Region 1: I/O ports at eb40 [size=64]
        Region 2: Memory at f7d00000 (32-bit, non-prefetchable) [size=1M]
        Capabilities: [dc] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=2 PME-

00:10.0 0607: 104c:ac50 (rev 01)
        Subsystem: 12a3:ab01
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168, Cache Line Size 08
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 3c100000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=02, subordinate=05, sec-latency=176
        Memory window 0: 30000000-31fff000 (prefetchable)
        Memory window 1: 32000000-33fff000
        I/O window 0: 00001000-000010ff
        I/O window 1: 00001400-000014ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset+ 16bInt- PostWrite+
        16-bit legacy interface ports at 0001

00:11.0 0607: 1179:0617 (rev 32)
        Subsystem: 1179:0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 3c101000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=06, subordinate=09, sec-latency=0
        Memory window 0: 34000000-35fff000 (prefetchable)
        Memory window 1: 36000000-37fff000
        I/O window 0: 00001800-000018ff
        I/O window 1: 00001c00-00001cff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001

00:11.1 0607: 1179:0617 (rev 32)
        Subsystem: 1179:0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B+ ParErr- DEVSEL=slow >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 168
        Interrupt: pin B routed to IRQ 11
        Region 0: Memory at 3c102000 (32-bit, non-prefetchable) [size=4K]
        Bus: primary=00, secondary=0a, subordinate=0d, sec-latency=0
        Memory window 0: 38000000-39fff000 (prefetchable)
        Memory window 1: 3a000000-3bfff000
        I/O window 0: 00002000-000020ff
        I/O window 1: 00002400-000024ff
        BridgeCtl: Parity- SERR- ISA- VGA- MAbort- >Reset- 16bInt+ PostWrite+
        16-bit legacy interface ports at 0001

00:12.0 0880: 1179:0805 (rev 03)
        Subsystem: 1179:0001
        Control: I/O- Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at f7cffe00 (32-bit, non-prefetchable) [size=512]
        Capabilities: [80] Power Management version 2
                Flags: PMEClk- DSI- D1+ D2+ AuxCurrent=0mA 
PME(D0+,D1+,D2+,D3hot+,D3cold+)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

01:00.0 0300: 1023:8820 (rev 82)
        Subsystem: 1179:0001
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- 
Stepping- SERR- FastB2B-
        Status: Cap+ 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- 
<TAbort- <MAbort- >SERR- <PERR-
        Latency: 8
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at fc000000 (32-bit, non-prefetchable) [size=32M]
        Region 1: Memory at fbc00000 (32-bit, non-prefetchable) [size=4M]
        Region 2: Memory at f8000000 (32-bit, non-prefetchable) [size=32M]
        Region 3: Memory at f7ff8000 (32-bit, non-prefetchable) [size=32K]
        [virtual] Expansion ROM at 3c000000 [disabled] [size=64K]
        Capabilities: [80] AGP version 2.0
                Status: RQ=33 Iso- ArqSz=0 Cal=0 SBA+ ITACoh- GART64- HTrans- 
64bit- FW- AGP3- Rate=x1,x2,x4
                Command: RQ=1 ArqSz=0 Cal=0 SBA- AGP- GART64- 64bit- FW- 
Rate=<none>
        Capabilities: [90] Power Management version 2
                Flags: PMEClk- DSI+ D1+ D2+ AuxCurrent=0mA 
PME(D0-,D1-,D2-,D3hot-,D3cold-)
                Status: D0 PME-Enable- DSel=0 DScale=0 PME-

{pts/0}% lsusb -vv

Bus 001 Device 001: ID 0000:0000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
  bDeviceSubClass         0 Unused
  bDeviceProtocol         0
  bMaxPacketSize0        64
  idVendor           0x0000
  idProduct          0x0000
  bcdDevice            2.06
  iManufacturer           3 Linux 2.6.17-1avb ohci_hcd
  iProduct                2 OHCI Host Controller
  iSerial                 1 0000:00:02.0
  bNumConfigurations      1
  Configuration Descriptor:
    bLength                 9
    bDescriptorType         2
    wTotalLength           25
    bNumInterfaces          1
    bConfigurationValue     1
    iConfiguration          0
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup
    MaxPower                0mA
    Interface Descriptor:
      bLength                 9
      bDescriptorType         4
      bInterfaceNumber        0
      bAlternateSetting       0
      bNumEndpoints           1
      bInterfaceClass         9 Hub
      bInterfaceSubClass      0 Unused
      bInterfaceProtocol      0
      iInterface              0
      Endpoint Descriptor:
        bLength                 7
        bDescriptorType         5
        bEndpointAddress     0x81  EP 1 IN
        bmAttributes            3
          Transfer Type            Interrupt
          Synch Type               None
          Usage Type               Data
        wMaxPacketSize     0x0002  1x 2 bytes
        bInterval             255
Hub Descriptor:
  bLength               9
  bDescriptorType      41
  nNbrPorts             3
  wHubCharacteristic 0x0002
    No power switching (usb 1.0)
    Ganged overcurrent protection
  bPwrOn2PwrGood        1 * 2 milli seconds
  bHubContrCurrent      0 milli Ampere
  DeviceRemovable    0x00
  PortPwrCtrlMask    0xff
 Hub Port Status:
   Port 1: 0000.0100 power
   Port 2: 0000.0100 power
   Port 3: 0000.0100 power
Device Status:     0x0003
  Self Powered
  Remote Wakeup Enabled

dmesg:
Linux version 2.6.17-1avb (bor@cooker) (gcc version 4.1.1 20060518 
(prerelease)) #2 Sun Jun 18 15:54:15 MSD 2006
BIOS-provided physical RAM map:
 BIOS-e820: 0000000000000000 - 000000000009fc00 (usable)
 BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved)
 BIOS-e820: 00000000000e0000 - 00000000000eee00 (reserved)
 BIOS-e820: 00000000000eee00 - 00000000000ef000 (ACPI NVS)
 BIOS-e820: 00000000000ef000 - 0000000000100000 (reserved)
 BIOS-e820: 0000000000100000 - 000000001ef60000 (usable)
 BIOS-e820: 000000001ef60000 - 000000001ef70000 (ACPI data)
 BIOS-e820: 000000001ef70000 - 0000000020000000 (reserved)
 BIOS-e820: 00000000fff80000 - 0000000100000000 (reserved)
495MB LOWMEM available.
On node 0 totalpages: 126816
  DMA zone: 4096 pages, LIFO batch:0
  Normal zone: 122720 pages, LIFO batch:31
DMI 2.3 present.
ACPI: RSDP (v000 TOSHIB                                ) @ 0x000f0090
ACPI: RSDT (v001 TOSHIB 750      0x00970814 TASM 0x04010000) @ 0x1ef60000
ACPI: FADT (v002 TOSHIB 750      0x00970814 TASM 0x04010000) @ 0x1ef60054
ACPI: DSDT (v001 TOSHIB 4000     0x20020417 MSFT 0x0100000a) @ 0x00000000
ACPI: PM-Timer IO Port: 0xee08
Allocating PCI resources starting at 30000000 (gap: 20000000:dff80000)
Built 1 zonelists
Kernel command line: root=/dev/hda2 pinit hdc=ide-cd resume=/dev/hda1 
splash=silent elevator=cfq vga=791 3
Local APIC disabled by BIOS -- you can enable it with "lapic"
mapped APIC to ffffd000 (013e4000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 2048 (order: 11, 8192 bytes)
Detected 747.740 MHz processor.
Using pmtmr for high-res timesource
Console: colour dummy device 80x25
Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
Memory: 499180k/507264k available (1663k kernel code, 7456k reserved, 795k 
data, 176k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1496.77 BogoMIPS (lpj=748388)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0387f9ff 00000000 00000000 00000000 
00000000 00000000 00000000
CPU: After vendor identify, caps: 0387f9ff 00000000 00000000 00000000 00000000 
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 0a
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 0k freed
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs... it is
Freeing initrd memory: 230k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfe5ae, last bus=5
Setting up standard PCI resources
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region ee00-ee3f claimed by ali7101 ACPI
PCI quirk: region ef00-ef1f claimed by ali7101 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: Power Resource [PFAN] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: f7f00000-fdffffff
  PREFETCH window: 3c000000-3c0fffff
PCI: Bus 2, cardbus bridge: 0000:00:10.0
  IO window: 00001000-000010ff
  IO window: 00001400-000014ff
  PREFETCH window: 30000000-31ffffff
  MEM window: 32000000-33ffffff
PCI: Bus 6, cardbus bridge: 0000:00:11.0
  IO window: 00001800-000018ff
  IO window: 00001c00-00001cff
  PREFETCH window: 34000000-35ffffff
  MEM window: 36000000-37ffffff
PCI: Bus 10, cardbus bridge: 0000:00:11.1
  IO window: 00002000-000020ff
  IO window: 00002400-000024ff
  PREFETCH window: 38000000-39ffffff
  MEM window: 3a000000-3bffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Enabling device 0000:00:10.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> 
IRQ 11
PCI: Enabling device 0000:00:11.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> 
IRQ 11
PCI: Enabling device 0000:00:11.1 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> 
IRQ 11
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1150642545.524:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
vesafb: framebuffer at 0xfc000000, mapped to 0xdf880000, using 3072k, total 
16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: protected mode interface info at c000:775e
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12ac
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI wakeup devices: 
 COM USB1 ASND VIY0 VIY1  LAN MPC0 MPC1 NOV0  LID 
ACPI: (supports S0 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 176k freed
Write protecting the kernel read-only data: 516k
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
input: AT Translated Set 2 keyboard as /class/input/input0
ALI15X3: IDE controller at PCI slot 0000:00:04.0
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ALI15X3: chipset revision 195
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xeff0-0xeff7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xeff8-0xefff, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N020ATDA04-0, ATA DISK drive
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB) w/1806KiB Cache, CHS=38760/16/63, UDMA(33)
hda: cache flushes not supported
 hda: hda1 hda2
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd 0000:00:02.0: OHCI Host Controller
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
usb usb1: configuration #1 chosen from 1 choice
hub 1-0:1.0: USB hub found
hub 1-0:1.0: 3 ports detected
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected ALi M1644 chipset
agpgart: AGP aperture is 64M @ 0xf0000000
ohci_hcd 0000:00:02.0: wakeup
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:10.0 [12a3:ab01]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:10.0, mfunc 0x01000002, devctl 0x60
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000059
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.0 [1179:0001]
ohci_hcd 0000:00:02.0: wakeup
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
ohci_hcd 0000:00:02.0: wakeup
pccard: PCMCIA card inserted into slot 0
ohci_hcd 0000:00:02.0: wakeup
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcbfff 0xe0000-0xfffff
cs: memory probe 0x60000000-0x60ffffff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
pcmcia: registering new device pcmcia0.0
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.1 [1179:0001]
wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems, 
http://www.agere.com
*** Modified for kernel 2.6 by Andrey Borzenkov <arvidjaar@mail.ru> $Revision: 
22 $
*** Station Mode (STA) Support: YES
*** Access Point Mode (AP) Support: YES
ohci_hcd 0000:00:02.0: wakeup
eth0: PRI 31 variant 2 version 9.48
eth0: NIC 5 variant 2 version 1.02
eth0: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Battery Slot [BAT2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ohci_hcd 0000:00:02.0: wakeup
ACPI: Thermal Zone [THRM] (53 C)
toshiba_acpi: Toshiba Laptop ACPI Extras version 0.18
toshiba_acpi:     HCI method: \_SB_.VALD.GHCI
ACPI: Video Device [VGA] (multi-head: yes  rom: yes  post: no)
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
Adding 500432k swap on /dev/hda1.  Priority:-1 extents:1 across:500432k
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
loop: loaded (max 8 devices)
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ohci_hcd 0000:00:02.0: wakeup
ohci_hcd 0000:00:02.0: wakeup
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFElW8WR6LMutpd94wRApdPAJ45BIDoOzPab3YncJ1MXO0RWyHZeQCfSyli
LqZY+QERkJQBKtw/Qr/w5Xg=
=nQS6
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[David Brownell]

On Sunday 18 June 2006 8:19 am, Andrey Borzenkov wrote:
> After reboot with 2.6.17 dmesg is overflowed with the above. 2.6.16.20 was OK.
> Please let me know what additional information may be useful; for now I
> simply commented out this printk. dmesg, lsusb and lspci follow.

The printk means you're getting more IRQs than would be good.
Did you apply any patches to this, e.g. from the MM tree?

An alternative (but post-boot) workaround _should_ be

    echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup

Looks like this is an old ALI-based motherboard with only one USB
controller; this might be a hardware problem, some others from
that era had problems handling USB suspend states.  In your case
(no USB devices hooked up here, right?) maybe this problem can
be automagically detected and worked around.

What would be most useful in this case -- and is ISTR one of
the FAQs for "how to report USB problems" -- is rebuilding
with CONFIG_USB_DEBUG and sending the boot log, so I can see
how that OHCI controller comes up in more detail than you've
provided here.

- Dave

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 18 June 2006 20:29, David Brownell wrote:
> On Sunday 18 June 2006 8:19 am, Andrey Borzenkov wrote:
> > After reboot with 2.6.17 dmesg is overflowed with the above. 2.6.16.20
> > was OK. Please let me know what additional information may be useful; for
> > now I simply commented out this printk. dmesg, lsusb and lspci follow.
>
> The printk means you're getting more IRQs than would be good.
> Did you apply any patches to this, e.g. from the MM tree?
>

no.

> An alternative (but post-boot) workaround _should_ be
>
>     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
>
> Looks like this is an old ALI-based motherboard with only one USB
> controller; this might be a hardware problem, some others from
> that era had problems handling USB suspend states.  In your case
> (no USB devices hooked up here, right?) maybe this problem can
> be automagically detected and worked around.
>

This is Tohiba Portege 4000 notebook. So far I did not have any USB related 
issues at least since 2.6.12. And true, I do not have any devices plugged in.

> What would be most useful in this case -- and is ISTR one of
> the FAQs for "how to report USB problems" -- is rebuilding
> with CONFIG_USB_DEBUG and sending the boot log, so I can see
> how that OHCI controller comes up in more detail than you've
> provided here.
>

Here you are. I am still puzzled where all these "suspends" come from - I did 
not try any suspend in the meantime ...

- -andrey


ble entries: 32768 (order: 5, 131072 bytes)
Memory: 499180k/507264k available (1663k kernel code, 7456k reserved, 795k 
data, 176k init, 0k highmem)
Checking if this processor honours the WP bit even in supervisor mode... Ok.
Calibrating delay using timer specific routine.. 1496.80 BogoMIPS (lpj=748402)
Mount-cache hash table entries: 512
CPU: After generic identify, caps: 0387f9ff 00000000 00000000 00000000 
00000000 00000000 00000000
CPU: After vendor identify, caps: 0387f9ff 00000000 00000000 00000000 00000000 
00000000 00000000
CPU: L1 I cache: 16K, L1 D cache: 16K
CPU: L2 cache: 256K
CPU serial number disabled.
CPU: After all inits, caps: 0383f9ff 00000000 00000000 00000040 00000000 
00000000 00000000
Intel machine check architecture supported.
Intel machine check reporting enabled on CPU#0.
CPU: Intel Pentium III (Coppermine) stepping 0a
Checking 'hlt' instruction... OK.
SMP alternatives: switching to UP code
Freeing SMP alternatives: 0k freed
ACPI: setting ELCR to 0200 (from 0a00)
checking if image is initramfs... it is
Freeing initrd memory: 230k freed
NET: Registered protocol family 16
ACPI: bus type pci registered
PCI: PCI BIOS revision 2.10 entry at 0xfe5ae, last bus=5
Setting up standard PCI resources
ACPI: Subsystem revision 20060127
ACPI: Interpreter enabled
ACPI: Using PIC for interrupt routing
ACPI: PCI Root Bridge [PCI0] (0000:00)
PCI: Probing PCI hardware (bus 00)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0
PCI quirk: region ee00-ee3f claimed by ali7101 ACPI
PCI quirk: region ef00-ef1f claimed by ali7101 SMB
Boot video device is 0000:01:00.0
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 10 *11)
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
ACPI: Power Resource [PFAN] (off)
Linux Plug and Play Support v0.97 (c) Adam Belay
pnp: PnP ACPI init
pnp: PnP ACPI: found 12 devices
PCI: Using ACPI for IRQ routing
PCI: If a device doesn't work, try "pci=routeirq".  If it helps, post a report
TC classifier action (bugs to netdev@vger.kernel.org cc hadi@cyberus.ca)
PCI: Bridge: 0000:00:01.0
  IO window: disabled.
  MEM window: f7f00000-fdffffff
  PREFETCH window: 3c000000-3c0fffff
PCI: Bus 2, cardbus bridge: 0000:00:10.0
  IO window: 00001000-000010ff
  IO window: 00001400-000014ff
  PREFETCH window: 30000000-31ffffff
  MEM window: 32000000-33ffffff
PCI: Bus 6, cardbus bridge: 0000:00:11.0
  IO window: 00001800-000018ff
  IO window: 00001c00-00001cff
  PREFETCH window: 34000000-35ffffff
  MEM window: 36000000-37ffffff
PCI: Bus 10, cardbus bridge: 0000:00:11.1
  IO window: 00002000-000020ff
  IO window: 00002400-000024ff
  PREFETCH window: 38000000-39ffffff
  MEM window: 3a000000-3bffffff
PCI: Setting latency timer of device 0000:00:01.0 to 64
PCI: Enabling device 0000:00:10.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKC] enabled at IRQ 11
PCI: setting IRQ 11 as level-triggered
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> 
IRQ 11
PCI: Enabling device 0000:00:11.0 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKA] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> 
IRQ 11
PCI: Enabling device 0000:00:11.1 (0000 -> 0003)
ACPI: PCI Interrupt Link [LNKB] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> 
IRQ 11
NET: Registered protocol family 2
IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
TCP established hash table entries: 16384 (order: 6, 262144 bytes)
TCP bind hash table entries: 8192 (order: 5, 163840 bytes)
TCP: Hash tables configured (established 16384 bind 8192)
TCP reno registered
audit: initializing netlink socket (disabled)
audit(1150650880.535:1): initialized
VFS: Disk quotas dquot_6.5.1
Dquot-cache hash table entries: 1024 (order 0, 4096 bytes)
Initializing Cryptographic API
io scheduler noop registered
io scheduler anticipatory registered
io scheduler deadline registered
io scheduler cfq registered (default)
Activating ISA DMA hang workarounds.
vesafb: framebuffer at 0xfc000000, mapped to 0xdf880000, using 3072k, total 
16384k
vesafb: mode is 1024x768x16, linelength=2048, pages=9
vesafb: protected mode interface info at c000:775e
vesafb: scrolling: redraw
vesafb: Truecolor: size=0:5:6:5, shift=0:11:5:0
Console: switching to colour frame buffer device 128x48
fb0: VESA VGA frame buffer device
Real Time Clock Driver v1.12ac
RAMDISK driver initialized: 16 RAM disks of 32000K size 1024 blocksize
PNP: PS/2 Controller [PNP0303:KBC,PNP0f13:PS2M] at 0x60,0x64 irq 1,12
serio: i8042 AUX port at 0x60,0x64 irq 12
serio: i8042 KBD port at 0x60,0x64 irq 1
mice: PS/2 mouse device common for all mice
NET: Registered protocol family 1
Using IPI Shortcut mode
ACPI wakeup devices: 
 COM USB1 ASND VIY0 VIY1  LAN MPC0 MPC1 NOV0  LID 
ACPI: (supports S0 S3 S4 S5)
BIOS EDD facility v0.16 2004-Jun-25, 1 devices found
Freeing unused kernel memory: 176k freed
Write protecting the kernel read-only data: 516k
Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx
input: AT Translated Set 2 keyboard as /class/input/input0
ALI15X3: IDE controller at PCI slot 0000:00:04.0
ACPI: PCI Interrupt 0000:00:04.0[A]: no GSI
ALI15X3: chipset revision 195
ALI15X3: not 100% native mode: will probe irqs later
    ide0: BM-DMA at 0xeff0-0xeff7, BIOS settings: hda:DMA, hdb:pio
    ide1: BM-DMA at 0xeff8-0xefff, BIOS settings: hdc:DMA, hdd:pio
Probing IDE interface ide0...
hda: IC25N020ATDA04-0, ATA DISK drive
input: ImPS/2 Generic Wheel Mouse as /class/input/input1
ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
Probing IDE interface ide1...
hdc: TOSHIBA DVD-ROM SD-C2502, ATAPI CD/DVD-ROM drive
ide1 at 0x170-0x177,0x376 on irq 15
hda: max request size: 128KiB
hda: 39070080 sectors (20003 MB) w/1806KiB Cache, CHS=38760/16/63, UDMA(33)
hda: cache flushes not supported
 hda: hda1 hda2
ReiserFS: hda2: found reiserfs format "3.6" with standard journal
ReiserFS: hda2: using ordered data mode
ReiserFS: hda2: journal params: device hda2, size 8192, journal first block 
18, max trans len 1024, max batch 900, max commit age 30, max trans age 30
ReiserFS: hda2: checking transaction log (hda2)
ReiserFS: hda2: Using r5 hash to sort names
usbcore: registered new driver usbfs
usbcore: registered new driver hub
ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
ohci_hcd: block sizes: ed 64 td 64
ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) -> 
IRQ 11
ohci_hcd 0000:00:02.0: OHCI Host Controller
/home/bor/src/linux-git/drivers/usb/core/inode.c: creating file 'devices'
/home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
ohci_hcd 0000:00:02.0: created debug files
ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x0
ohci_hcd 0000:00:02.0: enabling initreset quirk
ohci_hcd 0000:00:02.0: OHCI controller state
ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3
ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF
ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
ohci_hcd 0000:00:02.0: hcca frame #0003
ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
usb usb1: default language 0x0409
usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
usb usb1: Product: OHCI Host Controller
usb usb1: Manufacturer: Linux 2.6.17-2avb ohci_hcd
usb usb1: SerialNumber: 0000:00:02.0
usb usb1: uevent
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: 3 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: global 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: no over-current condition exists
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
/home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
Linux agpgart interface v0.101 (c) Dave Jones
agpgart: Detected ALi M1644 chipset
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
agpgart: AGP aperture is 64M @ 0xf0000000
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ACPI: PCI Interrupt 0000:00:10.0[A] -> Link [LNKC] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:10.0 [12a3:ab01]
Yenta: Using CSCINT to route CSC interrupts to PCI
Yenta: Routing CardBus interrupts to PCI
Yenta TI: socket 0000:00:10.0, mfunc 0x01000002, devctl 0x60
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
Yenta: ISA IRQ mask 0x0000, PCI irq 11
Socket status: 30000059
ACPI: PCI Interrupt 0000:00:11.0[A] -> Link [LNKA] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.0 [1179:0001]
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
pccard: PCMCIA card inserted into slot 0
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
cs: memory probe 0x0c0000-0x0fffff: excluding 0xc0000-0xcbfff 0xe0000-0xfffff
cs: memory probe 0x60000000-0x60ffffff: clean.
cs: memory probe 0xa0000000-0xa0ffffff: clean.
pcmcia: registering new device pcmcia0.0
ACPI: PCI Interrupt 0000:00:11.1[B] -> Link [LNKB] -> GSI 11 (level, low) -> 
IRQ 11
Yenta: CardBus bridge found at 0000:00:11.1 [1179:0001]
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
wlags49_h1_cs v7.18 for PCMCIA, 03/31/2004 14:31:00 by Agere Systems, 
http://www.agere.com
*** Modified for kernel 2.6 by Andrey Borzenkov <arvidjaar@mail.ru> $Revision: 
22 $
*** Station Mode (STA) Support: YES
*** Access Point Mode (AP) Support: YES
eth0: PRI 31 variant 2 version 9.48
eth0: NIC 5 variant 2 version 1.02
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
eth0: Wireless, io_addr 0x100, irq 11, mac_address 00:02:2D:26:95:6C
Yenta: ISA IRQ mask 0x04b8, PCI irq 11
Socket status: 30000007
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ACPI: AC Adapter [ADP1] (on-line)
ACPI: Battery Slot [BAT1] (battery present)
ACPI: Battery Slot [BAT2] (battery absent)
ACPI: Power Button (FF) [PWRF]
ACPI: Lid Switch [LID]
ACPI: Fan [FAN] (off)
ACPI: CPU0 (power states: C1[C1] C2[C2])
ACPI: Thermal Zone [THRM] (56 C)
toshiba_acpi: Toshiba Laptop ACPI Extras version 0.18
toshiba_acpi:     HCI method: \_SB_.VALD.GHCI
ACPI: Video Device [VGA] (multi-head: yes  rom: yes  post: no)
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
Adding 500432k swap on /dev/hda1.  Priority:-1 extents:1 across:500432k
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
loop: loaded (max 8 devices)
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
hdc: ATAPI 24X DVD-ROM drive, 128kB Cache, UDMA(33)
Uniform CD-ROM driver Revision: 3.20
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
ohci_hcd 0000:00:02.0: suspend root hub
hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFElY1rR6LMutpd94wRArYJAJ9wJyt8wZsdmtVx5nHBYlTrGZkYPwCgwhjC
+43GSMQZlzRyb1CKdcGCFT4=
=H9TZ
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[David Brownell]

On Sunday 18 June 2006 10:29 am, Andrey Borzenkov wrote:
> On Sunday 18 June 2006 20:29, David Brownell wrote:
> 
> > An alternative (but post-boot) workaround _should_ be
> >
> >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup

Did that work?


> This is Tohiba Portege 4000 notebook. So far I did not have any USB related
> issues at least since 2.6.12. And true, I do not have any devices plugged in.

It's the usual case of fixing one bug triggering another, in your case
because the fix ran into a previously unseen hardware bug.  One other
way to work around that bug would be disabling CONFIG_PM, but I suspect
you don't want to go that route...


> Here you are. I am still puzzled where all these "suspends" come from - I did
> not try any suspend in the meantime ...

It's the driver putting the controller into a low power state.  Your
hardware seems to have a bug whereby that doesn't work correctly,
making it immediately leave that state.  (And the driver messaging is
fine for what should be an uncommon event; plus it highlighted your
hardware bug.)  Notice the "initreset quirk" message -- another bug
in that hardware.  Workarounds in both cases are simple.

When I get a moment, I'll have a patch for you to try.  Meanwhile,
either workaround I showed above should prevent the attempt to enter
that low power mode.

- Dave



> ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI)
> ohci_hcd: block sizes: ed 64 td 64
> ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low) ->
> IRQ 11
> ohci_hcd 0000:00:02.0: OHCI Host Controller
> /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file 'devices'
> /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> ohci_hcd 0000:00:02.0: created debug files
> ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
> ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x0
> ohci_hcd 0000:00:02.0: enabling initreset quirk
> ohci_hcd 0000:00:02.0: OHCI controller state
> ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
> ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3
> ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
> ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF
> ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
> ohci_hcd 0000:00:02.0: hcca frame #0003
> ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
> ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
> ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
> ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
> ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
> ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
> usb usb1: default language 0x0409
> usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
> usb usb1: Product: OHCI Host Controller
> usb usb1: Manufacturer: Linux 2.6.17-2avb ohci_hcd
> usb usb1: SerialNumber: 0000:00:02.0
> usb usb1: uevent
> 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: 3 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: global 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: no over-current condition exists
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> ohci_hcd 0000:00:02.0: suspend root hub
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> ohci_hcd 0000:00:02.0: suspend root hub
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> ohci_hcd 0000:00:02.0: suspend root hub
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> ohci_hcd 0000:00:02.0: suspend root hub

... etc

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 18 June 2006 22:16, David Brownell wrote:
> On Sunday 18 June 2006 10:29 am, Andrey Borzenkov wrote:
> > On Sunday 18 June 2006 20:29, David Brownell wrote:
> > > An alternative (but post-boot) workaround _should_ be
> > >
> > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
>
> Did that work?
>

No. 

{pts/1}% LC_ALL=C sudo sh -c 'echo -n disabled 
> /sys/bus/pci/devices/0000:00:02.0/power/wakeup'
sh: line 0: echo: write error: Invalid argument

because "disabled" is apparently spelled right, this means it bails out at

        if (!device_can_wakeup(dev))
                return -EINVAL;

which is also confirmed by the fact that reading it returns nothing.

> > This is Tohiba Portege 4000 notebook. So far I did not have any USB
> > related issues at least since 2.6.12. And true, I do not have any devices
> > plugged in.
>
> It's the usual case of fixing one bug triggering another, in your case
> because the fix ran into a previously unseen hardware bug.  One other
> way to work around that bug would be disabling CONFIG_PM, but I suspect
> you don't want to go that route...
>

Well, after I have it doing STR just fine, I'd rather keep it :)

> > Here you are. I am still puzzled where all these "suspends" come from - I
> > did not try any suspend in the meantime ...
>
> It's the driver putting the controller into a low power state.  Your
> hardware seems to have a bug whereby that doesn't work correctly,
> making it immediately leave that state.  (And the driver messaging is
> fine for what should be an uncommon event; plus it highlighted your
> hardware bug.) Notice the "initreset quirk" message -- another bug 
> in that hardware.  Workarounds in both cases are simple.
>
> When I get a moment, I'll have a patch for you to try.  Meanwhile,
> either workaround I showed above should prevent the attempt to enter
> that low power mode.
>

Unfortunately one of them does not work and another is not really feasible :( 
I guess I run 2.6.16 for a while :)

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFElagVR6LMutpd94wRAkKvAJ9qZcf/fmo3lKAi3l/h0HtAYdVO7wCePfeM
kzJnCu8kzX5PjHFud837ShU=
=s5Wm
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 18 June 2006 22:16, David Brownell wrote:
> On Sunday 18 June 2006 10:29 am, Andrey Borzenkov wrote:
> > On Sunday 18 June 2006 20:29, David Brownell wrote:
> > > An alternative (but post-boot) workaround _should_ be
> > >
> > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
>
> Did that work?
>

No. But

	echo -n disabled > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup

did.

Now I noticed that when I boot 2.6.16 hub has only 'Self Powered' attribite 
(0xc0) while in 2.6.17 it adds 'Remote Wakeup':

Bus 001 Device 001: ID 0000:0000
Device Descriptor:
  bLength                18
  bDescriptorType         1
  bcdUSB               1.10
  bDeviceClass            9 Hub
...
    bmAttributes         0xe0
      Self Powered
      Remote Wakeup

It apparently makes OHCI believe controller can correctly do suspend/wakeup. 
The suspend does not come from upper layer - it is ohci_hub itself attempting 
to put controller in lower power mode:

ohci_hub_status_data (struct usb_hcd *hcd, char *buf)
{
...
        int             can_suspend = 
device_may_wakeup(&hcd->self.root_hub->dev);
...
#ifdef CONFIG_PM
        /* save power by suspending idle root hubs;
         * INTR_RD wakes us when there's work
         */
        if (can_suspend
                        && !changed
                        && !ohci->ed_rm_list
                        && ((OHCI_CTRL_HCFS | OHCI_SCHED_ENABLES)
                                        & ohci->hc_control)
                                == OHCI_USB_OPER
                        && time_after (jiffies, ohci->next_statechange)
                        && usb_trylock_device (hcd->self.root_hub) == 0
                        ) {
                ohci_vdbg (ohci, "autosuspend\n");
                (void) ohci_bus_suspend (hcd);
                usb_unlock_device (hcd->self.root_hub);
        }
#endif

can_suspend is true while it was apparently false in 2.6.16.

- -andrey
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2.2 (GNU/Linux)

iD8DBQFElu9JR6LMutpd94wRAv5rAJwO/NZ13duktsD0WsksmFqLtUZufACgkBCS
cOb6y1BG+RjecKtCcua9sNY=
=Rm8d
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[David Brownell]

> > > > An alternative (but post-boot) workaround _should_ be
> > > >
> > > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
> >
> > Did that work?
> >
> 
> No. But
> 
> 	echo -n disabled > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup

That's what I meant ... thanks, and sorry for the confusion.

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 18 June 2006 22:16, David Brownell wrote:
> On Sunday 18 June 2006 10:29 am, Andrey Borzenkov wrote:
> > On Sunday 18 June 2006 20:29, David Brownell wrote:
> > > An alternative (but post-boot) workaround _should_ be
> > >
> > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
>
> Did that work?
>
> > This is Tohiba Portege 4000 notebook. So far I did not have any USB
> > related issues at least since 2.6.12. And true, I do not have any devices
> > plugged in.
>
> It's the usual case of fixing one bug triggering another, in your case
> because the fix ran into a previously unseen hardware bug.  One other
> way to work around that bug would be disabling CONFIG_PM, but I suspect
> you don't want to go that route...
>
> > Here you are. I am still puzzled where all these "suspends" come from - I
> > did not try any suspend in the meantime ...
>
> It's the driver putting the controller into a low power state.  Your
> hardware seems to have a bug whereby that doesn't work correctly,
> making it immediately leave that state.  (And the driver messaging is
> fine for what should be an uncommon event; plus it highlighted your
> hardware bug.)  Notice the "initreset quirk" message -- another bug
> in that hardware.  Workarounds in both cases are simple.
>
> When I get a moment, I'll have a patch for you to try.  Meanwhile,
> either workaround I showed above should prevent the attempt to enter
> that low power mode.
>


I updated to 2.6.18 and got the same issue; any patch to try?

Thank you

- -andrey

> - Dave
>
> > ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
> > (PCI) ohci_hcd: block sizes: ed 64 td 64
> > ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> > ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low)
> > -> IRQ 11
> > ohci_hcd 0000:00:02.0: OHCI Host Controller
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file 'devices'
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> > ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> > ohci_hcd 0000:00:02.0: created debug files
> > ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
> > ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x0
> > ohci_hcd 0000:00:02.0: enabling initreset quirk
> > ohci_hcd 0000:00:02.0: OHCI controller state
> > ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
> > ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3
> > ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
> > ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF
> > ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
> > ohci_hcd 0000:00:02.0: hcca frame #0003
> > ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
> > ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
> > ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
> > ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
> > ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
> > ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
> > usb usb1: default language 0x0409
> > usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
> > usb usb1: Product: OHCI Host Controller
> > usb usb1: Manufacturer: Linux 2.6.17-2avb ohci_hcd
> > usb usb1: SerialNumber: 0000:00:02.0
> > usb usb1: uevent
> > 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: 3 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: global 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: no over-current condition exists
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
>
> .... etc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFFDE4R6LMutpd94wRAjhpAJ4+gsOgdQT8V83QPgbMXa6AVH2WQgCgh4nM
V0GQyKHQylBIrFQwcVGcaEs=
=dlTM
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Alan Stern]

On Fri, 22 Sep 2006, Andrey Borzenkov wrote:

> > It's the usual case of fixing one bug triggering another, in your case
> > because the fix ran into a previously unseen hardware bug.  One other
> > way to work around that bug would be disabling CONFIG_PM, but I suspect
> > you don't want to go that route...
> >
> > > Here you are. I am still puzzled where all these "suspends" come from - I
> > > did not try any suspend in the meantime ...
> >
> > It's the driver putting the controller into a low power state.  Your
> > hardware seems to have a bug whereby that doesn't work correctly,
> > making it immediately leave that state.  (And the driver messaging is
> > fine for what should be an uncommon event; plus it highlighted your
> > hardware bug.)  Notice the "initreset quirk" message -- another bug
> > in that hardware.  Workarounds in both cases are simple.
> >
> > When I get a moment, I'll have a patch for you to try.  Meanwhile,
> > either workaround I showed above should prevent the attempt to enter
> > that low power mode.
> >
> 
> 
> I updated to 2.6.18 and got the same issue; any patch to try?

> > > ohci_hcd 0000:00:02.0: suspend root hub
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > > ohci_hcd 0000:00:02.0: suspend root hub
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > > ohci_hcd 0000:00:02.0: suspend root hub
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > > ohci_hcd 0000:00:02.0: suspend root hub
> >
> > .... etc

I had to add special code in uhci-hcd for controllers where the 
resume-detect mechanism was broken.  When the root hub on one of those 
bad machines is suspended, the driver uses polling instead of interrupts 
to detect port status changes.

Alan Stern

Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sunday 18 June 2006 22:16, David Brownell wrote:
> On Sunday 18 June 2006 10:29 am, Andrey Borzenkov wrote:
> > On Sunday 18 June 2006 20:29, David Brownell wrote:
> > > An alternative (but post-boot) workaround _should_ be
> > >
> > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
>
> Did that work?
>
> > This is Tohiba Portege 4000 notebook. So far I did not have any USB
> > related issues at least since 2.6.12. And true, I do not have any devices
> > plugged in.
>
> It's the usual case of fixing one bug triggering another, in your case
> because the fix ran into a previously unseen hardware bug.  One other
> way to work around that bug would be disabling CONFIG_PM, but I suspect
> you don't want to go that route...
>
> > Here you are. I am still puzzled where all these "suspends" come from - I
> > did not try any suspend in the meantime ...
>
> It's the driver putting the controller into a low power state.  Your
> hardware seems to have a bug whereby that doesn't work correctly,
> making it immediately leave that state.  (And the driver messaging is
> fine for what should be an uncommon event; plus it highlighted your
> hardware bug.)  Notice the "initreset quirk" message -- another bug
> in that hardware.  Workarounds in both cases are simple.
>
> When I get a moment, I'll have a patch for you to try.  Meanwhile,
> either workaround I showed above should prevent the attempt to enter
> that low power mode.
>

this still happens in 2.6.19-rc5 too. In the meantime I have observed that 
those messages appear after warm reboot (i.e. just reboot from running 
system) but booting from poweroff state (or resuming) does not show those 
messages.

I am still interested in said patch :)

- -andrey

> - Dave
>
> > ohci_hcd: 2005 April 22 USB 1.1 'Open' Host Controller (OHCI) Driver
> > (PCI) ohci_hcd: block sizes: ed 64 td 64
> > ACPI: PCI Interrupt Link [LNKG] enabled at IRQ 11
> > ACPI: PCI Interrupt 0000:00:02.0[A] -> Link [LNKG] -> GSI 11 (level, low)
> > -> IRQ 11
> > ohci_hcd 0000:00:02.0: OHCI Host Controller
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file 'devices'
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> > ohci_hcd 0000:00:02.0: new USB bus registered, assigned bus number 1
> > ohci_hcd 0000:00:02.0: created debug files
> > ohci_hcd 0000:00:02.0: irq 11, io mem 0xf7eff000
> > ohci_hcd 0000:00:02.0: resetting from state 'reset', control = 0x0
> > ohci_hcd 0000:00:02.0: enabling initreset quirk
> > ohci_hcd 0000:00:02.0: OHCI controller state
> > ohci_hcd 0000:00:02.0: OHCI 1.0, NO legacy support registers
> > ohci_hcd 0000:00:02.0: control 0x083 HCFS=operational CBSR=3
> > ohci_hcd 0000:00:02.0: cmdstatus 0x00000 SOC=0
> > ohci_hcd 0000:00:02.0: intrstatus 0x00000044 RHSC SF
> > ohci_hcd 0000:00:02.0: intrenable 0x8000000a MIE RD WDH
> > ohci_hcd 0000:00:02.0: hcca frame #0003
> > ohci_hcd 0000:00:02.0: roothub.a 01000203 POTPGT=1 NPS NDP=3(3)
> > ohci_hcd 0000:00:02.0: roothub.b 00000000 PPCM=0000 DR=0000
> > ohci_hcd 0000:00:02.0: roothub.status 00008000 DRWE
> > ohci_hcd 0000:00:02.0: roothub.portstatus [0] 0x00000100 PPS
> > ohci_hcd 0000:00:02.0: roothub.portstatus [1] 0x00000100 PPS
> > ohci_hcd 0000:00:02.0: roothub.portstatus [2] 0x00000100 PPS
> > usb usb1: default language 0x0409
> > usb usb1: new device strings: Mfr=3, Product=2, SerialNumber=1
> > usb usb1: Product: OHCI Host Controller
> > usb usb1: Manufacturer: Linux 2.6.17-2avb ohci_hcd
> > usb usb1: SerialNumber: 0000:00:02.0
> > usb usb1: uevent
> > 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: 3 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: global 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: no over-current condition exists
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > /home/bor/src/linux-git/drivers/usb/core/inode.c: creating file '001'
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000, resume root
> > hub 1-0:1.0: state 7 ports 3 chg 0000 evt 0000
> > ohci_hcd 0000:00:02.0: suspend root hub
>
> .... etc
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFVbOmR6LMutpd94wRAqvhAKCtwi//xhbzR3VtHBjoMTARMd2Q6wCgnZPe
4alxU15SVFHqaenCagCp89E=
=NwAB
-----END PGP SIGNATURE-----

2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Tuesday 20 June 2006 00:12, David Brownell wrote:
> > > > > An alternative (but post-boot) workaround _should_ be
> > > > >
> > > > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
> > >
> > > Did that work?
> >
> > No. But
> >
> > 	echo -n disabled >
> > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup
>
> That's what I meant ... thanks, and sorry for the confusion.

this does not work anymore in current rc5. After writing 
cat /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup shows "disabled" 
but messages continue to be logged.

Anything I can do to help narrow it down?
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFVbQ0R6LMutpd94wRApCwAKCDLKVxGWlE8vyf8sH42wU2RBVxHQCgl0rl
4vRC3bgKflRGboCrzF8YnJY=
=nuLl
-----END PGP SIGNATURE-----

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

On Sat, 11 Nov 2006, Andrey Borzenkov wrote:

> On Tuesday 20 June 2006 00:12, David Brownell wrote:
> > > > > > An alternative (but post-boot) workaround _should_ be
> > > > > >
> > > > > >     echo disabled > /sys/bus/pci/devices/0000:00:02.0/power/wakeup
> > > >
> > > > Did that work?
> > >
> > > No. But
> > >
> > > 	echo -n disabled >
> > > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup
> >
> > That's what I meant ... thanks, and sorry for the confusion.
> 
> this does not work anymore in current rc5. After writing 
> cat /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup shows "disabled" 
> but messages continue to be logged.
> 
> Anything I can do to help narrow it down?

Undoubtedly this change in behavior is caused by the "autostop" code I 
added to ohci-hcd.  It doesn't check the "wakeup" attribute.

Dave, is there any clue about exactly what triggers the immediate wakeup?  
If you could tell me what to test for, I could try writing a patch to fix 
it.  Perhaps the driver needs a "resume_detect_is_broken" quirk.

Andrey, if you aren't using USB at all (you mentioned that no devices were 
plugged in), you can simply do "rmmod ohci-hcd" to stop all those log 
messages.

Alan Stern

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

> > > > 	echo -n disabled >
> > > > /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup
> > >
> > > That's what I meant ... thanks, and sorry for the confusion.
> > 
> > this does not work anymore in current rc5. After writing 
> > cat /sys/devices/pci0000:00/0000:00:02.0/usb1/power/wakeup shows "disabled" 
> > but messages continue to be logged.
> > 
> > Anything I can do to help narrow it down?
>
> Undoubtedly this change in behavior is caused by the "autostop" code I 
> added to ohci-hcd.  It doesn't check the "wakeup" attribute.

That's the basic bug ... it needs to do that, like it does in a 2.6.18
kernel I happen to still have sitting around.


> Dave, is there any clue about exactly what triggers the immediate wakeup?  
> If you could tell me what to test for, I could try writing a patch to fix 
> it.  Perhaps the driver needs a "resume_detect_is_broken" quirk.

It's an implementation bug in some silicon, or in some case some boards.

That's why the original OHCI autosuspend code initialized the "can this
root hub autosuspend" by testing the root hub wakeup flag:

        can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);

and then cleared it if any enabled port wasn't suspended, any schedule
was active, or any deletions were pending.  A quick glance at your new
"autostop" code shows that it only checks whether ports are enabled;
those other important constraints have been removed.

Knowing this is a regression probably explains why that one patch adding
the "broken suspend" board-specific quirk for the Tohsiba Portege 4000
didn't work:  the mechanism it relied on (root hub marked as "can't wakeup")
is broken.

I expect the AMD756 erratum 10 workaround is also broken, since that makes
a point of initializing the root hub so that device_may_wakeup() prevents
the autosuspend mechanism from kicking in.

- Dave

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

On Sun, 12 Nov 2006, David Brownell wrote:

> > Undoubtedly this change in behavior is caused by the "autostop" code I 
> > added to ohci-hcd.  It doesn't check the "wakeup" attribute.
> 
> That's the basic bug ... it needs to do that, like it does in a 2.6.18
> kernel I happen to still have sitting around.

It's not so clear whether this behavior is a bug.  Remember, autostop is 
different from autosuspend.  For instance, the root hub will never be in 
autostop mode during a system sleep (suspend to RAM or suspend to disk) -- 
hence autostop doesn't have to worry about waking up the system.

> > Dave, is there any clue about exactly what triggers the immediate wakeup?  
> > If you could tell me what to test for, I could try writing a patch to fix 
> > it.  Perhaps the driver needs a "resume_detect_is_broken" quirk.
> 
> It's an implementation bug in some silicon, or in some case some boards.
> 
> That's why the original OHCI autosuspend code initialized the "can this
> root hub autosuspend" by testing the root hub wakeup flag:
> 
>         can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> 
> and then cleared it if any enabled port wasn't suspended, any schedule
> was active, or any deletions were pending.

But the silicon or board-level implementation bug you mentioned wouldn't 
cause any of those tests to succeed, would it?  Hence it wouldn't prevent 
an unwanted root-hub suspend.

Or are you trying to say that the original device_may_wakeup() value would 
be 0 if the bug were detected?

>   A quick glance at your new
> "autostop" code shows that it only checks whether ports are enabled;
> those other important constraints have been removed.

No, you must have misread the code.  It retains the checks for active 
schedules or pending deletions.  There's no need to check for unsuspended 
enabled ports, since autostop kicks in only when no ports are enabled.

> Knowing this is a regression probably explains why that one patch adding
> the "broken suspend" board-specific quirk for the Tohsiba Portege 4000
> didn't work:  the mechanism it relied on (root hub marked as "can't wakeup")
> is broken.
> 
> I expect the AMD756 erratum 10 workaround is also broken, since that makes
> a point of initializing the root hub so that device_may_wakeup() prevents
> the autosuspend mechanism from kicking in.

If you think autostop should also check for device_may_wakeup(), I'll make 
it do so.  Remember though that autostop is intended to work even when 
CONFIG_PM is off.

Alan Stern

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

> > That's why the original OHCI autosuspend code initialized the "can this
> > root hub autosuspend" by testing the root hub wakeup flag:
> > 
> >         can_suspend = device_may_wakeup(&hcd->self.root_hub->dev);
> > 
> > and then cleared it if any enabled port wasn't suspended, any schedule
> > was active, or any deletions were pending.
> 
> But the silicon or board-level implementation bug you mentioned wouldn't 
> cause any of those tests to succeed, would it?  Hence it wouldn't prevent 
> an unwanted root-hub suspend.
> 
> Or are you trying to say that the original device_may_wakeup() value would 
> be 0 if the bug were detected?

The latter:  device_may_wakeup() never returns true.  There are three paths
for that:

  (a) userspace workaround, which is the regression that was reported;
  (b) the AMD 756 workaround, and
  (c) that board-specific quirk code.

Of course (c) hasn't been submitted yet because it didn't work ... evidently
because of the regression where device_may_wakeup(root_hub) was ignored.


> >   A quick glance at your new
> > "autostop" code shows that it only checks whether ports are enabled;
> > those other important constraints have been removed.
> 
> No, you must have misread the code.  It retains the checks for active 
> schedules or pending deletions.  There's no need to check for unsuspended 
> enabled ports, since autostop kicks in only when no ports are enabled.

Well, there are at least two regressions then.  One is the one in $SUBJECT,
and the other is for suspended-but-enabled ports.  (You've argued the latter
would be handled by a separate mechanism; fair enough, but I'm pointing
out that it's still a regression.)


> If you think autostop should also check for device_may_wakeup(), I'll make 
> it do so.  Remember though that autostop is intended to work even when 
> CONFIG_PM is off.

The original autosuspend logic would never kick in without PM; after all,
it's purely a power saving mechanism!  And testing device_may_wakeup() will
be restoring that behavior, since without PM that's always false.

- Dave

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

On Sun, 12 Nov 2006, David Brownell wrote:

> > Or are you trying to say that the original device_may_wakeup() value would 
> > be 0 if the bug were detected?
> 
> The latter:  device_may_wakeup() never returns true.  There are three paths
> for that:
> 
>   (a) userspace workaround, which is the regression that was reported;
>   (b) the AMD 756 workaround, and
>   (c) that board-specific quirk code.
> 
> Of course (c) hasn't been submitted yet because it didn't work ... evidently
> because of the regression where device_may_wakeup(root_hub) was ignored.

Well, I would argue that part of the problem has to do with the use of 
device_may_wakeup.  It is tied to a sysfs API and therefore administrative 
in nature, but now you say it's also being used to record hardware quirks.

> > If you think autostop should also check for device_may_wakeup(), I'll make 
> > it do so.  Remember though that autostop is intended to work even when 
> > CONFIG_PM is off.
> 
> The original autosuspend logic would never kick in without PM; after all,
> it's purely a power saving mechanism!  And testing device_may_wakeup() will
> be restoring that behavior, since without PM that's always false.

It would restore that behavior, and it would be silly way of doing so.  
There are better ways to prevent autostop without PM, such as making
ohci_rh_suspend() and ohci_rh_resume() depend on CONFIG_PM!

However it was always my intention that autostop should operate without
PM.  It's not only about saving power, it also is about reducing load on
system resources -- primarily DMA, although this may be a lot less severe
with OHCI than with UHCI.  Does OHCI do any DMA at all when no devices are
plugged in and the schedule is empty?

My quick impression from the spec is that it does not, in which case 
there is no point in keeping autostop when CONFIG_PM is off.

Alan Stern

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

On Monday 13 November 2006 7:57 am, Alan Stern wrote:
> On Sun, 12 Nov 2006, David Brownell wrote:
> 
> > > Or are you trying to say that the original device_may_wakeup() value would 
> > > be 0 if the bug were detected?
> > 
> > The latter:  device_may_wakeup() never returns true.  There are three paths
> > for that:
> > 
> >   (a) userspace workaround, which is the regression that was reported;
> >   (b) the AMD 756 workaround, and
> >   (c) that board-specific quirk code.
> > 
> > Of course (c) hasn't been submitted yet because it didn't work ... evidently
> > because of the regression where device_may_wakeup(root_hub) was ignored.
> 
> Well, I would argue that part of the problem has to do with the use of 
> device_may_wakeup.  It is tied to a sysfs API 

It's a *driver model* API, which is also accessible from sysfs ... to support
per-device policies, for example the (a) workaround.  The mechanism exists
even on kernels that don't include sysfs ... although on such systems, there
is no way for users to do things like say "ignore the fact that this mouse
claims to issue wakeup events, its descriptors lie".


> and therefore administrative  
> in nature, but now you say it's also being used to record hardware quirks.

No; I'm saying the driver model is used to record that the hardware mechanism
isn't available.   The fact that it's because of an implementation artifact
(bad silicon, or board layout, etc) versus a design artifact (silicon designed
without that feature) is immaterial ... in either case, the system can't use
the mechanism.


> > > If you think autostop should also check for device_may_wakeup(), I'll make 
> > > it do so.  Remember though that autostop is intended to work even when 
> > > CONFIG_PM is off.
> > 
> > The original autosuspend logic would never kick in without PM; after all,
> > it's purely a power saving mechanism!  And testing device_may_wakeup() will
> > be restoring that behavior, since without PM that's always false.
> 
> It would restore that behavior, and it would be silly way of doing so.  
> There are better ways to prevent autostop without PM, such as making
> ohci_rh_suspend() and ohci_rh_resume() depend on CONFIG_PM!

ISTR they do that too.  :)

 
> However it was always my intention that autostop should operate without
> PM.  It's not only about saving power, it also is about reducing load on
> system resources -- primarily DMA, although this may be a lot less severe
> with OHCI than with UHCI.  Does OHCI do any DMA at all when no devices are
> plugged in and the schedule is empty?

That's not an issue at all with OHCI; it only DMAs when the relevant
schedule is enabled.  Which it isn't, unless it has work to do.

 
> My quick impression from the spec is that it does not, in which case 
> there is no point in keeping autostop when CONFIG_PM is off.

Exactly.  That's why I said it's purely a power saving mechanism.

- Dave

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

On Mon, 13 Nov 2006, David Brownell wrote:

> > Well, I would argue that part of the problem has to do with the use of 
> > device_may_wakeup.  It is tied to a sysfs API 
> 
> It's a *driver model* API, which is also accessible from sysfs ... to support
> per-device policies, for example the (a) workaround.  The mechanism exists
> even on kernels that don't include sysfs ... although on such systems, there
> is no way for users to do things like say "ignore the fact that this mouse
> claims to issue wakeup events, its descriptors lie".

Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.

> > and therefore administrative  
> > in nature, but now you say it's also being used to record hardware quirks.
> 
> No; I'm saying the driver model is used to record that the hardware mechanism
> isn't available.   The fact that it's because of an implementation artifact
> (bad silicon, or board layout, etc) versus a design artifact (silicon designed
> without that feature) is immaterial ... in either case, the system can't use
> the mechanism.

But the information is being recorded in the wrong spot.  The correct test
should use device_can_wakeup, not device_may_wakeup.  The can_wakeup flag
is the one which records whether or not the hardware mechanism is actually
available.


> > > > If you think autostop should also check for device_may_wakeup(), I'll make 
> > > > it do so.  Remember though that autostop is intended to work even when 
> > > > CONFIG_PM is off.
> > > 
> > > The original autosuspend logic would never kick in without PM; after all,
> > > it's purely a power saving mechanism!  And testing device_may_wakeup() will
> > > be restoring that behavior, since without PM that's always false.
> > 
> > It would restore that behavior, and it would be silly way of doing so.  
> > There are better ways to prevent autostop without PM, such as making
> > ohci_rh_suspend() and ohci_rh_resume() depend on CONFIG_PM!
> 
> ISTR they do that too.  :)

They used to, but I changed it when I added autostop.  Looks like I need 
to change it back.

> > However it was always my intention that autostop should operate without
> > PM.  It's not only about saving power, it also is about reducing load on
> > system resources -- primarily DMA, although this may be a lot less severe
> > with OHCI than with UHCI.  Does OHCI do any DMA at all when no devices are
> > plugged in and the schedule is empty?
> 
> That's not an issue at all with OHCI; it only DMAs when the relevant
> schedule is enabled.  Which it isn't, unless it has work to do.
> 
>  
> > My quick impression from the spec is that it does not, in which case 
> > there is no point in keeping autostop when CONFIG_PM is off.
> 
> Exactly.  That's why I said it's purely a power saving mechanism.

Okay.  I'll write a patch to eliminate autostop and those routines when
CONFIG_PM is off.

But that doesn't answer the question above: Should autostop check 
device_can_wakeup rather than device_may_wakeup?

Also: Does the quirk/bug detection logic clear can_wakeup, as it should?  
Or does it only affect may_wakeup?

Alan Stern

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

Andrey:

Try this patch for 2.6.19-rc5.  Although it doesn't make all the changes 
Dave and I have discussed, it ought to fix your problem.

Alan Stern


Index: 2.6.19-rc5/drivers/usb/host/ohci-hub.c
===================================================================
--- 2.6.19-rc5.orig/drivers/usb/host/ohci-hub.c
+++ 2.6.19-rc5/drivers/usb/host/ohci-hub.c
@@ -422,7 +422,8 @@ ohci_hub_status_data (struct usb_hcd *hc
 				ohci->autostop = 0;
 				ohci->next_statechange = jiffies +
 						STATECHANGE_DELAY;
-			} else if (time_after_eq (jiffies,
+			} else if (device_may_wakeup(&hcd->self.root_hub->dev)
+					&& time_after_eq(jiffies,
 						ohci->next_statechange)
 					&& !ohci->ed_rm_list
 					&& !(ohci->hc_control &

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Andrey Borzenkov]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Monday 13 November 2006 22:58, Alan Stern wrote:
> Andrey:
>
> Try this patch for 2.6.19-rc5.  Although it doesn't make all the changes
> Dave and I have discussed, it ought to fix your problem.
>

It did. Thank you

- -andrey

> Alan Stern
>
>
> Index: 2.6.19-rc5/drivers/usb/host/ohci-hub.c
> ===================================================================
> --- 2.6.19-rc5.orig/drivers/usb/host/ohci-hub.c
> +++ 2.6.19-rc5/drivers/usb/host/ohci-hub.c
> @@ -422,7 +422,8 @@ ohci_hub_status_data (struct usb_hcd *hc
>  				ohci->autostop = 0;
>  				ohci->next_statechange = jiffies +
>  						STATECHANGE_DELAY;
> -			} else if (time_after_eq (jiffies,
> +			} else if (device_may_wakeup(&hcd->self.root_hub->dev)
> +					&& time_after_eq(jiffies,
>  						ohci->next_statechange)
>  					&& !ohci->ed_rm_list
>  					&& !(ohci->hc_control &
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (GNU/Linux)

iD8DBQFFWiueR6LMutpd94wRAu9JAKC/IXuGi+NvXx+O9zwDwaJI3AXqXQCfTF/I
jzkfD8gsU+JgYlqWkzQ2Pis=
=ckCE
-----END PGP SIGNATURE-----

Re: [Bulk] Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

On Tuesday 14 November 2006 12:48 pm, Andrey Borzenkov wrote:
> On Monday 13 November 2006 22:58, Alan Stern wrote:
> > Andrey:
> >
> > Try this patch for 2.6.19-rc5.  Although it doesn't make all the changes
> > Dave and I have discussed, it ought to fix your problem.
> >
> 
> It did. Thank you

Then this should get merged into 2.6.19-rc ASAP ...

- Dave


> -andrey
> 
> > Alan Stern
> >
> >
> > Index: 2.6.19-rc5/drivers/usb/host/ohci-hub.c
> > ===================================================================
> > --- 2.6.19-rc5.orig/drivers/usb/host/ohci-hub.c
> > +++ 2.6.19-rc5/drivers/usb/host/ohci-hub.c
> > @@ -422,7 +422,8 @@ ohci_hub_status_data (struct usb_hcd *hc
> >  				ohci->autostop = 0;
> >  				ohci->next_statechange = jiffies +
> >  						STATECHANGE_DELAY;
> > -			} else if (time_after_eq (jiffies,
> > +			} else if (device_may_wakeup(&hcd->self.root_hub->dev)
> > +					&& time_after_eq(jiffies,
> >  						ohci->next_statechange)
> >  					&& !ohci->ed_rm_list
> >  					&& !(ohci->hc_control &
> 

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> On Mon, 13 Nov 2006, David Brownell wrote:
> 
> > It's a *driver model* API, which is also accessible from sysfs ... to support
> > per-device policies, for example the (a) workaround.  The mechanism exists
> > even on kernels that don't include sysfs ... although on such systems, there
> > is no way for users to do things like say "ignore the fact that this mouse
> > claims to issue wakeup events, its descriptors lie".
> 
> Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.

I can't agree.  If you deconfigure sysfs, it still works.
Since it's independent like that, there's no way it's "tied".


> > > and therefore administrative  
> > > in nature, but now you say it's also being used to record hardware quirks.
> > 
> > No; I'm saying the driver model is used to record that the hardware mechanism
> > isn't available.   The fact that it's because of an implementation artifact
> > (bad silicon, or board layout, etc) versus a design artifact (silicon designed
> > without that feature) is immaterial ... in either case, the system can't use
> > the mechanism.
> 
> But the information is being recorded in the wrong spot.  The correct test
> should use device_can_wakeup, not device_may_wakeup.  The can_wakeup flag
> is the one which records whether or not the hardware mechanism is actually
> available.

Go look again.  "may" implies (i) can , and (ii) should.  So if there's a
hardware quirk registered, (i) always fails.  And in the not-uncommon case
where the device misbehavior isn't known to the kernel, userspace has the
option of making (ii) kick in (the workaround mentioned above).  This is a
generic approach, it works on all wakeup-capable devices.

So "may" is correct, and "can" is insufficient.



> Okay.  I'll write a patch to eliminate autostop and those routines when
> CONFIG_PM is off.
> 
> But that doesn't answer the question above: Should autostop check 
> device_can_wakeup rather than device_may_wakeup?

See above, and the definition of may_wakeup().


> Also: Does the quirk/bug detection logic clear can_wakeup, as it should?  
> Or does it only affect may_wakeup?

See above.  Quirks directly recognized by the kernel clear can_wakeup.
Ones that are reported via userspace clear should_wakeup.  Either suffices
to ensure that the may_wakeup() predicate fails.

- Dave

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[Alan Stern]

On Tue, 14 Nov 2006, David Brownell wrote:

> On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> > On Mon, 13 Nov 2006, David Brownell wrote:
> > 
> > > It's a *driver model* API, which is also accessible from sysfs ... to support
> > > per-device policies, for example the (a) workaround.  The mechanism exists
> > > even on kernels that don't include sysfs ... although on such systems, there
> > > is no way for users to do things like say "ignore the fact that this mouse
> > > claims to issue wakeup events, its descriptors lie".
> > 
> > Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.
> 
> I can't agree.  If you deconfigure sysfs, it still works.
> Since it's independent like that, there's no way it's "tied".

We could carry on this argument indefinitely.  Yes, the device_may_wakeup
stuff does work without sysfs.  But it doesn't do anything significant; it
amounts to no more than device_can_wakeup().  AFAIK there's no way to
change the setting of the may_wakeup flag other than via sysfs.  That's
what I meant by "tied".

> > > No; I'm saying the driver model is used to record that the hardware mechanism
> > > isn't available.   The fact that it's because of an implementation artifact
> > > (bad silicon, or board layout, etc) versus a design artifact (silicon designed
> > > without that feature) is immaterial ... in either case, the system can't use
> > > the mechanism.
> > 
> > But the information is being recorded in the wrong spot.  The correct test
> > should use device_can_wakeup, not device_may_wakeup.  The can_wakeup flag
> > is the one which records whether or not the hardware mechanism is actually
> > available.
> 
> Go look again.  "may" implies (i) can , and (ii) should.  So if there's a
> hardware quirk registered, (i) always fails.  And in the not-uncommon case
> where the device misbehavior isn't known to the kernel, userspace has the
> option of making (ii) kick in (the workaround mentioned above).  This is a
> generic approach, it works on all wakeup-capable devices.
> 
> So "may" is correct, and "can" is insufficient.

Things work differently in uhci-hcd.  I still haven't submitted the patch 
to add device_may_wakeup support (although it was written quite a while 
ago and may have been posted to linux-usb-devel; I can't remember).

However even when it is added and may_wakeup is off, autostop will still 
function.  It won't rely on interrupts or other wakeup events, though -- 
instead the root-hub status polling mechanism will be used.

Alan Stern

Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs

[David Brownell]

On Tuesday 14 November 2006 1:42 pm, Alan Stern wrote:
> On Tue, 14 Nov 2006, David Brownell wrote:
> 
> > On Monday 13 November 2006 9:15 am, Alan Stern wrote:
> > > On Mon, 13 Nov 2006, David Brownell wrote:
> > > 
> > > > It's a *driver model* API, which is also accessible from sysfs ... to support
> > > > per-device policies, for example the (a) workaround.  The mechanism exists
> > > > even on kernels that don't include sysfs ... although on such systems, there
> > > > is no way for users to do things like say "ignore the fact that this mouse
> > > > claims to issue wakeup events, its descriptors lie".
> > > 
> > > Yes, it is separate from sysfs -- but it is _tied_ to the sysfs API.
> > 
> > I can't agree.  If you deconfigure sysfs, it still works.
> > Since it's independent like that, there's no way it's "tied".
> 
> We could carry on this argument indefinitely.  Yes, the device_may_wakeup
> stuff does work without sysfs.  But it doesn't do anything significant; it
> amounts to no more than device_can_wakeup().  AFAIK there's no way to
> change the setting of the may_wakeup flag other than via sysfs.  That's
> what I meant by "tied".

So "tied" means "nobody has yet needed to create a different API for
that subset of the mechanism"?  Still can't agree.  Nothing's preventing
anyone from creating such an API, if they need to.


> > So "may" is correct, and "can" is insufficient.
> 
> Things work differently in uhci-hcd. 

They shouldn't.  That's the point of having this in the driver model:
so that all wakeup-capable devices can/will act the same in terms of
the basic capability and policy.

(Of course, there are ugly PPC/OF-only enumeration issues that keep us
from kicking in the wakeup mechanisms for PCI devices.  But that's a
separate issue, specific to PCI ... although it sucks hugely, since
so few developers have non-PCI wakeup-capable devices.)


> However even when it is added and may_wakeup is off, autostop will still 
> function.  It won't rely on interrupts or other wakeup events, though -- 
> instead the root-hub status polling mechanism will be used.

Well, as was said previously:  For UHCI it's not "just" a PM mechanism.

- Dave