[W530] Freezes and Random Reboots. CPU or Motherboard?

[RasmusP]

Hi,

I have a W530 with an Intel i7-3840QM CPU. I have two problems with it that I'm trying to debug.

1. Sometimes the computer reboots randomly. In particular, this happens when I stress the Intel HD Graphics 4000 card. For instance, I seem to force a reboot by running Furmark via gputest. There is no issues with the discrete graphics card.
2. Sometimes when I resume the computer from sleep/suspend it works for a second or two and then freezes completely until I cut power and force a reboot. I have mostly experienced this when I suspend the computer over night.

A couple of days ago the local Lenovo-supporter changed the fan on my computer, but the issue remains, although the measured temperature is now lowered by almost 10ᵒC when running mprime to stress the CPU.

I have stress tested CPU (mprime), NVIDIA GPU (Furmark), memory (memtest86+) and hard-disk (SMART) and have not found issues. The Lenovo diagnostics (the Linux Red Hat version) tool report no errors, though I crashes when I try run graphics test (it seems incompatible with my version of OpenCL or something like that...).

Thus far I have been pushing them to change the motherboard of the computer, since I though I having the "Random Power Failure"-bug, but now I'm not so sure. The fact that I can crash my computer by running Furmark on the HD 4000 might suggest that the CPU is faulty, right?

Any help would be appreciated.

Thanks,
Rasmus


BTW: Regarding issue 2 above, I found an option in BIOS-settings that allows the computer to go from suspend to hibernate. I've disabled this, but issue 2 remains.

[RealBlackStuff]

Have you considered using the laptop like a normal user, instead of doing all these useless time-wasting stress tests?
And just in case: Furmark is for testing the GPU, not the CPU.
Maybe your OS is outdated or there is some malware on it?

[rkawakami]

1) From your description that none of the other hardware seems to be the source (CPU, main memory, hard drive), the only thing that might cause unstable operation would be the driver (i.e., software). If you're not running the latest, I'd try searching the Intel web site to see if they have a standard driver for that GPU.

2) Not sure if this is related to 1) or not but there's been some history of problems associated with coming out of standby mode for some memories.

Being a memory test engineer, I would first confirm that you've run the latest version of memtest86+ for at least three full passes. This gives the system enough time to heat up and also allows memtest86+ to run more random data patterns. I say this as the Intel GPU uses system memory, whereas the Nvidia has it's own memory bank. I would also recommend that you trying swapping out the memory with other module(s) and see if your problems go away. While I trust memtest86+ enough to run it on all of the memory I obtain, it still could miss something. For example, I don't believe that there's any test for entering/exiting standby.

@RBS: Stress testing is NOT a useless endeavor and the time to waste is for the OP to decide. Yes, in some cases this will shorten the life of the system, but if reliability is key, then this is the thing to do.

[RasmusP]

First, thanks for your comments RBS.

Have you considered using the laptop like a normal user, instead of doing all these useless time-wasting stress tests?

Your interpretation is not quite the story. The story with issue 1. is that I don't like my computer restarting when I do do normal computer stuff (e.g. play 2D games(!) to relax after a workday; or occasionally when I do real work!).

Issue 2. is also about reliability. If I leave my computer in sleep it is because I want to continue working on the computer in its current state. It's quite annoying

Your answer indicate that you expect far less of your computers and that's fine! For my work I do, however, need my computers to be rock solid. My X200s is and it was 1/3 of the cost of this W530.

Oh, and I run tests to debug the issue to have Lenovo fix it correctly and not just replace my fan again...

And just in case: Furmark is for testing the GPU, not the CPU.

I assume that if you run it with the built-in graphics card it will test the Intel graphics card, no? I'm not an expert and would love to be corrected, but some quick searching suggested that the Intel graphics is the lower part of the CPU chip, but I'm really not sure on this.

Maybe your OS is outdated or there is some malware on it?

I am confident to say that this is not the issue.

[RealBlackStuff]

Apologies for my misinterpretation.
From your description it sounded (at least to me) as if you'd be doing only stress tests and the like.
I have run Furmark many times, but only on T61 or T61p with nVidia GPUs, to check if they are still suitable for a "FrankenPad".
Never ran it on machines with the newer i3/i5/i7 processors that integrate graphics in the CPU.

As to your laptop's bed-manners, what OS are you running?

[RasmusP]

Hi Ray,
Thanks for your insightful comments. They make a lot of sense.

1) From your description that none of the other hardware seems to be the source (CPU, main memory, hard drive), the only thing that might cause unstable operation would be the driver (i.e., software). If you're not running the latest, I'd try searching the Intel web site to see if they have a standard driver for that GPU.

It has been happening for Linux 3.10 & Intel/mesa 9.2.1 to 3.18 and Intel/mesa 10.4.0. I have been to busy to look into this for a year's time.

2) Not sure if this is related to 1) or not but there's been some history of problems associated with coming out of standby mode for some memories.

I guess it saves it in the memory when you put it into sleep so that's a good point. I had thought of it, but ruled it out due to the favorable memtest86+ results.

Being a memory test engineer, I would first confirm that you've run the latest version of memtest86+ for at least three full passes. This gives the system enough time to heat up and also allows memtest86+ to run more random data patterns. I say this as the Intel GPU uses system memory, whereas the Nvidia has it's own memory bank. I would also recommend that you trying swapping out the memory with other module(s) and see if your problems go away. While I trust memtest86+ enough to run it on all of the memory I obtain, it still could miss something. For example, I don't believe that there's any test for entering/exiting standby.

I use memtest86+ v5.0.1. I have 32GB of RAM so a full test is a couple of hours. Should I do the test three times in a row? Or, say, three nights in a row?

I don't really have a spare set of compatible RAMs laying around. But I guess I could test with one block at the time.
Do you believe that Furmark could be a reliable indicator for identifying if a block is defect? It's a lot quicker, since e.g. the suspend-issue happens randomly.

Thanks a bunch,
Rasmus

My RAMs are:

Code: Select all

dmidecode --type memory
# dmidecode 2.12
SMBIOS 2.7 present.

Handle 0x0007, DMI type 16, 23 bytes
Physical Memory Array
	Location: System Board Or Motherboard
	Use: System Memory
	Error Correction Type: None
	Maximum Capacity: 32 GB
	Error Information Handle: Not Provided
	Number Of Devices: 4

## Note 4 entries collapsed into one.
Handle 0x000{8,9,A,B}, DMI type 17, 34 bytes
Memory Device
	Array Handle: 0x0007
	Error Information Handle: Not Provided
	Total Width: 64 bits
	Data Width: 64 bits
	Size: 8192 MB
	Form Factor: SODIMM
	Set: None
	Locator: Channel{A,B}-DIMM{0,1}
	Bank Locator: BANK {0,1,2,3}
	Type: DDR3
	Type Detail: Synchronous
	Speed: 1600 MHz
	Manufacturer: Kingston
	Serial Number: x
	Asset Tag: None
	Part Number: 9905428-105.A00G  
	Rank: Unknown
	Configured Clock Speed: 1600 MHz

[RasmusP]

Apologies for my misinterpretation.
From your description it sounded (at least to me) as if you'd be doing only stress tests and the like.

I only run tests 'cause I want to identify the error so I can have it fixed. As for the misinterpretation, I probably worded it poorly. English is my working language, but not my native language, and I feel that it's starting to show more and more!

Never ran it on machines with the newer i3/i5/i7 processors that integrate graphics in the CPU.

The internets suggested it to me. I ran it the first time this December. It's note looking very pleasant.

As to your laptop's bed-manners, what OS are you running?

Archlinux w/Gnome-Shell, GCC, R, Python, the Intel compilers, Emacs, Firefox and the like. I occationally check it with ClamAV. I did use to use Intel Thermald, which is almost as bad as malware!

[rkawakami]

I use memtest86+ v5.0.1. I have 32GB of RAM so a full test is a couple of hours. Should I do the test three times in a row? Or, say, three nights in a row?

I've always recommended to run three complete passes in one shot (yes; in a row, which for 32GB would be overnight).

I don't really have a spare set of compatible RAMs laying around. But I guess I could test with one block at the time. Do you believe that Furmark could be a reliable indicator for identifying if a block is defect? It's a lot quicker, since e.g. the suspend-issue happens randomly.

Yes, that sounds like it could save you some time. If your system can run the test with one module, then test each module separately. It could be that you have only one that is causing problems.

[RasmusP]

I've always recommended to run three complete passes in one shot (yes; in a row, which for 32GB would be overnight).

Stupid question: Memtest86+ will automatically continue to the next test-battry (say "pass-2") after finishing the first pass, right?

Do you believe that Furmark could be a reliable indicator for identifying if a block is defect?

Yes, that sounds like it could save you some time. If your system can run the test with one module, then test each module separately. It could be that you have only one that is causing problems.

Sounds like a good weekend project!

Is it enough to test the blocks separately or could their be errors with certain combinations? (As I recall, they are from a single set).

[rkawakami]

Yes, memtest86+ should run until you stop it (or there's an error and the program hangs, or if your system overheats and shuts down). I've not yet tried version 5 but I don't expect anything to change in the way the program executes. The different versions have been due to bug fixes and program updates to support new hardware.

[bit_twiddler]

Running memtest86 sounds like a good idea.

If it doesn't show a problem, then you might be running into a kernel bug,
like the following: https://www.libreoffice.org/bugzilla/sh ... i?id=66738

I'm not saying that it is a linux bug, but you are more likely to run into
something like this with Arch which is a rolling release than an LTS release,
like Kubuntu 14.04 or Centos.

In any case, it's easy to use a caddy and boot off the second drive on a W530 so that you
can choose multiple operating systems.

If the memory checks out, than let me know, and I'll be happy to provide
some tips on how to do this while avoiding much pain and aggravation.

[RasmusP]

I finished the 3 passes of memtest86+ and got no errors. It took 17-18h!

The Lenovo guys offered to change my MB card now because they claim the graphics card is on the motherboard. Is that true? I though it was part of the processor? E.g. here. In any case, I'll try the Furmark-test with each of the RAM-blocks.

bit_twiddler,

If it doesn't show a problem, then you might be running into a kernel bug,
like the following: https://www.libreoffice.org/bugzilla/sh ... i?id=66738

I'm not saying that it is a linux bug, but you are more likely to run into
something like this with Arch which is a rolling release than an LTS release,
like Kubuntu 14.04 or Centos.

It's possible that it is a software/kernel/mesa bug. The problem would then have remained over 3.10-3.18, and with both the vanilla kernel and the ck patch-set. Which is entirely possible, but I have assumed this is not the case thus far. I haven't tested with other distros as setting up a working environment takes much time, and I do not have a sure way to reproduce at least the suspend-bug (issue 1 above).

In any case, it's easy to use a caddy and boot off the second drive on a W530 so that you
can choose multiple operating systems.

Indeed. But see above.

If the memory checks out, than let me know, and I'll be happy to provide
some tips on how to do this while avoiding much pain and aggravation.

If you have something in mind, let me know. But let me do the Furtest-debugging of individual RAM modules first.

[rkawakami]

Yes, from what I understand the Intel GPU is integrated into the same package as the CPU. The only good reason I can think of to replace the entire motherboard, as opposed to just swapping out the CPU, would be if the CPU is soldered down onto the board. I don't have a copy of the W530 HMM to know for sure but if I can get some time in a few minutes, I'll download a copy. Then again, it's probably a standard procedure to swap out an entire motherboard that's been fully tested/certified, than it is to change out the CPU. To be done right, the tech would have to run whatever factory diagnostic / QA procedure to verify that the CPU is still good after being installed and that it wasn't damaged due to handling. Then again, changing the entire hardware structure of the laptop would ensure that whatever bug exists on your current board is now gone.

[bit_twiddler]

Just out of curiosity, what version of xserver-xorg-video-intel are you running.
I ran into a nasty suspend-related bug on my T420 (Sandy Bridge, HD3000)
before upgrading to 2.99.something.

Also, what boot parameters are you using?

I'm not familiar with Arch Linux, but perhaps you have taken a look at this page?
https://wiki.archlinux.org/index.php/In ... SNA_issues

Before yanking the motherboard or CPU, I'd suspect the Intel Linux drivers;
they are only now becoming stable, at least on Sandy Bridge, and there have
been interactions between kernel boot parameters and the i915 driver
for some time now.

Of course, if you already have a ticket open with Lenovo, and your warranty
is running out, then that might be a reason to try swapping something,
anyway.

[RasmusP]

Just out of curiosity, what version of xserver-xorg-video-intel are you running.
I ran into a nasty suspend-related bug on my T420 (Sandy Bridge, HD3000)
before upgrading to 2.99.something.

Currently 2.99.917 (the earliest I've run is 2.21.15). I haven't seen the suspend-bug within the last couple of days, though definitely within the last week.

Also, what boot parameters are you using?

Code: Select all

normal setup: elevator=bfq pcie_aspm=force rcutree.rcu_idle_gp_delay=1
alternative setup: nothing unusual

I believe I have seen the suspend-bug on both setups.

I'm not familiar with Arch Linux, but perhaps you have taken a look at this page?
https://wiki.archlinux.org/index.php/In ... SNA_issues

Indeed. It seems I must have tried all of them. At least this is my intel.conf in xorg.conf.d

Code: Select all

Section "Device"
   Identifier  "Intel Graphics"
   Driver      "intel"
   Option      "AccelMethod"  "sna"  # default
##   Option      "AccelMethod"  "glamor"
   Option      "TearFree"     "true"
##   Option      "AccelMethod"  "uxa"
EndSection

I don't know if there has been difference in realized issues over AccelMethod.

Before yanking the motherboard or CPU, I'd suspect the Intel Linux drivers;
they are only now becoming stable, at least on Sandy Bridge, and there have
been interactions between kernel boot parameters and the i915 driver
for some time now.

Well, that would be a nice explanation. I would appreciate comments, if you see any glaring mistakes.

[bit_twiddler]

I don't know if there has been difference in realized issues over AccelMethod.

There have been quite a few suspend/resume bugs posted over the last 18
months related to SNA on SNB/IVB as well as older chipsets.

Since you know how to use xorg.conf, I'd recommend trying UXA
because SNA is still relatively new. It's certainly easier than
yanking the motherboard.

You could also try running glxgears or mplayer under gdb to see if you
can get it to crash that way.

[RasmusP]

I will try to run with uxa for a while. I don't really think it's a software issue, though, but of course it's possible.

However, today the computer froze while I was playing music (with a terminal program) and doing a potentially CPU-intensive git job (in periods the job is intensive). So no graphic intensive jobs (beside the Gnome-Shell (the "deskop-program") which utilizes some simple graphical effects).

From the looks of it, it's the same bug as issue 2 above, but now in the middle of a session rather than when resuming it.
Assuming I saw issue 2, could it then, with some reasonable probability, be a memory-defect given that I successfully passed memtest86+ three times? It seems less plausible to me, but I am not very knowledgeable on hardware.

Thanks,
Rasmus

[bit_twiddler]

I'm afraid that we've the limits of my expertise as far as being
able to help you diagnose this problem. I don't know much about
how memtest86+ compares to actual CPU/GPU usage
as far as stringency goes.

Since the bug is apparently not GPU or suspend/resume
related, your best option may be to have the motherboard
replaced, unless someone on this or another forum
can give you something else to try.

Is Lenovo offering to replace the motherboard, or do you
have to do it yourself?

[RasmusP]

Thanks for the help so far! Indeed the Lenovo technician (as in repair guy) I've spoken to has also not been able to pinpoint it.

Lenovo Support in my home-country has offered to replace the motherboard on-site, and I'm hoping Lenovo Support in my country of residence will honour that ticket (due to a mistake Lenovo Support didn't manage to get a new MB delivered while I was home). Thus, it doesn't really matter other than for the sake of not wasting everybody's physical resources.

Thanks again,
Rasmus

[RasmusP]

I had the motherboard replaced. It helped a bit to begin with. But shortly after the computer failed the Furmark test again, crashing in less than 10min. I tested the RAM blocks individually and found no faulty block. Then I ran test after adding back each RAM block and sure enough one block seemed to cause problems. I removed the block and tested both slots with another block. Finally, I added the defect RAM block again to ensure that it was in fact defect before contacting Kngston. However, Furmark has now been running for 35 minutes without crashing my system.

This is really, really weird. . .

Edit: I might have spoken too soon. When I restarted the system and ran the test again it crashed within 10 minutes. . .

[RasmusP]

Another insightful experiment.

I tested with two modules. I installed the RAM modules in the bottom compartment and I ran Furmark for 40+ minutes without any issues. I then moved the same RAM to the memory slots under the keyboard. The computer restarted within a couple of minutes after starting Furmark!

Does this give any hints as to what might be wrong?

Thanks,
Rasmus

[brchan]

If that is the case, I suspect the ram slot(s) under the keyboard to be faulty, in which case you would likely need to replace the motherboard. However, I would repeat the experiment again to see if this is really the problem.

[RasmusP]

The motherboard was replaced today and I've seen the issue before and after it was swapped.

I did the test a couple of runs each time, but I'll try with the other pair of RAM as well.

[bit_twiddler]

What are the exact RAM part numbers that you are using, and
are they exactly the same?

edit ---> I just noticed the part number that you posted,
does this mean that all of your memory sticks are identical?

In all probability, the memory slots on a W530 are interleaved,
so you would want to populate the motherboard in matched
pairs.

[RasmusP]

What are the exact RAM part numbers that you are using, and
are they exactly the same?

They all look the same and according to the blob above they seem pretty similar.

edit ---> I just noticed the part number that you posted,
does this mean that all of your memory sticks are identical?

In all probability, the memory slots on a W530 are interleaved,
so you would want to populate the motherboard in matched
pairs.

They are all 8GB, Kingston, and look the same. They are from the same set.

Are there more to matching RAM than them having similar characteristics? E.g. do I have to match serial numbers?

In any case, if the RAMs are stable in the bottom compartment, they should be stable in the top compartment as well, right?

[rkawakami]

"Matched sets" should be from the same manufacturer and share the same part number. As for stability, there's no guarantee that a module that works 100% in one socket (compartment), is going to work the same 100% in another. Besides a possibility of a different temperature or electrical environment, there could be something wrong with the socket itself, or the peripheral circuitry associated with that socket.

[RasmusP]

They all share the same part number according to dmidecode: 9905428-105.A00G.

I have been wondering if the temperature could be the issue as the top RAM socket do seem a bit warm after a crash. I will repeat the test without the keyboard enclosing the RAM.

If it is a heat issue, is it then the fault of the RAM or the PC or a user error?

Thanks again,
Rasmus

[rkawakami]

Most likely it's the RAM's fault, but then again you could fault the laptop designers for not taking heat convection into account, or the laptop manufacturer for not running a more thorough characterization of the system and/or a poor quality control environment. For a DRAM, heat is one of the more important variables that can degrade its performance.

That said, it's easy (but maybe not cheap) to swap out the memory modules with another brand and see what happens.

[bit_twiddler]

This may sound like a really dumb question, but when Lenovo swapped your motherboard, did they give you a new CPU, or use the old one? On modern Intel CPUs, the memory controller is on the CPU chip as opposed to being on a separate chip on the motherboard. The memory controller could be flakey, although I don't work for Intel, so I don't know what kind of self-tests the CPU does on start-up.

I haven't heard of anybody having problems like the one that you are having with the upper memory slots on a Sandy/Ivy Bridge, which are very similar architecturally. But, you might check the HMM to see if there is a requirement that you populate one pair before the other.

Also, do you have lm_sensors installed (or an equivalent package) and configured? If so, then it would be interesting to see what something like GKrellM reports on your CPU temperatures (and whatever other
sensors it can pick up.)

At this point, one of the following has to be happening:

1. heat is developing under the keyboard
2. a subtle defect on the CPU chip
3. a thermal or timing fault in your memory chips
4. something we missed, like a requirement that the lower slots
in a W530 be populated first.

[RasmusP]

Most likely it's the RAM's fault, but then again you could fault the laptop designers for not taking heat convection into account, or the laptop manufacturer for not running a more thorough characterization of the system and/or a poor quality control environment. For a DRAM, heat is one of the more important variables that can degrade its performance.

I agree that it could be bad design, but surely I'm not the first to fill up all slots on W530. I believe the moduels I've got are even sold by Lenovo. . . (though I don't know if they were bought from Lenovo). Also, the ram passed memtest86+ three times with no errors, which was a 24+ hour job.

This may sound like a really dumb question, but when Lenovo swapped your motherboard, did they give you a new CPU, or use the old one? On modern Intel CPUs, the memory controller is on the CPU chip as opposed to being on a separate chip on the motherboard. The memory controller could be flakey, although I don't work for Intel, so I don't know what kind of self-tests the CPU does on start-up.

I do not think the CPU was changed. I could try my luck again and ask them to replace the CPU. . . The flaky CPU story seems somewhat more compelling since, though it seems fishy that the error would be so subtle that the CPU could run mprime indefinitely, but not Furmark...

Also, do you have lm_sensors installed (or an equivalent package) and configured? If so, then it would be interesting to see what something like GKrellM reports on your CPU temperatures (and whatever other
sensors it can pick up.)

Yeah. It picks up the five sensors, all on the CPU I think (4 cores plus one on the outside, maybe?). I have never seen them above 70 when running Furmark (I always monitor the temperature when running these test), and I think they are 85-90 with mprime (though I'm less confident on this number).

1. heat is developing under the keyboard
2. a subtle defect on the CPU chip
3. a thermal or timing fault in your memory chips
4. something we missed, like a requirement that the lower slots
in a W530 be populated first.

1. => No issues when running mprime, which you'd think generates more heat.
2. => potentially
3. => potentially. Memtest86+ talks against this. Maybe so does the fact that I've never had a crash when using the NVIDIA card.
4. => I checked now, and did not see such requirements. Normally, I use all four memory slots.

Thanks again,
Rasmus