Date: Mon, 03 May 2010 10:39:27 +0200 From: Stefan Esser <se@FreeBSD.org> To: freebsd-stable@freebsd.org Subject: Re: net/mpd5, ppp, proxy-arp issues Message-ID: <4BDE8BBF.10603@FreeBSD.org> In-Reply-To: <4BD5B91B.2050606@elischer.org> References: <B583FBF374231F4A89607B4D08578A430619B993@bcs-mail03.internal.cacheflow.com> <4B28F841.1070900@skylinetele.com> <i2o717f7a3e1004182353v7ead46b8g899c2e021d2dee42@mail.gmail.com> <w2t9ace436c1004191050n97692c4fq3d76e6becc5b354f@mail.gmail.com> <k2q717f7a3e1004192300r44d2c4aem5568c9e412f8b6f2@mail.gmail.com> <j2q9ace436c1004200103n336f8118teb45c3ebacec8239@mail.gmail.com> <o2w717f7a3e1004221143p6fafa849t8da52a6aa5be3bac@mail.gmail.com> <4BD54AC7.7090301@FreeBSD.org> <4BD5B91B.2050606@elischer.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Am 26.04.2010 18:02, schrieb Julian Elischer: > On 4/26/10 1:11 AM, Stefan Esser wrote: >> 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 :-) Hmmm, I had a look at the code over the weekend and I'm not sure, whether changes during the last 5 years did not break assumptions and introduced bugs in if_attachdomain1() in /sys/net/if.c ... The tests at the head of the function seem problematic, but will need further analysis. I'll have to check the conditions under which the TRY_LOCK may fail and the second if clause seems to prevent the execution of the core of the function for KLDs (which would be BAD). Since I'm travelling abroad and without access to the sources or a test system for most of the week, I cannot perform these tests. But I'd be very surprised, if the code still worked as I intended it more than 5 years ago ... I'll hold back any commits until I have been able to perform tests (or somebody else looks into this and gets to a conclusion ...). Best regards, STefan
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4BDE8BBF.10603>