Odd error on my TS-859 Pro+

[doktornotor]

The fact remains WHY is the block_dump value a non-zero one then default ?!

It is NOT. Feel free to verify by performing a full factory reset, reverting the changes you made for some purpose you still did not explain here.

[evharten]

The fact remains WHY is the block_dump value a non-zero one then default ?!

It is NOT. Feel free to verify by performing a full factory reset, reverting the changes you made for some purpose you still did not explain here.

Well i did, i have it still in factory setup, never touched the SSH before, just logged in and see what 'dmesg' had to say to me.
So havn't modified it with anything, not even QPKG's.

[evharten]

The fact remains WHY is the block_dump value a non-zero one then default ?!

It is NOT. Feel free to verify by performing a full factory reset, reverting the changes you made for some purpose you still did not explain here.

Well i did, i have it still in factory setup, never touched the SSH before, just logged in and see what 'dmesg' had to say to me.
So havn't modified it with anything, not even QPKG's.

But your answer did help me, at least i dont see the messages now no clue why it was turned on by default tho

[schumaku]

1. It's not on by default.
2. It's NOT an error.
3. Not every message in the kernel log is an error.

Still no change of the FALSE and MISLEADING subject? You are strongly encouraged to do ...

Take this as a public moderator warning.

Well i did, i have it still in factory setup, never touched the SSH before, just logged in and see what 'dmesg' had to say to me.
So havn't modified it with anything, not even QPKG's.

...and chiming in after just five posts blaming QNAP of an odd error, and still not correcting the cleraly FALSE statement?

Go away!

[evharten]

1. It's not on by default.
2. It's NOT an error.
3. Not every message in the kernel log is an error.

Still no change of the FALSE and MISLEADING subject? You are strongly encouraged to do ...

Take this as a public moderator warning.

Well i did, i have it still in factory setup, never touched the SSH before, just logged in and see what 'dmesg' had to say to me.
So havn't modified it with anything, not even QPKG's.

...and chiming in after just five posts blaming QNAP of an odd error, and still not correcting the cleraly FALSE statement?

Go away!

1) So you are just accusing me of lying then, i told you already that this nas is completely default, only my 4-bay TS-419P+ has QPKG and stuff, as i use that one for BackupPC and that didnt even had that message.
2) See 3)
3) I asked what it was, error or warning as i've never seen the errors in my life before, and google results weren't conclusive as most are all pointing to disks, and not memory, you cannot blame me for asking something imho, everyone has the right to ask questions, if you answer on it, is ofcourse up to you.

So the topic is still valid, and definitly not misleading, as in my eyes and my opinion (which im allowed to have, in this free world) it is an odd error, as it appeared in dmesg without me doing anything.
After a reboot it went away luckely tho, so probably something went wrong during a early'r firmware upgrade when 3.6.1 came out.
You are btw saying that im blaming QNAP of an odd error, which isnt the true fact, as im asking why and what it is, im not blaming them for an error, im just stating what i see.

And saying go away is quote offensive ofcourse, if you dont want to answer or are thinking that im lying dont answer then, its your good right to skip my posts, thats up to you. You can however NOT tell me to go away, thats not up to you, and not your right.
So a bit more politeness wouldn't hurt you, this is a community forum where we all help eachother, so dont go assuming that i did something which i didnt and accuse me for lying, you know: Assumption is the mother of all **.

Right all that said, problem is at least solved now, i got nothing against you.

[schumaku]

The more you write, the less any message that can pop-up in te kernel log is an error. It's a valid output when block_dmp is set to anything but ZERO.

The fact remains WHY is the block_dump value a non-zero one then default ?!

Agreed, this is the one and only valid question in this cocntext, and should serve as topic title.

It's certainly neither standard (from the base of a few hunded active QNAP NAS in the field I have access to) - so it's certainly not intentional, and unlikely part of the design. Most likley, its set at runtime however - in absence of a sysctl.conf file.

Consider to re-install the NAS firmware using the manual process http://wiki.qnap.com/wiki/Manually_Updating_Firmware

[evharten]

The more you write, the less any message that can pop-up in te kernel log is an error. It's a valid output when block_dmp is set to anything but ZERO.

The fact remains WHY is the block_dump value a non-zero one then default ?!

Agreed, this is the one and only valid question in this cocntext, and should serve as topic title.

It's certainly neither standard (from the base of a few hunded active QNAP NAS in the field I have access to) - so it's certainly not intentional, and unlikely part of the design. Most likley, its set at runtime however - in absence of a sysctl.conf file.

Consider to re-install the NAS firmware using the manual process http://wiki.qnap.com/wiki/Manually_Updating_Firmware

I'll have a go at that indeed, maybe its just a glitch or so during the update, seems pretty straight forward that update, and no dataloss on it, so should be fine
Thanks for that tip!