On Fri, May 23, 2008 at 12:43 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > Hi, > > I am trying to broadcast an NMI like this: > > send_IPI_allbutself(NMI_VECTOR); > > But when I do this, I get a divide error: > > ... > CPU: L1 I cache: 8K > CPU: L2 cache: 128K > CPU1: Intel Pentium II (Klamath) stepping 03 > checking TSC synchronization [CPU#0 -> CPU#1]: passed. > Brought up 2 CPUs > Total of 2 processors activated (4515.61 BogoMIPS). > divide error: 0000 [#1] SMP > Modules linked in: > > Pid: 0, comm: swapper Not tainted (2.6.26-rc3-00020-g72fdb21-dirty #134) > EIP: 0060:[<c012b813>] EFLAGS: 00000206 CPU: 1 > EIP is at __do_softirq+0x63/0xf0 > EAX: c06b9480 EBX: 00000002 ECX: c1132600 EDX: 00a79000 > ESI: c065fb00 EDI: c06b9480 EBP: c7859f14 ESP: c7859efc > DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 > Process swapper (pid: 0, ti=c7858000 task=c783db80 task.ti=c7858000) > Stack: 0000000a 00000001 c06b6260 00000046 00000000 c06b9480 c7859f20 c012b8db > c112e140 c7859f28 c012bc5c c7859f40 c01153fb 00000000 2bdef2bc c0102c00 > 00000001 c7859f80 c0104b64 c0102c00 c06b9480 00a79000 00000001 c06b9480 > Call Trace: > [<c012b8db>] ? do_softirq+0x3b/0x50 > [<c012bc5c>] ? irq_exit+0x5c/0x70 > [<c01153fb>] ? smp_apic_timer_interrupt+0x5b/0x90 > [<c0102c00>] ? default_idle+0x0/0x50 > [<c0104b64>] ? apic_timer_interrupt+0x28/0x30 > [<c0102c00>] ? default_idle+0x0/0x50 > [<c0102c38>] ? default_idle+0x38/0x50 > [<c0102b1b>] ? cpu_idle+0x5b/0xc0 > [<c04b5894>] ? start_secondary+0x134/0x190 > ======================= > Code: c0 89 45 ec c7 45 e8 0a 00 00 00 89 55 f0 64 8b 15 04 20 6b c0 > 8b 14 95 00 82 66 c0 89 f8 c7 04 02 00 00 00 00 fb be 00 fb 65 c0 <eb> > 07 d1 eb 74 27 83 c6 08 f6 c3 01 74 f4 89 f0 ff 16 8b 55 ec > EIP: [<c012b813>] __do_softirq+0x63/0xf0 SS:ESP 0068:c7859efc > > And this doesn't really make sense, because the opcode is a jmp > instruction and can't cause divide errors: > > c012b813: eb 07 jmp c012b81c <__do_softirq+0x6c> > > > NMI_VECTOR is 2, and the divide error vector is 0, according to the > Intel manuals. > > Any ideas what's going wrong? Ok, seems to be qemu doing something wrong (again...). It worked fine on my real hardware. Vegard -- "The animistic metaphor of the bug that maliciously sneaked in while the programmer was not looking is intellectually dishonest as it disguises that the error is the programmer's own creation." -- E. W. Dijkstra, EWD1036 -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ