Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On Monday 22 October 2012 01:03:19 Adrian Chadd wrote: ... Obviously, handling device attach events is an exception from this rule, and up to this date this was never properly addressed... *laugh*. The problem now is figuring out how to do it without modifying all the drivers. The attach is easy - I can likely set it up during the device_attach() pass. I can do that, but it's enforcing networking-ness with the device attach, which will be called for networking and non-networking devices alike. However detach isn't easy - because I'm required to call CURVNET_SET(ifp-if_vnet) and CURVNET_RESTORE() around if_free(), and if_free() is called in the device specific detach() routine, I can't easily set the current VNET context from outside the driver. I _guess_ I could device_attach() to use CURVNET_SET(vnet0) but device_detach() can't do the same - it doesn't know about the networking-ness of the device. I'm open to other suggestions. The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. Marko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: kernel module parallel build?
On Sunday, October 21, 2012 7:11:10 am Andre Oppermann wrote: What's keeping kernel modules from building in parallel with make -j8? They don't for you? They do for me either via 'make buildkernel' or the old method. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On 22 October 2012 03:08, Marko Zec z...@fer.hr wrote: The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet - vnet0 during kldunload events? Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: Loader-kernel interaction
On Friday, October 19, 2012 7:05:05 pm Richard Yao wrote:
Dear Everyone,
I know that the kernel is a BTX client, but I do not understand the
protocol used by loader to pass sysctl settings and loadable modules to
the kernel. Is there documentation on this?
The loader passes it's variables as a set of environment variables.
They are stored in a contiguous block of memory after the last kernel
module. Look at sys/boot/i386/libi386/bootinfo{32,64}.c. Specifically
look at the bi_load*() routines.
--
John Baldwin
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On 10/22/12 7:12 AM, Adrian Chadd wrote: On 22 October 2012 03:08, Marko Zec z...@fer.hr wrote: The only option I can think of now is to update all of the hotunpluggable device_detach() handlers to do CURVNET_SET(ifp-if_vnet) before calling further down into the networking stack, because as you already observed, whatever triggers a device_detach() handler is not aware of the nature of the driver. Right. Well, since most things are in theory hotpluggable these days (or soon will be, with pcie hotplug), I think we need a slightly more generic solution. (how the hell does this work for devices attached at probe time? What vnet context do they have, and why doesn't the kernel panic there?) Because at boot / autoconfiguration time curvnet is implicitly set to vnet0 between SI_SUB_VNET and SI_SUB_VNET_DONE (i.e. before going SMP). Similarly, curvnet is set to vnet0 during kldload events. .. like this. The trouble is going to be handling unplug and kldunload events too. Does curvnet - vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) Thanks, Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On 22 October 2012 10:29, Julian Elischer jul...@freebsd.org wrote: The trouble is going to be handling unplug and kldunload events too. Does curvnet - vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) Well, in an unload event you know the device you're unloading. However, there may be clones and such involved. It's not like a kldunload will kill a specific VAP on an ath(4) interface, it'll kill the whole interface with all vaps. So in net80211 I need to teach the VAP setup/destroy path to use CURVNET_*() correctly. That's a given. I still however need to ensure that CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device attach/detach, as right now the hotplug code doesn't do this. So Marko: * Given that you've fixed the kldload path and bootup path to set CURVNET_SET(vnet0) as a special case, how about we teach the device_attach() path to just do this in general? * How does kldunload work right now if any devices are in a vnet? If I kldunload if_bridge with vnets everywhere, what happens? if_bridge doesn't at all know anything about VIMAGE. How do the cloned interfaces get correctly destroyed? I don't want to have to teach _every network device_ that they need to be vnet aware on attach or detach. * the device probe/attach path should just use vnet0; and * the device detach/destroy path, to things like if_free(), should have those functions just use ifp-if_vnet, rather than assuming CURVNET_SET() was called. I know you wanted to be warned if parts of the stack weren't correctly using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is already lost. :/ Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD in Google Code-In 2012? You can help too!
On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: (cross-posted message; please keep discussion on freebsd-hackers@) Hello, Last year FreeBSD qualified for Google Code-In 2011 event--contest for youngest open-source hackers in 13-17yr age range: http://www.google-melange.com/gci/homepage/google/gci2012 It was successful. We gained one more FreeBSD developer thanks to that (Isabell Long) We're pondering participating in the contest this year as well. For now we only have 25 ideas. We need at least 100. I felt all members of the FreeBSD community should help, so please submit your own Google Code-In 2012 ideas here: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Examples of previously completed tasks: http://wiki.freebsd.org/GoogleCodeIn/2011Tasks Those of you who have Wiki access, please spent 2 more minutes and submit straight to Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I plan to send out next e-mail if there's any progress on this project. Help will be appreciated. Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD in Google Code-In 2012? You can help too!
That wiki site has a distinct lack of help about: * what is required from us; * what the target is (kids, right?) * some examples of good and bad projects. Right now I have absolutely no idea what would constitute a good or bad coding project. :/ adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD in Google Code-In 2012? You can help too!
On 2012-10-22 12:44, Wojciech A. Koszek wrote: On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: (cross-posted message; please keep discussion on freebsd-hackers@) Hello, Last year FreeBSD qualified for Google Code-In 2011 event--contest for youngest open-source hackers in 13-17yr age range: http://www.google-melange.com/gci/homepage/google/gci2012 It was successful. We gained one more FreeBSD developer thanks to that (Isabell Long) We're pondering participating in the contest this year as well. For now we only have 25 ideas. We need at least 100. I felt all members of the FreeBSD community should help, so please submit your own Google Code-In 2012 ideas here: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Examples of previously completed tasks: http://wiki.freebsd.org/GoogleCodeIn/2011Tasks Those of you who have Wiki access, please spent 2 more minutes and submit straight to Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I plan to send out next e-mail if there's any progress on this project. Help will be appreciated. Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. One thing I can think to add if it's not already been done and if its a practical idea for the Google project, would be to update the mount_udf command to support newer versions of UDF. It looks like as of FreeBSD 7 that 1.02 1.50 are supported, I( haven't been able to find any more recent documentation to support whether or not updates have been made since then. I only know that server I have running 9.0, for the purpose of hosting ISO images on the network so they are available to our ESX environment for mounting as a local CDROM/DVD within virtual machines, and also available as files over a network share, can't mount the some of the more recent DVDs in the UDF format, but I am unsure which format they are in, they could be 2.0, 2.5, or 2.6. -- Thanks, Dean E. Weimer http://www.dweimer.net/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
On Monday 22 October 2012 19:41:19 Adrian Chadd wrote: On 22 October 2012 10:29, Julian Elischer jul...@freebsd.org wrote: The trouble is going to be handling unplug and kldunload events too. Does curvnet - vnet0 during kldunload events? I think in unload events we probably need to cycle through all vnets and do individual shutdowns of anything that is set up on that vnet.. (but I'm not reading the code to say that, it's possible to ignore me safely) Well, in an unload event you know the device you're unloading. However, there may be clones and such involved. It's not like a kldunload will kill a specific VAP on an ath(4) interface, it'll kill the whole interface with all vaps. So in net80211 I need to teach the VAP setup/destroy path to use CURVNET_*() correctly. That's a given. I still however need to ensure that CURVNET_SET(vnet0)/CURVNET_RESTORE() is used around the device attach/detach, as right now the hotplug code doesn't do this. So Marko: * Given that you've fixed the kldload path and bootup path to set CURVNET_SET(vnet0) as a special case, how about we teach the device_attach() path to just do this in general? While it's true that the kldunload path (most probably) does CURVNET_SET(vnet0), this is obviously just a kludge which works on pure luck, i.e. only when ifnets to be detached live inside vnet0. * How does kldunload work right now if any devices are in a vnet? It (most probably) doesn't. If I kldunload if_bridge with vnets everywhere, what happens? if_bridge doesn't at all know anything about VIMAGE. How do the cloned interfaces get correctly destroyed? Haven't tried this out recently, really, though bz@ maintained a patch for a while which specifically targetted VNET issues with cloner ifnets, but I don't know the current status of that work... I don't want to have to teach _every network device_ that they need to be vnet aware on attach or detach. * the device probe/attach path should just use vnet0; and Right. * the device detach/destroy path, to things like if_free(), should have those functions just use ifp-if_vnet, rather than assuming CURVNET_SET() was called. How many functions like if_free() are we talking about here? If only a few would need to be extended to do a CURVNET_SET(ifp-if_vnet), that doesn't sound like too big an issue, though I'm not completely convinced that such an approach could guarantee that every driver would survive hotunplugging with vnets. Still, that would be an improvement over what we have right now. I know you wanted to be warned if parts of the stack weren't correctly using CURVNET_SET()/CURVNET_RESTORE(), but I think this battle is already lost. :/ It is absolutely critical that, at minimum, we always completely unwind the VNET stack when exiting the networking code, otherwise we risk to continue running with a fully random implicit curvnet context. As many of the networking subsystems or code paths are still not VNET-friendly, entering any of those on a VIMAGE kernel should lead to panics, not to obscure and silent inter-vnet leakages which may become a nightmare to nail down. OTOH, avoiding excessive recursions on curvnet remains an effort similar to our style(9) - if you don't stick to it to the letter, things will still work, but some code paths may become more difficult to debug when things go wrong... Plus, keep in mind that every CURVNET_SET() consumes a few CPU cycles here and there, and requires a few extra bytes on the stack... Marko ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD in Google Code-In 2012? You can help too!
On Mon, Oct 22, 2012 at 03:08:27PM -0500, dweimer wrote: On 2012-10-22 12:44, Wojciech A. Koszek wrote: On Tue, Oct 16, 2012 at 10:19:57AM +, Wojciech A. Koszek wrote: (cross-posted message; please keep discussion on freebsd-hackers@) Hello, Last year FreeBSD qualified for Google Code-In 2011 event--contest for youngest open-source hackers in 13-17yr age range: http://www.google-melange.com/gci/homepage/google/gci2012 It was successful. We gained one more FreeBSD developer thanks to that (Isabell Long) We're pondering participating in the contest this year as well. For now we only have 25 ideas. We need at least 100. I felt all members of the FreeBSD community should help, so please submit your own Google Code-In 2012 ideas here: http://www.emailmeform.com/builder/form/4aU93Obxo4NYdVAgb1 Examples of previously completed tasks: http://wiki.freebsd.org/GoogleCodeIn/2011Tasks Those of you who have Wiki access, please spent 2 more minutes and submit straight to Wiki: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks I plan to send out next e-mail if there's any progress on this project. Help will be appreciated. Update: It looks pretty bad so far. Page: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks Has 38 tasks so far out of which: ~30 would qualify. Consider this e-mail to be the last call for action. Otherwise we'll have to pull back and concentrate our efforts on GSOC instead. One thing I can think to add if it's not already been done and if its a practical idea for the Google project, would be to update the mount_udf command to support newer versions of UDF. It looks like as of FreeBSD 7 that 1.02 1.50 are supported, I( haven't been able to find any more recent documentation to support whether or not updates have been made since then. I only know that server I have running 9.0, for the purpose of hosting ISO images on the network so they are available to our ESX environment for mounting as a local CDROM/DVD within virtual machines, and also available as files over a network share, can't mount the some of the more recent DVDs in the UDF format, but I am unsure which format they are in, they could be 2.0, 2.5, or 2.6. I think it's too hard for Google Code-In (participants are 13--17), but submit this idea via web form. We can always end up doing copypaste to GSOC section, which I think would be more appropriate. -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: FreeBSD in Google Code-In 2012? You can help too!
On Mon, Oct 22, 2012 at 11:46:21AM -0700, Adrian Chadd wrote: That wiki site has a distinct lack of help about: * what is required from us; * what the target is (kids, right?) * some examples of good and bad projects. Right now I have absolutely no idea what would constitute a good or bad coding project. :/ I updated the Wiki with Sample ideas section: http://wiki.freebsd.org/GoogleCodeIn/2012Tasks -- Wojciech A. Koszek wkos...@freebsd.czest.pl http://FreeBSD.czest.pl/~wkoszek/ ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: VIMAGE crashes on 9.x with hotplug net80211 devices
Hi, I don't mind tackling the net80211 clone detach path. I do mind how the default for hotplug is argh, it doesn't work. :-) So I'd like to come up with something to fix the basic device detach, rather than having to actually add CURVNET_*() calls around each if_free() in each device detach method. Adrian ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS server bottlenecks
Ivan Voras wrote: On 20 October 2012 13:42, Nikolay Denev nde...@gmail.com wrote: Here are the results from testing both patches : http://home.totalterror.net/freebsd/nfstest/results.html Both tests ran for about 14 hours ( a bit too much, but I wanted to compare different zfs recordsize settings ), and were done first after a fresh reboot. The only noticeable difference seems to be much more context switches with Ivan's patch. Thank you very much for your extensive testing! I don't know how to interpret the rise in context switches; as this is kernel code, I'd expect no context switches. I hope someone else can explain. But, you have also shown that my patch doesn't do any better than Rick's even on a fairly large configuration, so I don't think there's value in adding the extra complexity, and Rick knows NFS much better than I do. But there are a few things other than that I'm interested in: like why does your load average spike almost to 20-ties, and how come that with 24 drives in RAID-10 you only push through 600 MBit/s through the 10 GBit/s Ethernet. Have you tested your drive setup locally (AESNI shouldn't be a bottleneck, you should be able to encrypt well into Gbyte/s range) and the network? If you have the time, could you repeat the tests but with a recent Samba server and a CIFS mount on the client side? This is probably not important, but I'm just curious of how would it perform on your machine. Oh, I realized that, if you are testing 9/stable (and not head), that you won't have r227809. Without that, all reads on a given file will be serialized, because the server will acquire an exclusive lock on the vnode. The patch for r227809 in head is at: http://people.freebsd.org/~rmacklem/lkshared.patch This should apply fine to a 9 system (but not 8.n), I think. Good luck with it and have fun, rick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
Re: NFS server bottlenecks
On Oct 23, 2012, at 2:36 AM, Rick Macklem rmack...@uoguelph.ca wrote: Ivan Voras wrote: On 20 October 2012 13:42, Nikolay Denev nde...@gmail.com wrote: Here are the results from testing both patches : http://home.totalterror.net/freebsd/nfstest/results.html Both tests ran for about 14 hours ( a bit too much, but I wanted to compare different zfs recordsize settings ), and were done first after a fresh reboot. The only noticeable difference seems to be much more context switches with Ivan's patch. Thank you very much for your extensive testing! I don't know how to interpret the rise in context switches; as this is kernel code, I'd expect no context switches. I hope someone else can explain. But, you have also shown that my patch doesn't do any better than Rick's even on a fairly large configuration, so I don't think there's value in adding the extra complexity, and Rick knows NFS much better than I do. But there are a few things other than that I'm interested in: like why does your load average spike almost to 20-ties, and how come that with 24 drives in RAID-10 you only push through 600 MBit/s through the 10 GBit/s Ethernet. Have you tested your drive setup locally (AESNI shouldn't be a bottleneck, you should be able to encrypt well into Gbyte/s range) and the network? If you have the time, could you repeat the tests but with a recent Samba server and a CIFS mount on the client side? This is probably not important, but I'm just curious of how would it perform on your machine. Oh, I realized that, if you are testing 9/stable (and not head), that you won't have r227809. Without that, all reads on a given file will be serialized, because the server will acquire an exclusive lock on the vnode. The patch for r227809 in head is at: http://people.freebsd.org/~rmacklem/lkshared.patch This should apply fine to a 9 system (but not 8.n), I think. Good luck with it and have fun, rick ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org Thanks, I've applied the patch by hand because of some differences and I'm now rebuilding. In case they are still needed here are the dd tests with loopback UDP mount : http://home.totalterror.net/freebsd/nfstest/udp-dd.html Over udp writing degrades much worse... ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to freebsd-hackers-unsubscr...@freebsd.org
