PC spontaneous freeze and recovery FIXED

[Strayker]

Hi everyone,
This thread is a conclusion to one I posted recently regarding an issue I was experiencing with my Alienware 17 laptop. I decided to make a new thread because I believe that the problem is a generic one, not specific to my make or model, and so the fix I found may help others who experience the same problem I did.

A quick reminder of the problem:
Since buying my laptop last year it has been prone to spontaneously freezing, then recovering after 2-3 minutes. This occurred several times a day and seemed independent of what programs were running or how much stress the system was under. This was annoying for single player games, but far worse for multiplayer as the connection was always severed during the freeze and I never knew whether I was a sitting duck; scary when flying a couple hundred-million credit ship in ED.

The solution:
After checking eventlog, I could see that every freeze was accompanied by this warning, "Reset to device, \Device\RaidPort0, was issued". After researching online I found reference to this and how some people had been able to easily prevent future freezes by simply switching Power Management settings to 'High performance' then selecting...
-Change plan settings
-Change advanced power settings
-PCI Express
-Link State Power Management
-'On battery' and 'Plugged in', make sure these are both switched to 'off'

Great, but I had done this as soon as I got the machine - it's a gaming laptop, battery duration is not the priority here. HOWEVER, I discovered the Link Power Management (LPM) is also a performance option in my Intel Rapid Storage Technology software, which controls RAID hard drives. In here LPM was still listed as 'Enabled'.

By changing this one setting to 'Disabled' (and restarting the laptop as prompted) my freezing has completely disappeared (remember this occurred SEVERAL times a day, and not once since - suffice to say I'm a very happy bunny ).

So there it is. Hopefully this thread might help someone else in the future - particularly as these on-by-default power-saving options are apparently being rolled out on even some desktop machines now...

Sorry this is a long thread, but lastly I would like to thank TorTorden, de Carabas (who suggested checking event logs, something I've never done before - dude I could kiss you! ), and Feldspar who kindly offered advice on this issue. Much appreciated!

That's my monologue over...

Fly safe commanders!
Strayker
o7

[TorTorden]

Nice going.
Nothin better than a fix that doesn't cost any money.

[thebs]

New member, but reading back through the threads and I thought this was a really good one ...

... because I believe that the problem is a generic one, not specific to my make or model ...

You are absolutely and positively correct!

I constantly see this, especially with various OEM Windows Management Instrumentation (WMI) support, and they don't work with Intel (or AMD) for their system and peripheral interconnects and expansions, especially peripherials. OEMs change things and they often fail to obey Intel reference designs and command sets too, especially when the OEM uses a 3rd party Original Device Manufacturer (ODM) -- i.e., the actual designer/fabricator/manufacturer of the boards.

Ergo, your case ...

-PCI Express
-Link State Power Management
-'On battery' and 'Plugged in', make sure these are both switched to 'off'

Under Windows, absolutely turn off PCIe LSPM by default. Only enable it after testing for extensive compatibility. I know that many OEMs will tell you not to do that, especially since it will shave battery time off (but not much), but it's how I solve a lot of issues.

Which you seemingly did. Hence the bigger issue you ran into ...

Great, but I had done this as soon as I got the machine - it's a gaming laptop, battery duration is not the priority here. HOWEVER, I discovered the Link Power Management (LPM) is also a performance option in my Intel Rapid Storage Technology software, which controls RAID hard drives. In here LPM was still listed as 'Enabled'.
By changing this one setting to 'Disabled' (and restarting the laptop as prompted) my freezing has completely disappeared (remember this occurred SEVERAL times a day, and not once since - suffice to say I'm a very happy bunny ).

Yep, as you found out, Intel's own WMI solution in its "reference drivers" (and related software) attempts to contact the SATA ports via the AHCI services (it's still via AHCI, even in RAID mode, long story), and do the same, even though you disabled LSPM in the Windows Power Management, which told the OEM's 'platform' WMI support (using its driver) not to use it.

This happens a lot with Intel platform, graphics, etc... drivers, as well as with GPU drivers for others where the OEM releases its "own" driver sets -- separate from Intel, etc... "reference design" drivers -- so there are not conflicting WMI drivers. It's notorious in the notebook world, even for nVidia. I've been recommending Clevo more and more because they stick with reference nVidia far more than other OEMs, including Alienware-Dell, although YMMV.

It's a real PITA on Windows, because OEMs provide the drivers, not Microsoft -- sans for very basic stuff. That's why it's always ideal to get your drivers from your OEM for your exact model/sub-model, so you don't have conflicting management API calls with a non-OEM driver. Unfortunately a lot of OEMs are behind and just stop shipping updates (or rarely do), so you're now in a pickle.

► Show Spoiler

Linux has a similar problem, but from a completely other angle.

Instead of the OEM providing the WMI driver(s) and support, like for NT in Windows, the Linux kernel provides "unified" drivers -- all ODMs and OEMs work together, on the Upstream project -- so its supports for just about every WMI implementation out there, documented and implemented, very extensive. The problem?

You can get cases where multiple OEMs (e.g., Acer-Gateway, Asus, Dell-Alienare, HP, IBM-Lenovo) use the same ODM (e.g., Clevo, ECS, FIC, Foxconn, etc...) and they use similar IDs, and suddenly the wrong one (especially if the correct one has yet to be implemented as it's so new) or, worse yet, multiple, requiring us to blacklist the incorrect one(s), for that system.

E.g., I had a Lenovo IdeaPad where the kernel had the Lenovo WMI support, but loaded the conflicting Acer WMI first, then Lenovo second, and I had to blacklist the former, to get the second to work. Otherwise I had issues with the keyboard, RFkill (WiFi software kill switch) and suspend just never resumed.

So there it is. Hopefully this thread might help someone else in the future - particularly as these on-by-default power-saving options are apparently being rolled out on even some desktop machines now...
Sorry this is a long thread, but lastly I would like to thank TorTorden, de Carabas (who suggested checking event logs, something I've never done before - dude I could kiss you! ), and Feldspar who kindly offered advice on this issue. Much appreciated

Indeed. Really good catch. Always hit those logs. They often provide the strings to Google and get to possible "root causes."