Date: Tue, 22 Jun 1999 13:42:38 +0200 From: "Julian Stacey" <jhs@jhs.muc.de> To: Greg Lehey <grog@lemis.com> Cc: freebsd-mobile@FreeBSD.ORG, garyj@muc.de, mwe@consol.de Subject: Re: Delayed network mounts from pccard prevent amd & timed Message-ID: <199906221142.LAA03063@jhs.muc.de> In-Reply-To: Your message of "Sun, 20 Jun 1999 08:10:29 %2B0200." <19990620154029.E6820@freebie.lemis.com>
next in thread | previous in thread | raw e-mail | index | archive | help
Greg Lehey wrote: > On Thursday, 17 June 1999 at 20:59:17 +0000, Julian Stacey wrote: > > amd & timed (& maybe others too ?) do not start properly from rc.network > > if network availability is delayed resulting from delayed config of > > ep0 ethernet pcmcia via pccard, (on a 3.2 Release laptop). > > ( BTW I have no Amd fail problems on my 3.2 towers with ISA & PCI ether ca > rds, > > or on 3.2 laptops linked via plip & slip, only with the delayed pcmcia eth > er.) > > > > A reworking of the startup shells may be needed, a discussion of the > > startup interactions would involve non laptop users too. > > > > Meantime, personaly, I'll try for an earlier config of my pcmcia (not via t > he > > pccard.conf method), that'll solve it for me for now, but the general probl > em > > remains I think ? > Agreed. I'm having the same problem with network mounts. The obvious > thing to do is to put it in your /etc/pccard.conf, but I can't think > of a generic way of doing things. The real problem is that the system > thinks the network is up after running network_pass1. This works in /etc/rc.local ( sleep 60 ; # cludge to allow time for ether pcmcia ep0 # card to be recognised << Cut & paste timed amd rwhod stuff from rc.network. >> ) & A guess (I haven't had time to look at src/ to check): perhaps quick dieing processes that use UDP fail, & more persistent users of TCP survive ? if so, we just need to change rc.network so network_pass2 calls network_pass2_udp & network_pass2_tcp network_pass3 calls network_pass3_udp & network_pass3_tcp pccard.conf calls again network_pass2_udp & network_pass3_udp That should not adversely affect non-laptop systems. Even if it's not a tcp/udp split, a split under another name will help. BTW Without my rc.local cludge, Of processes listed in network_pass3: I saw not running: amd rwhod I saw running: nfsd nfsiod mountd rpc.statd I have not tried: rpc.lockd kadmind natd Of processes listed in network_pass2: I saw not running: timed named I saw running: portmap I have not tried: keyserv ntpdate rpc.yppasswd rpc.ypupdated rpc.ypxfrd xntpd ypbind ypserv Julian Julian H. Stacey http://www.freebsd.org/~jhs/ Virus/ Security/ License Worries ? FreeBSD & Linux provide free sources for public scrutiny - Microsoft do not - Who should you trust today ? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-mobile" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?199906221142.LAA03063>