Re: DRM-current-kmod is still a problem at r353339
Hi! On 2019-10-24 01:32, Clay Daniels Jr. wrote: 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? That is a specific revision of the source tree, not a snapshot. A snapshot that is later than r353906 is enough. It is also possible to update FreeBSD to arbitrary revisions by building the system from source. 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... Sometimes, it is enough to have a photo of the information. It is not as convenient as having it in text form, but in a pinch, it will do. However, I'd syggest that you either update your system by building it from source (you can find details here: https://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/current-stable.html) or wait for a more recent snapshot, before trying again. As a side note, please try to leave your reply below the message you are replying to, it makes the flow of the text more natural, as this way, you will read the e-mail in the order it was written. 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
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: 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"
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-21 11:08, Yuri Pankov wrote: Niclas Zeising wrote: On 2019-10-20 08:45, Yuri Pankov wrote: On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? This is a known regression with drm-devel-kmod, and one of the reasons it hasn't made it past devel yet. Got it, thanks. I'm only seeing it on the lenovo laptop with hd630 and not on the intel nuc with iris plus 650 graphics, so I thought it's that laptop specific. It is a strange error. I'm seeing it on my laptop (an x270) but only on the internal screen. If I connect an external screen using HDMI that screen works, but still not the internal screen. Others aren't having this issue at all. https://github.com/FreeBSDDesktop/kms-drm/issues/151 has some more (not very much more) info. 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
Niclas Zeising wrote: On 2019-10-20 08:45, Yuri Pankov wrote: On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? This is a known regression with drm-devel-kmod, and one of the reasons it hasn't made it past devel yet. Got it, thanks. I'm only seeing it on the lenovo laptop with hd630 and not on the intel nuc with iris plus 650 graphics, so I thought it's that laptop specific. ___ 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-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? 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-21 09:01, Thomas Mueller wrote: from Neel Chauhan: For me, the following code is still necessary for me (HP Spectre x360 2018), which is the remaining parts of the patches not committed if you are using a recent kernel. I don't know about you all ThinkPad users, it should still apply as it's Intel in general not just HP or Lenovo. Without these patches, I get a kernel panic. Keep in mind that the patch may render as spaces, but it should be tabs. What happens if the patch is applied with spaces as opposed to tabs? I believe, in C, there is no difference as far as compiling is concerned. Or is it just a standard for formatting? If the whitespace isn't correct, the patch won't apply cleanly. It has no effect on compiling the code though. 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-20 08:45, Yuri Pankov wrote: On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? This is a known regression with drm-devel-kmod, and one of the reasons it hasn't made it past devel yet. 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
from Neel Chauhan: > For me, the following code is still necessary for me (HP Spectre x360 > 2018), which is the remaining parts of the patches not committed if you > are using a recent kernel. I don't know about you all ThinkPad users, it > should still apply as it's Intel in general not just HP or Lenovo. > Without these patches, I get a kernel panic. > Keep in mind that the patch may render as spaces, but it should be tabs. What happens if the patch is applied with spaces as opposed to tabs? I believe, in C, there is no difference as far as compiling is concerned. Or is it just a standard for formatting? Tom ___ 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 10/21/2019 4:14 AM, Neel Chauhan wrote:
For me, the following code is still necessary for me (HP Spectre x360
2018), which is the remaining parts of the patches not committed if you
are using a recent kernel. I don't know about you all ThinkPad users, it
should still apply as it's Intel in general not just HP or Lenovo.
Without these patches, I get a kernel panic.
Keep in mind that the patch may render as spaces, but it should be tabs.
Index: amd64/pmap.c
===
--- amd64/pmap.c (revision 353788)
+++ amd64/pmap.c (working copy)
@@ -355,8 +355,9 @@
} \
} while (0)
-#define CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) \
- CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#define CHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do { \
+ CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)
#define RELEASE_PV_LIST_LOCK(lockp) do { \
struct rwlock **_lockp = (lockp); \
@@ -951,8 +952,16 @@
static u_long *
pmap_delayed_invl_genp(vm_page_t m)
{
+ vm_paddr_t pa;
+ u_long *gen;
- return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+ pa = VM_PAGE_TO_PHYS(m);
+ if (__predict_false((pa) > pmap_last_pa))
+ gen = _dummy_large.pv_invl_gen;
+ else
+ gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+ return (gen);
}
#else
static u_long *
If you look below, that's exactly the patch mjg@ provided and Xin
pointed you at.
On 2019-10-20 02:45, Yuri Pankov wrote:
On 10/18/2019 8:01 AM, Xin Li wrote:
Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
-> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) ,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.
Confirmed that it worked for me too on P51.
Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?
___
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
For me, the following code is still necessary for me (HP Spectre x360
2018), which is the remaining parts of the patches not committed if you
are using a recent kernel. I don't know about you all ThinkPad users, it
should still apply as it's Intel in general not just HP or Lenovo.
Without these patches, I get a kernel panic.
Keep in mind that the patch may render as spaces, but it should be tabs.
Index: amd64/pmap.c
===
--- amd64/pmap.c(revision 353788)
+++ amd64/pmap.c(working copy)
@@ -355,8 +355,9 @@
}\
} while (0)
-#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m)\
-CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m))
+#defineCHANGE_PV_LIST_LOCK_TO_VM_PAGE(lockp, m) do {\
+CHANGE_PV_LIST_LOCK_TO_PHYS(lockp, VM_PAGE_TO_PHYS(m)); \
+} while (0)
#defineRELEASE_PV_LIST_LOCK(lockp)do {\
struct rwlock **_lockp = (lockp);\
@@ -951,8 +952,16 @@
static u_long *
pmap_delayed_invl_genp(vm_page_t m)
{
+vm_paddr_t pa;
+u_long *gen;
-return (_to_pmdp(VM_PAGE_TO_PHYS(m))->pv_invl_gen);
+pa = VM_PAGE_TO_PHYS(m);
+if (__predict_false((pa) > pmap_last_pa))
+gen = _dummy_large.pv_invl_gen;
+else
+gen = &(pa_to_pmdp(pa)->pv_invl_gen);
+
+return (gen);
}
#else
static u_long *
-Neel
===
https://www.neelc.org/
On 2019-10-20 02:45, Yuri Pankov wrote:
On 10/18/2019 8:01 AM, Xin Li wrote:
Another (semi-fixed!) data point -- I can confirm that with if
(vm_page_sleep_if_busy(page, "linuxkpi"))
-> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and
mjg@'s earlier patch at
https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it)
,
the latest drm-v5.0 branch of drm-current-kmod worked just fine with
Intel HD Graphics P630 on Lenovo P51.
Confirmed that it worked for me too on P51.
Sorry for offtopic, but do you see the console getting "stuck" after
loading i915kms, i.e. for input to show you need to switch to another
console and back?
___
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
On 10/18/2019 8:01 AM, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. Confirmed that it worked for me too on P51. Sorry for offtopic, but do you see the console getting "stuck" after loading i915kms, i.e. for input to show you need to switch to another console and back? ___ 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
>> Another (semi-fixed!) data point -- I can confirm that with if >> (vm_page_sleep_if_busy(page, "linuxkpi")) >> -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and >> mjg@'s earlier patch at >> https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , >> the latest drm-v5.0 branch of drm-current-kmod worked just fine with >> Intel HD Graphics P630 on Lenovo P51. Thank you very much. Now, it is good working r353722M(1300053) on 3 machines. (1) DELL Vostro 3267 desktop (core i5-7500) Both patches are required. (2) DELL Vostro 3568 notebook (Celeron 3865U) Both patches are required. (3) DELL XPS 12 9Q33 notebook (core i7-4500U) At least mjg@'s pmap-fict-invl patch is required. -- Masachika ISHIZUKA ___ 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
Have you patched with mjg@'s pmap-fict-invl.diff? The panic seems to be similar... Cheers, On Fri, Oct 18, 2019 at 2:01 AM Neel Chauhan wrote: > This still panicks for me, but with a different error. > > https://i.postimg.cc/K8nxF57G/IMG-20191018-045338.jpg > > I really should be sleeping but can't because I have to use an older > kernel to have working graphics. Thanks, Netflix for making my life > harder. > > -Neel > > On 2019-10-18 01:01, Xin Li wrote: > > Another (semi-fixed!) data point -- I can confirm that with if > > (vm_page_sleep_if_busy(page, "linuxkpi")) > > -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and > > mjg@'s earlier patch at > > https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) > > , > > the latest drm-v5.0 branch of drm-current-kmod worked just fine with > > Intel HD Graphics P630 on Lenovo P51. > > > > On 2019-10-17 18:37, Neel Chauhan wrote: > >> However, the patch to drm-kmod doesn't work for me. I tried both > >> drm-devel-kmod and drm-current-kmod. > >> > >> https://i.imgur.com/81JvaOO.jpg > >> > >> -Neel > >> > >> === > >> > >> https://www.neelc.org/ > >> > >> On 2019-10-17 17:35, Eirik Øverby wrote: > >>> On 10/17/19 11:29 PM, Eirik Øverby wrote: > On 10/17/19 10:31 PM, 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: > >>> .. > >> 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. > >>> ...>> > > 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? > > Built, rebooting ... Will hopefully check back in soon. > >>> > >>> And tada, I'm back. That seemed to do the trick. Thanks! > >>> > >>> /Eirik > >>> ___ > >>> 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" > > ___ > > 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" > ___ 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
> Another (semi-fixed!) data point -- I can confirm that with if > (vm_page_sleep_if_busy(page, "linuxkpi")) > -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and > mjg@'s earlier patch at > https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , > the latest drm-v5.0 branch of drm-current-kmod worked just fine with > Intel HD Graphics P630 on Lenovo P51. Thank you very good information. As I was updated from r352923(1300048) to r353722M(1300053) with https://people.freebsd.org/~mjg/pmap-fict-invl.diff, it can good working with drm-current-kmod with i5-7500 desktop machine. Without https://people.freebsd.org/~mjg/pmap-fict-invl.diff patch, drm-current-kmod is loaded success fully, but when starting xorg, drm-current-kmod was paniced as follows. (The following syslog was on i7-4500U notebook machine on r352923.) kernel: WARNING !drm_modeset_is_locked(>mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:577 syslogd: last message repeated 2 times kernel: WARNING !drm_modeset_is_locked(>mode_config.connection_mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:622 kernel: WARNING !drm_modeset_is_locked(>mutex) failed at /usr/local/sys/modules/drm-current-kmod/drivers/gpu/drm/drm_atomic_helper.c:821 syslogd: last message repeated 8 times kernel: WARN_ON(!mutex_is_locked(>struct_mutex)) kernel: WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>lock))WARN_ON(!mutex_is_locked(>lock)) kernel: panic: handle_workitem_remove: DIRCHG and worklist not empty. kernel: cpuid = 2 kernel: time = 1571387388 kernel: KDB: stack backtrace: kernel: db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame 0xfe0060c4e860 kernel: vpanic() at vpanic+0x19d/frame 0xfe0060c4e8b0 kernel: panic() at panic+0x43/frame 0xfe0060c4e910 kernel: handle_workitem_remove() at handle_workitem_remove+0x607/frame 0xfe0060c4e980 kernel: process_worklist_item() at process_worklist_item+0x270/frame 0xfe0060c4ea00 kernel: softdep_process_worklist() at softdep_process_worklist+0xb2/frame 0xfe0060c4ea40 kernel: softdep_flush() at softdep_flush+0xef/frame 0xfe0060c4ea70 kernel: fork_exit() at fork_exit+0x84/frame 0xfe0060c4eab0 kernel: fork_trampoline() at fork_trampoline+0xe/frame 0xfe0060c4eab0 kernel: --- trap 0, rip = 0, rsp = 0, rbp = 0 --- kernel: Uptime: 11h21m3s kernel: Dumping 874 out of 8058 MB:..2%..11%..21%..32%..41%..52%..61%..72%..81%..92% -- Masachika ISHIZUKA ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
Hey, thanks for the patch and the CC, coincidentally I had some time to look into this again. On dj., oct. 17 2019, ma...@freebsd.org wrote: I believe it was the recent work on the vm page busy state, r353539 specifically. This patch should fix it; we don't yet have a __FreeBSD_version number bump on which to gate the patch. diff --git a/linuxkpi/gplv2/src/linux_page.c b/linuxkpi/gplv2/src/linux_page.c index e2b85c45c..060ae85ed 100644 --- a/linuxkpi/gplv2/src/linux_page.c +++ b/linuxkpi/gplv2/src/linux_page.c @@ -239,7 +239,7 @@ retry: page = vm_page_lookup(devobj, i); if (page == NULL) continue; - if (vm_page_sleep_if_busy(page, "linuxkpi")) + if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) goto retry; cdev_pager_free_page(devobj, page); } I can confirm this works now on AMD Ryzen 7 PRO 2700U w/ Radeon Vega Mobile Gfx :-D. Took the liberty of adding to the end of this message some schematic steps to upgrade world+kernel+drm-devel-kmod in a setup with poudriere+boot environments, I hope they are helpful for someone else. If not using poudriere/boot environments, those bits can be skipped. Now I have trick questions: What is the upgrade plan here? What would happen when 13 is released and people upgrade from 12? I mean, AFAIU one first upgrades world+kernel, then upgrades ports; in cases where drm-kmod is used, that seems to leave the system in an "unusable" state between those steps (there is single-user-mode which allows removal or upgrade of drm-kmod, but regular boot crashes) and since this is a compile-time patch, there doesn't seem to be an easy way to solve that. I saw Mark has a PR to apply the patch to 12.1 as well, but I think that will have the same upgrade path issue? Am I thinking too far ahead here or is there something I'm missing? The mentioned steps: 1. Built world and kernel from HEAD, in this case: FreeBSD 13.0-CURRENT #4 7f37066f607-c263595(master) 2. Created a boot environment so I can go back to it if things don't work out 3. Removed drm-devel-kmod 4. Installed world and kernel 5. Rebooted into a system without graphics, but with the new world and kernel 6. Destroyed my poudriere jail 7. Re-created it (drm-devel-kmod didn't build without steps 6 and 7) 8. Patched poudriere's ports directory: graphics/drm-devel-kmod as follows: --- Makefile(revision 514712) +++ Makefile(working copy) @@ -2,7 +2,7 @@ # $FreeBSD$ PORTNAME= drm-devel-kmod -PORTVERSION= 5.0.g20190828 +PORTVERSION= 5.0.g20191017 CATEGORIES= graphics kld MAINTAINER= x...@freebsd.org @@ -28,7 +28,7 @@ USE_GITHUB= yes GH_ACCOUNT= FreeBSDDesktop GH_PROJECT= kms-drm -GH_TAGNAME=dc414a9 +GH_TAGNAME=761ef739 9. Ran make makesum in graphics/drm-devel-kmod 10. Added the patch Mark mentioned before to graphics/drm-devel-kmod: # cat files/patch-linuxkpi_gplv2_src_linux__page.c --- linuxkpi/gplv2/src/linux_page.c.orig2019-08-27 19:58:24 UTC +++ linuxkpi/gplv2/src/linux_page.c @@ -239,7 +239,7 @@ retry: page = vm_page_lookup(devobj, i); if (page == NULL) continue; - if (vm_page_sleep_if_busy(page, "linuxkpi")) + if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) goto retry; cdev_pager_free_page(devobj, page); } 11. Built the port in poudriere 12. Installed drm-devel-kmod 13. Reboot and profit Thank you again for looking into this! -- Evilham ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
This still panicks for me, but with a different error. https://i.postimg.cc/K8nxF57G/IMG-20191018-045338.jpg I really should be sleeping but can't because I have to use an older kernel to have working graphics. Thanks, Netflix for making my life harder. -Neel On 2019-10-18 01:01, Xin Li wrote: Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. On 2019-10-17 18:37, Neel Chauhan wrote: However, the patch to drm-kmod doesn't work for me. I tried both drm-devel-kmod and drm-current-kmod. https://i.imgur.com/81JvaOO.jpg -Neel === https://www.neelc.org/ On 2019-10-17 17:35, Eirik Øverby wrote: On 10/17/19 11:29 PM, Eirik Øverby wrote: On 10/17/19 10:31 PM, 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: .. 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. ...>> 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? Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ 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" ___ 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
Another (semi-fixed!) data point -- I can confirm that with if (vm_page_sleep_if_busy(page, "linuxkpi")) -> if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL)) change and mjg@'s earlier patch at https://people.freebsd.org/~mjg/pmap-fict-invl.diff (please commit it) , the latest drm-v5.0 branch of drm-current-kmod worked just fine with Intel HD Graphics P630 on Lenovo P51. On 2019-10-17 18:37, Neel Chauhan wrote: > However, the patch to drm-kmod doesn't work for me. I tried both > drm-devel-kmod and drm-current-kmod. > > https://i.imgur.com/81JvaOO.jpg > > -Neel > > === > > https://www.neelc.org/ > > On 2019-10-17 17:35, Eirik Øverby wrote: >> On 10/17/19 11:29 PM, Eirik Øverby wrote: >>> On 10/17/19 10:31 PM, 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: >> .. > 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. >> ...>> 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? >>> >>> Built, rebooting ... Will hopefully check back in soon. >> >> And tada, I'm back. That seemed to do the trick. Thanks! >> >> /Eirik >> ___ >> 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" ___ 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
However, the patch to drm-kmod doesn't work for me. I tried both drm-devel-kmod and drm-current-kmod. https://i.imgur.com/81JvaOO.jpg -Neel === https://www.neelc.org/ On 2019-10-17 17:35, Eirik Øverby wrote: On 10/17/19 11:29 PM, Eirik Øverby wrote: On 10/17/19 10:31 PM, 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: .. 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. ...>> 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? Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ 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
On 10/17/19 11:29 PM, Eirik Øverby wrote: > On 10/17/19 10:31 PM, 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: .. >>> 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. ...>> >> 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? > > Built, rebooting ... Will hopefully check back in soon. And tada, I'm back. That seemed to do the trick. Thanks! /Eirik ___ 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 10/17/19 10:31 PM, 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? Built, rebooting ... Will hopefully check back in soon. /Eirik ___ 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 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 ___ 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-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? Thanks! 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 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); } ___ 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 10/17/19 3:03 PM, 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 have the same problem, same panic, as Neel. ThinkPad X1 Carbon Gen6. I'm bulding again right now, but my previous build was from EuroBSDCon so finding the commit that breaks is going to be kinda hard (unless you have some ninja trick to teach me). I notice there has been some significant changes to vm_pmap.c and friends since my build from yesterday, so here's hoping it's fixed.. Wbr /Eirik ___ 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-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? 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
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).
-Neel
===
https://www.neelc.org/
On 2019-10-13 10:37, Mateusz Guzik wrote:
On 10/13/19, Evilham wrote:
Hello,
I somehow had managed to mess up my build system and only
yesterday got it back to compiling properly.
So to be clear, there is an unrelated bug where it seems the module can
decide to abort loading and then it crashes in pseudofs. This can
happen
if there is a mismatch between the kernel and the module itself.
On ds., oct. 12 2019, Mateusz Guzik wrote:
Try this:
https://people.freebsd.org/~mjg/pmap-fict-invl.diff
I tested this patch on top of r353449 and a panic is still
ocurring when the drm-kmod modules are loaded.
This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
and a Radeon Vega graphics.
My last known working revision is r352987.
Here are bits of the core dump, I hope they are useful, if more
information is needed, please don't hesitate to ask.
BTW: I usually compile GENERIC-NODEBUG, if that results in the
dump being useless (sadly I can't tell), I can disable all the
performance goodies and compile GENERIC :-).
--
Evilham
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xf8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80b1be61
stack pointer = 0x28:0xfe00dd81ccc0
frame pointer = 0x28:0xfe00dd81ccf0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24022 (kldload)
trap number = 12
panic: page fault
cpuid = 2
time = 1570970502
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00dd81c920
vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
panic() at panic+0x43/frame 0xfe00dd81c9e0
trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
trap() at trap+0x288/frame 0xfe00dd81cbf0
calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
--- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
rbp = 0xfe00dd81ccf0 ---
pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
module_register_init() at module_register_init+0xa4/frame
0xfe00dd81cd80
linker_load_module() at linker_load_module+0xb49/frame
0xfe00dd81d0a0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d0f0
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d1b0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d4d0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d520
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d5e0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d900
kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe00dd81dab0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
KDB: enter: panic
__curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at
/freebsd/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at
/freebsd/src/sys/kern/kern_shutdown.c:392
#2 0x80496a7a in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=)
at /freebsd/src/sys/ddb/db_command.c:575
#3 0x8049683c in db_command (last_cmdp=,
cmd_table=, dopager=1)
at /freebsd/src/sys/ddb/db_command.c:482
#4 0x804965ad in db_command_loop ()
at /freebsd/src/sys/ddb/db_command.c:535
#5 0x80499858 in db_trap (type=,
code=)
at /freebsd/src/sys/ddb/db_main.c:252
#6 0x80c322a7 in kdb_trap (type=3, code=0, tf=)
at /freebsd/src/sys/kern/subr_kdb.c:692
#7 0x8105d925 in trap (frame=0xfe00dd81c850)
at /freebsd/src/sys/amd64/amd64/trap.c:585
#8
#9 kdb_enter (why=0x811dee7e "panic", msg=)
at /freebsd/src/sys/kern/subr_kdb.c:479
#10 0x80be377a in vpanic (fmt=,
ap=)
at /freebsd/src/sys/kern/kern_shutdown.c:897
#11 0x80be35d3 in panic (
fmt=0x818e4c18
"\357\327\037\201\377\377\377\377") at
/freebsd/src/sys/kern/kern_shutdown.c:835
#12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
eva=248)
at
Re: DRM-current-kmod is still a problem at r353339
On 10/13/19, Evilham wrote:
> Hello,
>
> I somehow had managed to mess up my build system and only
> yesterday got it back to compiling properly.
>
So to be clear, there is an unrelated bug where it seems the module can
decide to abort loading and then it crashes in pseudofs. This can happen
if there is a mismatch between the kernel and the module itself.
>
> On ds., oct. 12 2019, Mateusz Guzik wrote:
>
>> Try this:
>>
>> https://people.freebsd.org/~mjg/pmap-fict-invl.diff
>
>
> I tested this patch on top of r353449 and a panic is still
> ocurring when the drm-kmod modules are loaded.
>
> This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
> and a Radeon Vega graphics.
> My last known working revision is r352987.
>
>
> Here are bits of the core dump, I hope they are useful, if more
> information is needed, please don't hesitate to ask.
> BTW: I usually compile GENERIC-NODEBUG, if that results in the
> dump being useless (sadly I can't tell), I can disable all the
> performance goodies and compile GENERIC :-).
> --
> Evilham
>
>
> Fatal trap 12: page fault while in kernel mode
> cpuid = 2; apic id = 02
> fault virtual address = 0xf8
> fault code = supervisor read data, page not present
> instruction pointer = 0x20:0x80b1be61
> stack pointer = 0x28:0xfe00dd81ccc0
> frame pointer = 0x28:0xfe00dd81ccf0
> code segment= base 0x0, limit 0xf, type 0x1b
> = DPL 0, pres 1, long 1, def32 0, gran 1
> processor eflags= interrupt enabled, resume, IOPL = 0
> current process = 24022 (kldload)
> trap number = 12
> panic: page fault
> cpuid = 2
> time = 1570970502
> KDB: stack backtrace:
> db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
> 0xfe00dd81c920
> vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
> panic() at panic+0x43/frame 0xfe00dd81c9e0
> trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
> trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
> trap() at trap+0x288/frame 0xfe00dd81cbf0
> calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
> --- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
> rbp = 0xfe00dd81ccf0 ---
> pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
> pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
> vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
> module_register_init() at module_register_init+0xa4/frame
> 0xfe00dd81cd80
> linker_load_module() at linker_load_module+0xb49/frame
> 0xfe00dd81d0a0
> linker_load_dependencies() at linker_load_dependencies+0x18c/frame
> 0xfe00dd81d0f0
> link_elf_load_file() at link_elf_load_file+0x1127/frame
> 0xfe00dd81d1b0
> linker_load_module() at linker_load_module+0x89a/frame
> 0xfe00dd81d4d0
> linker_load_dependencies() at linker_load_dependencies+0x18c/frame
> 0xfe00dd81d520
> link_elf_load_file() at link_elf_load_file+0x1127/frame
> 0xfe00dd81d5e0
> linker_load_module() at linker_load_module+0x89a/frame
> 0xfe00dd81d900
> kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
> sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
> amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
> fast_syscall_common() at fast_syscall_common+0x101/frame
> 0xfe00dd81dab0
> --- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
> rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
> KDB: enter: panic
>
>
> __curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
> 55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
> (offsetof(struct pcpu,
> (kgdb) #0 __curthread () at
> /freebsd/src/sys/amd64/include/pcpu_aux.h:55
> #1 doadump (textdump=0) at
> /freebsd/src/sys/kern/kern_shutdown.c:392
> #2 0x80496a7a in db_dump (dummy=,
> dummy2=, dummy3=,
> dummy4=)
> at /freebsd/src/sys/ddb/db_command.c:575
> #3 0x8049683c in db_command (last_cmdp=,
> cmd_table=, dopager=1)
> at /freebsd/src/sys/ddb/db_command.c:482
> #4 0x804965ad in db_command_loop ()
> at /freebsd/src/sys/ddb/db_command.c:535
> #5 0x80499858 in db_trap (type=,
> code=)
> at /freebsd/src/sys/ddb/db_main.c:252
> #6 0x80c322a7 in kdb_trap (type=3, code=0, tf= out>)
> at /freebsd/src/sys/kern/subr_kdb.c:692
> #7 0x8105d925 in trap (frame=0xfe00dd81c850)
> at /freebsd/src/sys/amd64/amd64/trap.c:585
> #8
> #9 kdb_enter (why=0x811dee7e "panic", msg= out>)
> at /freebsd/src/sys/kern/subr_kdb.c:479
> #10 0x80be377a in vpanic (fmt=,
> ap=)
> at /freebsd/src/sys/kern/kern_shutdown.c:897
> #11 0x80be35d3 in panic (
> fmt=0x818e4c18
> "\357\327\037\201\377\377\377\377") at
> /freebsd/src/sys/kern/kern_shutdown.c:835
> #12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
> eva=248)
> at /freebsd/src/sys/amd64/amd64/trap.c:925
> #13 0x8105ddff in
Re: DRM-current-kmod is still a problem at r353339
Hello,
I somehow had managed to mess up my build system and only
yesterday got it back to compiling properly.
On ds., oct. 12 2019, Mateusz Guzik wrote:
Try this:
https://people.freebsd.org/~mjg/pmap-fict-invl.diff
I tested this patch on top of r353449 and a panic is still
ocurring when the drm-kmod modules are loaded.
This is on a Lenovo A485 Laptop, which is an AMD Ryzen processor
and a Radeon Vega graphics.
My last known working revision is r352987.
Here are bits of the core dump, I hope they are useful, if more
information is needed, please don't hesitate to ask.
BTW: I usually compile GENERIC-NODEBUG, if that results in the
dump being useless (sadly I can't tell), I can disable all the
performance goodies and compile GENERIC :-).
--
Evilham
Fatal trap 12: page fault while in kernel mode
cpuid = 2; apic id = 02
fault virtual address = 0xf8
fault code = supervisor read data, page not present
instruction pointer = 0x20:0x80b1be61
stack pointer = 0x28:0xfe00dd81ccc0
frame pointer = 0x28:0xfe00dd81ccf0
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, long 1, def32 0, gran 1
processor eflags= interrupt enabled, resume, IOPL = 0
current process = 24022 (kldload)
trap number = 12
panic: page fault
cpuid = 2
time = 1570970502
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfe00dd81c920
vpanic() at vpanic+0x17e/frame 0xfe00dd81c980
panic() at panic+0x43/frame 0xfe00dd81c9e0
trap_pfault() at trap_pfault/frame 0xfe00dd81ca50
trap_pfault() at trap_pfault+0x4f/frame 0xfe00dd81cac0
trap() at trap+0x288/frame 0xfe00dd81cbf0
calltrap() at calltrap+0x8/frame 0xfe00dd81cbf0
--- trap 0xc, rip = 0x80b1be61, rsp = 0xfe00dd81ccc0,
rbp = 0xfe00dd81ccf0 ---
pfs_destroy() at pfs_destroy+0x11/frame 0xfe00dd81ccf0
pfs_uninit() at pfs_uninit+0x16/frame 0xfe00dd81cd10
vfs_modevent() at vfs_modevent+0x474/frame 0xfe00dd81cd50
module_register_init() at module_register_init+0xa4/frame
0xfe00dd81cd80
linker_load_module() at linker_load_module+0xb49/frame
0xfe00dd81d0a0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d0f0
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d1b0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d4d0
linker_load_dependencies() at linker_load_dependencies+0x18c/frame
0xfe00dd81d520
link_elf_load_file() at link_elf_load_file+0x1127/frame
0xfe00dd81d5e0
linker_load_module() at linker_load_module+0x89a/frame
0xfe00dd81d900
kern_kldload() at kern_kldload+0xbd/frame 0xfe00dd81d950
sys_kldload() at sys_kldload+0x5b/frame 0xfe00dd81d980
amd64_syscall() at amd64_syscall+0x3a3/frame 0xfe00dd81dab0
fast_syscall_common() at fast_syscall_common+0x101/frame
0xfe00dd81dab0
--- syscall (304, FreeBSD ELF64, sys_kldload), rip = 0x8002d1cda,
rsp = 0x7fffd748, rbp = 0x7fffdcc0 ---
KDB: enter: panic
__curthread () at /freebsd/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n"
(offsetof(struct pcpu,
(kgdb) #0 __curthread () at
/freebsd/src/sys/amd64/include/pcpu_aux.h:55
#1 doadump (textdump=0) at
/freebsd/src/sys/kern/kern_shutdown.c:392
#2 0x80496a7a in db_dump (dummy=,
dummy2=, dummy3=,
dummy4=)
at /freebsd/src/sys/ddb/db_command.c:575
#3 0x8049683c in db_command (last_cmdp=,
cmd_table=, dopager=1)
at /freebsd/src/sys/ddb/db_command.c:482
#4 0x804965ad in db_command_loop ()
at /freebsd/src/sys/ddb/db_command.c:535
#5 0x80499858 in db_trap (type=,
code=)
at /freebsd/src/sys/ddb/db_main.c:252
#6 0x80c322a7 in kdb_trap (type=3, code=0, tf=out>)
at /freebsd/src/sys/kern/subr_kdb.c:692
#7 0x8105d925 in trap (frame=0xfe00dd81c850)
at /freebsd/src/sys/amd64/amd64/trap.c:585
#8
#9 kdb_enter (why=0x811dee7e "panic", msg=out>)
at /freebsd/src/sys/kern/subr_kdb.c:479
#10 0x80be377a in vpanic (fmt=,
ap=)
at /freebsd/src/sys/kern/kern_shutdown.c:897
#11 0x80be35d3 in panic (
fmt=0x818e4c18
"\357\327\037\201\377\377\377\377") at
/freebsd/src/sys/kern/kern_shutdown.c:835
#12 0x8105ddb0 in trap_fatal (frame=0xfe00dd81cc00,
eva=248)
at /freebsd/src/sys/amd64/amd64/trap.c:925
#13 0x8105ddff in trap_pfault (frame=0xfe00dd81cc00,
usermode=, signo=,
ucode=)
at /freebsd/src/sys/amd64/amd64/trap.c:743
#14 0x8105d458 in trap (frame=0xfe00dd81cc00)
at /freebsd/src/sys/amd64/amd64/trap.c:407
#15
#16 pfs_destroy (pn=0x0) at
/freebsd/src/sys/fs/pseudofs/pseudofs.c:324
#17 0x80b1ca96 in pfs_uninit (
pi=0x8360f120 ,
vfc=0x8360f010 )
at /freebsd/src/sys/fs/pseudofs/pseudofs.c:473
#18
Re: DRM-current-kmod is still a problem at r353339
The patch doesn't work for me on i915kms on a HP Spectre x360 13-p0043dx. I get a panic Screenshot: https://user-images.githubusercontent.com/5403564/66688014-d1a16700-ec52-11e9-9c3b-902f49e311de.png As of now, I'm using an older kernel. -Neel === https://www.neelc.org/ On 2019-10-11 10:28, Thomas Laus wrote: On 2019-10-10 13:44, Mateusz Guzik wrote: Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom ___ 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
The patch doesn't work for me on i915kms on a HP Spectre x360 13-p0043dx. I get a panic Screenshot: https://user-images.githubusercontent.com/5403564/66688014-d1a16700-ec52-11e9-9c3b-902f49e311de.png As of now, I'm using an older kernel. -Neel === https://www.neelc.org/ On 2019-10-11 10:28, Thomas Laus wrote: On 2019-10-10 13:44, Mateusz Guzik wrote: Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom ___ 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
Try this: https://people.freebsd.org/~mjg/pmap-fict-invl.diff On 10/12/19, Neel Chauhan wrote: > The patch doesn't work for me on i915kms on a HP Spectre x360 > 13-p0043dx. I get a panic > > Screenshot: > https://user-images.githubusercontent.com/5403564/66688014-d1a16700-ec52-11e9-9c3b-902f49e311de.png > > As of now, I'm using an older kernel. > > -Neel > > === > > https://www.neelc.org/ > > On 2019-10-11 10:28, Thomas Laus wrote: >> On 2019-10-10 13:44, Mateusz Guzik wrote: >>> Probably whitespace issues from copypasting. I used dpaste since >>> people.freebsd.org was down. >>> >>> It's up, so: >>> https://people.freebsd.org/~mjg/pmap-fict3.diff >>> >> That patch worked for me also. The patch applied clean when I used >> 'wget' to retrieve vs. saving a file from my web browser. >> >> Thanks for the quick fix. >> >> Tom > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-10 13:44, Mateusz Guzik wrote: > Probably whitespace issues from copypasting. I used dpaste since > people.freebsd.org was down. > > It's up, so: > https://people.freebsd.org/~mjg/pmap-fict3.diff > That patch worked for me also. The patch applied clean when I used 'wget' to retrieve vs. saving a file from my web browser. Thanks for the quick fix. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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 19. 10. 10., Mateusz Guzik wrote: > Probably whitespace issues from copypasting. I used dpaste since > people.freebsd.org was down. > > It's up, so: > https://people.freebsd.org/~mjg/pmap-fict3.diff This patch fixed a similar problem for me. FYI, I am using drm-devel-kmod for "AMD Ryzen 5 3500U with Radeon Vega Mobile Gfx" (aka. Vega 8). Jung-uk Kim > On 10/10/19, Thomas Laus wrote: >> On 2019-10-10 12:21, Mateusz Guzik wrote: >>> Try this: >>> >>> http://dpaste.com/0P2MXF6 >>> >>> if it still fails, provide the panic info + the first debug line(the >>> one with "pv_table"). >>> >> This patch did not apply cleanly to my source tree checked out today. >> My pmap.c version is r353311. I saved the file to filename pmap.diff >> and ran the patch utility with the command "patch -i pmap.diff" from the >> /sys/amd64/amd64 directory. Should I be using a different utility to >> patch this file? The FreeBSD patch utility has always worked for me in >> the past. >> >> Tom >> >> -- >> Public Keys: >> PGP KeyID = 0x5F22FDC1 >> GnuPG KeyID = 0x620836CF signature.asc Description: OpenPGP digital signature
Re: DRM-current-kmod is still a problem at r353339
Probably whitespace issues from copypasting. I used dpaste since people.freebsd.org was down. It's up, so: https://people.freebsd.org/~mjg/pmap-fict3.diff On 10/10/19, Thomas Laus wrote: > On 2019-10-10 12:21, Mateusz Guzik wrote: >> Try this: >> >> http://dpaste.com/0P2MXF6 >> >> if it still fails, provide the panic info + the first debug line(the >> one with "pv_table"). >> > This patch did not apply cleanly to my source tree checked out today. > My pmap.c version is r353311. I saved the file to filename pmap.diff > and ran the patch utility with the command "patch -i pmap.diff" from the > /sys/amd64/amd64 directory. Should I be using a different utility to > patch this file? The FreeBSD patch utility has always worked for me in > the past. > > Tom > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: DRM-current-kmod is still a problem at r353339
On 2019-10-10 12:21, Mateusz Guzik wrote: > Try this: > > http://dpaste.com/0P2MXF6 > > if it still fails, provide the panic info + the first debug line(the > one with "pv_table"). > This patch did not apply cleanly to my source tree checked out today. My pmap.c version is r353311. I saved the file to filename pmap.diff and ran the patch utility with the command "patch -i pmap.diff" from the /sys/amd64/amd64 directory. Should I be using a different utility to patch this file? The FreeBSD patch utility has always worked for me in the past. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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
Try this: http://dpaste.com/0P2MXF6 if it still fails, provide the panic info + the first debug line(the one with "pv_table"). On 10/10/19, Thomas Laus wrote: > List: > > I am still getting kernel panics on my laptop after the recent changes > made to /sys/amd64/amd64/pmap.c. > > The updated pmap.c works on my Skylake build machine but panics on my > laptop. I always build on the faster computer and perform a > installkernel and installworld from a nfs share. The Skylake is much > faster than the laptop. The hardware info from dmesg: > > Oct 9 17:27:37 inspiron kernel: VT(vga): resolution 640x480 > Oct 9 17:27:37 inspiron kernel: CPU: Intel(R) Core(TM)2 Duo CPU > T6400 @ 2.00GHz (1995.04-MHz K8-class CPU) > Oct 9 17:27:37 inspiron kernel: Origin="GenuineIntel" Id=0x1067a > Family=0x6 Model=0x17 Stepping=10 > Oct 9 17:27:37 inspiron kernel: > Features=0xbfebfbff > Oct 9 17:27:37 inspiron kernel: > Features2=0xc08e39d > Oct 9 17:27:37 inspiron kernel: AMD Features=0x20100800 > Oct 9 17:27:37 inspiron kernel: AMD Features2=0x1 > Oct 9 17:27:37 inspiron kernel: TSC: P-state invariant, performance > statistics > Oct 9 17:27:37 inspiron kernel: real memory = 3221225472 (3072 MB) > Oct 9 17:27:37 inspiron kernel: avail memory = 3040022528 (2899 MB) > Oct 9 17:27:37 inspiron kernel: Event timer "LAPIC" quality 100 > Oct 9 17:27:37 inspiron kernel: ACPI APIC Table: > Oct 9 17:27:37 inspiron kernel: FreeBSD/SMP: Multiprocessor System > Detected: 2 CPUs > Oct 9 17:27:37 inspiron kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) > Oct 9 17:27:37 inspiron kernel: random: unblocking device. > Oct 9 17:27:37 inspiron kernel: Firmware Warning (ACPI): 32/64X length > mismatch in FADT/Gpe0Block: 128/64 (20190703/tbfadt-748) > Oct 9 17:27:37 inspiron kernel: ioapic0: Changing APIC ID to 2 > Oct 9 17:27:37 inspiron kernel: ioapic0 irqs 0-23 > Oct 9 17:27:37 inspiron kernel: Launching APs: 1 > Oct 9 17:27:37 inspiron kernel: Timecounter "TSC" frequency 1995044780 > Hz quality 1000 > Oct 9 17:27:37 inspiron kernel: random: entropy device external interface > Oct 9 17:27:37 inspiron kernel: kbd1 at kbdmux0 > Oct 9 17:27:37 inspiron kernel: module_register_init: MOD_LOAD (vesa, > 0x811f7400, 0) error 19 > Oct 9 17:27:37 inspiron kernel: 000.45 [4335] netmap_init > netmap: loaded module > Oct 9 17:27:37 inspiron kernel: [ath_hal] loaded > Oct 9 17:27:37 inspiron kernel: nexus0 > Oct 9 17:27:37 inspiron kernel: vtvga0: > > I have a photo of the panic that I can send. > > Tom > > > -- > Public Keys: > PGP KeyID = 0x5F22FDC1 > GnuPG KeyID = 0x620836CF > ___ > 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" > -- Mateusz Guzik ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
DRM-current-kmod is still a problem at r353339
List: I am still getting kernel panics on my laptop after the recent changes made to /sys/amd64/amd64/pmap.c. The updated pmap.c works on my Skylake build machine but panics on my laptop. I always build on the faster computer and perform a installkernel and installworld from a nfs share. The Skylake is much faster than the laptop. The hardware info from dmesg: Oct 9 17:27:37 inspiron kernel: VT(vga): resolution 640x480 Oct 9 17:27:37 inspiron kernel: CPU: Intel(R) Core(TM)2 Duo CPU T6400 @ 2.00GHz (1995.04-MHz K8-class CPU) Oct 9 17:27:37 inspiron kernel: Origin="GenuineIntel" Id=0x1067a Family=0x6 Model=0x17 Stepping=10 Oct 9 17:27:37 inspiron kernel: Features=0xbfebfbff Oct 9 17:27:37 inspiron kernel: Features2=0xc08e39d Oct 9 17:27:37 inspiron kernel: AMD Features=0x20100800 Oct 9 17:27:37 inspiron kernel: AMD Features2=0x1 Oct 9 17:27:37 inspiron kernel: TSC: P-state invariant, performance statistics Oct 9 17:27:37 inspiron kernel: real memory = 3221225472 (3072 MB) Oct 9 17:27:37 inspiron kernel: avail memory = 3040022528 (2899 MB) Oct 9 17:27:37 inspiron kernel: Event timer "LAPIC" quality 100 Oct 9 17:27:37 inspiron kernel: ACPI APIC Table: Oct 9 17:27:37 inspiron kernel: FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs Oct 9 17:27:37 inspiron kernel: FreeBSD/SMP: 1 package(s) x 2 core(s) Oct 9 17:27:37 inspiron kernel: random: unblocking device. Oct 9 17:27:37 inspiron kernel: Firmware Warning (ACPI): 32/64X length mismatch in FADT/Gpe0Block: 128/64 (20190703/tbfadt-748) Oct 9 17:27:37 inspiron kernel: ioapic0: Changing APIC ID to 2 Oct 9 17:27:37 inspiron kernel: ioapic0 irqs 0-23 Oct 9 17:27:37 inspiron kernel: Launching APs: 1 Oct 9 17:27:37 inspiron kernel: Timecounter "TSC" frequency 1995044780 Hz quality 1000 Oct 9 17:27:37 inspiron kernel: random: entropy device external interface Oct 9 17:27:37 inspiron kernel: kbd1 at kbdmux0 Oct 9 17:27:37 inspiron kernel: module_register_init: MOD_LOAD (vesa, 0x811f7400, 0) error 19 Oct 9 17:27:37 inspiron kernel: 000.45 [4335] netmap_init netmap: loaded module Oct 9 17:27:37 inspiron kernel: [ath_hal] loaded Oct 9 17:27:37 inspiron kernel: nexus0 Oct 9 17:27:37 inspiron kernel: vtvga0: I have a photo of the panic that I can send. Tom -- Public Keys: PGP KeyID = 0x5F22FDC1 GnuPG KeyID = 0x620836CF ___ 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"
