Re: Increasing the DMESG buffer....
On Thu, 22 Nov 2012 08:12:17 +0100, Adrian Chadd wrote: On 21 November 2012 20:16, Ian Smith wrote: On Wed, 21 Nov 2012 12:08:42 -0800, Adrian Chadd wrote: > .. because some of us like kernel behaviour to be predictable and > controllable, rather than 'just be dynamic here, what could possibly > go wrong.' > > Just bump the default kernel buffer size up to 64k and leave it > hard-coded like that. Us embedded people can drop that down to > something smaller. > > There. Problem solved, right? Well maybe, but I still tend to take Andriy's point about snd_hda. For example, Lars Engels posted several verbose dmesgs the other day, not to do with sound, one of which was: http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works T61_dmesg.boot.10.works (file 1 of 2) lines 1813-1861/1861 byte 82415/82415 Cutting just the hdaa0, pcm0 and pcm1 stuff results in: hda_pcm.verbose (file 2 of 2) lines 712-760/760 byte 28531/28531 Is there a way to extract this topology information out of the driver without putting it in the verbose output? Adrian Maybe via /dev/sndstat. See hw.snd.verbose in sound(4). An additional level 5 for super verbose information? Ronald. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Some new hardware with 9.1 does not reboot easily
on 21/11/2012 20:11 Andriy Gapon said the following: > on 21/11/2012 20:08 Willem Jan Withagen said the following: >> On 2012-11-21 19:05, Andriy Gapon wrote: >>> on 21/11/2012 19:48 Willem Jan Withagen said the following: > [snip] It seems to to be waiting/working in the ZFS code to get things unmounted. >>> >>> Yeah, oops, this is a known ZFS deadlock in zfs_freebsd_reclaim -> zfs_zget >>> path. >>> I may commit my fix for it to head on the next weekend. >>> You may share this information with the list. >> >> Any change of getting this back into 9.1? >> Preferably before 9.1-RELEASE, but otherwise real soon after that. >> >> I'm the perfect test guinea-pig, it happens every time I reboot. > > I will definitely MFC it to stable/9, just not sure if I would be able to do > it > before New Year. It definitely won't be in 9.1. I'll send you a patch later. > The patch: http://people.freebsd.org/~avg/zfs-vfs.4.diff -- Andriy Gapon ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
USB flash diver Introduce for the NEW shared photos with you
Dear Manager Have a nice day This is Jerry from Shenzhen of China, writing to you to enter into business relationship with you. We are the professional manufacturer with nearly 6 years of experience oversea business in supplying USB Flash Drives, Tablet PC, Keyboard, Mouse, MP3, Digital Photo frame, Laser Pointer, Sound recording pen. We can supply you the competitive price and best quality, Welcome to visit our website: http://pzz510127.cn.alibaba.com Meanwhile, we will offer positive cooperation and sincere service, also look foward to buliding up long cooperation and double-win situation between us, Do the promise as belows: 1: Samples are arranged only about 2-3 days 2: The goods is at the rate of 100% inspected and tested before delivery 3: Any style of LOGO is no problem for us per as your requirement to publicize your company 4: There is thousand kinds of USB Flash Drive for your choice, also you can select any type you like or open new mould for you 5: Our factory is located in Shenzhen, so our quotation is FOB shenzhen. If any interest or need, Please feel free to contact us without hesitating, we will do everything well for you. Your reply will be highly appreciated Thank you very much Jerry Telephone: 86-0755-83268990-802 Mobilephone : 086 18682315895 MSN:jerry200...@hotmail.com Skype:jerry200836 Email :jerry200...@yahoo.cn Company name : T-Jorda Electronics Co.,Ltd Website : http://pzz510127.cn.alibaba.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On 22 November 2012 04:00, Morgan Reed wrote: > Hi All, > > I've a bit of an odd query which I hope somebody may be able to > assist with. > > I'm looking to set up several OpenVPN tunnels on a single machine > (each residing in its own jail) and route data to different > destinations over different tunnels by selectively routing the traffic > via a particular jail. > > I have three jails set up with OpenVPN tunnels terminated in each, > they all work as expected from the "local" machine. > > I can't do a straight forward route over the VPN tunnel as I don't > control the other end of the tunnel, I need to treat it as a > point-to-point connection as a result, hence I need to use NAT. > > I've tested this setup with a single tunnel running off a "real" > machine with natd providing NAT, it works like a charm, however, when > I move the config into a jail I run into issues, natd doesn't seem to > be able to see the incoming traffic, nothing shows up in the logs at > all. > > I'm not even sure if this is actually possible, I'm starting to > suspect that natd can't hook in low enough from the jails to access > the incoming traffic. > > Traffic gets into the jail by way of an epair interface between the > host and the jail, bridged to the ethernet adapter by way of a bridge > device, I can see the traffic attempting to route over the tun > interface in the jail (but obviously it's not being NATted so nothing > comes back) so the traffic is making it in and through the routing > engine, just not via natd. > > Any suggestions here? > > The host is FreeBSD-8.3. > I've not used it myself, but this sound like something VIMAGE may be good for, basically it's a virtual tcp stack per jail, there's some docs at http://wiki.freebsd.org/Image but I seem to remember a more up to date one elsewhere but can't find it at the moment! ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
> I've not used it myself, but this sound like something VIMAGE may be good > for, basically it's a virtual tcp stack per jail, there's some docs at > http://wiki.freebsd.org/Image but I seem to remember a more up to date one > elsewhere but can't find it at the moment! AFAIK, VIMAGE is still experimental feature. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Wed, 21 Nov 2012 23:12:17 -0800, Adrian Chadd wrote: > On 21 November 2012 20:16, Ian Smith wrote: > > On Wed, 21 Nov 2012 12:08:42 -0800, Adrian Chadd wrote: [..] > > T61_dmesg.boot.10.works (file 1 of 2) lines 1813-1861/1861 byte 82415/82415 > > > > Cutting just the hdaa0, pcm0 and pcm1 stuff results in: > > > > hda_pcm.verbose (file 2 of 2) lines 712-760/760 byte 28531/28531 > > Is there a way to extract this topology information out of the driver > without putting it in the verbose output? We should be asking Alexander, cc'd. I only have a snd_ich here, where hw.snd.verbose=3 is as rich as it gets, 105 lines incl. file versions. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Nov 22, 2012, at 2:43 AM, wrote: >> I've not used it myself, but this sound like something VIMAGE may be good >> for, basically it's a virtual tcp stack per jail, there's some docs at >> http://wiki.freebsd.org/Image but I seem to remember a more up to date one >> elsewhere but can't find it at the moment! I have created a boot script for managing vimages (downloadable as a FreeBSD package) and made a little write-up on how to use it... http://druidbsd.sf.net/vimage.shtml Note that I use netgraph for bridging (not if_bridge+epair method which seems to be popular in some other setups -- we've benchmarked netgraph and it scales well). Not to mention that "ngctl dot | dot -Tsvg -o network.svg" can produce nice pretty graphs of your vimage structure when using my setup. > AFAIK, VIMAGE is still experimental feature. Works great, tho, seriously! We're multiplexing hardware 20:1 and could probably push it further (but have conservatively kept things at about 2-3x the number of logical CPUs for number-of-vimages (tho, we have benchmarked up to 65530 nodes on a single bridged network connection before netgraph would refuse to make another (impressive -- but not nearly as impressive as the ~90 minutes it took ifconfig to list all the interfaces lol?). -- Devin _ The information contained in this message is proprietary and/or confidential. If you are not the intended recipient, please: (i) delete the message and all copies; (ii) do not disclose, distribute or use the message in any manner; and (iii) notify the sender immediately. In addition, please be aware that any message addressed to our domain is subject to archiving and review by persons other than the intended recipient. Thank you. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Thu, Nov 22, 2012 at 9:38 PM, Simon Dick wrote: > I've not used it myself, but this sound like something VIMAGE may be good > for, basically it's a virtual tcp stack per jail, there's some docs at > http://wiki.freebsd.org/Image but I seem to remember a more up to date one > elsewhere but can't find it at the moment! These are all VIMAGE jails :) I originally tried to do this without VIMAGE but OpenVPN won't work properly in that environment as if it updated the kernel routing table (which ISTR it couldn't, makes sense given the nature of jail) it would have changed it on the host and all jail images. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Fwd: natd in a jail
Hmm, list was missing from reply-to on this one. -- Forwarded message -- From: Morgan Reed Date: Thu, Nov 22, 2012 at 10:36 PM Subject: Re: natd in a jail To: Dewayne Geraghty On Thu, Nov 22, 2012 at 9:33 PM, Dewayne Geraghty wrote: > We run a lot of jails with kernel nat and ipfw (& ipsec but that's not what > you need here). Some of the hosts haven't migrated from natd to kernel nat, > so we're probably similar to your setup. Sounds very similar, just substituting OpenVPN for IPSec. > 90% of our jails have an 192.168/16 that nat via an external interface with > a routable address, and an internal non-routeable address (ie non-RFC1918); > which is probably what you're doing for your VPN stuff. > > Our openvpn's all use tun, I would suggest that your natd isn't doing > exactly like you'd wish - on a good day it can be tricky to get right and > tcpdump is your friend, which should be monitored in both your host > environment and within the jail. You'll need to enable allow.raw_sockets > and you'll probably want to enable bpf to be available in your jail, if you > haven't already done so. BPF is enabled for the jails, and the traffic is getting to where it needs to (but not via natd). I'll try enabling raw_sockets in the jails, it is entirely conceivable that natd requires that functionality. Thanks for your assistance, I'll see how I go and report back. Best Regards, Morgan Reed -- "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -- Benjamin Franklin, 1759 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Thu, Nov 22, 2012 at 10:32 PM, Teske, Devin wrote: > I have created a boot script for managing vimages (downloadable as a FreeBSD > package) and made a little write-up on how to use it... > http://druidbsd.sf.net/vimage.shtml As noted elsewhere, these are VIMAGE jails, but I'm managing them manually with a spaghetti script at the moment (just proof-of-concept at this point), I'll have a look at the script, might make my life easier. > Note that I use netgraph for bridging (not if_bridge+epair method which seems > to be popular in some other setups -- we've benchmarked netgraph and it > scales well). Not to mention that "ngctl dot | dot -Tsvg -o network.svg" can > produce nice pretty graphs of your vimage structure when using my setup. Hmmm, I've not done anything with netgraph before, I'll have a look into it, if it is an issue of the appropriate interfaces not being exposed to natd from the epair/bridge setup that might be an alternate solution, not hugely concerned about scale, it'll pretty much only be my traffic that gets routed this way, but I am interested in making it as efficient as possible (no sense adding additional latency unnecessarily when one already has the tunnel latency to deal with). Thanks, Morgan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On 11/22/2012 6:00 AM, Morgan Reed wrote: Hi All, Hi, [snipped content] Any suggestions here? A quick one. Could you make a try using "ipfw nat" instead of natd? I am not sure about divert socket and natd per jail, but NATing using ipfw and libalias(which natd uses as well) works. HTH, Nikos ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On 22.11.2012 12:53, Ian Smith wrote: On Wed, 21 Nov 2012 23:12:17 -0800, Adrian Chadd wrote: > On 21 November 2012 20:16, Ian Smith wrote: > > On Wed, 21 Nov 2012 12:08:42 -0800, Adrian Chadd wrote: [..] > > T61_dmesg.boot.10.works (file 1 of 2) lines 1813-1861/1861 byte 82415/82415 > > > > Cutting just the hdaa0, pcm0 and pcm1 stuff results in: > > > > hda_pcm.verbose (file 2 of 2) lines 712-760/760 byte 28531/28531 > > Is there a way to extract this topology information out of the driver > without putting it in the verbose output? We should be asking Alexander, cc'd. I only have a snd_ich here, where hw.snd.verbose=3 is as rich as it gets, 105 lines incl. file versions. Neither ICH, nor any other driver I know have amount of information comparable to what HDA hardware provides. So the analogy is not good. Respecting that most CODECs have no published datasheets, that information is the only input for debugging. snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver debugging. It also enables a lot of debugging in sound(4), that can be too verbose for HDA debugging. I will recheck again how can it be reorganized, but I think that the real problem is not in HDA. We need some way to structure and filter the output. -- Alexander Motin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On 22 November 2012 06:30, Alexander Motin wrote: > Neither ICH, nor any other driver I know have amount of information > comparable to what HDA hardware provides. So the analogy is not good. > Respecting that most CODECs have no published datasheets, that information > is the only input for debugging. > > snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver > debugging. It also enables a lot of debugging in sound(4), that can be too > verbose for HDA debugging. > > I will recheck again how can it be reorganized, but I think that the real > problem is not in HDA. We need some way to structure and filter the output. I honestly would like to just see it spat out using a userland tool, rather than having the kernel print that level of topology data out. It's highly unlikely that a topology problem is going to cause a system to not boot, right? So the kernel itself doesn't need to be able to spit that data out. adrian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd wrote: > On 22 November 2012 06:30, Alexander Motin wrote: > >> Neither ICH, nor any other driver I know have amount of information >> comparable to what HDA hardware provides. So the analogy is not good. >> Respecting that most CODECs have no published datasheets, that information >> is the only input for debugging. >> >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver >> debugging. It also enables a lot of debugging in sound(4), that can be too >> verbose for HDA debugging. >> >> I will recheck again how can it be reorganized, but I think that the real >> problem is not in HDA. We need some way to structure and filter the output. > > I honestly would like to just see it spat out using a userland tool, > rather than having the kernel print that level of topology data out. > > It's highly unlikely that a topology problem is going to cause a > system to not boot, right? So the kernel itself doesn't need to be > able to spit that data out. Maybe I'm missing something, but the data needed to adjust HDAC is available from 'sysctl dev.hdaa'. I have not looked at the verbose output in quite a while, but I think it is mstly or entirely hte information in that and 'sysctl dev.hdac'. I never needed to look elsewhere to get mine set up properly. Also, isn't the entire verbose boot captured in /var/run/dmesg? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote: > On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd wrote: > > On 22 November 2012 06:30, Alexander Motin wrote: > > > >> Neither ICH, nor any other driver I know have amount of information > >> comparable to what HDA hardware provides. So the analogy is not good. > >> Respecting that most CODECs have no published datasheets, that information > >> is the only input for debugging. > >> > >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver > >> debugging. It also enables a lot of debugging in sound(4), that can be too > >> verbose for HDA debugging. > >> > >> I will recheck again how can it be reorganized, but I think that the real > >> problem is not in HDA. We need some way to structure and filter the output. > > > > I honestly would like to just see it spat out using a userland tool, > > rather than having the kernel print that level of topology data out. > > > > It's highly unlikely that a topology problem is going to cause a > > system to not boot, right? So the kernel itself doesn't need to be > > able to spit that data out. > > Maybe I'm missing something, but the data needed to adjust HDAC is > available from 'sysctl dev.hdaa'. I have not looked at the verbose > output in quite a while, but I think it is mstly or entirely hte > information in that and 'sysctl dev.hdac'. I never needed to look > elsewhere to get mine set up properly. > > Also, isn't the entire verbose boot captured in /var/run/dmesg? Only if the message buffer hasn't overflowed before the utility runs to populate the file Gary ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer wrote: > On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote: >> On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd wrote: >> > On 22 November 2012 06:30, Alexander Motin wrote: >> > >> >> Neither ICH, nor any other driver I know have amount of information >> >> comparable to what HDA hardware provides. So the analogy is not good. >> >> Respecting that most CODECs have no published datasheets, that information >> >> is the only input for debugging. >> >> >> >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper driver >> >> debugging. It also enables a lot of debugging in sound(4), that can be too >> >> verbose for HDA debugging. >> >> >> >> I will recheck again how can it be reorganized, but I think that the real >> >> problem is not in HDA. We need some way to structure and filter the >> >> output. >> > >> > I honestly would like to just see it spat out using a userland tool, >> > rather than having the kernel print that level of topology data out. >> > >> > It's highly unlikely that a topology problem is going to cause a >> > system to not boot, right? So the kernel itself doesn't need to be >> > able to spit that data out. >> >> Maybe I'm missing something, but the data needed to adjust HDAC is >> available from 'sysctl dev.hdaa'. I have not looked at the verbose >> output in quite a while, but I think it is mstly or entirely hte >> information in that and 'sysctl dev.hdac'. I never needed to look >> elsewhere to get mine set up properly. >> >> Also, isn't the entire verbose boot captured in /var/run/dmesg? > > Only if the message buffer hasn't overflowed before the utility runs to > populate the file Ouch! I did miss hte obvious. Thanks for pointing this out. So we need to either expand the default buffer (not something I would want to do) or trim the verbosity of the verbose boot. Am I also missing an obvious reason most of the HDA output could not be eliminated since it is available y sysctl? -- R. Kevin Oberman, Network Engineer E-mail: kob6...@gmail.com ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Ask freebsd 9 to stabil
Hi, On Fri, 23 Nov 2012 08:27:16 +0700 Denny Johannurdin wrote: > dear admin > > how to make freebsd 9.1 prerelease in to stable you just update the system. Erich ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Increasing the DMESG buffer....
On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: > On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer wrote: > > On Thu, Nov 22, 2012 at 02:14:59PM -0800, Kevin Oberman wrote: > >> On Thu, Nov 22, 2012 at 2:05 PM, Adrian Chadd wrote: > >> > On 22 November 2012 06:30, Alexander Motin wrote: > >> > > >> >> Neither ICH, nor any other driver I know have amount of information > >> >> comparable to what HDA hardware provides. So the analogy is not good. > >> >> Respecting that most CODECs have no published datasheets, that > >> >> information > >> >> is the only input for debugging. > >> >> > >> >> snd_hda also uses hw.snd.verbose=3. But it is used for even deeper > >> >> driver > >> >> debugging. It also enables a lot of debugging in sound(4), that can be > >> >> too > >> >> verbose for HDA debugging. > >> >> > >> >> I will recheck again how can it be reorganized, but I think that the > >> >> real > >> >> problem is not in HDA. We need some way to structure and filter the > >> >> output. > >> > > >> > I honestly would like to just see it spat out using a userland tool, > >> > rather than having the kernel print that level of topology data out. > >> > > >> > It's highly unlikely that a topology problem is going to cause a > >> > system to not boot, right? So the kernel itself doesn't need to be > >> > able to spit that data out. > >> > >> Maybe I'm missing something, but the data needed to adjust HDAC is > >> available from 'sysctl dev.hdaa'. I have not looked at the verbose > >> output in quite a while, but I think it is mstly or entirely hte > >> information in that and 'sysctl dev.hdac'. I never needed to look > >> elsewhere to get mine set up properly. Kevin, could you check http://bsd-geek.de/FreeBSD/T61_dmesg.boot.10.works - the ~85k example I used - against what the sysctl presents on yours? With the caveat that I don't have a snd_hda, I suspect the initial information from hdacc0 and hdaa0 up to before "DUMPING HDA NODES" is likely useful in verbose boot, assuming all of the nid info is available by sysctl? Also the pcm0 and pcm1 data might be limited to that without "DUMPING PCM Playback/Record Channels", "DUMPING Playback/Record Paths" and "DUMPING Volume Controls", leaving in the mixer info as traditional - again assuming that sysctl access covers it? Clearly basic discovery of the particular wiring, routing etc should remain in verbose dmesg. > >> Also, isn't the entire verbose boot captured in /var/run/dmesg? > > > > Only if the message buffer hasn't overflowed before the utility runs to > > populate the file > > Ouch! I did miss hte obvious. Thanks for pointing this out. I've noticed quite a few truncated verbose dmesgs posted over the last couple of years, sometimes frustratingly starting after important stuff like the CPU info or ACPI tables etc .. Lars presumably had increased his buffer size to capture 85k, which would be well less than Adrian's suggested 64k with more minimal hda + pcm logging. Perhaps a debug.snd. or something tunable could reenable the higher verbosity if/when needed? > So we need to either expand the default buffer (not something I would > want to do) or trim the verbosity of the verbose boot. > > Am I also missing an obvious reason most of the HDA output could not > be eliminated since it is available y sysctl? It would be useful to know just which of it is available that way. cheers, Ian ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Thu, Nov 22, 2012 at 10:36 PM, Morgan Reed wrote: > BPF is enabled for the jails, and the traffic is getting to where it > needs to (but not via natd). I'll try enabling raw_sockets in the > jails, it is entirely conceivable that natd requires that > functionality. So it turns out I'd not bought bpf into the jails, however even with that and raw_sockets enabled I'm still having no joy with natd. I've been looking at ipfw a bit today but I've run into an issue, loading ipfw_nat causes my kernel to instantly panic, I need to recompile with KDB and DDB turned on so I can actually catch the trace though... Might look at netgraph before going too far down that path. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: natd in a jail
On Fri, Nov 23, 2012 at 5:16 PM, Morgan Reed wrote: > So it turns out I'd not bought bpf into the jails, however even with > that and raw_sockets enabled I'm still having no joy with natd. > > I've been looking at ipfw a bit today but I've run into an issue, > loading ipfw_nat causes my kernel to instantly panic, I need to > recompile with KDB and DDB turned on so I can actually catch the trace > though... Might look at netgraph before going too far down that path. Scratch that, netgtaph isn't in the GENERIC kernel, so I'll have to rebuild anyway. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
