BUG kmalloc-4096: Poison overwritten (2.6.35-rc2)
in [Kernel]
|
Prev: Trafik Karayolu Yönetmeliği,
Next: OMAP video compile error; regression from 2.6.33-rc4 onward (including current master)
From: Jiri Slaby on 6 Jun 2010 17:40 On 06/06/2010 11:06 PM, Justin P. Mattock wrote: > On 06/05/2010 11:27 PM, Jiri Slaby wrote: >> On 06/06/2010 08:12 AM, Justin P. Mattock wrote: >>> ============================================================================= >>> >>> >>> [ 0.002046] BUG kmalloc-4096: Poison overwritten >>> [ 0.002051] >>> ----------------------------------------------------------------------------- >>> >>> >>> [ 0.002052] >>> [ 0.002063] INFO: 0xffff88003ec09e00-0xffff88003ec09e9f. First byte >>> 0x20 instead of 0x6b >>> [ 0.002073] INFO: Slab 0xffffea0000dba1c0 objects=7 used=1 >>> fp=0xffff88003ec09048 flags=0x40000000000040c3 >>> [ 0.002082] INFO: Object 0xffff88003ec09048 @offset=4168 >>> fp=0xffff88003ec0a090 >>> [ 0.002083] >>> [ 0.002093] Bytes b4 0xffff88003ec09038: 00 00 00 00 00 00 00 00 5a >>> 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ >>> [ 0.002114] Object 0xffff88003ec09048: 6b 6b 6b 6b 6b 6b 6b 6b 6b >>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >> ... >>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >>> [ 0.002999] Object 0xffff88003ec09df8: 6b 6b 6b 6b 6b 6b 6b 6b 20 >>> 07 20 07 20 07 20 07 kkkkkkkk........ >>> [ 0.002999] Object 0xffff88003ec09e08: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e18: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e28: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e38: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e48: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e58: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e68: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e78: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e88: 20 07 20 07 20 07 20 07 20 >>> 07 20 07 20 07 20 07 ................ >>> [ 0.002999] Object 0xffff88003ec09e98: 20 07 20 07 20 07 20 07 6b >>> 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk >>> [ 0.002999] Object 0xffff88003ec09ea8: 6b 6b 6b 6b 6b 6b 6b 6b 6b >> >> Just guessing, grey spaces which should go to video ram? >> > > > o.k. I bisected this down to this commit: > 962400e8fd29 > reverting gets dmesg to not > have a Poison overwritten.. This definitely makes sense. > as for the screen blankness I think this > did cause it..keep in mind the blankness(black) > is not everytime(every so often) > here's some images of it: > http://www.flickr.com/photos/44066293(a)N08/4676350524/ > http://www.flickr.com/photos/44066293(a)N08/4676350016/ Yes, as I guessed, the "grey spaces" were written to some random space instead of video ram where they should overwrite (clear) the characters which you see on the pictures. Does the patch below help? --- drivers/char/vt.c | 4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/drivers/char/vt.c b/drivers/char/vt.c index 1296c42..e123958 100644 --- a/drivers/char/vt.c +++ b/drivers/char/vt.c @@ -304,8 +304,8 @@ static void scrup(struct vc_data *vc, unsigned int t, unsigned int b, int nr) d = (unsigned short *)(vc->vc_origin + vc->vc_size_row * t); s = (unsigned short *)(vc->vc_origin + vc->vc_size_row * (t + nr)); scr_memmovew(d, s, (b - t - nr) * vc->vc_size_row); - scr_memsetw(d + (b - t - nr) * vc->vc_size_row, vc->vc_video_erase_char, - vc->vc_size_row * nr); + scr_memsetw((void *)d + (b - t - nr) * vc->vc_size_row, + vc->vc_video_erase_char, vc->vc_size_row * nr); } static void scrdown(struct vc_data *vc, unsigned int t, unsigned int b, int nr) -- 1.7.1 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Justin P. Mattock on 6 Jun 2010 18:10 On 06/06/2010 02:33 PM, Jiri Slaby wrote: > On 06/06/2010 11:06 PM, Justin P. Mattock wrote: >> On 06/05/2010 11:27 PM, Jiri Slaby wrote: >>> On 06/06/2010 08:12 AM, Justin P. Mattock wrote: >>>> ============================================================================= >>>> >>>> >>>> [ 0.002046] BUG kmalloc-4096: Poison overwritten >>>> [ 0.002051] >>>> ----------------------------------------------------------------------------- >>>> >>>> >>>> [ 0.002052] >>>> [ 0.002063] INFO: 0xffff88003ec09e00-0xffff88003ec09e9f. First byte >>>> 0x20 instead of 0x6b >>>> [ 0.002073] INFO: Slab 0xffffea0000dba1c0 objects=7 used=1 >>>> fp=0xffff88003ec09048 flags=0x40000000000040c3 >>>> [ 0.002082] INFO: Object 0xffff88003ec09048 @offset=4168 >>>> fp=0xffff88003ec0a090 >>>> [ 0.002083] >>>> [ 0.002093] Bytes b4 0xffff88003ec09038: 00 00 00 00 00 00 00 00 5a >>>> 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ >>>> [ 0.002114] Object 0xffff88003ec09048: 6b 6b 6b 6b 6b 6b 6b 6b 6b >>>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >>> ... >>>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >>>> [ 0.002999] Object 0xffff88003ec09df8: 6b 6b 6b 6b 6b 6b 6b 6b 20 >>>> 07 20 07 20 07 20 07 kkkkkkkk........ >>>> [ 0.002999] Object 0xffff88003ec09e08: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e18: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e28: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e38: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e48: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e58: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e68: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e78: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e88: 20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ 0.002999] Object 0xffff88003ec09e98: 20 07 20 07 20 07 20 07 6b >>>> 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk >>>> [ 0.002999] Object 0xffff88003ec09ea8: 6b 6b 6b 6b 6b 6b 6b 6b 6b >>> >>> Just guessing, grey spaces which should go to video ram? >>> >> >> >> o.k. I bisected this down to this commit: >> 962400e8fd29 >> reverting gets dmesg to not >> have a Poison overwritten.. > > This definitely makes sense. > >> as for the screen blankness I think this >> did cause it..keep in mind the blankness(black) >> is not everytime(every so often) >> here's some images of it: >> http://www.flickr.com/photos/44066293(a)N08/4676350524/ >> http://www.flickr.com/photos/44066293(a)N08/4676350016/ > > Yes, as I guessed, the "grey spaces" were written to some random space > instead of video ram where they should overwrite (clear) the characters > which you see on the pictures. > > Does the patch below help? > > --- > drivers/char/vt.c | 4 ++-- > 1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/char/vt.c b/drivers/char/vt.c > index 1296c42..e123958 100644 > --- a/drivers/char/vt.c > +++ b/drivers/char/vt.c > @@ -304,8 +304,8 @@ static void scrup(struct vc_data *vc, unsigned int t, unsigned int b, int nr) > d = (unsigned short *)(vc->vc_origin + vc->vc_size_row * t); > s = (unsigned short *)(vc->vc_origin + vc->vc_size_row * (t + nr)); > scr_memmovew(d, s, (b - t - nr) * vc->vc_size_row); > - scr_memsetw(d + (b - t - nr) * vc->vc_size_row, vc->vc_video_erase_char, > - vc->vc_size_row * nr); > + scr_memsetw((void *)d + (b - t - nr) * vc->vc_size_row, > + vc->vc_video_erase_char, vc->vc_size_row * nr); > } > > static void scrdown(struct vc_data *vc, unsigned int t, unsigned int b, int nr) o.k. applied the above patch, and yes I dont see the Poison overwritten in dmesg, as well as the messages in the pics that I uploaded.. so I can say that the above fixes the issue (will monitor the system the remainder of the day to see if anything happens..) Reported-and-Bisected-By: Justin P. Mattock <justinmattock(a)gmail.com> cheers, Justin P. Mattock -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Frank Pan on 6 Jun 2010 22:20 > > Does the patch below help? > > --- > �drivers/char/vt.c | � �4 ++-- > �1 files changed, 2 insertions(+), 2 deletions(-) > > diff --git a/drivers/char/vt.c b/drivers/char/vt.c > index 1296c42..e123958 100644 > --- a/drivers/char/vt.c > +++ b/drivers/char/vt.c > @@ -304,8 +304,8 @@ static void scrup(struct vc_data *vc, unsigned int t, unsigned int b, int nr) > � � � �d = (unsigned short *)(vc->vc_origin + vc->vc_size_row * t); > � � � �s = (unsigned short *)(vc->vc_origin + vc->vc_size_row * (t + nr)); > � � � �scr_memmovew(d, s, (b - t - nr) * vc->vc_size_row); > - � � � scr_memsetw(d + (b - t - nr) * vc->vc_size_row, vc->vc_video_erase_char, > - � � � � � � � � � vc->vc_size_row * nr); > + � � � scr_memsetw((void *)d + (b - t - nr) * vc->vc_size_row, > + � � � � � � � � � � � vc->vc_video_erase_char, vc->vc_size_row * nr); > �} > > �static void scrdown(struct vc_data *vc, unsigned int t, unsigned int b, int nr) > -- > 1.7.1 > > > This patch fixed the issue. That's my mistake, forgot d's type. Sorry for that. -- Frank Pan Computer Science and Technology Tsinghua University -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Dave Airlie on 6 Jun 2010 23:30 On Mon, Jun 7, 2010 at 7:33 AM, Jiri Slaby <jslaby(a)suse.cz> wrote: > On 06/06/2010 11:06 PM, Justin P. Mattock wrote: >> On 06/05/2010 11:27 PM, Jiri Slaby wrote: >>> On 06/06/2010 08:12 AM, Justin P. Mattock wrote: >>>> ============================================================================= >>>> >>>> >>>> [ � �0.002046] BUG kmalloc-4096: Poison overwritten >>>> [ � �0.002051] >>>> ----------------------------------------------------------------------------- >>>> >>>> >>>> [ � �0.002052] >>>> [ � �0.002063] INFO: 0xffff88003ec09e00-0xffff88003ec09e9f. First byte >>>> 0x20 instead of 0x6b >>>> [ � �0.002073] INFO: Slab 0xffffea0000dba1c0 objects=7 used=1 >>>> fp=0xffff88003ec09048 flags=0x40000000000040c3 >>>> [ � �0.002082] INFO: Object 0xffff88003ec09048 @offset=4168 >>>> fp=0xffff88003ec0a090 >>>> [ � �0.002083] >>>> [ � �0.002093] Bytes b4 0xffff88003ec09038: �00 00 00 00 00 00 00 00 5a >>>> 5a 5a 5a 5a 5a 5a 5a ........ZZZZZZZZ >>>> [ � �0.002114] � Object 0xffff88003ec09048: �6b 6b 6b 6b 6b 6b 6b 6b 6b >>>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >>> ... >>>> 6b 6b 6b 6b 6b 6b 6b kkkkkkkkkkkkkkkk >>>> [ � �0.002999] � Object 0xffff88003ec09df8: �6b 6b 6b 6b 6b 6b 6b 6b 20 >>>> 07 20 07 20 07 20 07 kkkkkkkk........ >>>> [ � �0.002999] � Object 0xffff88003ec09e08: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e18: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e28: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e38: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e48: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e58: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e68: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e78: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e88: �20 07 20 07 20 07 20 07 20 >>>> 07 20 07 20 07 20 07 ................ >>>> [ � �0.002999] � Object 0xffff88003ec09e98: �20 07 20 07 20 07 20 07 6b >>>> 6b 6b 6b 6b 6b 6b 6b ........kkkkkkkk >>>> [ � �0.002999] � Object 0xffff88003ec09ea8: �6b 6b 6b 6b 6b 6b 6b 6b 6b >>> >>> Just guessing, grey spaces which should go to video ram? >>> >> >> >> o.k. I bisected this down to this commit: >> 962400e8fd29 >> reverting gets dmesg to not >> have a Poison overwritten.. > > This definitely makes sense. > >> as for the screen blankness I think this >> did cause it..keep in mind the blankness(black) >> is not everytime(every so often) >> here's some images of it: >> http://www.flickr.com/photos/44066293(a)N08/4676350524/ >> http://www.flickr.com/photos/44066293(a)N08/4676350016/ > > Yes, as I guessed, the "grey spaces" were written to some random space > instead of video ram where they should overwrite (clear) the characters > which you see on the pictures. > > Does the patch below help? > This helps a lot of issues on KMS systems,. can you get it to Linus? Acked-by: Dave Airlie <airlied(a)redhat.com> Dave. -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on 7 Jun 2010 00:10
On Mon, 7 Jun 2010, Dave Airlie wrote: > > This helps a lot of issues on KMS systems,. can you get it to Linus? Found this thread while following another thread. There were at least three different threads about the same issue, all looking at bug in different areas (ext4 too). I reverted the original commit, and pushed out. Linus -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo(a)vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/ |