On Thu, Aug 1, 2013 at 4:42 PM, Luck, Tony wrote:
> when I rebuilt a plain 3.11-rc3 it didn't log anything via pstore either :-(
Well this turned out to be operator error on my part. 3.11-rc3 does in fact
log errors to pstore and allows them to be retrieved and cleared.
So then I start testing w
A quick experiment to use your patchset - but with compression
disabled by tweaking this line in pstore_dump():
zipped_len = -1; //zip_data(dst, hsize + len);
turned out well. This kernel dumps uncompressed dmesg blobs into pstore
and gets them back out again. So it seems likely that the pro
One more experiment - removed previous hack that disabled compression.
Added a new hack to skip decompression.
System died cleanly when I forced a panic.
On reboot I found 3 files in pstore:
-r--r--r-- 1 root root 3972 Aug 5 09:24 dmesg-erst-5908671953186586625
-r--r--r-- 1 root root 2565 Aug
See attachment for what I actually applied - I think I got what you
suggested (I added a declaration for "total_len").
Forcing a panic worked some things were logged to pstore.
But on reboot with your patches applied I'm still seeing a GP fault
when pstore is mounted and we find compressed record
This patch seems to fix the garbage at the end problem. Booting an
old kernel and using openssl decodes them OK.
Still have problems booting if there are any compressed images in ERST
to be inflated.
-Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lis
On Mon, Aug 5, 2013 at 2:20 PM, Tony Luck wrote:
> Still have problems booting if there are any compressed images in ERST
> to be inflated.
So I took another look at this part of the code ... and saw a couple of issues:
while ((size = psi->read(&id, &type, &a
On Tue, Aug 6, 2013 at 6:58 PM, Aruna Balakrishnaiah
wrote:
> The patch looks right. I will clean it up. Does the issue still persist
> after this?
Things seem to be working - but testing has hardly been extensive (just
a couple of forced panics).
I do have one other question. In this code:
>>
On Tue, Aug 6, 2013 at 10:13 PM, Aruna Balakrishnaiah
wrote:
> How is it with erst and efivars?
ERST is at the whim of the BIOS writer (the ACPI standard doesn't provide any
suggestions on record sizes). My systems support ~6K record size.
efivars has, IIRC, a 1k limit coded in the Linux back e
Oh - one more thing - and my apologies for not spotting this before:
dst = allocate_buf_for_compression(big_buf_sz);
No - you may not call kmalloc() in oops/panic context. Please pre-allocate
everything you need in some initialization code to make sure that we don't
fail in the p
On Tue, Aug 6, 2013 at 10:35 PM, Tony Luck wrote:
> ERST is at the whim of the BIOS writer (the ACPI standard doesn't provide any
> suggestions on record sizes). My systems support ~6K record size.
Off by a little - 7896 bytes on my current machine.
> efivars has, IIRC, a 1k limi
On Wed, Aug 7, 2013 at 9:29 PM, Aruna Balakrishnaiah
wrote:
> When we preallocate, we can use the same big_buf for compression as well as
> decompression.
> Also workspace will be one for both. By allocating max of inflate workspace
> size and deflate
> workspace size. We can save memory here.
We
On Sat, Aug 17, 2013 at 11:32 AM, Kees Cook wrote:
> Yeah, this is great. While I haven't tested it myself yet, the code
> seems to be in good shape. I acked the ram piece separately, but
> consider the entire series:
>
> Reviewed-by: Kees Cook
Applied. This should show up in linux-next tomorro
any errors
>> as below.
>>
>> Failed to find blacklist 000101316830
Yes please ... just found this problem on ia64 in mainline
and was happy to see this fix for it.
Tested-by: Tony Luck
-Tony
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
On Tue, Jul 8, 2014 at 5:07 AM, Masami Hiramatsu
wrote:
> Ping?
>
> This patch can be applied without 1/2, and will fix ia64/ppc64 problem.
Is somebody going to push this upstream? Another week has gone by,
we are at -rc5, and I'm still seeing the
Failed to find blacklist a0010133b150
mes
On Thu, Jan 23, 2020 at 10:03 AM Linus Torvalds
wrote:
> We used to have a read/write argument to the old "verify_area()" and
> "access_ok()" model, and it was a mistake. It was due to odd i386 user
> access issues. We got rid of it. I'm not convinced this is any better
> - it looks very similar a
On Fri, Jul 27, 2012 at 3:28 AM, Wen Congyang wrote:
> +static inline int pfns_present(unsigned long pfn, unsigned long nr_pages)
> +{
> + int i;
> + for (i = 0; i < nr_pages; i++) {
> + if (pfn_present(pfn + 1))
Typo? I think you meant "pfn + i"
> +
he libswiotlb
changes into their own piece (which would have some of the ia64 and x86 bits).
Or at the very least minimize the breakage window by putting ia64
right after x86
in the patch sequence.
Otherwise seems OK
Acked-by: Tony Luck
___
Linuxppc-dev
> But there seems to be another problem.
> Why is pt_regs of type void *?
>
> gcc complains:
> In file included from include/linux/fsnotify.h:15:0,
> from include/linux/security.h:26,
> from init/main.c:32:
> include/linux/audit.h: In function ‘audit_syscall_exit’:
>
the value signed consistently for the audit functions across all archs.
v2 builds and boots on ia64 now
Acked-by: Tony Luck
> Signed-off-by: Eric Paris
> Acked-by: Acked-by: H. Peter Anvin [for x86 portion]
:-)
-Tony
_
memory, the handler for this will call memory_failure(). This
isn't a 100% solution. If there are multiple errors, not all may be
logged in this way.
Signed-off-by: Tony Luck
---
Changes in V2:
Naoya Horiguchi:
1) Use -EHWPOISON error code instead of minus one.
2) Poison
On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
>
>
> 在 2022/10/20 AM1:08, Tony Luck 写道:
> > If the kernel is copying a page as the result of a copy-on-write
> > fault and runs into an uncorrectable error, Linux will crash because
> > it does not have recove
On Fri, Oct 21, 2022 at 09:52:01AM +0800, Shuai Xue wrote:
>
>
> 在 2022/10/21 AM4:05, Tony Luck 写道:
> > On Thu, Oct 20, 2022 at 09:57:04AM +0800, Shuai Xue wrote:
> >>
> >>
> >> 在 2022/10/20 AM1:08, Tony Luck 写道:
> > I'm experi
uc_decode_notifier() processes memory controller report
[ 1647.761313] MCE: Killing einj_mem_uc:3599 due to hardware memory corruption
fault at 7f3309503400
Parent process tries to read poisoned page. Page has been unmapped, so
#PF handler sends SIGBUS
Tony Luck (2):
mm, hwpoison: Try to
memory, the handler for this will call memory_failure(). This
isn't a 100% solution. If there are multiple errors, not all may be
logged in this way.
Reviewed-by: Dan Williams
Signed-off-by: Tony Luck
---
Changes in V3:
Dan Williams
Rename copy_user_highpage_mc
error.
Also provide a stub version for CONFIG_MEMORY_FAILURE=n
Signed-off-by: Tony Luck
---
include/linux/mm.h | 5 -
mm/memory.c| 4 +++-
2 files changed, 7 insertions(+), 2 deletions(-)
diff --git a/include/linux/mm.h b/include/linux/mm.h
index 8bbcccbc5565..03ced659eb58 100644
--- a
copy_mc_user_highpage() ... at least in the successful case where the
page was copied with no machine checks.
2) Picked up some additional Reviewed-by and Tested-by tags.
Tony Luck (2):
mm, hwpoison: Try to recover from copy-on write faults
mm, hwpoison: When copy-on-write hits poison, take page offline
memory, the handler for this will call memory_failure(). This
isn't a 100% solution. If there are multiple errors, not all may be
logged in this way.
Reviewed-by: Dan Williams
Reviewed-by: Miaohe Lin
Reviewed-by: Naoya Horiguchi
Tested-by: Shuai Xue
Signed-off-by: Tony Luck
Messa
error.
Also provide a stub version for CONFIG_MEMORY_FAILURE=n
Reviewed-by: Miaohe Lin
Tested-by: Shuai Xue
Signed-off-by: Tony Luck
Message-Id: <20221021200120.175753-3-tony.l...@intel.com>
Signed-off-by: Tony Luck
---
include/linux/mm.h | 5 -
mm/memory.c| 4 +++-
2 files c
t (or gotten a success
build report from zero-day)?
If you have ... then add an Acked-by: Tony Luck
-Tony
On Wed, Jan 25, 2017 at 11:15 AM, Hari Bathini
wrote:
> I haven't gotten a success/failure build report from zero-day. Not sure what
> to make of it.
zero-day is generally silent unless it sees a problem. So no news is good news.
> But I did try cross-compiling and it was successful. Should that
30 matches
Mail list logo
