On Sun, Jan 24, 2021 at 2:49 PM Stephen Berman wrote:
>
> On Mon, 04 Jan 2021 16:38:43 +0100 Stephen Berman
> wrote:
>
> > On Thu, 31 Dec 2020 21:46:11 +0100 "Rafael J. Wysocki"
> > wrote:
> >
> >> ATM, I'm tempted to do something like the patch below (with the rationale
> >> that it shouldn't
On Mon, 04 Jan 2021 16:38:43 +0100 Stephen Berman
wrote:
> On Thu, 31 Dec 2020 21:46:11 +0100 "Rafael J. Wysocki"
> wrote:
>
>> ATM, I'm tempted to do something like the patch below (with the rationale
>> that it shouldn't be necessary to read the temperature right after updating
>> the trip p
On Thu, 31 Dec 2020 21:46:11 +0100 "Rafael J. Wysocki"
wrote:
> ATM, I'm tempted to do something like the patch below (with the rationale
> that it shouldn't be necessary to read the temperature right after updating
> the trip points if polling is in use, because the next update through polling
On Thursday, December 31, 2020 9:46:11 PM CET Rafael J. Wysocki wrote:
> On Wednesday, December 2, 2020 8:13:38 PM CET Rafael J. Wysocki wrote:
> > On Wed, Dec 2, 2020 at 7:31 PM Rafael J. Wysocki wrote:
> > >
> > > On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
> > > wrote:
> > > >
> >
On Wednesday, December 2, 2020 8:13:38 PM CET Rafael J. Wysocki wrote:
> On Wed, Dec 2, 2020 at 7:31 PM Rafael J. Wysocki wrote:
> >
> > On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
> > wrote:
> > >
> > > On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > > > > Done
On Wed, Dec 2, 2020 at 7:31 PM Rafael J. Wysocki wrote:
>
> On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
> wrote:
> >
> > On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > > > Done as Bug 208877.
> > > > > Rafael, do you have any suggestions?
> > > >
> > > > I've l
On Wed, Dec 2, 2020 at 7:03 PM Sebastian Andrzej Siewior
wrote:
>
> On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > > Done as Bug 208877.
> > > > Rafael, do you have any suggestions?
> > >
> > > I've lost track of this sorry.
> > >
> > > I have ideas, let me get back to this
On 2020-10-26 18:20:59 [+0100], To Rafael J. Wysocki wrote:
> > > > > Done as Bug 208877.
> > > Rafael, do you have any suggestions?
> >
> > I've lost track of this sorry.
> >
> > I have ideas, let me get back to this next week.
>
> :)
Rafael, any update? If you outline an idea or so then I may
On 2020-10-07 18:18:03 [+0200], Rafael J. Wysocki wrote:
> On 10/6/2020 11:49 PM, Sebastian Andrzej Siewior wrote:
> > On 2020-08-11 20:49:05 [+0200], To Stephen Berman wrote:
> > > On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> > > > Attached.
> > > ssdt6.dsl:
> > > | ThermalZone (TZ10)
On 10/6/2020 11:49 PM, Sebastian Andrzej Siewior wrote:
On 2020-08-11 20:49:05 [+0200], To Stephen Berman wrote:
On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
Attached.
ssdt6.dsl:
| ThermalZone (TZ10)
| {
…
| Method (_TSP, 0, Serialized) // _TSP: Thermal Sampling Period
|
On 2020-08-11 20:49:05 [+0200], To Stephen Berman wrote:
> On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> > Attached.
>
> ssdt6.dsl:
> | ThermalZone (TZ10)
> | {
> …
> | Method (_TSP, 0, Serialized) // _TSP: Thermal Sampling Period
> | {
> | Return (0x0A)
> | }
On 2020-08-11 19:22:19 [+0200], Stephen Berman wrote:
> Attached.
ssdt6.dsl:
| ThermalZone (TZ10)
| {
…
| Method (_TSP, 0, Serialized) // _TSP: Thermal Sampling Period
| {
| Return (0x0A)
| }
|
| Method (_TZP, 0, Serialized) // _TZP: Thermal Zone Polling
| {
|
On 2020-08-11 16:34:09 [+0200], Rafael J. Wysocki wrote:
> On Tue, Aug 11, 2020 at 3:29 PM Sebastian Andrzej Siewior
> wrote:
> >
> > On 2020-08-11 13:58:39 [+0200], Stephen Berman wrote:
> > > him about your workaround of adding 'thermal.tzp=300' to the kernel
> > > commandline, and he replied th
On Tue, Aug 11, 2020 at 3:29 PM Sebastian Andrzej Siewior
wrote:
>
> On 2020-08-11 13:58:39 [+0200], Stephen Berman wrote:
> > him about your workaround of adding 'thermal.tzp=300' to the kernel
> > commandline, and he replied that this works for him too. And it turns
> > out we have similar moth
On Tue, Aug 11, 2020 at 12:27 PM Sebastian Andrzej Siewior
wrote:
>
> On 2020-07-14 17:53:15 [+0200], Rafael J. Wysocki wrote:
> > acpi_evaluate_integer() doesn't show up in the trace, though, AFAICS.
> >
> > > I assumed acpi_ex_opcode_2A_0T_0R() since the other
> > > candidate was acpi_ev_asynch_
On 2020-08-11 13:58:39 [+0200], Stephen Berman wrote:
> him about your workaround of adding 'thermal.tzp=300' to the kernel
> commandline, and he replied that this works for him too. And it turns
> out we have similar motherboards: I have a Gigabyte Z390 M Gaming
> Rev. 1001 board and he has Gigab
On Sun, 19 Jul 2020 12:07:14 +0200 Stephen Berman
wrote:
> On Tue, 14 Jul 2020 16:11:35 +0200 Sebastian Andrzej Siewior
> wrote:
>
[...]
>> Stephen, the patch attached adds a WARN_ON() statement which will
>> produce a stack trace (4 or so). Could please run 'dmesg' after a while
>> and send it
On 2020-07-14 17:53:15 [+0200], Rafael J. Wysocki wrote:
> acpi_evaluate_integer() doesn't show up in the trace, though, AFAICS.
>
> > I assumed acpi_ex_opcode_2A_0T_0R() since the other
> > candidate was acpi_ev_asynch_execute_gpe_method().
>
> Which probably is the case. Specifically
>
> acpi
On Tue, 14 Jul 2020 16:11:35 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-07-14 15:54:57 [+0200], Rafael J. Wysocki wrote:
>> On Tue, Jul 14, 2020 at 3:44 PM Sebastian Andrzej Siewior
>> wrote:>
>> > On 2020-06-24 23:49:52 [+0200], Stephen Berman wrote:
>> >
>> > Let me summarize the thread
On 2020-07-14 17:53:15 [+0200], Rafael J. Wysocki wrote:
> > shows the pattern and we nailed it down that it comes from
> > thermal_get_temp().
>
> acpi_evaluate_integer() doesn't show up in the trace, though, AFAICS.
I deducted it. acpi_thermal_get_temperature() -> acpi_evaluate_integer()
and th
On Tue, Jul 14, 2020 at 4:11 PM Sebastian Andrzej Siewior
wrote:
>
> On 2020-07-14 15:54:57 [+0200], Rafael J. Wysocki wrote:
> > On Tue, Jul 14, 2020 at 3:44 PM Sebastian Andrzej Siewior
> > wrote:>
> > > On 2020-06-24 23:49:52 [+0200], Stephen Berman wrote:
> > >
> > > Let me summarize the thre
On 2020-07-14 15:54:57 [+0200], Rafael J. Wysocki wrote:
> On Tue, Jul 14, 2020 at 3:44 PM Sebastian Andrzej Siewior
> wrote:>
> > On 2020-06-24 23:49:52 [+0200], Stephen Berman wrote:
> >
> > Let me summarize the thread here:
> >
> > On Stephen's system, ACPI informs the thermal zone driver to po
On Tue, Jul 14, 2020 at 3:44 PM Sebastian Andrzej Siewior
wrote:>
> On 2020-06-24 23:49:52 [+0200], Stephen Berman wrote:
>
> Let me summarize the thread here:
>
> On Stephen's system, ACPI informs the thermal zone driver to poll the
> temperature every second and the driver does so.
> The driver
On 2020-06-24 23:49:52 [+0200], Stephen Berman wrote:
Let me summarize the thread here:
On Stephen's system, ACPI informs the thermal zone driver to poll the
temperature every second and the driver does so.
The driver queries the temperature by invoking acpi_evaluate_integer()
which invokes (at s
On Wed, 24 Jun 2020 22:11:56 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-17 23:09:44 [+0200], Stephen Berman wrote:
>>
>> Attached.
>
> I did not forget about this but had recently little time to look into
> this.
No problem!
Steve Berman
On 2020-06-17 23:09:44 [+0200], Stephen Berman wrote:
>
> Attached.
I did not forget about this but had recently little time to look into
this.
> Steve Berman
Sebastian
On Wed, 17 Jun 2020 16:27:34 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-16 22:28:43 [+0200], Stephen Berman wrote:
>> Your assessment and predictions are right on the mark!
> perfect.
>
>> I'm fine with the thermal.tzp=300 workaround, but it would be good to
>> find out why this problem
On 2020-06-16 22:28:43 [+0200], Stephen Berman wrote:
> Your assessment and predictions are right on the mark!
perfect.
> I'm fine with the thermal.tzp=300 workaround, but it would be good to
> find out why this problem started with commit 6d25be57, if my git
> bisection was correct, or if it wasn
On Tue, 16 Jun 2020 17:55:01 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-16 10:13:27 [+0200], Stephen Berman wrote:
>> Yes, thanks, that did it. Trace attached.
>
> So TZ10 is a temperature sensor of some kind on your motherboard. In
> your v5.6 dmesg there is:
> | thermal LNXTHERM:00:
On 2020-06-16 10:13:27 [+0200], Stephen Berman wrote:
> Yes, thanks, that did it. Trace attached.
So TZ10 is a temperature sensor of some kind on your motherboard. In
your v5.6 dmesg there is:
| thermal LNXTHERM:00: registered as thermal_zone0
| ACPI: Thermal Zone [TZ10] (17 C)
So. In /sys/class
On Tue, 16 Jun 2020 09:38:27 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-16 09:14:37 [+0200], Stephen Berman wrote:
>>
>> I set CONFIG_ACPI_DEBUG=y, applied the patch and rebuilt 5.6.4, but:
>>
>> $ cat /sys/kernel/debug/tracing/trace > trace.txt
>> cat: /sys/kernel/debug/tracing/trace:
On 2020-06-16 09:14:37 [+0200], Stephen Berman wrote:
>
> I set CONFIG_ACPI_DEBUG=y, applied the patch and rebuilt 5.6.4, but:
>
> $ cat /sys/kernel/debug/tracing/trace > trace.txt
> cat: /sys/kernel/debug/tracing/trace: No such file or directory
>
> Here are all the 5.6.4 config options with "T
On Mon, 15 Jun 2020 16:51:30 +0200 Sebastian Andrzej Siewior
wrote:
> I attached a modified acpi_dbg.patch. Please enable:
> - CONFIG_ACPI_DEBUG=y
>
> Looking at your 5.1 you have tracing enabled (hope it still is).
>
> The attached patch will dump the date into the tracing buffer, so you
> cons
On 2020-06-15 18:19:18 [+0200], Stephen Berman wrote:
> It's there, 196 lines above the Start 8d7aa8758a80 line:
>
> Jun 15 08:56:58 strobe-jhalfs kernel: [ 106.275356] acpi_os_execute(1109)
> Adding acpi_ev_notify_dispatch+0x0/0x55 8d7aa84e70a0
So compared with
| [ 193.321242] acpi_
On Mon, 15 Jun 2020 17:58:46 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-15 17:41:06 [+0200], Stephen Berman wrote:
>> > If you do this "t" then there should be a lot of output on your console.
>> > If you do this from an xterm then you can see the output after typing
>> > "dmesg". The o
On 2020-06-15 17:41:06 [+0200], Stephen Berman wrote:
> > If you do this "t" then there should be a lot of output on your console.
> > If you do this from an xterm then you can see the output after typing
> > "dmesg". The output should appear also in your system log.
>
> Ah, ok, I do see it in the
On Mon, 15 Jun 2020 16:51:30 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-15 09:58:00 [+0200], Stephen Berman wrote:
>> Ok, sorry, I had misunderstood, but now I've looked at the
>> documentation. I had in fact already done `echo t >
>> /proc/sysrq-trigger' in an xterm (as root) and ther
On 2020-06-15 09:58:00 [+0200], Stephen Berman wrote:
> Ok, sorry, I had misunderstood, but now I've looked at the
> documentation. I had in fact already done `echo t >
> /proc/sysrq-trigger' in an xterm (as root) and there was no output.
> Later, after booting kernel 5.1.0 because of the message
On Sun, 14 Jun 2020 19:10:05 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-14 14:12:18 [+0200], Stephen Berman wrote:
[...]
>> What am I supposed to do after "echo t > /proc/sysrq-trigger"? Both
>> before and after doing that I get an error trying to open the file:
>>
>> root [ ~ ]# cat
On 2020-06-14 14:12:18 [+0200], Stephen Berman wrote:
> On Fri, 12 Jun 2020 13:01:22 +0200 Sebastian Andrzej Siewior
> wrote:
>
> steve [ ~ ]$ grep -E 'acpi|smbus' /proc/interrupts
>9: 0 5 0 0 0 0
>0 0 0
On Fri, 12 Jun 2020 13:01:22 +0200 Sebastian Andrzej Siewior
wrote:
> + ACPI in case the ACPI folks see something obvious.
[...]
>> The "acpi_os_execute_deferred" messages were repeated many times in the
>> above line, then every 20-30 seconds again for several minutes. Then
>> suddenly a call
+ ACPI in case the ACPI folks see something obvious.
On 2020-06-11 17:39:40 [+0200], Stephen Berman wrote:
>
> I've done that now. I've sent you screenshots offlist. Here's a brief
> summary: The initial shutdown log output is essentially the same as the
> transcription I posted upthread, excep
On Thu, 11 Jun 2020 00:49:26 +0200 Stephen Berman
wrote:
> On Wed, 10 Jun 2020 12:25:14 +0200 Sebastian Andrzej Siewior
> wrote:
> [...]
>>> By the other patch do you mean the following? (This email was also put
>>> into my spam by GMX and AFAICT has not yet shown up on the vger list.)
>>
>> Y
On Wed, 10 Jun 2020 12:25:14 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-06-10 10:21:29 [+0200], Stephen Berman wrote:
>> (GMX put your email into my spam folder, so I didn't see it before I
>> sent my followup about removing the wifi firmware.)
>
> okay.
>
>> On Tue, 9 Jun 2020 22:23:39 +0
On 2020-06-10 10:21:29 [+0200], Stephen Berman wrote:
> (GMX put your email into my spam folder, so I didn't see it before I
> sent my followup about removing the wifi firmware.)
okay.
> On Tue, 9 Jun 2020 22:23:39 +0200 Sebastian Andrzej Siewior
> wrote:
> > scripts/decode_stacktrace.sh vmli
having.
>>
>> Do you still want me to check whether removing the iwlwifi driver makes
>> a differece? And with the CDROM still detached, or does that not
>> matter?
>
> I assumed the wifi driver shuts the AHCI port for some reason. But
> according to this log it
On Tue, 09 Jun 2020 12:06:23 +0200 Stephen Berman
wrote:
> Do you still want me to check whether removing the iwlwifi driver makes
> a differece? And with the CDROM still detached, or does that not
> matter?
I'm not actually sure just what you mean by removing the wifi driver,
but I just now t
On 2020-06-09 12:06:23 [+0200], Stephen Berman wrote:
> I recompiled kernel 5.6.4 with the printk() call you suggested, then
> booted the kernel with "ignore_loglevel initcall_debug" (but leaving the
> CDROM and wifi intact for now). After working as I normally do, I
> called `shutdown -h now', ag
On Fri, 22 May 2020 18:40:12 +0200 Sebastian Andrzej Siewior
wrote:
> Sorry for the late reply.
No problem, since as it turned out, I didn't have to time till now to
follow up on your latest suggestions. Details below.
> On 2020-05-14 23:39:40 [+0200], Stephen Berman wrote:
>> >> How will I k
Sorry for the late reply.
On 2020-05-14 23:39:40 [+0200], Stephen Berman wrote:
> >> How will I know if that happens, is there a specific message in the tty?
> >
> > On the tty console where you see the "timing out command, waited"
> > message, there should be something starting with
> > |BUG: wor
On Thu, 14 May 2020 00:04:28 +0200 Sebastian Andrzej Siewior
wrote:
> On 2020-05-08 23:30:45 [+0200], Stephen Berman wrote:
>> > Can you log the output on the serial console?
>>
>> How do I do that?
>
> The spec for your mainboard says "serial port header". You would need to
> connect a cable th
On 2020-05-08 23:30:45 [+0200], Stephen Berman wrote:
> > Can you log the output on the serial console?
>
> How do I do that?
The spec for your mainboard says "serial port header". You would need to
connect a cable there to another computer and log its output.
The alternative would be to delay th
On 2020-05-01 17:46:48 [+0200], Stephen Berman wrote:
> I'm experiencing a delay or hang in powering off my computer after `halt
> -d -f -i -p' and I've bisected it to this commit in the mainline tree:
You refer to a normal "poweroff" or is this some kind of "shutdown now"
kind of thing? Unless I'
I'm experiencing a delay or hang in powering off my computer after `halt
-d -f -i -p' and I've bisected it to this commit in the mainline tree:
commit 6d25be5782e482eb93e3de0c94d0a517879377d0
Author: Thomas Gleixner
Date: Wed Mar 13 17:55:48 2019 +0100
sched/core, workqueues: Distangle wor
54 matches
Mail list logo
