In message <[EMAIL PROTECTED]>, Matthew Jacob writes:
>[1]: by 'sleep', I mean if I do *my* locking right, I should be able to
>yield the processor and wait for an event (an interrupt in this case).
Not so when your device driver is entered through the devsw->strategy()
function, since that [cw]o
In message <[EMAIL PROTECTED]>, "Matthew Jacob" writes:
>Well, I don't agree with the design here, but it is what it is. I'll
>make the change that you've added a requirement for.
This is nothing new, but it is new that we can and do enforce it.
--
Poul-Henning Kamp | UNIX since Zilog Ze
On Tue, Oct 21, 2003 at 02:30:21PM -0700, Matthew Jacob wrote:
> So? How about some details and context?
Um, what more "details and context" do you need? I provided the log
of the system activity (specifically, media errors and swap read
failure) leading up to the panic, and the ddb backtrace.
>
is Kennaway'; [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Re: Sleeping on "isp_mboxwaiting" with the following
non-sleepablelocks held:
In message <[EMAIL PROTECTED]>, "Matthew Jacob"
writes:
>So? How about some details and context?
>
>I thought was told that
In message <[EMAIL PROTECTED]>, "Matthew Jacob" writes:
>So? How about some details and context?
>
>I thought was told that being able to use locks in HBAs is fine. I had
>them on for a while, and then had them off. I turned them on again over
>a month ago. I'm somewhat surprised to see that a prob
So? How about some details and context?
I thought was told that being able to use locks in HBAs is fine. I had
them on for a while, and then had them off. I turned them on again over
a month ago. I'm somewhat surprised to see that a problem shows up now.
*I* do the right thing with locks, IMO. I
