unable to handle kernel paging request

unable to handle kernel paging request

[Dennis Grevenstein]

Hi,

I want to get the current cvs kernel running on
an R5000PC Challenge S. It does compile, but the
kernel does not boot. I get this error repeatedly
printed all over the console until I pull the plug:

<1>CPU 0 Unable to handle kernel paging request at\
 virtual address 00000000, epc == 8810da1c, ra == 8810e22c

What could be wrong?

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 878 bytes --]

On Sun, 2004-10-31 19:42:33 +0100, Dennis Grevenstein <dennis@pcde.inka.de>
wrote in message <20041031184233.GA11120@aton.pcde.inka.de>:
> I want to get the current cvs kernel running on
> an R5000PC Challenge S. It does compile, but the
> kernel does not boot. I get this error repeatedly
> printed all over the console until I pull the plug:
> 
> <1>CPU 0 Unable to handle kernel paging request at\
>  virtual address 00000000, epc == 8810da1c, ra == 8810e22c

Look into your System.map what's at 0x8810da1c and 0x8810e22c

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: unable to handle kernel paging request

[Dennis Grevenstein]

On Sun, Oct 31, 2004 at 07:48:15PM +0100, Stanislaw Skowronek wrote:
> > <1>CPU 0 Unable to handle kernel paging request at\
> >  virtual address 00000000, epc == 8810da1c, ra == 8810e22c
> 
> Look into your System.map and tell us what is there.
 
At 8810da1c or 8810e22c? Nothing directly.
Closest thing is this:

8810d9b0 t ip22zilog_maybe_update_regs
8810d9fc t ip22zilog_receive_chars
8810dd18 t ip22zilog_status_handle
8810def0 t ip22zilog_transmit_chars
8810e0e0 t ip22zilog_interrupt
8810e26c t ip22zilog_tx_empty
8810e2e4 t ip22zilog_get_mctrl
8810e378 t ip22zilog_set_mctrl  
8810e3e0 t ip22zilog_stop_tx   
8810e3f0 t ip22zilog_start_tx
8810e508 t ip22zilog_stop_rx     
8810e544 t ip22zilog_enable_ms
8810e580 t ip22zilog_break_ctl
8810e628 t __ip22zilog_startup

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1650 bytes --]

On Sun, 2004-10-31 20:16:31 +0100, Dennis Grevenstein <dennis@pcde.inka.de>
wrote in message <20041031191631.GB11681@aton.pcde.inka.de>:
> On Sun, Oct 31, 2004 at 07:48:15PM +0100, Stanislaw Skowronek wrote:
> > > <1>CPU 0 Unable to handle kernel paging request at\
> > >  virtual address 00000000, epc == 8810da1c, ra == 8810e22c
> > 
> > Look into your System.map and tell us what is there.
>  
> At 8810da1c or 8810e22c? Nothing directly.
> Closest thing is this:

System.map is a list of function start addresses. Typically, functions
don't crash at their very first instructions, this is why you don't see
"exact" matches.

> 8810d9b0 t ip22zilog_maybe_update_regs
> 8810d9fc t ip22zilog_receive_chars
This is epc (+0x20).

> 8810dd18 t ip22zilog_status_handle
> 8810def0 t ip22zilog_transmit_chars
> 8810e0e0 t ip22zilog_interrupt
...and this is ra.

> 8810e26c t ip22zilog_tx_empty

>From my fading MIPS knowledge, ip22zilog_interrupt called
ip22zilog_receive_chars and the later one crashed. Now, use objdump and
create a disassembly dump of the object file that contains the IP22
Zilog stuff. There, find the part that's 0x20 bytes away from the start
of ip22zilog_receive_chars. Now you know the cause of this oops. From
here, try to figure out the reason for it...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: unable to handle kernel paging request

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 1649 bytes --]

On Sun, 2004-10-31 20:16:31 +0100, Dennis Grevenstein <dennis@pcde.inka.de>
wrote in message <20041031191631.GB11681@aton.pcde.inka.de>:
> On Sun, Oct 31, 2004 at 07:48:15PM +0100, Stanislaw Skowronek wrote:
> > > <1>CPU 0 Unable to handle kernel paging request at\
> > >  virtual address 00000000, epc == 8810da1c, ra == 8810e22c
> > 
> > Look into your System.map and tell us what is there.
>  
> At 8810da1c or 8810e22c? Nothing directly.
> Closest thing is this:

System.map is a list of function start addresses. Typically, functions
don't crash at their very first instructions, this is why you don't see
"exact" matches.

> 8810d9b0 t ip22zilog_maybe_update_regs
> 8810d9fc t ip22zilog_receive_chars
This is epc (+0x20).

> 8810dd18 t ip22zilog_status_handle
> 8810def0 t ip22zilog_transmit_chars
> 8810e0e0 t ip22zilog_interrupt
...and this is ra.

> 8810e26c t ip22zilog_tx_empty

From my fading MIPS knowledge, ip22zilog_interrupt called
ip22zilog_receive_chars and the later one crashed. Now, use objdump and
create a disassembly dump of the object file that contains the IP22
Zilog stuff. There, find the part that's 0x20 bytes away from the start
of ip22zilog_receive_chars. Now you know the cause of this oops. From
here, try to figure out the reason for it...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: unable to handle kernel paging request

[Dennis Grevenstein]

On Sun, Oct 31, 2004 at 08:26:53PM +0100, Jan-Benedict Glaw wrote:

> System.map is a list of function start addresses. Typically, functions
> don't crash at their very first instructions, this is why you don't see
> "exact" matches.

okay.
 
> From my fading MIPS knowledge, ip22zilog_interrupt called
> ip22zilog_receive_chars and the later one crashed. Now, use objdump and
> create a disassembly dump of the object file that contains the IP22
> Zilog stuff. There, find the part that's 0x20 bytes away from the start
> of ip22zilog_receive_chars. Now you know the cause of this oops.

That's what I found:

8810da14:       8c82001c        lw      v0,28(a0)
8810da18:       00809021        move    s2,a0
8810da1c:       8c510000        lw      s1,0(v0)
8810da20:       00a09821        move    s3,a1   
8810da24:       8e220118        lw      v0,280(s1) 

and:

8810e224:       0e04367f        jal     8810d9fc <ip22zilog_receive_chars>
8810e228:       02803021        move    a2,s4
8810e22c:       0a04386e        j       8810e1b8 <ip22zilog_interrupt+0xd8>
8810e230:       32020001        andi    v0,s0,0x1   
8810e234:       0e0437bc        jal     8810def0 <ip22zilog_transmit_chars>

> From
> here, try to figure out the reason for it...
 
Well, I'm sure "MIPS assembly for Dummies" must be available
somewhere. While I keep looking please help me ;-)

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Jan-Benedict Glaw]

[-- Attachment #1: Type: text/plain, Size: 2312 bytes --]

On Sun, 2004-10-31 20:55:50 +0100, Dennis Grevenstein <dennis@pcde.inka.de>
wrote in message <20041031195550.GA12397@aton.pcde.inka.de>:
> On Sun, Oct 31, 2004 at 08:26:53PM +0100, Jan-Benedict Glaw wrote:
> > From my fading MIPS knowledge, ip22zilog_interrupt called
> > ip22zilog_receive_chars and the later one crashed. Now, use objdump and
> > create a disassembly dump of the object file that contains the IP22
> > Zilog stuff. There, find the part that's 0x20 bytes away from the start
> > of ip22zilog_receive_chars. Now you know the cause of this oops.
> 
> That's what I found:


> 8810da14:       8c82001c        lw      v0,28(a0)
> 8810da18:       00809021        move    s2,a0
> 8810da1c:       8c510000        lw      s1,0(v0)

It's accessing (most probably) a structure's first field, where the
structure is supplied by pointer in v0.

> 8810da20:       00a09821        move    s3,a1   
> 8810da24:       8e220118        lw      v0,280(s1) 

So now, find out what v0 belongs to. Maybe compiling the kernel with
debug infos (-g) and using objdump -S (for intermixing sources) will
help you.

Most probably, something wasn't correctly registered, so the pointer to
a struct is just a NULL pointer.

> and:
> 
> 8810e224:       0e04367f        jal     8810d9fc <ip22zilog_receive_chars>
> 8810e228:       02803021        move    a2,s4
> 8810e22c:       0a04386e        j       8810e1b8 <ip22zilog_interrupt+0xd8>
> 8810e230:       32020001        andi    v0,s0,0x1   
> 8810e234:       0e0437bc        jal     8810def0 <ip22zilog_transmit_chars>

So this all fits properly :-)

> > From
> > here, try to figure out the reason for it...
>  
> Well, I'm sure "MIPS assembly for Dummies" must be available
> somewhere. While I keep looking please help me ;-)

"objdump -S" for starters, but it seems quite straight forward. Maybe
paste the code of ip22zilog_receive_chars, I don't  have that at hands
right now...

MfG, JBG

-- 
Jan-Benedict Glaw       jbglaw@lug-owl.de    . +49-172-7608481             _ O _
"Eine Freie Meinung in  einem Freien Kopf    | Gegen Zensur | Gegen Krieg  _ _ O
 fuer einen Freien Staat voll Freier Bürger" | im Internet! |   im Irak!   O O O
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: unable to handle kernel paging request

[Dennis Grevenstein]

On Sun, Oct 31, 2004 at 09:13:35PM +0100, Jan-Benedict Glaw wrote:
> 
> So now, find out what v0 belongs to. Maybe compiling the kernel with
> debug infos (-g) and using objdump -S (for intermixing sources) will
> help you.

recompiling the kernel will take another few hours, but
I may try later. Using "objdump -S" I don't get any more info.

Building a kernel without the driver for the serial port 
seems not so good for a Challenge S.
 
> "objdump -S" for starters, but it seems quite straight forward. Maybe
> paste the code of ip22zilog_receive_chars, I don't  have that at hands
> right now...
 
Okay, here it is:

static void ip22zilog_receive_chars(struct uart_ip22zilog_port *up,
                                   struct zilog_channel *channel,
                                   struct pt_regs *regs)
{
        struct tty_struct *tty = up->port.info->tty;    /* XXX info==NULL? */

        while (1) {
                unsigned char ch, r1;

                if (unlikely(tty->flip.count >= TTY_FLIPBUF_SIZE)) {
                        tty->flip.work.func((void *)tty);
                        if (tty->flip.count >= TTY_FLIPBUF_SIZE)
                                return;         /* XXX Ignores SysRq when we nee
d it most. Fix. */
                }

                r1 = read_zsreg(channel, R1);
                if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) {
                        writeb(ERR_RES, &channel->control);
                        ZSDELAY();
                        ZS_WSYNC(channel);
                }

                ch = readb(&channel->control);
                ZSDELAY();

                /* This funny hack depends upon BRK_ABRT not interfering
                 * with the other bits we care about in R1.
                 */
                if (ch & BRK_ABRT)
                        r1 |= BRK_ABRT;

                ch = readb(&channel->data);
                ZSDELAY();

                ch &= up->parity_mask;

                if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) {
                        /* Wait for BREAK to deassert to avoid potentially
                         * confusing the PROM.
                         */
                        while (1) {
                                ch = readb(&channel->control);
                                ZSDELAY();
                                if (!(ch & BRK_ABRT))
                                        break;
                        }
                        ip22_do_break();
                        return;
                }

                /* A real serial line, record the character and status.  */
                *tty->flip.char_buf_ptr = ch;
                *tty->flip.flag_buf_ptr = TTY_NORMAL;
                up->port.icount.rx++;
                if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) {
                        if (r1 & BRK_ABRT) {
                                r1 &= ~(PAR_ERR | CRC_ERR);
                                up->port.icount.brk++;
                                if (uart_handle_break(&up->port))
                                        goto next_char;
                        }
                        else if (r1 & PAR_ERR)
                                up->port.icount.parity++;
                        else if (r1 & CRC_ERR)
                                up->port.icount.frame++;
                        if (r1 & Rx_OVR)
                                up->port.icount.overrun++;
                        r1 &= up->port.read_status_mask;
                        if (r1 & BRK_ABRT)
                                *tty->flip.flag_buf_ptr = TTY_BREAK;
                        else if (r1 & PAR_ERR)
                                *tty->flip.flag_buf_ptr = TTY_PARITY;
                        else if (r1 & CRC_ERR)
                                *tty->flip.flag_buf_ptr = TTY_FRAME;
                }
                if (uart_handle_sysrq_char(&up->port, ch, regs))
                        goto next_char;

                if (up->port.ignore_status_mask == 0xff ||
                    (r1 & up->port.ignore_status_mask) == 0) {
                        tty->flip.flag_buf_ptr++;
                        tty->flip.char_buf_ptr++;
                        tty->flip.count++;
                }
                if ((r1 & Rx_OVR) &&
                    tty->flip.count < TTY_FLIPBUF_SIZE) {
                        *tty->flip.flag_buf_ptr = TTY_OVERRUN;
                        tty->flip.flag_buf_ptr++;
                        tty->flip.char_buf_ptr++;
                        tty->flip.count++;
                }
        next_char:
                ch = readb(&channel->control);
                ZSDELAY();
                if (!(ch & Rx_CH_AV))
                        break;
        }

        tty_flip_buffer_push(tty);
}


mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Dennis Grevenstein]

Hi,

I just tried a simple, quick recompile with the ip22zilog
driver. The kernel boots and seems to work.

misato:~# uname -a
Linux misato 2.6.10-rc1 #2 Sun Oct 31 21:56:20 CET 2004 mips GNU/Linux

Any more help is greatly appreciated though.

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Dennis Grevenstein]

On Sun, Oct 31, 2004 at 11:51:33PM +0100, Dennis Grevenstein wrote:
> 
> I just tried a simple, quick recompile with the ip22zilog
> driver. The kernel boots and seems to work.
 
Sorry, of course I meant _without_ the driver.

mfg
Dennis

-- 
There is certainly no purpose in remaining in the dark
except long enough to clear from the mind
the illusion of ever having been in the light.
                                        T.S. Eliot

Re: unable to handle kernel paging request

[Maciej W. Rozycki]

On Sun, 31 Oct 2004, Dennis Grevenstein wrote:

>         struct tty_struct *tty = up->port.info->tty;    /* XXX info==NULL? */

 It looks up->port.info is null for some reason (and unhandled as noted 
in the comment).

  Maciej

Re: unable to handle kernel paging request

[Florian Lohoff]

[-- Attachment #1: Type: text/plain, Size: 3705 bytes --]

On Sun, Oct 31, 2004 at 11:59:31PM +0000, Maciej W. Rozycki wrote:
> On Sun, 31 Oct 2004, Dennis Grevenstein wrote:
> 
> >         struct tty_struct *tty = up->port.info->tty;    /* XXX info==NULL? */
> 
>  It looks up->port.info is null for some reason (and unhandled as noted 
> in the comment).

I had the same problem and fixed it like this - It fixes some other
break/sysrq based problems ...

Index: drivers/serial/ip22zilog.c
===================================================================
RCS file: /home/flo/linux-mips-cvs/linux/drivers/serial/ip22zilog.c,v
retrieving revision 1.15
diff -u -r1.15 ip22zilog.c
--- drivers/serial/ip22zilog.c	28 Sep 2004 19:22:07 -0000	1.15
+++ drivers/serial/ip22zilog.c	3 Oct 2004 19:26:06 -0000
@@ -47,8 +47,6 @@
 
 #include "ip22zilog.h"
 
-void ip22_do_break(void);
-
 /*
  * On IP22 we need to delay after register accesses but we do not need to
  * flush writes.
@@ -256,17 +254,15 @@
 				   struct zilog_channel *channel,
 				   struct pt_regs *regs)
 {
-	struct tty_struct *tty = up->port.info->tty;	/* XXX info==NULL? */
+	struct tty_struct *tty = NULL;
+
+	if (up->port.info != NULL &&		/* Unopened serial console */
+	    up->port.info->tty != NULL)		/* Keyboard || mouse */
+		tty = up->port.info->tty;
 
 	while (1) {
 		unsigned char ch, r1;
 
-		if (unlikely(tty->flip.count >= TTY_FLIPBUF_SIZE)) {
-			tty->flip.work.func((void *)tty);
-			if (tty->flip.count >= TTY_FLIPBUF_SIZE)
-				return;		/* XXX Ignores SysRq when we need it most. Fix. */
-		}
-
 		r1 = read_zsreg(channel, R1);
 		if (r1 & (PAR_ERR | Rx_OVR | CRC_ERR)) {
 			writeb(ERR_RES, &channel->control);
@@ -288,24 +284,8 @@
 
 		ch &= up->parity_mask;
 
-		if (ZS_IS_CONS(up) && (r1 & BRK_ABRT)) {
-			/* Wait for BREAK to deassert to avoid potentially
-			 * confusing the PROM.
-			 */
-			while (1) {
-				ch = readb(&channel->control);
-				ZSDELAY();
-				if (!(ch & BRK_ABRT))
-					break;
-			}
-			ip22_do_break();
-			return;
-		}
-
-		/* A real serial line, record the character and status.  */
-		*tty->flip.char_buf_ptr = ch;
-		*tty->flip.flag_buf_ptr = TTY_NORMAL;
 		up->port.icount.rx++;
+
 		if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) {
 			if (r1 & BRK_ABRT) {
 				r1 &= ~(PAR_ERR | CRC_ERR);
@@ -319,6 +299,25 @@
 				up->port.icount.frame++;
 			if (r1 & Rx_OVR)
 				up->port.icount.overrun++;
+		}
+
+		if (uart_handle_sysrq_char(&up->port, ch, regs))
+			goto next_char;
+
+		if (!tty)
+			goto next_char;
+
+		if (unlikely(tty->flip.count >= TTY_FLIPBUF_SIZE)) {
+			tty->flip.work.func((void *)tty);
+			if (tty->flip.count >= TTY_FLIPBUF_SIZE)
+				goto push_tty;		/* XXX We drop characters here - Either read or die */
+		}
+
+		/* A real serial line, record the character and status.  */
+		*tty->flip.char_buf_ptr = ch;
+		*tty->flip.flag_buf_ptr = TTY_NORMAL;
+
+		if (r1 & (BRK_ABRT | PAR_ERR | Rx_OVR | CRC_ERR)) {
 			r1 &= up->port.read_status_mask;
 			if (r1 & BRK_ABRT)
 				*tty->flip.flag_buf_ptr = TTY_BREAK;
@@ -327,8 +326,6 @@
 			else if (r1 & CRC_ERR)
 				*tty->flip.flag_buf_ptr = TTY_FRAME;
 		}
-		if (uart_handle_sysrq_char(&up->port, ch, regs))
-			goto next_char;
 
 		if (up->port.ignore_status_mask == 0xff ||
 		    (r1 & up->port.ignore_status_mask) == 0) {
@@ -350,7 +347,9 @@
 			break;
 	}
 
-	tty_flip_buffer_push(tty);
+push_tty:
+	if (tty)
+		tty_flip_buffer_push(tty);
 }
 
 static void ip22zilog_status_handle(struct uart_ip22zilog_port *up,

-- 
Florian Lohoff                  flo@rfc822.org             +49-171-2280134
                        Heisenberg may have been here.

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]