Date: Wed, 26 Feb 2014 11:05:41 +0400 From: Lev Serebryakov <lev@FreeBSD.org> To: Alexander Motin <mav@FreeBSD.org> Cc: freebsd-geom@freebsd.org Subject: Re: 3rd party geom module on 10-STABLE cause panics in biodone() Message-ID: <202114262.20140226110541@serebryakov.spb.ru> In-Reply-To: <530D1640.3050104@FreeBSD.org> References: <585146922.20140226020105@serebryakov.spb.ru> <530D1640.3050104@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Hello, Alexander.
You wrote 26 =F4=E5=E2=F0=E0=EB=FF 2014 =E3., 2:16:32:
>> 3561 if ((bp->bio_flags & BIO_TRANSIENT_MAPPING) !=3D 0) {
>> 3562 bp->bio_flags &=3D ~BIO_TRANSIENT_MAPPING;
>> 3563 bp->bio_flags |=3D BIO_UNMAPPED;
>> 3564 start =3D trunc_page((vm_offset_t)bp->bio_data);
>> 3565 end =3D round_page((vm_offset_t)bp->bio_data + bp->bio_length);
>> 3566 pmap_qremove(start, OFF_TO_IDX(end - start));
>> 3567 vmem_free(transient_arena, start, end - start);
>> 3568 atomic_add_int(&inflight_transient_maps, -1);
>> 3569 }
>>
>> And these crashes are very bad: 9 of 10 times system could not make
>> crashdump or reboot and 8 out of 10 times it shuts down video output (!).
>>
>> I was lucky to get one crashdump to find this line...
>>
>> What could I do wrong in my module?
AM> IIRC I had problem with that part of code during my GEOM direct dispatch
AM> work when some requests were unmapped twice. At that time I've added=20
AM> restoring the flags at lines 3562-3563, and it helped in my case. Make=
=20
AM> sure that you are not have some unexpected requests reuse, etc, that ma=
y=20
AM> cause incorrect combination of BIO flags and addresses.
It is impossible to debug this on real hardware and now I'm trying to
reproduce this on VirtualBox. My plan is to print out EVERY bio which is
freed here and every processed bio in my module and to find exact path of
failing bio though my module...
--=20
// Black Lion AKA Lev Serebryakov <lev@FreeBSD.org>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?202114262.20140226110541>