Can't you defer attachment of your failing device?
On Sat, 25 Apr 2015, Masao Uebayashi wrote:
Can't you defer attachment of your failing device?
That was my initial thought. But there are lots of potential failing
devices.
A quick scan shows that there are about 125-130 sources files which
attempt to register with
On Sat, Apr 25, 2015 at 03:41:46PM +0800, Paul Goyette wrote:
A quick scan shows that there are about 125-130 sources files which
attempt to register with sysmon_{pswitch,wdog,envsys}_register.
Since this is only about early access to the register functions, can't we
just add a static boolean
On Sat, 25 Apr 2015, Martin Husemann wrote:
On Sat, Apr 25, 2015 at 03:41:46PM +0800, Paul Goyette wrote:
A quick scan shows that there are about 125-130 sources files which
attempt to register with sysmon_{pswitch,wdog,envsys}_register.
Since this is only about early access to the
I do not like the init_main change - the attached patch makes my system boot
with a LOCKDEBUG kernel.
Not sure if this is complete.
Martin
Index: sysmon_envsys.c
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_envsys.c,v
retrieving
The init_main change is really just reverting to the way things were
prior to my diving in and breaking things.
On Sat, 25 Apr 2015, Martin Husemann wrote:
I do not like the init_main change - the attached patch makes my system boot
with a LOCKDEBUG kernel.
Not sure if this is complete.
On Sat, 25 Apr 2015, Paul Goyette wrote:
On Sat, 25 Apr 2015, Martin Husemann wrote:
On Sat, Apr 25, 2015 at 03:41:46PM +0800, Paul Goyette wrote:
A quick scan shows that there are about 125-130 sources files which
attempt to register with sysmon_{pswitch,wdog,envsys}_register.
Since
Fyi, running bt in the debugger yields (transcribed BY HAND):
db{0} bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
lockdebug_abort() at netbsd:locdebug_abort+0x63
mutex_vector_enter() at netbsd:mutex_vector_enter+0x531
Transcribed boot msgs:
Mutex error: mutex_vector_enter: locking against myself
lock address : 0x811bc040
current cpu : 0
current lwp : 0x810cebc0
owner field : 0x810cebc0 wait/spin:0/0
panic: lock error: Mutex: mutex_vector_enter:
Thanks for the back-trace. Wiz had alerted me to this problem some
hours ago (in a different thread). Since this one has the most info
available, let's follow through on this thread.
I'm looking into this, but I don't see anything obvious yet.
On Fri, 24 Apr 2015, bch wrote:
Fyi, running
On Fri, 24 Apr 2015, bch wrote:
Fyi, running bt in the debugger yields (transcribed BY HAND):
db{0} bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
lockdebug_abort() at netbsd:locdebug_abort+0x63
mutex_vector_enter() at
On Sat, 25 Apr 2015, Martin Husemann wrote:
On Sat, Apr 25, 2015 at 08:59:45AM +0800, Paul Goyette wrote:
For some reason, the sme_global_mtx seems to already be locked when
sysmon_envsys_register tries to get it.
No, it is not initialized:
That is more in line with my expectations. I was
On Sat, Apr 25, 2015 at 08:59:45AM +0800, Paul Goyette wrote:
For some reason, the sme_global_mtx seems to already be locked when
sysmon_envsys_register tries to get it.
No, it is not initialized:
aibs0 at acpi0 (ASOC, ATK0110-16843024): ASUSTeK AI Booster
panic: lockdebug_lookup:
13 matches
Mail list logo
