From: Mark Lord <lkml@rtr.ca>
To: Pierre Ossman <drzeus-list@drzeus.cx>
Cc: sdhci-devel@list.drzeus.cx, Adrian Bunk <bunk@stusta.de>,
Andrew Morton <akpm@linux-foundation.org>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: [BUG] sdhci regression in 2.6.21-rc2
Date: Mon, 05 Mar 2007 09:25:21 -0500 [thread overview]
Message-ID: <45EC2851.7020905@rtr.ca> (raw)
In-Reply-To: <45EBAC73.7010600@drzeus.cx>
Pierre Ossman wrote:
> Mark Lord wrote:
>> Another regression, for Pierre Ossman this time.
>>
>> My syslog gets spammed like this (below) on suspend/resume (to RAM) cycles.
>> Worked fine, without all of the noise, in all previous kernels up to
>> 2.6.20+.
>>
>
> This looks like a PCI configuration issue.
To me, it looks like a buggy driver "resume" sequence.
The low-level SDHCI driver is trying to use the device
before the PM/PCI stuff has restored the pre-suspend state.
> Can you bisect which commit caused the issue?
Nope. I don't have time to run around that (huge) treadmill, thanks.
>And what's the PCI address of the device?
0000:03:01.2 0805: Ricoh Co Ltd R5C822 SD/SDIO/MMC/MS/MSPro Host Adapter (rev 17)
So, from the syslog, we see that the machine suspends (to RAM):
>kernel: Stopping tasks ... done.
>kernel: Suspending console(s)
>kernel: pl2303 1-1.3:1.0: no suspend for driver pl2303?
>kernel: ACPI: PCI interrupt for device 0000:03:01.2 disabled
>kernel: ACPI: PCI interrupt for device 0000:03:00.0 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1f.2 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1e.2 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1d.7 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1d.3 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1d.2 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1d.1 disabled
>kernel: ACPI: PCI interrupt for device 0000:00:1d.0 disabled
>kernel: Intel machine check architecture supported.
>kernel: Intel machine check reporting enabled on CPU#0.
A few seconds later, I manually wake-up the machine.
It resumes (from RAM), and the PM code begins restoring PCI config
space for various device:
>kernel: Back to C!
>kernel: PM: Writing back config space on device 0000:00:01.0 at offset 7 (was 2000d0d0, writing d0d0)
>kernel: PM: Writing back config space on device 0000:00:01.0 at offset 3 (was 10000, writing 10010)
>kernel: PCI: Setting latency timer of device 0000:00:01.0 to 64
>kernel: ACPI: PCI Interrupt 0000:00:1d.0[A] -> GSI 16 (level, low) -> IRQ 16
>kernel: PCI: Setting latency timer of device 0000:00:1d.0 to 64
>kernel: usb usb2: root hub lost power or was reset
>kernel: PCI: Enabling device 0000:00:1d.1 (0000 -> 0001)
>kernel: ACPI: PCI Interrupt 0000:00:1d.1[B] -> GSI 17 (level, low) -> IRQ 18
>kernel: PCI: Setting latency timer of device 0000:00:1d.1 to 64
>kernel: PM: Writing back config space on device 0000:00:1d.1 at offset f (was 200, writing 20a)
>kernel: PM: Writing back config space on device 0000:00:1d.1 at offset 8 (was 1, writing bf61)
>kernel: usb usb3: root hub lost power or was reset
>kernel: PCI: Enabling device 0000:00:1d.2 (0000 -> 0001)
>kernel: ACPI: PCI Interrupt 0000:00:1d.2[C] -> GSI 18 (level, low) -> IRQ 19
>kernel: PCI: Setting latency timer of device 0000:00:1d.2 to 64
>kernel: PM: Writing back config space on device 0000:00:1d.2 at offset f (was 300, writing 309)
>kernel: PM: Writing back config space on device 0000:00:1d.2 at offset 8 (was 1, writing bf41)
>kernel: usb usb4: root hub lost power or was reset
>kernel: PCI: Enabling device 0000:00:1d.3 (0000 -> 0001)
>kernel: ACPI: PCI Interrupt 0000:00:1d.3[D] -> GSI 19 (level, low) -> IRQ 17
>kernel: PCI: Setting latency timer of device 0000:00:1d.3 to 64
>kernel: PM: Writing back config space on device 0000:00:1d.3 at offset f (was 400, writing 407)
>kernel: PM: Writing back config space on device 0000:00:1d.3 at offset 8 (was 1, writing bf21)
>kernel: usb usb5: root hub lost power or was reset
But.. in the middle of all of this, we now see the SHDCI code
trying to talk to its as-yet-not-restored device, and being rather
noisy about it all:
>kernel: sdhci: ============== REGISTER DUMP ==============
>kernel: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
>kernel: sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff
>kernel: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
>kernel: sdhci: Present: 0xffffffff | Host ctl: 0x000000ff
>kernel: sdhci: Power: 0x000000ff | Blk gap: 0x000000ff
>kernel: sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff
>kernel: sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff
>kernel: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
>kernel: sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
>kernel: sdhci: Caps: 0xffffffff | Max curr: 0xffffffff
>kernel: sdhci: ===========================================
>kernel: mmc0: Card is consuming too much power!
>kernel: mmc0: Unexpected interrupt 0x00800000.
>kernel: sdhci: ============== REGISTER DUMP ==============
>kernel: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
>kernel: sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff
>kernel: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
>kernel: sdhci: Present: 0xffffffff | Host ctl: 0x000000ff
>kernel: sdhci: Power: 0x000000ff | Blk gap: 0x000000ff
>kernel: sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff
>kernel: sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff
>kernel: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
>kernel: sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
>kernel: sdhci: Caps: 0xffffffff | Max curr: 0xffffffff
>kernel: sdhci: ===========================================
Meanwhile, the PM code is also continuing to bring up devices:
>kernel: ACPI: PCI Interrupt 0000:00:1d.7[A] -> GSI 16 (level, low) -> IRQ 16
>kernel: PCI: Setting latency timer of device 0000:00:1d.7 to 64
>kernel: usb usb1: root hub lost power or was reset
>kernel: ehci_hcd 0000:00:1d.7: debug port 1
>kernel: PCI: cache line size of 32 is not supported by device 0000:00:1d.7
>kernel: PM: Writing back config space on device 0000:00:1e.0 at offset 9 (was 10001, writing 8bf18801)
>kernel: PM: Writing back config space on device 0000:00:1e.0 at offset 8 (was 0, writing dfc0dfc0)
>kernel: PM: Writing back config space on device 0000:00:1e.0 at offset 7 (was 2280e0f0, writing 22802020)
>kernel: PM: Writing back config space on device 0000:00:1e.0 at offset 6 (was 20030300, writing 20070300)
>kernel: PM: Writing back config space on device 0000:00:1e.0 at offset 1 (was 100005, writing 100107)
>kernel: PCI: Setting latency timer of device 0000:00:1e.0 to 64
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset f (was 100, writing 10b)
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset 7 (was 0, writing dffffd00)
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset 6 (was 0, writing dffffe00)
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset 5 (was 1, writing ec41)
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset 4 (was 1, writing ed01)
>kernel: PM: Writing back config space on device 0000:00:1e.2 at offset 1 (was 2900000, writing 2900003)
>kernel: ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 16 (level, low) -> IRQ 16
>kernel: PCI: Setting latency timer of device 0000:00:1e.2 to 64
And the SDHCI continues to spam the syslog:
>kernel: mmc0: Controller never released inhibit bit(s).
>kernel: sdhci: ============== REGISTER DUMP ==============
>kernel: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
>kernel: sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff
>kernel: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
>kernel: sdhci: Present: 0xffffffff | Host ctl: 0x000000ff
>kernel: sdhci: Power: 0x000000ff | Blk gap: 0x000000ff
>kernel: sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff
>kernel: sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff
>kernel: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
>kernel: sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
>kernel: sdhci: Caps: 0xffffffff | Max curr: 0xffffffff
>kernel: sdhci: ===========================================
>kernel: mmc0: Reset 0x2 never completed.
>kernel: sdhci: ============== REGISTER DUMP ==============
>kernel: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
>kernel: sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff
>kernel: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
>kernel: sdhci: Present: 0xffffffff | Host ctl: 0x000000ff
>kernel: sdhci: Power: 0x000000ff | Blk gap: 0x000000ff
>kernel: sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff
>kernel: sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff
>kernel: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
>kernel: sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
>kernel: sdhci: Caps: 0xffffffff | Max curr: 0xffffffff
>kernel: sdhci: ===========================================
>kernel: mmc0: Reset 0x4 never completed.
>kernel: sdhci: ============== REGISTER DUMP ==============
>kernel: sdhci: Sys addr: 0xffffffff | Version: 0x0000ffff
>kernel: sdhci: Blk size: 0x0000ffff | Blk cnt: 0x0000ffff
>kernel: sdhci: Argument: 0xffffffff | Trn mode: 0x0000ffff
>kernel: sdhci: Present: 0xffffffff | Host ctl: 0x000000ff
>kernel: sdhci: Power: 0x000000ff | Blk gap: 0x000000ff
>kernel: sdhci: Wake-up: 0x000000ff | Clock: 0x0000ffff
>kernel: sdhci: Timeout: 0x000000ff | Int stat: 0xffffffff
>kernel: sdhci: Int enab: 0xffffffff | Sig enab: 0xffffffff
>kernel: sdhci: AC12 err: 0x0000ffff | Slot int: 0x0000ffff
>kernel: sdhci: Caps: 0xffffffff | Max curr: 0xffffffff
>kernel: sdhci: ===========================================
...
<snip>
And eventually we see more PM recovery messages:
>kernel: PM: Writing back config space on device 0000:00:1f.0 at offset 1 (was 2000007, writing 2000107)
>kernel: PM: Writing back config space on device 0000:00:1f.2 at offset f (was 200, writing 20a)
>kernel: PM: Writing back config space on device 0000:00:1f.2 at offset 9 (was d0000, writing 0)
>kernel: ACPI: PCI Interrupt 0000:00:1f.2[B] -> GSI 17 (level, low) -> IRQ 18
>kernel: PCI: Setting latency timer of device 0000:00:1f.2 to 64
>kernel: PM: Writing back config space on device 0000:00:1f.3 at offset f (was 200, writing 20a)
>kernel: PM: Writing back config space on device 0000:00:1f.3 at offset 1 (was 2800001, writing 2800101)
>kernel: PM: Writing back config space on device 0000:01:00.0 at offset f (was 1ff, writing 10b)
>kernel: PM: Writing back config space on device 0000:01:00.0 at offset c (was 0, writing dfe00000)
>kernel: PM: Writing back config space on device 0000:01:00.0 at offset 3 (was 0, writing 10)
>kernel: ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 16 (level, low) -> IRQ 16
>kernel: PM: Writing back config space on device 0000:03:00.0 at offset f (was 100, writing 109)
>kernel: PM: Writing back config space on device 0000:03:00.0 at offset 4 (was 0, writing dfcfe000)
>kernel: PM: Writing back config space on device 0000:03:00.0 at offset 3 (was 0, writing 4000)
>kernel: PM: Writing back config space on device 0000:03:00.0 at offset 1 (was 100000, writing 100106)
>kernel: ACPI: PCI Interrupt 0000:03:00.0[A] -> GSI 18 (level, low) -> IRQ 19
And here, finally, we see the PM code restoring state for the SDHCI controller:
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset f (was 7800100, writing 58001ff)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset e (was 0, writing 24fc)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset d (was 0, writing 2400)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset c (was 0, writing 20fc)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset b (was 0, writing 2000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset a (was 0, writing 8ffff000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 9 (was 0, writing 8c000000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 8 (was 0, writing 8bfff000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 7 (was 0, writing 88000000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 6 (was 0, writing b0070403)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 4 (was 0, writing dfc00000)
>kernel: PM: Writing back config space on device 0000:03:01.0 at offset 3 (was 820000, writing 82a800)
>kernel: PM: Writing back config space on device 0000:03:01.1 at offset 4 (was 0, writing dfcfc800)
>kernel: PM: Writing back config space on device 0000:03:01.1 at offset 3 (was 800000, writing 804000)
>kernel: PM: Writing back config space on device 0000:03:01.1 at offset 1 (was 2100000, writing 2100106)
>kernel: ohci1394: fw-host0: OHCI-1394 1.1 (PCI): IRQ=[19] MMIO=[dfcfc800-dfcfcfff] Max Packet=[2048] IR/IT contexts=[4/4]
>kernel: PM: Writing back config space on device 0000:03:01.2 at offset 4 (was 0, writing dfcfc700)
>kernel: PM: Writing back config space on device 0000:03:01.2 at offset 3 (was 800000, writing 804000)
>kernel: PM: Writing back config space on device 0000:03:01.2 at offset 1 (was 2100000, writing 2100106)
>kernel: ACPI: PCI Interrupt 0000:03:01.2[C] -> GSI 17 (level, low) -> IRQ 18
>kernel: PM: Writing back config space on device 0000:03:03.0 at offset f (was 18030100, writing 1803010a)
>kernel: PM: Writing back config space on device 0000:03:03.0 at offset 4 (was 0, writing dfcfd000)
>kernel: PM: Writing back config space on device 0000:03:03.0 at offset 3 (was 0, writing 4010)
>kernel: PM: Writing back config space on device 0000:03:03.0 at offset 1 (was 2900000, writing 2900112)
So, somewhere, the SDHCI drivers need to be told to stay dormant until their
device has been recovered, just like most other device drivers do.
Cheers
Mark
next prev parent reply other threads:[~2007-03-05 14:25 UTC|newest]
Thread overview: 187+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-02-28 5:16 Linux 2.6.21-rc2 Linus Torvalds
2007-02-28 5:50 ` Gabriel C
2007-02-28 7:13 ` [PATCH] affinity is not defined in non-smp kernels - i386 Fernando Luis Vázquez Cao
2007-02-28 7:16 ` [PATCH] affinity is not defined in non-smp kernels - i386 (v2) Fernando Luis Vázquez Cao
2007-02-28 7:24 ` [PATCH] affinity is not defined in non-smp kernels - i386 Eric W. Biederman
2007-02-28 17:31 ` Bill Davidsen
2007-02-28 18:21 ` Eric W. Biederman
2007-02-28 18:30 ` Linus Torvalds
2007-02-28 7:42 ` [PATCH] affinity is not defined in non-smp kernels - i386 (v2) Fernando Luis Vázquez Cao
2007-02-28 7:17 ` [PATCH] affinity is not defined in non-smp kernels - x86_64 Fernando Luis Vázquez Cao
2007-02-28 7:23 ` Linux 2.6.21-rc2 David Brown
2007-02-28 7:39 ` Brice Goglin
2007-02-28 13:09 ` Eric W. Biederman
2007-02-28 16:44 ` David Brown
2007-02-28 17:07 ` Randy Dunlap
2007-02-28 7:41 ` [PATCH] affinity is not defined in non-smp kernels - x86_64 Fernando Luis Vázquez Cao
2007-02-28 7:59 ` Linux 2.6.21-rc2 Damien Wyart
2007-03-05 1:50 ` [1/6] 2.6.21-rc2: known regressions Adrian Bunk
2007-03-05 2:26 ` Andrew Morton
2007-03-05 3:35 ` Greg KH
2007-03-06 0:55 ` Johannes Berg
2007-03-05 4:01 ` Mark Lord
2007-03-05 4:34 ` Greg KH
2007-03-05 12:42 ` Marcel Holtmann
2007-03-05 4:34 ` [BUG} usb regression in 2.6.21-rc2-git3 Mark Lord
2007-03-05 4:37 ` [BUG] sdhci regression in 2.6.21-rc2 Mark Lord
2007-03-05 5:36 ` Pierre Ossman
2007-03-05 14:25 ` Mark Lord [this message]
2007-03-05 15:19 ` Mark Lord
2007-03-06 4:17 ` Andrew Morton
2007-03-06 5:47 ` Pierre Ossman
2007-03-06 6:09 ` Andrew Morton
2007-03-06 7:23 ` Pierre Ossman
2007-03-05 15:20 ` Pierre Ossman
2007-03-05 15:23 ` Pierre Ossman
2007-03-05 15:35 ` Mark Lord
2007-03-05 16:00 ` Pierre Ossman
2007-03-05 16:18 ` Mark Lord
2007-03-05 4:43 ` [BUG} usb regression in 2.6.21-rc2-git3 Mark Lord
2007-03-12 14:56 ` [BUG} usb-serial " Mark Lord
2007-03-12 15:06 ` Oliver Neukum
2007-03-12 15:13 ` Mark Lord
2007-03-12 15:27 ` Oliver Neukum
2007-03-12 15:29 ` Greg KH
2007-03-12 15:38 ` Oliver Neukum
2007-03-12 16:03 ` Mark Lord
2007-03-12 16:10 ` Greg KH
2007-03-12 16:22 ` Mark Lord
2007-03-12 16:11 ` Mark Lord
2007-03-12 16:14 ` Mark Lord
2007-03-12 16:27 ` Mark Lord
2007-03-12 16:50 ` Mark Lord
2007-03-12 18:48 ` Oliver Neukum
2007-03-12 20:22 ` [PATCH] usb-serial regression (Oops) in 2.6.21-rc* Mark Lord
2007-03-12 20:33 ` Greg KH
2007-03-12 22:20 ` Mark Lord
2007-03-12 22:42 ` Jim Radford
2007-03-12 22:59 ` [PATCH] usb-serial regression fix Jim Radford
2007-03-13 0:18 ` Greg KH
2007-03-13 0:41 ` Jim Radford
2007-03-13 1:55 ` Mark Lord
2007-03-13 9:14 ` Jim Radford
2007-03-13 10:14 ` Oliver Neukum
2007-03-13 13:39 ` Mark Lord
2007-03-13 13:50 ` Oliver Neukum
2007-03-13 13:55 ` Mark Lord
2007-03-13 15:30 ` Jim Radford
2007-03-13 16:35 ` Mark Lord
2007-03-12 16:28 ` [BUG} usb-serial regression in 2.6.21-rc2-git3 Oliver Neukum
2007-03-12 15:31 ` Greg KH
2007-03-07 11:06 ` [1/6] 2.6.21-rc2: known regressions Jeff Garzik
2007-03-07 22:17 ` Albert Hopkins
2007-03-05 1:50 ` [2/6] " Adrian Bunk
2007-03-07 11:09 ` Jeff Garzik
2007-03-07 16:10 ` Linus Torvalds
2007-03-08 12:03 ` Ash Milsted
2007-03-08 12:31 ` Michael S. Tsirkin
2007-03-08 15:11 ` Jeff Chua
2007-03-08 18:01 ` Linus Torvalds
2007-03-08 19:06 ` Ingo Molnar
2007-03-08 19:10 ` Ingo Molnar
2007-03-08 19:47 ` Michael S. Tsirkin
2007-03-08 20:10 ` Ingo Molnar
2007-03-08 19:25 ` Ingo Molnar
2007-03-08 23:07 ` Ingo Molnar
2007-03-08 23:12 ` Ingo Molnar
2007-03-08 23:28 ` Ingo Molnar
2007-03-08 23:49 ` Linus Torvalds
2007-03-09 10:56 ` Ingo Molnar
2007-03-09 18:00 ` Linus Torvalds
2007-03-09 11:19 ` Pavel Machek
2007-03-18 16:07 ` Ingo Molnar
2007-03-18 16:40 ` [linux-pm] " Jim Gettys
2007-03-19 19:08 ` BSOD (was: [2/6] 2.6.21-rc2: known regressions) Pete Zaitcev
2007-03-19 19:38 ` BSOD David Miller
2007-03-19 19:54 ` BSOD Jesse Barnes
2007-03-19 20:05 ` BSOD David Miller
2007-03-19 20:20 ` BSOD Jesse Barnes
2007-03-19 20:20 ` BSOD Jim Gettys
2007-03-20 9:19 ` BSOD Paul Mackerras
2007-03-20 20:33 ` BSOD Jim Gettys
2007-03-19 20:33 ` [linux-pm] [2/6] 2.6.21-rc2: known regressions Bill Davidsen
2007-03-19 22:08 ` Jim Gettys
2007-03-20 14:44 ` Bill Davidsen
2007-03-09 17:48 ` Johannes Stezenbach
2007-03-09 23:35 ` Pavel Machek
2007-03-10 9:01 ` Ingo Molnar
2007-03-10 11:43 ` Stefan Seyfried
2007-03-10 13:53 ` Johannes Stezenbach
2007-03-10 15:18 ` Ingo Molnar
2007-03-10 22:08 ` Pavel Machek
2007-03-11 8:20 ` Ingo Molnar
2007-03-12 6:34 ` Stefan Seyfried
2007-03-10 22:04 ` s2ram (was Re: [2/6] 2.6.21-rc2: known regressions) Pavel Machek
2007-03-08 19:46 ` [2/6] 2.6.21-rc2: known regressions Michael S. Tsirkin
2007-03-08 19:57 ` Michael S. Tsirkin
[not found] ` <20070311120802.GA8823@elte.hu>
2007-03-12 20:20 ` Michael S. Tsirkin
2007-03-17 21:41 ` Michael S. Tsirkin
2007-03-17 22:33 ` Thomas Gleixner
2007-03-21 17:28 ` Michael S. Tsirkin
2007-03-05 1:50 ` [3/6] " Adrian Bunk
2007-03-05 3:58 ` Michal Jaegermann
2007-03-06 17:08 ` Alan Cox
2007-03-07 11:12 ` Jeff Garzik
2007-03-10 1:09 ` Mathieu Bérard
2007-03-10 4:11 ` and try remove another quirk on this computers " Sergio Monteiro Basto
2007-03-10 5:41 ` Linus Torvalds
2007-03-11 4:32 ` Sergio Monteiro Basto
2007-03-12 11:37 ` Tejun Heo
2007-03-13 12:31 ` Mathieu Bérard
2007-03-13 12:41 ` Tejun Heo
2007-03-13 20:56 ` Mathieu Bérard
2007-03-14 6:07 ` Tejun Heo
2007-03-14 10:49 ` Mathieu Bérard
2007-03-05 1:50 ` [4/6] " Adrian Bunk
2007-03-05 10:35 ` Antonino A. Daplas
2007-03-05 15:06 ` Andrew
2007-03-08 23:28 ` Len Brown
2007-03-09 19:25 ` Andrew
2007-03-05 12:21 ` Richard Purdie
2007-03-05 1:50 ` [5/6] " Adrian Bunk
2007-03-05 7:57 ` Ingo Molnar
2007-03-05 8:13 ` Andrew Morton
2007-03-05 15:25 ` Daniel Walker
2007-03-05 15:27 ` Ingo Molnar
2007-03-05 16:42 ` Daniel Walker
2007-03-05 19:30 ` Ingo Molnar
2007-03-05 16:14 ` Bill Davidsen
2007-03-05 16:21 ` Ingo Molnar
2007-03-05 23:12 ` Adrian Bunk
2007-03-05 23:43 ` Thomas Gleixner
2007-03-05 23:45 ` Linus Torvalds
2007-03-06 0:25 ` Thomas Gleixner
2007-03-06 6:49 ` Soeren Sonnenburg
2007-03-06 7:49 ` Soeren Sonnenburg
2007-03-06 0:38 ` Linus Torvalds
2007-03-06 1:02 ` Thomas Gleixner
2007-03-06 1:31 ` Linus Torvalds
2007-03-06 2:18 ` Linus Torvalds
2007-03-06 7:25 ` Ingo Molnar
2007-03-06 8:09 ` Thomas Gleixner
2007-03-06 10:33 ` Michael S. Tsirkin
2007-03-06 10:37 ` Ingo Molnar
2007-03-06 10:46 ` Michael S. Tsirkin
2007-03-06 11:32 ` Ingo Molnar
2007-03-06 12:20 ` Michael S. Tsirkin
2007-03-06 16:44 ` Linus Torvalds
2007-03-06 17:05 ` Ingo Molnar
2007-03-06 17:29 ` [PATCH] highres: do not run the TIMER_SOFTIRQ after switching to highres mode Thomas Gleixner
2007-03-06 17:41 ` Linus Torvalds
2007-03-16 15:18 ` [5/6] 2.6.21-rc2: known regressions Randy Dunlap
2007-03-06 11:36 ` Soeren Sonnenburg
2007-03-06 12:07 ` Ingo Molnar
2007-03-06 12:15 ` Michael S. Tsirkin
2007-03-06 12:51 ` Ingo Molnar
2007-03-06 12:55 ` Michael S. Tsirkin
2007-03-06 13:03 ` Ingo Molnar
2007-03-06 13:09 ` Thomas Gleixner
2007-03-06 12:09 ` Jeff Chua
2007-03-11 17:32 ` Pavel Machek
2007-03-06 10:33 ` Michael S. Tsirkin
2007-03-05 1:50 ` [6/6] " Adrian Bunk
2007-03-05 2:07 ` David Miller
2007-03-05 2:26 ` Adrian Bunk
2007-03-05 2:29 ` David Miller
2007-03-05 4:42 ` David Miller
2007-03-05 3:32 ` Greg KH
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=45EC2851.7020905@rtr.ca \
--to=lkml@rtr.ca \
--cc=akpm@linux-foundation.org \
--cc=bunk@stusta.de \
--cc=drzeus-list@drzeus.cx \
--cc=linux-kernel@vger.kernel.org \
--cc=sdhci-devel@list.drzeus.cx \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox