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
[mailto:[EMAIL PROTECTED]
Sent: Tuesday, October 21, 2003 9:06 AM
To: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED]
Subject: Sleeping on "isp_mboxwaiting" with the following
non-sleepablelocks held:
This happened to me just now on alpha:
(da0:isp0:0:0:0): Retrying Comma
vm_fault: pager read error, pid 90537 (aspell)
Sleeping on "isp_mboxwaiting" with the following non-sleepablelocks held:
exclusive sleep mutex g_xdown r = 0 (0xfe0006bfdc78) locked @
/a/asami/portbuild/alpha/src-client/sys/geom/geom_io.c:345
witness_warn
Stopped at Debugger+0x3
