Re: 'set but unused' breaks drm-*-kmod
On dj., abr. 21 2022, Emmanuel Vadot wrote: Hello Michael, On Wed, 20 Apr 2022 23:39:12 -0400 Michael Butler wrote: Seems this new requirement breaks kmod builds too .. The first of many errors was (I stopped chasing them all for lack of time) .. --- amdgpu_cs.o --- /usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.7.19_3/drivers/gpu/drm/amd/amdgpu/amdgpu_cs.c:1210:26: error: variable 'priority' set but not used [-Werror,-Wunused-but-set-variable] enum drm_sched_priority priority; ^ 1 error generated. *** [amdgpu_cs.o] Error code 1 How are you building the port, directly or with PORTS_MODULES ? I do make passes on the warning for drm and I did for set-but-not-used case but unfortunately this option doesn't exists in 13.0 so I couldn't apply those in every branch. Cheers, Can confirm the breakage on 14-CURRENT building graphics/drm-devel-kmod in poudriere with matching sources and kernel. Probably due to 8b83d7e0ee54416b0ee58bd85f9c0ae7fb3357a1 -- Evilham
Re: -CURRENT hangs since at least 2022-04-04
On dl., abr. 18 2022, Pete Wright wrote: On 4/18/22 12:23, filis+fbsdcurr...@filis.org wrote: Hi, I'm running -CURRENT on this one desktop box which is a "Ryzen 7 4800U with Radeon Graphics", since it didn't work on 13R. I use Boot environments and on 2022-04-04 I updated it and it started to completely freeze under X (I haven't tried letting it run without X) after a few dozen minutes. I went on vacation and came back today and updated it again to see if the issue went away, but it froze again. I went back to the latest BE before 2022-04-04, which is from 2022-03-21 and so far it works fine again. I use a different machine to build and then rsync /usr/src and /usr/obj over and run make installworld, etc locally and also pkg upgrade (I use FreeBSD -latest packages) everything, so I can't quite tell if this is related to base or drm-kmod and I'm not too familiar with changes in the timeframe between 2022-03-21 and 2022-04-04 that would affect my setup. Is there anything I can try and/or find or collect info to shed more light on this? After updating your CURRENT environment did you rebuild the drm-kmod package? that's usually required as the LKPI is much more of a moving target on that branch compared to STABLE or RELEASE. i have a pretty much identical setup and building/installing drm-devel-kmod has been working flawlessly for quite a while. after building/installing my latest world i do following (this is from a local script i use when rebuilding): cd $PORTS/graphics/drm-devel-kmod sudo pkg unlock -y drm-devel-kmod sudo make package sudo pkg upgrade -y work/pkg/*.pkg sudo pkg lock -y drm-devel-kmod -pete I too have recently noticed some freezes after a few hours on -CURRENT that were not happening before. This with a matching drm-devel-kmod package (built with matching source on matching kernel). The hw being: AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx -- Evilham
Re: PAM: SSH: reject login when homdir does not exist?
On dg., abr. 17 2022, FreeBSD User wrote: Hello fellows, happy Easter! I run into a security issue this morning here and tried to look for a solution. We use OpenLDAP for all "regular users" login on hosts and web services. Authentication is required from some cloud/moodle services via LDAP, but some users not having any homedirectory on any machine within the domain will still be allowed to login, even if the home dir is not present. They get loged in onto the root of the filesystem, when login via SSH. Is there a way to prohibit login if homedir isn't present? Can you point me to the right place (PAM or something, pam_env isn't available on FreeBSD)? If this is a trivial issue and caused by lack of my personell knowledge, please excuse. Kind regards, Hey, even if you manage to do that, you probably shouldn't address your problem this way: existence of a directory is a rather weak assertion to make when deciding whether or not someone should be able to get a shell. Take a look at AllowGroups and AllowUsers in man 5 sshd_config, that should fit your use-case much better. Other than that, you probably want to change their shell and stuff like that. Do check: https://docs.freebsd.org/en/books/handbook/security/#security-intro And adapt to your LDAP setup. Also, mid-term this M.W. Lucas' Absolute FreeBSD is a really good place to learn things: https://mwl.io/nonfiction/os#af3e PS: This mailing list is for things related to FreeBSD-CURRENT; it seems like this question might be a better fit for freebsd-questions@, since it is related to systems in general. Cheers, -- Evilham
Re: Current kernel build broken with linuxkpi?
On dc., gen. 13 2021, David Wolfskill wrote:
On Wed, Jan 13, 2021 at 02:52:32PM -0500, Robert Huff wrote:
Hans Petter Selasky :
> You need to update that DRM port you are using before the
> issue
> will be fixed.
I'm confused.
I have drm-current-kmod listed in PORTS_MODULES; things on
that
list get built _after_ buildkernel (installkernel??) for
reasons I
thought I understood.
You are telling me I need to update this _before_ buildkernel?
Perplexedly,
He telling you to update the port itself -- e.g.,
/usr/ports/graphics/drm-kmod, as the port was recently updated:
r561457 | manu | 2021-01-13 03:22:25 -0800 (Wed, 13 Jan 2021) |
6 lines
graphics/drm-{current,devel}-kmod: Update to latest source
This fix a compilation problem with a pre 1300135 source tree.
Reported by:Filippo Moretti
So you need to update the "ports files" to get that update, then
rebuild
the port (in concert with rebuilding the kernel, as you are
doing).
Peace,
david
Just as a curiosity because I was hit by this and the thread was
helpful:
I was unable to build the kernel with an up to date
drm-current-kmod, but as soon as I switched to drm-devel-kmod, I
was able to.
The running kernel was uname -K: 1300133.
Thanks everyone for having added their input here.
--
Evilham
___
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: CFT for vendor openzfs - week 2 reminder
On dl., jul. 13 2020, Kyle Evans wrote: On Mon, Jul 13, 2020 at 12:27 PM Matthew Macy wrote: On Wednesday, July 8th I issued the initial call for testing for the update to HEAD to vendored openzfs. We'd like to give users roughly a month to test before merging. The current *tentative* merge date is August 10th. I hope it's not terribly controversial to point out that it really rests with users of non amd64 platforms to test to avoid any unpleasant surprises the next time they update their trees following the merge. I've had no problems with this on a couple amd64 systems; I did note that my loader.conf's needed a good s/vfs.zfs.arc_max/vfs.zfs.arc.max/ but I'm told a compat sysctl is on the TODO list to ease the transition. I've also been using this on amd64 for a few days without any issues, it's even fixed a bug I've been trying to figure out: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=247544 I have noticed a thing though: Previously observed behaviour: 1. A new zpool is made available (e.g. geli attach) 2. The zpool is imported 3. Something happens (e.g. system reboot) and the zpool is not available anymore but also not exported 4. The zpool is made available again 5. The zpool is *still* imported 6. The zpool must be manually mounted With the patches for OpenZFS, number 5 and 6 are instead: 5. The data zpool is not imported 6. The zpool must be manually re-imported It is different behaviour, but I am very unsure about whether or not that is to be considered a bug and needs a PR. -- Evilham ___ 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: CFT for vendor openzfs
Hey, thank you for this.
On dc., jul. 08 2020, Matthew Macy wrote:
Checkout updated HEAD:
% git clone https://github.com/mattmacy/networking.git -b
projects/openzfs_vendor freebsd
Checkout updated openzfs in to sys/contrib:
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor freebsd/sys/contrib/openzfs
A success compile and boot story here, will be alert and report
oddities if I find any; otherwise this would be one person who is
testing for whom things aren't utterly broken :-).
Just an addendum to your instructions:
If someone is already using git to manage FreeBSD's source, this
would be the way:
# Change working dir to the git repository
% cd ${FREEBSD_GIT_SOURCE}
# Add Matthew's remote
% git add remote mattmacy
https://github.com/mattmacy/networking.git
# This will make it easier to follow HEAD
% git config pull.rebase true
# Merge Matthew's changes into curent branch
% git merge mattmacy/projects/openzfs_vendor
# Get OpenZFS's code
% git clone https://github.com/zfsonfreebsd/ZoF.git -b
projects/openzfs_vendor sys/contrib/openzfs
# Build, install as usual, maybe use a checkpoint ;-)
--
Evilham
___
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 reattach USB devices (Lenovo bug?)
On dl., gen. 20 2020, Hans Petter Selasky wrote: ^^^ my best guess is this is ACPI related :-( ACPI has own debugging flags and options. --HPS Thank you, now reading handbook/acpi-overview.html in order to try to get more info. -- Evilham ___ 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"
Can't reattach USB devices (Lenovo bug?)
Hello, at first I thought I had found a regression in CURRENT (2020-01-19), and now I'm not so sure since, before reporting I rolled back a recent BIOS upgrade and that got rid of the issue. First of all, the hardware: Lenovo ThinkPad A485 (AMD Ryzen processor). The issue (BIOS v1.28[1]) being that any USB device: would work on first plug, but if unplugged and plugged again, it wouldn't work (see dmesg below). Downgrading to BIOS v1.24 results in the issue disappearing. How should this be dealt with? Could this be something FreeBSD needs better support for? or is it entirely on Lenovo? If the former, how can I help provide more information/testing(*)? If the latter, should I inform Lenovo of the issue? If anyone has experience with that, I'd appreciate pointers as to how to provide them with information in a way that makes it somewhat likely that things get solved. [1]: BIOS Release notes: https://download.lenovo.com/pccbbs/mobiles/r0wuj60w.txt (*): Helping spot bugs and provide information/testing is why I'm running CURRENT after all Just FTR: I also experienced random kernel panics [2] with versions v1.22 and v1.16 of the BIOS, so maybe Lenovo is being unreasonable/unreliable about BIOS upgrades. In any case I am curious as to how other OS deal with this class of issues and how FreeBSD could (if possible at all) work better in these cases. [2]: Kernel panic solved by BIOS upgrade (to v1.24) see: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 Also FTR, this was the contents of dmesg with BIOS v1.28 and CURRENT as of 2020-01-19: (notice there are multiple disconnect and reconnect attempts of different devices) ugen1.2: at usbus1 (disconnected) uhub4: at uhub1, port 1, addr 1 (disconnected) ugen1.3: at usbus1 (disconnected) ukbd0: at uhub4, port 2, addr 2 (disconnected) ukbd0: detached uhid0: at uhub4, port 2, addr 2 (disconnected) uhid0: detached ugen1.4: at usbus1 (disconnected) uhub5: at uhub4, port 4, addr 3 (disconnected) ugen1.5: at usbus1 (disconnected) uhid1: at uhub5, port 1, addr 4 (disconnected) uhid1: detached ums0: at uhub5, port 1, addr 4 (disconnected) ums0: detached ukbd1: at uhub5, port 1, addr 4 (disconnected) ukbd1: detached uhub5: detached uhub4: detached ugen1.2: at usbus1 uhub4 on uhub1 uhub4: on usbus1 acpi_ec0: EcCommand: no response to 0x84 uhub4: 4 ports with 4 removable, self powered acpi_ec0: EcCommand: no response to 0x84 acpi_ec0: EcCommand: no response to 0x84 acpi_ec0: GPE query failed: AE_NO_HARDWARE_RESPONSE usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 2 failed, USB_ERR_TIMEOUT ugen1.3: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device ugen1.2: at usbus1 (disconnected) uhub4: at uhub1, port 1, addr 1 (disconnected) uhub4: detached usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT ugen1.2: at usbus1 (disconnected) uhub_reattach_port: could not allocate new device usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT usbd_setup_device_desc: getting device descriptor at addr 1 failed, USB_ERR_TIMEOUT -- Evilham ___ 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"
/var/log/messages: "should not happen" "see local kernel hacker"
Hello, I thought I'd finally ask about these messages that appear on boot on my machine. It's a Lenovo A485, with an AMD Ryzen laptop running CURRENT as of 8 hours ago, in case that's relevant. Are some of these actionable/would it make sense to take a deeper look or are they about something needing further debugging with the "right" hardware? 1. "this should not happen": FTR: - I switched the wireless chip for an Intel AC 8265. - I'm used to having wireless be wlan0, so I rename iwm0 in rc.conf - This was connecting to a mobile hotspot, but I've seen the message on "normal" networks. And this is what I am seeing in /var/log/messages: Jan 14 06:33:50 kernel: iwm0: 8265> mem 0xc0a0-0xc0a01fff at device 0.0 on pci2 Jan 14 06:33:50 kernel: iwm0: hw rev 0x230, fw ver 22.361476.0, address XX Jan 14 06:33:50 kernel: wlan0: Ethernet address: XX Jan 14 06:33:50 kernel: wlan0: link state changed to UP Jan 14 06:33:50 kernel: iwm0: frame 3/122 b82c UNHANDLED (this should not happen) Jan 14 06:33:50 kernel: iwm0: frame 4/192 b82c UNHANDLED (this should not happen) Jan 14 06:33:50 kernel: iwm0: frame 5/233 b82c UNHANDLED (this should not happen) 2. There is also this "driver bug": Jan 14 06:33:50 kernel: AMD-Vi: IVRS Info VAsize = 64 PAsize = 48 GVAsize = 2 flags:0 Jan 14 06:33:50 kernel: driver bug: Unable to set devclass (class: ppc devname: (unknown)) 3. And "see your local kernel hacker" has been around on my system for about a year, suspend and resume work just fine. Jan 14 06:33:52 kernel: __pm_runtime_resume not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: pm_runtime_mark_last_busy not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_suspend not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_resume not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: pm_runtime_mark_last_busy not implemented -- see your local kernel hacker Jan 14 06:33:52 kernel: __pm_runtime_suspend not implemented -- see your local kernel hacker 4. Then 'Giant locked and may be deleted': Jan 14 06:33:50 kernel: WARNING: Device "kbd" is Giant locked and may be deleted before FreeBSD 13.0. Jan 14 06:33:50 kernel: WARNING: Device "psm" is Giant locked and may be deleted before FreeBSD 13.0. Jan 14 06:33:50 kernel: WARNING: Device "fb" is Giant locked and may be deleted before FreeBSD 13.0. I am guessing number 4 has to do with recent changes, and shouldn't really affect the system if the devices are deleted? Is there a way I can test if its deletion would leave the system unusable? Thank you, -- Evilham ___ 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 r355732 breaks DRM
On dc., des. 18 2019, Graham Perrin wrote: On 14/12/2019 01:30, Warner Losh wrote: > A fix is in progress. Thank you. r355860 drm-legacy-kmod <https://pastebin.com/NcrA9iLe> lines 70–81: the same issue, yes? FWIW: https://github.com/FreeBSDDesktop/kms-drm/issues/198 I've been using a locally built drm-kmod without patches (off commit ee53eae) for a couple days with the latest HEAD. Maybe the port just hasn't been rebuilt on FreeBSD infra yet? In any case, and at your own risk you can give that a go. -- Evilham ___ 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: Large patch that adds NFSv4.2 has been committed to head/current
On dv., des. 13 2019, Rick Macklem wrote: Hi, r355677 is a large patch that adds NFSv4.2 support to the NFS client/server. It has survived a "make universe" for all arches that would build (some mips and sparc64 failed for reasons unrelated to this patch). However, I have not been able to do a build with a recent GCC. If there are build problems, please let me know. Although there are a lot of code changes, they should not affect the other versions of NFS. The patch does add two new sysctls that can be used to limit the minor versions of NFSv4 supported by the nfsd and, as such, NFSv4.2 can be disabled without reverting this patch. It does change the internal interface between the NFS modules, so they must all be upgraded simultaneously. Although arguably not necessary, I will do a version bump for this. Hopefully this big patch does not cause you grief, rick Maybe for your relief: it looks like that build is working for me :-), so no unintended non-NFS consequences here. # uname -KiprsU FreeBSD 13.0-CURRENT amd64 GENERIC-NODEBUG 1300066 1300066 Hopefully I can test NFS 4.2 soon. Thank you for working on this! -- Evilham ___ 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: r353072 > r353427 > r353709
On ds., oct. 19 2019, Clay Daniels, Jr. wrote: r353709 of today 18 Oct has only gone down hill. I tried to load it a half dozen times, gave up and then tried re-installing r353072 which was working earlier today, but the problem is the drm-firmware-kmod is different this week, and even it will not run xorg. Have you seen the recent threads about this? Particularly this with some steps that worked-for-me (tm): https://lists.freebsd.org/pipermail/freebsd-current/2019-October/074660.html -- Evilham ___ 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: DRM-current-kmod is still a problem at r353339
Hey, thanks for the patch and the CC, coincidentally I had some time to look into this again. On dj., oct. 17 2019, ma...@freebsd.org wrote: I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. diff --git a/linuxkpi/gplv2/src/linux_page.c b/linuxkpi/gplv2/src/linux_page.c index e2b85c45c..060ae85ed 100644 --- a/linuxkpi/gplv2/src/linux_page.c +++ b/linuxkpi/gplv2/src/linux_page.c @@ -239,7 +239,7 @@ retry: page = vm_page_lookup(devobj, i); if (page == NULL) continue; - if (vm_page_sleep_if_busy(page, "linuxkpi")) + if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) goto retry; cdev_pager_free_page(devobj, page); } I can confirm this works now on AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx :-D. Took the liberty of adding to the end of this message some schematic steps to upgrade world+kernel+drm-devel-kmod in a setup with poudriere+boot environments, I hope they are helpful for someone else. If not using poudriere/boot environments, those bits can be skipped. Now I have trick questions: What is the upgrade plan here? What would happen when 13 is released and people upgrade from 12? I mean, AFAIU one first upgrades world+kernel, then upgrades ports; in cases where drm-kmod is used, that seems to leave the system in an "unusable" state between those steps (there is single-user-mode which allows removal or upgrade of drm-kmod, but regular boot crashes) and since this is a compile-time patch, there doesn't seem to be an easy way to solve that. I saw Mark has a PR to apply the patch to 12.1 as well, but I think that will have the same upgrade path issue? Am I thinking too far ahead here or is there something I'm missing? The mentioned steps: 1. Built world and kernel from HEAD, in this case: FreeBSD 13.0-CURRENT #4 7f37066f607-c263595(master) 2. Created a boot environment so I can go back to it if things don't work out 3. Removed drm-devel-kmod 4. Installed world and kernel 5. Rebooted into a system without graphics, but with the new world and kernel 6. Destroyed my poudriere jail 7. Re-created it (drm-devel-kmod didn't build without steps 6 and 7) 8. Patched poudriere's ports directory: graphics/drm-devel-kmod as follows: --- Makefile(revision 514712) +++ Makefile(working copy) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= drm-devel-kmod -PORTVERSION= 5.0.g20190828 +PORTVERSION= 5.0.g20191017 CATEGORIES= graphics kld MAINTAINER= x...@freebsd.org @@ -28,7 +28,7 @@ USE_GITHUB= yes GH_ACCOUNT= FreeBSDDesktop GH_PROJECT= kms-drm -GH_TAGNAME=dc414a9 +GH_TAGNAME=761ef739 9. Ran make makesum in graphics/drm-devel-kmod 10. Added the patch Mark mentioned before to graphics/drm-devel-kmod: # cat files/patch-linuxkpi_gplv2_src_linux__page.c --- linuxkpi/gplv2/src/linux_page.c.orig2019-08-27 19:58:24 UTC +++ linuxkpi/gplv2/src/linux_page.c @@ -239,7 +239,7 @@ retry: page = vm_page_lookup(devobj, i); if (page == NULL) continue; - if (vm_page_sleep_if_busy(page, "linuxkpi")) + if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) goto retry; cdev_pager_free_page(devobj, page); } 11. Built the port in poudriere 12. Installed drm-devel-kmod 13. Reboot and profit Thank you again for looking into this! -- Evilham ___ 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: DRM-current-kmod is still a problem at r353339
Hello,
I somehow had managed to mess up my build system and only
yesterday got it back to compiling properly.
On ds., oct. 12 2019, Mateusz Guzik wrote:
Try this:
https://people.freebsd.org/~mjg/pmap-fict-invl.diff
I tested this patch on top of r353449 and a panic is still
ocurring when the drm-kmod modules are loaded.
This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
and a Radeon Vega graphics.
My last known working revision is r352987.
Here are bits of the core dump, I hope they are useful, if more
information is needed, please don't hesitate to ask.
BTW: I usually compile GENERIC-NODEBUG, if that results in the
dump being useless (sadly I can't tell), I can disable all the
performance goodies and compile GENERIC :-).
--
Evilham
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xf8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80b1be61
stack pointer = 0x28:0xfe00dd81ccc0
frame pointer = 0x28:0xfe00dd81ccf0
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 = 24022 (kldload)
trap number = 12
panic: page fault
cpuid = 2
time = 1570970502
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00dd81c920
vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
panic() at panic+0x43/frame 0xfe00dd81c9e0
trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
trap() at trap+0x288/frame 0xfe00dd81cbf0
calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
--- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
rbp = 0xfe00dd81ccf0 ---
pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
module_register_init() at module_register_init+0xa4/frame
0xfe00dd81cd80
linker_load_module() at linker_load_module+0xb49/frame
0xfe00dd81d0a0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d0f0
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d1b0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d4d0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d520
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d5e0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d900
kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe00dd81dab0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
KDB: enter: panic
__curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at
/freebsd/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at
/freebsd/src/sys/kern/kern_shutdown.c:392
#2 0x80496a7a in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=)
at /freebsd/src/sys/ddb/db_command.c:575
#3 0x8049683c in db_command (last_cmdp=,
cmd_table=, dopager=1)
at /freebsd/src/sys/ddb/db_command.c:482
#4 0x804965ad in db_command_loop ()
at /freebsd/src/sys/ddb/db_command.c:535
#5 0x80499858 in db_trap (type=,
code=)
at /freebsd/src/sys/ddb/db_main.c:252
#6 0x80c322a7 in kdb_trap (type=3, code=0, tf=out>)
at /freebsd/src/sys/kern/subr_kdb.c:692
#7 0x8105d925 in trap (frame=0xfe00dd81c850)
at /freebsd/src/sys/amd64/amd64/trap.c:585
#8
#9 kdb_enter (why=0x811dee7e "panic", msg=out>)
at /freebsd/src/sys/kern/subr_kdb.c:479
#10 0x80be377a in vpanic (fmt=,
ap=)
at /freebsd/src/sys/kern/kern_shutdown.c:897
#11 0x80be35d3 in panic (
fmt=0x818e4c18
"\357\327\037\201\377\377\377\377") at
/freebsd/src/sys/kern/kern_shutdown.c:835
#12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
eva=248)
at /freebsd/src/sys/amd64/amd64/trap.c:925
#13 0x8105ddff in trap_pfault (frame=0xfe00dd81cc00,
usermode=, signo=,
ucode=)
at /freebsd/src/sys/amd64/amd64/trap.c:743
#14 0x8105d458 in trap (frame=0xfe00dd81cc00)
at /freebsd/src/sys/amd64/amd64/trap.c:407
#15
#16 pfs_destroy (pn=0x0) at
/freebsd/src/sys/fs/pseudofs/pseudofs.c:324
#17 0x80b1ca96 in pfs_uninit (
pi=0x8360f120 ,
vfc=0x8360f010
Panic on boot with r353298 (last known working r35295)
Hey, just a heads up that on a Lenovo A485 (AMD Ryzen processor), r353298 panics somewhat late in the boot process. r352925 is my last known working build. I am building GENERIC-NODEBUG. Sadly my pulse is shaky and I can't properly read the picture I took, it appears to say: Fatal trap 32: page fault while in kernel mode *something, something* fault mode = supervisor read data, page not present Will try to get more details and a proper dump when I have some time off (hopefully later today), just thought I'd warn before. -- Evilham ___ 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: panic: No vop_need_inactive
On dg., set. 01 2019, Evilham wrote: On dg., set. 01 2019, Guido Falsi wrote: Hi, I'm experiencing a recurring panic I can trigger repeatably. I was going to send a similar email a few hours ago to the current ML but decided to debug some more before that. FWIW: I am not 100% sure I it's the same panic, I am missing a cable ATM to get a full dump, but I do think they sound very similar. Awkward, my panic is gone after some fiddling around. I hope yours is indeed also gone after upgrading. -- Evilham ___ 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: panic: No vop_need_inactive
On dg., set. 01 2019, Guido Falsi wrote: Hi, I'm experiencing a recurring panic I can trigger repeatably. The machine is: FreeBSD 13.0-CURRENT r351604 amd64 The panic looks ZFS related. This machine performs mainly poudriere builds. I also use portshaker to manage the ports tree. Portshaker works by downloading ports trees and overlays in zfses, then snapshots them, clones them placing the clones in the poudriere namespace, then modifies the ports there applying the required overlays. This happens to me any time I run poudriere and after the build I run portshaker to update the ports trees, when it tries to remove the snapshot of the freebsd base tree (which AFAIK is the base for the clone where poudriere works). I'm going to try to create a more clear and detailed use case, removing from the equation complex programs like poudriere and portshaker. Interesting! I was going to send a similar email a few hours ago to the current ML but decided to debug some more before that. I use poudriere to manage my ports tree with svn, I do use ZFS. I can trigger the panic by running poudriere bulk on e.g. finance/gnucash. Some more info that may be related: - This worked fine on a build from the 2nd week of August, after r350551 (a fix for AMD Ryzen laptops). - Since that build had an issue with bhyve (as mentioned on this list a few days ago), I upgraded last week which started triggering this issue with poudriere - It still happens with: # uname -v FreeBSD 13.0-CURRENT r351654+209e505321db-c262365(master) GENERIC Which is posterior to r351642 that was mentioned by Mateusz. Here is the panic message: VNASSERT failed 0xf800abfcbd20: tag zfs, type VDIR usecount 0, writecount 0, refcount 1 mountedhere 0 flags (VI_ACTIVE) VI_LOCKedlock type zfs: UNLOCKED name = portshaker-2019-09-01:11:04:20 parent_id = 2 id = 269 panic: No vop_need_inactive(0xf800abfcbd20, 0xfe00ba39b3f0) cpuid = 2 time = 1567342436 KDB: stack backtrace: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe00ba39b310 vpanic() at vpanic+0x19d/frame 0xfe00ba39b360 panic() at panic+0x43/frame 0xfe00ba39b3c0 VOP_NEED_INACTIVE_APV() at VOP_NEED_INACTIVE_APV+0x8f/frame 0xfe00ba39b3e0 vputx() at vputx+0x1ae/frame 0xfe00ba39b440 vfs_mount_destroy() at vfs_mount_destroy+0x14f/frame 0xfe00ba39b470 dounmount() at dounmount+0x7e8/frame 0xfe00ba39b4d0 zfs_unmount_snap() at zfs_unmount_snap+0xbb/frame 0xfe00ba39b4f0 zfs_ioc_destroy_snaps() at zfs_ioc_destroy_snaps+0xb3/frame 0xfe00ba39b540 zfsdev_ioctl() at zfsdev_ioctl+0x54c/frame 0xfe00ba39b5e0 devfs_ioctl() at devfs_ioctl+0xc9/frame 0xfe00ba39b630 vn_ioctl() at vn_ioctl+0x13d/frame 0xfe00ba39b740 devfs_ioctl_f() at devfs_ioctl_f+0x1f/frame 0xfe00ba39b760 kern_ioctl() at kern_ioctl+0x1e4/frame 0xfe00ba39b7c0 sys_ioctl() at sys_ioctl+0x15d/frame 0xfe00ba39b890 amd64_syscall() at amd64_syscall+0x284/frame 0xfe00ba39b9b0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00ba39b9b0 --- syscall (54, FreeBSD ELF64, sys_ioctl), rip = 0x80049f2da, rsp = 0x7fffc948, rbp = 0x7fffc9c0 --- KDB: enter: panic FWIW: I am not 100% sure I it's the same panic, I am missing a cable ATM to get a full dump, but I do think they sound very similar. -- Evilham ___ 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: "amdgpu and radeonkms are known to fail with EFI Boot"
On ds., ag. 24 2019, Clay Daniels, Jr. wrote: Greg, thanks for the wonderful suggestion. Where should I put this line: " hw.syscons.disable=1 " I tried it in /etc/rc.conf and it booted into the console as usual with repeated messages: /etc/rc.conf hw.syscons.disable=1: not found I think that must go in /boot/loader.conf or just for one boot you can add it from the boot loader as a custom option with "set hw..." then "boot". -- Evilham ___ 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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
On dg., jul. 21 2019, Cristian Pogolsha wrote: Hi, Thank you for the instructions. I have a question related to post-installation. My system doesn't boot after installing and rebooting the system. It just doesn't find the partition on the drive. I get a blank screen when selecting from the boot media list. What partitioning scheme did you use for your installation? Or is this problem addressable with step #2 in your instructions? Putting in the boot/loader.conf -> set.hw.pci.mcfg=0? The **hw.pci.mcfg=0** line in /boot/loader.conf is so that your booting won't hang the same way it did on installation without manual parameters, shouldn't be related to your current issue. Remember to add the comment linking to the bug as well, so that you can remove it when those changes land in -CURRENT Also add yourself to the CC field in the bug, that way you can help test those changes. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760q Your current issue sounds like a problem with the way you installed / set up the system and is probably better for freebsd-questions: https://lists.freebsd.org/mailman/listinfo/freebsd-questions FWIW: I boot using EFI from ZFS in a geli-encrypted partition in a GPT disk, I recall some manual fiddling but those were likely because I needed sth particular. -- Evilham ___ 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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
On ds., jul. 20 2019, Evilham wrote: Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long And this is why I wanted to do more debugging before raising an issue :-). It kept happening without drm-kmod but the backtrace was different, which allowed me to reduce it to a piece of alpha Software I use pretty much all the time: WireGuard. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 So, update: there is no *serious* issue when using the ThinkPad A485, it works mostly fine with minor annoyances (including the fact that installation media won't work out of the box). -- Evilham ___ 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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hey, thanks for the feedback and your work, didn't think this would be interesting for anyone but the laptop owners. On ds., jul. 20 2019, Greg V. wrote: On July 20, 2019 1:54:47 AM GMT+03:00, Evilham wrote: it even suspends and resumes back to X Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I need suspend very much on desktop haha) Indeed, I was pleasantly surprised too - xbacklight doesn't work, neither does intel-backlight because it's AMD Since it's a Thinkpad, do the brightness keys work anyway? Does acpi_ibm work? Forgot to mention brightness keys, they also don't work. I just tried acpi_ibm and it also didn't help. Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. If you're on the packaged drm-kmod v4.16, it's amazing that Raven GPU works at all. You should try drm-v5.0 from git. kld_list="amdgpu" Huh, interesting, I'm trying to compile drm-v5.0 right now. This comment and Pete's made me re-visit the graphics settings, specifics below. It even works when loaded this early? Interesting. Do you also not have the EFI framebuffer conflict? i.e. without disabling vt.syscons, everything just works reliably? Yes, with my previous laptop that was necessary, but this one has no need for those settings, it works just fine without and font size is according to the screen (i.e. it's not huge). On ds., jul. 20 2019, Pete Wright wrote: On 7/19/19 3:54 PM, Evilham wrote: Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long interesting. can you post this kernel panic, and any backtraces you are able to get here: https://github.com/FreeBSDDesktop/kms-drm/issues also, are you using the xf86-video-amdgpu driver, or the stock modesetting driver to X? That was my plan for when I manage to fully isolate that it is on drm-kmod, thank you for confirming the path! I noticed I did have xf86-video-amdgpu installed, but just removed it and all traces of drm-kmod as well as the kld_list="amdgpu" bit and X actually works without it and without the xf86-video packages. HDMI output won't work though, I guess that makes sense. We'll see if working like this the system doesn't crash at all, if it does it may be related to #231760 and not to drm-kmod. If it does not crash without drm-kmod, I'll try my build of drm-kmod v5.0 before opening an issue, that'd be more information :-). I did have the question as to why the packaged version is 4.16 but didn't quite find an answer to that on the wikis / documentation. Thank you again, -- Evilham ___ 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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hey, On ds., jul. 20 2019, Cristian Pogolsha wrote: I tried recently to boot FreeBSD current r350103 on a Thinkpad A485. It's the AMD Ryzen equivalent of the T480. During the boot I encountered this ACPI related error https://drive.google.com/file/d/1dzgSonn6Cuc1YrDeAUYSqHZlcmzaDY2Y/view I have the same laptop and recently spent a fair amount of time getting it to work, I've been wanting to document this in a more proper fashion (e.g. FreeBSD's wiki) but haven't gotten the time, maybe since this will save you time, you would be able to put this and your own findings together and do that? If not, at the very least people searching on the web will have now a better chance to find this email. Note: I run on a daily basis, 12-RELEASE but I tested 13-CURRENT about a month ago and everything applied verbatim. First things: in order to get the Thinkpad A485 to boot, wait until you see the logo and press 3 for boot options, once there type: set hw.pci.mcfg=0 boot It should work alright now, after installing the system, triple check that /boot/loader.conf contains this: # Ryzen hack: FreeBSD bug #231760 # https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760 hw.pci.mcfg=0 # Wireless Intel AC8265 # Not strictly necessary, but the Realtek that is shipped is not supported # You can easily (and carefully) change them. if_iwm_load="YES" iwm8265fw_load="YES" Now, if you want X, you should install drm-kmod and add following to your /etc/rc.conf: # Graphics kld_list="amdgpu" Those are the tricky bits to get the system to work IIRC (also: your ethernet is re1, not re0). After this, the system should work fine (it even suspends and resumes back to X!), with minor glitches and a serious issue. Take into account that I didn't research these too much because they are minor annoyances for me. Minor glitches: - xbacklight doesn't work, neither does intel-backlight because it's AMD - Speakers don't appear to work, audio input/output on 3.5 jack does. - SD card reader doesn't work (Bounty for 125 USD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521) Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long Sorry that I'm posting images instead of plain text. I have no idea how to do kernel dumps during the bootload of a live image. I would be happy to post more information if required, let me know how I can do it. No worries, it took me forever to find the bug that had the sysctl. I hope this helps you out, -- Evilham ___ 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"
