Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485

2019-07-20 Thread Evilham

Hey,

thanks for the feedback and your work, didn't think this would be 
interesting for anyone but the laptop owners.



On ds., jul. 20 2019, Greg V. wrote:

On July 20, 2019 1:54:47 AM GMT+03:00, Evilham 
 wrote:



it even suspends and resumes back to X


Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I 
need suspend very much on desktop haha)


Indeed, I was pleasantly surprised too


- xbacklight doesn't work, neither does intel-backlight because
 it's AMD


Since it's a Thinkpad, do the brightness keys work anyway? Does 
acpi_ibm work?


Forgot to mention brightness keys, they also don't work.
I just tried acpi_ibm and it also didn't help.


Serious issue:
I was just debugging this right now, more infos with a proper 
bug

report will come, but I think the system encounters a deadlock
sometimes with the drm-kmod / amdgpu which results in a kernel
panic.


If you're on the packaged drm-kmod v4.16, it's amazing that 
Raven GPU works at all. You should try drm-v5.0 from git.



kld_list="amdgpu"


Huh, interesting, I'm trying to compile drm-v5.0 right now.
This comment and Pete's made me re-visit the graphics settings, 
specifics below.



It even works when loaded this early? Interesting. Do you also 
not have the EFI framebuffer conflict? i.e. without disabling 
vt.syscons, everything just works reliably?


Yes, with my previous laptop that was necessary, but this one has 
no need for those settings, it works just fine without and font 
size is according to the screen (i.e. it's not huge).




On ds., jul. 20 2019, Pete Wright wrote:


On 7/19/19 3:54 PM, Evilham wrote:


Serious issue:
I was just debugging this right now, more infos with a proper 
bug

report will come, but I think the system encounters a deadlock
sometimes with the drm-kmod / amdgpu which results in a kernel 
panic.
It is a serious issue, but it allows me to use the computer for 
work,
it doesn't happen every couple hours, but it does happen a 
couple

times a day.

FWIW, this is part of the crashlog:

WARNING !drm_modeset_is_locked(>mutex) failed at
/wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821
[Multiple times...]
kernel trap 22 with interrupts disabled
 kernel trap 22 with interrupts
 disabled
kernel trap 22 with interrupts disabled
kernel trap 22 with interrupts disabled
 panic: spin lock held too long



interesting. can you post this kernel panic, and any backtraces 
you are

able to get here:

https://github.com/FreeBSDDesktop/kms-drm/issues

also, are you using the xf86-video-amdgpu driver, or the stock
modesetting driver to X?



That was my plan for when I manage to fully isolate that it is on 
drm-kmod, thank you for confirming the path!


I noticed I did have xf86-video-amdgpu installed, but just removed 
it and all traces of drm-kmod as well as the kld_list="amdgpu" bit 
and X actually works without it and without the xf86-video 
packages.


HDMI output won't work though, I guess that makes sense.

We'll see if working like this the system doesn't crash at all, if 
it does it may be related to #231760 and not to drm-kmod.


If it does not crash without drm-kmod, I'll try my build of 
drm-kmod v5.0 before opening an issue, that'd be more information 
:-).


I did have the question as to why the packaged version is 4.16 but 
didn't quite find an answer to that on the wikis / documentation.


Thank you again,
--
Evilham
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: vmx0: watchdog timeout on queue 2, no interrupts on BSP

2019-07-20 Thread Patrick Kelsey
On Fri, Jul 19, 2019 at 10:07 AM Andriy Gapon  wrote:

>
> Recently we experienced a strange problem.
> We noticed a lot of these messages in the logs:
> vmx0: watchdog timeout on queue 2
> (always queue 2)
> Also, we noticed that connections to some end points did not work at all
> while others worked without problems.  I assume that that was because
> specific flows got assigned to that queue 2.
>
> Further investigation has shown that none of interrupts assigned to the
> BSP has ever fired (since boot, of course).  That included vmx0:rx2 and
> vmx0:tx2.  But also interrupts for other drivers as well.
>
> Trying to get more information I rebooted the system and the problem
> disappeared.
>
> Has anyone seen anything like that?
> Any thoughts on possible causes?
> Any suggestions what to check if/when the problem reoccurs?
>
> Thanks!
>
>
If you are running head at or after r347221 or stable/12 at or after r349112,
then this could be due to
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239118 (see Comment 4 -
short story is that an iflib change has broken the vmx driver).

-Patrick
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485

2019-07-20 Thread Greg V
On July 20, 2019 1:54:47 AM GMT+03:00, Evilham  wrote:

> it even suspends and resumes back to X

Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I need suspend 
very much on desktop haha)

>- xbacklight doesn't work, neither does intel-backlight because 
>  it's AMD

Since it's a Thinkpad, do the brightness keys work anyway? Does acpi_ibm work?

>Serious issue:
>I was just debugging this right now, more infos with a proper bug 
>report will come, but I think the system encounters a deadlock 
>sometimes with the drm-kmod / amdgpu which results in a kernel 
>panic.

If you're on the packaged drm-kmod v4.16, it's amazing that Raven GPU works at 
all. You should try drm-v5.0 from git.

>kld_list="amdgpu"

It even works when loaded this early? Interesting. Do you also not have the EFI 
framebuffer conflict? i.e. without disabling vt.syscons, everything just works 
reliably?
___
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"