[haiku-bugs] Re: [Haiku] #10249: Haiku built from Haiku doesn't boot without disabling SMP or NX-bit
- From: "bonefish" <trac@xxxxxxxxxxxx>
- Date: Sat, 07 Dec 2013 16:29:40 -0000
#10249: Haiku built from Haiku doesn't boot without disabling SMP or NX-bit
-----------------------------+----------------------------
Reporter: pulkomandy | Owner: bonefish
Type: bug | Status: assigned
Priority: normal | Milestone: R1
Component: System/Kernel | Version: R1/Development
Resolution: | Keywords: vm
Blocked By: | Blocking:
Has a Patch: 0 | Platform: All
-----------------------------+----------------------------
Comment (by bonefish):
Replying to [comment:36 anevilyak]:
> Replying to [comment:34 bonefish]:
> Out of curiosity, does TLB invalidation in this manner apply to all
CPUs, or just the current one?
Just the current one. I overlooked that it actually only invalidates non-
global TLB entries (we use global ones for the kernel), so this doesn't
have the desired effect in this case anyway.
> In this instance it should be irrelevant since the vbox instance for
this crash is, if I remember correctly, restricted to emulating a single
core, but in the general case, would be nice to know.
I was (and still am) under the impression that this issue only occurs with
multiple CPUs and also goes away when SMP is disabled. Please correct me,
if I'm wrong.
> Is a stack trace depth of 10 likely to be sufficient? That's what we
currently have the mapping trace depth configured for on his VM.
Yep, that's fine.
Unfortunately the latest syslog hasn't been too helpful. We can see that
the address in question was mapped and unmapped twice before as part of a
regular area. Before that, it was unmapped by
`vm_free_unused_boot_loader_range()`, so apparently it had been used in
the boot loader. The last unmap happened on the same CPU that crashed, but
since TLB invalidation is normally only performed when the entry had
actually been used (which can't be inferred from the available data), this
doesn't mean much.
In hrev46506 I've added more extensive information to the translation map
kernel tracing. I'm attaching a patch that adds tracing entries when TLB
entries are actually being invalided. It also adds a KDL command `tlb`
which invalidates the whole TLB of the current CPU. It is meant to replace
the ill-conceived `bt 1` idea. So `tlb` plus `co` should continue the boot
process, if the original theory holds.
Other than that basically the same information as before are needed:
1. `traced --stacktrace 0 -100 -1 #0x81000000`
1. `traced <number> -10 -1` for all six of the printed "translation map"
entries. There may be additional "TLB invalidate" entries. Those can be
skipped, since they already print the current CPU.
1. Additionally: `traced --stacktrace 0 -500 -1 "#invalidate all"`
--
Ticket URL: <http://dev.haiku-os.org/ticket/10249#comment:39>
Haiku <http://dev.haiku-os.org>
Haiku - the operating system.
Other related posts:
