Date: Sun, 01 Mar 2009 20:08:00 -0800 From: Sam Leffler <sam@freebsd.org> To: "M. Warner Losh" <imp@bsdimp.com> Cc: usb@freebsd.org, yanefbsd@gmail.com, freebsd-current@freebsd.org Subject: Re: The rc.d mess strikes back Message-ID: <49AB5BA0.9070406@freebsd.org> In-Reply-To: <20090301.205017.1025328203.imp@bsdimp.com> References: <69F972E4-D7C1-47D8-8C83-A44062DB47E1@gmail.com> <6D5C9BFA-CCF4-4AEE-9688-23D66D594BC6@gmail.com> <E39D3873-3F36-467A-B225-347A088B68F9@gmail.com> <20090301.205017.1025328203.imp@bsdimp.com>
next in thread | previous in thread | raw e-mail | index | archive | help
M. Warner Losh wrote: > In message: <E39D3873-3F36-467A-B225-347A088B68F9@gmail.com> > Garrett Cooper <yanefbsd@gmail.com> writes: > : On Mar 1, 2009, at 7:36 PM, Garrett Cooper wrote: > : > : > On Mar 1, 2009, at 7:20 PM, Garrett Cooper wrote: > : > > : >> On Mar 1, 2009, at 6:36 PM, Sam Leffler wrote: > : >> > : >>> Garrett Cooper wrote: > : >>>> device ums # Mouse > : >>> > : >>> This is why you cannot kldload. Not sure about any functional > : >>> regression. > : >>> > : >>> Sam > : >> > : >> Yeah, well that message was printed out by another process > : >> altogether while loading up the kernel after the ata subsystem was > : >> brought up, so something's getting confused and trying to kldload > : >> by accident... I was just reproducing the message. > : >> I'll provide more data to prove this claim when I can. > : >> Thanks, > : >> -Garrett > : > > : > Here's the picture from my iPhone: <http://s303.photobucket.com/albums/nn159/yaneurabeya/?action=view¤t=IMG_0032.png > : > >. I OBVIOUSLY didn't do the kldload... and because my /boot/ > : > loader.conf doesn't contain ums_load="YES", I'm really curious who > : > the actual culprit is in rc.d land... > : > I used to do WITHOUT_MODULES=* to not build modules, but I'm trying > : > to move away from that mentality for some things like snd_emu10kx, > : > but obviously there's a conflict somewhere for ums; hopefully it's > : > merely cosmetic... > : > Thanks, > : > -Garrett > : > : Ok, found the culprit. It turns out moused is being called from > : devd... this is all probably related to the startup mess I reported 2 > : weeks ago with my NIC. I'm seeing a lot of additional problems in > : terms of keeping track of daemons; for instance syslogd is getting > : started up twice, but the first instance isn't recording a PID and the > : second one is dying because the first one is bound to the address. > : Agh... > > I didn't think that moused loaded anything. > > And what do extra nics have to do with this? I think you are > confusing multiple problems... > > : Could we just unwind this rc.d mess? It seems to be causing issues > : and wasn't very thoroughly tested before commit. > > This is a little to vague to be actionable. Do you have specific > instances? Do you have rcorder output? Etc... > I saw a similar problem today; if I have a wireless nic setup with ifconfig_ath0="wlan0" ifconfig_wlan0="WPA DHCP" then two instances of wpa_supplicant are launched when I do /etc/rc.d/netif start ath0 (you get log msgs from wpa_supplicant about not being able to setup the /var/run/wpa_supplicant/wlan0 unix domain socket). Wasn't able to pin it down but it's likely the same issue. Sam
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?49AB5BA0.9070406>