Date: Mon, 11 Apr 2011 17:22:34 -0600 From: Warner Losh <imp@bsdimp.com> To: dieterbsd@engineer.com Cc: freebsd-hackers@freebsd.org, freebsd-drivers@freebsd.org Subject: Re: Need an alternative to DELAY() Message-ID: <2BD9089E-874C-41BB-80B1-25B0DDE489C4@bsdimp.com> In-Reply-To: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com> References: <8CDC697CCCE3652-124C-1B2@web-mmc-m04.sysops.aol.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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@engineer.com wrote: >>> FreeBSD 8.2 amd64 uniprocessor >>>=20 >>> 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=3D60ms status=3D00000123 >>> kernel: siisch1: SIIS reset done: devices=3D00000001 >>> 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=3D59ms status=3D00000123 >>> ... >>> kernel: siisch0: siis_wait_ready() calling DELAY(1000) >>> last message repeated 1300 times >>> kernel: siisch0: port is not ready (timeout 10000ms) status =3D=20 > 001f2000 >>>=20 >>> Meanwhile, *everything* comes to a screeching halt. Device >>> drivers are locked out, and thus incoming data is lost. >>> Losing incoming data is unacceptable. >>>=20 >>> 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. >=20 > 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. >=20 > 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? >=20 > 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. >=20 > Redesigning the SCSI layer sounds like a job for someone who took > a lot more CS classes than I did. /dev/brain returns ENOCLUE. :-( >=20 >=20 > _______________________________________________ > freebsd-hackers@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-hackers > To unsubscribe, send any mail to = "freebsd-hackers-unsubscribe@freebsd.org" >=20 >=20
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2BD9089E-874C-41BB-80B1-25B0DDE489C4>