Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
>
>
> On Sun, 3 Jun 2018 23:53:40 +0300
> Konstantin Belousov wrote:
>
> > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > >
> > >
> > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > Konstantin Belousov wrote:
> > >
> > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin wrote:
> > > > >
> > > > >
> > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > Konstantin Belousov wrote:
> > > > >
> > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > wrote:
> > > > > > > Hi,
> > > > > > >
> > > > > > > After upgrading CURRENT to r333992 (from something at least
> > > > > > > a year old, quite some changes in mp_machdep.c since), this
> > > > > > > machine crashes on boot:
> > > > > > >
> > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > trademark of The FreeBSD Foundation. FreeBSD 12.0-CURRENT
> > > > > > > #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy amd64
> > > > > > > FreeBSD clang version 6.0.0 (tags/RELEASE_600/final 326565)
> > > > > > > (based on LLVM 6.0.0) WARNING: WITNESS option enabled,
> > > > > > > expect reduced performance. VT(vga): resolution 640x480
> > > > > > > CPU: Intel(R) Celeron(R) 2955U @ 1.40GHz (1396.80-MHz
> > > > > > > K8-class CPU) Origin="GenuineIntel" Id=0x40651
> > > > > > > Family=0x6 Model=0x45 Stepping=1
> > > > > > > Features=0xbfebfbff > > > > > >
> > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > Features2=0x4ddaebbf > > > > > >
> > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > >
> > > > > > > AMD Features=0x2c100800 AMD
> > > > > > > Features2=0x21 Structured Extended
> > > > > > > Features=0x2603 XSAVE
> > > > > > > Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > performance statistics real memory = 4301258752 (4102 MB)
> > > > > > > avail memory = 1907572736 (1819 MB) Event timer "LAPIC"
> > > > > > > quality 600 ACPI APIC Table:
> > > > > > What does this mean ? Did you flashed coreboot ?
> > > > >
> > > > > This machine comes with it by default (my model was delivered
> > > > > with SeaBIOS 20131018_145217-build121-m2). So I didn't flash
> > > > > anything (didn't feel like bricking it).
> > > > >
> > > > > >
> > > > > > > kernel trap 12 with interrupts disabled
> > > > > > >
> > > > > > > Fatal trap 12: page fault while in kernel mode
> > > > > > > cpuid = 0; apic id = 00
> > > > > > > fault virtual address= 0xf8000100
> > > > > > > fault code = supervisor write data, protection
> > > > > > > violation instruction pointer = 0x20:Ox8102955f
> > > > > > > stack pointer= 0x28:0x82a79be0
> > > > > > > frame pointer= 0x28:0x82a79c10
> > > > > > > code segment = base Ox0, limit Oxf, type
> > > > > > > Ox1b = DPL 0, pres 1, long 1, def32 0, gran
> > > > > > > 1 processor eflags = resume, IOPL = 0
> > > > > > > current process = 0 ()
> > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > Stopped at native_start_all_aps+0x08f: movq
> > > > > > > %rax,(%rsi)
> > > > > > Look up the source line number for this address.
> > > > > >
> > > > >
> > > > > I guess that's sys/amd64/amd64/support.S line 854 (in rdmsr),
> > > > > called by native_start_all_aps. Any additional hints how I can
> > > > > track it down?
> > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > report clearly indicates that the fault occured acessing DMAP in
> > > > native_start_all_aps().
> > > >
> > > > Just look up the source line by the address
> > > > native_start_all_aps+0x08f.
> > >
> > > Okay, according to kgbd this should be here:
> > >
> > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > >
> > > 364
> > > 365/* Create the initial 1GB replicated page tables */
> > > 366for (i = 0; i < 512; i++) {
> > > 367/* Each slot of the level 4 pages points to the same
> > > level 3 page */ 368pt4[i] =
> > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > 371/* Each slot of the level 3 pages points to the same
> > > level 2 page */ 372pt3[i] =
> > > (u_int64_t)(uintptr_t)(mptramp_pagetables + (2 * PAGE_SIZE));
> > > 373pt3[i] |= PG_V | PG_RW | PG_U; 374
> > > 375/* The level 2 page slots are ma
Re: how to deal with variable set but not used warnings?
Matthew Macy wrote: >On Sun, Jun 3, 2018 at 2:40 PM, Theron wrote: >>> 4. Disable the stupid warning in the Makefile / build system. If you don't >>> care, and there's a good reason for what you are doing (sounds like there >>> is), better to just disable the warning as so much useless noise. >>> >>> Warner >>> ___ >>> freebsd-current@freebsd.org mailing list >>> https://lists.freebsd.org/mailman/listinfo/freebsd-current >>> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >> >> Or possibly, alongside a comment as in (3), use one of these: >> 5 - Disable warning pragma - >> http://gcc.gnu.org/onlinedocs/gcc/Diagnostic-Pragmas.html >> 6 - Use __attribute__((unused)) - > https://gcc.gnu.org/onlinedocs/gcc/Common-Variable-Attributes.html#Common-Variable-Attributes > > >There is already an __unused alias for #6. It's what I've used to >annotate variables that are only used by INVARIANTS builds. It >legitimately finds a bunch of dead code. However, 90+% of the >instances of the warning are not interesting. Ok. I didn't realize that __unused would work for this case of "set but not used" but I just tried it on the older gcc48 I have lying around and it worked. (clang doesn't seem to warn or care about these cases.) I may use this, since I avoid messing with the make files like the plague. Thanks, rick ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error build nvidia-driver with r334555
On Sun, 3 Jun 2018 15:20:24 +0200
Mateusz Guzik wrote:
> On Sun, Jun 3, 2018 at 2:42 PM, Tomoaki AOKI
> wrote:
>
> > This is caused by r334533 and/or r334534 (memset-related changes).
> > sysutils/lsof is also affected.
> >
> > You should revert r334533 and r334534 temporarily until nvidia-driver
> > support this change.
> >
> > CC'ing the revision author and maintainers of both ports.
> >
> >
> Support in what sense? The error message clearly indicates a bug in the
> driver
I meant "need some work to be built with r334533 (and r334534),
including fix for newly-became-prominent bug(s), because both
x11/nvidia-driver and sysutils/lsof were built OK before r334533.
Now understood that 3rd param SHALL be the size of destination "value",
NOT the size of destination "pointer".
> (also trivially fixable). Is there a problem adding a patch to files/?
Built and worked fine. Thanks!
Fix for sysutils/lsof is already committed by Larry as r471495.
Thanks, Larry!
As x11/nvidia-driver is the master port for legacy drivers,
and legacy drivers (nvidia-driver-304 and nvidia-driver-340 ATM) has
different src directory layout, it needs some cludge in Makefile.
See attached (edited) Makefile. (Not a diff.)
And at the same time, your patch needs some fix (filename part only,
though).
Attached extra-patch-* must be copied into files/ dir.
*extra-patch-src_nvidia__subr.c is the fixed one for legacy driver.
extra-patch-src_nvidia_nvidia__subr.c contains your original patch.
Note that legacy drivers are only build-tested.
Sorry for delay!
Regards.
>
> diff -ru src.orig/nvidia/nvidia_subr.c src/nvidia/nvidia_subr.c
> --- src.orig/nvidia/nvidia_subr.c2018-06-03 13:19:56.49048 +
> +++ src/nvidia/nvidia_subr.c2018-06-03 13:21:15.289344000 +
> @@ -364,7 +364,7 @@
> }
>
> ci = args;
> -memset(ci, 0, sizeof(ci));
> +memset(ci, 0, sizeof(*ci));
>
> for (i = 0; i < NV_MAX_DEVICES; i++) {
> sc = devclass_get_softc(nvidia_devclass, i);
>
>
> As for lsof:
> --- dlsof.h.orig2018-06-03 13:16:14.712701000 +
> +++ dlsof.h2018-06-03 13:17:15.042655000 +
> @@ -489,6 +489,12 @@
> # endif/* FREEBSDV>=2020 */
>
> #undefbzero/* avoid _KERNEL conflict */
> +#undefbcmp
> +#undefbcopy
> +#undefmemcmp
> +#undefmemmove
> +#undefmemcpy
> +#undefmemset
> #include
>
> --
> Mateusz Guzik
> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
>
--
Tomoaki AOKI
Makefile
Description: Binary data
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Can't seem to use 5GHz APs with Intel wireless
On Sun, Jun 3, 2018 at 9:50 PM, Dhananjay Balan wrote: > On Sun, Jun 03, 2018 at 07:33:30PM +0200, Christoph Moench-Tegeder wrote: > > > Is the regdomain/country setting correct for your area and matches your > > AP? Especially in the 5GHz band there are some "gaps" - not all channels > > may be used in all countries (because of possible interference with > > radar equipment and other stuff). See: > > https://en.wikipedia.org/wiki/List_of_WLAN_channels#5_GHz_( > 802.11a/h/j/n/ac/ax) > > > > Thanks for taking time to explain. > > Turns out PEBKAC. I had this offending line burried in rc.conf > > create_args_wlan0="country DE regdomain FCC4" > > According to regdomain(5) > > So I was forcing my card to do 2.4Ghz it seems, removed it - everything > worked like charm. I can see and connect to 5GHz 11a aps. > > wlan0: flags=8843 metric 0 mtu > 1500 > ether > inet 192.168.1.13 netmask 0xff00 broadcast 192.168.1.255 > nd6 options=29 > media: IEEE 802.11 Wireless Ethernet MCS mode 11na > status: associated > ssid channel 36 (5180 MHz 11a ht/40+) bssid > regdomain FCC country US authmode WPA2/802.11i privacy ON > deftxkey UNDEF TKIP 2:128-bit txpower 17 bmiss 10 mcastrate 6 > mgmtrate 6 scanvalid 60 ampdulimit 64k ampdudensity 4 -amsdutx > amsdurx > shortgi -stbc -ldpc wme roaming MANUAL > > Thanks for the posting. It appears I made some errors in my previous response. I'm using an iwm, not iwn. And after your pointer I changed my country to NO which then allows me to see, but not associate to 5gz. Good yours is working. -- Adam ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
error building libpmc_events.c
Hi, During a buildworld of head on amd64, from 332518 to 334590, the build stops with: --- all_subdir_lib/libpmc --- ===> lib/libpmc (all) --- libpmc_events.c --- ./pmu-events/jevents "x86" /home/src/lib/libpmc/pmu-events/arch libpmc_events.c sh: ./pmu-events/jevents: not found *** [libpmc_events.c] Error code 127 ... TIA CBu ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
RE: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
> Hi, > > Could folks please help boot-test the most recent 12.0-CURRENT amd64 memstick > images on various hardware? Note, this is not a request to install 12.0- > CURRENT, only a boot-test with various system knobs tweaked. > > The most recent images are available at: > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img > https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img > > We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we would > like to get this included in the upcoming 11.2-RELEASE if the change that > > had been committed addresses several boot issues reported recently. > > Please help test, and report back (both successes and failures). > > Thanks, > > Glen Went well on Lenovo Thinkpad X250, Fujitsu Celsius W530 and Lenovo ThinkCentre M710s. Martin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error build nvidia-driver with r334555
On Sun, Jun 03, 2018 at 09:42:22PM +0900, Tomoaki AOKI wrote: > This is caused by r334533 and/or r334534 (memset-related changes). > sysutils/lsof is also affected. > > You should revert r334533 and r334534 temporarily until nvidia-driver > support this change. nVidia driver port was fixed as of r471574. ./danfe ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Error build nvidia-driver with r334555
Спасибо Алексей! Thank you! 05.06.2018 00:46, Alexey Dokuchaev пишет: > On Sun, Jun 03, 2018 at 09:42:22PM +0900, Tomoaki AOKI wrote: >> This is caused by r334533 and/or r334534 (memset-related changes). >> sysutils/lsof is also affected. >> >> You should revert r334533 and r334534 temporarily until nvidia-driver >> support this change. > > nVidia driver port was fixed as of r471574. > > ./danfe > -- - Alex. ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
Hi, As a driver/framework developer - no, don't do that. It's worked mostly great for the video side of things because your touch points are "the VM system" and "linuxkpi". And they're all in one big driver pull from Linux. For wifi as an example - it has a bunch of userland components, a kernel framework component (net80211); it gets API churn from people who keep making networking API changes without making them opaque (i just got bitten by the STAILQ -> CK_STAILQ changes for multicast iteration, instead of us growing a multicast iterator function thing.) Having it be multiple drivers/firmware means that anyone doing wifi development here would have to install /all/ of the relevant packages and the net80211 stuff and userland just to get any work done and hope it stays in sync. It'd be nice if that was our stretch goal, but we ain't there yet. As for your intel NIC - I'm sorry that you've had issues getting that into the tree but you can just jump in #freebsd-wifi and whine at us until we commit it. That's what we're there for. -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Call for Testing: 12.0-CURRENT amd64 memstick installer boot-testing wanted
On 05/30/2018 11:50 AM, Glen Barber wrote: Hi, Could folks please help boot-test the most recent 12.0-CURRENT amd64 memstick images on various hardware? Note, this is not a request to install 12.0-CURRENT, only a boot-test with various system knobs tweaked. The most recent images are available at: https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-mini-memstick.img https://download.freebsd.org/ftp/snapshots/amd64/amd64/ISO-IMAGES/12.0/FreeBSD-12.0-CURRENT-amd64-20180529-r334337-memstick.img We are interested in testing both UEFI and CSM/BIOS/legacy mode, as we would like to get this included in the upcoming 11.2-RELEASE if the change that had been committed addresses several boot issues reported recently. Please help test, and report back (both successes and failures). Coincidentally, I was trying to install these on a very old 10" Dell Lattitude with an Atom N550 CPU. Both images booted to the beastie menu but hung loading the kernel. The only way I could get it to boot was to manually load the kernel at the loader prompt and boot. I was also unsuccessful performing a network install due to what I think was the download filesystem being read only. I was able to install from the bundled distribution. Ian -- ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [RFC] Deprecation and removal of the drm2 driver
On Mon, Jun 4, 2018 at 12:03 PM, Adrian Chadd wrote: > Hi, > > As a driver/framework developer - no, don't do that. > > It's worked mostly great for the video side of things because your > touch points are "the VM system" and "linuxkpi". And they're all in > one big driver pull from Linux. > > For wifi as an example - it has a bunch of userland components, a > kernel framework component (net80211); it gets API churn from people > who keep making networking API changes without making them opaque (i > just got bitten by the STAILQ -> CK_STAILQ changes for multicast > iteration, instead of us growing a multicast iterator function thing.) We've had one for several years. You're just not using it. > Having it be multiple drivers/firmware means that anyone doing wifi > development here would have to install /all/ of the relevant packages > and the net80211 stuff and userland just to get any work done and hope > it stays in sync. This is the same old saw of people who can't be bothered to use ports. It is more of a headache with ABI drift but it's certainly not a fundamental impediment. -M ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Deadlocks / hangs in ZFS
Quoting Slawa Olhovchenkov (from Sun, 3 Jun 2018 22:28:14 +0300): On Sun, Jun 03, 2018 at 09:14:50PM +0200, Alexander Leidinger wrote: Quoting Alexander Leidinger (from Mon, 28 May 2018 09:02:01 +0200): > Quoting Slawa Olhovchenkov (from Mon, 28 May 2018 > 01:06:12 +0300): > >> On Sun, May 27, 2018 at 09:41:59PM +0200, Kirill Ponomarev wrote: >> >>> On 05/22, Slawa Olhovchenkov wrote: > It has been a while since I tried Karl's patch the last time, and I > stopped because it didn't apply to -current anymore at some point. > Will what is provided right now in the patch work on -current? I am mean yes, after s/vm_cnt.v_free_count/vm_free_count()/g I am don't know how to have two distinct patch (for stable and current) in one review. >>> >>> I'm experiencing these issues sporadically as well, would you mind >>> to publish this patch for fresh current? >> >> Week ago I am adopt and publish patch to fresh current and stable, is >> adopt need again? > > I applied the patch in the review yesterday to rev 333966, it > applied OK (with some fuzz). I will try to reproduce my issue with > the patch. The behavior changed (or the system was long enough in this state without me noticing it). I have a panic now: panic: deadlkres: possible deadlock detected for 0xf803766db580, blocked for 1803003 ticks Hmm, may be first determinate locked function addr2line -ie /boot/kernel/kernel 0xf803766db580 or kgdb x/10i 0xf803766db580 Both don'T produce any sensible output: (kgdb) x/10i 0xf803766db580 0xf803766db580: subb $0x80,-0x78(%rsi) 0xf803766db584: (bad) 0xf803766db585: (bad) 0xf803766db586: (bad) 0xf803766db587: incl -0x7f7792(%rax) 0xf803766db58d: (bad) 0xf803766db58e: (bad) 0xf803766db58f: incl -0x7f7792(%rax) 0xf803766db595: (bad) 0xf803766db596: (bad) Seems I need to provoke a real kernel dump instead of a textdump for this. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpt4lkMicj25.pgp Description: Digitale PGP-Signatur
Re: Fatal trap 12: page fault on Acer Chromebook 720 (peppy)
On Mon, 4 Jun 2018 14:06:55 +0300
Konstantin Belousov wrote:
> On Mon, Jun 04, 2018 at 12:46:32AM +0200, Michael Gmelin wrote:
> >
> >
> > On Sun, 3 Jun 2018 23:53:40 +0300
> > Konstantin Belousov wrote:
> >
> > > On Sun, Jun 03, 2018 at 09:50:20PM +0200, Michael Gmelin wrote:
> > > >
> > > >
> > > > On Sun, 3 Jun 2018 18:04:23 +0300
> > > > Konstantin Belousov wrote:
> > > >
> > > > > On Sun, Jun 03, 2018 at 04:55:00PM +0200, Michael Gmelin
> > > > > wrote:
> > > > > >
> > > > > >
> > > > > > On Sun, 3 Jun 2018 16:21:10 +0300
> > > > > > Konstantin Belousov wrote:
> > > > > >
> > > > > > > On Sun, Jun 03, 2018 at 02:48:40PM +0200, Michael Gmelin
> > > > > > > wrote:
> > > > > > > > Hi,
> > > > > > > >
> > > > > > > > After upgrading CURRENT to r333992 (from something at
> > > > > > > > least a year old, quite some changes in mp_machdep.c
> > > > > > > > since), this machine crashes on boot:
> > > > > > > >
> > > > > > > > Copyright (c) 1992-2018 The FreeBSD Project.
> > > > > > > > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991,
> > > > > > > > 1992, 1993, 1994 The Regents of the University of
> > > > > > > > California. All rights reserved. FreeBSD is a registered
> > > > > > > > trademark of The FreeBSD Foundation. FreeBSD
> > > > > > > > 12.0-CURRENT #1 r333992: Tue May 22 00:31:04 CEST 2018
> > > > > > > > root@flimsy:/usr/obj/usr/src/amd64.amd64/sys/flimsy
> > > > > > > > amd64 FreeBSD clang version 6.0.0
> > > > > > > > (tags/RELEASE_600/final 326565) (based on LLVM 6.0.0)
> > > > > > > > WARNING: WITNESS option enabled, expect reduced
> > > > > > > > performance. VT(vga): resolution 640x480 CPU: Intel(R)
> > > > > > > > Celeron(R) 2955U @ 1.40GHz (1396.80-MHz K8-class CPU)
> > > > > > > > Origin="GenuineIntel" Id=0x40651 Family=0x6
> > > > > > > > Model=0x45 Stepping=1
> > > > > > > > Features=0xbfebfbff > > > > > > > CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM,PBE>
> > > > > > > > Features2=0x4ddaebbf > > > > > > > xTPR,PDCM,PCID,SSE4.1,SSE4.2,MOVBE,POPCNT,TSCDLT,XSAVE,OSXSAVE,RDRAND>
> > > > > > > > AMD Features=0x2c100800
> > > > > > > > AMD Features2=0x21 Structured Extended
> > > > > > > > Features=0x2603
> > > > > > > > XSAVE Features=0x1 VT-x: (disabled in BIOS)
> > > > > > > > PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant,
> > > > > > > > performance statistics real memory = 4301258752 (4102
> > > > > > > > MB) avail memory = 1907572736 (1819 MB) Event timer
> > > > > > > > "LAPIC" quality 600 ACPI APIC Table: > > > > > > > COREBOOT>
> > > > > > > What does this mean ? Did you flashed coreboot ?
> > > > > >
> > > > > > This machine comes with it by default (my model was
> > > > > > delivered with SeaBIOS 20131018_145217-build121-m2). So I
> > > > > > didn't flash anything (didn't feel like bricking it).
> > > > > >
> > > > > > >
> > > > > > > > kernel trap 12 with interrupts disabled
> > > > > > > >
> > > > > > > > Fatal trap 12: page fault while in kernel mode
> > > > > > > > cpuid = 0; apic id = 00
> > > > > > > > fault virtual address= 0xf8000100
> > > > > > > > fault code = supervisor write data,
> > > > > > > > protection violation instruction pointer =
> > > > > > > > 0x20:Ox8102955f stack pointer=
> > > > > > > > 0x28:0x82a79be0 frame pointer=
> > > > > > > > 0x28:0x82a79c10 code segment = base
> > > > > > > > Ox0, limit Oxf, type Ox1b = DPL 0, pres 1, long 1,
> > > > > > > > def32 0, gran 1 processor eflags = resume, IOPL
> > > > > > > > = 0 current process = 0 ()
> > > > > > > > [ thread pid 0 tid 0 ]
> > > > > > > > Stopped at native_start_all_aps+0x08f: movq
> > > > > > > > %rax,(%rsi)
> > > > > > > Look up the source line number for this address.
> > > > > > >
> > > > > >
> > > > > > I guess that's sys/amd64/amd64/support.S line 854 (in
> > > > > > rdmsr), called by native_start_all_aps. Any additional
> > > > > > hints how I can track it down?
> > > > > Why did you decided that this is rdmsr_safe() ? First,
> > > > > native_start_all_aps() does not call rdmsr, second the ddb
> > > > > report clearly indicates that the fault occured acessing DMAP
> > > > > in native_start_all_aps().
> > > > >
> > > > > Just look up the source line by the address
> > > > > native_start_all_aps+0x08f.
> > > >
> > > > Okay, according to kgbd this should be here:
> > > >
> > > > https://svnweb.freebsd.org/base/head/sys/amd64/amd64/mp_machdep.c?revision=68&view=markup#l369
> > > >
> > > > 364
> > > > 365/* Create the initial 1GB replicated page tables */
> > > > 366for (i = 0; i < 512; i++) {
> > > > 367/* Each slot of the level 4 pages points to the
> > > > same level 3 page */ 368pt4[i] =
> > > > (u_int64_t)(uintptr_t)(mptramp_pagetables + PAGE_SIZE); 369
> > > > pt4[i] |= PG_V | PG_RW | PG_U; 370
> > > > 3
Re: [RFC] Deprecation and removal of the drm2 driver
Hi, If there's an API that isn't being used then great, I'll go find it and fix up pieces in my spare time to use it. But the last drive by cut/paste didn't do that; it just changed the code in place. :-) -adrian ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn commit: r334626 - in head: . . . [brk_test fails to build for aarch64 and stops build: no brk or sbrk to test, so undefined symbols]
>From ci.freebsd.org for a -r334626 + builds: --- brk_test.full --- cc -target aarch64-unknown-freebsd12.0 --sysroot=/usr/obj/usr/src/arm64.aarch64/tmp -B/usr/obj/usr/src/arm64.aarch64/tmp/usr/bin -O2 -pipe -g -std=iso9899:1999 -fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wno-pointer-sign -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable -Wno-tautological-compare -Wno-unused-value -Wno-parentheses-equality -Wno-unused-function -Wno-enum-conversion -Wno-unused-local-typedef -Wno-address-of-packed-member -Wno-switch -Wno-switch-enum -Wno-knr-promoted-parameter -Qunused-arguments -o brk_test.full brk_test.o -lprivateatf-c /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: brk >>> referenced by brk_test.c:52 (/usr/src/lib/libc/tests/sys/brk_test.c:52) >>> brk_test.o:(atfu_brk_basic_body) /usr/obj/usr/src/arm64.aarch64/tmp/usr/bin/ld: error: undefined symbol: sbrk >>> referenced by brk_test.c:55 (/usr/src/lib/libc/tests/sys/brk_test.c:55) >>> brk_test.o:(atfu_brk_basic_body) . . . (and many more) . . . === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
