On 1/9/06, Hugh Dickins <[email protected]> wrote:
> On Mon, 9 Jan 2006, Jesper Juhl wrote:
> > On 1/9/06, Dave Jones <[email protected]> wrote:
> > > On Mon, Jan 09, 2006 at 06:47:01PM +0100, Jesper Juhl wrote:
> > >
> > > > Here's what bad_page printed for me :
> > > >
> > > > Bad page state in process 'kded'
> > > > [<c0103e77>] dump_stack+0x17/0x20
> > > > [<c0148999>] bad_page+0x69/0x160
> > >
> > > Odd, there should be more state between the 'Bad page'
> > > and the backtrace.
> > >
> > > printk(KERN_EMERG "Bad page state in process '%s'\n"
> > > "page:%p flags:0x%0*lx mapping:%p mapcount:%d count:%d\n"
> > > "Trying to fix it up, but a reboot is needed\n"
> > >
> > > Did you aggressively trim that, or did it for some
> > > reason not get printed ?
> > >
> >
> > I did not trim that.
> >
> > All I did was add
> >
> > printk(KERN_EMERG "we hit bad page, looping forever\n");
> > while (1) {
> > mdelay(1000);
> > }
> >
> > to the end of bad_page()
>
> I'm afraid someone has recently "tidied up" bad_page, and missed out
> the most interesting KERN_EMERG of all. No promises that this will
> actually help us more than the backtrace you've sent, but please give
> it another go with patch below applied. Andrew, please pass along...
>
>
> Restore KERN_EMERG to each line printed by bad_page.
>
Ok, with that patch the page, flags, mapping, mapcount & count
information prints again.
I get the exact same backtrace as before though, but a slightly
different hexdump :
Bad page state in process 'kded'
page:c1e75400 flags:0x00000000 mapping:00000000 mapcount:1 count:0
Trying to fix it up, but a reboot is needed
Backtrace:
[<c0103e77>] dump_stack+0x17/0x20
[<c0148999>] bad_page+0x69/0x160
[<c0148e92>] __free_pages_ok+0xa2/0x120
[<c0149c7f>] __free_pages+0x2f/0x60
[<c02acb63>] sg_page_free+0x23/0x30
[<c02abdb3>] sg_remove_scat+0x63/0xe0
[<c02ac80d>] __sg_remove_sfp+0x4d/0xc0
[<c02ac927>] sg_remove_sfp+0xa7/0x120
[<c02a8b39>] sg_release+0x49/0xc0
[<c0166827>] __fput+0x167/0x1b0
[<c01666ab>] fput+0x3b/0x50
[<c0164efc>] filp_close+0x3c/0x80
[<c0164fa9>] sys_close+0x69/0x90
[<c0103009>] syscall_call+0x7/0xb
Hexdump:
000: ff ff ff ff 00 00 00 00 00 00 00 00 00 00 00 00
010: d0 53 e7 c1 d0 53 e7 c1 ff ff ff ff 00 00 00 00
020: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
030: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
040: 00 00 00 00 ff ff ff ff 00 00 00 00 00 00 00 00
050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
070: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
080: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
090: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0a0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
0b0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
One more note: the first time I booted the kernel with this patch X
failed to start. It started and blacked out the screen, at that point
the system hung, but not completely, I could still switch tty with
ctrl+alt+f? but all tty's I switched to were also completely black
with just a cursor in the top left corner. The system never recovered
from this state and I was forced to press the reset button.
The second time it booted up fine and launched kdm as usual to let me
log in and upon logging in it crashed as expected while launching KDE
(at that point I had switched over to tty1 and captured the crash dump
you see above).
So, it seems to me that we may have more than one bug.
--
Jesper Juhl <[email protected]>
Don't top-post http://www.catb.org/~esr/jargon/html/T/top-post.html
Plain text mails only, please http://www.expita.com/nomime.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
