Re: 1.3.94 Ooops For Sale...

Jonathan Layes (layes@loran.com)
Thu, 25 Apr 1996 18:32:57 -0400

On Apr 25, 22:11, bj0rn@blox.se (Bjorn Ekwall) wrote:
>Linus wrote:
>> Simon Shapiro wrote:
>> > Few more tidbits;
>> > death):
>> >
>> > 1. ``Ouch, kerneld wanted to sleep in interrupt'' every second or two
>> > 2. Login freezes after taking the login name on the console.
>> > 3. Existing telnet session totally frozen.
>> > 4. ``Cannot load interpreter'' in response to login - sometimes.
>> >
>> > This was preceeded by the same unholy stream of prophanity as described in
>> > my previous posting under this title (``route to %p was born dead'').
>>
>> Ok, "kerneld" goes disabled in the next kernel, and won't be resuscitated until
>> after 2.0 is out unless somebody really starts to look into this thing. I'm not
>> using kerneld personally, and for a few reasons I don't think I _will_ be using
>> it in the near future, so I won't be fixing this.

Bjorn is right.... there is absolutely no need to disable kerneld, because
the problems described are exclusively arpd's fault.

I have talked to Simon before about this - the solution is simple. Don't
turn on arpd until I can fix the problem. Something/one has changed the
behaviour of ARP in the past 10-15 releases and it hasn't been stable since,
in particular on machines with more than one interface.
Since arpd is marked as experimental and defaults to being off and there
is a lengthy explanation about its purpose in the make config help, I
don't see why this is such a big issue.

For what it's worth, on a single interface machine on a class B network,
linux still performs better with arpd than without, even with the known
problems. So, I'm suggesting that it not be disabled just yet. Maybe
we just need to put the word experimental in all caps, blinking and boldface.

jonathan

(p.s. thanks for the tips Bjorn, I'm looking into it asap)