From owner-freebsd-usb@FreeBSD.ORG Mon Mar 2 04:02:14 2009 Return-Path: Delivered-To: usb@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:4f8:fff6::34]) by hub.freebsd.org (Postfix) with ESMTP id B3BFE10656EE; Mon, 2 Mar 2009 04:02:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from mxout5.cac.washington.edu (mxout5.cac.washington.edu [140.142.32.135]) by mx1.freebsd.org (Postfix) with ESMTP id 87F598FC0A; Mon, 2 Mar 2009 04:02:14 +0000 (UTC) (envelope-from yanefbsd@gmail.com) Received: from smtp.washington.edu (smtp.washington.edu [140.142.32.139]) by mxout5.cac.washington.edu (8.14.3+UW08.09/8.14.3+UW09.01) with ESMTP id n2242C9M006976 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sun, 1 Mar 2009 20:02:12 -0800 X-Auth-Received: from [192.168.10.7] (adsl-99-147-148-174.dsl.pltn13.sbcglobal.net [99.147.148.174]) (authenticated authid=youshi10) by smtp.washington.edu (8.14.3+UW08.09/8.14.3+UW09.01) with ESMTP id n2242B7M029121 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NOT); Sun, 1 Mar 2009 20:02:12 -0800 Message-Id: <2E9BD549-EF77-4F48-AB7E-C93AFC4BE387@gmail.com> From: Garrett Cooper To: "M. Warner Losh" In-Reply-To: <20090301.205017.1025328203.imp@bsdimp.com> Content-Type: text/plain; charset=US-ASCII; format=flowed; delsp=yes Content-Transfer-Encoding: 7bit Mime-Version: 1.0 (Apple Message framework v930.3) Date: Sun, 1 Mar 2009 20:07:46 -0800 References: <69F972E4-D7C1-47D8-8C83-A44062DB47E1@gmail.com> <6D5C9BFA-CCF4-4AEE-9688-23D66D594BC6@gmail.com> <20090301.205017.1025328203.imp@bsdimp.com> X-Mailer: Apple Mail (2.930.3) X-PMX-Version: 5.5.0.356843, Antispam-Engine: 2.6.1.350677, Antispam-Data: 2009.3.2.35224 X-Uwash-Spam: Gauge=IIIIIII, Probability=8%, Report='FORGED_FROM_GMAIL 0.1, BODY_SIZE_3000_3999 0, BODY_SIZE_5000_LESS 0, BODY_SIZE_7000_LESS 0, LINK_TO_IMAGE 0, __BOUNCE_CHALLENGE_SUBJ 0, __CP_URI_IN_BODY 0, __CT 0, __CTE 0, __CT_TEXT_PLAIN 0, __FRAUD_419_BODY_WEBMAIL 0, __FRAUD_419_WEBMAIL 0, __FRAUD_419_WEBMAIL_FROM 0, __FROM_GMAIL 0, __HAS_MSGID 0, __HAS_X_MAILER 0, __MIME_TEXT_ONLY 0, __MIME_VERSION 0, __SANE_MSGID 0' Cc: usb@freebsd.org, freebsd-current@freebsd.org Subject: Re: The rc.d mess strikes back X-BeenThere: freebsd-usb@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: FreeBSD support for USB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 02 Mar 2009 04:02:15 -0000 On Mar 1, 2009, at 7:50 PM, M. Warner Losh wrote: > In message: > Garrett Cooper 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: : > >. 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 For whatever reason the NFS filemounts not coming up forces rc.d to restart from a square one (because it enters maintenance mode), which nukes PID files in /var/run (I'm assuming) via the cleanvar service, and causes devd and syslogd to be started twice, which in turn causes that message to be printed out on the console. devd's rc script is just smart enough to recognize that there's a PID already running on the system, and thus it doesn't try to start more than once, but syslogd's is braindead (is there really a point to running multiple instances of syslogd?) and thus it tries to start up the service twice. I'm understand why devd attempts to probe and install ums in the kernel's namespace if it already exists... but I'm unhappy with the fact that even though I set moused_enable=NO in rc.conf, moused still doesn't honor that option ;(... -Garrett