Pierre Riteau wrote: > On 5 févr. 2010, at 16:07, Jan Kiszka wrote: > >> Pierre Riteau wrote: >>> On 5 févr. 2010, at 15:46, Jan Kiszka wrote: >>> >>>> Pierre Riteau wrote: >>>>> On 4 févr. 2010, at 15:34, Pierre Riteau wrote: >>>>> >>>>>> Hello, >>>>>> I'm having trouble running the latest qemu-kvm code on Debian Lenny >>>>>> (Linux 2.6.26). >>>>>> qemu-kvm dies with an error like this one: >>>>>> exception 13 (0) >>>>>> rax 0000000000000010 rbx 0000000000008c00 rcx 0000000000006ebe rdx >>>>>> 00000000000c8c00 >>>>>> rsi 00000000e2010000 rdi 00000000000c0000 rsp 0000000000006eb4 rbp >>>>>> 00000000e2010000 >>>>>> r8 0000000000000000 r9 0000000000000000 r10 0000000000000000 r11 >>>>>> 0000000000000000 >>>>>> r12 0000000000000000 r13 0000000000000000 r14 0000000000000000 r15 >>>>>> 0000000000000000 >>>>>> rip 00000000000fdeb0 rflags 00033002 >>>>>> cs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> ds 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> es 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> ss 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> fs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> gs 0000 (00000000/0000ffff p 1 dpl 3 db 0 s 1 type 3 l 0 g 0 avl 0) >>>>>> tr 0000 (feffd000/00002088 p 1 dpl 0 db 0 s 0 type b l 0 g 0 avl 0) >>>>>> ldt 0000 (00000000/0000ffff p 1 dpl 0 db 0 s 0 type 2 l 0 g 0 avl 0) >>>>>> gdt f7a20/37 >>>>>> idt f8aa0/0 >>>>>> cr0 10 cr2 0 cr3 0 cr4 0 cr8 0 efer 0 >>>>>> code: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 --> 00 >>>>>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 >>>>>> 00 00 00 00 00 >>>>>> >>>>>> I think I traced back the issue to the switch from Bochs BIOS to >>>>>> Seabios. By forcing the usage of Bochs BIOS >>>>>> 5f08bb45861f54be478b25075b90d2406a0f8bb3 works, while it dies without >>>>>> the -bios override. >>>>>> Unfortunately, newer versions don't seem to work with Bochs BIOS. >>>>>> >>>>>> Upgrading the host kernel to 2.6.32 (Debian Squeeze) solves the issue. >>>>>> No problem on Fedora 12 as well. >>>>> Am I the only one to see this issue? >>>>> >>>> The oldest kernels I've running here are 2.6.27. They all run kvm-kmod, >>>> and they are all happy (mostly). >>>> >>>> Are you using the KVM support 2.6.26 provided or are you on some recent >>>> kvm-kmod? The latter is highly recommended for tons of reasons. >>>> >>>> Jan >>> >>> I use the KVM modules provided by the distribution. >>> >> Then it makes some sense to try with kvm-kmod first. I do not know what >> KVM patches debian people back-ported to their kernel, maybe you run >> into long-fixed bugs. > > > I confirm that this exception does not happen with kvm-kmod-2.6.33-rc6. > > However, after I run and stop a guest VM just executing the bios sequence (no > disk/CD image attached), I get this kind of errors on the host when untar a > small archive (less than 1MB, about 300 files): > > Feb 8 12:00:32 paraquad-7 kernel: [ 200.073865] Bad page state in process > 'gzip' > Feb 8 12:00:32 paraquad-7 kernel: [ 200.073867] page:ffffe200040c4638 > flags:0x020000000000001c mapping:0000000000000000 mapcount:0 count:0 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.102991] Trying to fix it up, but a > reboot is needed > Feb 8 12:00:32 paraquad-7 kernel: [ 200.102992] Backtrace: > Feb 8 12:00:32 paraquad-7 kernel: [ 200.129821] Pid: 3559, comm: gzip > Tainted: P 2.6.26-2-amd64 #1 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.143267] > Feb 8 12:00:32 paraquad-7 kernel: [ 200.143268] Call Trace: > Feb 8 12:00:32 paraquad-7 kernel: [ 200.156024] [<ffffffff8022f0d2>] > hrtick_set+0x88/0xf7 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.167250] [<ffffffff8027504d>] > bad_page+0x6b/0x95 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.179879] [<ffffffff80276482>] > get_page_from_freelist+0x3e1/0x606 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.195345] [<ffffffff80276929>] > __alloc_pages_internal+0xd6/0x3bf > Feb 8 12:00:32 paraquad-7 kernel: [ 200.210580] [<ffffffff80281707>] > handle_mm_fault+0x244/0x867 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.223694] [<ffffffff8027313a>] > filemap_fault+0x1c2/0x33c > Feb 8 12:00:32 paraquad-7 kernel: [ 200.237948] [<ffffffff80221fbc>] > do_page_fault+0x5d8/0x9c8 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.251793] [<ffffffff8042a599>] > error_exit+0x0/0x60 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.265754] [<ffffffff80270df1>] > file_read_actor+0x52/0x125 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.278595] [<ffffffff802764fb>] > get_page_from_freelist+0x45a/0x606 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.294022] [<ffffffff80272c03>] > generic_file_aio_read+0x29e/0x4ae > Feb 8 12:00:32 paraquad-7 kernel: [ 200.309319] [<ffffffff8029ae47>] > do_sync_read+0xc9/0x10c > Feb 8 12:00:32 paraquad-7 kernel: [ 200.322816] [<ffffffff80246221>] > autoremove_wake_function+0x0/0x2e > Feb 8 12:00:32 paraquad-7 kernel: [ 200.338051] [<ffffffff80221fbc>] > do_page_fault+0x5d8/0x9c8 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.351919] [<ffffffff8029b638>] > vfs_read+0xaa/0x152 > Feb 8 12:00:32 paraquad-7 kernel: [ 200.366108] [<ffffffff8029ba19>] > sys_read+0x45/0x6e > Feb 8 12:00:32 paraquad-7 kernel: [ 200.378750] [<ffffffff8020beca>] > system_call_after_swapgs+0x8a/0x8f >
Haven't seen this before. Can you reproduce it with a) kvm-kmod-2.6.32.7? b) a host kernel >= 2.6.27? Thanks, Jan -- Siemens AG, Corporate Technology, CT T DE IT 1 Corporate Competence Center Embedded Linux -- To unsubscribe from this list: send the line "unsubscribe kvm" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
