Re: Increasing the DMESG buffer....
on 25/11/2012 02:08 Willem Jan Withagen said the following: > 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... Eh? I thought I already told about the tunable? -- 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"
Re: Where do I purchace an unlock code to build a custom kernel?
Unless somebody precisely does not want to automatically include new changes brought in by GENERIC (e.g. me). I have crafted current kernel config about 8-CURRENT, and it's still more or less the same on 9-STABLE now. >From time to time it can bite, because of some new dependency, but really rarely. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Where-do-I-purchace-an-unlock-code-to-build-a-custom-kernel-tp5763722p5763953.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: Increasing the DMESG buffer....
On 25 November 2012 10:10, wrote: > Alexander Motin 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. > The tunable was merged to stable/8 in March 2011 and first appeared in 8.3. It was never merged to stable/7. IIRC it should be quite easy to adopt those patches to stable/7. -- wbr, pluknet ___ 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 Sun, Nov 25, 2012 at 05:20:52PM +1100, Ian Smith wrote: > 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. IIRC I just uploaded /var/run/dmesg.boot pgpH27zmOFnuy.pgp Description: PGP signature
Re: Increasing the DMESG buffer....
On Sun, Nov 25, 2012 at 02:00:30PM +0300, Sergey Kandaurov wrote: > On 25 November 2012 10:10, wrote: > > Alexander Motin 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. > > > > The tunable was merged to stable/8 in March 2011 and > first appeared in 8.3. It was never merged to stable/7. > IIRC it should be quite easy to adopt those patches to stable/7. > stable/7 will be out of support in 3 months. If someone is still using it now is the time to upgrade. http://www.freebsd.org/security/security.html#sup -- Mateusz Guzik ___ 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 have been using WITH_CLANG_IS_CC=true WITHOUT_GCC=true on stable almost since switching to clang build system without any build problems whatsoever. -- View this message in context: http://freebsd.1045724.n5.nabble.com/buildworld-with-clang-breaks-because-no-cc-tp5763472p5764013.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"
/var/account/acct gorws indefinitely: Does /etc/peridoic/daily/310.accounting work properly?
Hello, Freebsd-stable. I have accounting_enable="YES" in /etc/rc.conf and: daily_accounting_enable="YES" daily_accounting_compress="YES" daily_accounting_flags=-m daily_accounting_save=365 in /etc/periodic.conf It packs daily logs, but it looks like main log (/var/account/acct) is not tuncated at all. It is 30M now and every day I got monotonically increasing numbers in daily mail. Is it Ok, and it is as it should be? I've thought, log rotation should restart log every day and I should get _Daily_ resource usage by user in daily mail... If it is Ok, is it possible to switch behavior to expected by me without code editing? -- // Black Lion AKA Lev Serebryakov ___ 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"
hastctl hang
Hello, I'm trying to integrate HAST to NAS4Free (FreeBSD 9.1-RC3). Now I have created version 9.1.0.1.531. http://sourceforge.net/projects/nas4free/files/NAS4Free-9.1.0.1/9.1.0.1.531/ Basic CARP + HAST + iSCSI target setup can be done, but very frequently I get hastctl hang when called: /sbin/hastctl status /sbin/hastctl dump Is it better for this method not to call from a script? or somthing wrong to use it? Also, I don't know how to detect an error of writing to local device from hastd. Does anyone know about it? Thanks, Daisuke Aoyama -- the procstat shows like this: [root@nas4free-nodeb /tmp]# procstat -ka|grep hast 11668 100069 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep kern_wait sys_wait4 amd64_syscall Xfast_syscall 17981 100406 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 17981 100559 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit recvit sys_recvfrom amd64_syscall Xfast_syscall 17981 100560 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit recvit sys_recvfrom amd64_syscall Xfast_syscall 17981 100561 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 17984 100078 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 17984 100562 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit recvit sys_recvfrom amd64_syscall Xfast_syscall 17984 100563 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit recvit sys_recvfrom amd64_syscall Xfast_syscall 17984 100564 hastd-mi_switch sleepq_catch_signals sleepq_wait_sig _sleep do_wait __umtx_op_wait_uint_private amd64_syscall Xfast_syscall 18218 100145 hastctl -mi_switch sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit recvit sys_recvfrom amd64_syscall Xfast_syscall [root@nas4free-nodeb /tmp]# procstat -ta|grep hast 11668 100069 hastd- 0 120 sleep wait 17979 100557 hastd- 2 120 sleep g_waitid 17981 100406 hastd- 2 120 sleep uwait 17981 100559 hastd- 0 120 sleep sbwait 17981 100560 hastd- 0 120 sleep sbwait 17981 100561 hastd- 1 120 sleep uwait 17984 100078 hastd- 2 121 sleep uwait 17984 100562 hastd- 3 120 sleep sbwait 17984 100563 hastd- 2 120 sleep sbwait 17984 100564 hastd- 1 121 sleep uwait 18218 100145 hastctl - 2 152 sleep sbwait -- the procstat shows like this: ___ 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: Help review the FAQ
Please include some SSD recommended practice. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764053.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: Help review the FAQ
Why is my kernel so big? "As long as you make sure you follow the steps above, you can build your kernel normally, and you should notice a fairly large size decrease; most kernels tend to be around 1.5 MB to 2 MB." Not really, stripped amd64 kernel is about 9 MB currently... -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764056.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: Help review the FAQ
Why does Opera take so long to start? "The usual answer is that DNS on your system is misconfigured. Opera perform DNS checks when starting up. The browser will not appear on your desktop until the program either gets a response or determines that the system has no network connection." Needs rechecking, I doubt it's still applicable. -- View this message in context: http://freebsd.1045724.n5.nabble.com/Help-review-the-FAQ-tp5762326p5764058.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 Sun, 2012-11-25 at 00:29 +0100, Andreas Nilsson wrote: > [big discussion snipped, including advice to include GENERIC] > > 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 > I think including GENERIC and then trying to customize by disabling what you don't need is horrible advice, and results in just as big and unmaintainable a mess as writing a custom config file from scratch. Either way you do it, you are absolutely required on each OS release to carefully comb through every line of the new GENERIC and compare it to your customizations to make sure you're still turning on and off the right things to get the kernel you want. Where's the benefits? The problem, as I see it, is that GENERIC is not intended to be a baseline config to which various little extras can be added and maybe one or two things might be trimmed away. It's an ever-changing vision of a config that can be almost everything that almost everyone needs. The ever-changingness of that vision is the big problem. Things that had to be in GENERIC 10 years ago are all but meaningless now (NDIS drivers, anyone? device EISA?). It would be nice if kernel configs were truly modularized and designed to be used in a mix-ins sort of way. There should be an I386-BASE and AMD64-BASE and so on that contains just things that are truly required to get that hardware working. There should be useful mix-ins like FIREWALL and ROUTER and DESKTOP. I should be able to write a config file that looks like ident MYBEAST include AMD64-BASE include DESKTOP include DISKLESS-NFSROOT device frannistan # The cheap-o multi-io card I bought device uftdi # My favorite usb->serial adapters -- 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?
That's good idea, albeit you are missing two points: - GENERIC is expected too be able to boot almost all hardware (is this correct approach?) - almost no one really needs custom stripped kernel, most people (e.g. me) do it for fun. There is a reason only GENERIC is supported in OpenBSD, mind. Those who want custom kernel one way or another should just write full config themselves. $ wc -l /usr/src/sys/amd64/conf/STRIPPED 83 /usr/src/sys/amd64/conf/STRIPPED -- View this message in context: http://freebsd.1045724.n5.nabble.com/Where-do-I-purchace-an-unlock-code-to-build-a-custom-kernel-tp5763722p5764066.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 Sun, 2012-11-25 at 11:19 -0800, Jakub Lach wrote: > That's good idea, albeit you are missing two points: > > - GENERIC is expected too be able to boot almost all hardware (is this > correct approach?) > > - almost no one really needs custom stripped kernel, most people > (e.g. me) do it for fun. There is a reason only GENERIC is supported > in OpenBSD, mind. Those who want custom kernel one way or another > should just write full config themselves. > > $ wc -l /usr/src/sys/amd64/conf/STRIPPED > 83 /usr/src/sys/amd64/conf/STRIPPED On x86 platforms for most users, I'd agree that customized kernels are more geekware than necessity. For business use (when you're creating a system to sell to others, whether it's small/embedded or a large dedicated purpose server) the customizations make more sense. On the other hardware (arm, mips, powerpc, etc) I think the modular approach makes more sense. There are certain things that are required for every arm kernel. There are other things that change based on major architecture (armv4 vs. armv6 for example; the same sorts of distinctions as i386 vs amd64). There are also things that are very specific to the chip or system-on-a-chip the kernel is for. -- 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: Help review the FAQ
On 25 November 2012 13:28, Jakub Lach wrote: > Why is my kernel so big? > > "As long as you make sure you follow the steps above, you can build your > kernel normally, and you should notice a fairly large size decrease; most > kernels tend to be around 1.5 MB to 2 MB." > > Not really, stripped amd64 kernel is about 9 MB currently... Is this the size of GENERIC on release media? -- Eitan Adler ___ 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: hastctl hang
Sorry, the message went privately to Daisuke, which was not my intention. -- Forwarded message -- From: Mikolaj Golub Date: Mon, Nov 26, 2012 at 9:38 AM Subject: Re: hastctl hang To: Daisuke Aoyama On Mon, Nov 26, 2012 at 01:17:46AM +0900, Daisuke Aoyama wrote: > Hello, > > I'm trying to integrate HAST to NAS4Free (FreeBSD 9.1-RC3). > Now I have created version 9.1.0.1.531. > http://sourceforge.net/projects/nas4free/files/NAS4Free-9.1.0.1/9.1.0.1.531/ > > Basic CARP + HAST + iSCSI target setup can be done, but very frequently I > get hastctl hang when called: > > /sbin/hastctl status > /sbin/hastctl dump > > Is it better for this method not to call from a script? > or somthing wrong to use it? Normally it is ok to use hastctl for scripting. Do you have it hang forever of just for a few seconds? Usually hanged hastctl means that hastd master process is waiting for its worker (either its response or exit). Could you provide logs from both master ans secondary? Also you might want to run hastd with -d to make it more verbose. > Also, I don't know how to detect an error of writing to local device from > hastd. > Does anyone know about it? Currently only by monitoring logs. It looks like a good idea to add error counters to hastctl statistics output... > Thanks, > Daisuke Aoyama > > -- the procstat shows like this: > [root@nas4free-nodeb /tmp]# procstat -ka|grep hast > 11668 100069 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep kern_wait sys_wait4 > amd64_syscall Xfast_syscall > 17981 100406 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep do_wait > __umtx_op_wait_uint_private amd64_syscall Xfast_syscall > 17981 100559 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit > recvit sys_recvfrom amd64_syscall Xfast_syscall > 17981 100560 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit > recvit sys_recvfrom amd64_syscall Xfast_syscall > 17981 100561 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep do_wait > __umtx_op_wait_uint_private amd64_syscall Xfast_syscall > 17984 100078 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep do_wait > __umtx_op_wait_uint_private amd64_syscall Xfast_syscall > 17984 100562 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit > recvit sys_recvfrom amd64_syscall Xfast_syscall > 17984 100563 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit > recvit sys_recvfrom amd64_syscall Xfast_syscall > 17984 100564 hastd-mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep do_wait > __umtx_op_wait_uint_private amd64_syscall Xfast_syscall > 18218 100145 hastctl -mi_switch > sleepq_catch_signals sleepq_wait_sig _sleep soreceive_generic kern_recvit > recvit sys_recvfrom amd64_syscall Xfast_syscall > > [root@nas4free-nodeb /tmp]# procstat -ta|grep hast > 11668 100069 hastd- 0 120 sleep wait > 17979 100557 hastd- 2 120 sleep g_waitid Strange, I don't see 17979 process in procstat -k output. Again, the logs might be helpful here. > 17981 100406 hastd- 2 120 sleep uwait > 17981 100559 hastd- 0 120 sleep sbwait > 17981 100560 hastd- 0 120 sleep sbwait > 17981 100561 hastd- 1 120 sleep uwait > 17984 100078 hastd- 2 121 sleep uwait > 17984 100562 hastd- 3 120 sleep sbwait > 17984 100563 hastd- 2 120 sleep sbwait > 17984 100564 hastd- 1 121 sleep uwait > 18218 100145 hastctl - 2 152 sleep sbwait > -- the procstat shows like this: > > > ___ > 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" -- Mikolaj Golub ___ 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"
