* Unable to handle kernel paging request
@ 2007-09-27 16:30 Laurent Vivier
[not found] ` <46FBDA8A.8030109-6ktuUTfB/bM@public.gmane.org>
0 siblings, 1 reply; 24+ messages in thread
From: Laurent Vivier @ 2007-09-27 16:30 UTC (permalink / raw)
To: kvm-devel
[-- 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
^ permalink raw reply [flat|nested] 24+ messages in thread* unable to handle kernel paging request
@ 2019-11-15 15:26 Lange Norbert
2019-11-15 15:41 ` Jan Kiszka
0 siblings, 1 reply; 24+ messages in thread
From: Lange Norbert @ 2019-11-15 15:26 UTC (permalink / raw)
To: Xenomai (xenomai@xenomai.org)
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
________________________________
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2019-11-15 15:26 unable " Lange Norbert
@ 2019-11-15 15:41 ` Jan Kiszka
0 siblings, 0 replies; 24+ messages in thread
From: Jan Kiszka @ 2019-11-15 15:41 UTC (permalink / raw)
To: Lange Norbert, Xenomai (xenomai@xenomai.org)
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* unable to handle kernel paging request
@ 2016-09-15 14:08 Mark Gavalda
2016-09-15 16:05 ` Chris Mason
0 siblings, 1 reply; 24+ messages in thread
From: Mark Gavalda @ 2016-09-15 14:08 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2016-09-15 14:08 Mark Gavalda
@ 2016-09-15 16:05 ` Chris Mason
2016-09-15 20:12 ` Mark Gavalda
0 siblings, 1 reply; 24+ messages in thread
From: Chris Mason @ 2016-09-15 16:05 UTC (permalink / raw)
To: Mark Gavalda, linux-btrfs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2016-09-15 16:05 ` Chris Mason
@ 2016-09-15 20:12 ` Mark Gavalda
2016-09-16 2:45 ` Duncan
0 siblings, 1 reply; 24+ messages in thread
From: Mark Gavalda @ 2016-09-15 20:12 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2016-09-15 20:12 ` Mark Gavalda
@ 2016-09-16 2:45 ` Duncan
0 siblings, 0 replies; 24+ messages in thread
From: Duncan @ 2016-09-16 2:45 UTC (permalink / raw)
To: linux-btrfs
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Unable to handle kernel paging request
@ 2005-01-12 18:43 Praedor Atrebates
0 siblings, 0 replies; 24+ messages in thread
From: Praedor Atrebates @ 2005-01-12 18:43 UTC (permalink / raw)
To: linux-kernel
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* unable to handle kernel paging request
@ 2004-10-31 18:42 Dennis Grevenstein
2004-10-31 19:15 ` Jan-Benedict Glaw
[not found] ` <Pine.GSO.4.10.10410311947570.9753-100000@helios.et.put.poznan.pl>
0 siblings, 2 replies; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 18:42 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: unable to handle kernel paging request
2004-10-31 18:42 unable " Dennis Grevenstein
@ 2004-10-31 19:15 ` Jan-Benedict Glaw
[not found] ` <Pine.GSO.4.10.10410311947570.9753-100000@helios.et.put.poznan.pl>
1 sibling, 0 replies; 24+ messages in thread
From: Jan-Benedict Glaw @ 2004-10-31 19:15 UTC (permalink / raw)
To: Dennis Grevenstein; +Cc: linux-mips
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread[parent not found: <Pine.GSO.4.10.10410311947570.9753-100000@helios.et.put.poznan.pl>]
* Re: unable to handle kernel paging request
[not found] ` <Pine.GSO.4.10.10410311947570.9753-100000@helios.et.put.poznan.pl>
@ 2004-10-31 19:16 ` Dennis Grevenstein
2004-10-31 19:26 ` Jan-Benedict Glaw
0 siblings, 1 reply; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 19:16 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: unable to handle kernel paging request
@ 2004-10-31 19:26 ` Jan-Benedict Glaw
0 siblings, 0 replies; 24+ messages in thread
From: Jan-Benedict Glaw @ 2004-10-31 19:26 UTC (permalink / raw)
To: Dennis Grevenstein; +Cc: linux-mips
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
@ 2004-10-31 19:26 ` Jan-Benedict Glaw
0 siblings, 0 replies; 24+ messages in thread
From: Jan-Benedict Glaw @ 2004-10-31 19:26 UTC (permalink / raw)
To: Dennis Grevenstein; +Cc: linux-mips
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2004-10-31 19:26 ` Jan-Benedict Glaw
(?)
@ 2004-10-31 19:55 ` Dennis Grevenstein
2004-10-31 20:13 ` Jan-Benedict Glaw
-1 siblings, 1 reply; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 19:55 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: unable to handle kernel paging request
2004-10-31 19:55 ` Dennis Grevenstein
@ 2004-10-31 20:13 ` Jan-Benedict Glaw
2004-10-31 22:36 ` Dennis Grevenstein
2004-10-31 22:51 ` Dennis Grevenstein
0 siblings, 2 replies; 24+ messages in thread
From: Jan-Benedict Glaw @ 2004-10-31 20:13 UTC (permalink / raw)
To: Dennis Grevenstein; +Cc: linux-mips
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2004-10-31 20:13 ` Jan-Benedict Glaw
@ 2004-10-31 22:36 ` Dennis Grevenstein
2004-10-31 23:59 ` Maciej W. Rozycki
2004-10-31 22:51 ` Dennis Grevenstein
1 sibling, 1 reply; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 22:36 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: unable to handle kernel paging request
2004-10-31 22:36 ` Dennis Grevenstein
@ 2004-10-31 23:59 ` Maciej W. Rozycki
2004-11-01 21:50 ` Florian Lohoff
0 siblings, 1 reply; 24+ messages in thread
From: Maciej W. Rozycki @ 2004-10-31 23:59 UTC (permalink / raw)
To: Dennis Grevenstein; +Cc: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2004-10-31 23:59 ` Maciej W. Rozycki
@ 2004-11-01 21:50 ` Florian Lohoff
0 siblings, 0 replies; 24+ messages in thread
From: Florian Lohoff @ 2004-11-01 21:50 UTC (permalink / raw)
To: Maciej W. Rozycki; +Cc: Dennis Grevenstein, linux-mips
[-- 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 --]
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: unable to handle kernel paging request
2004-10-31 20:13 ` Jan-Benedict Glaw
2004-10-31 22:36 ` Dennis Grevenstein
@ 2004-10-31 22:51 ` Dennis Grevenstein
2004-10-31 23:13 ` Dennis Grevenstein
1 sibling, 1 reply; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 22:51 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: unable to handle kernel paging request
2004-10-31 22:51 ` Dennis Grevenstein
@ 2004-10-31 23:13 ` Dennis Grevenstein
0 siblings, 0 replies; 24+ messages in thread
From: Dennis Grevenstein @ 2004-10-31 23:13 UTC (permalink / raw)
To: linux-mips
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
^ permalink raw reply [flat|nested] 24+ messages in thread
* Unable to handle kernel paging request
@ 2004-03-03 16:33 Paulo Marques
0 siblings, 0 replies; 24+ messages in thread
From: Paulo Marques @ 2004-03-03 16:33 UTC (permalink / raw)
To: linux-kernel
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?"
^ permalink raw reply [flat|nested] 24+ messages in thread
end of thread, other threads:[~2019-11-15 15:41 UTC | newest]
Thread overview: 24+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2007-09-27 16:30 Unable to handle kernel paging request Laurent Vivier
[not found] ` <46FBDA8A.8030109-6ktuUTfB/bM@public.gmane.org>
2007-09-27 16:54 ` Laurent Vivier
[not found] ` <46FBE055.2040904-6ktuUTfB/bM@public.gmane.org>
2007-09-30 9:07 ` Avi Kivity
[not found] ` <46FF6764.5090502-atKUWr5tajBWk0Htik3J/w@public.gmane.org>
2007-10-01 6:58 ` Laurent Vivier
-- strict thread matches above, loose matches on Subject: below --
2019-11-15 15:26 unable " Lange Norbert
2019-11-15 15:41 ` Jan Kiszka
2016-09-15 14:08 Mark Gavalda
2016-09-15 16:05 ` Chris Mason
2016-09-15 20:12 ` Mark Gavalda
2016-09-16 2:45 ` Duncan
2005-01-12 18:43 Unable " Praedor Atrebates
2004-10-31 18:42 unable " Dennis Grevenstein
2004-10-31 19:15 ` Jan-Benedict Glaw
[not found] ` <Pine.GSO.4.10.10410311947570.9753-100000@helios.et.put.poznan.pl>
2004-10-31 19:16 ` Dennis Grevenstein
2004-10-31 19:26 ` Jan-Benedict Glaw
2004-10-31 19:26 ` Jan-Benedict Glaw
2004-10-31 19:55 ` Dennis Grevenstein
2004-10-31 20:13 ` Jan-Benedict Glaw
2004-10-31 22:36 ` Dennis Grevenstein
2004-10-31 23:59 ` Maciej W. Rozycki
2004-11-01 21:50 ` Florian Lohoff
2004-10-31 22:51 ` Dennis Grevenstein
2004-10-31 23:13 ` Dennis Grevenstein
2004-03-03 16:33 Unable " Paulo Marques
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.