Re: RFC: mpsafe bridge and NIC drivers (vioif and wm)
No comment or objection? Then, I'll commit the patch tomorrow. ozaki-r On Wed, Jul 9, 2014 at 12:55 PM, Ryota Ozaki ozak...@iij.ad.jp wrote: On Tue, Jul 8, 2014 at 12:54 PM, Ryota Ozaki ozak...@iij.ad.jp wrote: Hi, A new patch has come: http://www.netbsd.org/~ozaki-r/mpsafe-bridge.diff I confirmed the patch doesn't add new failures in both NET_MPSAFE and non-NET_MPSAFE cases. ozaki-r The patch makes bridge forwarding MPSAFE. As same as wm, it introduces BRIDGE_MPSAFE to switch MPSAFE and non-MPSAFE codes. However, in the case of bridge, some locking codes are always enabled to reduce ifdef switches. I think it's not a problem because the codes are not performance critical. And also some splnet are still there for the same reason. Another note is about bif (bridge member list entry) object reference counting. It enables fine-grain locking for bridge member lists by allowing to not hold a lock during touching a bif. In order to do so, bridge_release_member is added to decrement the reference count and a condition variable to do bridge_delete_member graceful. You can try the patch with MPSAFE enabled by defining NET_MPSAFE in if.h or your kernel config file. If your machine has Intel 1G NICs (wm), by applying a patch(*), you can see bridge_forward running in parallel. (*) https://github.com/ozaki-r/netbsd-src/commit/2879f184e336376574c7a07d9ab34d9d55449a7b Have fun, ozaki-r
Automated report: NetBSD-current/i386 build failure
This is an automatically generated notice of a NetBSD-current/i386 build failure. The failure occurred on babylon5.NetBSD.org, a NetBSD/amd64 host, using sources from CVS date 2014.07.13.14.56.56. An extract from the build.sh output follows: Source directory: /tmp/bracket/build/2014.07.13.14.56.56-i386/src Target directory: /tmp/bracket/build/2014.07.13.14.56.56-i386/destdir/ obsolete_stand fix: postinstall fixes passed: obsolete_stand postinstall fixes failed: === checkflist === distrib/sets --- check_DESTDIR --- --- checkflist --- cd /tmp/bracket/build/2014.07.13.14.56.56-i386/src/distrib/sets DESTDIR=/tmp/bracket/build/2014.07.13.14.56.56-i386/destdir MACHINE=i386 MACHINE_ARCH=i386 AWK=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbawk CKSUM=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbcksum DB=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbdb HOST_SH=/bin/sh MAKE=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbmake MKTEMP=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbmktemp MTREE=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbmtree PAX=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbpax COMPRESS_PROGRAM=gzip GZIP=-n PKG_CREATE=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbpkg_create SED=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbsed TSORT=/tmp/bracket/build/2014.07.13.14.56.56-i386/tools/bin/nbtsort\ -q /bin/sh /tmp/bracket/build/2014.07.13.14.56.56-i386/src/distrib/sets/checkflist -L base -M /tmp/bracket/build/2014.07.13.14.56.56-i386/destdir/METALOG.sanitised == 5 missing files in DESTDIR Files in flist but missing from DESTDIR. File wasn't installed ? -- ./usr/share/wscons/keymaps/pckbd.bg.bds.cp1251 ./usr/share/wscons/keymaps/pckbd.bg.bds.iso8859-5 ./usr/share/wscons/keymaps/pckbd.bg.qwerty.cp1251 ./usr/share/wscons/keymaps/pckbd.bg.qwerty.iso8859-5 ./usr/share/wscons/keymaps/pckbd.bg.qwerty.koi8-r end of 5 missing files == *** [checkflist] Error code 1 nbmake[2]: stopped in /tmp/bracket/build/2014.07.13.14.56.56-i386/src/distrib/sets 1 error The following commits were made between the last successful build and the failed build: 2014.07.13.12.04.07 wiz src/share/man/man4/asus.4,v 1.2 2014.07.13.12.08.32 wiz src/share/man/man4/acpi.4,v 1.77 2014.07.13.12.15.45 martin src/distrib/sets/lists/debug/ad.arm,v 1.37 2014.07.13.12.15.45 martin src/distrib/sets/lists/debug/ad.mips,v 1.33 2014.07.13.12.15.45 martin src/distrib/sets/lists/debug/ad.powerpc,v 1.13 2014.07.13.12.15.45 martin src/distrib/sets/lists/debug/md.sparc64,v 1.56 2014.07.13.12.29.01 mbalmer src/distrib/sets/lists/base/mi,v 1.1073 2014.07.13.12.29.01 mbalmer src/share/wscons/keymaps/pckbd.bg.bds.cp1251,v 1.1 2014.07.13.12.29.01 mbalmer src/share/wscons/keymaps/pckbd.bg.bds.iso8859-5,v 1.1 2014.07.13.12.29.01 mbalmer src/share/wscons/keymaps/pckbd.bg.qwerty.cp1251,v 1.1 2014.07.13.12.29.01 mbalmer src/share/wscons/keymaps/pckbd.bg.qwerty.iso8859-5,v 1.1 2014.07.13.12.29.01 mbalmer src/share/wscons/keymaps/pckbd.bg.qwerty.koi8-r,v 1.1 2014.07.13.12.47.13 mbalmer src/share/man/man4/netintro.4,v 1.28 2014.07.13.13.53.59 martin src/distrib/sets/lists/debug/ad.arm,v 1.38 2014.07.13.13.53.59 martin src/distrib/sets/lists/debug/ad.mips,v 1.34 2014.07.13.13.53.59 martin src/distrib/sets/lists/debug/ad.powerpc,v 1.14 2014.07.13.13.53.59 martin src/distrib/sets/lists/debug/md.sparc64,v 1.57 2014.07.13.14.54.22 christos src/external/bsd/bind/lib/libirs/Makefile,v 1.2 2014.07.13.14.56.56 christos src/external/bsd/dhcp/dist/includes/config.h.in,v 1.2 2014.07.13.14.56.56 christos src/external/bsd/dhcp/include/config.h,v 1.6 Log files can be found at: http://releng.NetBSD.org/b5reports/i386/commits-2014.07.html#2014.07.13.14.56.56
Issues with i915drmkms on AMD64
Today I've attempted to try out the new i915drmkms support on NetBSD 6.99.47-CURRENT. I've built the DRMKMS kernel conf and installed its modules, and attempted to boot. Unfortunately, despite having all relevant debug options checked, it seems that NetBSD kernel simply freezes after displaying the line: i915drmkms0 at pci0 dev 2 function 0 [...] I've also tried the prebuilt kernel from Nonaka at http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/drmkms/ which did not work either, except in its case, the screen was blanked and then froze. On the other hand, gsutre's DRMGEM *does* work fine. This is on a ThinkPad T410 with an i5-560m CPU and Intel IronLake HD Graphics.
Preparation for creating netbsd-7 branch
On behalf of the release engineering team, I am happy to announce that the release process for NetBSD 7.0 is now underway. We will be creating the netbsd-7 CVS branch on or about July 26th, just under two weeks from today. The creation of this branch will mark the start of the Beta period, which is expected to last into September. Between now and branch time, our focus is on fixing bugs, updating documentation, and ensuring that the basics (build, installation, boot) work on as many platforms as possible. How can you help? Glad you asked! 1. Please make sure NetBSD-current can be installed and boots on hardware (or software emulators) you care about, it in your preferred configuration. *This is especially important for users of unusual or embedded hardware*. The latest builds, as always, can be downloaded from http://releng.netbsd.org/cgi-bin/builds.cgi - it's the HEAD builds we care about until branch time. If you encounter problems, please report them via send-pr (see http://www.netbsd.org/support/send-pr.html ), or at least a quick note to current-users. 2. Help to update documentation and release notes! The release notes for NetBSD are in the src tree, in src/distrib/notes [1]. As of this writing, many of those notes have not changed since the NetBSD 6.0 release - any patches against these release notes would be gratefully accepted. 3. Fix bugs that you find! Send-pr with minor fixes, whatever you've got. A more formal announcement will be made when the first beta binaries are available - in approximately two weeks. [1] These notes are written in *roff mdoc. The *most* helpful thing is to provide patches against this code, but if you just want to provide updated text against, say, http://nyftp.netbsd.org/pub/NetBSD-daily/HEAD/201407131140Z/amd64/INSTALL.html (this link will disappear in the next few days, but the latest snapshot always has the latest notes) - that would be helpful, too.
Re: Issues with i915drmkms on AMD64
On 7/13/14, 11:28 AM, David Mackay wrote: Today I've attempted to try out the new i915drmkms support on NetBSD 6.99.47-CURRENT. I've built the DRMKMS kernel conf and installed its modules, and attempted to boot. Unfortunately, despite having all relevant debug options checked, it seems that NetBSD kernel simply freezes after displaying the line: i915drmkms0 at pci0 dev 2 function 0 [...] There was a change checked in very recently (less than 18h) which fixed this for me: http://mail-index.netbsd.org/source-changes/2014/07/13/msg056288.html - make sure the kernel you're using was built with this change. I've also tried the prebuilt kernel from Nonaka at http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/drmkms/ which did not work either, except in its case, the screen was blanked and then froze. On the other hand, gsutre's DRMGEM *does* work fine. This is on a ThinkPad T410 with an i5-560m CPU and Intel IronLake HD Graphics.
Re: Multiple NetBSD targets using the same OBJDIR
For the time being, I have decided to create a custom shell script in the spirit of etcmanage, after looking over BUILD-NetBSD; perhaps an INSTALL-NETBSD custom shell script will follow. I do a large amount of cross-building (my NetBSD compiling box is an Ubuntu machine), and I'm not sure how easy it is to use use etcmanage on a Linux host, where the only access to the target NetBSD's /etc files would either be SSHFS, SMB, FTP, or NFS. This is probably overkill, but this m4 script generates a number of variables which can be used to start a ./build.sh session where directories are separated based on target. It current supports rebuilding from scratch and updating after cvs update/git pull. The script also supports choosing MAKECONF and the kernel to be compiled. The script assumes the tools directory already exists, but this is okay, since the same tools directory can be used for all possible targets. m4 is used to reduce the chance I make a mistake on a per-architecture basis. https://gist.github.com/cr1901/07b8e6810caedc31fe7c Hopefully this is useful to somebody... and since it's a gist, it can be forked as well :P. - Original Message - From: Greg Troxel g...@ir.bbn.com To: thor0...@comcast.net Cc: current-users@netbsd.org Sent: Saturday, July 12, 2014 10:54:21 AM Subject: Re: Multiple NetBSD targets using the same OBJDIR thor0...@comcast.net writes: I have a need to build NetBSD for multiple architectures using the same source tree. While I understand that one can use the same tools This is normal. directory for all possible targets, I have not found an option to separate objects, releasedir, and destdir according to the target or some chosen ID (I also have the need to build NetBSD for the same architecture in two different configurations). If you set all of those, you can separate the builds. But what configuration are you changing, and does that result in changes to the tree, or are you passing a different mk.conf, or something else? See pkgsrc/sysutils/etcmanage for the scripts I use, which are aimed at having a source tree per branch and organizing tool/obj/release/dest directories in a way I like. If you want to pass different mk.conf files and have different paths, that should be pretty easy. The basic hint is to not insist on passing one argument, and accept that you will set multiple options. My script invokes build.sh as ./build.sh -m i386 -j8 -x -u -U -O /usr/obj/gdt-current/i386 -T /usr/obj/gdt-current/tools -D /usr/obj/gdt-current/destdir/i386 -R /usr/obj/gdt-current/releasedir -X /u0/n0/gdt/NetBSD-current/xsrc release which sets 4 output options in a way that I the human find consistent. Arguably I should change -O to make it objdir/i386; there's no good reason to have the per-arch objdirs not in a container.
Add Firmware images to INSTALL kernels
Hello all, Although my question is specific to the Raspberry Pi, I can imagine anyone who has specific network cards- or hardware requiring firmware during installation- asking this question. I have a Raspberry Pi Model A, which does not contain onboard Ethernet. In order to get a network connection, I use a USB dongle which is supported by the urtwn device driver. When I boot an install kernel, my urtwn hardware is recognized, but the interface cannot be brought up because the firmware is missing. This prevents me from reliably continuing an install; as of at least yesterday, mounting devices in the RPI kernel is broken (will file a PR in the next few hours if I can't duplicate the issue in the current HEAD), so grabbing local sets from a mounted drive is impossible. According to http://www.daemon-systems.org/man/urtwn.4.html, the firmware for urtwn needs to be installed in /libdata/firmware/if_urtwn/rtl8192cfw.bin when bringing up a network interface. So far, I have not found a way to customize install images to add the firmware into the install image/ramdisk by reviewing the source over the past hour. In fact, I have not found any information in manual pages or the mailing list about whether there is a documented way of adding firmware or extra files to an installation, beyond having the option to choose MAKEDEV targets in the obsolete i386 bootfloppy-tiny floppies. Editing $SRC_ROOT/distrib/evbarm/instkernel/sshramdisk/mtree.conf seems to be the way to add the relevant directory into the ramdisk. However, is there a way to tell ./build.sh or the Makefiles to add the relevant firmware as well into these directories? Is modifying the source to sysinst (which I know can be used to change the default kernel's name in the install prompt) the only way of adding this feature? Again, thanks for any help anyone can give me! Sincerely, William D. Jones
Re: Add Firmware images to INSTALL kernels
On Sun, Jul 13, 2014 at 09:43:50PM +, thor0...@comcast.net wrote: Editing $SRC_ROOT/distrib/evbarm/instkernel/sshramdisk/mtree.conf seems to be the way to add the relevant directory into the ramdisk. However, is there a way to tell ./build.sh or the Makefiles to add the relevant firmware as well into these directories? The list file in the same directory is what you are looking for. Martin
Re: Add Firmware images to INSTALL kernels
The list file in the same directory is what you are looking for.
Beautiful, thanks! I notice that the standard RAMdisks are missing the
mtree.conf file. Is altering the list file alone enough to add directories to
the standard RAMdisk (not sshramdisk*), or do I have to create my own
mtree.conf as well (assuming the directory structure of the standard RAMdisk
set somewhere else)?
This would make upgrading (contrast to initial install) easier if I can just
download the install kernel from the build machine to the target machine,
reboot, and then install using sysinst with a kernel/ramdisk that contains the
firmware.
*I altered both mtree.conf to add the libdata subtree, and lists to tell
./build.sh/make to copy the firmware:
COPY${NETBSDSRCDIR}/external/realtek/urtwn/dist/rtl8192cfw.bin
libdata/firmware/if_urtwn/rtl8192cfw.bin
Re: Issues with i915drmkms on AMD64
I've updated my sources to include this change. Unfortunately, it has not made a difference. Thanks for letting me know about it, though. On Sun, Jul 13, 2014 at 8:18 PM, Jeff Rizzo r...@tastylime.net wrote: On 7/13/14, 11:28 AM, David Mackay wrote: Today I've attempted to try out the new i915drmkms support on NetBSD 6.99.47-CURRENT. I've built the DRMKMS kernel conf and installed its modules, and attempted to boot. Unfortunately, despite having all relevant debug options checked, it seems that NetBSD kernel simply freezes after displaying the line: i915drmkms0 at pci0 dev 2 function 0 [...] There was a change checked in very recently (less than 18h) which fixed this for me: http://mail-index.netbsd.org/source-changes/2014/07/13/msg056288.html - make sure the kernel you're using was built with this change. I've also tried the prebuilt kernel from Nonaka at http://ftp.netbsd.org/pub/NetBSD/misc/nonaka/drmkms/ which did not work either, except in its case, the screen was blanked and then froze. On the other hand, gsutre's DRMGEM *does* work fine. This is on a ThinkPad T410 with an i5-560m CPU and Intel IronLake HD Graphics.
daily CVS update output
Updating src tree: P src/distrib/sets/lists/base/mi P src/distrib/sets/lists/debug/ad.arm P src/distrib/sets/lists/debug/ad.mips P src/distrib/sets/lists/debug/ad.powerpc P src/distrib/sets/lists/debug/md.sparc64 P src/distrib/sets/lists/man/mi P src/etc/rc.d/named P src/external/bsd/bind/dist/configure P src/external/bsd/bind/dist/configure.in P src/external/bsd/bind/include/config.h P src/external/bsd/bind/lib/libirs/Makefile P src/external/bsd/dhcp/dist/includes/config.h.in P src/external/bsd/dhcp/include/config.h P src/external/mit/xorg/bin/xauth/Makefile P src/external/mit/xorg/lib/Makefile P src/external/mit/xorg/lib/dri/i965/Makefile P src/external/mit/xorg/lib/dri/libmesa/Makefile P src/external/mit/xorg/lib/dri/r600/Makefile P src/external/mit/xorg/lib/libGLU/Makefile P src/external/mit/xorg/lib/libOSMesa/Makefile P src/external/mit/xorg/lib/libdrm_radeon/Makefile P src/games/tetris/screen.c P src/games/tetris/tetris.6 P src/games/tetris/tetris.c P src/games/tetris/tetris.h P src/share/man/man4/Makefile P src/share/man/man4/acpi.4 U src/share/man/man4/asus.4 P src/share/man/man4/netintro.4 P src/share/man/man7/tests.atf.7 P src/share/man/man9/audio.9 P src/share/man/man9/cardbus.9 P src/share/misc/airport P src/share/wscons/keymaps/Makefile U src/share/wscons/keymaps/pckbd.bg.bds.cp1251 U src/share/wscons/keymaps/pckbd.bg.bds.iso8859-5 U src/share/wscons/keymaps/pckbd.bg.qwerty.cp1251 U src/share/wscons/keymaps/pckbd.bg.qwerty.iso8859-5 U src/share/wscons/keymaps/pckbd.bg.qwerty.koi8-r P src/sys/arch/arm/cortina/files.g2 P src/sys/arch/arm/include/int_types.h P src/sys/arch/luna68k/dev/lunafb.c P src/sys/arch/sgimips/hpc/pi1ppc.c P src/sys/arch/sparc64/sparc64/locore.s P src/sys/dev/ic/atppc.c P src/sys/dev/pci/if_wm.c P src/sys/dev/ppbus/ppbus_1284.c P src/sys/dev/ppbus/ppbus_base.c P src/sys/dev/scsipi/scsipi_base.c P src/sys/dev/scsipi/scsipiconf.h P src/sys/dev/spi/spivar.h P src/sys/dev/usb/xhci.c P src/sys/external/bsd/drm2/dist/drm/i915/intel_display.c P src/sys/miscfs/fdesc/fdesc.h P src/sys/miscfs/fdesc/fdesc_vfsops.c P src/sys/miscfs/fdesc/fdesc_vnops.c P src/sys/net/bpfjit.c P src/sys/net/bridgestp.c P src/sys/net/if.h P src/sys/net/if_bridge.c P src/sys/net/if_bridgevar.h P src/tests/lib/libbpfjit/t_cop.c P src/tests/net/bpfjit/t_cop.c Updating xsrc tree: P xsrc/external/mit/MesaLib/dist/src/glsl/ir.h P xsrc/external/mit/libX11/dist/src/xkb/XKBMAlloc.c Killing core files: Running the SUP scanner: SUP Scan for current starting at Mon Jul 14 03:09:54 2014 SUP Scan for current completed at Mon Jul 14 03:10:58 2014 SUP Scan for mirror starting at Mon Jul 14 03:10:58 2014 SUP Scan for mirror completed at Mon Jul 14 03:13:36 2014 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 Jul 14 03:27:56 2014 SUP Scan for release-5 completed at Mon Jul 14 03:28:02 2014 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 Jul 14 03:34:04 2014 SUP Scan for release-6 completed at Mon Jul 14 03:34:16 2014 Updating file list: -rw-rw-r-- 1 srcmastr netbsd 43758625 Jul 14 03:47 ls-lRA.gz
Re: Add Firmware images to INSTALL kernels
On Sun, Jul 13, 2014 at 10:20:46PM +, thor0...@comcast.net wrote:
*I altered both mtree.conf to add the libdata subtree, and lists
to tell ./build.sh/make to copy the firmware: COPY
${NETBSDSRCDIR}/external/realtek/urtwn/dist/rtl8192cfw.bin
libdata/firmware/if_urtwn/rtl8192cfw.bin
That sounds correct - if it works for you, can you please send a diff -u ?
This should be changed in the main tree (and maybe extended to other
firmwares).
Martin
