On Wed, Oct 17, 2018 at 2:24 AM Gabe Black <[email protected]> wrote:
> Hi Vitorio. It looks like the kernel panicked and never finished booting. > You can exit m5term by typing ~. (tilda and then period), > OMG, this is amazing! > or you can use whatever telnet client/terminal emulator you're comfortable > with. > > Beware however that telnet has some quirks, e.g. arrows stop working, better stick to m5term. > Gabe > > On Tue, Oct 16, 2018, 3:41 PM Vitorio Cargnini (lcargnini) < > [email protected]> wrote: > >> Hello, >> >> >> >> I set a running simulation, with a SPEC benchmark. However this it is >> running for some days already. So I want to check if everything it is fine >> with the simulated system, if it is really running. >> >> >> >> The reason it is: >> >> I have my installation in /home/folder/folder. However I’m running from a >> different folder like >> /somewhere/folder/folder/folder_where_i_want_the_m5out_folder >> >> >> >> Looking inside this target location, stats.txt it is empty so far, there >> is also a file system.pc.com_1.terminal, and when I look in it I see in the >> end: >> >> … >> >> Mountpoint-cache hash table entries: 32768 (order: 6, 262144 bytes) >> >> CPU: CPU feature monitor disabled, no CPUID level 0x5 >> >> CPU: CPU feature xsave disabled, no CPUID level 0xd >> >> mce: CPU supports 4 MCE banks >> >> mce: unknown CPU type - not enabling MCE support >> >> Last level iTLB entries: 4KB 0, 2MB 0, 4MB 0 >> >> Last level dTLB entries: 4KB 0, 2MB 0, 4MB 0, 1GB 0 >> >> Freeing SMP alternatives memory: 24K (ffffffff8198e000 - ffffffff81994000) >> >> BUG: unable to handle kernel paging request at ffffffffcd82c740 >> >> IP: [<ffffffffcd82c771>] 0xffffffffcd82c771 >> >> PGD 1807067 PUD 1809067 PMD 0 >> >> Oops: 0010 [#1] SMP >> >> Modules linked in: >> >> CPU: 0 PID: 0 Comm: swapper/0 Not tainted 4.8.13 #1 >> >> Hardware name: , BIOS 06/08/2008 >> >> task: ffffffff8180b500 task.stack: ffffffff81800000 >> >> RIP: 0010:[<ffffffffcd82c771>] [<ffffffffcd82c771>] 0xffffffffcd82c771 >> >> RSP: 0000:ffffffff81803e30 EFLAGS: 00000028 >> >> RAX: 0000000000020f76 RBX: 0000000000000805 RCX: 0000000004000209 >> >> RDX: 00000000e7dbfbff RSI: ffffffff81803e59 RDI: 000000000000026c >> >> RBP: ffffffff81803e52 R08: ffffffff810145f3 R09: 000000000000026c >> >> R10: ffffffff81803e52 R11: ffffffff81803e52 R12: ffffffff819858bc >> >> R13: ffffffff8192c2e0 R14: ffffffff81995000 R15: 0000000000090200 >> >> FS: 0000000000000000(0000) GS:ffff88043fc00000(0000) >> knlGS:0000000000000000 >> >> CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 >> >> CR2: ffffffffcd82c740 CR3: 0000000001806000 CR4: 00000000000006b0 >> >> DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 >> >> DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000000 >> >> Stack: >> >> ffffffff810145fb 000000000000026c ffffffff8197b6a0 ffffffff81014a35 >> >> 669066669d570006 0000000000009090 ffffffff819dfbe2 000000000000004a >> >> ffffffff8106abcd 0000000000000000 0000000000000000 000000000000026c >> >> Call Trace: >> >> [<ffffffff810145fb>] ? text_poke_early+0x2c/0x30 >> >> [<ffffffff81014a35>] ? apply_paravirt.part.1+0x74/0x82 >> >> [<ffffffff8106abcd>] ? vprintk_emit+0x357/0x368 >> >> [<ffffffff810acaaf>] ? printk+0x43/0x4b >> >> [<ffffffff810b347c>] ? free_reserved_area+0x105/0x114 >> >> [<ffffffff818b57a1>] ? alternative_instructions+0xbf/0xcf >> >> [<ffffffff818b708e>] ? check_bugs+0xa/0x28 >> >> [<ffffffff818ace24>] ? start_kernel+0x412/0x424 >> >> [<ffffffff818ac120>] ? early_idt_handler_array+0x120/0x120 >> >> [<ffffffff818ac36c>] ? x86_64_start_kernel+0xe6/0xf5 >> >> Code: Bad RIP value. >> >> RIP [<ffffffffcd82c771>] 0xffffffffcd82c771 >> >> RSP <ffffffff81803e30> >> >> CR2: ffffffffcd82c740 >> >> ---[ end trace 0000000000000000 ]--- >> >> Kernel panic - not syncing: Attempted to kill the idle task! >> >> ---[ end Kernel panic - not syncing: Attempted to kill the idle task! >> >> random: fast init done >> >> >> > As Gabe said, kernel panic means the kernel completely shuts down, there is no way your simulation can be running after one. You can also have a look at the kernel source of the backtrace "text_poke_early", and see if it gives a clue to what happened. Sometimes it is easy, sometimes not. You can find the exact line with GDB post-mortem with GDB disassemble/rs https://stackoverflow.com/questions/22769246/how-to-disassemble-one-single-function-using-objdump/31138400#31138400 You can also try to connect through the GDB stub and step debug kernel code. >> >> So I’m not sure if it is working. Still, I tested the application before, >> and everything was working. However, I’m not so sure now, and I didn’t want >> to use m5term, because I don’t know how to kill it without killing the >> simulation and having to restart all over again. Since, this has being >> running for a few days already, and I’m collecting traces, and the trace >> file has increased over this entire time. >> >> >> > The contents of m5term also show at m5out/system.terminal on later parts of the boot. > Will wait your feedback people. >> >> >> >> Best Regards, >> >> >> >> *Luis Vitorio Cargnini, Ph.D.* >> >> [email protected] >> Sr. Systems Architect, >> Micron Technology, Inc. >> *This email and any attachments contained within may contain confidential >> and proprietary information.* >> >> >> >> >> >> >> >> >> >> >> >> >> _______________________________________________ >> 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
_______________________________________________ gem5-users mailing list [email protected] http://m5sim.org/cgi-bin/mailman/listinfo/gem5-users
