2

I am trying to diagnose an interesting problem that affects perhaps a dozen or more identical computers. We have an increased rate of kernel panic errors lately, yet I cannot figure out how to diagnose the cause.

The situation is that we purchased numerous identical machines, and we're running Debian Wheezy on these machines to play flash files and AVI content; they sit all day just playing a series of fullscreen visuals. We've been buying these machines for a while (it's an LG-made signage computer) but in the last month we've had a huge increase in kernel panic errors.

I've taken a photo of each error and generally they cite a fairly random process each time. It's been ntpd, or mplayer, or any number of other seemingly-unrelated processes. When the crash dump outputs to the screen I cannot see anything that definitively identifies why these crashes might be occurring.

So I ran memtest86 on the machines, on perhaps 8 of them (all machines that had previously suffered a panic) and found no errors. fsck returns no issues with the filesystem.

I am asking very humbly, as a person with not much experience dealing with linux crashes, for advice on how to try and identify the source of this problem.

  • Originally it seemed correlated with HDMI output, but we switched to VGA output and after a few days of stability, we had three kernel panics
  • The chip is an i5-520M processor running Intel HD Graphics, so as far as I know it's supported by the Wheezy intel driver in kernel 3.2, but perhaps I am mistaken.
  • The panics DO appear correlated with machines manufactured around the same time, which suggests possibly a hardware problem, but for the life of me I cannot discover it.

I did a bunch of reading on kdump but I'm having trouble figuring out how to install it on Debian.

Is there anything else I can try? Any logs I can try and plumb through after a kernel-panic'd machine has been removed from site and returned to my office? I would love to either rule out software or hardware and get closer to an explanation. If we have to return these computers or totally remove them from our operations I'd like to be as informed as possible as to why.

Apologies for the vagueness of my question, but thank you very much for any help.

1 Answer 1

0

I eventually discovered the answer to this problem.

Pouring over dmesg logs I realized that in some cases the SSD entries had a different hex string depending on what engine I was connected to.

Since we were imaging these engines with a standard-sized partition, I hadn't realized it but some of the engines featured 64gb Sandisc U100 SSD's, and some had 32gb drives.

Only the 64gb versions were suffering kernel panics. So I don't know if it was a problem with our kernel, or the SSD firmware, or what, but our solution is now definitively hardware and we can swap the drives and make everything happy.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .