[f_d]

I've been using the 10.1, build 1429 leaked OS for a few days now, and I'm very happy about most of the tweaks and fixes, particularly that of battery life: far superior to the 10.0.10.85 release.. But, I've also had my first experiences with "random crashes" with this leak..

I've seen the question on this forum before: if QNX is so stable, why is BB10 crashing and rebooting so much? Yes, crashes and reboots are an annoyance, but I'm not particularly "mad" about the situation because I understand what's happening behind the scenes..

The problem is not QNX.. I've been a QNX user since almost the very beginning: I still have a copy of Qunix (as it was called back then) 1.something on a 5-1/4" floppy disk somewhere.. Back then, it wasn't POSIX compliant, but only sort-of, vaguely, unix-like: standard commands like 'ls' existed, but APIs were quite different and you couldn't expect to easily port a Unix (BSD or SysV styles, back then) over to Qunix, but that wasn't the point... This new OS was a whole different animal: microkernel, hard real time: the performance was phenomenal: I recall running a test suite on an 8MHz XT under Qunix and it literally ran circles around the latest and greatest Intel 80386 machine.. Not only that, it was rock solid stable.. I virtually could not get the OS to crash, but that was then, and this is now.. Back then, an OS had a command line shell as a user interface and to start up other processes, and if you crashed the shell, you simply logged in again and continued where you left off, nothing else in the system was affected. With other "monolithic" OSes, if your program did something bad in "kernel" space, you could kill not just the shell, but the whole system, but with QNX, with a microkernel architecture, "kernel" no longer has the same connotation: it's just a message passer, the real action happens in user space, so if you do the same "bad thing" in QNX, you just crash your own process vs. everything..

Great, but why is BB10 crashing so much you ask? Well, since those days, Microsoft and others have pushed the definition of what an "operating system" is.. Remember the argument? "Windows" is not just a fancy user interface running on top of "DOS", it actually comprises the "operating system".. Things have only gotten more complex over the years.. A mobile OS is not just a kernel and a simple GUI process that allows you to touch icons to start programs, it is a whole ecosystem of interworking processes that provide various "Operating System Services". The inherent stability of QNX is still there: if a single process crashes, the kernel doesn't go bye-bye, it continues to run, but what happens if other processes depend on the crashed process? Well if there isn't a way to gracefully restart the crashed process, or it simply cannot restart for whatever reason, different scenarios might result:

1) The dependent processes may be able to continue working at a degraded capacity (eg, early PlayBook OS, when the audio driver crashed- OS and everything else continued to work just fine, but you'd get no sound until you rebooted),
2) If the crashed process was something critical for user interaction, the system may continue to run, but you'd have no way to interact with it (eg, BB10, touch screen driver crash- no way to interact with or unlock the device, but buttons still worked, other processes still running: you could hold the top button for 3 seconds and power off, but you couldn't do much else), or
3) In rare circumstances, a crashed process may cause a cascade effect and bring down other critical processes, which is when the OS has "crashed"..

Again, this has nothing to do with the inherent stability of QNX: everything that is still able to run actually continues to do so.. Some processes do have the ability to automatically restart if they crash (eg, the Hub), but other things may not. There is also a "watchdog" process in BB10 (the "sanity" monitor) that is probably responsible for the majority of reboots that users are seeing: if a critical system process goes down and cannot be restarted, then the rest of the device may still be running, but you may not be able to use the device, and so, the only course of action to restore usability, is to force a reboot.. Things may be different on other devices: if you have QNX running a vehicle driving down the road at 100 mph and the entertainment system crashes, you probably don't want to automatically reboot the system: just leave the entertainment system crashed and leave the other vehicle control systems running; similarly with medical devices: even if the user interface crashes, you don't auto reboot because the rest of the processes may still be performing life support functions.

So at the end of the day, while reboots are an annoyance, I'm still glad that RIM chose to use QNX as the underlying basis of BB10. Because a mobile OS is a complex entity with many interactions that are needed to produce the amazing set of capabilities that are offered, a failure in just one component may result in loss of system functionality even though a lot of things may still be running just fine behind the scenes.. I think as BB10 matures, RIM will put more error control and recovery mechanisms in, and then we'll really see how the inherent stability of QNX makes BlackBerry 10 a class leader.

[jasonvan9]

Now the question is does it savea log file to send to blackberry every time a reboot occurs? Or is this going to be something that is untraceable and we have to wait until lab guys can recreate the issue to fix it?

Does qnx create log files for later debug?

I'm assuming that a log is created when a watchdog timer times out, and once the phone is restarted it will send those logs to blackberry (assuming you have that option selected) to be debugged and fixed by the time the next update hits

Either way these issues happen on a new OS, and we can rest assured they will be corrected shortly


Posted via CB10

[Richard Buckley]

Now the question is does it savea log file to send to blackberry every time a reboot occurs? Or is this going to be something that is untraceable and we have to wait until lab guys can recreate the issue to fix it?

Does qnx create log files for later debug?

I'm assuming that a log is created when a watchdog timer times out, and once the phone is restarted it will send those logs to blackberry (assuming you have that option selected) to be debugged and fixed by the time the next update hits

Either way these issues happen on a new OS, and we can rest assured they will be corrected shortly


Posted via CB10

Yes there are log files, and I've read about users being asked to send them in. Don't know if that is true, but a ticket has been raised on the issue so I assume that it is.


Posted via CB10

[Vector-SS]

OK, that post was intense, but I definitely need to re-read it tomorrow with my morning coffee to comprehend it.

Posted via CB10

[polytan02]

OP,

I don't know what kind of crashes or reboot you are experiencing but during the last months of Z10 use, I simply had NONE.

Maybe this is because I switch off my device at night every night?

Posted via CB10

[Innovatology]

Apparently the reboots are caused by an over-zealous security watchdog task. It probably thinks it has detected some sort of intrusion or tampering and, though the cause is mistakenly detected, the reboot is by design.

[raw_dog]

Thanks. This is one of the more understandable posts concerning how QNX works as an operating system. I always enjoy reading solid technical material that doesn't try to be too high brow.

[notfanboy]

Trouble is, the same line of reasoning can be used to make excuses for iOS and Android stability. Imagine a thread on an Apple forum titled "Mach 3 microkernel and iOS stability" or "Linux kernel and Jellybean stability". This is just passing the buck and naming which layer of the OS is to blame doesn't mean anything to the end user.

[katesbb]

Apparently the reboots are caused by an over-zealous security watchdog task. It probably thinks it has detected some sort of intrusion or tampering and, though the cause is mistakenly detected, the reboot is by design.

LOL, yay... so we (some of us) have a rogue HAL/Agent Smith/Skynet inside our Z10s?

[SDTRMG]

Thanks

Posted via CB10

[f_d]

Now the question is does it savea log file to send to blackberry every time a reboot occurs? Or is this going to be something that is untraceable and we have to wait until lab guys can recreate the issue to fix it?

Does qnx create log files for later debug?

I'm assuming that a log is created when a watchdog timer times out, and once the phone is restarted it will send those logs to blackberry (assuming you have that option selected) to be debugged and fixed by the time the next update hits

Either way these issues happen on a new OS, and we can rest assured they will be corrected shortly


Posted via CB10

The auto diagnostic submission feature in the settings, if enabled, will send some forms of logging, but the big set of comprehensive logs are not automatically sent unless you open a ticket with BlackBerry and then manually send the log package with the "Help Me" app. If you have a RIM-issued device with a special debug token installed, there's additional log collection capabilities that are activated and they can be set to automatically send.. You *may* be able (I haven't tested this on a non-RIM-issued device without a debug token, so regular users may not be able to do this) to access these logs yourself on a standard consumer device through the e-screen: unlock the e-screen using the various methods described in the forums, go into the QXCDMP log setting screen, turn on the logging, turn on "offline" mode to force the logs to be saved locally, turn on SD card logging, turn *OFF* log encryption (otherwise you won't be able to read them), turn on/off any of the other settings you're interested in, and you'll find .zip files on your SD card containing memory dumps (if enabled) and virtually every single log file available on the system.. I haven't take the time to look carefully at the logs since I did the OS upgrade to see if I can find the reason for the crashes, but I may do that once I get a few spare moments..

[mikeo007]

Trouble is, the same line of reasoning can be used to make excuses for iOS and Android stability. Imagine a thread on an Apple forum titled "Mach 3 microkernel and iOS stability" or "Linux kernel and Jellybean stability". This is just passing the buck and naming which layer of the OS is to blame doesn't mean anything to the end user.

Yes, but I think this thread really needs to be crammed down the throats of the people that keep saying "BUT BUT QNX!!"

QNX is great, it can run nuclear plants, awesome. But as this thread goes to show, QNX only comprises a tiny amount of BB10, and it doesn't seem to help the inherent stability of the OS. Bugs in the upper OS layers can still cause a whole host of problems, even though QNX is rock-solid underneath.

The QNX "engine" may be unstopable, but the Blackberry "car" isn't going anywhere if the wheels fall off.

Just because QNX can run a nuclear plant, doesn't mean your phone can.

[Innovatology]

Just because QNX can run a nuclear plant, doesn't mean your phone can.

Surely there's an app for that. Or should we "port" and sideload the Android version?

[Blackberry_Boss]

Surely there's an app for that. Or should we "port" and sideload the Android version?

LMAO

Posted via CB10

[niravzaveri]

The auto diagnostic submission feature in the settings, if enabled, will send some forms of logging, but the big set of comprehensive logs are not automatically sent unless you open a ticket with BlackBerry and then manually send the log package with the "Help Me" app. If you have a RIM-issued device with a special debug token installed, there's additional log collection capabilities that are activated and they can be set to automatically send.. You *may* be able (I haven't tested this on a non-RIM-issued device without a debug token, so regular users may not be able to do this) to access these logs yourself on a standard consumer device through the e-screen: unlock the e-screen using the various methods described in the forums, go into the QXCDMP log setting screen, turn on the logging, turn on "offline" mode to force the logs to be saved locally, turn on SD card logging, turn *OFF* log encryption (otherwise you won't be able to read them), turn on/off any of the other settings you're interested in, and you'll find .zip files on your SD card containing memory dumps (if enabled) and virtually every single log file available on the system.. I haven't take the time to look carefully at the logs since I did the OS upgrade to see if I can find the reason for the crashes, but I may do that once I get a few spare moments..

I would like to know more about this.

CB10 is a fantastic experience!

[f_d]

Posted via CB10