From owner-cvs-all Tue Apr 9 19:48:47 2002 Delivered-To: cvs-all@freebsd.org Received: from mail.speakeasy.net (mail17.speakeasy.net [216.254.0.217]) by hub.freebsd.org (Postfix) with ESMTP id AF97137B404 for ; Tue, 9 Apr 2002 19:48:39 -0700 (PDT) Received: (qmail 1256 invoked from network); 10 Apr 2002 02:48:38 -0000 Received: from unknown (HELO server.baldwin.cx) ([216.27.160.63]) (envelope-sender ) by mail17.speakeasy.net (qmail-ldap-1.03) with DES-CBC3-SHA encrypted SMTP for ; 10 Apr 2002 02:48:38 -0000 Received: from laptop.baldwin.cx (john@laptop.baldwin.cx [192.168.0.4]) by server.baldwin.cx (8.11.6/8.11.6) with ESMTP id g3A2nOv50996; Tue, 9 Apr 2002 22:49:24 -0400 (EDT) (envelope-from jhb@FreeBSD.org) Message-ID: X-Mailer: XFMail 1.5.2 on FreeBSD X-Priority: 3 (Normal) Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 8bit MIME-Version: 1.0 In-Reply-To: <200204100231.g3A2VEOF005953@hak.lan.Awfulhak.org> Date: Tue, 09 Apr 2002 22:48:34 -0400 (EDT) From: John Baldwin To: Brian Somers Subject: Re: cvs commit: src/sys/kern kern_linker.c Cc: cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Sender: owner-cvs-all@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On 10-Apr-2002 Brian Somers wrote: >> On 10-Apr-2002 Brian Somers wrote: >> >> brian 2002/04/09 18:14:45 PDT >> >> >> >> Modified files: >> >> sys/kern kern_linker.c >> >> Log: >> >> In linker_load_module(), check that rootdev != NODEV before calling >> >> linker_search_module(). >> >> >> >> Without this, modules loaded from loader.conf that then try to load >> >> in additional modules (such as digi.ko loading a card's BIOS) die >> >> badly in the vn_open() called from linker_search_module(). >> >> >> >> It may be worth checking (KASSERTing?) that rootdev != NODEV in >> >> vn_open() too. >> >> >> >> Revision Changes Path >> >> 1.88 +5 -3 src/sys/kern/kern_linker.c >> > >> > After these changes, it's possible for digi to find it's BIOS/FEPOS >> > from one of the digi_* modules at boot time - as long as that >> > digi_* module is already available (either built into the kernel or >> > ``loaded'' at boot time). However, digi fails to initialise the >> > card - I think due to tsleep failing... but I'm not sure yet. >> >> tsleep/wakeup don't work during the boot device probe. More >> specifically, interrupt handlers don't run, so you will never get woken >> up. Also, since timeouts aren't working yet the tsleep() won't timeout >> either. Thus, if you try to tsleep() during this time period, tsleep() >> will return immediately. > > Is DELAY() the only alternative ? It seems that if I DELAY(), it has > a rather noticeable effect on the machine (everything seems to lock > up 'till the DELAY()s are done). > > Maybe I should look at having the driver ``test'' tsleep and use > DELAY() instead if it doesn't work ? During boot you want to defer things that depend on interrupts until later like the ATA probe does. DELAY() will basically hang the machine, yes. You can tell if tsleep works or not by testing the 'cold' variable. If it is true, then tsleep doesn't work. -- John Baldwin <>< http://www.FreeBSD.org/~jhb/ "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message