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...
Could we just unwind this rc.d mess? It seems to be causing issues
and wasn't very thoroughly tested before commit.
Thanks,
-Garrett
_______________________________________________
freebsd-usb@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-usb
To unsubscribe, send any mail to "freebsd-usb-unsubscr...@freebsd.org"
