From owner-cvs-all Tue Apr 9 20:10:39 2002 Delivered-To: cvs-all@freebsd.org Received: from Awfulhak.org (gw.Awfulhak.org [217.204.245.18]) by hub.freebsd.org (Postfix) with ESMTP id B1CE537B400; Tue, 9 Apr 2002 20:10:28 -0700 (PDT) Received: from hak.lan.Awfulhak.org (root@hak.lan.Awfulhak.org [IPv6:fec0::1:12]) by Awfulhak.org (8.12.2/8.11.6) with ESMTP id g3A3APoi027887; Wed, 10 Apr 2002 04:10:25 +0100 (BST) (envelope-from brian@freebsd-services.com) Received: from hak.lan.Awfulhak.org (brian@localhost [127.0.0.1]) by hak.lan.Awfulhak.org (8.12.2/8.12.2) with ESMTP id g3A3ANOF006501; Wed, 10 Apr 2002 04:10:23 +0100 (BST) (envelope-from brian@freebsd-services.com) Message-Id: <200204100310.g3A3ANOF006501@hak.lan.Awfulhak.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: John Baldwin Cc: Brian Somers , cvs-committers@FreeBSD.org, cvs-all@FreeBSD.org Subject: Re: cvs commit: src/sys/kern kern_linker.c In-Reply-To: Message from John Baldwin of "Tue, 09 Apr 2002 22:48:34 EDT." Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Wed, 10 Apr 2002 04:10:23 +0100 From: Brian Somers 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. That does the trick. Thank you ! The DELAY/tsleep is required once the driver has uploaded the firmware onto the card - it needs to poll the card 'till it reports that it's initialised itself. The tsleep() calls in question were all tsleep(...., 1) with no wakeups, so it's pretty safe to use at boot time. > -- > > John Baldwin <>< http://www.FreeBSD.org/~jhb/ > "Power Users Use the Power to Serve!" - http://www.FreeBSD.org/ -- Brian http://www.freebsd-services.com/ Don't _EVER_ lose your sense of humour ! To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe cvs-all" in the body of the message