Re: DRM-current-kmod is still a problem at r353339
Niclas, my last working install of 13.0 Current was r353072 of Oct 4th. The next week's r353427 of Oct 11th did not work and I reverted to r353072 for a week. Then r353709 of Oct 18th did not work, and when I tried to revert back to r353072 it does not work either. These were install from ports, not pkg install. I'm looking at the available Current amd64 snapshots and all I see are: r352778 (which worked), r353072 (worked), r353427 (did not work for me), & r353709 (did not work for me). I don't see a r353906? I would like to provide the full backtrace from the panic, as well as the output from kldstat -v, but the boot hangs at this point, and the first line of the panic I quoted above was a pen & paper transcription. Not sure how to get what you would like... I will also note that I saw that the gpu-firmware-kmod package has a date of 10-15-2019, but that may not have anything to do with this. Thanks, Niclas. I really like FreeBSD, and I'm working on a little FreeBSD project on efitools & secure boot, so I would like to get this working again. But actually the new snapshot will come out the day after tomorrow, so there's always hope. Clay On Wed, Oct 23, 2019 at 4:33 PM Niclas Zeising wrote: > On 2019-10-23 21:50, Clay Daniels Jr. wrote: > > r353709 > > Looked promising, but failed: > > > > Loaded r353709 > > make install drm-kmod, all 3 installed > > (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod) > > set /etc/rc.conf & /boot/loader.conf configs as usual > > rebooted and looked good, video tingling > > pkg install xorg > > rebooted and ran startx > > > > panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive > busy @ > > /usr/src/sys/vm/vm_page.c > > > > System: Ryzen 7 3700X, MSI 570 series motherboard & video card > > Hi! > Did this used to work before the recent changes to current? Can you > please update past current r353906, which contains some fixes that was > posted earlier in this thread. > > Can you also provide the full backtrace from the panic, as well as the > output from kldstat -v. > > Thank you! > Regards > -- > Niclas > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-23 21:50, Clay Daniels Jr. wrote: r353709 Looked promising, but failed: Loaded r353709 make install drm-kmod, all 3 installed (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod) set /etc/rc.conf & /boot/loader.conf configs as usual rebooted and looked good, video tingling pkg install xorg rebooted and ran startx panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy @ /usr/src/sys/vm/vm_page.c System: Ryzen 7 3700X, MSI 570 series motherboard & video card Hi! Did this used to work before the recent changes to current? Can you please update past current r353906, which contains some fixes that was posted earlier in this thread. Can you also provide the full backtrace from the panic, as well as the output from kldstat -v. Thank you! Regards -- Niclas ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
sorry, should be all 3 installed (drm-kmod, drm-current-kmod, & gpu-firmware-kmod) On Wed, Oct 23, 2019 at 2:50 PM Clay Daniels Jr. wrote: > r353709 > Looked promising, but failed: > > Loaded r353709 > make install drm-kmod, all 3 installed > (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod) > set /etc/rc.conf & /boot/loader.conf configs as usual > rebooted and looked good, video tingling > pkg install xorg > rebooted and ran startx > > panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy > @ /usr/src/sys/vm/vm_page.c > > System: Ryzen 7 3700X, MSI 570 series motherboard & video card > > Thanks for trying, > Clay > > On Wed, Oct 23, 2019 at 3:42 AM Niclas Zeising < > zeising+free...@daemonic.se> wrote: > >> On 2019-10-21 10:13, Niclas Zeising wrote: >> > On 2019-10-17 23:05, Mark Johnston wrote: >> >> On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote: >> >>> On 2019-10-17 21:53, ma...@freebsd.org wrote: >> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: >> > On 2019-10-16 18:57, Neel Chauhan wrote: >> >> While drm-current-kmod worked for a little while, it broke with >> >> r353645. >> >> >> >> https://i.imgur.com/Q5nYZf2.jpg >> >> >> >> I'm using the same HP Spectre that I used earlier (where it worked >> >> and >> >> where it panicked). >> >> >> > >> > That commit looks unrelated, it touches the wbwd and superio >> drivers, >> > nothing else. Any chance you can bisect exactly which revision that >> > caused the new issues? >> >> I believe it was the recent work on the vm page busy state, r353539 >> specifically. This patch should fix it; we don't yet have a >> __FreeBSD_version number bump on which to gate the patch. >> >> diff --git a/linuxkpi/gplv2/src/linux_page.c >> b/linuxkpi/gplv2/src/linux_page.c >> index e2b85c45c..060ae85ed 100644 >> --- a/linuxkpi/gplv2/src/linux_page.c >> +++ b/linuxkpi/gplv2/src/linux_page.c >> @@ -239,7 +239,7 @@ retry: >> page = vm_page_lookup(devobj, i); >> if (page == NULL) >> continue; >> -if (vm_page_sleep_if_busy(page, "linuxkpi")) >> +if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) >> goto retry; >> cdev_pager_free_page(devobj, page); >> } >> >>> >> >>> Hi! >> >>> Hopefully someone can confirm that this patch to drm-current-kmod or >> >>> drm-devel-kmod fixes the issue. I won't be able to work on this >> before >> >>> the weekend at the earliest, I'm afraid. >> >>> Mark, is it possible to get a belated version bump for this fix, and >> >>> what changed to require it? >> >> >> >> I committed the bump and verified the patch on amdgpu. Here are some >> >> PRs for the drivers: >> >> >> >> https://github.com/FreeBSDDesktop/kms-drm/pull/180 >> >> https://github.com/FreeBSDDesktop/kms-drm/pull/181 >> > >> > Hi! >> > I'm working on getting this into the versions that are in ports. For >> > drm-current-kmod it's fairly simple, but for drm-devel-kmod there are >> > unrelated changes which I need to check if they are ready to go in or >> > not, so it will take some more time. >> > >> > Looking at the mail list thread, there seems to be a patch needed for >> > base as well, has this been committed? >> >> drm-devel-kmod and drm-current-kmod has been updated with the above fix. >> If there are further issues, please let us know. >> Regards >> -- >> Niclas >> ___ >> freebsd-current@freebsd.org mailing list >> https://lists.freebsd.org/mailman/listinfo/freebsd-current >> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org >> " >> > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
r353709 Looked promising, but failed: Loaded r353709 make install drm-kmod, all 3 installed (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod) set /etc/rc.conf & /boot/loader.conf configs as usual rebooted and looked good, video tingling pkg install xorg rebooted and ran startx panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy @ /usr/src/sys/vm/vm_page.c System: Ryzen 7 3700X, MSI 570 series motherboard & video card Thanks for trying, Clay On Wed, Oct 23, 2019 at 3:42 AM Niclas Zeising wrote: > On 2019-10-21 10:13, Niclas Zeising wrote: > > On 2019-10-17 23:05, Mark Johnston wrote: > >> On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote: > >>> On 2019-10-17 21:53, ma...@freebsd.org wrote: > On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: > > On 2019-10-16 18:57, Neel Chauhan wrote: > >> While drm-current-kmod worked for a little while, it broke with > >> r353645. > >> > >> https://i.imgur.com/Q5nYZf2.jpg > >> > >> I'm using the same HP Spectre that I used earlier (where it worked > >> and > >> where it panicked). > >> > > > > That commit looks unrelated, it touches the wbwd and superio drivers, > > nothing else. Any chance you can bisect exactly which revision that > > caused the new issues? > > I believe it was the recent work on the vm page busy state, r353539 > specifically. This patch should fix it; we don't yet have a > __FreeBSD_version number bump on which to gate the patch. > > diff --git a/linuxkpi/gplv2/src/linux_page.c > b/linuxkpi/gplv2/src/linux_page.c > index e2b85c45c..060ae85ed 100644 > --- a/linuxkpi/gplv2/src/linux_page.c > +++ b/linuxkpi/gplv2/src/linux_page.c > @@ -239,7 +239,7 @@ retry: > page = vm_page_lookup(devobj, i); > if (page == NULL) > continue; > -if (vm_page_sleep_if_busy(page, "linuxkpi")) > +if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) > goto retry; > cdev_pager_free_page(devobj, page); > } > >>> > >>> Hi! > >>> Hopefully someone can confirm that this patch to drm-current-kmod or > >>> drm-devel-kmod fixes the issue. I won't be able to work on this before > >>> the weekend at the earliest, I'm afraid. > >>> Mark, is it possible to get a belated version bump for this fix, and > >>> what changed to require it? > >> > >> I committed the bump and verified the patch on amdgpu. Here are some > >> PRs for the drivers: > >> > >> https://github.com/FreeBSDDesktop/kms-drm/pull/180 > >> https://github.com/FreeBSDDesktop/kms-drm/pull/181 > > > > Hi! > > I'm working on getting this into the versions that are in ports. For > > drm-current-kmod it's fairly simple, but for drm-devel-kmod there are > > unrelated changes which I need to check if they are ready to go in or > > not, so it will take some more time. > > > > Looking at the mail list thread, there seems to be a patch needed for > > base as well, has this been committed? > > drm-devel-kmod and drm-current-kmod has been updated with the above fix. > If there are further issues, please let us know. > Regards > -- > Niclas > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" > ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: > r353680: multiuser crash due to: m_getzone: Inavlid cluster size 0
This is 241403 in bugzilla. On Wed, Oct 23, 2019, 12:57 AM O. Hartmann wrote: > The last known good update of CURRENT on a Fujitsu Primergy RX2530-M5 > (only one > of two sockets equipted, 64 GB RAM) was October, 17th, 2019 before 15 > o'clock, > I suppose that was r353680 that time. Today's update to r353881 resulted > in an > immediate crash when the network (igb0-igb3, two built-in i350 NICs and two > i350 NICs placed on a i350-T2 server adapter) comes up, just when rc > scripts > configure the NIC's. > > Last message I see is something like m_getzone: Inavlid cluster size 0 and > "dubugnet" or similar. Since the crash wrecked the installation (it seems > after > updating, the UFS filesystem received, as so often, inconsistencies, so I > can > not start vi or other applications after a full fsck -yf on all partitons, > those programs fail with some serious trap, stating that ELF is corrupt, I > can't remember the exact message). We do not have debugging facilities > enabled > on that kernel suite, so I can not provide more proper informations. > > For emergency rescue we downloaded the latest CURRENT memstick image, > FreeBSD-13.0-CURRENT-amd64-20191018-r353709-memstick.img dated Oct., 18th, > which > also shows the bug described above. > > It seems that I have to go back to memimage > FreeBSD-13.0-CURRENT-amd64-20191011-r353427-memstick.img which dates to > 11th > October 2019. > Since the crash resulted in a serious damage of the base filesystem and the > installation, I need to copy first the installation tarballs from the > install > memstick into place and try then to rebuild the system with sources up to > the > version which is deemed working. The I'll report, hopefully, more > information. > > Kind regards, > oh > > Addendum: > > r353680 works > r353709 doesn't work > > > [...] > /etc # more /var/crash/info.last > Dump header from device: /dev/da0p2 > Architecture: amd64 > Architecture Version: 2 > Dump Length: 2952835072 > Blocksize: 512 > Compression: none > Dumptime: Tue Oct 22 12:13:19 2019 > Hostname: wotan.lan101.bundesimmobilien.intern > Magic: FreeBSD Kernel Dump > Version String: FreeBSD 13.0-CURRENT #11 r353877: Tue Oct 22 11:02:32 > CEST > 2019 root@:/usr/obj/usr/src/amd64.amd64/sys/WOTAN > Panic String: m_getzone: invalid cluster size 0 > Dump Parity: 2027469319 > Bounds: 0 > Dump Status: good > [...] > > [...] > > # more /var/crash/core.txt.0 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > /dev/stdin:1: Error in sourced command file: > Cannot access memory at address 0x65657246 > > > [...] > > > [...] > ---<>--- > Copyright (c) 1992-2019 The FreeBSD Project. > Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 > The Regents of the University of California. All rights reserved. > FreeBSD is a registered trademark of The FreeBSD Foundation. > FreeBSD 13.0-CURRENT #14 r353680: Wed Oct 23 08:50:04 CEST 2019 > root@wotan.lan101.bundesimmobilien.intern > :/usr/obj/usr/src/amd64.amd64/sys/WOTAN > amd64 FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on > LLVM 9.0.0) VT(efifb): resolution 1280x1024 > CPU microcode: no matching update found > CPU: Intel(R) Xeon(R) Gold 5217 CPU @ 3.00GHz (2993.05-MHz K8-class CPU) > Origin="GenuineIntel" Id=0x50657 Family=0x6 Model=0x55 Stepping=7 > > Features=0xbfebfbff > > Features2=0x7ffefbff > AMD Features=0x2c100800 > AMD Features2=0x121 > Structured Extended > > Features=0xd39b > Structured Extended Features2=0x808 Structured Extended > Features3=0xbc000400 XSAVE > Features=0xf > IA32_ARCH_CAPS=0x2b VT-x: > PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, > performance > statistics real memory = 68719476736 (65536 MB) > avail memory = 66361274368 (63287 MB) > Event timer "LAPIC" quality 600 > ACPI APIC Table: > FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs > FreeBSD/SMP: 1 package(s) x 8 core(s) x 2 hardware threads > random: registering fast source Intel Secure Key RNG > random: fast provider: "Intel Secure Key RNG" > random: unblocking device. > Security policy loaded: MAC/ntpd (mac_ntpd) > ioapic0 irqs 0-23 > ioapic1 irqs 24-31 > ioapic2 irqs 32-39 > ioapic3 irqs 40-47 > ioapic4 irqs 48-55 > Launching APs: 1 13 5 12 9 14 8 7 10 6 11 15 3 4 2 > Timecounter "TSC-low" frequency 1496523352 Hz quality 1000 > random: entropy device external interface > kbd0 at kbdmux0 > [...] > ___ > freebsd-current@freebsd.org mailing list > https://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" >
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-21 10:13, Niclas Zeising wrote: On 2019-10-17 23:05, Mark Johnston wrote: On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote: On 2019-10-17 21:53, ma...@freebsd.org wrote: On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote: On 2019-10-16 18:57, Neel Chauhan wrote: While drm-current-kmod worked for a little while, it broke with r353645. https://i.imgur.com/Q5nYZf2.jpg I'm using the same HP Spectre that I used earlier (where it worked and where it panicked). That commit looks unrelated, it touches the wbwd and superio drivers, nothing else. Any chance you can bisect exactly which revision that caused the new issues? I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. diff --git a/linuxkpi/gplv2/src/linux_page.c b/linuxkpi/gplv2/src/linux_page.c index e2b85c45c..060ae85ed 100644 --- a/linuxkpi/gplv2/src/linux_page.c +++ b/linuxkpi/gplv2/src/linux_page.c @@ -239,7 +239,7 @@ retry: page = vm_page_lookup(devobj, i); if (page == NULL) continue; - if (vm_page_sleep_if_busy(page, "linuxkpi")) + if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) goto retry; cdev_pager_free_page(devobj, page); } Hi! Hopefully someone can confirm that this patch to drm-current-kmod or drm-devel-kmod fixes the issue. I won't be able to work on this before the weekend at the earliest, I'm afraid. Mark, is it possible to get a belated version bump for this fix, and what changed to require it? I committed the bump and verified the patch on amdgpu. Here are some PRs for the drivers: https://github.com/FreeBSDDesktop/kms-drm/pull/180 https://github.com/FreeBSDDesktop/kms-drm/pull/181 Hi! I'm working on getting this into the versions that are in ports. For drm-current-kmod it's fairly simple, but for drm-devel-kmod there are unrelated changes which I need to check if they are ready to go in or not, so it will take some more time. Looking at the mail list thread, there seems to be a patch needed for base as well, has this been committed? drm-devel-kmod and drm-current-kmod has been updated with the above fix. If there are further issues, please let us know. Regards -- Niclas ___ 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"
> r353680: multiuser crash due to: m_getzone: Inavlid cluster size 0
The last known good update of CURRENT on a Fujitsu Primergy RX2530-M5 (only one of two sockets equipted, 64 GB RAM) was October, 17th, 2019 before 15 o'clock, I suppose that was r353680 that time. Today's update to r353881 resulted in an immediate crash when the network (igb0-igb3, two built-in i350 NICs and two i350 NICs placed on a i350-T2 server adapter) comes up, just when rc scripts configure the NIC's. Last message I see is something like m_getzone: Inavlid cluster size 0 and "dubugnet" or similar. Since the crash wrecked the installation (it seems after updating, the UFS filesystem received, as so often, inconsistencies, so I can not start vi or other applications after a full fsck -yf on all partitons, those programs fail with some serious trap, stating that ELF is corrupt, I can't remember the exact message). We do not have debugging facilities enabled on that kernel suite, so I can not provide more proper informations. For emergency rescue we downloaded the latest CURRENT memstick image, FreeBSD-13.0-CURRENT-amd64-20191018-r353709-memstick.img dated Oct., 18th, which also shows the bug described above. It seems that I have to go back to memimage FreeBSD-13.0-CURRENT-amd64-20191011-r353427-memstick.img which dates to 11th October 2019. Since the crash resulted in a serious damage of the base filesystem and the installation, I need to copy first the installation tarballs from the install memstick into place and try then to rebuild the system with sources up to the version which is deemed working. The I'll report, hopefully, more information. Kind regards, oh Addendum: r353680 works r353709 doesn't work [...] /etc # more /var/crash/info.last Dump header from device: /dev/da0p2 Architecture: amd64 Architecture Version: 2 Dump Length: 2952835072 Blocksize: 512 Compression: none Dumptime: Tue Oct 22 12:13:19 2019 Hostname: wotan.lan101.bundesimmobilien.intern Magic: FreeBSD Kernel Dump Version String: FreeBSD 13.0-CURRENT #11 r353877: Tue Oct 22 11:02:32 CEST 2019 root@:/usr/obj/usr/src/amd64.amd64/sys/WOTAN Panic String: m_getzone: invalid cluster size 0 Dump Parity: 2027469319 Bounds: 0 Dump Status: good [...] [...] # more /var/crash/core.txt.0 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 /dev/stdin:1: Error in sourced command file: Cannot access memory at address 0x65657246 [...] [...] ---<>--- Copyright (c) 1992-2019 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD is a registered trademark of The FreeBSD Foundation. FreeBSD 13.0-CURRENT #14 r353680: Wed Oct 23 08:50:04 CEST 2019 root@wotan.lan101.bundesimmobilien.intern:/usr/obj/usr/src/amd64.amd64/sys/WOTAN amd64 FreeBSD clang version 9.0.0 (tags/RELEASE_900/final 372316) (based on LLVM 9.0.0) VT(efifb): resolution 1280x1024 CPU microcode: no matching update found CPU: Intel(R) Xeon(R) Gold 5217 CPU @ 3.00GHz (2993.05-MHz K8-class CPU) Origin="GenuineIntel" Id=0x50657 Family=0x6 Model=0x55 Stepping=7 Features=0xbfebfbff Features2=0x7ffefbff AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0xd39b Structured Extended Features2=0x808 Structured Extended Features3=0xbc000400 XSAVE Features=0xf IA32_ARCH_CAPS=0x2b VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID,VID,PostIntr TSC: P-state invariant, performance statistics real memory = 68719476736 (65536 MB) avail memory = 66361274368 (63287 MB) Event timer "LAPIC" quality 600 ACPI APIC Table: FreeBSD/SMP: Multiprocessor System Detected: 16 CPUs FreeBSD/SMP: 1 package(s) x 8 core(s) x 2 hardware threads random: registering fast source Intel Secure Key RNG random: fast provider: "Intel Secure Key RNG" random: unblocking device. Security policy loaded: MAC/ntpd (mac_ntpd) ioapic0 irqs 0-23 ioapic1 irqs 24-31 ioapic2 irqs 32-39 ioapic3 irqs 40-47 ioapic4 irqs 48-55 Launching APs: 1 13 5 12 9 14 8 7 10 6 11 15 3 4 2 Timecounter "TSC-low" frequency 1496523352 Hz quality 1000 random: entropy device external interface kbd0 at kbdmux0 [...] ___ 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"
