Re: rc(8) script -- waiting for the network to become usable
On Sun, Apr 18, 2010 at 02:37:27PM -0700, Jeremy Chadwick wrote: I'd like to discuss the possibility of introduction of a new script into /etc/rc.d base system a script, which when enabled, would provide a way to wait until the IP networking layer (using ping(8)) is up and usable before continuing with daemon startup. Let's discuss. :-) HISTORY = The situation which brought this debacle to my attention: I found that on reboot of some of our systems, ntpdate (used to sync the clock initially before ntpd would be started) wouldn't work. The daemon would report that it couldn't resolve any of the FQDNs within ntp.conf, and would therefore act as a no-op before continuing on. By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. In preference, we should work on the failing daemons or hassle up-stream daemon authors so that the daemons in question either (a) retry until they *do* get the information they're after or (b) fail properly, so that they can be restarted by an external process monitoring framework like sysutils/daemontools or launchd. The reasoning is simple: network outage is something that can happen even after startup, and when network connectivity returns, the routing and addresses that are visible won't necessarily be the same. Consider laptops that suspend, as a particular example. Or mobile devices that switch from wi-fi to cellular networking to no connectivity on a regular basis. The get it right at boot time model is important and traditional, but (I think) a fragile and diminishing fraction of use cases. Our rc-ng framework favours solution (a). I'm more a fan of approach (b), myself: I use daemontools for many services, and I like the way that launchd works on my Mac laptops. I think that rc is being overloaded yet again(*), and a launchDaemon kind of solution should be followed, maybe even as a replacement for inetd? /blah (*): in the begining rc would do everything, but life was simple - no internet, then it got complicated, too many daemons, so inetd was invented, things were back in control, for a while. Then sysv invented init.d/init levels, then rc-ng came along, though it solves many problems, 1) the order of things, 2) easy to configure services, it's getting complicated to get 1 'correctly'. blah/ danny ___ 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: net/mpd5, ppp, proxy-arp issues
Hi,
I was setting up mpd5 from ports, but this proxy-arp issue still exists in
8.0.
uname -r
8.0-RELEASE-p2
I've attached the output from the mpd5 daemon, where you can still see that
the issue is relevant.
I've also tried to apply the patch, but it's no longer on that location.
Something else to add - I've a dns server running on the same machine that
mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp
issue, but after a couple of start/stops of mpd5 the name resolving from the
gateway machine is not possible, all other systems from the internal network
are able to use the dns server on the gateway, but the gateway itself
cannot.
Restart of named, doesn't help either, so I had to completely reboot the
machine, so that arp entries are flushed as well.
Could you please have a look at the issue? If you need some additional
information, please let me know.
Regards,
Marin
On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. pr...@skylinetele.comwrote:
Thank you !
The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with
mpd5).
Please, somebody fix the bug kern/141285...
Li, Qing wrote:
Hi,
Recently there have been several reports regarding issues with ppp, mpd5
and proxy-arp configuration over the ppp links. I read through the
various postings and the problems seem to be:
1. Unable to add proxy-arp entries for the remote ppp clients.
2. Log showing ifa_add_loopback_route: insertion failed causingsome
userland applications to fail.
May I ask that you try applying patch
http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diffhttp://people.freebsd.org/%7Eqingli/ppp-proxy-arp-patch-121515.diff
and report back if the patch fixes your problems. And if not, please
describe what additional issues you are having.
Thanks,
-- Qing
___
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to freebsd-net-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
--
Marin Atanasov Nikolov
dnaeon AT gmail DOT com
daemon AT unix-heaven DOT org
# /usr/local/sbin/mpd5
Multi-link PPP daemon for FreeBSD
process 2295 started, version 5.5 (r...@domain 02:21 17-Apr-2010)
Usage: set user {name} {password} [{priv}]
CONSOLE: listening on 127.0.0.1 5005
web: listening on 0.0.0.0 5006
PPTP: waiting for connection on external-ip-here 1723
[L] [L-1] Accepting PPTP connection
[L-1] Link: OPEN event
[L-1] LCP: Open event
[L-1] LCP: state change Initial -- Starting
[L-1] LCP: LayerStart
[L-1] PPTP: attaching to peer's outgoing call
[L-1] Link: UP event
[L-1] LCP: Up event
[L-1] LCP: state change Starting -- Req-Sent
[L-1] LCP: SendConfigReq #1
[L-1] ACFCOMP
[L-1] PROTOCOMP
[L-1] MRU 1500
[L-1] MAGICNUM 102c4d22
[L-1] AUTHPROTO CHAP MSOFTv2
[L-1] MP MRRU 2048
[L-1] MP SHORTSEQ
[L-1] ENDPOINTDISC [802.1] 00 10 dc 10 55 3f
[L-1] LCP: rec'd Configure Reject #1 (Req-Sent)
[L-1] MP MRRU 2048
[L-1] MP SHORTSEQ
[L-1] ENDPOINTDISC [802.1] 00 10 dc 10 55 3f
[L-1] LCP: SendConfigReq #2
[L-1] ACFCOMP
[L-1] PROTOCOMP
[L-1] MRU 1500
[L-1] MAGICNUM 102c4d22
[L-1] AUTHPROTO CHAP MSOFTv2
[L-1] LCP: rec'd Configure Ack #2 (Req-Sent)
[L-1] ACFCOMP
[L-1] PROTOCOMP
[L-1] MRU 1500
[L-1] MAGICNUM 102c4d22
[L-1] AUTHPROTO CHAP MSOFTv2
[L-1] LCP: state change Req-Sent -- Ack-Rcvd
[L-1] LCP: rec'd Configure Request #1 (Ack-Rcvd)
[L-1] MRU 1400
[L-1] MAGICNUM 7fe5744d
[L-1] PROTOCOMP
[L-1] ACFCOMP
[L-1] CALLBACK 6
[L-1] LCP: SendConfigRej #1
[L-1] CALLBACK 6
[L-1] LCP: rec'd Configure Request #2 (Ack-Rcvd)
[L-1] MRU 1400
[L-1] MAGICNUM 7fe5744d
[L-1] PROTOCOMP
[L-1] ACFCOMP
[L-1] LCP: SendConfigAck #2
[L-1] MRU 1400
[L-1] MAGICNUM 7fe5744d
[L-1] PROTOCOMP
[L-1] ACFCOMP
[L-1] LCP: state change Ack-Rcvd -- Opened
[L-1] LCP: auth: peer wants nothing, I want CHAP
[L-1] CHAP: sending CHALLENGE #1 len: 21
[L-1] LCP: LayerUp
[L-1] LCP: rec'd Ident #3 (Opened)
[L-1] MESG: MSRASV5.10
[L-1] LCP: rec'd Ident #4 (Opened)
[L-1] MESG: MSRAS-0-TSUNAMI
[L-1] CHAP: rec'd RESPONSE #1 len: 61
[L-1] Name: mratest
[L-1] AUTH: Trying INTERNAL
[L-1] AUTH: INTERNAL returned: undefined
[L-1] CHAP: Auth return status: undefined
[L-1] CHAP: Response is valid
[L-1] CHAP: Reply message: S=8BE305F08FBAEB4E801B6201037B4B4AEB76A73B
[L-1] CHAP: sending SUCCESS #1 len: 46
[L-1] LCP: authorization successful
[L-1] Link: Matched action 'bundle B '
[L-1] Creating new bundle using template B.
[B-1] Bundle: Interface ng0 created
[L-1] Link: Join bundle B-1
[B-1] Bundle: Status update: up 1 link, total bandwidth 64000 bps
[B-1] IPCP: Open event
[B-1] IPCP: state change Initial -- Starting
[B-1] IPCP: LayerStart
[B-1] CCP: Open event
8.6 The Configuration File out of date?
Hi, I wonder if somebody add/remove the kernel options that came went with FreeBSD 8.0. For example: Those that seemed to have disappeared: machinei386 options GEOM_GPT options COMPAT_43 options ADAPTIVE_GIANT New ones that appeared in GENERIC (at least: they are not discussed in the Handbook, 8.6): optionsSCTP options UFS_GJOURNAL options GEOM_PART_GPT options GEOM_LABEL options COMPAT_43TTY options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 options STACK options P1003_1B_SEMAPHORES options PRINTF_BUFR_SIZE=128 Regards, R. ___ 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: ath0: kernel panic when adhoc mode.
Hello, Paul B Mahol! On Sun, Apr 18, 2010 at 10:20:26AM + one...@gmail.com wrote about Re: ath0: kernel panic when adhoc mode.: On 4/14/10, Lystopad Olexandr l...@laa.zp.ua wrote: Hi! I install 8.0 FreeBSD, upgrade it to yesturday stable. I need to create wireless link in adhoc mode. Help me to do this. I put a wireless card into this box: a...@pci0:3:3:0:class=0x02 card=0xcc2114b9 chip=0x0013168c rev=0x01 hdr=0x00 vendor = 'Atheros Communications Inc.' device = '802.11a/b/g Wireless Adapter (AR5212)' class = network subclass = ethernet cap 01[44] = powerspec 2 supports D0 D3 current D0 when I do: # ifconfig wlan0 create wlandev ath0 wlanmode adhoc server reboot with kernel panic: Fatal trap 12: page fault while in kernel mode cpuid = 1; apic id = 01 fault virtual address = 0x fault code = supervisor read, page not present instruction pointer = 0x20:0xc0791612 stack pointer = 0x28:0xd2f42ba4 frame pointer = 0x28:0xd2f42bac code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 0 (ath0 taskq) trap number = 12 panic: page fault cpuid = 1 Uptime: 3m35s Physical memory: 439 MB Dumping 80 MB: 65 49 33panic: bufwrite: buffer is not busy??? cpuid = 1 17 1 #0 doadump () at pcpu.h:246 246 pcpu.h: No such file or directory. in pcpu.h (kgdb) #0 doadump () at pcpu.h:246 #1 0xc06b3497 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:416 #2 0xc06b3789 in panic (fmt=Variable fmt is not available. ) at /usr/src/sys/kern/kern_shutdown.c:579 #3 0xc08b63bc in trap_fatal (frame=0xd2f42b64, eva=65535) at /usr/src/sys/i386/i386/trap.c:938 #4 0xc08b6620 in trap_pfault (frame=0xd2f42b64, usermode=0, eva=65535) at /usr/src/sys/i386/i386/trap.c:851 #5 0xc08b6f39 in trap (frame=0xd2f42b64) at /usr/src/sys/i386/i386/trap.c:533 #6 0xc0899b3b in calltrap () at /usr/src/sys/i386/i386/exception.s:165 #7 0xc0791612 in ieee80211_getcapinfo (vap=0xc2d5f000, chan=0x) at /usr/src/sys/net80211/ieee80211_output.c:1836 #8 0xc0793d17 in ieee80211_beacon_construct (m=0xc2edca00, frm=0xc2f0516e , bo=0xc2d5f884, ni=0xc2ceb000) at /usr/src/sys/net80211/ieee80211_output.c:2559 #9 0xc07946db in ieee80211_beacon_alloc (ni=0xc2ceb000, bo=0xc2d5f884) at /usr/src/sys/net80211/ieee80211_output.c:2756 #10 0xc050eaea in ath_newstate (vap=0xc2d5f000, nstate=IEEE80211_S_RUN, arg=-1) at /usr/src/sys/dev/ath/if_ath.c:2641 #11 0xc0798db1 in ieee80211_newstate_cb (xvap=0xc2d5f000, npending=3) at /usr/src/sys/net80211/ieee80211_proto.c:1654 #12 0xc06ebf92 in taskqueue_run (queue=0xc2a84c80) at /usr/src/sys/kern/subr_taskqueue.c:239 #13 0xc06ec19d in taskqueue_thread_loop (arg=0xc2ada074) at /usr/src/sys/kern/subr_taskqueue.c:360 #14 0xc068a331 in fork_exit (callout=0xc06ec0e0 taskqueue_thread_loop, arg=0xc2ada074, frame=0xd2f42d38) at /usr/src/sys/kern/kern_fork.c:843 #15 0xc0899bb0 in fork_trampoline () at /usr/src/sys/i386/i386/exception.s:270 (kgdb) This is bug, please report it ASAP. Thanks. Done. http://www.freebsd.org/cgi/query-pr.cgi?pr=145826 -- Olexandr Lystopad ___ 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: 8.6 The Configuration File out of date?
On Mon, Apr 19, 2010 at 12:54 AM, Rob spamref...@yahoo.com wrote: Hi, I wonder if somebody add/remove the kernel options that came went with FreeBSD 8.0. For example: Those that seemed to have disappeared: machine i386 What architecture was this for -- amd64, i386, etc? options GEOM_GPT Should be GEOM_PART_GPT options COMPAT_43 Eh...? This still should be in there according to NOTES. options ADAPTIVE_GIANT Yes, this should be removed. New ones that appeared in GENERIC (at least: they are not discussed in the Handbook, 8.6): options SCTP options UFS_GJOURNAL options GEOM_PART_GPT options GEOM_LABEL options COMPAT_43TTY options COMPAT_FREEBSD6 options COMPAT_FREEBSD7 options STACK options P1003_1B_SEMAPHORES options PRINTF_BUFR_SIZE=128 These are all discussed in sys/conf/NOTES though, so they definitely need to be updated in the handbook. I'd file a PR with your findings and assign it to the doc category. Thanks for the keen eyes :)! -Garrett ___ 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: 8.6 The Configuration File out of date?
Garrett Cooper wrote: machinei386 What architecture was this for -- amd64, i386, etc? But this line is not at all present in the GENERIC configuration of FreeBSD 8.0 release options COMPAT_43 Eh...? This still should be in there according to NOTES. It's not in the GENERIC kernel configuration... There is, however: options COMPAT_43TTY Is that a mistake then? R. ___ 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: 8.6 The Configuration File out of date?
On Mon, Apr 19, 2010 at 6:13 AM, Rob spamref...@yahoo.com wrote: Garrett Cooper wrote: machine i386 What architecture was this for -- amd64, i386, etc? But this line is not at all present in the GENERIC configuration of FreeBSD 8.0 release Probably because there was unnecessary overlap with `cpu ...'. options COMPAT_43 Eh...? This still should be in there according to NOTES. It's not in the GENERIC kernel configuration... There is, however: options COMPAT_43TTY Is that a mistake then? Not IIRC; they were just preparing to remove the need for COMPAT_43 entirely in 8.1 (I think). Thanks, -Garrett ___ 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: cyclades driver in 8.0-STABLE
On Sunday 18 April 2010 10:11:07 pm Albert Chin wrote: Just updated to 8.0-RELEASE and recompiling 8.0-STABLE with the following addition to GENERIC: device cy options CY_PCI_FASTINTR Building the kernel with: make buildkernel KERNCONF=NEWKERNEL gives me: cc -c -O -pipe -march=pentium4 -std=c99 -g -Wall -Wredundant-decls - Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith - Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -nostdinc -I. -I/opt/freebsd/src/sys -I/opt/freebsd/src/sys/contrib/altq -D_KERNEL - DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-common -finline- limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow - mno-sse -mno-sse2 -mno-sse3 -ffreestanding -fstack-protector -Werror /opt/freebsd/src/sys/dev/cy/cy.c /opt/freebsd/src/sys/dev/cy/cy.c:251: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cybreak' /opt/freebsd/src/sys/dev/cy/cy.c:252: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cymodem' /opt/freebsd/src/sys/dev/cy/cy.c:253: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyopen' /opt/freebsd/src/sys/dev/cy/cy.c:254: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'cyclose' cc1: warnings being treated as errors FreeBSD 7 had: typedef void t_break_t(struct tty *, int); in sys/tty.h This is no longer present in FreeBSD 8. Oversight? Should I be able to compile the cyclades driver for FreeBSD 8? No, it is not presently supported on 8. It needs to be ported to the new tty layer. You could perhaps ask e...@freebsd.org for some assistance. -- John Baldwin ___ 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: 8.6 The Configuration File out of date?
On Mon, Apr 19, 2010 at 8:12 AM, Garrett Cooper yanef...@gmail.com wrote: On Mon, Apr 19, 2010 at 6:13 AM, Rob spamref...@yahoo.com wrote: Garrett Cooper wrote: machinei386 What architecture was this for -- amd64, i386, etc? But this line is not at all present in the GENERIC configuration of FreeBSD 8.0 release Probably because there was unnecessary overlap with `cpu ...'. No, it's been moved to DEFAULTS, along with a handful of other things that should always be present in an i386 kernel (isa, npx, mem, io, etc). Same for amd64. machine amd64 is in DEFAULTS, not GENERIC. options COMPAT_43 Eh...? This still should be in there according to NOTES. It's not in the GENERIC kernel configuration... There is, however: options COMPAT_43TTY Is that a mistake then? Not IIRC; they were just preparing to remove the need for COMPAT_43 entirely in 8.1 (I think). One does not need COMPAT_43 anymore, as the few remaining bits that are required were moved to COMPAT_43TTY. One can build a kernel without COMPAT_43 (been doing that for awhile now). -- Freddie Cash fjwc...@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: rc(8) script -- waiting for the network to become usable
On 4/18/2010 4:24 PM, Andrew Reilly wrote: By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. While I find the discussion about launchd-type facilities interesting, we have a real problem at the moment and now we have a real solution for it. Jeremy, since no one has criticized your idea on a technical basis why don't you run it by the -net and -rc lists to be sure that it's technically sound, then I would be inclined to move forward with it. Doug -- ... and that's just a little bit of history repeating. -- Propellerheads Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.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: rc(8) script -- waiting for the network to become usable
On Mon, Apr 19, 2010 at 11:05 AM, Doug Barton do...@freebsd.org wrote: On 4/18/2010 4:24 PM, Andrew Reilly wrote: By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. While I find the discussion about launchd-type facilities interesting, we have a real problem at the moment and now we have a real solution for it. Jeremy, since no one has criticized your idea on a technical basis why don't you run it by the -net and -rc lists to be sure that it's technically sound, then I would be inclined to move forward with it. Agreed. Thanks, -Garrett ___ 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: net/mpd5, ppp, proxy-arp issues
Have you seen this thread? http://lists.freebsd.org/pipermail/freebsd-net/2010-April/025128.html Quite a few fixes have gone into the -current and RELENG_8 branches. Please try sync-up to the latest code before applying the patch. -- Qing On Sun, Apr 18, 2010 at 11:53 PM, Marin Atanasov dna...@gmail.com wrote: Hi, I was setting up mpd5 from ports, but this proxy-arp issue still exists in 8.0. uname -r 8.0-RELEASE-p2 I've attached the output from the mpd5 daemon, where you can still see that the issue is relevant. I've also tried to apply the patch, but it's no longer on that location. Something else to add - I've a dns server running on the same machine that mpd5 was set up. I'm not sure if this is caused by mpd5 daemon or the arp issue, but after a couple of start/stops of mpd5 the name resolving from the gateway machine is not possible, all other systems from the internal network are able to use the dns server on the gateway, but the gateway itself cannot. Restart of named, doesn't help either, so I had to completely reboot the machine, so that arp entries are flushed as well. Could you please have a look at the issue? If you need some additional information, please let me know. Regards, Marin On Wed, Dec 16, 2009 at 6:09 PM, Prokofiev S.P. pr...@skylinetele.com wrote: Thank you ! The problem with proxy-arp has disappeared (FreeBSD 8-STABLE amd64 with mpd5). Please, somebody fix the bug kern/141285... Li, Qing wrote: Hi, Recently there have been several reports regarding issues with ppp, mpd5 and proxy-arp configuration over the ppp links. I read through the various postings and the problems seem to be: 1. Unable to add proxy-arp entries for the remote ppp clients. 2. Log showing ifa_add_loopback_route: insertion failed causing some userland applications to fail. May I ask that you try applying patch http://people.freebsd.org/~qingli/ppp-proxy-arp-patch-121515.diff and report back if the patch fixes your problems. And if not, please describe what additional issues you are having. Thanks, -- Qing ___ freebsd-...@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to freebsd-net-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 -- Marin Atanasov Nikolov dnaeon AT gmail DOT com daemon AT unix-heaven DOT 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: rc(8) script -- waiting for the network to become usable
On Mon, Apr 19, 2010 at 11:05:17AM -0700, Doug Barton wrote: On 4/18/2010 4:24 PM, Andrew Reilly wrote: By way of discussion, I'd just like to re-iterate what I said the first time around: it must be understood that this sort of thing is a (necessary) hacky-workaround that should ultimately be unnecessary. While I find the discussion about launchd-type facilities interesting, we have a real problem at the moment and now we have a real solution for it. Jeremy, since no one has criticized your idea on a technical basis why don't you run it by the -net and -rc lists to be sure that it's technically sound, then I would be inclined to move forward with it. Doug and Garrett -- thanks. I'll send a shorter mail to said lists referencing the discussion here on -stable and let folks weigh in. Much appreciated! -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ 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
Problems with gmirror locking up on recent 8.0-STABLE/i386
I have a machine used as a firewall which boots from a pair of drives mirrored using gmirror. This has been in situ for a long time, and was upgraded to 8.0 a while ago. Just before the weekend I upgraded the kernel to the latest STABLE to get the new em code. After doing this I observed that at seemingly random points the disc system would 'lockup' by which I mean that all networking continued fine, but if you tried to do anything which would read or write the disc then that would pause forever. Only fixed by reboot, and on reboot the array was degraded, and always resynced the same drive. dying drive I thought to myself - seemed a resonable conclusion. Except today I took another machine (completelt different hardware BTW) and build a new system with different drives, but the same gmirrored configuration - and an hour after I had installed it, it locked up in exactly the same way. Just after I upgraded it to match the version of the kernel running onthe original one in fact. So now I am wondering if there is some unfortunate problem which has crept into gmirror in the last few weeks. Has anyone else seen anything like this ? -pete. ___ 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: Problems with gmirror locking up on recent 8.0-STABLE/i386
Just following up my own email, but soemthing is definitely up with gmirror, as it has got to 100% complete on the resync, but stays in degraded mode... i.e. $ gmirror status NameStatus Components mirror/pair0 DEGRADED da0s1 da1s1 (100%) this, obviously, shouldn't happen should it ? I am thinking maybe I should resync my code and rebuild my kernel. -pete. ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
A switch to use newer GMP version has been committed. Unfortunately lang/ghc and dependent ports (and possibly lang/gnat-gcc44) were broken by this. The brokenness wasn't detected in our -exp run because of being masked by other issues. It will take a few days to fix lang/ghc. I'm still investigating lang/gnat-gcc44. As a workaround, keep your old gmp library in /usr/local/lib/compat/pkg; both portmaster and portupdate have an option for this. X11 is still in work, the other are waiting for it. -- IOnut - Un^d^dregistered ;) FreeBSD user Intellectual Property is nowhere near as valuable as Intellect FreeBSD committer - ite...@freebsd.org, PGP Key ID 057E9F8B493A297B signature.asc Description: PGP signature
Re: [ HEADS UP ] Ports unstable for the next 10 days
On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: A switch to use newer GMP version has been committed. I'm still investigating lang/gnat-gcc44. As far as I know, the gnat-gcc44 bootstrap binaries will be fine as they're bundled with the libgmp library that was used to build them. Whether gcc builds with the newer libgmp remains to be seen... M ___ 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: [ HEADS UP ] Ports unstable for the next 10 days
On Mon, Apr 19, 2010 at 4:38 PM, freebsd-po...@coreland.ath.cx wrote: On 2010-04-20 02:14:20, Ion-Mihai Tetcu wrote: A switch to use newer GMP version has been committed. I'm still investigating lang/gnat-gcc44. As far as I know, the gnat-gcc44 bootstrap binaries will be fine as they're bundled with the libgmp library that was used to build them. Whether gcc builds with the newer libgmp remains to be seen... As discussed in the QAT emails, it might be related to ccache use on the build cluster graciously donated by ixSystems, and the fact that the cached data is inconsistently distributed across the cluster. I've provided some tips for itetcu to work around this on IRC (basically disable ccache), but it kind of sucks when you run into periodic issues with toolchain variance like this, s.t. building with NO_CACHE=yes is a necessary evil to work through end-to-end build functional issues. Someone else who knows more about ccache could provide a better explanation of what's going on because my ranting about this would only be me talking out of my rear :). More info about ccache with FreeBSD can be found here: http://forums.freebsd.org/archive/index.php/t-174.html Cheers, -Garrett ___ 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: 8.6 The Configuration File out of date?
Freddie Cash wrote: No, it's been moved to DEFAULTS, along with a handful of other things that should always be present in an i386 kernel (isa, npx, mem, io, etc). Is the DEFAULTS configuration automagically included into a custom kernel configuration file, or does it then require an extra line: include DEFAULTS to have these defaults included? Is this documented somewhere? Thanks. R. ___ 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: 8.6 The Configuration File out of date?
On Mon, Apr 19, 2010 at 8:13 PM, Rob spamref...@yahoo.com wrote: Freddie Cash wrote: No, it's been moved to DEFAULTS, along with a handful of other things that should always be present in an i386 kernel (isa, npx, mem, io, etc). Is the DEFAULTS configuration automagically included into a custom kernel configuration file, or does it then require an extra line: include DEFAULTS to have these defaults included? You'd have to double-check the Makefiles and whatnot, but I believe it's pulled in to every kernel build, not matter what. Hence the name. :) Is this documented somewhere? In the Makefiles? -- Freddie Cash fjwc...@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: ZFS Tuning - arc_summary.pl
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On Mon, 29 Mar 2010 10:43, Barry Pederson wrote:
In Message-Id: 4bb0bc7c.3000...@barryp.org
I've been using the arc_summary.pl script from here:
http://jhell.googlecode.com/svn/base/head/scripts/zfs/arc_summary/arc_summary.pl
and noticed some odd numbers, with the ARC Current Size being larger than the
Max Size, and the breakdown adding up to less than the current size as shown
below
ARC Size:
Current Size: 992.71M (arcsize)
Target Size: (Adaptive) 512.00M (c)
Min Size (Hard Limit): 81.82M (arc_min)
Max Size (Hard Limit): 512.00M (arc_max)
ARC Size Breakdown:
Recently Used Cache Size: 99.84% 511.18M (p)
Frequently Used Cache Size: 0.16% 0.82M (c-p)
From another thread I saw, it sounds like arc_max isn't really
a Hard Limit but rather some kind of high water mark. If that's
the case then I wonder if this might make more sense
-
--- arc_summary.pl.original 2010-02-25 19:23:13.0 -0600
+++ arc_summary.pl 2010-03-29 09:32:28.0 -0500
@@ -121,20 +121,20 @@
my $arc_size = ${Kstat}-{zfs}-{0}-{arcstats}-{size};
my $arc_size_MiB = ($arc_size / 1048576);
-my $mfu_size = $target_size - $mru_size;
+my $mfu_size = $arc_size - $mru_size;
my $mfu_size_MiB = ($mfu_size / 1048576);
-my $mru_perc = 100*($mru_size / $target_size);
-my $mfu_perc = 100*($mfu_size / $target_size);
+my $mru_perc = 100*($mru_size / $arc_size);
+my $mfu_perc = 100*($mfu_size / $arc_size);
print ARC Size:\n;
printf(\tCurrent Size:\t\t\t\t%0.2fM (arcsize)\n, $arc_size_MiB);
printf(\tTarget Size: (Adaptive)\t\t\t%0.2fM (c)\n, $target_size_MiB);
printf(\tMin Size (Hard Limit):\t\t\t%0.2fM (arc_min)\n,
$arc_min_size_MiB);
-printf(\tMax Size (Hard Limit):\t\t\t%0.2fM (arc_max)\n,
$arc_max_size_MiB);
+printf(\tMax Size :\t\t\t%0.2fM (arc_max)\n,
$arc_max_size_MiB);
print \nARC Size Breakdown:\n;
printf(\tRecently Used Cache Size:\t%0.2f%%\t%0.2fM (p)\n, $mru_perc,
$mru_size_MiB);
-printf(\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (c-p)\n, $mfu_perc,
$mfu_size_MiB);
+printf(\tFrequently Used Cache Size:\t%0.2f%%\t%0.2fM (arcsize-p)\n,
$mfu_perc, $mfu_size_MiB);
print \n;
### ARC Efficency ###
---
Giving something like this...
ARC Size:
Current Size: 992.88M (arcsize)
Target Size: (Adaptive) 512.00M (c)
Min Size (Hard Limit): 81.82M (arc_min)
Max Size : 512.00M (arc_max)
ARC Size Breakdown:
Recently Used Cache Size: 51.48% 511.18M (p)
Frequently Used Cache Size: 48.52% 481.70M (arcsize-p)
Barry
Barry,
What branch and revision was this run on ?
I need the above information because the output above just does not match
up quite as it should and I want to investigate when, where why as I
believe something else is going on here that is not on the behalf of
arc_summary.pl.
Or if you could provide me personally with the full output of the script
from the downloads section just to be sure in an attachment that would
work as well.
Thanks.
- --
jhell
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.14 (FreeBSD)
iQEcBAEBAgAGBQJLzUAhAAoJEJBXh4mJ2FR+kP4H/3FSkazC+Jxv0q5XJhP/YfeP
gJ0vWP+84J6HM68GyS4eCOu3QPGUPBAuqZOS8Bb9jXg9xNfxCvw2DQn5mP6v6i6H
w8mWyYyCla7iBfItod4L2GjQeP52SIt7sW9icDeWvrS+LphwjTQmBiA4QwGBQT5D
YiarUMpzY1Jkq8I6YgGYRIwZqeuNn7X68ZEKIz8/LhTM6WKdktm5dcBb6UM/mC/a
I82sv+7mG/9Bn0Orp7DMqvym0rllYmb+Sj7Pj2NEcPt9LYDNf6Vy1Wmly6hNQTYb
b8WkfgLeMogDN9JS6Bw+UxNGwHgQgqDIWvkKDt9qrmuTpKLEozD6GnBzo27uZkg=
=RoRd
-END PGP SIGNATURE-
___
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
