From: Xiao-Yong Jin <meta.jxy@gmail.com>
To: 9front@9front.org
Subject: Re: [9front] kernel crash in bhyve
Date: Wed, 9 Dec 2020 13:42:45 -0600 [thread overview]
Message-ID: <113209FF-35EA-4C62-B3D1-0CD39CE37BCF@gmail.com> (raw)
In-Reply-To: <CCB90423AC46D11566DD984AE761E1EA@felloff.net>
Here is the boot output from the current 9pc64 with *nomtrr=
Plan 9
wrmsr to register 0x401(0) on vcpu 0
125 holes free
0x00024000 0x0009f000 503808
0x00100000 0x00110000 65536
0x005f7000 0x136ff000 319848448
320417792 bytes free
cpu0: 6785MHz GenuineIntel P6 (AX 000306A9 CX F69A6217 DX 9F8BFBFF)
LAPIC: fee00000 0xffffff00fee00000
ELCR: 0260
cpu0: lapic clock at 268MHz
#l0: virtio: 1000Mbps port 0x2080 irq 6 ea 52540000b008
1024M memory: 336M kernel data, 688M user, 1313M swap
Here is the boot output after adding two memmapdump().
Plan 9
wrmsr to register 0x401(0) on vcpu 0
0000000000000000-0000000000020000 4
0000000000020000-000000000009fc00 2
000000000009fc00-00000000000a0000 4
00000000000a0000-00000000000c0000 80000001
00000000000c0000-00000000000d0000 4
00000000000d0000-00000000000f0000 1
00000000000f0000-0000000000100000 4
0000000000100000-0000000000110000 2
0000000000110000-00000000005f7000 4
00000000005f7000-0000000040000000 2
0000000040000000-0000000100000000 0
0000000000000000-00000000000a0000 4
00000000000a0000-00000000000c0000 80000001
00000000000c0000-00000000000d0000 4
00000000000d0000-00000000000f0000 1
00000000000f0000-0000000040000000 4
0000000040000000-0000000100000000 0
panic: rampage: out of memory
dumpstack
ktrace /kernel/path 0xffffffff801173c7 0xffffffff8001fbf8 <<EOF
estackx ffffffff80020000
8001fb18=80117121 8001fb50=8024ceca 8001fb90=8024b683 8001fbc8=801173c7
8001fbf0=801173c7 8001fbf8=80117129 8001fc08=8016abad 8001fc68=8024b720
8001fc78=80110db2 8001fc98=80110e16 8001fcb0=8024d664 8001fcb8=80110f11
8001fcc0=80224b84 8001fcd0=80225001 8001fcd8=80119cb0 8001fcf0=80224ea8
8001fcf8=8016a67d 8001fd08=80213803 8001fd10=801a4906 8001fd18=8021388f
8001fd40=8016a7ef 8001fd58=8011339a 8001fd88=8016a8f7 8001fd98=80114d79
8001fdb0=8016a956 8001fdd8=80247f3d 8001fde0=80114e5d 8001fe28=80115193
8001fe50=80113812 8001fe58=801134f8 8001fe70=80213799 8001fe78=80224b84
8001fe80=80115b62 8001fea8=8011451f 8001fed0=801e4848 8001fef8=80113980
8001ff20=802136d6 8001ff28=80118d63 8001ff30=801e4b09 8001ff58=801e6394
8001ffa0=8015c6cb 8001ffa8=801144ce 8001ffe0=80112de9 8001ffe8=00000000
8001fff0=00000000 8001fff8=801101c9
EOF
cpu0: exiting
Takes a licking and keeps on ticking...
Here is the boot output from a previous 9pc64.
Everything else is the same.
Plan 9
wrmsr to register 0x401(0) on vcpu 0
125 holes free
0x00024000 0x0009f000 503808
0x00100000 0x00110000 65536
0x005f6000 0x136ff000 319852544
320421888 bytes free
cpu0: 6781MHz GenuineIntel P6 (AX 000306A9 CX F69A6217 DX 9F8BFBFF)
LAPIC: fee00000 0xffffff00fee00000
ELCR: 0260
cpu0: lapic clock at 268MHz
#l0: virtio: 1000Mbps port 0x2080 irq 6 ea 52540000b008
1024M memory: 336M kernel data, 688M user, 1313M swap
> On Dec 9, 2020, at 1:05 PM, cinap_lenrek@felloff.net wrote:
>
> the wmsr 0x401 is harmless. its trying to initialize
> the MCE registers. you can get rid of it by passing
> *nomce= to the kernel.
>
> for the panic...
>
> is this a regression or the first time you tried it?
>
> the kernel calls rampage() initially to get memory
> for the page tables todo the mappings at KZERO.
>
> if this is a regression, you might try the *nomtrr=
> flag. maybe the mtrr's are giving strange cache
> attributes which makes the kernel exclude it from
> the memory map.
>
> the relevant line is here:
>
> /* RAM needs to be writeback */
> mtrrexclude(MemRAM, "wb");
>
> maybe you can insert a call of memmapdump() before
> and after this line?
>
> --
> cinap
next prev parent reply other threads:[~2020-12-09 19:47 UTC|newest]
Thread overview: 18+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-12-09 18:18 Xiao-Yong Jin
2020-12-09 18:26 ` [9front] " Xiao-Yong Jin
2020-12-09 18:44 ` ori
2020-12-09 19:05 ` [9front] " cinap_lenrek
2020-12-09 19:42 ` Xiao-Yong Jin [this message]
2020-12-09 20:52 ` cinap_lenrek
2020-12-09 21:22 ` Xiao-Yong Jin
2020-12-09 22:04 ` cinap_lenrek
2020-12-09 22:36 ` Xiao-Yong Jin
2020-12-09 23:18 ` cinap_lenrek
2020-12-10 0:10 ` Xiao-Yong Jin
2020-12-10 0:45 ` cinap_lenrek
2020-12-10 11:30 ` cinap_lenrek
2020-12-10 20:37 ` Xiao-Yong Jin
2020-12-10 23:12 ` Nick Owens
2020-12-11 4:55 ` Xiao-Yong Jin
2020-12-11 14:27 ` cinap_lenrek
2020-12-11 1:12 ` ori
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=113209FF-35EA-4C62-B3D1-0CD39CE37BCF@gmail.com \
--to=meta.jxy@gmail.com \
--cc=9front@9front.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).