Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 20 Apr 2013 10:57:38 -0700
From:      Marcel Moolenaar <marcel@xcllnt.net>
To:        John Baldwin <jhb@FreeBSD.org>
Cc:        Jerome Ibanes <jibanes@gmail.com>, freebsd-ia64@freebsd.org
Subject:   Re: panic: mutex sched lock 0 not owned at /usr/src/sys/kern/sched_ule.c:2341
Message-ID:  <C2708F0E-BEA8-489A-B2C3-7D0466D7DA91@xcllnt.net>
In-Reply-To: <201304031540.59183.jhb@freebsd.org>
References:  <CAB%2B41mFJh0kBNJYBwPGedSe7Gy9PhjGDHcNARSV78tBj2zRVUQ@mail.gmail.com> <CAB%2B41mEJ%2BhfEM7sfW=cTbGVYAq1r%2B5w3wO2K_p2Lh261a7tJAw@mail.gmail.com> <CAB%2B41mHKC-n_c=iGwfmH%2B2YsJGCbejarvcTYzos6fcc==zO-3g@mail.gmail.com> <201304031540.59183.jhb@freebsd.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On Apr 3, 2013, at 12:40 PM, John Baldwin <jhb@FreeBSD.org> wrote:

> On Tuesday, March 26, 2013 4:18:24 pm Jerome Ibanes wrote:
>> John, Marcel, @List,
>>=20
>>> On most platforms the APs don't enable interrupts until their first =
context
>>> switch into their idle thread completes.  It seems they are enabled =
by
>>> accident here?
>>=20
>> Is it possible to disable this when booting from the iso?
>=20
> Originally I said no, but you can try disabling SMP altogether by =
setting=20
> kern.smp.disabled=3D1' from the loader prompt.

It may actually trigger a bug in the kernel on ia64...
The problem is that we're still collecting CPU information and create
PCPU structures for them. With SMP disabled this means yields some
inconsistency due to partial initialization. All IIRC...

--=20
Marcel Moolenaar
marcel@xcllnt.net





Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?C2708F0E-BEA8-489A-B2C3-7D0466D7DA91>