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
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.
> >
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
> > &q
ound 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
s 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
-O
estart 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
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
l 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
Hi,
I don't know what you mean by "sleep", but some CPUs have bug and setting:
sysctl machdep.idle=spin
Helps!
--HPS
….. 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
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 wh
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 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
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 th
>>>>>> 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.
>>>>
>
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 bu
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
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
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
> 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 t
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 Wa
> 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 th
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
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 suppr
s
> #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
land 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, bu
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
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
>>&g
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 Mu
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 t
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
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
n 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 (
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
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 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
gt;>>>> 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 be
.
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
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.
&g
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
>
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
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 ba
iguration 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 "
hen 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 determin
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.
>
&g
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
25 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
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
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
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
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
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
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
x 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 foll
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
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
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
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:
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
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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Kubilay Kocak changed:
What|Removed |Added
Flags|mfc-stable12? |mfc-stable12+
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Andriy Gapon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In
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:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Andriy Gapon changed:
What|Removed |Added
Assignee|a...@freebsd.org|a...@freebsd.org
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
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
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.
--
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]
>&
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-
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
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
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
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?
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
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
___
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"
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
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
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
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/fr
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
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
---
; 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
que
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]
>>>> (0xfff
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
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
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:
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 EmbeddedCo
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
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 f
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
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:
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?
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
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
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
>
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,
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
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
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
1 - 100 of 1744 matches
Mail list logo
