Re: net/mpd5, ppp, proxy-arp issues
Am 22.04.2010 20:43, schrieb Marin Atanasov: > Hello, > > Thanks a lot for the patch, Qing! > > It works fine. However I've noticed one thing, after I start mpd5 and > connect to my home network: > > kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() > > Not very sure if this is something to worry about or not? There was a problem with the initialization order of network "domains", which caused kernel crashes with ISDN+INET6 some two years ago. The reason was, that there was an implicit assumption, that all domains were initialized when the network interfaces are initialized, with NULL dereferences if domains are added (and relevant to a device) after the device has been initialized. I debugged this problem and prepared a patch for discussion, which later was committed by Max Laier (if memory serves me right). The message was added in order to identify further situations, where network domains are added after network interfaces have been initialized. This message ought to be informational right now, since the interface init is repeated whenever a network domain is added as part of above mentioned patch. Init order should be fixed, if this message is printed for compiled in drivers, but in case of a kernel module (like netgraph) that adds a domain, it is unadvoidable that the init order is reversed. Perhaps the message should be made conditional on the start-up of the kernel not having finished, or it should be completely removed, since time has shown, that the init order is correct in general. I'll remove that message (or make it conditional on "bootverbose") unless there is opposition to this change ... Regards, STefan ___ 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:54:46AM -0700, Jeremy Chadwick wrote: > 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! I've sent said mail to -rc and -net. -- | 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"
Re: can't compile kernel on STABLE
on 25/04/2010 11:37 Sandra Kachelmann said the following: > I _just_ checked out the source tree for RELENG_6 and tried to build > an image for my ALIX board: > > > $ NOCCACHE=yes KERNCONF=GENERIC TARGET_ARCH=i386 CPUTYPE=i586 make buildkernel > > ... > /usr/src/sys/i386/i386/genassym.c:1: error: > -mpreferred-stack-boundary=2 is not between 4 and 12 > *** Error code 1 You are cross-compiling a kernel for a different architecture but you haven't built a toolchain for that architecture. See kernel-toolchain in build(7). -- 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: net/mpd5, ppp, proxy-arp issues
On 4/26/10 1:11 AM, Stefan Esser wrote: Am 22.04.2010 20:43, schrieb Marin Atanasov: Hello, Thanks a lot for the patch, Qing! It works fine. However I've noticed one thing, after I start mpd5 and connect to my home network: kernel: WARNING: attempt to domain_add(netgraph) after domainfinalize() Not very sure if this is something to worry about or not? There was a problem with the initialization order of network "domains", which caused kernel crashes with ISDN+INET6 some two years ago. The reason was, that there was an implicit assumption, that all domains were initialized when the network interfaces are initialized, with NULL dereferences if domains are added (and relevant to a device) after the device has been initialized. I debugged this problem and prepared a patch for discussion, which later was committed by Max Laier (if memory serves me right). The message was added in order to identify further situations, where network domains are added after network interfaces have been initialized. This message ought to be informational right now, since the interface init is repeated whenever a network domain is added as part of above mentioned patch. Init order should be fixed, if this message is printed for compiled in drivers, but in case of a kernel module (like netgraph) that adds a domain, it is unadvoidable that the init order is reversed. Perhaps the message should be made conditional on the start-up of the kernel not having finished, or it should be completely removed, since time has shown, that the init order is correct in general. I'll remove that message (or make it conditional on "bootverbose") unless there is opposition to this change ... please do.. it's an unavoidable thing that domains added after boot are done after boot completes :-) Regards, STefan ___ 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"
RE: rc(8) script -- waiting for the network to become usable
Jeremy, A good proposal to improve start-up robustness. If I may suggest, waitnetwork_ip should include a short list of alternate IP's in the event of a local network outage, or DOS, etc. Something like: waitnetwork_ip="IP1 IP2 IP3" Having multiple target IP's will improve the likelihood of timely booting when silly/nasty things happen on the wider network. Good idea to have incorporated into the base system. Andrew, I agree that the problems should be corrected at the source; and my preference is to fail properly (b) so that other mitigation may occur. Done in parallel, would eventually provide a belts and braces start-up: wait for the network, and fail properly for network dependent processes. (I can't speak to desktops that resume from a suspend when the network has changed state.) Regards, Phil ___ 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 Tue, Apr 27, 2010 at 09:48:41AM +1000, Phil wrote:
> Jeremy,
> A good proposal to improve start-up robustness. If I may suggest,
> waitnetwork_ip should include a short list of alternate IP's in
> the event of a local network outage, or DOS, etc. Something like:
> waitnetwork_ip="IP1 IP2 IP3"
>
> Having multiple target IP's will improve the likelihood of timely
> booting when silly/nasty things happen on the wider network.
>
> Good idea to have incorporated into the base system.
Phil,
I brought this point up in my post on -rc and -net, actually. I've
since extended the script to support multiple IPs in $waitnetwork_ip
(wasn't that hard). The logic is that if any of the IPs pass the ping
test, then the network connection is considered usable.
Attached is the modified script. I'll be updating the version on my
server (HTTP) momentarily.
--
| 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 |
#!/bin/sh
#
# $FreeBSD: $
#
# PROVIDE: waitnetwork
# REQUIRE: NETWORKING
# BEFORE: mountcritremote
# KEYWORD: nojail
# XXX - Once/if committed to base, it's better to have mountcritremote
# XXX - REQUIRE waitnetwork, rather than use the above BEFORE line.
. /etc/rc.subr
name="waitnetwork"
rc_var=`set_rcvar`
start_cmd="waitnetwork_start"
stop_cmd=":"
# XXX - Once/if committed to base, the following defaults should
# XXX - be placed into src/etc/defaults/rc.conf instead of here
# XXX - Also be sure to keep waitnetwork_ip="" commented out!
waitnetwork_enable="NO" # Wait for network availability before
# continuing with NETWORKING rc scripts
#waitnetwork_ip="" # IP address to ping
waitnetwork_count="5" # ping count (see ping(8) -c flag)
waitnetwork_timeout="60"# ping timeout (see ping(8) -t flag)
waitnetwork_start()
{
local ip rc success
success=0
if [ -z "${waitnetwork_ip}" ]; then
warn "You must define one or more IP addresses in
waitnetwork_ip"
return
fi
for ip in ${waitnetwork_ip}; do
echo "Waiting for ${ip} to respond to ICMP..."
if [ -z "${waitnetwork_timeout}" ]; then
/sbin/ping -c ${waitnetwork_count} ${ip} >/dev/null 2>&1
rc=$?
else
info "Using timeout of ${waitnetwork_timeout} seconds"
/sbin/ping -t ${waitnetwork_timeout} -c
${waitnetwork_count} ${ip} >/dev/null 2>&1
rc=$?
fi
if [ $rc -eq 0 ]; then
echo "Host reachable; network considered available."
return
else
echo "No response from host."
fi
done
echo "Exhausted IP list. Continuing with startup, but be aware you may"
echo "not have a fully functional networking layer at this point."
}
load_rc_config $name
run_rc_command "$1"
___
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"
