Unable to handle kernel paging request

Unable to handle kernel paging request

[Paulo Marques]

I got this shortly after reconnecting a stale smb connection on a 2.6.4-rc1 
vanilla kernel:

(removed hostname and date information to make it less verbose)

04:03:31 SMB connection re-established (-5)
04:03:47 Unable to handle kernel paging request at virtual address c1f16f1c
04:03:47 printing eip:
04:03:47 c01fc2f8
04:03:47 ws15t1 syslog.alert klogd: *pde = 00007067
04:03:47 ws15t1 syslog.alert klogd: *pte = 01f16000
04:03:47 Oops: 0000 [#1]
04:03:47 PREEMPT DEBUG_PAGEALLOC
04:03:47 CPU:    0
04:03:47 EIP:    0060:[01fc2f8>]    Not tainted
04:03:47 EFLAGS: 00010246
04:03:47 EIP is at smb_add_request+0x238/0x520
04:03:47 eax: 00000000   ebx: c3a22000   ecx: c29a2e60   edx: c6940f78
04:03:47 esi: c1f16eec   edi: c29a2e60   ebp: c3a23dc4   esp: c3a23d74
04:03:47 ds: 007b   es: 007b   ss: 0068
04:03:47 Process bash (pid: 93, threadinfo=c3a22000 task=c3a319e0)
04:03:47 Stack: 0000000b c3cec000 c1f16eec c6dcfe00 c1f16ef8 00000000 00000040 
c1f16f24
04:03:47        c29a2df8 00000000 c3a319e0 c011eab0 00100100 00200200 00000401 
c3cec006
04:03:47        c29a2df8 00000002 c1f16eec c3cec000 c3a23df0 c01f3434 c2529f38 
00000000
04:03:47 Call Trace:
04:03:47  [011eab0>] default_wake_function+0x0/0x10
04:03:47  [01f3434>] smb_proc_getattr_trans2+0x84/0x100
04:03:47  [01f3734>] smb_proc_getattr_trans2_all+0x44/0xe0
04:03:47  [01f114c>] smb_init_dirent+0x4c/0x60
04:03:47  [01f1222>] smb_proc_getattr+0x32/0x50
04:03:47  [01f851c>] smb_refresh_inode+0x1c/0x100
04:03:47  [016d8ac>] __getblk+0x1c/0x40
04:03:47  [01bbc4a>] ext3_getblk+0xca/0x260
04:03:47  [01f86cc>] smb_revalidate_inode+0xcc/0x200
04:03:47  [011c826>] kernel_map_pages+0x16/0x50
04:03:47  [01f8bec>] smb_getattr+0x1c/0x50
04:03:47  [01f8bd0>] smb_getattr+0x0/0x50
04:03:47  [01783f1>] vfs_getattr+0x41/0xc0
04:03:47  [01789bf>] vfs_lstat+0x3f/0x60
04:03:47  [016adb0>] filp_dtor+0x0/0x190
04:03:47  [01789f4>] sys_lstat64+0x14/0x30
04:03:47  [010d12d>] do_IRQ+0x2dd/0x430
04:03:47  [016b193>] __fput+0x83/0xd0
04:03:47  [0109fef>] syscall_call+0x7/0xb
04:03:47
04:03:47 Code: 8b 46 30 c7 04 24 a0 da 41 c0 89 44 24 0c b8 58 a6 3f c0 89

The directory was mounted and was idle (no file activity at all) for about 20 
hours before this happened.

I also have the complete syslog (it is only 400 lines), meminfo and slabinfo 
from the same machine at the time of the dump, and I can post it if you find it 
useful.

This is a somewhat "embedded" system, using a transmeta crusoe processor at 
500MHz. The kernel configuration includes BlueZ modules, ethernet bridging and 
cardbus (yenta) support. These are the most uncommon features.

The samba server was version 2.2.2 (which is quite old), but the client is the 
latest kernel available.

I saw this only once and I don't believe this is going to be easy to reproduce.

After the dump the machine continued to operate normally (including acesing the 
samba mounted directory), except for the shell that was doing a tab completion 
on the directory name, that exited.

-- 
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"

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 --]

Unable to handle kernel paging request

[Praedor Atrebates]

Please CC me any answer you might have to offer me as I am not subscribed to 
the list.  

I am running Mandrake 10.1 on a Gateway Solo laptop, Pentium M, ATI Radeon 
9000, firewire, builtin e1000 ethernet.  Kernel is 2.6.8.1-12mdk.  I have 
lately been running into a tremendous problem with kernel paging request 
errors/Oops's at seemingly random moments.  Right now I am running a 
2.6.0-rc2.2mdk kernel because under the 2.6.8.1 kernel the errors were 
happening so often that the system was unusable for any length of time.  I am 
virtually certain to see one upon shutdown even with the current running 
kernel as well.  The latest such error produced this:

Jan 12 10:31:09 dhcp18-126 kernel: NET: Unregistered protocol family 23
Jan 12 10:32:19 dhcp18-126 kernel: Unable to handle kernel paging request at 
virtual address d56c34ac
Jan 12 10:32:19 dhcp18-126 kernel:  printing eip:
Jan 12 10:32:19 dhcp18-126 kernel: c01294a3
Jan 12 10:32:19 dhcp18-126 kernel: *pde = 0e1a6067
Jan 12 10:32:19 dhcp18-126 kernel: *pte = 00000000
Jan 12 10:32:19 dhcp18-126 kernel: Oops: 0000 [#1]
Jan 12 10:32:19 dhcp18-126 kernel: Modules linked in: crc-ccitt sg st sr_mod 
sd_mod scsi_mod fglrx exportfs lockd sunrpc md5 ipv6 snd-seq-oss 
snd-seq-midi-event snd-seq snd-pcm-oss snd-mixer-oss snd-intel8x0 
snd-ac97-codec snd-pcm snd-timer snd-page-alloc gameport snd-mpu401-uart 
snd-rawmidi snd-seq-device snd soundcore parport_pc lp parport driverloader 
af_packet floppy ds yenta_socket pcmcia_core eth1394 e1000 tulip raw ide-cd 
cdrom ohci1394 ieee1394 loop nls_iso8859-1 ntfs ext3 jbd intel-agp agpgart 
nvram evdev ehci-hcd uhci-hcd usbcore rtc reiserfs
Jan 12 10:32:19 dhcp18-126 kernel: CPU:    0
Jan 12 10:32:19 dhcp18-126 kernel: EIP:    0060:[notifier_call_chain+35/64]    
Tainted: P   VLI
Jan 12 10:32:19 dhcp18-126 kernel: EIP:    0060:[<c01294a3>]    Tainted: P   
VLI
Jan 12 10:32:19 dhcp18-126 kernel: EFLAGS: 00010286   (2.6.8.1-12mdk)
Jan 12 10:32:19 dhcp18-126 kernel: EIP is at notifier_call_chain+0x23/0x40
Jan 12 10:32:19 dhcp18-126 kernel: eax: 00000001   ebx: d56c34ac   ecx: 
00000000   edx: 00000001
Jan 12 10:32:20 dhcp18-126 kernel: esi: cf264800   edi: 00000006   ebp: 
c3eade7c   esp: c3eade64
Jan 12 10:32:20 dhcp18-126 kernel: ds: 007b   es: 007b   ss: 0068
Jan 12 10:32:20 dhcp18-126 kernel: Process rmmod (pid: 3956, 
threadinfo=c3eac000 task=c253a0b0)
Jan 12 10:32:20 dhcp18-126 kernel: Stack: d56c34ac 00000006 cf264800 cf264800 
cf264800 cf264938 c3eadea4 c02769a2
Jan 12 10:32:20 dhcp18-126 kernel:        c03e5520 00000006 cf264800 d0ee1cae 
cf264938 cf264800 cc40ec98 ccf64000
Jan 12 10:32:20 dhcp18-126 kernel:        c3eadeb4 c0220537 cf264800 cf264a20 
c3eaded8 d0f7cb9f cf264800 ccf64000
Jan 12 10:32:20 dhcp18-126 kernel: Call Trace:
Jan 12 10:32:20 dhcp18-126 kernel:  [show_stack+127/160] show_stack+0x7f/0xa0
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0107bbf>] show_stack+0x7f/0xa0
Jan 12 10:32:20 dhcp18-126 kernel:  [show_registers+342/464] 
show_registers+0x156/0x1d0
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0107d56>] show_registers+0x156/0x1d0
Jan 12 10:32:20 dhcp18-126 kernel:  [die+102/208] die+0x66/0xd0
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0107ef6>] die+0x66/0xd0
Jan 12 10:32:20 dhcp18-126 kernel:  [do_page_fault+966/1456] 
do_page_fault+0x3c6/0x5b0
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0119b26>] do_page_fault+0x3c6/0x5b0
Jan 12 10:32:20 dhcp18-126 kernel:  [error_code+45/56] error_code+0x2d/0x38
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0107849>] error_code+0x2d/0x38
Jan 12 10:32:20 dhcp18-126 kernel:  [unregister_netdevice+338/606] 
unregister_netdevice+0x152/0x25e
Jan 12 10:32:20 dhcp18-126 kernel:  [<c02769a2>] 
unregister_netdevice+0x152/0x25e
Jan 12 10:32:20 dhcp18-126 kernel:  [unregister_netdev+23/32] 
unregister_netdev+0x17/0x20
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0220537>] unregister_netdev+0x17/0x20
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+280554399/1069613056] 
ether1394_remove_host+0x6f/0x90 [eth1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0f7cb9f>] 
ether1394_remove_host+0x6f/0x90 [eth1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+279897277/1069613056] 
__unregister_host+0x8d/0xc0 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0edc4bd>] __unregister_host+0x8d/0xc0 
[ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+279897361/1069613056] 
highlevel_for_each_host_unreg+0x21/0x30 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0edc511>] 
highlevel_for_each_host_unreg+0x21/0x30 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+279917671/1069613056] 
nodemgr_for_each_host+0x47/0x80 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0ee1467>] 
nodemgr_for_each_host+0x47/0x80 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+279897499/1069613056] 
hpsb_unregister_highlevel+0x7b/0x90 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0edc59b>] 
hpsb_unregister_highlevel+0x7b/0x90 [ieee1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [pg0+280562478/1069613056] 
ether1394_exit_module+0x1e/0x2d [eth1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [<d0f7eb2e>] 
ether1394_exit_module+0x1e/0x2d [eth1394]
Jan 12 10:32:20 dhcp18-126 kernel:  [sys_delete_module+306/384] 
sys_delete_module+0x132/0x180
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0131902>] sys_delete_module+0x132/0x180
Jan 12 10:32:20 dhcp18-126 kernel:  [sysenter_past_esp+82/113] 
sysenter_past_esp+0x52/0x71
Jan 12 10:32:20 dhcp18-126 kernel:  [<c0106dcd>] sysenter_past_esp+0x52/0x71
Jan 12 10:32:20 dhcp18-126 kernel: Code: b8 fe ff ff ff c3 89 f6 55 31 d2 89 
e5 57 56 53 83 ec 0c 8b 45 08 8b 7d 0c 8b 75 10 8b 18 eb 19 89 74 24 08 89 7c 
24 04 89 1c 24 <ff> 13 a9 00 80 00 00 89 c2 75 07 8b 5b 04 85 db 75 e3 83 c4 
0c

A previous such error (very brief) produced:

Jan  6 14:23:17 lapdog kernel: NET: Registered protocol family 4
Jan  6 14:23:17 lapdog kernel: Unable to handle kernel paging request at 
virtual
 address d0bb24b4
Jan  6 14:23:17 lapdog kernel:  printing eip:
Jan  6 14:23:17 lapdog kernel: c012942f
Jan  6 14:23:17 lapdog kernel: *pde = 012f3067
Jan  6 14:23:17 lapdog kernel: *pte = 00000000
Jan  6 14:23:17 lapdog kernel: Oops: 0000 [#2]

The same hex address region is involved.  From my system map the above two 
addresses fall between inter_module_unregister in my system map 
(c0129460) and before inter_module_get (c0129520).

Is this indicative of a hardware problem or a software problem?  I have booted 
up with memtest86+ and let it run for about an hour (couldn't afford to let 
it go longer at that point) and it found no problems at all.  

Thank you for any aid you can toss my way.

praedor

Unable to handle kernel paging request

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 2382 bytes --]

Hi,

booting a FC6 on my intel box (xeon) with a kernel 2.6.22.5 and KVM git, I had
the following error (not reproducible):

# kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda fc6.qcow2 -net nic
-net tap -serial stdio -smp 4
...
INIT: version 2.86 booting
                Welcome to Fedora Core
                Press 'I' to enter interactive startup.
Setting clock  (utc): Thu Sep 27 18:06:27 CEST 2007 [  OK  ]
Starting udev: Unable to handle kernel paging request at ffffffff880e9000 RIP:
 [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786
PGD 203067 PUD 205063 PMD 7fc4067 PTE 6b50163
Oops: 0002 [1] SMP
CPU 1
Modules linked in: dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata sd_mod s
csi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
Pid: 641, comm: modprobe Not tainted 2.6.22.5 #1
RIP: 0010:[<ffffffff8104ebc1>]  [<ffffffff8104ebc1>] sys_init_module+0x985/0x178
6
RSP: 0018:ffff810006399e68  EFLAGS: 00010246
RAX: 0000000000000000 RBX: ffffc20000090a20 RCX: 0000000000000f84
RDX: ffffffff880e6000 RSI: 0000000000000163 RDI: ffffffff880e9000
RBP: 0000000000000026 R08: ffff810007d94254 R09: 00000000000050cf
R10: 0000000000000000 R11: 0000000000000001 R12: ffffc2000007c300
R13: 0000000000000004 R14: ffffc200000900e0 R15: 00002ab868ac2010
FS:  00002ab8690096e0(0000) GS:ffff810007d94280(0000) knlGS:0000000000000000
CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
CR2: ffffffff880e9000 CR3: 0000000007cfd000 CR4: 00000000000006e0
Process modprobe (pid: 641, threadinfo ffff810006398000, task ffff81000788e000)
Stack:  00000000000276d8 0000000000000000 0000000000000000 000000000608f340
 0000000000000000 0000000000000000 0000000000000000 0000000000000000
 0000000000000000 0000000000000000 ffffc200000a2328 ffff810006402000
Call Trace:
 [<ffffffff8108e67d>] vfs_read+0xcb/0x173
 [<ffffffff81009b9e>] system_call+0x7e/0x83


Code: f3 aa 49 89 94 24 88 01 00 00 49 8b bc 24 90 01 00 00 e8 32
RIP  [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786
 RSP <ffff810006399e68>
CR2: ffffffff880e9000


The instruction at [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786 is:

0xffffffff8104ebc1 <sys_init_module+2437>:      rep stos %al,%es:(%rdi)

Any idea of what happened ?

Laurent
-- 
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Unable to handle kernel paging request

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 3711 bytes --]

Correct me if I'm wrong, perhaps it's the bug Nitin is hunting.

There is always something wrong in the management in the REP prefix.

I think what is happen is:

- we have a REP prefix, we save ECX and EIP.
- we set c->dst to emulate a "stos"
- goto writeback
- writeback: we try a "write_emulated()" with c->dst
- write_emulated failed() AND WE DON'T RESTORE ECX AND EIP -> it's bad...
- exit to QEMU
- re-enter in x86_emulate_insn() with already modified ECX and EIP.

Any comment ?
(Yes, I know, it's again another bug I've introduced into KVM...)

Laurent

Laurent Vivier wrote:
> Hi,
> 
> booting a FC6 on my intel box (xeon) with a kernel 2.6.22.5 and KVM git, I had
> the following error (not reproducible):
> 
> # kvm-userspace/qemu/x86_64-softmmu/qemu-system-x86_64 -hda fc6.qcow2 -net nic
> -net tap -serial stdio -smp 4
> ...
> INIT: version 2.86 booting
>                 Welcome to Fedora Core
>                 Press 'I' to enter interactive startup.
> Setting clock  (utc): Thu Sep 27 18:06:27 CEST 2007 [  OK  ]
> Starting udev: Unable to handle kernel paging request at ffffffff880e9000 RIP:
>  [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786
> PGD 203067 PUD 205063 PMD 7fc4067 PTE 6b50163
> Oops: 0002 [1] SMP
> CPU 1
> Modules linked in: dm_snapshot dm_zero dm_mirror dm_mod ata_piix libata sd_mod s
> csi_mod ext3 jbd mbcache ehci_hcd ohci_hcd uhci_hcd
> Pid: 641, comm: modprobe Not tainted 2.6.22.5 #1
> RIP: 0010:[<ffffffff8104ebc1>]  [<ffffffff8104ebc1>] sys_init_module+0x985/0x178
> 6
> RSP: 0018:ffff810006399e68  EFLAGS: 00010246
> RAX: 0000000000000000 RBX: ffffc20000090a20 RCX: 0000000000000f84
> RDX: ffffffff880e6000 RSI: 0000000000000163 RDI: ffffffff880e9000
> RBP: 0000000000000026 R08: ffff810007d94254 R09: 00000000000050cf
> R10: 0000000000000000 R11: 0000000000000001 R12: ffffc2000007c300
> R13: 0000000000000004 R14: ffffc200000900e0 R15: 00002ab868ac2010
> FS:  00002ab8690096e0(0000) GS:ffff810007d94280(0000) knlGS:0000000000000000
> CS:  0010 DS: 0000 ES: 0000 CR0: 000000008005003b
> CR2: ffffffff880e9000 CR3: 0000000007cfd000 CR4: 00000000000006e0
> Process modprobe (pid: 641, threadinfo ffff810006398000, task ffff81000788e000)
> Stack:  00000000000276d8 0000000000000000 0000000000000000 000000000608f340
>  0000000000000000 0000000000000000 0000000000000000 0000000000000000
>  0000000000000000 0000000000000000 ffffc200000a2328 ffff810006402000
> Call Trace:
>  [<ffffffff8108e67d>] vfs_read+0xcb/0x173
>  [<ffffffff81009b9e>] system_call+0x7e/0x83
> 
> 
> Code: f3 aa 49 89 94 24 88 01 00 00 49 8b bc 24 90 01 00 00 e8 32
> RIP  [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786
>  RSP <ffff810006399e68>
> CR2: ffffffff880e9000
> 
> 
> The instruction at [<ffffffff8104ebc1>] sys_init_module+0x985/0x1786 is:
> 
> 0xffffffff8104ebc1 <sys_init_module+2437>:      rep stos %al,%es:(%rdi)
> 
> Any idea of what happened ?
> 
> Laurent
> 
> 
> ------------------------------------------------------------------------
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> kvm-devel mailing list
> kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
> https://lists.sourceforge.net/lists/listinfo/kvm-devel


-- 
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

Re: Unable to handle kernel paging request

[Avi Kivity]

Laurent Vivier wrote:
> (Yes, I know, it's again another bug I've introduced into KVM...)
>
>   

To avoid this, I suggest that Nitin and yourself review each other's 
patches.  While I review every patch I commit, it works much better when 
someone who's involved daily with the code reviews the patch.

-- 
error compiling committee.c: too many arguments to function


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

Re: Unable to handle kernel paging request

[Laurent Vivier]

[-- Attachment #1.1: Type: text/plain, Size: 494 bytes --]

Avi Kivity wrote:
> Laurent Vivier wrote:
>> (Yes, I know, it's again another bug I've introduced into KVM...)
>>
>>   
> 
> To avoid this, I suggest that Nitin and yourself review each other's
> patches.  While I review every patch I commit, it works much better when
> someone who's involved daily with the code reviews the patch.

I agree...

Laurent
-- 
------------- Laurent.Vivier-6ktuUTfB/bM@public.gmane.org  --------------
          "Software is hard" - Donald Knuth


[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

[-- Attachment #2: Type: text/plain, Size: 228 bytes --]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/

[-- Attachment #3: Type: text/plain, Size: 186 bytes --]

_______________________________________________
kvm-devel mailing list
kvm-devel-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f@public.gmane.org
https://lists.sourceforge.net/lists/listinfo/kvm-devel

unable to handle kernel paging request

[Mark Gavalda]

Hi,

Bumped into the following one today; kernel 4.4.0-36-generic Ubuntu
16.4.1; CPU went to 100% and only a hard restart solved the issue.
Since then everything's back to normal.

Please let me know how can I help get to the bottom of this?

[239049.350514] BUG: unable to handle kernel paging request at 00000000d3c53de8
[239049.358107] IP: [<ffffffff810eecf9>] hrtimer_active+0x9/0x60
[239049.364127] PGD a688df067 PUD 0
[239049.367828] Oops: 0000 [#2] SMP
[239049.371543] Modules linked in: xt_recent xt_nat xt_multiport
ip6t_REJECT nf_reject_ipv6 xt_hl ip6t_rt nf_conntrack_ipv6
nf_defrag_ipv6 ipt_REJECT nf_reject_ipv4 xt_limit xt_addrtype
xt_conntrack binfmt_misc veth xt_CHECKSUM iptable_mangle xt_tcpudp
ipt_MASQUERADE nf_nat_masquerade_ipv4 xt_comment iptable_nat
nf_conntrack_ipv4 nf_defrag_ipv4 nf_nat_ipv4 nf_nat nf_conntrack
bridge stp llc ip6table_filter ip6_tables iptable_filter ip_tables
x_tables ppdev parport_pc parport serio_raw pvpanic ib_iser rdma_cm
iw_cm ib_cm ib_sa ib_mad ib_core ib_addr iscsi_tcp libiscsi_tcp
libiscsi scsi_transport_iscsi autofs4 btrfs raid10 raid456
async_raid6_recov async_memcpy async_pq async_xor async_tx xor
raid6_pq libcrc32c raid1 raid0 multipath linear crct10dif_pclmul
crc32_pclmul aesni_intel aes_x86_64 lrw gf128mul glue_helper
ablk_helper cryptd psmouse virtio_scsi
[239049.457553] CPU: 24 PID: 1298718 Comm: kworker/u64:24 Tainted: G
   D         4.4.0-36-generic #55-Ubuntu
[239049.467497] Hardware name: Google Google/Google, BIOS Google 01/01/2011
[239049.474348] Workqueue: btrfs-endio-write btrfs_endio_write_helper [btrfs]
[239049.481472] task: ffff8801512dee00 ti: ffff8801fd1c8000 task.ti:
ffff8801fd1c8000
[239049.489205] RIP: 0010:[<ffffffff810eecf9>]  [<ffffffff810eecf9>]
hrtimer_active+0x9/0x60
[239049.497702] RSP: 0018:ffff8801fd1cbc20  EFLAGS: 00010046
[239049.503230] RAX: 0000000000000000 RBX: 00000000d3c53db8 RCX:
0000000000000000
[239049.510569] RDX: 0000000000000000 RSI: 0000000000000003 RDI:
00000000d3c53db8
[239049.517910] RBP: ffff8801fd1cbc20 R08: ffff88336f416d00 R09:
ffff88333fe57e00
[239049.525250] R10: 00000000000000a0 R11: 0000000001b5675f R12:
ffff8807024cb628
[239049.532595] R13: ffff8802d5e5bd98 R14: 0000000000000000 R15:
0000000000000003
[239049.539938] FS:  0000000000000000(0000) GS:ffff88336f400000(0000)
knlGS:0000000000000000
[239049.548246] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[239049.554234] CR2: 00000000d3c53de8 CR3: 0000000a5e8a1000 CR4:
00000000001406e0
[239049.561576] Stack:
[239049.563812]  ffff8801fd1cbc58 ffffffff810ef249 0000000000000003
00000000d3b71a0d
[239049.571936]  00000000d3c53db8 ffff8807024cb628 ffff8802d5e5bd98
ffff8801fd1cbca8
[239049.580141]  ffffffff8182d3c1 ffffffff810c35f2 0000000100000001
0000000000000000
[239049.588300] Call Trace:
[239049.590976]  [<ffffffff810ef249>] hrtimer_try_to_cancel+0x29/0x130
[239049.597384]  [<ffffffff8182d3c1>] schedule_hrtimeout_range_clock+0xd1/0x1b0
[239049.604571]  [<ffffffff810c35f2>] ? __wake_up_common+0x52/0x90
[239049.610619]  [<ffffffff810c3669>] __wake_up+0x39/0x50
[239049.615906]  [<ffffffffc02ce324>]
btrfs_remove_ordered_extent+0x154/0x250 [btrfs]
[239049.623620]  [<ffffffffc02bc040>]
btrfs_finish_ordered_io+0x1d0/0x650 [btrfs]
[239049.630993]  [<ffffffffc02bc785>] finish_ordered_fn+0x15/0x20 [btrfs]
[239049.637666]  [<ffffffffc02e4eba>]
btrfs_scrubparity_helper+0xca/0x2f0 [btrfs]
[239049.645042]  [<ffffffffc02e516e>] btrfs_endio_write_helper+0xe/0x10 [btrfs]
[239049.652239]  [<ffffffff8109a2c5>] process_one_work+0x165/0x480
[239049.658293]  [<ffffffff8109a62b>] worker_thread+0x4b/0x4c0
[239049.663984]  [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
[239049.670196]  [<ffffffff8109a5e0>] ? process_one_work+0x480/0x480
[239049.676420]  [<ffffffff810a0808>] kthread+0xd8/0xf0
[239049.681514]  [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[239049.688260]  [<ffffffff8182e34f>] ret_from_fork+0x3f/0x70
[239049.693870]  [<ffffffff810a0730>] ? kthread_create_on_node+0x1e0/0x1e0
[239049.700599] Code: 00 00 0f 1f 44 00 00 55 48 c7 47 28 10 f0 0e 81
48 89 77 58 48 89 e5 5d c3 66 0f 1f 84 00 00 00 00 00 0f 1f 44 00 00
55 48 89 e5 <48> 8b 57 30 eb 1d 80 7f 38 00 75 32 48 3b 78 08 74 2c 39
50 04
[239049.727797] RIP  [<ffffffff810eecf9>] hrtimer_active+0x9/0x60
[239049.733868]  RSP <ffff8801fd1cbc20>
[239049.737557] CR2: 00000000d3c53de8
[239049.741535] ---[ end trace 774da4af66731bb5 ]---

Thanks,
Mark Gavalda

Re: unable to handle kernel paging request

[Chris Mason]

On 09/15/2016 10:08 AM, Mark Gavalda wrote:
> Hi,
>
> Bumped into the following one today; kernel 4.4.0-36-generic Ubuntu
> 16.4.1; CPU went to 100% and only a hard restart solved the issue.
> Since then everything's back to normal.
>
> Please let me know how can I help get to the bottom of this?

I saw similar traces when tracking down this bug:

https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/commit/?h=for-linus-4.8&id=cbd60aa7cd17d81a434234268c55192862147439

It's flagged for stable, so you'll get it with the next stable update, 
or you can apply it by hand and rebuild.

-chris

Re: unable to handle kernel paging request

[Mark Gavalda]

Thanks, I can see it included in 4.8-rc6 but not the other branches.
Will it get pulled later or is this a 4.8 only fix?

Mark

On Thu, Sep 15, 2016 at 6:05 PM, Chris Mason <clm@fb.com> wrote:
> On 09/15/2016 10:08 AM, Mark Gavalda wrote:
>>
>> Hi,
>>
>> Bumped into the following one today; kernel 4.4.0-36-generic Ubuntu
>> 16.4.1; CPU went to 100% and only a hard restart solved the issue.
>> Since then everything's back to normal.
>>
>> Please let me know how can I help get to the bottom of this?
>
>
> I saw similar traces when tracking down this bug:
>
> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/commit/?h=for-linus-4.8&id=cbd60aa7cd17d81a434234268c55192862147439
>
> It's flagged for stable, so you'll get it with the next stable update, or
> you can apply it by hand and rebuild.
>
> -chris

Re: unable to handle kernel paging request

[Duncan]

Mark Gavalda posted on Thu, 15 Sep 2016 22:12:57 +0200 as excerpted:

[Moved to bottom to retain quote/reply order.]

> On Thu, Sep 15, 2016 at 6:05 PM, Chris Mason <clm@fb.com> wrote:
>> On 09/15/2016 10:08 AM, Mark Gavalda wrote:
>>>
>>> Hi,
>>>
>>> Bumped into the following one today; kernel 4.4.0-36-generic Ubuntu
>>> 16.4.1; CPU went to 100% and only a hard restart solved the issue.
>>> Since then everything's back to normal.
>>>
>>> Please let me know how can I help get to the bottom of this?
>>
>>
>> I saw similar traces when tracking down this bug:
>>
>> https://git.kernel.org/cgit/linux/kernel/git/mason/linux-btrfs.git/
commit/?h=for-linus-4.8&id=cbd60aa7cd17d81a434234268c55192862147439
>>
>> It's flagged for stable, so you'll get it with the next stable update,
>> or you can apply it by hand and rebuild.

> Thanks, I can see it included in 4.8-rc6 but not the other branches.
> Will it get pulled later or is this a 4.8 only fix?

Flagged for stable means it's headed to the maintained stable branches 
(well, the ones to which the fix applies for regression fixes, but 
definitely 4.4 LTS series in this case since Chris Mason indicated it 
should apply in your case), not just current.

But stabilization policy says a patch must hit mainline current first, 
before it is eligible for older stable as well.  So it would be 
/expected/ to hit 4.8-rc, current development, first.  After that, given 
that it's already flagged for stable, it should eventually hit all the 
stable kernels to which it applies as well.  That can be right away, but 
if the stable maintainer (Greg K-H, normally) is backlogged due to just 
getting back from vacation or something, as sometimes happens, it can 
take a few weeks to work thru the backlog, so it can take a bit, as well.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

unable to handle kernel paging request

[Lange Norbert]

Hello,

How can I get to the bottom of bugs that lockup the system completely?
I got that error now the 3rd time.

[ 1643.652566] BUG: unable to handle kernel paging request at 0000000000044540
[ 1643.659546] PGD 1750d1067 P4D 1750d1067 PUD 1775e7067 PMD 0
[ 1643.665237] Oops: 0010 [#1] SMP NOPTI
[ 1643.668911] CPU: 2 PID: 862 Comm: fup.medium Tainted: G        W         4.19.75-xeno7-static #1
[ 1643.677703] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, BIOS 5.12.30.21.16 01/31/2019
[ 1643.687013] I-pipe domain: Linux
[ 1643.690250] RIP: 0086:0x1c000
[ 1643.693231] Code: Bad RIP value.
[ 1643.696468] RSP: 3bb00000:0000000000000083 EFLAGS: ffff92103bb25090 ORIG_RAX: 0000000000000046
[ 1643.705092] RAX: ffff92103bb30400 RBX: ffff92103bb30400 RCX: ffff92103bb31bb0
[ 1643.712235] RDX: ffff92103bb31d58 RSI: ffffffff8ab85272 RDI: ffff921039f24cc0
[ 1643.719378] RBP: ffff92103bb305c8 R08: 0000000000000002 R09: ffff92103bb31d58
[ 1643.726517] R10: ffff92103bb31bb0 R11: 0000000000004000 R12: ffffffff8bc3f3c0
[ 1643.733657] R13: ffffffff8ab8284b R14: 000000000001c000 R15: 0000000000000086
[ 1643.740799] FS:  00007fffe81da700 GS:  0000000000000000
[ 1643.746033] Modules linked in: rt_igb plusb usbnet mii
[ 1643.751210] CR2: 0000000000044540
[ 1643.754542] ---[ end trace 7dda9c557e28b024 ]---
[ 1643.759167] RIP: 0086:0x1c000
[ 1643.762146] Code: Bad RIP value.
[ 1643.765379] RSP: 3bb00000:0000000000000083 EFLAGS: ffff92103bb25090 ORIG_RAX: 0000000000000046
[ 1643.774003] RAX: ffff92103bb30400 RBX: ffff92103bb30400 RCX: ffff92103bb31bb0
[ 1643.781147] RDX: ffff92103bb31d58 RSI: ffffffff8ab85272 RDI: ffff921039f24cc0
[ 1643.788289] RBP: ffff92103bb305c8 R08: 0000000000000002 R09: ffff92103bb31d58
[ 1643.795427] R10: ffff92103bb31bb0 R11: 0000000000004000 R12: ffffffff8bc3f3c0
[ 1643.802569] R13: ffffffff8ab8284b R14: 000000000001c000 R15: 0000000000000086
[ 1643.809712] FS:  00007fffe81da700(0000) GS:ffff92103bb00000(0000) knlGS:0000000000000000
[ 1643.817806] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 1643.823558] CR2: 000000000001bfd6 CR3: 00000001750e4000 CR4: 00000000003406e0

Mit besten Grüßen / Kind regards

NORBERT LANGE

AT-RD3

ANDRITZ HYDRO GmbH
Eibesbrunnergasse 20
1120 Vienna / AUSTRIA
p: +43 50805 56684
norbert.lange@andritz.com<mailto:norbert.lange@andritz.com>
andritz.com<http://www.andritz.com/>

________________________________

This message and any attachments are solely for the use of the intended recipients. They may contain privileged and/or confidential information or other information protected from disclosure. If you are not an intended recipient, you are hereby notified that you received this email in error and that any review, dissemination, distribution or copying of this email and any attachment is strictly prohibited. If you have received this email in error, please contact the sender and delete the message and any attachment from your system.

ANDRITZ HYDRO GmbH


Rechtsform/ Legal form: Gesellschaft mit beschränkter Haftung / Corporation

Firmensitz/ Registered seat: Wien

Firmenbuchgericht/ Court of registry: Handelsgericht Wien

Firmenbuchnummer/ Company registration: FN 61833 g

DVR: 0605077

UID-Nr.: ATU14756806


Thank You
________________________________

Re: unable to handle kernel paging request

[Jan Kiszka]

On 15.11.19 16:26, Lange Norbert via Xenomai wrote:
> Hello,
> 
> How can I get to the bottom of bugs that lockup the system completely?
> I got that error now the 3rd time.
> 
> [ 1643.652566] BUG: unable to handle kernel paging request at 0000000000044540
> [ 1643.659546] PGD 1750d1067 P4D 1750d1067 PUD 1775e7067 PMD 0
> [ 1643.665237] Oops: 0010 [#1] SMP NOPTI
> [ 1643.668911] CPU: 2 PID: 862 Comm: fup.medium Tainted: G        W         4.19.75-xeno7-static #1
> [ 1643.677703] Hardware name: TQ-Group TQMxE39M/Type2 - Board Product Name, BIOS 5.12.30.21.16 01/31/2019
> [ 1643.687013] I-pipe domain: Linux
> [ 1643.690250] RIP: 0086:0x1c000
> [ 1643.693231] Code: Bad RIP value.
> [ 1643.696468] RSP: 3bb00000:0000000000000083 EFLAGS: ffff92103bb25090 ORIG_RAX: 0000000000000046
> [ 1643.705092] RAX: ffff92103bb30400 RBX: ffff92103bb30400 RCX: ffff92103bb31bb0
> [ 1643.712235] RDX: ffff92103bb31d58 RSI: ffffffff8ab85272 RDI: ffff921039f24cc0
> [ 1643.719378] RBP: ffff92103bb305c8 R08: 0000000000000002 R09: ffff92103bb31d58
> [ 1643.726517] R10: ffff92103bb31bb0 R11: 0000000000004000 R12: ffffffff8bc3f3c0
> [ 1643.733657] R13: ffffffff8ab8284b R14: 000000000001c000 R15: 0000000000000086
> [ 1643.740799] FS:  00007fffe81da700 GS:  0000000000000000
> [ 1643.746033] Modules linked in: rt_igb plusb usbnet mii
> [ 1643.751210] CR2: 0000000000044540
> [ 1643.754542] ---[ end trace 7dda9c557e28b024 ]---
> [ 1643.759167] RIP: 0086:0x1c000
> [ 1643.762146] Code: Bad RIP value.
> [ 1643.765379] RSP: 3bb00000:0000000000000083 EFLAGS: ffff92103bb25090 ORIG_RAX: 0000000000000046
> [ 1643.774003] RAX: ffff92103bb30400 RBX: ffff92103bb30400 RCX: ffff92103bb31bb0
> [ 1643.781147] RDX: ffff92103bb31d58 RSI: ffffffff8ab85272 RDI: ffff921039f24cc0
> [ 1643.788289] RBP: ffff92103bb305c8 R08: 0000000000000002 R09: ffff92103bb31d58
> [ 1643.795427] R10: ffff92103bb31bb0 R11: 0000000000004000 R12: ffffffff8bc3f3c0
> [ 1643.802569] R13: ffffffff8ab8284b R14: 000000000001c000 R15: 0000000000000086
> [ 1643.809712] FS:  00007fffe81da700(0000) GS:ffff92103bb00000(0000) knlGS:0000000000000000
> [ 1643.817806] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [ 1643.823558] CR2: 000000000001bfd6 CR3: 00000001750e4000 CR4: 00000000003406e0

You need CONFIG_DEBUG_INFO and here likely CONFIG_IPIPE_TRACE_PANIC with 
the tracer on when the issue occurs.

Jan

-- 
Siemens AG, Corporate Technology, CT RDA IOT SES-DE
Corporate Competence Center Embedded Linux