by making it wait for the next
> RCU grace period to elapse, for all of the RCU callbacks to complete
> and for all of the scheduled work items to be flushed before
> returning.
>
> Fixes: 1757659d022b ("ACPI: OSL: Implement deferred unmapping of ACPI memory")
sible)
> after resume when you see the problem.
See attached.
> I guess tlp only uses /sys/module/pcie_aspm/parameters/policy, so it
> sets the same ASPM policy system-wide.
Yeah.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA00:00
; with the tlp tweak and without?
Definitely with the revert everything works. I'll try your patch after the
revert and see if anything changes.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
On Sun, 27 Dec 2020, Kenneth R. Crudup wrote:
> I'll try your patch after the revert and see if anything changes.
I just realized today's patch makes no sense if it's reverted, so nevermind.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
environment by the exact same commit.
I can confirm that reverting 7f3d176f5f stops my kernel from panic()ing:
$ sudo fwupdtpmevlog
[sudo] password for kenny:
Failed to parse file: attempted to read 0x10 bytes from buffer of 0x00
$
It would normally OOPS at that point.
-Kenny
--
Kenneth R
s a
panic() when 7f3d176f5f7e is in place) and the results are:
- With 7f3d176f5f7e reverted, no WARNs of any kind
- With 7f3d176f5f7e in place, same, I just get "UEFI TPM log area empty"
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
6
From: Kenneth R. Crudup
To: vid...@nvidia.com
Cc: bhelg...@google.com
Subject: Commit 4257f7e0 ("PCI/ASPM: Save/restore L1SS Capability for
suspend/resume") causing hibernate resume
failures
I've been running Linus' master branch on my laptop (Dell XPS 13 2-in-1). With
this commit
disabling "tlp" doesn't fix the issue; I'd tested this and if IIRC,
if I don't use tlp it doesn't prevent this from happening, it just shifts it
from breaking on hibernate cycles to suspend/resume cycles instead.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
fresh branch that does contain the commit in the
Subject: line, and w/o Christoph's ROMs patch and as long as I don't boot
with the TB adapter attached (or from a cold boot- SOMEtimes) it seems to
work. So, my apologies for wasting everyone's time.
-Kenny
--
Kenneth R. Crudup Sr. SW En
On Sat, Jun 20, 2020 at 6:46 AM Kenneth R. Crudup wrote:
> > So, be totally surprised :) I've just booted with "maccess: rename
> > probe_kernel_address to get_kernel_nofault" intact and your probe_roms.c
> > patch with no issues.
> > (Perhaps there's some s
s well).
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
.probe_roms.o.cmd
Description: Binary data
probe_roms.o
Description: application/object
v/kernel/traps.c:if (probe_kernel_address((bug_insn_t *)pc,
insn))
./arch/riscv/kernel/traps.c:if (probe_kernel_address((bug_insn_t *)pc,
insn))
> Do you see any compiler warnings or something
> odd in the kernel log before the actual crash?
Not that I could see, but I'll try
the bisect turned up the commit in the subject: and reverting it
(only) stopped the crashes. This was this afternoon's (US PST) Linus' master.
> Below is a patch to do a "partial revert" for probe_roms.c.
I'll give it a shot later, thanks.
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
me
probe_kernel_address to get_kernel_nofault" intact and your probe_roms.c
patch with no issues.
(Perhaps there's some sort of compiler optimization going on?)
-Kenny
--
Kenneth R. Crudup Sr. SW Engineer, Scott County Consulting, Orange County CA
> > From: Kenneth R. Crudup
> > I've been running Linus' master branch on my laptop (Dell XPS 13
> > 2-in-1). With this commit in place, after resuming from hibernate
> > my machine is essentially useless, with a torrent of disk I/O errors
> > on my NVMe device
15 matches
Mail list logo
