It is not spamming, it is education....thank for the info. BTW...I think u gave me an idea now...... Currently your kmemcheck is restricted to only one CPU. Why not ALWAYS enable all the CPU to run at the same time....BUT WHEN AND ONLY WHEN read operation is detected on one CPU.....immediately send an IPI to all other CPU to freeze their operation.....until the not present flag is turned off again.....so it solved your "very small window" of racing condition..... What do you think? On Fri, May 23, 2008 at 7:28 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: > On Fri, May 23, 2008 at 1:26 PM, Vegard Nossum <vegard.nossum@xxxxxxxxx> wrote: >> 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. > > Sorry for the spamming. I just wanted to say that it works in > qemu-0.9.1 as well, though not in qemu-0.9.0. > > > 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 > > -- Regards, Peter Teoh -- To unsubscribe from this list: send an email with "unsubscribe kernelnewbies" to ecartis@xxxxxxxxxxxx Please read the FAQ at http://kernelnewbies.org/FAQ
