daily CVS update output
Updating src tree: P src/lib/libedit/vi.c P src/sys/arch/arm/arm32/bus_dma.c P src/sys/arch/arm/nvidia/tegra_nouveau.c P src/sys/arch/evbarm/tegra/tegra_machdep.c P src/sys/arch/hppa/hppa/machdep.c P src/sys/arch/m68k/m68k/db_trace.c P src/sys/arch/x86/include/cacheinfo.h P src/sys/compat/linux/common/linux_exec_aout.c P src/sys/compat/sunos/sunos_exec_aout.c P src/sys/compat/sunos32/sunos32_exec_aout.c P src/sys/dev/usb/usbdevs P src/sys/dev/usb/usbdevs.h P src/sys/dev/usb/usbdevs_data.h P src/sys/external/bsd/drm2/dist/drm/nouveau/Makefile P src/sys/external/bsd/drm2/dist/drm/nouveau/core/core/nouveau_core_object.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/device/nouveau_engine_device_nve0.c U src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/fifo/nouveau_engine_fifo_gk20a.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/ctxnvc0.h U src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nouveau_engine_graph_ctxgk20a.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nouveau_engine_graph_ctxnve4.c U src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nouveau_engine_graph_gk20a.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nouveau_engine_graph_nvc0.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nouveau_engine_graph_nve4.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/graph/nvc0.h P src/sys/external/bsd/drm2/dist/drm/nouveau/core/include/engine/fifo.h P src/sys/external/bsd/drm2/dist/drm/nouveau/core/include/engine/graph.h P src/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/fb.h P src/sys/external/bsd/drm2/dist/drm/nouveau/core/include/subdev/ibus.h P src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/bar/nouveau_subdev_bar_base.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/bar/nouveau_subdev_bar_nvc0.c U src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/fb/nouveau_subdev_fb_gk20a.c U src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/fb/nouveau_subdev_fb_ramgk20a.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/fb/priv.h U src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/ibus/nouveau_subdev_ibus_gk20a.c P src/sys/external/bsd/drm2/dist/drm/nouveau/core/subdev/mc/nouveau_subdev_mc_base.c P src/sys/external/bsd/drm2/include/linux/mm.h P src/sys/external/bsd/drm2/include/linux/platform_device.h P src/sys/external/bsd/drm2/nouveau/files.nouveau P src/sys/kern/tty.c P src/sys/net/npf/npf.c P src/tests/net/in_cksum/in_cksum.c P src/usr.sbin/cpuctl/arch/i386.c P src/usr.sbin/sysinst/target.c Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Oct 19 03:21:10 2015 SUP Scan for current completed at Mon Oct 19 03:35:17 2015 SUP Scan for mirror starting at Mon Oct 19 03:35:17 2015 SUP Scan for mirror completed at Mon Oct 19 03:52:06 2015 Updating release-5 src tree (netbsd-5): Updating release-5 xsrc tree (netbsd-5): Running the SUP scanner: SUP Scan for release-5 starting at Mon Oct 19 04:03:21 2015 SUP Scan for release-5 completed at Mon Oct 19 04:03:29 2015 Updating release-6 src tree (netbsd-6): Updating release-6 xsrc tree (netbsd-6): Running the SUP scanner: SUP Scan for release-6 starting at Mon Oct 19 04:14:10 2015 SUP Scan for release-6 completed at Mon Oct 19 04:14:22 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 54971303 Oct 19 04:38 ls-lRA.gz
Re: Finding the current network devices
Date:Sun, 18 Oct 2015 10:49:05 -0400 From:Greg Troxel Message-ID: | Another hacky trick is to create both ifconfig.wm0 and ifconfig.bge0 and | just leave both there, if you are pretty sure you'll have one or the | other. That might create annoying or problematic errors though. No errors, not hacky at all, that's the ideal solution (the two files for interface 0 (and of course 1) can even be linked together, so there's only one real file (for each interface) to edit to make config changes, in case it contains more than just "up" and perhaps "dhcp") This works because the startup scripts look for what interface names exist, and then for each interface name, look for /etc/ifconfig.$ifname. The files for interface names that don't exist are never even noticed. Doing this in fstab for filesystems is much (MUCH) less likely to work, the fsck scripts bomb out if a filesystem can't be correctly checked. Either using raidframs (servers should anyway) and raid autoconfig, which then doesn't care what the actual device names happen to be, or named wedges, is the solution to that one. kre
Re: Finding the current network devices
On Sun, 18 Oct 2015 16:20:15 + (UTC) chris...@astron.com (Christos Zoulas) wrote: > >In any case the other problem is that variable names can't be > >variable. I can't do "ifconfig_$eth0="etc...". I quess I just have > >to remember to edit the files when I move a server. > > sure they can, just eval them. I tried that but it didn't work. Maybe I did it wrong. I will try again. OK, it did work. Not sure what I did the first time. eval "ifconfig_`ifconfig -lb | cut -d' ' -f2`=\"BLAH BLAH BLAH\"" Thanks. -- D'Arcy J.M. Cain http://www.NetBSD.org/ IM:da...@vex.net
Re: Finding the current network devices
In article <20151018104020.32350513@imp>, D'Arcy J.M. Cain wrote: >On Sun, 18 Oct 2015 10:07:05 -0400 >g...@duzan.org wrote: >>Note that that isn't universal across Linux. I have at least one >> fairly modern Linux box at work which renames the interfaces from >> eth# to something else. > >In any case the other problem is that variable names can't be >variable. I can't do "ifconfig_$eth0="etc...". I quess I just have to >remember to edit the files when I move a server. sure they can, just eval them. christos
Re: Finding the current network devices
g...@ir.bbn.com (Greg Troxel) writes: >But how is the ordering determined? The basic issue is that you have >cables plugged into ports and then interfaces appearing, and ordering is >based on some probe order, somehow. Probe in some order when you see it, then fix the name to the MAC address so it stays the same even when interfaces come and go. Breaks in some hotplug scenarios and of course when the NIC gets replaced (e.g. replacement motherboard). -- -- Michael van Elst Internet: mlel...@serpens.de "A potential Snark may lurk in every tree."
Re: Finding the current network devices
da...@druid.net ("D'Arcy J.M. Cain") writes:
>Maybe Linux has the right idea. The ethernet cards are always eth# no
>matter what the actual hardware.
That's a convention that has been given up some time ago. Now some,
but not all devices, may get a name assigned by the BIOS that is
somehow associated with a location (i.e. motherboard, pci slot number, ...).
--
--
Michael van Elst
Internet: mlel...@serpens.de
"A potential Snark may lurk in every tree."
Re: Finding the current network devices
In Message , Greg Troxel wrote: =>"D'Arcy J.M. Cain" writes: => =>> Maybe Linux has the right idea. The ethernet cards are always eth# no =>> matter what the actual hardware. => =>But how is the ordering determined? The basic issue is that you have =>cables plugged into ports and then interfaces appearing, and ordering is =>based on some probe order, somehow. They have udev to do that. http://serverfault.com/questions/614216/how-do-i-control-the-ordering-of-network-interfaces As you can see from the config example, it can remember the MAC address and assign device names accordingly. Presumably NetBSD would need some kernel facility to rename devices, or maybe provide interface name aliases, to support a similar capability. Gary Duzan
Re: Finding the current network devices
On Sun, 18 Oct 2015 10:49:05 -0400 Greg Troxel wrote: > Another hacky trick is to create both ifconfig.wm0 and ifconfig.bge0 > and just leave both there, if you are pretty sure you'll have one or > the other. That might create annoying or problematic errors though. I was thinking about doing that for fstab as well. > > Maybe Linux has the right idea. The ethernet cards are always eth# > > no matter what the actual hardware. > > But how is the ordering determined? The basic issue is that you have > cables plugged into ports and then interfaces appearing, and ordering > is based on some probe order, somehow. Well, I already depend on the ordering anyway. All my servers have two ethernet ports and they are labeled 1 and 2 (or 0 and 1) . I plug the first one into the external network and the second into the internal one. I have never had to swap those ports. The numbering on the case always matched the system. -- D'Arcy J.M. Cain http://www.NetBSD.org/ IM:da...@vex.net
Re: Finding the current network devices
"D'Arcy J.M. Cain" writes: >> read eth0 eth1 _ <<< `ifconfig -l` > > In any case, this doesn't work. It's a bash operator and rc.conf is > run by sh. I will have to do something else to get the values. > However, I still don't know if I can depend on the order. Can anyone > tell me that? I suspect ifconfig prints out interfaces in order of ifindex, and that it will depend on what attaches first. But if you are trying to switch between wm0/1 and bge0/1, the ordering will probably be ok. Another hacky trick is to create both ifconfig.wm0 and ifconfig.bge0 and just leave both there, if you are pretty sure you'll have one or the other. That might create annoying or problematic errors though. > Maybe Linux has the right idea. The ethernet cards are always eth# no > matter what the actual hardware. But how is the ordering determined? The basic issue is that you have cables plugged into ports and then interfaces appearing, and ordering is based on some probe order, somehow. signature.asc Description: PGP signature
Re: Finding the current network devices
On Sun, 18 Oct 2015 10:07:05 -0400 g...@duzan.org wrote: >Note that that isn't universal across Linux. I have at least one > fairly modern Linux box at work which renames the interfaces from > eth# to something else. In any case the other problem is that variable names can't be variable. I can't do "ifconfig_$eth0="etc...". I quess I just have to remember to edit the files when I move a server. Or, I could create a script that generates all my files that I call with the server that I want it to be. Call it as; make_server [web|db|mail|phone|admin] Then create templates for the different servers. That would solve the fstab problem as well. -- D'Arcy J.M. Cain http://www.NetBSD.org/ IM:da...@vex.net
Re: Finding the current network devices
=> On Fri, 16 Oct 2015 13:29:14 -0400 => "D'Arcy J.M. Cain" wrote: =>> and then reboot. If I forget to adjust the network cards I am locked =>> out until I go to the server room. My solution is to add this to the =>> top of rc.conf: =>> =>> read eth0 eth1 _ <<< `ifconfig -l` => => In any case, this doesn't work. It's a bash operator and rc.conf is => run by sh. I will have to do something else to get the values. => However, I still don't know if I can depend on the order. Can anyone => tell me that? => => Maybe Linux has the right idea. The ethernet cards are always eth# no => matter what the actual hardware. Note that that isn't universal across Linux. I have at least one fairly modern Linux box at work which renames the interfaces from eth# to something else. Gary Duzan
Re: Finding the current network devices
On Fri, 16 Oct 2015 13:29:14 -0400 "D'Arcy J.M. Cain" wrote: > and then reboot. If I forget to adjust the network cards I am locked > out until I go to the server room. My solution is to add this to the > top of rc.conf: > > read eth0 eth1 _ <<< `ifconfig -l` In any case, this doesn't work. It's a bash operator and rc.conf is run by sh. I will have to do something else to get the values. However, I still don't know if I can depend on the order. Can anyone tell me that? Maybe Linux has the right idea. The ethernet cards are always eth# no matter what the actual hardware. -- D'Arcy J.M. Cain | Democracy is three wolves http://www.druid.net/darcy/| and a sheep voting on +1 416 788 2246 (DoD#0082)(eNTP) | what's for dinner. IM: da...@vex.net, VoIP: sip:da...@druid.net
daily CVS update output
Updating src tree: P src/common/lib/libc/arch/sparc/atomic/Makefile.inc P src/common/lib/libc/arch/sparc64/atomic/atomic_add.S P src/common/lib/libc/arch/sparc64/atomic/atomic_and.S P src/common/lib/libc/arch/sparc64/atomic/atomic_cas.S P src/common/lib/libc/arch/sparc64/atomic/atomic_dec.S P src/common/lib/libc/arch/sparc64/atomic/atomic_inc.S P src/common/lib/libc/arch/sparc64/atomic/atomic_op_asm.h P src/common/lib/libc/arch/sparc64/atomic/atomic_or.S P src/common/lib/libc/arch/sparc64/atomic/atomic_swap.S P src/distrib/sets/lists/xcomp/md.amd64 U src/distrib/sets/lists/xcomp/md.evbarm P src/distrib/sets/lists/xcomp/md.i386 P src/sys/arch/arm/allwinner/awin_board.c P src/sys/arch/arm/allwinner/awin_reg.h P src/sys/arch/arm/allwinner/awin_var.h P src/sys/arch/arm/arm32/armv7_generic_space.c P src/sys/arch/arm/include/cpufunc.h P src/sys/arch/arm/include/arm32/vmparam.h P src/sys/arch/arm/nvidia/files.tegra P src/sys/arch/arm/nvidia/tegra_car.c P src/sys/arch/arm/nvidia/tegra_carreg.h P src/sys/arch/arm/nvidia/tegra_intr.h P src/sys/arch/arm/nvidia/tegra_io.c U src/sys/arch/arm/nvidia/tegra_nouveau.c P src/sys/arch/arm/nvidia/tegra_pmc.c P src/sys/arch/arm/nvidia/tegra_pmcreg.h P src/sys/arch/arm/nvidia/tegra_reg.h P src/sys/arch/arm/nvidia/tegra_var.h P src/sys/arch/arm/xscale/pxa2x0_lcd.c P src/sys/arch/evbarm/awin/awin_machdep.c P src/sys/arch/evbarm/conf/BPI P src/sys/arch/evbarm/conf/CUBIEBOARD P src/sys/arch/evbarm/conf/JETSONTK1 P src/sys/arch/evbarm/conf/std.tegra P src/sys/arch/shark/ofw/ofw.c P src/sys/arch/sparc64/include/asm.h P src/sys/arch/sparc64/include/locore.h P src/sys/arch/sparc64/sparc64/copy.S P src/sys/arch/sparc64/sparc64/cpu_in_cksum.S P src/sys/external/bsd/drm2/dist/drm/nouveau/core/engine/device/nouveau_engine_device_base.c P src/sys/external/bsd/drm2/dist/drm/ttm/ttm_bo_util.c P src/sys/external/bsd/drm2/dist/include/drm/drm_agpsupport.h P src/sys/external/bsd/drm2/drm/drm_cache.c P src/sys/external/bsd/drm2/drm/drm_drv.c P src/sys/external/bsd/drm2/drm/drm_memory.c P src/sys/external/bsd/drm2/include/drm/bus_dma_hacks.h P src/sys/external/bsd/drm2/include/drm/drm_agp_netbsd.h P src/sys/external/bsd/drm2/include/linux/acpi.h P src/sys/external/bsd/drm2/include/linux/pci.h P src/sys/external/bsd/drm2/include/linux/platform_device.h P src/sys/external/bsd/drm2/linux/linux_work.c P src/sys/external/bsd/drm2/linux/linux_writecomb.c P src/sys/external/bsd/drm2/nouveau/files.nouveau P src/sys/external/bsd/drm2/nouveau/nouveau_module.c P src/sys/external/bsd/drm2/nouveau/nouveau_pci.c P src/sys/external/bsd/drm2/nouveau/nouveau_pci.h P src/sys/external/bsd/drm2/nouveau/nouveaufb.c P src/sys/external/bsd/drm2/ttm/ttm_agp_backend.c P src/sys/kern/init_main.c P src/sys/net/npf/npf.c P src/sys/sys/resourcevar.h Updating xsrc tree: Killing core files: Running the SUP scanner: SUP Scan for current starting at Sun Oct 18 04:43:50 2015 SUP Scan for current completed at Sun Oct 18 05:03:29 2015 SUP Scan for mirror starting at Sun Oct 18 05:03:29 2015 SUP Scan for mirror completed at Sun Oct 18 08:46:10 2015 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 55022845 Oct 18 12:58 ls-lRA.gz
Raw data from automated tests available by rsync
Hello -current users,
A couple of developers have expressed interest in getting access
to the raw data from the automated build and test runs on
babylon5.netbsd.org, for research or to generate new reports
and visualizations.
The data are now available by anonymous rsync, not only to developers
but also to the general public. They have in fact been available for
some months now, but I didn't get around to announcing it until now.
There are historical data from builds and tests of the i386 and sparc
ports going back to May 2011, and for amd64 going back to August 2011.
New data are added in real time as each build or test run finishes.
The following shell command will mirror the full data set to a local
directory:
for arch in i386 amd64 sparc
do
rsync -v -a rsync://babylon5.netbsd.org/bracket-${arch}-results ${arch}
done
This currently takes 7.3 GB of disk space.
The data for each port are organized into one directory per CVS source
date tested, and include
- The last 1000 lines of the build log from each build, including
the output of a "time" command indicating the total user, system,
and CPU time consumed (build.log.tail.gz)
- Full console output from the sysinst installation and the ATF
test run (isntall.log.gz and test.log.gz, respectively)
- The raw ATF output and the corresponding XML from each test run
(test.tps.gz and test.xml.gz, respectively)
- A text file of key-value pairs containing summary information
such as the exit status of the build and install (bracket.db).
The console logs in particular are easy to query using zgrep.
For example, if you are curious about when the "min" test case of
the usr.bin/config/t_config test started failing on amd64, you
could simply run
zgrep 'min: ' amd64/2015*/test.log.gz
Thanks to spz@ for setting up the rsync service.
Yours,
--
Andreas Gustafsson, g...@netbsd.org
Re: Does wscons use compat syscalls to switch sessions
Yes, it sounds very familiar.
On Sun, 18 Oct 2015, Valery Ushakov wrote:
On Sun, Oct 18, 2015 at 11:03:37 +0800, Paul Goyette wrote:
I just noticed that when switching console sessions from my X display
(on ttyE4) to the console session (on ttyE0), the system auto-loads the
"compat" kernel module.
Is this expected? normal? Shouldn't all "current" production code be
using "current" syscalls and/or ioctls?
This might be (haven't looked) the same problem I complained about
some time ago on tech-kern:
http://mail-index.netbsd.org/tech-kern/2013/12/15/msg016327.html
On Sun, Dec 15, 2013 at 15:35:01 +0400, Valery Ushakov wrote:
Date: Sun, 15 Dec 2013 15:35:01 +0400
From: Valery Ushakov
Subject: Compat module auto-bounce
To: tech-k...@netbsd.org
ttioctl() in sys/tty.c ends with doing
(void)module_autoload("compat", MODULE_CLASS_ANY);
for ioctls that it doesn't know about. This causes compat module to
auto-bounce in and out a lot. Note that this happens even for
up-to-date userland that doesn't need compat code. E.g. ttyname(3)
uses TIOCPTSNAME which ttioctl() doesn't handle. Running vi on
console seems to cause compat.mod to be autoloaded twice.
This seems rather wasteful.
-uwe
+--+--+-+
| 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: Does wscons use compat syscalls to switch sessions
On Sun, Oct 18, 2015 at 11:03:37 +0800, Paul Goyette wrote:
> I just noticed that when switching console sessions from my X display
> (on ttyE4) to the console session (on ttyE0), the system auto-loads the
> "compat" kernel module.
>
> Is this expected? normal? Shouldn't all "current" production code be
> using "current" syscalls and/or ioctls?
This might be (haven't looked) the same problem I complained about
some time ago on tech-kern:
http://mail-index.netbsd.org/tech-kern/2013/12/15/msg016327.html
On Sun, Dec 15, 2013 at 15:35:01 +0400, Valery Ushakov wrote:
> Date: Sun, 15 Dec 2013 15:35:01 +0400
> From: Valery Ushakov
> Subject: Compat module auto-bounce
> To: tech-k...@netbsd.org
>
> ttioctl() in sys/tty.c ends with doing
>
> (void)module_autoload("compat", MODULE_CLASS_ANY);
>
> for ioctls that it doesn't know about. This causes compat module to
> auto-bounce in and out a lot. Note that this happens even for
> up-to-date userland that doesn't need compat code. E.g. ttyname(3)
> uses TIOCPTSNAME which ttioctl() doesn't handle. Running vi on
> console seems to cause compat.mod to be autoloaded twice.
>
> This seems rather wasteful.
-uwe
Re: Crash on -current in pool_drain()
On Sun, 18 Oct 2015, Nick Hudson wrote:
On 10/18/15 00:30, Paul Goyette wrote:
Under heavy load, and after several hours of building packages, I am
seeing the following crash. I'm doing a bisect to narrow down more,
but it has been happening at least a week ago, with kernel and all
modules build from sources updated on 2015-10-13 at 08:30:00 UTC.
(This is on amd64)
Here's the backtrace from gdb:
[snip]
#8 0x80333415 in pool_drain (ppp=ppp@entry=0xfe810f528e30)
at /build/netbsd-local/src/sys/kern/subr_pool.c:1429
#9 0x802d1791 in uvm_pageout (arg=)
at /build/netbsd-local/src/sys/uvm/uvm_pdaemon.c:343
#10 0x80100807 in lwp_trampoline ()
#11 0x in ?? ()
(gdb) fr 8
#8 0x80333415 in pool_drain (ppp=ppp@entry=0xfe810f528e30)
at /build/netbsd-local/src/sys/kern/subr_pool.c:1429
1429if (drainpp == NULL) {
(gdb) disass pool_drain
This looks like one of the crashes riz@ had on a tegra which I think was also
building packages.
I'm still working on a bisect - so far I have confirmed that the issue
occurs at least as far back as Oct 10, possibly longer.
My "reproduction" involves building a large number of packages, one at
a time, with MAKE_JOBS=3. At first I wasn't paying much attention, but
all of the crashes I specifically remember were on the 359th package,
www/firefox !
=> 0x80333415 <+59>:mov (%rax),%rdx
I think %rax will be "weird" and indicate pool_head list corruption - no idea
why, though.
%rax looks reasonable:
(gdb) info reg
rax0x8099fb40 -2137392320
rbx0x0 0
rcx0x80724880 -2139993984
rdx0x0 0
...
and matches the value reported for drainpp
(gdb) print drainpp
$1 = (struct pool *) 0x8099fb40
and which also matches the tailq's tqh_last
$3 = {tqh_first = 0x80724880 ,
tqh_last = 0x8099fb40}
However, it seems that something has been badly corrupted:
(gdb) print *drainpp
Cannot access memory at address 0x8099fb40
+--+--+-+
| 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: Crash on -current in pool_drain()
On 10/18/15 00:30, Paul Goyette wrote:
Under heavy load, and after several hours of building packages, I am
seeing the following crash. I'm doing a bisect to narrow down more,
but it has been happening at least a week ago, with kernel and all
modules build from sources updated on 2015-10-13 at 08:30:00 UTC.
(This is on amd64)
Here's the backtrace from gdb:
[snip]
#8 0x80333415 in pool_drain (ppp=ppp@entry=0xfe810f528e30)
at /build/netbsd-local/src/sys/kern/subr_pool.c:1429
#9 0x802d1791 in uvm_pageout (arg=)
at /build/netbsd-local/src/sys/uvm/uvm_pdaemon.c:343
#10 0x80100807 in lwp_trampoline ()
#11 0x in ?? ()
(gdb) fr 8
#8 0x80333415 in pool_drain (ppp=ppp@entry=0xfe810f528e30)
at /build/netbsd-local/src/sys/kern/subr_pool.c:1429
1429if (drainpp == NULL) {
(gdb) disass pool_drain
This looks like one of the crashes riz@ had on a tegra which I think was
also
building packages.
=> 0x80333415 <+59>:mov (%rax),%rdx
I think %rax will be "weird" and indicate pool_head list corruption - no
idea why, though.
Nick
