On 2015/04/14 17:22, Masanobu SAITOH wrote:
On 2015/04/10 4:26, 6b...@6bone.informatik.uni-leipzig.de wrote:
On Wed, 8 Apr 2015, SAITOH Masanobu wrote:
Use new one:
http://www.netbsd.org/~msaitoh/ixg-20150407-1.dif
After a first test, it looks as if the interrupt throttling now works
Hi Brett
On 24/04/2015 04:40, Brett Lymn wrote:
I am clearly doing something wrong here. I have a machine with a wired
ethernet connection that I have manually configured the ipv4 address
for, it appears to have an ipv6 address:
wm0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu
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:
wo...@planix.ca (Greg A. Woods) writes:
Well, perhaps shove is the wrong word, but either the boot code is
lying about where it loads the kernel from and it is filling in
BTINFO_BOOTWEDGE info when it should not (why the heck would it even
look on a different device from where it came from and
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:
At Thu, 23 Apr 2015 05:55:11 + (UTC), mlel...@serpens.de (Michael van Elst)
wrote:
Subject: Re: why does dk(4) take precedence in boot device selection???
wo...@planix.ca (Greg A. Woods) writes:
Am I missing something here that I could do to change the wedge
configuration to avoid this
FYI -- I sent msg to current-users this morning about same (not
recognizing subject of this existing thread).
Ref: http://mail-index.netbsd.org/current-users/2015/04/24/msg027232.html
-bch
On 4/24/15, Paul Goyette p...@vps1.whooppee.com wrote:
On Fri, 24 Apr 2015, Thomas Klausner wrote:
11 matches
Mail list logo
