Leo Weppelman wrote:
> One way that might work to get around this is the addition of a FREEWHENDONE
> flag. So the code in scsipi_execute_xs() looks like:
>         ....
>        switch (scsipi_command_direct(xs)) {
>        case SUCCESSFULLY_QUEUED:
>                 if ((xs->flags & (SCSI_NOSLEEP | SCSI_POLL)) == SCSI_NOSLEEP) {
>                      xs->flags |= SCSI_FREEWHENDONE;
>                      return (EJUSTRETURN);
>                 }
>        .....
> 
> The tail of scsipi_done() will look like:
> 
>        .....
>        if (xs->flags & SCSI_FREEWHENDONE)
>               scsipi_free_xs(xs, SCSI_NOSLEEP);
>        if (bp)
>        .....

It appears that not running scsipi_free_xs() from scsipi_done() has other
effects - i.e. the kernel doesn't boot :

	sd0(ncrscsi0:0:0); Does not support linked commands
	sd0: mode sense (4) returned nonsense: using fictitious geometry
		<machine is locked solid at this point>

This is the same result as trying to make scsipi_free_xs() conditional
on SCSI_NOSLEEP.  I tried to call scsipi_free_xs() from scsipi_execute_xs()
too, but that didn't help either :(

As the problem seems to occur when handle_message() is called between
information_transfer() and the return to scsipi_execute_xs(), is it safe
to block SCSI interrupts until the return?

J

-- 
    1024/55A5BC19        0F 3F 62 56 18 10 8B 84  43 8F F4 94 93 37 76 AA

S.E.P.