* BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 @ 2008-06-03 8:42 Zdenek Kabelac 2008-06-03 11:51 ` Jiri Kosina 0 siblings, 1 reply; 9+ messages in thread From: Zdenek Kabelac @ 2008-06-03 8:42 UTC (permalink / raw) To: Linux Kernel Mailing List Hello Another backtrace from suspend code path: (T61, 2GB, C2D, no SD card) kernel from git 20080603, commit 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 ---- agpgart-intel 0000:00:00.0: LATE suspend platform bay.0: LATE suspend platform dock.0: LATE suspend Extended CMOS year: 2000 hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] Back to C! BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 caller is do_machine_check+0xa9/0x500 Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 Call Trace: [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 [<ffffffff810184d9>] do_machine_check+0xa9/0x500 [<ffffffff81010e7b>] ? init_8259A+0x1b/0x120 [<ffffffff810189d6>] mce_init+0x56/0xf0 [<ffffffff81018a7b>] mce_resume+0xb/0x10 [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 [<ffffffff81205068>] sysdev_resume+0x58/0x90 [<ffffffff8120aac9>] device_power_up+0x9/0x10 [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 [<ffffffff8106f80a>] state_store+0xba/0x100 [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 [<ffffffff810ba00b>] vfs_write+0xcb/0x190 [<ffffffff810ba1c0>] sys_write+0x50/0x90 [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 Extended CMOS year: 2000 BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 caller is retrigger_next_event+0x1c/0x100 Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 Call Trace: [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 [<ffffffff81055d3c>] retrigger_next_event+0x1c/0x100 [<ffffffff812f5710>] ? _spin_unlock+0x30/0x60 [<ffffffff810565ae>] hres_timers_resume+0x1e/0x50 [<ffffffff81059657>] timekeeping_resume+0x137/0x170 [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 [<ffffffff81205068>] sysdev_resume+0x58/0x90 [<ffffffff8120aac9>] device_power_up+0x9/0x10 [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 [<ffffffff8106f80a>] state_store+0xba/0x100 [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 [<ffffffff810ba00b>] vfs_write+0xcb/0x190 [<ffffffff810ba1c0>] sys_write+0x50/0x90 [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 caller is retrigger_next_event+0x8b/0x100 Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 Call Trace: [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 [<ffffffff81055dab>] retrigger_next_event+0x8b/0x100 [<ffffffff810565ae>] hres_timers_resume+0x1e/0x50 [<ffffffff81059657>] timekeeping_resume+0x137/0x170 [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 [<ffffffff81205068>] sysdev_resume+0x58/0x90 [<ffffffff8120aac9>] device_power_up+0x9/0x10 [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 [<ffffffff8106f80a>] state_store+0xba/0x100 [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 [<ffffffff810ba00b>] vfs_write+0xcb/0x190 [<ffffffff810ba1c0>] sys_write+0x50/0x90 [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 platform dock.0: EARLY resume platform bay.0: EARLY resume agpgart-intel 0000:00:00.0: EARLY resume pci 0000:00:02.0: EARLY resume pci 0000:00:02.1: EARLY resume e1000e 0000:00:19.0: EARLY resume ---- Zdenek ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-03 8:42 BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 Zdenek Kabelac @ 2008-06-03 11:51 ` Jiri Kosina [not found] ` <c4e36d110806030501g46363beev7126c8312aadd12e@mail.gmail.com> 0 siblings, 1 reply; 9+ messages in thread From: Jiri Kosina @ 2008-06-03 11:51 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: Linux Kernel Mailing List On Tue, 3 Jun 2008, Zdenek Kabelac wrote: > Another backtrace from suspend code path: > (T61, 2GB, C2D, no SD card) > kernel from git 20080603, commit 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 > ---- > agpgart-intel 0000:00:00.0: LATE suspend > platform bay.0: LATE suspend > platform dock.0: LATE suspend > Extended CMOS year: 2000 > hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] > Back to C! > BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 > caller is do_machine_check+0xa9/0x500 > Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 > Call Trace: > [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 > [<ffffffff810184d9>] do_machine_check+0xa9/0x500 > [<ffffffff81010e7b>] ? init_8259A+0x1b/0x120 > [<ffffffff810189d6>] mce_init+0x56/0xf0 > [<ffffffff81018a7b>] mce_resume+0xb/0x10 > [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 > [<ffffffff81205068>] sysdev_resume+0x58/0x90 > [<ffffffff8120aac9>] device_power_up+0x9/0x10 > [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 > [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 > [<ffffffff8106f80a>] state_store+0xba/0x100 > [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 > [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 > [<ffffffff810ba00b>] vfs_write+0xcb/0x190 > [<ffffffff810ba1c0>] sys_write+0x50/0x90 > [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 This looks very much like the oops you reported here: http://lkml.org/lkml/2008/4/7/130 Is this also a virtual machine run under KVM, as it has been in the aforementioned thread? Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
[parent not found: <c4e36d110806030501g46363beev7126c8312aadd12e@mail.gmail.com>]
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 [not found] ` <c4e36d110806030501g46363beev7126c8312aadd12e@mail.gmail.com> @ 2008-06-03 12:05 ` Jiri Kosina 2008-06-04 9:41 ` Avi Kivity 2008-06-04 10:54 ` Thomas Gleixner 0 siblings, 2 replies; 9+ messages in thread From: Jiri Kosina @ 2008-06-03 12:05 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: linux-kernel, kvm, avi [ re-introduced LKML to CC, and also added KVM CCs] On Tue, 3 Jun 2008, Zdenek Kabelac wrote: > 2008/6/3 Jiri Kosina <jkosina@suse.cz>: > > On Tue, 3 Jun 2008, Zdenek Kabelac wrote: > > > >> Another backtrace from suspend code path: > >> (T61, 2GB, C2D, no SD card) > >> kernel from git 20080603, commit 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 > >> ---- > >> agpgart-intel 0000:00:00.0: LATE suspend > >> platform bay.0: LATE suspend > >> platform dock.0: LATE suspend > >> Extended CMOS year: 2000 > >> hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] > >> Back to C! > >> BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 > >> caller is do_machine_check+0xa9/0x500 > >> Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 > >> Call Trace: > >> [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 > >> [<ffffffff810184d9>] do_machine_check+0xa9/0x500 > >> [<ffffffff81010e7b>] ? init_8259A+0x1b/0x120 > >> [<ffffffff810189d6>] mce_init+0x56/0xf0 > >> [<ffffffff81018a7b>] mce_resume+0xb/0x10 > >> [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 > >> [<ffffffff81205068>] sysdev_resume+0x58/0x90 > >> [<ffffffff8120aac9>] device_power_up+0x9/0x10 > >> [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 > >> [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 > >> [<ffffffff8106f80a>] state_store+0xba/0x100 > >> [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 > >> [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 > >> [<ffffffff810ba00b>] vfs_write+0xcb/0x190 > >> [<ffffffff810ba1c0>] sys_write+0x50/0x90 > >> [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 > > > > This looks very much like the oops you reported here: > > http://lkml.org/lkml/2008/4/7/130 > > > > Is this also a virtual machine run under KVM, as it has been in the > > aforementioned thread? > > > Ahh yes - you are right , I've completely forget about that old post - > I've thought that my post are usually getting fixed sooner :) > So yes - this is actually the same bug which is still not fixed within > the latest kernel - the machine is running qemu guest (which seems to > me now somehow also slower) OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the resume path. The original bug-report is on http://lkml.org/lkml/2008/4/7/130 -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-03 12:05 ` Jiri Kosina @ 2008-06-04 9:41 ` Avi Kivity 2008-06-04 9:57 ` Zdenek Kabelac 2008-06-04 10:54 ` Thomas Gleixner 1 sibling, 1 reply; 9+ messages in thread From: Avi Kivity @ 2008-06-04 9:41 UTC (permalink / raw) To: Jiri Kosina; +Cc: Zdenek Kabelac, linux-kernel, kvm Jiri Kosina wrote: > [ re-introduced LKML to CC, and also added KVM CCs] > > On Tue, 3 Jun 2008, Zdenek Kabelac wrote: > > >> 2008/6/3 Jiri Kosina <jkosina@suse.cz>: >> >>> On Tue, 3 Jun 2008, Zdenek Kabelac wrote: >>> >>> >>>> Another backtrace from suspend code path: >>>> (T61, 2GB, C2D, no SD card) >>>> kernel from git 20080603, commit 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 >>>> ---- >>>> agpgart-intel 0000:00:00.0: LATE suspend >>>> platform bay.0: LATE suspend >>>> platform dock.0: LATE suspend >>>> Extended CMOS year: 2000 >>>> hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] >>>> Back to C! >>>> BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 >>>> caller is do_machine_check+0xa9/0x500 >>>> Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 >>>> Call Trace: >>>> [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 >>>> [<ffffffff810184d9>] do_machine_check+0xa9/0x500 >>>> [<ffffffff81010e7b>] ? init_8259A+0x1b/0x120 >>>> [<ffffffff810189d6>] mce_init+0x56/0xf0 >>>> [<ffffffff81018a7b>] mce_resume+0xb/0x10 >>>> [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 >>>> [<ffffffff81205068>] sysdev_resume+0x58/0x90 >>>> [<ffffffff8120aac9>] device_power_up+0x9/0x10 >>>> [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 >>>> [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 >>>> [<ffffffff8106f80a>] state_store+0xba/0x100 >>>> [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 >>>> [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 >>>> [<ffffffff810ba00b>] vfs_write+0xcb/0x190 >>>> [<ffffffff810ba1c0>] sys_write+0x50/0x90 >>>> [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 >>>> >>> This looks very much like the oops you reported here: >>> http://lkml.org/lkml/2008/4/7/130 >>> >>> Is this also a virtual machine run under KVM, as it has been in the >>> aforementioned thread? >>> >> Ahh yes - you are right , I've completely forget about that old post - >> I've thought that my post are usually getting fixed sooner :) >> So yes - this is actually the same bug which is still not fixed within >> the latest kernel - the machine is running qemu guest (which seems to >> me now somehow also slower) >> > > OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the > resume path. The original bug-report is on > http://lkml.org/lkml/2008/4/7/130 > > Wait, is this in a virtual machine, or on a host that's also running a virtual machine (or has the kvm modules loaded)? I looked at the kvm host resume path, and it doesn't touch interrupts. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-04 9:41 ` Avi Kivity @ 2008-06-04 9:57 ` Zdenek Kabelac 2008-06-04 10:34 ` Avi Kivity 0 siblings, 1 reply; 9+ messages in thread From: Zdenek Kabelac @ 2008-06-04 9:57 UTC (permalink / raw) To: Avi Kivity; +Cc: Jiri Kosina, linux-kernel, kvm 2008/6/4 Avi Kivity <avi@qumranet.com>: > Jiri Kosina wrote: >> >> [ re-introduced LKML to CC, and also added KVM CCs] >> >> On Tue, 3 Jun 2008, Zdenek Kabelac wrote: >> >> >>> >>> 2008/6/3 Jiri Kosina <jkosina@suse.cz>: >>> >>>> >>>> On Tue, 3 Jun 2008, Zdenek Kabelac wrote: >>>> >>>> >>>>> >>>>> Another backtrace from suspend code path: >>>>> (T61, 2GB, C2D, no SD card) >>>>> kernel from git 20080603, commit >>>>> 1beee8dc8cf58e3f605bd7b34d7a39939be7d8d2 >>>>> ---- >>>>> agpgart-intel 0000:00:00.0: LATE suspend >>>>> platform bay.0: LATE suspend >>>>> platform dock.0: LATE suspend >>>>> Extended CMOS year: 2000 >>>>> hwsleep-0324 [00] enter_sleep_state : Entering sleep state [S3] >>>>> Back to C! >>>>> BUG: using smp_processor_id() in preemptible [00000000] code: >>>>> pm-suspend/17334 >>>>> caller is do_machine_check+0xa9/0x500 >>>>> Pid: 17334, comm: pm-suspend Not tainted 2.6.26-rc4 #31 >>>>> Call Trace: >>>>> [<ffffffff8118347c>] debug_smp_processor_id+0xcc/0xd0 >>>>> [<ffffffff810184d9>] do_machine_check+0xa9/0x500 >>>>> [<ffffffff81010e7b>] ? init_8259A+0x1b/0x120 >>>>> [<ffffffff810189d6>] mce_init+0x56/0xf0 >>>>> [<ffffffff81018a7b>] mce_resume+0xb/0x10 >>>>> [<ffffffff81204fd0>] __sysdev_resume+0x20/0x60 >>>>> [<ffffffff81205068>] sysdev_resume+0x58/0x90 >>>>> [<ffffffff8120aac9>] device_power_up+0x9/0x10 >>>>> [<ffffffff8106f4f7>] suspend_devices_and_enter+0x147/0x1a0 >>>>> [<ffffffff8106f6c6>] enter_state+0x146/0x1d0 >>>>> [<ffffffff8106f80a>] state_store+0xba/0x100 >>>>> [<ffffffff81177ae7>] kobj_attr_store+0x17/0x20 >>>>> [<ffffffff81110fea>] sysfs_write_file+0xca/0x140 >>>>> [<ffffffff810ba00b>] vfs_write+0xcb/0x190 >>>>> [<ffffffff810ba1c0>] sys_write+0x50/0x90 >>>>> [<ffffffff8100c4fb>] system_call_after_swapgs+0x7b/0x80 >>>>> >>>> >>>> This looks very much like the oops you reported here: >>>> http://lkml.org/lkml/2008/4/7/130 >>>> >>>> Is this also a virtual machine run under KVM, as it has been in the >>>> aforementioned thread? >>>> >>> >>> Ahh yes - you are right , I've completely forget about that old post - >>> I've thought that my post are usually getting fixed sooner :) >>> So yes - this is actually the same bug which is still not fixed within >>> the latest kernel - the machine is running qemu guest (which seems to >>> me now somehow also slower) >>> >> >> OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the >> resume path. The original bug-report is on http://lkml.org/lkml/2008/4/7/130 >> >> > > Wait, is this in a virtual machine, or on a host that's also running a > virtual machine (or has the kvm modules loaded)? > > I looked at the kvm host resume path, and it doesn't touch interrupts. Oops is from my real-hardware T61 (host) running the kvm-qemu (guest) and was noticed after suspend. But everything seemed to work just fine - host&guest continued to operate normally after resume. Zdenek ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-04 9:57 ` Zdenek Kabelac @ 2008-06-04 10:34 ` Avi Kivity 0 siblings, 0 replies; 9+ messages in thread From: Avi Kivity @ 2008-06-04 10:34 UTC (permalink / raw) To: Zdenek Kabelac; +Cc: Jiri Kosina, linux-kernel, kvm Zdenek Kabelac wrote: > Oops is from my real-hardware T61 (host) running the kvm-qemu (guest) > and was noticed after suspend. > But everything seemed to work just fine - host&guest continued to > operate normally after resume. > Can you reproduce this, with and without the kvm modules loaded? -- I have a truly marvellous patch that fixes the bug which this signature is too narrow to contain. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-03 12:05 ` Jiri Kosina 2008-06-04 9:41 ` Avi Kivity @ 2008-06-04 10:54 ` Thomas Gleixner 2008-06-04 11:13 ` Jiri Kosina 1 sibling, 1 reply; 9+ messages in thread From: Thomas Gleixner @ 2008-06-04 10:54 UTC (permalink / raw) To: Jiri Kosina; +Cc: Zdenek Kabelac, linux-kernel, kvm, avi On Tue, 3 Jun 2008, Jiri Kosina wrote: > > Ahh yes - you are right , I've completely forget about that old post - > > I've thought that my post are usually getting fixed sooner :) > > So yes - this is actually the same bug which is still not fixed within > > the latest kernel - the machine is running qemu guest (which seems to > > me now somehow also slower) > > OK, so it looks like KVM could be wrongly enabling IRQs/preemption on the > resume path. The original bug-report is on > http://lkml.org/lkml/2008/4/7/130 sysdev_resume() is supposed to run with interrupts disabled, at least it was that way when the timekeeping_resume code was written. Thanks, tglx ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-04 10:54 ` Thomas Gleixner @ 2008-06-04 11:13 ` Jiri Kosina 2008-06-04 11:16 ` Avi Kivity 0 siblings, 1 reply; 9+ messages in thread From: Jiri Kosina @ 2008-06-04 11:13 UTC (permalink / raw) To: Thomas Gleixner; +Cc: Zdenek Kabelac, linux-kernel, kvm, avi On Wed, 4 Jun 2008, Thomas Gleixner wrote: > > OK, so it looks like KVM could be wrongly enabling IRQs/preemption on > > the resume path. The original bug-report is on > > http://lkml.org/lkml/2008/4/7/130 > sysdev_resume() is supposed to run with interrupts disabled, at least > it was that way when the timekeeping_resume code was written. True. However in Zdenek's case, interrupts/preemption gets enabled somewhere during the resume, which correctly triggers the warning. Thanks, -- Jiri Kosina SUSE Labs ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 2008-06-04 11:13 ` Jiri Kosina @ 2008-06-04 11:16 ` Avi Kivity 0 siblings, 0 replies; 9+ messages in thread From: Avi Kivity @ 2008-06-04 11:16 UTC (permalink / raw) To: Jiri Kosina; +Cc: Thomas Gleixner, Zdenek Kabelac, linux-kernel, kvm Jiri Kosina wrote: > On Wed, 4 Jun 2008, Thomas Gleixner wrote: > > >>> OK, so it looks like KVM could be wrongly enabling IRQs/preemption on >>> the resume path. The original bug-report is on >>> http://lkml.org/lkml/2008/4/7/130 >>> >> sysdev_resume() is supposed to run with interrupts disabled, at least >> it was that way when the timekeeping_resume code was written. >> > > True. However in Zdenek's case, interrupts/preemption gets enabled > somewhere during the resume, which correctly triggers the warning. > > We might add a check to the generic resume controller, to check after each ->resume() method and warn in case of interrupts enabled. That will pinpoint the offending driver immediately. -- Do not meddle in the internals of kernels, for they are subtle and quick to panic. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2008-06-04 11:16 UTC | newest]
Thread overview: 9+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-06-03 8:42 BUG: using smp_processor_id() in preemptible [00000000] code: pm-suspend/17334 Zdenek Kabelac
2008-06-03 11:51 ` Jiri Kosina
[not found] ` <c4e36d110806030501g46363beev7126c8312aadd12e@mail.gmail.com>
2008-06-03 12:05 ` Jiri Kosina
2008-06-04 9:41 ` Avi Kivity
2008-06-04 9:57 ` Zdenek Kabelac
2008-06-04 10:34 ` Avi Kivity
2008-06-04 10:54 ` Thomas Gleixner
2008-06-04 11:13 ` Jiri Kosina
2008-06-04 11:16 ` Avi Kivity
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox