NETGEAR is aware of a growing number of phone and online scams. To learn how to stay safe click here.
Forum Discussion
Kernel BUG on modified Pro Pioneer. Can someone help?
Hello,
For some time I have been having strange lock-ups in my Pro Pioneer. I'm currently running 4.2.19, and I have upgraded memory to 4 GBytes and the CPU to an E6700. I understand that I have voided my warranty and blah-blah. I'm just hoping someone is curious enough to help :-)
For the fisrt time I have managed to catch the kernel message that appears when the instability starts. Any thoughts?
BUG: unable to handle kernel paging request at ffff88114fb07b58
IP: [<ffffffff880c0783>] __d_lookup+0x83/0x130
PGD 8766063 PUD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/md2/md/sync_action
CPU 0
Modules linked in: nv6gpio nv6lcd nv6vpd(P)
Pid: 2855, comm: monitor_enclosu Tainted: P 2.6.37.6.RNx86_64.2.1 #1 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffff880c0783>] [<ffffffff880c0783>] __d_lookup+0x83/0x130
RSP: 0000:ffff88013e7dbcf8 EFLAGS: 00010282
RAX: 000000000000000e RBX: ffff88114fb07b40 RCX: 0000000000000013
RDX: 000000000004170b RSI: 0187321690bc170b RDI: ffff88014fb02780
RBP: ffff88013e7dbd48 R08: 0000000000000000 R09: ffff880109037000
R10: ffff88013e7da000 R11: 0000000000000000 R12: ffff88114fb07b58
R13: 0000000090bec8fd R14: ffff88014fb02780 R15: ffff88013e7dbe48
FS: 0000000000000000(0000) GS:ffff8800afc00000(0063) knlGS:00000000f76056b0
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: ffff88114fb07b58 CR3: 000000010e7f9000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process monitor_enclosu (pid: 2855, threadinfo ffff88013e7da000, task ffff88014fc6f1c0)
Stack:
ffff88013e7dbe38 000000000000000e ffff88013e7dbe48 0000000e3e7dbe38
ffff880109037007 ffff88014fb02780 ffff88013e7dbe38 ffff88013e7dbe38
ffff88013e7dbee8 ffff88013e7dbe48 ffff88013e7dbd98 ffffffff880b7a48
Call Trace:
[<ffffffff880b7a48>] do_lookup+0x58/0x160
[<ffffffff880b8e89>] do_last+0x1a9/0x650
[<ffffffff880ba1a8>] do_filp_open+0x1f8/0x590
[<ffffffff88098ce6>] ? unmap_region+0x146/0x150
[<ffffffff880c4d23>] ? alloc_fd+0x43/0x130
[<ffffffff880ac475>] do_sys_open+0x65/0x110
[<ffffffff880e9865>] compat_sys_open+0x15/0x20
[<ffffffff880249a3>] ia32_sysret+0x0/0x5
Code: d6 8b 15 89 01 70 00 21 f2 48 8b 04 d0 49 89 c4 8b 45 cc 4d 85 e4 48 89 45 b8 75 0a eb 41 48 85 c0 49 89 c4 74 39 49 8d 5c 24 e8 <49> 8b 04 24 44 3b 6b 30 0f 18 08 75 e6 4c 3b 73 28 75 e0 4c 8d
RIP [<ffffffff880c0783>] __d_lookup+0x83/0x130
RSP <ffff88013e7dbcf8>
CR2: ffff88114fb07b58
---[ end trace 4f68e1a5ae5a74d3 ]---
For some time I have been having strange lock-ups in my Pro Pioneer. I'm currently running 4.2.19, and I have upgraded memory to 4 GBytes and the CPU to an E6700. I understand that I have voided my warranty and blah-blah. I'm just hoping someone is curious enough to help :-)
For the fisrt time I have managed to catch the kernel message that appears when the instability starts. Any thoughts?
BUG: unable to handle kernel paging request at ffff88114fb07b58
IP: [<ffffffff880c0783>] __d_lookup+0x83/0x130
PGD 8766063 PUD 0
Oops: 0000 [#1] SMP
last sysfs file: /sys/devices/virtual/block/md2/md/sync_action
CPU 0
Modules linked in: nv6gpio nv6lcd nv6vpd(P)
Pid: 2855, comm: monitor_enclosu Tainted: P 2.6.37.6.RNx86_64.2.1 #1 To Be Filled By O.E.M. To Be Filled By O.E.M./To be filled by O.E.M.
RIP: 0010:[<ffffffff880c0783>] [<ffffffff880c0783>] __d_lookup+0x83/0x130
RSP: 0000:ffff88013e7dbcf8 EFLAGS: 00010282
RAX: 000000000000000e RBX: ffff88114fb07b40 RCX: 0000000000000013
RDX: 000000000004170b RSI: 0187321690bc170b RDI: ffff88014fb02780
RBP: ffff88013e7dbd48 R08: 0000000000000000 R09: ffff880109037000
R10: ffff88013e7da000 R11: 0000000000000000 R12: ffff88114fb07b58
R13: 0000000090bec8fd R14: ffff88014fb02780 R15: ffff88013e7dbe48
FS: 0000000000000000(0000) GS:ffff8800afc00000(0063) knlGS:00000000f76056b0
CS: 0010 DS: 002b ES: 002b CR0: 000000008005003b
CR2: ffff88114fb07b58 CR3: 000000010e7f9000 CR4: 00000000000006f0
DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
Process monitor_enclosu (pid: 2855, threadinfo ffff88013e7da000, task ffff88014fc6f1c0)
Stack:
ffff88013e7dbe38 000000000000000e ffff88013e7dbe48 0000000e3e7dbe38
ffff880109037007 ffff88014fb02780 ffff88013e7dbe38 ffff88013e7dbe38
ffff88013e7dbee8 ffff88013e7dbe48 ffff88013e7dbd98 ffffffff880b7a48
Call Trace:
[<ffffffff880b7a48>] do_lookup+0x58/0x160
[<ffffffff880b8e89>] do_last+0x1a9/0x650
[<ffffffff880ba1a8>] do_filp_open+0x1f8/0x590
[<ffffffff88098ce6>] ? unmap_region+0x146/0x150
[<ffffffff880c4d23>] ? alloc_fd+0x43/0x130
[<ffffffff880ac475>] do_sys_open+0x65/0x110
[<ffffffff880e9865>] compat_sys_open+0x15/0x20
[<ffffffff880249a3>] ia32_sysret+0x0/0x5
Code: d6 8b 15 89 01 70 00 21 f2 48 8b 04 d0 49 89 c4 8b 45 cc 4d 85 e4 48 89 45 b8 75 0a eb 41 48 85 c0 49 89 c4 74 39 49 8d 5c 24 e8 <49> 8b 04 24 44 3b 6b 30 0f 18 08 75 e6 4c 3b 73 28 75 e0 4c 8d
RIP [<ffffffff880c0783>] __d_lookup+0x83/0x130
RSP <ffff88013e7dbcf8>
CR2: ffff88114fb07b58
---[ end trace 4f68e1a5ae5a74d3 ]---
4 Replies
Replies have been turned off for this discussion
- Upgrade CPU to from 65nm to 45nm processors is not guarantee. The original Pro Pioneer PCB is designed for 65nm processors.
- Also do you still get the problem if you put the stock memory back in (and remove the 3rd party memory)?
- Hi Guys,
Thanks for the comments.
It was clear from the start that it was either the CPU or the memory or the combination of both. So while I waited for comments I tried to narrow things down...
The first thing I tried is going back to stock memory. I have left the system like that for 5 weeks and have not gotten a single error or instability!!!
So, the possible causes are:
a) my memory was bad, which I doubt because I tested it very throughly
b) The combination of the E6700 CPU + the memory I picked up was bad. I tend to lean toward this because the FSB runs faster (1100 MHz vs. 800 MHz) with the E6700, and the memory I used was also very fast (SPD has aggressive timings). This could be too much for the ReadyNAS board. I noticed that the SYS temperature went down 2º when I put back the old memory.
So at least I get to keep the faster CPU. I now may try my luck with other memory types, maybe with more reasonable timings. Does anyone know if there is a way to force the FSB to run slower from Linux? All I have been able to do is read the setting, but there does not seem to be a way to control it. - While not one who over clocks PC's, much less NAS boxes (a friend once told me if I wanted faster to buy faster), those setting are usually access either from the BIOS setup or a special program to access the motherboard settings. I don't think you can do either in a ReadyNAS.
NETGEAR Academy
Boost your skills with the Netgear Academy - Get trained, certified and stay ahead with the latest Netgear technology!
Join Us!
