RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
> But let's make sure that efivars, erst, > etc. are all happy with the changes we make before I ask Linus to pull another > pstore piece. I will test efivars when Aruna posts the bugfix patches. Seiji > -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Wednesday, September 04, 2013 12:11 PM > To: Aruna Balakrishnaiah; Seiji Aguchi > Cc: jkeni...@linux.vnet.ibm.com; keesc...@chromium.org; > mah...@linux.vnet.ibm.com; ccr...@android.com; linux- > ker...@vger.kernel.org; linuxppc-...@ozlabs.org; cbouatmai...@gmail.com > Subject: RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore > > > The reason behind compression failure is the size of big_oops_buf which is > > too > > big for efivars case. I will do some experiments with different kind of > > texts > > for buffer size 1024 to check if 100/53 suits for all the cases. > ... > > > Yes this can be changed to zlib_inflateInit2(). > > Original patch series was just pulled by Linus ... so we'll need a patch on > top > of current Linus git tree to fix these issues. But let's make sure that > efivars, erst, > etc. are all happy with the changes we make before I ask Linus to pull another > pstore piece. > > Thanks > > -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
> The reason behind compression failure is the size of big_oops_buf which is too > big for efivars case. I will do some experiments with different kind of texts > for buffer size 1024 to check if 100/53 suits for all the cases. ... > Yes this can be changed to zlib_inflateInit2(). Original patch series was just pulled by Linus ... so we'll need a patch on top of current Linus git tree to fix these issues. But let's make sure that efivars, erst, etc. are all happy with the changes we make before I ask Linus to pull another pstore piece. Thanks -Tony -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
On Wednesday 04 September 2013 07:14 AM, Seiji Aguchi wrote: Aruna, Sorry for the late response. Seiji, Could you let us know the efivars buffer size with which the pstore is registered when the failure occurred. I looked into the issue today. I added some debug message just before pstore_compress(). As you can see below, the buffer size is a fixed value(1024). Therefore, the size doesn't seem to be related to the failure directly. Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero. So, I thought big_oops_buf_sz is too big in my environment. And then, I tuned big_oops_buf_sz to (psinfo->bufsize * 100) / 53. Seiji, Thank you for the analysis. The reason behind compression failure is the size of big_oops_buf which is too big for efivars case. I will do some experiments with different kind of texts for buffer size 1024 to check if 100/53 suits for all the cases. At the same time, while looking into this issue, I had two concerns about current cording. 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()? If you use zlib_deflateInit2() for specifying window_bit at compressing time, zlib_inflateInit2() seems to be appropriate for decompressing. (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c) Yes this can be changed to zlib_inflateInit2(). 2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the beginning of compressing/decompressing time. So, in pstore case, stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress(). Hmm.. I don't think this is a issue. If you see fs/logfs/compr.c from which I derived the compression algorithms for pstore as well, they have not initialized stream.workspace. Since the space will be overwritten during the calculation, I dont think it will matter. The above 2 things you have suggested are good to have. But the reason behind compression failure is the big_oops_buf_sz which is too big for efivars. I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment. As a result, compressions/decmpressions of all entries succeeded with efivars driver. Panic#2 Part1 <4>[ 75.665020] [] SyS_write+0x4c/0xa0 <4>[ 75.665020] [] system_call_fastpath+0x16/0x1b <4>[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e <1>[ 75.665020] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 75.665020] RSP <4>[ 75.665020] CR2: <4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]--- <3>[ 75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 2 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 5 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5 <3>[ 75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 9 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9 <3>[ 75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo->bufsize=1024 <0>[ 75.665020] Kernel panic - not syncing: Fatal exception <3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text console Seiji ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
Aruna, Sorry for the late response. > Seiji, > > Could you let us know the efivars buffer size with which the pstore is > registered when > the failure occurred. I looked into the issue today. I added some debug message just before pstore_compress(). As you can see below, the buffer size is a fixed value(1024). Therefore, the size doesn't seem to be related to the failure directly. Also, in the failure case, zlib_deflate() returns Z_OK and stream.avail_out is zero. So, I thought big_oops_buf_sz is too big in my environment. And then, I tuned big_oops_buf_sz to (psinfo->bufsize * 100) / 53. At the same time, while looking into this issue, I had two concerns about current cording. 1) In pstore_decompress(), why not use zlib_inflateInit2() instead of zlib_inflateInit()? If you use zlib_deflateInit2() for specifying window_bit at compressing time, zlib_inflateInit2() seems to be appropriate for decompressing. (Please see a comment about inflateInit2() in include/linux/zlib.h and source code of crypto/deflate.c) 2) As looking at crypto/deflate.c, stream->workspace is kzalloced at the beginning of compressing/decompressing time. So, in pstore case, stream.workspace must be initialized to 0 with memset() in pstore_compress()/decompress(). I did three things above, tuning big_oops_buf_sz, using zlib_inflateInit2() and initializing stream.workspace , in my environment. As a result, compressions/decmpressions of all entries succeeded with efivars driver. Panic#2 Part1 <4>[ 75.665020] [] SyS_write+0x4c/0xa0 <4>[ 75.665020] [] system_call_fastpath+0x16/0x1b <4>[ 75.665020] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00 0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8 04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e <1>[ 75.665020] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 75.665020] RSP <4>[ 75.665020] CR2: <4>[ 75.665020] ---[ end trace 97bb4a1f8d3fe7b2 ]--- <3>[ 75.665020] pstore_dump hsize=13 len=2155 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2246 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 2 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 75.665020] pstore_dump hsize=13 len=2239 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2231 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2185 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 5 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 5 <3>[ 75.665020] pstore_dump hsize=13 len=2234 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2208 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len=2218 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=13 len= big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore: compression failed for Part 9 returned -5 <3>[ 75.665020] pstore: Capture uncompressed oops/panic report of Part 9 <3>[ 75.665020] pstore_dump hsize=14 len=2256 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2219 big_oops_buf_sz=2275 psinfo->bufsize=1024 <3>[ 75.665020] pstore_dump hsize=14 len=2226 big_oops_buf_sz=2275 psinfo->bufsize=1024 <0>[ 75.665020] Kernel panic - not syncing: Fatal exception <3>[ 75.665020] drm_kms_helper: panic occurred, switching back to text console Seiji -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
On Friday 23 August 2013 04:47 AM, Luck, Tony wrote: <1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 383.209057] RSP <4>[ 383.209057] CR2: <4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]--- <3>[ 383.209057] pstore: compression failed for Part 2 returned -5 <3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 383.209057] pstore: compression failed for Part 5 returned -5 Interesting. With ERST backend I didn't see these messages. Traces in pstore recovered files go as far as the line before the "---[ end trace 04a1cddad37b4b33 ]---" Why the difference depending on which back end is in use? But I agree that we shouldn't have these messages. They use up space in the persistent store that could be better used saving some more lines from earlier in the console log. Yeah. We can remove these messages as it will add to the space consumed. But it would be good to know why the compression failed with efivars case. Seiji, Could you let us know the efivars buffer size with which the pstore is registered when the failure occurred. Regards, Aruna -Tony ___ Linuxppc-dev mailing list linuxppc-...@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
> -Original Message- > From: Luck, Tony [mailto:tony.l...@intel.com] > Sent: Thursday, August 22, 2013 7:17 PM > To: Seiji Aguchi; Aruna Balakrishnaiah; linuxppc-...@ozlabs.org; > linux-kernel@vger.kernel.org; keesc...@chromium.org > Cc: jkeni...@linux.vnet.ibm.com; ana...@in.ibm.com; b...@kernel.crashing.org; > cbouatmai...@gmail.com; > mah...@linux.vnet.ibm.com; ccr...@android.com > Subject: RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore > > <1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20 > <4>[ 383.209057] RSP > <4>[ 383.209057] CR2: > <4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]--- > <3>[ 383.209057] pstore: compression failed for Part 2 returned -5 > <3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2 > <3>[ 383.209057] pstore: compression failed for Part 5 returned -5 > > Interesting. With ERST backend I didn't see these messages. Traces in > pstore recovered files go as far as the line before the "---[ end trace > 04a1cddad37b4b33 ]---" > > Why the difference depending on which back end is in use? I think the difference doesn't depend on the back end. Rather it depends on the environment. I tested on a kvm guest with OVMF. Seiji > > But I agree that we shouldn't have these messages. They use up space > in the persistent store that could be better used saving some more lines > from earlier in the console log. > > -Tony
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
<1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20 <4>[ 383.209057] RSP <4>[ 383.209057] CR2: <4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]--- <3>[ 383.209057] pstore: compression failed for Part 2 returned -5 <3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2 <3>[ 383.209057] pstore: compression failed for Part 5 returned -5 Interesting. With ERST backend I didn't see these messages. Traces in pstore recovered files go as far as the line before the "---[ end trace 04a1cddad37b4b33 ]---" Why the difference depending on which back end is in use? But I agree that we shouldn't have these messages. They use up space in the persistent store that could be better used saving some more lines from earlier in the console log. -Tony
RE: [RFC PATCH v2 04/11] pstore: Add compression support to pstore
> * callback from kmsg_dump. (s2,l2) has the most recently
> * written bytes, older bytes are in (s1,l1). Save as much
> @@ -148,23 +243,56 @@ static void pstore_dump(struct kmsg_dumper *dumper,
> char *dst;
> unsigned long size;
> int hsize;
> + int zipped_len = -1;
> size_t len;
> - bool compressed = false;
> + bool compressed;
> + size_t total_len;
>
> - dst = psinfo->buf;
> - hsize = sprintf(dst, "%s#%d Part%d\n", why, oopscount, part);
> - size = psinfo->bufsize - hsize;
> - dst += hsize;
> + if (big_oops_buf) {
> + dst = big_oops_buf;
> + hsize = sprintf(dst, "%s#%d Part%d\n", why,
> + oopscount, part);
> + size = big_oops_buf_sz - hsize;
>
> - if (!kmsg_dump_get_buffer(dumper, true, dst, size, &len))
> - break;
> + if (!kmsg_dump_get_buffer(dumper, true, dst + hsize,
> + size, &len))
> + break;
> +
> + zipped_len = pstore_compress(dst, psinfo->buf,
> + hsize + len, psinfo->bufsize);
> +
> + if (zipped_len > 0) {
> + compressed = true;
> + total_len = zipped_len;
> + } else {
> + pr_err("pstore: compression failed for Part %d"
> + " returned %d\n", part, zipped_len);
> + pr_err("pstore: Capture uncompressed"
> + " oops/panic report of Part %d\n",
> part);
Why did you add these messages in pstore_dump()?
In my test case, they are not needed
# cat dmesg-efi-1
Panic#2 Part1
<4>[ 383.209057] RBP: 88006f551e80 R08: 0002 R09:
<4>[ 383.209057] R10: 0382 R11: R12:
0063
<4>[ 383.209057] R13: 0286 R14: 000f R15:
<4>[ 383.209057] FS: 7f53317cc740() GS:88007c40()
knlGS:
<4>[ 383.209057] CS: 0010 DS: ES: CR0: 80050033
<4>[ 383.209057] CR2: CR3: 78a73000 CR4:
06f0
<4>[ 383.209057] Stack:
<4>[ 383.209057] 88006f551eb8 813d40a2 0002
7f53317db000
<4>[ 383.209057] 88006f551f50 0002
88006f551ed8
<4>[ 383.209057] 813d45aa 7f53317db000 88003f8c2b00
88006f551ef8
<4>[ 383.209057] Call Trace:
<4>[ 383.209057] [] __handle_sysrq+0xa2/0x170
<4>[ 383.209057] [] write_sysrq_trigger+0x4a/0x50
<4>[ 383.209057] [] proc_reg_write+0x3d/0x80
<4>[ 383.209057] [] vfs_write+0xc0/0x1f0
<4>[ 383.209057] [] SyS_write+0x4c/0xa0
<4>[ 383.209057] [] system_call_fastpath+0x16/0x1b
<4>[ 383.209057] Code: ef e8 ff f7 ff ff eb d8 66 2e 0f 1f 84 00 00 00 00 00
0f 1f 00 0f 1f 44 00 00 55 c7 05 cc f3 c9 00 01 00 00 00 48 89 e5 0f ae f8
04 25 00 00 00 00 01 5d c3 0f 1f 44 00 00 55 31 c0 c7 05 5e
<1>[ 383.209057] RIP [] sysrq_handle_crash+0x16/0x20
<4>[ 383.209057] RSP
<4>[ 383.209057] CR2:
<4>[ 383.209057] ---[ end trace 04a1cddad37b4b33 ]---
<3>[ 383.209057] pstore: compression failed for Part 2 returned -5
<3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 2
<3>[ 383.209057] pstore: compression failed for Part 5 returned -5
<3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 5
<3>[ 383.209057] pstore: compression failed for Part 12 returned -5
<3>[ 383.209057] pstore: Capture uncompressed oops/panic report of Part 12
<0>[ 383.209057] Kernel panic - not syncing: Fatal exception
<3>[ 383.209057] drm_kms_helper: panic occurred, switching back to text console
In efi-pstore case, after rebooting a system,
we are able to know which entry failed to compress with 'C' or 'D' as below.
#ls /sys/firmware/efi/vars/ |grep dump
dump-type0-10-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-10-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-11-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-12-1-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-1-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-12-2-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-13-1-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-13-2-1377204734-C-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-1-1377204734-D-cfc8fc79-be2e-4ddc-97f0-9f98bfe298a0
dump-type0-2-2-1377
