Re: svn commit: r203134 - in head: share/man/man4 sys/conf sys/contrib/dev/run sys/dev/usb sys/dev/usb/wlan sys/modules sys/modules/runfw sys/modules/usb sys/modules/usb/run
On 29 January 2010 09:16, pluknet pluk...@gmail.com wrote: On 29 January 2010 01:24, Andrew Thompson thom...@freebsd.org wrote: Author: thompsa Date: Thu Jan 28 22:24:54 2010 New Revision: 203134 URL: http://svn.freebsd.org/changeset/base/203134 Log: Add run(4), a driver for Ralink RT2700U/RT2800U/RT3000U USB 802.11agn devices. This driver was written for OpenBSD by Damien Bergamini and ported over by Akinori Furukoshi. [...] Added: head/share/man/man4/run.4 [...] +The +.Nm +driver offloads both encryption and decryption of data frames to the +hardware for the WEP40, WEP104, TKIP(+MIC) and CCMP ciphers. +.Pp +The +.Nm +driver can be configured at runtime with +.Xr ifconfig 8 +or on boot with +.Xr hostname.if 5 . hostname.if(5) is something that only exists in OpenBSD. I think the following would be better: For more information on configuring this device, see .Xr ifconfig 8 . Hi, This is still relevant. hostname.if(5) is in OBSD. Will someone fix this? -- 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: Bumping MAXCPU on amd64?
2010/9/22 Maxim Sobolev sobo...@freebsd.org: Hi, Is there any reason to keep MAXCPU at 16 in the default kernel config? There are quite few servers on the market today that have 24 or even 32 physical cores. With hyper-threading this can even go as high as 48 or 64 virtual cpus. People who buy such hardware might get very disappointed finding out that the FreeBSD is not going to use such hardware to its full potential. Does anybody object if I'd bump MAXCPU to 32, which is still low but might me more reasonable default these days, or at least make it an kernel configuration option documented in the NOTES? Please correct me, if I'm about smth. different, but isn't it already? /sys/amd64/include/param.h:#define MAXCPU 32 /sys/arm/include/param.h:#defineMAXCPU 2 /sys/i386/include/param.h:#define MAXCPU32 /sys/ia64/include/param.h:#define MAXCPU 32 /sys/mips/include/param.h:#define MAXCPU MAXSMPCPU /sys/powerpc/include/param.h:#defineMAXCPU 2 /sys/sparc64/include/param.h:#define MAXCPU 16 /sys/sun4v/include/param.h:#define MAXCPU 32 (almost 2y ago for x86) -- 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: At r212060, but /usr/bin/drace and /usr/sbin/lockstat still depend on libz.so.5
On 6 September 2010 16:50, Anton Shterenlikht me...@bristol.ac.uk wrote: On sparc64 after updating to r212060, libz.so.5 came up as old library. I rebuit all ports to use libz.so.6 instead, but libchk still shows that Binaries that are linked with: /lib/libz.so.5 /usr/sbin/dtrace /usr/sbin/lockstat What did I do wrong that resulted in these 2 programs still linked against the old version of libz? Hi, Anton. After r210693, these utilities are built for i386 and amd64 only. Thereby you have stale binaries installed from older sources. -- 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: patch for topology detection of Intel CPUs
On 29 August 2010 13:25, Andriy Gapon a...@freebsd.org wrote: [Reposted from stable@; edited] The below patch is against sources in FreeBSD tree, it should be applied either to sys/amd64/amd64/mp_machdep.c or sys/i386/i386/mp_machdep.c depending on the desired architecture: http://people.freebsd.org/~avg/intel-cpu-topo.diff Hi, Andriy. I tried your patch and see no regression on Xeon 50xx, 55xx, 54xx. It also improved CPU detection on Xeon 54xx (as well as original Junk-uk's patch). It also improved CPU detection on Xen HVM @ Xeon 55xx @ 3 cores: FreeBSD/SMP: Multiprocessor System Detected: 3 CPUs FreeBSD/SMP: 1 package(s) x 3 core(s) cpu0 (BSP): APIC ID: 0 cpu1 (AP): APIC ID: 2 cpu2 (AP): APIC ID: 4 -- 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: [RFC] ifconfig description support in rc.d
On 27 August 2010 01:09, Xin LI delp...@delphij.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 2010/08/26 13:09, Doug Barton wrote: On 08/26/2010 12:53 PM, pluknet wrote: [cc'ing current@ as rc@ looks too quite] Hi. Since ifconfig has grown to label interfaces with ifconfig $ifname description foobar, what about to give it more life and store i/face descriptions semi-permanently, so they will survive between reboots? This patch adds a functionality to rc.d to label interfaces at boot time. Comments are welcome. This seems like a good addition, thanks. Please also write a patch for rc.conf.5 to describe this new functionality and I'll be happy to commit it. One note below. I have drafted one. Nice, thank you! With my poor English, this is a valuable help from you. (Note that fxp is a 100Mbps card so it might be sensible to replace it with just Switch 2?) Thanks for catching this. Will fix it. -- 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: [RFC] ifconfig description support in rc.d
On 27 August 2010 00:09, Doug Barton do...@freebsd.org wrote:
On 08/26/2010 12:53 PM, pluknet wrote:
[cc'ing current@ as rc@ looks too quite]
Hi.
Since ifconfig has grown to label interfaces with
ifconfig $ifname description foobar, what about
to give it more life and store i/face descriptions
semi-permanently, so they will survive between reboots?
This patch adds a functionality to rc.d to label
interfaces at boot time.
Comments are welcome.
This seems like a good addition, thanks. Please also write a patch for
rc.conf.5 to describe this new functionality and I'll be happy to commit it.
Xin Li helped me with updating rc.conf.5 (thanks!).
It's included in attached patch.
One note below.
--- etc/network.subr (revision 211280)
+++ etc/network.subr (working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
This is probably better as [ -n $_ifdescr ]
This was blindly copypasted after ifnet_rename().
So, it makes sense probably to change test expression there as well.
[see ifnet_rename() proposed change below inline]
This change to ifnet_rename() is not included in attached patch
to not complicate things unnecessarily for now.
Index: etc/network.subr
===
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1179,7 +1179,7 @@
# ifconfig_IF_name
for _if in `ifconfig -l`; do
_ifname=`get_if_var $_if ifconfig_IF_name`
- if [ ! -z $_ifname ]; then
+ if [ -n $_ifname ]; then
ifconfig $_if name $_ifname
fi
done
--
wbr,
pluknet
descr.rc.d.2.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
[RFC] ifconfig description support in rc.d
[cc'ing current@ as rc@ looks too quite]
Hi.
Since ifconfig has grown to label interfaces with
ifconfig $ifname description foobar, what about
to give it more life and store i/face descriptions
semi-permanently, so they will survive between reboots?
This patch adds a functionality to rc.d to label
interfaces at boot time.
Comments are welcome.
%%%
Index: etc/rc.d/netif
===
--- etc/rc.d/netif (revision 211280)
+++ etc/rc.d/netif (working copy)
@@ -75,6 +75,9 @@
# Rename interfaces.
ifnet_rename
+
+ # Give description to interfaces.
+ ifnet_descr
fi
# Configure the interface(s).
Index: etc/network.subr
===
--- etc/network.subr(revision 211280)
+++ etc/network.subr(working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
+ ifconfig $_if descr $_ifdescr
+ fi
+ done
+
+ return 0
+}
+
# list_net_interfaces type
# List all network interfaces. The type of interface returned
# can be controlled by the type argument. The type
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf(revision 211280)
+++ etc/defaults/rc.conf(working copy)
@@ -215,6 +215,7 @@
#ifconfig_ed0_ipv6=inet6 2001:db8:1::1 prefixlen 64 # Sample IPv6 addr entry
#ifconfig_ed0_alias0=inet6 2001:db8:2::1 prefixlen 64 # Sample IPv6 alias
#ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0.
+#ifconfig_fxp0_descr=Uplink to Gigabit Switch 2 # Label fxp0 interface
#vlans_fxp0=101 vlan0# vlan(4) interfaces for fxp0 device
#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device
#wlans_ath0=wlan0# wlan(4) interfaces for ath0 device
%%%
--
wbr,
pluknet
Index: etc/rc.d/netif
===
--- etc/rc.d/netif (revision 211280)
+++ etc/rc.d/netif (working copy)
@@ -75,6 +75,9 @@
# Rename interfaces.
ifnet_rename
+
+ # Give description to interfaces.
+ ifnet_descr
fi
# Configure the interface(s).
Index: etc/network.subr
===
--- etc/network.subr (revision 211280)
+++ etc/network.subr (working copy)
@@ -1187,6 +1187,24 @@
return 0
}
+# ifnet_descr
+# Add description to all requested interfaces.
+#
+ifnet_descr()
+{
+ local _if _ifdescr
+
+ # ifconfig_IF_descr
+ for _if in `ifconfig -l`; do
+ _ifdescr=`get_if_var $_if ifconfig_IF_descr`
+ if [ ! -z $_ifdescr ]; then
+ ifconfig $_if descr $_ifdescr
+ fi
+ done
+
+ return 0
+}
+
# list_net_interfaces type
# List all network interfaces. The type of interface returned
# can be controlled by the type argument. The type
Index: etc/defaults/rc.conf
===
--- etc/defaults/rc.conf (revision 211280)
+++ etc/defaults/rc.conf (working copy)
@@ -215,6 +215,7 @@
#ifconfig_ed0_ipv6=inet6 2001:db8:1::1 prefixlen 64 # Sample IPv6 addr entry
#ifconfig_ed0_alias0=inet6 2001:db8:2::1 prefixlen 64 # Sample IPv6 alias
#ifconfig_fxp0_name=net0 # Change interface name from fxp0 to net0.
+#ifconfig_fxp0_descr=Uplink to Gigabit Switch 2 # Label fxp0 interface
#vlans_fxp0=101 vlan0 # vlan(4) interfaces for fxp0 device
#create_arg_vlan0=vlan 102 # vlan tag for vlan0 device
#wlans_ath0=wlan0 # wlan(4) interfaces for ath0 device
___
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 19 August 2010 17:34, John Baldwin j...@freebsd.org wrote: On Thursday, August 19, 2010 5:29:25 am pluknet wrote: On 19 August 2010 00:07, John Baldwin j...@freebsd.org wrote: 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. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. - 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. Err.. that's resulted after a set of changes. Thanks for noting that. 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. I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pattern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). Ah, if it is safe to sleep then I have a couple of suggestions: Cool, credits go to John :). I just adopted all of your changes (attached). - Use M_WAITOK to malloc() so you don't have to worry about the failure case (I see Rick already suggested this). After all that reduces to the following replacement in nfs_nfsiodnew(). So, no regression should be there in theory. mtx_unlock(nfs_iod_mtx); - kproc_create(...) + malloc(...) mtx_lock(nfs_iod_mtx); It survived after this simple test running for an hour, which forces creation of many iods with r/w from 300 threads: nfsserv:/home/svn/freebsd/obj_exp on /usr/obj (nfs) ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 ./randomio /usr/obj/file 100 0.5 0 4096 60 100 while [ true ]; do sysctl vfs.nfs.iodmax=2; sysctl vfs.nfs.iodmax=60; sleep 20; done randomio is from ports/149838. P.S. it's funny to see in top 0 root 10 440 0K 144K deadlk 2 23:16 28.86% kernel Someone might think the kernel is in deadlock. -- wbr, pluknet nfsiod_tq_lock.3.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
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 19 August 2010 00:07, John Baldwin j...@freebsd.org wrote: 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. Thanks for your suggestions. So I converted nfs_nfsiodnew_tq() into loop, and as such I changed a cleanup SLIST_FOREACH() as well to free a bulk of (potentially consolidated) completed requests in one pass. kproc_create() is still out of the SLIST_FOREACH() to avoid calling it with nfs_iod_mtx held. - 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. Err.. that's resulted after a set of changes. Thanks for noting that. 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. I put taskqueue_drain() right after taskqueue_enqueue() to be in sync with task handler. That was part to think about, as I didn't find such a use pattern. It seems though that tasks are launched now strictly one-by-one, without visible parallelism (as far as debug printf()s don't overlap anymore). -- wbr, pluknet nfsiod_tq_lock.2.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
Re: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
On 19 August 2010 04:04, Rick Macklem rmack...@uoguelph.ca 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. 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 Nice :) I need to step back and get a timeout to re-think how to use this technique. -- 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: 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: 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
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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
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). load: 1.34 cmd: cp 1348 [bo_wwait] 4.74r 0.00u 0.00s 0% 1204k tst-web# procstat -k 1348 PIDTID COMM TDNAME KSTACK 1348 100095 cp -mi_switch sleepq_switch sleepq_wait _sleep bufobj_wwait nfs_flush nfs_close vn_close vn_closefile _fdrop closef kern_close syscallenter syscall Xfast_syscall Process 1347 (cp) thread 0xff0002ed7000 (100094) exclusive lockmgr nfs (nfs) r = 0 (0xff006a05a638) locked @ /usr/src/sys/kern/vfs_vnops.c:301 (kgdb) bt #0 sched_switch (td=0xff0002ed7000, newtd=0x80ca17e0, flags=Variable flags is not available. ) at /usr/src/sys/kern/sched_ule.c:1848 #1 0x805bf49b in mi_switch (flags=260, newtd=0x0) at /usr/src/sys/kern/kern_synch.c:449 #2 0x805f50e3 in sleepq_switch (wchan=0xff006a05a720, pri=77) at /usr/src/sys/kern/subr_sleepqueue.c:530 #3 0x805f5ccd in sleepq_wait (wchan=0xff006a05a720, pri=77) at /usr/src/sys/kern/subr_sleepqueue.c:609 #4 0x805bfac9 in _sleep (ident=0xff006a05a720, lock=0xff006a05a6c0, priority=Variable priority is not available. ) at /usr/src/sys/kern/kern_synch.c:234 #5 0x80633083 in bufobj_wwait (bo=0xff006a05a6c0, slpflag=Variable slpflag is not available. ) at /usr/src/sys/kern/vfs_bio.c:4016 #6 0x8077f5af in nfs_flush (vp=0xff006a05a5a0, waitfor=1, commit=Variable commit is not available. ) at /usr/src/sys/nfsclient/nfs_vnops.c:3216 #7 0x807802e3 in nfs_close (ap=0xff8029bd8900) at /usr/src/sys/nfsclient/nfs_vnops.c:644 #8 0x8065b3fe in vn_close (vp=0xff006a05a5a0, flags=2, file_cred=0xff006a01b600, td=0xff0002ed7000) at vnode_if.h:225 #9 0x8065b4fa in vn_closefile (fp=0xff00027c7500, td=0xff0002ed7000) at /usr/src/sys/kern/vfs_vnops.c:942 #10 0x8057e3e3 in _fdrop (fp=0xff00027c7500, td=Variable td is not available. ) at file.h:277 #11 0x8057ff4b in closef (fp=0xff00027c7500, td=0xff0002ed7000) at /usr/src/sys/kern/kern_descrip.c:2117 ---Type return to continue, or q return to quit--- #12 0x80580530 in kern_close (td=0xff0002ed7000, fd=4) at /usr/src/sys/kern/kern_descrip.c:1162 -- wbr, pluknet nfs_shep.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
LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
Hi. Seeing on mostly idle, recently updated current, while closing a file. Presumably never reported on ML. lock order reversal: 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xff000234a048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1580 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 fdinit() at fdinit+0x5b fdcopy() at fdcopy+0x2a fork1() at fork1+0x836 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffea88, rbp = 0 --- -- 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: LOR on nfs: vfs_vnops.c:301 kern_descrip.c:1580
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. lock order reversal: 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0xff000234a048 filedesc structure (filedesc structure) @ /usr/src/sys/kern/kern_descrip.c:1580 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_xlock() at _sx_xlock+0x55 fdinit() at fdinit+0x5b fdcopy() at fdcopy+0x2a fork1() at fork1+0x836 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffea88, rbp = 0 --- Mostly the same (different 2nd lock path). lock order reversal: 1st 0xff00198199f8 nfs (nfs) @ /usr/src/sys/kern/vfs_vnops.c:301 2nd 0x80ca47e0 proctree (proctree) @ /usr/src/sys/kern/kern_fork.c:335 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x807 _sx_slock() at _sx_slock+0x55 fork1() at fork1+0x190 kproc_create() at kproc_create+0x63 nfs_nfsiodnew() at nfs_nfsiodnew+0xd7 nfs_asyncio() at nfs_asyncio+0xa6 nfs_strategy() at nfs_strategy+0x83 bufstrategy() at bufstrategy+0x43 nfs_writebp() at nfs_writebp+0xcf nfs_flush() at nfs_flush+0x1dc nfs_close() at nfs_close+0x213 vn_close() at vn_close+0x10e vn_closefile() at vn_closefile+0x5a _fdrop() at _fdrop+0x23 closef() at closef+0x5b kern_close() at kern_close+0x110 syscallenter() at syscallenter+0x1aa syscall() at syscall+0x4c Xfast_syscall() at Xfast_syscall+0xe2 --- syscall (6, FreeBSD ELF64, close), rip = 0x80089830c, rsp = 0x7fffea88, rbp = 0 --- -- 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: bsdgrep does not work with tail -f | grep combination
On 4 August 2010 20:28, Lars Engels lars.eng...@0x20.net wrote: On Wed, Aug 04, 2010 at 10:51:08AM -0400, Alexandre Sunny Kovalenko wrote: On Tue, 2010-08-03 at 20:21 +0200, Gabor Kovesdan wrote: Em 2010.08.03. 19:25, poyop...@puripuri.plala.or.jp escreveu: Hi, It seems bsdgrep does not work when piped from tail -f. I'm running r210728. term0$ jot 10 /tmp/1 term0$ tail -f /tmp/1 | grep 0 [no output] otherterm$ jot 10 /tmp/1 [no output to term0] = with GNU grep: term0$ tail -f /tmp/1 | gnugrep 0 10 otherterm$ jot 10 /tmp/1 [on term0] 10 10 I've checked on 8.0 and GNU grep doesn't output anything either for me. If you use tail -f, you will enter more lines and end it with EOF, won't you? And then BSD grep will process the input and print out matches. I don't think it's bad behaviour in itself but if you can explain why you think it's bad I'm willing to change it. I am not sure it is specific to the GNU grep -- below is the example from AIX 5.3: [...] Same on Solaris, so this is not a GNU feature. By the way, egrep from 4.4BSD-Alpha used read(2) with 8k blocks. I justed checked, it works with tail -f. -- 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
[patch] big whitespace cleanup in sys/kern/*
Hi. I looked into sys/kern/* files to fix a bunch of common w/s style issues (221): - leading space before label; - leading space(s) before tab; - space(s) instead of tab(s); - space(s) in blank like. I tried to be conservative and didn't touch semi-contrib files and those with its own style. Here is a diff I'd like someone look into and check in if there will no objections. -- wbr, pluknet ws_kern.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
Re: panic in deadlkres
On 25 June 2010 13:50, Anton Yuzhaninov cit...@citrin.ru wrote:
I've got panic on 9-current from Jun 25 2010
May be this is bug in deadlock resolver
panic: blockable sleep lock (sleep mutex) process lock @
/usr/src/sys/kern/kern_clock.c:203
db show alllocks
Process 0 (kernel) thread 0xc4dcd270 (100047)
shared sx allproc (allproc) r = 0 (0xc0885ebc) locked @
/usr/src/sys/kern/kern_clock.c:193
db show lock 0xc4dcd270
class: spin mutex
name: D
flags: {SPIN, RECURSE}
state: {OWNED}
(kgdb) bt
#0 doadump () at pcpu.h:248
#1 0xc05ae59f in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416
#2 0xc05ae825 in panic (fmt=Variable fmt is not available.
) at /usr/src/sys/kern/kern_shutdown.c:590
#3 0xc048ff45 in db_panic (addr=Could not find the frame base for db_panic.
) at /usr/src/sys/ddb/db_command.c:478
#4 0xc0490533 in db_command (last_cmdp=0xc086ef1c, cmd_table=0x0, dopager=1)
at /usr/src/sys/ddb/db_command.c:445
#5 0xc0490662 in db_command_loop () at /usr/src/sys/ddb/db_command.c:498
#6 0xc04923ef in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:229
#7 0xc05dade6 in kdb_trap (type=3, code=0, tf=0xc4b31bd0) at
/usr/src/sys/kern/subr_kdb.c:535
#8 0xc078696b in trap (frame=0xc4b31bd0) at /usr/src/sys/i386/i386/trap.c:692
#9 0xc076ca0b in calltrap () at /usr/src/sys/i386/i386/exception.s:165
#10 0xc05daf30 in kdb_enter (why=0xc07ea02d panic, msg=0xc07ea02d panic)
at cpufunc.h:71
#11 0xc05ae806 in panic (fmt=0xc07efd94 blockable sleep lock (%s) %s @
%s:%d) at /usr/src/sys/kern/kern_shutdown.c:573
#12 0xc05ee30b in witness_checkorder (lock=0xc5148088, flags=9,
file=0xc07e3b20 /usr/src/sys/kern/kern_clock.c, line=203, interlock=0x0)
at /usr/src/sys/kern/subr_witness.c:1067
#13 0xc05a093c in _mtx_lock_flags (m=0xc5148088, opts=0, file=0xc07e3b20
/usr/src/sys/kern/kern_clock.c, line=203)
at /usr/src/sys/kern/kern_mutex.c:200
#14 0xc05706a9 in deadlkres () at /usr/src/sys/kern/kern_clock.c:203
#15 0xc0588721 in fork_exit (callout=0xc05705ea deadlkres, arg=0x0,
frame=0xc4b31d38) at /usr/src/sys/kern/kern_fork.c:843
#16 0xc076ca80 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270
Hi!
[throw in ideas (just ignore them if they're dumb, thinking badly atm).]
AFAIK, that indicates that some thread already has
a spin mutex and then it tries to acquire a sleep mutex.
Looks like kern/kern_clock.c v1.213 (SVN rev 206482)
has a regression in handling ticks wrap-up
w.r.t. it doesn't release a thread mutex, does it?
From subr_witness.c:
1062: * Since spin locks include a critical section, this check
1063: * implicitly enforces a lock order of all sleep
locks before
1064: * all spin locks.
1065: */
1066:if (td-td_critnest != 0 !kdb_active)
1067:panic(blockable sleep lock (%s) %s @ %s:%d,
1068:class-lc_name, lock-lo_name, file, line);
From kern_clock.c, v1.213 (in several places, while holding a thread lock):
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick)
+ continue;
Should not it be like the next:
+ /* Handle ticks wrap-up. */
+ if (ticks td-td_blktick) {
+ thread_unlock(td);
+ continue;
+ }
The precondition idea to reproduce it is to lock a subject thread
in some deadlkres callout, handle re-wrap condition, then try
to lock a process to witch the thread belongs in (n+m)'th deadlkres
callout, or in different context.
--
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: Dell Perc 5/i Performance issues
On 19 June 2010 11:17, Michael Reifenberger m...@reifenberger.com wrote: Have you enabled the disk caches as well? Something like: MegaCli -LdSetProp Cached -LALL -a0 MegaCli -LdSetProp NORA -LALL -a0 MegaCli -LdSetProp WB -LALL -a0 MegaCli -LdSetProp -EnDskCache -LALL -a0 (Only if having a USV of course) Dunno if there is a mfiutil equivalent though. Hi. That would be: mfiutil cache mfid0 enable mfiutil cache mfid0 read-ahead none mfiutil cache mfid0 write-back mfiutil cache mfid0 write-cache enable -- 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: [CFT] SIFTR - Statistical Information For TCP Research
On 13 June 2010 12:12, Lawrence Stewart lstew...@freebsd.org wrote: Hi all, The time has come to solicit some external testing for my SIFTR tool. I'm hoping to commit it within a week or so unless problems are discovered. SIFTR is a kernel module that logs a range of statistics on active TCP connections to a log file. It provides the ability to make highly granular measurements of TCP connection state, aimed at system administrators, developers and researchers. You can use the data to find bugs in the stack, understand why connections are performing badly and test new code to name a few uses. Development has been made possible in part by grants from the Cisco University Research Program Fund at Community Foundation Silicon Valley, and the FreeBSD Foundation. Bringing it into FreeBSD proper is being carried out under the auspices of the Enhancing the FreeBSD TCP Implementation FreeBSD Foundation project. More details are available at [1,2,3]. If you can help out, please read on! Before continuing, make sure you're running with at least svn revision 209119 (my commit to sys/pcpu.h), or you can manually apply the r209119 diff to to your earlier rev source tree. The SIFTR patch is here: http://people.freebsd.org/~lstewart/patches/tcp_ffcaia2008/siftr_9.x.r209119.patch Copy it to the root of your source tree and run the following: patch -p1 siftr_9.x.r209119.patch It's a loadable kernel module so you can build it for testing like so: cd path/to/src/sys/modules/siftr make kldload ./siftr.ko (don't forget to make cleandir to remove cruft when finished testing) After applying the patch, you can read the man page by running: man -M path/to/src/share/man siftr If I've done a decent job, all the info you need to understand what it does and how to use it should be in the man page. I'm interested in all feedback and reports of success/failure, along with details of the architecture tested and number of CPUs if you would be so kind. That should be enough to get the ball rolling. Thanks and I look forward to hearing from you! Cheers, Lawrence [1] http://caia.swin.edu.au/freebsd/etcp09/ [2] http://www.freebsdfoundation.org/projects.shtml#Swinburne [3] http://caia.swin.edu.au/urp/newtcp/ Hi. I'm seeing this right after enabling siftr via sysctl and changing ppl. Sorry, if that was already discussed, known or unrelated (since em is in locking chain). lock order reversal: 1st 0x80e51568 PFil hook read/write mutex (PFil hook read/write mutex) @ /usr/src/sys/net/pfil.c:77 2nd 0x80e52788 tcp (tcp) @ /usr/src/sys/modules/siftr/../../netinet/siftr.c:698 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2a _witness_debugger() at _witness_debugger+0x2e witness_checkorder() at witness_checkorder+0x81e _rw_rlock() at _rw_rlock+0x5f siftr_chkpkt() at siftr_chkpkt+0x374 pfil_run_hooks() at pfil_run_hooks+0xcf ip_input() at ip_input+0x2ae netisr_dispatch_src() at netisr_dispatch_src+0xb8 ether_demux() at ether_demux+0x17d ether_input() at ether_input+0x175 em_rxeof() at em_rxeof+0x193 em_handle_que() at em_handle_que+0x4a taskqueue_run() at taskqueue_run+0x91 taskqueue_thread_loop() at taskqueue_thread_loop+0x3f fork_exit() at fork_exit+0x12a fork_trampoline() at fork_trampoline+0xe --- trap 0, rip = 0, rsp = 0xff8bed30, rbp = 0 --- -- 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: [TESTING]: ClangBSD branch needs testing before the import to HEAD
On 4 June 2010 12:52, Andriy Gapon a...@icyb.net.ua wrote: on 04/06/2010 11:13 b. f. said the following: Mark Linimon wrote: On Tue, Jun 01, 2010 at 12:18:41PM +0200, Alban Hertroys wrote: Compiler bugs in gcc are probably just as hard to find as compiler bugs in clang There are two types of compiler bug: a) bug that produces bad code; b) bug that makes the compiler crash. Let's remember that the entire toolchain is important here, and not just the compiler. Some of the problems can be attributed to our old binutils. For comparison, bitrot that is probably due to older ports not keeping up with compiler changes is at: http://portsmon.freebsd.org/portsconcordanceforbuilderror.py?build_error=gcc4_error How did you obtain gcc4-errors? We're not alone here: some major GNU/Linux distributions, NetBSD, and DragonFlyBSD are using newer versions of binutils and/or gcc, so we can look at their patches and error logs to fix some problems. DragonFlyBSD and NetBSD use newer GCC? This is the first time I hear about that. No doubt about major Linux distributions, though. AFAIK, NetBSD does it for quite a while since they have a different pov on this. http://www.thejemreport.com/content/view/317 -- 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: [head tinderbox] failure on i386/pc98
On 25 May 2010 19:13, FreeBSD Tinderbox tinder...@freebsd.org wrote: TB --- 2010-05-25 13:30:00 - tinderbox 2.6 running on freebsd-current.sentex.ca TB --- 2010-05-25 13:30:00 - starting HEAD tinderbox run for i386/pc98 TB --- 2010-05-25 13:30:00 - cleaning the object tree TB --- 2010-05-25 13:30:24 - cvsupping the source tree TB --- 2010-05-25 13:30:24 - /usr/bin/csup -z -r 3 -g -L 1 -h cvsup.sentex.ca /tinderbox/HEAD/i386/pc98/supfile TB --- 2010-05-25 13:47:17 - building world TB --- 2010-05-25 13:47:17 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-25 13:47:17 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-25 13:47:17 - TARGET=pc98 TB --- 2010-05-25 13:47:17 - TARGET_ARCH=i386 TB --- 2010-05-25 13:47:17 - TZ=UTC TB --- 2010-05-25 13:47:17 - __MAKE_CONF=/dev/null TB --- 2010-05-25 13:47:17 - cd /src TB --- 2010-05-25 13:47:17 - /usr/bin/make -B buildworld World build started on Tue May 25 13:47:17 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 Tue May 25 14:45:12 UTC 2010 TB --- 2010-05-25 14:45:12 - generating LINT kernel config TB --- 2010-05-25 14:45:12 - cd /src/sys/pc98/conf TB --- 2010-05-25 14:45:12 - /usr/bin/make -B LINT TB --- 2010-05-25 14:45:12 - building LINT kernel TB --- 2010-05-25 14:45:12 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-25 14:45:12 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-25 14:45:12 - TARGET=pc98 TB --- 2010-05-25 14:45:12 - TARGET_ARCH=i386 TB --- 2010-05-25 14:45:12 - TZ=UTC TB --- 2010-05-25 14:45:12 - __MAKE_CONF=/dev/null TB --- 2010-05-25 14:45:12 - cd /src TB --- 2010-05-25 14:45:12 - /usr/bin/make -B buildkernel KERNCONF=LINT Kernel build for LINT started on Tue May 25 14:45:12 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 Kernel build for LINT completed on Tue May 25 15:07:19 UTC 2010 TB --- 2010-05-25 15:07:19 - building GENERIC kernel TB --- 2010-05-25 15:07:19 - MAKEOBJDIRPREFIX=/obj TB --- 2010-05-25 15:07:19 - PATH=/usr/bin:/usr/sbin:/bin:/sbin TB --- 2010-05-25 15:07:19 - TARGET=pc98 TB --- 2010-05-25 15:07:19 - TARGET_ARCH=i386 TB --- 2010-05-25 15:07:19 - TZ=UTC TB --- 2010-05-25 15:07:19 - __MAKE_CONF=/dev/null TB --- 2010-05-25 15:07:19 - cd /src TB --- 2010-05-25 15:07:19 - /usr/bin/make -B buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Tue May 25 15:07:19 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 [...] : hack.c cc -shared -nostdlib hack.c -o hack.So rm -f hack.c MAKE=/usr/bin/make sh /src/sys/conf/newvers.sh GENERIC cc -c -O -pipe -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror vers.c linking kernel.debug mca.o(.text+0x1627): In function `mca_init': /src/sys/i386/i386/mca.c:786: undefined reference to `lapic_enable_cmc' *** Error code 1 Stop in /obj/pc98/src/sys/GENERIC. Just wonder why apic is still commented out in pc98's GENERIC. Is there a reason to keep things intact? It was inherited from i386 port in time when it was commented out. -- 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: About 32bit binary on amd64
On 24 May 2010 08:49, Kohji Okuno okuno.ko...@jp.panasonic.com wrote: Hi all, I want to compile 32bit binary on amd64, but I met with the problem. Could you teach me the best solution, please? My environment is FreeBSD 8.1-PRERELEASE #0: Tue May 18 12:01:26 JST 2010. I compiled and executed test.c as below on amd64. [...] % gcc -m32 -B/usr/lib32 test.c % ./a.out mmap: Invalid argument AFAIK, it still doesn't work on FreeBSD. You need something like 32bit chroot environment. There's also about: http://www.freebsd.org/projects/ideas/#p-freebsd-amd64-gcc-m32 -- 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: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE
On 1 May 2010 19:03, Marius Strobl mar...@alchemy.franken.de wrote:
On Fri, Apr 30, 2010 at 06:50:26PM +0400, pluknet wrote:
On 30 April 2010 18:22, Matthew Jacob m...@feral.com wrote:
pluknet wrote:
Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll
put
it in
Err.. I thought that list is dedicated for cam related stuff.
[cc'ing scsi@ for better coverage. Sorry for cross-posting :/ ]
--- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c 2010-03-02
15:38:13.0 +0300
+++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c 2010-04-21
19:31:00.0 +0400
@@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req
CAMLOCK_2_MPTLOCK(mpt);
break;
}
+ case MPI_EVENT_IR_RESYNC_UPDATE:
+ {
+ uint8_t resync = (data0 16) 0xff;
+ mpt_prt(mpt, IR resync update %d completed\n, resync);
+ break;
+ }
case MPI_EVENT_EVENT_CHANGE:
case MPI_EVENT_INTEGRATED_RAID:
case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:
Another way - just hide such event since mptutil displays rebuild
progress.
Could you maybe avoid defining a variable inside a nested scope for
consistency with the majority of the existing cases and in order to
not violate style(9) unnecessarily?
Marius
Index: mpt_cam.c
===
--- mpt_cam.c (revision 207463)
+++ mpt_cam.c (working copy)
@@ -2575,6 +2575,10 @@ mpt_cam_event(struct mpt_softc *mpt, request_t *re
CAMLOCK_2_MPTLOCK(mpt);
break;
}
+ case MPI_EVENT_IR_RESYNC_UPDATE:
+ mpt_prt(mpt, IR resync update %d completed\n,
+ (data0 16) 0xff);
+ break;
case MPI_EVENT_EVENT_CHANGE:
case MPI_EVENT_INTEGRATED_RAID:
case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:
I'm fine with it, resync variable is not necessary there.
Thanks for review.
--
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
mpt(4) MPI_EVENT_IR_RESYNC_UPDATE
Hi,
what do you think of adding this handler (based on old bz@ patch)?
It's quite annoying to see the meaningless messages like
mpt0: Unhandled Event Notify Frame. Event 0x14 (ACK not required).
each 1% change in logical array rebuild progress.
--- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c2010-03-02
15:38:13.0 +0300
+++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c 2010-04-21
19:31:00.0 +0400
@@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req
CAMLOCK_2_MPTLOCK(mpt);
break;
}
+ case MPI_EVENT_IR_RESYNC_UPDATE:
+ {
+ uint8_t resync = (data0 16) 0xff;
+ mpt_prt(mpt, IR resync update %d completed\n, resync);
+ break;
+ }
case MPI_EVENT_EVENT_CHANGE:
case MPI_EVENT_INTEGRATED_RAID:
case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:
Another way - just hide such event since mptutil displays rebuild progress.
--
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: SUJ update
On 30 April 2010 08:37, Jeff Roberson jrober...@jroberson.net wrote: Hello, I fixed a few SUJ bugs. If those of you who reported one of the following bugs could re-test I would greatly appreciate it. 1) panic on gnome start via softdep_cancel_link(). 2) Difficulty setting flags on /. This can only be done from a direct boot into single user but there were problems with tunefs that could lead to the kernel and disk becoming out of sync with filesystem state. 3) Kernel compiles without SOFTUPDATES defined in the config now work. Just finished make universe. Everything is fine (c). Thanks. I have had some reports of a hang waiting on journal space with certain types of activity. I have only had this reported twice and I am not able to reproduce no matter how much load I throw at the machine. If you reproduce this please try to get a coredump or minidump. Thanks, Jeff -- 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: mpt(4) MPI_EVENT_IR_RESYNC_UPDATE
On 30 April 2010 18:22, Matthew Jacob m...@feral.com wrote:
pluknet wrote:
Seems good to me- why not trhow it freebsd-scsi? if nobody says no, I'll put
it in
Err.. I thought that list is dedicated for cam related stuff.
[cc'ing scsi@ for better coverage. Sorry for cross-posting :/ ]
--- RELENG_7_3/src/sys/dev/mpt/mpt_cam.c 2010-03-02
15:38:13.0 +0300
+++ RELENG_7_3.ours/src/sys/dev/mpt/mpt_cam.c 2010-04-21
19:31:00.0 +0400
@@ -2564,6 +2564,12 @@ mpt_cam_event(struct mpt_softc *mpt, req
CAMLOCK_2_MPTLOCK(mpt);
break;
}
+ case MPI_EVENT_IR_RESYNC_UPDATE:
+ {
+ uint8_t resync = (data0 16) 0xff;
+ mpt_prt(mpt, IR resync update %d completed\n, resync);
+ break;
+ }
case MPI_EVENT_EVENT_CHANGE:
case MPI_EVENT_INTEGRATED_RAID:
case MPI_EVENT_SAS_DEVICE_STATUS_CHANGE:
Another way - just hide such event since mptutil displays rebuild
progress.
--
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: HEADS UP: SUJ Going in to head today
On 27 April 2010 10:01, Jeff Roberson jrober...@jroberson.net wrote: On Mon, 26 Apr 2010, pluknet wrote: On 26 April 2010 17:42, dikshie diks...@gmail.com wrote: Hi Jeff, thanks for SUJ. btw, why there is nan% utilization? and what does it mean? -- ** SU+J Recovering /dev/ad0s1g ** Reading 33554432 byte journal from inode 4. ** Building recovery table. ** Resolving unreferenced inode list. ** Processing journal entries. ** 0 journal records in 0 bytes for nan% utilization ** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags. -- That may be due to an empty journal (the only plausible version for me), so jrecs and jblocks are not updated. Yes, this is it exactly. It's a simple bug, I will post a fix in the next few days. Thanks, Jeff While here, could you please look at my another su+j issue email? (to not create a new thread of the same thing). Thanks in advance. http://lists.freebsd.org/pipermail/svn-src-all/2010-April/023303.html -- 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: HEADS UP: SUJ Going in to head today
On 26 April 2010 17:42, dikshie diks...@gmail.com wrote:
Hi Jeff,
thanks for SUJ.
btw, why there is nan% utilization? and what does it mean?
--
** SU+J Recovering /dev/ad0s1g
** Reading 33554432 byte journal from inode 4.
** Building recovery table.
** Resolving unreferenced inode list.
** Processing journal entries.
** 0 journal records in 0 bytes for nan% utilization
** Freed 0 inodes (0 dirs) 0 blocks, and 0 frags.
--
That may be due to an empty journal (the only plausible version for me),
so jrecs and jblocks are not updated.
/* Next ensure that segments are ordered properly. */
seg = TAILQ_FIRST(allsegs);
if (seg == NULL) {
if (debug)
printf(Empty journal\n);
return;
}
--
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: FreeBSD kernel doesn't boot on FUJITSU PRIMERGY RX200 S5 server
2010/4/21 Andrey V. Elsukov bu7c...@yandex.ru: On 21.04.2010 2:44, Maxim Sobolev wrote: Maxim Sobolev wrote: Maybe try adding hint.atkbdc.0.disabled=1 hint.atkbd.0.disabled=1 Actually it helped, thank you very much! The problem was that I have had my hints compiled into the kernel itself. Hi, Maxim. I tried to boot 9.0-CURRENT amd64 snapshot on IBM x3650 M2 and seems have the same problem, i set hints from loader prompt, but this didn't help. Can you explain what you did to boot FreeBSD faster? Hmm.. That's strange to hear. We have in production a number of x3650m2: 7.2-R, 7.3-R (all amd64). All runs flawlessly. I'll try to boot it from head today if that matters. -- 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 7 April 2010 23:49, John Baldwin j...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included from sys/user.h in !_KERNEL only too. -- wbr, pluknet KINFO_PROC_SIZE_md.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
Re: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
On 15 April 2010 17:41, Nathan Whitehorn nwhiteh...@freebsd.org wrote: On 04/15/10 08:13, John Baldwin wrote: On Thursday 15 April 2010 6:06:24 am pluknet wrote: On 7 April 2010 23:49, John Baldwinj...@freebsd.org wrote: On Tuesday 06 April 2010 11:24:21 am Nathan Whitehorn wrote: pluknet wrote: Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). Probably the cleanest thing would be to set KINFO_PROC_SIZE in machine/proc.h instead of where it is now, and then also define a KINFO_PROC32_SIZE or something in the same place. Also, that would be a really nice feature. Yes, I think this sounds like the best approach. Something quick not clean (well, it passes universe) attached. So, don't shoot me, please ;-). It's unclear how to convert those mips o32/n32/o64/n64 though. I had to make definitions out of _KERNEL visibility as far as sys/proc.h is included fromsys/user.h in !_KERNEL only too. Just one suggestion: don't make KINFO_PROC32 #define depenedent on COMPAT_FREEBSD32. It should just be always defined. I think that is the approach Nathan used for the 32-bit ELF machine type. I agree. There's no harm in making it a global definition. You also need a KINFO_PROC32 for ia64, which also implements i386 compatibility. Other than that, the patch looks good to me. -Nathan Thanks for your suggestions. -- wbr, pluknet KINFO_PROC_SIZE_md.2.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
Re: Malloc_init: Bad Malloc type Magic
On 16 April 2010 04:53, Francis Provencher francisp...@gmail.com wrote: Hi All, I have update my Freebsd Box to 8.0 last nigth. When i reboot it, i received this error message. Panic: malloc_init: bad malloc type magic CPUID = 0 I can't anymore boot my box... You most likely faced with this (from src/UPDATING): 1.594 rwatson 428: 20090419: 429:The layout of struct malloc_type, used by modules to register new 430:memory allocation types, has changed. Most modules will need to 431:be rebuilt or panics may be experienced. 432:Bump __FreeBSD_version to 800081. If you have 3th-party modules from FreeBSD 7, it's time to rebuild them. -- 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: Samba problems on 8.0-RC2
On 8 November 2009 17:33, Kostik Belousov kostik...@gmail.com wrote: On Sun, Nov 08, 2009 at 02:55:49PM +0100, Jon Theil Nielsen wrote: Hi After running the latest upgrade for samba33, I cannot start it anymore. The error message is: *Starting smbd. /libexec/ld-elf.so.1: /usr/local/sbin/smbd: invalid PT_PHDR /usr/local/etc/rc.d/samba: WARNING: failed to start smbd* uname -a says: *mflserver2.mydomain.dk 8.0-RC2 FreeBSD 8.0-RC2 #0: Sun Nov 8 02:37:45 CET 2009 r...@mydomain.dk:/usr/obj/usr/src/sys/SERVER2 i386* I'm not sure if this problem is related to the system or to samba itself. I think you have old rtld, i.e. it misses r197931, but new kernel. Kernel maps PIE binaries at non-zero base address, that cannot be properly handled by old rtld. Hi. I faced this problem today on 7.3 kernel 7.2 world. quagga refused to start bgpd with error: /libexec/ld-elf.so.1: /usr/local/sbin/bgpd: invalid PT_PHDR. Issue fixed after cp'ing /libexec/ld-elf.so.1 from 7.3 world. So I think the next entry probably needs to be (belatedly) added to 7'th UPDATING and/or errata as (as far as I know) that brakes newer kernel usually works with older world users expectation. 20100119: PIE support has been improved. Kernel maps PIE binaries at non-zero base address. Users need to rebuild rtld(1) to hook up with a new kernel. -- 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: HEADS UP: COMPAT_IA32 renamed COMPAT_FREEBSD32
Hi, the interesting part for me is how to properly assert now a value of e.g. KINFO_PROC_SIZE varying on err.. different COMPAT_FREEBSD32 arches (say, FreeBSD would have _kern_proc FreeBSD32 compat layer for top/ps/). -- 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: samba failed MD5 Checksum
On 4 April 2010 11:02, gahn ipfr...@yahoo.com wrote: Hi all: I am trying to compile the smaba34 but somehow it failed MD5 Checksum and SHA256 Checksum: # make all === Vulnerability check disabled, database not found === Found saved configuration for samba34-3.4.5_1 === --- === Run 'make config' to (re)configure the port === --- === Extracting for samba34-3.4.5_1 = MD5 Checksum mismatch for samba-3.4.5.tar.gz. = SHA256 Checksum mismatch for samba-3.4.5.tar.gz. === Refetch for 1 more times files: samba-3.4.5.tar.gz samba-3.4.5.tar.gz === Vulnerability check disabled, database not found === Found saved configuration for samba34-3.4.5_1 === --- === Run 'make config' to (re)configure the port === --- = samba-3.4.5.tar.gz doesn't seem to exist in /usr/ports/distfiles/. - actually samba-3.4.5.tar.gz does exist under /usr/ports/distfiles Looks like you have partially fetched distfile. Try to make distclean, then restart again. -- 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: [head tinderbox] failure on amd64/amd64
cc -c -O2 -frename-registers -pipe -fno-strict-aliasing -std=c99 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/src/sys -I/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -fno-builtin -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-sse3 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror -pg -mprofiler-epilogue /src/sys/dev/e1000/if_lem.c -I/src/sys/dev/e1000 /src/sys/dev/e1000/if_lem.c: In function 'lem_ioctl': /src/sys/dev/e1000/if_lem.c:1125: error: 'lem_poll' undeclared (first use in this function) /src/sys/dev/e1000/if_lem.c:1125: error: (Each undeclared identifier is reported only once /src/sys/dev/e1000/if_lem.c:1125: error: for each function it appears in.) *** Error code 1 I guess it should fix error. --- src/sys/dev/e1000/if_lem.c.orig 2010-03-31 18:02:30.0 +0400 +++ src/sys/dev/e1000/if_lem.c 2010-03-31 18:03:29.0 +0400 @@ -269,7 +269,7 @@ #endif /* ~EM_LEGACY_IRQ */ #ifdef DEVICE_POLLING -static poll_handler_t em_poll; +static poll_handler_t lem_poll; #endif /* POLLING */ /* -- 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
