2008/3/12, Zdenek Kabelac <[EMAIL PROTECTED]>: > 2008/3/12, Andi Kleen <[EMAIL PROTECTED]>: > > > > Argh - being stupid here - it looks like these 'working' kernels were > > > not SMP actually. > > > As long as the SMP is used - I still get the busy loop :( > > > Now being clueless.... > > > > > > Sorry don't have the cycles to look into your problem, but the > > standard procedure for hard problems that can be reproduced > > is to git bisect them down to the change set that introduced the > > problem originally and then complain to whoever authored that. > > > The problem is - I don't know about any working SMP kernel which would > survive this test - thought haven't got into a really big history - > tried something like 2.6.22 kernels - no luck - also many kernel seems > to be unbootable in SMP mode on my machine giving many oopses - in > fact just 2.6.24 series starts to be at least reliable in booting in > my Qemu setup without failing during disk mounting or in some other > place... > > Will try to find probably some 2.6.18 kernel and will check what happens. > > On the other hand - I've tried to replicate my bug on few other > machines with no luck actually - so it's something which might not be > easy to trace :( >
Btw - just for testing purposes - I've taken current fedora rawhide kernel. Started machine with this kernel and installed it into qemu guest as well. And this is what I get when running in SMP mode: BUG: soft lockup - CPU#1 stuck for 61s! [udevd:583] CPU 1: Modules linked in: floppy ata_piix ata_generic pata_acpi pcnet32 mii libata scsi_m od Pid: 583, comm: udevd Not tainted 2.6.25-0.105.rc5.fc9 #1 RIP: 0010:[<ffffffff8113b907>] [<ffffffff8113b907>] clear_page_c+0x7/0x10 RSP: 0000:ffff810015455b20 EFLAGS: 00010246 RAX: 0000000000000000 RBX: ffff810015455be8 RCX: 0000000000000200 RDX: 00000000000006a0 RSI: ffff810015455a74 RDI: ffff810015001000 RBP: ffff810000000000 R08: 0000000015562000 R09: ffff810000000000 R10: 0000000000000292 R11: 0000000000000001 R12: 00003ffffffff000 R13: ffff810000009540 R14: ffff810015454000 R15: 0000000000000001 FS: 0000000000000000(0000) GS:ffff810017509320(0063) knlGS:00000000f7f1d720 CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b CR2: ffff810015001000 CR3: 00000000159e9000 CR4: 00000000000006a0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400 Call Trace: [<ffffffff810833ac>] ? get_page_from_freelist+0x51f/0x6b6 [<ffffffff810838ae>] ? __alloc_pages+0xed/0x3c3 [<ffffffff8109d5d8>] ? alloc_pages_current+0x100/0x109 [<ffffffff81082e4e>] ? __get_free_pages+0xe/0x4d [<ffffffff810f0d4b>] ? show_stat+0x2a/0x4af [<ffffffff810838ae>] ? __alloc_pages+0xed/0x3c3 [<ffffffff8109d5d8>] ? alloc_pages_current+0x100/0x109 [<ffffffff81082e4e>] ? __get_free_pages+0xe/0x4d [<ffffffff810a621d>] ? __kmalloc+0x3e/0xf0 [<ffffffff810c555f>] ? seq_read+0x143/0x2a2 [<ffffffff810c5532>] ? seq_read+0x116/0x2a2 [<ffffffff810c541c>] ? seq_read+0x0/0x2a2 [<ffffffff810c541c>] ? seq_read+0x0/0x2a2 [<ffffffff810e9df5>] ? proc_reg_read+0x8a/0xa7 [<ffffffff810ab489>] ? vfs_read+0xab/0x154 [<ffffffff810ab5f6>] ? sys_read+0x47/0x70 [<ffffffff81023f32>] ? ia32_sysret+0x0/0xa (Full trace attached) So I guess I'm kind of lucky that my own kernels actually boot in smp mode properly. Guest was started with 384MB - host has 2GB - around 1GB was free when started. Kernel boots with nosmp flag. Zdenek
qemu-debian.tty
Description: Binary data
------------------------------------------------------------------------- This SF.net email is sponsored by: Microsoft Defy all challenges. Microsoft(R) Visual Studio 2008. http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________ kvm-devel mailing list kvm-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/kvm-devel
