Skip site navigation (1)Skip section navigation (2)
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>