Re: lock order reversals w/ backtrace
On Fri, Jan 24, 2014 at 9:52 AM, Thomas Hoffmann wrote: > On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky < > hans.petter.sela...@bitfrost.no> wrote: > >> Hi, >> >> Can you see if you can snap some keywords of the backtraces, like usb_xxx >> usbdx_xxx cam scsi or something like that. >> >> Else I believe there are some sysctl options to prevent the final reboot >> somehow so that you can write down the messages. >> >> --HPS >> >> >> -Original message- >> > From:Thomas Hoffmann >> > Sent: Thursday 23rd January 2014 17:15 >> >> > To: freebsd-current >> > Subject: lock order reversals w/ backtrace >> > >> > A few days ago I started running 11.0-CURRENT at r260971 for the first >> > time. >> >> > >> > The last couple of times I shutdown my system I noticed 2 or 3 short "lock >> > order reversal" messages with accompanying backtraces scroll by. Do these >> > messages represent a problem that I should report or can I ignore them as >> >> > debug in nature? If I should report them, how or where do these messages >> > get logged? I can find no reference to them in syslog or anywhere else upon >> > my subsequent reboot. >> > >> > I also had a couple of these messages pop up the other day while >> >> > mounting/umounting USB thumb drives. I did not think anything of them at >> > the time as the mounts/umounts completed successfully. >> > >> > Please advise. Thanks. >> > >> > -Tom >> >> I managed to snap a photo of my screen during shutdown. > Here is the full text of the first of two lock order reversals I got last > night during system shutdown, both of which are zfs-related to (it > appears?) unmounts. A few lines got chopped as they were out-of-frame when > I took the photo: > > shutting down local daemons: > lock order reversal: > 1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 > 2nd 0xf801194f6420 syncer (syncer) @ > /usr/src/sys/kern/vfs_subr.c:22[..chopped...] > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame > 0xfe01ac78[...chopped...] > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0 > __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810 > vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860 > _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0 > vputx() at vputx+0x240/frame 0xfe01ac784930 > dounmount at dounmount+0x327/frame 0xfe01ac7849b0 > sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0 > --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, > rsp[...chopped...] > > I have a zpool on an external USB HDD that I export at shutdown via > rc.shutdown.local. Don't know if that is contributing to this or not. When > I get a chance to bring down the system I will manually export it before > shutdown to see if that makes any difference. > Was able to capture the full text of the lock order reversal I've been experiencing at shutdown. Turns out to be associated with the export of one of my zpools that is hosted on an external USB HDD. Normally I export the zpool from rc.shutdown.local, but tonight I exported it manually before I shutdown and got the following. lock order reversal: : 1st 0xf8011952b5f0 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 : 2nd 0xf8011952b068 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:2212 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe01add6e5a0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01add6e650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01add6e6e0 __lockmgr_args() at __lockmgr_args+0x878/frame 0xfe01add6e810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01add6e830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01add6e860 _vn_lock() at _vn_lock+0xab/frame 0xfe01add6e8d0 vputx() at vputx+0x240/frame 0xfe01add6e930 dounmount() at dounmount+0x327/frame 0xfe01add6e9b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01add6eae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01add6ebf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01add6ebf0 --- syscall (22, FreeBSD ELF64, sys_unmount), rip = 0x80191c72a, rsp = 0x7fffc4c8, rbp = 0x7fffc960 --- When imported and mounted, the zpool reports no errors and I have not experienced any anomalies reading or writing to the zpool. Should I be concerned? ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[head tinderbox] failure on i386/pc98
TB --- 2014-01-25 02:18:18 - tinderbox 2.20 running on freebsd-current.sentex.ca TB --- 2014-01-25 02:18:18 - FreeBSD freebsd-current.sentex.ca 8.3-PRERELEASE FreeBSD 8.3-PRERELEASE #0: Mon Mar 26 13:54:12 EDT 2012 d...@freebsd-current.sentex.ca:/usr/obj/usr/src/sys/GENERIC amd64 TB --- 2014-01-25 02:18:18 - starting HEAD tinderbox run for i386/pc98 TB --- 2014-01-25 02:18:18 - cleaning the object tree TB --- 2014-01-25 02:18:18 - /usr/local/bin/svn stat /src TB --- 2014-01-25 02:18:35 - At svn revision 261138 TB --- 2014-01-25 02:18:36 - building world TB --- 2014-01-25 02:18:36 - CROSS_BUILD_TESTING=YES TB --- 2014-01-25 02:18:36 - MAKEOBJDIRPREFIX=/obj TB --- 2014-01-25 02:18:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2014-01-25 02:18:36 - SRCCONF=/dev/null TB --- 2014-01-25 02:18:36 - TARGET=pc98 TB --- 2014-01-25 02:18:36 - TARGET_ARCH=i386 TB --- 2014-01-25 02:18:36 - TZ=UTC TB --- 2014-01-25 02:18:36 - __MAKE_CONF=/dev/null TB --- 2014-01-25 02:18:36 - cd /src TB --- 2014-01-25 02:18:36 - /usr/bin/make -B buildworld >>> Building an up-to-date make(1) >>> World build started on Sat Jan 25 02:18:45 UTC 2014 >>> Rebuilding the temporary build tree >>> stage 1.1: legacy release compatibility shims >>> stage 1.2: bootstrap tools >>> stage 2.1: cleaning up the object tree >>> stage 2.2: rebuilding the object tree >>> stage 2.3: build tools >>> stage 3: cross tools [...] c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaCodeComplete.cpp -o SemaCodeComplete.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaConsumer.cpp -o SemaConsumer.o c++ -O2 -pipe -I/src/lib/clang/libclangsema/../../../contrib/llvm/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include -I/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema -I. -I/src/lib/clang/libclangsema/../../../contrib/llvm/../../lib/clang/include -DLLVM_ON_UNIX -DLLVM_ON_FREEBSD -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS -fno-strict-aliasing -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd11.0\" -DLLVM_HOST_TRIPLE=\"x86_64-unknown-freebsd11.0\" -DDEFAULT_SYSROOT=\"/obj/pc98.i386/src/tmp\" -I/obj/pc98.i386/src/tmp/legacy/usr/include -fno-exceptions -fno-rtti -c /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp -o SemaDecl.o /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp: In member function 'clang::Decl* clang::Sema::ActOnTag(clang::Scope*, unsigned int, clang::Sema::TagUseKind, clang::SourceLocation, clang::CXXScopeSpec&, clang::IdentifierInfo*, clang::SourceLocation, clang::AttributeList*, clang::AccessSpecifier, clang::SourceLocation, clang::MultiTemplateParamsArg, bool&, bool&, clang::SourceLocation, bool, clang::TypeResult)': /src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/lib/Sema/SemaDecl.cpp:9480: internal compiler error: Segmentation fault: 11 Please submit a full bug report, with preprocessed source if appropriate. See http://gcc.gnu.org/bugs.html> for instructions. *** Error code 1 Stop. bmake[3]: stopped in /src/lib/clang/libclangsema *** Error code 1 Stop. bmake[2]: stopped in /src/lib/clang *** Error code 1 Stop. bmake[1]: stopped in /src *** Error code 1 Stop. bmake: stopped in /src *** Error code 1 Stop in /src. TB --- 2014-01-25 02:49:33 - WARNING: /usr/bin/make returned exit code 1 TB --- 2014-01-25 02:49:33 - ERROR: failed to build world TB --- 2014-01-25 02:49:33 - 1531.10 user 198.98 system 1875.05 real http://tinderbox.freebsd.org/tinderbox-head-build-HEAD-i386-pc98.full ___ freebsd-current@freebsd.org mailing list http://lists.freebs
Re: freebsd-update
On 1/24/2014 11:31 AM, Mark Felder wrote: I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. I've yet to go through a freebsd-update process that didn't require a manual clean-up afterward. It's easier (and faster) to build an obj tree on my desktop, ship it to my servers via NFS over a tunnel. Another scenario I've run into more than once: - Install release m.x - Realize there's a kernel/driver bug, fixed in m-stable - Source upgrade to m-stable - Release m.z happens, contains fix - Freebsd-update upgrade to m.z The updater will discover that all of /etc differs by $Id tag. A few will have non-edit differences. The rest are either default-empty files or files not found in the distribution (pf.conf, sshd keys, etc.). Freebsd-update will force me to manually approve every single change. With mergemaster, automatic upgrade takes care of all but the edits and provides a MUCH nicer diff editor for those. Mergemaster is a <1 minute process, even on I/O-constrained hardware. I understand that when freebsd-update was written there were "some problems" with the existing install/merge tools used for source upgrades; but I have to wonder: what issues could be so bad that the above is the lesser evil? Freebsd-update's merge needs to learn what mergemaster's can do. Until then, freebsd-update is a non-starter, IMO. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
installworld for -CURRENT is broken on 9.1-R
Hi John, seems that your commit 261030 has broken installworld target when the installation is done on 9.1-RELEASE (and, actually, all releases before). Installing world fails with the following error: cd /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 644 crontab devd.conf devfs.conf ddb.conf dhclient.conf disktab fbtab ftpusers gettytab group hosts hosts.allow hosts.equiv inetd.conf libalias.conf libmap.conf login.access login.conf mac.conf motd netconfig network.subr networks newsyslog.conf nsswitch.conf phones profile protocols rc rc.bsdextended rc.firewall rc.initdiskless rc.sendmail rc.shutdown rc.subr remote rpc services shells sysctl.conf syslog.conf termcap.small etc.i386/ttys snmpd.config hosts.lpd printcap ntp.conf pf.os csh.cshrc csh.login csh.logout regdomain.xml /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; cap_mkdb -l /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/login.conf; services_mkdb -l -q -o /home/kibab/repos/freebsd-git/gs0/obj/_.w/var/db/services.db /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/services; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; install -N /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; services_mkdb: illegal option -- l Usage: services_mkdb [-q] [-o ] [] services_mkdb -u [] *** Error code 1 Stop. bmake[1]: stopped in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd/etc *** Error code 1 Stop. bmake: stopped in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd *** [distribution] Error code 1 Stop in /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd. So services_mkdb is taken from base system, and it indeed doesn't have -l switch introduced by your commit. -- Regards, Ilya Bakulin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
Oh! The NDIS FPU patch is limited to the NDIS module. Tell you what, I'll get that committed to -HEAD soon. Would you poke the original author and see if he's willing to work with you and I on getting this stuff into -HEAD? -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: installworld for -CURRENT is broken on 9.1-R
On Friday, January 24, 2014 3:42:15 pm Ilya Bakulin wrote: > Hi John, > > seems that your commit 261030 has broken installworld target when the > installation is done on 9.1-RELEASE (and, actually, all releases > before). Installing world fails with the following error: > > cd > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc; > install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 644 crontab devd.conf devfs.conf ddb.conf > dhclient.conf disktab fbtab ftpusers gettytab group hosts > hosts.allow hosts.equiv inetd.conf libalias.conf libmap.conf > login.access login.conf mac.conf motd netconfig network.subr > networks newsyslog.conf nsswitch.conf phones profile protocols rc > rc.bsdextended rc.firewall rc.initdiskless rc.sendmail rc.shutdown > rc.subr remote rpc services shells sysctl.conf syslog.conf > termcap.small etc.i386/ttys snmpd.config hosts.lpd printcap ntp.conf > pf.os csh.cshrc csh.login csh.logout regdomain.xml > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; cap_mkdb -l > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/login.conf; services_mkdb > -l -q -o /home/kibab/repos/freebsd-git/gs0/obj/_.w/var/db/services.db > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc/services; install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 755 netstart pccard_ether rc.suspend rc.resume > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; install -N > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > -o root -g wheel -m 600 master.passwd nsmb.conf opieaccess > /home/kibab/repos/freebsd-git/gs0/obj/_.w/etc; > services_mkdb: illegal option -- l > Usage: services_mkdb [-q] [-o ] [] > services_mkdb -u [] > *** Error code 1 > > Stop. > bmake[1]: stopped in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd- git/freebsd/etc > *** Error code 1 > > Stop. > bmake: stopped in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd > *** [distribution] Error code 1 > > Stop in > /stor0/jails/buildhost.kibab.com/usr/home/kibab/repos/freebsd-git/freebsd. > > > So services_mkdb is taken from base system, and it indeed doesn't have > -l switch introduced by your commit. This isn't from installworld. 'make distribute' doesn't get run as part of 'installworld'. Can you tell me what command you actually ran? -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
Unfortunately, I think there is measurable penalty going to BSD licensed tools, same system: http://pastebin.com/BNfhevBa -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878896p5879565.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update
On 2014-01-24 20:31, Mark Felder wrote: > I agree with the rest of this thread. This is just awful. I'm basically > forced to do source based updates when jumping major versions because > freebsd-update is a nightmare to use. Not tested, but maybe this works. a) use etcmerge before freebsd-upgrade and exclude /etc in freebsd-update.conf b) manually extract the sources, then use mergemaster and then run freebsd-update c) if you have more then one system fix once freebsd-update and deploy the script to the rest of the systems I use myself a mix of mergemaster and upgrade via the (kernel|src|man|...).txz and base.txz (exclude ^./etc). Going this way since 6.x and also major upgrades 6.x->7.x->8.x ... main issue on older systems is the space required by the kernel symbols. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
On Fri, Jan 24, 2014 at 8:16 PM, Adrian Chadd wrote: > > Is i kept up to date with -head changes? > > As far as I know it was kept up to date with -head changes. HI, > > Well, someone needs to break the fork up into pieces and submit those. > The FPU change is a good candidate - but it needs to be a sepaate PR > for that. > > So, how about we start with the fpu change? Get it into a separate > enhancement PR, then email -arch and -current. I'll help you get it > reviewed and put into -head. > > > -a > Sounds good, I'll try. Thank you. -- Have a nice day, Vlad Movchan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: freebsd-update
On 2014-01-21 15:42, Kevin Oberman wrote: > On Tue, Jan 21, 2014 at 8:49 AM, John Baldwin wrote: > >> On Tuesday, January 21, 2014 10:46:37 am David Chisnall wrote: >>> On 21 Jan 2014, at 07:13, Antonio Olivares >> wrote: On Tue, Jan 21, 2014 at 7:49 AM, Ivan Voras >> wrote: > Hi, > > Is there any way I can avoid manually resolving hundreds of merge > conflicts of the following type while using freebsd-update ? > > 1 <<< current version > > > 2 # $FreeBSD: release/9.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > peter $ > > 3 === > > > 4 # $FreeBSD: release/10.0.0/etc/csh.cshrc 50472 1999-08-27 23:37:10Z > peter $ > > 5 >>> 10.0-RELEASE > > > > ? > > I can't be the only one seeing those...? > Yes, One has to manually go one by one to fix these :( I tried at one point a sed command like sed -i "" '' to fix these, but it did not work correctly. I see errrors when booting when I don't correct these :( >>> I thought this was fixed already (I didn't see these in the 9.2->10-RC3 >> upgrade). Doesn't freebsd-update pass -F (If the files differ only by VCS >> Id >> ($FreeBSD) install the new file) to mergemaster? >> >> AFAIK it doesn't use mergemaster? I thought it used its own tool? I >> really >> want to figure out a way to let it use etcupdate instead since it handles >> this case even for locally modified files cleanly. >> > Having just gone through this on a 10.0-rc5 to 10.0-RELEASE run, I can > assure you that it is not completely fixed. One huge part is fixed... every > file's ID line is no longer is changed on every release. OTOH, for files > that are modified, thy still show up. It hit many of the sendmail .cf > files. Annoying as I don't even use sendmail. > > Not sure if there was a good reason Colin re-invented the wheel on this. It > does not use mergemaster or even a reasonable differences editor such as > the one mergemaster uses. Just going to the mergemaster code for handling > diffs would be a HUGE win. I am getting really tired of > "/3n". I discussed this a bit with Colin on Wednesday during our interview with him for BSDNow.tv He had some problems with mergemaster so wrote his own tool. In 10 it ignores the $Id tags, but there are still other changes that have to either be merged or the file replaced with the new one. I am all for further improvement here. -- Allan Jude signature.asc Description: OpenPGP digital signature
Re: freebsd-update
I agree with the rest of this thread. This is just awful. I'm basically forced to do source based updates when jumping major versions because freebsd-update is a nightmare to use. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
On 24 January 2014 08:47, Vlad Movchan wrote: > NDISulator on github (and mirror on gitorious) is a FreeBSD ndis > module+binaries forked by Paul B. Mahol in 2009 (I've sent Paul's email > address privately to Adrian). > Almost every change in this project was made by Paul. > My part is small - I've just discovered and fixed several panic/problems. Is i kept up to date with -head changes? > I've tried to submit my changes back to FreeBSD base tree via problem > reports: > One was commited: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165630 > Another one is hanging without feedback: > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165622 > > Few more fixes are depend on kern/165622. I have not created more PRs as > without fix for panic described in 165622 new reports would be like: > "I'm running something different than FreeBSD sources and it panics. And I > have a fix for it. But you won't be able to reproduce and/or test it on your > machine." > I bet there are not much people who would like to spend their time on > reports like this :) > HI, Well, someone needs to break the fork up into pieces and submit those. The FPU change is a good candidate - but it needs to be a sepaate PR for that. So, how about we start with the fpu change? Get it into a separate enhancement PR, then email -arch and -current. I'll help you get it reviewed and put into -head. -a ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
Ah.. my bad its "0x47217" not 21 :P works: ndis0: flags=8802 metric 0 mtu 1500 ether ac:81:12:35:79:73 nd6 options=29 media: IEEE 802.11 Wireless Ethernet autoselect (autoselect ) status: no carrier On Fri, Jan 24, 2014 at 4:49 PM, Miguel Clara wrote: > NOTE: tried NDISulator > > pciconf -lv | grep -i bcm -B2 > none2@pci0:13:0:0: class=0x028000 card=0x145c103c chip=0x472714e4 > rev=0x01 hdr=0x00 > vendor = 'Broadcom Corporation' > device = 'BCM4313 802.11b/g/n Wireless LAN Controller' > > > # ndisload -p -s /home/user/bcmWireless/bcmwl564.sys -n bcmw -v 0x14e4 -d > 0x4721 > > > and get this in dmesg: > > NDIS: no match for ZwQueryInformationFile > > > I'll report it in the github page, but it seems its not working! > > > # tail /var/log/messages > Jan 24 16:44:37 hpbsd kernel: NDIS: no match for ZwQueryInformationFile > Jan 24 16:46:10 hpbsd kernel: NDIS: no match for ZwQueryInformationFile > Jan 24 16:48:27 hpbsd kernel: Warning: memory type ndis_ntoskrnl > leaked memory on destroy (8 allocations, 2304 bytes leaked). > > On Fri, Jan 24, 2014 at 1:59 PM, Adrian Chadd wrote: >> ... who's the author of this? Why aren't they posting updates to >> FreeBSD-HEAD so it can be included in the base system? >> >> Does anyone have a contact email for the author, Vadislav? >> >> >> -a >> >> >> On 24 January 2014 03:52, Thomas Mueller wrote: >>> To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, >>> driver rsu. >>> >>> But you would need to do good research to find what the chip is, and which >>> FreeBSD driver, if any, would it work with, before you buy. >>> >>> NDISulator looks worth trying. FreeBSD users will want to know if it works. >>> >>> https://github.com/NDISulator/ndisulator >>> >>> Regarding deprecation of NDIS, is it a matter of something that is >>> compatible with Linux but very difficult to port to BSD? >>> >>> There is the problem with newer MS-Windows drivers that they don't come >>> with .sys and .inf files, or maybe they have to be unpacked and installed >>> from MS-Windows. Then NDIS would have nothing to work with. >>> >>> Tom >>> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
NOTE: tried NDISulator pciconf -lv | grep -i bcm -B2 none2@pci0:13:0:0: class=0x028000 card=0x145c103c chip=0x472714e4 rev=0x01 hdr=0x00 vendor = 'Broadcom Corporation' device = 'BCM4313 802.11b/g/n Wireless LAN Controller' # ndisload -p -s /home/user/bcmWireless/bcmwl564.sys -n bcmw -v 0x14e4 -d 0x4721 and get this in dmesg: NDIS: no match for ZwQueryInformationFile I'll report it in the github page, but it seems its not working! # tail /var/log/messages Jan 24 16:44:37 hpbsd kernel: NDIS: no match for ZwQueryInformationFile Jan 24 16:46:10 hpbsd kernel: NDIS: no match for ZwQueryInformationFile Jan 24 16:48:27 hpbsd kernel: Warning: memory type ndis_ntoskrnl leaked memory on destroy (8 allocations, 2304 bytes leaked). On Fri, Jan 24, 2014 at 1:59 PM, Adrian Chadd wrote: > ... who's the author of this? Why aren't they posting updates to > FreeBSD-HEAD so it can be included in the base system? > > Does anyone have a contact email for the author, Vadislav? > > > -a > > > On 24 January 2014 03:52, Thomas Mueller wrote: >> To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, >> driver rsu. >> >> But you would need to do good research to find what the chip is, and which >> FreeBSD driver, if any, would it work with, before you buy. >> >> NDISulator looks worth trying. FreeBSD users will want to know if it works. >> >> https://github.com/NDISulator/ndisulator >> >> Regarding deprecation of NDIS, is it a matter of something that is >> compatible with Linux but very difficult to port to BSD? >> >> There is the problem with newer MS-Windows drivers that they don't come with >> .sys and .inf files, or maybe they have to be unpacked and installed from >> MS-Windows. Then NDIS would have nothing to work with. >> >> Tom >> ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
NDISulator on github (and mirror on gitorious) is a FreeBSD ndis module+binaries forked by Paul B. Mahol in 2009 (I've sent Paul's email address privately to Adrian). Almost every change in this project was made by Paul. My part is small - I've just discovered and fixed several panic/problems. I've tried to submit my changes back to FreeBSD base tree via problem reports: One was commited: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165630 Another one is hanging without feedback: http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165622 Few more fixes are depend on kern/165622. I have not created more PRs as without fix for panic described in 165622 new reports would be like: "I'm running something different than FreeBSD sources and it panics. And I have a fix for it. But you won't be able to reproduce and/or test it on your machine." I bet there are not much people who would like to spend their time on reports like this :) On Fri, Jan 24, 2014 at 3:59 PM, Adrian Chadd wrote: > ... who's the author of this? Why aren't they posting updates to > FreeBSD-HEAD so it can be included in the base system? > > Does anyone have a contact email for the author, Vadislav? > > > -a > > > On 24 January 2014 03:52, Thomas Mueller > wrote: > > To Miguel Clara, you might try a USB wireless adapter. I use Hiro > H50191, driver rsu. > > > > But you would need to do good research to find what the chip is, and > which FreeBSD driver, if any, would it work with, before you buy. > > > > NDISulator looks worth trying. FreeBSD users will want to know if it > works. > > > > https://github.com/NDISulator/ndisulator > > > > Regarding deprecation of NDIS, is it a matter of something that is > compatible with Linux but very difficult to port to BSD? > > > > There is the problem with newer MS-Windows drivers that they don't come > with .sys and .inf files, or maybe they have to be unpacked and installed > from MS-Windows. Then NDIS would have nothing to work with. > > > > Tom > > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > -- Have a nice day, Vlad Movchan ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: lock order reversals w/ backtrace
On Thu, Jan 23, 2014 at 11:49 AM, Hans Petter Selasky < hans.petter.sela...@bitfrost.no> wrote: > Hi, > > Can you see if you can snap some keywords of the backtraces, like usb_xxx > usbdx_xxx cam scsi or something like that. > > Else I believe there are some sysctl options to prevent the final reboot > somehow so that you can write down the messages. > > --HPS > > > -Original message- > > From:Thomas Hoffmann > > Sent: Thursday 23rd January 2014 17:15 > > To: freebsd-current > > Subject: lock order reversals w/ backtrace > > > > A few days ago I started running 11.0-CURRENT at r260971 for the first time. > > > > The last couple of times I shutdown my system I noticed 2 or 3 short "lock > > order reversal" messages with accompanying backtraces scroll by. Do these > > messages represent a problem that I should report or can I ignore them as > > debug in nature? If I should report them, how or where do these messages > > get logged? I can find no reference to them in syslog or anywhere else upon > > my subsequent reboot. > > > > I also had a couple of these messages pop up the other day while > > mounting/umounting USB thumb drives. I did not think anything of them at > > the time as the mounts/umounts completed successfully. > > > > Please advise. Thanks. > > > > -Tom > > I managed to snap a photo of my screen during shutdown. Here is the full text of the first of two lock order reversals I got last night during system shutdown, both of which are zfs-related to (it appears?) unmounts. A few lines got chopped as they were out-of-frame when I took the photo: shutting down local daemons: lock order reversal: 1st 0xf801194f67c8 zfs (zfs) @ /usr/src/sys/kern/vfs_mount.c:1237 2nd 0xf801194f6420 syncer (syncer) @ /usr/src/sys/kern/vfs_subr.c:22[..chopped...] KDB: stack backtrace: db_trace_self_wrapper() at db_trace_delf_wrapper+0x2b/frame 0xfe01ac78[...chopped...] kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe01ac784650 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe01ac7846e0 __lockmgr_args() __lockmgr_args+0x878/frame 0xfe01ac784810 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe01ac784830 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe01ac784860 _vn_lock() at _vn_lock+0xab/frame 0xfe01ac7848d0 vputx() at vputx+0x240/frame 0xfe01ac784930 dounmount at dounmount+0x327/frame 0xfe01ac7849b0 sys_unmount() at sys_unmount+0x356/frame 0xfe01ac784ac0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe01ac784bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe01ac784bf0 --- syscall (22, FreeBSD ELF64, sys_unmount, rip = 0x80191c72a, rsp[...chopped...] I have a zpool on an external USB HDD that I export at shutdown via rc.shutdown.local. Don't know if that is contributing to this or not. When I get a chance to bring down the system I will manually export it before shutdown to see if that makes any difference. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Lessons learned from source upgrade from FreeBSD i386 9.2 Stable to FreeBSD i386 10.0 Release.
I've made a switch early. What gave me some bumps: - removal of ntfs module - vorbis-tools-1.4.0_6,3 with ogg123 missing (??) - ports built on db42 - malloc.conf - gcc48 entries in libmap.conf (my fault) - subversion-static looks broken a bit, nls problems e.g. $ sudo svn up Password: Service unavailableService unavailableService unavailableUpdating '.': -- View this message in context: http://freebsd.1045724.n5.nabble.com/Lessons-learned-from-source-upgrade-from-FreeBSD-i386-9-2-Stable-to-FreeBSD-i386-10-0-Release-tp5878896p5879448.html Sent from the freebsd-current mailing list archive at Nabble.com. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
... who's the author of this? Why aren't they posting updates to FreeBSD-HEAD so it can be included in the base system? Does anyone have a contact email for the author, Vadislav? -a On 24 January 2014 03:52, Thomas Mueller wrote: > To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, > driver rsu. > > But you would need to do good research to find what the chip is, and which > FreeBSD driver, if any, would it work with, before you buy. > > NDISulator looks worth trying. FreeBSD users will want to know if it works. > > https://github.com/NDISulator/ndisulator > > Regarding deprecation of NDIS, is it a matter of something that is compatible > with Linux but very difficult to port to BSD? > > There is the problem with newer MS-Windows drivers that they don't come with > .sys and .inf files, or maybe they have to be unpacked and installed from > MS-Windows. Then NDIS would have nothing to work with. > > Tom > ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Freebsd 11 current testing ndis / kldload: bcmwl564_sys.ko PANIC
To Miguel Clara, you might try a USB wireless adapter. I use Hiro H50191, driver rsu. But you would need to do good research to find what the chip is, and which FreeBSD driver, if any, would it work with, before you buy. NDISulator looks worth trying. FreeBSD users will want to know if it works. https://github.com/NDISulator/ndisulator Regarding deprecation of NDIS, is it a matter of something that is compatible with Linux but very difficult to port to BSD? There is the problem with newer MS-Windows drivers that they don't come with .sys and .inf files, or maybe they have to be unpacked and installed from MS-Windows. Then NDIS would have nothing to work with. Tom ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
r261034: buildworld fails: undefined reference to `DES_ecb_encrypt'
With r261034, I get the error shown below on one specific box running kernel/world 11.0-CURRENT #0 r261034: Wed Jan 22 20:14:05 CET 2014 amd64 Another box compiles the same source without any problems (running kernel/world 11.0-CURRENT #4 r261091: Thu Jan 23 22:46:03 CET 2014 amd64 My buildworld process on all systems is to delete the content of /usr/obj first before building the world/kernel, so remnants of faulty code or inconsistencies regarding the source tree are not likely. How to repair this strange behaviour? Regards, Oliver [...] (cd /usr/src/rescue/rescue/../../usr.bin/id && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/id/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/id/ id.o) `id.o' is up to date. (cd /usr/src/rescue/rescue/../../usr.sbin/chroot && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chroot/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chroot/ chroot.o) `chroot.o' is up to date. (cd /usr/src/rescue/rescue/../../usr.sbin/chown && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ depend && make -DRESCUE CRUNCH_CFLAGS=-DRESCUE DIRPRFX=rescue/rescue/chown/ chown.o) `chown.o' is up to date. cc -static -o rescue rescue.o cat.lo chflags.lo chio.lo chmod.lo cp.lo date.lo dd.lo df.lo echo.lo ed.lo expr.lo getfacl.lo hostname.lo kenv.lo kill.lo ln.lo ls.lo mkdir.lo mv.lo pkill.lo ps.lo pwd.lo realpath.lo rm.lo rmdir.lo setfacl.lo sh.lo stty.lo sync.lo test.lo rcp.lo csh.lo badsect.lo camcontrol.lo ccdconfig.lo clri.lo devfs.lo dmesg.lo dump.lo dumpfs.lo dumpon.lo fsck.lo fsck_ffs.lo fsck_msdosfs.lo fsdb.lo fsirand.lo gbde.lo geom.lo ifconfig.lo init.lo kldconfig.lo kldload.lo kldstat.lo kldunload.lo ldconfig.lo md5.lo mdconfig.lo mdmfs.lo mknod.lo mount.lo mount_cd9660.lo mount_msdosfs.lo mount_nfs.lo mount_nullfs.lo mount_udf.lo mount_unionfs.lo newfs.lo newfs_msdos.lo nos-tun.lo ping.lo reboot.lo restore.lo rcorder.lo route.lo routed.lo rtquery.lo rtsol.lo savecore.lo spppcontrol.lo swapon.lo sysctl.lo tunefs.lo umount.lo atmconfig.lo ping6.lo ipf.lo zfs.lo zpool.lo bsdlabel.lo fdisk.lo dhclient.lo head.lo mt.lo nc.lo sed.lo tail.lo tee.lo gzip.lo bzip2.lo less.lo xz.lo tar.lo vi.lo id.lo chroot.lo chown.lo /usr/obj/usr/src/rescue/rescue/../librescue/exec.o /usr/obj/usr/src/rescue/rescue/../librescue/getusershell.o /usr/obj/usr/src/rescue/rescue/../librescue/login_class.o /usr/obj/usr/src/rescue/rescue/../librescue/popen.o /usr/obj/usr/src/rescue/rescue/../librescue/rcmdsh.o /usr/obj/usr/src/rescue/rescue/../librescue/sysctl.o /usr/obj/usr/src/rescue/rescue/../librescue/system.o -lcrypt -ledit -lkvm -ll -ltermcap -lutil -lalias -lcam -lcurses -ldevstat -lipsec -lipx -lavl -ljail -lzfs_core -lzfs -lnvpair -lpthread -luutil -lumem -lgeom -lbsdxml -lkiconv -lmd -lsbuf -lufs -lz -lbz2 -llzma -larchive -lcrypto -lm nc.lo: In function `_$$hide$$ nc.lo main': (.text+0x622): warning: warning: mktemp() possibly used unsafely; consider using mkstemp() ed.lo: In function `_$$hide$$ ed.lo cbc_decode': (.text+0xddc): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo cbc_encode': (.text+0xf81): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo cbc_encode': (.text+0x100a): undefined reference to `DES_ecb_encrypt' ed.lo: In function `_$$hide$$ ed.lo get_keyword': (.text+0x1187): undefined reference to `DES_set_odd_parity' ed.lo: In function `_$$hide$$ ed.lo get_keyword': (.text+0x1194): undefined reference to `DES_set_key' ed.lo: In function `_$$hide$$ ed.lo set_des_key': (.text+0x15a3): undefined reference to `DES_set_odd_parity' ed.lo: In function `_$$hide$$ ed.lo set_des_key': (.text+0x15b4): undefined reference to `DES_set_key' cc: error: linker command failed with exit code 1 (use -v to see invocation) *** Error code 1 Stop. make[5]: stopped in /usr/obj/usr/src/rescue/rescue *** Error code 1 signature.asc Description: PGP signature
