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.
> > >
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 FreeBS
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
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
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
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
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
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
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
x27;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.
>>>>>> 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.
>>>>
>
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 linu
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:
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:
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 (0x00
> 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 s
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:
> > ---
> &g
> 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.
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.
o 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 A
serland 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
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 imp
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 powe
re 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 \_PT
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
..
>>>> 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 "
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 det
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
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
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 bo
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
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
>
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+
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 Thin
, 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 ad
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/vie
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 pla
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:
Yo
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
-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
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Kubilay Kocak changed:
What|Removed |Added
Flags|mfc-stable12? |mfc-stable12+
Keywords|n
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Andriy Gapon changed:
What|Removed |Added
Resolution|--- |FIXED
Status|In Progres
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,Batte
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=227191
Andriy Gapon changed:
What|Removed |Added
Assignee|a...@freebsd.org|a...@freebsd.org
Status
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&#
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.
--
P
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
RENT 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.or
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
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 w
___
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 a
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/freeb
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 value
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
; 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 wo
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
https://lists.freebsd.org/ma
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 "freeb
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
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:
dev.amdtemp.3.core0.sensor0
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? 10
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 cho
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 pa
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.
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, si
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 positi
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 thou
1 - 100 of 1762 matches
Mail list logo
