On Fri, Apr 14, 2000 at 08:07:14PM +0900, enami tsugutomo wrote:
> No.  Please read the PR carefully.
> 
> >From PR #4460:
> 
> 382:    switch (scsipi_command_direct(xs)) {
> 383:    case SUCCESSFULLY_QUEUED:
> 384:            if ((xs->flags & (SCSI_NOSLEEP | SCSI_POLL)) == SCSI_NOSLEEP)
> 385:                    return (EJUSTRETURN);
> 386:#ifdef DIAGNOSTIC
> 387:            if (xs->flags & SCSI_NOSLEEP)
> 388:                    panic("scsipi_execute_xs: NOSLEEP and POLL");
> 389:#endif
> 390:            s = splbio();
> 391:            while ((xs->flags & ITSDONE) == 0)
> 392:                    tsleep(xs, PRIBIO + 1, "scsipi_cmd", 0);
> 393:            splx(s);
> 394:    case COMPLETE:          /* Polling command completed ok */
> 
> The problem described in the PR is that the value resulted by the
> evaluation of xs->flags at the line 384 is cached and used when the
> first evaluation of xs->flags at the line 391 (and tsleep function
> call occurs after it).
> 
> Note that the splbio() is not a function call on x68k/m68k
> architecture.  So, a compiler thought that it is safe to reuse the
> value at first time, but actually an interrupt handler may alter it
> (and it isn't blocked).

Ok, so the problem may be different here.

Anyway, we now have lookups in IDE code (you know what I mean :) which
appeared after I changed the way timeout()/untimeout() is used.
The machine look up solid (no debugger), just as if there was a loop at
splhigh(). I originally suspected a timing problem which would look up
the PCI bus, but this problem has now been observed on different platforms
with different controllers, which let me believe it's a software lookup.

Can we use printf() (on i386) within a splhigh() loop ? Will the text appear
immediatly on screen ?

--
Manuel Bouyer <bouyer@antioche.eu.org>
--