panic running include/t_paths
Hello, since a few days, anita Xen tests of HEAD panics on include/t_paths: include/t_paths (42/618): 1 test cases paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe fatal page fault in supervisor mode trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300 curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0 panic: trap cpu0: Begin traceback... vpanic(c04f0421,cdb5ac58,cdb5acdc,c03d4c06,c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246) at netbsd:vpanic+0x11a panic(c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246,0,0,4300,cdb5ace8) at netbsd:panic+0x18 trap() at netbsd:trap+0xbe6 --- trap (number 6) --- sysmonopen(4300,0,1,2000,c17d1a80,0,c11e8e50,c11f18f0,43,c0d8a780) at netbsd:sysmonopen+0x8a spec_open(cdb5adb8,cdb5aea4,cdb5aecc,c04b9874,c11f18f0,1,c0d8a780,c104c000,cdb5ae80,c04522c5) at netbsd:spec_open+0x1ec VOP_OPEN(c11f18f0,1,c0d8a780,c0d8fcc0,cdb5ae08,c0d8a780,c0596f80,cdb5ae18,c023626d,c1766d00) at netbsd:VOP_OPEN+0x32 vn_open(cdb5aea4,1,160,cdb5aeb8,c0edc1c0,c1755200,3,0,c1879200,c1075400) at netbsd:vn_open+0x1f5 do_open(c17d1a80,0,c1879200,0,8049362,cdb5af38,0,c1879200,c17d1a80,cdb5afa8) at netbsd:do_open+0xc0 do_sys_openat(0,8049362,cdb5af38,c057fbcc,cdb5af9c,c03aade3,c17d1a80,cdb5af68,cdb5af60,c159881c) at netbsd:do_sys_openat+0x6f sys_open(c17d1a80,cdb5af68,cdb5af60,c159881c,cdb5afa0,c0586964,cdb5af68,0,0,8049362) at netbsd:sys_open+0x2c syscall() at netbsd:syscall+0x83 --- syscall (number 5) --- bb683b07: cpu0: End traceback... This showed up between -04-23 09:30 UTC and 2015-04-24 13:10 UTC The sysmonopen() in the stack trace could point to sysmon; could the recent work on sysmon be the cause of this ? -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
netbsd-7 kernel build failure
A netbsd-7 kernel build from today's sources with -Os errors out with # compile P3B-F/drmfb_pci.o /u/netbsd-builds/7/i386/tools/bin/i486--netbsdelf-gcc -msoft-float -mno-mmx -mno-sse -mno-avx -ffreestanding -fno-zero-initialized-in-bss -pipe -Os -march=pentium3 -fstack-protector -Wstack-protector --param ssp-buffer-size=1 -fno-strict-aliasing -fno-common -std=gnu99 -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wold-style-definition -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Wold-style-definition -Wno-sign-compare --sysroot=/u/netbsd-builds/7/i386/destdir -Di386 -I. -I/public/netbsd-7/sys/../common/include -I/public/netbsd-7/sys/arch -I/public/netbsd-7/sys -nostdinc -DP1003_1B_SEMAPHORE -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT -std=gnu99 -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/quad -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/string -I/public/netbsd-7/sys/lib/libkern/../../../common/lib/libc/arch/i386/string -D_FORTIFY_SOURCE=2 -I/public/netbsd-7/sys/external/bsd/drm2/include -I/public/netbsd-7/sys/external/bsd/common/include -I/public/netbsd-7/sys/external/bsd/drm2/include -I/public/netbsd-7/sys/external/bsd/drm2/include/drm -I/public/netbsd-7/sys/external/bsd/drm2/dist -I/public/netbsd-7/sys/external/bsd/drm2/dist/include -I/public/netbsd-7/sys/external/bsd/drm2/dist/include/drm -I/public/netbsd-7/sys/external/bsd/drm2/dist/uapi -I/public/netbsd-7/sys/external/bsd/common/include -D__KERNEL__ -I/public/netbsd-7/sys/../common/include -DCONFIG_AGP -I/public/netbsd-7/sys/external/bsd/drm2/dist/drm/i915 -I/public/netbsd-7/sys/external/bsd/drm2/i915drm -DCONFIG_DRM_I915_FBDEV -I/public/netbsd-7/sys/external/bsd/drm2/dist/drm/radeon -I/public/netbsd-7/sys/external/bsd/drm2/include/radeon -I/public/netbsd-7/sys/external/bsd/drm2/radeon -I/public/netbsd-7/sys/external/bsd/acpica/dist/include -c /public/netbsd-7/sys/external/bsd/drm2/pci/drmfb_pci.c --- drm_scatter.o --- /public/netbsd-7/sys/external/bsd/drm2/drm/drm_scatter.c: In function 'drm_sg_alloc': /public/netbsd-7/sys/external/bsd/drm2/drm/drm_scatter.c:83:10: error: 'sg' may be used uninitialized in this function [-Werror=maybe-uninitialized] dev-sg = sg; ^ cc1: all warnings being treated as errors *** [drm_scatter.o] Error code 1 nbmake: stopped in /var/obj/netbsd-builds/7/i386/sys/arch/i386/compile/P3B-F 1 error drm_sg_alloc_mem() sets up sg, but the compiler cannot know, I guess. hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in email Institut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-3281
Re: netbsd-7 kernel build failure
On Mon, 04 May 2015 16:18:42 +0200, Hauke Fath wrote: A netbsd-7 kernel build from today's sources with -Os errors out with [...] ... and a few more. Looks like '-Os' applies slightly different criteria than '-O2' to what gcc perceives as an unused variable. The question is - should we care? In the files I patched, initializing the variable clarified things, but that clarity lies in the eyes of the beholder... hauke -- The ASCII Ribbon CampaignHauke Fath () No HTML/RTF in emailInstitut für Nachrichtentechnik /\ No Word docs in email TU Darmstadt Respect for open standards Ruf +49-6151-16-3281
USB stick image for snapshots
Hello, on ftp://nyftp.netbsd.org/pub/NetBSD-daily ISO images of snapshots (e.g. named boot.iso) can be found. Would it be possible to also add something like boot.img which can be copied to a USB stick? If one often installs new snaphots on bare metal it is more comfortable to use a USB stick than burning a CD every time. Or is there a script which converts the ISO image to a USB image? I did follow the instructions on https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/ but it didn't work. E.g. there is no file named netbsd-INSTALL.gz and no directory named sets on the CD image. Carsten
Re: USB stick image for snapshots
On Mon, May 04, 2015 at 06:00:43PM +0200, carsten.ku...@arcor.de wrote: Hello, on ftp://nyftp.netbsd.org/pub/NetBSD-daily ISO images of snapshots (e.g. named boot.iso) can be found. Would it be possible to also add something like boot.img which can be copied to a USB stick? If one often installs new snaphots on bare metal it is more comfortable to use a USB stick than burning a CD every time. On most machines it works to just dd the .iso to the usb stick. Martin
Re: Recent sysmon changes
On Sun, Apr 26, 2015 at 07:59:11AM +0800, Paul Goyette wrote: Apologies to everyone for any inconvenience caused by the recent changes to sysmon. With the help of many, I think that we've identified and fixed all of the fallout during initialization. If any further issues are found, please let me know and I'll get them fixed as quickly as I can. Panics from Xen guests could be related to your changes: http://www-soc.lip6.fr/~bouyer/NetBSD-tests/xen/HEAD/ the trace shows: include/t_paths (42/618): 1 test cases paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe fatal page fault in supervisor mode trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300 curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0 panic: trap cpu0: Begin traceback... vpanic(c04f0421,cdb5ac58,cdb5acdc,c03d4c06,c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246) at netbsd:vpanic+0x11a panic(c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246,0,0,4300,cdb5ace8) at netbsd:panic+0x18 trap() at netbsd:trap+0xbe6 --- trap (number 6) --- sysmonopen(4300,0,1,2000,c17d1a80,0,c11e8e50,c11f18f0,43,c0d8a780) at netbsd:sysmonopen+0x8a spec_open(cdb5adb8,cdb5aea4,cdb5aecc,c04b9874,c11f18f0,1,c0d8a780,c104c000,cdb5ae80,c04522c5) at netbsd:spec_open+0x1ec VOP_OPEN(c11f18f0,1,c0d8a780,c0d8fcc0,cdb5ae08,c0d8a780,c0596f80,cdb5ae18,c023626d,c1766d00) at netbsd:VOP_OPEN+0x32 vn_open(cdb5aea4,1,160,cdb5aeb8,c0edc1c0,c1755200,3,0,c1879200,c1075400) at netbsd:vn_open+0x1f5 do_open(c17d1a80,0,c1879200,0,8049362,cdb5af38,0,c1879200,c17d1a80,cdb5afa8) at netbsd:do_open+0xc0 do_sys_openat(0,8049362,cdb5af38,c057fbcc,cdb5af9c,c03aade3,c17d1a80,cdb5af68,cdb5af60,c159881c) at netbsd:do_sys_openat+0x6f sys_open(c17d1a80,cdb5af68,cdb5af60,c159881c,cdb5afa0,c0586964,cdb5af68,0,0,8049362) at netbsd:sys_open+0x2c syscall() at netbsd:syscall+0x83 --- syscall (number 5) --- -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: why does dk(4) take precedence in boot device selection???
On Fri, Apr 24, 2015 at 12:07:06AM -0700, Greg A. Woods wrote: [...] 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 For Xen dom0, the boot loader doens't provide any information about the boot device (remember that the booted kernel is not NetBSD but Xen in this case - NetBSD is a module provided to Xen). If you don't specify a root= option in the boot loader configuration, the NetBSD kernel will use the first disk device from its list (or something like that). To avoid problems like that you should always specify a root= option to a NetSBD/Xen dom0 boot. -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Aw: Re: USB stick image for snapshots
On most machines it works to just dd the .iso to the usb stick. Unfortunately it does not work on my machine. It does recognize the USB stick as a floppy disk, then fails to boot it. So again--could a boot.img could be provided e.g. for some mainstream ports like amd64? Or a conversion script? Carsten
Re: why does dk(4) take precedence in boot device selection???
bou...@antioche.eu.org (Manuel Bouyer) writes: To avoid problems like that you should always specify a root= option to a NetSBD/Xen dom0 boot. It would be certainly useful if all kernels allowed some kind of root= option, but currently the boot parameters are almost all some historic machine-dependent binary structure and some machine-dependent interpreter or parser of that data. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: netbsd-7 kernel build failure
On Mon, May 04, 2015 at 05:30:17PM +0200, Hauke Fath wrote: Looks like '-Os' applies slightly different criteria than '-O2' to what gcc perceives as an unused variable. Congratulation, you discovered one of the biggest bugs in GCC's unused variable warning. Joerg
Re: USB stick image for snapshots
On 2015-05-04 18:00, carsten.ku...@arcor.de wrote: Hello, on ftp://nyftp.netbsd.org/pub/NetBSD-daily ISO images of snapshots (e.g. named boot.iso) can be found. Would it be possible to also add something like boot.img which can be copied to a USB stick? If one often installs new snaphots on bare metal it is more comfortable to use a USB stick than burning a CD every time. Or is there a script which converts the ISO image to a USB image? I did follow the instructions on https://wiki.netbsd.org/tutorials/how_to_install_netbsd_from_an_usb_memory_stick/ but it didn't work. E.g. there is no file named netbsd-INSTALL.gz and no directory named sets on the CD image. Carsten If you're ok to download the full installation sets, e.g. you could use these ones: ftp://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201505031900Z/images/NetBSD-7.0_BETA-amd64-install.img.gz ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201505041130Z/images/NetBSD-7.99.15-amd64-install.img.gz In the past, they worked for me on a USB stick.
Re: why does dk(4) take precedence in boot device selection???
On Mon, May 04, 2015 at 05:58:54PM +, Michael van Elst wrote: bou...@antioche.eu.org (Manuel Bouyer) writes: To avoid problems like that you should always specify a root= option to a NetSBD/Xen dom0 boot. It would be certainly useful if all kernels allowed some kind of root= option, but currently the boot parameters are almost all some historic machine-dependent binary structure and some machine-dependent interpreter or parser of that data. You're probably right, but how is it relevant to my message ? -- Manuel Bouyer bou...@antioche.eu.org NetBSD: 26 ans d'experience feront toujours la difference --
Re: Install over FTP: DNS lookup problem
carsten.ku...@arcor.de writes: I try to install 201504051500Z/amd64/installation/cdrom/boot.iso. After network config FTP install says: ftp: Can't lookup 'ftp.netbsd.org:ftp': Temporary failure in name resolution Name server is 8.8.8.8 Ping works. What can be the problem? That's a bug in the installation routines. dhcpcd conflicts with the manual entry of the nameserver because it overwrites /etc/resolv.conf. As a workaround either don't use DHCP for installation or kill dhcpcd when it has configured the network. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Re: Problem with cgdconfig
carsten.ku...@arcor.de writes: if I encrypt a device with cgdconfig -V re-enter cgd1 /dev/wd0e then unconfigure it: cgdconfig -u cgd1 and then try to decrypt it: cgdconfig cgd1 /dev/wd0e The password is not excepted. What can be the reason? The only way to verify password is to see if the decrypted disk contains valid information. By default cgd checks for a valid disklabel. But if you never write a disklabel to your encrypted disk (using the disklabel command), then that check fails. N.B. cgd can also check for GPT labels or a valid FFS superblock if you don't want to use a disklabel. -- -- Michael van Elst Internet: mlel...@serpens.de A potential Snark may lurk in every tree.
Aw: Re: USB stick image for snapshots
Hi Travis and Joachim, If you're ok to download the full installation sets, e.g. you could use these ones: ftp://nyftp.netbsd.org/pub/NetBSD-daily/netbsd-7/201505031900Z/images/NetBSD -7.0_BETA-amd64-install.img.gz ftp://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201505041130Z/images/NetBSD-7.9 9.15-amd64-install.img.gz In the past, they worked for me on a USB stick. I've overlooked the directory images. When I opened .../HEAD/201505041130Z I saw amd64 and searched there for the image. Thank you for the correct link! Carsten
Re: panic running include/t_paths
On Mon, 4 May 2015, Manuel Bouyer wrote: Hello, since a few days, anita Xen tests of HEAD panics on include/t_paths: include/t_paths (42/618): 1 test cases paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe fatal page fault in supervisor mode trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300 curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0 panic: trap cpu0: Begin traceback... vpanic(c04f0421,cdb5ac58,cdb5acdc,c03d4c06,c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246) at netbsd:vpanic+0x11a panic(c04f0421,cdb5ace8,cdb5ace8,1,cdb582c0,10246,0,0,4300,cdb5ace8) at netbsd:panic+0x18 trap() at netbsd:trap+0xbe6 --- trap (number 6) --- sysmonopen(4300,0,1,2000,c17d1a80,0,c11e8e50,c11f18f0,43,c0d8a780) at netbsd:sysmonopen+0x8a spec_open(cdb5adb8,cdb5aea4,cdb5aecc,c04b9874,c11f18f0,1,c0d8a780,c104c000,cdb5ae80,c04522c5) at netbsd:spec_open+0x1ec VOP_OPEN(c11f18f0,1,c0d8a780,c0d8fcc0,cdb5ae08,c0d8a780,c0596f80,cdb5ae18,c023626d,c1766d00) at netbsd:VOP_OPEN+0x32 vn_open(cdb5aea4,1,160,cdb5aeb8,c0edc1c0,c1755200,3,0,c1879200,c1075400) at netbsd:vn_open+0x1f5 do_open(c17d1a80,0,c1879200,0,8049362,cdb5af38,0,c1879200,c17d1a80,cdb5afa8) at netbsd:do_open+0xc0 do_sys_openat(0,8049362,cdb5af38,c057fbcc,cdb5af9c,c03aade3,c17d1a80,cdb5af68,cdb5af60,c159881c) at netbsd:do_sys_openat+0x6f sys_open(c17d1a80,cdb5af68,cdb5af60,c159881c,cdb5afa0,c0586964,cdb5af68,0,0,8049362) at netbsd:sys_open+0x2c syscall() at netbsd:syscall+0x83 --- syscall (number 5) --- bb683b07: cpu0: End traceback... This showed up between -04-23 09:30 UTC and 2015-04-24 13:10 UTC The sysmonopen() in the stack trace could point to sysmon; could the recent work on sysmon be the cause of this ? Quite likely. Let me see if I can figure out what it happening, and how the xen test environment differs from the qemu environment. - | 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: panic running include/t_paths
On Mon, 4 May 2015, Manuel Bouyer wrote:
Hello,
since a few days, anita Xen tests of HEAD panics on
include/t_paths:
include/t_paths (42/618): 1 test cases
paths: uvm_fault(0xc15ef0dc, 0, 1) - 0xe
fatal page fault in supervisor mode
trap type 6 code 0 eip c03ab50a cs 9 eflags 10246 cr2 0 ilevel 0 esp 4300
curlwp 0xc17d1a80 pid 24550 lid 1 lowest kstack 0xcdb582c0
panic: trap
snip
OK, I think I found this one!
It seems that when sysmonopen() is called, it might need to autoload the
module that handles the specific sub-comopnent (envsys, power, or wdog).
But if the autoload failed, the code blindly proceeded to call the
sub-component's open routine anyway (indirectly through the sysmon_opvec
table). Since autoload had failed, the opvec entry was never loaded and
we jumped off into never-never land. :)
I've fixed the code to just return the error code ENODEV if autoload
fails.
The include/t_paths test will likely still fail, since it won't be able
to open /dev/{sysmon,power,wdog} paths. But at least it shouldn't panic
any more.
-
| 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 |
-
