Kernel Panic On Boot after r327979
Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at prison_allow+0x4 movq 0x30(%rdi),%rax Is this a known issue? This is my primary workstation - so I'm going to revert back to an older kernel, but if more info is needed I can put some cycles into debugging today. Cheers! -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"
[SOLVED] Re: Kernel Panic On Boot after r327979
On 01/15/2018 09:26, Pete Wright wrote: Hello, I updated an amd64 system last night to r327979 and it panics into gdb after rc attempts to mount local filesystems. The panic line is: Fatal trap 12: page fault while in kernel mode gdb states that it stopped at: Stopped at prison_allow+0x4 movq 0x30(%rdi),%rax Is this a known issue? This is my primary workstation - so I'm going to revert back to an older kernel, but if more info is needed I can put some cycles into debugging today. closing the loop on this. it looks like the panic was due to debugfs being mounted on my system. debugfs is part of the drm-next-kmod port which enables i915 gfx on recent intel GPU's, and debugfs doesn't *need* to be mounted but is quite useful and fun to play with. anywho - the fix on my end is to: - remove the drm-next-kmod port/pkg - build and install latest kernel+world - reboot and build/install the drm-next-kmod port/pkg - reboot and enjoy i915 graphics i'm kinda interested in what prison_allow does now as i haven't run across it before. is this part of the jails infrastrucutre? cheers, -p -- 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"
New ACPI Errors
Hello, I have started seeing a lot of these messages spam my system log: ACPI Error: No pointer back to namespace node in package 0xf8000f79a080 (20180209/dsargs-472) ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) ACPI Error: Method parse/execution failed \134_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) I noticed this starting from a CURRENT build i installed two weeks ago, and still see it from a world/kernel i built last night. two questions: 1) has anyone else noticed this? 2) is this something to worry about? i can help debug the issue but am not sure where to start poking. thanks! -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"
Re: New ACPI Errors
On 02/15/2018 13:37, Jung-uk Kim wrote: On 02/13/2018 17:34, Claude Buisson wrote: On 02/13/2018 22:49, Pete Wright wrote: Hello, I have started seeing a lot of these messages spam my system log: ACPI Error: No pointer back to namespace node in package 0xf8000f79a080 (20180209/dsargs-472) ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) ACPI Error: Method parse/execution failed \134_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) I noticed this starting from a CURRENT build i installed two weeks ago, and still see it from a world/kernel i built last night. two questions: 1) has anyone else noticed this? 2) is this something to worry about? i can help debug the issue but am not sure where to start poking. thanks! -pete Here I have ACPI Error: No pointer back to namespace node in package 0xf8000171f700 (20180209/dsargs-472) ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20180209/dswexec-606) ACPI Error: Method parse/execution failed \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677) with svn 329142 on a Lenovo ThinkCentre M83 ACPI APIC Table: Claude Buisson I believe you can silence the errors with the attached patch. Please try it and let me know. hrm still getting errors: Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to namespace node in package 0xf80003c8c080 (20180209/dsargs-472) Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed \_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) here's my diff: diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h b/sys/contrib/dev/acpica/include/platform/acfreebsd.h index 905dffb7a40..df89399a369 100644 --- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h +++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h @@ -166,6 +166,7 @@ #define ACPI_UINTPTR_T uintptr_t +#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS #define ACPI_USE_DO_WHILE_0 #define ACPI_USE_LOCAL_CACHE #define ACPI_USE_NATIVE_DIVIDE -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"
Re: Compilation failure of the kernel for drm-next
On 02/26/2018 17:17, Mylan Connolly wrote: Hello all, I'm not sure if this is the best place to send this, but it looks like the issue tracker in Github is a bit dead. there may not be much traffic on it recently, but people are def still actively working on the repository and will see when new issues are reported. as of now your best to to use or test out the drm-next bits is to run a recent 12-CURRENT with no patches applied. then you can build the port or package via the ports tree under graphics/drm-next-kmod. it currently runs on my end under 12-CURRENT and 11-STABLE. cheers, -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"
Re: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 8:53 AM, Jan Bramkamp wrote: > On 25.02.18 16:48, Johannes M Dieterich wrote: >> Dear all, >> >> Please CC me as I am not subscribed. >> >> On behalf of the FreeBSDDesktop team and thanks to the tireless efforts >> of Johannes Lundberg and Hans Petter Selasky (hselasky), I am pleased to >> report that the graphics/drm-next-kmod port just received an update to >> Linux level 4.11 KMS/DRM for amdgpu, radeon, and i915 for both recent >> CURRENT and 11-STABLE. >> >> We have tested this on a range of hardware ourselves: >> * Haswell >> * Broadwell >> * Skylake >> * Evergreen >> * Kaveri (both radeon and amgpu KMS) >> * Carrizo >> * Polaris >> >> Needless to say, the possible space of hardware this could run on is >> significantly larger. Hence, if you find issues and/or want to propose >> patches, please do so at our development github: >> >> https://github.com/FreeBSDDesktop/kms-drm >> >> We absolutely do welcome contributions! >> >> Johannes > > Thx for your hard work. The drm-next-kmod port enabled me to finally > replace my ageing Thinkpad X220 with newer hardware. > > The latest update (g20180117_3 -> 4.11.g20180224) to the drm-next-kmod > port introduced a regression which causes Xorg on my T470s running > 12-current from a few days ago to fail at startup stating that it > didn't find any screen. (removing freebsd-stable@ from this reply since this is a current system) interesting, so Xorg complains about no displays being present if i understand correctly? can you verify that the i915 module is being loaded at boot, kld stat should show something like this: $ kldstat |grep i915 7 1 0x82f38000 11f615 i915kms.ko If it is present, can you also verify that you are a member of the "video" group? And failing that it will be helpful to post your dmesg and Xorg.log.0 to help triage this. Cheers, -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 9:03 AM, Hadi Rezaee wrote: > Hello there, > My laptop is running FreeBSD-12 CURRENT, and i hadnt any problem with my > graphic before upgrading drm-next (g20180117_3 -> 4.11.g20180224). But now > it getting failed. Tried to build from source, but same result. > Laptop model: Lenovo E470 > (removing stable since this is a potential issue on CURRENT) we'll need more details to help triage and hopefully fix this issue. what errors are you seeing? are you having problems loading the driver, or is Xorg having issues? -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 2:30 PM, Hadi Rezaee wrote: > Hello Pete, sorry I’m on trip so i cannot output the logs in proper > way. About i915 kernel module please refer to screen shot. > > I can confirm that i915 module is not getting loaded normaly at system > startup, so kldstat shows nothing. > > Yes, the user is already in video group. (Generally didnt changed > anything on system config, just updated pkg and this happend) thanks for posting the screen shot - it looks like your kernel and world may not be recent enough to load the kld. i'd suggest pulling the latest code from svn or git for 12-CURRENT then removing and reinstalling the drm-next-kmod pkg after you have booted into this fresh checkout. that's the first thing that comes to my mind when seeing that your kernel is unable to handle these modules. you also may want to remove the drm-next-kmod package and ensure there are no artifacts left behind in /boot/modules/ that were installed via the pkg, then re-install from the upstream pkg servers. hope this helps, -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: update of graphics/drm-next-kmod to Linux 4.11 level for recent CURRENT and 11-STABLE
On 2/28/18 2:47 PM, Hadi Rezaee wrote: > Thanks Pete, i’ll try your solution. But just wanted to report back > the system current revision: r329639 > > sounds great, let me know how it looks. i suggest we move the rest of this discussion to the freebsd-...@freebsd.org list so we don't SPAM the -current list. cheers! -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: New ACPI Errors
On 02/16/2018 13:54, Pete Wright wrote: On 02/15/2018 13:37, Jung-uk Kim wrote: On 02/13/2018 17:34, Claude Buisson wrote: On 02/13/2018 22:49, Pete Wright wrote: Hello, I have started seeing a lot of these messages spam my system log: ACPI Error: No pointer back to namespace node in package 0xf8000f79a080 (20180209/dsargs-472) ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) ACPI Error: Method parse/execution failed \134_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) I noticed this starting from a CURRENT build i installed two weeks ago, and still see it from a world/kernel i built last night. two questions: 1) has anyone else noticed this? 2) is this something to worry about? i can help debug the issue but am not sure where to start poking. thanks! -pete Here I have ACPI Error: No pointer back to namespace node in package 0xf8000171f700 (20180209/dsargs-472) ACPI Error: AE_AML_INTERNAL, While resolving operands for [OpcodeName unavailable] (20180209/dswexec-606) ACPI Error: Method parse/execution failed \134_PR.CPU0._CST,AE_AML_INTERNAL (20180209/psparse-677) with svn 329142 on a Lenovo ThinkCentre M83 ACPI APIC Table: Claude Buisson I believe you can silence the errors with the attached patch. Please try it and let me know. hrm still getting errors: Feb 16 13:49:45 runner kernel: ACPI Error: No pointer back to namespace node in package 0xf80003c8c080 (20180209/dsargs-472) Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed \_SB.AC.ADJP, AE_AML_INTERNAL (20180209/psparse-677) Feb 16 13:49:45 runner kernel: ACPI Error: Method parse/execution failed \_SB.AC._PSR, AE_AML_INTERNAL (20180209/psparse-677) here's my diff: diff --git a/sys/contrib/dev/acpica/include/platform/acfreebsd.h b/sys/contrib/dev/acpica/include/platform/acfreebsd.h index 905dffb7a40..df89399a369 100644 --- a/sys/contrib/dev/acpica/include/platform/acfreebsd.h +++ b/sys/contrib/dev/acpica/include/platform/acfreebsd.h @@ -166,6 +166,7 @@ #define ACPI_UINTPTR_T uintptr_t +#define ACPI_IGNORE_PACKAGE_RESOLUTION_ERRORS #define ACPI_USE_DO_WHILE_0 #define ACPI_USE_LOCAL_CACHE #define ACPI_USE_NATIVE_DIVIDE hi there - i was wondering if anyone has taken a look at this issue. I am still seeing these ACPI errors on recent CURRENT systems: ACPI Error: No pointer back to namespace node in package 0xf803e71fff00 (20180313/dsargs-472) ACPI Error: Method parse/execution failed \134_SB.AC.ADJP, AE_AML_INTERNAL (20180313/psparse-677) ACPI Error: Method parse/execution failed \134_SB.AC._PSR, AE_AML_INTERNAL (20180313/psparse-677) I have two amd64 (skylake and kabylake) systems that are exhibiting this behavior and am more than happy to test patches or other things. cheers! -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"
Re: clang manual page?
On 04/05/2018 17:15, Steve Kargl wrote: This assumes that a gcc(1) is available on the system. % man gcc No manual entry for gcc If the system compiler is clang/clang++, then it ought to be documented better than it currently is. Ian's suggests for 'clang --help' is even worse % clang --help | grep -- -std -cl-std= OpenCL language standard to compile for. -std=Language standard to compile for -stdlib= C++ standard library to use Does == ? a quick google search turns up the following additional information: "clang supports the -std option, which changes what language mode clang uses. The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, c17, gnu17, and various aliases for those modes. If no -std option is specified, clang defaults to gnu11 mode. Many C99 and C11 features are supported in earlier modes as a conforming extension, with a warning. Use |-pedantic-errors| to request an error if a feature from a later standard revision is used in an earlier mode." https://clang.llvm.org/docs/UsersManual.html -p -- 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"
Re: Regression Resume Lenovo T450
On 05/03/2018 23:07, Manuel Stühn wrote: Since some time now CURRENT runs very smoothly on my Lenovo T450 in conjunction with drm-stable-kmod installed. WLAN, Suspense&Resume worked out of the box (at least ... until now). Due to pkg(8) complaining about wrong ABI of packages, I've made an update from r332385 (1200061) to r333091 (1200062), and now the T450 does not resume anymore; i have to hold the power button for some time to power it down. The ZFS-Boot-Environment I've made beforehand updating is still capable of resuming. I tried to find out which commit broke the resume for me by installing older kernels, but even installing r332385 kernel (into the actual r333091 userland) does not restore its capability to resume. Any ideas or hints? Which information can i provide to help investigating this matter? have you tried suspend/resume without having the drm-next kmod loaded? I have run into a couple instances of that breaking due to drm-next. if it does work w/o drm-next then it might be worth rebuilding the pkg locally (via "cd /usr/ports/graphics/drm-next-kmod && make package" for example) and see if that fixes it. there is also a sysctl knob i've set in the past to help in this area, i'll dig through my notes and see if i can find it... -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"
suspend/resume regression
hi there - i have an amd64 laptop that's been running CURRENT for a while using both drm-next and drm-stable for graphics. during the past week or so i've run into issues with suspend resume...well technically resume has stopped working. i've tested a couple configurations and none have allowed my system to resume successfully: - drm-next installed with DMC firmware loaded - drm-next installed without DMC firmware loaded (worked previously) - drm-stable with DMC - drm-stable without DMC - no drm modules loaded. I've also tested these configs with the following sysctl set to 0 and 1: hw.acpi.reset_video at this point i'd like to help find what the regression i'm running into is, so any pointers on how i can help? the system seems to boot and i'm pretty sure i can ssh into it most times, just not sure what info i should grab to help. nothing of interest in messages or dmesg buffer either. cheers, -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"
Re: suspend/resume regression
On 05/13/2018 08:58, Theron wrote: Hi! I'm also seeing issues, not as severe as Pete, but after I resume (which works, with drm-next and DMC firmware), the system becomes sluggish. It feels like I/O takes more time, and graphics are sluggish (very sientific, I know, but for instance git operations are much slower after a resume). I know there's been an update to acpica between my system updates, when this started to happen, but I haven't had time to revert that update and test again. I will try to do that and report back. Regards Hi Niclas, I used drm-next on Skylake with issues which sound similar. Resuming from suspend, or simply switching the laptop display output off and on from xrandr, resulted in graphics sluggishness (drop to 30fps in glxgears) and graphical corruption in Xorg apps, which persisted even after restarting these apps. Switching to drm-stable made the problems go away; I haven't had time to figure out what -next is doing differently to cause them. Pete's issue sounds more severe, and unrelated as it happens without drm loaded. My kernel is two weeks out of date (r333093), so I need to check whether the more recent changes affect my system as well. so i've done a bit more debugging on my end. i've even installed the 11.2-BETA branch last night since 11-STABLE worked without issues about a month or so ago. i've set "debug.acpi.resume_beep=1" and when resuming after entering an S3 sleep state the bell rings and does not stop until i do a hard reset (both with i915kms loaded and unloaded). kinda at a loss as to how this could break both CURRENT and basically 11-STABLE. i'm going to make a ubuntu live image and test that, my laptop is a System76 laptop that shipped with ubuntu originally. if that is broken as well then i guess this could be a hardware issue. the good news is that 11.2-BETA and drm-next works great (aside from suspend/resume) :) -p -- 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"
Re: suspend/resume regression
On 05/13/2018 10:27, Pete Wright wrote: On 05/13/2018 08:58, Theron wrote: Hi! I'm also seeing issues, not as severe as Pete, but after I resume (which works, with drm-next and DMC firmware), the system becomes sluggish. It feels like I/O takes more time, and graphics are sluggish (very sientific, I know, but for instance git operations are much slower after a resume). I know there's been an update to acpica between my system updates, when this started to happen, but I haven't had time to revert that update and test again. I will try to do that and report back. Regards Hi Niclas, I used drm-next on Skylake with issues which sound similar. Resuming from suspend, or simply switching the laptop display output off and on from xrandr, resulted in graphics sluggishness (drop to 30fps in glxgears) and graphical corruption in Xorg apps, which persisted even after restarting these apps. Switching to drm-stable made the problems go away; I haven't had time to figure out what -next is doing differently to cause them. Pete's issue sounds more severe, and unrelated as it happens without drm loaded. My kernel is two weeks out of date (r333093), so I need to check whether the more recent changes affect my system as well. so i've done a bit more debugging on my end. i've even installed the 11.2-BETA branch last night since 11-STABLE worked without issues about a month or so ago. i've set "debug.acpi.resume_beep=1" and when resuming after entering an S3 sleep state the bell rings and does not stop until i do a hard reset (both with i915kms loaded and unloaded). kinda at a loss as to how this could break both CURRENT and basically 11-STABLE. i'm going to make a ubuntu live image and test that, my laptop is a System76 laptop that shipped with ubuntu originally. if that is broken as well then i guess this could be a hardware issue. ubuntu live image suspends/resumes without issue so this certainly seems to be a freebsd issue unfortunately. i guess next step is to attempt to find a working CURRENT snapshot that does suspend/resume without issue then start looking at commits? -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"
Re: suspend/resume regression
On 05/14/2018 01:18, Niclas Zeising wrote: On 05/13/18 21:44, Pete Wright wrote: On 05/13/2018 10:27, Pete Wright wrote: On 05/13/2018 08:58, Theron wrote: Hi! I'm also seeing issues, not as severe as Pete, but after I resume (which works, with drm-next and DMC firmware), the system becomes sluggish. It feels like I/O takes more time, and graphics are sluggish (very sientific, I know, but for instance git operations are much slower after a resume). I know there's been an update to acpica between my system updates, when this started to happen, but I haven't had time to revert that update and test again. I will try to do that and report back. Regards Hi Niclas, I used drm-next on Skylake with issues which sound similar. Resuming from suspend, or simply switching the laptop display output off and on from xrandr, resulted in graphics sluggishness (drop to 30fps in glxgears) and graphical corruption in Xorg apps, which persisted even after restarting these apps. Switching to drm-stable made the problems go away; I haven't had time to figure out what -next is doing differently to cause them. Pete's issue sounds more severe, and unrelated as it happens without drm loaded. My kernel is two weeks out of date (r333093), so I need to check whether the more recent changes affect my system as well. so i've done a bit more debugging on my end. i've even installed the 11.2-BETA branch last night since 11-STABLE worked without issues about a month or so ago. i've set "debug.acpi.resume_beep=1" and when resuming after entering an S3 sleep state the bell rings and does not stop until i do a hard reset (both with i915kms loaded and unloaded). kinda at a loss as to how this could break both CURRENT and basically 11-STABLE. i'm going to make a ubuntu live image and test that, my laptop is a System76 laptop that shipped with ubuntu originally. if that is broken as well then i guess this could be a hardware issue. ubuntu live image suspends/resumes without issue so this certainly seems to be a freebsd issue unfortunately. i guess next step is to attempt to find a working CURRENT snapshot that does suspend/resume without issue then start looking at commits? Hi! It's a bit worrisome that your regression occurs both on CURRENT and STABLE. There was an update to both drm-next-kmod and drm-stable-kmod last week, but both are very minor. One question, did you install from pkg or compile from ports? i create a package directly from the github mirror of the ports tree (i.e. make package; pkg install...). -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"
Re: suspend/resume regression
On 05/14/2018 20:35, Theron wrote: On 05/13/18 15:44, Pete Wright wrote: so i've done a bit more debugging on my end. i've even installed the 11.2-BETA branch last night since 11-STABLE worked without issues about a month or so ago. i've set "debug.acpi.resume_beep=1" and when resuming after entering an S3 sleep state the bell rings and does not stop until i do a hard reset (both with i915kms loaded and unloaded). kinda at a loss as to how this could break both CURRENT and basically 11-STABLE. i'm going to make a ubuntu live image and test that, my laptop is a System76 laptop that shipped with ubuntu originally. if that is broken as well then i guess this could be a hardware issue. ubuntu live image suspends/resumes without issue so this certainly seems to be a freebsd issue unfortunately. i guess next step is to attempt to find a working CURRENT snapshot that does suspend/resume without issue then start looking at commits? -pete Returning to the original issue: complete failure to resume, rather than slowness: I am affected as well. CURRENT r333093 worked, but r333582 fails in a manner consistent with what Pete has described, with or without drm loaded. There have been a few commit messages mentioning ACPI in that window of history, which I will use to help me bisect when I have time. do you think it may be due to r333150 "Merge ACPICA 20180427." not sure if that's been merged into 11-STABLE, but it seems to touch a lot of bits that could effect suspend/resume. -p -- 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"
Re: suspend/resume regression
On 05/12/2018 19:25, Pete Wright wrote: hi there - i have an amd64 laptop that's been running CURRENT for a while using both drm-next and drm-stable for graphics. during the past week or so i've run into issues with suspend resume...well technically resume has stopped working. i've tested a couple configurations and none have allowed my system to resume successfully: - drm-next installed with DMC firmware loaded - drm-next installed without DMC firmware loaded (worked previously) - drm-stable with DMC - drm-stable without DMC - no drm modules loaded. I've also tested these configs with the following sysctl set to 0 and 1: hw.acpi.reset_video at this point i'd like to help find what the regression i'm running into is, so any pointers on how i can help? the system seems to boot and i'm pretty sure i can ssh into it most times, just not sure what info i should grab to help. nothing of interest in messages or dmesg buffer either. Closing the loop on this thread. Git commit 4e99d4e797ba9cea01897b6909b061db841f855a fixes this issue on my end. For more info there is a thread on this list named "Lag after resume culprit found" that has details. -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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/21/2018 10:07, Steve Kargl wrote: On Mon, May 21, 2018 at 02:40:50AM +0300, Rozhuk Ivan wrote: On Sun, 20 May 2018 21:10:28 +0200 Oliver Pinter wrote: One of the reasons for the deprecation and removal of the drm2 bits is that they prevent us from automatically loading the drm-next/stable-kmod kernel modules, since the two collide. Regards Then it wold be better to resolve this problem, rather then removing a working solution. What's about module versioning what in other cases works? May be just move old drm2 to ports? Why? "If it isn't broken, why fix it?" The conflict affects x86_64-*-freebsd aka amd64. The conflict does not affect any other architecture. The Makefile infrastructure can use MACHINE_ARCH to exclude drm2 from build of amd64. I don't use netgraph or any of the if_*.ko modules. Can we put all of that into ports? I don't use any scsi controllers, so those can go too. Why make it insanely fun for users to configure a FreeBSD system. to play devils advocate - why include a kernel module that causes conflicts for a vast majority of the laptop devices that you can purchase today (as well as for the foreseeable future), while forcing the up to date and actively developed driver to not work out of the box? IMHO it is issues like this (having out of date code that supports some edge cases) which makes it harder for developers to dog-food the actual OS they are developing on. Having things work on modern hardware by default seems like a great way to get more people on the platform testing and bugfixing things. The suggestion seems like a pretty good middle ground, people with older devices will still have workable code while also making it easier to continue to follow the state of the art in terms of hardware support. -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"
Re: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12
On 05/23/2018 00:41, David Pan wrote: Hi: how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not drive the Intel Wireless Card. please help me fix that, I have this working on my end under both 12-current and 11-stable. here's my configuration: output from "pciconf -lv" iwm0@pci0:3:0:0: class=0x028000 card=0x10108086 chip=0x24fd8086 rev=0x78 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 8265 / 8275' class = network to bring up the card i have added this entry to /etc/rc.conf: kld_list="if_iwm" then configuring the interface is the same as any other wifi as per the handbook, the device will be available as "iwm0". hope this helps, -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"
Re: Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12
On 05/24/2018 05:55, Mateusz Piotrowski wrote: On Wed, 23 May 2018 09:46:13 -0700 Pete Wright wrote: On 05/23/2018 00:41, David Pan wrote: how config the Intel Corporation Wireless 8265 / 8275 (rev 78) on FreeBSD 12?I installed FreeBSD 12 on my thinkpad t470p ,and can not drive the Intel Wireless Card. please help me fix that, I have this working on my end under both 12-current and 11-stable. here's my configuration: output from "pciconf -lv" iwm0@pci0:3:0:0: class=0x028000 card=0x10108086 chip=0x24fd8086 rev=0x78 hdr=0x00 vendor = 'Intel Corporation' device = 'Wireless 8265 / 8275' class = network to bring up the card i have added this entry to /etc/rc.conf: kld_list="if_iwm" then configuring the interface is the same as any other wifi as per the handbook, the device will be available as "iwm0". Shouldn't you load some firmware as well? That's what the iwm(4) manual and WiFi/FAQ wiki page[1] say. on my system loading if_iwm via the above rc.conf entry pulls in the appropriate firmware kld: $ kldstat|grep iwm 6 1 0x82c21000 14af0 if_iwm.ko 7 1 0x82c36000 1ba76f iwm8265fw.ko -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"
Re: [RFC] Deprecation and removal of the drm2 driver
On 05/31/2018 15:34, Oliver Pinter wrote: On Thursday, May 31, 2018, Johannes Lundberg wrote: On Thu, May 31, 2018 at 4:34 PM Joe Maloney wrote: I personally wish that more drivers, and firmware were separated from base. I'm not a committer If you are not a committer, how and why want to remove drm2 from the base system? Johannes did not start this threat. A committer, Niclas Zeising, did. Johannes has stepped up and done a ton of work (along with many others, some committers and some not) to get modern intel and amd GPU's working under freebsd. this was something that was a gaping hole in freebsd when this work started a bit over a year ago, and i'm not sure why more committers weren't embarrassed by this gap nor motivated to chip in. regardless - not sure why you'd take his comment out of context :/ the full quote was: "I'm not a committer but as I understand there's not pre-commit integration tests.. If one had that, plus that it would test build kmod ports against the pre-commit state of head as well, then maybe this would work." not really sure what's controversial about that statement which would prompt your reply - but i guess people dedicating their spare time to help create useful things for others shouldn't go unpunished. well i guess i broke my promise to ignore this bikeshed :( -p -- 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"
Re: cannot get touchpad mouse, no psm device, on Dell Precision 3520
On 06/07/2018 13:21, Anton Shterenlikht wrote: Please help get touchpad mouse on Dell Precision 3520. The usb mouse works fine. pciconf isn't really applicable here i think. does your dmesg buffer reference any PS/2 devices being detected? here is CURRENT detecting my synaptics touchpad: $ dmesg|grep psm psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 assuming it is being detected, have you set: moused_enable="YES" in /etc/rc.conf? If you have set that but do not see your touchpad being detected, and assuming it's a synaptics device, have you set the following in /boot/loader.conf? hw.psm.synaptics_support="1" Cheers, -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"
Re: cannot get touchpad mouse, no psm device, on Dell Precision 3520
On 06/07/2018 14:01, Anton Shterenlikht wrote: On Thu, Jun 07, 2018 at 01:34:31PM -0700, Pete Wright wrote: On 06/07/2018 13:21, Anton Shterenlikht wrote: Please help get touchpad mouse on Dell Precision 3520. The usb mouse works fine. pciconf isn't really applicable here i think. does your dmesg buffer reference any PS/2 devices being detected? here is CURRENT detecting my synaptics touchpad: $ dmesg|grep psm psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model Synaptics Touchpad, device ID 0 z> dmesg|grep psm z> Perhaps this relatively modern laptop uses a different device for its touchpad? hrm, looks like it should be a pretty well supported touchpad. did you try updating loader.conf and rebooting to see if it shows up? it looks like this is the touchpad vendor according to the dell/ubuntu docs: Aquantia Corp. DLL07A9:01 044E:120B -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"
Re: RealTek RTL8192E/RTL8192SE Wireless Support
On 06/13/2018 17:31, Stephen Albright wrote: Hello All: I have a Samsung NP-N140 with a RTL8192E card and I am having difficulty with it. I am running -current because if I read the man pages correctly, only 12-Current has the driver in rtwn (from the rtwn(4) man page). So, I built a custom kernel per the man pages: out of curiosity have you attempted to boot 12-CURRENT with the stock GENERIC kernel and attempt to load the kernel module by hand or via /etc/rc.conf? for example you could create this line in /etc/rc.conf: kld_list="rtwn.ko" then verify it is loaded after reboot by running "kldstat". cheers, -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"
buildkernel broken on if_ixl when EVDEV is enabled
howdy - just ran into an issue with building a kernel that has EVDEV enabled causing this error: --- kernel.full --- linking kernel.full ld: error: undefined symbol: ixl_iw_pf_init >>> referenced by if_ixl.c:900 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:900) >>> if_ixl.o:(ixl_if_init) ld: error: undefined symbol: ixl_iw_pf_stop >>> referenced by if_ixl.c:920 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:920) >>> if_ixl.o:(ixl_if_stop) ld: error: undefined symbol: ixl_iw_pf_attach >>> referenced by if_ixl.c:669 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:669) >>> if_ixl.o:(ixl_if_attach_post) ld: error: undefined symbol: ixl_iw_pf_detach >>> referenced by if_ixl.c:711 (/usr/home/pete/git/freebsd/sys/dev/ixl/if_ixl.c:711) >>> if_ixl.o:(ixl_if_detach) *** [kernel.full] Error code 1 building a standard GENERIC kernel works without issue. my "EVDEV" kern conf has the following two lines added: options EVDEV_SUPPORT # D10265 from phabricator device evdev Not sure if anyone else has seen this? -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"
Re: buildkernel broken on if_ixl when EVDEV is enabled
On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: Hi, check if you have 'options IXL_IW' in your kernel conf. It's removed from GENERIC. I had the same problem here with my customized conf. ah - that was totally it i think. i was lazy and just copied GENERIC to GENERIC-EVDEV so it got of sync. i've now re-created my EVDEV config to just include GENERIC. thanks for the heads up! -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"
Re: buildkernel broken on if_ixl when EVDEV is enabled
On 06/22/2018 10:38, Navdeep Parhar wrote: On 06/22/18 10:25, Pete Wright wrote: On 06/21/2018 20:47, Danilo Egêa Gondolfo wrote: Hi, check if you have 'options IXL_IW' in your kernel conf. It's removed from GENERIC. I had the same problem here with my customized conf. ah - that was totally it i think. i was lazy and just copied GENERIC to GENERIC-EVDEV so it got of sync. i've now re-created my EVDEV config to just include GENERIC. You can avoid your kernconf going out of sync by including GENERIC in it and then adding just your customizations. include GENERIC ident GENERIC-EVDEV options EVDEV_SUPPORT device evdev yep, that's exactly what i did - don't think my hasty response phrased things too well :) -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"
Re: atomic changes break drm-next-kmod?
On 07/03/2018 12:02, John Baldwin wrote:
On 7/3/18 11:28 AM, Niclas Zeising wrote:
On 07/03/18 17:02, O. Hartmann wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler schrieb:
It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v);
^
:1:7: note: instantiated into assembly here
andq $9223372036854775807,40672(%r14)
^
1 error generated.
*** [i915_drv.o] Error code 1
make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set, long, "orq %1,%0", "ir", v);
^
:1:6: note: instantiated into assembly here
orq $-9223372036854775808,40672(%r14)
^~
1 error generated.
*** [i915_gem.o] Error code 1
___
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"
It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is <
r335873,
those kmod compile well.
We are looking into why both the drm ports fail.
Regards
I haven't yet tested an amd64 kernel with this, but I think this change to
sys/amd64/include/atomic.h
might fix it:
Index: atomic.h
===
--- atomic.h(revision 335896)
+++ atomic.h(working copy)
@@ -446,10 +446,10 @@ ATOMIC_ASM(clear,int, "andl %1,%0", "ir", ~
ATOMIC_ASM(add,int, "addl %1,%0", "ir", v);
ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v);
-ATOMIC_ASM(set, long, "orq %1,%0", "ir", v);
-ATOMIC_ASM(clear,long, "andq %1,%0", "ir", ~v);
-ATOMIC_ASM(add, long, "addq %1,%0", "ir", v);
-ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v);
+ATOMIC_ASM(set, long, "orq %1,%0", "er", v);
+ATOMIC_ASM(clear,long, "andq %1,%0", "er", ~v);
+ATOMIC_ASM(add, long, "addq %1,%0", "er", v);
+ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v);
#define ATOMIC_LOADSTORE(TYPE) \
ATOMIC_LOAD(TYPE); \
i've just built a kernel with this patch applied, rebooted into it and
was able to build the drm-next-kmod port. i am also running X without
issues so far with this configuration.
cheers,
-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"
Re: atomic changes break drm-next-kmod?
On 07/03/2018 14:17, Pete Wright wrote: On 07/03/2018 12:02, John Baldwin wrote: On 7/3/18 11:28 AM, Niclas Zeising wrote: On 07/03/18 17:02, O. Hartmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Tue, 3 Jul 2018 10:19:57 -0400 Michael Butler schrieb: It seems recent changes (SVN r335873?) may have broken drm-next-kmod .. --- i915_drv.o --- In file included from i915_drv.c:30: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37: In file included from /usr/src/sys/sys/systm.h:44: ./machine/atomic.h:450:29: error: invalid operand for instruction ATOMIC_ASM(clear, long, "andq %1,%0", "ir", ~v); ^ :1:7: note: instantiated into assembly here andq $9223372036854775807,40672(%r14) ^ 1 error generated. *** [i915_drv.o] Error code 1 make[3]: stopped in /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915 --- i915_gem.o --- In file included from i915_gem.c:28: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38: In file included from /usr/src/sys/sys/malloc.h:42: In file included from /usr/src/sys/sys/systm.h:44: ./machine/atomic.h:449:29: error: invalid operand for instruction ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); ^ :1:6: note: instantiated into assembly here orq $-9223372036854775808,40672(%r14) ^~ 1 error generated. *** [i915_gem.o] Error code 1 ___ 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" It breaks also graphics/drm-stable-kmod (see PR 229484, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you described above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < r335873, those kmod compile well. We are looking into why both the drm ports fail. Regards I haven't yet tested an amd64 kernel with this, but I think this change to sys/amd64/include/atomic.h might fix it: Index: atomic.h === --- atomic.h (revision 335896) +++ atomic.h (working copy) @@ -446,10 +446,10 @@ ATOMIC_ASM(clear, int, "andl %1,%0", "ir", ~ ATOMIC_ASM(add, int, "addl %1,%0", "ir", v); ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v); -ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); -ATOMIC_ASM(clear, long, "andq %1,%0", "ir", ~v); -ATOMIC_ASM(add, long, "addq %1,%0", "ir", v); -ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v); +ATOMIC_ASM(set, long, "orq %1,%0", "er", v); +ATOMIC_ASM(clear, long, "andq %1,%0", "er", ~v); +ATOMIC_ASM(add, long, "addq %1,%0", "er", v); +ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v); #define ATOMIC_LOADSTORE(TYPE) \ ATOMIC_LOAD(TYPE); \ i've just built a kernel with this patch applied, rebooted into it and was able to build the drm-next-kmod port. i am also running X without issues so far with this configuration. oh neat - looks like this may have triggered a kernel panic. fortunately i was able to savecore. here's the output of my info file: info: Version String: FreeBSD 12.0-CURRENT #7 d7ac1268f3a(master)-dirty: Tue Jul 3 13:53:50 PDT 2018 pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV Panic String: Duplicate free of 0xf8010ac59000 from zone 0xf800340935a0(i915_gem_request) slab 0xf8010ac43af0(0) i didn't build a kernel.debug file unfortunately, but here's the output of my core.txt file, not sure how helpful it is: BFD: /bootpool/boot/kernel/kernel: invalid relocation type 37 BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/home/pete/git/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276 BFD: /bootpool/boot/kernel/kernel: invalid relocation type 37 BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail /usr/home/pete/git/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276 /dev/stdin:1: Error in sourced command file: Cannot acce
Re: atomic changes break drm-next-kmod?
On 07/03/2018 15:12, Pete Wright wrote: On 07/03/2018 14:17, Pete Wright wrote: On 07/03/2018 12:02, John Baldwin wrote: On 7/3/18 11:28 AM, Niclas Zeising wrote: On 07/03/18 17:02, O. Hartmann wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Am Tue, 3 Jul 2018 10:19:57 -0400 Michael Butler schrieb: It seems recent changes (SVN r335873?) may have broken drm-next-kmod .. --- i915_drv.o --- In file included from i915_drv.c:30: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35: In file included from /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37: In file included from /usr/src/sys/sys/systm.h:44: ./machine/atomic.h:450:29: error: invalid operand for instruction ATOMIC_ASM(clear, long, "andq %1,%0", "ir", ~v); ^ :1:7: note: instantiated into assembly here andq $9223372036854775807,40672(%r14) ^ 1 error generated. *** [i915_drv.o] Error code 1 make[3]: stopped in /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915 --- i915_gem.o --- In file included from i915_gem.c:28: In file included from /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38: In file included from /usr/src/sys/sys/malloc.h:42: In file included from /usr/src/sys/sys/systm.h:44: ./machine/atomic.h:449:29: error: invalid operand for instruction ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); ^ :1:6: note: instantiated into assembly here orq $-9223372036854775808,40672(%r14) ^~ 1 error generated. *** [i915_gem.o] Error code 1 ___ 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" It breaks also graphics/drm-stable-kmod (see PR 229484, https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you described above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < r335873, those kmod compile well. We are looking into why both the drm ports fail. Regards I haven't yet tested an amd64 kernel with this, but I think this change to sys/amd64/include/atomic.h might fix it: Index: atomic.h === --- atomic.h (revision 335896) +++ atomic.h (working copy) @@ -446,10 +446,10 @@ ATOMIC_ASM(clear, int, "andl %1,%0", "ir", ~ ATOMIC_ASM(add, int, "addl %1,%0", "ir", v); ATOMIC_ASM(subtract, int, "subl %1,%0", "ir", v); -ATOMIC_ASM(set, long, "orq %1,%0", "ir", v); -ATOMIC_ASM(clear, long, "andq %1,%0", "ir", ~v); -ATOMIC_ASM(add, long, "addq %1,%0", "ir", v); -ATOMIC_ASM(subtract, long, "subq %1,%0", "ir", v); +ATOMIC_ASM(set, long, "orq %1,%0", "er", v); +ATOMIC_ASM(clear, long, "andq %1,%0", "er", ~v); +ATOMIC_ASM(add, long, "addq %1,%0", "er", v); +ATOMIC_ASM(subtract, long, "subq %1,%0", "er", v); #define ATOMIC_LOADSTORE(TYPE) \ ATOMIC_LOAD(TYPE); \ i've just built a kernel with this patch applied, rebooted into it and was able to build the drm-next-kmod port. i am also running X without issues so far with this configuration. oh neat - looks like this may have triggered a kernel panic. fortunately i was able to savecore. here's the output of my info file: info: Version String: FreeBSD 12.0-CURRENT #7 d7ac1268f3a(master)-dirty: Tue Jul 3 13:53:50 PDT 2018 pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV Panic String: Duplicate free of 0xf8010ac59000 from zone 0xf800340935a0(i915_gem_request) slab 0xf8010ac43af0(0) i didn't build a kernel.debug file unfortunately, but here's the output of my core.txt file, not sure how helpful it is: darn, hit send too soon - i was looking in wrong place for debug kernel - here is some hopefully more helpful info: $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1 Unread portion of the kernel message buffer: WARNING !state->acquire_ctx failed at drm_atomic.c:634 WARNING !state->acquire_ctx failed at drm_atomic.c:270 WARNING !state->acquire_ctx failed at drm_atomic.c:634 WARNING !state->acquire_ctx failed at drm_atomi
Re: atomic changes break drm-next-kmod?
On 07/03/2018 15:29, John Baldwin wrote: That seems like kgdb is looking at the wrong CPU. Can you use 'info threads' and look for threads not stopped in 'sched_switch' and get their backtraces? You could also just do 'thread apply all bt' and put that file at a URL if that is easiest. sure thing John - here's a gist of "thread apply all bt" https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed cheers! -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"
Re: atomic changes break drm-next-kmod?
On 07/03/2018 15:56, John Baldwin wrote: On 7/3/18 3:34 PM, Pete Wright wrote: On 07/03/2018 15:29, John Baldwin wrote: That seems like kgdb is looking at the wrong CPU. Can you use 'info threads' and look for threads not stopped in 'sched_switch' and get their backtraces? You could also just do 'thread apply all bt' and put that file at a URL if that is easiest. sure thing John - here's a gist of "thread apply all bt" https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed That doesn't look right at all. Are you sure the kernel matches the vmcore? Also, which kgdb version are you using? yea i agree that doesn't look right at all. here is my setup: $ which kgdb /usr/bin/kgdb $ kgdb GNU gdb 6.1.1 [FreeBSD] $ ls -lh /var/crash/vmcore.1 -rw--- 1 root wheel 1.6G Jul 3 15:03 /var/crash/vmcore.1 $ ls -l /usr/lib/debug/boot/kernel/kernel.debug -r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54 /usr/lib/debug/boot/kernel/kernel.debug and i invoke kgdb like so: $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1 here's a gist of my full gdb session: http://termbin.com/krsn dunno - maybe i have a bad core dump? regardless, more than happy to help so let me know if i should try anything else or patches etc.. -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"
Re: atomic changes break drm-next-kmod?
On 07/05/2018 10:10, John Baldwin wrote:
On 7/3/18 5:10 PM, Pete Wright wrote:
On 07/03/2018 15:56, John Baldwin wrote:
On 7/3/18 3:34 PM, Pete Wright wrote:
On 07/03/2018 15:29, John Baldwin wrote:
That seems like kgdb is looking at the wrong CPU. Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces? You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.
sure thing John - here's a gist of "thread apply all bt"
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
That doesn't look right at all. Are you sure the kernel matches the
vmcore? Also, which kgdb version are you using?
yea i agree that doesn't look right at all. here is my setup:
$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw--- 1 root wheel 1.6G Jul 3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54
/usr/lib/debug/boot/kernel/kernel.debug
and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
here's a gist of my full gdb session:
http://termbin.com/krsn
dunno - maybe i have a bad core dump? regardless, more than happy to
help so let me know if i should try anything else or patches etc..
Can you try installing gdb from ports and using /usr/local/bin/kgdb?
that seems to have done the trick, at least the output looks more
encouraging.
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
here's my full kgdb session:
http://termbin.com/qa4f
i don't see any threads not in "sched_switch" though :(
-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"
Re: atomic changes break drm-next-kmod?
On 07/05/2018 12:12, Hans Petter Selasky wrote:
On 07/05/18 20:59, Hans Petter Selasky wrote:
On 07/05/18 19:48, Pete Wright wrote:
On 07/05/2018 10:10, John Baldwin wrote:
On 7/3/18 5:10 PM, Pete Wright wrote:
On 07/03/2018 15:56, John Baldwin wrote:
On 7/3/18 3:34 PM, Pete Wright wrote:
On 07/03/2018 15:29, John Baldwin wrote:
That seems like kgdb is looking at the wrong CPU. Can you use
'info threads' and look for threads not stopped in 'sched_switch'
and get their backtraces? You could also just do 'thread apply
all bt' and put that file at a URL if that is easiest.
sure thing John - here's a gist of "thread apply all bt"
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
That doesn't look right at all. Are you sure the kernel matches the
vmcore? Also, which kgdb version are you using?
yea i agree that doesn't look right at all. here is my setup:
$ which kgdb
/usr/bin/kgdb
$ kgdb
GNU gdb 6.1.1 [FreeBSD]
$ ls -lh /var/crash/vmcore.1
-rw--- 1 root wheel 1.6G Jul 3 15:03 /var/crash/vmcore.1
$ ls -l /usr/lib/debug/boot/kernel/kernel.debug
-r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54
/usr/lib/debug/boot/kernel/kernel.debug
and i invoke kgdb like so:
$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
/var/crash/vmcore.1
here's a gist of my full gdb session:
http://termbin.com/krsn
dunno - maybe i have a bad core dump? regardless, more than happy to
help so let me know if i should try anything else or patches etc..
Can you try installing gdb from ports and using /usr/local/bin/kgdb?
that seems to have done the trick, at least the output looks more
encouraging.
--- trap 0, rip = 0, rsp = 0, rbp = 0 ---
KDB: enter: panic
__curthread () at ./machine/pcpu.h:231
231 __asm("movq %%gs:%1,%0" : "=r" (td)
here's my full kgdb session:
http://termbin.com/qa4f
i don't see any threads not in "sched_switch" though :(
Hi,
The problem may be that the patch to enable atomic inlining of all
macros forgot to set the SMP keyword which means SMP is not defined
at all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
/*
* For userland, always use lock prefixes so that the binaries will run
* on both SMP and !SMP systems.
*/
#if defined(SMP) || !defined(_KERNEL)
#define MPLOCKED "lock ; "
#else
#define MPLOCKED
#endif
Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with
DEBUG_FLAGS="-DSMP" ?
and similarly the drm-next package?
Also please find attached a patch for amd64.
i have been running this patch for about 4hours. previous uptime before
this patch was under 1hr. i've attached and detached HDMI displays and
gone through several suspend/resume cycles as well without any issues.
to be clear - since i'm not sure this is was your intent - i applied the
patch, rebuilt/installed a new kernel. i did *not* use the "-DSMP"
flags for linuxkpi or the drm-next module.
cheers,
-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"
AWS M5 ena issues
hi there - this is in relation to this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225791 "ena driver causing kernel panics on AWS EC2" reading through the thread, and Colin's blog post on the new M5 instance types, it looks like the issues people are running into are related to NVMe devices fronting EBS block stores. My question is is this a discreet issue from other anomalies people have seen with ena network devices. For example, on some currently lightly loaded m5.large instances I have been seeing this in the logs pretty regularly: ena0: device is going DOWN ena0: device is going UP ena0: queue 0 - cpu 0 ena0: queue 1 - cpu 1 These systems were previously running 11.1-RELEASE, which I upgraded to 11.2-RELEASE via "freebsd-update". These messages only started showing up after I had completed the upgrade.2 from reading the bug report above though it's not clear as to the state of the ena drivers themselves. Are they considered unstable on 11.2-RELEASE? Cheers, -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"
Re: AWS M5 ena issues [IGNORE]
sorry - this was sent to incorrect list - please ignore. sorry for the noise! -pete On 07/06/2018 16:22, Pete Wright wrote: hi there - this is in relation to this ticket: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=225791 "ena driver causing kernel panics on AWS EC2" reading through the thread, and Colin's blog post on the new M5 instance types, it looks like the issues people are running into are related to NVMe devices fronting EBS block stores. My question is is this a discreet issue from other anomalies people have seen with ena network devices. For example, on some currently lightly loaded m5.large instances I have been seeing this in the logs pretty regularly: ena0: device is going DOWN ena0: device is going UP ena0: queue 0 - cpu 0 ena0: queue 1 - cpu 1 These systems were previously running 11.1-RELEASE, which I upgraded to 11.2-RELEASE via "freebsd-update". These messages only started showing up after I had completed the upgrade.2 from reading the bug report above though it's not clear as to the state of the ena drivers themselves. Are they considered unstable on 11.2-RELEASE? Cheers, -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"
Re: atomic changes break drm-next-kmod?
On 07/06/2018 03:15, Hans Petter Selasky wrote:
On 07/06/18 11:14, Johannes Lundberg wrote:
On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov
wrote:
On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
On 07/06/18 00:02, Warner Losh wrote:
On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin mailto:j...@freebsd.org>> wrote:
On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky
wrote:
>> On 07/05/18 20:59, Hans Petter Selasky wrote:
>>> On 07/05/18 19:48, Pete Wright wrote:
>>>>
>>>>
>>>> On 07/05/2018 10:10, John Baldwin wrote:
>>>>> On 7/3/18 5:10 PM, Pete Wright wrote:
>>>>>>
>>>>>> On 07/03/2018 15:56, John Baldwin wrote:
>>>>>>> On 7/3/18 3:34 PM, Pete Wright wrote:
>>>>>>>> On 07/03/2018 15:29, John Baldwin wrote:
>>>>>>>>> That seems like kgdb is looking at the wrong CPU.
Can
you use
>>>>>>>>> 'info threads' and look for threads not stopped in
'sched_switch'
>>>>>>>>> and get their backtraces? You could also just do
'thread
apply
>>>>>>>>> all bt' and put that file at a URL if that is
easiest.
>>>>>>>>>
>>>>>>>> sure thing John - here's a gist of "thread apply
all bt"
>>>>>>>>
>>>>>>>>
https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
<https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
>>>>>>> That doesn't look right at all. Are you sure the
kernel
matches the
>>>>>>> vmcore? Also, which kgdb version are you using?
>>>>>>>
>>>>>> yea i agree that doesn't look right at all. here is my
setup:
>>>>>>
>>>>>> $ which kgdb
>>>>>> /usr/bin/kgdb
>>>>>> $ kgdb
>>>>>> GNU gdb 6.1.1 [FreeBSD]
>>>>>> $ ls -lh /var/crash/vmcore.1
>>>>>> -rw--- 1 root wheel 1.6G Jul 3 15:03
/var/crash/vmcore.1
>>>>>> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
>>>>>> -r-xr-xr-x 1 root wheel 87840496 Jul 3 13:54
>>>>>> /usr/lib/debug/boot/kernel/kernel.debug
>>>>>>
>>>>>> and i invoke kgdb like so:
>>>>>> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug
/var/crash/vmcore.1
>>>>>>
>>>>>> here's a gist of my full gdb session:
>>>>>> http://termbin.com/krsn
>>>>>>
>>>>>> dunno - maybe i have a bad core dump? regardless, more
than
happy to
>>>>>> help so let me know if i should try anything else or
patches
etc..
>>>>> Can you try installing gdb from ports and using
/usr/local/bin/kgdb?
>>>>>
>>>>
>>>> that seems to have done the trick, at least the output
looks
more
>>>> encouraging.
>>>>
>>>> --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>>>> KDB: enter: panic
>>>>
>>>> __curthread () at ./machine/pcpu.h:231
>>>> 231 __asm("movq %%gs:%1,%0" : "=r" (td)
>>>>
>>>>
>>>> here's my full kgdb session:
>>>> http://termbin.com/qa4f
>>>>
>>>> i don't see any threads not in "sched_switch" though :(
>>>
>>> Hi,
>>>
>>> The problem may be that the patch to enable atomic inlining
of all
>>> macros forgot to set the SMP keyword which means SMP is not
defined at
>>> all for KLD's so all non-kernel atomic usage is with
MPLOCKED
empty!
> Problem is that out-of-tree modules build does not have
opt*.h
files
> from the kernel. UP config is a valid one, flipping some
option's
> default value does not solve the problem.
Yes, but using the lock prefix in a generic module is ok (it
will
still
work, just not quite as fast) whereas the lack of lock is
fatal on
SMP.
Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On 07/12/2018 12:25, Yuri wrote: On 07/03/18 12:45, Yuri wrote: I updated the laptop to r335884 last night, and 'service wpa_supplicant start wlan0' doesn't succeed any more. kernel is supposed to create the network interface 'run0', but it doesn't. This is the immediate reason why wpa_supplicant fails. The non-creation of 'run0' is a regression. I don't know of any workaround. The steps 'mergemaster -p' and 'mergemaster' were done during the upgrade, so /etc is updated. Bug report for this problem: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229738 This is a very serious regression breaking WiFi. sorry if i missed something (don't see details in the bug report) - is the issue that the run(4) kernel module is not being loaded? is there an error when the system attempts to load the kernel module in the dmesg buffer? if it is not being loaded automagically what happens when you manually load the module via "kldload" or by updating rc.conf? -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"
Re: [regression] The USB WiFi card stopped working: if_run doesn't create the 'run0' interface any more
On 07/12/2018 21:15, Yuri wrote: On 07/12/18 13:38, Pete Wright wrote: sorry if i missed something (don't see details in the bug report) - is the issue that the run(4) kernel module is not being loaded? is there an error when the system attempts to load the kernel module in the dmesg buffer? if it is not being loaded automagically what happens when you manually load the module via "kldload" or by updating rc.conf? No errors while the kernel module is loaded. The problem is that when the card is inserted wlan0 isn't automatically created. It also isn't created during boot with the card in. I think that there were some changes in devd that caused this regression. interesting, i ran into an issue with a kernel/world i updated to on thursday where my USB mouse was non-functional and i suspect something funky happened with devd as well. one suggestion i heard was to enable devmatch which i haven't had a chance to test yet. throwing it out there as it may help you. cheers, -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"
ntpd as ntpd user question
hello - i am testing out the new ntpd that was committed yesterday and
am attempting to run as non-root. i've created a ntpd user/group, and
verified permissions look good on pertinent directories. i am running
into an issue with the rc script tho - it's complaining about multiple
pid files being specified?
$ sudo /etc/rc.d/ntpd start
Starting ntpd.
ntpd error: only one pidfile option allowed
ntpd - NTP daemon program - Ver. 4.2.8p11
Usage: ntpd [ - [] | --[{=| }] ]... \
[ ... ]
Try 'ntpd --help' for more information.
/etc/rc.d/ntpd: WARNING: failed to start ntpd
has anyone else seen this issue? not sure if this is an issue with my
local config or not, i've read through the rc script and its not obvious
to me yet why it may be getting multiple pid arguments passed. the only
relevant bit i have set in rc.conf is:
$ grep ntpd /etc/rc.conf
ntpd_enable="YES"
thanks!
-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"
Re: ntpd as ntpd user question
On 07/21/2018 09:47, Ian Lepore wrote:
On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
hello - i am testing out the new ntpd that was committed yesterday and
am attempting to run as non-root. i've created a ntpd user/group, and
verified permissions look good on pertinent directories. i am running
into an issue with the rc script tho - it's complaining about multiple
pid files being specified?
$ sudo /etc/rc.d/ntpd start
Starting ntpd.
ntpd error: only one pidfile option allowed
ntpd - NTP daemon program - Ver. 4.2.8p11
Usage: ntpd [ - [] | --[{=| }] ]... \
[ ... ]
Try 'ntpd --help' for more information.
/etc/rc.d/ntpd: WARNING: failed to start ntpd
has anyone else seen this issue? not sure if this is an issue with my
local config or not, i've read through the rc script and its not obvious
to me yet why it may be getting multiple pid arguments passed. the only
relevant bit i have set in rc.conf is:
$ grep ntpd /etc/rc.conf
ntpd_enable="YES"
thanks!
-pete
You say you created an ntpd user/group, that seems to imply you didn't
run mergemaster (which would have done that). If that's the case, you
probably also didn't get /etc/defaults/rc.conf updated, so it still has
the old ntpd_flags that includes the pidfile (which is now provided by
the startup script and shouldn't be set in ntpd_flags).
If all of that is the wrong guess, let me know and we'll figure it out.
that's Ian - that's most likely it (defaults/rc.conf). i did run
mergemaster but i suspect i didn't run it correctly b/c it didn't copy
over any files, nor create the ntpd uid/gid. my buildworld script does
a "mergemaster -m $CHECKOUT -a". i'll re-read the man page today and
update my scripts accordingly.
thanks again for the bread-crumb!
-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"
Re: ntpd as ntpd user question
On 07/21/2018 10:14, Ian Lepore wrote:
On Sat, 2018-07-21 at 10:11 -0700, Pete Wright wrote:
On 07/21/2018 09:47, Ian Lepore wrote:
On Sat, 2018-07-21 at 09:41 -0700, Pete Wright wrote:
hello - i am testing out the new ntpd that was committed
yesterday and
am attempting to run as non-root. i've created a ntpd
user/group, and
verified permissions look good on pertinent directories. i am
running
into an issue with the rc script tho - it's complaining about
multiple
pid files being specified?
$ sudo /etc/rc.d/ntpd start
Starting ntpd.
ntpd error: only one pidfile option allowed
ntpd - NTP daemon program - Ver. 4.2.8p11
Usage: ntpd [ - [] | --[{=| }] ]... \
[ ... ]
Try 'ntpd --help' for more information.
/etc/rc.d/ntpd: WARNING: failed to start ntpd
has anyone else seen this issue? not sure if this is an issue
with my
local config or not, i've read through the rc script and its not
obvious
to me yet why it may be getting multiple pid arguments passed.
the only
relevant bit i have set in rc.conf is:
$ grep ntpd /etc/rc.conf
ntpd_enable="YES"
thanks!
-pete
You say you created an ntpd user/group, that seems to imply you
didn't
run mergemaster (which would have done that). If that's the case,
you
probably also didn't get /etc/defaults/rc.conf updated, so it still
has
the old ntpd_flags that includes the pidfile (which is now provided
by
the startup script and shouldn't be set in ntpd_flags).
If all of that is the wrong guess, let me know and we'll figure it
out.
that's Ian - that's most likely it (defaults/rc.conf). i did run
mergemaster but i suspect i didn't run it correctly b/c it didn't
copy
over any files, nor create the ntpd uid/gid. my buildworld script
does
a "mergemaster -m $CHECKOUT -a". i'll re-read the man page today
and
update my scripts accordingly.
thanks again for the bread-crumb!
-pete
There's a "pre-world" stage of mergemaster (-Fp option I think) which
isn't needed often, but one of the times it is needed is apparently
when new user ids are added. (So I've been told, I've never much used
mergemaster myself). I think there are some words about it at the very
bottom of UPDATING.
so i was running the "pre-world" mergemaster, but i think what bit me
was relying on the "-a" switch. after reading UPDATING as you suggested
i re-ran mergemaster like so:
"sudo mergemaster -m $CHECKOUT -rvF"
which seems closer in-line with the documentation. i had a ton of stuff
missing, which would explain some funky behaviour i've seen in regards
to devd, so glad i sorted this out.
as someone RW mentions later in this thread, it would be sweet if
mergemaster could auto add users/groups. i missed this in the diff
during my pre-installworld mergemaster run. easily fixed - but def
something i'll have to keep my eye out for.
cheers,
-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"
Re: ntpd as ntpd user question
On 8/2/18 10:43 PM, Chris H wrote: On Mon, 23 Jul 2018 12:57:28 +0200 "Niclas Zeising" said On 07/21/18 19:56, RW wrote: > On Sat, 21 Jul 2018 11:14:45 -0600 > Ian Lepore wrote: > > >> There's a "pre-world" stage of mergemaster (-Fp option I think) which >> isn't needed often, but one of the times it is needed is apparently >> when new user ids are added. > > I wish mergemaster had an option to just add new users and groups, > rather than merging the files. etcupdate is usually pretty good at automatically merge updates to files without user interaction, even when the files are locally edited as well. For instance, I had no problem merging /etc/master.passwd and /etc/group for the ntp change. Regards -- Niclas FWIW I found mergemaster intimidating when I was first starting out. Not because I didn't understand patch(1)/diff(1). I was well familiar there. But I found it unintuitive. Despite the messages regarding it's usage. Anyway. I finally developed a strategy that worked for me. I start out with the standard mergemaster -p then the installworld But I implement the following mergemster, thusly mergemaster -vF It dispenses with asking about all the files that only have revision changes, and date differences, and just updates them, the -v portion, just keeps "enlightened" as to wtf is actually happening during the process. Then all that's left are just some 5-9 files I need to deal with, with mergemaster informing me that by default, it'll leave them for me, to look at later. To which I reply Y. Done. Knowing diff/patch, makes the resulting unmerged files a trivial task, requiring perhaps 5-10 minutes while still at the console. Then I reboot into the new system. this certainly sums up my experience and workflow now. if i were someone with more free time on my hands i'd look at adding an option to mergemaster to read in an env-var or the ~/.mergemasterrc file to use a diff program of choice. i remember when i used to admin IRIX systems we would use xdiff frequently when updates of software required updates to configs, being a junior admin at the time and having a decent gui to manage diffs certainly made me feel more confident about the changes i was making. but honestly this is such an edge case i haven't put any effort into hacking on this :) -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"
ix SR-IOV working
hello, i have a newly provisioned VPS system from Vultr which comes stock with a 10Gbe ix interface: ix0@pci0:1:0:0: class=0x02 card=0x082315d9 chip=0x15578086 rev=0x01 hdr=0x00 vendor = 'Intel Corporation' device = '82599 10 Gigabit Network Connection' class = network subclass = ethernet it is currently running 11-STABLE but was curious if there are any reports of people successfully running SR-IOV under CURRENT with this hardware and driver? On both 11.2-RELEASE and 11-STABLE, after running iovctl to bring up the interface results in the NIC hanging - for example like so: $ sudo iovctl -C -f /etc/iovctl.conf iovctl: Failed to configure SR-IOV: No space left on device so if its working on CURRENT i'll go through the upgrade process, but if no one is testing this I'll forgo SR-IOV for now. thanks! -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"
Re: ix SR-IOV working
On 8/10/18 8:30 AM, Ryan Stone wrote:
How many VFs are you trying to create? Getting ENOSPC either
indicates that you tried to allocate more VFs than the hardware
supports, or the system could not allocate enough MMIO space for the
VFs.
Hi Ryan,
I was attempting to create a single VF. here's my iovct.conf:
PF {
num_vfs: 1;
device : "ix0";
}
DEFAULT {
passthrough : true;
}
my goal is to setup several bhyve instances on this server, and allocate
one VF per instance. for now i'm attempting to create a single VF for
testing purposes.
Cheers!
-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"
Re: ix SR-IOV working
On 8/10/18 9:52 AM, Ultima wrote: Hello, This is probably a driver issue. The only way I could get sr-iov working with the ix driver is compiling the driver provided by Intel and loading it before boot. [1] for more details and [2] for the driver. Have not tested the latest version and only tested this on CURRENT. Also, there were some options that needed to be changed before compiling to enable sr-iov, it's pretty straightforward though if I recall correctly. awesome, thanks! i had downloaded the latest version from Intel and was thinking of giving it a spin, this seems to confirm this would worth my time testing out. thanks for the links for reference! -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"
CURRENT from today throws lots of ACPI errors, lost HDMI detection
howdy, running code from today and having lots of issues. when i boot the system (a kabylake laptop) using legacy mode in the BIOS i see lots of these errors are thrown in dmesg: acpi0: on motherboard Firmware Error (ACPI): Failure creating [\134_SB.PCI0.XHC.RHUB.HS01._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-372) ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689) Firmware Error (ACPI): Failure creating [\134_SB.PCI0.XHC.RHUB.HS01._PLD], AE_ALREADY_EXISTS (20180810/dswload2-468) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-372) ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689) Firmware Error (ACPI): Failure creating [\134_SB.PCI0.XHC.RHUB.HS02._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-372) ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689) Firmware Error (ACPI): Failure creating [\134_SB.PCI0.XHC.RHUB.HS02._PLD], AE_ALREADY_EXISTS (20180810/dswload2-468) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-372) ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689) Firmware Error (ACPI): Failure creating [\134_SB.PCI0.XHC.RHUB.HS03._UPC], AE_ALREADY_EXISTS (20180810/dswload2-468) ACPI Error: AE_ALREADY_EXISTS, During name lookup/catalog (20180810/psobject-372) ACPI Error: Skip parsing opcode OpcodeName unavailable (20180810/psloop-689) there are lots more, i can post a pastebin link if needed. i also attempted to boot using UEFI but the system hangs very early in the boot process. i have reverted to legacy mode for now so that i can work, but am keen to test out any patches or do any other debugging that is needed. thx! -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"
Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection
On 8/14/18 6:13 PM, Kyle Evans wrote: On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote: i also attempted to boot using UEFI but the system hangs very early in the boot process. i have reverted to legacy mode for now so that i can work, but am keen to test out any patches or do any other debugging that is needed. Hi Pete, Where in the process does it hang with UEFI? I can't help much with any of your other problems, but I am curious about this one. =) sure thing - the last several lines are: random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 netmap: loaded module nexus0 at this point it hangs. let me know if you want me to try booting with verbose output to dmesg or something. cheers, -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"
Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection
On 8/14/18 8:45 PM, Kyle Evans wrote: On Tue, Aug 14, 2018 at 10:41 PM, Pete Wright wrote: On 8/14/18 6:13 PM, Kyle Evans wrote: On Tue, Aug 14, 2018 at 7:28 PM, Pete Wright wrote: i also attempted to boot using UEFI but the system hangs very early in the boot process. i have reverted to legacy mode for now so that i can work, but am keen to test out any patches or do any other debugging that is needed. Hi Pete, Where in the process does it hang with UEFI? I can't help much with any of your other problems, but I am curious about this one. =) sure thing - the last several lines are: random: fast provider: "Intel Secure Key RNG" kbd1 at kbdmux0 netmap: loaded module nexus0 at this point it hangs. let me know if you want me to try booting with verbose output to dmesg or something. Are you running GENERIC, or custom config? Any modules loaded? this is a GENERIC kernel using ZFS as well as GELI full disk encryption. I'm curious if you've been bitten somehow by recently enabling EFIRT in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and see where that gets you? i did attempt to set that in loader.conf - and it progressed farther but kernel panic'd when trying to bring up my iwn wireless interface. i'm building an older version in an attempt to bisect this issue (i have a skylake system running a checkout from monday without issues, so testing that now). if i am still running into problems i'll boot with efi.rt.disabled=1 and will post the gdb panic string here. -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"
Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection
On 8/14/18 9:01 PM, Kyle Evans wrote: I'm curious if you've been bitten somehow by recently enabling EFIRT in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and see where that gets you? i did attempt to set that in loader.conf - and it progressed farther but kernel panic'd when trying to bring up my iwn wireless interface. Interesting... out of side curiosity, what does this panic look like? Can you also try running a kernel >= r337773 with kib's patch from [1] applied to make sure this the EFI part of this isn't already solved? sure i can give that a spin. i'm building an older version in an attempt to bisect this issue (i have a skylake system running a checkout from monday without issues, so testing that now). if i am still running into problems i'll boot with efi.rt.disabled=1 and will post the gdb panic string here. Excellent. so i have reverted back to this git hash: 90f37b39e4a https://github.com/freebsd/freebsd/commit/90f37b39e4ad481d3e5a059123f7d68ac153f0c5 and i can confirm that i am able to boot with EFI enabled, do not experience any issues bringing up my iwn interface and HDMI is recognized according to xrandr. so that solves my immediate problem! :) interestingly enough i still see the ACPI errors I reported earlier, but perhaps that is a red herring. i'll go back to the tip of master and apply kib's patch and see how it goes. -p -- 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"
Re: CURRENT from today throws lots of ACPI errors, lost HDMI detection
On 8/14/18 9:06 PM, Pete Wright wrote: On 8/14/18 9:01 PM, Kyle Evans wrote: I'm curious if you've been bitten somehow by recently enabling EFIRT in GENERIC. Can you try setting efi.rt.disabled=1 at loader prompt and see where that gets you? i did attempt to set that in loader.conf - and it progressed farther but kernel panic'd when trying to bring up my iwn wireless interface. Interesting... out of side curiosity, what does this panic look like? Can you also try running a kernel >= r337773 with kib's patch from [1] applied to make sure this the EFI part of this isn't already solved? sure i can give that a spin. i'm building an older version in an attempt to bisect this issue (i have a skylake system running a checkout from monday without issues, so testing that now). if i am still running into problems i'll boot with efi.rt.disabled=1 and will post the gdb panic string here. Excellent. so i have reverted back to this git hash: 90f37b39e4a https://github.com/freebsd/freebsd/commit/90f37b39e4ad481d3e5a059123f7d68ac153f0c5 and i can confirm that i am able to boot with EFI enabled, do not experience any issues bringing up my iwn interface and HDMI is recognized according to xrandr. so that solves my immediate problem! :) interestingly enough i still see the ACPI errors I reported earlier, but perhaps that is a red herring. i'll go back to the tip of master and apply kib's patch and see how it goes. ok great (thank's ccache for making buildkernel fast :) ) so after applying the patch from kib i have the same behavior as i'm seeing on git hash 90f37b39e4a. i.e. boots fine with UEFI enabled, iwn interface comes up, HDMI output is detected by xrandr and interesting ACPI warning messages. i'll dogfood this patch tomorrow when i get into the office and validate connecting my HDMI display works as expected and will report any other issues i bump into. thanks for your help Kyle! I didn't think to test kib's patch as i was assuming my issue was related to the ACPI errors, but this seems to get me back to where i need to be to work tomorrow so i'm good to go :) -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"
Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M
On 8/22/18 2:11 AM, Graham Perrin wrote: HP EliteBook 8570p with AMD 'Thames' Radeon HD 7570M. If neither drm-stable-kmod nor drm-next-kmod is used – commenting out # kld_list="/boot/modules/radeonkms.ko" in /etc/rc.conf and if boot is pure UEFI, without CSM, then the notebook can reliably resume from suspend. There's a distinctive single amber pulse of the (normally blue) radio button before suspend occurs. However: - without CSM, most of the startup routine is illegible, 'torn' – for example, I can't see what's typed when I boot to single user mode. If either drm-stable-kmod or drm-next-kmod is used and if boot is pure UEFI, then the notebook can not suspend. No amber pulse of the radio button. With and without drm-next-kmod: if boot is hybrid UEFI with CSM, then suspend occurs, but resume fails. No beep, the computer restarts. debug.acpi.resume_beep=1 in /boot/loader.conf for an audible beep. Please: might graphics/drm-devel-kmod be better for either the tearing (without CSM) or for suspend? not sure this will address this specific issue - but have you tested setting this sysctl knob and seeing if that fixes your resume issues: hw.acpi.reset_video=1 -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"
Re: drm / drm2 removal in 12
On 8/24/18 4:07 PM, blubee blubeeme wrote: This project: https://wiki.freebsd.org/Use%20linuxkpi%20in%20DRM Goals - Move DRM headers to a similar location as Linux - Use kmalloc() instead of malloc(9) - Use kref - Use idr and get rid of drm_gem_names.c - Use PCI API - Use Linux locking primitives is garbage, if you want to use develop Linux code and use Linux then go do that on Linux. having a hard time not feeding the troll here...but what specifically is garbage. as in, what implementation of all this work do you have available that has been developed independently which also enables support for modern desktop and portable systems that you can buy today? Are these guys insane and please avoid the nonsense about you're doing this in your spare time. speaking as someone who's been working on this from pretty much the day of the initial CFT (maybe before?) - i don't know anyone who's getting paid for this specific work. at least when it comes to GPU support. but, if you have the means, I'd love to work on this full time and am open to any serious offers :) -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"
issues with usb mouse detection on 12.0-ALPHA3
howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. thx! -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"
Re: issues with usb mouse detection on 12.0-ALPHA3
On 8/25/18 11:10 AM, Yuri Pankov wrote: Pete Wright wrote: howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. d'oh - didn't even think to check bugzilla. thanks! -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"
Re: issues with usb mouse detection on 12.0-ALPHA3
___ 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: issues with usb mouse detection on 12.0-ALPHA3
On 8/25/18 11:51 AM, Warner Losh wrote: On Sat, Aug 25, 2018, 12:17 PM Pete Wright wrote: On 8/25/18 11:10 AM, Yuri Pankov wrote: Pete Wright wrote: howdy - just upgraded one of my machines to 12.0-ALPHA3 and noticed that my usb mouse is not being detected. i made sure to do a proper mergemaster after building my kernel and world, and verified that updates to devd configs were picked up as per UPDATING. i am seeing the following in my dmesg console: ugen0.2: at usbus0 (disconnected) ugen0.2: at usbus0 this seems to happen every 60secs or so. starting moused also reports the following: $ sudo service moused start Starting default mousedmoused: unable to open /dev/psm0: No such file or directory not really sure what the best way to debug this is as i'm a bit uncertain about devd and devmatch's recent changes, so let me know if more info is needed or if i'm just missing something obvious. See https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=230868. d'oh - didn't even think to check bugzilla. Just committed a change to devmatch. It looks like I committed from the wrong tree, dropping a new line.:( Warner thanks! yep that fix 'er up on my end. initially i thought it didn't work because i had only installed an updated kernel. once i realized my mistake, rebuilding devmatch with your latest patch applied fixed everything up. cheers! -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"
beadm vs bectl
hi there - i have a zfs based system where /boot is on its own pool. beadm seems happy enough with this setup but bectl errors out like so: $ sudo bectl list / and /boot not on same device, quitting $ $ beadm list BE Active Mountpoint Space Created default NR / 47.6G 2018-03-02 20:30 snapshot_02262018 - - 1.5G 2018-03-03 14:38 badresume_05122018 - - 4.4G 2018-05-12 19:45 11_2_beta - - 2.6G 2018-05-13 18:26 resume_works - - 12.6G 2018-06-01 16:45 $ reading the manpage for bectl it doesn't mention this being an issue. so i guess i have two questions: 1) is it a bad thing(tm) to have /boot on its own pool? 2) assuming that having /boot on its own pool, why does bectl not work with this configuration? thanks! -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"
Re: beadm vs bectl
On 8/27/18 3:22 PM, Allan Jude wrote: On 2018-08-27 14:50, Pete Wright wrote: hi there - i have a zfs based system where /boot is on its own pool. beadm seems happy enough with this setup but bectl errors out like so: $ sudo bectl list / and /boot not on same device, quitting $ $ beadm list BE Active Mountpoint Space Created default NR / 47.6G 2018-03-02 20:30 snapshot_02262018 - - 1.5G 2018-03-03 14:38 badresume_05122018 - - 4.4G 2018-05-12 19:45 11_2_beta - - 2.6G 2018-05-13 18:26 resume_works - - 12.6G 2018-06-01 16:45 $ reading the manpage for bectl it doesn't mention this being an issue. so i guess i have two questions: 1) is it a bad thing(tm) to have /boot on its own pool? 2) assuming that having /boot on its own pool, why does bectl not work with this configuration? thanks! -pete Your /boot being on a separate pool can never work, since you can't take a consistent snapshot of / and have it include your kernel (which is under /boot/kernel which is a separate pool) Do you know why you have 2 separate pools? If it was for GELI support, FreeBSD 12.0 will not require two separate pools anymore, and there will be migration instructions shortly. thanks Allan! that is precisely why i have a separate /boot IIRC - i use GELI to encrypt zroot. i'll keep my eyes open for migration instructions which i'll be sure to test out and provide feedback on. thanks! -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"
Re: testing early microcode loading
On 9/10/18 11:26 AM, Mark Johnston wrote: Hi, Support for boot-time loading of Intel microcode updates has landed in the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. I'd like to solicit some testing of the feature ahead of 12.0. The port has been modified to install /boot/firmware/intel-ucode.bin. This file contains a copy of every Intel microcode update supplied by the port. Per the pkg-message, one can enable early loading of this file by specifying: cpu_microcode_load="YES" cpu_microcode_name="/boot/firmware/intel-ucode.bin" in loader.conf. The update will be applied upon a subsequent reboot. Testing consists of enabling early loading and verifying that the CPUs report an updated microcode version. If early loading fails, a message is printed to the dmesg. If your system is capable of successful ACPI suspend/resume, it is useful to also verify that the microcode remains updated following a resume. To fetch the current microcode version, use sysutils/x86info: # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 Compare with the version installed by the microcode_update rc script at run-time: # service microcode_update onestart Updating CPU Microcode... Done. # kldload -n cpuctl && x86info -a | grep Micro Microcode version: 0x0020 If your testing indicates that the boot-time loading method doesn't work, please include the dmesg in your reply. Thanks in advance. Hey there Mark, So I've just tested this on a kabylake system running a kernel/world from Sept 7th which I believe is recent enough. After updating /boot/loader.conf as per your email I am not sure if any microcode updates are being applied. I'm not seeing any messages regarding firmware updates being applied in the dmesg buffer. running x86info results in the following: $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro Microcode version: 0x008e this is after rebooting with the updated loader.conf as well as running the rc script by hand. i didn't think to compare the output of x86info before running the rc script, i can do that later today. for reference here is my dmesg: https://gist.github.com/nomadlogic/bfc54315b97d374a7818d29bfc93223e Cheers, -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"
Re: testing early microcode loading
On 9/10/18 5:41 PM, Mark Johnston wrote: > On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >> >> On 9/10/18 11:26 AM, Mark Johnston wrote: >>> Hi, >>> >>> Support for boot-time loading of Intel microcode updates has landed in >>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>> I'd like to solicit some testing of the feature ahead of 12.0. >> Hey there Mark, >> So I've just tested this on a kabylake system running a kernel/world >> from Sept 7th which I believe is recent enough. >> >> After updating /boot/loader.conf as per your email I am not sure if any >> microcode updates are being applied. I'm not seeing any messages >> regarding firmware updates being applied in the dmesg buffer. > Right, we currently print something only if an update was configured > but failed to apply. We should probably print something either way, > perhaps only if the kernel is booted with -v. i could certainly as being helpful for debugging. >> running x86info results in the following: >> >> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >> Microcode version: 0x008e >> >> this is after rebooting with the updated loader.conf as well as running >> the rc script by hand. i didn't think to compare the output of x86info >> before running the rc script, i can do that later today. > Thanks. If the boot-time update succeeded, the rc script should have > been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages > in /var/log/messages? That would indicate that the rc script applied an > update, which would imply that the boot-time update failed somehow. when i ran the rc script after boot i saw the CPU related messages in dmesg on the console (CPU count, type, features, etc). i did not see anything in /var/log/messages of interest either. i'll re-test tomorrow when i get back into the office and let you know if i see anything of interest. my plan is to: - boot with the /boot/loader.conf additions for applying microcode and save the output from x86info - boot with loader.conf settings uncommented, view output of x86conf - then run rc script and get output of x86conf -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: testing early microcode loading
On 9/10/18 8:55 PM, Pete Wright wrote: > On 9/10/18 5:41 PM, Mark Johnston wrote: >> On Mon, Sep 10, 2018 at 12:48:56PM -0700, Pete Wright wrote: >>> On 9/10/18 11:26 AM, Mark Johnston wrote: >>>> Hi, >>>> >>>> Support for boot-time loading of Intel microcode updates has landed in >>>> the kernel in r337715, and in the sysutils/devcpu-data port as of 1.20. >>>> I'd like to solicit some testing of the feature ahead of 12.0. >>> Hey there Mark, >>> So I've just tested this on a kabylake system running a kernel/world >>> from Sept 7th which I believe is recent enough. >>> >>> After updating /boot/loader.conf as per your email I am not sure if any >>> microcode updates are being applied. I'm not seeing any messages >>> regarding firmware updates being applied in the dmesg buffer. >> Right, we currently print something only if an update was configured >> but failed to apply. We should probably print something either way, >> perhaps only if the kernel is booted with -v. > i could certainly as being helpful for debugging. >>> running x86info results in the following: >>> >>> $ sudo kldload -n cpuctl && sudo x86info -a | grep Micro >>> Microcode version: 0x008e >>> >>> this is after rebooting with the updated loader.conf as well as running >>> the rc script by hand. i didn't think to compare the output of x86info >>> before running the rc script, i can do that later today. >> Thanks. If the boot-time update succeeded, the rc script should have >> been a no-op. Can you check for "updating cpu /dev/cpuctl..." messages >> in /var/log/messages? That would indicate that the rc script applied an >> update, which would imply that the boot-time update failed somehow. > > when i ran the rc script after boot i saw the CPU related messages in > dmesg on the console (CPU count, type, features, etc). i did not see > anything in /var/log/messages of interest either. i'll re-test tomorrow > when i get back into the office and let you know if i see anything of > interest. my plan is to: ok had time to test during lunch: > - boot with the /boot/loader.conf additions for applying microcode and > save the output from x86info Microcode version: 0x0..48 > > - boot with loader.conf settings uncommented, view output of x86conf Microcode version: 0x0...8e > - then run rc script and get output of x86conf Microcode version: 0x0..8e great, so it looks like this is working on my kabylake workstation. the only time i see a log entry is when i update the microcode via rc, i do not see anything when its updated via loader.conf. cheers, -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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: ntpd user and group missing when upgrading from sources from 11-stable to 12-current
On 9/13/18 2:07 PM, Marek Zarychta wrote: Dear subscribers, stable/12 hasn't been branched yet, so it could be not a bug. Since r336525 make installworld fails on 11-stable when installing world for 12-current without ntpd user/group added. Of course, as a workaround user and group could be added manually. Mergemeaster also fails when it is run before installworld, what is IMHO predictable and expected behaviour. So mergemaster will not help with this issue. So the question arises, is it a feature or should a PR be submitted? can you share how you are running mergemaster? i recently upgraded a system from 11.2-RELEASE to 12-CURRENT without issues. my steps are: make buildkernel make buildworld make installkernel mergemaster -m /path/to/current/checkout -p make installworld mergemaster -m /path/to/current/checkout -a it is critical to run the mergemaster -p before installing the world. this will prompt you to update your /etc/password and /etc/group tables to add the new ntp user/group. the same goes for using the mergemaster -a switch after installing the world, as that will ensure that critical configs for rc are updated correctly. cheers, -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"
resume issues on ALPHA7
Hello, I am having issues resuming my system under ALPHA7. Under ALPHA5 I was able to suspend/resume my kabylake laptop without issues, but under ALPHA7 when I attempt to resume it seems to lock up (no input working from keyboard) requiring a hard reboot of my system. Not sure how I can debug this, so any tips would be appreciated. Here's my current dmesg: http://termbin.com/y4lk probably worth noting I've seen those ACPI errors since around ALPHA3 IIRC. cheers, -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"
Re: resume issues on ALPHA7
On 9/27/18 12:12 PM, Pete Wright wrote: Hello, I am having issues resuming my system under ALPHA7. Under ALPHA5 I was able to suspend/resume my kabylake laptop without issues, but under ALPHA7 when I attempt to resume it seems to lock up (no input working from keyboard) requiring a hard reboot of my system. Not sure how I can debug this, so any tips would be appreciated. Here's my current dmesg: http://termbin.com/y4lk probably worth noting I've seen those ACPI errors since around ALPHA3 IIRC. bumping this thread with an update. i re-installed my laptop from the ALPHA7 snapshot to ensure i had a clean env, and am unable to wake from resume. i had misspoke regarding ALPHA5, as i tested that as well and it failed to resume. my plan is to go back to ALPHA3 and see if it worked then. one question, i've enabled: debug.acpi.resume_beep:1 and it indeed does beep on resume, and does not stop beeping until i hit power button. does that ring any bells? thanks! -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"
Resume Issue with em(4) ALPHA7
Hello, More suspend/resume testing on my end. This system is a desktop, so not critical for my daily workflow but wanted to flag it regardless. The system is a Lenovo m900 with skylake and em(4) NIC. Entering suspend works without issues, resuming seems to mostly work as well. I.e. no issues with display or input from keyboard or mouse. The one issue I am running into is my NIC is non-functional after resume. restarting the network stack via "service netif restart" does not work - as in no DHCP lease is aquired and no link is detected. Nor does manually down'ing and up'ing the interface work. I see these messages in my dmesg buffer after resume: in6_purgeaddr: err=65, destination address delete failed lo0: link state changed to DOWN lo0: link state changed to UP Link state changed to down em0: link state changed to DOWN em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 em0: TX(0) desc avail = 1024, pidx = 0 Another thing I noticed is that after resume "ifconfig" hangs for a couple seconds printing after printing the first line of my em0 device (after the flags). Not sure if that's helpful but thought it could be a useful datapoint. It is easy to reproduce this, so I am happy to do any additional debugging or testing on this. Cheers, -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"
Re: Resume Issue with em(4) ALPHA7
On 9/30/18 1:27 AM, Johannes Lundberg wrote: On Sun, Sep 30, 2018 at 8:24 AM Ali Abdallah wrote: I'm having also the same problem on my Thinkpad x230. However I'm running a minimal kernel, so usually I do kldunload/kldload if_em, to reset the hardware and to avoid a reboot. Hopefully this gets fixed soon. Hi I've been having the same problem for at least several months with if_em, hw I218-LM and I219-LM. Need to unload and reload if_em to make it work again after resume. thanks for the workaround suggestion Ali and Johannes! if there isn't a PR for this yet i'll file one now. -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"
Re: Resume Issue with em(4) ALPHA7
On 9/30/18 10:12 AM, Pete Wright wrote: On 9/30/18 1:27 AM, Johannes Lundberg wrote: On Sun, Sep 30, 2018 at 8:24 AM Ali Abdallah wrote: I'm having also the same problem on my Thinkpad x230. However I'm running a minimal kernel, so usually I do kldunload/kldload if_em, to reset the hardware and to avoid a reboot. Hopefully this gets fixed soon. Hi I've been having the same problem for at least several months with if_em, hw I218-LM and I219-LM. Need to unload and reload if_em to make it work again after resume. thanks for the workaround suggestion Ali and Johannes! if there isn't a PR for this yet i'll file one now. file this PR for those playing along at home: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231828 -p -- 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"
Re: FreeBSD 12.0-ALPHA7 em0 networking with resume from suspend: OK
On 10/1/18 5:32 PM, Graham Perrin wrote: >> Re: FreeBSD-12-ALPHA6: Network not starting at boot & can't start Plasma 5 > On 23/09/2018 14:50, Warner Losh wrote: > >> I'll test r338892 em0 networking with resume from suspend next week. >> >> >> I just fixed a bug in devd that would cause this, but that was after the >> last snapshot. > Thanks Warner! > > For me, with an HP EliteBook 8570p, the issue is no longer reproducible. > > Tested on a handful of occasions late last week, probably tested again > yesterday (Monday). > > $ uname -v > FreeBSD 12.0-ALPHA7 r338956 GENERIC-NODEBUG thanks Graham - i seemed to have missed that, rebuilding my kernel now to test. if it works i'll close out the bug report. -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ 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 HD 7570M: drm: deep frustration with r339186
On 10/5/18 6:34 PM, Graham Perrin wrote: On 23/09/2018 08:09, Graham Perrin wrote: Re: Suspend, resume, UEFI, CSM, drm-stable-kmod and drm-next-kmod with Radeon HD 7570M … better without drm-next-kmod; and (as expected, given the package message) drm-stable-kmod has known problems with UEFI. Now (with r339186) it seems that drm-next-kmod is the only usable option. However, I'm sorry to say: - it does feel regressive, compared to working without drm-next-kmod with earlier versions of -CURRENT. I can no longer find a way to reliably suspend (sleep) the notebook. hey Graham - I'm struggling with suspend/resume issues as well on my end with recent 12-ALPHA releases. can you verify that you can suspend/resume without loading the radeonkms.ko (i believe that is what you are using for gfx)? on my systems it's broken regardless if i load the drm modules. also, what was the last version of CURRENT you were able to suspend/resume with? At the time of writing my part-working configuration is as outlined below. However – frustratingly – for a while, an hour or so ago, it seemed as if the same configuration was useless; after a point, the screen would go blank (grey) and things would progress no further e.g. no login manager (sddm); no response to Control-Alt-F2; no response to Control-Alt-Delete. The apparent unpredictability leading to a dead-end situation has created a sense of unease; now I'm genuinely afraid to test suspend :-( i believe johannes lundberg is working on a fix for this issue. i'm in the same uneasy situation as you. the system i use for dogfooding is also my main work laptop, and not having suspend/resume and other instability like this is certainly not ideal. one potential fix workaround we've found is to not load the module via "kld_list" but rather load it by hand via "kldload" manually. i believe the bug is in relation to how the BIOS allocates memory - i'll let him fill in details :) for me at least it looks like system instability when loading drm-next kernels is separate from suspend/resume. but its certainly possible my laptop is a snowflake :p hope this helps. -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"
Re: dmesg submission service -- please submit today
On 10/8/18 12:35 AM, Thomas Mueller wrote: I just submitted /var/run/dmesg.boot from my current NetBSD and from FreeBSD 11.1-STABLE. I was surprised to see some other BSD OSes listed, including 5 dmesg reports from Bitrig and 3 from RetroBSD. I had been tracking three bitrig trees from https://github.com/bitrig : bitrig, bitrig-xenocara and bitrig-ports , noticed no activity at all since December 2016 or January 2017: dead OS. there are lots of gems in dmesgd.nycbug.org. we put it up in 2004 or (earlier IIRC) - i know i've put posted some hardware in there that i wish i still had :) -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"
Re: Dependencies – drm-kmod, drm-stable-kmod and drm-next-kmod
On 10/7/18 11:11 PM, Graham Perrin wrote: On 07/10/2018 14:03, Niclas Zeising wrote: … $ pkg rquery %rn graphics/drm-next-kmod drm-kmod drm-kmod $ – is there _truly_ intended to be some dependency between drm-next-kmod and drm-kmod? Hi! The version of drm-*-kmod that's pulled in is dependent on your FreeBSD version. … OK, I wasn't aware of that. For me at this time: - post-installation of drm-next-kmod, the presence of drm-kmod is pretty much a show-stopper – better to be without drm-kmod, leaving drm-next-kmod in isolation. I'd like to await Pete Wright's response to <https://lists.freebsd.org/pipermail/freebsd-current/2018-October/071517.html> before sharing details. here ya go (i'm running drm-devel on a kabylake system in this instance): $ uname -v ; pkg query '%n %v %R' drm-kmod ; pkg query '%n %v %R' drm-devel-kmod FreeBSD 12.0-ALPHA8 #1 b4764e4a0ec(master)-dirty: Thu Oct 4 11:50:08 PDT 2018 pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC drm-devel-kmod 4.16.g20180927 unknown-repository i am not installing the drm-kmod port on my end, sorry if i mentioned i was earlier i was probably mixed up there. cheers, -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"
Re: drm-kmod, drm-next-kmod, suspend and resume with radeonkms.ko with and without Kaby Lake
On 10/8/18 11:48 PM, Graham Perrin wrote: On 06/10/2018 08:38, Graham Perrin wrote: On 06/10/2018 04:16, Pete Wright wrote: … struggling with suspend/resume issues as well on my end with recent 12-ALPHA releases. … radeonkms.ko … on my systems it's broken regardless if i load the drm modules. … Pete, please, what output do you get from this? uname -v ; pkg query '%n %v %R' drm-kmod ; pkg query '%n %v %R' drm-next-kmod Pete replied: here ya go (i'm running drm-devel on a kabylake system in this instance): $ uname -v ; pkg query '%n %v %R' drm-kmod ; pkg query '%n %v %R' drm-devel-kmod FreeBSD 12.0-ALPHA8 #1 b4764e4a0ec(master)-dirty: Thu Oct 4 11:50:08 PDT 2018 pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC drm-devel-kmod 4.16.g20180927 unknown-repository i am not installing the drm-kmod port on my end, sorry if i mentioned i was earlier i was probably mixed up there. cheers, -pete Thanks, Pete, I assume that you have a discrete Radeon card with the Kaby Lake system, can you share details of the discrete and on-board graphics? no this system is using Intel HD Graphics: Intel(R) HD Graphics 630 (Kaby Lake GT2) sorry if this was causing confusion. -p -- 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"
Re: 12.0-beta3 base.txz missing complete dir tree
On 11/8/18 12:25 PM, Ernie Luzar wrote: ftp.freebsd.org/pub/FreeBSD/releases/amd/amd/12.0-BETA3/base.txz /usr/local empty /var/log empty This is really making testing imposable! shouldn't both of those directories be empty in the base.txz file? or is their another error you are getting? -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"
Re: DRM Project report (week of August 10)
On 8/17/20 1:46 AM, Emmanuel Vadot wrote: Hello, 5.4 was finilly reached ! For AMD users it means that Navi12/14, Arctarus and Renoir should work. For Intel users it means that TigerLake should work too. No ports update for now as I want to give current users a bit of time to update their base (as the ports needs recent addition to base linuxkpi) but if you have a current >= 364233 you can test directly the master branch of https://github.com/freebsd/drm-kmod/ I plan to commit the port update at the end of the week, and probably at the end of the month we will switch drm-current-kmod to 5.4. thanks Manu! would it make sense to make this version available in graphics/drm-devel-kmod now to make it easier to test for people who update world/kernel more frequently? -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"
Undefined symbol "lzc_remap"
Hello, I have a system running current that is acting a little odd after a rebuild from last night (sept 13th). After reboot my root zfs pool mountd fine, but my second datavol "tank0" didn't auto-import/mount. A manual "zpool import" then "zfs mount -a" got everything back where it should be, but I am noticing some odd behavior with iocage: ImportError: /lib/libzfs.so.3: Undefined symbol "lzc_remap" Interestingly enough this is the second update i've done to this system since the import of openzfs code, and iocage was operating without issues previously. i am wondering does iocage need to be rebuild against newer sources or did something else change recently? -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"
Re: Undefined symbol "lzc_remap"
On 9/14/20 1:00 PM, Kyle Evans wrote: On Mon, Sep 14, 2020 at 2:56 PM Pete Wright wrote: Hello, I have a system running current that is acting a little odd after a rebuild from last night (sept 13th). After reboot my root zfs pool mountd fine, but my second datavol "tank0" didn't auto-import/mount. A manual "zpool import" then "zfs mount -a" got everything back where it should be, but I am noticing some odd behavior with iocage: ImportError: /lib/libzfs.so.3: Undefined symbol "lzc_remap" Interestingly enough this is the second update i've done to this system since the import of openzfs code, and iocage was operating without issues previously. i am wondering does iocage need to be rebuild against newer sources or did something else change recently? Hi, You'll need a ports tree >= r548105 and rebuild devel/py-libzfs from that -- that should be sufficient. Thanks Kyle - you saved me quite a bit of debugging, i'll give that a spin now :) -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"
Re: Deprecating ftpd in the FreeBSD base system?
On 9/17/20 12:49 PM, John-Mark Gurney wrote: Ian Lepore wrote this message on Thu, Sep 17, 2020 at 09:01 -0600: On Thu, 2020-09-17 at 18:43 +0400, Gleb Popov wrote: On Thu, Sep 17, 2020 at 6:05 PM Cy Schubert < cy.schub...@cschubert.com> wrote: I've been advocating removing FTP (and HTTP) from libfetch as well. People should be using HTTPS only. Isn't this a bit too much? I often find myself in need to download something starting with "http://"; or "ftp://"; and use fetch for this. Indeed, we have products which rely on this ability in libfetch and we have to keep supporting them for many many years to come. I hate it when someone imperiously declares [For security reasons] "People should/shouldn't be using __". You have no idea what the context is, and thus no ability to declare what should or shouldn't be used in that context. For example, two embedded systems talking to each other over a point to point link within a sealed device are not concerned about man in the middle attacks or other modern internet threats. And I really dislike when people want to make sure that their unique case that less than a percent of people would every hit blocks the security improvements for the majority of people... I've given up on a number of security improvements in FreeBSD because of this attitude... while i tend to agree with you here - i would say that in this case there is a very large use case where preservation of http is very important to a wide base of users: https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/instancedata-data-retrieval.html https://cloud.google.com/compute/docs/storing-retrieving-metadata https://docs.microsoft.com/en-us/azure/virtual-machines/windows/instance-metadata-service regarding the main topic tho - dropping ftpd from base seems like a good iteration in clearing out cruft from the code base so we can focus on things with much larger user bases. fortunately we have an excellent ports/pkg infrastructure to service this need if it arises. -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"
Re: Plans for git
making quarterly reports about this for almost a years as well. We put out calls for people to help with the efforts about the same time. We have tried at every step of the way to be open and honest that this was going to happen. All developer centric communications I would argue that quarterly reports are actually one of the few methods of getting accurate information about the state of the project as a non-insider. i've been following the progress of this work via the quarterly status reports for years now, and as someone who is merely a freebsd operator felt like i was more or less kept up to date on this eventuality. honestly there has to be *some* responsibility of operators to at least make an effort to keep up to date on the status of the various efforts in such a large project. and as an outsider the idea that comms can only happen on the mailing list isn't the greatest - how am i to know that the idea of one person on the ML carries more weight than another, or one persons opinion is the "official" stated opinion of the core 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"
Re: Plans for git
On 9/21/20 12:49 PM, Christian Weisgerber wrote: On 2020-09-21, Alexander Leidinger wrote: In my opinion the people which drive this didn't keep it behind closed curtains, and they went step by step more public, as they made progress. To me it looks like now, that they have something which is presentable to the world (and not only to committers), they presented it to the world. Since I am one of the sad people who managed to miss all this public information, where can we find a summary of what's planned for the switch? I believe the most detailed report on this was in the 2020-04 quarterly status report: https://www.freebsd.org/news/status/report-2020-04-2020-06.html#Git-Migration-Working-Group before this, work was mentioned in previous updates as part of the core teams status update. there is also the freebsd-git@ mailing list here: https://lists.freebsd.org/pipermail/freebsd-git/ i don't subscribe to that list personally but i have checked the archives periodically when i have questions that pop up. hope this helps, -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"
Re: Can't forward X11 apps over ssh since migrating to 13-CURRENT
On 9/21/20 8:39 PM, O'Connor, Daniel wrote: On 22 Sep 2020, at 08:06, Patrick McMunn wrote: I don't know if it's just coincidental or if it's because of some change in 13-CURRENT, but I recently migrated from 12.1-STABLE, and now I am unable to forward X11 apps over ssh. The only app I was accustomed to running this way was Handbrake. It worked fine before, but now i get this: $ ghb Unable to init server: Could not connect to 127.0.0.1: Connection refused (ghb:87219): Gtk-WARNING **: 13:12:41.281: cannot open display: I have tried other apps like Wireshark and even xclock just to see, but they won't work either. Has anyone else had problems with X11 forwarding on 13-CURRENT? If it's working for everyone else, at least I can know it's probably not 13-CURRENT's fault, and I need to look elsewhere for the cause. And yes, my sshd_config has it enabled. It worked fine before, and I made sure to keep the same config. What is the value of DISPLAY? (ie echo $DISPLAY) Is sshd listening on that port? eg.. [test 3:36] ~> echo $DISPLAY localhost:11.0 [test 3:36] ~> sockstat|grep 6011 radarsshd 5414 8 tcp6 ::1:6011 *:* radarsshd 5414 9 tcp4 127.0.0.1:6011*:* might have missed this but how is the ssh session being established. i just verified "ssh -X host" allows me to redirect X to my local workstation. both systems are running CURRENT as well. -p -- 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"
second ZFS pool no longer auto-imports
Hello, I have a workstation with two ZFS pools (zroot and tank0). After upgrading CURRENT post the OpenZFS merge I have found that my tank0 pool no longer auto-imports on boot. After the system has booted I am able to import it via "zpool import tank0" then mount all of its filesystems without issues or errors. I've also run a scrub on the pool and no issues were identified their either. I've also been careful to *not* run "zpool upgrade" on this system as my zroot is geli encrypted, and have been waiting for the all clear to do that. Has anyone else noticed this behavior? Perhaps I'm missing an option or something - kinda confused here as to what may have changed to cause this to happen. Thanks! -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"
Re: second ZFS pool no longer auto-imports
On 9/29/20 1:53 PM, xto...@hotmail.com wrote: Pete Wright wrote: Hello, I have a workstation with two ZFS pools (zroot and tank0). After upgrading CURRENT post the OpenZFS merge I have found that my tank0 pool no longer auto-imports on boot. After the system has booted I am able to import it via "zpool import tank0" then mount all of its filesystems without issues or errors. I've also run a scrub on the pool and no issues were identified their either. I've also been careful to *not* run "zpool upgrade" on this system as my zroot is geli encrypted, and have been waiting for the all clear to do that. Has anyone else noticed this behavior? Perhaps I'm missing an option or something - kinda confused here as to what may have changed to cause this to happen. Check /usr/src/UPDATING, 20200824 entry. thank-you! I had read that entry but obviously skipped over the last paragraph, sorry for the noise. cheers, -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"
CURRENT failing at contrib/unbound/util/config_file.c:122:20
wondering if anyone else is having this error building CURRENT today: --- config_file.o --- /usr/home/pete/git/freebsd/contrib/unbound/util/config_file.c:122:20: error: use of undeclared identifier 'UNBOUND_DNS_OVER_HTTPS_PORT' cfg->https_port = UNBOUND_DNS_OVER_HTTPS_PORT; ^ 1 error generated. --- all_subdir_lib/ncurses --- my last commit from the github mirror is: commit efb48d58bee75fdb221adece8ef5a13cede99e8c (HEAD -> master, origin/master, origin/HEAD) Author: tuexen Date: Sat Nov 7 21:17:49 2020 + The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMARK access the socket send or receive buffer. This is not possible for listening sockets since r319722. Because send()/recv() calls fail on listening sockets, fail also ioctl() indicating EINVAL. so not sure if it's been found or if this is a real issue. thx! -p -- 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"
Re: CURRENT failing at contrib/unbound/util/config_file.c:122:20
On 11/7/20 3:56 PM, Cy Schubert wrote: In message , Pete Wright w rites: wondering if anyone else is having this error building CURRENT today: --- config_file.o --- /usr/home/pete/git/freebsd/contrib/unbound/util/config_file.c:122:20: error: use of undeclared identifier 'UNBOUND_DNS_OVER_HTTPS_PORT'        cfg->https_port = UNBOUND_DNS_OVER_HTTPS_PORT;                          ^ 1 error generated. --- all_subdir_lib/ncurses --- my last commit from the github mirror is: commit efb48d58bee75fdb221adece8ef5a13cede99e8c (HEAD -> master, origin/master, origin/HEAD) Author: tuexen Date:  Sat Nov 7 21:17:49 2020 +    The ioctl() calls using FIONREAD, FIONWRITE, FIONSPACE, and SIOCATMAR K    access the socket send or receive buffer. This is not possible for    listening sockets since r319722.    Because send()/recv() calls fail on listening sockets, fail also ioctl()    indicating EINVAL. so not sure if it's been found or if this is a real issue. No such problem here. What do you see on line 1397 of /usr/src/usr.sbin/unbound/config.h? Also, uname -a, please. And, git status usr.sbin/unbound, looking for local mods. Your cwd will need to be the root of your git tree. Thanks Cy for the confirmation that it is working on your end. I think my git checkout must be in a bad state locally. Even after a make clean and purge of my obj directory it was still failing. I then did a fresh checkout using the cgit-beta server and it is building fine now by the looks of it. I should have done that before spam'ing the list - d'oh. -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"
Re: git and the loss of revision numbers
On 12/28/20 4:38 PM, monochrome wrote: what would be the git command for reverting source to a previous version using these numbers? for example, with svn and old numbers: svnlite update -r367627 /usr/src I will generally just checkout the short git hash like so in my local checkout: $ git checkout gb81783dc98e6 you can quickly get the hashes by running "git log" from your checkout. cheers, -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 6:26 AM, Thomas Laus wrote: I perform a CURRENT build weekly on a more powerful build machine and then export /usr/src and /usr/obj via NFS to other slower PC's. The 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It looks like this file is not installed before the rest of the 'drm-current-kmod' files. This causes the 'installkernel' over NFS to fail. My fis was to un-install drm-current-kmod, install the kernel and then re-install drm-current-kmod. hrm, i'm not sure this is specifically an NFS issue. I am building/installing locally on my workstation but am getting similar errors trying to load drm-devel-kmod's amdgpu mod. at this point even uninstalling drm-devel-kmod, make installkernel, install drm-devel-kmod pkg results in the same problem. -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 11:33 AM, Pete Wright wrote: On 1/19/21 6:26 AM, Thomas Laus wrote: I perform a CURRENT build weekly on a more powerful build machine and then export /usr/src and /usr/obj via NFS to other slower PC's. The 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It looks like this file is not installed before the rest of the 'drm-current-kmod' files. This causes the 'installkernel' over NFS to fail. My fis was to un-install drm-current-kmod, install the kernel and then re-install drm-current-kmod. hrm, i'm not sure this is specifically an NFS issue. I am building/installing locally on my workstation but am getting similar errors trying to load drm-devel-kmod's amdgpu mod. at this point even uninstalling drm-devel-kmod, make installkernel, install drm-devel-kmod pkg results in the same problem. forgot to include dmesg error: KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD amdgpu.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/amdgpu.ko - unsupported file type -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 12:11 PM, Emmanuel Vadot wrote: On Tue, 19 Jan 2021 11:40:04 -0800 Pete Wright wrote: On 1/19/21 11:33 AM, Pete Wright wrote: On 1/19/21 6:26 AM, Thomas Laus wrote: I perform a CURRENT build weekly on a more powerful build machine and then export /usr/src and /usr/obj via NFS to other slower PC's. The 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It looks like this file is not installed before the rest of the 'drm-current-kmod' files. This causes the 'installkernel' over NFS to fail. My fis was to un-install drm-current-kmod, install the kernel and then re-install drm-current-kmod. hrm, i'm not sure this is specifically an NFS issue. I am building/installing locally on my workstation but am getting similar errors trying to load drm-devel-kmod's amdgpu mod. at this point even uninstalling drm-devel-kmod, make installkernel, install drm-devel-kmod pkg results in the same problem. forgot to include dmesg error: KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD amdgpu.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/amdgpu.ko - unsupported file type -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA Sound like you have an old linuxkpi_gplv2.ko in /boot/kernel/ Thanks Manu - so it looks like i don't have that file under /boot/kernel/ but in /boot/modules instead: $ find /boot/ -name '*linuxkpi*' -print /boot/modules/linuxkpi_gplv2.ko /boot/kernel/linuxkpi.ko /boot/kernel.old/linuxkpi.ko $ pkg which /boot/modules/linuxkpi_gplv2.ko /boot/modules/linuxkpi_gplv2.ko was installed by package drm-current-kmod-5.4.62.g20210118 $ above is after installing the current kmod to see if it behaved differently than the devel one. -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 12:18 PM, Pete Wright wrote: On 1/19/21 12:11 PM, Emmanuel Vadot wrote: On Tue, 19 Jan 2021 11:40:04 -0800 Pete Wright wrote: On 1/19/21 11:33 AM, Pete Wright wrote: On 1/19/21 6:26 AM, Thomas Laus wrote: I perform a CURRENT build weekly on a more powerful build machine and then export /usr/src and /usr/obj via NFS to other slower PC's. The 'installkernel' phase failed with 'linuxkpi_gplv2.ko' not found. It looks like this file is not installed before the rest of the 'drm-current-kmod' files. This causes the 'installkernel' over NFS to fail. My fis was to un-install drm-current-kmod, install the kernel and then re-install drm-current-kmod. hrm, i'm not sure this is specifically an NFS issue. I am building/installing locally on my workstation but am getting similar errors trying to load drm-devel-kmod's amdgpu mod. at this point even uninstalling drm-devel-kmod, make installkernel, install drm-devel-kmod pkg results in the same problem. forgot to include dmesg error: KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD amdgpu.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/amdgpu.ko - unsupported file type -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA Sound like you have an old linuxkpi_gplv2.ko in /boot/kernel/ Thanks Manu - so it looks like i don't have that file under /boot/kernel/ but in /boot/modules instead: $ find /boot/ -name '*linuxkpi*' -print /boot/modules/linuxkpi_gplv2.ko /boot/kernel/linuxkpi.ko /boot/kernel.old/linuxkpi.ko $ pkg which /boot/modules/linuxkpi_gplv2.ko /boot/modules/linuxkpi_gplv2.ko was installed by package drm-current-kmod-5.4.62.g20210118 $ above is after installing the current kmod to see if it behaved differently than the devel one. -pete interesting - so it seems like if i have drm-devel-kmod installed this will fail (missing or wrong linuxkpi_gplv2.ko). this happens both if i install the pkg and rebuild the kernel, and if i build the kernel w/o the pkg installed. yet, if i have the drm-current-kmod pkg installed, then "make buildkernel" it looks like the i915/amdgpu modules get build and an "installkernel" drops the linuxkpi_gplv2.ko module under /boot/kernel. at that point i am able to successfully load the amdgpu.ko. finally, i install the drm-current-pkg fresh (without doing the above buildkernel/installkernel) i get the linuxkpi_gplv2 error as above. -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 1:18 PM, Emmanuel Vadot wrote: interesting - so it seems like if i have drm-devel-kmod installed this will fail (missing or wrong linuxkpi_gplv2.ko). this happens both if i install the pkg and rebuild the kernel, and if i build the kernel w/o the pkg installed. Don't use the package, always rebuild from the latest ports. see bellow yet, if i have the drm-current-kmod pkg installed, then "make buildkernel" it looks like the i915/amdgpu modules get build and an "installkernel" drops the linuxkpi_gplv2.ko module under /boot/kernel. at that point i am able to successfully load the amdgpu.ko. drm-current-kmod will also install its sources in /usr/local/sys/ and this will get built with buildkernel. The problem is that if the package is old (and it is right now) you might have sources that either don't compile or don't work correctly. OK interesting, in both cases I was building the package from my local ports tree (via "make package"). i should have better explained that in previous emails. i verified my checkout was up to date as well (it includes your latest commits from Sunday and Monday). i'm happy now running the current-kmod but let me know if it'd be helpful to do any more tests or provide additional info. cheers, -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/19/21 11:55 PM, Emmanuel Vadot wrote: i'm happy now running the current-kmod but let me know if it'd be helpful to do any more tests or provide additional info. So what did you change ? ok i think i spot the issue - in my checkout of the ports tree via the github mirror at git://github.com/freebsd/freebsd-ports.git it looks like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements: $ cat pkg-plist %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko %%AMDKFD%%/%%KMODDIR%%/amdkfd.ko /%%KMODDIR%%/drm.ko %%I915%%/%%KMODDIR%%/i915kms.ko /%%KMODDIR%%/linuxkpi_gplv2.ko /%%KMODDIR%%/radeonkms.ko /%%KMODDIR%%/ttm.ko $ on the drm-current-kmod plist things look as we would expect them i believe: $ head pkg-plist %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko /%%KMODDIR%%/drm.ko %%I915%%/%%KMODDIR%%/i915kms.ko /%%KMODDIR%%/linuxkpi_gplv2.ko /%%KMODDIR%%/radeonkms.ko /%%KMODDIR%%/ttm.ko %%SOURCEKMODSRC%%/Makefile %%SOURCEKMODSRC%%/kconfig.mk %%SOURCEKMODSRC%%/amd/Makefile %%SOURCEKMODSRC%%/amd/amdgpu/Makefile $ I can file a PR with a patch later today if that's helpful, if this isn't due to bad git workspace on my end. cheers, -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"
Re: DRM problem installing kernel on main-c561-gc3e75b6c1
On 1/20/21 11:09 AM, Emmanuel Vadot wrote: On Wed, 20 Jan 2021 09:47:28 -0800 Pete Wright wrote: On 1/19/21 11:55 PM, Emmanuel Vadot wrote: i'm happy now running the current-kmod but let me know if it'd be helpful to do any more tests or provide additional info. So what did you change ? ok i think i spot the issue - in my checkout of the ports tree via the github mirror at git://github.com/freebsd/freebsd-ports.git it looks like the pkg-plist doesn't include the %%SOURCE%%KMODSRC%% statements: $ cat pkg-plist %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko %%AMDKFD%%/%%KMODDIR%%/amdkfd.ko /%%KMODDIR%%/drm.ko %%I915%%/%%KMODDIR%%/i915kms.ko /%%KMODDIR%%/linuxkpi_gplv2.ko /%%KMODDIR%%/radeonkms.ko /%%KMODDIR%%/ttm.ko $ on the drm-current-kmod plist things look as we would expect them i believe: $ head pkg-plist %%AMDGPU%%/%%KMODDIR%%/amdgpu.ko /%%KMODDIR%%/drm.ko %%I915%%/%%KMODDIR%%/i915kms.ko /%%KMODDIR%%/linuxkpi_gplv2.ko /%%KMODDIR%%/radeonkms.ko /%%KMODDIR%%/ttm.ko %%SOURCEKMODSRC%%/Makefile %%SOURCEKMODSRC%%/kconfig.mk %%SOURCEKMODSRC%%/amd/Makefile %%SOURCEKMODSRC%%/amd/amdgpu/Makefile $ I can file a PR with a patch later today if that's helpful, if this isn't due to bad git workspace on my end. cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA drm-devel-kmod doesn't install the sources on purpose. It never had and never will. So, did you "solve" the problem by switching to drm-current-kmod or to drm-devel-kmod ? ah i see, thanks for the clarification. so as of now i'm using the drm-current-kmod on my amdgpu system. using the drm-devel-kmod throws the previously reported error trying to load linuxkpi_gplv2.ko: KLD drm.ko: depends on linuxkpi_gplv2 - not available or version mismatch linker_load_file: /boot/modules/drm.ko - unsupported file type KLD amdgpu.ko: depends on drmn - not available or version mismatch linker_load_file: /boot/modules/amdgpu.ko - unsupported file type -p -- 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"
Re: freebsd.org ftp site throws BOGUS cert
On 3/4/21 10:20 AM, Chris wrote: This post probably belongs on a different list that I am not subscribed to. But... The appropriate list is freebsd-hubs@ https://lists.freebsd.org/mailman/listinfo/freebsd-hubs I can't get to the freebsd ftp sites because the cert(s) appear to be bad: https://ftp0.tuk.freebsd.org/ they should be able to track down the owner of that site, it looks like the TLS cert is valid for download.freebsd.org: * Server certificate: * subject: CN=download.freebsd.org * start date: Feb 14 20:17:20 2021 GMT * expire date: May 15 20:17:20 2021 GMT * subjectAltName does not match ftp0.tuk.freebsd.org download.freebsd.org may actually be the preferred method for accessing resources on this system. For example if geo-loadbalancing is used. anywho - the people on the above mailing list would know best. -p -- 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"
Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported?
On 3/23/22 14:44, Chris wrote: On a releng/13 install. I've installed the drm-kmod and loaded both the amdgpu and the radeonkms (at different times). I also installed the xf86-ati driver. But X isn't happy with it. This is in a laptop with the A8-7410. It claims Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD Graphics wiki, or any of the links from there. Has anyone set one of these up sucessfully? Is it even possible? If so, what must I do? hey chris - what happens when you load the amdgpu driver via rc.conf? does it load correctly, or does the system crash on boot? for example what does "dmesg | grep drm" look like? assuming it does load successfully i think you are using the wrong xorg driver as the xf86-ati driver is ATI not amd devices. Does loading xf86-video-amdgpu work better? cheers, -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: Is the graphics on AMD A8-7410 APU (Radeon R5 Graphics) supported?
On 3/23/22 15:09, Chris wrote: On 2022-03-23 14:57, Pete Wright wrote: On 3/23/22 14:44, Chris wrote: On a releng/13 install. I've installed the drm-kmod and loaded both the amdgpu and the radeonkms (at different times). I also installed the xf86-ati driver. But X isn't happy with it. This is in a laptop with the A8-7410. It claims Radeon R5 (formerly Carrizo). I find no mention of it in the on the FBSD Graphics wiki, or any of the links from there. Has anyone set one of these up sucessfully? Is it even possible? If so, what must I do? hey chris - what happens when you load the amdgpu driver via rc.conf? does it load correctly, or does the system crash on boot? for example what does "dmesg | grep drm" look like? Hey pete, thanks for the prompt reply! It "flashes" but the resolution doesn't appear to change. It's booting UEFI, if that should matter. grep(1) output attached. It's a bit long to paste inline. assuming it does load successfully i think you are using the wrong xorg driver as the xf86-ati driver is ATI not amd devices. Does loading xf86-video-amdgpu work better? You're probably right. I'll give that a try. Thanks again! :-) no worries! i took a peek at your dmesg and i think once you install the amdgpu xorg driver you'll be good to go. the screen flash is just the display cutting over to the new driver and is expected. looks like it detected both of your displays too so you window manager should pick them up too. a bunch of work was done recently to make xorg load up correctly without any configuration files - so you shouldn't even need to setup an xorg.conf or anything like that :) have fun! -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: loading amfgpu results in immefiate power off on 12.3-STABLE r371721
On 3/25/22 21:42, Chris wrote: This probably isn't the correct list. But it's the closest of all the lists I'm subscribed to. Please forgive me. OK so here's what happened. I couldn't get the trackpad on a Dell laptop I just got to work in FreeBSD-13. So after a couple of days, I gave up and tried 12.3-STABLE r371721 today. Once I got the network (wifi) going. I pkg installed drm-kmod && it's depends. Added kld_list="amdgpu" to rc.conf && rebooted. The moment it loaded, the screen went black and it powered off. Booted to single-user, fsck && cp /var/log/messages to ~/ . I'm attaching a copy in case it sheds any light on the cause. The most interesting thing about all this, is that amdgpu worked flawlessly on 13 -- go figure. this discussion is probably best suited for the freebsd-x11 mailing list, but i think you can try a couple things: - give NomadBSD a spin (https://nomadbsd.org/). it's a live USB image that does a really good job at auto-detecting hardware and giving you nice desktop. it's based on freebsd-13.0. you can also install it on your disk if everything looks good. i frequently use it to test hardware support on new systems i encounter. - it's hard to tell without any hardware info provided, but its possible you have an older AMD gpu, as such you might want to try using radeonkms in rc.conf rather than amdgpu. if neither of those things help i'd definitely suggest subscribing to the freebsd-x11@ mailing list to get the appropriate eyes on things: https://lists.freebsd.org/subscription/freebsd-x11 -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Re: -CURRENT hangs since at least 2022-04-04
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 -- Pete Wright p...@nomadlogic.org @nomadlogicLA
Chasing OOM Issues - good sysctl metrics to use?
hello - on my workstation running CURRENT (amd64/32g of ram) i've been running into a scenario where after 4 or 5 days of daily use I get an OOM event and both chromium and firefox are killed. then in the next day or so the system will become very unresponsive in the morning when i unlock my screensaver in the morning forcing a manual power cycle. one thing i've noticed is growing swap usage but plenty of free and inactive memory as well as a GB or so of memory in the Laundry state according top. my understanding is that seeing swap usage grow over time is expected and doesn't necessarily indicate a problem. but what concerns me is the system locking up while seeing quite a bit of disk i/o (maybe from paging back in?). in order to help chase this down i've setup the prometheus_sysctl_exporter(8) to send data to a local prometheus instance. the goal is to examine memory utilizaton over time to help detect any issues. so my question is this: what OID's would be useful to help see to help diagnose weird memory issues like this? i'm currently looking at: sysctl_vm_domain_0_stats_laundry sysctl_vm_domain_0_stats_active sysctl_vm_domain_0_stats_free_count sysctl_vm_domain_0_stats_inactive_pps thanks in advance - and i'd be happy to share my data if anyone is interested :) -pete -- Pete Wright p...@nomadlogic.org @nomadlogicLA
