Need an alternative to DELAY()
Warner Losh
imp at bsdimp.com
Mon Apr 11 23:27:38 UTC 2011
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"
>
>
More information about the freebsd-hackers
mailing list