LKML Archive on lore.kernel.org
help / color / mirror / Atom feed
* 2.6.25-rc7: Ugh.
@ 2008-03-27 15:29 Mark Lord
2008-03-27 16:07 ` Greg KH
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-27 15:29 UTC (permalink / raw)
To: Linux Kernel, Greg KH, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 15:29 2.6.25-rc7: Ugh Mark Lord
@ 2008-03-27 16:07 ` Greg KH
2008-03-28 0:32 ` Jiri Kosina
` (2 more replies)
2008-03-27 22:00 ` Rafael J. Wysocki
2008-03-28 2:14 ` Mark Lord
2 siblings, 3 replies; 90+ messages in thread
From: Greg KH @ 2008-03-27 16:07 UTC (permalink / raw)
To: Mark Lord, jkosina; +Cc: Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 15:29 2.6.25-rc7: Ugh Mark Lord
2008-03-27 16:07 ` Greg KH
@ 2008-03-27 22:00 ` Rafael J. Wysocki
2008-03-28 5:22 ` Mark Lord
2008-03-28 2:14 ` Mark Lord
2 siblings, 1 reply; 90+ messages in thread
From: Rafael J. Wysocki @ 2008-03-27 22:00 UTC (permalink / raw)
To: Mark Lord; +Cc: Linux Kernel, Greg KH, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 16:07 ` Greg KH
@ 2008-03-28 0:32 ` Jiri Kosina
2008-03-28 1:57 ` Mark Lord
2008-03-28 1:51 ` Mark Lord
2008-03-28 2:11 ` Mark Lord
2 siblings, 1 reply; 90+ messages in thread
From: Jiri Kosina @ 2008-03-28 0:32 UTC (permalink / raw)
To: Greg KH, Mark Lord; +Cc: Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 16:07 ` Greg KH
2008-03-28 0:32 ` Jiri Kosina
@ 2008-03-28 1:51 ` Mark Lord
2008-03-28 2:11 ` Mark Lord
2 siblings, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 1:51 UTC (permalink / raw)
To: Greg KH; +Cc: jkosina, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
>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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 0:32 ` Jiri Kosina
@ 2008-03-28 1:57 ` Mark Lord
2008-03-28 3:12 ` David Miller
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 1:57 UTC (permalink / raw)
To: Jiri Kosina; +Cc: Greg KH, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 16:07 ` Greg KH
2008-03-28 0:32 ` Jiri Kosina
2008-03-28 1:51 ` Mark Lord
@ 2008-03-28 2:11 ` Mark Lord
2008-03-28 2:13 ` Mark Lord
2008-03-28 14:34 ` Alan Stern
2 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 2:11 UTC (permalink / raw)
To: Greg KH; +Cc: jkosina, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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.
??
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 2:11 ` Mark Lord
@ 2008-03-28 2:13 ` Mark Lord
2008-03-28 14:34 ` Alan Stern
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 2:13 UTC (permalink / raw)
To: Greg KH; +Cc: jkosina, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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
=======================
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 15:29 2.6.25-rc7: Ugh Mark Lord
2008-03-27 16:07 ` Greg KH
2008-03-27 22:00 ` Rafael J. Wysocki
@ 2008-03-28 2:14 ` Mark Lord
2008-03-28 9:24 ` Pavel Machek
2 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 2:14 UTC (permalink / raw)
To: Linux Kernel, Greg KH, Pavel Machek, Andrew Morton
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 1:57 ` Mark Lord
@ 2008-03-28 3:12 ` David Miller
2008-03-28 4:42 ` Bob Tracy
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: David Miller @ 2008-03-28 3:12 UTC (permalink / raw)
To: lkml; +Cc: jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
From: Mark Lord <lkml@rtr.ca>
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 3:12 ` David Miller
@ 2008-03-28 4:42 ` Bob Tracy
2008-03-28 4:56 ` David Miller
2008-03-28 5:36 ` Mike Galbraith
2008-03-28 5:46 ` Mark Lord
2 siblings, 1 reply; 90+ messages in thread
From: Bob Tracy @ 2008-03-28 4:42 UTC (permalink / raw)
To: David Miller; +Cc: lkml, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
David Miller wrote:
> From: Mark Lord <lkml@rtr.ca>
> 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
rct@frus.com | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 4:42 ` Bob Tracy
@ 2008-03-28 4:56 ` David Miller
2008-03-28 5:17 ` Mark Lord
` (2 more replies)
0 siblings, 3 replies; 90+ messages in thread
From: David Miller @ 2008-03-28 4:56 UTC (permalink / raw)
To: rct; +Cc: lkml, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
From: rct@frus.com (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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 4:56 ` David Miller
@ 2008-03-28 5:17 ` Mark Lord
2008-03-28 6:01 ` david
2008-03-28 16:34 ` Bob Tracy
2008-04-05 18:23 ` Bill Davidsen
2 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 5:17 UTC (permalink / raw)
To: David Miller; +Cc: rct, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
David Miller wrote:
> From: rct@frus.com (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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-27 22:00 ` Rafael J. Wysocki
@ 2008-03-28 5:22 ` Mark Lord
0 siblings, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 5:22 UTC (permalink / raw)
To: Rafael J. Wysocki; +Cc: Linux Kernel, Greg KH, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 3:12 ` David Miller
2008-03-28 4:42 ` Bob Tracy
@ 2008-03-28 5:36 ` Mike Galbraith
2008-03-28 5:46 ` Mark Lord
2 siblings, 0 replies; 90+ messages in thread
From: Mike Galbraith @ 2008-03-28 5:36 UTC (permalink / raw)
To: David Miller; +Cc: lkml, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
On Thu, 2008-03-27 at 20:12 -0700, David Miller wrote:
> From: Mark Lord <lkml@rtr.ca>
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 3:12 ` David Miller
2008-03-28 4:42 ` Bob Tracy
2008-03-28 5:36 ` Mike Galbraith
@ 2008-03-28 5:46 ` Mark Lord
2008-03-28 5:52 ` Mark Lord
2 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 5:46 UTC (permalink / raw)
To: David Miller; +Cc: jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
David Miller wrote:
> From: Mark Lord <lkml@rtr.ca>
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 5:46 ` Mark Lord
@ 2008-03-28 5:52 ` Mark Lord
2008-03-28 6:05 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 5:52 UTC (permalink / raw)
To: David Miller; +Cc: jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 5:17 ` Mark Lord
@ 2008-03-28 6:01 ` david
0 siblings, 0 replies; 90+ messages in thread
From: david @ 2008-03-28 6:01 UTC (permalink / raw)
To: Mark Lord
Cc: David Miller, rct, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
On Fri, 28 Mar 2008, Mark Lord wrote:
> David Miller wrote:
>> From: rct@frus.com (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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 5:52 ` Mark Lord
@ 2008-03-28 6:05 ` Mark Lord
2008-03-28 6:58 ` David Brownell
2008-03-29 3:58 ` Mark Lord
0 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 6:05 UTC (permalink / raw)
To: David Miller
Cc: jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 6:05 ` Mark Lord
@ 2008-03-28 6:58 ` David Brownell
2008-03-28 9:16 ` Ingo Molnar
2008-03-29 3:58 ` Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-03-28 6:58 UTC (permalink / raw)
To: Mark Lord
Cc: David Miller, jkosina, gregkh, linux-kernel, linux-usb, pavel,
akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 6:58 ` David Brownell
@ 2008-03-28 9:16 ` Ingo Molnar
2008-03-28 9:49 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Ingo Molnar @ 2008-03-28 9:16 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, David Miller, jkosina, gregkh, linux-kernel,
linux-usb, pavel, akpm, rtc-linux
* David Brownell <david-b@pacbell.net> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 2:14 ` Mark Lord
@ 2008-03-28 9:24 ` Pavel Machek
2008-03-30 21:04 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Pavel Machek @ 2008-03-28 9:24 UTC (permalink / raw)
To: Mark Lord; +Cc: Linux Kernel, Greg KH, Andrew Morton, jikos
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/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 9:16 ` Ingo Molnar
@ 2008-03-28 9:49 ` David Brownell
2008-03-28 10:20 ` Ingo Molnar
` (3 more replies)
0 siblings, 4 replies; 90+ messages in thread
From: David Brownell @ 2008-03-28 9:49 UTC (permalink / raw)
To: Ingo Molnar
Cc: Mark Lord, David Miller, jkosina, gregkh, linux-kernel,
linux-usb, pavel, akpm, rtc-linux
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 <dbrownell@users.sourceforge.net>
---
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 9:49 ` David Brownell
@ 2008-03-28 10:20 ` Ingo Molnar
2008-03-28 11:01 ` Pavel Machek
2008-03-28 15:03 ` Jan Engelhardt
2008-03-28 12:51 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) Tilman Schmidt
` (2 subsequent siblings)
3 siblings, 2 replies; 90+ messages in thread
From: Ingo Molnar @ 2008-03-28 10:20 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, David Miller, jkosina, gregkh, linux-kernel,
linux-usb, pavel, akpm, rtc-linux
* David Brownell <david-b@pacbell.net> 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 <mingo@elte.hu>
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 10:20 ` Ingo Molnar
@ 2008-03-28 11:01 ` Pavel Machek
2008-03-28 15:03 ` Jan Engelhardt
1 sibling, 0 replies; 90+ messages in thread
From: Pavel Machek @ 2008-03-28 11:01 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Brownell, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, akpm, rtc-linux
On Fri 2008-03-28 11:20:10, Ingo Molnar wrote:
>
> * David Brownell <david-b@pacbell.net> 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 <mingo@elte.hu>
Acked-by: Pavel Machek <pavel@suse.cz>
> 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/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 9:49 ` David Brownell
2008-03-28 10:20 ` Ingo Molnar
@ 2008-03-28 12:51 ` Tilman Schmidt
2008-03-28 13:49 ` Kconfig RTC selection Mark Lord
2008-03-28 19:22 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
2008-03-28 13:47 ` 2.6.25-rc7: Ugh Mark Lord
2008-03-28 14:56 ` 2.6.25-rc7: Ugh Jan Engelhardt
3 siblings, 2 replies; 90+ messages in thread
From: Tilman Schmidt @ 2008-03-28 12:51 UTC (permalink / raw)
To: David Brownell
Cc: Ingo Molnar, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 1315 bytes --]
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: tilman@imap.cc
Bonn, Germany
Diese Nachricht besteht zu 100% aus wiederverwerteten Bits.
Ungeöffnet mindestens haltbar bis: (siehe Rückseite)
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 250 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 9:49 ` David Brownell
2008-03-28 10:20 ` Ingo Molnar
2008-03-28 12:51 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) Tilman Schmidt
@ 2008-03-28 13:47 ` Mark Lord
2008-03-28 20:04 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
2008-03-28 14:56 ` 2.6.25-rc7: Ugh Jan Engelhardt
3 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-28 13:47 UTC (permalink / raw)
To: David Brownell
Cc: Ingo Molnar, David Miller, jkosina, gregkh, linux-kernel,
linux-usb, pavel, akpm, rtc-linux
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 <dbrownell@users.sourceforge.net>
> ---
> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection
2008-03-28 12:51 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) Tilman Schmidt
@ 2008-03-28 13:49 ` Mark Lord
2008-03-28 19:22 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 13:49 UTC (permalink / raw)
To: Tilman Schmidt
Cc: David Brownell, Ingo Molnar, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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++++++++++++++++++++++
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 2:11 ` Mark Lord
2008-03-28 2:13 ` Mark Lord
@ 2008-03-28 14:34 ` Alan Stern
2008-03-28 14:57 ` Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: Alan Stern @ 2008-03-28 14:34 UTC (permalink / raw)
To: Mark Lord
Cc: Greg KH, jkosina, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 9:49 ` David Brownell
` (2 preceding siblings ...)
2008-03-28 13:47 ` 2.6.25-rc7: Ugh Mark Lord
@ 2008-03-28 14:56 ` Jan Engelhardt
2008-03-28 17:47 ` Adrian Bunk
3 siblings, 1 reply; 90+ messages in thread
From: Jan Engelhardt @ 2008-03-28 14:56 UTC (permalink / raw)
To: David Brownell
Cc: Ingo Molnar, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 14:34 ` Alan Stern
@ 2008-03-28 14:57 ` Mark Lord
0 siblings, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-28 14:57 UTC (permalink / raw)
To: Alan Stern
Cc: Greg KH, jkosina, Linux Kernel, linux-usb, Pavel Machek, Andrew Morton
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 10:20 ` Ingo Molnar
2008-03-28 11:01 ` Pavel Machek
@ 2008-03-28 15:03 ` Jan Engelhardt
2008-03-28 20:14 ` David Brownell
1 sibling, 1 reply; 90+ messages in thread
From: Jan Engelhardt @ 2008-03-28 15:03 UTC (permalink / raw)
To: Ingo Molnar
Cc: David Brownell, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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 :-/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 4:56 ` David Miller
2008-03-28 5:17 ` Mark Lord
@ 2008-03-28 16:34 ` Bob Tracy
2008-04-05 18:23 ` Bill Davidsen
2 siblings, 0 replies; 90+ messages in thread
From: Bob Tracy @ 2008-03-28 16:34 UTC (permalink / raw)
To: David Miller
Cc: rct, lkml, jkosina, gregkh, linux-kernel, linux-usb, pavel, akpm
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
rct@frus.com | get all the bugs out." - Steve McGrew on /.
------------------------------------------------------------------------
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 14:56 ` 2.6.25-rc7: Ugh Jan Engelhardt
@ 2008-03-28 17:47 ` Adrian Bunk
0 siblings, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2008-03-28 17:47 UTC (permalink / raw)
To: Jan Engelhardt
Cc: David Brownell, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 12:51 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) Tilman Schmidt
2008-03-28 13:49 ` Kconfig RTC selection Mark Lord
@ 2008-03-28 19:22 ` David Brownell
2008-03-29 12:55 ` Kconfig RTC selection Tilman Schmidt
1 sibling, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-03-28 19:22 UTC (permalink / raw)
To: Tilman Schmidt
Cc: Ingo Molnar, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 13:47 ` 2.6.25-rc7: Ugh Mark Lord
@ 2008-03-28 20:04 ` David Brownell
2008-03-28 21:06 ` Adrian Bunk
0 siblings, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-03-28 20:04 UTC (permalink / raw)
To: Mark Lord; +Cc: Ingo Molnar, linux-kernel, akpm, rtc-linux, David Miller
[ 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 15:03 ` Jan Engelhardt
@ 2008-03-28 20:14 ` David Brownell
0 siblings, 0 replies; 90+ messages in thread
From: David Brownell @ 2008-03-28 20:14 UTC (permalink / raw)
To: Jan Engelhardt
Cc: Ingo Molnar, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 20:04 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
@ 2008-03-28 21:06 ` Adrian Bunk
2008-03-28 21:23 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Adrian Bunk @ 2008-03-28 21:06 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, Ingo Molnar, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 21:06 ` Adrian Bunk
@ 2008-03-28 21:23 ` David Brownell
2008-03-28 21:33 ` Adrian Bunk
0 siblings, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-03-28 21:23 UTC (permalink / raw)
To: Adrian Bunk
Cc: Mark Lord, Ingo Molnar, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 21:23 ` David Brownell
@ 2008-03-28 21:33 ` Adrian Bunk
2008-03-28 21:45 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Adrian Bunk @ 2008-03-28 21:33 UTC (permalink / raw)
To: David Brownell; +Cc: Mark Lord, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 21:33 ` Adrian Bunk
@ 2008-03-28 21:45 ` David Brownell
2008-03-28 21:59 ` Adrian Bunk
0 siblings, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-03-28 21:45 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Mark Lord, linux-kernel, akpm, rtc-linux, David Miller
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 21:45 ` David Brownell
@ 2008-03-28 21:59 ` Adrian Bunk
2008-03-28 22:18 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Adrian Bunk @ 2008-03-28 21:59 UTC (permalink / raw)
To: David Brownell; +Cc: Mark Lord, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 21:59 ` Adrian Bunk
@ 2008-03-28 22:18 ` David Brownell
2008-03-28 22:36 ` Adrian Bunk
2008-03-29 11:40 ` [rtc-linux] " Alessandro Zummo
0 siblings, 2 replies; 90+ messages in thread
From: David Brownell @ 2008-03-28 22:18 UTC (permalink / raw)
To: Adrian Bunk; +Cc: Mark Lord, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 22:18 ` David Brownell
@ 2008-03-28 22:36 ` Adrian Bunk
2008-03-29 11:40 ` [rtc-linux] " Alessandro Zummo
1 sibling, 0 replies; 90+ messages in thread
From: Adrian Bunk @ 2008-03-28 22:36 UTC (permalink / raw)
To: David Brownell; +Cc: Mark Lord, linux-kernel, akpm, rtc-linux, David Miller
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 6:05 ` Mark Lord
2008-03-28 6:58 ` David Brownell
@ 2008-03-29 3:58 ` Mark Lord
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-29 3:58 UTC (permalink / raw)
To: linux-kernel
Cc: David Miller, jkosina, gregkh, linux-usb, pavel, akpm, rtc-linux
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [rtc-linux] Re: Kconfig RTC selection (was: 2.6.25-rc7: Ugh.)
2008-03-28 22:18 ` David Brownell
2008-03-28 22:36 ` Adrian Bunk
@ 2008-03-29 11:40 ` Alessandro Zummo
1 sibling, 0 replies; 90+ messages in thread
From: Alessandro Zummo @ 2008-03-29 11:40 UTC (permalink / raw)
To: rtc-linux
Cc: david-b, Adrian Bunk, Mark Lord, linux-kernel, akpm, David Miller
On Fri, 28 Mar 2008 15:18:35 -0700
David Brownell <david-b@pacbell.net> 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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: Kconfig RTC selection
2008-03-28 19:22 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
@ 2008-03-29 12:55 ` Tilman Schmidt
0 siblings, 0 replies; 90+ messages in thread
From: Tilman Schmidt @ 2008-03-29 12:55 UTC (permalink / raw)
To: David Brownell
Cc: Ingo Molnar, Mark Lord, David Miller, jkosina, gregkh,
linux-kernel, linux-usb, pavel, akpm, rtc-linux
[-- Attachment #1: Type: text/plain, Size: 716 bytes --]
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
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 254 bytes --]
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 9:24 ` Pavel Machek
@ 2008-03-30 21:04 ` Mark Lord
2008-03-30 21:09 ` Mark Lord
2008-03-31 11:55 ` Oliver Neukum
0 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-30 21:04 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-30 21:04 ` Mark Lord
@ 2008-03-30 21:09 ` Mark Lord
2008-03-31 11:55 ` Oliver Neukum
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-30 21:09 UTC (permalink / raw)
To: Pavel Machek; +Cc: Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-30 21:04 ` Mark Lord
2008-03-30 21:09 ` Mark Lord
@ 2008-03-31 11:55 ` Oliver Neukum
2008-03-31 14:39 ` Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: Oliver Neukum @ 2008-03-31 11:55 UTC (permalink / raw)
To: Mark Lord; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 11:55 ` Oliver Neukum
@ 2008-03-31 14:39 ` Mark Lord
2008-03-31 15:04 ` Oliver Neukum
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-31 14:39 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 14:39 ` Mark Lord
@ 2008-03-31 15:04 ` Oliver Neukum
2008-03-31 15:04 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Oliver Neukum @ 2008-03-31 15:04 UTC (permalink / raw)
To: Mark Lord; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 15:04 ` Oliver Neukum
@ 2008-03-31 15:04 ` Mark Lord
2008-03-31 15:14 ` Mark Lord
2008-03-31 16:37 ` Oliver Neukum
0 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-31 15:04 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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?
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 15:04 ` Mark Lord
@ 2008-03-31 15:14 ` Mark Lord
2008-03-31 16:37 ` Oliver Neukum
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-31 15:14 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 15:04 ` Mark Lord
2008-03-31 15:14 ` Mark Lord
@ 2008-03-31 16:37 ` Oliver Neukum
2008-03-31 17:03 ` Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: Oliver Neukum @ 2008-03-31 16:37 UTC (permalink / raw)
To: Mark Lord; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 16:37 ` Oliver Neukum
@ 2008-03-31 17:03 ` Mark Lord
2008-03-31 17:06 ` Mark Lord
2008-03-31 17:15 ` Mark Lord
0 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-31 17:03 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 17:03 ` Mark Lord
@ 2008-03-31 17:06 ` Mark Lord
2008-03-31 17:15 ` Mark Lord
1 sibling, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-03-31 17:06 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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 majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 17:03 ` Mark Lord
2008-03-31 17:06 ` Mark Lord
@ 2008-03-31 17:15 ` Mark Lord
2008-03-31 17:21 ` Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-31 17:15 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 17:15 ` Mark Lord
@ 2008-03-31 17:21 ` Mark Lord
2008-03-31 17:30 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-31 17:21 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 17:21 ` Mark Lord
@ 2008-03-31 17:30 ` Mark Lord
2008-03-31 18:05 ` Oliver Neukum
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-31 17:30 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 17:30 ` Mark Lord
@ 2008-03-31 18:05 ` Oliver Neukum
2008-03-31 19:21 ` Mark Lord
2008-04-01 9:59 ` 2.6.25-rc7: Ugh Pavel Machek
0 siblings, 2 replies; 90+ messages in thread
From: Oliver Neukum @ 2008-03-31 18:05 UTC (permalink / raw)
To: Mark Lord; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 18:05 ` Oliver Neukum
@ 2008-03-31 19:21 ` Mark Lord
2008-04-02 8:04 ` Oliver Neukum
2008-04-01 9:59 ` 2.6.25-rc7: Ugh Pavel Machek
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-03-31 19:21 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
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
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 18:05 ` Oliver Neukum
2008-03-31 19:21 ` Mark Lord
@ 2008-04-01 9:59 ` Pavel Machek
1 sibling, 0 replies; 90+ messages in thread
From: Pavel Machek @ 2008-04-01 9:59 UTC (permalink / raw)
To: Oliver Neukum; +Cc: Mark Lord, Linux Kernel, Greg KH, Andrew Morton, jikos
Hi!
> > But suspend *with* any USB device plugged-in, and it *always* fails resume,
> > even when the USB device is unplugged before hitting the resume button.
> >
> > Conclusion: the bug is in the usb SUSPEND code, not the RESUME code.
>
> I would arrive at the opposite conclusion. Independent from that, loss of
> power is not really supported by USB during STR. Obviously it should not
> hang, but all devices will be disconnected and reconnected.
All devices disconnected / reconnected is expected, but it has to
work. Machines like thinkpad x60 kill USB power during s2ram.
Pavel
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-31 19:21 ` Mark Lord
@ 2008-04-02 8:04 ` Oliver Neukum
2008-04-02 14:38 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Oliver Neukum @ 2008-04-02 8:04 UTC (permalink / raw)
To: Mark Lord; +Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos
Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
> 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.
Very well.
Mark, can you get a sysrq-t trace of your whole system when USB goes
dead? And please enable CONFIG_USB_DEBUG. We need to do whether
khubd and ksuspend_usbd are in state D.
Regards
Oliver
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 8:04 ` Oliver Neukum
@ 2008-04-02 14:38 ` Mark Lord
2008-04-02 14:38 ` Mark Lord
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 14:38 UTC (permalink / raw)
To: Oliver Neukum
Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos, Alan Stern
(CCing Alan Stern on this sub-thread)
Oliver Neukum wrote:
> Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
>> 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.
>
> Very well.
>
> Mark, can you get a sysrq-t trace of your whole system when USB goes
> dead? And please enable CONFIG_USB_DEBUG. We need to do whether
> khubd and ksuspend_usbd are in state D.
..
Both of those things were already done, and results from the last time
are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 14:38 ` Mark Lord
@ 2008-04-02 14:38 ` Mark Lord
2008-04-02 15:05 ` 2.6.25-rc7/rc8 USB dead on resume Mark Lord
2008-04-02 15:08 ` 2.6.25-rc7: Ugh Alan Stern
0 siblings, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-04-02 14:38 UTC (permalink / raw)
To: Oliver Neukum
Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos,
Alan Stern, linux-usb
(CCing linux-usb again)
(CCing Alan Stern on this sub-thread)
Oliver Neukum wrote:
> Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
>> 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.
>
> Very well.
>
> Mark, can you get a sysrq-t trace of your whole system when USB goes
> dead? And please enable CONFIG_USB_DEBUG. We need to do whether
> khubd and ksuspend_usbd are in state D.
..
Both of those things were already done, and results from the last time
are attached to the bugzilla report: http://bugzilla.kernel.org/show_bug.cgi?id=10345
I'll be installing -rc8 today, and see what happens there.
Cheers
^ permalink raw reply [flat|nested] 90+ messages in thread
* 2.6.25-rc7/rc8 USB dead on resume
2008-04-02 14:38 ` Mark Lord
@ 2008-04-02 15:05 ` Mark Lord
2008-04-02 15:21 ` Oliver Neukum
2008-04-02 15:08 ` 2.6.25-rc7: Ugh Alan Stern
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 15:05 UTC (permalink / raw)
To: Oliver Neukum
Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos,
Alan Stern, linux-usb
Mark Lord wrote:
> (CCing linux-usb again)
> (CCing Alan Stern on this sub-thread)
>
> Oliver Neukum wrote:
>> Am Montag, 31. März 2008 21:21:45 schrieb Mark Lord:
>>> 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.
>>
>> Very well.
>>
>> Mark, can you get a sysrq-t trace of your whole system when USB goes
>> dead? And please enable CONFIG_USB_DEBUG. We need to do whether
>> khubd and ksuspend_usbd are in state D.
> ..
>
> Both of those things were already done, and results from the last time
> are attached to the bugzilla report:
> http://bugzilla.kernel.org/show_bug.cgi?id=10345
>
> I'll be installing -rc8 today, and see what happens there.
..
No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config
as attachements to the bugzilla entry:
http://bugzilla.kernel.org/show_bug.cgi?id=10345
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 14:38 ` Mark Lord
2008-04-02 15:05 ` 2.6.25-rc7/rc8 USB dead on resume Mark Lord
@ 2008-04-02 15:08 ` Alan Stern
2008-04-02 15:44 ` 2.6.25-rc7: Ugh. ---> PATCH Mark Lord
2008-04-02 16:04 ` 2.6.25-rc7: Ugh David Brownell
1 sibling, 2 replies; 90+ messages in thread
From: Alan Stern @ 2008-04-02 15:08 UTC (permalink / raw)
To: Mark Lord
Cc: Oliver Neukum, Pavel Machek, Linux Kernel, Greg KH,
Andrew Morton, jikos, linux-usb
On Wed, 2 Apr 2008, Mark Lord wrote:
> I'll be installing -rc8 today, and see what happens there.
Have you tried testing with all the USB drivers present except
ehci-hcd? So far all the indicators are that it is the source of the
problem.
Also, check out the thread on LKML started by Tino Keitel. He had
similar problems and found that reverting commit
e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7/rc8 USB dead on resume
2008-04-02 15:05 ` 2.6.25-rc7/rc8 USB dead on resume Mark Lord
@ 2008-04-02 15:21 ` Oliver Neukum
0 siblings, 0 replies; 90+ messages in thread
From: Oliver Neukum @ 2008-04-02 15:21 UTC (permalink / raw)
To: Mark Lord
Cc: Pavel Machek, Linux Kernel, Greg KH, Andrew Morton, jikos,
Alan Stern, linux-usb
Am Mittwoch, 2. April 2008 17:05:21 schrieb Mark Lord:
> Mark Lord wrote:
> No change in -rc8. I've uploaded new syslog (with alt-sysrq-T) and .config
> as attachements to the bugzilla entry:
>
> http://bugzilla.kernel.org/show_bug.cgi?id=10345
>
>
Same analysis. ehci_endpoint_disable() is spinning and ksuspend_usb
is waiting for it.
Regards
Oliver
PS: Sorry for not looking at the full bugzilla entry
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh. ---> PATCH
2008-04-02 15:08 ` 2.6.25-rc7: Ugh Alan Stern
@ 2008-04-02 15:44 ` Mark Lord
2008-04-02 15:47 ` Mark Lord
2008-04-02 20:09 ` Alan Stern
2008-04-02 16:04 ` 2.6.25-rc7: Ugh David Brownell
1 sibling, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-04-02 15:44 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Pavel Machek, Linux Kernel, Greg KH,
Andrew Morton, jikos, linux-usb
This patch seems to fix it.
Could you guys look this over some more,
as I really am not familiar with the USB code.
* * * *
When comparing 2.6.24 against 2.6.25, this line of code
stood out as not looking entirely correct, given the new
uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths
on my machine here. More testing is needed to be sure.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- linux-2.6.25-rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
+++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
@@ -815,7 +815,7 @@
end_unlink_async(ehci);
/* if it's not linked then there's nothing to do */
- if (qh->qh_state != QH_STATE_LINKED)
+ if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
;
/* defer till later if busy */
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh. ---> PATCH
2008-04-02 15:44 ` 2.6.25-rc7: Ugh. ---> PATCH Mark Lord
@ 2008-04-02 15:47 ` Mark Lord
2008-04-02 15:49 ` Mark Lord
2008-04-02 20:09 ` Alan Stern
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 15:47 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Pavel Machek, Linux Kernel, Greg KH,
Andrew Morton, jikos, linux-usb
Mark Lord wrote:
> This patch seems to fix it.
> Could you guys look this over some more,
> as I really am not familiar with the USB code.
Here it is again, with more lines of context, for easier review:
* * *
When comparing 2.6.24 against 2.6.25, this line of code
stood out as not looking entirely correct, given the new
uses of QH_STATE_UNLINK_WAIT in 2.6.25.
Applying this patch seems to fix the USB suspend/resume deaths
on my machine here. More testing is needed to be sure.
Signed-off-by: Mark Lord <mlord@pobox.com>
---
Regenerated with more context in diff, for easier review.
--- linux/drivers/usb/host/ehci-hcd.c.orig 2008-03-11 11:18:40.000000000 -0400
+++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
@@ -801,35 +801,35 @@
return intr_submit(ehci, urb, &qtd_list, mem_flags);
case PIPE_ISOCHRONOUS:
if (urb->dev->speed == USB_SPEED_HIGH)
return itd_submit (ehci, urb, mem_flags);
else
return sitd_submit (ehci, urb, mem_flags);
}
}
static void unlink_async (struct ehci_hcd *ehci, struct ehci_qh *qh)
{
/* failfast */
if (!HC_IS_RUNNING(ehci_to_hcd(ehci)->state) && ehci->reclaim)
end_unlink_async(ehci);
/* if it's not linked then there's nothing to do */
- if (qh->qh_state != QH_STATE_LINKED)
+ if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
;
/* defer till later if busy */
else if (ehci->reclaim) {
struct ehci_qh *last;
for (last = ehci->reclaim;
last->reclaim;
last = last->reclaim)
continue;
qh->qh_state = QH_STATE_UNLINK_WAIT;
last->reclaim = qh;
/* start IAA cycle */
} else
start_unlink_async (ehci, qh);
}
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh. ---> PATCH
2008-04-02 15:47 ` Mark Lord
@ 2008-04-02 15:49 ` Mark Lord
0 siblings, 0 replies; 90+ messages in thread
From: Mark Lord @ 2008-04-02 15:49 UTC (permalink / raw)
To: Alan Stern
Cc: Oliver Neukum, Pavel Machek, Linux Kernel, Greg KH,
Andrew Morton, jikos, linux-usb
Mark Lord wrote:
> Mark Lord wrote:
>> This patch seems to fix it.
>> Could you guys look this over some more,
>> as I really am not familiar with the USB code.
>
> Here it is again, with more lines of context, for easier review:
..
Nope. Nevermind.
Just got lucky once, without the resistor installed on USB power.
The patch doesn't fix it. But that code still looks strange to me.
Cheers
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 15:08 ` 2.6.25-rc7: Ugh Alan Stern
2008-04-02 15:44 ` 2.6.25-rc7: Ugh. ---> PATCH Mark Lord
@ 2008-04-02 16:04 ` David Brownell
2008-04-02 16:09 ` Mark Lord
2008-04-02 16:20 ` [PATCH] usb ehci_iaa_watchdog fix Mark Lord
1 sibling, 2 replies; 90+ messages in thread
From: David Brownell @ 2008-04-02 16:04 UTC (permalink / raw)
To: stern, lkml; +Cc: pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
> Also, check out the thread on LKML started by Tino Keitel. He had
> similar problems and found that reverting commit
> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
And try the change I suggested there: taking the
HC_IS_RUNNING test out of ehci_iaa_watchdog().
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 16:04 ` 2.6.25-rc7: Ugh David Brownell
@ 2008-04-02 16:09 ` Mark Lord
2008-04-02 20:22 ` David Brownell
2008-04-02 16:20 ` [PATCH] usb ehci_iaa_watchdog fix Mark Lord
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 16:09 UTC (permalink / raw)
To: David Brownell
Cc: stern, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
David Brownell wrote:
>> Also, check out the thread on LKML started by Tino Keitel. He had
>> similar problems and found that reverting commit
>> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
>
> And try the change I suggested there: taking the
> HC_IS_RUNNING test out of ehci_iaa_watchdog().
..
Will do, thanks. And there's a similar one in ehci_work(). ??
^ permalink raw reply [flat|nested] 90+ messages in thread
* [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 16:04 ` 2.6.25-rc7: Ugh David Brownell
2008-04-02 16:09 ` Mark Lord
@ 2008-04-02 16:20 ` Mark Lord
2008-04-02 16:48 ` Alan Stern
2008-04-02 16:56 ` David Brownell
1 sibling, 2 replies; 90+ messages in thread
From: Mark Lord @ 2008-04-02 16:20 UTC (permalink / raw)
To: David Brownell
Cc: stern, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
David Brownell wrote:
>> Also, check out the thread on LKML started by Tino Keitel. He had
>> similar problems and found that reverting commit
>> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
>
> And try the change I suggested there: taking the
> HC_IS_RUNNING test out of ehci_iaa_watchdog().
..
Yup, that does indeed cure it.
Here's a patch, in case you didn't already generate one:
Signed-off-by: Mark Lord <mlord@pobox.com>
--- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
+++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
@@ -289,9 +289,7 @@
* (a) SMP races against real IAA firing and retriggering, and
* (b) clean HC shutdown, when IAA watchdog was pending.
*/
- if (ehci->reclaim
- && !timer_pending(&ehci->iaa_watchdog)
- && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
+ if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
u32 cmd, status;
/* If we get here, IAA is *REALLY* late. It's barely
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 16:20 ` [PATCH] usb ehci_iaa_watchdog fix Mark Lord
@ 2008-04-02 16:48 ` Alan Stern
2008-04-02 17:34 ` Mark Lord
2008-04-02 20:31 ` David Brownell
2008-04-02 16:56 ` David Brownell
1 sibling, 2 replies; 90+ messages in thread
From: Alan Stern @ 2008-04-02 16:48 UTC (permalink / raw)
To: Mark Lord
Cc: David Brownell, pavel, oliver, linux-usb, linux-kernel, jikos,
gregkh, akpm
On Wed, 2 Apr 2008, Mark Lord wrote:
> Yup, that does indeed cure it.
> Here's a patch, in case you didn't already generate one:
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
> @@ -289,9 +289,7 @@
> * (a) SMP races against real IAA firing and retriggering, and
> * (b) clean HC shutdown, when IAA watchdog was pending.
> */
> - if (ehci->reclaim
> - && !timer_pending(&ehci->iaa_watchdog)
> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
> u32 cmd, status;
>
> /* If we get here, IAA is *REALLY* late. It's barely
Okay, I'm puzzled. How could this make any difference?
ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is
set.
Is the real problem that it does so before calling ehci_work() instead
of after calling ehci_halt()?
Mark, if you want to experiment some more, try reverting your patch
above and moving:
if (ehci->reclaim)
end_unlink_async(ehci);
in ehci-hub.c:ehci_bus_suspend() to just after the line saying:
hcd->state = HC_STATE_SUSPENDED;
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 16:20 ` [PATCH] usb ehci_iaa_watchdog fix Mark Lord
2008-04-02 16:48 ` Alan Stern
@ 2008-04-02 16:56 ` David Brownell
1 sibling, 0 replies; 90+ messages in thread
From: David Brownell @ 2008-04-02 16:56 UTC (permalink / raw)
To: Mark Lord
Cc: stern, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Mark Lord wrote:
> David Brownell wrote:
> >> Also, check out the thread on LKML started by Tino Keitel. He had
> >> similar problems and found that reverting commit
> >> e82cc1288fa57857c6af8c57f3d07096d4bcd9d9 fixed them.
> >
> > And try the change I suggested there: taking the
> > HC_IS_RUNNING test out of ehci_iaa_watchdog().
> ..
>
> Yup, that does indeed cure it.
Given your immediately-preceding experience, I'll wait for a
bit more confirmation ... but this seems like a candidate to
merge while 2.6.25 still hasn't frozen!!
> Here's a patch, in case you didn't already generate one:
I hadn't; thanks.
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
> @@ -289,9 +289,7 @@
> * (a) SMP races against real IAA firing and retriggering, and
> * (b) clean HC shutdown, when IAA watchdog was pending.
> */
> - if (ehci->reclaim
> - && !timer_pending(&ehci->iaa_watchdog)
> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
> u32 cmd, status;
>
> /* If we get here, IAA is *REALLY* late. It's barely
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 16:48 ` Alan Stern
@ 2008-04-02 17:34 ` Mark Lord
2008-04-02 18:08 ` Mark Lord
2008-04-02 20:31 ` David Brownell
1 sibling, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 17:34 UTC (permalink / raw)
To: Alan Stern
Cc: David Brownell, pavel, oliver, linux-usb, linux-kernel, jikos,
gregkh, akpm
Alan Stern wrote:
> On Wed, 2 Apr 2008, Mark Lord wrote:
>
>> Yup, that does indeed cure it.
>> Here's a patch, in case you didn't already generate one:
>>
>> Signed-off-by: Mark Lord <mlord@pobox.com>
>>
>> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
>> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 12:16:40.000000000 -0400
>> @@ -289,9 +289,7 @@
>> * (a) SMP races against real IAA firing and retriggering, and
>> * (b) clean HC shutdown, when IAA watchdog was pending.
>> */
>> - if (ehci->reclaim
>> - && !timer_pending(&ehci->iaa_watchdog)
>> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
>> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
>> u32 cmd, status;
>>
>> /* If we get here, IAA is *REALLY* late. It's barely
>
> Okay, I'm puzzled. How could this make any difference?
> ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim is
> set.
>
> Is the real problem that it does so before calling ehci_work() instead
> of after calling ehci_halt()?
>
> Mark, if you want to experiment some more, try reverting your patch
> above and moving:
..
Here's what I did, and yes, this also works. Pick one.
This patch, suggested by Alan Stern, fixes the hung USB issues
on my notebook from suspend/resume cycles.
Signed-off-by: Mark Lord <mlord@pobox.com>
--- rc8/drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400
+++ linux/drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000 -0400
@@ -135,8 +135,6 @@
hcd->state = HC_STATE_QUIESCING;
}
ehci->command = ehci_readl(ehci, &ehci->regs->command);
- if (ehci->reclaim)
- end_unlink_async(ehci);
ehci_work(ehci);
/* Unlike other USB host controller types, EHCI doesn't have
@@ -180,6 +178,9 @@
ehci_halt (ehci);
hcd->state = HC_STATE_SUSPENDED;
+ if (ehci->reclaim)
+ end_unlink_async(ehci);
+
/* allow remote wakeup */
mask = INTR_MASK;
if (!device_may_wakeup(&hcd->self.root_hub->dev))
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 17:34 ` Mark Lord
@ 2008-04-02 18:08 ` Mark Lord
2008-04-02 19:20 ` Alan Stern
0 siblings, 1 reply; 90+ messages in thread
From: Mark Lord @ 2008-04-02 18:08 UTC (permalink / raw)
To: Alan Stern
Cc: David Brownell, pavel, oliver, linux-usb, linux-kernel, jikos,
gregkh, akpm
Mark Lord wrote:
> Alan Stern wrote:
>> On Wed, 2 Apr 2008, Mark Lord wrote:
>>
>>> Yup, that does indeed cure it.
>>> Here's a patch, in case you didn't already generate one:
>>>
>>> Signed-off-by: Mark Lord <mlord@pobox.com>
>>>
>>> --- rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000
>>> -0400
>>> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02
>>> 12:16:40.000000000 -0400
>>> @@ -289,9 +289,7 @@
>>> * (a) SMP races against real IAA firing and retriggering, and
>>> * (b) clean HC shutdown, when IAA watchdog was pending.
>>> */
>>> - if (ehci->reclaim
>>> - && !timer_pending(&ehci->iaa_watchdog)
>>> - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
>>> + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
>>> u32 cmd, status;
>>>
>>> /* If we get here, IAA is *REALLY* late. It's barely
>>
>> Okay, I'm puzzled. How could this make any difference?
>> ehci_bus_suspend() calls end_unlink_async() anyway, whenever reclaim
>> is set.
>>
>> Is the real problem that it does so before calling ehci_work() instead
>> of after calling ehci_halt()?
>>
>> Mark, if you want to experiment some more, try reverting your patch
>> above and moving:
> ..
>
> Here's what I did, and yes, this also works. Pick one.
>
> This patch, suggested by Alan Stern, fixes the hung USB issues
> on my notebook from suspend/resume cycles.
>
> Signed-off-by: Mark Lord <mlord@pobox.com>
>
> --- rc8/drivers/usb/host/ehci-hub.c 2008-03-11 11:18:40.000000000 -0400
> +++ linux/drivers/usb/host/ehci-hub.c 2008-04-02 13:28:50.000000000
> -0400
> @@ -135,8 +135,6 @@
> hcd->state = HC_STATE_QUIESCING;
> }
> ehci->command = ehci_readl(ehci, &ehci->regs->command);
> - if (ehci->reclaim)
> - end_unlink_async(ehci);
> ehci_work(ehci);
>
> /* Unlike other USB host controller types, EHCI doesn't have
> @@ -180,6 +178,9 @@
> ehci_halt (ehci);
> hcd->state = HC_STATE_SUSPENDED;
>
> + if (ehci->reclaim)
> + end_unlink_async(ehci);
> +
> /* allow remote wakeup */
> mask = INTR_MASK;
> if (!device_may_wakeup(&hcd->self.root_hub->dev))
..
Either patch is stable here, and have survived reboots and suspend/resumes,
with and without the 2.2Kohm resistor to drain residual USB voltage.
Which one should Andrew/Linus take?
-ml
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 18:08 ` Mark Lord
@ 2008-04-02 19:20 ` Alan Stern
2008-04-02 20:42 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Alan Stern @ 2008-04-02 19:20 UTC (permalink / raw)
To: Mark Lord
Cc: David Brownell, pavel, oliver, linux-usb, linux-kernel, jikos,
gregkh, akpm
On Wed, 2 Apr 2008, Mark Lord wrote:
> Either patch is stable here, and have survived reboots and suspend/resumes,
> with and without the 2.2Kohm resistor to drain residual USB voltage.
Great! Thanks for testing.
> Which one should Andrew/Linus take?
It's up to David, of course. My preference is for the patch I
proposed, naturally enough. It fixes the cause rather than the
symptom.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh. ---> PATCH
2008-04-02 15:44 ` 2.6.25-rc7: Ugh. ---> PATCH Mark Lord
2008-04-02 15:47 ` Mark Lord
@ 2008-04-02 20:09 ` Alan Stern
1 sibling, 0 replies; 90+ messages in thread
From: Alan Stern @ 2008-04-02 20:09 UTC (permalink / raw)
To: Mark Lord
Cc: Oliver Neukum, Pavel Machek, Linux Kernel, Greg KH,
Andrew Morton, jikos, linux-usb
On Wed, 2 Apr 2008, Mark Lord wrote:
> When comparing 2.6.24 against 2.6.25, this line of code
> stood out as not looking entirely correct, given the new
> uses of QH_STATE_UNLINK_WAIT in 2.6.25.
> --- linux-2.6.25-rc8/drivers/usb/host/ehci-hcd.c 2008-03-11 11:18:40.000000000 -0400
> +++ linux/drivers/usb/host/ehci-hcd.c 2008-04-02 11:36:13.000000000 -0400
> @@ -815,7 +815,7 @@
> end_unlink_async(ehci);
>
> /* if it's not linked then there's nothing to do */
> - if (qh->qh_state != QH_STATE_LINKED)
> + if (qh->qh_state != QH_STATE_LINKED && qh->qh_state != QH_STATE_UNLINK_WAIT)
> ;
>
> /* defer till later if busy */
To answer your implied question...
QH_STATE_UNLINK_WAIT doesn't have a new meaning in 2.6.25. Just as
before, it means that qh is on a queue waiting to be unlinked.
qh->qh_state can never be equal to QH_STATE_UNLINK_WAIT at this point.
If it were, it would mean that some part of the driver had tried to
unlink qh twice. But even then, the correct move would be to follow
the "nothing to do" path -- since qh is already waiting to be unlinked,
there's no point trying to do any more.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-04-02 16:09 ` Mark Lord
@ 2008-04-02 20:22 ` David Brownell
0 siblings, 0 replies; 90+ messages in thread
From: David Brownell @ 2008-04-02 20:22 UTC (permalink / raw)
To: Mark Lord
Cc: stern, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Mark Lord wrote:
>
> > And try the change I suggested there: taking the
> > HC_IS_RUNNING test out of ehci_iaa_watchdog().
> ..
>
> Will do, thanks. And there's a similar one in ehci_work(). ??
Don't see why that should matter. In any case, that
test hasn't changed recently.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 16:48 ` Alan Stern
2008-04-02 17:34 ` Mark Lord
@ 2008-04-02 20:31 ` David Brownell
2008-04-02 20:55 ` Alan Stern
1 sibling, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-04-02 20:31 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Alan Stern wrote:
> > - if (ehci->reclaim
> > - && !timer_pending(&ehci->iaa_watchdog)
> > - && HC_IS_RUNNING(ehci_to_hcd(ehci)->state)) {
> > + if (ehci->reclaim && !timer_pending(&ehci->iaa_watchdog)) {
> > u32 cmd, status;
> >
> > /* If we get here, IAA is *REALLY* late. It's barely
>
> Okay, I'm puzzled. How could this make any difference?
It's more like: what else in that patch could have had
any such effect? That HC_IS_RUNNING test was the only
candidate.
Those hcd->state tests have been getting more and more
dodgey as time goes by. At this point I hardly trust
any of them. There *IS* no clear state machine which
governs the usbcore/HCD interaction.
- Dave
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 19:20 ` Alan Stern
@ 2008-04-02 20:42 ` David Brownell
2008-04-02 21:08 ` Alan Stern
0 siblings, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-04-02 20:42 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Alan Stern wrote:
> > Which one should Andrew/Linus take?
>
> It's up to David, of course. My preference is for the patch I
> proposed, naturally enough.
Mine was for the one that got two "it works" confirmations. :)
> It fixes the cause rather than the symptom.
I'm not sure I'd agree with that.
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 20:31 ` David Brownell
@ 2008-04-02 20:55 ` Alan Stern
2008-04-02 23:07 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Alan Stern @ 2008-04-02 20:55 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wed, 2 Apr 2008, David Brownell wrote:
> Those hcd->state tests have been getting more and more
> dodgey as time goes by. At this point I hardly trust
> any of them. There *IS* no clear state machine which
> governs the usbcore/HCD interaction.
ISTR trying to make that same point a few times over the past two or
three years... :-)
It would make more sense for each HCD to keep its own private "state"
variable. The interaction with usbcore can be broken down into a few
simple tests, such as:
Is the HC dead?
Is the HC (i.e., the PCI or platform device) suspended?
Is the HC running?
Is it okay to submit an URB?
There's plenty of redundancy in this list, and some of the information
may already be available in hcd->self.root_hub->state. In many or most
cases, these questions can't be answered in a race-free manner anyhow,
which limits their usefulness.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 20:42 ` David Brownell
@ 2008-04-02 21:08 ` Alan Stern
2008-04-07 23:37 ` David Brownell
0 siblings, 1 reply; 90+ messages in thread
From: Alan Stern @ 2008-04-02 21:08 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wed, 2 Apr 2008, David Brownell wrote:
> > It fixes the cause rather than the symptom.
>
> I'm not sure I'd agree with that.
Really? The logic seemed clear enough to me.
1. Evidently the ehci_iaa_watchdog routine was getting called at a
time when the host controller wasn't running -- which had to
have been after it was suspended.
2. But ehci_bus_suspend() calls end_unlink_async(), which turns
off the IAA watchdog timer.
3. Hence the timer must have been restarted later on while
ehci_bus_suspend() was still running. The call to ehci_work()
appeared to be the only place that could have happened.
4. Thus moving the end_unlink_async() call to after ehci_work()
(or just to be doubly safe, after ehci_halt() and the change
to HC_STATE_SUSPENDED) should take care of all pending QH
unlinks and leave none of them unfinished.
Strictly speaking, it would be best to move the del_timer_sync() calls
to after ehci_lock is released. But it doesn't really matter if the
timer routines get invoked after the controller is suspended.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 20:55 ` Alan Stern
@ 2008-04-02 23:07 ` David Brownell
0 siblings, 0 replies; 90+ messages in thread
From: David Brownell @ 2008-04-02 23:07 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Alan Stern wrote:
> On Wed, 2 Apr 2008, David Brownell wrote:
>
> > Those hcd->state tests have been getting more and more
> > dodgey as time goes by. At this point I hardly trust
> > any of them. There *IS* no clear state machine which
> > governs the usbcore/HCD interaction.
>
> ISTR trying to make that same point a few times over the past two or
> three years... :-)
Was there any argument about that fact? The question was
more "shouldn't there actually *be* such a state machine"
than "do we have one yet".
> It would make more sense for each HCD to keep its own private "state"
> variable. The interaction with usbcore can be broken down into a few
> simple tests, such as:
>
> Is the HC dead?
> Is the HC (i.e., the PCI or platform device) suspended?
> Is the HC running?
> Is it okay to submit an URB?
>
> There's plenty of redundancy in this list, and some of the information
> may already be available in hcd->self.root_hub->state. In many or most
> cases, these questions can't be answered in a race-free manner anyhow,
> which limits their usefulness.
At any given instant, all of them have valid answers.
The only one that's not resolvable by mutual exclusion
on the HCD's spinlock is "is it dead", since the HC
could crap out at any time. (Nowadays that's fortunately
rare ... we've been whomping on such bugs for long enough
by now!)
- Dave
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: 2.6.25-rc7: Ugh.
2008-03-28 4:56 ` David Miller
2008-03-28 5:17 ` Mark Lord
2008-03-28 16:34 ` Bob Tracy
@ 2008-04-05 18:23 ` Bill Davidsen
2 siblings, 0 replies; 90+ messages in thread
From: Bill Davidsen @ 2008-04-05 18:23 UTC (permalink / raw)
To: linux-kernel; +Cc: linux-usb, linux-kernel
David Miller wrote:
> From: rct@frus.com (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.
>
Most of us got over "mine is bigger than yours" bragging at about age
13. He said "laptop," that means slow builds, slow installs, slow boots,
and unless he's on a fat net pipe to a faster machine, build elsewhere
isn't much of a saving.
--
Bill Davidsen <davidsen@tmr.com>
"We have more to fear from the bungling of the incompetent than from
the machinations of the wicked." - from Slashdot
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-02 21:08 ` Alan Stern
@ 2008-04-07 23:37 ` David Brownell
2008-04-08 2:13 ` Alan Stern
0 siblings, 1 reply; 90+ messages in thread
From: David Brownell @ 2008-04-07 23:37 UTC (permalink / raw)
To: Alan Stern
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Wednesday 02 April 2008, Alan Stern wrote:
> On Wed, 2 Apr 2008, David Brownell wrote:
>
> > > It fixes the cause rather than the symptom.
> >
> > I'm not sure I'd agree with that.
>
> Really? The logic seemed clear enough to me.
>
> 1. Evidently the ehci_iaa_watchdog routine was getting called at a
> time when the host controller wasn't running -- which had to
> have been after it was suspended.
The change to remove the HC_IS_RUNNING test meant that routine
would then work when hcd->state is HC_STATE_SUSPENDED or possibly
HC_STATE_RESUMING. (Since those are the two states for which
HC_IS_RUNNING fails, other than HC_STATE_HALTED which shouldn't
be happening here...)
Now, prior to the now-merged patch that was skipping some work,
and that seemed to cause resume problems. Making it not skip
the work made the resume behave (as did the now-merged patch).
> 2. But ehci_bus_suspend() calls end_unlink_async(), which turns
> off the IAA watchdog timer.
Not exactly. First, ehci_bus_suspend() force the timer off all
by itself ... way too early, while things can still retrigger it.
That's a buggy idiom that should be fixed. (As you've agreed,
elsewhere.)
Second, it doesn't always call end_unlink_async() ... only when
one or more async unlink is still pending.
Third, if it *does* call end_unlink_async(), it can retriger
the timer when it needs to do another unlink. Only when the
HC is halted (HC_STATE_HALT) is that logic bypassed, scrubbing
several endpoints at once. (And a minor fourth point, direct
calls to end_unlink_async leaves the IAA IRQ machinery active.)
I think your fix handles the "one pending unlink" case, but
not the more general "N pending unlinks" ...
> 3. Hence the timer must have been restarted later on while
> ehci_bus_suspend() was still running. The call to ehci_work()
> appeared to be the only place that could have happened.
Removing the state check in the watchdog changed behavior, so the
HC must have been in one of the two states I listed above when
that watchdog fired (SUSPENDED or RESUMING). And it had work to
do, which (because of the state check) it didn't do.
> 4. Thus moving the end_unlink_async() call to after ehci_work()
> (or just to be doubly safe, after ehci_halt() and the change
> to HC_STATE_SUSPENDED) should take care of all pending QH
> unlinks and leave none of them unfinished.
It takes care of *ONE* pending QH unlink. If there's more than
one, it retriggers the timer, so this problem will reappear...
> Strictly speaking, it would be best to move the del_timer_sync() calls
> to after ehci_lock is released. But it doesn't really matter if the
> timer routines get invoked after the controller is suspended.
When the timer would be retriggered, to finish additional unlinks,
it does matter. A complete fix for this would (a) disable the IAA
watchdog timer later, once it can never be retriggered again, and
(b) make end_unlink_async handle the multiple-unlinks case when the
HC is suspended, including not retriggering the watchdog.
- Dave
>
> Alan Stern
>
^ permalink raw reply [flat|nested] 90+ messages in thread
* Re: [PATCH] usb ehci_iaa_watchdog fix
2008-04-07 23:37 ` David Brownell
@ 2008-04-08 2:13 ` Alan Stern
0 siblings, 0 replies; 90+ messages in thread
From: Alan Stern @ 2008-04-08 2:13 UTC (permalink / raw)
To: David Brownell
Cc: Mark Lord, pavel, oliver, linux-usb, linux-kernel, jikos, gregkh, akpm
On Mon, 7 Apr 2008, David Brownell wrote:
> Third, if it *does* call end_unlink_async(), it can retriger
> the timer when it needs to do another unlink. Only when the
> HC is halted (HC_STATE_HALT) is that logic bypassed, scrubbing
> several endpoints at once. (And a minor fourth point, direct
> calls to end_unlink_async leaves the IAA IRQ machinery active.)
>
> I think your fix handles the "one pending unlink" case, but
> not the more general "N pending unlinks" ...
Sounds right. That test at the end of start_unlink_async() should be
changed to !RUNNING instead of HALT.
To help prevent unwanted recursion, I wrote a patch some time ago that
would batch up multiple unlinks. (The idea was to keep track of which
entries were added to the reclaim queue before the current IAA cycle
got started, and handle them all at one stroke when the current cycle
ends.) That patch is a bit out-of-date now, but it shouldn't be too
hard to bring it up to speed.
> When the timer would be retriggered, to finish additional unlinks,
> it does matter. A complete fix for this would (a) disable the IAA
> watchdog timer later, once it can never be retriggered again, and
> (b) make end_unlink_async handle the multiple-unlinks case when the
> HC is suspended, including not retriggering the watchdog.
Agreed. If the code does (a) after (b) then end_unlink_async doesn't
need to avoid retriggering the watchdog.
Alan Stern
^ permalink raw reply [flat|nested] 90+ messages in thread
end of thread, other threads:[~2008-04-08 2:13 UTC | newest]
Thread overview: 90+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2008-03-27 15:29 2.6.25-rc7: Ugh Mark Lord
2008-03-27 16:07 ` Greg KH
2008-03-28 0:32 ` Jiri Kosina
2008-03-28 1:57 ` Mark Lord
2008-03-28 3:12 ` David Miller
2008-03-28 4:42 ` Bob Tracy
2008-03-28 4:56 ` David Miller
2008-03-28 5:17 ` Mark Lord
2008-03-28 6:01 ` david
2008-03-28 16:34 ` Bob Tracy
2008-04-05 18:23 ` Bill Davidsen
2008-03-28 5:36 ` Mike Galbraith
2008-03-28 5:46 ` Mark Lord
2008-03-28 5:52 ` Mark Lord
2008-03-28 6:05 ` Mark Lord
2008-03-28 6:58 ` David Brownell
2008-03-28 9:16 ` Ingo Molnar
2008-03-28 9:49 ` David Brownell
2008-03-28 10:20 ` Ingo Molnar
2008-03-28 11:01 ` Pavel Machek
2008-03-28 15:03 ` Jan Engelhardt
2008-03-28 20:14 ` David Brownell
2008-03-28 12:51 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) Tilman Schmidt
2008-03-28 13:49 ` Kconfig RTC selection Mark Lord
2008-03-28 19:22 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
2008-03-29 12:55 ` Kconfig RTC selection Tilman Schmidt
2008-03-28 13:47 ` 2.6.25-rc7: Ugh Mark Lord
2008-03-28 20:04 ` Kconfig RTC selection (was: 2.6.25-rc7: Ugh.) David Brownell
2008-03-28 21:06 ` Adrian Bunk
2008-03-28 21:23 ` David Brownell
2008-03-28 21:33 ` Adrian Bunk
2008-03-28 21:45 ` David Brownell
2008-03-28 21:59 ` Adrian Bunk
2008-03-28 22:18 ` David Brownell
2008-03-28 22:36 ` Adrian Bunk
2008-03-29 11:40 ` [rtc-linux] " Alessandro Zummo
2008-03-28 14:56 ` 2.6.25-rc7: Ugh Jan Engelhardt
2008-03-28 17:47 ` Adrian Bunk
2008-03-29 3:58 ` Mark Lord
2008-03-28 1:51 ` Mark Lord
2008-03-28 2:11 ` Mark Lord
2008-03-28 2:13 ` Mark Lord
2008-03-28 14:34 ` Alan Stern
2008-03-28 14:57 ` Mark Lord
2008-03-27 22:00 ` Rafael J. Wysocki
2008-03-28 5:22 ` Mark Lord
2008-03-28 2:14 ` Mark Lord
2008-03-28 9:24 ` Pavel Machek
2008-03-30 21:04 ` Mark Lord
2008-03-30 21:09 ` Mark Lord
2008-03-31 11:55 ` Oliver Neukum
2008-03-31 14:39 ` Mark Lord
2008-03-31 15:04 ` Oliver Neukum
2008-03-31 15:04 ` Mark Lord
2008-03-31 15:14 ` Mark Lord
2008-03-31 16:37 ` Oliver Neukum
2008-03-31 17:03 ` Mark Lord
2008-03-31 17:06 ` Mark Lord
2008-03-31 17:15 ` Mark Lord
2008-03-31 17:21 ` Mark Lord
2008-03-31 17:30 ` Mark Lord
2008-03-31 18:05 ` Oliver Neukum
2008-03-31 19:21 ` Mark Lord
2008-04-02 8:04 ` Oliver Neukum
2008-04-02 14:38 ` Mark Lord
2008-04-02 14:38 ` Mark Lord
2008-04-02 15:05 ` 2.6.25-rc7/rc8 USB dead on resume Mark Lord
2008-04-02 15:21 ` Oliver Neukum
2008-04-02 15:08 ` 2.6.25-rc7: Ugh Alan Stern
2008-04-02 15:44 ` 2.6.25-rc7: Ugh. ---> PATCH Mark Lord
2008-04-02 15:47 ` Mark Lord
2008-04-02 15:49 ` Mark Lord
2008-04-02 20:09 ` Alan Stern
2008-04-02 16:04 ` 2.6.25-rc7: Ugh David Brownell
2008-04-02 16:09 ` Mark Lord
2008-04-02 20:22 ` David Brownell
2008-04-02 16:20 ` [PATCH] usb ehci_iaa_watchdog fix Mark Lord
2008-04-02 16:48 ` Alan Stern
2008-04-02 17:34 ` Mark Lord
2008-04-02 18:08 ` Mark Lord
2008-04-02 19:20 ` Alan Stern
2008-04-02 20:42 ` David Brownell
2008-04-02 21:08 ` Alan Stern
2008-04-07 23:37 ` David Brownell
2008-04-08 2:13 ` Alan Stern
2008-04-02 20:31 ` David Brownell
2008-04-02 20:55 ` Alan Stern
2008-04-02 23:07 ` David Brownell
2008-04-02 16:56 ` David Brownell
2008-04-01 9:59 ` 2.6.25-rc7: Ugh Pavel Machek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).