The rc.d mess strikes back (was Re: ums no longer loads on CURRENT)

Garrett Cooper yanefbsd at
Sun Mar 1 19:41:27 PST 2009

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: < 
> >. 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.  
	Could we just unwind this rc.d mess? It seems to be causing issues  
and wasn't very thoroughly tested before commit.

More information about the freebsd-usb mailing list