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@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "freebsd-hackers-unsubscr...@freebsd.org"
