Admin console not accessable after 15-1 update

[fvdw]

thanks for this info I again learned something today !
I can try to compile ksymoops although the source code is rather old..
From the oops error you can read that the kernel fails when executing a memcpy call. I checked the system map and that fits. However the oops error doesn't contain a back trace and the address that called the function outside the range used by the kernel. probably a function of nzbget

ps kernel 164 is running and nzbget downloading for quite some time already without crash.
The biggest differences between #164 and #199 are that the last one contains support for several netfilter functions and some functions for wireless dongles

Attached the system.map for kernel #200 (i don't have the one form 199 anymore, but 200 is almost same as 199)

[fvdw]

ksymoops is a no go

after some tweaking I could compile it however it gives rubbish output, think not suitable for modern kernels (the most recent version of this prgram is from 2005)

ps kernel 164 + nzbget (12-0) is still running and downloading. It is up and running now for more then 3 hours and downloaded already 3 GB
I added some files that it should continue for at least the next 24 hours.

Using the 199 kernel gave already failure within the hour

[brinka123]

It crashed with the 164 kernel. Same error. Oops 817

Unanble to handle kernel paging request at virtual adress 0009fc28

Attached the dmesg out put.

[fvdw]

that's remarkable, on my nwsp2 it is still running since last evening
A quick look at the log show again a failure during memcpy

On which version of fvdw-sl did nzbget run without a problem ?

[brinka123]

Not shure but it was version 11 or 12 with nzbget 9. It worked fine. It looks like it worked for ages.... :)

Then I upgraded to 15.0 and later added the patches.
Then I upgraded to 15.1 and started this thread. I ran nzbget 9 on this version. Isuses were fvdw console hung and no power reset button reaction.

Not shure whether I used nzb on 15.0 alot....

Will test again with kernel 164. What is your download speed? I set it to 500 kb/sec. Normaly I use 200.
I will verify in the system console whether 164 is realy loaded befor the test starts....

No way to analyse the Oops messages in more detail?? I understand that the dump after the Oops messages reveal the function call tree in the kernel when translated using the .map file...


Regards.

[fvdw]

I need to look at home (I am at work now) in what version we changed the kernel from 2.6.39.4 to 3.9.5

It could be that 11-0 was still using that older kernel

No way to analyse the Oops messages in more detail?? I understand that the dump after the Oops messages reveal the function call tree in the kernel when translated using the .map file...

Not with the output that we have it is clear that the oops happens by calling memcpy function of the kernel however the call is made by a routine outside the kernel therefore there is also no back trace output. The routine that calls the kernel function is inside nzbget..Probably it use wring arguments in the memcpy function causing a memory access violation

[brinka123]

So memcopy..., nice analysis.

Is memcopy written in C or ARM instructions....
Is the implementation changed?

I start a test again with Kernel: Linux 3.9.5 #164 PREEMPT Fri Aug 9 14:52:22 GMT+1 2013

Regards.

[fvdw]

nzbget is now running for 21 hours and downloaded more then 20 GB (fvdw-sl-15-1 nzbget 12,0 kernel 164)

ps kernel linux 3.9.5 was introduced in version fvdw-sl-15-0, earlier versions have a 2.6.39.4 kernel (we can run 15-1 with a 2.6.39.4 kernel if we want)

memcpy is a kernel routine but used very very often, if you use to copy data from one memory address location to another and you use a wrong address you get these kind of errors for instance by a wrong pointer value. The function is called by the application, during compile it nows that the kernel supports this function.
There is one thing if the nzbget code is the problem (using a wrong memcpy function call) then i don't understand why another kernel would not have the problem :scratch

[fvdw]

nzbget 12-0 with kernel 164 is still running...

(I did not limit download speed)

[brinka123]

2nd test with 164 kernel is running for 15 hours now..
Is the kernel not changed between 15.0 and 15.1 ???

Probably the memcpy itself is not the issue. (Although they change the implementation to improve the performance i read). Before the Oops message there goes someting wrong in the paging, see the error.
"Unable to handle kernel paging request at virtual address 0009fc28"

The paging is managed by the kernel. Probably this results in wrong pointer values which are passed by nzbget to the memcpy...

Is it possible to check whether memcpy and memory management implementations are changed in the kernel versions using diff tooling??? Or is the memcpy written in assembly...