cvs commit: src/sys/geom geom_disk.c

[Greg 'groggy' Lehey]

On Tuesday, 13 May 2003 at  7:27:58 +0200, Poul-Henning Kamp wrote:
> In message <20030512230725.GB28486 at wantadilla.lemis.com>, "Greg 'groggy' Lehey"
>  writes:
>>
>> --ESr4fftwSwE2Rzwi
>> Content-Type: text/plain; charset=us-ascii
>> Content-Disposition: inline
>>
>> On Monday, 12 May 2003 at 13:15:29 -0700, Poul-Henning Kamp wrote:
>>> phk         2003/05/12 13:15:29 PDT
>>>
>>>   FreeBSD src repository
>>>
>>>   Modified files:
>>>     sys/geom             geom_disk.c
>>>   Log:
>>>   When a disk disappears, destroy the class from the event thread
>>>   to avoid race condtion.
>>
>> Was this the cause of a panic while mallocing 16 bytes?
>
> I don't think so.
>
> Where is that panic reported ?

I haven't reported it yet because I was in the middle of debugging my
own mess.  Here's what happens when I remove a disk while accessing a
Vinum volume on it:

(da1:sym0:0:1:0): lost device
(da1:sym0:0:1:0): Invalidating pack
<6>vinum: miniraid.p0.s1 is crashed by force
<6>vinum: miniraid.p0 is degraded
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
<3> fatal:miniraid.p0.s1 read error, block 1902193 for 512 bytes
<3>miniraid.p0.s1: user buffer block 3803808 for 65536 bytes
<3>mytest2: fatal drive I/O error, block 1902193 for 512 bytes
<6>vinum: drive mytest2 is down
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
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
<118>May 13 17:19:23 zaphod kernel: vinum: miniraid.p0.s1 is crashed by force
<118>May 13 17:19:23 zaphod kernel: vinum: miniraid.p0 is degraded
<118>May 13 17:19:23 zaphod kernel: fatal:miniraid.p0.s1 read error, block 1902193 for 512 bytes
<118>May 13 17:19:23 zaphod kernel: miniraid.p0.s1: user buffer block 3803808 for 65536 bytes
<118>May 13 17:19:23 zaphod kernel: mytest2: fatal drive I/O error, block 1902193 for 512 bytes
<118>May 13 17:19:23 zaphod kernel: vinum: drive mytest2 is down
(da1:sym0:0:1:0): Synchronize cache failed, status == 0x5b, scsi status == 0x0
(da1:sym0:0:1:0): removing device entry
panic: final g_dev_close() with outstanding bios

After looking at it more carefully, the final panic is my problem.  I
don't know if it would have panicked otherwise.

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/4178397d/attachment.bin