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
On Thu, Mar 27, 2008 at 11:29:27AM -0400, Mark Lord wrote:
> 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:)
> 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.
Haven't heard of this one before sorry. Jiri, have you?
> 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
This looks like your usb device should be up and working.
Do you have CONFIG_USB_SUSPEND enabled in your .config?
> ## 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 :(
>
> 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
On Thursday, 27 of March 2008, Mark Lord wrote:
> 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
On Thu, 27 Mar 2008, Greg KH wrote:
> > 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 ... ?
> > 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
Hmm, what device is this?
--
Jiri Kosina
SUSE Labs
>Do you have CONFIG_USB_SUSPEND enabled 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 set
CONFIG_X86_32=y
# CONFIG_X86_64 is not set
CONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set
CONFIG_GENERIC_TIME=y
CONFIG_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=y
CONFIG_MMU=y
CONFIG_ZONE_DMA=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
# CONFIG_GENERIC_GPIO is not set
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_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=y
CONFIG_X86_SMP=y
CONFIG_X86_32_SMP=y
CONFIG_X86_HT=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_X86_TRAMPOLINE=y
CONFIG_KTIME_SCALAR=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#
CONFIG_EXPERIMENTAL=y
CONFIG_LOCK_KERNEL=y
CONFIG_INIT_ENV_ARG_LIMIT=32
CONFIG_LOCALVERSION=""
# CONFIG_LOCALVERSION_AUTO is not set
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
CONFIG_SYSVIPC_SYSCTL=y
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
CONFIG_LOG_BUF_SHIFT=16
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
CONFIG_SYSFS_DEPRECATED_V2=y
# CONFIG_RELAY is not set
# CONFIG_NAMESPACES is not set
# CONFIG_BLK_DEV_INITRD is not set
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
CONFIG_EMBEDDED=y
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
# CONFIG_COMPAT_BRK is not set
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_ANON_INODES=y
CONFIG_EPOLL=y
CONFIG_SIGNALFD=y
CONFIG_TIMERFD=y
CONFIG_EVENTFD=y
CONFIG_SHMEM=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_SLAB=y
# CONFIG_SLUB is not set
# CONFIG_SLOB is not set
# CONFIG_PROFILING is not set
# CONFIG_MARKERS is not set
CONFIG_HAVE_OPROFILE=y
# CONFIG_KPROBES is not set
CONFIG_HAVE_KPROBES=y
CONFIG_HAVE_KRETPROBES=y
CONFIG_PROC_PAGE_MONITOR=y
CONFIG_SLABINFO=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
CONFIG_MODVERSIONS=y
CONFIG_MODULE_SRCVERSION_ALL=y
CONFIG_KMOD=y
CONFIG_STOP_MACHINE=y
CONFIG_BLOCK=y
# CONFIG_LBD is not set
# CONFIG_BLK_DEV_IO_TRACE is not set
# CONFIG_LSF is not set
CONFIG_BLK_DEV_BSG=y
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not set
CONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not set
CONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="cfq"
CONFIG_PREEMPT_NOTIFIERS=y
CONFIG_CLASSIC_RCU=y
#
# Processor type and features
#
CONFIG_TICK_ONESHOT=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_GENERIC_CLOCKEVENTS_BUILD=y
CONFIG_SMP=y
CONFIG_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 set
CONFIG_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 set
CONFIG_MCORE2=y
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_X86_XADD=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_P6_NOP=y
CONFIG_X86_TSC=y
CONFIG_X86_MINIMUM_CPU_FAMILY=6
CONFIG_X86_DEBUGCTLMSR=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
# CONFIG_IOMMU_HELPER is not set
CONFIG_NR_CPUS=2
# CONFIG_SCHED_SMT is not set
CONFIG_SCHED_MC=y
# CONFIG_PREEMPT_NONE is not set
# CONFIG_PREEMPT_VOLUNTARY is not set
CONFIG_PREEMPT=y
# CONFIG_PREEMPT_RCU is not set
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not set
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
CONFIG_I8K=m
CONFIG_X86_REBOOTFIXUPS=y
CONFIG_MICROCODE=m
CONFIG_MICROCODE_OLD_INTERFACE=y
CONFIG_X86_MSR=m
CONFIG_X86_CPUID=m
# CONFIG_NOHIGHMEM is not set
CONFIG_HIGHMEM4G=y
# CONFIG_HIGHMEM64G is not set
CONFIG_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 set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_HIGHMEM=y
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
CONFIG_ZONE_DMA_FLAG=1
CONFIG_BOUNCE=y
CONFIG_VIRT_TO_BUS=y
# CONFIG_HIGHPTE is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
CONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
CONFIG_SCHED_HRTICK=y
# CONFIG_KEXEC is not set
# CONFIG_CRASH_DUMP is not set
CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_HOTPLUG_CPU=y
# CONFIG_COMPAT_VDSO is not set
CONFIG_ARCH_ENABLE_MEMORY_HOTPLUG=y
#
# Power management options
#
CONFIG_PM=y
CONFIG_PM_LEGACY=y
# CONFIG_PM_DEBUG is not set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATION=y
CONFIG_PM_STD_PARTITION="/dev/sda3"
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_PROCFS=y
CONFIG_ACPI_PROCFS_POWER=y
CONFIG_ACPI_SYSFS_POWER=y
CONFIG_ACPI_PROC_EVENT=y
CONFIG_ACPI_AC=m
CONFIG_ACPI_BATTERY=m
CONFIG_ACPI_BUTTON=m
CONFIG_ACPI_FAN=m
CONFIG_ACPI_DOCK=y
# CONFIG_ACPI_BAY is not set
CONFIG_ACPI_PROCESSOR=m
CONFIG_ACPI_HOTPLUG_CPU=y
CONFIG_ACPI_THERMAL=m
CONFIG_ACPI_WMI=m
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
CONFIG_ACPI_CONTAINER=y
# CONFIG_ACPI_SBS is not set
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_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 set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCI_DOMAINS=y
CONFIG_PCIEPORTBUS=y
CONFIG_HOTPLUG_PCI_PCIE=m
CONFIG_PCIEAER=y
CONFIG_ARCH_SUPPORTS_MSI=y
# CONFIG_PCI_MSI is not set
CONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not set
# CONFIG_HT_IRQ is not set
CONFIG_ISA_DMA_API=y
# CONFIG_ISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
# CONFIG_PCCARD is not set
CONFIG_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=y
CONFIG_BINFMT_AOUT=m
CONFIG_BINFMT_MISC=m
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
CONFIG_PACKET=m
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=m
CONFIG_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 set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
CONFIG_IP_ADVANCED_ROUTER=y
CONFIG_ASK_IP_FIB_HASH=y
# CONFIG_IP_FIB_TRIE is not set
CONFIG_IP_FIB_HASH=y
CONFIG_IP_MULTIPLE_TABLES=y
CONFIG_IP_ROUTE_MULTIPATH=y
CONFIG_IP_ROUTE_VERBOSE=y
# CONFIG_IP_PNP is not set
CONFIG_NET_IPIP=m
CONFIG_NET_IPGRE=m
CONFIG_NET_IPGRE_BROADCAST=y
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
CONFIG_INET_AH=m
CONFIG_INET_ESP=m
CONFIG_INET_IPCOMP=m
CONFIG_INET_XFRM_TUNNEL=m
CONFIG_INET_TUNNEL=m
CONFIG_INET_XFRM_MODE_TRANSPORT=m
CONFIG_INET_XFRM_MODE_TUNNEL=m
CONFIG_INET_XFRM_MODE_BEET=m
CONFIG_INET_LRO=y
CONFIG_INET_DIAG=m
CONFIG_INET_TCP_DIAG=m
# CONFIG_TCP_CONG_ADVANCED is not set
CONFIG_TCP_CONG_CUBIC=y
CONFIG_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 set
CONFIG_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 set
CONFIG_SCTP_HMAC_MD5=y
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=m
CONFIG_VLAN_8021Q=m
# CONFIG_DECNET is not set
CONFIG_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 set
CONFIG_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 set
CONFIG_BT=m
CONFIG_BT_L2CAP=m
CONFIG_BT_SCO=m
CONFIG_BT_RFCOMM=m
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=m
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=m
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_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 set
CONFIG_FIB_RULES=y
#
# Wireless
#
CONFIG_CFG80211=m
CONFIG_NL80211=y
CONFIG_WIRELESS_EXT=y
CONFIG_MAC80211=m
#
# Rate control algorithm selection
#
# CONFIG_MAC80211_RC_DEFAULT_PID is not set
# CONFIG_MAC80211_RC_DEFAULT_SIMPLE is not set
CONFIG_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 set
CONFIG_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 set
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
CONFIG_PNPACPI=y
CONFIG_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 set
CONFIG_BLK_DEV_LOOP=m
CONFIG_BLK_DEV_CRYPTOLOOP=m
# CONFIG_BLK_DEV_NBD is not set
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
CONFIG_BLK_DEV_RAM=y
CONFIG_BLK_DEV_RAM_COUNT=4
CONFIG_BLK_DEV_RAM_SIZE=8192
# CONFIG_BLK_DEV_XIP is not set
CONFIG_CDROM_PKTCDVD=m
CONFIG_CDROM_PKTCDVD_BUFFERS=8
# CONFIG_CDROM_PKTCDVD_WCACHE is not set
# CONFIG_ATA_OVER_ETH is not set
CONFIG_VIRTIO_BLK=m
CONFIG_MISC_DEVICES=y
# CONFIG_IBM_ASM is not set
# CONFIG_PHANTOM is not set
CONFIG_EEPROM_93CX6=m
# CONFIG_SGI_IOC4 is not set
CONFIG_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 set
CONFIG_HAVE_IDE=y
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
CONFIG_SCSI_DMA=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_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 set
CONFIG_BLK_DEV_SR=m
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_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=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
CONFIG_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 set
CONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not set
CONFIG_ATA_ACPI=y
# CONFIG_SATA_AHCI is not set
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
CONFIG_SATA_MV=m
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
CONFIG_SATA_QSTOR=m
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
CONFIG_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 set
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=m
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=m
CONFIG_DM_SNAPSHOT=m
CONFIG_DM_MIRROR=m
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
# CONFIG_DM_DELAY is not set
CONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_FIREWIRE=m
CONFIG_FIREWIRE_OHCI=m
CONFIG_FIREWIRE_SBP2=m
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not set
# CONFIG_MACINTOSH_DRIVERS is not set
CONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not set
CONFIG_BONDING=m
CONFIG_MACVLAN=m
CONFIG_EQUALIZER=m
CONFIG_TUN=m
# CONFIG_VETH is not set
# CONFIG_NET_SB1000 is not set
# CONFIG_ARCNET is not set
# CONFIG_PHYLIB is not set
CONFIG_NET_ETHERNET=y
CONFIG_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 set
CONFIG_B44=m
CONFIG_B44_PCI_AUTOSELECT=y
CONFIG_B44_PCICORE_AUTOSELECT=y
CONFIG_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 set
CONFIG_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 set
CONFIG_USB_ZD1201=m
CONFIG_USB_NET_RNDIS_WLAN=m
CONFIG_RTL8180=m
CONFIG_RTL8187=m
# CONFIG_ADM8211 is not set
# CONFIG_P54_COMMON is not set
CONFIG_ATH5K=m
# CONFIG_IWL4965 is not set
CONFIG_IWL3945=m
# CONFIG_IWL3945_QOS is not set
CONFIG_IWL3945_SPECTRUM_MEASUREMENT=y
# CONFIG_IWL3945_DEBUG is not set
# CONFIG_HOSTAP is not set
CONFIG_B43=m
CONFIG_B43_PCI_AUTOSELECT=y
CONFIG_B43_PCICORE_AUTOSELECT=y
CONFIG_B43_RFKILL=y
# CONFIG_B43_DEBUG is not set
CONFIG_B43LEGACY=m
CONFIG_B43LEGACY_PCI_AUTOSELECT=y
CONFIG_B43LEGACY_PCICORE_AUTOSELECT=y
CONFIG_B43LEGACY_RFKILL=y
# CONFIG_B43LEGACY_DEBUG is not set
CONFIG_B43LEGACY_DMA=y
CONFIG_B43LEGACY_PIO=y
CONFIG_B43LEGACY_DMA_AND_PIO_MODE=y
# CONFIG_B43LEGACY_DMA_MODE is not set
# CONFIG_B43LEGACY_PIO_MODE is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
# CONFIG_RT2X00 is not set
#
# USB Network Adapters
#
CONFIG_USB_CATC=m
CONFIG_USB_KAWETH=m
CONFIG_USB_PEGASUS=m
CONFIG_USB_RTL8150=m
CONFIG_USB_USBNET=m
CONFIG_USB_NET_AX8817X=m
CONFIG_USB_NET_CDCETHER=m
CONFIG_USB_NET_DM9601=m
CONFIG_USB_NET_GL620A=m
CONFIG_USB_NET_NET1080=m
CONFIG_USB_NET_PLUSB=m
CONFIG_USB_NET_MCS7830=m
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
CONFIG_USB_ALI_M5632=y
CONFIG_USB_AN2720=y
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
CONFIG_USB_EPSON2888=y
CONFIG_USB_KC2190=y
CONFIG_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 set
CONFIG_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 set
CONFIG_INPUT_POLLDEV=m
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=m
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
CONFIG_INPUT_EVDEV=y
CONFIG_INPUT_EVBUG=m
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_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 set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
CONFIG_MOUSE_PS2_ALPS=y
CONFIG_MOUSE_PS2_LOGIPS2PP=y
CONFIG_MOUSE_PS2_SYNAPTICS=y
# CONFIG_MOUSE_PS2_LIFEBOOK is not set
# CONFIG_MOUSE_PS2_TRACKPOINT is not set
# CONFIG_MOUSE_PS2_TOUCHKIT is not set
CONFIG_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 set
CONFIG_INPUT_MISC=y
CONFIG_INPUT_PCSPKR=m
# CONFIG_INPUT_WISTRON_BTNS is not set
# CONFIG_INPUT_ATLAS_BTNS is not set
CONFIG_INPUT_ATI_REMOTE=m
CONFIG_INPUT_ATI_REMOTE2=m
CONFIG_INPUT_KEYSPAN_REMOTE=m
# CONFIG_INPUT_POWERMATE is not set
CONFIG_INPUT_YEALINK=m
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_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 set
CONFIG_FIX_EARLYCON_MEM=y
# CONFIG_SERIAL_8250_PCI is not set
# CONFIG_SERIAL_8250_PNP is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_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 set
CONFIG_UNIX98_PTYS=y
CONFIG_LEGACY_PTYS=y
CONFIG_LEGACY_PTY_COUNT=256
# CONFIG_IPMI_HANDLER is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=m
# CONFIG_HW_RANDOM_AMD is not set
# CONFIG_HW_RANDOM_GEODE is not set
# CONFIG_HW_RANDOM_VIA is not set
CONFIG_NVRAM=m
# CONFIG_RTC is not set
CONFIG_GEN_RTC=y
CONFIG_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 set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
CONFIG_HANGCHECK_TIMER=m
# CONFIG_TCG_TPM is not set
# CONFIG_TELCLOCK is not set
CONFIG_DEVPORT=y
CONFIG_I2C=m
CONFIG_I2C_BOARDINFO=y
CONFIG_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 set
CONFIG_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 set
CONFIG_THERMAL=y
# CONFIG_WATCHDOG is not set
#
# Sonics Silicon Backplane
#
CONFIG_SSB_POSSIBLE=y
CONFIG_SSB=y
CONFIG_SSB_PCIHOST_POSSIBLE=y
CONFIG_SSB_PCIHOST=y
CONFIG_SSB_B43_PCI_BRIDGE=y
CONFIG_SSB_SILENT=y
CONFIG_SSB_DRIVER_PCICORE_POSSIBLE=y
CONFIG_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 set
CONFIG_AGP_ATI=m
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_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 set
CONFIG_DRM=m
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_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 set
CONFIG_FB=y
CONFIG_FIRMWARE_EDID=y
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=y
CONFIG_FB_CFB_COPYAREA=y
CONFIG_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 set
CONFIG_FB_DEFERRED_IO=y
# CONFIG_FB_SVGALIB is not set
# CONFIG_FB_MACMODES is not set
CONFIG_FB_BACKLIGHT=y
CONFIG_FB_MODE_HELPERS=y
CONFIG_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 set
CONFIG_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 set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_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 set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not set
CONFIG_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=y
CONFIG_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=m
CONFIG_SND_TIMER=m
CONFIG_SND_PCM=m
CONFIG_SND_HWDEP=m
CONFIG_SND_RAWMIDI=m
CONFIG_SND_SEQUENCER=m
CONFIG_SND_SEQ_DUMMY=m
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=m
CONFIG_SND_PCM_OSS=m
CONFIG_SND_PCM_OSS_PLUGINS=y
CONFIG_SND_SEQUENCER_OSS=y
# CONFIG_SND_DYNAMIC_MINORS is not set
CONFIG_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 set
CONFIG_SND_HDA_INTEL=m
# CONFIG_SND_HDA_HWDEP is not set
CONFIG_SND_HDA_CODEC_REALTEK=y
CONFIG_SND_HDA_CODEC_ANALOG=y
CONFIG_SND_HDA_CODEC_SIGMATEL=y
CONFIG_SND_HDA_CODEC_VIA=y
CONFIG_SND_HDA_CODEC_ATIHDMI=y
CONFIG_SND_HDA_CODEC_CONEXANT=y
CONFIG_SND_HDA_CODEC_CMEDIA=y
CONFIG_SND_HDA_CODEC_SI3054=y
CONFIG_SND_HDA_GENERIC=y
CONFIG_SND_HDA_POWER_SAVE=y
CONFIG_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 set
CONFIG_SND_INTEL8X0=m
CONFIG_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 set
CONFIG_SND_AC97_POWER_SAVE=y
CONFIG_SND_AC97_POWER_SAVE_DEFAULT=10
#
# USB devices
#
CONFIG_SND_USB_AUDIO=m
CONFIG_SND_USB_USX2Y=m
CONFIG_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 set
CONFIG_AC97_BUS=m
CONFIG_HID_SUPPORT=y
CONFIG_HID=m
# CONFIG_HID_DEBUG is not set
CONFIG_HIDRAW=y
#
# USB Input Devices
#
CONFIG_USB_HID=m
# CONFIG_USB_HIDINPUT_POWERBOOK is not set
# CONFIG_HID_FF is not set
CONFIG_USB_HIDDEV=y
#
# USB HID Boot Protocol drivers
#
# CONFIG_USB_KBD is not set
# CONFIG_USB_MOUSE is not set
CONFIG_USB_SUPPORT=y
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=m
# CONFIG_USB_DEBUG is not set
CONFIG_USB_ANNOUNCE_NEW_DEVICES=y
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
CONFIG_USB_DEVICE_CLASS=y
# CONFIG_USB_DYNAMIC_MINORS is not set
CONFIG_USB_SUSPEND=y
CONFIG_USB_PERSIST=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
CONFIG_USB_EHCI_ROOT_HUB_TT=y
CONFIG_USB_EHCI_TT_NEWSCHED=y
# CONFIG_USB_ISP116X_HCD is not set
CONFIG_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 set
CONFIG_USB_OHCI_LITTLE_ENDIAN=y
CONFIG_USB_UHCI_HCD=m
CONFIG_USB_SL811_HCD=m
# CONFIG_USB_R8A66597_HCD is not set
#
# USB Device Class drivers
#
CONFIG_USB_ACM=m
CONFIG_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=m
CONFIG_USB_MICROTEK=m
CONFIG_USB_MON=y
#
# USB port drivers
#
CONFIG_USB_SERIAL=m
CONFIG_USB_EZUSB=y
CONFIG_USB_SERIAL_GENERIC=y
CONFIG_USB_SERIAL_AIRCABLE=m
CONFIG_USB_SERIAL_AIRPRIME=m
CONFIG_USB_SERIAL_ARK3116=m
CONFIG_USB_SERIAL_BELKIN=m
CONFIG_USB_SERIAL_CH341=m
CONFIG_USB_SERIAL_WHITEHEAT=m
CONFIG_USB_SERIAL_DIGI_ACCELEPORT=m
CONFIG_USB_SERIAL_CP2101=m
CONFIG_USB_SERIAL_CYPRESS_M8=m
CONFIG_USB_SERIAL_EMPEG=m
CONFIG_USB_SERIAL_FTDI_SIO=m
CONFIG_USB_SERIAL_FUNSOFT=m
CONFIG_USB_SERIAL_VISOR=m
CONFIG_USB_SERIAL_IPAQ=m
CONFIG_USB_SERIAL_IR=m
CONFIG_USB_SERIAL_EDGEPORT=m
CONFIG_USB_SERIAL_EDGEPORT_TI=m
CONFIG_USB_SERIAL_GARMIN=m
CONFIG_USB_SERIAL_IPW=m
CONFIG_USB_SERIAL_IUU=m
CONFIG_USB_SERIAL_KEYSPAN_PDA=m
CONFIG_USB_SERIAL_KEYSPAN=m
CONFIG_USB_SERIAL_KEYSPAN_MPR=y
CONFIG_USB_SERIAL_KEYSPAN_USA28=y
CONFIG_USB_SERIAL_KEYSPAN_USA28X=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XA=y
CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y
CONFIG_USB_SERIAL_KEYSPAN_USA19=y
CONFIG_USB_SERIAL_KEYSPAN_USA18X=y
CONFIG_USB_SERIAL_KEYSPAN_USA19W=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
CONFIG_USB_SERIAL_KEYSPAN_USA19QI=y
CONFIG_USB_SERIAL_KEYSPAN_USA49W=y
CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
CONFIG_USB_SERIAL_KLSI=m
CONFIG_USB_SERIAL_KOBIL_SCT=m
CONFIG_USB_SERIAL_MCT_U232=m
CONFIG_USB_SERIAL_MOS7720=m
CONFIG_USB_SERIAL_MOS7840=m
CONFIG_USB_SERIAL_NAVMAN=m
CONFIG_USB_SERIAL_PL2303=m
CONFIG_USB_SERIAL_OTI6858=m
# CONFIG_USB_SERIAL_HP4X is not set
CONFIG_USB_SERIAL_SAFE=m
CONFIG_USB_SERIAL_SAFE_PADDED=y
CONFIG_USB_SERIAL_SIERRAWIRELESS=m
CONFIG_USB_SERIAL_TI=m
CONFIG_USB_SERIAL_CYBERJACK=m
CONFIG_USB_SERIAL_XIRCOM=m
CONFIG_USB_SERIAL_OPTION=m
CONFIG_USB_SERIAL_OMNINET=m
# CONFIG_USB_SERIAL_DEBUG is not set
#
# USB Miscellaneous drivers
#
CONFIG_USB_EMI62=m
CONFIG_USB_EMI26=m
CONFIG_USB_ADUTUX=m
CONFIG_USB_AUERSWALD=m
CONFIG_USB_RIO500=m
CONFIG_USB_LEGOTOWER=m
CONFIG_USB_LCD=m
# CONFIG_USB_BERRY_CHARGE is not set
CONFIG_USB_LED=m
CONFIG_USB_CYPRESS_CY7C63=m
CONFIG_USB_CYTHERM=m
CONFIG_USB_PHIDGET=m
# CONFIG_USB_PHIDGETKIT is not set
# CONFIG_USB_PHIDGETMOTORCONTROL is not set
# CONFIG_USB_PHIDGETSERVO is not set
CONFIG_USB_IDMOUSE=m
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
CONFIG_USB_SISUSBVGA=m
# CONFIG_USB_SISUSBVGA_CON is not set
CONFIG_USB_LD=m
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_IOWARRIOR is not set
CONFIG_USB_TEST=m
# CONFIG_USB_GADGET is not set
CONFIG_MMC=m
# CONFIG_MMC_DEBUG is not set
# CONFIG_MMC_UNSAFE_RESUME is not set
#
# MMC/SD Card Drivers
#
CONFIG_MMC_BLOCK=m
CONFIG_MMC_BLOCK_BOUNCE=y
CONFIG_SDIO_UART=m
#
# MMC/SD Host Controller Drivers
#
CONFIG_MMC_SDHCI=m
CONFIG_MMC_RICOH_MMC=m
CONFIG_MMC_WBSD=m
CONFIG_MMC_TIFM_SD=m
# CONFIG_MEMSTICK is not set
# CONFIG_NEW_LEDS is not set
# CONFIG_INFINIBAND is not set
# CONFIG_EDAC is not set
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_DMADEVICES=y
#
# DMA Devices
#
CONFIG_INTEL_IOATDMA=m
CONFIG_DMA_ENGINE=y
#
# DMA Clients
#
CONFIG_NET_DMA=y
CONFIG_DCA=m
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#
CONFIG_EDD=m
CONFIG_DELL_RBU=m
CONFIG_DCDBAS=m
CONFIG_DMIID=y
#
# File systems
#
CONFIG_EXT2_FS=m
# CONFIG_EXT2_FS_XATTR is not set
CONFIG_EXT2_FS_XIP=y
CONFIG_FS_XIP=y
CONFIG_EXT3_FS=y
# CONFIG_EXT3_FS_XATTR is not set
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
# CONFIG_REISERFS_FS is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_DNOTIFY=y
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
# CONFIG_AUTOFS_FS is not set
# CONFIG_AUTOFS4_FS is not set
CONFIG_FUSE_FS=m
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=m
CONFIG_JOLIET=y
CONFIG_ZISOFS=y
CONFIG_UDF_FS=m
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=m
CONFIG_MSDOS_FS=m
CONFIG_VFAT_FS=m
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=m
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_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 set
CONFIG_NETWORK_FILESYSTEMS=y
CONFIG_NFS_FS=m
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
CONFIG_NFS_V4=y
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=m
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
CONFIG_NFSD_V4=y
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=m
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=m
CONFIG_NFS_ACL_SUPPORT=m
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=m
CONFIG_SUNRPC_GSS=m
CONFIG_SUNRPC_BIND34=y
CONFIG_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 set
CONFIG_MAC_PARTITION=y
CONFIG_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 set
CONFIG_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 set
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="cp437"
CONFIG_NLS_CODEPAGE_437=m
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_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 set
CONFIG_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 set
CONFIG_NLS_ASCII=m
CONFIG_NLS_ISO8859_1=m
CONFIG_NLS_ISO8859_2=m
CONFIG_NLS_ISO8859_3=m
CONFIG_NLS_ISO8859_4=m
CONFIG_NLS_ISO8859_5=m
CONFIG_NLS_ISO8859_6=m
CONFIG_NLS_ISO8859_7=m
CONFIG_NLS_ISO8859_9=m
CONFIG_NLS_ISO8859_13=m
CONFIG_NLS_ISO8859_14=m
CONFIG_NLS_ISO8859_15=m
CONFIG_NLS_KOI8_R=m
CONFIG_NLS_KOI8_U=m
CONFIG_NLS_UTF8=m
CONFIG_DLM=m
# CONFIG_DLM_DEBUG is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
# CONFIG_ENABLE_WARN_DEPRECATED is not set
# CONFIG_ENABLE_MUST_CHECK is not set
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
CONFIG_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 set
CONFIG_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 set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
CONFIG_IO_DELAY_TYPE_0X80=0
CONFIG_IO_DELAY_TYPE_0XED=1
CONFIG_IO_DELAY_TYPE_UDELAY=2
CONFIG_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 set
CONFIG_IO_DELAY_NONE=y
CONFIG_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 set
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_AEAD=m
CONFIG_CRYPTO_BLKCIPHER=m
# CONFIG_CRYPTO_SEQIV is not set
CONFIG_CRYPTO_HASH=m
CONFIG_CRYPTO_MANAGER=m
CONFIG_CRYPTO_HMAC=m
CONFIG_CRYPTO_XCBC=m
CONFIG_CRYPTO_NULL=m
CONFIG_CRYPTO_MD4=y
CONFIG_CRYPTO_MD5=m
CONFIG_CRYPTO_SHA1=m
CONFIG_CRYPTO_SHA256=m
CONFIG_CRYPTO_SHA512=m
CONFIG_CRYPTO_WP512=m
CONFIG_CRYPTO_TGR192=m
CONFIG_CRYPTO_GF128MUL=m
CONFIG_CRYPTO_ECB=m
CONFIG_CRYPTO_CBC=m
CONFIG_CRYPTO_PCBC=m
CONFIG_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 set
CONFIG_CRYPTO_CRYPTD=m
CONFIG_CRYPTO_DES=m
CONFIG_CRYPTO_FCRYPT=m
CONFIG_CRYPTO_BLOWFISH=m
CONFIG_CRYPTO_TWOFISH=m
CONFIG_CRYPTO_TWOFISH_COMMON=m
CONFIG_CRYPTO_TWOFISH_586=m
CONFIG_CRYPTO_SERPENT=m
CONFIG_CRYPTO_AES=m
CONFIG_CRYPTO_AES_586=m
CONFIG_CRYPTO_CAST5=m
CONFIG_CRYPTO_CAST6=m
CONFIG_CRYPTO_TEA=m
CONFIG_CRYPTO_ARC4=m
CONFIG_CRYPTO_KHAZAD=m
CONFIG_CRYPTO_ANUBIS=m
# CONFIG_CRYPTO_SEED is not set
# CONFIG_CRYPTO_SALSA20 is not set
# CONFIG_CRYPTO_SALSA20_586 is not set
CONFIG_CRYPTO_DEFLATE=m
CONFIG_CRYPTO_MICHAEL_MIC=m
CONFIG_CRYPTO_CRC32C=m
CONFIG_CRYPTO_CAMELLIA=m
# CONFIG_CRYPTO_TEST is not set
CONFIG_CRYPTO_AUTHENC=m
CONFIG_CRYPTO_LZO=m
# CONFIG_CRYPTO_HW is not set
CONFIG_HAVE_KVM=y
CONFIG_VIRTUALIZATION=y
CONFIG_KVM=m
CONFIG_KVM_INTEL=m
# CONFIG_KVM_AMD is not set
# CONFIG_LGUEST is not set
CONFIG_VIRTIO=m
CONFIG_VIRTIO_RING=m
# CONFIG_VIRTIO_PCI is not set
CONFIG_VIRTIO_BALLOON=m
#
# Library routines
#
CONFIG_BITREVERSE=m
CONFIG_CRC_CCITT=m
CONFIG_CRC16=m
CONFIG_CRC_ITU_T=m
CONFIG_CRC32=m
CONFIG_CRC7=m
CONFIG_LIBCRC32C=m
CONFIG_ZLIB_INFLATE=m
CONFIG_ZLIB_DEFLATE=m
CONFIG_LZO_COMPRESS=m
CONFIG_LZO_DECOMPRESS=m
CONFIG_PLIST=y
CONFIG_HAS_IOMEM=y
CONFIG_HAS_IOPORT=y
CONFIG_HAS_DMA=y
Jiri Kosina wrote:
> On Thu, 27 Mar 2008, Greg KH wrote:
>
>>> 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.
> 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.
..
>>> 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
>
> Hmm, what device is this?
..
Wireless PCIe card on internal slot -- Intel 3945ABG.
Greg KH wrote:
> On Thu, Mar 27, 2008 at 11:29:27AM -0400, Mark Lord wrote:
>> 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:)
>
>> 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.
..
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.
??
Mark Lord wrote:
> Greg KH wrote:
>> On Thu, Mar 27, 2008 at 11:29:27AM -0400, Mark Lord wrote:
>>> 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:)
>>
>>> 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.
> ..
>
> 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.
..
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
=======================
Mark Lord wrote:
> 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.
..
Correction there: 3GB of RAM, not 2.
From: Mark Lord <[email protected]>
Date: Thu, 27 Mar 2008 21:57:55 -0400
> 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.
David Miller wrote:
> From: Mark Lord <[email protected]>
> Date: Thu, 27 Mar 2008 21:57:55 -0400
>
> > 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.
--
------------------------------------------------------------------------
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)
> 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.
David Miller wrote:
> From: [email protected] (Bob Tracy)
> Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)
>
>> 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
Rafael J. Wysocki wrote:
> On Thursday, 27 of March 2008, Mark Lord wrote:
>> 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 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.nousb 2008-03-27 22:43:50.000000000 -0400
+++ dot_config.nothing 2008-03-27 22:47:32.000000000 -0400
@@ -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 set
CONFIG_X86_32=y
@@ -70,7 +70,7 @@
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
-CONFIG_LOG_BUF_SHIFT=16
+CONFIG_LOG_BUF_SHIFT=17
# CONFIG_CGROUPS is not set
# CONFIG_GROUP_SCHED is not set
CONFIG_SYSFS_DEPRECATED=y
@@ -84,7 +84,7 @@
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
-# CONFIG_KALLSYMS_ALL is not set
+CONFIG_KALLSYMS_ALL=y
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
@@ -277,7 +277,10 @@
#
CONFIG_PM=y
CONFIG_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 set
CONFIG_PM_SLEEP_SMP=y
CONFIG_PM_SLEEP=y
CONFIG_SUSPEND=y
@@ -1767,30 +1770,35 @@
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
-# CONFIG_DEBUG_SHIRQ is not set
+CONFIG_DEBUG_SHIRQ=y
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHED_DEBUG is not set
# CONFIG_SCHEDSTATS is not set
CONFIG_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=y
CONFIG_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 set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
On Thu, 2008-03-27 at 20:12 -0700, David Miller wrote:
> From: Mark Lord <[email protected]>
> Date: Thu, 27 Mar 2008 21:57:55 -0400
>
> > 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
David Miller wrote:
> From: Mark Lord <[email protected]>
> Date: Thu, 27 Mar 2008 21:57:55 -0400
>
>> 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
Mark Lord wrote:
>
> 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.
..
> -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.
On Fri, 28 Mar 2008, Mark Lord wrote:
> David Miller wrote:
>> From: [email protected] (Bob Tracy)
>> Date: Thu, 27 Mar 2008 23:42:58 -0500 (CDT)
>>
>>> 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.
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
Mark Lord wrote:
> Mark Lord wrote:
>>
>> 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.
> ..
>> -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.
..
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
On Thursday 27 March 2008, Mark Lord wrote:
> 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
* David Brownell <[email protected]> wrote:
> On Thursday 27 March 2008, Mark Lord wrote:
> > 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
Hi!
>> 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.
> ..
>
> 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
--
(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/
On Friday 28 March 2008, Ingo Molnar wrote:
> > > 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.
Signed-off-by: David Brownell <[email protected]>
---
drivers/char/Kconfig | 8 ++++++++
drivers/rtc/Kconfig | 5 +----
2 files changed, 9 insertions(+), 4 deletions(-)
--- linux-2.6.orig/drivers/char/Kconfig 2008-03-28 02:35:58.000000000 -0700
+++ linux-2.6/drivers/char/Kconfig 2008-03-28 02:39:17.000000000 -0700
@@ -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
--- linux-2.6.orig/drivers/rtc/Kconfig 2008-03-28 02:35:58.000000000 -0700
+++ linux-2.6/drivers/rtc/Kconfig 2008-03-28 02:39:12.000000000 -0700
@@ -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.
* David Brownell <[email protected]> wrote:
> 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!!!!
> - When using generic RTC on x86, enable rtc-cmos by default.
Amen.
> It seems too many people are used to enabling a legacy RTC despite the
> Kconfig help/comments; the gentle approach hasn't worked.
Very-Much-Acked-by: Ingo Molnar <[email protected]>
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
On Fri 2008-03-28 11:20:10, Ingo Molnar wrote:
>
> * David Brownell <[email protected]> wrote:
>
> > 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!!!!
>
> > - When using generic RTC on x86, enable rtc-cmos by default.
>
> Amen.
>
> > It seems too many people are used to enabling a legacy RTC despite the
> > Kconfig help/comments; the gentle approach hasn't worked.
>
> Very-Much-Acked-by: Ingo Molnar <[email protected]>
Acked-by: Pavel Machek <[email protected]>
> 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.
--
(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/
On Fri, 28 Mar 2008 02:49:41 -0700, David Brownell wrote:
> It seems too many people are used to enabling a legacy RTC despite
> the Kconfig help/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.
--
Tilman Schmidt E-Mail: [email protected]
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Unge?ffnet mindestens haltbar bis: (siehe R?ckseite)
David Brownell wrote:
> On Friday 28 March 2008, Ingo Molnar wrote:
>>>> 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.
>
> Signed-off-by: David Brownell <[email protected]>
> ---
> drivers/char/Kconfig | 8 ++++++++
> drivers/rtc/Kconfig | 5 +----
> 2 files changed, 9 insertions(+), 4 deletions(-)
>
> --- linux-2.6.orig/drivers/char/Kconfig 2008-03-28 02:35:58.000000000 -0700
> +++ linux-2.6/drivers/char/Kconfig 2008-03-28 02:39:17.000000000 -0700
> @@ -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
Tilman Schmidt wrote:
> On Fri, 28 Mar 2008 02:49:41 -0700, David Brownell wrote:
>> It seems too many people are used to enabling a legacy RTC despite the
>> Kconfig help/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 ***
..
Exactly the issue. Mod++++++++++++++++++++++
On Thu, 27 Mar 2008, Mark Lord wrote:
> 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.
>
> ??
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
On Friday 2008-03-28 10:49, David Brownell wrote:
> @@ -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.
I do not see why it should default to y, given that udev loads my m
perfectly fine.
Alan Stern wrote:
> On Thu, 27 Mar 2008, Mark Lord wrote:
>
>> 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.
>>
>> ??
>
> 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.
..
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
On Friday 2008-03-28 11:20, Ingo Molnar wrote:
>
> 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 :-/
David Miller wrote:
> 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 :-).
--
------------------------------------------------------------------------
Bob Tracy | "I was a beta tester for dirt. They never did
[email protected] | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
On Fri, Mar 28, 2008 at 03:56:49PM +0100, Jan Engelhardt wrote:
>
> On Friday 2008-03-28 10:49, David Brownell wrote:
>> @@ -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.
>
> 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
--
"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 Seed
On Friday 28 March 2008, Tilman Schmidt wrote:
>
> 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.
> 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 ...
> - 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!
> - 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.
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
[ CC's trimmed a bit ]
On Friday 28 March 2008, Mark Lord wrote:
> > +# 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.
> 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
On Friday 28 March 2008, Jan Engelhardt wrote:
> > 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 :-/
-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
On Fri, Mar 28, 2008 at 01:04:38PM -0700, David Brownell wrote:
> [ CC's trimmed a bit ]
>
> On Friday 28 March 2008, Mark Lord wrote:
> > > +# 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 ?
The only reason against killing it immediately seems to be SND_RTCTIMER.
> "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
>...
> "DS1302" ... M32R-specific, "rtc-ds1302" should replace it
> --> ready to deprecate now?
>...
Kconfig currently offers rtc-ds1302 only for an sh platform...
> - Dave
cu
Adrian
--
"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 Seed
On Friday 28 March 2008, Adrian Bunk wrote:
> > ? "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
In which case, just enable rtc.c ... a "egrep -r 'JS_RTC|js-rtc'"
shows that it looks pretty pointless.
> >...
> > ? "DS1302" ... M32R-specific, "rtc-ds1302" should replace it
> > ??????--> ready to deprecate now?
> >...
>
> Kconfig currently 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
On Fri, Mar 28, 2008 at 02:23:45PM -0700, David Brownell wrote:
> On Friday 28 March 2008, Adrian Bunk wrote:
> > > "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
>
> 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_RTC and you'll get the point.
> - Dave
cu
Adrian
--
"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 Seed
On Friday 28 March 2008, Adrian Bunk wrote:
> > > > ? "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
> >
> > 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_RTC and you'll get the point.
Right: it doesn't mention JS_RTC at all. Whatever is up
with that stuff, it's broken.
On Fri, Mar 28, 2008 at 02:45:07PM -0700, David Brownell wrote:
> On Friday 28 March 2008, Adrian Bunk wrote:
> > > > > "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
> > >
> > > 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_RTC and you'll get the point.
>
> Right: it doesn't mention JS_RTC at 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
--
"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 Seed
On Friday 28 March 2008, Adrian Bunk wrote:
> > > grep for CONFIG_SUN_MOSTEK_RTC and you'll get the point.
> >
> > Right: it doesn't mention JS_RTC at 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.
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
On Fri, Mar 28, 2008 at 03:18:35PM -0700, David Brownell wrote:
> On Friday 28 March 2008, Adrian Bunk wrote:
>
> > > > grep for CONFIG_SUN_MOSTEK_RTC and you'll get the point.
> > >
> > > Right: it doesn't mention JS_RTC at 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.
>
> 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 ...
The Mostek code does not need drivers/char/rtc.c
JS_RTC is only needed for some unusual sparc machines.
> 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...
> - Dave
cu
Adrian
--
"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 Seed
Mark Lord wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>>
>>> 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.
>> ..
>>> -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.
> ..
>
> 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
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 :)
--
Best regards,
Alessandro Zummo,
Tower Technologies - Torino, Italy
http://www.towertech.it
On Fri, 28 Mar 2008 12:22:32 -0700, David Brownell wrote:
> On Friday 28 March 2008, Tilman Schmidt wrote:
>> 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
Pavel Machek wrote:
> Hi!
>
>>> 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.
>> ..
>>
>> 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
Mark Lord wrote:
> Pavel Machek wrote:
>> Hi!
>>
>>>> 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.
>>> ..
>>>
>>> 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:
> >> 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
Oliver Neukum wrote:
> Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
>>>> 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:
> Oliver Neukum wrote:
> > Am Sonntag, 30. März 2008 23:04:25 schrieb Mark Lord:
> >>>> 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.
Yes. What happens if you unload only usbhid at that time?
> 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
Oliver Neukum wrote:
> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>
>> 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?
>> 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?
Mark Lord wrote:
> Oliver Neukum wrote:
>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>>
>>> 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?
..
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:
> Oliver Neukum wrote:
> > Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
> >
> >> 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?
hci_usb doesn't have any autosuspend code.
> >> 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
Oliver Neukum wrote:
> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>> Oliver Neukum wrote:
>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>>>
>>>> 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?
>
> hci_usb doesn't have any autosuspend code.
>
>>>> 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.
..
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.
Mark Lord wrote:
> Oliver Neukum wrote:
>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>>> Oliver Neukum wrote:
>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>>>>
>>>>> 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?
>>
>> hci_usb doesn't have any autosuspend code.
>>
>>>>> 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.
> ..
>
> 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.
> 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.
>
> --
> 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/
Mark Lord wrote:
> Oliver Neukum wrote:
>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>>> Oliver Neukum wrote:
>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
..
>>>>> 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.
> ..
> 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.
> 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.
Mark Lord wrote:
> Mark Lord wrote:
>> Oliver Neukum wrote:
>>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>>>> Oliver Neukum wrote:
>>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
> ..
>>>>>> 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.
>> ..
>> 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.
>
>> 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.
Mark Lord wrote:
> Mark Lord wrote:
>> Mark Lord wrote:
>>> Oliver Neukum wrote:
>>>> Am Montag, 31. März 2008 17:04:46 schrieb Mark Lord:
>>>>> Oliver Neukum wrote:
>>>>>> Am Montag, 31. März 2008 16:39:33 schrieb Mark Lord:
>> ..
>>>>>>> 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.
>>> ..
>>> 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.
>>
>>> 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.
..
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:
> 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.
> 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
Oliver Neukum wrote:
>
> 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