2.6.25-rc7: Ugh.
Subsystems (4)
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.
The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhid
And the console hung at 100% CPU on the insmod. Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:
Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
Suspend/Resume have worked perfectly (after kernel fixes, mostly USB) for all kernels in the past since 2.6.20 or so.
Here's the /var/log/messages from the suspend/resume. That's it for now. I've got work to do, and I'm tired of seeing this break with each new revision.
logger: /usr/local/bin/suspend.sh kernel: [ 107.491762] PM: Syncing filesystems ... done.
kernel: [ 107.492274] Freezing user space processes ... (elapsed 0.00 seconds) done.
kernel: [ 107.493016] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
kernel: [ 107.499129] ACPI: Preparing to enter system sleep state S3
kernel: [ 107.499656] Suspending console(s)
kernel: [ 107.524879] b44: eth0: powering down PHY
kernel: [ 108.011326] sd 0:0:0:0: [sda] Synchronizing SCSI cache
kernel: [ 108.011473] sd 0:0:0:0: [sda] Stopping disk
kernel: [ 110.058446] pciehp_suspend ENTRY
last message repeated 2 times
kernel: [ 110.058446] ricoh-mmc: Suspending.
kernel: [ 110.058446] ricoh-mmc: Controller is now re-enabled.
kernel: [ 110.058446] ACPI handle has no context!
kernel: [ 110.058446] ACPI: PCI interrupt for device 0000:03:01.1 disabled
kernel: [ 110.058446] ACPI handle has no context!
kernel: [ 110.089544] ACPI: PCI interrupt for device 0000:03:00.0 disabled
kernel: [ 110.089554] ACPI handle has no context!
kernel: [ 110.102988] ACPI: PCI interrupt for device 0000:00:1f.2 disabled
kernel: [ 110.116231] ACPI: PCI interrupt for device 0000:00:1d.7 disabled
kernel: [ 110.129385] ACPI: PCI interrupt for device 0000:00:1d.3 disabled
kernel: [ 110.129433] ACPI: PCI interrupt for device 0000:00:1d.2 disabled
kernel: [ 110.129480] ACPI: PCI interrupt for device 0000:00:1d.1 disabled
kernel: [ 110.129526] ACPI: PCI interrupt for device 0000:00:1d.0 disabled
kernel: [ 110.129533] pciehp_suspend ENTRY
kernel: [ 110.129601] pciehp_suspend ENTRY
kernel: [ 110.129668] pciehp_suspend ENTRY
kernel: [ 110.142697] ACPI: PCI interrupt for device 0000:00:1b.0 disabled
kernel: [ 110.155936] Disabling non-boot CPUs ...
kernel: [ 110.159155] CPU 1 is now offline
kernel: [ 110.159159] SMP alternatives: switching to UP code
kernel: [ 110.161085] CPU1 is down
kernel: [ 110.161085] Back to C!
kernel: [ 110.161498] Enabling non-boot CPUs ...
kernel: [ 110.161854] SMP alternatives: switching to SMP code
kernel: [ 110.162467] Booting processor 1/1 ip 4000
kernel: [ 110.162471] CPU 1 irqstacks, hard=c037f000 soft=c037d000
kernel: [ 111.314889] Initializing CPU#1
kernel: [ 111.314889] Calibrating delay using timer specific routine.. 4321.52 BogoMIPS (lpj=7199246)
kernel: [ 111.314889] CPU: L1 I cache: 32K, L1 D cache: 32K
kernel: [ 111.314889] CPU: L2 cache: 4096K
kernel: [ 111.314889] CPU: Physical Processor ID: 0
kernel: [ 111.314889] CPU: Processor Core ID: 1
kernel: [ 110.256366] CPU1: Intel(R) Core(TM)2 CPU T7400 @ 2.16GHz stepping 06
kernel: [ 111.314889] CPU1 is up
kernel: [ 111.314896] Switched to high resolution mode on CPU 1
kernel: [ 111.349610] PM: Writing back config space on device 0000:00:01.0 at offset a (was f, writing 0)
kernel: [ 111.349618] PM: Writing back config space on device 0000:00:01.0 at offset 3 (was 10000, writing 10010)
kernel: [ 111.349629] PCI: Setting latency timer of device 0000:00:01.0 to 64
kernel: [ 111.360769] PM: Writing back config space on device 0000:00:1b.0 at offset f (was 100, writing 10b)
kernel: [ 111.360795] PM: Writing back config space on device 0000:00:1b.0 at offset 4 (was ffa7c004, writing efffc004)
kernel: [ 111.360804] PM: Writing back config space on device 0000:00:1b.0 at offset 3 (was 0, writing 10)
kernel: [ 111.360814] PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100000, writing 100102)
kernel: [ 111.360845] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21
kernel: [ 111.360856] PCI: Setting latency timer of device 0000:00:1b.0 to 64
kernel: [ 111.360892] PM: Writing back config space on device 0000:00:1c.0 at offset f (was 100, writing 20100)
kernel: [ 111.360910] PM: Writing back config space on device 0000:00:1c.0 at offset 9 (was 10001, writing 1fff1)
kernel: [ 111.360917] PM: Writing back config space on device 0000:00:1c.0 at offset 8 (was 0, writing fff0)
kernel: [ 111.360925] PM: Writing back config space on device 0000:00:1c.0 at offset 7 (was 0, writing 200000f0)
kernel: [ 111.360932] PM: Writing back config space on device 0000:00:1c.0 at offset 6 (was 0, writing b0b00)
kernel: [ 111.360944] PM: Writing back config space on device 0000:00:1c.0 at offset 3 (was 810000, writing 810010)
kernel: [ 111.360954] PM: Writing back config space on device 0000:00:1c.0 at offset 1 (was 100000, writing 100007)
kernel: [ 111.360982] PCI: Setting latency timer of device 0000:00:1c.0 to 64
kernel: [ 111.360989] pciehp_resume ENTRY
kernel: [ 111.361035] PM: Writing back config space on device 0000:00:1c.1 at offset f (was 200, writing 20200)
kernel: [ 111.361047] PM: Writing back config space on device 0000:00:1c.1 at offset 9 (was 10001, writing 1fff1)
kernel: [ 111.361052] PM: Writing back config space on device 0000:00:1c.1 at offset 8 (was 0, writing efc0efc0)
kernel: [ 111.361056] PM: Writing back config space on device 0000:00:1c.1 at offset 7 (was 20000000, writing 200000f0)
kernel: [ 111.361061] PM: Writing back config space on device 0000:00:1c.1 at offset 6 (was 0, writing c0c00)
kernel: [ 111.361068] PM: Writing back config space on device 0000:00:1c.1 at offset 3 (was 810000, writing 810010)
kernel: [ 111.361075] PM: Writing back config space on device 0000:00:1c.1 at offset 1 (was 100000, writing 100107)
kernel: [ 111.361095] PCI: Setting latency timer of device 0000:00:1c.1 to 64
kernel: [ 111.361099] pciehp_resume ENTRY
kernel: [ 112.362047] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 112.362052] pciehp: Cannot add device 0xc:0
kernel: [ 112.362085] PM: Writing back config space on device 0000:00:1c.3 at offset f (was 400, writing 20400)
kernel: [ 112.362102] PM: Writing back config space on device 0000:00:1c.3 at offset 9 (was 10001, writing e011e001)
kernel: [ 112.362110] PM: Writing back config space on device 0000:00:1c.3 at offset 8 (was 0, writing efb0efa0)
kernel: [ 112.362117] PM: Writing back config space on device 0000:00:1c.3 at offset 7 (was 0, writing d0d0)
kernel: [ 112.362125] PM: Writing back config space on device 0000:00:1c.3 at offset 6 (was 0, writing e0d00)
kernel: [ 112.362136] PM: Writing back config space on device 0000:00:1c.3 at offset 3 (was 810000, writing 810010)
kernel: [ 112.362146] PM: Writing back config space on device 0000:00:1c.3 at offset 1 (was 100000, writing 100007)
kernel: [ 112.362174] PCI: Setting latency timer of device 0000:00:1c.3 to 64
kernel: [ 112.362181] pciehp_resume ENTRY
kernel: [ 112.362213] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 20
kernel: [ 112.362222] PCI: Setting latency timer of device 0000:00:1d.0 to 64
kernel: [ 112.362287] usb usb1: root hub lost power or was reset
kernel: [ 112.362311] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
kernel: [ 112.362316] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 21
kernel: [ 112.362326] PCI: Setting latency timer of device 0000:00:1d.1 to 64
kernel: [ 112.362335] PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20b)
kernel: [ 112.362353] PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing bf61)
kernel: [ 112.362399] usb usb2: root hub lost power or was reset
kernel: [ 112.362421] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
kernel: [ 112.362426] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, low) -> IRQ 22
kernel: [ 112.362436] PCI: Setting latency timer of device 0000:00:1d.2 to 64
kernel: [ 112.362445] PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 309)
kernel: [ 112.362464] PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing bf41)
kernel: [ 112.362509] usb usb3: root hub lost power or was reset
kernel: [ 112.362532] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
kernel: [ 112.362537] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, low) -> IRQ 23
kernel: [ 112.362547] PCI: Setting latency timer of device 0000:00:1d.3 to 64
kernel: [ 112.362556] PM: Writing back config space on device 0000:00:1d.3 at offset f (was 400, writing 407)
kernel: [ 112.362574] PM: Writing back config space on device 0000:00:1d.3 at offset 8 (was 1, writing bf21)
kernel: [ 112.362619] usb usb4: root hub lost power or was reset
kernel: [ 112.375278] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 20
kernel: [ 112.375286] PCI: Setting latency timer of device 0000:00:1d.7 to 64
kernel: [ 112.375379] PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 100f1, writing 1fff1)
kernel: [ 112.375390] PM: Writing back config space on device 0000:00:1e.0 at offset 8 (was 90, writing ef90ef90)
kernel: [ 112.375400] PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was 2280e0f0, writing 228000f0)
kernel: [ 112.375418] PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100007, writing 100107)
kernel: [ 112.375446] PCI: Setting latency timer of device 0000:00:1e.0 to 64
kernel: [ 112.375495] PM: Writing back config space on device 0000:00:1f.0 at offset 1 (was 2100007, writing 2100107)
kernel: [ 112.388552] PM: Writing back config space on device 0000:00:1f.2 at offset f (was 200, writing 205)
kernel: [ 112.388602] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 17
kernel: [ 112.388610] PCI: Setting latency timer of device 0000:00:1f.2 to 64
kernel: [ 112.388636] PM: Writing back config space on device 0000:00:1f.3 at offset f (was 200, writing 205)
kernel: [ 111.330331] ata2.00: _GTF evaluation failed (AE 0x1001)
kernel: [ 111.330331] ata2.01: _GTF evaluation failed (AE 0x1001)
kernel: [ 112.388678] PM: Writing back config space on device 0000:00:1f.3 at offset 1 (was 2800001, writing 2800101)
kernel: [ 112.388751] PM: Writing back config space on device 0000:01:00.0 at offset f (was 1ff, writing 104)
kernel: [ 112.388838] PM: Writing back config space on device 0000:01:00.0 at offset 3 (was 0, writing 10)
kernel: [ 111.330331] ata1.01: _GTF evaluation failed (AE 0x1001)
kernel: [ 112.417656] PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
kernel: [ 112.417662] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
kernel: [ 112.417677] PM: Writing back config space on device 0000:03:00.0 at offset f (was 100, writing 105)
kernel: [ 112.417702] PM: Writing back config space on device 0000:03:00.0 at offset 4 (was 0, writing ef9fe000)
kernel: [ 112.417710] PM: Writing back config space on device 0000:03:00.0 at offset 3 (was 0, writing 4000)
kernel: [ 112.417720] PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100002, writing 100106)
kernel: [ 112.431706] PM: Writing back config space on device 0000:03:01.0 at offset f (was 4020100, writing 4020103)
kernel: [ 112.431734] PM: Writing back config space on device 0000:03:01.0 at offset 4 (was 0, writing ef9fd800)
kernel: [ 112.431742] PM: Writing back config space on device 0000:03:01.0 at offset 3 (was 800000, writing 804000)
kernel: [ 112.431751] PM: Writing back config space on device 0000:03:01.0 at offset 1 (was 2100000, writing 2100106)
kernel: [ 112.517139] PM: Writing back config space on device 0000:03:01.1 at offset f (was 200, writing 209)
kernel: [ 112.517168] PM: Writing back config space on device 0000:03:01.1 at offset 4 (was 0, writing ef9fd400)
kernel: [ 112.517176] PM: Writing back config space on device 0000:03:01.1 at offset 3 (was 800000, writing 804000)
kernel: [ 112.517186] PM: Writing back config space on device 0000:03:01.1 at offset 1 (was 2100000, writing 2100106)
kernel: [ 112.517211] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, low) -> IRQ 18
kernel: [ 112.517234] ricoh-mmc: Resuming.
kernel: [ 112.517245] ricoh-mmc: Controller is now disabled.
kernel: [ 112.517259] PM: Writing back config space on device 0000:03:01.3 at offset f (was 200, writing 209)
kernel: [ 112.517286] PM: Writing back config space on device 0000:03:01.3 at offset 4 (was 0, writing ef9fd700)
kernel: [ 112.517298] PM: Writing back config space on device 0000:03:01.3 at offset 1 (was 2100000, writing 2100102)
kernel: [ 112.517382] pciehp_resume ENTRY
kernel: [ 112.517410] pciehp_resume ENTRY
kernel: [ 111.839425] ata2.00: configured for UDMA/33
kernel: [ 113.520191] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 113.520197] pciehp: Cannot add device 0xc:0
kernel: [ 113.520214] pciehp_resume ENTRY
kernel: [ 113.520461] sd 0:0:0:0: [sda] Starting disk
kernel: [ 113.727280] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded
kernel: [ 113.746993] ata1.00: configured for UDMA/133
kernel: [ 113.770650] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
kernel: [ 113.770650] sd 0:0:0:0: [sda] Write Protect is off
kernel: [ 113.770650] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
kernel: [ 113.770650] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA
kernel: [ 114.901667] Restarting tasks ... <6>usb 5-1: USB disconnect, address 2
kernel: [ 114.933424] done.
kernel: [ 115.128131] usb 5-1: new high speed USB device using ehci_hcd and address 5
## Note: these are "normal" and harmless on this machine,
## and the reason for them has never been tracked down:
kernel: [ 115.198514] Uhhuh. NMI received for unknown reason 90 on CPU 0.
kernel: [ 115.198519] You have some hardware problem, likely on the PCI bus.
kernel: [ 115.198521] Dazed and confused, but trying to continue
kernel: [ 117.690742] b44: eth0: Link is up at 100 Mbps, full duplex.
kernel: [ 117.690750] b44: eth0: Flow control is off for TX and off for RX. login[3020]: (pam_unix) session opened for user root by (uid=0) login[4507]: ROOT LOGIN on 'tty1'
root: reloading usbhid module
kernel: [ 225.955054] usbcore: deregistering interface driver usbhid
kernel: [ 225.966118] usbcore: deregistering interface driver hiddev
root: session hung on insmod
kernel: [ 248.875843] SysRq : Emergency Sync
kernel: [ 248.876629] Emergency Sync complete
kernel: [ 249.535815] SysRq : Emergency Remount R/O
Quoted 3 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
That's not good, why not tell the linux-usb developers this? (added to the cc:)
Quoted 7 lines
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.
Quoted 6 lines
The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod.
Haven't heard of this one before sorry. Jiri, have you?
Quoted 255 lines
Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
Suspend/Resume have worked perfectly (after kernel fixes, mostly USB) for all kernels in the past since 2.6.20 or so.
Here's the
/var/log/messagesfrom the suspend/resume. That's it for now. I've got work to do, and I'm tired of seeing this break with each new revision.logger:
/usr/local/bin/suspend.shkernel: [ 107.491762] PM: Syncing filesystems ... done.
kernel: [ 107.492274] Freezing user space processes ... (elapsed 0.00 seconds) done.
kernel: [ 107.493016] Freezing remaining freezable tasks ... (elapsed 0.00 seconds) done.
kernel: [ 107.499129] ACPI: Preparing to enter system sleep state S3
kernel: [ 107.499656] Suspending console(s)
kernel: [ 107.524879] b44: eth0: powering down PHY
kernel: [ 108.011326] sd 0:0:0:0: [sda] Synchronizing SCSI cache
kernel: [ 108.011473] sd 0:0:0:0: [sda] Stopping disk
kernel: [ 110.058446]pciehp_suspendENTRY
last message repeated 2 times
kernel: [ 110.058446] ricoh-mmc: Suspending.
kernel: [ 110.058446] ricoh-mmc: Controller is now re-enabled.
kernel: [ 110.058446] ACPI handle has no context!
kernel: [ 110.058446] ACPI: PCI interrupt for device 0000:03:01.1 disabled
kernel: [ 110.058446] ACPI handle has no context!
kernel: [ 110.089544] ACPI: PCI interrupt for device 0000:03:00.0 disabled
kernel: [ 110.089554] ACPI handle has no context!
kernel: [ 110.102988] ACPI: PCI interrupt for device 0000:00:1f.2 disabled
kernel: [ 110.116231] ACPI: PCI interrupt for device 0000:00:1d.7 disabled
kernel: [ 110.129385] ACPI: PCI interrupt for device 0000:00:1d.3 disabled
kernel: [ 110.129433] ACPI: PCI interrupt for device 0000:00:1d.2 disabled
kernel: [ 110.129480] ACPI: PCI interrupt for device 0000:00:1d.1 disabled
kernel: [ 110.129526] ACPI: PCI interrupt for device 0000:00:1d.0 disabled
kernel: [ 110.129533]pciehp_suspendENTRY
kernel: [ 110.129601]pciehp_suspendENTRY
kernel: [ 110.129668]pciehp_suspendENTRY
kernel: [ 110.142697] ACPI: PCI interrupt for device 0000:00:1b.0 disabled
kernel: [ 110.155936] Disabling non-boot CPUs ...
kernel: [ 110.159155] CPU 1 is now offline
kernel: [ 110.159159] SMP alternatives: switching to UP code
kernel: [ 110.161085] CPU1 is down
kernel: [ 110.161085] Back to C!
kernel: [ 110.161498] Enabling non-boot CPUs ...
kernel: [ 110.161854] SMP alternatives: switching to SMP code
kernel: [ 110.162467] Booting processor 1/1 ip 4000
kernel: [ 110.162471] CPU 1 irqstacks, hard=c037f000 soft=c037d000
kernel: [ 111.314889] Initializing CPU#1
kernel: [ 111.314889] Calibrating delay using timer specific routine.. 4321.52 BogoMIPS (lpj=7199246)
kernel: [ 111.314889] CPU: L1 I cache: 32K, L1 D cache: 32K
kernel: [ 111.314889] CPU: L2 cache: 4096K
kernel: [ 111.314889] CPU: Physical Processor ID: 0
kernel: [ 111.314889] CPU: Processor Core ID: 1
kernel: [ 110.256366] CPU1: Intel(R) Core(TM)2 CPU T7400 @
2.16GHz stepping 06
kernel: [ 111.314889] CPU1 is up
kernel: [ 111.314896] Switched to high resolution mode on CPU 1
kernel: [ 111.349610] PM: Writing back config space on device 0000:00:01.0 at offset a (was f, writing 0)
kernel: [ 111.349618] PM: Writing back config space on device 0000:00:01.0 at offset 3 (was 10000, writing 10010)
kernel: [ 111.349629] PCI: Setting latency timer of device 0000:00:01.0 to 64
kernel: [ 111.360769] PM: Writing back config space on device 0000:00:1b.0 at offset f (was 100, writing 10b)
kernel: [ 111.360795] PM: Writing back config space on device 0000:00:1b.0 at offset 4 (wasffa7c004, writingefffc004)
kernel: [ 111.360804] PM: Writing back config space on device 0000:00:1b.0 at offset 3 (was 0, writing 10)
kernel: [ 111.360814] PM: Writing back config space on device 0000:00:1b.0 at offset 1 (was 100000, writing 100102)
kernel: [ 111.360845] ACPI: PCI Interrupt 0000:00:1b.0[A] -> GSI 21 (level, low) -> IRQ 21
kernel: [ 111.360856] PCI: Setting latency timer of device 0000:00:1b.0 to 64
kernel: [ 111.360892] PM: Writing back config space on device 0000:00:1c.0 at offset f (was 100, writing 20100)
kernel: [ 111.360910] PM: Writing back config space on device 0000:00:1c.0 at offset 9 (was 10001, writing 1fff1)
kernel: [ 111.360917] PM: Writing back config space on device 0000:00:1c.0 at offset 8 (was 0, writing fff0)
kernel: [ 111.360925] PM: Writing back config space on device 0000:00:1c.0 at offset 7 (was 0, writing200000f0)
kernel: [ 111.360932] PM: Writing back config space on device 0000:00:1c.0 at offset 6 (was 0, writing b0b00)
kernel: [ 111.360944] PM: Writing back config space on device 0000:00:1c.0 at offset 3 (was 810000, writing 810010)
kernel: [ 111.360954] PM: Writing back config space on device 0000:00:1c.0 at offset 1 (was 100000, writing 100007)
kernel: [ 111.360982] PCI: Setting latency timer of device 0000:00:1c.0 to 64
kernel: [ 111.360989]pciehp_resumeENTRY
kernel: [ 111.361035] PM: Writing back config space on device 0000:00:1c.1 at offset f (was 200, writing 20200)
kernel: [ 111.361047] PM: Writing back config space on device 0000:00:1c.1 at offset 9 (was 10001, writing 1fff1)
kernel: [ 111.361052] PM: Writing back config space on device 0000:00:1c.1 at offset 8 (was 0, writingefc0efc0)
kernel: [ 111.361056] PM: Writing back config space on device 0000:00:1c.1 at offset 7 (was 20000000, writing200000f0)
kernel: [ 111.361061] PM: Writing back config space on device 0000:00:1c.1 at offset 6 (was 0, writing c0c00)
kernel: [ 111.361068] PM: Writing back config space on device 0000:00:1c.1 at offset 3 (was 810000, writing 810010)
kernel: [ 111.361075] PM: Writing back config space on device 0000:00:1c.1 at offset 1 (was 100000, writing 100107)
kernel: [ 111.361095] PCI: Setting latency timer of device 0000:00:1c.1 to 64
kernel: [ 111.361099]pciehp_resumeENTRY
kernel: [ 112.362047] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 112.362052] pciehp: Cannot add device 0xc:0
kernel: [ 112.362085] PM: Writing back config space on device 0000:00:1c.3 at offset f (was 400, writing 20400)
kernel: [ 112.362102] PM: Writing back config space on device 0000:00:1c.3 at offset 9 (was 10001, writinge011e001)
kernel: [ 112.362110] PM: Writing back config space on device 0000:00:1c.3 at offset 8 (was 0, writingefb0efa0)
kernel: [ 112.362117] PM: Writing back config space on device 0000:00:1c.3 at offset 7 (was 0, writing d0d0)
kernel: [ 112.362125] PM: Writing back config space on device 0000:00:1c.3 at offset 6 (was 0, writing e0d00)
kernel: [ 112.362136] PM: Writing back config space on device 0000:00:1c.3 at offset 3 (was 810000, writing 810010)
kernel: [ 112.362146] PM: Writing back config space on device 0000:00:1c.3 at offset 1 (was 100000, writing 100007)
kernel: [ 112.362174] PCI: Setting latency timer of device 0000:00:1c.3 to 64
kernel: [ 112.362181]pciehp_resumeENTRY
kernel: [ 112.362213] ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 20 (level, low) -> IRQ 20
kernel: [ 112.362222] PCI: Setting latency timer of device 0000:00:1d.0 to 64
kernel: [ 112.362287] usb usb1: root hub lost power or was reset
kernel: [ 112.362311] PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
kernel: [ 112.362316] ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 21 (level, low) -> IRQ 21
kernel: [ 112.362326] PCI: Setting latency timer of device 0000:00:1d.1 to 64
kernel: [ 112.362335] PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20b)
kernel: [ 112.362353] PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing bf61)
kernel: [ 112.362399] usb usb2: root hub lost power or was reset
kernel: [ 112.362421] PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
kernel: [ 112.362426] ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 22 (level, low) -> IRQ 22
kernel: [ 112.362436] PCI: Setting latency timer of device 0000:00:1d.2 to 64
kernel: [ 112.362445] PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 309)
kernel: [ 112.362464] PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing bf41)
kernel: [ 112.362509] usb usb3: root hub lost power or was reset
kernel: [ 112.362532] PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
kernel: [ 112.362537] ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 23 (level, low) -> IRQ 23
kernel: [ 112.362547] PCI: Setting latency timer of device 0000:00:1d.3 to 64
kernel: [ 112.362556] PM: Writing back config space on device 0000:00:1d.3 at offset f (was 400, writing 407)
kernel: [ 112.362574] PM: Writing back config space on device 0000:00:1d.3 at offset 8 (was 1, writing bf21)
kernel: [ 112.362619] usb usb4: root hub lost power or was reset
kernel: [ 112.375278] ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 20 (level, low) -> IRQ 20
kernel: [ 112.375286] PCI: Setting latency timer of device 0000:00:1d.7 to 64
kernel: [ 112.375379] PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 100f1, writing 1fff1)
kernel: [ 112.375390] PM: Writing back config space on device 0000:00:1e.0 at offset 8 (was 90, writingef90ef90)
kernel: [ 112.375400] PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was2280e0f0, writing228000f0)
kernel: [ 112.375418] PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100007, writing 100107)
kernel: [ 112.375446] PCI: Setting latency timer of device 0000:00:1e.0 to 64
kernel: [ 112.375495] PM: Writing back config space on device 0000:00:1f.0 at offset 1 (was 2100007, writing 2100107)
kernel: [ 112.388552] PM: Writing back config space on device 0000:00:1f.2 at offset f (was 200, writing 205)
kernel: [ 112.388602] ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 17
kernel: [ 112.388610] PCI: Setting latency timer of device 0000:00:1f.2 to 64
kernel: [ 112.388636] PM: Writing back config space on device 0000:00:1f.3 at offset f (was 200, writing 205)
kernel: [ 111.330331] ata2.00:_GTFevaluation failed (AE0x1001)
kernel: [ 111.330331] ata2.01:_GTFevaluation failed (AE0x1001)
kernel: [ 112.388678] PM: Writing back config space on device 0000:00:1f.3 at offset 1 (was 2800001, writing 2800101)
kernel: [ 112.388751] PM: Writing back config space on device 0000:01:00.0 at offset f (was 1ff, writing 104)
kernel: [ 112.388838] PM: Writing back config space on device 0000:01:00.0 at offset 3 (was 0, writing 10)
kernel: [ 111.330331] ata1.01:_GTFevaluation failed (AE0x1001)
kernel: [ 112.417656] PCI: Enabling device 0000:03:00.0 (0000 -> 0002)
kernel: [ 112.417662] ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 17 (level, low) -> IRQ 17
kernel: [ 112.417677] PM: Writing back config space on device 0000:03:00.0 at offset f (was 100, writing 105)
kernel: [ 112.417702] PM: Writing back config space on device 0000:03:00.0 at offset 4 (was 0, writingef9fe000)
kernel: [ 112.417710] PM: Writing back config space on device 0000:03:00.0 at offset 3 (was 0, writing 4000)
kernel: [ 112.417720] PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100002, writing 100106)
kernel: [ 112.431706] PM: Writing back config space on device 0000:03:01.0 at offset f (was 4020100, writing 4020103)
kernel: [ 112.431734] PM: Writing back config space on device 0000:03:01.0 at offset 4 (was 0, writingef9fd800)
kernel: [ 112.431742] PM: Writing back config space on device 0000:03:01.0 at offset 3 (was 800000, writing 804000)
kernel: [ 112.431751] PM: Writing back config space on device 0000:03:01.0 at offset 1 (was 2100000, writing 2100106)
kernel: [ 112.517139] PM: Writing back config space on device 0000:03:01.1 at offset f (was 200, writing 209)
kernel: [ 112.517168] PM: Writing back config space on device 0000:03:01.1 at offset 4 (was 0, writingef9fd400)
kernel: [ 112.517176] PM: Writing back config space on device 0000:03:01.1 at offset 3 (was 800000, writing 804000)
kernel: [ 112.517186] PM: Writing back config space on device 0000:03:01.1 at offset 1 (was 2100000, writing 2100106)
kernel: [ 112.517211] ACPI: PCI Interrupt 0000:03:01.1[B] -> GSI 18 (level, low) -> IRQ 18
kernel: [ 112.517234] ricoh-mmc: Resuming.
kernel: [ 112.517245] ricoh-mmc: Controller is now disabled.
kernel: [ 112.517259] PM: Writing back config space on device 0000:03:01.3 at offset f (was 200, writing 209)
kernel: [ 112.517286] PM: Writing back config space on device 0000:03:01.3 at offset 4 (was 0, writingef9fd700)
kernel: [ 112.517298] PM: Writing back config space on device 0000:03:01.3 at offset 1 (was 2100000, writing 2100102)
kernel: [ 112.517382]pciehp_resumeENTRY
kernel: [ 112.517410]pciehp_resumeENTRY
kernel: [ 111.839425] ata2.00: configured for UDMA/33
kernel: [ 113.520191] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 113.520197] pciehp: Cannot add device 0xc:0
kernel: [ 113.520214]pciehp_resumeENTRY
kernel: [ 113.520461] sd 0:0:0:0: [sda] Starting disk
kernel: [ 113.727280] ata1.00: ACPI cmd ef/10:03:00:00:00:a0 succeeded
kernel: [ 113.746993] ata1.00: configured for UDMA/133
kernel: [ 113.770650] sd 0:0:0:0: [sda] 312581808 512-byte hardware sectors (160042 MB)
kernel: [ 113.770650] sd 0:0:0:0: [sda] Write Protect is off
Quoted 8 lines
kernel: [ 113.770650] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00
kernel: [ 113.770650] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
kernel: [ 114.901667] Restarting tasks ... <6>usb 5-1: USB disconnect, address 2
kernel: [ 114.933424] done.
kernel: [ 115.128131] usb 5-1: new high speed USB device usingehci_hcdand address 5
This looks like your usb device should be up and working.
Do you have CONFIG_USB_SUSPEND enabled in your .config?
Quoted 6 lines
## Note: these are "normal" and harmless on this machine,
## and the reason for them has never been tracked down:
kernel: [ 115.198514] Uhhuh. NMI received for unknown reason 90 on CPU 0.
kernel: [ 115.198519] You have some hardware problem, likely on the PCI bus.
kernel: [ 115.198521] Dazed and confused, but trying to continue
Not very nice "harmless" messages :(
Quoted 13 lines
kernel: [ 117.690742] b44: eth0: Link is up at 100 Mbps, full duplex.
kernel: [ 117.690750] b44: eth0: Flow control is off for TX and off for RX.
login[3020]: (pam_unix) session opened for user root by (uid=0) login[4507]: ROOT LOGIN on 'tty1'
root: reloading usbhid module
kernel: [ 225.955054] usbcore: deregistering interface driver usbhid
kernel: [ 225.966118] usbcore: deregistering interface driver hiddev
root: session hung on insmod
kernel: [ 248.875843] SysRq : Emergency Sync
kernel: [ 248.876629] Emergency Sync complete
kernel: [ 249.535815] SysRq : Emergency Remount R/O
Quoted 8 lines · Greg KH
Quoted 7 lines
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again, but with no USB functionality -- no mouse.
The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhid
And the console hung at 100% CPU on the insmod.Haven't heard of this one before sorry. Jiri, have you?
No, haven't heard anything similar either. Mark, are you able to collect the stacktraces via alt-sysrq-t at the time the system goes crazy?
Also, as you seem to be able to easily reproduce the bug, git-bisect might reveal the culprit easily. For start, you can try to bisect only let's say usb, hid and acpi code probably ... ?
Quoted 4 lines
Quoted 4 lines
kernel: [ 111.361099]
pciehp_resumeENTRY
kernel: [ 112.362047] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 112.362052] pciehp: Cannot add device 0xc:0
Hmm, what device is this?
Signature · 2 lines
Jiri Kosina SUSE Labs
Quoted 10 lines · Jiri Kosina
Quoted 6 lines · Greg KH
Quoted 5 lines
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again, but with no USB functionality -- no mouse. The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhid
And the console hung at 100% CPU on the insmod.Haven't heard of this one before sorry. Jiri, have you?
No, haven't heard anything similar either. Mark, are you able to collect the stacktraces via alt-sysrq-t at the time the system goes crazy?
..
No where practical to capture them to.
I don't know if the machine was entirely dead,
or just the console at that point.
Quoted 1 line
Also, as you seem to be able to easily reproduce the bug, git-bisect might reveal the culprit easily. For start, you can try to bisect only let's say usb, hid and acpi code probably ... ?
..
I don't have the XX days necessary for git-bisect right now. But if there were some likely candidates, I could probably try a couple. Mostly I just wanted to give a heads-up that all is not well with 2.6.25 for now, and I'll get round to debugging it when I have time to do so.
I haven't yet tried -rc7 on my *other* dissimilar notebook,
but back at -rc2 it also had serious issues with suspend/resume not working. This is my first look at 2.6.25 (on notebooks) since then.
..
Quoted 5 lines
Quoted 3 lines
Quoted 3 lines
kernel: [ 111.361099]
pciehp_resumeENTRY
kernel: [ 112.362047] pciehp: Device 0000:0c:00.0 already exists at c:0, cannot hot-add
kernel: [ 112.362052] pciehp: Cannot add device 0xc:0Hmm, what device is this?
..
Wireless PCIe card on internal slot -- Intel 3945ABG.
From: Mark Lord <[email protected]>
Date: Thu, 27 Mar 2008 21:57:55 -0400
Quoted 1 line
I don't have the XX days necessary for git-bisect right now.
I wish people would say stuff like this.
It takes 20 to 40 minutes, tops, to do this.
The bulk of it can run in the background while you perform other tasks.
Quoted 11 lines · David Miller
From: Mark Lord <[email protected]>
Date: Thu, 27 Mar 2008 21:57:55 -0400Quoted 1 line
I don't have the XX days necessary for git-bisect right now.
I wish people would say stuff like this.
It takes 20 to 40 minutes, tops, to do this.
The bulk of it can run in the background while you perform other tasks.
I don't understand this claim. On what incredibly fast piece of iron can you possibly do between 8 and 16 kernel builds (the range I've encountered when I do the "git bisect" dance), boot each one, and evaluate the results in so small a period of time? An Alpha kernel build takes me between 5 and 10 minutes for minor changes, closer to four *hours* for a "from scratch" (make clean) build. Even worse: for those of us who don't have access to the console of the test machine continuously (e.g., the machine is at home and you normally work outside the home), the whole bisection process can take several days to complete.
Yes, Mark's problem is with a laptop, and maybe he's allowed to take it with him into his workplace, but still...
If your claim is 20 to 40 minutes "per iteration", I could believe that.
Signature · 4 lines
------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did [email protected] | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------
From: [email protected] (Bob Tracy)
Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)
Quoted 4 lines
I don't understand this claim. On what incredibly fast piece of iron can you possibly do between 8 and 16 kernel builds (the range I've encountered when I do the "git bisect" dance), boot each one, and evaluate the results in so small a period of time?
Builds are just over a minute on my box. I can do a full kernel build plus reboot cycle in under 2 minutes.
Quoted 10 lines · David Miller
From: [email protected] (Bob Tracy)
Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)Quoted 4 lines
I don't understand this claim. On what incredibly fast piece of iron can you possibly do between 8 and 16 kernel builds (the range I've encountered when I do the "git bisect" dance), boot each one, and evaluate the results in so small a period of time?
Builds are just over a minute on my box. I can do a full kernel build plus reboot cycle in under 2 minutes.
...
Well, lucky you.
I have a box almost that quick here, too.
Except it's not the one with the problem.
My main email/work machine is the one with the problem,
and the downtime is not affordable -- ie. it costs *me* personally money.
Cheers
Quoted 13 lines · Mark Lord
Quoted 10 lines · David Miller
From: [email protected] (Bob Tracy)
Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)Quoted 4 lines
I don't understand this claim. On what incredibly fast piece of iron can you possibly do between 8 and 16 kernel builds (the range I've encountered when I do the "git bisect" dance), boot each one, and evaluate the results in so small a period of time?
Builds are just over a minute on my box. I can do a full kernel build plus reboot cycle in under 2 minutes.
...
Quoted 7 lines
Well, lucky you.
I have a box almost that quick here, too.
Except it's not the one with the problem.My main email/work machine is the one with the problem,
and the downtime is not affordable -- ie. it costs *me* personally money.
not that it's relavent to the problem that you are troubleshooting (based on later messages), but I will point out that there is nothing wrong with useing a fast box to compile kernels for slower boxes.
David Lang
Quoted 2 lines · David Miller
Builds are just over a minute on my box. I can do a full kernel build plus reboot cycle in under 2 minutes.
I've gotta get me some of that :-).
Signature · 4 lines
------------------------------------------------------------------------ Bob Tracy | "I was a beta tester for dirt. They never did [email protected] | get all the bugs out." - Steve McGrew on /. ------------------------------------------------------------------------
Quoted 11 lines · David Miller
From: [email protected] (Bob Tracy)
Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)Quoted 4 lines
I don't understand this claim. On what incredibly fast piece of iron can you possibly do between 8 and 16 kernel builds (the range I've encountered when I do the "git bisect" dance), boot each one, and evaluate the results in so small a period of time?
Builds are just over a minute on my box. I can do a full kernel build plus reboot cycle in under 2 minutes.
Most of us got over "mine is bigger than yours" bragging at about age 13. He said "laptop," that means slow builds, slow installs, slow boots, and unless he's on a fat net pipe to a faster machine, build elsewhere isn't much of a saving.
Signature · 3 lines
Bill Davidsen <[email protected]> "We have more to fear from the bungling of the incompetent than from the machinations of the wicked." - from Slashdot
Quoted 8 lines · David Miller
From: Mark Lord <[email protected]>
Date: Thu, 27 Mar 2008 21:57:55 -0400Quoted 1 line
I don't have the XX days necessary for git-bisect right now.
I wish people would say stuff like this.
It takes 20 to 40 minutes, tops, to do this.
Heh, my 3GHz P4 takes 20 minutes to build one kernel.
-Mike
Quoted 6 lines · David Miller
From: Mark Lord <[email protected]>
Date: Thu, 27 Mar 2008 21:57:55 -0400Quoted 1 line
I don't have the XX days necessary for git-bisect right now.
I wish people would say stuff like this.
..
I just did, thanks.
In this case, a bisect would be a complete waste of time, because whatever is wrong seems to be a timing-related race condition of some kind.
Merely rebuilding the kernel with slightly different debug flags affects things, so trying to bisect it would be a super waste of time in all probability.
When I rebuilt with all debug stuff on, the kernel was worse than before, and just gave the "black screen of nothing" on resume, with a hung system.
At least before the system didn't hang.
Now I've just booted with a differently configured kernel, with only about half of the debug flags turned on. This one resumes from suspend, and *with* working USB too.
Ugh. Gotta love it when the bug is so subtle that turning on the debug flags makes it (1) get worse, and/or (2) get cured.
Here's the abbreviated diff between broken (no USB on resume, no hang), and working (good USB, no hang) .config files.
--- dot_config.nousb 2008-03-27 22:43:50.000000000 -0400
+++ dot_config.works 2008-03-28 01:29:22.000000000 -0400
-CONFIG_LOG_BUF_SHIFT=16
+CONFIG_LOG_BUF_SHIFT=17
-# CONFIG_KALLSYMS_ALL is not set +CONFIG_KALLSYMS_ALL=y
-# CONFIG_MAC80211_DEBUGFS is not set
-# CONFIG_RTC is not set
-CONFIG_GEN_RTC=y
-CONFIG_GEN_RTC_X=y
+CONFIG_RTC=y
+CONFIG_SND_RTCTIMER=m +CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
-CONFIG_RTC_LIB=y
-CONFIG_RTC_CLASS=y
-
-#
-# Conflicting RTC option has been selected, check GEN_RTC and RTC -#
-CONFIG_RTC_HCTOSYS=y
-CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
-# CONFIG_RTC_DEBUG is not set
-
-#
-# RTC interfaces
-#
-CONFIG_RTC_INTF_SYSFS=y
-CONFIG_RTC_INTF_PROC=y
-CONFIG_RTC_INTF_DEV=y
-# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set -CONFIG_RTC_DRV_TEST=m
-
-#
-# I2C RTC drivers
-#
-CONFIG_RTC_DRV_DS1307=m
-CONFIG_RTC_DRV_DS1374=m
-CONFIG_RTC_DRV_DS1672=m
-CONFIG_RTC_DRV_MAX6900=m
-CONFIG_RTC_DRV_RS5C372=m
-CONFIG_RTC_DRV_ISL1208=m
-CONFIG_RTC_DRV_X1205=m
-CONFIG_RTC_DRV_PCF8563=m
-CONFIG_RTC_DRV_PCF8583=m
-# CONFIG_RTC_DRV_M41T80 is not set
-# CONFIG_RTC_DRV_S35390A is not set
-
-#
-# SPI RTC drivers
-#
-
-#
-# Platform RTC drivers
-#
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_RTC_DRV_DS1511=m
-CONFIG_RTC_DRV_DS1553=m
-CONFIG_RTC_DRV_DS1742=m
-# CONFIG_RTC_DRV_STK17TA8 is not set -CONFIG_RTC_DRV_M48T86=m
-# CONFIG_RTC_DRV_M48T59 is not set -CONFIG_RTC_DRV_V3020=m
-
-#
-# on-CPU RTC drivers
-#
+# CONFIG_RTC_CLASS is not set
-# CONFIG_JBD_DEBUG is not set
-CONFIG_DLM=m
-# CONFIG_DLM_DEBUG is not set
+# CONFIG_DLM is not set
-CONFIG_DEBUG_FS=y
+# CONFIG_DEBUG_FS is not set
-CONFIG_TIMER_STATS=y
-# CONFIG_DEBUG_SLAB is not set
+# CONFIG_TIMER_STATS is not set
+CONFIG_DEBUG_SLAB=y
+CONFIG_DEBUG_SLAB_LEAK=y
-# CONFIG_DEBUG_SPINLOCK is not set
-# CONFIG_DEBUG_MUTEXES is not set
-# CONFIG_DEBUG_LOCK_ALLOC is not set
-# CONFIG_PROVE_LOCKING is not set +CONFIG_DEBUG_SPINLOCK=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_LOCK_ALLOC=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
-# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
-# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
-# CONFIG_DEBUG_KOBJECT is not set
-# CONFIG_DEBUG_HIGHMEM is not set +CONFIG_DEBUG_LOCKDEP=y
+CONFIG_TRACE_IRQFLAGS=y
+CONFIG_DEBUG_SPINLOCK_SLEEP=y +CONFIG_DEBUG_LOCKING_API_SELFTESTS=y +CONFIG_STACKTRACE=y
+CONFIG_DEBUG_KOBJECT=y
+CONFIG_DEBUG_HIGHMEM=y
-# CONFIG_DEBUG_INFO is not set
-# CONFIG_DEBUG_VM is not set
-# CONFIG_DEBUG_LIST is not set
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_LIST=y
-# CONFIG_FRAME_POINTER is not set +CONFIG_FRAME_POINTER=y
-# CONFIG_DEBUG_STACKOVERFLOW is not set
-# CONFIG_DEBUG_STACK_USAGE is not set +CONFIG_DEBUG_STACKOVERFLOW=y +CONFIG_DEBUG_STACK_USAGE=y
-CONFIG_4KSTACKS=y
+# CONFIG_4KSTACKS is not set
-# CONFIG_DEBUG_BOOT_PARAMS is not set
Quoted 16 lines · Mark Lord
When I rebuilt with all debug stuff on, the kernel was worse than before, and just gave the "black screen of nothing" on resume, with a hung system.
At least before the system didn't hang.
Now I've just booted with a differently configured kernel, with only about half of the debug flags turned on. This one resumes from suspend, and *with* working USB too.
Ugh. Gotta love it when the bug is so subtle that turning on the debug flags makes it (1) get worse, and/or (2) get cured.
Here's the abbreviated diff between broken (no USB on resume, no hang), and working (good USB, no hang) .config files.
..
Review
Quoted 2 lines
(quoted diff) +1
-1-CONFIG_RTC_CLASS=y +# CONFIG_RTC_CLASS is not set
Mmm.. also had the RTC conflict resolved in that one. Time to try another kernel with just the RTC change now.
Quoted 15 lines · Mark Lord
Quoted 14 lines · Mark Lord
When I rebuilt with all debug stuff on, the kernel was worse than before, and just gave the "black screen of nothing" on resume, with a hung system.
At least before the system didn't hang.
Now I've just booted with a differently configured kernel, with only about half of the debug flags turned on. This one resumes from suspend, and *with* working USB too.
Ugh. Gotta love it when the bug is so subtle that turning on the debug flags makes it (1) get worse, and/or (2) get cured.
Quoted 8 lines
Quoted 2 lines
Here's the abbreviated diff between broken (no USB on resume, no hang), and working (good USB, no hang) .config files.
..
Review
Quoted 2 lines
(quoted diff) +1
-1-CONFIG_RTC_CLASS=y +# CONFIG_RTC_CLASS is not setMmm.. also had the RTC conflict resolved in that one. Time to try another kernel with just the RTC change now.
..
Okay, that might be it. I've booted and am running without debug flags again. The difference between "bad" .config and "good" .config was this (below).
Could somebody please fix the RTC mess in kconfig now ?
--- dot_config.nousb 2008-03-27 22:43:50.000000000 -0400
+++ dot_config.best 2008-03-28 01:50:40.000000000 -0400
-# CONFIG_RTC is not set
-CONFIG_GEN_RTC=y
-CONFIG_GEN_RTC_X=y
+CONFIG_RTC=y
+CONFIG_SND_RTCTIMER=m +CONFIG_SND_SEQ_RTCTIMER_DEFAULT=y
-CONFIG_RTC_LIB=y
-CONFIG_RTC_CLASS=y
-
-#
-# Conflicting RTC option has been selected, check GEN_RTC and RTC -#
-CONFIG_RTC_HCTOSYS=y
-CONFIG_RTC_HCTOSYS_DEVICE="rtc0"
-# CONFIG_RTC_DEBUG is not set
-
-#
-# RTC interfaces
-#
-CONFIG_RTC_INTF_SYSFS=y
-CONFIG_RTC_INTF_PROC=y
-CONFIG_RTC_INTF_DEV=y
-# CONFIG_RTC_INTF_DEV_UIE_EMUL is not set -CONFIG_RTC_DRV_TEST=m
-
-#
-# I2C RTC drivers
-#
-CONFIG_RTC_DRV_DS1307=m
-CONFIG_RTC_DRV_DS1374=m
-CONFIG_RTC_DRV_DS1672=m
-CONFIG_RTC_DRV_MAX6900=m
-CONFIG_RTC_DRV_RS5C372=m
-CONFIG_RTC_DRV_ISL1208=m
-CONFIG_RTC_DRV_X1205=m
-CONFIG_RTC_DRV_PCF8563=m
-CONFIG_RTC_DRV_PCF8583=m
-# CONFIG_RTC_DRV_M41T80 is not set
-# CONFIG_RTC_DRV_S35390A is not set
-
-#
-# SPI RTC drivers
-#
-
-#
-# Platform RTC drivers
-#
-CONFIG_RTC_DRV_CMOS=y
-CONFIG_RTC_DRV_DS1511=m
-CONFIG_RTC_DRV_DS1553=m
-CONFIG_RTC_DRV_DS1742=m
-# CONFIG_RTC_DRV_STK17TA8 is not set -CONFIG_RTC_DRV_M48T86=m
-# CONFIG_RTC_DRV_M48T59 is not set -CONFIG_RTC_DRV_V3020=m
-
-#
-# on-CPU RTC drivers
-#
+# CONFIG_RTC_CLASS is not set
Quoted 1 line · Mark Lord
Could somebody please fix the RTC mess in kconfig now ?
My version has been sitting in MM for a while now. I'll forward it to you off-list, in case you want to verify that it resolves that specific issue.
It would have prevented your broken initial config, which statically linked both the new framework plus some incompatible legacy stuff.
- Dave
Quoted 6 lines · David Brownell
Quoted 1 line · Mark Lord
Could somebody please fix the RTC mess in kconfig now ?
My version has been sitting in MM for a while now. I'll forward it to you off-list, in case you want to verify that it resolves that specific issue.
could you please provide an URL or the patch itself so that others who hit this issue and read this thread can apply the fix?
Ingo
Quoted 6 lines · Ingo Molnar
Quoted 3 lines
Quoted 1 line
Could somebody please fix the RTC mess in kconfig now ?
My version has been sitting in MM for a while now.
could you please provide an URL or the patch itself so that others who hit this issue and read this thread can apply the fix?
I merged the two patches (gentle, then harsh) so the result is smaller. Here you go.
- dave
========== CUT HERE
Prevent the most significant RTC configuration problems:
- If the new RTC framework is enabled, don't allow any of the legacy drivers to be configured.
- When using generic RTC on x86, enable rtc-cmos by default.
It seems too many people are used to enabling a legacy RTC despite the Kconfig help/comments; the gentle approach hasn't worked.
--- drivers/char/Kconfig | 8 ++++++++ drivers/rtc/Kconfig | 5 +---- 2 files changed, 9 insertions(+), 4 deletions(-)
drivers/char/Kconfig +8 -0
@@ -704,6 +704,12 @@ config NVRAM To compile this driver as a module, choose M here: the module will be called nvram. +# +# These legacy RTC drivers just cause too many conflicts with the generic +# RTC framework ... let's not even try to coexist any more. +# +if RTC_LIB=n + config RTC tristate "Enhanced Real Time Clock Support" depends on !PPC && !PARISC && !IA64 && !M68K && !SPARC && !FRV && !ARM && !SUPERH && !S390
@@ -812,6 +818,8 @@ config DS1302 will get access to the real time clock (or hardware clock) built into your computer. +endif # RTC_LIB + config COBALT_LCD bool "Support for Cobalt LCD" depends on MIPS_COBALT
drivers/rtc/Kconfig +1 -4
@@ -20,10 +20,6 @@ menuconfig RTC_CLASS if RTC_CLASS -if GEN_RTC || RTC -comment "Conflicting RTC option has been selected, check GEN_RTC and RTC" -endif - config RTC_HCTOSYS bool "Set system time from RTC on startup and resume" depends on RTC_CLASS = y
@@ -303,6 +299,7 @@ comment "Platform RTC drivers" config RTC_DRV_CMOS tristate "PC-style 'CMOS'" depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPS + default y if X86 help Say "yes" here to get direct support for the real time clock found in every PC or ACPI-based system, and some other boards.
Quoted 4 lines · David Brownell
Prevent the most significant RTC configuration problems:
- If the new RTC framework is enabled, don't allow any of the legacy drivers to be configured.
yay!!!!
Quoted 1 line
- When using generic RTC on x86, enable rtc-cmos by default.
Amen.
Quoted 2 lines
It seems too many people are used to enabling a legacy RTC despite the
Kconfighelp/comments; the gentle approach hasn't worked.
it's not just about being gentle: it's that there are thousands of .config options that are confusing to most users, so our defaults and rules must make sense. If we think that an approach is superior (which your new RTC code certainly is), we have to take up the responsibility of pushing that as a prominent, default choice and excluding the old code. That ends up benefiting everyone, reduces complexity of the kernel. You wont see anyone shed tears for the old code.
Ingo
Pavel Machek
Acked-byQuoted 10 lines · Ingo Molnar
Quoted 4 lines · David Brownell
Prevent the most significant RTC configuration problems:
- If the new RTC framework is enabled, don't allow any of the legacy drivers to be configured.
yay!!!!
Quoted 8 lines
Quoted 1 line
- When using generic RTC on x86, enable rtc-cmos by default.
Amen.
Quoted 2 lines
It seems too many people are used to enabling a legacy RTC despite the
Kconfighelp/comments; the gentle approach hasn't worked.Very-Much-Acked-by Ingo Molnar <[email protected]>
Quoted 7 lines
it's not just about being gentle: it's that there are thousands of .config options that are confusing to most users, so our defaults and rules must make sense. If we think that an approach is superior (which your new RTC code certainly is), we have to take up the responsibility of pushing that as a prominent, default choice and excluding the old code. That ends up benefiting everyone, reduces complexity of the kernel. You wont see anyone shed tears for the old code.
...as I got bitten by this, too.
Signature · 3 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/
Quoted 8 lines · Ingo Molnar
it's not just about being gentle: it's that there are thousands of .config options that are confusing to most users, so our defaults and rules must make sense. If we think that an approach is superior (which your new RTC code certainly is), we have to take up the responsibility of pushing that as a prominent, default choice and excluding the old code. That ends up benefiting everyone, reduces complexity of the kernel. You wont see anyone shed tears for the old code.
Users with audio-related usage patterns do, as SND_RTCTIMER still depends on old rtc :-/
Quoted 8 lines · Jan Engelhardt
Quoted 5 lines
If we think that an approach is superior (which
your new RTC code certainly is), we have to take up the responsibility of pushing that as a prominent, default choice and excluding the old code. That ends up benefiting everyone, reduces complexity of the kernel. You wont see anyone shed tears for the old code.Users with audio-related usage patterns do, as
SND_RTCTIMERstill depends on old rtc :-/
-ENOPATCH :)
Last time this specific issue came up, a related point was that the relevant ALSA documentation in this area needed updating too. ISTR it assumed there was only one kind of RTC, and had a few other issues.
- Dave
Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
In reply to David BrownellQuoted 1 line · David Brownell
It seems too many people are used to enabling a legacy RTC despite the
Kconfighelp/comments; the gentle approach hasn't worked.
Gentleness is not the point. The Kconfig help/comments where just not clear at all.
FWIW, it's still confusing to have an option "Enhanced Real Time Clock Support" under "Character Devices", then later an option "Real Time Clock" one level higher, none of the two in any way acknowledging the existence of the other one, and only after naively selecting both, you are told that there is some sort of conflict. Couldn't this be made more explicit, such as:
- mentioning in both options' help text that the other one shouldn't be selected at the same time (if that's true)
- noting explicitly which of the two RTC options is the "legacy" one (is it RTC_CLASS?)
- enhancing the conflict message, which reads, in git-current:
*** Conflicting RTC option has been selected, check GEN_RTC *** RTC interfaces ***
Perhaps it's only me, but I do not know what to make of this.
HTH
T.
Signature · 4 lines
Tilman Schmidt E-Mail: [email protected] Bonn, Germany Diese Nachricht besteht zu 100% aus wiederverwerteten Bits. Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
Re: Kconfig RTC selection
Quoted 6 lines · Tilman Schmidt
Quoted 1 line · David Brownell
It seems too many people are used to enabling a legacy RTC despite the
Kconfighelp/comments; the gentle approach hasn't worked.Gentleness is not the point. The
Kconfighelp/comments where just not clear at all.
Quoted 13 lines
FWIW, it's still confusing to have an option "Enhanced Real Time Clock Support" under "Character Devices", then later an option "Real Time Clock" one level higher, none of the two in any way acknowledging the existence of the other one, and only after naively selecting both, you are told that there is some sort of conflict. Couldn't this be made more explicit, such as:
- mentioning in both options' help text that the other one shouldn't be selected at the same time (if that's true)
- noting explicitly which of the two RTC options is the "legacy" one (is itRTC_CLASS?)
- enhancing the conflict message, which reads, in git-current:
*** Conflicting RTC option has been selected, checkGEN_RTC*** RTC interfaces ***
..
Exactly the issue. Mod++++++++++++++++++++++
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
In reply to Tilman SchmidtQuoted 7 lines · Tilman Schmidt
FWIW, it's still confusing to have an option "Enhanced Real Time Clock Support" under "Character Devices", then later an option "Real Time Clock" one level higher, none of the two in any way acknowledging the existence of the other one, and only after naively selecting both, you are told that there is some sort of conflict.
You mean "still, after applying that patch I sent"? I don't see how that could be; it doesn't allow both to be selected.
Quoted 3 lines
Couldn't this be made more explicit, such as:
- mentioning in both options' help text that the other one shouldn't be selected at the same time (if that's true)
I think that'd be more confusing, since it's not possible. Telling people not to do something will usually make them think it's possible ...
Quoted 2 lines
- noting explicitly which of the two RTC options is the "legacy" one (is it
RTC_CLASS?)
That term isn't visible through the Kconfig user interfaces, so I'm not sure why it should be introduced except as part of a strategy to get rid of all those old drivers. Which is probably worth having, but isn't waht that patch addressed!
Quoted 4 lines
- enhancing the conflict message, which reads, in git-current:
*** Conflicting RTC option has been selected, checkGEN_RTC*** RTC interfaces ***
Perhaps it's only me, but I do not know what to make of this.
Me either, since the patch I sent removed that message. I'm now quite sure you did *NOT* apply and try that patch before responding to it.
- Dave
Re: Kconfig RTC selection
Quoted 9 lines · David Brownell
Quoted 6 lines · Tilman Schmidt
FWIW, it's still confusing to have an option "Enhanced Real Time Clock Support" under "Character Devices", then later an option "Real Time Clock" one level higher, none of the two in any way acknowledging the existence of the other one, and only after naively selecting both, you are told that there is some sort of conflict.
You mean "still, after applying that patch I sent"?
No, I was referring to the situation still existing in current mainline. My comment was intended to be in support of your patches. Sorry for not having made myself clear.
Regards,
Tilman
Quoted 30 lines · David Brownell
Quoted 3 lines · Ingo Molnar
Quoted 2 lines
Quoted 1 line
Could somebody please fix the RTC mess in kconfig now ?
My version has been sitting in MM for a while now.
could you please provide an URL or the patch itself so that others who hit this issue and read this thread can apply the fix?
I merged the two patches (gentle, then harsh) so the result is smaller. Here you go.
- dave
========== CUT HERE
Prevent the most significant RTC configuration problems:- If the new RTC framework is enabled, don't allow any of the legacy drivers to be configured.
- When using generic RTC on x86, enable rtc-cmos by default.
It seems too many people are used to enabling a legacy RTC despite the
Kconfighelp/comments; the gentle approach hasn't worked.Signed-off-by David Brownell <[email protected]>--- drivers/char/Kconfig | 8 ++++++++ drivers/rtc/Kconfig | 5 +---- 2 files changed, 9 insertions(+), 4 deletions(-)
drivers/char/Kconfig config NVRAM · line 709
Quoted 6 lines
drivers/char/Kconfig +3
-0@@ -704,6 +704,12 @@ config NVRAM To compile this driver as a module, choose M here: the module will be called nvram. +# +# These legacy RTC drivers just cause too many conflicts with the generic +# RTC framework ... let's not even try to coexist any more.
...
Thanks, David. Could you perhaps also update the option descriptions to clearly indicate which set of RTCs are the new ones, and which are the old ones that are going away someday?
I didn't find it at all obvious, and I still don't know which set my configured kernel is actually using.
Thanks
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
[ CC's trimmed a bit ]
Quoted 7 lines · Mark Lord
drivers/char/Kconfig config NVRAM · line 709
Quoted 2 lines
drivers/char/Kconfig +2
-0+# These legacy RTC drivers just cause too many conflicts with the generic +# RTC framework ... let's not even try to coexist any more....
Thanks, David. Could you perhaps also update the option descriptions to clearly indicate which set of RTCs are the new ones, and which are the old ones that are going away someday?
Hmm, I thought that would be clear from context. "These" (drivers/char) legacy RTC drivers (old), vs generic RTC framework (toplevel driver Kconfig).
Admittedly the *previous* Kconfig was troublesome, at the UI level (vs. those comments outside the GUI).
A more general issue seems to be what to do with those legacy RTC drivers. Few of them seem to have maintainers. I don't want to own them, and I doubt Alessandro does either. If their Kconfig is going to change, I'd rather just see them all flagged as deprecated ... with plans to delete them.
The RTCs in question being:
"RTC" ... replaced by new "rtc-cmos"
--> ready to deprecate now ?
"JS_RTC" ... a SPARC32 thing
--> bug?? no "js-rtc.c" in the tree! patch sent
"SGI_DS1286" ...
--> needs conversion to new framework
"SGI_IP27_RTC" ...
--> needs conversion to new framework
"GEN_RTC", "GEN_RTC_X" ... I never really saw the point
--> who uses this?
"EFI_RTC" ... IA64 only
--> needs conversion to new framework
"DS1302" ... M32R-specific, "rtc-ds1302" should replace it
--> ready to deprecate now?
Plus there are various chunks of RTC code elsewhere in the tree, mostly in arch subdirectories, which should be phased out but aren't such obvious targets.
Quoted 2 lines
I didn't find it at all obvious, and I still don't know which set my configured kernel is actually using.
If you enable the new framework, that's what it's using; there should be no other options visible. (At least, none that are even as loosely organized as the drivers/char stuff.)
Else ... it's clearly not enabled! So it's some other (legacy) RTC driver. I don't see the issue.
- Dave
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 26 lines · David Brownell
[ CC's trimmed a bit ]
Quoted 7 lines · Mark Lord
drivers/char/Kconfig config NVRAM · line 709
Quoted 2 lines
drivers/char/Kconfig +2
-0+# These legacy RTC drivers just cause too many conflicts with the generic +# RTC framework ... let's not even try to coexist any more....
Thanks, David. Could you perhaps also update the option descriptions to clearly indicate which set of RTCs are the new ones, and which are the old ones that are going away someday?
Hmm, I thought that would be clear from context. "These" (
drivers/char) legacy RTC drivers (old), vs generic RTC framework (toplevel driverKconfig).Admittedly the *previous*
Kconfigwas troublesome, at the UI level (vs. those comments outside the GUI).A more general issue seems to be what to do with those legacy RTC drivers. Few of them seem to have maintainers. I don't want to own them, and I doubt Alessandro does either. If their
Kconfigis going to change, I'd rather just see them all flagged as deprecated ... with plans to delete them.
Quoted 4 lines
The RTCs in question being:
"RTC" ... replaced by new "rtc-cmos"
--> ready to deprecate now ?
The only reason against killing it immediately seems to be SND_RTCTIMER.
Quoted 2 lines
"
JS_RTC" ... a SPARC32 thing--> bug?? no "js-rtc.c" in the tree! patch sent
Where's the bug?
js-rtc is built from rtc.c
Quoted 4 lines
...
"DS1302" ... M32R-specific, "rtc-ds1302" should replace it--> ready to deprecate now?...
Kconfig currently offers rtc-ds1302 only for an sh platform...
Quoted 1 line
- Dave
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 5 lines · Adrian Bunk
Quoted 2 lines
"
JS_RTC" ... a SPARC32 thing
--> bug?? no "js-rtc.c" in the tree! patch sentWhere's the bug?
js-rtc is built fromrtc.c
In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'" shows that it looks pretty pointless.
Quoted 6 lines
Quoted 4 lines
...
"DS1302" ... M32R-specific, "rtc-ds1302" should replace it --> ready to deprecate now?
...
Kconfigcurrently offers rtc-ds1302 only for an sh platform...
Right, I looked at that a bit more. The rtc-ds1302 code was
not written portably. If it were updated to get addresses
from platform resources -- like *normal* platform drivers do, since the addresses are platform specific -- and if those two M32R platforms got updated ... *then* this could be deprecated.
- Dave
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 10 lines · David Brownell
Quoted 5 lines · Adrian Bunk
Quoted 2 lines
"
JS_RTC" ... a SPARC32 thing
--> bug?? no "js-rtc.c" in the tree! patch sentWhere's the bug?
js-rtc is built fromrtc.cIn which case, just enable
rtc.c... a "egrep -r 'JS_RTC|js-rtc'" shows that it looks pretty pointless.
...
grep for CONFIG_SUN_MOSTEK_RTC and you'll get the point.
Quoted 1 line
- Dave
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 11 lines · Adrian Bunk
Quoted 9 lines
Quoted 5 lines
Quoted 2 lines
"
JS_RTC" ... a SPARC32 thing
--> bug?? no "js-rtc.c" in the tree! patch sentWhere's the bug?
js-rtc is built fromrtc.cIn which case, just enable
rtc.c... a "egrep -r 'JS_RTC|js-rtc'" shows that it looks pretty pointless.
...grep for
CONFIG_SUN_MOSTEK_RTCand you'll get the point.
Right: it doesn't mention JS_RTC at all. Whatever is up with that stuff, it's broken.
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 7 lines · David Brownell
Quoted 6 lines · Adrian Bunk
Quoted 6 lines
Quoted 5 lines
Quoted 2 lines
"
JS_RTC" ... a SPARC32 thing
--> bug?? no "js-rtc.c" in the tree! patch sentWhere's the bug?
js-rtc is built fromrtc.c
Quoted 8 lines
Quoted 5 lines
Quoted 3 lines
In which case, just enable
rtc.c... a "egrep -r 'JS_RTC|js-rtc'" shows that it looks pretty pointless.
...grep for
CONFIG_SUN_MOSTEK_RTCand you'll get the point.Right: it doesn't mention
JS_RTCat all. Whatever is up with that stuff, it's broken.
You miss the point, the point is:
drivers/sbus/char/Makefile:obj-$(CONFIG_SUN_MOSTEK_RTC) += rtc.o
Two modules with the same name in one build are not allowed.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 9 lines · Adrian Bunk
Quoted 4 lines
Quoted 1 line
grep for
CONFIG_SUN_MOSTEK_RTCand you'll get the point.Right: it doesn't mention
JS_RTCat all. Whatever is up with that stuff, it's broken.You miss the point, the point is:
drivers/sbus/char/Makefile:obj-$(CONFIG_SUN_MOSTEK_RTC) += rtc.oTwo modules with the same name in one build are not allowed.
It gets uglier and uglier. So if that abortion is really needed, it'd make more sense to rename the MOSTEK code. If that's not fixed, its Kconfig should mention needing the JS_RTC thing instead of the "real" legacy rtc.c ...
Glad I got rid of my JavaStation ages ago, but I liked the idea of having a real builtin coffee cup holder. :)
You see why nobody wants to touch the legacy RTC stuff? Some of it is broken *BY DESIGN* instead of just by pure happenstance of evolution.
- Dave
Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
Quoted 10 lines · David Brownell
Quoted 8 lines · Adrian Bunk
Quoted 4 lines
Quoted 1 line
grep for
CONFIG_SUN_MOSTEK_RTCand you'll get the point.Right: it doesn't mention
JS_RTCat all. Whatever is up with that stuff, it's broken.You miss the point, the point is:
drivers/sbus/char/Makefile:obj-$(CONFIG_SUN_MOSTEK_RTC) += rtc.o
Quoted 6 lines
Quoted 1 line
Two modules with the same name in one build are not allowed.
It gets uglier and uglier. So if that abortion is really needed, it'd make more sense to rename the MOSTEK code. If that's not fixed, its
Kconfigshould mention needing theJS_RTCthing instead of the "real" legacyrtc.c...
The Mostek code does not need drivers/char/rtc.c
JS_RTC is only needed for some unusual sparc machines.
Quoted 3 lines
Glad I got rid of my JavaStation ages ago, but I liked the idea of having a real builtin coffee cup holder. :)
...
I'm not sure, but the JavaStation might actually be one of these unusual machines...
Quoted 1 line
- Dave
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedRe: [rtc-linux] Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
In reply to David BrownellQuoted 4 lines · On Fri, 28 Mar 2008 15:18:35 -0700 David Brownell <[email protected]> wrote:
You see why nobody wants to touch the legacy RTC stuff? Some of it is broken *BY DESIGN* instead of just by pure happenstance of evolution.
And we did not even touched the 11 minutes ntp update mode :)
Signature · 6 lines
Best regards, Alessandro Zummo, Tower Technologies - Torino, Italy http://www.towertech.it
Quoted 8 lines · David Brownell
(quoted diff) +0
-0@@ -303,6 +299,7 @@ comment "Platform RTC drivers"config
RTC_DRV_CMOStristate "PC-style 'CMOS'" depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPSdrivers/rtc/Kconfig +1
-0+ default y if X86help
Say "yes" here to get direct support for the real time clock found in every PC or ACPI-based system, and some other boards.
I do not see why it should default to y, given that udev loads my m perfectly fine.
Quoted 13 lines · Jan Engelhardt
Quoted 8 lines · David Brownell
(quoted diff) +0
-0@@ -303,6 +299,7 @@ comment "Platform RTC drivers"config
RTC_DRV_CMOStristate "PC-style 'CMOS'" depends on X86 || ALPHA || ARM || M32R || ATARI || PPC || MIPSdrivers/rtc/Kconfig +1
-0+ default y if X86help
Say "yes" here to get direct support for the real time clock found in every PC or ACPI-based system, and some other boards.I do not see why it should default to y, given that udev loads my m perfectly fine.
Then there's no problem with having it default to "y".
The usual case is to have a driver disabled by default, and when it's that common that we do not want it disabled by default we can as well immediately let it default to "y".
The user still has all three choices.
cu
Adrian
Signature · 4 lines
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon SeedQuoted 19 lines · Mark Lord
Quoted 18 lines · Mark Lord
Quoted 16 lines · Mark Lord
When I rebuilt with all debug stuff on, the kernel was worse than before, and just gave the "black screen of nothing" on resume, with a hung system.
At least before the system didn't hang.
Now I've just booted with a differently configured kernel, with only about half of the debug flags turned on. This one resumes from suspend, and *with* working USB too.
Ugh. Gotta love it when the bug is so subtle that turning on the debug flags makes it (1) get worse, and/or (2) get cured.
Here's the abbreviated diff between broken (no USB on resume, no hang), and working (good USB, no hang) .config files.
..
Quoted 8 lines
Quoted 5 lines
Review
Quoted 2 lines
(quoted diff) +1
-1-CONFIG_RTC_CLASS=y +# CONFIG_RTC_CLASS is not setMmm.. also had the RTC conflict resolved in that one. Time to try another kernel with just the RTC change now.
..
Okay, that might be it. I've booted and am running without debug flags again.
..
An update: still mostly stable now.
But I have seen one resume failure on this machine since then, and that's not "normal" -- suspend/resume are normally rock solid.
My other pure Intel Dell X1 notebook has also hung a couple
of time during startup -- usually with "switched to high resolution" messages near-last on the the screen. There's a long standing bug to do with that stuff, which I first reported back in 2.6.20 (or .21). Back then, it was kernel .config dependent, and has never been tracked down.
Maybe the same thing here, maybe not.
Cheers
Quoted 1 line
Do you have
CONFIG_USB_SUSPENDenabled in your .config?
Yes.
I'm puzzled by this one, but really too busy to fix it myself this time around. I will fix it myself if necessary, eventually, just not for a few weeks while I catch up on some deadlines.
Cheers
#
# Automatically generated make config: don't edit # Linux kernel version: 2.6.25-rc7
# Thu Mar 27 10:54:45 2008
#
# CONFIG_64BIT is not setCONFIG_X86_32=y
# CONFIG_X86_64 is not setCONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=yCONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_HAVE_LATENCYTOP_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_FAST_CMPXCHG_LOCAL=yCONFIG_MMU=yCONFIG_ZONE_DMA=yCONFIG_GENERIC_ISA_DMA=yCONFIG_GENERIC_IOMAP=yCONFIG_GENERIC_BUG=yCONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set CONFIG_ARCH_MAY_HAVE_PC_FDC=yCONFIG_DMI=y
# CONFIG_RWSEM_GENERIC_SPINLOCK is not set CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_ARCH_HAS_CPU_IDLE_WAIT=y CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set CONFIG_ARCH_HAS_CPU_RELAX=y
# CONFIG_HAVE_SETUP_PER_CPU_AREA is not set CONFIG_ARCH_HIBERNATION_POSSIBLE=y CONFIG_ARCH_SUSPEND_POSSIBLE=y
# CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set CONFIG_ARCH_SUPPORTS_AOUT=y CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=yCONFIG_X86_SMP=yCONFIG_X86_32_SMP=yCONFIG_X86_HT=yCONFIG_X86_BIOS_REBOOT=yCONFIG_X86_TRAMPOLINE=yCONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#CONFIG_EXPERIMENTAL=yCONFIG_LOCK_KERNEL=yCONFIG_INIT_ENV_ARG_LIMIT=32CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not setCONFIG_SWAP=yCONFIG_SYSVIPC=yCONFIG_SYSVIPC_SYSCTL=yCONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not setCONFIG_IKCONFIG=yCONFIG_IKCONFIG_PROC=yCONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not setCONFIG_SYSFS_DEPRECATED=yCONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
# CONFIG_BLK_DEV_INITRD is not setCONFIG_CC_OPTIMIZE_FOR_SIZE=yCONFIG_SYSCTL=yCONFIG_EMBEDDED=yCONFIG_UID16=yCONFIG_SYSCTL_SYSCALL=yCONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not setCONFIG_HOTPLUG=yCONFIG_PRINTK=yCONFIG_BUG=yCONFIG_ELF_CORE=y
# CONFIG_COMPAT_BRK is not setCONFIG_BASE_FULL=yCONFIG_FUTEX=yCONFIG_ANON_INODES=yCONFIG_EPOLL=yCONFIG_SIGNALFD=yCONFIG_TIMERFD=yCONFIG_EVENTFD=yCONFIG_SHMEM=yCONFIG_VM_EVENT_COUNTERS=yCONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not setCONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not setCONFIG_HAVE_KPROBES=yCONFIG_HAVE_KRETPROBES=yCONFIG_PROC_PAGE_MONITOR=yCONFIG_SLABINFO=yCONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not setCONFIG_BASE_SMALL=0CONFIG_MODULES=yCONFIG_MODULE_UNLOAD=yCONFIG_MODULE_FORCE_UNLOAD=yCONFIG_MODVERSIONS=yCONFIG_MODULE_SRCVERSION_ALL=yCONFIG_KMOD=yCONFIG_STOP_MACHINE=yCONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not setCONFIG_BLK_DEV_BSG=y
#
# IO Schedulers
#CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not setCONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not setCONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not setCONFIG_DEFAULT_IOSCHED="cfq"CONFIG_PREEMPT_NOTIFIERS=yCONFIG_CLASSIC_RCU=y
#
# Processor type and features
#CONFIG_TICK_ONESHOT=yCONFIG_NO_HZ=yCONFIG_HIGH_RES_TIMERS=yCONFIG_GENERIC_CLOCKEVENTS_BUILD=yCONFIG_SMP=yCONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not setCONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER=y
# CONFIG_PARAVIRT_GUEST is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not setCONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not setCONFIG_X86_CMPXCHG=yCONFIG_X86_L1_CACHE_SHIFT=6CONFIG_X86_XADD=yCONFIG_X86_WP_WORKS_OK=yCONFIG_X86_INVLPG=yCONFIG_X86_BSWAP=yCONFIG_X86_POPAD_OK=yCONFIG_X86_GOOD_APIC=yCONFIG_X86_INTEL_USERCOPY=yCONFIG_X86_USE_PPRO_CHECKSUM=yCONFIG_X86_P6_NOP=yCONFIG_X86_TSC=yCONFIG_X86_MINIMUM_CPU_FAMILY=6CONFIG_X86_DEBUGCTLMSR=yCONFIG_HPET_TIMER=yCONFIG_HPET_EMULATE_RTC=y
# CONFIG_IOMMU_HELPER is not setCONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not setCONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not setCONFIG_PREEMPT=y
# CONFIG_PREEMPT_RCU is not setCONFIG_X86_LOCAL_APIC=yCONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not setCONFIG_VM86=y
# CONFIG_TOSHIBA is not setCONFIG_I8K=mCONFIG_X86_REBOOTFIXUPS=yCONFIG_MICROCODE=mCONFIG_MICROCODE_OLD_INTERFACE=yCONFIG_X86_MSR=mCONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not setCONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not setCONFIG_VMSPLIT_3G=y
# CONFIG_VMSPLIT_3G_OPT is not set
# CONFIG_VMSPLIT_2G is not set
# CONFIG_VMSPLIT_2G_OPT is not set
# CONFIG_VMSPLIT_1G is not setCONFIG_PAGE_OFFSET=0xC0000000CONFIG_HIGHMEM=yCONFIG_ARCH_FLATMEM_ENABLE=yCONFIG_ARCH_SPARSEMEM_ENABLE=yCONFIG_ARCH_SELECT_MEMORY_MODEL=yCONFIG_SELECT_MEMORY_MODEL=yCONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not setCONFIG_FLATMEM=yCONFIG_FLAT_NODE_MEM_MAP=yCONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not setCONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not setCONFIG_ZONE_DMA_FLAG=1CONFIG_BOUNCE=yCONFIG_VIRT_TO_BUS=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not setCONFIG_MTRR=y
# CONFIG_EFI is not setCONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not setCONFIG_HZ_300=y
# CONFIG_HZ_1000 is not setCONFIG_HZ=300CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not setCONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not setCONFIG_PHYSICAL_ALIGN=0x100000CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not setCONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management options
#CONFIG_PM=yCONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not setCONFIG_PM_SLEEP_SMP=yCONFIG_PM_SLEEP=yCONFIG_SUSPEND=yCONFIG_SUSPEND_FREEZER=yCONFIG_HIBERNATION=yCONFIG_PM_STD_PARTITION="/dev/sda3"CONFIG_ACPI=yCONFIG_ACPI_SLEEP=yCONFIG_ACPI_PROCFS=yCONFIG_ACPI_PROCFS_POWER=yCONFIG_ACPI_SYSFS_POWER=yCONFIG_ACPI_PROC_EVENT=yCONFIG_ACPI_AC=mCONFIG_ACPI_BATTERY=mCONFIG_ACPI_BUTTON=mCONFIG_ACPI_FAN=mCONFIG_ACPI_DOCK=y
# CONFIG_ACPI_BAY is not setCONFIG_ACPI_PROCESSOR=mCONFIG_ACPI_HOTPLUG_CPU=yCONFIG_ACPI_THERMAL=mCONFIG_ACPI_WMI=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not setCONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not setCONFIG_ACPI_EC=yCONFIG_ACPI_POWER=yCONFIG_ACPI_SYSTEM=yCONFIG_X86_PM_TIMER=yCONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set
#
# CPU Frequency scaling
#CONFIG_CPU_FREQ=yCONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set CONFIG_CPU_FREQ_STAT=m CONFIG_CPU_FREQ_STAT_DETAILS=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE is not set # CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set CONFIG_CPU_FREQ_DEFAULT_GOV_ONDEMAND=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_CONSERVATIVE is not set CONFIG_CPU_FREQ_GOV_PERFORMANCE=y CONFIG_CPU_FREQ_GOV_POWERSAVE=m CONFIG_CPU_FREQ_GOV_USERSPACE=m CONFIG_CPU_FREQ_GOV_ONDEMAND=y CONFIG_CPU_FREQ_GOV_CONSERVATIVE=m
#
# CPUFreq processor drivers
#CONFIG_X86_ACPI_CPUFREQ=m
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
# CONFIG_X86_SPEEDSTEP_CENTRINO is not set
# CONFIG_X86_SPEEDSTEP_ICH is not set
# CONFIG_X86_SPEEDSTEP_SMI is not set
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
# CONFIG_X86_E_POWERSAVER is not set
#
# shared options # # CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set # CONFIG_X86_SPEEDSTEP_LIB is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y CONFIG_CPU_IDLE_GOV_MENU=y
#
# Bus options (PCI etc.)
#CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not setCONFIG_PCI_GOANY=yCONFIG_PCI_BIOS=yCONFIG_PCI_DIRECT=yCONFIG_PCI_MMCONFIG=yCONFIG_PCI_DOMAINS=yCONFIG_PCIEPORTBUS=yCONFIG_HOTPLUG_PCI_PCIE=mCONFIG_PCIEAER=yCONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not setCONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_HT_IRQ is not setCONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not setCONFIG_HOTPLUG_PCI=m
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
# CONFIG_HOTPLUG_PCI_IBM is not set
# CONFIG_HOTPLUG_PCI_ACPI is not set
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
#
# Executable file formats / Emulations
#CONFIG_BINFMT_ELF=yCONFIG_BINFMT_AOUT=mCONFIG_BINFMT_MISC=m
#
# Networking
#CONFIG_NET=y
#
# Networking options
#CONFIG_PACKET=mCONFIG_PACKET_MMAP=yCONFIG_UNIX=mCONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_XFRM_STATISTICS is not set
# CONFIG_NET_KEY is not setCONFIG_INET=yCONFIG_IP_MULTICAST=yCONFIG_IP_ADVANCED_ROUTER=yCONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not setCONFIG_IP_FIB_HASH=yCONFIG_IP_MULTIPLE_TABLES=yCONFIG_IP_ROUTE_MULTIPATH=yCONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not setCONFIG_NET_IPIP=mCONFIG_NET_IPGRE=mCONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not setCONFIG_SYN_COOKIES=yCONFIG_INET_AH=mCONFIG_INET_ESP=mCONFIG_INET_IPCOMP=mCONFIG_INET_XFRM_TUNNEL=mCONFIG_INET_TUNNEL=mCONFIG_INET_XFRM_MODE_TRANSPORT=mCONFIG_INET_XFRM_MODE_TUNNEL=mCONFIG_INET_XFRM_MODE_BEET=mCONFIG_INET_LRO=yCONFIG_INET_DIAG=mCONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not setCONFIG_TCP_CONG_CUBIC=yCONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
# CONFIG_IPV6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
# CONFIG_INET6_TUNNEL is not set
# CONFIG_NETWORK_SECMARK is not set
# CONFIG_NETFILTER is not set
# CONFIG_IP_DCCP is not setCONFIG_IP_SCTP=m
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not set
# CONFIG_SCTP_HMAC_SHA1 is not setCONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
# CONFIG_ATM is not setCONFIG_BRIDGE=mCONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not setCONFIG_LLC=m
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not setCONFIG_NET_SCH_FIFO=y
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_CAN is not set
# CONFIG_IRDA is not setCONFIG_BT=mCONFIG_BT_L2CAP=mCONFIG_BT_SCO=mCONFIG_BT_RFCOMM=mCONFIG_BT_RFCOMM_TTY=yCONFIG_BT_BNEP=mCONFIG_BT_BNEP_MC_FILTER=yCONFIG_BT_BNEP_PROTO_FILTER=yCONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#CONFIG_BT_HCIUSB=mCONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIBTSDIO is not set
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIVHCI is not set
# CONFIG_AF_RXRPC is not setCONFIG_FIB_RULES=y
#
# Wireless
#CONFIG_CFG80211=mCONFIG_NL80211=yCONFIG_WIRELESS_EXT=yCONFIG_MAC80211=m
#
# Rate control algorithm selection
#
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
# CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not setCONFIG_MAC80211_RC_DEFAULT_NONE=y
#
# Selecting 'y' for an algorithm will
#
#
# build the algorithm into mac80211. # CONFIG_MAC80211_RC_DEFAULT="" CONFIG_MAC80211_RC_PID=m CONFIG_MAC80211_RC_SIMPLE=m # CONFIG_MAC80211_DEBUGFS is not set # CONFIG_MAC80211_DEBUG_PACKET_ALIGNMENT is not set # CONFIG_MAC80211_DEBUG is not set CONFIG_IEEE80211=m # CONFIG_IEEE80211_DEBUG is not set CONFIG_IEEE80211_CRYPT_WEP=m CONFIG_IEEE80211_CRYPT_CCMP=m CONFIG_IEEE80211_CRYPT_TKIP=m CONFIG_IEEE80211_SOFTMAC=m # CONFIG_IEEE80211_SOFTMAC_DEBUG is not set CONFIG_RFKILL=m CONFIG_RFKILL_INPUT=m # CONFIG_NET_9P is not set
#
# Device Drivers
#
#
# Generic Driver Options
#CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"CONFIG_STANDALONE=y
# CONFIG_PREVENT_FIRMWARE_BUILD is not setCONFIG_FW_LOADER=m
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not set
# CONFIG_CONNECTOR is not set
# CONFIG_MTD is not set
# CONFIG_PARPORT is not setCONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#CONFIG_PNPACPI=yCONFIG_BLK_DEV=y
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not setCONFIG_BLK_DEV_LOOP=mCONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not setCONFIG_BLK_DEV_RAM=yCONFIG_BLK_DEV_RAM_COUNT=4CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not setCONFIG_CDROM_PKTCDVD=mCONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not setCONFIG_VIRTIO_BLK=mCONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not setCONFIG_EEPROM_93CX6=m
# CONFIG_SGI_IOC4 is not setCONFIG_TIFM_CORE=m
# CONFIG_TIFM_7XX1 is not set
# CONFIG_FUJITSU_LAPTOP is not set
# CONFIG_TC1100_WMI is not set
# CONFIG_MSI_LAPTOP is not set
# CONFIG_SONY_LAPTOP is not set
# CONFIG_THINKPAD_ACPI is not set
# CONFIG_INTEL_MENLOW is not set
# CONFIG_ENCLOSURE_SERVICES is not setCONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not setCONFIG_SCSI=yCONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not setCONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not setCONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not setCONFIG_CHR_DEV_SG=m
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs #CONFIG_SCSI_MULTI_LUN=yCONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set CONFIG_SCSI_SCAN_ASYNC=yCONFIG_SCSI_WAIT_SCAN=m
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not setCONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not setCONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not setCONFIG_ATA_PIIX=yCONFIG_SATA_MV=m
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not setCONFIG_SATA_QSTOR=m
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not setCONFIG_SATA_SIL24=m
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_SATA_INIC162X is not set
# CONFIG_PATA_ACPI is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_IT8213 is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NINJA32 is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_NS87415 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_PLATFORM is not setCONFIG_MD=y
# CONFIG_BLK_DEV_MD is not setCONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not setCONFIG_DM_CRYPT=mCONFIG_DM_SNAPSHOT=mCONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not setCONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#CONFIG_FIREWIRE=mCONFIG_FIREWIRE_OHCI=mCONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not setCONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not setCONFIG_BONDING=mCONFIG_MACVLAN=mCONFIG_EQUALIZER=mCONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not setCONFIG_NET_ETHERNET=yCONFIG_MII=m
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_NET_TULIP is not set
# CONFIG_HP100 is not set
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not set
# CONFIG_NET_PCI is not setCONFIG_B44=mCONFIG_B44_PCI_AUTOSELECT=yCONFIG_B44_PCICORE_AUTOSELECT=yCONFIG_B44_PCI=y
# CONFIG_NETDEV_1000 is not set
# CONFIG_NETDEV_10000 is not set
# CONFIG_TR is not set
#
# Wireless LAN
#
# CONFIG_WLAN_PRE80211 is not setCONFIG_WLAN_80211=y
# CONFIG_IPW2100 is not set
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
# CONFIG_PRISM54 is not setCONFIG_USB_ZD1201=mCONFIG_USB_NET_RNDIS_WLAN=mCONFIG_RTL8180=mCONFIG_RTL8187=m
# CONFIG_ADM8211 is not set
# CONFIG_P54_COMMON is not setCONFIG_ATH5K=m
# CONFIG_IWL4965 is not setCONFIG_IWL3945=m
# CONFIG_IWL3945_QOS is not setCONFIG_IWL3945_SPECTRUM_MEASUREMENT=y
# CONFIG_IWL3945_DEBUG is not set
# CONFIG_HOSTAP is not setCONFIG_B43=mCONFIG_B43_PCI_AUTOSELECT=yCONFIG_B43_PCICORE_AUTOSELECT=yCONFIG_B43_RFKILL=y
# CONFIG_B43_DEBUG is not setCONFIG_B43LEGACY=mCONFIG_B43LEGACY_PCI_AUTOSELECT=yCONFIG_B43LEGACY_PCICORE_AUTOSELECT=yCONFIG_B43LEGACY_RFKILL=y
# CONFIG_B43LEGACY_DEBUG is not setCONFIG_B43LEGACY_DMA=yCONFIG_B43LEGACY_PIO=yCONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not setCONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
# CONFIG_RT2X00 is not set
#
# USB Network Adapters
#CONFIG_USB_CATC=mCONFIG_USB_KAWETH=mCONFIG_USB_PEGASUS=mCONFIG_USB_RTL8150=mCONFIG_USB_USBNET=mCONFIG_USB_NET_AX8817X=mCONFIG_USB_NET_CDCETHER=mCONFIG_USB_NET_DM9601=mCONFIG_USB_NET_GL620A=mCONFIG_USB_NET_NET1080=mCONFIG_USB_NET_PLUSB=mCONFIG_USB_NET_MCS7830=mCONFIG_USB_NET_RNDIS_HOST=mCONFIG_USB_NET_CDC_SUBSET=mCONFIG_USB_ALI_M5632=yCONFIG_USB_AN2720=yCONFIG_USB_BELKIN=yCONFIG_USB_ARMLINUX=yCONFIG_USB_EPSON2888=yCONFIG_USB_KC2190=yCONFIG_USB_NET_ZAURUS=m
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not set
# CONFIG_NETCONSOLE is not set
# CONFIG_NETPOLL is not set
# CONFIG_NET_POLL_CONTROLLER is not setCONFIG_VIRTIO_NET=m
# CONFIG_ISDN is not set
# CONFIG_PHONE is not set
#
# Input device support
#CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not setCONFIG_INPUT_POLLDEV=m
#
# Userland interfaces
#CONFIG_INPUT_MOUSEDEV=mCONFIG_INPUT_MOUSEDEV_PSAUX=yCONFIG_INPUT_MOUSEDEV_SCREEN_X=1024CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not setCONFIG_INPUT_EVDEV=yCONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#CONFIG_INPUT_KEYBOARD=yCONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not setCONFIG_INPUT_MOUSE=yCONFIG_MOUSE_PS2=yCONFIG_MOUSE_PS2_ALPS=yCONFIG_MOUSE_PS2_LOGIPS2PP=yCONFIG_MOUSE_PS2_SYNAPTICS=y
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not setCONFIG_MOUSE_SERIAL=m
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TABLET is not set
# CONFIG_INPUT_TOUCHSCREEN is not setCONFIG_INPUT_MISC=yCONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not setCONFIG_INPUT_ATI_REMOTE=mCONFIG_INPUT_ATI_REMOTE2=mCONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_POWERMATE is not setCONFIG_INPUT_YEALINK=mCONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#CONFIG_SERIO=yCONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not setCONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#CONFIG_VT=yCONFIG_VT_CONSOLE=yCONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
# CONFIG_NOZOMI is not set
#
# Serial drivers
#CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not setCONFIG_FIX_EARLYCON_MEM=y
# CONFIG_SERIAL_8250_PCI is not set
# CONFIG_SERIAL_8250_PNP is not setCONFIG_SERIAL_8250_NR_UARTS=4CONFIG_SERIAL_8250_RUNTIME_UARTS=2
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not setCONFIG_UNIX98_PTYS=yCONFIG_LEGACY_PTYS=yCONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not setCONFIG_HW_RANDOM=yCONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not setCONFIG_NVRAM=m
# CONFIG_RTC is not setCONFIG_GEN_RTC=yCONFIG_GEN_RTC_X=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not setCONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not setCONFIG_HPET_MMAP=yCONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not setCONFIG_DEVPORT=yCONFIG_I2C=mCONFIG_I2C_BOARDINFO=yCONFIG_I2C_CHARDEV=m
#
# I2C Algorithms
#CONFIG_I2C_ALGOBIT=m
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_I801 is not set
# CONFIG_I2C_I810 is not set
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_TAOS_EVM is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_TINY_USB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not set
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_PCF8575 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_TPS65010 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_SENSORS_TSL2550 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not setCONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not setCONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#CONFIG_SSB_POSSIBLE=yCONFIG_SSB=yCONFIG_SSB_PCIHOST_POSSIBLE=yCONFIG_SSB_PCIHOST=yCONFIG_SSB_B43_PCI_BRIDGE=yCONFIG_SSB_SILENT=yCONFIG_SSB_DRIVER_PCICORE_POSSIBLE=yCONFIG_SSB_DRIVER_PCICORE=y
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#CONFIG_AGP=m
# CONFIG_AGP_ALI is not setCONFIG_AGP_ATI=m
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not setCONFIG_AGP_INTEL=m
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not setCONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not setCONFIG_DRM_RADEON=m
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not setCONFIG_FB=yCONFIG_FIRMWARE_EDID=yCONFIG_FB_DDC=mCONFIG_FB_CFB_FILLRECT=yCONFIG_FB_CFB_COPYAREA=yCONFIG_FB_CFB_IMAGEBLIT=y
# CONFIG_FB_CFB_REV_PIXELS_IN_BYTE is not set
# CONFIG_FB_SYS_FILLRECT is not set
# CONFIG_FB_SYS_COPYAREA is not set
# CONFIG_FB_SYS_IMAGEBLIT is not set
# CONFIG_FB_SYS_FOPS is not setCONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not setCONFIG_FB_BACKLIGHT=yCONFIG_FB_MODE_HELPERS=yCONFIG_FB_TILEBLITTING=y
#
# Frame buffer hardware drivers
#
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_ASILIANT is not set
# CONFIG_FB_IMSTT is not set
# CONFIG_FB_VGA16 is not setCONFIG_FB_VESA=y
# CONFIG_FB_EFI is not set
# CONFIG_FB_HECUBA is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_LE80578 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not setCONFIG_FB_RADEON=mCONFIG_FB_RADEON_I2C=yCONFIG_FB_RADEON_BACKLIGHT=y
# CONFIG_FB_RADEON_DEBUG is not set
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_S3 is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_VT8623 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_ARK is not set
# CONFIG_FB_PM3 is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not setCONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not setCONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
#
# Display device support
#
# CONFIG_DISPLAY_SUPPORT is not set
#
# Console display driver support
#CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=yCONFIG_DUMMY_CONSOLE=y CONFIG_FRAMEBUFFER_CONSOLE=m
# CONFIG_FRAMEBUFFER_CONSOLE_DETECT_PRIMARY is not set # CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set # CONFIG_FONTS is not set
CONFIG_FONT_8x8=y
CONFIG_FONT_8x16=y
# CONFIG_LOGO is not set
#
# Sound
#CONFIG_SOUND=m
#
# Advanced Linux Sound Architecture
#CONFIG_SND=mCONFIG_SND_TIMER=mCONFIG_SND_PCM=mCONFIG_SND_HWDEP=mCONFIG_SND_RAWMIDI=mCONFIG_SND_SEQUENCER=mCONFIG_SND_SEQ_DUMMY=mCONFIG_SND_OSSEMUL=yCONFIG_SND_MIXER_OSS=mCONFIG_SND_PCM_OSS=mCONFIG_SND_PCM_OSS_PLUGINS=yCONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_DYNAMIC_MINORS is not setCONFIG_SND_SUPPORT_OLD_API=y
# CONFIG_SND_VERBOSE_PROCFS is not set
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#CONFIG_SND_AC97_CODEC=m
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_VIRMIDI is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
#
# PCI devices
#CONFIG_SND_AD1889=m
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_OXYGEN is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5530 is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not setCONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not setCONFIG_SND_HDA_CODEC_REALTEK=yCONFIG_SND_HDA_CODEC_ANALOG=yCONFIG_SND_HDA_CODEC_SIGMATEL=yCONFIG_SND_HDA_CODEC_VIA=yCONFIG_SND_HDA_CODEC_ATIHDMI=yCONFIG_SND_HDA_CODEC_CONEXANT=yCONFIG_SND_HDA_CODEC_CMEDIA=yCONFIG_SND_HDA_CODEC_SI3054=yCONFIG_SND_HDA_GENERIC=yCONFIG_SND_HDA_POWER_SAVE=yCONFIG_SND_HDA_POWER_SAVE_DEFAULT=10
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_HIFIER is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not setCONFIG_SND_INTEL8X0=mCONFIG_SND_INTEL8X0M=m
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SIS7019 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VIRTUOSO is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not setCONFIG_SND_AC97_POWER_SAVE=yCONFIG_SND_AC97_POWER_SAVE_DEFAULT=10
#
# USB devices
#CONFIG_SND_USB_AUDIO=mCONFIG_SND_USB_USX2Y=mCONFIG_SND_USB_CAIAQ=m
# CONFIG_SND_USB_CAIAQ_INPUT is not set
#
# System on Chip audio support
#
# CONFIG_SND_SOC is not set
#
# SoC Audio support for SuperH
#
#
# ALSA SoC audio for Freescale SOCs
#
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not setCONFIG_AC97_BUS=mCONFIG_HID_SUPPORT=yCONFIG_HID=m
# CONFIG_HID_DEBUG is not setCONFIG_HIDRAW=y
#
# USB Input Devices
#CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not setCONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not setCONFIG_USB_SUPPORT=yCONFIG_USB_ARCH_HAS_HCD=yCONFIG_USB_ARCH_HAS_OHCI=yCONFIG_USB_ARCH_HAS_EHCI=yCONFIG_USB=m
# CONFIG_USB_DEBUG is not setCONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#CONFIG_USB_DEVICEFS=yCONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not setCONFIG_USB_SUSPEND=yCONFIG_USB_PERSIST=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#CONFIG_USB_EHCI_HCD=mCONFIG_USB_EHCI_ROOT_HUB_TT=yCONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_ISP116X_HCD is not setCONFIG_USB_OHCI_HCD=m
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not setCONFIG_USB_OHCI_LITTLE_ENDIAN=yCONFIG_USB_UHCI_HCD=mCONFIG_USB_SL811_HCD=m
# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
#CONFIG_USB_ACM=mCONFIG_USB_PRINTER=m
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' #
#
# may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=m # CONFIG_USB_STORAGE_DEBUG is not set CONFIG_USB_STORAGE_DATAFAB=y CONFIG_USB_STORAGE_FREECOM=y CONFIG_USB_STORAGE_ISD200=y CONFIG_USB_STORAGE_DPCM=y CONFIG_USB_STORAGE_USBAT=y CONFIG_USB_STORAGE_SDDR09=y CONFIG_USB_STORAGE_SDDR55=y CONFIG_USB_STORAGE_JUMPSHOT=y CONFIG_USB_STORAGE_ALAUDA=y # CONFIG_USB_STORAGE_KARMA is not set CONFIG_USB_LIBUSUAL=y
#
# USB Imaging devices
#CONFIG_USB_MDC800=mCONFIG_USB_MICROTEK=mCONFIG_USB_MON=y
#
# USB port drivers
#CONFIG_USB_SERIAL=mCONFIG_USB_EZUSB=yCONFIG_USB_SERIAL_GENERIC=yCONFIG_USB_SERIAL_AIRCABLE=mCONFIG_USB_SERIAL_AIRPRIME=mCONFIG_USB_SERIAL_ARK3116=mCONFIG_USB_SERIAL_BELKIN=mCONFIG_USB_SERIAL_CH341=mCONFIG_USB_SERIAL_WHITEHEAT=mCONFIG_USB_SERIAL_DIGI_ACCELEPORT=mCONFIG_USB_SERIAL_CP2101=mCONFIG_USB_SERIAL_CYPRESS_M8=mCONFIG_USB_SERIAL_EMPEG=mCONFIG_USB_SERIAL_FTDI_SIO=mCONFIG_USB_SERIAL_FUNSOFT=mCONFIG_USB_SERIAL_VISOR=mCONFIG_USB_SERIAL_IPAQ=mCONFIG_USB_SERIAL_IR=mCONFIG_USB_SERIAL_EDGEPORT=mCONFIG_USB_SERIAL_EDGEPORT_TI=mCONFIG_USB_SERIAL_GARMIN=mCONFIG_USB_SERIAL_IPW=mCONFIG_USB_SERIAL_IUU=mCONFIG_USB_SERIAL_KEYSPAN_PDA=mCONFIG_USB_SERIAL_KEYSPAN=mCONFIG_USB_SERIAL_KEYSPAN_MPR=yCONFIG_USB_SERIAL_KEYSPAN_USA28=yCONFIG_USB_SERIAL_KEYSPAN_USA28X=yCONFIG_USB_SERIAL_KEYSPAN_USA28XA=yCONFIG_USB_SERIAL_KEYSPAN_USA28XB=yCONFIG_USB_SERIAL_KEYSPAN_USA19=yCONFIG_USB_SERIAL_KEYSPAN_USA18X=yCONFIG_USB_SERIAL_KEYSPAN_USA19W=yCONFIG_USB_SERIAL_KEYSPAN_USA19QW=yCONFIG_USB_SERIAL_KEYSPAN_USA19QI=yCONFIG_USB_SERIAL_KEYSPAN_USA49W=yCONFIG_USB_SERIAL_KEYSPAN_USA49WLC=yCONFIG_USB_SERIAL_KLSI=mCONFIG_USB_SERIAL_KOBIL_SCT=mCONFIG_USB_SERIAL_MCT_U232=mCONFIG_USB_SERIAL_MOS7720=mCONFIG_USB_SERIAL_MOS7840=mCONFIG_USB_SERIAL_NAVMAN=mCONFIG_USB_SERIAL_PL2303=mCONFIG_USB_SERIAL_OTI6858=m
# CONFIG_USB_SERIAL_HP4X is not setCONFIG_USB_SERIAL_SAFE=mCONFIG_USB_SERIAL_SAFE_PADDED=yCONFIG_USB_SERIAL_SIERRAWIRELESS=mCONFIG_USB_SERIAL_TI=mCONFIG_USB_SERIAL_CYBERJACK=mCONFIG_USB_SERIAL_XIRCOM=mCONFIG_USB_SERIAL_OPTION=mCONFIG_USB_SERIAL_OMNINET=m
# CONFIG_USB_SERIAL_DEBUG is not set
#
# USB Miscellaneous drivers
#CONFIG_USB_EMI62=mCONFIG_USB_EMI26=mCONFIG_USB_ADUTUX=mCONFIG_USB_AUERSWALD=mCONFIG_USB_RIO500=mCONFIG_USB_LEGOTOWER=mCONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not setCONFIG_USB_LED=mCONFIG_USB_CYPRESS_CY7C63=mCONFIG_USB_CYTHERM=mCONFIG_USB_PHIDGET=m
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETMOTORCONTROL is not set
# CONFIG_USB_PHIDGETSERVO is not setCONFIG_USB_IDMOUSE=m
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not setCONFIG_USB_SISUSBVGA=m
# CONFIG_USB_SISUSBVGA_CON is not setCONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not setCONFIG_USB_TEST=m
# CONFIG_USB_GADGET is not setCONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
#
# MMC/SD Card Drivers
#CONFIG_MMC_BLOCK=mCONFIG_MMC_BLOCK_BOUNCE=yCONFIG_SDIO_UART=m
#
# MMC/SD Host Controller Drivers
#CONFIG_MMC_SDHCI=mCONFIG_MMC_RICOH_MMC=mCONFIG_MMC_WBSD=mCONFIG_MMC_TIFM_SD=m
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not setCONFIG_RTC_LIB=yCONFIG_RTC_CLASS=y
#
# Conflicting RTC option has been selected, check GEN_RTC and RTC #CONFIG_RTC_HCTOSYS=yCONFIG_RTC_HCTOSYS_DEVICE="rtc0"
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#CONFIG_RTC_INTF_SYSFS=yCONFIG_RTC_INTF_PROC=yCONFIG_RTC_INTF_DEV=y
# CONFIG_RTC_INTF_DEV_UIE_EMUL is not setCONFIG_RTC_DRV_TEST=m
#
# I2C RTC drivers
#CONFIG_RTC_DRV_DS1307=mCONFIG_RTC_DRV_DS1374=mCONFIG_RTC_DRV_DS1672=mCONFIG_RTC_DRV_MAX6900=mCONFIG_RTC_DRV_RS5C372=mCONFIG_RTC_DRV_ISL1208=mCONFIG_RTC_DRV_X1205=mCONFIG_RTC_DRV_PCF8563=mCONFIG_RTC_DRV_PCF8583=m
# CONFIG_RTC_DRV_M41T80 is not set
# CONFIG_RTC_DRV_S35390A is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#CONFIG_RTC_DRV_CMOS=yCONFIG_RTC_DRV_DS1511=mCONFIG_RTC_DRV_DS1553=mCONFIG_RTC_DRV_DS1742=m
# CONFIG_RTC_DRV_STK17TA8 is not setCONFIG_RTC_DRV_M48T86=m
# CONFIG_RTC_DRV_M48T59 is not setCONFIG_RTC_DRV_V3020=m
#
# on-CPU RTC drivers
#CONFIG_DMADEVICES=y
#
# DMA Devices
#CONFIG_INTEL_IOATDMA=mCONFIG_DMA_ENGINE=y
#
# DMA Clients
#CONFIG_NET_DMA=yCONFIG_DCA=m
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#CONFIG_EDD=mCONFIG_DELL_RBU=mCONFIG_DCDBAS=mCONFIG_DMIID=y
#
# File systems
#CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not setCONFIG_EXT2_FS_XIP=yCONFIG_FS_XIP=yCONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4DEV_FS is not setCONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not setCONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not setCONFIG_DNOTIFY=yCONFIG_INOTIFY=yCONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not setCONFIG_FUSE_FS=m
#
# CD-ROM/DVD Filesystems
#CONFIG_ISO9660_FS=mCONFIG_JOLIET=yCONFIG_ZISOFS=yCONFIG_UDF_FS=mCONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#CONFIG_FAT_FS=mCONFIG_MSDOS_FS=mCONFIG_VFAT_FS=mCONFIG_FAT_DEFAULT_CODEPAGE=437CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not setCONFIG_NTFS_RW=y
#
# Pseudo filesystems
#CONFIG_PROC_FS=yCONFIG_PROC_KCORE=yCONFIG_PROC_SYSCTL=yCONFIG_SYSFS=yCONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not setCONFIG_CONFIGFS_FS=m
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not set
# CONFIG_MINIX_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_ROMFS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not setCONFIG_NETWORK_FILESYSTEMS=yCONFIG_NFS_FS=mCONFIG_NFS_V3=yCONFIG_NFS_V3_ACL=yCONFIG_NFS_V4=yCONFIG_NFS_DIRECTIO=yCONFIG_NFSD=mCONFIG_NFSD_V2_ACL=yCONFIG_NFSD_V3=yCONFIG_NFSD_V3_ACL=yCONFIG_NFSD_V4=yCONFIG_NFSD_TCP=yCONFIG_LOCKD=mCONFIG_LOCKD_V4=yCONFIG_EXPORTFS=mCONFIG_NFS_ACL_SUPPORT=mCONFIG_NFS_COMMON=yCONFIG_SUNRPC=mCONFIG_SUNRPC_GSS=mCONFIG_SUNRPC_BIND34=yCONFIG_RPCSEC_GSS_KRB5=m
# CONFIG_RPCSEC_GSS_SPKM3 is not set
# CONFIG_SMB_FS is not set
# CONFIG_CIFS is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
#
# Partition Types
#CONFIG_PARTITION_ADVANCED=y
# CONFIG_ACORN_PARTITION is not set
# CONFIG_OSF_PARTITION is not set
# CONFIG_AMIGA_PARTITION is not set
# CONFIG_ATARI_PARTITION is not setCONFIG_MAC_PARTITION=yCONFIG_MSDOS_PARTITION=y
# CONFIG_BSD_DISKLABEL is not set
# CONFIG_MINIX_SUBPARTITION is not set
# CONFIG_SOLARIS_X86_PARTITION is not set
# CONFIG_UNIXWARE_DISKLABEL is not setCONFIG_LDM_PARTITION=y
# CONFIG_LDM_DEBUG is not set
# CONFIG_SGI_PARTITION is not set
# CONFIG_ULTRIX_PARTITION is not set
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not setCONFIG_NLS=yCONFIG_NLS_DEFAULT="cp437"CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not setCONFIG_NLS_CODEPAGE_850=m
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not setCONFIG_NLS_CODEPAGE_863=m
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
# CONFIG_NLS_CODEPAGE_932 is not set
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not setCONFIG_NLS_ASCII=mCONFIG_NLS_ISO8859_1=mCONFIG_NLS_ISO8859_2=mCONFIG_NLS_ISO8859_3=mCONFIG_NLS_ISO8859_4=mCONFIG_NLS_ISO8859_5=mCONFIG_NLS_ISO8859_6=mCONFIG_NLS_ISO8859_7=mCONFIG_NLS_ISO8859_9=mCONFIG_NLS_ISO8859_13=mCONFIG_NLS_ISO8859_14=mCONFIG_NLS_ISO8859_15=mCONFIG_NLS_KOI8_R=mCONFIG_NLS_KOI8_U=mCONFIG_NLS_UTF8=mCONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set
#
# Kernel hacking
#CONFIG_TRACE_IRQFLAGS_SUPPORT=yCONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not setCONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not setCONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not setCONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not setCONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not setCONFIG_TIMER_STATS=y
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
# CONFIG_DEBUG_HIGHMEM is not setCONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not set
# CONFIG_FRAME_POINTER is not set
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not set
# CONFIG_LATENCYTOP is not set
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_SAMPLES is not set
# CONFIG_EARLY_PRINTK is not set
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
# CONFIG_DEBUG_PAGEALLOC is not set
# CONFIG_DEBUG_RODATA is not set
# CONFIG_DEBUG_NX_TEST is not setCONFIG_4KSTACKS=yCONFIG_X86_FIND_SMP_CONFIG=yCONFIG_X86_MPPARSE=yCONFIG_DOUBLEFAULT=yCONFIG_IO_DELAY_TYPE_0X80=0CONFIG_IO_DELAY_TYPE_0XED=1CONFIG_IO_DELAY_TYPE_UDELAY=2CONFIG_IO_DELAY_TYPE_NONE=3
# CONFIG_IO_DELAY_0X80 is not set
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not setCONFIG_IO_DELAY_NONE=yCONFIG_DEFAULT_IO_DELAY_TYPE=3
# CONFIG_DEBUG_BOOT_PARAMS is not set
# CONFIG_CPA_DEBUG is not set
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
# CONFIG_SECURITY_FILE_CAPABILITIES is not setCONFIG_CRYPTO=yCONFIG_CRYPTO_ALGAPI=yCONFIG_CRYPTO_AEAD=mCONFIG_CRYPTO_BLKCIPHER=m
# CONFIG_CRYPTO_SEQIV is not setCONFIG_CRYPTO_HASH=mCONFIG_CRYPTO_MANAGER=mCONFIG_CRYPTO_HMAC=mCONFIG_CRYPTO_XCBC=mCONFIG_CRYPTO_NULL=mCONFIG_CRYPTO_MD4=yCONFIG_CRYPTO_MD5=mCONFIG_CRYPTO_SHA1=mCONFIG_CRYPTO_SHA256=mCONFIG_CRYPTO_SHA512=mCONFIG_CRYPTO_WP512=mCONFIG_CRYPTO_TGR192=mCONFIG_CRYPTO_GF128MUL=mCONFIG_CRYPTO_ECB=mCONFIG_CRYPTO_CBC=mCONFIG_CRYPTO_PCBC=mCONFIG_CRYPTO_LRW=m
# CONFIG_CRYPTO_XTS is not set
# CONFIG_CRYPTO_CTR is not set
# CONFIG_CRYPTO_GCM is not set
# CONFIG_CRYPTO_CCM is not setCONFIG_CRYPTO_CRYPTD=mCONFIG_CRYPTO_DES=mCONFIG_CRYPTO_FCRYPT=mCONFIG_CRYPTO_BLOWFISH=mCONFIG_CRYPTO_TWOFISH=mCONFIG_CRYPTO_TWOFISH_COMMON=mCONFIG_CRYPTO_TWOFISH_586=mCONFIG_CRYPTO_SERPENT=mCONFIG_CRYPTO_AES=mCONFIG_CRYPTO_AES_586=mCONFIG_CRYPTO_CAST5=mCONFIG_CRYPTO_CAST6=mCONFIG_CRYPTO_TEA=mCONFIG_CRYPTO_ARC4=mCONFIG_CRYPTO_KHAZAD=mCONFIG_CRYPTO_ANUBIS=m
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not setCONFIG_CRYPTO_DEFLATE=mCONFIG_CRYPTO_MICHAEL_MIC=mCONFIG_CRYPTO_CRC32C=mCONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_TEST is not setCONFIG_CRYPTO_AUTHENC=mCONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_HW is not setCONFIG_HAVE_KVM=yCONFIG_VIRTUALIZATION=yCONFIG_KVM=mCONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_LGUEST is not setCONFIG_VIRTIO=mCONFIG_VIRTIO_RING=m
# CONFIG_VIRTIO_PCI is not setCONFIG_VIRTIO_BALLOON=m
#
# Library routines
#CONFIG_BITREVERSE=mCONFIG_CRC_CCITT=mCONFIG_CRC16=mCONFIG_CRC_ITU_T=mCONFIG_CRC32=mCONFIG_CRC7=mCONFIG_LIBCRC32C=mCONFIG_ZLIB_INFLATE=mCONFIG_ZLIB_DEFLATE=mCONFIG_LZO_COMPRESS=mCONFIG_LZO_DECOMPRESS=mCONFIG_PLIST=yCONFIG_HAS_IOMEM=yCONFIG_HAS_IOPORT=yCONFIG_HAS_DMA=y
Quoted 21 lines · Greg KH
Quoted 3 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
That's not good, why not tell the linux-usb developers this? (added to the cc:)
Quoted 13 lines
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod.
..
Okay, correction there: it just hangs the console, but not 100% CPU. Other tasks still continue running.
Same thing happens when I rmmod usbhid, and then rmmod ehci_hcd. The rmmod ehci_hcd hangs.
But since the rest of the system is still alive, including the non-USB touchpad(!), here is the alt-sysrq-t from syslog:
rmmod D f74c2ddc 0 4538 4492
f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000
00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8
00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000
Call Trace:
[__wake_up_common+46/88] __wake_up_common+0x2e/0x58
[schedule_timeout+19/134] schedule_timeout+0x13/0x86
[wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d
[wait_for_common+205/308] wait_for_common+0xcd/0x134
[default_wake_function+0/8] default_wake_function+0x0/0x8
[__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138
[wq_barrier_func+0/8] wq_barrier_func+0x0/0x8
[<f889f684>] usb_remove_hcd+0x63/0xd7 [usbcore]
[<f88a858e>] usb_hcd_pci_remove+0x15/0x68 [usbcore]
[pci_device_remove+22/53] pci_device_remove+0x16/0x35
[__device_release_driver+88/118] __device_release_driver+0x58/0x76
[driver_detach+122/182] driver_detach+0x7a/0xb6
[bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e
[pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f
[sys_delete_module+388/445] sys_delete_module+0x184/0x1bd
[remove_vma+49/54] remove_vma+0x31/0x36
[do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
=======================If nothing else, this should point to where USB is getting deadlocked.
??
Quoted 56 lines · Mark Lord
Quoted 21 lines · Greg KH
Quoted 3 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
That's not good, why not tell the linux-usb developers this? (added to the cc:)
Quoted 13 lines
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod.
..
Okay, correction there: it just hangs the console, but not 100% CPU. Other tasks still continue running.
Same thing happens when I rmmod usbhid, and then rmmod
ehci_hcd. The rmmodehci_hcdhangs.But since the rest of the system is still alive, including the non-USB touchpad(!), here is the alt-sysrq-t from syslog:
rmmod D
f74c2ddc0 4538 4492f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be00000000 00000001
c0324a00c0324a0000000000 000000017fffffff7ffffffff653cea800000002c02906f800000000 00000012c038f6aa00000086c011aa0500000000 Call Trace:
[__wake_up_common+46/88]__wake_up_common+0x2e/0x58[schedule_timeout+19/134]schedule_timeout+0x13/0x86[wake_up_klogd+43/45]wake_up_klogd+0x2b/0x2d[wait_for_common+205/308]wait_for_common+0xcd/0x134[default_wake_function+0/8]default_wake_function+0x0/0x8[__cancel_work_timer+237/312]__cancel_work_timer+0xed/0x138[wq_barrier_func+0/8]wq_barrier_func+0x0/0x8[<f889f684>] usb_remove_hcd+0x63/0xd7 [usbcore] [<f88a858e>] usb_hcd_pci_remove+0x15/0x68 [usbcore] [pci_device_remove+22/53] pci_device_remove+0x16/0x35 [__device_release_driver+88/118] __device_release_driver+0x58/0x76 [driver_detach+122/182] driver_detach+0x7a/0xb6 [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd [remove_vma+49/54] remove_vma+0x31/0x36 [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 =======================
Quoted 1 line
If nothing else, this should point to where USB is getting deadlocked.
..
Oh, I also had a hung "lsusb" in another window at the same time:
lsusb D f74c187c 0 4491 4397
f6d3bc80 00000082 f74c1730 f74c187c c2816840 00000000 c26cb440 f666bab8
00000003 c014b132 00000000 00000000 00000000 f75c1114 00000246 f75c111c
f74c1730 c0291678 00000001 f74c1730 c01156bc f75c1120 f77e5f78 f75c1000
Call Trace:
[handle_mm_fault+1205/1222] handle_mm_fault+0x4b5/0x4c6
[__down+194/212] __down+0xc2/0xd4
[default_wake_function+0/8] default_wake_function+0x0/0x8
[__down_failed+7/12] __down_failed+0x7/0xc
[<f88a70a0>] usbdev_ioctl+0x42/0x1132 [usbcore]
[dput+22/197] dput+0x16/0xc5
[__link_path_walk+2664/2969] __link_path_walk+0xa68/0xb99
[mntput_no_expire+17/92] mntput_no_expire+0x11/0x5c
[path_walk+144/152] path_walk+0x90/0x98
[klist_del+24/59] klist_del+0x18/0x3b
[klist_iter_exit+15/24] klist_iter_exit+0xf/0x18
[bus_find_device+87/97] bus_find_device+0x57/0x61
[kobject_get+15/19] kobject_get+0xf/0x13
[get_device+14/20] get_device+0xe/0x14
[<f889c29e>] usb_get_dev+0xf/0x13 [usbcore]
[<f88a6d9c>] usbdev_open+0x13c/0x144 [usbcore]
[chrdev_open+312/373] chrdev_open+0x138/0x175
[open_namei+582/1357] open_namei+0x246/0x54d
[chrdev_open+0/373] chrdev_open+0x0/0x175
[__dentry_open+263/404] __dentry_open+0x107/0x194
[nameidata_to_filp+28/44] nameidata_to_filp+0x1c/0x2c
[do_filp_open+43/49] do_filp_open+0x2b/0x31
[vfs_ioctl+71/93] vfs_ioctl+0x47/0x5d
[do_vfs_ioctl+555/574] do_vfs_ioctl+0x22b/0x23e
[sys_ioctl+44/69] sys_ioctl+0x2c/0x45
[sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85
[schedule+53/1498] schedule+0x35/0x5da
=======================Alan Stern
maintainerQuoted 31 lines · Mark Lord
Same thing happens when I rmmod usbhid, and then rmmod
ehci_hcd. The rmmodehci_hcdhangs.But since the rest of the system is still alive, including the non-USB touchpad(!), here is the alt-sysrq-t from syslog:
rmmod D
f74c2ddc0 4538 4492f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000 00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8 00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000 Call Trace: [__wake_up_common+46/88] __wake_up_common+0x2e/0x58 [schedule_timeout+19/134] schedule_timeout+0x13/0x86 [wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d [wait_for_common+205/308] wait_for_common+0xcd/0x134 [default_wake_function+0/8] default_wake_function+0x0/0x8 [__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138 [wq_barrier_func+0/8] wq_barrier_func+0x0/0x8 [<f889f684>] usb_remove_hcd+0x63/0xd7 [usbcore] [<f88a858e>] usb_hcd_pci_remove+0x15/0x68 [usbcore] [pci_device_remove+22/53] pci_device_remove+0x16/0x35 [__device_release_driver+88/118] __device_release_driver+0x58/0x76 [driver_detach+122/182] driver_detach+0x7a/0xb6 [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd [remove_vma+49/54] remove_vma+0x31/0x36 [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 =======================
Quoted 3 lines
If nothing else, this should point to where USB is getting deadlocked.
??
rmmod is hanging up in a call to cancel_work_sync(), which means the real problem is in the workqueue. It's quite understandable that you wouldn't want to go any further into debugging this, but in case you don't mind, the workqueue task is ksuspend_usbd.
On the other hand, I don't understand how problems with the RTC configuration could cause this sort of result.
Alan Stern
Quoted 35 lines · Alan Stern
Quoted 33 lines · Mark Lord
Same thing happens when I rmmod usbhid, and then rmmod
ehci_hcd. The rmmodehci_hcdhangs.But since the rest of the system is still alive, including the non-USB touchpad(!), here is the alt-sysrq-t from syslog:
rmmod D
f74c2ddc0 4538 4492f6d3b200 00000086 f74c2c90 f74c2ddc c281e840 00000001 c01131be 00000000 00000001 c0324a00 c0324a00 00000000 00000001 7fffffff 7fffffff f653cea8 00000002 c02906f8 00000000 00000012 c038f6aa 00000086 c011aa05 00000000 Call Trace: [__wake_up_common+46/88] __wake_up_common+0x2e/0x58 [schedule_timeout+19/134] schedule_timeout+0x13/0x86 [wake_up_klogd+43/45] wake_up_klogd+0x2b/0x2d [wait_for_common+205/308] wait_for_common+0xcd/0x134 [default_wake_function+0/8] default_wake_function+0x0/0x8 [__cancel_work_timer+237/312] __cancel_work_timer+0xed/0x138 [wq_barrier_func+0/8] wq_barrier_func+0x0/0x8 [<f889f684>] usb_remove_hcd+0x63/0xd7 [usbcore] [<f88a858e>] usb_hcd_pci_remove+0x15/0x68 [usbcore] [pci_device_remove+22/53] pci_device_remove+0x16/0x35 [__device_release_driver+88/118] __device_release_driver+0x58/0x76 [driver_detach+122/182] driver_detach+0x7a/0xb6 [bus_remove_driver+96/126] bus_remove_driver+0x60/0x7e [pci_unregister_driver+30/95] pci_unregister_driver+0x1e/0x5f [sys_delete_module+388/445] sys_delete_module+0x184/0x1bd [remove_vma+49/54] remove_vma+0x31/0x36 [do_page_fault+506/1232] do_page_fault+0x1fa/0x4d0 [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 =======================If nothing else, this should point to where USB is getting deadlocked.
Quoted 8 lines
Quoted 1 line
??
rmmod is hanging up in a call to
cancel_work_sync(), which means the real problem is in the workqueue. It's quite understandable that you wouldn't want to go any further into debugging this, but in case you don't mind, the workqueue task isksuspend_usbd.On the other hand, I don't understand how problems with the RTC configuration could cause this sort of result.
..
Yeah, me neither. It's not clear whether simply changing the kernel
config made a race condition "go away" for now, or whether it really fixed things for real.
My system is working with the current config, that's all I know right now. Gotta fix VMware modules again, but that's de-rigour with new kernels.
Cheers
Quoted 10 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.
Mark, could you try to boot with "acpi_new_pts_ordering" and retest?
Perhaps the problem is caused by the suspend ordering being wrong.
Thanks,
Rafael
Quoted 8 lines · Rafael J. Wysocki
Quoted 7 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
Quoted 7 lines
Quoted 3 lines
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.Mark, could you try to boot with "
acpi_new_pts_ordering" and retest?Perhaps the problem is caused by the suspend ordering being wrong.
..
Thanks for the suggestion. It made no difference.
I do have this in the syslog from either boot method:
proc_dir_entry 'rtc' already registered
Pid: 1, comm: swapper Not tainted 2.6.25-rc7 #2 [proc_register+185/295] proc_register+0xb9/0x127 [create_proc_entry+109/128] create_proc_entry+0x6d/0x80 [rtc_proc_add_device+26/53] rtc_proc_add_device+0x1a/0x35 [rtc_device_register+328/443] rtc_device_register+0x148/0x1bb [cmos_do_probe+197/661] cmos_do_probe+0xc5/0x295 [pnp_device_probe+99/129] pnp_device_probe+0x63/0x81 [driver_probe_device+182/296] driver_probe_device+0xb6/0x128 [__driver_attach+0/121] __driver_attach+0x0/0x79 [__driver_attach+70/121] __driver_attach+0x46/0x79 [bus_for_each_dev+55/89] bus_for_each_dev+0x37/0x59 [driver_attach+17/19] driver_attach+0x11/0x13 [__driver_attach+0/121] __driver_attach+0x0/0x79 [bus_add_driver+138/424] bus_add_driver+0x8a/0x1a8 [driver_register+69/153] driver_register+0x45/0x99 [kernel_init+307/621] kernel_init+0x133/0x26d [schedule_tail+23/68] schedule_tail+0x17/0x44 [ret_from_fork+6/28] ret_from_fork+0x6/0x1c [kernel_init+0/621] kernel_init+0x0/0x26d [kernel_init+0/621] kernel_init+0x0/0x26d [kernel_thread_helper+7/16] kernel_thread_helper+0x7/0x10
=======================rtc_cmos 00:06: rtc core: registered rtc_cmos as rtc0
rtc0: alarms up to one month, y3k
Some kind of .config conflict, I suppose -- though how it has survived this far into 2.6.25-rc* makes one wonder.
Meanwhile, I've been trying to rebuild a kernel with debug options enabled, but so far none of them will come back from suspend, just a black screen, no alt-sysrq, 5-seconds on the power button required to escape.
The last attempt had only these differences from the original problem kernel. The original at least resumes, this one doesn't. I'm rebuilding now without the PM debug flags set.
dot_config.nothing renamed from dot_config.nousb +0 -0
@@ -1,7 +1,7 @@
#
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.25-rc7
-# Thu Mar 27 10:54:45 2008
+# Thu Mar 27 22:47:32 2008
#
# CONFIG_64BIT is not setCONFIG_X86_32=y
@@ -70,7 +70,7 @@
# CONFIG_AUDIT is not setCONFIG_IKCONFIG=yCONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
+CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not setCONFIG_SYSFS_DEPRECATED=y
@@ -84,7 +84,7 @@CONFIG_UID16=yCONFIG_SYSCTL_SYSCALL=yCONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not setCONFIG_HOTPLUG=yCONFIG_PRINTK=y
@@ -277,7 +277,10 @@
#CONFIG_PM=yCONFIG_PM_LEGACY=y
-# CONFIG_PM_DEBUG is not set
+CONFIG_PM_DEBUG=y
+CONFIG_PM_VERBOSE=y
+CONFIG_CAN_PM_TRACE=y
+# CONFIG_PM_TRACE_RTC is not setCONFIG_PM_SLEEP_SMP=yCONFIG_PM_SLEEP=yCONFIG_SUSPEND=y
@@ -1767,30 +1770,35 @@CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not setCONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DEBUG_SHIRQ=yCONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not setCONFIG_TIMER_STATS=y
-# CONFIG_DEBUG_SLAB is not set
+CONFIG_DEBUG_SLAB=y
+CONFIG_DEBUG_SLAB_LEAK=y
# CONFIG_DEBUG_PREEMPT is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
-# CONFIG_DEBUG_SPINLOCK is not set
-# CONFIG_DEBUG_MUTEXES is not set
-# CONFIG_DEBUG_LOCK_ALLOC is not set
-# CONFIG_PROVE_LOCKING is not set
+CONFIG_DEBUG_SPINLOCK=y
+CONFIG_DEBUG_MUTEXES=y
+CONFIG_DEBUG_LOCK_ALLOC=y
+CONFIG_PROVE_LOCKING=y
+CONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
-# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
-# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
-# CONFIG_DEBUG_KOBJECT is not set
-# CONFIG_DEBUG_HIGHMEM is not set
+CONFIG_DEBUG_LOCKDEP=y
+CONFIG_TRACE_IRQFLAGS=y
+CONFIG_DEBUG_SPINLOCK_SLEEP=y
+CONFIG_DEBUG_LOCKING_API_SELFTESTS=y
+CONFIG_STACKTRACE=y
+CONFIG_DEBUG_KOBJECT=y
+CONFIG_DEBUG_HIGHMEM=yCONFIG_DEBUG_BUGVERBOSE=y
-# CONFIG_DEBUG_INFO is not set
-# CONFIG_DEBUG_VM is not set
-# CONFIG_DEBUG_LIST is not set
-# CONFIG_DEBUG_SG is not set
-# CONFIG_FRAME_POINTER is not set
+CONFIG_DEBUG_INFO=y
+CONFIG_DEBUG_VM=y
+CONFIG_DEBUG_LIST=y
+CONFIG_DEBUG_SG=y
+CONFIG_FRAME_POINTER=y
# CONFIG_BOOT_PRINTK_DELAY is not set
# CONFIG_RCU_TORTURE_TEST is not set
# CONFIG_BACKTRACE_SELF_TEST is not set
@@ -1799,10 +1807,11 @@
# CONFIG_PROVIDE_OHCI1394_DMA_INIT is not set
# CONFIG_SAMPLES is not set
# CONFIG_EARLY_PRINTK is not set
-# CONFIG_DEBUG_STACKOVERFLOW is not set
-# CONFIG_DEBUG_STACK_USAGE is not set
-# CONFIG_DEBUG_PAGEALLOC is not set
-# CONFIG_DEBUG_RODATA is not set
+CONFIG_DEBUG_STACKOVERFLOW=y
+CONFIG_DEBUG_STACK_USAGE=y
+CONFIG_DEBUG_PAGEALLOC=y
+CONFIG_DEBUG_RODATA=y
+# CONFIG_DEBUG_RODATA_TEST is not set
# CONFIG_DEBUG_NX_TEST is not setCONFIG_4KSTACKS=yCONFIG_X86_FIND_SMP_CONFIG=y
Quoted 16 lines · Mark Lord
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhid
Quoted 7 lines
And the console hung at 100% CPU on the insmod. Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
..
Correction there: 3GB of RAM, not 2.
Hi!
Quoted 19 lines
Quoted 19 lines
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod. Back to 2.6.24.3 again, for now -- I've got work to do.
Quoted 7 lines
Quoted 4 lines
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
..
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
If rmmod/insmod usbhid helps, and system is fully working after that, then it is probably usb problem....
Is your problem fixed after latest RTC findings? If not, try to debug insmod/rmmod of usb, first. If that does not work, it is unlikely suspend/resume will.
Pavel
Signature · 3 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html pomozte zachranit klanovicky les: http://www.ujezdskystrom.info/
Quoted 24 lines · Pavel Machek
Hi!
Quoted 22 lines
Quoted 22 lines
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod. Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
..
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
-ml
Quoted 28 lines · Mark Lord
Quoted 27 lines · Pavel Machek
Hi!
Quoted 25 lines
Quoted 23 lines
It is with great reluctance when I attempt moving my main "desktop" over to a new kernel version -- because the USB subsystem seems to break every single time.
So today I tried 2.6.25-rc7 on it for the first time. Not good.
It boots, but just a simple suspend/resume (RAM) was enough to kill it. It comes back on resume, with an X desktop again,
but with no USB functionality -- no mouse.The keyboard still works, so I dropped to a console and tried:
rmmod usbhid
insmod usbhidAnd the console hung at 100% CPU on the insmod. Back to 2.6.24.3 again, for now -- I've got work to do.
The specs of this machine have been posted with great regularity
in the past, every new kernel revision it seems. So here we go again:Dell Inspiron 9400 notebook, Intel Core2Duo T7400, 2GB SDRAM.
..
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
..
And booting with iommu=soft is worse: video comes back with bizarre timings after suspend/resume -- totally unsynced display afterwards.
Cheers
Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
Are you running with CONFIG_USB_SUSPEND? If so, please try without it.
Regards
Oliver
Quoted 9 lines · Oliver Neukum
Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
Are you running with
CONFIG_USB_SUSPEND? If so, please try without it.
..
Funny. One of the first posts in this thread told me to make sure that I do use CONFIG_USB_SUSPEND (which I have been for many kernels now).
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.
Still want USB_SUSPEND=n ? Please explain.
Thanks
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 12 lines
Quoted 9 lines · Oliver Neukum
Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Correction there: 3GB of RAM, not 2.
3GB of RAM can be a problem. Try iommu=soft. .. but in such case rmmod/insmod of usbhid would not help...
..
Booted with mem=2GB, and USB hung again on the first suspend/resume cycle.
Are you running with
CONFIG_USB_SUSPEND? If so, please try without it...
Quoted 8 lines
Funny. One of the first posts in this thread told me to make sure that I do use
CONFIG_USB_SUSPEND(which I have been for many kernels now).One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.
Yes. What happens if you unload only usbhid at that time?
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
Regards
Oliver
Quoted 9 lines · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 5 lines
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.Yes. What happens if you unload only usbhid at that time?
..
Mmm.. interesting choice, there. I'll try that.
There is another quirk on this machine that might confuse software that's not robust: the internal Bluetooth adapter is USB connected, and I normally have it disabled (BIOS hotkey). So it normally is "not present".
But on any power-on / resume, it briefly powers up and becomes "present", and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it. If that software is not carefully coded, it might get confused.
This has not been a problem before, but perhaps with the new USB autosuspend code?
Quoted 4 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
..
Okay, and once we see that it works fine: then what?
Quoted 19 lines · Mark Lord
Quoted 9 lines · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 5 lines
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.Yes. What happens if you unload only usbhid at that time?
..
Mmm.. interesting choice, there. I'll try that.
There is another quirk on this machine that might confuse software that's not robust: the internal Bluetooth adapter is USB connected, and I normally have it disabled (BIOS hotkey). So it normally is "not present".
Quoted 7 lines
But on any power-on / resume, it briefly powers up and becomes "present", and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it. If that software is not carefully coded, it might get confused.
This has not been a problem before, but perhaps with the new USB autosuspend code?
..
Speaking of which.. what's with this "broken" message? I wonder if it could be at all related ?
kobject: 'hci_usb' (f89d2948): kobject_cleanup
kobject: 'hci_usb' (f89d2948): does not have a release() function, it is broken and must be fixed.
kobject: 'hci_usb' (f89d2948): auto cleanup 'remove' event
kobject: 'hci_usb' (f89d2948): kobject_uevent_env
kobject: 'hci_usb' (f89d2948): fill_kobj_path: path = '/module/hci_usb'
kobject: 'hci_usb' (f89d2948): auto cleanup kobject_del
kobject: 'hci_usb': free name
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 19 lines
Quoted 9 lines · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 5 lines
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.Yes. What happens if you unload only usbhid at that time?
..
Mmm.. interesting choice, there. I'll try that.
There is another quirk on this machine that might confuse software that's not robust: the internal Bluetooth adapter is USB connected, and I normally have it disabled (BIOS hotkey). So it normally is "not present".
Quoted 7 lines
But on any power-on / resume, it briefly powers up and becomes "present", and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it. If that software is not carefully coded, it might get confused.
This has not been a problem before, but perhaps with the new USB autosuspend code?
hci_usb doesn't have any autosuspend code.
Quoted 7 lines
Quoted 4 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
..
Okay, and once we see that it works fine: then what?
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
Regards
Oliver
Quoted 32 lines · Oliver Neukum
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 18 lines
Quoted 8 lines · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 5 lines
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.Yes. What happens if you unload only usbhid at that time?
..
Mmm.. interesting choice, there. I'll try that.
There is another quirk on this machine that might confuse software that's not robust: the internal Bluetooth adapter is USB connected, and I normally have it disabled (BIOS hotkey). So it normally is "not present".
Quoted 7 lines
But on any power-on / resume, it briefly powers up and becomes "present", and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it. If that software is not carefully coded, it might get confused.
This has not been a problem before, but perhaps with the new USB autosuspend code?
hci_usbdoesn't have any autosuspend code.Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
Quoted 8 lines
Quoted 3 lines
..
Okay, and once we see that it works fine: then what?
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
..
Thanks!
It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded.
I'm still working my way through the rest of the suggestions here, and USB_DEBUG=n is next.
I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB. But with a voltmeter, I discovered that there is sufficient capacitance on the USB +5V, that it takes many minutes for the voltage to decay from 5.1V down to near 0V.
Resuming while the voltage is still relatively high, generally works. Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines, forcing it to decay to zero within about 5 seconds. This helps a lot for debugging here.
It probably also provides a vital clue as to what is wrong. Resume seems to generally work when the USB devices maintain some amount of standby power, and always fails when they don't.
Quoted 41 lines · Mark Lord
Quoted 32 lines · Oliver Neukum
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 18 lines
Quoted 8 lines · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
Quoted 5 lines
One thing I just tried, was to unload all USB stuff before suspend, and reload on resume -- just stuck the commands into my suspend/resume script.
The machine has been 100% rock solid since then.
So I think that definitely implicates USB.Yes. What happens if you unload only usbhid at that time?
..
Mmm.. interesting choice, there. I'll try that.
There is another quirk on this machine that might confuse software that's not robust: the internal Bluetooth adapter is USB connected, and I normally have it disabled (BIOS hotkey). So it normally is "not present".
Quoted 7 lines
But on any power-on / resume, it briefly powers up and becomes "present", and, after a second or two, the BIOS powers it down again, "not present".
Just long enough for software to notice it and try talking to it. If that software is not carefully coded, it might get confused.
This has not been a problem before, but perhaps with the new USB autosuspend code?
hci_usbdoesn't have any autosuspend code.Quoted 3 lines
Quoted 3 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
Quoted 8 lines
Quoted 3 lines
..
Okay, and once we see that it works fine: then what?
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
Quoted 8 lines
..
Thanks!
It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded.
I'm still working my way through the rest of the suggestions here, and USB_DEBUG=n is next.
..
Correction.. USB_SUSPEND=n is next.
Quoted 22 lines
I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB. But with a voltmeter, I discovered that there is sufficient capacitance on the USB +5V, that it takes many minutes for the voltage to decay from 5.1V down to near 0V.Resuming while the voltage is still relatively high, generally works. Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines, forcing it to decay to zero within about 5 seconds. This helps a lot for debugging here.
It probably also provides a vital clue as to what is wrong. Resume seems to generally work when the USB devices maintain some amount of standby power, and always fails when they don't.
Signature · 4 lines
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Quoted 4 lines · Mark Lord
Quoted 3 lines · Oliver Neukum
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 2 lines
Quoted 1 line · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
..
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
..
Okay, and once we see that it works fine: then what?
Quoted 7 lines
Quoted 4 lines
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
..
It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded.
..
And it does *not* hang with # CONFIG_USB_SUSPEND is not set.
Quoted 16 lines
I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB. But with a voltmeter, I discovered that there is sufficient capacitance on the USB +5V, that it takes many minutes for the voltage to decay from 5.1V down to near 0V.Resuming while the voltage is still relatively high, generally works. Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines, forcing it to decay to zero within about 5 seconds. This helps a lot for debugging here.
It probably also provides a vital clue as to what is wrong. Resume seems to generally work when the USB devices maintain some amount of standby power, and always fails when they don't.
Quoted 17 lines · Mark Lord
Quoted 4 lines · Mark Lord
Quoted 3 lines · Oliver Neukum
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 2 lines
Quoted 1 line · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
..
Quoted 11 lines
Quoted 11 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
..
Okay, and once we see that it works fine: then what?
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
Quoted 23 lines
Quoted 3 lines
..
It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded...
And it does *not* hang with #
CONFIG_USB_SUSPENDis not set.Quoted 16 lines
I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB. But with a voltmeter, I discovered that there is sufficient capacitance on the USB +5V, that it takes many minutes for the voltage to decay from 5.1V down to near 0V.Resuming while the voltage is still relatively high, generally works. Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines, forcing it to decay to zero within about 5 seconds. This helps a lot for debugging here.
It probably also provides a vital clue as to what is wrong. Resume seems to generally work when the USB devices maintain some amount of standby power, and always fails when they don't.
..
Note that it makes no difference whether I unplug all external USB devices prior to suspend or not. The failure patterns remain the same.
Quoted 38 lines · Mark Lord
Quoted 37 lines · Mark Lord
Quoted 4 lines · Mark Lord
Quoted 3 lines · Oliver Neukum
Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
Quoted 2 lines
Quoted 1 line · Oliver Neukum
Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
..
Quoted 7 lines
Quoted 7 lines
Quoted 6 lines
Quoted 3 lines
Quoted 1 line
Still want USB_SUSPEND=n ? Please explain.
It looks like you are hanging in the kthread for autosuspending. Compiling that out should confirm it.
..
Okay, and once we see that it works fine: then what?
Quoted 7 lines
Quoted 4 lines
We'll combine that information with the result of only removing usbhid and arrive at a pretty good idea where in the kernel the hang occurs. There are only two functions that touch autosuspend in the usbhid code. So if it works with usbhid unloaded, either of them should be to blame.
..
It does still hang with *usbhid* unloaded,
but not if all USB stuff is unloaded...
And it does *not* hang with #
CONFIG_USB_SUSPENDis not set.Quoted 13 lines
I have figured out a way to make this much more reproducible now:
When suspended, the notebook does not supply +5V over USB. But with a voltmeter, I discovered that there is sufficient capacitance on the USB +5V, that it takes many minutes for the voltage to decay from 5.1V down to near 0V.Resuming while the voltage is still relatively high, generally works. Resuming after the voltage drops to near zero, always fails (with USB modules loaded).
So I've put a 2Kohm resistor across the USB +5V lines, forcing it to decay to zero within about 5 seconds. This helps a lot for debugging here.
Quoted 7 lines
Quoted 3 lines
Quoted 3 lines
It probably also provides a vital clue as to what is wrong. Resume seems to generally work when the USB devices maintain some amount of standby power, and always fails when they don't.
..
Note that it makes no difference whether I unplug all external USB devices prior to suspend or not. The failure patterns remain the same.
..
I've now removed the internal USB-Bluetooth adaptor, so we can now test without any USB devices connected.
Suspend without any USB devices plugged-in, and it *always* resumes fine with working USB, even when the USB stuff is plugged in before hitting the resume button.
But suspend *with* any USB device plugged-in, and it *always* fails resume, even when the USB device is unplugged before hitting the resume button.
Conclusion: the bug is in the usb SUSPEND code, not the RESUME code.
Am Montag, 31. März 2008 19:30:46 schrieb Mark Lord:
Quoted 6 lines
I've now removed the internal USB-Bluetooth adaptor, so we can now test without any USB devices connected.
Suspend without any USB devices plugged-in, and it *always* resumes fine with working USB, even when the USB stuff is plugged in before hitting the resume button.
To the USB subsystem these devices are plugged in as soon as power is returned.
Quoted 4 lines
But suspend *with* any USB device plugged-in, and it *always* fails resume, even when the USB device is unplugged before hitting the resume button.
Conclusion: the bug is in the usb SUSPEND code, not the RESUME code.
I would arrive at the opposite conclusion. Independent from that, loss of power is not really supported by USB during STR. Obviously it should not hang, but all devices will be disconnected and reconnected.
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
Regards
Oliver
Quoted 4 lines · Oliver Neukum
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
..
No, that's no different.
This notebook always cuts +5V from USB on suspend or poweroff. Regardless of kernel version. I don't know how common this is, but all of my notebooks here have always behaved this way, as have most (but not all) of the larger systems.
The two most recent PCIe motherboards I have here do provide +5V standby power to USB, even when "OFF", much to my annoyance and to the detriment of this planet.
Cheers
Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
Quoted 13 lines
Quoted 4 lines · Oliver Neukum
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
..
No, that's no different.
This notebook always cuts +5V from USB on suspend or poweroff. Regardless of kernel version. I don't know how common this is, but all of my notebooks here have always behaved this way, as have most (but not all) of the larger systems.
Quoted 3 lines
The two most recent PCIe motherboards I have here do provide +5V standby power to USB, even when "OFF", much to my annoyance and to the detriment of this planet.
Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes dead? And please enable CONFIG_USB_DEBUG. We need to do whether khubd and ksuspend_usbd are in state D.
Regards
Oliver
(CCing Alan Stern on this sub-thread)
Quoted 17 lines · Oliver Neukum
Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
Quoted 12 lines
Quoted 3 lines · Oliver Neukum
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
..
No, that's no different.
This notebook always cuts +5V from USB on suspend or poweroff. Regardless of kernel version. I don't know how common this is, but all of my notebooks here have always behaved this way, as have most (but not all) of the larger systems.Quoted 3 lines
The two most recent PCIe motherboards I have here do provide +5V standby power to USB, even when "OFF", much to my annoyance and to the detriment of this planet.
Quoted 5 lines
Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes dead? And please enable
CONFIG_USB_DEBUG. We need to do whether khubd andksuspend_usbdare in state D.
..
Both of those things were already done, and results from the last time are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers
(CCing linux-usb again)
(CCing Alan Stern on this sub-thread)
Quoted 17 lines · Oliver Neukum
Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
Quoted 12 lines
Quoted 3 lines · Oliver Neukum
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
..
No, that's no different.
This notebook always cuts +5V from USB on suspend or poweroff. Regardless of kernel version. I don't know how common this is, but all of my notebooks here have always behaved this way, as have most (but not all) of the larger systems.Quoted 3 lines
The two most recent PCIe motherboards I have here do provide +5V standby power to USB, even when "OFF", much to my annoyance and to the detriment of this planet.
Quoted 5 lines
Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes dead? And please enable
CONFIG_USB_DEBUG. We need to do whether khubd andksuspend_usbdare in state D.
..
Both of those things were already done, and results from the last time are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers
2.6.25-rc7/rc8 USB dead on resume
Quoted 26 lines · Mark Lord
(CCing linux-usb again)
(CCing Alan Stern on this sub-thread)Quoted 17 lines · Oliver Neukum
Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
Quoted 12 lines
Quoted 3 lines · Oliver Neukum
But if power is cut with newer kernels and older kernels retain it, something must have changed. Can you undo the ACPI changes since the last working kernel?
..
No, that's no different.
This notebook always cuts +5V from USB on suspend or poweroff. Regardless of kernel version. I don't know how common this is, but all of my notebooks here have always behaved this way, as have most (but not all) of the larger systems.Quoted 3 lines
The two most recent PCIe motherboards I have here do provide +5V standby power to USB, even when "OFF", much to my annoyance and to the detriment of this planet.
Quoted 5 lines
Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes dead? And please enable
CONFIG_USB_DEBUG. We need to do whether khubd andksuspend_usbdare in state D.
Quoted 6 lines
..
Both of those things were already done, and results from the last time are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
..
No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config as attachements to the bugzilla entry:
Re: 2.6.25-rc7/rc8 USB dead on resume
Am Mittwoch, 2. April 2008 17:05:21 schrieb Mark Lord:
Quoted 8 lines
Mark Lord wrote:
No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config as attachements to the bugzilla entry:
http://bugzilla.kernel.org/show_bug.cgi?id=10345
Same analysis. ehci_endpoint_disable() is spinning and ksuspend_usb is waiting for it.
Regards
Oliver
PS: Sorry for not looking at the full bugzilla entry
Alan Stern
maintainerQuoted 1 line · Mark Lord
I'll be installing -rc8 today, and see what happens there.
Have you tried testing with all the USB drivers present except ehci-hcd? So far all the indicators are that it is the source of the problem.
Also, check out the thread on LKML started by Tino Keitel. He had similar problems and found that reverting commit e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
Alan Stern
Re: 2.6.25-rc7: Ugh. ---> PATCH
This patch seems to fix it.
Could you guys look this over some more,
as I really am not familiar with the USB code.
* * * *
When comparing 2.6.24 against 2.6.25, this line of code stood out as not looking entirely correct, given the new uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths on my machine here. More testing is needed to be sure.
drivers/usb/host/ehci-hcd.c +0 -0
@@ -815,7 +815,7 @@
end_unlink_async(ehci); /* if it's not linked then there's nothing to do */ - if (qh->qh_state != QH_STATE_LINKED) + if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT) ; /* defer till later if busy */
Re: 2.6.25-rc7: Ugh. ---> PATCH
Quoted 3 lines · Mark Lord
This patch seems to fix it.
Could you guys look this over some more,
as I really am not familiar with the USB code.
Here it is again, with more lines of context, for easier review:
* * *
When comparing 2.6.24 against 2.6.25, this line of code stood out as not looking entirely correct, given the new uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths on my machine here. More testing is needed to be sure.
---
Regenerated with more context in diff, for easier review.
drivers/usb/host/ehci-hcd.c renamed from drivers/usb/host/ehci-hcd.c.orig +0 -0
@@ -801,35 +801,35 @@
return intr_submit(ehci, urb, &qtd_list, mem_flags); case PIPE_ISOCHRONOUS: if (urb->dev->speed == USB_SPEED_HIGH) return itd_submit (ehci, urb, mem_flags); else return sitd_submit (ehci, urb, mem_flags); } }
static void unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh)
{
/* failfast */
if (!HC_IS_RUNNING(ehci_to_hcd(ehci)->state) && ehci->reclaim)
end_unlink_async(ehci);
/* if it's not linked then there's nothing to do */
- if (qh->qh_state != QH_STATE_LINKED)
+ if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
;
/* defer till later if busy */
else if (ehci->reclaim) {
struct ehci_qh *last;
for (last = ehci->reclaim;
last->reclaim;
last = last->reclaim)
continue;
qh->qh_state = QH_STATE_UNLINK_WAIT;
last->reclaim = qh;
/* start IAA cycle */
} else
start_unlink_async (ehci, qh);
}Re: 2.6.25-rc7: Ugh. ---> PATCH
Quoted 6 lines · Mark Lord
Quoted 3 lines · Mark Lord
This patch seems to fix it.
Could you guys look this over some more,
as I really am not familiar with the USB code.Here it is again, with more lines of context, for easier review:
..
Nope. Nevermind.
Just got lucky once, without the resistor installed on USB power.
The patch doesn't fix it. But that code still looks strange to me.
Cheers
Alan Stern
maintainerRe: 2.6.25-rc7: Ugh. ---> PATCH
In reply to Mark LordQuoted 7 lines · Mark Lord
When comparing 2.6.24 against 2.6.25, this line of code stood out as not looking entirely correct, given the new uses of
QH_STATE_UNLINK_WAITin 2.6.25.
drivers/usb/host/ehci-hcd.c line 821
Quoted 8 lines
drivers/usb/host/ehci-hcd.c +1
-1@@ -815,7 +815,7 @@end_unlink_async (ehci);/* if it's not linked then there's nothing to do */ -if (qh->qh_state !=QH_STATE_LINKED ) +if (qh->qh_state !=QH_STATE_LINKED && qh->qh_state !=QH_STATE_UNLINK_WAIT ) ;/* defer till later if busy */
To answer your implied question...
QH_STATE_UNLINK_WAIT doesn't have a new meaning in 2.6.25. Just as before, it means that qh is on a queue waiting to be unlinked.
qh->qh_state can never be equal to QH_STATE_UNLINK_WAIT at this point. If it were, it would mean that some part of the driver had tried to unlink qh twice. But even then, the correct move would be to follow the "nothing to do" path -- since qh is already waiting to be unlinked, there's no point trying to do any more.
Alan Stern
Quoted 3 lines
Also, check out the thread on LKML started by Tino Keitel. He had similar problems and found that reverting commit
e82cc1288fa57857c6af8c57f3d07096d4bcd9d9fixed them.
And try the change I suggested there: taking theHC_IS_RUNNING test out of ehci_iaa_watchdog().
Quoted 6 lines · David Brownell
Quoted 3 lines
Also, check out the thread on LKML started by Tino Keitel. He had similar problems and found that reverting commit
e82cc1288fa57857c6af8c57f3d07096d4bcd9d9fixed them.And try the change I suggested there: taking the
HC_IS_RUNNINGtest out ofehci_iaa_watchdog().
..
Will do, thanks. And there's a similar one in ehci_work(). ??
Quoted 6 lines · Mark Lord
Quoted 3 lines
And try the change I suggested there: taking the
HC_IS_RUNNINGtest out ofehci_iaa_watchdog()...
Will do, thanks. And there's a similar one in
ehci_work(). ??
Don't see why that should matter. In any case, that test hasn't changed recently.
PATCH 1/1 usb ehci_iaa_watchdog fix
In reply to David BrownellQuoted 6 lines · David Brownell
Quoted 3 lines
Also, check out the thread on LKML started by Tino Keitel. He had similar problems and found that reverting commit
e82cc1288fa57857c6af8c57f3d07096d4bcd9d9fixed them.And try the change I suggested there: taking the
HC_IS_RUNNINGtest out ofehci_iaa_watchdog().
..
Yup, that does indeed cure it.
Here's a patch, in case you didn't already generate one:
drivers/usb/host/ehci-hcd.c +0 -0
@@ -289,9 +289,7 @@
* (a) SMP races against real IAA firing and retriggering, and
* (b) clean HC shutdown, when IAA watchdog was pending. */
- if (ehci->reclaim
- && !timer_pending(&ehci->iaa_watchdog)
- && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
+ if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
u32 cmd, status;
/* If we get here, IAA is *REALLY* late. It's barelyAlan Stern
maintainerRe: [PATCH] usb ehci_iaa_watchdog fix
Quoted 8 lines · Mark Lord
Yup, that does indeed cure it.
Here's a patch, in case you didn't already generate one:Signed-off-by Mark Lord <[email protected]>
drivers/usb/host/ehci-hcd.c line 295
Quoted 10 lines
drivers/usb/host/ehci-hcd.c +1
-3@@ -289,9 +289,7 @@* (a) SMP races against real IAA firing and retriggering, and * (b) clean HC shutdown, when IAA watchdog was pending. */ -if (ehci->reclaim - && !timer_pending (&ehci->iaa_watchdog) - &&HC_IS_RUNNING (ehci_to_hcd (ehci)->state)) { +if (ehci->reclaim && !timer_pending (&ehci->iaa_watchdog)) {u32 cmd, status;/* If we get here, IAA is *REALLY* late. It's barely
Okay, I'm puzzled. How could this make any difference? ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is set.
Is the real problem that it does so before calling ehci_work() instead of after calling ehci_halt()?
Mark, if you want to experiment some more, try reverting your patch above and moving:
if (ehci->reclaim) end_unlink_async(ehci);
in ehci-hub.c:ehci_bus_suspend() to just after the line saying:
hcd->state = HC_STATE_SUSPENDED;
Alan Stern
Re: [PATCH] usb ehci_iaa_watchdog fix
Quoted 19 lines · Alan Stern
Quoted 17 lines · Mark Lord
Yup, that does indeed cure it.
Here's a patch, in case you didn't already generate one:Signed-off-by Mark Lord <[email protected]>drivers/usb/host/ehci-hcd.c +1
-3@@ -289,9 +289,7 @@* (a) SMP races against real IAA firing and retriggering, and * (b) clean HC shutdown, when IAA watchdog was pending. */ -if (ehci->reclaim - && !timer_pending (&ehci->iaa_watchdog) - &&HC_IS_RUNNING (ehci_to_hcd (ehci)->state)) { +if (ehci->reclaim && !timer_pending (&ehci->iaa_watchdog)) {u32 cmd, status;
Quoted 7 lines
drivers/usb/host/ehci-hcd.c line 295
Quoted 1 line
drivers/usb/host/ehci-hcd.c +0
-0/* If we get here, IAA is *REALLY* late. It's barely Okay, I'm puzzled. How could this make any difference?
ehci_bus_suspend()callsend_unlink_async()anyway, whenever reclaim is set.Is the real problem that it does so before calling
ehci_work()instead of after callingehci_halt()?Mark, if you want to experiment some more, try reverting your patch above and moving:
..
Here's what I did, and yes, this also works. Pick one.
This patch, suggested by Alan Stern, fixes the hung USB issues on my notebook from suspend/resume cycles.
drivers/usb/host/ehci-hub.c +0 -0
@@ -135,8 +135,6 @@
hcd->state = HC_STATE_QUIESCING; } ehci->command = ehci_readl(ehci, &ehci->regs->command); - if (ehci->reclaim) - end_unlink_async(ehci); ehci_work(ehci); /* Unlike other USB host controller types, EHCI doesn't have @@ -180,6 +178,9 @@ ehci_halt (ehci); hcd->state = HC_STATE_SUSPENDED;
+ if (ehci->reclaim)
+ end_unlink_async(ehci);
+
/* allow remote wakeup */ mask = INTR_MASK; if (!device_may_wakeup(&hcd->self.root_hub->dev))
Re: [PATCH] usb ehci_iaa_watchdog fix
Quoted 51 lines · Mark Lord
Quoted 21 lines · Alan Stern
Quoted 19 lines · Mark Lord
Yup, that does indeed cure it.
Here's a patch, in case you didn't already generate one:Signed-off-by Mark Lord <[email protected]>---
rc8/drivers/usb/host/ehci-hcd.c2008-03-11 11:18:40.000000000
-0400
+++linux/drivers/usb/host/ehci-hcd.c2008-04-02
12:16:40.000000000 -0400(quoted diff) +1
-3@@ -289,9 +289,7 @@ * (a) SMP races against real IAA firing and retriggering, and * (b) clean HC shutdown, when IAA watchdog was pending. */ - if (ehci->reclaim - && !timer_pending(&ehci->iaa_watchdog) - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) { + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) { u32 cmd, status;Quoted 7 lines
Review line 295
Quoted 1 line
(quoted diff) +0
-0/* If we get here, IAA is *REALLY* late. It's barelyOkay, I'm puzzled. How could this make any difference?
ehci_bus_suspend()callsend_unlink_async()anyway, whenever reclaim is set.Is the real problem that it does so before calling
ehci_work()instead of after callingehci_halt()?Mark, if you want to experiment some more, try reverting your patch above and moving:
..
Here's what I did, and yes, this also works. Pick one.
This patch, suggested by Alan Stern, fixes the hung USB issues on my notebook from suspend/resume cycles.
Signed-off-by Mark Lord <[email protected]>drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000 renamed from drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400 +0
-3-0400@@ -135,8 +135,6 @@ hcd->state = HC_STATE_QUIESCING; } ehci->command = ehci_readl(ehci, &ehci->regs->command); - if (ehci->reclaim) - end_unlink_async(ehci); ehci_work(ehci); /* Unlike other USB host controller types, EHCI doesn't have
drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000 line 186
Quoted 9 lines
drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000 renamed from drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400 +3
-0@@ -180,6 +178,9 @@ ehci_halt (ehci); hcd->state = HC_STATE_SUSPENDED; + if (ehci->reclaim) + end_unlink_async(ehci); + /* allow remote wakeup */ mask = INTR_MASK; if (!device_may_wakeup(&hcd->self.root_hub->dev))
..
Either patch is stable here, and have survived reboots and suspend/resumes, with and without the 2.2Kohm resistor to drain residual USB voltage.
Which one should Andrew/Linus take?
-ml
Alan Stern
maintainerRe: [PATCH] usb ehci_iaa_watchdog fix
Quoted 2 lines · Mark Lord
Either patch is stable here, and have survived reboots and suspend/resumes, with and without the 2.2Kohm resistor to drain residual USB voltage.
Great! Thanks for testing.
Quoted 1 line
Which one should Andrew/Linus take?
It's up to David, of course. My preference is for the patch I proposed, naturally enough. It fixes the cause rather than the symptom.
Alan Stern
Re: [PATCH] usb ehci_iaa_watchdog fix
Quoted 4 lines · Alan Stern
Quoted 1 line
Which one should Andrew/Linus take?
It's up to David, of course. My preference is for the patch I proposed, naturally enough.
Mine was for the one that got two "it works" confirmations. :)
Quoted 1 line
It fixes the cause rather than the symptom.
I'm not sure I'd agree with that.
Alan Stern
maintainerRe: [PATCH] usb ehci_iaa_watchdog fix
Quoted 3 lines · David Brownell
Quoted 1 line
It fixes the cause rather than the symptom.
I'm not sure I'd agree with that.
Really? The logic seemed clear enough to me.
1. Evidently the ehci_iaa_watchdog routine was getting called at a time when the host controller wasn't running -- which had to have been after it was suspended.
2. But ehci_bus_suspend() calls end_unlink_async(), which turns off the IAA watchdog timer.
3. Hence the timer must have been restarted later on while ehci_bus_suspend() was still running. The call to ehci_work() appeared to be the only place that could have happened.
4. Thus moving the end_unlink_async() call to after ehci_work() (or just to be doubly safe, after ehci_halt() and the change to HC_STATE_SUSPENDED) should take care of all pending QH unlinks and leave none of them unfinished.
Strictly speaking, it would be best to move the del_timer_sync() calls to after ehci_lock is released. But it doesn't really matter if the timer routines get invoked after the controller is suspended.
Alan Stern
Re: [PATCH] usb ehci_iaa_watchdog fix
Quoted 11 lines · Alan Stern
Quoted 3 lines · David Brownell
Quoted 1 line
It fixes the cause rather than the symptom.
I'm not sure I'd agree with that.
Really? The logic seemed clear enough to me.
1. Evidently the
ehci_iaa_watchdogroutine was getting called at a time when the host controller wasn't running -- which had to have been after it was suspended.
The change to remove the HC_IS_RUNNING test meant that routine would then work when hcd->state is HC_STATE_SUSPENDED or possibly HC_STATE_RESUMING. (Since those are the two states for which HC_IS_RUNNING fails, other than HC_STATE_HALTED which shouldn't be happening here...)
Now, prior to the now-merged patch that was skipping some work, and that seemed to cause resume problems. Making it not skip the work made the resume behave (as did the now-merged patch).
Quoted 2 lines
2. But
ehci_bus_suspend()callsend_unlink_async(), which turns off the IAA watchdog timer.
Not exactly. First, ehci_bus_suspend() force the timer off all by itself ... way too early, while things can still retrigger it. That's a buggy idiom that should be fixed. (As you've agreed, elsewhere.)
Second, it doesn't always call end_unlink_async() ... only when one or more async unlink is still pending.
Third, if it *does* call end_unlink_async(), it can retriger the timer when it needs to do another unlink. Only when the HC is halted (HC_STATE_HALT) is that logic bypassed, scrubbing several endpoints at once. (And a minor fourth point, direct calls to end_unlink_async leaves the IAA IRQ machinery active.)
I think your fix handles the "one pending unlink" case, but not the more general "N pending unlinks" ...
Quoted 3 lines
3. Hence the timer must have been restarted later on while
ehci_bus_suspend()was still running. The call toehci_work()appeared to be the only place that could have happened.
Removing the state check in the watchdog changed behavior, so the HC must have been in one of the two states I listed above when that watchdog fired (SUSPENDED or RESUMING). And it had work to do, which (because of the state check) it didn't do.
Quoted 4 lines
4. Thus moving the
end_unlink_async()call to afterehci_work()(or just to be doubly safe, afterehci_halt()and the change toHC_STATE_SUSPENDED) should take care of all pending QH unlinks and leave none of them unfinished.
It takes care of *ONE* pending QH unlink. If there's more than one, it retriggers the timer, so this problem will reappear...
Quoted 3 lines
Strictly speaking, it would be best to move the
del_timer_sync()calls to afterehci_lockis released. But it doesn't really matter if the timer routines get invoked after the controller is suspended.
When the timer would be retriggered, to finish additional unlinks, it does matter. A complete fix for this would (a) disable the IAA watchdog timer later, once it can never be retriggered again, and
(b) make end_unlink_async handle the multiple-unlinks case when the HC is suspended, including not retriggering the watchdog.
- Dave
Quoted 3 lines
Alan Stern
Alan Stern
maintainerRe: [PATCH] usb ehci_iaa_watchdog fix
Quoted 8 lines · David Brownell
Third, if it *does* call
end_unlink_async(), it can retriger the timer when it needs to do another unlink. Only when the HC is halted (HC_STATE_HALT) is that logic bypassed, scrubbing several endpoints at once. (And a minor fourth point, direct calls toend_unlink_asyncleaves the IAA IRQ machinery active.)I think your fix handles the "one pending unlink" case, but not the more general "N pending unlinks" ...
Sounds right. That test at the end of start_unlink_async() should be changed to !RUNNING instead of HALT.
To help prevent unwanted recursion, I wrote a patch some time ago that would batch up multiple unlinks. (The idea was to keep track of which entries were added to the reclaim queue before the current IAA cycle got started, and handle them all at one stroke when the current cycle ends.) That patch is a bit out-of-date now, but it shouldn't be too hard to bring it up to speed.
Quoted 5 lines
When the timer would be retriggered, to finish additional unlinks, it does matter. A complete fix for this would (a) disable the IAA watchdog timer later, once it can never be retriggered again, and
(b) makeend_unlink_asynchandle the multiple-unlinks case when the HC is suspended, including not retriggering the watchdog.
Agreed. If the code does (a) after (b) then end_unlink_async doesn't need to avoid retriggering the watchdog.
Alan Stern
Re: [PATCH] usb ehci_iaa_watchdog fix
In reply to Alan SternQuoted 9 lines · Alan Stern
Quoted 7 lines
- if (
ehci->reclaim
- && !timer_pending(&ehci->iaa_watchdog) - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) { + if (ehci->reclaim&& !timer_pending(&ehci->iaa_watchdog)) { u32 cmd, status;
/* If we get here, IAA is *REALLY* late. It's barelyOkay, I'm puzzled. How could this make any difference?
It's more like: what else in that patch could have had any such effect? That HC_IS_RUNNING test was the only candidate.
Those hcd->state tests have been getting more and more dodgey as time goes by. At this point I hardly trust any of them. There *IS* no clear state machine which governs the usbcore/HCD interaction.
- Dave
Alan Stern
maintainerRe: [PATCH] usb ehci_iaa_watchdog fix
Quoted 4 lines · David Brownell
Those
hcd->statetests have been getting more and more dodgey as time goes by. At this point I hardly trust any of them. There *IS* no clear state machine which governs the usbcore/HCD interaction.
ISTR trying to make that same point a few times over the past two or three years... :-)
It would make more sense for each HCD to keep its own private "state" variable. The interaction with usbcore can be broken down into a few simple tests, such as:
Is the HC dead?
Is the HC (i.e., the PCI or platform device) suspended? Is the HC running?
Is it okay to submit an URB?
There's plenty of redundancy in this list, and some of the information may already be available in hcd->self.root_hub->state. In many or most cases, these questions can't be answered in a race-free manner anyhow, which limits their usefulness.
Alan Stern
Re: [PATCH] usb ehci_iaa_watchdog fix
Quoted 9 lines · Alan Stern
Quoted 4 lines · David Brownell
Those
hcd->statetests have been getting more and more dodgey as time goes by. At this point I hardly trust any of them. There *IS* no clear state machine which governs the usbcore/HCD interaction.ISTR trying to make that same point a few times over the past two or three years... :-)
Was there any argument about that fact? The question was more "shouldn't there actually *be* such a state machine" than "do we have one yet".
Quoted 9 lines
It would make more sense for each HCD to keep its own private "state" variable. The interaction with usbcore can be broken down into a few simple tests, such as:
Is the HC dead?
Is the HC (i.e., the PCI or platform device) suspended? Is the HC running?
Is it okay to submit an URB?
Quoted 4 lines
There's plenty of redundancy in this list, and some of the information may already be available in
hcd->self.root_hub->state. In many or most cases, these questions can't be answered in a race-free manner anyhow, which limits their usefulness.
At any given instant, all of them have valid answers. The only one that's not resolvable by mutual exclusion on the HCD's spinlock is "is it dead", since the HC could crap out at any time. (Nowadays that's fortunately rare ... we've been whomping on such bugs for long enough by now!)
- Dave
Re: [PATCH] usb ehci_iaa_watchdog fix
In reply to Mark LordQuoted 10 lines · Mark Lord
Quoted 6 lines · David Brownell
Quoted 3 lines
Also, check out the thread on LKML started by Tino Keitel. He had similar problems and found that reverting commit
e82cc1288fa57857c6af8c57f3d07096d4bcd9d9fixed them.And try the change I suggested there: taking the
HC_IS_RUNNINGtest out ofehci_iaa_watchdog()...
Yup, that does indeed cure it.
Given your immediately-preceding experience, I'll wait for a bit more confirmation ... but this seems like a candidate to merge while 2.6.25 still hasn't frozen!!
Quoted 1 line
Here's a patch, in case you didn't already generate one:
I hadn't; thanks.
Quoted 16 lines
Signed-off-by Mark Lord <[email protected]>drivers/usb/host/ehci-hcd.c +1
-3@@ -289,9 +289,7 @@* (a) SMP races against real IAA firing and retriggering, and * (b) clean HC shutdown, when IAA watchdog was pending. */ -if (ehci->reclaim - && !timer_pending (&ehci->iaa_watchdog) - &&HC_IS_RUNNING (ehci_to_hcd (ehci)->state)) { +if (ehci->reclaim && !timer_pending (&ehci->iaa_watchdog)) {u32 cmd, status;/* If we get here, IAA is *REALLY* late. It's barely
Hi!
Quoted 8 lines
Quoted 4 lines
But suspend *with* any USB device plugged-in, and it *always* fails resume, even when the USB device is unplugged before hitting the resume button.
Conclusion: the bug is in the usb SUSPEND code, not the RESUME code.
I would arrive at the opposite conclusion. Independent from that, loss of power is not really supported by USB during STR. Obviously it should not hang, but all devices will be disconnected and reconnected.
All devices disconnected / reconnected is expected, but it has to work. Machines like thinkpad x60 kill USB power during s2ram.
Pavel
Signature · 2 lines
(english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html