Bastian Blank wrote: > Control: tag -1 moreinfo > > On Sun, Dec 29, 2013 at 09:12:35PM +0000, halfdog wrote: >> When executing code in virtual-8086 mode via vm86 syscall, kernel >> seems to perform incomplete CPU state sanitation when switching tasks, >> thus causing OOPSes or complete machine lockup. > > You only showed exceptions while running within VirtualBox. Please also > show some while running on real hardware.
Because I did not care to copy the OOPSes from the initrd via USB to crypto-disks since most of them were triggered in already well-known fault location, also primary problem at emms instruction (math_state_restore+0x3e/0x140 is a much easier target to hit). I'll try to capture on real hardware when hardware is idle again. [ 4194.121492] fpu exception: 0000 [#1] [ 4194.123114] Modules linked in: nfnetlink_log nfnetlink xt_multiport xt_hashlimit xt_tcpudp ipt_ULOG xt_LOG xt_conntrack iptable_raw iptable_nat nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack iptable_mangle iptable_filter ip_tables x_tables snd_pcm snd_page_alloc snd_timer snd parport_pc soundcore microcode psmouse serio_raw pcspkr evdev parport ac battery button i2c_piix4 i2c_core ext4 crc16 mbcache jbd2 sg sr_mod sd_mod cdrom crc_t10dif ata_generic ata_piix mptspi scsi_transport_spi mptscsih libata mptbase pcnet32 mii scsi_mod [ 4194.123114] CPU: 0 PID: 2326 Comm: Virtual86Random Not tainted 3.11-2-486 #1 Debian 3.11.10-1 [ 4194.123114] Hardware name: innotek GmbH VirtualBox/VirtualBox, BIOS VirtualBox 12/01/2006 [ 4194.123114] task: cf439400 ti: ccfd6000 task.ti: ccfd6000 [ 4194.123114] EIP: 0060:[<c100230e>] EFLAGS: 00010002 CPU: 0 [ 4194.123114] EIP is at math_state_restore+0x3e/0x140 [ 4194.123114] EAX: 8005003b EBX: cf439400 ECX: 0000007b EDX: ffffffff [ 4194.123114] ESI: 00000000 EDI: c1399bb0 EBP: 00000400 ESP: ccfd7eb4 [ 4194.123114] DS: 007b ES: 007b FS: 0000 GS: 00e0 SS: 0068 [ 4194.123114] CR0: 80050033 CR2: 00000000 CR3: 0da55000 CR4: 00000690 [ 4194.123114] Stack: [ 4194.123114] ccfd7ed0 c1399bb0 c1399c05 c1023f17 ccfd7ef8 00000000 c1399585 00000000 [ 4194.123114] 0000ffff 00000000 00000000 0000be77 00000400 00000000 00000000 00000000 [ 4194.123114] 00000000 00000000 ffffffff 0000ee89 00001000 00030202 000003f8 00001000 [ 4194.123114] Call Trace: [ 4194.123114] [<c1399bb0>] ? do_debug+0x160/0x160 [ 4194.123114] [<c1399c05>] ? do_device_not_available+0x55/0x70 [ 4194.123114] [<c1023f17>] ? SYSC_vm86+0x97/0x280 [ 4194.123114] [<c1399585>] ? error_code+0x65/0x70 [ 4194.123114] [<c10243ed>] ? SyS_vm86+0xd/0x10 [ 4194.123114] [<c1398fef>] ? syscall_call+0x7/0xb [ 4194.123114] Code: 00 89 d8 e8 15 62 00 00 85 c0 0f 85 95 00 00 00 fa 90 8d 74 26 00 e9 50 00 00 00 c7 83 4c 02 00 00 01 00 00 00 89 1d 74 cd 4d c1 <0f> 77 db 83 4c 02 00 00 89 f6 eb 3e b8 ff ff ff ff 8b bb 50 02 [ 4194.123114] EIP: [<c100230e>] math_state_restore+0x3e/0x140 SS:ESP 0068:ccfd7eb4 >> See [1] for reproducers. Vrtual86SwitchToEmmsFault.c locks up >> reproducible when run in one VirtualBox guest, but fails to do so on >> real hardware. The random code tool Virtual86RandomCode.c might yield >> better results on those machines. > > So it does _not_ fail on real hardware. Why do you think this is a > kernel bug then? The specific test does not kill the idle task on real hardware but faults in a different way (math_state_restore). Perhaps memory layout is somehow relevant. Did you try the random code test? Perhaps the fault is specific to AMD-processors? You can use 'Virtual86RandomCode < /dev/urandom > /dev/null', on this hardware it took just some ms to trigger first faults. -- http://www.halfdog.net/ PGP: 156A AE98 B91F 0114 FE88 2BD8 C459 9386 feed a bee -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
