FYI: RPi4B via ACPI style boot suggests "armv8crypto0: CPU lacks AES instructions" can lead to a hung up boot sequence in 14.0-BETA2
See: https://lists.freebsd.org/archives/freebsd-arm/2023-September/003071.html for details. (It is not my activity.) === Mark Millard marklmi at yahoo.com
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Sun, Nov 13, 2022 at 2:11 PM Tomoaki AOKI wrote: > On Sun, 13 Nov 2022 09:53:00 -0800 > Steve Rikli wrote: > > > On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.free...@xs4all.nl wrote: > > > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ > the system stays active. > > > However . that is also the end the GUI in this case GNOME. > > > > > > Since I could not work which a machine hibernating every ^10 minutes^, > I have disabled gdm for the moment. > > > That does not take away that that is .. ridiculous !! > > > > Seems like you aren't alone in that opinion -- there are several threads > > for multiple OSes about this same topic. Kirk's findings below match my > > recollection -- this is Gnome default behavior nowdays. > > > > In any case, since we obviously can't use the Linux systemD settings to > > control the behavior in FreeBSD, a few folks mentioned other workarounds > > with things like dconf; e.g. this suggestion which came originally from > > the Arch linux folks: > > > > https://twitter.com/_neelc/status/1487200568149831681 > > > > https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28) > > > > Something like: > > > > sudo -u gdm dbus-launch gsettings set \ > > org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type > 'nothing' > > > > >From the threads, it sounds like part of the problem is this behavior > and > > settings are per-user, so making a system-wide change is hard. Not sure > > how this workaround will play in your situation. > > > > My FreeBSD servers don't run a gui display manager; my Debian laptop > > runs gdm3 display manager but I switched to Xfce for the window manager > > around the time Gnome3 came out (too many changes for my taste). Fwiw > > the Xfce Power Manager has controls for system power save / sleep mode > > for "On battery" and "Plugged in", including "never". > > Found these. > > > https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad > > > https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf > > /etc/ in those should be read /usr/local/etc/ on FreeBSD. > And possibly defaults of each application are stored > under /usr/local/share/ or under /usr/local/lib/. > > BTW, I'm basically using x11/mate, a fork from Gnome2. > It doesn't sleep by default on AC powerline. > (Old installation succeeding Gnome2 settings. So current default could > be different, though.) > > > > > Cheers, > > sr. > This is the source of foolishness that led to the creation of Linux Mint and to Mate. Mate does not have this stupidness and I suspect that Cinnamon does not, either. Gnome has simply gone off the rails. Another option is to NOT use gdm, but start Gnome with startx, which I have always done. You will need to create a suitable .xinitrc to set up dbus and run X as a child: exec ck-launch-session dbus-launch --exit-with-session mate-session Under Linux this stuff is all wrapped around systemd which makes dealing with it a pain. I am not remotely expert on this, but it works OK and I am hoping to figure out a bit more as time is available. -- Kevin Oberman, Part time kid herder and retired Network Engineer E-mail: rkober...@gmail.com PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Sun, 13 Nov 2022 09:53:00 -0800 Steve Rikli wrote: > On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.free...@xs4all.nl wrote: > > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the > > system stays active. > > However . that is also the end the GUI in this case GNOME. > > > > Since I could not work which a machine hibernating every ^10 minutes^, I > > have disabled gdm for the moment. > > That does not take away that that is .. ridiculous !! > > Seems like you aren't alone in that opinion -- there are several threads > for multiple OSes about this same topic. Kirk's findings below match my > recollection -- this is Gnome default behavior nowdays. > > In any case, since we obviously can't use the Linux systemD settings to > control the behavior in FreeBSD, a few folks mentioned other workarounds > with things like dconf; e.g. this suggestion which came originally from > the Arch linux folks: > > https://twitter.com/_neelc/status/1487200568149831681 > > https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28) > > Something like: > > sudo -u gdm dbus-launch gsettings set \ > org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing' > > >From the threads, it sounds like part of the problem is this behavior and > settings are per-user, so making a system-wide change is hard. Not sure > how this workaround will play in your situation. > > My FreeBSD servers don't run a gui display manager; my Debian laptop > runs gdm3 display manager but I switched to Xfce for the window manager > around the time Gnome3 came out (too many changes for my taste). Fwiw > the Xfce Power Manager has controls for system power save / sleep mode > for "On battery" and "Plugged in", including "never". Found these. https://unix.stackexchange.com/questions/289640/how-to-create-a-default-system-wide-dconf-setting-starting-from-just-created-ad https://askubuntu.com/questions/1038184/how-to-lockdown-system-wide-settings-with-dconf /etc/ in those should be read /usr/local/etc/ on FreeBSD. And possibly defaults of each application are stored under /usr/local/share/ or under /usr/local/lib/. BTW, I'm basically using x11/mate, a fork from Gnome2. It doesn't sleep by default on AC powerline. (Old installation succeeding Gnome2 settings. So current default could be different, though.) > > Cheers, > sr. > > > > There should be a way to disable ACPI in FreeBSD so that even gdm can not > > "kill" the machine !! > > I say ^kill^ because there is also another bug, the machine is not properly > > restarting form hibernation, > > Even not from S1. > > > > Louis > > > > -Original Message- > > From: Kirk McKusick > > Sent: Sunday, November 13, 2022 1:23 AM > > To: louis.free...@xs4all.nl > > Cc: freebsd-current@FreeBSD.org > > Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > > (on FreeBSD14 CURRENT) > > > > > From: > > > To: > > > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > > > (on FreeBSD14 CURRENT) > > > Date: Thu, 10 Nov 2022 21:29:21 +0100 > > > > > > I am still desperately trying to stop FreeBSD from sleeping, but I > > > simply do not manage. > > > > > > It is really very annoying that I have to restart the machine every > > > 10 minutes, when I am working via SSH. > > > > > > So if any one has a solution, it would be very much appreciated! > > > > > > It should ….. be possible to kill / stop ACPI some how 〓 > > > > > > If absolutely not possible in the actual build 〓, a cron job > > > restarting the timer every 5 minutes perhaps !!??? > > > > > > It is possible perhaps … that GNOME is initiating this, despite that > > > the GUI powersetting is screenblank “NEVER”. > > > > > > Whatever is causing the problem, the settings should be such that ^no > > > whatever program^ should not be capable to initiate the sleepmode. > > > > > > Louis > > > > If you are using Gnome, Gnome suspends the machine after 20 minutes if > > there is no mouse or keyboard activity. I went into settings, but there is > > no way to adjust this feature. Some web searching brought me to this page: > > > > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 > > > > Apparently the 20-minute suspend was made unchangable (at least not without > > changing the source code for Gnome and rebuilding it). > > Apparently this change was made to comply with EU power regulations. > > Anyway, this ruled out Gnome for me. > > > > Kirk McKusick > -- Tomoaki AOKI
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Sun, Nov 13, 2022 at 04:47:40PM +0100, louis.free...@xs4all.nl wrote: > I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the > system stays active. > However . that is also the end the GUI in this case GNOME. > > Since I could not work which a machine hibernating every ^10 minutes^, I have > disabled gdm for the moment. > That does not take away that that is .. ridiculous !! Seems like you aren't alone in that opinion -- there are several threads for multiple OSes about this same topic. Kirk's findings below match my recollection -- this is Gnome default behavior nowdays. In any case, since we obviously can't use the Linux systemD settings to control the behavior in FreeBSD, a few folks mentioned other workarounds with things like dconf; e.g. this suggestion which came originally from the Arch linux folks: https://twitter.com/_neelc/status/1487200568149831681 https://wiki.archlinux.org/title/GDM#GDM_auto-suspend_(GNOME_3.28) Something like: sudo -u gdm dbus-launch gsettings set \ org.gnome.settings-daemon.plugins.power sleep-inactive-ac-type 'nothing' >From the threads, it sounds like part of the problem is this behavior and settings are per-user, so making a system-wide change is hard. Not sure how this workaround will play in your situation. My FreeBSD servers don't run a gui display manager; my Debian laptop runs gdm3 display manager but I switched to Xfce for the window manager around the time Gnome3 came out (too many changes for my taste). Fwiw the Xfce Power Manager has controls for system power save / sleep mode for "On battery" and "Plugged in", including "never". Cheers, sr. > There should be a way to disable ACPI in FreeBSD so that even gdm can not > "kill" the machine !! > I say ^kill^ because there is also another bug, the machine is not properly > restarting form hibernation, > Even not from S1. > > Louis > > -Original Message- > From: Kirk McKusick > Sent: Sunday, November 13, 2022 1:23 AM > To: louis.free...@xs4all.nl > Cc: freebsd-current@FreeBSD.org > Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on > FreeBSD14 CURRENT) > > > From: > > To: > > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > > (on FreeBSD14 CURRENT) > > Date: Thu, 10 Nov 2022 21:29:21 +0100 > > > > I am still desperately trying to stop FreeBSD from sleeping, but I > > simply do not manage. > > > > It is really very annoying that I have to restart the machine every > > 10 minutes, when I am working via SSH. > > > > So if any one has a solution, it would be very much appreciated! > > > > It should ….. be possible to kill / stop ACPI some how > > > > If absolutely not possible in the actual build , a cron job > > restarting the timer every 5 minutes perhaps !!??? > > > > It is possible perhaps … that GNOME is initiating this, despite that > > the GUI powersetting is screenblank “NEVER”. > > > > Whatever is causing the problem, the settings should be such that ^no > > whatever program^ should not be capable to initiate the sleepmode. > > > > Louis > > If you are using Gnome, Gnome suspends the machine after 20 minutes if there > is no mouse or keyboard activity. I went into settings, but there is no way > to adjust this feature. Some web searching brought me to this page: > > https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 > > Apparently the 20-minute suspend was made unchangable (at least not without > changing the source code for Gnome and rebuilding it). > Apparently this change was made to comply with EU power regulations. > Anyway, this ruled out Gnome for me. > > Kirk McKusick
RE: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
I noticed that after disabling gdm in /etc/rc.conf ^"gdm_enable="N"^ the system stays active. However . that is also the end the GUI in this case GNOME. Since I could not work which a machine hibernating every ^10 minutes^, I have disabled gdm for the moment. That does not take away that that is .. ridiculous !! There should be a way to disable ACPI in FreeBSD so that even gdm can not "kill" the machine !! I say ^kill^ because there is also another bug, the machine is not properly restarting form hibernation, Even not from S1. Louis -Original Message- From: Kirk McKusick Sent: Sunday, November 13, 2022 1:23 AM To: louis.free...@xs4all.nl Cc: freebsd-current@FreeBSD.org Subject: Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT) > From: > To: > Subject: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? > (on FreeBSD14 CURRENT) > Date: Thu, 10 Nov 2022 21:29:21 +0100 > > I am still desperately trying to stop FreeBSD from sleeping, but I > simply do not manage. > > It is really very annoying that I have to restart the machine every > 10 minutes, when I am working via SSH. > > So if any one has a solution, it would be very much appreciated! > > It should ….. be possible to kill / stop ACPI some how > > If absolutely not possible in the actual build , a cron job > restarting the timer every 5 minutes perhaps !!??? > > It is possible perhaps … that GNOME is initiating this, despite that > the GUI powersetting is screenblank “NEVER”. > > Whatever is causing the problem, the settings should be such that ^no > whatever program^ should not be capable to initiate the sleepmode. > > Louis If you are using Gnome, Gnome suspends the machine after 20 minutes if there is no mouse or keyboard activity. I went into settings, but there is no way to adjust this feature. Some web searching brought me to this page: https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/22 Apparently the 20-minute suspend was made unchangable (at least not without changing the source code for Gnome and rebuilding it). Apparently this change was made to comply with EU power regulations. Anyway, this ruled out Gnome for me. Kirk McKusick
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On Thu, Nov 10, 2022 at 10:21:24PM -0500, Alexander Motin wrote: > On 10.11.2022 15:29, louis.free...@xs4all.nl wrote: > > I am still desperately trying to stop FreeBSD from sleeping, but I > > simply do not manage. > > > > It is really very annoying that I have to restart the machine every 10 > > minutes, when I am working via SSH. > > > > So if any one has a solution, it would be very much appreciated! > > > > It should ….. be possible to kill / stop ACPI some how > > > > If absolutely not possible in the actual build , a cron job restarting > > the timer every 5 minutes perhaps !!??? > > I've never used it, so just an idea, but there is sysctl > kern.suspend_blocked that being set to 1 seems should block suspend > requests. You may try to set it and see what happen. > > > It is possible perhaps … that GNOME is initiating this, despite that the > > GUI powersetting is screenblank “NEVER”. > > It is not a screen blank. Gnome site tells: > https://help.gnome.org/users/gnome-help/stable/power-autosuspend.html.en > > > Whatever is causing the problem, the settings should be such that ^no > > whatever program^ should not be capable to initiate the sleepmode. > > Does the system suspends if you do not start Gnome? For example if you boot > into single-user mode and leave the system there? It would be the easiest > test probably. This sounds somewhat like the Gnome gdm3 behavior that causes some(?) Linuxes to suspend & sleep after 20 minutes (ymmv?) by default if gdm3 is running. E.g. https://wiki.debian.org/Suspend IME it didn't matter if user was logged in to desktop or not, the mere presence of a running gdm3 process was enough to trigger the behavior unless it was disabled. My FreeBSD's without gdm3 don't see this. Obviously there's no Linux systemD in-play here, but along the lines Alexander suggests, you might try stopping any running gdm3 processes and see if the sleep behavior persists. That would at least give some hint as to the vicinity of the problem. sr.
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
On 10.11.2022 15:29, louis.free...@xs4all.nl wrote: I am still desperately trying to stop FreeBSD from sleeping, but I simply do not manage. It is really very annoying that I have to restart the machine every 10 minutes, when I am working via SSH. So if any one has a solution, it would be very much appreciated! It should ….. be possible to kill / stop ACPI some how If absolutely not possible in the actual build , a cron job restarting the timer every 5 minutes perhaps !!??? I've never used it, so just an idea, but there is sysctl kern.suspend_blocked that being set to 1 seems should block suspend requests. You may try to set it and see what happen. It is possible perhaps … that GNOME is initiating this, despite that the GUI powersetting is screenblank “NEVER”. It is not a screen blank. Gnome site tells: https://help.gnome.org/users/gnome-help/stable/power-autosuspend.html.en Whatever is causing the problem, the settings should be such that ^no whatever program^ should not be capable to initiate the sleepmode. Does the system suspends if you do not start Gnome? For example if you boot into single-user mode and leave the system there? It would be the easiest test probably. -- Alexander Motin
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
> On Nov 11, 2022, at 4:29 AM, > wrote: > > I am still desperately trying to stop FreeBSD from sleeping, but I simply do > not manage. > > It is really very annoying that I have to restart the machine every 10 > minutes, when I am working via SSH. I think you will need to find the event triggering sleep (ACPI s1 / s3) every 10 minutes. > So if any one has a solution, it would be very much appreciated! > > It should ….. be possible to kill / stop ACPI some how > If absolutely not possible in the actual build , a cron job restarting the > timer every 5 minutes perhaps !!??? > > It is possible perhaps … that GNOME is initiating this, despite that the GUI > powersetting is screenblank “NEVER”. Probably. (or some other components of the GNOME) I've dozens of VMs / baremetal machines used as servers and routers. None of them sleep (without explicitly means such as acpiconf). I've not use FreeBSD as desktop since about ten year ago. > Whatever is causing the problem, the settings should be such that ^no > whatever program^ should not be capable to initiate the sleepmode. > > > Louis > > I need to disable acpi and the indicated method for that is to add > ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . > However that crashes my system !! > Not only that, to make it work again I have to edit loader.conf on a system > which does ^not start^. > > After a lot of searching Internet came to the help with, I could start the > system again: > 1. Select 3. Escape to loader prompt at the splash screen > 2. Type set hint.acpi.0.disabled="0" on the loader prompt > 3. Then type boot on the loader prompt > edit the loader.conf > Very very glad with that fix however > > However the problem is still there, no idea how to prevent the system from > going to sleep (after about 10 minutes). > No idea how to change those 10 minutes to a much longer time as well > > Note that I have gnome as gui and use the system more or less as server and > manage the machine partly local via the GUI and partly remote via SSH. I think you can disable GUI / GNOME completely and try again. > > Related to GNOME I did try ^gsettings set > org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, however > that did not solve the problem as well. > > In the end there seems to two problems > a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and > b) a GNOME issue (switching the system off during user inactivity, which is > bullshit for a server / for ssh-login / with multiple users). > What IMHO apart from the screen lock, this is not a GNOME task but an OS > function to be configured by the system administrator. > > A third problem, not to be addressed here, is that recovery from sleep mode > does not work on my system as well (even not S1). > > Most important for the moment is that the system keeps running / is not going > down after x-time ! > > Louis Best regards, Zhenlei
Re: DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
Hi, I don't know what you mean by "sleep", but some CPUs have bug and setting: sysctl machdep.idle=spin Helps! --HPS
DESPARATE: How to stop FreeBSD form sleeping / disable ACPI? (on FreeBSD14 CURRENT)
I am still desperately trying to stop FreeBSD from sleeping, but I simply do not manage. � It is really very annoying that I have to restart the machine every 10 minutes, when I am working via SSH. So if any one has a solution, it would be very much appreciated! � It should ….. be possible to kill / stop ACPI some how If absolutely not possible in the actual build , a cron job restarting the timer every 5 minutes perhaps !!??? � It is possible perhaps … that GNOME is initiating this, despite that the GUI powersetting is screenblank “NEVER”. � Whatever is causing the problem, the settings should be such that ^no whatever program^ should not be capable to initiate the sleepmode. � � Louis I need to disable acpi and the indicated method for that is to add ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . However that crashes my system !! Not only that, to make it work again I have to edit loader.conf on a system which does ^not start^. � � After a lot of searching Internet came to the help with, I could start the system again: 1. Select 3. Escape to loader prompt at the splash screen 2. Type set hint.acpi.0.disabled="0" on the loader prompt 3. Then type boot on the loader prompt edit the loader.conf Very very glad with that fix however � However the problem is still there, no idea how to prevent the system from going to sleep (after about 10 minutes). No idea how to change those 10 minutes to a much longer time as well � Note that I have gnome as gui and use the system more or less as server and manage the machine partly local via the GUI and partly remote via SSH. � Related to GNOME I did try ^gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, however that did not solve the problem as well. � In the end there seems to two problems a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and b) a GNOME issue (switching the system off during user inactivity, which is bullshit for a server / for ssh-login / with multiple users). What IMHO apart from the screen lock, this is not a GNOME task but an OS � function to be configured by the system administrator. � A third problem, not to be addressed here, is that recovery from sleep mode does not work on my system as well (even not S1). � Most important for the moment is that the system keeps running / is not going down after x-time ! � Louis
Re: How to disable ACPI? (on FreeBSD14 CURRENT)
On 6 Nov 2022, at 16:47, Alexander Motin wrote: > Hi Louis, > > You should not try to disable ACPI these days. It was a recommendation in > some cases probably ~15 years ago, but for many years now modern systems > depend on ACPI for proper operation. I have no idea what causes crash in > your case, but I would not expect it to end up good any way. > > I know nothing about GNOME, haven't touched it for many years, but it must be > it what makes your laptop to sleep. FreeBSD itself does not implement such > automatic policies. It could the BIOS also if this is a laptop. Mike > On 06.11.2022 09:04, louis.free...@xs4all.nl wrote: >> I need to disable acpi and the indicated method for that is to add >> ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . >> >> However that crashes my system !! >> >> Not only that, to make it work again I have to edit loader.conf on a system >> which does ^not start^. >> >> After a lot of searching Internet came to the help with, I could start the >> system again: >> >> 1. Select 3. Escape to loader prompt at the splash screen >> >> 2. Type set hint.acpi.0.disabled="0" on the loader prompt >> >> 3. Then type boot on the loader prompt >> >> edit the loader.conf >> >> Very very glad with that fix however >> >> However the problem is still there, no idea how to prevent the system from >> going to sleep (after about 10 minutes). >> >> No idea how to change those 10 minutes to a much longer time as well >> >> Note that I have gnome as gui and use the system more or less as server and >> manage the machine partly local via the GUI and partly remote via SSH. >> >> Related to GNOME I did try ^gsettings set >> org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, >> however that did not solve the problem as well. >> >> In the end there seems to two problems >> >> a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and >> >> b) a GNOME issue (switching the system off during user inactivity, which is >> bullshit for a server / for ssh-login / with multiple users). >> >> What IMHO apart from the screen lock, this is not a GNOME task but an OS >> function to be configured by the system administrator. >> >> A third problem, not to be addressed here, is that recovery from sleep mode >> does not work on my system as well (even not S1). >> >> Most important for the moment is that the system keeps running / is not >> going down after x-time ! > > -- > Alexander Motin
Re: How to disable ACPI? (on FreeBSD14 CURRENT)
Hi Louis, You should not try to disable ACPI these days. It was a recommendation in some cases probably ~15 years ago, but for many years now modern systems depend on ACPI for proper operation. I have no idea what causes crash in your case, but I would not expect it to end up good any way. I know nothing about GNOME, haven't touched it for many years, but it must be it what makes your laptop to sleep. FreeBSD itself does not implement such automatic policies. On 06.11.2022 09:04, louis.free...@xs4all.nl wrote: I need to disable acpi and the indicated method for that is to add ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . However that crashes my system !! Not only that, to make it work again I have to edit loader.conf on a system which does ^not start^. After a lot of searching Internet came to the help with, I could start the system again: 1. Select 3. Escape to loader prompt at the splash screen 2. Type set hint.acpi.0.disabled="0" on the loader prompt 3. Then type boot on the loader prompt edit the loader.conf Very very glad with that fix however However the problem is still there, no idea how to prevent the system from going to sleep (after about 10 minutes). No idea how to change those 10 minutes to a much longer time as well Note that I have gnome as gui and use the system more or less as server and manage the machine partly local via the GUI and partly remote via SSH. Related to GNOME I did try ^gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, however that did not solve the problem as well. In the end there seems to two problems a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and b) a GNOME issue (switching the system off during user inactivity, which is bullshit for a server / for ssh-login / with multiple users). What IMHO apart from the screen lock, this is not a GNOME task but an OS function to be configured by the system administrator. A third problem, not to be addressed here, is that recovery from sleep mode does not work on my system as well (even not S1). Most important for the moment is that the system keeps running / is not going down after x-time ! -- Alexander Motin
How to disable ACPI? (on FreeBSD14 CURRENT)
I need to disable acpi and the indicated method for that is to add ^hint.acpi.0.disabled="1"^ in /boot/loader.conf . However that crashes my system !! Not only that, to make it work again I have to edit loader.conf on a system which does ^not start^. � After a lot of searching Internet came to the help with, I could start the system again: 1. Select 3. Escape to loader prompt at the splash screen 2. Type set hint.acpi.0.disabled="0" on the loader prompt 3. Then type boot on the loader prompt edit the loader.conf Very very glad with that fix however � However the problem is still there, no idea how to prevent the system from going to sleep (after about 10 minutes). No idea how to change those 10 minutes to a much longer time as well � Note that I have gnome as gui and use the system more or less as server and manage the machine partly local via the GUI and partly remote via SSH. � Related to GNOME I did try ^gsettings set org.gnome.settings-daemon.plugins.power sleep-inactive-ac-timeout 0^, however that did not solve the problem as well. � In the end there seems to two problems a) A BSD-issue ACPI-turn off in the bootloader is crashing the system ! ! and b) a GNOME issue (switching the system off during user inactivity, which is bullshit for a server / for ssh-login / with multiple users). What IMHO apart from the screen lock, this is not a GNOME task but an OS function to be configured by the system administrator. � A third problem, not to be addressed here, is that recovery from sleep mode does not work on my system as well (even not S1). � Most important for the moment is that the system keeps running / is not going down after x-time ! � Louis
Re: dmesg: ACPI Warning: Firmware issue warning spaming
Am 14.06.22 um 04:00 schrieb Jung-uk Kim: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 FYI, I removed the message. https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 Thank you! This message bothered me a lot on two notebooks, Dell Latitude 6520 and Dell Latitude 5521. Greetings, Rainer Jung-uk Kim
Re: dmesg: ACPI Warning: Firmware issue warning spaming
>>>>>> What do you think opening a review about this fix/tweak to stop this >>>>>> spamming that blinds dmesg? >>>> [snip] >>>> >>>> FYI, both FreeBSD and Linux use ACPICA to implement ACPI. >>>> >>>> https://acpica.org >>>> >>>> This message was added by this commit: >>>> >>>> https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c >>>> You can file your complaints here if it is really bothering you. >>>> >>>> https://github.com/acpica/acpica/issues >>> >>> BTW, it seems it was discussed on Linux ML. >>> >>> https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 >>> I am not sure what happened after that. >> I found the author actually filed a pull request to revert the commit. >> https://github.com/acpica/acpica/pull/780 > > FYI, I removed the message. > > https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 Thank you very much. -- Masachika ISHIZUKA
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 FYI, I removed the message. https://cgit.freebsd.org/src/commit/?id=c7f14adfda21dfacab1895015b4c78bf7c2febb6 Jung-uk Kim
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. I found the author actually filed a pull request to revert the commit. https://github.com/acpica/acpica/pull/780 Jung-uk Kim OpenPGP_signature Description: OpenPGP digital signature
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Jung-uk Kim wrote: On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues BTW, it seems it was discussed on Linux ML. https://lore.kernel.org/lkml/cajz5v0gwyz_bsonhlgt7l4wpqvxlvyobppte1nx6ponsgn4...@mail.gmail.com/T/#mae6a816bbcebb01dea9e5c19c81e9be872cad521 I am not sure what happened after that. Jung-uk Kim OpenPGP_signature Description: OpenPGP digital signature
Re: dmesg: ACPI Warning: Firmware issue warning spaming
On 22. 6. 13., Masachika ISHIZUKA wrote: What do you think opening a review about this fix/tweak to stop this spamming that blinds dmesg? I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. FYI, both FreeBSD and Linux use ACPICA to implement ACPI. https://acpica.org This message was added by this commit: https://github.com/acpica/acpica/commit/2a0d1d475e7ea1c815bee1e0692d81db9a7c909c You can file your complaints here if it is really bothering you. https://github.com/acpica/acpica/issues Jung-uk Kim
Re: dmesg: ACPI Warning: Firmware issue warning spaming
> What do you think opening a review about this fix/tweak to stop this > spamming that blinds dmesg? > >> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg >> warnings: >> > --- >> > ACPI Warning: Firmware issue: Excessive sleep time (0x0010 >> ms > >> > 10 ms) in ACPI Control Method (20220331/exsystem-347) >> > --- >> > Is there a way to silence it? I think this spam message is from linux. So, I think we should discuss on linux forum but I don't familier to linux. -- Masachika ISHIZUKA
Re: dmesg: ACPI Warning: Firmware issue warning spaming
What do you think opening a review about this fix/tweak to stop this
spamming that blinds dmesg?
Masachika ISHIZUKA escreveu no dia domingo,
12/06/2022 à(s) 09:03:
> > I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg
> warnings:
> > ---
> > ACPI Warning: Firmware issue: Excessive sleep time (0x0010
> ms >
> > 10 ms) in ACPI Control Method (20220331/exsystem-347)
> > ---
> > Is there a way to silence it?
>
> Hi.
>
> I think these messages are only informational and make them easier
> to miss more important messages.
> My old machine's ACPI bios is worked at 20msec, so I did patch to
> /usr/src/sys/contrib/dev/acpica/components/executer/exsystem.c like below.
>
> % diff -ruN exsystem.c.orig exsystem.c
> --- exsystem.c.orig 2022-04-03 07:18:33.339997000 +0900
> +++ exsystem.c 2022-04-26 19:13:06.814856000 +0900
> @@ -342,10 +342,10 @@
> * Warn users about excessive sleep times, so ASL code can be
> improved to
> * use polling or similar techniques.
> */
> -if (HowLongMs > 10)
> +if (HowLongMs > 20)
> {
> ACPI_WARNING ((AE_INFO,
> -"Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 10
> ms)"
> +"Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 20
> ms)"
> " in ACPI Control Method",
> ACPI_FORMAT_UINT64 (HowLongMs)));
> }
> --
> Masachika ISHIZUKA
>
>
Re: dmesg: ACPI Warning: Firmware issue warning spaming
> I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings:
> ---
> ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms >
> 10 ms) in ACPI Control Method (20220331/exsystem-347)
> ---
> Is there a way to silence it?
Hi.
I think these messages are only informational and make them easier
to miss more important messages.
My old machine's ACPI bios is worked at 20msec, so I did patch to
/usr/src/sys/contrib/dev/acpica/components/executer/exsystem.c like below.
% diff -ruN exsystem.c.orig exsystem.c
--- exsystem.c.orig 2022-04-03 07:18:33.339997000 +0900
+++ exsystem.c 2022-04-26 19:13:06.814856000 +0900
@@ -342,10 +342,10 @@
* Warn users about excessive sleep times, so ASL code can be improved to
* use polling or similar techniques.
*/
-if (HowLongMs > 10)
+if (HowLongMs > 20)
{
ACPI_WARNING ((AE_INFO,
-"Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 10 ms)"
+"Firmware issue: Excessive sleep time (0x%8.8X%8.8X ms > 20 ms)"
" in ACPI Control Method",
ACPI_FORMAT_UINT64 (HowLongMs)));
}
--
Masachika ISHIZUKA
dmesg: ACPI Warning: Firmware issue warning spaming
Hello, I'm running CURRENT 8d95f500521 and I'm receiving loads of dmesg warnings: --- ACPI Warning: Firmware issue: Excessive sleep time (0x0010 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347) --- Is there a way to silence it? Thanks in advance, Nuno Teixeira
How can I suppress ACPI Warning messages ?
I'm using 14.0-current on old DELL xps12 notebook. Xconsole on it is fillfulled the 'ACPI Warning: Firmware issue: Excessive sleep time (0x0014 ms > 10 ms) in ACPI Control Method (20220331/exsystem-347)' messages and I'm failling to see other important messages. How can I suppress this ACPI warning messages ? -- Masachika ISHIZUKA
Re: main-n254654-d4e8207317c results in "no pools available to import" [zfs/ACPI/NVMe updates in the identified range]
On 2022-Apr-12, at 18:31, Mark Millard wrote: > Most recent good of good->failed update step reported: > (extracted from dev-commits-src-main but shown in increasing-time order) > > Monday, 28 March 2022 > • git: 1b3af110bcd5 - main - uudecode: add missing test files to > Makefile Piotr Pawel Stefaniak > > From there, zfs updates are: > > Tuesday, 29 March 2022 > • git: da5137abdf46 - main - zfs: merge openzfs/zfs_at_bc3f12bfa > (master) into main Martin Matuska > • git: 8d0b6a7d4969 - main - zfs: update zfs_config.h and zfs_gitrev.h > Martin Matuska > . . . > • git: 40c911e8da50 - main - zfs: use zero_region instead of allocating > a dedicated page Mateusz Guzik > > Friday, 8 April 2022 > • git: 0c348b97eb05 - main - zfs: Disable -Wunused-but-set-variable for > a few files in zstd. John Baldwin > • Re: git: 0c348b97eb05 - main - zfs: Disable -Wunused-but-set-variable > for a few files in zstd. John Baldwin [Adjusted the to match time order above.] > Note: bsdinstall was not in use/involved as far as I can tell from the > reporting. > So I've omitted the reference. > > Oldest identified failure observation for a good->failed step: > > Sunday, 10 April 2022 > • git: d4e8207317ca - main - vmm_instruction_emul.c: fix bhyve build > Robert Wing > > > As for da5137abdf46 : > >zfs: merge openzfs/zfs_at_bc3f12bfa (master) into main > >Notable upstream pull request merges: > #12083 libzfs: FreeBSD doesn't resize partitions for you > #13106 add physical device size to SIZE column in 'zpool list -v' > #13158 Allow zfs send to exclude datasets > #13190 module: zfs: zio_inject: zio_match_handler: don't << -1 > #13219 FreeBSD: add missing replay check to an assert in zfs_xvattr_set > #13220 module: freebsd: avoid a taking a destroyed lock in zfs_zevent > bits > #13221 Fix ACL checks for NFS kernel server For ACPI and NVMe there was: Friday, 1 April 2022 • git: ab71bbb75a92 - main - acpica: Import ACPICA 20220331 Jung-uk Kim • git: a70b5660f379 - main - nvme: MPS is a power of two, not a size / 8k Warner Losh • git: 6af6a52ee47b - main - nvme: Save cap_lo and cap_hi Warner Losh • git: 161fcf79941b - main - nvme: Publish the drive's capabilities Warner Losh Saturday, 9 April 2022 • git: 214df80a9cb3 - main - nvme: new define for size of host memory buffer sizes Warner Losh (I have ignored comment typo fixes and RE: messages this time.) === Mark Millard marklmi at yahoo.com === Mark Millard marklmi at yahoo.com
Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On 2021-01-13 16:13, David Wolfskill wrote: > On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote: >> ... >>> I believe that this is evidence in favor of a "race condition" diagnosis. >>> (In precisely what, I don't know,) >> >> I haven't followed source changes too closely as of recent. >> It might be a good idea to check for recent imports of ACPICA updates. >> > > Most recent of those in head was: > > | commit fbde34778ba0ba31fcae99e992f353d989433dba > | Merge: a2fe464c81de 960614968e0d > | Author: Jung-uk Kim > | Date: Fri Nov 13 22:45:26 2020 + > | > | MFV:r367652 > | > | Merge ACPICA 20201113. > | > | Notes: > | svn path=/head/; revision=367654 > > and I certainly had not been seeing the symptom at all until I > mentioned it on 11 January. (And I have been tracking head daily, > including the "poweroff" at the end). Another "wild" idea: some sort of a change related to signal delivery or checking. As I understand, the whole kernel shutdown procedure is executed in a context of a userland process (init? shutdown?). And I guess that that process gets a signal at some point during the shutdown. Now, our implementation of the ACPI mutex is such that it would abort / fail if msleep(PCATCH) in it returns EINTR. I was concerned about that for a long time and I think that it is wrong, but it didn't cause much problems before. Also, I should note that that applies not only to mutexes declared in AML but also to ACPICA's mutexes that protect its internal states (such as ACPI_MTX_Caches / ACPI_MTX_CACHES which appears in your output). So, if that mutex is uncontested then it can be acquired even when a signal is pending and everything is okay. But if the mutex happens to be held by some other thread, then the signal gets checked and the operation is failed because of EINTR. This is the only failure mode that I can think of for that mutex. But again, I have no idea what could have changed recently with respect to signal delivery / signal checking. Or perhaps it's something else, something that creates concurrent ACPI activity that increases likelihood of that mutex being contested. -- Andriy Gapon ___ 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: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On Wed, Jan 13, 2021 at 04:07:35PM +0200, Andriy Gapon wrote: > ... > > I believe that this is evidence in favor of a "race condition" diagnosis. > > (In precisely what, I don't know,) > > I haven't followed source changes too closely as of recent. > It might be a good idea to check for recent imports of ACPICA updates. > Most recent of those in head was: | commit fbde34778ba0ba31fcae99e992f353d989433dba | Merge: a2fe464c81de 960614968e0d | Author: Jung-uk Kim | Date: Fri Nov 13 22:45:26 2020 + | | MFV:r367652 | | Merge ACPICA 20201113. | | Notes: | svn path=/head/; revision=367654 and I certainly had not been seeing the symptom at all until I mentioned it on 11 January. (And I have been tracking head daily, including the "poweroff" at the end). FWIW. Thanks. Peace, david -- David H. Wolfskill da...@catwhisker.org "What happened at the Capitol last Wednesday, then, wasn't the first time Trump's base took him literally. It was the culmination of having taken him literally the entire duration of his presidency." - Chris Cillizza See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On 2021-01-13 16:03, David Wolfskill wrote: > On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote: >> On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote: >>> On 2021-01-11 14:55, David Wolfskill wrote: >>>> pci3: unknown notify 0x2 >>>> ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex >>>> [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434) >>> >>> Looks like that was some sort of a race or otherwise transient condition >>> that lead to the _PTS (prepare-to-sleep) failure. >>> >>>> ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) >>>> (20201113/psparse-689) >>>> acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY >>> >> >> That's certainly plausible -- as I noted a bit earlier today, there was >> no recurrence after this morning's main-c255850-g16079c7233be -> >> main-c255894-g8b1839548750 update. >> >> Should I encounter a recurrence, I will plan to get another screenshot, >> then bring the machine back up and re-try the poweroff (and then report >> my findings). >> > > I had a recurrence this morninig, after the update from: > > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 > main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1300134 1300134 > > to: > > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #121 > main-c255921-gec2700e01532-dirty: Wed Jan 13 05:06:22 PST 2021 > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1300135 1300135 > > > New swcreenshot is in https://www.catwhisker.org/~david/FreeBSD/head/c255921; > the previous one is in https://www.catwhisker.org/~david/FreeBSD/head/c255850. > > They look quite similar to me. > > After grabbing the screenshot, I rebooted again, but the poweroff > just worked normally on re-try. > > I believe that this is evidence in favor of a "race condition" diagnosis. > (In precisely what, I don't know,) I haven't followed source changes too closely as of recent. It might be a good idea to check for recent imports of ACPICA updates. -- Andriy Gapon ___ 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: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On Tue, Jan 12, 2021 at 07:37:28AM -0800, David Wolfskill wrote: > On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote: > > On 2021-01-11 14:55, David Wolfskill wrote: > > > pci3: unknown notify 0x2 > > > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex > > > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434) > > > > Looks like that was some sort of a race or otherwise transient condition > > that lead to the _PTS (prepare-to-sleep) failure. > > > > > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) > > > (20201113/psparse-689) > > > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY > > > > That's certainly plausible -- as I noted a bit earlier today, there was > no recurrence after this morning's main-c255850-g16079c7233be -> > main-c255894-g8b1839548750 update. > > Should I encounter a recurrence, I will plan to get another screenshot, > then bring the machine back up and re-try the poweroff (and then report > my findings). > I had a recurrence this morninig, after the update from: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300134 1300134 to: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #121 main-c255921-gec2700e01532-dirty: Wed Jan 13 05:06:22 PST 2021 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300135 1300135 New swcreenshot is in https://www.catwhisker.org/~david/FreeBSD/head/c255921; the previous one is in https://www.catwhisker.org/~david/FreeBSD/head/c255850. They look quite similar to me. After grabbing the screenshot, I rebooted again, but the poweroff just worked normally on re-try. I believe that this is evidence in favor of a "race condition" diagnosis. (In precisely what, I don't know,) Peace, david -- David H. Wolfskill da...@catwhisker.org "What happened at the Capitol last Wednesday, then, wasn't the first time Trump's base took him literally. It was the culmination of having taken him literally the entire duration of his presidency." - Chris Cillizza See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On Tue, Jan 12, 2021 at 05:31:30PM +0200, Andriy Gapon wrote: > On 2021-01-11 14:55, David Wolfskill wrote: > > pci3: unknown notify 0x2 > > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex > > [ACPI_MTX_Caches] (0c4) (20201113/utmutex-434) > > Looks like that was some sort of a race or otherwise transient condition > that lead to the _PTS (prepare-to-sleep) failure. > > > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) > > (20201113/psparse-689) > > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY > That's certainly plausible -- as I noted a bit earlier today, there was no recurrence after this morning's main-c255850-g16079c7233be -> main-c255894-g8b1839548750 update. Should I encounter a recurrence, I will plan to get another screenshot, then bring the machine back up and re-try the poweroff (and then report my findings). Thanks for looking at it. Peace, david -- David H. Wolfskill da...@catwhisker.org "What happened at the Capitol last Wednesday, then, wasn't the first time Trump's base took him literally. It was the culmination of having taken him literally the entire duration of his presidency." - Chris Cillizza See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Re: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On 2021-01-11 14:55, David Wolfskill wrote: > pci3: unknown notify 0x2 > ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex [ACPI_MTX_Caches] > (0c4) (20201113/utmutex-434) Looks like that was some sort of a race or otherwise transient condition that lead to the _PTS (prepare-to-sleep) failure. > ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY) > (20201113/psparse-689) > acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY -- Andriy Gapon ___ 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: Laptop ACPI poweroff failed after main-c255826 -> main-c255850
On Mon, Jan 11, 2021 at 04:55:13AM -0800, David Wolfskill wrote: > At the conclusion of each morning's "update cycle," I have (for > some time) been in the habit of powering the laptop off, leaving > it powered off for about 15 seconds, then powering it back up. (The > build machine also gets powered off, but doesn't get powered back > up until a bit before midnight.) This is usually the only time the > laptop is powered off (which may reflect ... something :-} ). > > Today's update was from: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #118 > main-c255826-g81b3a0a34145-dirty: Sun Jan 10 04:02:54 PST 2021 > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1300134 1300134 > > to: > FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119 > main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021 > r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1300134 1300134 > After today's update -- from: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119 main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300134 1300134 to: FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #120 main-c255894-g8b1839548750-dirty: Tue Jan 12 05:23:50 PST 2021 r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64 1300134 1300134 poweroff was normal; I did not see a recurrence of the original issue. Peace, david -- David H. Wolfskill da...@catwhisker.org "What happened at the Capitol last Wednesday, then, wasn't the first time Trump's base took him literally. It was the culmination of having taken him literally the entire duration of his presidency." - Chris Cillizza See https://www.catwhisker.org/~david/publickey.gpg for my public key. signature.asc Description: PGP signature
Laptop ACPI poweroff failed after main-c255826 -> main-c255850
At the conclusion of each morning's "update cycle," I have (for
some time) been in the habit of powering the laptop off, leaving
it powered off for about 15 seconds, then powering it back up. (The
build machine also gets powered off, but doesn't get powered back
up until a bit before midnight.) This is usually the only time the
laptop is powered off (which may reflect ... something :-} ).
Today's update was from:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #118
main-c255826-g81b3a0a34145-dirty: Sun Jan 10 04:02:54 PST 2021
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
1300134 1300134
to:
FreeBSD g1-55.catwhisker.org 13.0-CURRENT FreeBSD 13.0-CURRENT #119
main-c255850-g16079c7233be-dirty: Mon Jan 11 04:01:51 PST 2021
r...@g1-55.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY amd64
1300134 1300134
(and yes, while the tree was "dirty," that's because none of my
local changes are committed; the counts & hashes correspond with
what's on git.freebsd.org).
I have place a photo of the screen in
https://www.catwhisker.org/~david/FreeBSD/head/c255850/
Here is a hand-transcription of the final few lines:
acpi_button0: wake_prep disabled wake for \_SB_.PBBTN (S5)
nvidia-modeset: Unloading
pci3: unknown notify 0x2
ACPI Error: AE_ERROR, Thread 12 could not acquire Mutex [ACPI_MTX_Caches]
(0c4) (20201113/utmutex-434)
ACPI Error: Aborting method \_PTS due to previous error (AE_NO_MEMORY)
(20201113/psparse-689)
acpi0: AcpiEnterSleepStatePrep failed - AE_NO_MEMORY
The operating system has halted.
Please press any key to reboot.
[At that point, after getting the photo, I pressed the power burtton
long enough to power the machine off, waited about 15 seconds, then
powered it back up.]
A copy of the (verbose) dmesg.boot (grabbed just before the attempted
power-off) may be found at
https://www.catwhisker.org/~david/FreeBSD/history/laptop.13_dmesg.txt
Normal and gzipped copies of the kernel config file ("CANARY") are at
https://www.catwhisker.org/~david/FreeBSD/head/
As may be seen, the config includes GENERIC, and tweaks it a bit --
but hasn't been changed since 01 December 2020.
While I won't be able to do much testing with the laptop for several
hours (as I use it for work), I'm happy to test when I can.
The build machine seems to have powered off without complaint, FWIW.
What may I do to help figure out what's wrong?
Peace,
david
--
David H. Wolfskill da...@catwhisker.org
"I want him to resign. I want him out. He has caused enough damage."
- Senator Lisa Murkowski (R-AK)
See https://www.catwhisker.org/~david/publickey.gpg for my public key.
signature.asc
Description: PGP signature
RPi4 (8 GiByte) example: non-debug head -r368500 kernel fails to mount root where artifact debug kernel works fine (uefi/ACPI boot)
The boot attempts were via uefi/ACPI using https://github.com/pftf/RPi4
v1.21 materials, directly booting from the USB3 SSD, no microsd card
involved.
Non-debug kernels built for cortex-A72 and for cortex-A53 both got the
behavior that leads mount root failure. (This tends to eliminate some types
of missing synchronization as a potential issue: in the past the cortex-a72
style of build caught a problem that cortex-a53 builds did not show. So my
original thought to cc hps may have been a waste.) Still, the below is
based on my usual cortex-a72 based kernel being used as the non-debug kernel
example.
The artifact debug kernel from:
https://artifact.ci.freebsd.org/snapshot/13.0-CURRENT/r368500/arm64/aarch64/kernel.txz
does not get the problem.
The prior RPi4 context was back at head -r365932 or so and back then
the combination worked. The FreeBSD upgrade is recent.
In the failing contexts (i.e., non-debug contexts), the following
never shows up:
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0: Fixed Direct Access SPC-4 SCSI device
da0: Serial Number REPLACED
da0: 400.000MB/s transfers
da0: 228936MB (468862128 512 byte sectors)
da0: quirks=0x2
and the message:
Root mount waiting for: usbus0
repeats indefinitely, unlike historically for my configuration.
Capturing and diffing boot -v output did not show much interesting
but here is the range with usbusN and the like (+: for artifact debug
kernel, -: for non-debug -mcpu=cortex-a72 kernel):
@@ -197,18 +198,18 @@
vlan: initialized, using hash tables with chaining
IPsec: Initialized Security Association Processing.
tcp_init: net.inet.tcp.tcbhashsize auto tuned to 32768
-AcpiOsExecute: enqueue 1 pending tasks
usbus0: 5.0Gbps Super Speed USB v3.0
usbus1: 480Mbps High Speed USB v2.0
-Release APs...Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
-done
-Root mount waiting for: usbus0CPU 0: ARM Cortex-A72 r0p3 affinity: 0
- usbus1 Cache Type = <64 byte D-cacheline,64 byte
I-cacheline,PIPT ICache,64 byte ERG,64 byte CWG>
- CAM
- Instruction Set Attributes 0 =
- Instruction Set Attributes 1 = <>
- Processor Features 0 =
- Processor Features 1 = <>
+AcpiOsExecute: enqueue 1 pending tasks
+Release APs...done
+CPU 0: ARM Cortex-A72 r0p3 affinity: 0
+Trying to mount root from ufs:/dev/gpt/RPi4Broot []...
+ Cache Type = <64 byte D-cacheline,64 byte I-cacheline,PIPT
ICache,64 byte ERG,64 byte CWG>
+Root mount waiting for: Instruction Set Attributes 0 =
+ usbus0 Instruction Set Attributes 1 = <>
+ usbus1 Processor Features 0 =
+ CAM Processor Features 1 = <>
+
Memory Model Features 0 =
Memory Model Features 1 = <8bit VMID>
Memory Model Features 2 = <32bit CCIDX,48bit VA>
@@ -219,12 +220,13 @@
CPU 1: ARM Cortex-A72 r0p3 affinity: 1
CPU 2: ARM Cortex-A72 r0p3 affinity: 2
CPU 3: ARM Cortex-A72 r0p3 affinity: 3
+WARNING: WITNESS option enabled, expect reduced performance.
regulator: shutting down unused regulators
ugen1.1: at usbus1
ugen0.1: at usbus0
uhub0 on usbus1
-uhub0: on usbus1
uhub1 on usbus0
+uhub0: on usbus1
uhub1: on usbus0
uhub0: 1 port with 1 removable, self powered
uhub1: 5 ports with 4 removable, self powered
@@ -233,15 +235,28 @@
uhub2: on usbus0
Root mount waiting for: usbus0 CAM
uhub2: 4 ports with 4 removable, self powered
-Root mount waiting for: usbus0 CAM
ugen0.3: at usbus0
Root mount waiting for: usbus0 CAM
Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0 CAM
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
-Root mount waiting for: usbus0
+ugen0.4: at usbus0
+umass0 on uhub1
+umass0: on usbus0
+umass0: SCSI over Bulk-Only; quirks = 0x0100
+umass0:0:0: Attached to scbus0
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+Root mount waiting for: CAM
+GEOM: new disk da0
+pass0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+pass0: Fixed Direct Access SPC-4 SCSI device
+pass0: Serial Number REPLACED
+pass0: 400.000MB/s transfers
+da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
+da0: Fixed Direct Access SPC-4 SCSI device
+da0: Serial Number REPLACED
+da0: 400.000MB/s transfers
+da0: 228936MB (468862128 512 byte sectors)
+da0: quirks=0x2
+da0: Delete methods:
(I did not include more of the waiting-for messages for the
non-debug kernel ("-"). I see no reason to have later text
from the debug kernel case ("+").)
I do have a working u-boot 2020.10 based, microsd card first-stages
boot for the same USB3 SSD that mounts the same root file system
just fine. The kernel is a copy of the same non-debug kernel that
the the above used, but the used copy is on the microsd card for
this type of booting. (The u-boot
Re: CFT: major update to if_ure (RPi4B uefi/ACPI booted example's iperf3 output)
I had reason to switch to using the RPi4B, which happens to be booted from ACPI. The only Ethernet connection present for this test is via: Autoloading module: if_ure.ko ure0 on uhub1 ure0: on usbus0 add host 127.0.0.1: gateway lo0 fib 0: route already in table miibus0: on ure0 rgephy0: PHY 0 on miibus0 rgephy0: none, 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT-FDX, 1000baseT-FDX-master, auto ue0: on ure0 ue0: Ethernet address: ### . . . ue0: flags=8843 metric 0 mtu 1500 options=68009b ether ### inet 192.168.1.133 netmask 0xff00 broadcast 192.168.1.255 media: Ethernet autoselect (1000baseT ) status: active nd6 options=29 # iperf3 -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 [ 5] local 192.168.1.133 port 15954 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 83.6 MBytes 702 Mbits/sec 797 17.1 KBytes [ 5] 1.00-2.00 sec 83.5 MBytes 700 Mbits/sec 797 7.13 KBytes [ 5] 2.00-3.00 sec 83.7 MBytes 702 Mbits/sec 783 1.43 KBytes [ 5] 3.00-4.00 sec 83.3 MBytes 699 Mbits/sec 813127 KBytes [ 5] 4.00-5.00 sec 82.8 MBytes 695 Mbits/sec 806 18.5 KBytes [ 5] 5.00-6.00 sec 83.9 MBytes 704 Mbits/sec 822 38.4 KBytes [ 5] 6.00-7.00 sec 83.7 MBytes 702 Mbits/sec 808 64.2 KBytes [ 5] 7.00-8.00 sec 83.1 MBytes 697 Mbits/sec 787 92.2 KBytes [ 5] 8.00-9.00 sec 83.2 MBytes 698 Mbits/sec 788 51.2 KBytes [ 5] 9.00-10.00 sec 83.1 MBytes 697 Mbits/sec 799 47.1 KBytes - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.00 sec 834 MBytes 700 Mbits/sec 8000 sender [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver Server output: Accepted connection from 192.168.1.133, port 18615 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 15954 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 63.7 MBytes 535 Mbits/sec [ 5] 1.00-2.00 sec 83.3 MBytes 699 Mbits/sec [ 5] 2.00-3.00 sec 83.6 MBytes 701 Mbits/sec [ 5] 3.00-4.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 4.00-5.00 sec 83.4 MBytes 699 Mbits/sec [ 5] 5.00-6.00 sec 83.5 MBytes 700 Mbits/sec [ 5] 6.00-7.00 sec 83.2 MBytes 698 Mbits/sec [ 5] 7.00-8.00 sec 83.5 MBytes 701 Mbits/sec [ 5] 8.00-9.00 sec 83.1 MBytes 697 Mbits/sec [ 5] 9.00-10.00 sec 83.4 MBytes 700 Mbits/sec [ 5] 10.00-10.24 sec 19.6 MBytes 693 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate [ 5] 0.00-10.24 sec 834 MBytes 683 Mbits/sec receiver iperf Done. # iperf3 -R -c 192.168.1.120 --get-server-output Connecting to host 192.168.1.120, port 5201 Reverse mode, remote host 192.168.1.120 is sending [ 5] local 192.168.1.133 port 55961 connected to 192.168.1.120 port 5201 [ ID] Interval Transfer Bitrate [ 5] 0.00-1.00 sec 111 MBytes 933 Mbits/sec [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec [ 5] 3.00-4.00 sec 111 MBytes 933 Mbits/sec [ 5] 4.00-5.00 sec 111 MBytes 932 Mbits/sec [ 5] 5.00-6.00 sec 111 MBytes 933 Mbits/sec [ 5] 6.00-7.00 sec 111 MBytes 933 Mbits/sec [ 5] 7.00-8.00 sec 111 MBytes 933 Mbits/sec [ 5] 8.00-9.00 sec 111 MBytes 933 Mbits/sec [ 5] 9.00-10.00 sec 111 MBytes 933 Mbits/sec - - - - - - - - - - - - - - - - - - - - - - - - - [ ID] Interval Transfer Bitrate Retr [ 5] 0.00-10.23 sec 1.09 GBytes 914 Mbits/sec 498 sender [ 5] 0.00-10.00 sec 1.09 GBytes 933 Mbits/sec receiver Server output: --- Server listening on 5201 --- Accepted connection from 192.168.1.133, port 51297 [ 5] local 192.168.1.120 port 5201 connected to 192.168.1.133 port 55961 [ ID] Interval Transfer Bitrate Retr Cwnd [ 5] 0.00-1.00 sec 87.5 MBytes 734 Mbits/sec 72 1.60 MBytes [ 5] 1.00-2.00 sec 111 MBytes 933 Mbits/sec 92 1.60 MBytes [ 5] 2.00-3.00 sec 111 MBytes 933 Mbits/sec 96191 KBytes [ 5] 3.00-4.00 sec
Re: acpi timer reads all ones [Was: efirtc + atrtc at the same time]
On 2020-05-27 23:38, John Baldwin wrote: No. I get that constantly on a desktop that never suspends/resumes. It only started after upgrading to 12.0. If you have time, could you investigate why the USB host controllers Root HUB PCI register flips to -1U ? Which cause these spurious events ... Maybe some kind of PCI power save feature which is not timed correctly ... --HPS ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 5/27/20 2:05 PM, Hans Petter Selasky wrote: > On 2020-05-27 15:41, Justin Hibbits wrote: >> On Wed, 27 May 2020 06:27:16 -0700 >> John Baldwin wrote: >> >>> On 5/27/20 2:39 AM, Andriy Gapon wrote: >>>> On 27/05/2020 11:13, Andriy Gapon wrote: >>>>> I added more diagnostics and it seems to support the idea that the >>>>> problem is related to I/O cycles and bridges. >>>>> >>>>> ACPI timer suddenly starts returning 0x and that lasts for >>>>> tens of microseconds before the timer goes back to returning >>>>> normal values with an expected increase. >>>>> AMD provides a proprietary way to access ACPI registers via MMIO >>>>> (0xfed808xx). That mechanism is unaffected, ACPI timer register >>>>> always returns good values. >>>>> >>>>> The problem seems to happen when restoring configuration of a >>>>> particular PCI bridge. What's interesting is that the bridge >>>>> decodes one memory range and one I/O range. >>>>> >>>>> Looking at pci_cfg_restore() I wonder if it is wise to restore >>>>> PCIR_COMMAND so early. Could it be that after the resume the >>>>> bridge is configured with a wrong I/O range (e.g., too wide) and >>>>> by writing PCIR_COMMAND we enable that decoding. So, the bridge >>>>> steals I/O cycles destined for ACPI support hardware. If there is >>>>> nothing behind the bridge to handle those ports, then we get those >>>>> bad readings. Once the bridge configuration is fully restored, the >>>>> I/O handling goes back to normal. >>>> >>>> From what I see, this looks like a BIOS bug. >>>> Upon resume, it swaps window configurations of pcib1 and pcib2 >>>> (until FreeBSD restores them). pcib1 originally does not have an >>>> I/O window. So, BIOS programs both base and limit of pcib2 I/O >>>> window to zero. When FreeBSD writes its command register to >>>> enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range. >>>> That covers the ACPI ports at 0x8xx. >>>> >>>> Some printf-s. >>>> From (verbose) boot time: >>>> pcib1: domain0 >>>> pcib1: secondary bus 1 >>>> pcib1: subordinate bus 1 >>>> pcib1: memory decode 0xfea0-0xfeaf >>>> pcib2: domain0 >>>> pcib2: secondary bus 2 >>>> pcib2: subordinate bus 2 >>>> pcib2: I/O decode0xf000-0x >>>> pcib2: memory decode 0xfe90-0xfe9f >>>> >>>> My printf-s from resume time: >>>> pcib1: old I/O base (low): 0xf1 >>>> pcib1: old I/O base (high): 0x0 >>>> pcib1: old I/O limit (low): 0x1 >>>> pcib1: old I/O limit (high): 0x0 >>>> pcib2: old I/O base (low): 0x1 >>>> pcib2: old I/O base (high): 0x0 >>>> pcib2: old I/O limit (low): 0x1 >>>> pcib2: old I/O limit (high): 0x0 >>> >>> The "solution" I think is to have resume be multi-pass and to resume >>> all the bridges first before trying to resume leaf devices (including >>> timers), but that's a fair bit of work. It might be that we just >>> need to resume timer interrupts later after the new-bus resume (I >>> think we currently do it before?), though the reason for that was to >>> allow resume methods in devices to sleep (I'm not sure if any do). >>> >> >> That sounds like a good fit for https://reviews.freebsd.org/D203 . >> Someone (TM) just needs to take it over the finish line... 6 years >> later. > > Is this perhaps related to: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 No. I get that constantly on a desktop that never suspends/resumes. It only started after upgrading to 12.0. -- John Baldwin ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 2020-05-27 15:41, Justin Hibbits wrote: On Wed, 27 May 2020 06:27:16 -0700 John Baldwin wrote: On 5/27/20 2:39 AM, Andriy Gapon wrote: On 27/05/2020 11:13, Andriy Gapon wrote: I added more diagnostics and it seems to support the idea that the problem is related to I/O cycles and bridges. ACPI timer suddenly starts returning 0x and that lasts for tens of microseconds before the timer goes back to returning normal values with an expected increase. AMD provides a proprietary way to access ACPI registers via MMIO (0xfed808xx). That mechanism is unaffected, ACPI timer register always returns good values. The problem seems to happen when restoring configuration of a particular PCI bridge. What's interesting is that the bridge decodes one memory range and one I/O range. Looking at pci_cfg_restore() I wonder if it is wise to restore PCIR_COMMAND so early. Could it be that after the resume the bridge is configured with a wrong I/O range (e.g., too wide) and by writing PCIR_COMMAND we enable that decoding. So, the bridge steals I/O cycles destined for ACPI support hardware. If there is nothing behind the bridge to handle those ports, then we get those bad readings. Once the bridge configuration is fully restored, the I/O handling goes back to normal. From what I see, this looks like a BIOS bug. Upon resume, it swaps window configurations of pcib1 and pcib2 (until FreeBSD restores them). pcib1 originally does not have an I/O window. So, BIOS programs both base and limit of pcib2 I/O window to zero. When FreeBSD writes its command register to enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range. That covers the ACPI ports at 0x8xx. Some printf-s. From (verbose) boot time: pcib1: domain0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xfea0-0xfeaf pcib2: domain0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode0xf000-0x pcib2: memory decode 0xfe90-0xfe9f My printf-s from resume time: pcib1: old I/O base (low): 0xf1 pcib1: old I/O base (high): 0x0 pcib1: old I/O limit (low): 0x1 pcib1: old I/O limit (high): 0x0 pcib2: old I/O base (low): 0x1 pcib2: old I/O base (high): 0x0 pcib2: old I/O limit (low): 0x1 pcib2: old I/O limit (high): 0x0 The "solution" I think is to have resume be multi-pass and to resume all the bridges first before trying to resume leaf devices (including timers), but that's a fair bit of work. It might be that we just need to resume timer interrupts later after the new-bus resume (I think we currently do it before?), though the reason for that was to allow resume methods in devices to sleep (I'm not sure if any do). That sounds like a good fit for https://reviews.freebsd.org/D203 . Someone (TM) just needs to take it over the finish line... 6 years later. Is this perhaps related to: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237666 --HPS ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On Wed, 27 May 2020 06:27:16 -0700 John Baldwin wrote: > On 5/27/20 2:39 AM, Andriy Gapon wrote: > > On 27/05/2020 11:13, Andriy Gapon wrote: > >> I added more diagnostics and it seems to support the idea that the > >> problem is related to I/O cycles and bridges. > >> > >> ACPI timer suddenly starts returning 0x and that lasts for > >> tens of microseconds before the timer goes back to returning > >> normal values with an expected increase. > >> AMD provides a proprietary way to access ACPI registers via MMIO > >> (0xfed808xx). That mechanism is unaffected, ACPI timer register > >> always returns good values. > >> > >> The problem seems to happen when restoring configuration of a > >> particular PCI bridge. What's interesting is that the bridge > >> decodes one memory range and one I/O range. > >> > >> Looking at pci_cfg_restore() I wonder if it is wise to restore > >> PCIR_COMMAND so early. Could it be that after the resume the > >> bridge is configured with a wrong I/O range (e.g., too wide) and > >> by writing PCIR_COMMAND we enable that decoding. So, the bridge > >> steals I/O cycles destined for ACPI support hardware. If there is > >> nothing behind the bridge to handle those ports, then we get those > >> bad readings. Once the bridge configuration is fully restored, the > >> I/O handling goes back to normal. > > > > From what I see, this looks like a BIOS bug. > > Upon resume, it swaps window configurations of pcib1 and pcib2 > > (until FreeBSD restores them). pcib1 originally does not have an > > I/O window. So, BIOS programs both base and limit of pcib2 I/O > > window to zero. When FreeBSD writes its command register to > > enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range. > > That covers the ACPI ports at 0x8xx. > > > > Some printf-s. > > From (verbose) boot time: > > pcib1: domain0 > > pcib1: secondary bus 1 > > pcib1: subordinate bus 1 > > pcib1: memory decode 0xfea0-0xfeaf > > pcib2: domain0 > > pcib2: secondary bus 2 > > pcib2: subordinate bus 2 > > pcib2: I/O decode0xf000-0x > > pcib2: memory decode 0xfe90-0xfe9f > > > > My printf-s from resume time: > > pcib1: old I/O base (low): 0xf1 > > pcib1: old I/O base (high): 0x0 > > pcib1: old I/O limit (low): 0x1 > > pcib1: old I/O limit (high): 0x0 > > pcib2: old I/O base (low): 0x1 > > pcib2: old I/O base (high): 0x0 > > pcib2: old I/O limit (low): 0x1 > > pcib2: old I/O limit (high): 0x0 > > The "solution" I think is to have resume be multi-pass and to resume > all the bridges first before trying to resume leaf devices (including > timers), but that's a fair bit of work. It might be that we just > need to resume timer interrupts later after the new-bus resume (I > think we currently do it before?), though the reason for that was to > allow resume methods in devices to sleep (I'm not sure if any do). > That sounds like a good fit for https://reviews.freebsd.org/D203 . Someone (TM) just needs to take it over the finish line... 6 years later. - Justin ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 27/05/2020 16:27, John Baldwin wrote:
> The "solution" I think is to have resume be multi-pass and to resume all the
> bridges
> first before trying to resume leaf devices (including timers), but that's a
> fair bit
> of work. It might be that we just need to resume timer interrupts later
> after the
> new-bus resume (I think we currently do it before?), though the reason for
> that was
> to allow resume methods in devices to sleep (I'm not sure if any do).
But it's not only about timers.
{sbin,bin,micro,etc}uptime() calls can return garbage as well and confuse their
callers.
--
Andriy Gapon
___
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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 5/27/20 2:39 AM, Andriy Gapon wrote: > On 27/05/2020 11:13, Andriy Gapon wrote: >> I added more diagnostics and it seems to support the idea that the problem is >> related to I/O cycles and bridges. >> >> ACPI timer suddenly starts returning 0x and that lasts for tens of >> microseconds before the timer goes back to returning normal values with an >> expected increase. >> AMD provides a proprietary way to access ACPI registers via MMIO >> (0xfed808xx). >> That mechanism is unaffected, ACPI timer register always returns good values. >> >> The problem seems to happen when restoring configuration of a particular PCI >> bridge. What's interesting is that the bridge decodes one memory range and >> one >> I/O range. >> >> Looking at pci_cfg_restore() I wonder if it is wise to restore PCIR_COMMAND >> so >> early. Could it be that after the resume the bridge is configured with a >> wrong >> I/O range (e.g., too wide) and by writing PCIR_COMMAND we enable that >> decoding. >> So, the bridge steals I/O cycles destined for ACPI support hardware. If >> there >> is nothing behind the bridge to handle those ports, then we get those bad >> readings. >> Once the bridge configuration is fully restored, the I/O handling goes back >> to >> normal. > > From what I see, this looks like a BIOS bug. > Upon resume, it swaps window configurations of pcib1 and pcib2 (until FreeBSD > restores them). pcib1 originally does not have an I/O window. So, BIOS > programs both base and limit of pcib2 I/O window to zero. When FreeBSD > writes > its command register to enable I/O decoding it starts claiming 0x0 - 0xFFF I/O > port range. That covers the ACPI ports at 0x8xx. > > Some printf-s. > From (verbose) boot time: > pcib1: domain0 > pcib1: secondary bus 1 > pcib1: subordinate bus 1 > pcib1: memory decode 0xfea0-0xfeaf > pcib2: domain0 > pcib2: secondary bus 2 > pcib2: subordinate bus 2 > pcib2: I/O decode0xf000-0x > pcib2: memory decode 0xfe90-0xfe9f > > My printf-s from resume time: > pcib1: old I/O base (low): 0xf1 > pcib1: old I/O base (high): 0x0 > pcib1: old I/O limit (low): 0x1 > pcib1: old I/O limit (high): 0x0 > pcib2: old I/O base (low): 0x1 > pcib2: old I/O base (high): 0x0 > pcib2: old I/O limit (low): 0x1 > pcib2: old I/O limit (high): 0x0 The "solution" I think is to have resume be multi-pass and to resume all the bridges first before trying to resume leaf devices (including timers), but that's a fair bit of work. It might be that we just need to resume timer interrupts later after the new-bus resume (I think we currently do it before?), though the reason for that was to allow resume methods in devices to sleep (I'm not sure if any do). -- John Baldwin ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 27/05/2020 11:13, Andriy Gapon wrote: > I added more diagnostics and it seems to support the idea that the problem is > related to I/O cycles and bridges. > > ACPI timer suddenly starts returning 0x and that lasts for tens of > microseconds before the timer goes back to returning normal values with an > expected increase. > AMD provides a proprietary way to access ACPI registers via MMIO (0xfed808xx). > That mechanism is unaffected, ACPI timer register always returns good values. > > The problem seems to happen when restoring configuration of a particular PCI > bridge. What's interesting is that the bridge decodes one memory range and > one > I/O range. > > Looking at pci_cfg_restore() I wonder if it is wise to restore PCIR_COMMAND so > early. Could it be that after the resume the bridge is configured with a > wrong > I/O range (e.g., too wide) and by writing PCIR_COMMAND we enable that > decoding. > So, the bridge steals I/O cycles destined for ACPI support hardware. If > there > is nothing behind the bridge to handle those ports, then we get those bad > readings. > Once the bridge configuration is fully restored, the I/O handling goes back to > normal. >From what I see, this looks like a BIOS bug. Upon resume, it swaps window configurations of pcib1 and pcib2 (until FreeBSD restores them). pcib1 originally does not have an I/O window. So, BIOS programs both base and limit of pcib2 I/O window to zero. When FreeBSD writes its command register to enable I/O decoding it starts claiming 0x0 - 0xFFF I/O port range. That covers the ACPI ports at 0x8xx. Some printf-s. >From (verbose) boot time: pcib1: domain0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: memory decode 0xfea0-0xfeaf pcib2: domain0 pcib2: secondary bus 2 pcib2: subordinate bus 2 pcib2: I/O decode0xf000-0x pcib2: memory decode 0xfe90-0xfe9f My printf-s from resume time: pcib1: old I/O base (low): 0xf1 pcib1: old I/O base (high): 0x0 pcib1: old I/O limit (low): 0x1 pcib1: old I/O limit (high): 0x0 pcib2: old I/O base (low): 0x1 pcib2: old I/O base (high): 0x0 pcib2: old I/O limit (low): 0x1 pcib2: old I/O limit (high): 0x0 -- Andriy Gapon ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 27/05/2020 01:14, John Baldwin wrote: > On 5/26/20 11:55 AM, Konstantin Belousov wrote: >> On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote: >>> I am not sure if this is just a coincidence but it appears as if a write to >>> some >>> PCI configuration register could temporarily interfere with access to the PM >>> timer I/O port. >>> Is that plausible? >> If something disabled a BAR, then typical response of x86 chipset for timed >> out read from PCIe is 0xf... . > > And the ACPI timer might be "behind" the isab0 bridge device which would > indeed > cause this. I added more diagnostics and it seems to support the idea that the problem is related to I/O cycles and bridges. ACPI timer suddenly starts returning 0x and that lasts for tens of microseconds before the timer goes back to returning normal values with an expected increase. AMD provides a proprietary way to access ACPI registers via MMIO (0xfed808xx). That mechanism is unaffected, ACPI timer register always returns good values. The problem seems to happen when restoring configuration of a particular PCI bridge. What's interesting is that the bridge decodes one memory range and one I/O range. Looking at pci_cfg_restore() I wonder if it is wise to restore PCIR_COMMAND so early. Could it be that after the resume the bridge is configured with a wrong I/O range (e.g., too wide) and by writing PCIR_COMMAND we enable that decoding. So, the bridge steals I/O cycles destined for ACPI support hardware. If there is nothing behind the bridge to handle those ports, then we get those bad readings. Once the bridge configuration is fully restored, the I/O handling goes back to normal. Is this possible? P.S. pci_cfg_restore() also attempts to restore PCIR_INTPIN, but it's read-only? -- Andriy Gapon ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On 5/26/20 11:55 AM, Konstantin Belousov wrote: > On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote: >> On 25/05/2020 11:37, Andriy Gapon wrote: >>> Also, there is another issue related to atrtc. >>> When I have both drivers attached, and also when I have only atrtc attached >>> (efi.rt.disabled=1), system clock jumps 10 minutes forward after each >>> suspend / >>> resume cycle (S0 -> S3 -> S0). That does not happen for reboot and shutdown >>> cycles. I haven't investigated this deeper, but it is a curious problem. >> >> Actually, I was wrong. The problem can also occur with efirtc alone. >> Also, sometimes there is a different problem where there are no callouts for >> a >> period of time on the order of minutes. I tracked it to cc_lastscan being >> set >> to a value greater than the current uptime. So, any scheduled callout gets >> scheduled at cc_lastscan and it is a while before the uptime catches up. >> >> It seemed that both issues were connected and were a result of the uptime >> jumping forward by some minutes and then jumping back to a sane value. >> If something important happened during the weird period, like getting time of >> day from hardware or invoking a callout, it lead to the observed effects. >> >> So, that gave me some ideas where to add debugging checks. >> What I determined is that ACPI timer (ACPI-fast) could produce a reading of >> all >> 1-s like happens when there is no hardware response. >> >> I caught one such instance and got a stack trace for it (but no crash dump >> because devices had not resumed yet): >> tc_windup() at tc_windup+0x318/frame 0xfe00a7a19300 >> tc_ticktock() at tc_ticktock+0x4b/frame 0xfe00a7a19320 >> hardclock() at hardclock+0x107/frame 0xfe00a7a19360 >> handleevents() at handleevents+0xb3/frame 0xfe00a7a193a0 >> timercb() at timercb+0x196/frame 0xfe00a7a193f0 >> lapic_handle_timer() at lapic_handle_timer+0x98/frame 0xfe00a7a19420 >> Xtimerint() at Xtimerint+0xb1/frame 0xfe00a7a19420 >> --- interrupt, rip = 0x80b34500, rsp = 0xfe00a7a194f8, rbp = >> 0xfe00a7a19540 --- >> acpi_pcib_write_config() at acpi_pcib_write_config/frame 0xfe00a7a19540 >> pci_cfg_restore() at pci_cfg_restore+0x2cc/frame 0xfe00a7a195a0 >> pci_resume_child() at pci_resume_child+0xee/frame 0xfe00a7a195e0 >> pci_resume() at pci_resume+0x49/frame 0xfe00a7a19630 >> bus_generic_resume_child() at bus_generic_resume_child+0x43/frame >> 0xfe00a7a19650 >> bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19680 >> bus_generic_resume_child() at bus_generic_resume_child+0x43/frame >> 0xfe00a7a196a0 >> bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a196d0 >> bus_generic_resume_child() at bus_generic_resume_child+0x43/frame >> 0xfe00a7a196f0 >> bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19720 >> bus_generic_resume_child() at bus_generic_resume_child+0x43/frame >> 0xfe00a7a19740 >> root_resume() at root_resume+0x29/frame 0xfe00a7a19770 >> acpi_EnterSleepState() at acpi_EnterSleepState+0x73b/frame 0xfe00a7a197f0 >> acpi_AckSleepState() at acpi_AckSleepState+0x144/frame 0xfe00a7a19820 >> devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe00a7a19870 >> vn_ioctl() at vn_ioctl+0x132/frame 0xfe00a7a19980 >> devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe00a7a199a0 >> kern_ioctl() at kern_ioctl+0x27b/frame 0xfe00a7a19a00 >> sys_ioctl() at sys_ioctl+0x123/frame 0xfe00a7a19ad0 >> amd64_syscall() at amd64_syscall+0x140/frame 0xfe00a7a19bf0 >> fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a7a19bf0 >> >> I am not sure if this is just a coincidence but it appears as if a write to >> some >> PCI configuration register could temporarily interfere with access to the PM >> timer I/O port. >> Is that plausible? > If something disabled a BAR, then typical response of x86 chipset for timed > out read from PCIe is 0xf... . And the ACPI timer might be "behind" the isab0 bridge device which would indeed cause this. -- John Baldwin ___ 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 timer reads all ones [Was: efirtc + atrtc at the same time]
On Tue, May 26, 2020 at 06:22:13PM +0300, Andriy Gapon wrote: > On 25/05/2020 11:37, Andriy Gapon wrote: > > Also, there is another issue related to atrtc. > > When I have both drivers attached, and also when I have only atrtc attached > > (efi.rt.disabled=1), system clock jumps 10 minutes forward after each > > suspend / > > resume cycle (S0 -> S3 -> S0). That does not happen for reboot and shutdown > > cycles. I haven't investigated this deeper, but it is a curious problem. > > Actually, I was wrong. The problem can also occur with efirtc alone. > Also, sometimes there is a different problem where there are no callouts for a > period of time on the order of minutes. I tracked it to cc_lastscan being set > to a value greater than the current uptime. So, any scheduled callout gets > scheduled at cc_lastscan and it is a while before the uptime catches up. > > It seemed that both issues were connected and were a result of the uptime > jumping forward by some minutes and then jumping back to a sane value. > If something important happened during the weird period, like getting time of > day from hardware or invoking a callout, it lead to the observed effects. > > So, that gave me some ideas where to add debugging checks. > What I determined is that ACPI timer (ACPI-fast) could produce a reading of > all > 1-s like happens when there is no hardware response. > > I caught one such instance and got a stack trace for it (but no crash dump > because devices had not resumed yet): > tc_windup() at tc_windup+0x318/frame 0xfe00a7a19300 > tc_ticktock() at tc_ticktock+0x4b/frame 0xfe00a7a19320 > hardclock() at hardclock+0x107/frame 0xfe00a7a19360 > handleevents() at handleevents+0xb3/frame 0xfe00a7a193a0 > timercb() at timercb+0x196/frame 0xfe00a7a193f0 > lapic_handle_timer() at lapic_handle_timer+0x98/frame 0xfe00a7a19420 > Xtimerint() at Xtimerint+0xb1/frame 0xfe00a7a19420 > --- interrupt, rip = 0x80b34500, rsp = 0xfe00a7a194f8, rbp = > 0xfe00a7a19540 --- > acpi_pcib_write_config() at acpi_pcib_write_config/frame 0xfe00a7a19540 > pci_cfg_restore() at pci_cfg_restore+0x2cc/frame 0xfe00a7a195a0 > pci_resume_child() at pci_resume_child+0xee/frame 0xfe00a7a195e0 > pci_resume() at pci_resume+0x49/frame 0xfe00a7a19630 > bus_generic_resume_child() at bus_generic_resume_child+0x43/frame > 0xfe00a7a19650 > bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19680 > bus_generic_resume_child() at bus_generic_resume_child+0x43/frame > 0xfe00a7a196a0 > bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a196d0 > bus_generic_resume_child() at bus_generic_resume_child+0x43/frame > 0xfe00a7a196f0 > bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19720 > bus_generic_resume_child() at bus_generic_resume_child+0x43/frame > 0xfe00a7a19740 > root_resume() at root_resume+0x29/frame 0xfe00a7a19770 > acpi_EnterSleepState() at acpi_EnterSleepState+0x73b/frame 0xfe00a7a197f0 > acpi_AckSleepState() at acpi_AckSleepState+0x144/frame 0xfe00a7a19820 > devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe00a7a19870 > vn_ioctl() at vn_ioctl+0x132/frame 0xfe00a7a19980 > devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe00a7a199a0 > kern_ioctl() at kern_ioctl+0x27b/frame 0xfe00a7a19a00 > sys_ioctl() at sys_ioctl+0x123/frame 0xfe00a7a19ad0 > amd64_syscall() at amd64_syscall+0x140/frame 0xfe00a7a19bf0 > fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a7a19bf0 > > I am not sure if this is just a coincidence but it appears as if a write to > some > PCI configuration register could temporarily interfere with access to the PM > timer I/O port. > Is that plausible? If something disabled a BAR, then typical response of x86 chipset for timed out read from PCIe is 0xf... . ___ 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"
acpi timer reads all ones [Was: efirtc + atrtc at the same time]
On 25/05/2020 11:37, Andriy Gapon wrote: > Also, there is another issue related to atrtc. > When I have both drivers attached, and also when I have only atrtc attached > (efi.rt.disabled=1), system clock jumps 10 minutes forward after each suspend > / > resume cycle (S0 -> S3 -> S0). That does not happen for reboot and shutdown > cycles. I haven't investigated this deeper, but it is a curious problem. Actually, I was wrong. The problem can also occur with efirtc alone. Also, sometimes there is a different problem where there are no callouts for a period of time on the order of minutes. I tracked it to cc_lastscan being set to a value greater than the current uptime. So, any scheduled callout gets scheduled at cc_lastscan and it is a while before the uptime catches up. It seemed that both issues were connected and were a result of the uptime jumping forward by some minutes and then jumping back to a sane value. If something important happened during the weird period, like getting time of day from hardware or invoking a callout, it lead to the observed effects. So, that gave me some ideas where to add debugging checks. What I determined is that ACPI timer (ACPI-fast) could produce a reading of all 1-s like happens when there is no hardware response. I caught one such instance and got a stack trace for it (but no crash dump because devices had not resumed yet): tc_windup() at tc_windup+0x318/frame 0xfe00a7a19300 tc_ticktock() at tc_ticktock+0x4b/frame 0xfe00a7a19320 hardclock() at hardclock+0x107/frame 0xfe00a7a19360 handleevents() at handleevents+0xb3/frame 0xfe00a7a193a0 timercb() at timercb+0x196/frame 0xfe00a7a193f0 lapic_handle_timer() at lapic_handle_timer+0x98/frame 0xfe00a7a19420 Xtimerint() at Xtimerint+0xb1/frame 0xfe00a7a19420 --- interrupt, rip = 0x80b34500, rsp = 0xfe00a7a194f8, rbp = 0xfe00a7a19540 --- acpi_pcib_write_config() at acpi_pcib_write_config/frame 0xfe00a7a19540 pci_cfg_restore() at pci_cfg_restore+0x2cc/frame 0xfe00a7a195a0 pci_resume_child() at pci_resume_child+0xee/frame 0xfe00a7a195e0 pci_resume() at pci_resume+0x49/frame 0xfe00a7a19630 bus_generic_resume_child() at bus_generic_resume_child+0x43/frame 0xfe00a7a19650 bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19680 bus_generic_resume_child() at bus_generic_resume_child+0x43/frame 0xfe00a7a196a0 bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a196d0 bus_generic_resume_child() at bus_generic_resume_child+0x43/frame 0xfe00a7a196f0 bus_generic_resume() at bus_generic_resume+0x29/frame 0xfe00a7a19720 bus_generic_resume_child() at bus_generic_resume_child+0x43/frame 0xfe00a7a19740 root_resume() at root_resume+0x29/frame 0xfe00a7a19770 acpi_EnterSleepState() at acpi_EnterSleepState+0x73b/frame 0xfe00a7a197f0 acpi_AckSleepState() at acpi_AckSleepState+0x144/frame 0xfe00a7a19820 devfs_ioctl() at devfs_ioctl+0xcb/frame 0xfe00a7a19870 vn_ioctl() at vn_ioctl+0x132/frame 0xfe00a7a19980 devfs_ioctl_f() at devfs_ioctl_f+0x1e/frame 0xfe00a7a199a0 kern_ioctl() at kern_ioctl+0x27b/frame 0xfe00a7a19a00 sys_ioctl() at sys_ioctl+0x123/frame 0xfe00a7a19ad0 amd64_syscall() at amd64_syscall+0x140/frame 0xfe00a7a19bf0 fast_syscall_common() at fast_syscall_common+0x101/frame 0xfe00a7a19bf0 I am not sure if this is just a coincidence but it appears as if a write to some PCI configuration register could temporarily interfere with access to the PM timer I/O port. Is that plausible? I'll try to dig up more data. -- Andriy Gapon ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
On Sat, 20 Jul 2019 00:54:47 +0200
Evilham wrote:
> Minor glitches:
> - xbacklight doesn't work, neither does intel-backlight because
> it's AMD
> - Speakers don't appear to work, audio input/output on 3.5 jack
> does.
> - SD card reader doesn't work (Bounty for 125 USD:
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521)
I have Asus 505 and backlight not work too (try via xfce4-power-manager).
I dig into it and found that problem somewhere in ACPI code.
1. It does not proper export some functions and FreeBSD
ACPI + xfce4-power-manager cant detect support this feature.
I hack kernel:
Index: /usr/src/sys/dev/acpica/acpi_video.c
===
--- /usr/src/sys/dev/acpica/acpi_video.c(revision 350398)
+++ /usr/src/sys/dev/acpica/acpi_video.c(working copy)
@@ -1053,8 +1053,12 @@
dcs = 0;
status = acpi_GetInteger(handle, "_DCS", );
if (ACPI_FAILURE(status))
- printf("can't evaluate %s._DCS - %s\n",
- acpi_name(handle), AcpiFormatException(status));
+ status = acpi_GetInteger(handle, "_STA", );
+ if (ACPI_FAILURE(status)) {
+ /* Assume that device OK by default. */
+ dcs = (DCS_EXISTS | DCS_ACTIVE | DCS_READY |
+ DCS_FUNCTIONAL | DCS_ATTACHED);
+ }
return (dcs);
}
and now acpi/xfce4-power-manager show that feature supported but
it does not work.
(later I can move this hack into ACPI ASL code that load into bios, but it
harder to maintain)
2. I dig more depper and decompile acpi code via isl.
There is a mess.
I found that function that set backlight level check some mem/register
value before write new backlight value.
I fail to found place where this value changed.
I try rewrite code to remove this check and recompile ACPI and load new
version witout this check on FreeBSD boot, it loaded but backlight still
not work.
Also I set in loader.conf:
hw.acpi.osname="Windows 2015" # Some systems' ASL may have problems because
they look for names of Microsoft operating systems.
because there is at least 4 different places in decompiled ACPI
where OS version and name checked - not help with blackligth, but as I see
this unblock some features/devices.
Also i2c touchpad dont work.
https://reviews.freebsd.org/D16698
not help.
For speakers probably wrong snddev set.
Try change hw.snd.default_unit.
> 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
I have another issue with amdgpu:
after lid closed and open again video freezes to few seconds every 10 seconds.
Switch to scfb xorg driver to fix it, but get small tearing on video playback.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
On dg., jul. 21 2019, Cristian Pogolsha wrote: Hi, Thank you for the instructions. I have a question related to post-installation. My system doesn't boot after installing and rebooting the system. It just doesn't find the partition on the drive. I get a blank screen when selecting from the boot media list. What partitioning scheme did you use for your installation? Or is this problem addressable with step #2 in your instructions? Putting in the boot/loader.conf -> set.hw.pci.mcfg=0? The **hw.pci.mcfg=0** line in /boot/loader.conf is so that your booting won't hang the same way it did on installation without manual parameters, shouldn't be related to your current issue. Remember to add the comment linking to the bug as well, so that you can remove it when those changes land in -CURRENT Also add yourself to the CC field in the bug, that way you can help test those changes. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760q Your current issue sounds like a problem with the way you installed / set up the system and is probably better for freebsd-questions: https://lists.freebsd.org/mailman/listinfo/freebsd-questions FWIW: I boot using EFI from ZFS in a geli-encrypted partition in a GPT disk, I recall some manual fiddling but those were likely because I needed sth particular. -- Evilham ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
On ds., jul. 20 2019, Evilham wrote: Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long And this is why I wanted to do more debugging before raising an issue :-). It kept happening without drm-kmod but the backtrace was different, which allowed me to reduce it to a piece of alpha Software I use pretty much all the time: WireGuard. See: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=239351 So, update: there is no *serious* issue when using the ThinkPad A485, it works mostly fine with minor annoyances (including the fact that installation media won't work out of the box). -- Evilham ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hi, Thank you for the instructions. I have a question related to post-installation. My system doesn't boot after installing and rebooting the system. It just doesn't find the partition on the drive. I get a blank screen when selecting from the boot media list. What partitioning scheme did you use for your installation? Or is this problem addressable with step #2 in your instructions? Putting in the boot/loader.conf -> set.hw.pci.mcfg=0? Thank you very much, Cristian ___ 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
Having same issue with an i915 inside a hp envy On July 19, 2019 3:15:11 PM PDT, Cristian Pogolsha wrote: >Hi, > >I tried recently to boot FreeBSD current r350103 on a Thinkpad A485. >It's >the AMD Ryzen equivalent of the T480. During the boot I encountered >this >ACPI related error >https://drive.google.com/file/d/1dzgSonn6Cuc1YrDeAUYSqHZlcmzaDY2Y/view >Sorry that I'm posting images instead of plain text. I have no idea how >to >do kernel dumps during the bootload of a live image. I would be happy >to >post more information if required, let me know how I can do it. > >Thank you, >Cristian >___ >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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hey, thanks for the feedback and your work, didn't think this would be interesting for anyone but the laptop owners. On ds., jul. 20 2019, Greg V. wrote: On July 20, 2019 1:54:47 AM GMT+03:00, Evilham wrote: it even suspends and resumes back to X Wow, that's great news! Desktop Ryzen+Vega doesn't (not that I need suspend very much on desktop haha) Indeed, I was pleasantly surprised too - xbacklight doesn't work, neither does intel-backlight because it's AMD Since it's a Thinkpad, do the brightness keys work anyway? Does acpi_ibm work? Forgot to mention brightness keys, they also don't work. I just tried acpi_ibm and it also didn't help. Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. If you're on the packaged drm-kmod v4.16, it's amazing that Raven GPU works at all. You should try drm-v5.0 from git. kld_list="amdgpu" Huh, interesting, I'm trying to compile drm-v5.0 right now. This comment and Pete's made me re-visit the graphics settings, specifics below. It even works when loaded this early? Interesting. Do you also not have the EFI framebuffer conflict? i.e. without disabling vt.syscons, everything just works reliably? Yes, with my previous laptop that was necessary, but this one has no need for those settings, it works just fine without and font size is according to the screen (i.e. it's not huge). On ds., jul. 20 2019, Pete Wright wrote: On 7/19/19 3:54 PM, Evilham wrote: Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long interesting. can you post this kernel panic, and any backtraces you are able to get here: https://github.com/FreeBSDDesktop/kms-drm/issues also, are you using the xf86-video-amdgpu driver, or the stock modesetting driver to X? That was my plan for when I manage to fully isolate that it is on drm-kmod, thank you for confirming the path! I noticed I did have xf86-video-amdgpu installed, but just removed it and all traces of drm-kmod as well as the kld_list="amdgpu" bit and X actually works without it and without the xf86-video packages. HDMI output won't work though, I guess that makes sense. We'll see if working like this the system doesn't crash at all, if it does it may be related to #231760 and not to drm-kmod. If it does not crash without drm-kmod, I'll try my build of drm-kmod v5.0 before opening an issue, that'd be more information :-). I did have the question as to why the packaged version is 4.16 but didn't quite find an answer to that on the wikis / documentation. Thank you again, -- Evilham ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
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"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hi Jordy, Thank you for your fast reply. Your links were very helpful. As per the bugzilla report https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760, during the kernel load screen I dropped to shell prompt and changed the boot params with command 'set hw.pci.mcfg="0" I was successful booting and installing FreeBSD from there. Hope it works for you too! Kind regards, Cristian On Sat, Jul 20, 2019 at 12:35 AM Jordy van Wolferen wrote: > Hi, > > I have the Thinkpad E485 and I'm also unable to boot FreeBSD on it. > It has some UEFI firmware issues, for linux it needs some kernel arguments > to get it to boot: > "ivrs_ioapic[32]=00:14.0 ivrs_ioapic[33]=00:00.0 iommu=pt" > > https://forums.lenovo.com/t5/Other-Linux-Discussions/ThinkPad-E485-E585-Firmware-bug-ACPI-IVRS-table/td-p/4191484 > . > On linux I have to add the following kernel arguments: > "ivrs_ioapic[32]=00:14.0 ivrs_ioapic[33]=00:00.0 iommu=pt", I would like to > know what the equivalent for FreeBSD arguments are. > > There is also an open bug for Ryzen mobile on FreeBSD: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760 > > Hope this helps a bit. > > Best regards, > Jordy > > On Sat, Jul 20, 2019 at 12:15 AM Cristian Pogolsha > wrote: > >> Hi, >> >> I tried recently to boot FreeBSD current r350103 on a Thinkpad A485. It's >> the AMD Ryzen equivalent of the T480. During the boot I encountered this >> ACPI related error >> https://drive.google.com/file/d/1dzgSonn6Cuc1YrDeAUYSqHZlcmzaDY2Y/view >> Sorry that I'm posting images instead of plain text. I have no idea how to >> do kernel dumps during the bootload of a live image. I would be happy to >> post more information if required, let me know how I can do it. >> >> Thank you, >> Cristian >> ___ >> 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: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
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? thanks! -pete -- Pete Wright p...@nomadlogic.org 310.309.9298 ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hey, On ds., jul. 20 2019, Cristian Pogolsha wrote: I tried recently to boot FreeBSD current r350103 on a Thinkpad A485. It's the AMD Ryzen equivalent of the T480. During the boot I encountered this ACPI related error https://drive.google.com/file/d/1dzgSonn6Cuc1YrDeAUYSqHZlcmzaDY2Y/view I have the same laptop and recently spent a fair amount of time getting it to work, I've been wanting to document this in a more proper fashion (e.g. FreeBSD's wiki) but haven't gotten the time, maybe since this will save you time, you would be able to put this and your own findings together and do that? If not, at the very least people searching on the web will have now a better chance to find this email. Note: I run on a daily basis, 12-RELEASE but I tested 13-CURRENT about a month ago and everything applied verbatim. First things: in order to get the Thinkpad A485 to boot, wait until you see the logo and press 3 for boot options, once there type: set hw.pci.mcfg=0 boot It should work alright now, after installing the system, triple check that /boot/loader.conf contains this: # Ryzen hack: FreeBSD bug #231760 # https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=231760 hw.pci.mcfg=0 # Wireless Intel AC8265 # Not strictly necessary, but the Realtek that is shipped is not supported # You can easily (and carefully) change them. if_iwm_load="YES" iwm8265fw_load="YES" Now, if you want X, you should install drm-kmod and add following to your /etc/rc.conf: # Graphics kld_list="amdgpu" Those are the tricky bits to get the system to work IIRC (also: your ethernet is re1, not re0). After this, the system should work fine (it even suspends and resumes back to X!), with minor glitches and a serious issue. Take into account that I didn't research these too much because they are minor annoyances for me. Minor glitches: - xbacklight doesn't work, neither does intel-backlight because it's AMD - Speakers don't appear to work, audio input/output on 3.5 jack does. - SD card reader doesn't work (Bounty for 125 USD: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521) Serious issue: I was just debugging this right now, more infos with a proper bug report will come, but I think the system encounters a deadlock sometimes with the drm-kmod / amdgpu which results in a kernel panic. It is a serious issue, but it allows me to use the computer for work, it doesn't happen every couple hours, but it does happen a couple times a day. FWIW, this is part of the crashlog: WARNING !drm_modeset_is_locked(>mutex) failed at /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821 [Multiple times...] kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled kernel trap 22 with interrupts disabled panic: spin lock held too long Sorry that I'm posting images instead of plain text. I have no idea how to do kernel dumps during the bootload of a live image. I would be happy to post more information if required, let me know how I can do it. No worries, it took me forever to find the bug that had the sysctl. I hope this helps you out, -- Evilham ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
acpi issues on FreeBSD-current_r350103 on Thinkpad A485
Hi, I tried recently to boot FreeBSD current r350103 on a Thinkpad A485. It's the AMD Ryzen equivalent of the T480. During the boot I encountered this ACPI related error https://drive.google.com/file/d/1dzgSonn6Cuc1YrDeAUYSqHZlcmzaDY2Y/view Sorry that I'm posting images instead of plain text. I have no idea how to do kernel dumps during the bootload of a live image. I would be happy to post more information if required, let me know how I can do it. Thank you, Cristian ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #24 from Kubilay Kocak --- (In reply to Slava from comment #22) Alternatively, one can apply the commit that was merged to stable/12 in base r342278, and rebuild/reinstall the kernel -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #23 from Kubilay Kocak --- (In reply to Slava from comment #22) The fix has been committed and merged to the stable/12 branch, and will be part of the next (12.1) FreeBSD release cut from that branch. If you would not like to wait for that release, you may update to the stable/12 branch. For more information on tracking development branches, see: https://www.freebsd.org/doc/handbook/current-stable.html -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Slava changed: What|Removed |Added CC||sl...@planetslav.ca --- Comment #22 from Slava --- Hello, I'm having the same issue on Lenovo X1 Carbon gen1, Coreboot 4.7 TianoCore on Freebsd 12.0-RELEASE-p3. It was working since Freebsd 11.1 when I just set this up over a year ago and in 11.2. Stopped working after update to 12. [moose@beast /usr/home/moose]$ acpiconf -i 0 acpiconf: get battery info (0) failed: Device not configured [moose@beast /usr/home/moose]$ dmesg | grep -i acpi | grep -i bat ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT0._STA, AE_NOT_EXIST (20181003/psparse-677) ACPI Error: Method parse/execution failed \134_SB.PCI0.LPCB.EC.BAT1._STA, AE_NOT_EXIST (20181003/psparse-677) [moose@beast /usr/home/moose]$ uname -a FreeBSD beast 12.0-RELEASE-p3 FreeBSD 12.0-RELEASE-p3 GENERIC amd64 Please let me know if you need any additional information and/or if I need to apply any patches manually. Thank you -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Kubilay Kocak changed: What|Removed |Added Flags|mfc-stable12? |mfc-stable12+ Keywords|needs-qa| -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Resolution|--- |FIXED Status|In Progress |Closed -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
--- Comment #21 from commit-h...@freebsd.org ---
A commit references this bug:
Author: avg
Date: Thu Dec 20 08:45:41 UTC 2018
New revision: 342278
URL: https://svnweb.freebsd.org/changeset/base/342278
Log:
MFC r341632: acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.
PR: 227191
Changes:
_U stable/12/
stable/12/sys/dev/acpica/acpi.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 Andriy Gapon changed: What|Removed |Added Assignee|a...@freebsd.org|a...@freebsd.org Status|Open|In Progress -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
--- Comment #20 from commit-h...@freebsd.org ---
A commit references this bug:
Author: avg
Date: Thu Dec 6 12:34:34 UTC 2018
New revision: 341632
URL: https://svnweb.freebsd.org/changeset/base/341632
Log:
acpi_{Device,Battery}IsPresent: restore pre-r330957 behaviour
Specifically, assume that the device is present if evaluation of _STA
method fails.
Before r330957 we ignored any _STA evaluation failure (which was
performed by AcpiGetObjectInfo in ACPICA contrib code) for the purpose
of acpi_DeviceIsPresent and acpi_BatteryIsPresent. ACPICA 20180313
removed evaluation of _STA from AcpiGetObjectInfo. So, we added
evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent.
One important difference is that the new code ignored a failure only if
_STA did not exist (AE_NOT_FOUND). Any other kind of failure was
treated as a fatal failure. Apparently, on some systems we can get
AE_NOT_EXIST when evaluating _STA. And that error is not an evil twin
of AE_NOT_FOUND, despite a very similar name, but a distinct error
related to a missing handler for an ACPI operation region.
It's possible that for some people the problem was already fixed by
changes in ACPICA and/or in acpi_ec driver (or even in BIOS) that fixed
the AE_NOT_EXIST failure related to EC operation region.
This work is based on a great analysis by cem and an earlier patch by
Ali Abdallah .
PR: 227191
Reported by: 0mp
MFC after:2 weeks
Changes:
head/sys/dev/acpica/acpi.c
--
You are receiving this mail because:
You are on the CC list for the bug.
___
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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #19 from Andriy Gapon --- I am curious if anyone who had this problem before still has it. Especially, I am curious if they had an error message like in comment#1 and if that message went way. In addition to the prior analysis I'd like to add the following summary. - before base r330957 we ignored any _STA evaluation failure (which was performed in ACPICA contrib code) for the purpose of acpi_DeviceIsPresent and acpi_BatteryIsPresent - ACPICA 20180313 stopped evaluating _STA altogether - so, we added evaluation of _STA to acpi_DeviceIsPresent and acpi_BatteryIsPresent - one important difference is that now we ignore a failure only if _STA does not exist (AE_NOT_FOUND) - any other kind of failure is treated as a failure - apparently, on some systems we can get AE_NOT_EXIST when evaluating _STA - that error is not an evil twin of AE_NOT_FOUND, despite a very similar name, but a distinct error related to a missing handler for embedded controller (EC) address space - it's possible that for some people the problem was fixed by some changes in ACPICA and/or acpi_ec that fixed the AE_NOT_EXIST failure Still, I would like to re-iterate my proposal that we restore full pre-r330957 behaviour by ignoring any _STA error. -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 Error: No handler for Region [ECOR]
In message <10399.1543270...@critter.freebsd.dk>, "Poul-Henning Kamp" writes: >>I'm seeing it on my ThinkPad x230 as well > >and on T480 running 13.0-CURRENT r340932M as well: And seems to be gone with this kernel: 13.0-CURRENT r341006M Havn't tried the ones in between. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 p...@freebsd.org | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ 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 Error: No handler for Region [ECOR]
On 26/11/18 19:59, Yuri Pankov wrote: > Renato Botelho wrote: >> On 26/11/18 19:32, Florian Limberger wrote: >>> Hi, >>> >>> On 20.11.18 14:46, Charlie Li wrote: >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>>> (ID=3) has no handler (20181031/exfldio-428) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >>> >>> On my Thinkpad T410 I get exactly the same error, but it prevents the >>> ACPI poweroff. Instead following lines are printed: >> >> I'm seeing it on my ThinkPad x230 as well > > Looks like r340993 should be the fix? > If fixed it to me. Thanks! -- Renato Botelho signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
Renato Botelho wrote: > On 26/11/18 19:32, Florian Limberger wrote: >> Hi, >> >> On 20.11.18 14:46, Charlie Li wrote: >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>> (ID=3) has no handler (20181031/exfldio-428) >>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >> >> On my Thinkpad T410 I get exactly the same error, but it prevents the >> ACPI poweroff. Instead following lines are printed: > > I'm seeing it on my ThinkPad x230 as well Looks like r340993 should be the fix? signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 26/11/18 19:32, Florian Limberger wrote: > Hi, > > On 20.11.18 14:46, Charlie Li wrote: >> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >> (ID=3) has no handler (20181031/exfldio-428) >> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > On my Thinkpad T410 I get exactly the same error, but it prevents the > ACPI poweroff. Instead following lines are printed: I'm seeing it on my ThinkPad x230 as well -- Renato Botelho ___ 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"
ACPI Error: No handler for Region [ECOR]
Hi, On 20.11.18 14:46, Charlie Li wrote: > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > (ID=3) has no handler (20181031/exfldio-428) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) On my Thinkpad T410 I get exactly the same error, but it prevents the ACPI poweroff. Instead following lines are printed: > The operating system has halted. > Please press any key to reboot. Additional info on my system: $ uname -a FreeBSD hostname 13.0-CURRENT FreeBSD 13.0-CURRENT #6 r340926: Mon Nov 26 00:19:49 CET 2018 root@hostname:/usr/obj/usr/src/amd64.amd64/sys/GENERIC-NODEBUG amd64 $ sysctl dev.acpi_ec dev.acpi_ec.0.%parent: acpi0 dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPC_.EC__ dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x11, ECDT dev.acpi_ec.%parent: Regards, flo ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #18 from Matías Pizarro --- I was still having this problem on 13-CURRENT r340703 ( https://svnweb.freebsd.org/base?view=revision=340703 ). But that was nearly 6 days ago, I have not tested further down the 13-CURRENT development branch and, as you said, there's been quite a few ACPI-related commits since then -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #17 from Mark Johnston --- (In reply to Matías Pizarro from comment #16) There have been several ACPICA updates since the bug was filed, but 13-CURRENT and 12.0 should be in sync. Which revision of 13-CURRENT did you test? Can anyone confirm that this is still an issue, either on -CURRENT on 12? -- You are receiving this mail because: You are on the CC list for the bug. ___ 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"
[Bug 227191] Cannot check battery status after upgrading to 12-CURRENT after r330957 (ACPI _STA method removed)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 --- Comment #16 from Matías Pizarro --- Hi all, FYI, I had the same issue with 13-CURRENT but it now works fine in today';s stable/12 | 12-PRERELEASE which I understand should be the same as 12-RC2. Thanks for your work on this, All the best, -- matías -- You are receiving this mail because: You are on the CC list for the bug. ___ 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 Error: No handler for Region [ECOR]
On 18-11-23 13:05:00, Charlie Li wrote: > On 23/11/2018 00:02, Ben Widawsky wrote: > > Thanks both of you. Here's another shot at roughly the same thing I asked > > the > > first reporter to try (that patch was wrong). If it doesn't work, can you > > please > > post the dmesg? > > > This patch works on my machine as well. > Thanks all. Here is the differential in phabricator: https://reviews.freebsd.org/D18311 > -- > Charlie Li > Can't think of a witty .sigline today… > > (This email address is for mailing list use only; replace local-part > with vishwin for off-list communication) > ___ 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 Error: No handler for Region [ECOR]
___ 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 Error: No handler for Region [ECOR]
On 23/11/2018 00:02, Ben Widawsky wrote: > Thanks both of you. Here's another shot at roughly the same thing I asked the > first reporter to try (that patch was wrong). If it doesn't work, can you > please > post the dmesg? > This patch works on my machine as well. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 18-11-23 16:42:22, Mateusz Piotrowski wrote: > On Tue, 20 Nov 2018 at 15:47, Charlie Li wrote: > > > Somewhere between r340491 and r340650, probably starting from r340595, > > my ThinkPad W550s started spewing these messages repeatedly in the > > system log since boot: > > > > ... > > > > As a result, I am now unable to query battery information at the very > > least. r340490 is my last built revision with this working. > > > > There's a bug report for a similar issue after r330957: > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 This is unrelated. The issue in this thread has to do with a regression I introduced when an ECDT, and an EC device is present (not uncommon). I am going to post a review momentarily for this. ___ 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 Error: No handler for Region [ECOR]
On Tue, 20 Nov 2018 at 15:47, Charlie Li wrote: > Somewhere between r340491 and r340650, probably starting from r340595, > my ThinkPad W550s started spewing these messages repeatedly in the > system log since boot: > > ... > > As a result, I am now unable to query battery information at the very > least. r340490 is my last built revision with this working. > There's a bug report for a similar issue after r330957: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191 ___ 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 Error: No handler for Region [ECOR]
With your patch applied, normal behavior seems back again. "dmesg" output and other relevent files are availabe at: http://imp.ovh/acpi > ___ 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 Error: No handler for Region [ECOR]
Hi all, "patch -p 1 < your_patch" gives me the following *.rej file: @@ -362,7 +362,8 @@ ret = 0; goto out; -} +} else + ecdt = 0; ret = ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids, NULL); if (ret > 0) @@ -422,16 +434,6 @@ /* Store the values we got from the namespace for attach. */ acpi_set_private(dev, params); -/* - * Check for a duplicate probe. This can happen when a probe via ECDT - * succeeded already. If this is a duplicate, disable this device. - */ -peer = devclass_get_device(acpi_ec_devclass, params->uid); -if (peer == NULL || !device_is_alive(peer)) - ret = 0; -else - device_disable(dev); - if (buf.Pointer) AcpiOsFree(buf.Pointer); out: Reject of hunk 1 and hunk 3 may be due to indentation. Anyway, I manually patched these two parts and I am now waiting for kernel build. ___ 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 Error: No handler for Region [ECOR]
Thanks both of you. Here's another shot at roughly the same thing I asked the
first reporter to try (that patch was wrong). If it doesn't work, can you please
post the dmesg?
diff --git a/sys/dev/acpica/acpi_ec.c b/sys/dev/acpica/acpi_ec.c
index a21dbc963af..666aba2b3c8 100644
--- a/sys/dev/acpica/acpi_ec.c
+++ b/sys/dev/acpica/acpi_ec.c
@@ -362,7 +362,8 @@ acpi_ec_probe(device_t dev)
ret = 0;
goto out;
-}
+} else
+ ecdt = 0;
ret = ACPI_ID_PROBE(device_get_parent(dev), dev, ec_ids, NULL);
if (ret > 0)
@@ -382,6 +383,17 @@ acpi_ec_probe(device_t dev)
if (ACPI_FAILURE(status))
params->uid = 0;
+/*
+ * Check for a duplicate probe. This can happen when a probe via ECDT
+ * succeeded already. If this is a duplicate, disable this device.
+ */
+peer = devclass_get_device(acpi_ec_devclass, params->uid);
+if (peer && device_is_alive(peer)) {
+ device_disable(dev);
+ ret = ENXIO;
+ goto out;
+}
+
status = acpi_GetInteger(h, "_GLK", >glk);
if (ACPI_FAILURE(status))
params->glk = 0;
@@ -422,16 +434,6 @@ acpi_ec_probe(device_t dev)
/* Store the values we got from the namespace for attach. */
acpi_set_private(dev, params);
-/*
- * Check for a duplicate probe. This can happen when a probe via ECDT
- * succeeded already. If this is a duplicate, disable this device.
- */
-peer = devclass_get_device(acpi_ec_devclass, params->uid);
-if (peer == NULL || !device_is_alive(peer))
- ret = 0;
-else
- device_disable(dev);
-
if (buf.Pointer)
AcpiOsFree(buf.Pointer);
out:
On 18-11-21 17:08:15, Samy Mahmoudi wrote:
> Hi again,
>
> Please find the requested files:
>
> http://imp.ovh/18.2.0/acpidump_-dt_output
> http://imp.ovh/18.2.0/acpi_ec_values
> http://imp.ovh/18.2.0/dmesg_output
>
> Best regards,
> Samy
>
___
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 Error: No handler for Region [ECOR]
On 21/11/2018 11:21, Charlie Li wrote: > On 20/11/2018 14:37, Ben Widawsky wrote: >> On 18-11-20 11:28:56, Ben Widawsky wrote: >>> On 18-11-20 14:09:08, Jung-uk Kim wrote: >>>> I am pretty sure r340644 caused the regression. >>>> >>> >>> Seems like a good bet. Could you please add the full dmesg as well as an >>> ACPI >>> dump and the output of `sysctl dev.acpi_ec.` Thanks. > Going to try backing out r340644 in my tree. > This revision is indeed the culprit. No more log spam and battery info querying works after backing out. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
On 20/11/2018 14:37, Ben Widawsky wrote: > On 18-11-20 11:28:56, Ben Widawsky wrote: >> On 18-11-20 14:09:08, Jung-uk Kim wrote: >>> On 18. 11. 20., Charlie Li wrote: >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] >>>> (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl >>>> (ID=3) has no handler (20181031/exfldio-428) >>>> Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution >>>> failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) >>>> >>> I am pretty sure r340644 caused the regression. >>> >>> https://svnweb.freebsd.org/changeset/base/340644 >>> >>> Jung-uk Kim >> >> Seems like a good bet. Could you please add the full dmesg as well as an ACPI >> dump and the output of `sysctl dev.acpi_ec.` Thanks. The full dmesg is flooded. sysctl dev.acpi_ec: dev.acpi_ec.0.%parent: acpi0 dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPC_.EC__ dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x25, ECDT dev.acpi_ec.%parent: > > Just for a quick eyeball, this looks suspicious. You could also try this: > I had to remove another line due to -Wunused-variable. In any case, the log spam continues unabated and battery status querying continues to fail. Going to try backing out r340644 in my tree. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) diff -r 531cf2dab058 sys/dev/acpica/acpi_ec.c --- a/sys/dev/acpica/acpi_ec.c Mon Nov 19 17:31:36 2018 -0500 +++ b/sys/dev/acpica/acpi_ec.c Wed Nov 21 10:52:58 2018 -0500 @@ -338,7 +338,6 @@ ACPI_HANDLE h; ACPI_OBJECT *obj; ACPI_STATUS status; -device_t peer; char desc[64]; int ecdt; int ret; @@ -422,6 +421,7 @@ /* Store the values we got from the namespace for attach. */ acpi_set_private(dev, params); +#if 0 /* * Check for a duplicate probe. This can happen when a probe via ECDT * succeeded already. If this is a duplicate, disable this device. @@ -431,6 +431,7 @@ ret = 0; else device_disable(dev); +#endif if (buf.Pointer) AcpiOsFree(buf.Pointer); signature.asc Description: OpenPGP digital signature
Re: ACPI Error: No handler for Region [ECOR]
Hi again, Please find the requested files: http://imp.ovh/18.2.0/acpidump_-dt_output http://imp.ovh/18.2.0/acpi_ec_values http://imp.ovh/18.2.0/dmesg_output Best regards, Samy > ___ 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 Error: No handler for Region [ECOR]
Same problem/output as Charlie Li, with a Lenovo T520. I will post requested output files as soon as possible. ___ 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 Error: No handler for Region [ECOR]
Hi, I have the same problem as Charlie Li. In case it could help you address this I put up the data you requested in a gist: https://gist.github.com/rebost/f8f231662a7501b14d63f348ee5e4ca2 you can also download it as a zip file: https://gist.github.com/rebost/f8f231662a7501b14d63f348ee5e4ca2/archive/6af9d446aaef167fc8c72c56f1cae9f7be1fff97.zip # uname -a FreeBSD lenovo01.x.xx 13.0-CURRENT FreeBSD 13.0-CURRENT r340703+73a91fe29c4(svn_head) GENERIC-NODEBUG amd64 # sysctl dev.acpi_ec dev.acpi_ec.0.%parent: acpi0 dev.acpi_ec.0.%pnpinfo: _HID=PNP0C09 _UID=0 dev.acpi_ec.0.%location: handle=\_SB_.PCI0.LPCB.EC__ dev.acpi_ec.0.%driver: acpi_ec dev.acpi_ec.0.%desc: Embedded Controller: GPE 0x16, ECDT dev.acpi_ec.%parent: Best, -- matías ___ 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 Error: No handler for Region [ECOR]
On 18-11-20 11:28:56, Ben Widawsky wrote: > On 18-11-20 14:09:08, Jung-uk Kim wrote: > > On 18. 11. 20., Charlie Li wrote: > > > Somewhere between r340491 and r340650, probably starting from r340595, > > > my ThinkPad W550s started spewing these messages repeatedly in the > > > system log since boot: > > > > > > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > > > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > > > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > > > (ID=3) has no handler (20181031/exfldio-428) > > > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > > > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > > > > > As a result, I am now unable to query battery information at the very > > > least. r340490 is my last built revision with this working. > > > > I am pretty sure r340644 caused the regression. > > > > https://svnweb.freebsd.org/changeset/base/340644 > > > > Jung-uk Kim > > Seems like a good bet. Could you please add the full dmesg as well as an ACPI > dump and the output of `sysctl dev.acpi_ec.` Thanks. Just for a quick eyeball, this looks suspicious. You could also try this: diff --git a/sys/dev/acpica/acpi_ec.c b/sys/dev/acpica/acpi_ec.c index a21dbc963af..5d6dba6a887 100644 --- a/sys/dev/acpica/acpi_ec.c +++ b/sys/dev/acpica/acpi_ec.c @@ -422,6 +422,7 @@ acpi_ec_probe(device_t dev) /* Store the values we got from the namespace for attach. */ acpi_set_private(dev, params); +#if 0 /* * Check for a duplicate probe. This can happen when a probe via ECDT * succeeded already. If this is a duplicate, disable this device. @@ -431,6 +432,7 @@ acpi_ec_probe(device_t dev) ret = 0; else device_disable(dev); +#endif if (buf.Pointer) AcpiOsFree(buf.Pointer); -- Ben Widawsky, Intel Open Source Technology Center ___ 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 Error: No handler for Region [ECOR]
On 18-11-20 14:09:08, Jung-uk Kim wrote: > On 18. 11. 20., Charlie Li wrote: > > Somewhere between r340491 and r340650, probably starting from r340595, > > my ThinkPad W550s started spewing these messages repeatedly in the > > system log since boot: > > > > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > > (ID=3) has no handler (20181031/exfldio-428) > > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > > > As a result, I am now unable to query battery information at the very > > least. r340490 is my last built revision with this working. > > I am pretty sure r340644 caused the regression. > > https://svnweb.freebsd.org/changeset/base/340644 > > Jung-uk Kim Seems like a good bet. Could you please add the full dmesg as well as an ACPI dump and the output of `sysctl dev.acpi_ec.` Thanks. ___ 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 Error: No handler for Region [ECOR]
On 18. 11. 20., Charlie Li wrote: > Somewhere between r340491 and r340650, probably starting from r340595, > my ThinkPad W550s started spewing these messages repeatedly in the > system log since boot: > > Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] > (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl > (ID=3) has no handler (20181031/exfldio-428) > Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution > failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) > > As a result, I am now unable to query battery information at the very > least. r340490 is my last built revision with this working. I am pretty sure r340644 caused the regression. https://svnweb.freebsd.org/changeset/base/340644 Jung-uk Kim ___ 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"
ACPI Error: No handler for Region [ECOR]
Somewhere between r340491 and r340650, probably starting from r340595, my ThinkPad W550s started spewing these messages repeatedly in the system log since boot: Nov 20 09:35:19 ardmore kernel: ACPI Error: No handler for Region [ECOR] (0xf80003662300) [EmbeddedControl] (20181031/evregion-288) Nov 20 09:35:19 ardmore kernel: ACPI Error: Region EmbeddedControl (ID=3) has no handler (20181031/exfldio-428) Nov 20 09:35:19 ardmore kernel: ACPI Error: Method parse/execution failed \_SB.PCI0.LPC.EC.BAT1._BST, AE_NOT_EXIST (20181031/psparse-677) As a result, I am now unable to query battery information at the very least. r340490 is my last built revision with this working. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Wednesday, 14 November 2018 12:41:53 MST Stefan Ehmann wrote: > On 11/14/18 5:41 AM, Conrad Meyer wrote: > > Ok I'll go ahead and commit that too. > > Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range. > Looks reasonable. Much better here, too: dev.amdtemp.3.core0.sensor0: 38.1C dev.amdtemp.3.sensor_offset: -27 dev.amdtemp.2.core0.sensor0: 39.0C dev.amdtemp.2.sensor_offset: -27 dev.amdtemp.1.core0.sensor0: 37.5C dev.amdtemp.1.sensor_offset: -27 dev.amdtemp.0.core0.sensor0: 40.1C dev.amdtemp.0.sensor_offset: -27 Thanks! Rebecca ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On 11/14/18 5:41 AM, Conrad Meyer wrote: > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the same > thing. I guess that patch never landed? 102°C - 49°C is the very > reasonable 53°C. > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 > > Ok I'll go ahead and commit that too. Applied to 12.0-BETA, Ryzen 7 2700 values are now in the 30-55C range. Looks reasonable. Thanks! ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
Perfect! Sounds like we are on the right track, at least. Best, Conrad On Tue, Nov 13, 2018 at 8:55 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote: > > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > > I.e., sometimes the CPU chooses to report on a range from 0-225C and > > sometimes -49C-206C. I think someone else's 2990WX did the same > > thing. I guess that patch never landed? 102°C - 49°C is the very > > reasonable 53°C. > > > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 > > Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD > reporting 51.1C while the readout on the motherboard shows 51C :) > > I'll fetch and build r340426 tomorrow. > > -- > Rebecca > > ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tuesday, 13 November 2018 21:41:58 MST Conrad Meyer wrote: > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the same > thing. I guess that patch never landed? 102°C - 49°C is the very > reasonable 53°C. > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 Thanks, that's it: setting the sensor_offset sysctls to -76 results in FreeBSD reporting 51.1C while the readout on the motherboard shows 51C :) I'll fetch and build r340426 tomorrow. -- Rebecca ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
Please try r340426 :-). On Tue, Nov 13, 2018 at 8:41 PM Conrad Meyer wrote: > > You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? > I.e., sometimes the CPU chooses to report on a range from 0-225C and > sometimes -49C-206C. I think someone else's 2990WX did the same > thing. I guess that patch never landed? 102°C - 49°C is the very > reasonable 53°C. > > Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 > > Ok I'll go ahead and commit that too. > > Thanks, > Conrad > On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer wrote: > > > > On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran wrote: > > > > > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > > > > > > > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > > > > plausible 75?C (still pretty warm even for load). How good is your > > > > cooling solution? > > > > > > D'oh, of course it's -54 instead of +54 (For some reason I presumed a > > > positive > > > offset would be *subtracted*)! I have an all-in-one liquid thermaltake > > > cooler installed, and under Windows it reports reaching 67C when running > > > flat > > > out, which doesn't seem bad. > > > > Yeah, 67C seems totally great at load. > > > > > > (The references I can find with a quick search suggest TR 29xx should > > > > also be -27? rather than -54?C, but they may be mistaken. 183-54-27 > > > > is still 102?C ? extremely hot!) > > > > > > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 > > > cores > > > instead of 2 units and 16 cores for other models, so I guessed that > > > perhaps I > > > should double the 27 value other people had said should be used. > > > > Hm, the Linux folks still use -27 for the 2990WX as well as all of the > > other threadripper models. I'm not sure what's right. I wish I had > > access to the Ryzen 2 register docs, but I don't. > > > > Best, > > Conrad ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
You know what, I wonder if you're running into the CUR_TEMP_RANGE_SEL? I.e., sometimes the CPU chooses to report on a range from 0-225C and sometimes -49C-206C. I think someone else's 2990WX did the same thing. I guess that patch never landed? 102°C - 49°C is the very reasonable 53°C. Yeah, sigh, it never landed: https://reviews.freebsd.org/D16855 Ok I'll go ahead and commit that too. Thanks, Conrad On Tue, Nov 13, 2018 at 8:38 PM Conrad Meyer wrote: > > On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran wrote: > > > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > > > > > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > > > plausible 75?C (still pretty warm even for load). How good is your > > > cooling solution? > > > > D'oh, of course it's -54 instead of +54 (For some reason I presumed a > > positive > > offset would be *subtracted*)! I have an all-in-one liquid thermaltake > > cooler installed, and under Windows it reports reaching 67C when running > > flat > > out, which doesn't seem bad. > > Yeah, 67C seems totally great at load. > > > > (The references I can find with a quick search suggest TR 29xx should > > > also be -27? rather than -54?C, but they may be mistaken. 183-54-27 > > > is still 102?C ? extremely hot!) > > > > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores > > instead of 2 units and 16 cores for other models, so I guessed that perhaps > > I > > should double the 27 value other people had said should be used. > > Hm, the Linux folks still use -27 for the 2990WX as well as all of the > other threadripper models. I'm not sure what's right. I wish I had > access to the Ryzen 2 register docs, but I don't. > > Best, > Conrad ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tue, Nov 13, 2018 at 8:29 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > > > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > > plausible 75?C (still pretty warm even for load). How good is your > > cooling solution? > > D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive > offset would be *subtracted*)! I have an all-in-one liquid thermaltake > cooler installed, and under Windows it reports reaching 67C when running flat > out, which doesn't seem bad. Yeah, 67C seems totally great at load. > > (The references I can find with a quick search suggest TR 29xx should > > also be -27? rather than -54?C, but they may be mistaken. 183-54-27 > > is still 102?C ? extremely hot!) > > That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores > instead of 2 units and 16 cores for other models, so I guessed that perhaps I > should double the 27 value other people had said should be used. Hm, the Linux folks still use -27 for the 2990WX as well as all of the other threadripper models. I'm not sure what's right. I wish I had access to the Ryzen 2 register docs, but I don't. Best, Conrad ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tuesday, 13 November 2018 21:17:59 MST Conrad Meyer wrote: > Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat > plausible 75?C (still pretty warm even for load). How good is your > cooling solution? D'oh, of course it's -54 instead of +54 (For some reason I presumed a positive offset would be *subtracted*)! I have an all-in-one liquid thermaltake cooler installed, and under Windows it reports reaching 67C when running flat out, which doesn't seem bad. > (The references I can find with a quick search suggest TR 29xx should > also be -27? rather than -54?C, but they may be mistaken. 183-54-27 > is still 102?C ? extremely hot!) That's why I thought 54 was more likely! My 2990WX has 4 units for 32 cores instead of 2 units and 16 cores for other models, so I guessed that perhaps I should double the 27 value other people had said should be used. -- Rebecca ___ 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: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G
On Tue, Nov 13, 2018 at 8:05 PM Rebecca Cran wrote: > > On Tuesday, 13 November 2018 16:20:22 MST Stefan Ehmann wrote: > > > The 2700 has an offset of 0 though (2700X has 10). > > And I'm seeing a difference of more than 30 degrees. I guess something > > else must be happening here. > > I had thought 54 was the right offset for my 2990WX system, but now it's under > load building ports the temperature reported via dev.amdtemp is 183C! > Meanwhile the readout on the motherboard says "CPU Temp 53 C". Maybe it should be -54 instead of +54? 183-(54*2) is the somewhat plausible 75°C (still pretty warm even for load). How good is your cooling solution? (The references I can find with a quick search suggest TR 29xx should also be -27° rather than -54°C, but they may be mistaken. 183-54-27 is still 102°C — extremely hot!) Best, Conrad ___ 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"
