Can't you defer attachment of your failing device?
On 04/25/15 02:10, Michael van Elst wrote:
There is no safe way to identify the boot disk from information passed
by the BIOS. Here is what the MD code for x86 does: 1. BTINFO_ROOTDEVICE
3. BTINFO_BOOTDISK
a) ...
b) ...
c) bootloader passed BIOS disk number for a CD
Search for the fir
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
Updating src tree:
P src/doc/CHANGES
P src/doc/CHANGES.prev
P src/share/misc/acronyms
P src/share/misc/acronyms-o.real
P src/sys/compat/svr4/svr4_stream.c
P src/sys/dev/pci/ixgbe/LICENSE
P src/sys/dev/pci/ixgbe/ixgbe.c
P src/sys/dev/pci/ixgbe/ixgbe.h
P src/sys/dev/pci/ixgbe/ixgbe_82598.c
P src/sys
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: uninitiali
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 netbsd:mutex_vect
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
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
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 wrote:
> On Fri, 24 Apr 2015, Thomas Klausner wrote:
>
>> On Thu, Apr 23, 2015
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
sysmon_evnsys_regist
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: locki
> On Apr 23, 2015, at 8:40 PM, Brett Lymn wrote:
>
> inet6 fe80::76d0:2bff:fe2b:89bc%wm0 prefixlen 64 scopeid 0x1
That is a link local address is only good for communicating with other
machines accesible from that interface.
If you had “real” IPv6 you’d see something other than fe80::
On Fri, 24 Apr 2015, Thomas Klausner wrote:
On Thu, Apr 23, 2015 at 11:23:20PM +, Paul Goyette wrote:
Log Message:
Welcome to 7.99.x and the modularization of sysmon!
I've built a 7.99.11 kernel today and booted it, and it twice failed
in the same place during boot.
acpicpu1 at cpu1: ACP
On Thu, Apr 23, 2015 at 11:23:20PM +, Paul Goyette wrote:
> Log Message:
> Welcome to 7.99.x and the modularization of sysmon!
I've built a 7.99.11 kernel today and booted it, and it twice failed
in the same place during boot.
acpicpu1 at cpu1: ACPI CPU
coretemp1 at cpu1: thermal sensor, 1 C
Am Freitag, 24. April 2015, 13:10:24 schrieben Sie:
> inet6 fe80::76d0:2bff:fe2b:89bc%wm0 prefixlen 64 scopeid 0x1
If you mean this "IPv6 address" - this is (by IPv6 spec) a "link local"
address - auto generated by "your operating system" byself (from the network
hardware / MAC). This mea
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=8843 mtu 1500
> capabilities=7ff80
>
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 av
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 (
18 matches
Mail list logo
