Re: Where do I purchace an unlock code to build a custom kernel?
Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) would throw me a bone if it were wrong. Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. -- Best regards, Derekmailto:tak...@takeda.tk The Internet: where men are men, women are men, and children are FBI agents. ___ 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 Sat, 24 Nov 2012 17:44:30 +1100, Morgan Reed wrote: On Fri, Nov 23, 2012 at 5:16 PM, Morgan Reed morgan.s.r...@gmail.com 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. Rebuilt the kernel with option IPFIREWALL and friends turned on (including IPFILTER_DEFAULT_TO_ACCEPT or whatever it is). Unless you needed to include FIREWALL_FORWARD, you really didn't need to build ipfw into the kernel, it's all loadable by module. No harm, but. Throw ipfw_nat_load=YES and ipdivert_load=YES into /boot/loader.conf so the modules are available for the jails. And with ipfw nat you won't be needing ipdivert. Again, no harm. Run a quick and dirty ipfw script (running out of an 'up' script I wrote into the OpenVPN config); ipfw nat 1 config if tun0 reset same_ports deny_in ipfw add 500 nat 1 ip from any to any via tun0 Works like a charm, just one last thing I'd like to get squared away here though, currently OpenVPN is using a dynamically created tun device, I'd like to have a static /dev/tun0 exist prior to the /etc/rc.d/natd start launching (because as it is I have to restart natd after the openvpn tunnel comes up), not sure what the best way to achieve this is in a jailed environment though. If the address of the tunX interface is fixed in the jail, you can specify it by IP instead of the interface in the nat setup, like: ipfw nat 1 config ip $address same_ports deny_in ipfw add 500 nat 1 ip from any to any via $address Your use of 'reset' in nat config makes me wonder if it's a variable address though? If IP varies you will need to specify the interface. The next trick will be migrating from my spaghetti script into rc launched jails... 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: Where do I purchace an unlock code to build a custom kernel?
Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) would throw me a bone if it were wrong. Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. Understood. That's what I did (i386/GENERIC -- CUSTOM). I _knew_ there would be issue(s) otherwise. Thank you again for the advice. Looks to be working as expected. :) -- Best regards, Derekmailto:tak...@takeda.tk The Internet: where men are men, women are men, and children are FBI agents. ___ 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 Sat, Nov 24, 2012 at 7:26 PM, Ian Smith smi...@nimnet.asn.au wrote: Unless you needed to include FIREWALL_FORWARD, you really didn't need to build ipfw into the kernel, it's all loadable by module. No harm, but. The ipfw_nat module was causing an instant panic at load and I was going to have to rebuild my kernel to debug that anyway, went with the sledgehammer approach and built it in, this box won't be doing anything else so it's no problem. And with ipfw nat you won't be needing ipdivert. Again, no harm. Yeah, I didn't think it should be necessary but something was trying to load it from within the jails and throwing an error, probably the natd startup script, not sure why, I might do some digging if I get bored at some point. If the address of the tunX interface is fixed in the jail, you can specify it by IP instead of the interface in the nat setup, like: ipfw nat 1 config ip $address same_ports deny_in ipfw add 500 nat 1 ip from any to any via $address Your use of 'reset' in nat config makes me wonder if it's a variable address though? If IP varies you will need to specify the interface. Dynamically assigned IP address, I don't control the remote end of the tunnel, IP changes each time the tunnel connects. ___ 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: buildworld with clang breaks because no cc
On 2012-11-23 12:37, Beeblebrox wrote: I am doing a buildworld with clang on amd64 9.1-PRERELEASE #2 r242867. In /etc/src.conf I have WITHOUT_GCC= yes. Compile progresses up to below then breaks: ... lint: cannot exec /usr/obj/asp/src/tmp/usr/bin/cc: No such file or directory Currently, you cannot use WITHOUT_GCC without also setting WITH_CLANG_IS_CC. Some programs, like lint, are still hardcoded to run 'cc' for their processing, so if there is no 'cc' executable during the world stage, your build will fail. ___ 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: buildworld with clang breaks because no cc
On 2012-11-23 13:38, Beeblebrox wrote: Looks like I should have placed these in my /etc/src.conf: WITH_CLANG= yes This is not strictly necessary, WITH_CLANG is already enabled by default. WITH_CLANG_EXTRAS= yes In most cases, you will not need the llvm/clang extras, and they will add some build time. WITH_CLANG_IS_CC= yes If you want to use WITHOUT_GCC, as you mentioned in your first post, you will indeed need this setting. I don't believe I will need anything under /usr/src/tools. How can I disable that in /etc/src.conf? The man page does not have that info. You cannot disable them, some of the tools under there are needed for buildworld. Others are just nice to have for specific jobs, like cleaning up old files, or regression tests. ___ 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 Sat, Nov 24, 2012 at 9:16 PM, Morgan Reed morgan.s.r...@gmail.com wrote: And with ipfw nat you won't be needing ipdivert. Again, no harm. Yeah, I didn't think it should be necessary but something was trying to load it from within the jails and throwing an error, probably the natd startup script, not sure why, I might do some digging if I get bored at some point. *facepalm* or I could just remove natd_enable from rc.conf since I don't need it anymore... ___ 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: buildworld with clang breaks because no cc
On 2012-11-23 14:45, Beeblebrox wrote: I am now stuck with trying to make this work. I am doing buildworld with clang and ccache enabled. If you want to use clang in combination with ccache, you must at least set CCACHE_CPP2 to make it work. If you experience any issues with this setup, always try disabling ccache first, to see if the issues go away. In most cases, disabling ccache fixes the problems. 1. I have to keep re-starting buildworld at different points of break. When re-started the build continues past the last break-point and goes on to break somewhere else. 2. This continues until build gets to === usr.bin/ypwhich (all) and cannot continue past the error. As in your first post, you are most likely doing make -j X buildworld, and this can obscure the actual error(s), which occur long before the ypwhich message. You should save the entire log, and search backwards from the end for the actual error. If you can't find it, post the full log somewhere off-list. 3. I disable ccache in /usr/local/etc/buildflags.conf and re-start the build. Progresses upto: sh /asp/src/tools/install.sh -s -o root -g wheel -m 444 libz.so.6 /usr/obj/asp/src/lib32/usr/lib32 ln -fs libz.so.6 /usr/obj/asp/src/lib32/usr/lib32/libz.so However, examining the contents after build-break of /usr/obj/asp/src/lib32/usr/lib32/ shows libz.so.6 and its linked alias libz.so. I am not able to move any further without help because I cannot figure out where the problem may be. This looks like there is a problem building the 32-bit compat libraries. What are your exact make.conf and src.conf settings? ___ 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 Sat, Nov 24, 2012 at 5:44 PM, Morgan Reed morgan.s.r...@gmail.com wrote: Works like a charm, just one last thing I'd like to get squared away here though, currently OpenVPN is using a dynamically created tun device, I'd like to have a static /dev/tun0 exist prior to the /etc/rc.d/natd start launching (because as it is I have to restart natd after the openvpn tunnel comes up), not sure what the best way to achieve this is in a jailed environment though. Scratch that, I definitely need a holiday... natd_enable removed from rc.conf, appropriate ipfw script being run by openvpn prior to dropping its privs (by way of the up directive) and it just works (tm) ___ 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: buildworld with clang breaks because no cc
On 2012-11-23 15:14, Beeblebrox wrote: Thanks for the suggestion. Build progressed a little further then had other problem: === gnu/lib/libstdc++ (all) building shared library libstdc++.so.6 /usr/obj/asp/src/tmp/usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I am not sure what causes this. Maybe strange CFLAGS in make.conf? Or is this still with ccache? clang: error: linker command failed with exit code 1 (use -v to see invocation) *** [libstdc++.so.6] Error code 1 Stop in /asp/src/gnu/lib/libstdc++. *** [all] Error code 1 Stop in /asp/src/gnu/lib. *** [gnu/lib__L] Error code 1 Why is it building gcc4.2 ?? This is not gcc, it is libstdc++. Currently, there is no way to disable it, as many applications will still use it. After libc++ has matured enough, it can probably be moved to a compat port, but that will certainly not happen in the 9.x series. :) Should I not be using WITH_CLANG_IS_CC= yes ? Bummer... This setting should work just fine. ___ 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: buildworld with clang breaks because no cc
On 2012-11-23 23:03, Beeblebrox wrote:
I went ahead and hacked gnu/lib/Makefile and changed to:
if ${MK_CXX} != no
#SUBDIR+= libstdc++ libsupc++
.endif
Don't do that, it will not work. Parts of the system need GNU libstdc++
and libsupc++.
I then restarted buildworld. Next stop, new error:
clang -m32 -march=k8 -DCOMPAT_32BIT -isystem
/usr/obj/asp/src/lib32/usr/include/ -L/usr/obj/asp/src/lib32/usr/lib32
-B/usr/obj/asp/src/lib32/usr/lib32 -fpic -DPIC -O2 -pipe -DNDEBUG
-std=gnu99 -Qunused-arguments -fstack-protector -Wno-pointer-sign
-Wno-empty-body -Wno-string-plus-int -Wno-tautological-compare
-Wno-unused-value -Wno-parentheses-equality -Wno-unused-function
-Wno-conversion -Wno-switch -Wno-switch-enum -Wno-parentheses -c
/asp/src/lib/libncp/ipx.c -o ipx.So
building shared library libncp.so.4
/usr/obj/asp/src/tmp/usr/bin/ld: warning: creating a DT_TEXTREL in a shared
object.
This is still the same problem as before, some of your object files were
not created correctly. Most likely, there is something wrong with your
make.conf and/or src.conf, please post them.
___
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: buildworld with clang breaks because no cc
Hi Dimitry,
I have been working at this for 6 hours today (I don't want to tell you how
long I was at it yesterday). Thanks for your input / suggestions. I will try
to answer all of them, please let me know if I forget something.
1. Fist the good news: I have just now finished buildworld with setting
WITHOUT_GCC= yes and has WITH_CLANG= yes WITH_CLANG_EXTRAS= yes
WITH_CLANG_IS_CC= yes
2. First I tried to buildworld after disabling WITHOUT_GCC.
* First I had ccache and threads enabled. The build progressed with the
exact same errors as above (many start-stop-restarts) then finally broke.
* I disabled ccache and threads, also removed /usr/obj/src. I restarted the
build, it broke at (as above):
building shared library libstdc++.so.6
3. Then I remembered that I had seen some ccache stuff flash by, despite the
fact I had disabled it. So in /etc/make.conf I disabled the call to
/usr/local/etc/buildflags.conf, cleaned /usr/obj/src and restarted the build
(no ccache, no threads, gcc not disabled). This time it completd buildworld.
What?? Why is buildflags.conf killing things?
4. Then I remembered something else: some of the source code seems to be
hard-coded as /usr/src and not as {path} (my ports, source, ccache,
distfiles are all on zpool/asp - I find it easier). I had observed in the
past that that some source code which fails to compile will compile if I cd
tu /ysr/src and re-run buildworld. The problem was that in
/usr/local/etc/buildflags.conf I had for source:
/asp/src | /asp/src/*{ which I changed to:
/asp/src | /asp/src/* | /usr/src | /usr/src/*{
The build stopped several times, I re-saterted and later disabled threads
and ccache. That is when buildworld finished successfully. Fianl
/etc/src.conf settings:
WITHOUT_GCC= yes
WITH_CLANG= yes
WITH_CLANG_EXTRAS= yes
WITH_CLANG_IS_CC= yes
5. You should save the entire log
I don't know how to do this.
6. buildkernel also does not like ccache!!
Thank you for your input and help...
--
View this message in context:
http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5763756.html
Sent from the freebsd-stable mailing list archive at Nabble.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
SOLVED: Thanks all for your assistance.
SUMMARY:
- Kernel rebuilt with option IPFIREWALL and friends turned on (not
necessary if your ipfw modules work you should just be able to load
them, mine didn't for reasons I don't really have the time or
inclination to track down)
- OpenVPN configurations modified to use a specific tun device
('device tun' directive replaced with 'device tun0')
- OpenVPN configurations modified to run the following script prior
to dropping privs (via the 'up' directive);
/usr/local/etc/openvpn/up.sh
---
ipfw -q flush
pfw nat 1 config if tun0 reset same_ports deny_in
ipfw add 500 nat 1 ip from any to any via tun0
---
This script assumes that option IPFILTER_DEFAULT_TO_ACCEPT or the
equivalent sysctl frob is set, this is most probably *not* what you
want to do in the real world. Modify as needed, and be sure to set
the permissions on the file appropriately as the script will be
executed by root.
A warning though; this is a total hack, the ipfw stuff should be moved
to /etc/ipfw.rules or similar and processed by ipfw at boot but I'm
not sure how it'll react if you try to do this config before the tun
device is created, I expect it'll be unhappy so you'll need to create
a static tun device for openvpn, this is the right way to do things
but I'm being exceedingly lazy. The script above is a filthy hack, and
potentially dangerous.
- Normal requirements for gateway operation also apply here (which
essentially means set gateway_enable=YES in rc.conf on the host and
all router jails).
___
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: buildworld with clang breaks because no cc
I just finished installkernel + installworld - I'm up and running with world that has WITHOUT_GCC= yes!! Just for reference: I ran into this chronic error at installworld: (to paraphrase) can't find btx/btx loader something... I keep a separate section in my notes for chronic recurring errors. So the fix is: cd /usr/src/sys/boot # make cd /usr/src # make installworld Thanks everyone... [SOLVED] -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5763761.html Sent from the freebsd-stable mailing list archive at Nabble.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: buildworld with clang breaks because no cc
On 24/11/2012 13:18, Beeblebrox wrote: 5. You should save the entire log I don't know how to do this. See script(1) Cheers, Matthew -- Dr Matthew J Seaman MA, D.Phil. PGP: http://www.infracaninophile.co.uk/pgpkey signature.asc Description: OpenPGP digital signature
Re: buildworld with clang breaks because no cc
@ Dr. Seaman: Ahh yes, forgot about script. Thanks. @ Chuck So I hear you like spam. Hipster Monty Python talked about spam before it was cool: http://www.youtube.com/watch?v=anwy2MPT5RE Bonus: The Lumberjack Song is an alternative to the spam song: http://www.youtube.com/watch?feature=endscreenNR=1v=xToPCaNxaow -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5763771.html Sent from the freebsd-stable mailing list archive at Nabble.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: Where do I purchace an unlock code to build a custom kernel?
On Sat, 24 Nov 2012, Chris H wrote: Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) would throw me a bone if it were wrong. Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. Understood. That's what I did (i386/GENERIC -- CUSTOM). I _knew_ there would be issue(s) otherwise. Thank you again for the advice. Looks to be working as expected. :) Rather than copy and modify, a custom config can include the GENERIC config and override settings. That generally makes the custom config file smaller and easier to maintain: http://www.wonkity.com/~wblock/docs/html/kernelconfig.html ___ 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: buildworld with clang breaks because no cc
On Sat, Nov 24, 2012 at 01:55:50PM +0100, Dimitry Andric wrote: On 2012-11-23 15:14, Beeblebrox wrote: Thanks for the suggestion. Build progressed a little further then had other problem: === gnu/lib/libstdc++ (all) building shared library libstdc++.so.6 /usr/obj/asp/src/tmp/usr/bin/ld: warning: creating a DT_TEXTREL in a shared object. I am not sure what causes this. Maybe strange CFLAGS in make.conf? Or is this still with ccache? There are two usual causes for this error: 1. missed -fPIC when compiling some .c file 2. wrong assembler which uses non-pic safe relocations. I very much doubt that #2 is the cause. pgpglk5Ytt4ru.pgp Description: PGP signature
Re: How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?
Is this what are you looking for? http://svnweb.freebsd.org/base/releng/8.3/UPDATING?view=log -- View this message in context: http://freebsd.1045724.n5.nabble.com/How-go-back-from-X-Y-RELEASE-pZ-to-X-Y-RELEASE-tp5763474p5763805.html Sent from the freebsd-stable mailing list archive at Nabble.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: How go back from X.Y-RELEASE-pZ to X.Y-RELEASE?
On Sat, Nov 24, 2012 at 09:17:18AM -0800, Jakub Lach wrote: Is this what are you looking for? http://svnweb.freebsd.org/base/releng/8.3/UPDATING?view=log Yes, thanks! -- Peter Olsson -- View this message in context: http://freebsd.1045724.n5.nabble.com/How-go-back-from-X-Y-RELEASE-pZ-to-X-Y-RELEASE-tp5763474p5763805.html Sent from the freebsd-stable mailing list archive at Nabble.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 ___ 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: Where do I purchace an unlock code to build a custom kernel?
On Sat, 24 Nov 2012, Chris H wrote: Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) would throw me a bone if it were wrong. Greetings, and thank you for your reply. Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. Understood. That's what I did (i386/GENERIC -- CUSTOM). I _knew_ there would be issue(s) otherwise. Thank you again for the advice. Looks to be working as expected. :) Rather than copy and modify, a custom config can include the GENERIC config and override settings. That generally makes the custom config file smaller and easier to maintain: http://www.wonkity.com/~wblock/docs/html/kernelconfig.html Excellent advice. In fact I now feel fairly embarrassed, as your suggestion seems so _obvious_. :P Thanks, that will _definitely_ be my course of action, going forward (as will cross-compiling on my 6 core AMD64 for this k7) :) Best wishes. --Chris ___ 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 23-11-2012 1:20, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@freebsd.org 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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@freebsd.org 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? Reason I asked for how to set a bigger buffer was booting a serverboard verbose And there is so much pci stuff dumped that it ran out of space. Plenty of unknown devices. There is no sound on this board. And usually that is the first thing that is asked for on this list, once one start reporting problems. --WjW ___ 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: Where do I purchace an unlock code to build a custom kernel?
I full-heartedly agree that include-statement is good, but still $ wc -l /usr/src/sys/amd64/conf/MINI 174 /usr/src/sys/amd64/conf/MINI And this is just after removing network cards ( (usb)ethernet, (usb)wlan, raid drivers and firewire) for my pretty standard lenovo t510. There is so much in GENERIC today that seems to work just as well as modules. I guess one thread on a mailing list this summer tried to achieve a more modular config, which would make the include statement even more useful. Best regards Andreas On Sat, Nov 24, 2012 at 6:50 PM, Chris H chris#@1command.com wrote: On Sat, 24 Nov 2012, Chris H wrote: Hi Chris, Friday, November 23, 2012, 11:50:16 PM, you wrote: Thank you! Yes, I _did_ know k7 was actually i(x)86, but figured config(8) would throw me a bone if it were wrong. Greetings, and thank you for your reply. Anyway, I'll take your advice. There are some architecture specific settings there, so it is best to actually do this and fail it early (well if you would do buildkernel it would be earlier :) than getting some strange errors. If you were thinking to just copy it to i386 directory, to save you future issues, I would recommend you to redo the config based on GENERIC in i386 directory. Understood. That's what I did (i386/GENERIC -- CUSTOM). I _knew_ there would be issue(s) otherwise. Thank you again for the advice. Looks to be working as expected. :) Rather than copy and modify, a custom config can include the GENERIC config and override settings. That generally makes the custom config file smaller and easier to maintain: http://www.wonkity.com/~wblock/docs/html/kernelconfig.html Excellent advice. In fact I now feel fairly embarrassed, as your suggestion seems so _obvious_. :P Thanks, that will _definitely_ be my course of action, going forward (as will cross-compiling on my 6 core AMD64 for this k7) :) Best wishes. --Chris ___ 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 ___ 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....
I'm surprised it's not tunable via a kenv variable at boottime.. 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 25-11-2012 0:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. That would help, especially if we can get it in the beastie bootmenu options... --WjW ___ 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 8:50 PM, Ian Smith smi...@nimnet.asn.au wrote: On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: On Thu, Nov 22, 2012 at 2:49 PM, Gary Palmer gpal...@freebsd.org 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 adr...@freebsd.org wrote: On 22 November 2012 06:30, Alexander Motin m...@freebsd.org 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. Ian, With the (U.S.) holiday, I just got to this. The verbose boot presents an impressive amount of detail. I have not looked at it for some time and there is a LOT more there than list time I verbose booted. It's well over 24 KB of output.The sysctl presents all of the NID information for all three of my pcm devices and is all that is needed to customize them (as I did). It does a much nicer presentation, though, in a neat table instead of just a list. A great deal of the output repeats prior information, but in a different format that would be very convenient for debugging. All of the NID information and most of the rest really needs to be behind a .debug tunable so it does not always get dumped. Only when you really want it and have a larger buffer so it does not get lost. (I always hav a larger buffer on my workstations and the servers don't have HDA, so it's never been an issue. The reality is that there are a number of things in the verbose output that would be useful for tracking an error report and should be kept, but most of the verbosity looks to be of use in real driver debuging, so should not be part of the default verbose boot output. -- 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 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer -- 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 Fri, 23 Nov 2012 11:33:21 +0100, Lars Engels wrote: Am 23.11.2012 05:50, schrieb Ian Smith: On Thu, 22 Nov 2012 16:20:52 -0800, Kevin Oberman wrote: [..] 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? No, I was creating the dmesg on a vanilla FreeBSD 10-CURRENT kernel and the other one on PC-BSD 9.1-RCsomething. Well that's interesting, excuse my assumption. But as downloaded: -rw-r--r-- 1 smithi smithi 82415 Nov 22 14:08 T61_dmesg.boot.10.works So is the default msgbufsize on 10 different to what mav@ just posted? kern.msgbufsize=65536 # Set size of kernel message buffer And if the PC-BSD 9.1-RCsomething one you refer to is: http://bsd-geek.de/FreeBSD/T61_dmesg.boot.9.works then that's only 37844 bytes and has most of its head missing, in fact starting only a screenful before the hda stuff that's most of the rest. 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: Increasing the DMESG buffer....
Alexander Motin m...@freebsd.org wrote: On 25.11.2012 01:43, Adrian Chadd wrote: I'm surprised it's not tunable via a kenv variable at boottime.. It is tunable. AFAIR that is it: kern.msgbufsize=65536 # Set size of kernel message buffer Yep. That tunable is available in 8.2 (not 8.1), and I think in all 9.x; dunno if it was ever MFC'd to the 7.x branch. I was going to suggest adding a mention in the docs where verbose boot is described, but the only verbose boot mention I found is in Handbook 13.4.1, Kernel Boot Flags, which doesn't seem like a particularly good place to get into tunables. ___ 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
