Re: acpi panic on Dell Optiplex 760 (i82Q45 chip set)
On Sun, Nov 29, 2020 at 06:23:40PM -0600, John D. Baker wrote: > On Sun, 29 Nov 2020 17:55:41 - (UTC), chris...@astron.com (Christos > Zoulas) wrote: > > > If you have netbsd.gdb and the crash file it should be simple... > > No crashdump as it boots -current via NFS. When next the machine is > available as a test target I'll see about putting a -current GENERIC > and modules on the local disk (netbsd-9) and see if I can get one. Just netbsd.gdb would be enough to map the address from your backtrace, the address did not match my local build, could have been either hid or uid. Martin
Re: uvm_map_enter entry merging (was Re: vrelel...)
Dear Chuck, On 2020-11-29, Chuck Silvers wrote: > hi Yorick, > > On Sat, Nov 28, 2020 at 12:39:56AM +0200, Yorick Hardy wrote: > > May I ask if you have an opinion on this patch? I have > > not noticed any bad behaviour if it is omitted but, if I read > > the code correctly, I don't think it is correct to fall through > > for this case. > > this function is very hard to follow, it's very tangled. > I stared at it for a while and I didn't see anything wrong, > but it's hard to be sure just from reading the code. I am sorry to have made more work for you, and thanks for looking at it! I agree, and since I have only a superficial understanding of how everything fits together I am not 100% sure that my reading is correct. > could you explain the specific case that you think is wrong now and > that your patch fixes? I will look at the tests as suggested below. Please read/ignore this part as you see fit. Superficially (and perhaps that is part of the "not reading correctly"!) 1) if we reach http://nxr.netbsd.org/xref/src/sys/uvm/uvm_map.c#1479 then one of two things happened (with merged == 1): a) an amap was extended b) neither prev_entry nor prev_entry->next have an amap 2) now we reach https://nxr.netbsd.org/xref/src/sys/uvm/uvm_map.c#1493 and since merged == 1 in (1) https://nxr.netbsd.org/xref/src/sys/uvm/uvm_map.c#1497 UVMMAP_EVCNT_DECR(ubackmerge); UVMMAP_EVCNT_INCR(ubimerge); but in case 1(b) the forward merge never happened? That was the starting point of my query. I thought perhaps that 1(b) never happens, but a printf shows that it happens often. I am "living dangerously" and running with the patch for now, although I am not sure yet where to look for any adverse effects. > even better would be if you could write a set of atf tests to exercise > all of the possible merge cases and verify that the contents of memory > after the new mapping is created is what it should be. > any previous and next mapping should have the same contents as before, > and the new mapping should have either zeroes (for a new amap mapping) > or the uobj contents at that offset (for a new uobj mapping). I did not think I could do that, I will look into it! (Energy is low again so, when I get to it ...) > note that a vm_map_entry can reference both a uobj and an amap at the > same time, so there are 4 possible cases for the each of previous and next > entries (none, uobj, amap, uobj+amap), and two possible cases for the > new entry (uobj, amap). then I guess there are two more factors of 2 > for whether the forward and/or backward merges succeed, so that gives > at least 128 cases to test. I think there are some more cases hidden > in there because there are multiple reasons why the merges might fail > and those checks are in different places, so it would really be best > to test all of the different possible paths through this function. > > I would be reluctant to change anything here without such a set of > comprehensive tests, because even if we are sure that a change fixes > one case, it would be very hard to be sure that it doesn't break > some other case. > > -Chuck Understood, it is quite possible that I am way out of my depth! -- Kind regards, Yorick Hardy
daily CVS update output
Updating src tree: P src/lib/libc/sys/open.2 P src/share/misc/style P src/sys/arch/ofppc/conf/GENERIC P src/sys/arch/x86/x86/procfs_machdep.c P src/sys/dev/usb/uhid.c P src/sys/dev/usb/uhidev.c P src/sys/dev/usb/uhidev.h P src/usr.bin/make/config.h P src/usr.bin/make/dir.c P src/usr.bin/make/dir.h P src/usr.bin/make/hash.h P src/usr.bin/make/job.c P src/usr.bin/make/job.h P src/usr.bin/make/make.h P src/usr.bin/make/meta.c P src/usr.bin/make/pathnames.h P src/usr.bin/make/test-variants.sh P src/usr.bin/make/filemon/filemon.h P src/usr.bin/make/filemon/filemon_dev.c P src/usr.bin/make/filemon/filemon_ktrace.c P src/usr.bin/make/unit-tests/Makefile Updating xsrc tree: Killing core files: Updating release-8 src tree (netbsd-8): U doc/CHANGES-8.3 P include/arpa/nameser_compat.h P lib/libc/net/getaddrinfo.c P lib/libc/net/gethnamaddr.c Updating release-8 xsrc tree (netbsd-8): Updating release-9 src tree (netbsd-9): U doc/CHANGES-9.2 P external/cddl/osnet/dist/uts/common/fs/zfs/vdev_disk.c P include/arpa/nameser_compat.h P lib/libc/net/getaddrinfo.c P lib/libc/net/gethnamaddr.c P sys/external/bsd/drm2/dist/drm/i915/intel_sprite.c P usr.sbin/sysinst/arch/evbarm/md.c Updating release-9 xsrc tree (netbsd-9): Updating file list: -rw-rw-r-- 1 srcmastr netbsd 38631428 Nov 30 03:11 ls-lRA.gz
Re: acpi panic on Dell Optiplex 760 (i82Q45 chip set)
On Sun, 29 Nov 2020 17:55:41 - (UTC), chris...@astron.com (Christos Zoulas) wrote: > If you have netbsd.gdb and the crash file it should be simple... No crashdump as it boots -current via NFS. When next the machine is available as a test target I'll see about putting a -current GENERIC and modules on the local disk (netbsd-9) and see if I can get one. -- |/"\ John D. Baker, KN5UKS NetBSD Darwin/MacOS X |\ / jdbaker[snail]consolidated[flyspeck]net OpenBSDFreeBSD | X No HTML/proprietary data in email. BSD just sits there and works! |/ \ GPGkeyID: D703 4A7E 479F 63F8 D3F4 BD99 9572 8F23 E4AD 1645
Re: uvm_map_enter entry merging (was Re: vrelel...)
hi Yorick,
On Sat, Nov 28, 2020 at 12:39:56AM +0200, Yorick Hardy wrote:
> May I ask if you have an opinion on this patch? I have
> not noticed any bad behaviour if it is omitted but, if I read
> the code correctly, I don't think it is correct to fall through
> for this case.
this function is very hard to follow, it's very tangled.
I stared at it for a while and I didn't see anything wrong,
but it's hard to be sure just from reading the code.
could you explain the specific case that you think is wrong now and
that your patch fixes?
even better would be if you could write a set of atf tests to exercise
all of the possible merge cases and verify that the contents of memory
after the new mapping is created is what it should be.
any previous and next mapping should have the same contents as before,
and the new mapping should have either zeroes (for a new amap mapping)
or the uobj contents at that offset (for a new uobj mapping).
note that a vm_map_entry can reference both a uobj and an amap at the
same time, so there are 4 possible cases for the each of previous and next
entries (none, uobj, amap, uobj+amap), and two possible cases for the
new entry (uobj, amap). then I guess there are two more factors of 2
for whether the forward and/or backward merges succeed, so that gives
at least 128 cases to test. I think there are some more cases hidden
in there because there are multiple reasons why the merges might fail
and those checks are in different places, so it would really be best
to test all of the different possible paths through this function.
I would be reluctant to change anything here without such a set of
comprehensive tests, because even if we are sure that a change fixes
one case, it would be very hard to be sure that it doesn't break
some other case.
-Chuck
> --
> Kind regards,
>
> Yorick Hardy
>
> Index: uvm_map.c
> ===
> RCS file: /cvsroot/src/sys/uvm/uvm_map.c,v
> retrieving revision 1.385
> diff -u -r1.385 uvm_map.c
> --- uvm_map.c 9 Jul 2020 05:57:15 - 1.385
> +++ uvm_map.c 19 Nov 2020 16:04:07 -
> @@ -1477,6 +1477,13 @@
> amapwaitflag | AMAP_EXTEND_BACKWARDS))
> goto nomerge;
> }
> +
> + /*
> + * We could not extend either amap, just skip on.
> + */
> + else {
> + goto nomerge;
> + }
> } else {
> /*
>* Pull the next entry's amap backwards to cover this
Re: acpi panic on Dell Optiplex 760 (i82Q45 chip set)
In article ,
John D. Baker wrote:
>After updating to the latest -current (9.99.76) with the recent ACPI
>subsystem update, my Dell Optiplex 760 panics attaching acpi0:
Something is overwriting allocated memory. Can you find which free does
this?
Cleanup:
if (Hid)
{
ACPI_FREE (Hid);
}
if (Uid)
{
ACPI_FREE (Uid);
}
if (CidList)
{
ACPI_FREE (CidList);
}
if (Cls)
{
ACPI_FREE (Cls);
}
If you have netbsd.gdb and the crash file it should be simple...
christos
