Re: HEADS UP: Merging drm update

[Taylor R Campbell <riastradh%NetBSD.org@localhost>]

> Date: Wed, 22 Dec 2021 18:58:51 +0000
> From: Taylor R Campbell <riastradh%NetBSD.org@localhost>
> 
> > Date: Thu, 23 Dec 2021 00:57:13 +0900
> > From: Ryo ONODERA <ryo%tetera.org@localhost>
> > 
> > Ryo ONODERA <ryo%tetera.org@localhost> writes:
> > 
> > > I have no useful information or thought yet…
> > >
> > > I have added check for BADADDR+OPREGION_SIZE in bus_space_reserve.
> > > And I have found that no one uses that address.
> > 
> > I have added similar logic to extent_alloc_region() and
> > extent_insert_and_optimize(). And I have found that someone
> > reserves 0x6375c000 to 0x63f3ffff.
> > However I cannot find who reserves this range.
> > i915drmkms wants 0x63ec5018 to 0x63ec7017 and this is overlapped
> > with 0x6375c000 to 0x63f3ffff.
> 
> Can you use db_stacktrace() in extent_alloc_region and
> extent_insert_and_optimize when the region covers that address?  That
> might help narrow it down.

Can you make it stop panicking here, but still print the messages and
get the dmesg at the end?  (If you need to make it panic to get the
dmesg, maybe make it panic in drmfb_attach?)  It may be that i915
tries to map it twice but we didn't notice because we were looking for
any other driver before i915.