Re: current status of ixg(4)
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 (better). Thanks. I committed the diff. I also committed a change that ifconfig -z didn't work. Regards Uwe New one: http://www.netbsd.org/~msaitoh/ixg-20150414-0.dif - Sync ixg(4) up to FreeBSD r250108: - Cleanup some unused counters and some unused code. - Improve performance. - Fix flow control - don't override user value on re-init - Fix to make 1G optics work correctly - Change to interrupt enabling - some bits were incorrect for certain hardware. - Certain stats fixes, remove a duplicate increment of ierror, thanks to Scott Long for pointing these out. - Fix the setting of RX which related to multicast. - Some netmap related fixes. - Committed. -- --- SAITOH Masanobu (msai...@execsw.org msai...@netbsd.org)
Re: default ipv6 route?
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 1500 capabilities=7ff80TSO4,IP4CSUM_Rx,IP4CSUM_Tx,TCP4CSUM_Rx capabilities=7ff80TCP4CSUM_Tx,UDP4CSUM_Rx,UDP4CSUM_Tx,TCP6CSUM_Rx capabilities=7ff80TCP6CSUM_Tx,UDP6CSUM_Rx,UDP6CSUM_Tx,TSO6 enabled=0 ec_capabilities=7VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU ec_enabled=0 address: 74:d0:2b:2b:89:bc media: Ethernet autoselect (1000baseT full-duplex,flowcontrol,rxpause,txpause) status: active inet 192.168.3.1 netmask 0xff00 broadcast 192.168.3.255 inet6 fe80::76d0:2bff:fe2b:89bc%wm0 prefixlen 64 scopeid 0x1 but I cannot seem to add a default route for ipv6 to point to my home router. I know my ipv6 set up is ok because a laptop I configure using dhcp works fine with ipv6 so it must be something I am not doing on the wired machine. Any suggestions? Thanks. DHCPv6 does not specify any default route or prefix. On NetBSD, DHCPv6 is only started when a RA is received with either the O or M flags set and even then you need to use dhcpcd(8) to get this working. Did your host receive a valid RA? Roy
Re: kernel fault -current of 23/24 Apr 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_register() at netbsd:sysmon_evnsys_register+0x41
acpiacad_attach() at netbsd:acpiacad_attach+0xcd
config_attach_loc() at netbsd:config_attach_loc+0x17a
acpi_rescan() at netbsd:acpi_rescan+0x20d
acpi_attach() at netbsd:acpi_attach+0x2f1
config_attach_loc() at netbsd:config_attach_loc+0x17a
mainbus_attach() at netbsd:mainbus_attach+0x2a6
config_attach_loc() at netbsd:config_attach_loc+0x17a
cpu_configure() atnetbsd:cpu_configure+0x26
main() at netbsd:main+0x29e
On 4/24/15, bch brad.har...@gmail.com wrote:
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: locking against myself:
lock 0x811bc040 cpu 0 lwp 0x810cebc0
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8
rsp 8137fab0
curlwp 0x810cebc0 pid 0.1 lowest kstack 0x8137c2c0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
kernel fault -current of 23/24 Apr 2015
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: locking against myself: lock 0x811bc040 cpu 0 lwp 0x810cebc0 fatal breakpoint trap in supervisor mode trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8 rsp 8137fab0 curlwp 0x810cebc0 pid 0.1 lowest kstack 0x8137c2c0 Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
Re: why does dk(4) take precedence in boot device selection???
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 from where it found and loaded the kernel!?!?!?), or the code for match_bootwedge() is somehow too simplistic and over-eager. 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 a) bootloader passed root device name as driverunitpartition. Search for driver instance with the correct name and unit and pass partition number to MI code. The MI code will later identify a matching wedge or use the partition number with the disk driver. b) bootloader passed wedge name as wedge:name. The kernel will later search for a wedge with that name. This is for a bootloader that passes a NetBSD identifier to the kernel, i.e. one that reads bootdev from boot.cfg. Nothing depends on BIOS information. 2. BTINFO_BOOTWEDGE bootloader passed start offset and length of a hard disk partition and a offset,size and hash of a boot area. Search all disks and wedges for a block sequence at that offset with a matching hash. Pass device, offset and length to the MI code. The MI code will later search for a matching wedge on that device. A partition number is provided if the bootloader also passed a BTINFO_BOOTDISK record. This (or partition 'a') will be used by the MI code as a fallback if there is no matching wedge. This is the conventional hard disk boot. It fails to identify the disk if there are disks or wedges with the same (according to hash) boot areas. But the kernel prints a warning if more than one matching disk is found. 3. BTINFO_BOOTDISK a) bootloader passed BIOS disk number for floppy and a partition number. Search the first fd driver instance with the correct unit, pass driver instance and partition number to MI code. b) bootloader passed BIOS disk number for a hard drive, a partition number and disklabel data (offset,type,checksum,packname). Search all disks for a matching disklabel at the passed label offset. Pass driver instance and partition number to MI code. The MI code will later identify a matching wedge or use the partition number with the disk driver. c) bootloader passed BIOS disk number for a CD Search for the first cd device, you can only boot from unit 0. Pass driver instance (and partition 0) to MI code. This is only used for floppy and CD unless you have an old bootloader that doesn't know about BTINFO_BOOTWEDGE. This could also mismatch if several hard disks have matching disklabels (including faked default labels if there is no label on disk). But again, a warning is printed in that case. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: kernel fault -current of 23/24 Apr 2015
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 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_register() at netbsd:sysmon_evnsys_register+0x41
acpiacad_attach() at netbsd:acpiacad_attach+0xcd
config_attach_loc() at netbsd:config_attach_loc+0x17a
acpi_rescan() at netbsd:acpi_rescan+0x20d
acpi_attach() at netbsd:acpi_attach+0x2f1
config_attach_loc() at netbsd:config_attach_loc+0x17a
mainbus_attach() at netbsd:mainbus_attach+0x2a6
config_attach_loc() at netbsd:config_attach_loc+0x17a
cpu_configure() atnetbsd:cpu_configure+0x26
main() at netbsd:main+0x29e
On 4/24/15, bch brad.har...@gmail.com wrote:
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: locking against myself:
lock 0x811bc040 cpu 0 lwp 0x810cebc0
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8
rsp 8137fab0
curlwp 0x810cebc0 pid 0.1 lowest kstack 0x8137c2c0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
-
Re: kernel fault -current of 23/24 Apr 2015
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_vector_enter+0x531
sysmon_evnsys_register() at netbsd:sysmon_evnsys_register+0x41
acpiacad_attach() at netbsd:acpiacad_attach+0xcd
config_attach_loc() at netbsd:config_attach_loc+0x17a
acpi_rescan() at netbsd:acpi_rescan+0x20d
acpi_attach() at netbsd:acpi_attach+0x2f1
config_attach_loc() at netbsd:config_attach_loc+0x17a
mainbus_attach() at netbsd:mainbus_attach+0x2a6
config_attach_loc() at netbsd:config_attach_loc+0x17a
cpu_configure() atnetbsd:cpu_configure+0x26
main() at netbsd:main+0x29e
Very odd
For some reason, the sme_global_mtx seems to already be locked when
sysmon_envsys_register tries to get it. Code examination shows that
there is one error path where the mutex is not released, and I just
committed a fix for that. It is unlikely, though, that this is why you
two are having problems, as this code path would not (or, at least,
should not) have changed from the modularization changes.
Brad, do you have the dmesg output leading up to the panic? Wiz already
provided his.
On 4/24/15, bch brad.har...@gmail.com wrote:
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: locking against myself:
lock 0x811bc040 cpu 0 lwp 0x810cebc0
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8
rsp 8137fab0
curlwp 0x810cebc0 pid 0.1 lowest kstack 0x8137c2c0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
-
| Paul Goyette | PGP Key fingerprint: | E-mail addresses: |
| (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com|
| Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org |
-
Re: kernel fault -current of 23/24 Apr 2015
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 surprised that the lock info from Wiz and bch both showed that the owner was curlwp. The basic problem is that the device configuration is being done long before the module subsystem is fully initialized. And we cannot simply initialize the module subsystem earlier, as many of the modules are devices or pseudodevices which require the configuration system to be available! Chicken vs egg... I've got a couple of ideas, but they'll take a few days to gestate, and then a bit more time to discuss on tech-kern before implementing. As much as I don't want to do it, I might have to revert that series of commits. And due to a current illness, even the revert might take a couple days. snip Additionally there seems to be a missing mutex_exit() in an error branch: I think I already caught that one. :) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -
Re: kernel fault -current of 23/24 Apr 2015
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: uninitialized lock (lock=0x811aa9a0,
from=808f320f)
fatal breakpoint trap in supervisor mode
trap type 1 code 0 rip 8028b8bd cs 8 rflags 246 cr2 0 ilevel 8 rsp
8135ea60
curlwp 0x810e4940 pid 0.1 lowest kstack 0x8135b2c0
Stopped in pid 0.1 (system) at netbsd:breakpoint+0x5: leave
db{0} bt
breakpoint() at netbsd:breakpoint+0x5
vpanic() at netbsd:vpanic+0x13c
snprintf() at netbsd:snprintf
lockdebug_locked() at netbsd:lockdebug_locked
mutex_enter() at netbsd:mutex_enter+0x43f
sysmon_envsys_register() at netbsd:sysmon_envsys_register+0x41
aibs_attach() at netbsd:aibs_attach+0x19a
config_attach_loc() at netbsd:config_attach_loc+0x17a
acpi_rescan() at netbsd:acpi_rescan+0x20d
acpi_attach() at netbsd:acpi_attach+0x2f1
config_attach_loc() at netbsd:config_attach_loc+0x17a
mainbus_attach() at netbsd:mainbus_attach+0x2a6
config_attach_loc() at netbsd:config_attach_loc+0x17a
cpu_configure() at netbsd:cpu_configure+0x26
main() at netbsd:main+0x29e
Additionally there seems to be a missing mutex_exit() in an error branch:
Index: sysmon_envsys.c
===
RCS file: /cvsroot/src/sys/dev/sysmon/sysmon_envsys.c,v
retrieving revision 1.132
diff -u -p -r1.132 sysmon_envsys.c
--- sysmon_envsys.c 24 Apr 2015 03:32:25 - 1.132
+++ sysmon_envsys.c 25 Apr 2015 05:28:20 -
@@ -779,6 +779,7 @@ sysmon_envsys_register(struct sysmon_env
mutex_enter(sme_global_mtx);
if (!prop_dictionary_set(sme_propd, sme-sme_name, array)) {
error = EINVAL;
+ mutex_exit(sme_global_mtx);
DPRINTF((%s: prop_dictionary_set for '%s'\n, __func__,
sme-sme_name));
goto out;
Martin
Re: why does dk(4) take precedence in boot device selection???
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 issue? Is it still so difficult to discover which device the boot loader booted the kernel from on such a semi-modern amd64 machine that the kernel can make such mistakes as this? If dk(4) is auto-configuring can it not at least look to see if there's a valid filesystem on the device before it shoves itself in the front of the line as the supposed boot device? The device drivers, including dk, do not 'shove itself' anywhere. There are several, ugly, heuristics to guess which device and partition was used to boot from, so that it be mounted as root. 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 from where it found and loaded the kernel!?!?!?), or the code for match_bootwedge() is somehow too simplistic and over-eager. In any case the result is any old dk(4) device gets undue precedence in being selected as the booted_device and this of course entirely foils the default logic for searching for the root FS, since it may not have anything whatsoever to do with where the kernel came from, which is also where the root filesystem is also supposed to be. The worst part is that none of this seems to be documented, never mind with a big warning that it violates the principle of least astonishment. Which means it must be a bug, right? :-) -- Greg A. Woods Planix, Inc. wo...@planix.com +1 250 762-7675http://www.planix.com/ pgpNe8v2hnJuX.pgp Description: PGP signature
Re: CVS commit: src/sys/sys
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: 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 resolution Mutex error: mutex_vector_enter: locking against myself lock address : 0x811c0040 current cpu : 0 current lwp : 0x810d2b80 owner field : 0x810d2b80 wait spin: 0/0 panic: lock error: Mutex: mutex_vector_enter: locking against myself: lock 0x811c0040 cpu 0 lwp 0x810d2b80 fata breakpoint trap in supervisor mode trap type 1 code 0 rip 80289eed cs 8 rflags 246 cr2 0 ilevel 8 rsp 81373c00 curlwp 0x810d2b80 pid 0.1 lowest kstrack 0x813702c0 7.99.10 from yesterday boots fine. Hmmm. The dmesg would at least suggest that this would be a result of my changes. Is there any chance you can get a backtrace? Or use the kernel map to identify which lock is being referenced? (Both data would be useful.) - | Paul Goyette | PGP Key fingerprint: | E-mail addresses: | | (Retired)| FA29 0E3B 35AF E8AE 6651 | paul at whooppee.com| | Kernel Developer | 0786 F758 55DE 53BA 7731 | pgoyette at netbsd.org | -
