today's 6.1 would not boot here

[Ariff Abdullah]

On Tue, 28 Feb 2006 09:37:20 -0700
Scott Long <scottl at samsco.org> wrote:
> Scott Long wrote:
> > Ariff Abdullah wrote:
> > 
> >> On Mon, 27 Feb 2006 13:45:52 -0700
> >> Scott Long <scottl at samsco.org> wrote:
> >>
> >>> Ariff Abdullah wrote:
> >>>
> >>>> On Mon, 27 Feb 2006 12:38:26 -0700
> >>>> Scott Long <scottl at samsco.org> wrote:
> >>>>
> >>>>
> >>>>> Is this a problem with calibrating the sample rate on the
> >chip?  >>>> There  was a problem with snd_ich several years ago
> >where the >>>> calibration would fail or be unpredictable during
> >boot.  I fixed >>>
> >>>>
> >>>> it >my moving the  calibration code to a separate step that
> >gets >>> run via >the  config_intrhook API.  That made it work
> >reliably >>> during boot >and when loaded after boot.  Is this new
> >problem >>> somehow related to >this?  Since I was the one who
> >fixed it in the >>> past, I'd be happy to >help now.
> >>>>
> >>>> It seems related. From my naked eyes, I can sense that the
> >>>> interrupt was trigered during/before sampling rate calibration,
> >>>> and since the calibration expect to not trigger any interrupt,
> >>>> this will cause unexpected behaviour especially for this
> >MPSAFEed >>> driver *and* during boot. Besides, the pcm
> >construction also done >>> before the calibration, unlike
> >snd_atiixp where the hook is use to >>> bring everything alive
> >after the necessary step is finished. >>>
> >>>>
> >>>> I'll come up with something shortly.
> >>>>
> >>>
> >>> Maybe move the bus_setup_intr() call to after the calibration? 
> >If >> the driver doesn't need interrupts until after calibration, I
> >think >> that this would cleanly solve the problem.
> >>>
> >>
> >> Good idea, or, simply ignore interrupt trigger until all has been
> >> calibrated. Pretty much like this:
> >>
> >> http://people.freebsd.org/~ariff/test/ich.c
> >>
> > 
> > Yup, that looks good too.
> > 
> > Scott
> > 
> 
> Actually, I'll ammend that.  If the ich device is sharing an
> interrupt (increasingly common these days) then interrupts from
> those other devices will still cause the ich handler to run, and you
> catch that with the the calibration flag that you put in there.  But
> even though you exit right away from the handler, you still have to
> wait while the other handlers run, block on mutexes, etc.  At the
> very least this will still corrupt the calibration results.  On the
> other hand, if you don't register an interrupt handler until after
> the calibration is done and you are ready to handle interrupts, then
> you are guaranteed to avoid these problems.  Adding a critical
> section around the calibration loop would further guarantee this.
> 
Indeed. For driver requiring this type of initialization hook, moving
various pcm_addchan/AC97_CREATE *after* the calibration completed
seems reasonable too.


--
Ariff Abdullah
FreeBSD
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/freebsd-multimedia/attachments/20060301/18031f69/attachment.bin