The rc.d mess strikes back

[M. Warner Losh]

In message: <E39D3873-3F36-467A-B225-347A088B68F9 at gmail.com>
            Garrett Cooper <yanefbsd at 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&current=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...

Warner