On Thursday 08 August 2013 09:38 AM, Aruna Balakrishnaiah wrote:
Hi Tony,
On Thursday 08 August 2013 03:52 AM, Tony Luck wrote:
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 sys
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 Wednesday 07 August 2013 11:00 PM, Tony Luck wrote:
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 in
Hi Tony,
On Thursday 08 August 2013 03:52 AM, Tony Luck wrote:
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
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 limit coded in the
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: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
Hi Tony,
On Wednesday 07 August 2013 08:55 AM, Tony Luck wrote:
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 f
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 Wednesday 07 August 2013 05:06 AM, Tony Luck wrote:
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
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, &count, &time, &buf, &compresse
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
Hi Tony,
On Monday 05 August 2013 11:52 PM, Tony Luck wrote:
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
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
Hi Tony,
Thank you very much for testing my patches.
On Saturday 03 August 2013 03:42 AM, Tony Luck wrote:
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
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
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
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
> Could you please review and let me know your comments!!
Skimmed through it today and didn't notice anything I hated. It built fine -
but doesn't seem to be working on top of ERST. This doesn't seem to be your
fault though, when I rebuilt a plain 3.11-rc3 it didn't log anything via pstore
Hi Tony/Kees,
Could you please review and let me know your comments!!
Regards,
Aruna
On Monday 15 July 2013 10:25 PM, Aruna Balakrishnaiah wrote:
The patchset adds compression support to pstore.
As the non-volatile storage space is limited, adding compression
support results in capturing
The patchset adds compression support to pstore.
As the non-volatile storage space is limited, adding compression
support results in capturing more data within limited space.
Size of dmesg file in a powerpc/pseries box with nvram's
oops partition (to store oops-log) size 4k:
Without compression:
21 matches
Mail list logo
