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 m...@freebsd.org
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
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: 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 j...@berklix.com 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
Re: lock order reversals on 10.0-ALPHA4
On Sun, Oct 6, 2013 at 6:44 AM, Julian H. Stacey j...@berklix.com 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
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 j...@berklix.com 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
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_jname_* 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_jname_* rc.conf(5) variables
+ for per-jail configuration are automatically converted to
+ /var/run/jail.jname.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 jname command to generate
+ a jail(8) configuration file in /var/run/jail.jname.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_jname_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 d...@des.no 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_jname_* rc.conf(5) variables
+ for per-jail configuration are automatically converted to
+ /var/run/jail.jname.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 jname command to generate
+ a jail(8) configuration file in /var/run/jail.jname.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_jname_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()
+{
+
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
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 p...@freebsd.org 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 p...@freebsd.org 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
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
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 21 | 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 21 | 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 21 | 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 21 | sed -n 's;^X\.Org X Server \([^ ]*\).*;\1;p' signature.asc Description: This is a digitally signed message part
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 21 | 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 21 | 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 21 | 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 21 | 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
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 21 | 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 21 | 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 21 | 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 21 | 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: 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
[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
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
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
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 21 | 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 21 | 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 21 | 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 21 | 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
