Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 10 May 2002 23:03:36 -0400 (EDT)
From:      John Baldwin <jhb@FreeBSD.org>
To:        Brian Somers <brian@Awfulhak.org>
Cc:        cvs-all@FreeBSD.org, cvs-committers@FreeBSD.org, Joerg Wunsch <joerg@FreeBSD.org>
Subject:   Re: cvs commit: src/sys/isa fd.c fdreg.h
Message-ID:  <XFMail.20020510230336.jhb@FreeBSD.org>
In-Reply-To: <200205110256.g4B2uNnA008926@hak.lan.Awfulhak.org>

next in thread | previous in thread | raw e-mail | index | archive | help

On 11-May-2002 Brian Somers wrote:
>> 
>> On 11-May-2002 Brian Somers wrote:
>> >> 
>> >> On 11-May-2002 Brian Somers wrote:
>> >> >> joerg       2002/05/10 10:56:39 PDT
>> >> >> 
>> >> >>   Modified files:
>> >> >>     sys/isa              fd.c fdreg.h 
>> >> >>   Log:
>> >> >>   Change the PIO loops from a hard counter into a loop that calls
>> >> >>   DELAY()
>> >> >>   in each cycle, with a tunable max cycle count defined in fdreg.h.
>> >> >>   
>> >> >>   This is said to fix the problem on some Compaq hardware (and perhaps
>> >> >>   on other machines using the Natsemi PC87317 chip) where the fdc(4)
>> >> >>   driver failed to operate at all.
>> >> >>   
>> >> >>   PR:             kern/21397
>> >> >>   Submitted by:   Jung-uk Kim <jkim@niksun.com>
>> >> >>   MFC after:      3 days
>> >> >>   
>> >> >>   Revision  Changes    Path
>> >> >>   1.229     +14 -8     src/sys/isa/fd.c
>> >> >>   1.16      +12 -0     src/sys/isa/fdreg.h
>> >> > 
>> >> > As fdc is also a module, would it be better to call tsleep() instead 
>> >> > of delay if (!cold) ?  Like in sys/dev/digi/digi.c:digi_delay()...
>> >> 
>> >> Hmm, we should come up with the real fix for this quick so as to avoid
>> >> propagating that hack any farther than we have to. :-/  (Not picking on
>> >> you Brian).
>> > 
>> > Yes.
>> > 
>> > NetBSD has an MD delay() function in sys/arch/*/{,*/}clock.c, 
>> > prototyped in sys/arch/*/include/cpu.h.  I guess I could have a go at 
>> > bringing that into FreeBSD.
>> 
>> No, the real fix is to redo device probing so it's always done in the
>> same environment.  IOW, you would always use tsleep() and never use
>> DELAY().
> 
> Well, the environment can't be the same - there's no filesystem yet 
> during the boot time probe for example (and there can't be if we 
> expect to be able to load the filesystem driver as a module).

For the most part kernel modules don't go out dinking around in userland,
so most of them don't care about stuff like this. :)  What I meant is more
that things like interrupts and timeouts are always enabled.

> However, I agree that it'd be nice to have interrupts before any 
> probes occur.  Are you suggesting that the contents of configure() 
> in autoconf.c should be re-arranged so that the spl0() happens before 
> root_bus_configure() ?  I suspect it's not that easy ;*)

You have to do multiple passes.  On the first pass you probe things like
clocks, interrupt controllers, bridges, etc.  Then you can turn on
interrupts and timeouts so scheduling works.  Finally, you go through and
do a second pass where you probe everything else.

-- 

John Baldwin <jhb@FreeBSD.org>  <><  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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?XFMail.20020510230336.jhb>