x86 multi-core with O3 and the classic memory system doesn't work, as the classic caches don't have support for x86 locked accesses. In contrast, x86 multi-core works with O3 and Ruby, since Ruby does support locked accesses; and it also works with the AtomicSimple CPU model and classic memory, since in that case the locked accesses are handled by the AtomicSimple CPU model.
x86 single-core typically does work with the classic memory system. As I'm writing this, I'm wondering whether it's possible to have a problem with taking an interrupt in the middle of a locked RMW on a single core system... I would think not, since the interrupt should only be taken at a macro-instruction boundary, but there could be something subtle like that. Or maybe it's not related to locked accesses at all; I just bring that up since it's one thing that's known not to work in your configuration. Steve On Sat, Jun 28, 2014 at 8:07 PM, Ivan Stalev <[email protected]> wrote: > I am simulating a multi-core system, but the issue also occurs with > single-core as well. The error message comes from the kernel. Here is one > of them below: > > Thanks, > > Ivan > > Bad page state in process 'spec.astar_base' > page:ffffffff807205e8 flags:0x0000000000000000 mapping:000000baffffffff > mapcount:1 count:0 > Trying to fix it up, but a reboot is needed > Backtrace: > > Call Trace: > [<ffffffff8025d36d>] bad_page+0x5d/0x90 > [<ffffffff8025dddb>] get_page_from_freelist+0x42b/0x440 > [<ffffffff8025de81>] __alloc_pages+0x91/0x350 > [<ffffffff80270a24>] anon_vma_prepare+0x24/0x110 > [<ffffffff802681a3>] __handle_mm_fault+0x9d3/0xcd0 > [<ffffffff8026c4ce>] vma_adjust+0x13e/0x500 > [<ffffffff805be88f>] do_page_fault+0x1af/0x900 > [<ffffffff8026cf04>] vma_merge+0x1c4/0x2a0 > [<ffffffff805b9c84>] schedule+0x134/0x35a > [<ffffffff8026d32a>] do_brk+0x1aa/0x380 > [<ffffffff805bcbbd>] error_exit+0x0/0x84 > > Unable to handle kernel paging request at 49485c48fc01b000 RIP: > [<ffffffff8037b1d2>] clear_page+0x12/0x40 > PGD 0 > Oops: 0002 [1] SMP > CPU 2 > Modules linked in: > Pid: 849, comm: spec.astar_base Tainted: G B 2.6.22 #1 > RIP: 0010:[<ffffffff8037b1d2>] [<ffffffff8037b1d2>] clear_page+0x12/0x40 > RSP: 0000:ffff81013edc3c50 EFLAGS: 0000023c > RAX: 0000000000000000 RBX: 0000000000000000 RCX: 000000000000003f > RDX: 00000000ffffffff RSI: 0000000000000000 RDI: 49485c48fc01b000 > RBP: 0000000000000001 R08: 0000000000000005 R09: 0000000000000000 > R10: 0000000000000000 R11: 0000000000000000 R12: ffffffff807205e8 > R13: ffffffff807205e8 R14: ffff810000000000 R15: 6db6db6db6db6db7 > FS: 00000000006b5860(0063) GS:ffff81013fc65cc0(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 000000008005003b > CR2: 49485c48fc01b000 CR3: 000000013ed27000 CR4: 00000000000006e0 > Process spec.astar_base (pid: 849, threadinfo ffff81013edc2000, task > ffff81013f294ae0) > Stack: ffffffff8025dc26 ffffffff80720d58 0000000000000000 000000000000026c > 0000000000000002 ffffffff807dd820 00000000000280d2 0000000000000001 > ffffffff80720a00 ffffffff80720d58 0000000100000000 0000000000000044 > Call Trace: > [<ffffffff8025dc26>] get_page_from_freelist+0x276/0x440 > [<ffffffff8025de81>] __alloc_pages+0x91/0x350 > [<ffffffff80270a24>] anon_vma_prepare+0x24/0x110 > [<ffffffff802681a3>] __handle_mm_fault+0x9d3/0xcd0 > [<ffffffff8026c4ce>] vma_adjust+0x13e/0x500 > [<ffffffff805be88f>] do_page_fault+0x1af/0x900 > [<ffffffff8026cf04>] vma_merge+0x1c4/0x2a0 > [<ffffffff805b9c84>] schedule+0x134/0x35a > [<ffffffff8026d32a>] do_brk+0x1aa/0x380 > [<ffffffff805bcbbd>] error_exit+0x0/0x84 > > > Code: 48 89 07 48 89 47 08 48 89 47 10 48 89 47 18 48 89 47 20 48 > RIP [<ffffffff8037b1d2>] clear_page+0x12/0x40 > RSP <ffff81013edc3c50> > CR2: 49485c48fc01b000 > note: spec.astar_base[849] exited with preempt_count 1 > > > On Sat, Jun 28, 2014 at 10:34 PM, Steve Reinhardt <[email protected]> > wrote: > >> Sorry, we primarily use SE mode, so we don't have this problem. Is this >> for a single-core system? Is the error message you see from the kernel or >> from gem5? >> >> Steve >> >> >> On Sat, Jun 28, 2014 at 6:51 PM, Ivan Stalev via gem5-users < >> [email protected]> wrote: >> >>> Is anyone successfully running SPEC2006 benchmarks using x86 full-system >>> with detailed CPUs and the classic memory model? I am able to run simple C >>> programs, but when I run any SPEC benchmark, I get a "Bad page state in >>> process" error for each SPEC benchmark and then the kernel crashes. I've >>> tried a few different kernels and disk images, including the ones on the >>> GEM5 website and building my own. I've also tried different GEM5 versions. >>> Everything runs fine with atomic CPUs. A few of my labmates are also >>> experiencing the same issue. >>> >>> Can you please share if you have been successful with this setup? >>> >>> Thanks, >>> >>> Ivan >>> >>> _______________________________________________ >>> gem5-users mailing list >>> [email protected] >>> http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users >>> >> >> >
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
