Re: Reproducable deadlock in NFS client
On 2019-Oct-03 23:28:07 +, Rick Macklem wrote: >1 - kib@ just put a patch up on phabricator that reorganizes the handling > of vnode_pager_setsize(). > D21883 > (If you could test this patch, that might be the best approach.) That fixes my problem. I've added a note to D21883 >ps: Btw, capturing "procstat -kk" and "ps axHl" would give you/us more info. > (The "H" on "ps" shows the iod threads.) > If you can drop into the debugger when it is hung as above, you could > capture the stuff listed here: >https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html Thanks for the pointer and sorry for leaving that out. -- Peter Jeremy signature.asc Description: PGP signature
Re: AMD Secure Encrypted Virtualization - FreeBSD Status?
>> Just whose secure keys do you suggest? I go to a lot of trouble to disable >> secure boot so I can load any operating system I want. Some motherboards have BIOS that allows you to both - Upload your own keys - Delete all the spooky Microsoft keys Read the UEFI Secure Boot specification document. Then paste all the key management specs into a ticket with your motherboard vendor and get on them to publish a BIOS release that has proper key management functions. Some BIOS makers have this as selectable options in their BIOS reference build routines... ie: the motherboard maker doesn't have to write any code, they just point and click, and the option appears in a BIOS release for mobo end user customers. Sometimes you have to bug and escalate the mobo makers and threaten to walk your next purchase to another mobo maker to get them to cut and post the new BIOS release. https://www.uefi.org/ https://uefi.org/learning_center/papers https://uefi.org/specsandtesttools https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf https://uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_2019.pdf > The goal would be not to disable secure boot and have FreeBSD running > with a secured bootloader :-) > > At the moment we have insecure boot + insecure kernel + possible > encrypted data partition.. > would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-) Yes. ___ 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: Reproducable deadlock in NFS client
Hi Peter, You could try a couple of things: 1 - kib@ just put a patch up on phabricator that reorganizes the handling of vnode_pager_setsize(). D21883 (If you could test this patch, that might be the best approach.) or 2 - The only differences between the post r352392 code and the older stuff is that it calls vnode_pager_setsize() when the size hasn't changed. I can't think of why that might cause a problem, but?? I have a patch in phabricator D21814 that doesn't do the vnode_pager_setsize() call when the size doesn't change. --> If this patch were to avoid the hang, it could help diagnose the problem. The other difference is that it called vnode_pager_setsize() when there was a small change, but not enough to affect a page boundary. I can't think of how this would affect things either, but.. or If you can't test either of the above patches, you could try reverting both r352393 and r352457, which would put things back the way they've been for years, to see if that works ok. Good luck with it, rick ps: Btw, capturing "procstat -kk" and "ps axHl" would give you/us more info. (The "H" on "ps" shows the iod threads.) If you can drop into the debugger when it is hung as above, you could capture the stuff listed here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 11:52:38PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 22:26, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > >> > >> If you leave the port debug knob for drm-current-kmod AS-IS, I think you > >> can get away with: > >> > >> make DEBUG_FLAGS="-g" > >> > >> Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > >> symbol files for the modules loaded. Then get the backtrace using bt > >> command. > >> > >> BTW: Did you try drm-devel-kmod for 13-current? > >> > > > > Took a bit of trial and error. If I skip the panic > > and trap frames (#0 through #8). I find the backtrace > > that follows by sig. If I move to frame #11, I see > > > > (kgdb) frame 11 > > #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) > > at > > /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 > > 4114writel(reg, ((void __iomem *)rdev->rmmio) + > > RADEON_MM_INDEX); > > (kgdb) p rdev->rmmio > > $3 = (void *) 0x0 > > > > So, your guess of a NULL pointer seems correct. > > Can you do: > > set print pretty on > print *rdev > Left work for the day. I'll get this info first thing tomorrow morning. -- Steve ___ 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: radeon panics kernels
On 2019-10-03 22:26, Steve Kargl wrote: On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: If you leave the port debug knob for drm-current-kmod AS-IS, I think you can get away with: make DEBUG_FLAGS="-g" Then re-load the vmcore file in GDB/KGDB from ports (!) and add the symbol files for the modules loaded. Then get the backtrace using bt command. BTW: Did you try drm-devel-kmod for 13-current? Took a bit of trial and error. If I skip the panic and trap frames (#0 through #8). I find the backtrace that follows by sig. If I move to frame #11, I see (kgdb) frame 11 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 4114writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); (kgdb) p rdev->rmmio $3 = (void *) 0x0 So, your guess of a NULL pointer seems correct. Can you do: set print pretty on print *rdev --HPS ___ 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"
Reproduceable deadlock in NFS Client
My diskless Rock64 has taken to deadlocking reproduceably whilst building libprivatesqlite3.a as part of buildworld when running r352792. At the time of the deadlock, the relevant running process is: ar -crD libprivatesqlite3.a sqlite3.o And those files are: -rw-r--r--1 root wheel 3178496 4 Oct 01:10 libprivatesqlite3.a -rw-r--r--1 root wheel 7975272 4 Oct 01:10 sqlite3.o The "ar" reports it's in bo_wwait and, after about 30 minutes, I get: deadlres_td_sleep_q: possible deadlock detected for 0xfd00012c9560, blocked for 1800613 ticks cpuid = 2 time = 1570117920 KDB: stack backtrace: db_trace_self() at db_trace_self_wrapper+0x28 pc = 0x0054b83c lr = 0x000e2b08 sp = 0x4030a790 fp = 0x4030a9a0 db_trace_self_wrapper() at vpanic+0x18c pc = 0x000e2b08 lr = 0x0027fb54 sp = 0x4030a9b0 fp = 0x4030aa50 vpanic() at panic+0x44 pc = 0x0027fb54 lr = 0x0027f904 sp = 0x4030aa60 fp = 0x4030aae0 panic() at deadlkres+0x33c pc = 0x0027f904 lr = 0x0021c19c sp = 0x4030aaf0 fp = 0x4030ab50 deadlkres() at fork_exit+0x7c pc = 0x0021c19c lr = 0x002404f4 sp = 0x4030ab60 fp = 0x4030ab90 fork_exit() at fork_trampoline+0x10 pc = 0x002404f4 lr = 0x0056743c sp = 0x4030aba0 fp = 0x -- Peter Jeremy signature.asc Description: PGP signature
Re: AMD Secure Encrypted Virtualization - FreeBSD Status?
On Thu, Oct 3, 2019 at 10:29 PM Clay Daniels Jr. wrote: > Just whose secure keys do you suggest? I go to a lot of trouble to disable > secure boot so I can load any operating system I want. The goal would be not to disable secure boot and have FreeBSD running with a secured bootloader :-) At the moment we have insecure boot + insecure kernel + possible encrypted data partition.. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: AMD Secure Encrypted Virtualization - FreeBSD Status?
Just whose secure keys do you suggest? I go to a lot of trouble to disable secure boot so I can load any operating system I want. On Thu, Oct 3, 2019 at 11:10 AM Tomasz CEDRO wrote: > would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-) > > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > ___ > 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" > ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > > If you leave the port debug knob for drm-current-kmod AS-IS, I think you > can get away with: > > make DEBUG_FLAGS="-g" > > Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > symbol files for the modules loaded. Then get the backtrace using bt > command. > > BTW: Did you try drm-devel-kmod for 13-current? > Took a bit of trial and error. If I skip the panic and trap frames (#0 through #8). I find the backtrace that follows by sig. If I move to frame #11, I see (kgdb) frame 11 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at /usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c:4114 4114writel(reg, ((void __iomem *)rdev->rmmio) + RADEON_MM_INDEX); (kgdb) p rdev->rmmio $3 = (void *) 0x0 So, your guess of a NULL pointer seems correct. -- Steve #9 __raw_writel (v=1932408418, addr=) at /usr/src/sys/compat/linuxkpi/common/include/linux/io.h:111 #10 writel (v=1932408418, addr=) at /usr/src/sys/compat/linuxkpi/common/include/linux/io.h:199 #11 r100_mm_rreg_slow (rdev=0xf80135766a70, reg=) at PATH/drivers/gpu/drm/radeon/r100.c:4114 #12 0x817ba613 in r100_mm_rreg (rdev=, reg=, always_indirect=false) at PATH/drivers/gpu/drm/radeon/radeon.h:2481 #13 radeon_fence_read (rdev=, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:95 #14 radeon_fence_activity (rdev=0xf80135766a70, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:229 #15 0x817ba6e9 in radeon_fence_process (rdev=0xf80135766a70, ring=0) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:324 #16 radeon_fence_seq_signaled (rdev=, seq=, ring=) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:349 #17 radeon_fence_signaled (fence=0xf801f7a62700) at PATH/drivers/gpu/drm/radeon/radeon_fence.c:438 #18 0x817d2601 in radeon_sa_bo_try_free (sa_manager=) at PATH/drivers/gpu/drm/radeon/radeon_sa.c:163 #19 radeon_sa_bo_new (rdev=0xfe00b07fc000, sa_manager=0xfe00b07fdf18, sa_bo=0xfe00b4380450, size=11168, align=256) at PATH/drivers/gpu/drm/radeon/radeon_sa.c:341 #20 0x817c1a4f in radeon_ib_get (rdev=0xfe00b07fc000, ring=0, ib=0xfe00b4380450, vm=0x0, size=0) at PATH/drivers/gpu/drm/radeon/radeon_ib.c:61 #21 0x817ad6ed in radeon_cs_ib_fill (rdev=, parser=) at PATH/drivers/gpu/drm/radeon/radeon_cs.c:640 #22 radeon_cs_ioctl (dev=, data=, filp=) at PATH/drivers/gpu/drm/radeon/radeon_cs.c:687 #23 0x818a82f5 in drm_ioctl_kernel (linux_file=, func=0x817ad490 , kdata=0xfe00b43806c0, flags=33) at PATH/drivers/gpu/drm/drm_ioctl.c:760 #24 0x818a858a in drm_ioctl (filp=0xf8001ba48e00, cmd=, arg=65536) at PATH/drivers/gpu/drm/drm_ioctl.c:856 #25 0x807cf568 in linux_file_ioctl_sub (fp=, filp=, fop=, cmd=, data=0x0, td=) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965 #26 linux_file_ioctl (fp=, cmd=, data=, cred=, td=) at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558 #27 0x80643694 in fo_ioctl (fp=, com=3223348326, data=0x8185dd5c, active_cred=0xf8001be3a001, td=) at /usr/src/sys/sys/file.h:341 #28 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326, data=0x8185dd5c "PATH/drivers/gpu/drm/radeon/r100.c") at /usr/src/sys/kern/sys_generic.c:804 #29 0x80643398 in sys_ioctl (td=0xf8001be3a000, uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712 #30 0x808b92e5 in syscallenter (td=0xf8001be3a000) at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144 #31 amd64_syscall (td=0xf8001be3a000, traced=0) at /usr/src/sys/amd64/amd64/trap.c:1162 ___ 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: rc.d/linux runs unconditionally
On 1003T0947, Michael Butler wrote:
> In rc.d/sysvipc we see ..
>
> name="sysvipc"
> desc="Load SysV IPC modules"
> rcvar="sysvipc_enable"
> start_cmd="${name}_start"
>
> .. so it won't try to run without explicitly setting sysvipc_enable in
> /etc/rc.conf.
>
> However in rc.d/linux, we have only ..
>
> name="linux"
> desc="Enable Linux ABI"
> start_cmd="${name}_start"
>
> .. which causes it to try to load the linux modules unconditionally
> even when I don't want them,
Should be fixed now; thanks!
___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?
would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info ___ 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: Troubles with the X-Server on an RADEON GPU 240
On Wed, 2 Oct 2019 at 18:50, mms.vanbreukelin...@gmail.com wrote: Forgotten to tell, I did this aleady. User has been already added to the video group. On Wed, 2 Oct 2019 at 18:42, Pete Wright wrote: On 10/2/19 9:36 AM, Miranda Maria Sophie Van den Breukelingen wrote: > Revision: svn'd but not yet built 353009 on CURRENT GENERIC; > built: xorg-xserver; llvm-devel > > X -configure log tells, can't open dev/io; falling back to scfb > no screens found > > /etc/rc.conf: kld_load="amdgpu". > > sddm: > xauth in sloop... > > kernel rebuilt? I would make sure you've installed the drm-kmod pkg, it is not clear to me that you have done this yet as per above. This should install the appropriate kernel drivers, just make sure you read the pkg message after installing it (esp making sure you are a member of the "video" group). -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA ___ 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"
rc.d/linux runs unconditionally
In rc.d/sysvipc we see ..
name="sysvipc"
desc="Load SysV IPC modules"
rcvar="sysvipc_enable"
start_cmd="${name}_start"
.. so it won't try to run without explicitly setting sysvipc_enable in
/etc/rc.conf.
However in rc.d/linux, we have only ..
name="linux"
desc="Enable Linux ABI"
start_cmd="${name}_start"
.. which causes it to try to load the linux modules unconditionally
even when I don't want them,
imb
___
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: HEADS UP - users of hpt27xx, hptmv, hptnr, hptrr drivers
Speaking of these drivers, is anybody actually using the hptmv, htpnr, hptrr or hpt27xx? Please email me or the list if you are. Warner On Thu, Oct 3, 2019 at 6:56 AM Ed Maste wrote: > These drivers have been removed from GENERIC. If you use them on > -CURRENT please add the appropriate foo_load="YES" entry to > /boot/loader.conf, or create a kernel config with the required > driver(s) added. > > -- Forwarded message - > Author: emaste > Date: Thu Oct 3 12:51:57 2019 > New Revision: 353042 > URL: https://svnweb.freebsd.org/changeset/base/353042 > > Log: > Remove host binary object drivers from GENERIC > > Four drivers (hpt27xx, hptmv, hptnr, hptrr, hpt27xx) include precompiled > binary objects; have users load them as modules if they are needed. > > Additional work (i.e., integrating devmatch) required before MFC. > > Reviewed by: markj > Relnotes: Yes > Sponsored by: The FreeBSD Foundation > Differential Revision:https://reviews.freebsd.org/D21865 > > Modified: > head/UPDATING > head/sys/amd64/conf/GENERIC > head/sys/i386/conf/GENERIC > > Modified: head/UPDATING > > == > --- head/UPDATING Thu Oct 3 12:47:05 2019(r353041) > +++ head/UPDATING Thu Oct 3 12:51:57 2019(r353042) > @@ -26,6 +26,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: > disable the most expensive debugging functionality run > "ln -s 'abort:false,junk:false' /etc/malloc.conf".) > > +20191003: > + The hpt27xx, hptmv, hptnr, and hptrr drivers have been removed from > + GENERIC. They are available as modules and can be loaded by adding > + to /boot/loader.conf hpt27xx_load="YES", hptmv_load="YES", > + hptnr_load="YES", or hptrr_load="YES", respectively. > + > 20190913: > ntpd no longer by default locks its pages in memory, allowing them > to be paged out by the kernel. Use rlimit memlock to restore > > Modified: head/sys/amd64/conf/GENERIC > > == > --- head/sys/amd64/conf/GENERIC Thu Oct 3 12:47:05 2019(r353041) > +++ head/sys/amd64/conf/GENERIC Thu Oct 3 12:51:57 2019(r353042) > @@ -165,10 +165,6 @@ device ses # > Enclosure Services (SES and SAF-TE) > device amr # AMI MegaRAID > device arcmsr # Areca SATA II RAID > device ciss# Compaq Smart RAID 5* > -device hptmv # Highpoint RocketRAID 182x > -device hptnr # Highpoint DC7280, R750 > -device hptrr # Highpoint RocketRAID 17xx, > 22xx, 23xx, 25xx > -device hpt27xx # Highpoint RocketRAID 27xx > device iir # Intel Integrated RAID > device ips # IBM (Adaptec) ServeRAID > device mly # Mylex AcceleRAID/eXtremeRAID > > Modified: head/sys/i386/conf/GENERIC > > == > --- head/sys/i386/conf/GENERIC Thu Oct 3 12:47:05 2019(r353041) > +++ head/sys/i386/conf/GENERIC Thu Oct 3 12:51:57 2019(r353042) > @@ -151,10 +151,6 @@ device ses # > Enclosure Services (SES and SAF-TE) > device amr # AMI MegaRAID > device arcmsr # Areca SATA II RAID > device ciss# Compaq Smart RAID 5* > -device hptmv # Highpoint RocketRAID 182x > -device hptnr # Highpoint DC7280, R750 > -device hptrr # Highpoint RocketRAID 17xx, > 22xx, 23xx, 25xx > -device hpt27xx # Highpoint RocketRAID 27xx > device iir # Intel Integrated RAID > device ips # IBM (Adaptec) ServeRAID > device mly # Mylex AcceleRAID/eXtremeRAID > ___ > 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" > ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 03:05:27PM +0200, Hans Petter Selasky wrote: > On 2019-10-03 14:59, Steve Kargl wrote: > > On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > >> On 2019-10-02 23:19, Steve Kargl wrote: > >>> troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > >>> > >>> Wed Oct 2 14:12:38 PDT 2019 > >>> > >> > >> This looks like a simple NULL pointer. > >> > >> Can you re-compile the drm ports module with debugging symbols and then > >> reproduce? > >> > > > > Yes. Is there a ports knob, ie., 'make -DEBUG' for the > > drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? > > > > BTW, this is what I have installed > > > > drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS > > drm-kmod-g20190710 Metaport of DRM modules > > gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS > > If you leave the port debug knob for drm-current-kmod AS-IS, I think you > can get away with: > > make DEBUG_FLAGS="-g" > > Then re-load the vmcore file in GDB/KGDB from ports (!) and add the > symbol files for the modules loaded. Then get the backtrace using bt > command. > > BTW: Did you try drm-devel-kmod for 13-current? > No. I let drm-kmod select drm-current-kod. I can trying drm-devel-kmodr. I do have an older graphics card, which required the drm-legacy-kmod port until recently % pciconf -vl ... vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]' device = 'Caicos [Radeon HD 6450/7450/8450 / R5 230 OEM]' class = display subclass = VGA -- Steve ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 05:59:20AM -0700, Steve Kargl wrote: > On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > > On 2019-10-02 23:19, Steve Kargl wrote: > > > troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > > > > > > Wed Oct 2 14:12:38 PDT 2019 > > > > > > > This looks like a simple NULL pointer. > > > > Can you re-compile the drm ports module with debugging symbols and then > > reproduce? > > > > Yes. Is there a ports knob, ie., 'make -DEBUG' for the > drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? > Nevermind. After reading the Makefile, I see that there is an option knob that can be toggled. -- Steve ___ 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: radeon panics kernels
On 2019-10-03 14:59, Steve Kargl wrote: On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: On 2019-10-02 23:19, Steve Kargl wrote: troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 Wed Oct 2 14:12:38 PDT 2019 This looks like a simple NULL pointer. Can you re-compile the drm ports module with debugging symbols and then reproduce? Yes. Is there a ports knob, ie., 'make -DEBUG' for the drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? BTW, this is what I have installed drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS drm-kmod-g20190710 Metaport of DRM modules gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS If you leave the port debug knob for drm-current-kmod AS-IS, I think you can get away with: make DEBUG_FLAGS="-g" Then re-load the vmcore file in GDB/KGDB from ports (!) and add the symbol files for the modules loaded. Then get the backtrace using bt command. BTW: Did you try drm-devel-kmod for 13-current? --HPS ___ 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: radeon panics kernels
On Thu, Oct 03, 2019 at 09:17:32AM +0200, Hans Petter Selasky wrote: > On 2019-10-02 23:19, Steve Kargl wrote: > > troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7 > > > > Wed Oct 2 14:12:38 PDT 2019 > > > > This looks like a simple NULL pointer. > > Can you re-compile the drm ports module with debugging symbols and then > reproduce? > Yes. Is there a ports knob, ie., 'make -DEBUG' for the drm ports? Or, do I need to add CFLAGS+=-g to the Makefile? BTW, this is what I have installed drm-current-kmod-4.16.g20190927 DRM modules for the linuxkpi-based KMS drm-kmod-g20190710 Metaport of DRM modules gpu-firmware-kmod-g20190825Firmware modules for the linuxkpi-based KMS -- Steve ___ 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"
HEADS UP - users of hpt27xx, hptmv, hptnr, hptrr drivers
These drivers have been removed from GENERIC. If you use them on -CURRENT please add the appropriate foo_load="YES" entry to /boot/loader.conf, or create a kernel config with the required driver(s) added. -- Forwarded message - Author: emaste Date: Thu Oct 3 12:51:57 2019 New Revision: 353042 URL: https://svnweb.freebsd.org/changeset/base/353042 Log: Remove host binary object drivers from GENERIC Four drivers (hpt27xx, hptmv, hptnr, hptrr, hpt27xx) include precompiled binary objects; have users load them as modules if they are needed. Additional work (i.e., integrating devmatch) required before MFC. Reviewed by: markj Relnotes: Yes Sponsored by: The FreeBSD Foundation Differential Revision:https://reviews.freebsd.org/D21865 Modified: head/UPDATING head/sys/amd64/conf/GENERIC head/sys/i386/conf/GENERIC Modified: head/UPDATING == --- head/UPDATING Thu Oct 3 12:47:05 2019(r353041) +++ head/UPDATING Thu Oct 3 12:51:57 2019(r353042) @@ -26,6 +26,12 @@ NOTE TO PEOPLE WHO THINK THAT FreeBSD 13.x IS SLOW: disable the most expensive debugging functionality run "ln -s 'abort:false,junk:false' /etc/malloc.conf".) +20191003: + The hpt27xx, hptmv, hptnr, and hptrr drivers have been removed from + GENERIC. They are available as modules and can be loaded by adding + to /boot/loader.conf hpt27xx_load="YES", hptmv_load="YES", + hptnr_load="YES", or hptrr_load="YES", respectively. + 20190913: ntpd no longer by default locks its pages in memory, allowing them to be paged out by the kernel. Use rlimit memlock to restore Modified: head/sys/amd64/conf/GENERIC == --- head/sys/amd64/conf/GENERIC Thu Oct 3 12:47:05 2019(r353041) +++ head/sys/amd64/conf/GENERIC Thu Oct 3 12:51:57 2019(r353042) @@ -165,10 +165,6 @@ device ses # Enclosure Services (SES and SAF-TE) device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device ciss# Compaq Smart RAID 5* -device hptmv # Highpoint RocketRAID 182x -device hptnr # Highpoint DC7280, R750 -device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx -device hpt27xx # Highpoint RocketRAID 27xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID Modified: head/sys/i386/conf/GENERIC == --- head/sys/i386/conf/GENERIC Thu Oct 3 12:47:05 2019(r353041) +++ head/sys/i386/conf/GENERIC Thu Oct 3 12:51:57 2019(r353042) @@ -151,10 +151,6 @@ device ses # Enclosure Services (SES and SAF-TE) device amr # AMI MegaRAID device arcmsr # Areca SATA II RAID device ciss# Compaq Smart RAID 5* -device hptmv # Highpoint RocketRAID 182x -device hptnr # Highpoint DC7280, R750 -device hptrr # Highpoint RocketRAID 17xx, 22xx, 23xx, 25xx -device hpt27xx # Highpoint RocketRAID 27xx device iir # Intel Integrated RAID device ips # IBM (Adaptec) ServeRAID device mly # Mylex AcceleRAID/eXtremeRAID ___ 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: Kernel panic after rebuilding CURRENT
Yes for me too. Op vr 27 sep. 2019 om 13:23 schreef mms.vanbreukelin...@gmail.com < mms.vanbreukelin...@gmail.com>: > Works again, just 'svn up' to the latest release, rebuuld, nothing to > do with virtualization but a serious kernel problem - IMO having too little > userspace and too much right winged here. > > Miranda > > On Fri, 27 Sep 2019 at 11:48, Johan Hendriks > wrote: > Just a me too, for me it is a standard FreeBSD running on virtualbox. > > regards, > Johan > > > Op wo 25 sep. 2019 om 17:30 schreef mms.vanbreukelin...@gmail.com < > mms.vanbreukelin...@gmail.com>: > > Had verbose on and got the following kernel error on 290: > taskqgroup_adjust_if_config_tqg: panic: sched_pickcpu: failed to find a cpu > Looked for device tqg, isn't available in a slightly changing GENERIC > custom. I know what this personally means to me, incompatibility and a > lack of social integration, but what's the reason for BSD telling me: > "thank you, that's it!" I have LOCK_PROFILING as option for building, but > this had nothing to do with that kinda problem. > Reversion from this morning, as a lack of Inet at the moment, I had to > 'svn up' from within Linux with ufs write enabled and gave root to the > rescue CD for fsck'ing the /dev/ada0p7. The hashkey terror stops and when > unmounted without flags -fl on arch. They're doing well together simple > because if unification purpose against monopoly. > Had to rebuild without SMP, so virtualization is problematic. #ing the > ule_scheduler shouldn't be "unticked", as this causes severe compile > errors. > I think she just wants a backward development at this age, nostalgia > electronica should be a study tribe on universities like history in > school! Anyone able to get 2nd CPU up again? > > ___ > 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 > " > > ___ 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"
AMD Secure Encrypted Virtualization - FreeBSD Status?
https://developer.amd.com/sev/ https://github.com/AMDESE/AMDSEV https://arstechnica.com/gadgets/2019/08/a-detailed-look-at-amds-new-epyc-rome-7nm-server-cpus/ http://amd-dev.wpengine.netdna-cdn.com/wordpress/media/2013/12/AMD_Memory_Encryption_Whitepaper_v7-Public.pdf https://libvirt.org/kbase/launch_security_sev.html "AMD is also using its Secure Processor to enable a couple of key features that we believe aren't getting enough attention: Secure Memory Encryption and Secure Encrypted Virtualization. There's an AES-128 engine inside Epyc's memory controller, with the keys managed by the SEP. If SME is enabled in the system BIOS, all RAM in the system will be encrypted using a single key provided by the SEP and decrypted when requested by the CPU. Expanding upon SME, SEV allows guests' allocated RAM to be encrypted with individual keys, separate from the one used by the host operating system." ___ 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: radeon panics kernels
On 2019-10-02 23:19, Steve Kargl wrote:
troutmask.apl.washington.edu dumped core - see /var/crash/vmcore.7
Wed Oct 2 14:12:38 PDT 2019
This looks like a simple NULL pointer.
Can you re-compile the drm ports module with debugging symbols and then
reproduce?
--HPS
FreeBSD troutmask.apl.washington.edu 13.0-CURRENT FreeBSD 13.0-CURRENT r352812
HPC amd64
panic: page fault
Fatal trap 12: page fault while in kernel mode
cpuid = 0; apic id = 10
fault virtual address = 0x0
fault code = supervisor write data, page not present
instruction pointer = 0x20:0x8177ba1c
stack pointer = 0x28:0xfe00b437ff50
frame pointer = 0x28:0xfe00b437ff70
code segment = base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags = interrupt enabled, resume, IOPL = 0
current process = 782 (X:rcs0)
trap number = 12
panic: page fault
cpuid = 0
time = 1570050659
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00b437fc00
vpanic() at vpanic+0x19d/frame 0xfe00b437fc50
panic() at panic+0x43/frame 0xfe00b437fcb0
trap_fatal() at trap_fatal+0x394/frame 0xfe00b437fd10
trap_pfault() at trap_pfault+0x4f/frame 0xfe00b437fd70
trap() at trap+0x2a1/frame 0xfe00b437fe80
calltrap() at calltrap+0x8/frame 0xfe00b437fe80
--- trap 0xc, rip = 0x8177ba1c, rsp = 0xfe00b437ff50, rbp =
0xfe00b437ff70 ---
r100_mm_rreg_slow() at r100_mm_rreg_slow+0x3c/frame 0xfe00b437ff70
radeon_fence_activity() at radeon_fence_activity+0x103/frame 0xfe00b437ffd0
radeon_fence_signaled() at radeon_fence_signaled+0x59/frame 0xfe00b4380010
radeon_sa_bo_new() at radeon_sa_bo_new+0x251/frame 0xfe00b4380170
radeon_ib_get() at radeon_ib_get+0x2f/frame 0xfe00b43801b0
radeon_cs_ioctl() at radeon_cs_ioctl+0x25d/frame 0xfe00b4380630
drm_ioctl_kernel() at drm_ioctl_kernel+0xf5/frame 0xfe00b4380680
drm_ioctl() at drm_ioctl+0x27a/frame 0xfe00b4380770
linux_file_ioctl() at linux_file_ioctl+0x298/frame 0xfe00b43807d0
kern_ioctl() at kern_ioctl+0x284/frame 0xfe00b4380840
sys_ioctl() at sys_ioctl+0x158/frame 0xfe00b4380910
amd64_syscall() at amd64_syscall+0x275/frame 0xfe00b4380a30
fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00b4380a30
--- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x200cc95ca, rsp =
0x7fffbfffde98, rbp = 0x7fffbfffdec0 ---
Uptime: 5d1h10m44s
Dumping 1764 out of 16327 MB:..1%..11% (CTRL-C to abort)
..21%..31%..41%..51%..61%..71%..81%..91%
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct pcpu,
(kgdb) #0 __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:392
#2 0x805e26aa in kern_reboot (howto=260)
at /usr/src/sys/kern/kern_shutdown.c:479
#3 0x805e2b09 in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:908
#4 0x805e2903 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:835
#5 0x808b8884 in trap_fatal (frame=0xfe00b437fe90, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:925
#6 0x808b88df in trap_pfault (frame=0xfe00b437fe90,
usermode=, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:743
#7 0x808b7f71 in trap (frame=0xfe00b437fe90)
at /usr/src/sys/amd64/amd64/trap.c:407
#8
#9 0x8177ba1c in r100_mm_rreg_slow () from /boot/modules/radeonkms.ko
#10 0x817ba613 in radeon_fence_activity ()
from /boot/modules/radeonkms.ko
#11 0x817ba6e9 in radeon_fence_signaled ()
from /boot/modules/radeonkms.ko
#12 0x817d2601 in radeon_sa_bo_new () from /boot/modules/radeonkms.ko
#13 0x817c1a4f in radeon_ib_get () from /boot/modules/radeonkms.ko
#14 0x817ad6ed in radeon_cs_ioctl () from /boot/modules/radeonkms.ko
#15 0x818a82f5 in drm_ioctl_kernel () from /boot/modules/drm.ko
#16 0x818a858a in drm_ioctl () from /boot/modules/drm.ko
#17 0x807cf568 in linux_file_ioctl_sub (fp=,
filp=, fop=, cmd=, data=0x0,
td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:965
#18 linux_file_ioctl (fp=, cmd=,
data=, cred=, td=)
at /usr/src/sys/compat/linuxkpi/common/src/linux_compat.c:1558
#19 0x80643694 in fo_ioctl (fp=, com=3223348326,
data=0x8185dd5c, active_cred=0xf8001be3a001,
td=) at /usr/src/sys/sys/file.h:341
#20 kern_ioctl (td=0xf8001be3a000, fd=, com=3223348326,
data=0x8185dd5c
"/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852e/drivers/gpu/drm/radeon/r100.c")
at /usr/src/sys/kern/sys_generic.c:804
#21 0x80643398 in sys_ioctl (td=0xf8001be3a000,
uap=0xf8001be3a3c8) at /usr/src/sys/kern/sys_generic.c:712
#22 0x808b92e5 in syscallenter (td=0xf8001be3a000)
at /usr/src/sys/amd64/amd64/../../kern/subr_syscall.c:144
#23
