Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: On Tue, Aug 17, 2010 at 07:42:41PM +0400, pluknet wrote: 2010/8/16 Kostik Belousov kostik...@gmail.com: On Mon, Aug 16, 2010 at 09:07:24PM +0400, pluknet wrote: On 16 August 2010 21:05, pluknet pluk...@gmail.com wrote: Hi. Seeing on mostly idle, recently updated current, while closing a file. Presumably never reported on ML. [...] Both LORs are valid. The fork performed deep inside the VFS call stack is obviously problematic. As a workaround, you may fix the number of nfsiods. Proper fix might consist of creating a shepherd thread which only task is to act on the requests on creating new nfsiods. Would you try to implement this ? I will provide the assistance, if needed. Hmm.. I tried to move kproc_create() under shepherd thread and now stuck with cp process lockup in [bo_wwait] when cp'ing something on nfs: cp a b. Did I screw up something? See weird draft patch attached (weird, as I have no idea how to nicely exchange data between nfs_nfsiodnew() and shep_thread() thread). Most likely, you loose the requests to create nfsiods since the existing request in the global variable shep_chan can be overwritten by new request. You should either sleep till existing request is serviced, or form a queue. It turns out I passed pointer to pointer instead of pointer (sorry for my poor English). Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. -- wbr, pluknet ___ 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: AR9280 bb hang and other
Rui Paulo wrote: On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting BB hangs are a problem with the 9280 but I don't know how to fix. Hardware errors shouldn't happen, but this might mean you have very aggressive power reduction settings (ACPI C3, etc.) that are interfering with the atheros card. This has happened to me in the past. Now, I've made 2 changes so I'm not sure which affected it: 1. I replaced the card with an AR9285 a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)' class = network 2. I changed the channel on our AP. (there were 2 other nearby APs on the same channel). I noticed that I got a lot more bb hangs at the office compared to home - there are a lot more APs nearby: [mini] /usr/home/ianf $ ifconfig wlan0 scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS Ignition00:26:bb:78:b4:916 54M -89:-96 100 EPS RSN HTCAP WPA WME Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP WPS WPA WME Viic00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH WME cluelan 00:30:4f:58:bf:967 54M -72:-96 100 EPS WPA ATH WME PRIVATE LABEL 00:19:70:05:28:c43 54M -79:-96 100 EP WPA WME blinkbroom1 00:18:4d:1c:8e:3a5 54M -89:-96 100 EPS WPA Sasman 00:26:f2:46:2c:de1 54M -93:-96 100 EP WME cocoa 00:26:f2:3d:aa:133 54M -94:-96 200 EPS WME HTCAP ATH CareCross 30:46:9a:1e:b0:ca8 54M -35:-96 100 EPS RSN WPA We're cluelan and we were on channel 3. Previously, I was seeing a hang every 10 minutes or so, since changing the channel to a free one, I haven't had a hang in the last 40 minutes. The only bb hang I've had was when I deactivated the RF switch on netbook and that was a semi-expected result. Ian -- Ian Freislich ___ 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
8.1-release + zfs v15 df(1) hangs
Hi All,
i installed freebsd 8.1-release on my workstation (based on the
8.1-release mfsbsd isos) and I'm now experiencing some strange effects.
A df(1) doesn't return and is not killable and while taking a look
around in my process table, I could find several find's hanging around too.
mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h
mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h
root 215 0.0 0.0 5804 1232 ?? DMon05AM 0:04.29 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 4139 0.0 0.0 5804 1324 ?? DTue05AM 0:02.38 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 7305 0.0 0.0 5804 1324 ?? D 5:01AM 0:00.43 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 73775 0.0 0.0 5804 1232 ?? DFri05AM 0:10.18 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
root 94589 0.0 0.0 5804 1232 ?? DSat05AM 0:07.68 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
nobody 94746 0.0 0.0 5804 1072 ?? DN Sat06AM 0:07.38 find -s
/ ! ( -fstype zfs ) -prune -or -path /tmp -prune -or -path /usr/tmp
-prune -or -path /var/tmp -prune -or -path /var/db/portsnap -prune -or
-print
root 97430 0.0 0.0 5804 1232 ?? DSun05AM 0:06.02 find
-sx / /home /tmp /var /dev/null -type f ( -perm -u+x -or -perm -g+x -or
-perm -o+x ) ( -perm -u+s -or -perm -g+s ) -exec ls -liTd {} +
I couldn't figure out where they're coming from, but since it seems
there's a new one every night I suspect its coming from a periodic script.
Any ideas how to get rid of those processes?
And yes, I know that zfs V15 isn't in -STABLE for a reason...
# uname -a
# FreeBSD siteop38-1.mobile.rz 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Tue
Aug 3 12:03:02 UTC 2010
r...@siteop38-1.mobile.rz:/usr/obj/usr/src/sys/GENERIC amd64
(I csup'ed to RELENG_8_1 and applied the v15 patch from
http://mfsbsd.vx.sk/ and did a make world)
best regards,
Marian
PS.: For the author of mfsbsd iso's: I like them. Cool! Thanks! :)
___
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/i386
TB --- 2010-08-18 06:10:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 06:10:00 - starting HEAD tinderbox run for i386/i386 TB --- 2010-08-18 06:10:00 - cleaning the object tree TB --- 2010-08-18 06:10:38 - cvsupping the source tree TB --- 2010-08-18 06:10:38 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/i386/supfile TB --- 2010-08-18 06:16:37 - building world TB --- 2010-08-18 06:16:37 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 06:16:37 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 06:16:37 - TARGET=i386 TB --- 2010-08-18 06:16:37 - TARGET_ARCH=i386 TB --- 2010-08-18 06:16:37 - TZ=UTC TB --- 2010-08-18 06:16:37 - __MAKE_CONF=/dev/null TB --- 2010-08-18 06:16:37 - cd /src TB --- 2010-08-18 06:16:37 - /usr/bin/make -B buildworld World build started on Wed Aug 18 06:16:37 UTC 2010 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 stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Aug 18 08:03:38 UTC 2010 TB --- 2010-08-18 08:03:38 - generating LINT kernel config TB --- 2010-08-18 08:03:38 - cd /src/sys/i386/conf TB --- 2010-08-18 08:03:38 - /usr/bin/make -B LINT TB --- 2010-08-18 08:03:38 - building LINT kernel TB --- 2010-08-18 08:03:38 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:03:38 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:03:38 - TARGET=i386 TB --- 2010-08-18 08:03:38 - TARGET_ARCH=i386 TB --- 2010-08-18 08:03:38 - TZ=UTC TB --- 2010-08-18 08:03:38 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:03:38 - cd /src TB --- 2010-08-18 08:03:38 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Aug 18 08:03:38 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT completed on Wed Aug 18 08:30:39 UTC 2010 TB --- 2010-08-18 08:30:39 - building GENERIC kernel TB --- 2010-08-18 08:30:39 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:30:39 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:30:39 - TARGET=i386 TB --- 2010-08-18 08:30:39 - TARGET_ARCH=i386 TB --- 2010-08-18 08:30:39 - TZ=UTC TB --- 2010-08-18 08:30:39 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:30:39 - cd /src TB --- 2010-08-18 08:30:39 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Aug 18 08:30:39 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for GENERIC completed on Wed Aug 18 08:51:08 UTC 2010 TB --- 2010-08-18 08:51:08 - building PAE kernel TB --- 2010-08-18 08:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 08:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 08:51:08 - TARGET=i386 TB --- 2010-08-18 08:51:08 - TARGET_ARCH=i386 TB --- 2010-08-18 08:51:08 - TZ=UTC TB --- 2010-08-18 08:51:08 - __MAKE_CONF=/dev/null TB --- 2010-08-18 08:51:08 - cd /src TB --- 2010-08-18 08:51:08 - /usr/bin/make -B buildkernel KERNCONF=PAE Kernel build for PAE started on Wed Aug 18 08:51:08 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules -- cd /obj/i386.i386/src/sys/PAE; MAKEOBJDIRPREFIX=/obj/i386.i386 MACHINE_ARCH=i386 MACHINE=i386 CPUTYPE= GROFF_BIN_PATH=/obj/i386.i386/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/i386.i386/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/i386.i386/src/tmp VERSION=FreeBSD 8.0-STABLE amd64 800504 INSTALL=sh /src/tools/install.sh PATH=/obj/i386.i386/src/tmp/legacy/usr/sbin:/obj/i386.i386/src/tmp/legacy/usr/bin:/obj/i386.i386/src/tmp/legacy/usr/games:/obj/i386.i386/src/tmp/usr/sbin:/obj/i386.i386/src/tmp/usr/bin:/obj/i386.i386/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ make: don't know how to make modules-all. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 08:56:29 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 08:56:29 - ERROR: failed to build PAE kernel TB --- 2010-08-18 08:56:29 - 7339.23 user 1486.55 system 9989.07 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-i386-i386.full
unionfs a little improvement
Hi Ed and unionfs fan gyus.
Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.
Thanks Ed ;)
Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
- struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;
@@ -280,26 +279,6 @@
mp-mnt_flag |= ump-um_uppervp-v_mount-mnt_flag MNT_RDONLY;
/*
-* Check whiteout
-*/
- if ((mp-mnt_flag MNT_RDONLY) == 0) {
- memset(fakecn, 0, sizeof(fakecn));
- fakecn.cn_nameiop = LOOKUP;
- fakecn.cn_thread = td;
- error = VOP_WHITEOUT(ump-um_uppervp, fakecn, LOOKUP);
- if (error) {
- if (below) {
- VOP_UNLOCK(ump-um_uppervp, 0);
- vrele(upperrootvp);
- } else
- vput(ump-um_uppervp);
- free(ump, M_UNIONFSMNT);
- mp-mnt_data = NULL;
- return (error);
- }
- }
-
- /*
* Unlock the node
*/
VOP_UNLOCK(ump-um_uppervp, 0);
Ed's message here:
Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.
The manpage says the following:
Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer
objects
can be done. EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).
This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().
It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.
After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.
--
Daichi GOTO
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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: AR9280 bb hang and other
On 18 Aug 2010, at 09:26, Ian FREISLICH wrote: Rui Paulo wrote: On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting BB hangs are a problem with the 9280 but I don't know how to fix. Hardware errors shouldn't happen, but this might mean you have very aggressive power reduction settings (ACPI C3, etc.) that are interfering with the atheros card. This has happened to me in the past. Now, I've made 2 changes so I'm not sure which affected it: 1. I replaced the card with an AR9285 a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)' class = network 2. I changed the channel on our AP. (there were 2 other nearby APs on the same channel). I noticed that I got a lot more bb hangs at the office compared to home - there are a lot more APs nearby: [mini] /usr/home/ianf $ ifconfig wlan0 scan SSID/MESH IDBSSID CHAN RATE S:N INT CAPS Ignition00:26:bb:78:b4:916 54M -89:-96 100 EPS RSN HTCAP WPA WME Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP WPS WPA WME Viic00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH WME cluelan 00:30:4f:58:bf:967 54M -72:-96 100 EPS WPA ATH WME PRIVATE LABEL 00:19:70:05:28:c43 54M -79:-96 100 EP WPA WME blinkbroom1 00:18:4d:1c:8e:3a5 54M -89:-96 100 EPS WPA Sasman 00:26:f2:46:2c:de1 54M -93:-96 100 EP WME cocoa 00:26:f2:3d:aa:133 54M -94:-96 200 EPS WME HTCAP ATH CareCross 30:46:9a:1e:b0:ca8 54M -35:-96 100 EPS RSN WPA We're cluelan and we were on channel 3. Previously, I was seeing a hang every 10 minutes or so, since changing the channel to a free one, I haven't had a hang in the last 40 minutes. The only bb hang I've had was when I deactivated the RF switch on netbook and that was a semi-expected result. Yes, the hangs are dependent on the signal and noise conditions. Regards, -- Rui Paulo ___ 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: Building world with clang
Dimitry Andric dimi...@andric.com writes:
Alexander Kabaev kab...@gmail.com writes:
Does method 1) work fine with 'make buildenv'? I doubt that. I would
strongly suggest we should not lose this feature. I do not like the
idea of having to depend on -isystem in CFLAGS in such an environment.
I have not tested make buildenv with this method, but since ${CC} is
modified, not ${CFLAGS}, there is a reasonable chance that it might
work. :)
I'm not a big fan of reasonable chances when it comes to the
toolchain.
Note a similar method is already being using for the build32 stage on
amd64, where ${CC} has a bunch of flags (including -isystem, -L and -B)
appended.
No, what is used is a variant of method 1 *on top of* method 2 for a
very specific case. You need a special version of clang (method 2)
anyway to support cross-building.
DES
--
Dag-Erling Smørgrav - d...@des.no
___
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: AR9280 bb hang and other
Can you please change one at a time and see which affected it? Thanks, Adrian On 18 August 2010 16:26, Ian FREISLICH i...@clue.co.za wrote: Rui Paulo wrote: On 17 Aug 2010, at 09:17, Ian FREISLICH wrote: Aug 17 09:29:08 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:37:57 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 09:49:10 mini kernel: ath0: bb hang detected (0x80), resetting Aug 17 10:06:17 mini kernel: ath0: bb hang detected (0x80), resetting BB hangs are a problem with the 9280 but I don't know how to fix. Hardware errors shouldn't happen, but this might mean you have very aggressive power reduction settings (ACPI C3, etc.) that are interfering with the atheros card. This has happened to me in the past. Now, I've made 2 changes so I'm not sure which affected it: 1. I replaced the card with an AR9285 a...@pci0:1:0:0: class=0x028000 card=0x7167144f chip=0x002b168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = 'Atheros AR9285 Wireless LAN 802.11 a/b/g/n Controller (AR928x)' class = network 2. I changed the channel on our AP. (there were 2 other nearby APs on the same channel). I noticed that I got a lot more bb hangs at the office compared to home - there are a lot more APs nearby: [mini] /usr/home/ianf $ ifconfig wlan0 scan SSID/MESH ID BSSID CHAN RATE S:N INT CAPS Ignition 00:26:bb:78:b4:91 6 54M -89:-96 100 EPS RSN HTCAP WPA WME Eco Impact 00:22:3f:55:80:bc 11 54M -92:-96 100 EP HTCAP WPS WPA WME Viic 00:14:6c:49:3f:1c 11 54M -92:-96 100 EPS WPA ATH WME cluelan 00:30:4f:58:bf:96 7 54M -72:-96 100 EPS WPA ATH WME PRIVATE LABEL 00:19:70:05:28:c4 3 54M -79:-96 100 EP WPA WME blinkbroom1 00:18:4d:1c:8e:3a 5 54M -89:-96 100 EPS WPA Sasman 00:26:f2:46:2c:de 1 54M -93:-96 100 EP WME cocoa 00:26:f2:3d:aa:13 3 54M -94:-96 200 EPS WME HTCAP ATH CareCross 30:46:9a:1e:b0:ca 8 54M -35:-96 100 EPS RSN WPA We're cluelan and we were on channel 3. Previously, I was seeing a hang every 10 minutes or so, since changing the channel to a free one, I haven't had a hang in the last 40 minutes. The only bb hang I've had was when I deactivated the RF switch on netbook and that was a semi-expected result. Ian -- Ian Freislich ___ 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 ___ 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: AR9280 bb hang and other
Adrian Chadd wrote: Can you please change one at a time and see which affected it? Looking at my logs: startup: Aug 18 09:41:40 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:41:41 mini kernel: wlan0: link state changed to UP ?: Aug 18 09:45:25 mini kernel: ath0: bb hang detected (0x80), resetting RF switch off: Aug 18 09:49:50 mini kernel: ath0: bb hang detected (0x80), resetting Aug 18 09:50:13 mini kernel: wlan0: link state changed to DOWN RF switch on: Aug 18 09:50:13 mini kernel: wlan0: link state changed to UP AP changed channels Aug 18 09:54:40 mini kernel: ath0: bb hang detected (0x80), resetting wlan0 destroy: Aug 18 09:56:31 mini kernel: wlan0: link state changed to DOWN Aug 18 09:56:31 mini dhclient[1300]: Interface wlan0 no longer appears valid. wlan0 create: Aug 18 09:56:33 mini kernel: wlan0: Ethernet address: b4:82:fe:72:16:09 Aug 18 09:56:36 mini kernel: wlan0: link state changed to UP It really looks likes like it's signal related, not card related because this card still got a signal related bb hang before the channel change, but not after. Ian -- Ian Freislich ___ 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. -- wbr, pluknet nfsiod_tq.diff Description: Binary data ___ 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
Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement]
Hi Daichi, I think Keith Packard of Xorg once wrote a commit message along the lines of 5000 lines of code removed, feature added This seems to be similar, albeit on a smaller scale. ;-) Apart from this issue with unionfs, I am also experiencing another issue, where for some reason I cannot perform a second mount of the CD right after booting the system. Basically, my WIP FreeBSD boot CD does the following (but written in C): mount -t cd9660 /dev/iso9660/freebsd /mnt mount -t tmpfs none /tmp mount -t unionfs /tmp /mnt mount -t devfs none /mnt/dev chroot /mnt /sbin/init The first step fails with EBUSY. I use the following hack to get it working, but I don't think it's the proper way to solve it: %%% Index: sys/geom/geom_vfs.c === --- sys/geom/geom_vfs.c (revision 211093) +++ sys/geom/geom_vfs.c (working copy) @@ -162,8 +162,10 @@ *cpp = NULL; bo = vp-v_bufobj; +#if 0 if (bo-bo_private != vp) return (EBUSY); +#endif pp = g_dev_getprovider(vp-v_rdev); if (pp == NULL) %%% I am really not that familiar with GEOM/VFS to understand the impact of this change. What does it actually mean if bo-bo_private != vp? -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgpDtQb4iDzU5.pgp Description: PGP signature
Re: bsdgrep does not work with tail -f | grep combination
Hi Gabor and others, As Gabor committed r211364, bsdgrep now works nicely with tail -f. http://svn.freebsd.org/changeset/base/211364 Thank you very much. -- kuro ___ 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 sparc64/sun4v
TB --- 2010-08-18 09:47:11 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 09:47:11 - starting HEAD tinderbox run for sparc64/sun4v TB --- 2010-08-18 09:47:11 - cleaning the object tree TB --- 2010-08-18 09:47:41 - cvsupping the source tree TB --- 2010-08-18 09:47:41 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/sparc64/sun4v/supfile TB --- 2010-08-18 09:50:08 - building world TB --- 2010-08-18 09:50:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 09:50:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 09:50:08 - TARGET=sun4v TB --- 2010-08-18 09:50:08 - TARGET_ARCH=sparc64 TB --- 2010-08-18 09:50:08 - TZ=UTC TB --- 2010-08-18 09:50:08 - __MAKE_CONF=/dev/null TB --- 2010-08-18 09:50:08 - cd /src TB --- 2010-08-18 09:50:08 - /usr/bin/make -B buildworld World build started on Wed Aug 18 09:50:09 UTC 2010 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 stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything World build completed on Wed Aug 18 10:55:36 UTC 2010 TB --- 2010-08-18 10:55:36 - generating LINT kernel config TB --- 2010-08-18 10:55:36 - cd /src/sys/sun4v/conf TB --- 2010-08-18 10:55:36 - /usr/bin/make -B LINT TB --- 2010-08-18 10:55:36 - building LINT kernel TB --- 2010-08-18 10:55:36 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 10:55:36 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 10:55:36 - TARGET=sun4v TB --- 2010-08-18 10:55:36 - TARGET_ARCH=sparc64 TB --- 2010-08-18 10:55:36 - TZ=UTC TB --- 2010-08-18 10:55:36 - __MAKE_CONF=/dev/null TB --- 2010-08-18 10:55:36 - cd /src TB --- 2010-08-18 10:55:36 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Aug 18 10:55:37 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules Kernel build for LINT completed on Wed Aug 18 11:19:24 UTC 2010 TB --- 2010-08-18 11:19:24 - building GENERIC kernel TB --- 2010-08-18 11:19:24 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 11:19:24 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 11:19:24 - TARGET=sun4v TB --- 2010-08-18 11:19:24 - TARGET_ARCH=sparc64 TB --- 2010-08-18 11:19:24 - TZ=UTC TB --- 2010-08-18 11:19:24 - __MAKE_CONF=/dev/null TB --- 2010-08-18 11:19:24 - cd /src TB --- 2010-08-18 11:19:24 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Wed Aug 18 11:19:24 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel stage 3.3: building the modules -- cd /obj/sun4v.sparc64/src/sys/GENERIC; MAKEOBJDIRPREFIX=/obj/sun4v.sparc64 MACHINE_ARCH=sparc64 MACHINE=sun4v CPUTYPE= GROFF_BIN_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/bin GROFF_FONT_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/groff_font GROFF_TMAC_PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/share/tmac _SHLIBDIRPREFIX=/obj/sun4v.sparc64/src/tmp VERSION=FreeBSD 8.0-STABLE amd64 800504 INSTALL=sh /src/tools/install.sh PATH=/obj/sun4v.sparc64/src/tmp/legacy/usr/sbin:/obj/sun4v.sparc64/src/tmp/legacy/usr/bin:/obj/sun4v.sparc64/src/tmp/legacy/usr/games:/obj/sun4v.sparc64/src/tmp/usr/sbin:/obj/sun4v.sparc64/src/tmp/usr/bin:/obj/sun4v.sparc64/src/tmp/usr/games:/sbin:/bin:/usr/sbin:/usr/bin /usr/bin/make KERNEL=kernel modules-all -DNO_MODULES_OBJ make: don't know how to make modules-all. Stop *** Error code 2 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 11:23:06 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 11:23:06 - ERROR: failed to build GENERIC kernel TB --- 2010-08-18 11:23:06 - 4043.42 user 965.02 system 5754.09 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-sparc64-sun4v.full ___ 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
CFR: Replace man/manpath/whatis/apropos with a shell script
All, I sat down and rewrote the man tools from a relatively old codebase to a single shell script. My original motivation was to allow multiple configuration files so port installations did not have to mess with /etc/manpath.config (like perl for example) when needing to manipulate the manpath. After looking at the existing code, I figured I could rewrite it as a shell script relatively easily. Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, /usr/bin/whatis) http://people.freebsd.org/~gordon/man.shhttp://people.freebsd.org/%7Egordon/man.sh Features of the new code: 1. BSD licensed (old code is GPL). 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf (purposefully changed the manpath.config file since it is a different syntax). 3. Allows ports to override the toolset used to display the manpage based on language. This was done to try to merge the functionality of the japanese/man port into the base system as much as possible. I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd whatever will generally give me the debug information I need). Thanks, Gordon ___ 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 powerpc64/powerpc
TB --- 2010-08-18 09:18:34 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-18 09:18:34 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64 TB --- 2010-08-18 09:18:34 - mkdir /tinderbox/HEAD/powerpc64/powerpc TB --- 2010-08-18 09:18:34 - cleaning the object tree TB --- 2010-08-18 09:18:34 - cvsupping the source tree TB --- 2010-08-18 09:18:34 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-18 09:38:05 - building world TB --- 2010-08-18 09:38:05 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 09:38:05 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 09:38:05 - TARGET=powerpc TB --- 2010-08-18 09:38:05 - TARGET_ARCH=powerpc64 TB --- 2010-08-18 09:38:05 - TZ=UTC TB --- 2010-08-18 09:38:05 - __MAKE_CONF=/dev/null TB --- 2010-08-18 09:38:05 - cd /src TB --- 2010-08-18 09:38:05 - /usr/bin/make -B buildworld World build started on Wed Aug 18 09:38:06 UTC 2010 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 stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Wed Aug 18 11:18:07 UTC 2010 TB --- 2010-08-18 11:18:07 - generating LINT kernel config TB --- 2010-08-18 11:18:07 - cd /src/sys/powerpc/conf TB --- 2010-08-18 11:18:07 - /usr/bin/make -B LINT TB --- 2010-08-18 11:18:07 - building LINT kernel TB --- 2010-08-18 11:18:07 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-18 11:18:07 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-18 11:18:07 - TARGET=powerpc TB --- 2010-08-18 11:18:07 - TARGET_ARCH=powerpc64 TB --- 2010-08-18 11:18:07 - TZ=UTC TB --- 2010-08-18 11:18:07 - __MAKE_CONF=/dev/null TB --- 2010-08-18 11:18:07 - cd /src TB --- 2010-08-18 11:18:07 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Wed Aug 18 11:18:07 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building the kernel [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-18 11:31:17 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-18 11:31:17 - ERROR: failed to build lint kernel TB --- 2010-08-18 11:31:17 - 4864.50 user 1282.72 system 7963.35 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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: ZFS will gone,FreeBSD will import btrfs?
Hi, On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote: It's not gone since Oracle can not withdraw code that is already licensed under CDDL. They _may_ choose not to release anything new but we already have a newer zfs version that have basic functionality usable in p4. So all we need to direct some of the money we already spend for supporting developers and certain developments to core ZFS developers no longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS development platform for the future. If you have the key developers, the community will follow. Before someone starts argueing... I know, it's not that easy and I don't have a clue how one would do that. This is most probably more like a crazy idea than a plan that could actually work :-/ - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | |Ich bin das Internet. Sowahr ich Gott helfe. | pgpyMYQpaY2XO.pgp Description: PGP signature
Re: Building world with clang
On 2010-08-18 11:15, Dag-Erling Smørgrav wrote: I'm not a big fan of reasonable chances when it comes to the toolchain. Me neither, which is why I created method 2 originally. :) The -isysroot method was invented by Roman Divacky in r198248. No, what is used is a variant of method 1 *on top of* method 2 for a very specific case. You need a special version of clang (method 2) anyway to support cross-building. Eventually, clang should support building objects for all targets from one executable, but not in the short term, unfortunately... ___ 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: Building world with clang
Dimitry Andric dimi...@andric.com writes: Dag-Erling Smørgrav d...@des.no writes: No, what is used is a variant of method 1 *on top of* method 2 for a very specific case. You need a special version of clang (method 2) anyway to support cross-building. Eventually, clang should support building objects for all targets from one executable, but not in the short term, unfortunately... That doesn't matter. You still need two versions of the compiler. If you're cross-building sprac64 on an i386 machine, for instance, you need an i386 version of the compiler that produces sparc64 binaries *and* a sparc64 version that produces sparc64 binaries. The former is used only during the build, the latter is what will be installed on the target. DES -- Dag-Erling Smørgrav - d...@des.no ___ 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: bsdgrep does not work with tail -f | grep combination
Em 2010.08.18. 7:42, poyop...@puripuri.plala.or.jp escreveu: Hi Gabor and others, As Gabor committed r211364, bsdgrep now works nicely with tail -f. http://svn.freebsd.org/changeset/base/211364 Thank you very much. Acknowledgements also go to you and other users. Without quality feedback I may not have found myself all reported bugs. Gabor ___ 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: Interpreted language(s) in the base
On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: got any other suggestions? This is very much a sorry I asked question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). Unfortunately it seems that quite a lot of people have issues with lisp syntax these days. There are some other compile-to-C languages that might work too. [Aside: I think that the answer to this question might get a *lot* more interesting once we have llvm in the base system (it comes along with clang). There are (and I'm sure will be more) languages that compile down to llvm byte-code without the contortions required in going through C.] Cheers, -- Andrew ___ 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. pgp3biVEZldik.pgp Description: PGP signature
Re: Interpreted language(s) in the base
On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: got any other suggestions? This is very much a sorry I asked question, but is none-the less quite a good one, given the size of the hole to be plugged. I think that a reasonable answer for this sort of thing might be one of the dynamic languages that compiles to C, like (perhaps) one of the schemes (chicken, gambit-C, bigloo, etc). You get the benefit of flexibility and dynamism with good regexp and data structure ability, good performance, and only requiring the build tools available in the base system, as long as you don't want to be the developer: just ship the C code (as well as the source, of course). slightly off topic but I disagree on the latter part. The whole point of having source code is to be able to make modifications, small or large, private or ones to be contributed back. As a teacher, i am very concerned about the ease-of-use for non-developer types: it is important to make it easy for people to experiments, as this is one of the ways people learn things. Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) cheers luigi ___ 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: 8.1-release + zfs v15 df(1) hangs
on 18/08/2010 11:23 Marian Hettwer said the following: Hi All, i installed freebsd 8.1-release on my workstation (based on the 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. A df(1) doesn't return and is not killable and while taking a look around in my process table, I could find several find's hanging around too. mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h Can you run procstat -k to see where exactly the processes are stuck? -- Andriy Gapon ___ 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: Mounting cd9660 multiple times gives EBUSY [Was: unionfs a little improvement]
* Pawel Jakub Dawidek p...@freebsd.org wrote: What you are trying to do here is to mount /dev/iso9660/freebsd for the second time? This is not supported. The check is there to prevent doing this, as it will panic on you when you try to unmount first mount (not really a problem in your case, as the first mount is /, so you probably don't want to unmount it, but it is a problem in general). You should be able to reproduce the panic with your patch applied by doing the following: # mount -t cd9660 /dev/iso9660/freebsd /mnt0 # mount -t cd9660 /dev/iso9660/freebsd /mnt1 # umount /mnt0 Ah, I see. Well, I changed my setup to use an md root now. Works quite nicely. Screenshot: http://80386.nl/pub/livecd.png Thanks for the explanation! -- Ed Schouten e...@80386.nl WWW: http://80386.nl/ pgps9FfC06S09.pgp Description: PGP signature
CFR: importing openresolv
Hi,
I wish to import openresolv 3.3.5 into our base tree. It makes
merging the DNS server addresses informed from DHCP, DHCPv6, PPP, ...
into /etc/resolv.conf easier.
http://roy.marples.name/projects/openresolv
My patch against 9-CURRENT can be obtained from:
http://www.imasy.or.jp/~ume/FreeBSD/openresolv-20100818.diff.gz
Sincerely,
--
Hajimu UMEMOTO @ Internet Mutual Aid Society Yokohama, Japan
u...@mahoroba.org u...@{,jp.}FreeBSD.org
http://www.imasy.org/~ume/
___
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: STABLE kernel panic: privileged instruction fault
on 13/08/2010 00:45 Alexey Tarasov said the following: Fatal trap 1: privileged instruction fault while in kernel mode cpuid = 1; apic id = 01 instruction pointer = 0x20:0xff8040d2cc83 stack pointer = 0x28:0xff8040d2ca80 frame pointer = 0x28:0xff0060c0b740 I suspect that either stack is corrupted or non-code is executed (or both). Stack pointer seems to be too close to instruction pointer and too far from frame pointer. Can you try to use kgdb and disassemble code (or examine data) near instruction pointer address and also near frame pointer address? Also, you might want to rebuild kgdb with a recent change from head, so that it better maps symbols and addresses in kernel modules. code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, long 1, def32 0, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 9388 (nginx) trap number = 1 panic: privileged instruction fault cpuid = 1 Uptime: 17d15h48m49s Physical memory: 2032 MB Dumping 1485 MB: 1470 1454 1438 1422 1406 1390 1374 1358 1342 1326 1310 1294 1278 1262 1246 1230 1214 1198 1182 1166 1150 1134 1118 1102 1086 1070 1054 1038 1022 1006 990 974 958 942 926 910 894 878 862 846 830 814 798 782 766 750 734 718 702 686 670 654 638 622 606 590 574 558 542 526 510 494 478 462 446 430 414 398 382 366 350 334 318 302 286 270 254 238 222 206 190 174 158 142 126 110 94 78 62 46 30 14 (kgdb) #0 doadump () at pcpu.h:223 #1 0x80590c59 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0x8059108c in panic (fmt=0x80951fc4 %s) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0x80878fd8 in trap_fatal (frame=0xff0060c0b740, eva=Variable eva is not available. ) at /usr/src/sys/amd64/amd64/trap.c:857 #4 0x808799ea in trap (frame=0xff8040d2c9d0) at /usr/src/sys/amd64/amd64/trap.c:644 #5 0x8085f983 in calltrap () at /usr/src/sys/amd64/amd64/exception.S:224 #6 0xff8040d2cc83 in ?? () #7 0xff8040d2cb50 in ?? () #8 0xff8040d2caf0 in ?? () #9 0xff8040d2cbf0 in ?? () #10 0xff0060c0b740 in ?? () #11 0x80b83c60 in sysent () #12 0xff8040d2cc80 in ?? () #13 0xff8040d2cae0 in ?? () #14 0x8059c431 in bintime (bt=0x80ad3140) at /usr/src/sys/kern/kern_tc.c:200 Previous frame inner to this frame (corrupt stack?) (kgdb) -- Andriy Gapon ___ 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: ZFS will gone,FreeBSD will import btrfs?
So all we need to direct some of the money we already spend for supporting developers and certain developments to core ZFS developers no longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS development platform for the future. If you have the key developers, the community will follow. I'd argue that we'll need pjd@ more than ever. I don't think that ex-OpenSolaris contributors are going to jump to FreeBSD. There's project Illumos which is essentially an OpenSolaris fork minus binary-only bits. My guess is that it's got a decent chance to become a viable OpenSolaris replacement. Interestingly enough, Illumos plans to import FreeBSD drivers (and some utils) to replace closed-source ones that used to come from Solaris. --Artem On Wed, Aug 18, 2010 at 5:54 AM, Oliver Brandmueller o...@e-gitt.net wrote: Hi, On Tue, Aug 17, 2010 at 09:47:00AM -0700, Xin LI wrote: It's not gone since Oracle can not withdraw code that is already licensed under CDDL. They _may_ choose not to release anything new but we already have a newer zfs version that have basic functionality usable in p4. So all we need to direct some of the money we already spend for supporting developers and certain developments to core ZFS developers no longer employed by Sun/Oracle and that way make FreeBSD the primary ZFS development platform for the future. If you have the key developers, the community will follow. Before someone starts argueing... I know, it's not that easy and I don't have a clue how one would do that. This is most probably more like a crazy idea than a plan that could actually work :-/ - Oliver -- | Oliver Brandmueller http://sysadm.in/ o...@sysadm.in | | Ich bin das Internet. Sowahr ich Gott helfe. | ___ 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: CFR: Replace man/manpath/whatis/apropos with a shell script
On Wed Aug 18 10, Gordon Tetlow wrote: All, I sat down and rewrote the man tools from a relatively old codebase to a single shell script. My original motivation was to allow multiple configuration files so port installations did not have to mess with /etc/manpath.config (like perl for example) when needing to manipulate the manpath. After looking at the existing code, I figured I could rewrite it as a shell script relatively easily. Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, /usr/bin/whatis) http://people.freebsd.org/~gordon/man.shhttp://people.freebsd.org/%7Egordon/man.sh wow! that's great. thanks a lot. :) could you have a look at gnu/4419? although your script seems to fix this issue partially, when *.[0-9] and *[0-9].gz manuals exist it will choose the uncompressed file and complain with not in gzip format. it would be nice if your script would prefer compressed over uncompressed manuals. however i'm not sure if a different approach might be better. people with more in depth knowledge might want to comment on this. cheers. alex Features of the new code: 1. BSD licensed (old code is GPL). 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf (purposefully changed the manpath.config file since it is a different syntax). 3. Allows ports to override the toolset used to display the manpage based on language. This was done to try to merge the functionality of the japanese/man port into the base system as much as possible. I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd whatever will generally give me the debug information I need). Thanks, Gordon -- a13x ___ 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: Interpreted language(s) in the base
+---[ Luigi Rizzo ]-- | On Wed, Aug 18, 2010 at 11:43:41PM +1000, Andrew Reilly wrote: | On Sun, Aug 15, 2010 at 11:15:55PM -0700, Doug Barton wrote: | got any other suggestions? | | This is very much a sorry I asked question, but is none-the | less quite a good one, given the size of the hole to be plugged. | | I think that a reasonable answer for this sort of thing might be | one of the dynamic languages that compiles to C, like (perhaps) | one of the schemes (chicken, gambit-C, bigloo, etc). You get | the benefit of flexibility and dynamism with good regexp and | data structure ability, good performance, and only requiring the | build tools available in the base system, as long as you don't | want to be the developer: just ship the C code (as well as the | source, of course). | | slightly off topic but I disagree on the latter part. | | The whole point of having source code is to be able to make | modifications, small or large, private or ones to be contributed | back. As a teacher, i am very concerned about the ease-of-use for | non-developer types: it is important to make it easy for people to | experiments, as this is one of the ways people learn things. I have to agree with Luigi. You have to work out your target audience, and that should be your first constraint to choosing the language. If the language has a syntax structure that's going to be hard to parse by non-developers at first glance (like forth or perl), then you're really limiting the userbase. C is scriptable and embeddable these days from a variety of projects, but, I wouldn't recommend that either necessarily (since C doesn't have dynamic typing), even if we could get 100% architecture coverage. -- Andrew Milton a...@theinternet.com.au ___ 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
Removal of ICC (intel compiler) bits from mk
Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) -- Rui Paulo___ 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: Removal of ICC (intel compiler) bits from mk
On 18 Aug 2010, at 18:18, Garrett Cooper wrote: On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo rpa...@gmail.com wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. Regards, -- Rui Paulo ___ 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: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo rpa...@gmail.com wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? Thanks, -Garrett ___ 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: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 10:18 AM, Garrett Cooper gcoo...@freebsd.org wrote: On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulo rpa...@gmail.com wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, Sorry -- wrong term. s/compliant/compatible/ :). wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? Thanks, -Garrett ___ 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: Official request: Please make GNU grep the default
Em 2010.08.13. 10:43, Doug Barton escreveu: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gabor, I hope at this point it goes without saying that I have a lot of respect for the work you've done on BSD grep, and I've already told you that I think you're very courageous for taking the project on. I've been testing and evaluating it for some time now, and I think I've given it a fair trial. You've done a fairly good job of responding to bug reports, and I understand that the exposure BSD grep has received as the default in HEAD has been very valuable in exposing additional areas that need work. However, with all that in mind I am officially asking you to please change the default in HEAD to GNU grep. (Note, I am _not_ asking you to remove BSD grep from the tree, just to change the default.) My reason is simple, performance. [...] I've just committed a patch with the kind help of Dimitry Andric, which gives BSD grep a huge performance boost. The performance is now almost comparable to GNU grep. I think with this, BSD grep may remain default if no other serious issues come up. Please report if you notice something weird. I know about some minor issues, which aren't fixed yet. I'll be out for 4 days as of tomorrow but when I come back I'll take care of these: - Infinite loop when reading directory on ZFS/NFS filesystem - Problems with context grepping When reply, please remove core@ from CC, let's not bother them with this, I just wanted to let them know that I'm not neglecting this issue but if still demanded for a good reason, I'll switch back to default GNU grep. Gabor ___ 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: Removal of ICC (intel compiler) bits from mk
Em 2010.08.18. 19:37, Rui Paulo escreveu: On 18 Aug 2010, at 18:18, Garrett Cooper wrote: On Wed, Aug 18, 2010 at 9:23 AM, Rui Paulorpa...@gmail.com wrote: Hi, I've been chatting with the ICC ex-users and they seem to be ok with the removal of the ICC bits from share/mk and other places. The reason is that it doesn't work and no one has volunteered to fix it for many years. This seems to indicate that the interest in ICC is low. If there's anyone against this, speak now or forever be silent. :-) Later versions of icc are more gcc compliant aren't they? If so, wouldn't this also be a non-issue to remove the bits, or are there still some incompatibilities between gcc and icc that are worth noting? I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. IIRC, apart from the low interest, the problem was that because of ICC's license using ICC to test this mk stuff requires a commercial license because somehow it is considered a derivative work. It has also prevented us from providing better support. In 2006, I wanted to do some progress as part of my SoC project because that time there was more interest. Alexander (CC'd) may comment on this. I think he has a license for FreeBSD work but he is not allowed to give it out to a third party. Gabor ___ 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: Removal of ICC (intel compiler) bits from mk
On 2010-08-18 19:37, Rui Paulo wrote: I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. I recently installed the port, which has icc 8.1, but it fails to compile even simple C++ programs, because it cannot cope with the libstdc++ headers from g++ 4.2.1. You have to do all kinds of tricks, such as installing the gcc 3.4.x port, and pointing the Intel compiler to its libstdc++ headers and libraries, or nothing will work. Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) ___ 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: Official request: Please make GNU grep the default
In message: 4c6c1cfe.6060...@freebsd.org Gabor Kovesdan ga...@freebsd.org writes: : When reply, please remove core@ from CC, let's not bother them with : this, I just wanted to let them know that I'm not neglecting this : issue but if still demanded for a good reason, I'll switch back to : default GNU grep. So making it default turned out well in the end. Sure, there was pain involved (but this is current), but making it default exposed the pain that would otherwise have gone unnoticed. The big hue and cry, while excessive at times, did result in people actually running the profiling tools which pointed to the buffering as the number one thing to fix. That being fixed now, it looks like we can go to the next stage: benchmarking again. Thanks, Gabor and everybody else that contributed, for seeing this through. Warner ___ 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: Official request: Please make GNU grep the default
Op 18 aug. 2010 om 18:48 heeft Gabor Kovesdan ga...@freebsd.org het volgende geschreven: Em 2010.08.13. 10:43, Doug Barton escreveu: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Gabor, I hope at this point it goes without saying that I have a lot of respect for the work you've done on BSD grep, and I've already told you that I think you're very courageous for taking the project on. I've been testing and evaluating it for some time now, and I think I've given it a fair trial. You've done a fairly good job of responding to bug reports, and I understand that the exposure BSD grep has received as the default in HEAD has been very valuable in exposing additional areas that need work. However, with all that in mind I am officially asking you to please change the default in HEAD to GNU grep. (Note, I am _not_ asking you to remove BSD grep from the tree, just to change the default.) My reason is simple, performance. [...] I've just committed a patch with the kind help of Dimitry Andric, which gives BSD grep a huge performance boost. The performance is now almost comparable to GNU grep. I think with this, BSD grep may remain default if no other serious issues come up. Please report if you notice something weird. I know about some minor issues, which aren't fixed yet. I'll be out for 4 days as of tomorrow but when I come back I'll take care of these: - Infinite loop when reading directory on ZFS/NFS filesystem - Problems with context grepping When reply, please remove core@ from CC, let's not bother them with this, I just wanted to let them know that I'm not neglecting this issue but if still demanded for a good reason, No worries there Gabor! Wilko I'll switch back to default GNU grep. Gabor ___ 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: 8.1-release + zfs v15 df(1) hangs
Hej there, Am 18.08.10 17:18, schrieb Andriy Gapon: on 18/08/2010 11:23 Marian Hettwer said the following: Hi All, i installed freebsd 8.1-release on my workstation (based on the 8.1-release mfsbsd isos) and I'm now experiencing some strange effects. A df(1) doesn't return and is not killable and while taking a look around in my process table, I could find several find's hanging around too. mhettwer 5976 0.0 0.0 6896 1088 13 D+5:55PM 0:00.00 df -h mhettwer 5351 0.0 0.0 6896 1088 19 D+1:49PM 0:00.00 df -h Can you run procstat -k to see where exactly the processes are stuck? for some reason, the stuck df and find processes are gone. And since df works again, I could see a nfs mount which I guessed caused the issue. Hm, so best guess, a hanging nfs mount is not good. I remember I mounted it without any special options. just mount ip:/export /mnt and probably forgot about it. I'll try and reproduce that tomorrow. I would say, a hanging nfs mount shouldn't lead to a hanging around df(1). all the best, Marian ___ 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote:
On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote:
On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote:
On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote:
Also please take a note of the John' suggestion to use the taskqueue.
I decided to go this road. Thank you both.
Now I do nfs buildkernel survive and prepare some benchmark results.
So, I modified the patch to defer proc_create() with taskqueue(9).
Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation.
Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both
nfs-mounted over 1Gbit LAN.
clean old
1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w
clean new
1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w
Patch needs polishing, though it generally works.
Not sure if shep_chan (or whatever name it will get) needs locking.
As I said yesterday, if several requests to create nfsiod coming one
after another, you would loose all but the last.
You should put the requests into the list, probably protected by
nfs_iod_mtx.
How about this patch? Still several things to ask.
1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held.
2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated.
3) if (1) is fine, is it right to use fail: logic (i.e. set
NFSIOD_NOT_AVAILABLE)
on memory shortage? Not tested.
There are debug printf() left intentionally to see how 3 contexts run under load
to each other. I attached these messages as well if that makes sense.
--
wbr,
pluknet
dmesg.out
Description: Binary data
Index: sys/nfsclient/nfs_subs.c
===
--- sys/nfsclient/nfs_subs.c (revision 211279)
+++ sys/nfsclient/nfs_subs.c (working copy)
@@ -59,6 +59,7 @@
#include sys/sysent.h
#include sys/syscall.h
#include sys/sysproto.h
+#include sys/taskqueue.h
#include vm/vm.h
#include vm/vm_object.h
@@ -117,6 +118,7 @@
struct nfs_bufq nfs_bufq;
static struct mtx nfs_xid_mtx;
+struct task nfs_nfsiodnew_task;
/*
* and the reverse mapping from generic to Version 2 procedure numbers
@@ -354,6 +356,7 @@
*/
mtx_init(nfs_iod_mtx, NFS iod lock, NULL, MTX_DEF);
mtx_init(nfs_xid_mtx, NFS xid lock, NULL, MTX_DEF);
+ TASK_INIT(nfs_nfsiodnew_task, 0, nfs_nfsiodnew_tq, NULL);
nfs_pbuf_freecnt = nswbuf / 2 + 1;
Index: sys/nfsclient/nfs_nfsiod.c
===
--- sys/nfsclient/nfs_nfsiod.c (revision 211279)
+++ sys/nfsclient/nfs_nfsiod.c (working copy)
@@ -59,6 +59,7 @@
#include sys/fcntl.h
#include sys/lockf.h
#include sys/mutex.h
+#include sys/taskqueue.h
#include netinet/in.h
#include netinet/tcp.h
@@ -75,6 +76,17 @@
static void nfssvc_iod(void *);
+struct nfsiod_str {
+ SLIST_ENTRY(nfsiod_str) ni_list;
+ int *ni_inst;
+ int ni_iod;
+ int ni_error;
+ int ni_busy;
+ int ni_done;
+};
+static SLIST_HEAD(, nfsiod_str) nfsiodhead =
+SLIST_HEAD_INITIALIZER(nfsiodhead);
+
static int nfs_asyncdaemon[NFS_MAXASYNCDAEMON];
SYSCTL_DECL(_vfs_nfs);
@@ -159,11 +171,34 @@
sizeof (nfs_iodmax), sysctl_iodmax, IU,
Max number of nfsiod kthreads);
+void
+nfs_nfsiodnew_tq(__unused void *arg, int pending)
+{
+ struct nfsiod_str *nip;
+
+ mtx_lock(nfs_iod_mtx);
+ SLIST_FOREACH(nip, nfsiodhead, ni_list) {
+ printf(tq: SLIST nip: %p\n, nip);
+ if (nip-ni_busy == 0) {
+ nip-ni_busy = 1;
+ break;
+ }
+ }
+ mtx_unlock(nfs_iod_mtx);
+ KASSERT(nip != NULL, (nfs_nfsiodnew_tq: nip is NULL));
+ printf(tq: nip: %p\n, nip);
+ printf(tq: ni_inst: %p\n, nip-ni_inst);
+ printf(tq: ni_iod: %d\n, nip-ni_iod);
+ nip-ni_error = kproc_create(nfssvc_iod, nip-ni_inst, NULL,
+ RFHIGHPID, 0, nfsiod %d, nip-ni_iod);
+ nip-ni_done = 1;
+}
+
int
nfs_nfsiodnew(int set_iodwant)
{
- int error, i;
- int newiod;
+ int i, newiod, error;
+ struct nfsiod_str *nip, *nip_temp;
if (nfs_numasync = nfs_iodmax)
return (-1);
@@ -178,17 +213,34 @@
return (-1);
if (set_iodwant 0)
nfs_iodwant[i] = NFSIOD_CREATED_FOR_NFS_ASYNCIO;
+ nip = malloc(sizeof(*nip), M_TEMP, M_NOWAIT | M_ZERO);
+ if (nip == NULL)
+ goto fail;
+ nip-ni_inst = nfs_asyncdaemon + i;
+ nip-ni_iod = newiod;
+ SLIST_INSERT_HEAD(nfsiodhead, nip, ni_list);
mtx_unlock(nfs_iod_mtx);
- error = kproc_create(nfssvc_iod, nfs_asyncdaemon + i, NULL, RFHIGHPID,
- 0, nfsiod %d, newiod);
+ printf(new: nip: %p\n, nip);
+ printf(new: ni_inst: %p\n, nip-ni_inst);
+ printf(new: ni_iod: %d\n, nip-ni_iod);
+ taskqueue_enqueue(taskqueue_thread, nfs_nfsiodnew_task);
mtx_lock(nfs_iod_mtx);
- if (error) {
- if (set_iodwant 0)
- nfs_iodwant[i] = NFSIOD_NOT_AVAILABLE;
- return (-1);
+ error = nip-ni_error;
+ SLIST_FOREACH_SAFE(nip, nfsiodhead, ni_list, nip_temp) {
+ if (nip-ni_busy != 0 nip-ni_done != 0) {
+ SLIST_REMOVE(nfsiodhead, nip, nfsiod_str, ni_list);
+
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 18 August 2010 23:11, pluknet pluk...@gmail.com wrote: On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote: On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under load to each other. I attached these messages as well if that makes sense. Ah, yes. Sorry, forgot about that. This is from last run: 1139.225u 239.873s 7:44.90 296.6% 6524+2130k 77+43153io 220pf+0w -- wbr, pluknet ___ 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: 8.1-release + zfs v15 df(1) hangs
on 18/08/2010 22:07 Marian Hettwer said the following: I'll try and reproduce that tomorrow. I would say, a hanging nfs mount shouldn't lead to a hanging around df(1). See df -n. -- Andriy Gapon ___ 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: Removal of ICC (intel compiler) bits from mk
On Wed, Aug 18, 2010 at 10:56 AM, Dimitry Andric dimi...@andric.com wrote: On 2010-08-18 19:37, Rui Paulo wrote: I really don't know how compatible is the latest icc because no one ever updated the ports version. This is actually a hint that no one really uses this anymore. I recently installed the port, which has icc 8.1, but it fails to compile even simple C++ programs, because it cannot cope with the libstdc++ headers from g++ 4.2.1. You have to do all kinds of tricks, such as installing the gcc 3.4.x port, and pointing the Intel compiler to its libstdc++ headers and libraries, or nothing will work. Updating that port to icc 11.1 is probably not a trivial task, and making sure it compiles programs properly is even trickier... :) Yeah... I was referring to icc 11.x because of work that my old group was looking at doing back when I was working on Linux. Anything older than that probably has compatibility issues :). Thanks, -Garrett ___ 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On Wednesday, August 18, 2010 3:17:56 pm pluknet wrote: On 18 August 2010 23:11, pluknet pluk...@gmail.com wrote: On 18 August 2010 17:46, Kostik Belousov kostik...@gmail.com wrote: On Wed, Aug 18, 2010 at 02:43:19PM +0400, pluknet wrote: On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. So, I modified the patch to defer proc_create() with taskqueue(9). Below is `time make -j5 buildkernel WITHOUT_MODULES=yes` perf. evaluation. Done on 4-way CPU on clean /usr/obj with /usr/src /usr/obj both nfs-mounted over 1Gbit LAN. clean old 1137.985u 239.411s 7:42.15 298.0% 6538+2133k 87+43388io 226pf+0w clean new 1134.755u 240.032s 7:41.25 298.0% 6553+2133k 87+43367io 224pf+0w Patch needs polishing, though it generally works. Not sure if shep_chan (or whatever name it will get) needs locking. As I said yesterday, if several requests to create nfsiod coming one after another, you would loose all but the last. You should put the requests into the list, probably protected by nfs_iod_mtx. How about this patch? Still several things to ask. 1) I used malloc instance w/ M_NOWAIT, since it's called with nfs_iod_mtx held. 2) Probably busy/done gymnastics is a wrong mess. Your help is appreciated. 3) if (1) is fine, is it right to use fail: logic (i.e. set NFSIOD_NOT_AVAILABLE) on memory shortage? Not tested. There are debug printf() left intentionally to see how 3 contexts run under load to each other. I attached these messages as well if that makes sense. Ah, yes. Sorry, forgot about that. Your task handler needs to run in a loop until the list of requests is empty. If multiple threads call taskqueue_enqueue() before your task is scheduled, they will be consolidated down to a single call of your task handler. - int error, i; - int newiod; + int i, newiod, error; You should sort these alphabetically if you are going to change this. I would probably just leave it as-is. Also, I'm not sure how this works as you don't actually wait for the task to complete. If the taskqueue_enqueue() doesn't preempt, then you may read ni_error as zero before the kproc has actually been created and return success even though an nfsiod hasn't been created. -- 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: Official request: Please make GNU grep the default
On 2010-Aug-17 22:29:46 +0200, Dimitry Andric dimi...@andric.com wrote: On 2010-08-17 18:29, Alan Cox wrote: Try it again on a memory resident file with the MAP_PREFAULT_READ option that is provided by this patch: http://www.cs.rice.edu/~alc/MAP_PREFAULT_READ.patch A time trial gives: grep with normal mmap() 1396s grep with prefault mmap() 1354s grep with regular read() 1354s Is this with uncached (ie remount the filesystem on each test) or cached data? Which filesystem (and does it change for different filesystems (particularly between UFS and ZFS))? And one trial is not statistically valid - especially given the small differences. How about multiple multiple trials with ministat. -- Peter Jeremy pgpPvNHrEZWZQ.pgp Description: PGP signature
Re: Official request: Please make GNU grep the default
On 2010-08-18 22:52, Peter Jeremy wrote: grep with normal mmap() 1396s grep with prefault mmap() 1354s grep with regular read() 1354s Is this with uncached (ie remount the filesystem on each test) or cached data? This is all on the same filesystem, and the test file is ~370MB, so eventually all data will be in RAM, most likely. E.g. normal mmap() seems to add a bit of overhead that explains the slower result. Which filesystem (and does it change for different filesystems (particularly between UFS and ZFS))? I only checked on UFS2. And one trial is not statistically valid - especially given the small differences. How about multiple multiple trials with ministat. The result were averages of three trials; they were fairly close to each other, but I didn't calculate the standard deviation. I was not aware of ministat, which looks like a real handy program. :) ___ 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: CFR: Replace man/manpath/whatis/apropos with a shell script
On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow gor...@tetlows.org wrote: All, I sat down and rewrote the man tools from a relatively old codebase to a single shell script. My original motivation was to allow multiple configuration files so port installations did not have to mess with /etc/manpath.config (like perl for example) when needing to manipulate the manpath. After looking at the existing code, I figured I could rewrite it as a shell script relatively easily. Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, /usr/bin/whatis) http://people.freebsd.org/~gordon/man.shhttp://people.freebsd.org/%7Egordon/man.sh Features of the new code: 1. BSD licensed (old code is GPL). 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf (purposefully changed the manpath.config file since it is a different syntax). 3. Allows ports to override the toolset used to display the manpage based on language. This was done to try to merge the functionality of the japanese/man port into the base system as much as possible. I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd whatever will generally give me the debug information I need). Thanks, Gordon I did some additional testing with the japanese/man-doc port and found the following was necessary: 1. Install my script as /usr/bin/man 2. Install japanese/man-doc 3. Create a /usr/local/etc/man.d/ja-man-doc.conf with the following contents: EQN_JA /usr/local/bin/geqn COL_JA /bin/cat NROFF_JA /usr/local/bin/groff -S -Wall -mtty-char -man -Tnippon -dlang=ja_JP.eucJP PIC_JA /usr/local/bin/gpic TBL_JA /usr/local/bin/gtbl TROFF_JA /usr/local/bin/groff -man -dlang=ja_JP.eucJP MANLOCALE ja_JP.eucJP 4. Create a symlink from /usr/share/man/ja.eucJP - /usr/local/man/ja 5. Set LC_CTYPE=ja_JP.eucJP 6. man ls When all is said and done, 3 should be handled by the man-doc port while 4 is a problem. The current base system man uses the following search order for localized manpages (which I have emulated): Look in /usr/share/man/lang.enc /usr/share/man/ ... /usr/local/man//lang.enc /usr/local/man/ ... Without step 4 from above, if you were to attempt to get a localized manpage for ls(1) that resides in /usr/local/man/lang.enc, you would never see it because the english language manpage in /usr/share/man would be found first. The japanese man port gets around this by installing their own man implementation (jman) forcing /usr/local/man/ja before /usr/share/man in the search order. I'm interested in feedback about whether the search order should change or if I should leave it as is. ___ 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: Official request: Please make GNU grep the default
On 2010-08-18 23:12, Dimitry Andric wrote: And one trial is not statistically valid - especially given the small differences. How about multiple multiple trials with ministat. The result were averages of three trials Actually, since I kept using Doug's original grep-time-trial.sh, each of the three 'trials' consisted of running grep 100 times, and the listed time was the total elapsed time for those 100 runs. So I assume that will reasonably average out the differences between each individual run? Also, I'm not sure if the actual disk/fs reading performance will differ much between GNU grep and any other grep, since they will all basically read through the whole test file sequentially. For instance, when I profiled GNU grep with gprof, the top time results were: % cumulative self self total time seconds secondscalls ms/call ms/call name 99.1 0.59 0.5911497 0.05 0.05 read [5] 0.6 0.59 0.0011497 0.00 0.00 kwsexec [8] 0.1 0.59 0.000 100.00% .mcount (130) 0.1 0.59 0.001 0.62 594.77 grepfile [3] 0.1 0.60 0.0011496 0.00 0.00 memmove [9] 0.0 0.60 0.004 0.03 0.03 memchr [10] 0.0 0.60 0.0012541 0.00 0.00 memset [16] 0.0 0.60 0.0011497 0.00 0.00 EGexecute [7] 0.0 0.60 0.0011497 0.00 0.05 fillbuf [4] 0.0 0.60 0.0011497 0.00 0.00 grepbuf [6] E.g. it looks like most of the time is spent in the read system call. If mmap'ing can help improve that, it would be nice, but I suspect the gains would be marginal. The actual performance difference is much more likely to be related to how efficiently grep parses out lines, and searches for regexps in there. BSD grep still has quite some room for improvement in that department. ___ 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: Interpreted language(s) in the base
Hi Luigi, On 19/08/2010, at 00:28 , Luigi Rizzo wrote: slightly off topic but I disagree on the latter part. I didn't expect everyone to agree. Not sure that I do, necessarily, either. (A neat, small language like TCL or Lua is probably better for most of the uses we're discussing here.) Just making a low-impact suggestion to the problem of making use of a higher-level language than C while not dragging large lumps of code into core, or accumulating maintenance issues. The whole point of having source code is to be able to make modifications, small or large, private or ones to be contributed back. As a teacher, i am very concerned about the ease-of-use for non-developer types: it is important to make it easy for people to experiments, as this is one of the ways people learn things. I'm not making any suggestion about preventing or discouraging tinkering. After all, we used to carry f2c around in the base, in order to support Fortran code. There's no particular reason *not* to provide the front-end for (whatever language), but so long as it's readily available in ports, and build-able form a base config, I don't see that being in base is essential. Having sources in some fantastic new language 'fuffa' and no 'fuffa2c' tool is almost as bad as having no source. This is an opinion I certainly don't share. There are many languages that I don't like but that doesn't make them useful, or even best-for-purpose in their niche. (a) I'm not suggesting that we don't provide source, and (b) learning a new language is an excellent excellent exercise for students, and one that they're going to have to go through often, for the rest of their careers. (in fact, it is like the joke of supplying source for the GPL'd software in your brand new LCD tv or appliance. I'd like to know who will ever be able to build an updated image and upload it to the appliance) It's nothing of the sort, of course. In the scenario I suggested, the task of updating the putative program would involve the editors available in base, to edit the source shipped with the system. Only the compilation of the edited source might or might not be gated by installing the port for the putative compiler. Several of the examples I gave originally come with an interpreter and debugging environment, so even that potential argument need not be a blocker. Not a high bar to entry, I suggest. Cheers, -- Andrew ___ 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: CFR: Replace man/manpath/whatis/apropos with a shell script
Gordon Tetlow gor...@tetlows.org writes: I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd whatever will generally give me the debug information I need). It doesn't search in bin/../man nor in bin/.man. For example, my PATH contains $LOCALBASE/bin:$HOME/.bin, while /etc/manpath.config is default one and contains /usr/local/man which does not exist here. $ man -w mplayer rsync HOME/.bin/man/man1/mplayer.1 LOCALBASE/man/man1/rsync.1.gz $ echo $PATH LOCALBASE/libexec/ccache:HOME/.bin:LOCALBASE/sbin:LOCALBASE/bin:/sbin:/bin:/usr/sbin:/usr/bin:/usr/games:HOME/blah/bin Unfortunately, if ~/.bin is in PATH it still will not search in ~/.man without touching MANPATH. But with man.sh it doesn't respect PATH at all. $ man -ddd -w mplayer rsync -- Using architecture: amd64:amd64 -- Using pager: less -- Using manual sections: 1:1aout:8:2:3:n:4:5:6:7:9:l -- Using manual path: /usr/share/man:/usr/share/openssl/man:/usr/local/man -- Using locale paths: en_US.UTF-8:en.UTF-8:. -- Searching for mplayer -- Searching section 1 -- Searching directory /usr/share/man/en.UTF-8/man1 -- Searching directory /usr/share/man/man1 -- Searching directory /usr/share/openssl/man/man1 -- Searching section 1aout -- Searching directory /usr/share/man/en.UTF-8/man1aout -- Searching directory /usr/share/man/man1aout -- Searching section 8 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8 -- Searching section 2 -- Searching directory /usr/share/man/en.UTF-8/man2 -- Searching directory /usr/share/man/man2 -- Searching section 3 -- Searching directory /usr/share/man/en.UTF-8/man3 -- Searching directory /usr/share/man/man3 -- Searching directory /usr/share/openssl/man/man3 -- Searching section n -- Searching section 4 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4 -- Searching section 5 -- Searching directory /usr/share/man/en.UTF-8/man5 -- Searching directory /usr/share/man/man5 -- Searching section 6 -- Searching directory /usr/share/man/en.UTF-8/man6 -- Searching directory /usr/share/man/man6 -- Searching section 7 -- Searching directory /usr/share/man/en.UTF-8/man7 -- Searching directory /usr/share/man/man7 -- Searching section 9 -- Searching directory /usr/share/man/en.UTF-8/man9 -- Searching directory /usr/share/man/man9 -- Searching section l No manual entry for mplayer -- Searching for rsync -- Searching section 1 -- Searching directory /usr/share/man/en.UTF-8/man1 -- Searching directory /usr/share/man/man1 -- Searching directory /usr/share/openssl/man/man1 -- Searching section 1aout -- Searching directory /usr/share/man/en.UTF-8/man1aout -- Searching directory /usr/share/man/man1aout -- Searching section 8 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8/amd64 -- Searching directory /usr/share/man/en.UTF-8/man8 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8/amd64 -- Searching directory /usr/share/man/man8 -- Searching section 2 -- Searching directory /usr/share/man/en.UTF-8/man2 -- Searching directory /usr/share/man/man2 -- Searching section 3 -- Searching directory /usr/share/man/en.UTF-8/man3 -- Searching directory /usr/share/man/man3 -- Searching directory /usr/share/openssl/man/man3 -- Searching section n -- Searching section 4 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4/amd64 -- Searching directory /usr/share/man/en.UTF-8/man4 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4/amd64 -- Searching directory /usr/share/man/man4 -- Searching section 5 -- Searching directory /usr/share/man/en.UTF-8/man5 -- Searching directory /usr/share/man/man5 -- Searching section 6 -- Searching directory /usr/share/man/en.UTF-8/man6 -- Searching directory
Re: CFR: Replace man/manpath/whatis/apropos with a shell script
Anonymous swel...@gmail.com writes: Gordon Tetlow gor...@tetlows.org writes: I've tried to make this mirror the functionality, directory search order, and arguments as the current base implementation. This brings me to my next point. I need some testers willing to try this out. It would be particularly great if I could get some foreign language testers with localized manpage installations. If something doesn't work the way you expect, please contact me and I can help debug it (using man -ddd whatever will generally give me the debug information I need). It doesn't search in bin/../man nor in bin/.man. Oops, I meant bin/man there. ___ 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 18 August 2010 12:07, pluknet pluk...@gmail.com wrote: On 17 August 2010 20:04, Kostik Belousov kostik...@gmail.com wrote: Also please take a note of the John' suggestion to use the taskqueue. I decided to go this road. Thank you both. Now I do nfs buildkernel survive and prepare some benchmark results. I'm away from home, so I can only do email and haven't looked at the patch, but I think you might want to consider avoiding the malloc() failure by calling malloc(... M_WAITOK); before grabbing the mutex. Then, set the pointer to NULL if you use it and free it at the end (I tend to test for non-NULL before calling free(), but others have pointed out that this isn't necessary.) I believe this is called Dykstra's technique, although I used it a lot before I found out it had been published. I think handling the case where malloc() fails correctly could be difficult which is why I suggested the above. Good luck with the patch, rick ___ 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
unionfs a little improvement
Hi Ed and unionfs fan gyus.
Ed pointed out a contradict behavior between current
unionfs implementation and its manual, and sent me a
patch.
Thanks Ed ;)
Index: sys/fs/unionfs/union_vfsops.c
===
--- sys/fs/unionfs/union_vfsops.c (revision 211093)
+++ sys/fs/unionfs/union_vfsops.c (working copy)
@@ -89,7 +89,6 @@
u_short ufile;
unionfs_copymode copymode;
unionfs_whitemode whitemode;
- struct componentname fakecn;
struct nameidata nd, *ndp;
struct vattrva;
@@ -280,26 +279,6 @@
mp-mnt_flag |= ump-um_uppervp-v_mount-mnt_flag MNT_RDONLY;
/*
-* Check whiteout
-*/
- if ((mp-mnt_flag MNT_RDONLY) == 0) {
- memset(fakecn, 0, sizeof(fakecn));
- fakecn.cn_nameiop = LOOKUP;
- fakecn.cn_thread = td;
- error = VOP_WHITEOUT(ump-um_uppervp, fakecn, LOOKUP);
- if (error) {
- if (below) {
- VOP_UNLOCK(ump-um_uppervp, 0);
- vrele(upperrootvp);
- } else
- vput(ump-um_uppervp);
- free(ump, M_UNIONFSMNT);
- mp-mnt_data = NULL;
- return (error);
- }
- }
-
- /*
* Unlock the node
*/
VOP_UNLOCK(ump-um_uppervp, 0);
Ed's message here:
Just for fun I was hacking on a writable bootcd, using unionfs and
tmpfs. I noticed tmpfs doesn't support whiteouts (yet). This prevents
unionfs from mounting tmpfs on top. I do want to be able to use tmpfs,
even if it means we can't get any whiteouts.
The manpage says the following:
Without whiteout support from the file system backing the upper layer,
there is no way that delete and rename operations on lower layer
objects
can be done. EROFS is returned for this kind of operations along with
any others which would make modifications to the lower layer, such as
chmod(1).
This seems to contradict the current behaviour, which is to deny the
mount altogether. The attached patch makes it work, but instead of
EROFS, it now returns EOPNOTSUPP, as generated by VOP_WHITEOUT().
It looks like reasonable and patch is simple and effective I guess.
If you unionfs guys or fs guys have some ideas around this patch,
please teach me.
After some tests and a couple of weeks after, I'll commit ed's patch
if there is no objections.
--
Daichi GOTO
CEO | ONGS Inc.
81-42-316-7945 | dai...@ongs.co.jp | http://www.ongs.co.jp
LinkedIn: http://linkedin.com/in/daichigoto
___
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: 8.1-release + zfs v15 df(1) hangs
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 08/18/2010 15:46, Andriy Gapon wrote:
on 18/08/2010 22:07 Marian Hettwer said the following:
I'll try and reproduce that tomorrow. I would say, a hanging nfs mount
shouldn't lead to a hanging around df(1).
See df -n.
Going with this making an addition.
I usually add this to my periodic.conf:
daily_status_disks_df_flags=-h -i -t ufs,zfs
Adding '-c' for a system that has ZFS produces results that are not
correct for a total, but stating it more for reference. It might make
sense to patch df(1) so it looks at the begging portion of the
file-system up to the first '/' and get the value for free and used from
that but this is tricky when refreserved, quota and other properties
come into play and is a little beyond what df is meant for. But that
subject is for another thread.
I do wonder if it would make sense to just split the daily_status_disks*
into daily_status_{FILESYSTEM} to look like this
daily_status_ufs_df_flags etc... and keep daily_status_disks_df to be
defined as daily_status_disks_df=ufs zfs xfs
Ignore random babbling meant to spur thought. ;)
Regards,
- --
jhell,v
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.16 (FreeBSD)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
iQEcBAEBAgAGBQJMbIQnAAoJEJBXh4mJ2FR+1lkH/3UbwkUE0L7AbivsIc1bjZA6
R+6lVv80xquXrgxZiMZWAhd40fqaduztM9hWzicL2yEVIsg+lp1WE4IRo2pyUdFs
ZTDsa3RcDpXeTt2NmUdMHefd0RC0aRrrAmf1JGifUs2/UNHpT/5PP1fIl783P71J
z8VFNcGcCmCSUcSdg8I14LDoFAqfbA0DkpTDyYrQVcHmNEp7aBgvJBNF+9/3y4R9
wC6+CbPVy93L3yOmxIfEM88oHtq4zfMRLcNreMAx+bQntzM7bA2xJrXV8Zkt5Jok
RFqE7TScKyE89YulkosSFMs1OK0SwTFDHZdAIO4mM4V9mVcaaZ8iWTiGrlZRxoQ=
=Kf91
-END PGP SIGNATURE-
___
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: CFR: Replace man/manpath/whatis/apropos with a shell script
Gordon Tetlow gor...@freebsd.org wrote in aanlktikw3j5hbrz0gjpbab=8urfnkgjm069i8ennx...@mail.gmail.com: go On Wed, Aug 18, 2010 at 12:11 AM, Gordon Tetlow gor...@tetlows.org wrote: go go All, go go I sat down and rewrote the man tools from a relatively old codebase to a go single shell script. My original motivation was to allow multiple go configuration files so port installations did not have to mess with go /etc/manpath.config (like perl for example) when needing to manipulate the go manpath. After looking at the existing code, I figured I could rewrite it as go a shell script relatively easily. go go Script (install as /usr/bin/man, /usr/bin/manpath, /usr/bin/apropos, go /usr/bin/whatis) go http://people.freebsd.org/~gordon/man.shhttp://people.freebsd.org/%7Egordon/man.sh go go Features of the new code: go go 1. BSD licensed (old code is GPL). go 2. Imports configuration from /usr/local/etc/man.d/*.conf and /etc/man.conf go (purposefully changed the manpath.config file since it is a different go syntax). go 3. Allows ports to override the toolset used to display the manpage based go on language. This was done to try to merge the functionality of the go japanese/man port into the base system as much as possible. go go I've tried to make this mirror the functionality, directory search order, go and arguments as the current base implementation. go go This brings me to my next point. I need some testers willing to try this go out. It would be particularly great if I could get some foreign language go testers with localized manpage installations. If something doesn't work the go way you expect, please contact me and I can help debug it (using man -ddd go whatever will generally give me the debug information I need). go go Thanks, go Gordon go go go I did some additional testing with the japanese/man-doc port and found the go following was necessary: Great, I will test it and get back to you! -- Hiroki pgpQyXyxPu4Qz.pgp Description: PGP signature
[head tinderbox] failure on powerpc64/powerpc
TB --- 2010-08-19 01:12:25 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-08-19 01:12:25 - starting HEAD tinderbox run for powerpc64/powerpc TB --- 2010-08-19 01:12:25 - cleaning the object tree TB --- 2010-08-19 01:13:00 - cvsupping the source tree TB --- 2010-08-19 01:13:00 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/powerpc64/powerpc/supfile TB --- 2010-08-19 01:13:18 - building world TB --- 2010-08-19 01:13:18 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 01:13:18 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 01:13:18 - TARGET=powerpc TB --- 2010-08-19 01:13:18 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 01:13:18 - TZ=UTC TB --- 2010-08-19 01:13:18 - __MAKE_CONF=/dev/null TB --- 2010-08-19 01:13:18 - cd /src TB --- 2010-08-19 01:13:18 - /usr/bin/make -B buildworld World build started on Thu Aug 19 01:13:21 UTC 2010 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 stage 4.1: building includes stage 4.2: building libraries stage 4.3: make dependencies stage 4.4: building everything stage 5.1: building 32 bit shim libraries World build completed on Thu Aug 19 02:51:08 UTC 2010 TB --- 2010-08-19 02:51:08 - generating LINT kernel config TB --- 2010-08-19 02:51:08 - cd /src/sys/powerpc/conf TB --- 2010-08-19 02:51:08 - /usr/bin/make -B LINT TB --- 2010-08-19 02:51:08 - building LINT kernel TB --- 2010-08-19 02:51:08 - MAKEOBJDIRPREFIX=/obj TB --- 2010-08-19 02:51:08 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-08-19 02:51:08 - TARGET=powerpc TB --- 2010-08-19 02:51:08 - TARGET_ARCH=powerpc64 TB --- 2010-08-19 02:51:08 - TZ=UTC TB --- 2010-08-19 02:51:08 - __MAKE_CONF=/dev/null TB --- 2010-08-19 02:51:08 - cd /src TB --- 2010-08-19 02:51:08 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Thu Aug 19 02:51:08 UTC 2010 stage 1: configuring the kernel stage 2.1: cleaning up the object tree stage 2.2: rebuilding the object tree stage 2.3: build tools stage 3.1: making dependencies stage 3.2: building everything [...] /src/sys/dev/ofw/ofw_standard.c:705: warning: cast to pointer from integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_release': /src/sys/dev/ofw/ofw_standard.c:719: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c:724: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_enter': /src/sys/dev/ofw/ofw_standard.c:742: warning: cast from pointer to integer of different size /src/sys/dev/ofw/ofw_standard.c: In function 'ofw_std_exit': /src/sys/dev/ofw/ofw_standard.c:760: warning: cast from pointer to integer of different size *** Error code 1 Stop in /obj/powerpc.powerpc64/src/sys/LINT. *** Error code 1 Stop in /src. *** Error code 1 Stop in /src. TB --- 2010-08-19 03:04:31 - WARNING: /usr/bin/make returned exit code 1 TB --- 2010-08-19 03:04:31 - ERROR: failed to build lint kernel TB --- 2010-08-19 03:04:31 - 4834.63 user 1183.45 system 6726.66 real http://tinderbox.freebsd.org/tinderbox-head-HEAD-powerpc64-powerpc.full ___ 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
