> However, are there any other similar fallouts outside this initmsgbuf()
> situation?
There is only a risk on platforms where initmsgbuf() is invoked in (or
before) pmap_bootstrap(), and where curcpu() will not necessarily point
into the kernel data section for the boot processor.
That
On Thu, Jan 07, 2021 at 11:51:02AM -, Miod Vallat wrote:
>
> >> Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
> >> makes the kernel boot again.
> >
> > Here is a diff for that.
>
> After a bit more thinking, it might be worth introduce a
> msgbuf_putchar_unlocked()
> From: Miod Vallat
> Date: Thu, 7 Jan 2021 11:51:02 - (UTC)
>
> >> Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
> >> makes the kernel boot again.
> >
> > Here is a diff for that.
>
> After a bit more thinking, it might be worth introduce a
>
>> Indeed. Wrappinge the mutex operations in msgbuf_putchar with if (!cold)
>> makes the kernel boot again.
>
> Here is a diff for that.
After a bit more thinking, it might be worth introduce a
msgbuf_putchar_unlocked() routine for the inner part only, and have
initmsgbuf() use it, since:
- it
On Thu, Jan 07, 2021 at 07:08:05AM +, Miod Vallat wrote:
> > The per-CPU struct is mapped using a 64K locked TLB entry. That TLB
> > entry is installed by sun4u_bootstrap_cpu(), which gets called *after*
> > initsmgbuf() is called. So this issue was introduced when locking was
> > added to
> The per-CPU struct is mapped using a 64K locked TLB entry. That TLB
> entry is installed by sun4u_bootstrap_cpu(), which gets called *after*
> initsmgbuf() is called. So this issue was introduced when locking was
> added to msgbuf_putchar().
>
> Now the real question is why this doesn't crash
> Date: Wed, 6 Jan 2021 19:14:08 +
> From: Miod Vallat
>
> I have been confused by a very strange issue on sparc64 over the last
> few days, and I can't figure out its cause.
>
> What happens is that cold boots work, but warm boots (i.e. rebooting)
> almost always fail like this:
>
>
> I think the window this occurs is something like:
>
> bad
> OpenBSD 6.8-current (GENERIC) #510: Thu Oct 29 19:58:32 MDT 2020
>
> good
> OpenBSD 6.8-current (GENERIC) #508: Thu Oct 29 06:05:29 MDT 2020
I was trying to find a narrow window, but since it does not always
happen, I ended up with a
On Wed, Jan 06, 2021 at 07:14:08PM +, Miod Vallat wrote:
> I have been confused by a very strange issue on sparc64 over the last
> few days, and I can't figure out its cause.
>
> What happens is that cold boots work, but warm boots (i.e. rebooting)
> almost always fail like this:
>
>
