Help!

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

 
Goto page 1, 2
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> Kernel (archive) RSS
Next:  [PATCHSET] Announce: High-res timers, tickless/dy..  
Author Message
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Sun Jun 18, 2006 9:30 pm    Post subject: 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup"
Archived from groups: linux>kernel (more info?)

-----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 0Cool
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 $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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Sun Jun 18, 2006 10:40 pm    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Sun Jun 18, 2006 11:30 pm    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----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 $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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Mon Jun 19, 2006 12:30 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Mon Jun 19, 2006 1:30 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

> > 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 Sad
I guess I run 2.6.16 for a while Smile

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

iD8DBQFElagVR6LMutpd94wRAkKvAJ9qZcf/fmo3lKAi3l/h0HtAYdVO7wCePfeM
kzJnCu8kzX5PjHFud837ShU=
=s5Wm
-----END PGP SIGNATURE-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Tue Jun 20, 2006 12:40 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Tue Jun 20, 2006 2:20 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

> > > > 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.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Sat Sep 23, 2006 1:00 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Sat Sep 23, 2006 3:00 am    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Sat Nov 11, 2006 5:30 pm    Post subject: Re: [linux-usb-devel] 2.6.17: dmesg flooded with "ohci_hcd 0000:00:02.0: wakeup" [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

- -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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Sat Nov 11, 2006 5:30 pm    Post subject: 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Sun Nov 12, 2006 10:40 pm    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Mon Nov 13, 2006 12:10 am    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Mon Nov 13, 2006 4:00 am    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Mon Nov 13, 2006 5:30 am    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

> > 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Mon Nov 13, 2006 10:00 pm    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
David Brownell
External


Since: Mar 16, 2005
Posts: 483



PostPosted: Mon Nov 13, 2006 10:40 pm    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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


> 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
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Mon Nov 13, 2006 11:20 pm    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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

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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Alan Stern
External


Since: May 20, 2006
Posts: 562



PostPosted: Tue Nov 14, 2006 2:00 am    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

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 &

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Andrey Borzenkov
External


Since: May 27, 2006
Posts: 72



PostPosted: Wed Nov 15, 2006 2:50 am    Post subject: Re: [linux-usb-devel] 2.6.19-rc5 regression: can't disable OHCI wakeup via sysfs [Login to view extended thread Info.]
Archived from groups: per prev. post (more info?)

-----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-----
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Back to top
Display posts from previous:   
Post new topic   General Reply to Topic (not reply to a specific post)    Forums Home -> Kernel (archive) All times are: Eastern Time (US & Canada)
Goto page 1, 2
Page 1 of 2

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