Box crashed

Robti

Member
hi all I get in the error log is
Code:
Humax crashed at Fri Jan 26 19:03:26 UTC 2018 - Uptime: 1282
, anything else I could look at, the box was off for about 6 hours and as far as I can tell woke up to record emmerdale at 7pm
 
The T2s do occasionally crash for no parent reason. Unless it happens frequently, just reboot it, say "Oh well, it's only tele" and don't worry about it.
If it happens frequently, there are some techniques to try to find out why.
 
Thanks only had it a couple of months and this is the first crash, ran fixdisk and no errors reported, so will live with it
 
Yep, that's the thing to do. Most peeps on here have reported the occasional crash on their T2s.

Persistent crashes can usually be tracked down.
 
Yep, that's the thing to do. Most peeps on here have reported the occasional crash on their T2s.
It does seem to be just one of those things, along with the occasional lock-up. The one here crashed last night while doing nothing more demanding than playing a recorded programme. Previous entry in the log was back in November, before that July then November '16. I'll do the monthly fixdisk run tomorrow just in case.
 
Last edited:
Is that fact or a guess? How do you know for sure?
We know that network activity can make them crash, but is it always that which causes the crash?
 
Experience and engineering nouse. Yes, okay, it is not possible to rule out other causes entirely and I have even seen an un-networked HD-FOX without a drive freeze, but these events are very rare.

We know network events cause crashes, and therefore that the network interface code isn't as well tested or robust as it could be. Why would that be? Because network abilities were an afterthought, and at the time of market not a significant factor. IIRC DNLA was not included in the original firmware roll-out.

We see plenty of reports of disk faults slowing down HDR-FOXes to a crawl, and I have experienced "RC overload" crashing it, but we don't get reports of disk faults resulting in crashes unless there is also RC activity. Conclusion: the disk interface code is well proven and all the execution paths valid (as you would expect from a mature OS kernel).

If the errant execution of code results in the program counter landing on a random (unplanned) memory location, the result will be unexpected actions, lock-up, or system restart. It is not possible to separate lock-ups from restarts, although restarts could also be triggered deliberately if the system is designed to detect faults and reset in response.

So far I have only talked about mis-execution caused by inadequate programming. This is when an external event or exact combination of events has not been anticipated and accounted for in the code or the testing. Programming cannot overcome mis-execution as a result of hardware failure or disturbance - by which I mean the state of a memory cell or register being altered by a radioactive particle (cosmic rays, ambient radiation, radioactive nuclei in the chip packaging), or the functioning being disturbed by signals (voltage, timing) or power rails being out of specification.

The PSU can become marginal (in which case the whole system will be unreliable), there may be mains-born disturbances (failure will be erratic, and likely other equipment will also be affected), the HDD may go out of spec (failures will be persistent).

On balance, the opportunities for network activity to promote crashes overwhelm all other possibilities unless the crashes are frequent and persist with the network disconnected. The very occasional crash could be triggered by a random event, but that's just noise!
 
Although I agree with all of the above, and thanks for your enlightening deepest analytical thoughts on the subject (no irony intended), I still think that your bald statement "It's network activity that makes them crash/freeze." should have been slightly tempered with the word "often", "frequently" or even "usually".;)
 
On balance, the opportunities for network activity to promote crashes overwhelm all other possibilities unless the crashes are frequent and persist with the network disconnected. The very occasional crash could be triggered by a random event, but that's just noise!
I think you experience crashes much more frequently than some of us and you may be right that your crashes are network related. I think it is a big jump to say that network activity "overwhelm all other possibilities" for crashes in the general case.
 
As far as I am concerned, with the noted caveats, the case is sufficiently clear as to be my position on the matter. Disregard a 30-odd year career in electronics engineering design for military applications as you wish.

Mine is a theory which requires disproof, as opposed to a hypothesis in need of further supporting data.
 
As far as I am concerned, with the noted caveats, the case is sufficiently clear as to be my position on the matter.
You have presented zero evidence to support your conjecture. I have fifty years experience of working with and writing software for computers and thirty years of networking experience but I wouldn't promote something as a theory without some sort of evidence; I would say what you have is a conjecture rather than a theory.
 
You appear to be blind to the observations - observations and reported events are evidence. Are you offering a comprehensive analysis to counter mine in post 8?

I have evidence that network errors increase the incidence of crashes. Data errors would be reproducible. Dicky PSUs would cause frequent misoperation. Everything else are random events.

Regardless of your experience as a programmer, I'm a hardware engineer. I shall say no more - hopefully time will resolve the issue.
 
Last edited:
I can easily accept that network-related glitches are the primary issue in crashes (iPlayer app, take a bow): presumably it's the Humax blob (/usr/bin/humaxtv, 7MB, needs a good disassembling) at fault rather than network-based CF packages taking the blob or the kernel down.

For an example of a non-network crash, I have observed a consistently repeatable hang/crash when stopping or ending play of an imported mp4 when there is a separate .srt subtitle file, regardless of whether the subtitles are being used, so far with 2 video files from different sources, albeit the same talent.
 
Back
Top