Re: X related ports not finding version strings and hanging
On Sun, Oct 6, 2013 at 4:29 PM, Steve Kargl < s...@troutmask.apl.washington.edu> wrote: > On Sun, Oct 06, 2013 at 03:36:42PM -0700, Sean Bruno wrote: > > On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > > > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > > > causing problems duing the update. When this happens, some prompt is > > > waiting for me to hit "enter" that has scrolled past and I cannot see > > > it. > > > > > > > > > ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) > > > > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org > X > > > Server \([^ ]*\).*;\1;p'" > > > > > > > > > Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild > > it. > > > > Yep. Yet another port change disaster during a code freeze. > > As usual with such upgrades, pkg_libchk is your friend. Assuming you have updated pixman: portmaster graphics/libGL graphics/dri pkg_libchk -o | grep pixman | cut -d: -f1 | sort | uniq > pixman-files.txt portmaster =D `cat pixman-files.txt` portmaster -aD portmaster -y -clean-distfiles This will do the job much more quickly than "portmaster -r pixman -- R. Kevin Oberman, Network Engineer E-mail: rkober...@gmail.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: Hyper-V virtual DVD not detected
Oh, never mind - apparently, this particular party has already started over in freebsd-virtualization@, something about how Hyper-V doesn't virtualize the CD/DVD drive. It's a work in progress. Best wishes, Matthew -- I FIGHT FOR THE USERS ___ 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"
Hyper-V virtual DVD not detected
Hi everybody! Is anyone else running FreeBSD-current under Hyper-V? I can boot 10.0-ALPHA4 under Hyper-V Server 2012 using the installation CD image, but once running FreeBSD doesn't detect the virtual DVD drive - or at least the cd0 device is missing. Virtual hard disks attached to the same storage controller work just fine, IDE or SCSI. Conversely, everything works as expected under FreeBSD 9.2. I was able to install 10.0-ALPHA4 by attaching a second hard drive and copying the ISO image over the top of it. (The installer had no problems locating the FREEBSD_INSTALL volume on the second hard drive.) I'm not sure how to go about troubleshooting this. To start I am upgrading to r256072 in case any commits since ALPHA4 have fixed this problem. I'm also going to take a look at the source to the Hyper-V drivers. Beyond that, I'm open to any suggestions. Best wishes, Matthew -- I FIGHT FOR THE USERS ___ 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"
[Heads Up] RCS removed from base
Hey all, RCS was removed from the base system in r256095. If you still want to use RCS please install either devel/rcs or devel/rcs57. If not, be sure to check out the alternatives (pun stolen and intended). -- Eitan Adler ___ 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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
I just happened to be browsing man urtwn in NetBSD-current (6.99.23), and Edimax EW-7811Un is listed as supported by this driver. This strongly suggests it should work for FreeBSD-current (barring bugs). 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: X related ports not finding version strings and hanging
On Sun, Oct 06, 2013 at 03:36:42PM -0700, Sean Bruno wrote: > On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > > causing problems duing the update. When this happens, some prompt is > > waiting for me to hit "enter" that has scrolled past and I cannot see > > it. > > > > > > ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) > > > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > > Server \([^ ]*\).*;\1;p'" > > > > > Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild > it. > Yep. Yet another port change disaster during a code freeze. -- Steve ___ 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: X related ports not finding version strings and hanging
On Sun, 2013-10-06 at 15:28 -0700, Sean Bruno wrote: > Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be > causing problems duing the update. When this happens, some prompt is > waiting for me to hit "enter" that has scrolled past and I cannot see > it. > > > ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) > > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read > shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X > Server \([^ ]*\).*;\1;p'" > Oh ... this is due to the bump in pixman. Wow. Let me *try* to rebuild it. sean signature.asc Description: This is a digitally signed message part
X related ports not finding version strings and hanging
Was doing a portmaster -a today and noted that bsd.xorg.mk seems to be causing problems duing the update. When this happens, some prompt is waiting for me to hit "enter" that has scrolled past and I cannot see it. ===>>> All >> cairo-1.10.2_5,2 >> libGL-8.0.5_4 (13/35) make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" make: "/usr/ports/Mk/bsd.xorg.mk" line 158: warning: Couldn't read shell's output for "/usr/local/bin/X -version 2>&1 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p'" signature.asc Description: This is a digitally signed message part
drm2/radeon dfixed_trunc() warnings
These caught my eye today, and the checks strewn about sys/dev/drm2/radeon seem completely bogus to me, but I don't have the h/w to test it at the moment. /usr/src/sys/modules/drm2/radeonkms/../../../dev/drm2/radeon/rs690.c:491:37: warning: comparison of unsigned expression < 0 is always false [-Wtautological-compare] if (dfixed_trunc(priority_mark02) < 0) dfixed_trunc is a macro: drm_fixed.h:#define dfixed_trunc(A) ((A).full >> 12) that returns the output of a shift right operation ... priority_mark02 is of type union fixed20_12, single element union of type u32, so I can't see this check ever doing anything useful. But, as always, I'm probably missing something obvious. Sean signature.asc Description: This is a digitally signed message part
Re: Call for FreeBSD 2013Q3 (July-September) Status Reports
Dear FreeBSD Community, This is another gentle reminder that the deadline for submissions for the third Quarterly Status Report is tomorrow! Please find the details quoted below. On Sun, Sep 29, 2013 at 12:22 PM, Gabor Pali wrote: > Dear FreeBSD Community, > > Please note that the next submission date for the July to September > Quarterly Status Reports is October 7th, 2013, bit more than a week > away. Please consult my previous message for the details: > > On Mon, Sep 9, 2013 at 12:04 AM, Gabor Pali wrote: >> They do not have to be very long -- basically they may be about >> anything that lets people know what is going on around the FreeBSD >> Project. Submission of reports is not restricted to committers: >> Anyone who is doing anything interesting and FreeBSD-related can (and >> therefore encouraged to) write one! >> >> The preferred and easiest submission method is to use the XML >> generator [1] with the result emailed as an attachment to us, that is, >> mont...@freebsd.org [2]. There is also an XML template [3] which can >> be filled out manually and attached if preferred. >> >> To enable compilation and publication of the Q3 report as soon as >> possible for the October 7th deadline, please be prompt with any >> report submissions you may have. >> >> We are looking forward to all of your 2013Q3 reports! >> >> Cheers, >> Gabor >> >> >> [1] http://www.freebsd.org/cgi/monthly.cgi >> [2] mailto:mont...@freebsd.org >> [3] http://www.freebsd.org/news/status/report-sample.xml ___ 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 on 10.0-ALPHA4
> > Those two LORs are well-known and at least the fist is definitely a false > positive. They're rather tricky to fix; there's been previous discussion. > > The first one is #261 at http://sources.zabbadoz.net/freebsd/lor.html . > The second one is probably #280. > > Cheers, > matthew Thanks Matthew, I'll ignore them then, plenty else to do :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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"
CFT: rc.d/jail rewrite (was: jail configuration)
[Please reply to freebsd-current@] Hi, Can anyone who are using jail_* variables in rc.conf test the attached patch? On freebsd-arch@ there is a discussion about deprecating jail__* variables in favor of jail.conf. This rewrite is one to support the both in a backward compatible way. I want to make sure if this does not break the existing configurations. The following is the entry in UPDATING: +20131007: + The rc.d/jail script has been updated to support jail(8) + configuration file. The "jail__*" rc.conf(5) variables + for per-jail configuration are automatically converted to + /var/run/jail..conf before the jail(8) utility is invoked. + This is transparently backward compatible. See the below about some + incompatibilities. + + These variables are now deprecated in favor of jail(8) configuration + file. One can use "rc.d/jail config " command to generate + a jail(8) configuration file in /var/run/jail..conf without + running the jail(8) utility. The default pathname of the + configuration file is /etc/jail.conf and can be specified by + using $jail_conf or $jail__conf variables. + + Please note that jail_fdesc_enable and jail_procfs_enable are + not supported, and jail_devfs_ruleset accepts an integer at + this moment. Please consider to use exec.fstab for the + additional mount and rewrite the ruleset name with an integer. Dag-Erling Smørgrav wrote in <8638oerh39@nine.des.no>: de> I didn't look at the patch very closely, but I see that you print a de> warning when you generate a configuration for an old-style jail while de> jail.conf exists. I think you should *always* print that warning for de> every old-style jail so people will be reminded to convert. We should de> also remove the examples from /etc/defaults/rc.conf and replace the de> documentation for jail_${_j}_* in rc.conf(5) with a short paragraph that de> says they are for compatibility only. Thank you for your feedback. The warning message is always displayed in "rc.d/jail start", and rc.conf(5) and defaults/rc.conf are updated in this patch. -- Hiroki Index: UPDATING === --- UPDATING (revision 256090) +++ UPDATING (working copy) @@ -31,6 +31,26 @@ disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20131007: + The rc.d/jail script has been updated to support jail(8) + configuration file. The "jail__*" rc.conf(5) variables + for per-jail configuration are automatically converted to + /var/run/jail..conf before the jail(8) utility is invoked. + This is transparently backward compatible. See the below about some + incompatibilities. + + These variables are now deprecated in favor of jail(8) configuration + file. One can use "rc.d/jail config " command to generate + a jail(8) configuration file in /var/run/jail..conf without + running the jail(8) utility. The default pathname of the + configuration file is /etc/jail.conf and can be specified by + using $jail_conf or $jail__conf variables. + + Please note that jail_fdesc_enable and jail_procfs_enable are + not supported, and jail_devfs_ruleset accepts an integer at + this moment. Please consider to use exec.fstab for the + additional mount and rewrite the ruleset name with an integer. + 20130930: BIND has been removed from the base system. If all you need is a local resolver, simply enable and start the local_unbound Index: etc/rc.d/jail === --- etc/rc.d/jail (revision 256090) +++ etc/rc.d/jail (working copy) @@ -8,81 +8,138 @@ # BEFORE: securelevel # KEYWORD: nojail shutdown -# WARNING: This script deals with untrusted data (the data and -# processes inside the jails) and care must be taken when changing the -# code related to this! If you have any doubt whether a change is -# correct and have security impact, please get the patch reviewed by -# the FreeBSD Security Team prior to commit. - . /etc/rc.subr name="jail" rcvar="jail_enable" -start_precmd="jail_prestart" start_cmd="jail_start" +start_postcmd="jail_warn" stop_cmd="jail_stop" +config_cmd="jail_config" +console_cmd="jail_console" +status_cmd="jail_status" +extra_commands="config console status" +: ${jail_conf:=/etc/jail.conf} +: ${jail_program:=/usr/sbin/jail} +: ${jail_consolecmd:=/bin/sh} +: ${jail_jexec:=/usr/sbin/jexec} +: ${jail_jls:=/usr/sbin/jls} -# init_variables _j -# Initialize the various jail variables for jail _j. +need_dad_wait= + +# extact_var jail name param num defval +# Extract value from ${jail_$jail_$name} or ${jail_$name} and +# set it to $param. If not defined, $defval is used. +# When $num is [0-9]*, ${jail_$jail_$name$num} are looked up and +# $param is set by using +=. +# When $num is YN or NY, the value is interpret as boolean. +extract_var() +{ + local i _j _name _param _
Re: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
On 10/6/13 8:21 AM, Julian H. Stacey wrote: I wrote Thu, 03 Oct 2013 23:28:43 +0200 Rui Paulo wrote: On 2 Oct 2013, at 16:57, Julian H. Stacey wrote: Hi current@, It seems I need if_urtwn driver for a really miniature WLAN USB stick, & if_urtwn is only in current ? man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? This driver was never merged to FreeBSD 9. OK, Thanks for confirmation. Can you use FreeBSD 10 instead? Yes, easier than building from 9.X I guess (& helps test alpha :-). I'll fetch from local mirror, per http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html The port reference in the man page is wrong. The firmware is now shipped as part of the base system. Oh nice, easier :-) I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load="YES" `ifconfig wlan0 scan` works OK. Thanks :-) Cheers, Julian Cool! I have a g4 tibook 12in with an if_bwn that doesn't really work at all. I got one of these (if_urtwn) and it works enough to download about a meg or so before the watchdog kicks in and I have to ifconfig down/up it to get it to respond again. I even have a patch pending to add the usb identifier for this. Is there someone I can provide debug information for to help resolve this? -- Alfred Perlstein ___ 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 on 10.0-ALPHA4
On Sun, Oct 6, 2013 at 6:44 AM, Julian H. Stacey wrote: > With: > FreeBSD lapr.js.berklix.net 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 > r255933: Sun Sep 29 02:50:54 UTC 2013 > r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 > > At boot dmesg shows several lock order reversals, eg > > -- > Trying to mount root from ufs:/dev/ad4s2a [rw]... > ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, > logging disabled > lock order reversal: > 1st 0xfe00a6e26b48 bufwait (bufwait) @ > /usr/src/sys/kern/vfs_bio.c:3059 > 2nd 0xf80005cf8400 dirhash (dirhash) @ > /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe00c8f3d3f0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00c8f3d4a0 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfe00c8f3d530 > _sx_xlock() at _sx_xlock+0x75/frame 0xfe00c8f3d570 > ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfe00c8f3d5b0 > ufs_direnter() at ufs_direnter+0x688/frame 0xfe00c8f3d670 > ufs_makeinode() at ufs_makeinode+0x573/frame 0xfe00c8f3d830 > ufs_symlink() at ufs_symlink+0x32/frame 0xfe00c8f3d880 > VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf0/frame 0xfe00c8f3d8b0 > kern_symlinkat() at kern_symlinkat+0x23e/frame 0xfe00c8f3dae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfe00c8f3dbf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00c8f3dbf0 > --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x800888ffa, rsp = > 0x7fffca58, rbp = 0x7fffdc10 --- > lock order reversal: > 1st 0xf800881b9d50 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 > 2nd 0xf800881b99a0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2099 > KDB: stack backtrace: > db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame > 0xfe00c8ed93d0 > kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00c8ed9480 > witness_checkorder() at witness_checkorder+0xd23/frame 0xfe00c8ed9510 > __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfe00c8ed9640 > vop_stdlock() at vop_stdlock+0x3c/frame 0xfe00c8ed9660 > VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe00c8ed9690 > _vn_lock() at _vn_lock+0xab/frame 0xfe00c8ed9700 > vget() at vget+0x70/frame 0xfe00c8ed9750 > devfs_allocv() at devfs_allocv+0xfd/frame 0xfe00c8ed97a0 > devfs_root() at devfs_root+0x43/frame 0xfe00c8ed97d0 > vfs_donmount() at vfs_donmount+0x115e/frame 0xfe00c8ed9aa0 > sys_nmount() at sys_nmount+0x72/frame 0xfe00c8ed9ae0 > amd64_syscall() at amd64_syscall+0x265/frame 0xfe00c8ed9bf0 > Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00c8ed9bf0 > --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a9dd7a, rsp = > 0x7fffccb8, rbp = 0x7fffd220 --- > > > Those two LORs are well-known and at least the fist is definitely a false positive. They're rather tricky to fix; there's been previous discussion. The first one is #261 at http://sources.zabbadoz.net/freebsd/lor.html . The second one is probably #280. Cheers, matthew ___ 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: urtwn driver for Edimax EW-7811U WLAN nano USB Adapter
I wrote Thu, 03 Oct 2013 23:28:43 +0200 > Rui Paulo wrote: > > > > On 2 Oct 2013, at 16:57, Julian H. Stacey wrote: > > > > > Hi current@, > > > It seems I need if_urtwn driver for a really miniature WLAN USB stick, > > > & if_urtwn is only in current ? > > > man 4 if_urtwn refers to ports/net/urtwn-firmware-kmod which is missing ? > > > > > > This driver was never merged to FreeBSD 9. > > OK, Thanks for confirmation. > > > > Can you use FreeBSD 10 instead? > > Yes, easier than building from 9.X I guess (& helps test alpha :-). > I'll fetch from local mirror, per > http://lists.freebsd.org/pipermail/freebsd-current/2013-September/044951.html > > > > The port reference in the man page is wrong. The firmware is now shipped as > > part of the base system. > > Oh nice, easier :-) I'm happy to report with 10.0-ALPHA4 /boot/loader.conf if_urtwn_load="YES" `ifconfig wlan0 scan` works OK. Thanks :-) Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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"
lock order reversals on 10.0-ALPHA4
With: FreeBSD lapr.js.berklix.net 10.0-ALPHA4 FreeBSD 10.0-ALPHA4 #0 r255933: Sun Sep 29 02:50:54 UTC 2013 r...@snap.freebsd.org:/usr/obj/usr/src/sys/GENERIC amd64 At boot dmesg shows several lock order reversals, eg -- Trying to mount root from ufs:/dev/ad4s2a [rw]... ipfw2 (+ipv6) initialized, divert loadable, nat loadable, default to deny, logging disabled lock order reversal: 1st 0xfe00a6e26b48 bufwait (bufwait) @ /usr/src/sys/kern/vfs_bio.c:3059 2nd 0xf80005cf8400 dirhash (dirhash) @ /usr/src/sys/ufs/ufs/ufs_dirhash.c:284 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c8f3d3f0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00c8f3d4a0 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe00c8f3d530 _sx_xlock() at _sx_xlock+0x75/frame 0xfe00c8f3d570 ufsdirhash_add() at ufsdirhash_add+0x3b/frame 0xfe00c8f3d5b0 ufs_direnter() at ufs_direnter+0x688/frame 0xfe00c8f3d670 ufs_makeinode() at ufs_makeinode+0x573/frame 0xfe00c8f3d830 ufs_symlink() at ufs_symlink+0x32/frame 0xfe00c8f3d880 VOP_SYMLINK_APV() at VOP_SYMLINK_APV+0xf0/frame 0xfe00c8f3d8b0 kern_symlinkat() at kern_symlinkat+0x23e/frame 0xfe00c8f3dae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00c8f3dbf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00c8f3dbf0 --- syscall (57, FreeBSD ELF64, sys_symlink), rip = 0x800888ffa, rsp = 0x7fffca58, rbp = 0x7fffdc10 --- lock order reversal: 1st 0xf800881b9d50 ufs (ufs) @ /usr/src/sys/kern/vfs_mount.c:851 2nd 0xf800881b99a0 devfs (devfs) @ /usr/src/sys/kern/vfs_subr.c:2099 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00c8ed93d0 kdb_backtrace() at kdb_backtrace+0x39/frame 0xfe00c8ed9480 witness_checkorder() at witness_checkorder+0xd23/frame 0xfe00c8ed9510 __lockmgr_args() at __lockmgr_args+0x6f2/frame 0xfe00c8ed9640 vop_stdlock() at vop_stdlock+0x3c/frame 0xfe00c8ed9660 VOP_LOCK1_APV() at VOP_LOCK1_APV+0xf5/frame 0xfe00c8ed9690 _vn_lock() at _vn_lock+0xab/frame 0xfe00c8ed9700 vget() at vget+0x70/frame 0xfe00c8ed9750 devfs_allocv() at devfs_allocv+0xfd/frame 0xfe00c8ed97a0 devfs_root() at devfs_root+0x43/frame 0xfe00c8ed97d0 vfs_donmount() at vfs_donmount+0x115e/frame 0xfe00c8ed9aa0 sys_nmount() at sys_nmount+0x72/frame 0xfe00c8ed9ae0 amd64_syscall() at amd64_syscall+0x265/frame 0xfe00c8ed9bf0 Xfast_syscall() at Xfast_syscall+0xfb/frame 0xfe00c8ed9bf0 --- syscall (378, FreeBSD ELF64, sys_nmount), rip = 0x800a9dd7a, rsp = 0x7fffccb8, rbp = 0x7fffd220 --- It comes up multi user OK, Do you already have enough lock order reversal to work on, or do you want me to run diagnostics ? what ? Cheers, Julian -- Julian Stacey, BSD Unix Linux C Sys Eng Consultant, Munich http://berklix.com Reply below not above, like a play script. Indent old text with "> ". Send plain text. No quoted-printable, HTML, base64, multipart/alternative. ___ 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: [RFC][CFT] GEOM direct dispatch and fine-grained CAM locking
On 02.10.2013 20:30, John Baldwin wrote: On Saturday, September 07, 2013 2:32:45 am Alexander Motin wrote: On 07.09.2013 02:02, Jeremie Le Hen wrote: On Fri, Sep 06, 2013 at 11:29:11AM +0300, Alexander Motin wrote: On 06.09.2013 11:06, Jeremie Le Hen wrote: On Fri, Sep 06, 2013 at 12:46:27AM +0200, Olivier Cochard-Labbé wrote: On Thu, Sep 5, 2013 at 11:38 PM, Alexander Motin wrote: I've found and fixed possible double request completion, that could cause such symptoms if happened. Updated patch located as usual: http://people.freebsd.org/~mav/camlock_patches/camlock_20130905.patch With this new one I cannot boot any more (I also updated the source tree). This is a hand transcripted version: Trying to mount root from zfs:zroot/root []... panic: Batch flag already set cpuid = 1 KDB: stack backtrace: db_trace_self_wrapper() kdb_backtrace() vpanic() kassert_panic() xpt_batch_start() ata_interrupt() softclock_call_cc() softclock() ithread_loop() fork_exit() fork_trampoline() Thank you for the report. I see my fault. It is probably specific to ata(4) driver only. I've workarounded that in new patch version, but probably that area needs some rethinking. http://people.freebsd.org/~mav/camlock_patches/camlock_20130906.patch I'm not sure you needed a confirmation, but it boots. Thanks :). I didn't quite understand the thread; is direct dispatch enabled for amd64? ISTR you said only i386 but someone else posted the macro for amd64. Yes, it is enabled for amd64. I've said x86, meaning both i386 and amd64. FYI, I tested mfi with this patch set and mfid worked fine for handling g_up directly: Index: dev/mfi/mfi_disk.c === --- dev/mfi/mfi_disk.c (revision 257407) +++ dev/mfi/mfi_disk.c (working copy) @@ -162,6 +162,7 @@ sc->ld_disk->d_unit = sc->ld_unit; sc->ld_disk->d_sectorsize = secsize; sc->ld_disk->d_mediasize = sectors * secsize; + sc->ld_disk->d_flags = DISKFLAG_DIRECT_COMPLETION; if (sc->ld_disk->d_mediasize >= (1 * 1024 * 1024)) { sc->ld_disk->d_fwheads = 255; sc->ld_disk->d_fwsectors = 63; Thank you for the feedback. But looking on mfi driver sources I would say that it calls biodone() from mfi_disk_complete() from cm_complete() method, which is called while holding mfi_io_lock mutex. I guess that if on top of mfi device would be some GEOM class, supporting direct dispatch and sending new requests down on previous request completion (or retrying requests), that could cause recursive mfi_io_lock acquisition. That is exactly the cause why I've added this flag. May be it is a bit paranoid, but it is better to be safe then sorry. Another good reason to drop the lock before calling biodone() would be reducing the lock hold time. Otherwise it may just increase lock congestion there and destroy all benefits of the direct dispatch. -- Alexander Motin ___ 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"