cvs commit: src/sys/geom geom_disk.c

[Greg 'groggy' Lehey]

On Wednesday, 14 May 2003 at 13:37:59 +0200, Poul-Henning Kamp wrote:
> In message <20030514081041.GD4390 at wantadilla.lemis.com>, "Greg 'groggy' Lehey"
> writes:
>
>> malloc() of "16" with the following non-sleepablelocks held:
>> exclusive sleep mutex g_xup r = 0 (0xc8612ca8) locked @ /src/FreeBSD/5-CURRENT-ZAPHOD/src/sys/geom/geom_io.c:363
>
> This is a problem, you cannot sleep in the primary I/O path (ie: strategy()
> and done()), if you sleep in the I/O path, you stop all I/O processing
> and if the system needs to page something out to make the ram available
> to you, you have a deadlock.

I wasn't sleeping.  This happened elsewhere as the result of a drive
going away.  I had expected that the panic stack trace would point me
at it, but it didn't.  I'll investigate further when I've fixed the
current panic.

>> panic: final g_dev_close() with outstanding bios
>
> This means that close was called before all the I/O requests had
> been delivered, this is not allowed.

Correct.

> You have to stop sending I/Os, wait for the ones you have sent to
> come back, then you can close.

They won't complete if the drive has gone away.  I had this solved
before with a call to vinvalbuf(), but the new code is calling the
hardware drivers ) directly rather than the vnode operations.  This
sounds like a mistake to me, unless you can see a good reason for it.

Greg
--
See complete headers for address and phone numbers
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
Url : http://lists.freebsd.org/pipermail/cvs-src/attachments/20030514/17978e11/attachment.bin