Need an alternative to DELAY()

[Warner Losh]

I don't suppose that your driver could cause the hardware to interrupt after a little time?  That would be more resource friendly...  Otherwise, 1ms is long enough that a msleep or tsleep would likely work quite nicely.

Warner

On Apr 11, 2011, at 1:43 PM, dieterbsd at engineer.com wrote:

>>> FreeBSD 8.2  amd64  uniprocessor
>>> 
>>> kernel: siisch1: DISCONNECT requested
>>> kernel: siisch1: SIIS reset...
>>> kernel: siisch1: siis_sata_connect() calling DELAY(1000)
>>> last message repeated 59 times
>>> kernel: siisch1: SATA connect time=60ms status=00000123
>>> kernel: siisch1: SIIS reset done: devices=00000001
>>> kernel: siisch1: DISCONNECT requested
>>> kernel: siisch1: SIIS reset...
>>> kernel: siisch1: siis_sata_connect() calling DELAY(1000)
>>> last message repeated 58 times
>>> kernel: siisch1: SATA connect time=59ms status=00000123
>>> ...
>>> kernel: siisch0: siis_wait_ready() calling DELAY(1000)
>>> last message repeated 1300 times
>>> kernel: siisch0: port is not ready (timeout 10000ms) status = 
> 001f2000
>>> 
>>> Meanwhile, *everything* comes to a screeching halt.  Device
>>> drivers are locked out, and thus incoming data is lost.
>>> Losing incoming data is unacceptable.
>>> 
>>> Need an alternative to DELAY() that does not lock out
>>> other device drivers.  There must be a way to reset one
>>> bit of hardware without locking down the entire machine.
> 
> Hans Petter Selasky writes:
>> An alternative to DELAY() is the simplest solution. You probably need
>> to do some redesign in the SCSI layer to find a better solution.
> 
> I keep coming back to the idea that a device driver for one
> controller should not have to lock out *all* the hardware.
> RS-232 locks out Ethernet.  Disk drivers lock out Ethernet.
> And so on.  Why?  Is there some fundamental reason that this
> *has* to be?  I thought the conversion from spl() to mutex()
> was supposed to fix this?
> 
> I'm making progress on my project converting printf(9) calls
> to log(9), and fixing some bugs along the way.  Eventually I'll
> have patches to submit.  But this is really a workaround, not
> a fix to the underlying problem.
> 
> Redesigning the SCSI layer sounds like a job for someone who took
> a lot more CS classes than I did.  /dev/brain returns ENOCLUE.  :-(
> 
> 
> _______________________________________________
> freebsd-hackers at freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
> To unsubscribe, send any mail to "freebsd-hackers-unsubscribe at freebsd.org"
> 
>