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, -GarrettReceived on Mon Mar 02 2009 - 02:41:26 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:39:43 UTC
