Category: Dell

Strange mSATA SSD behaviour on Dell Latitude E7240

One of our Dell Latitude E7240 exhibited strange mSATA SSD behaviour. Disk requests didn’t complete on time. This computer ran the A13 firmware.

The case was eventually solved by upgrading to the A21 firmware executed from an USB stick as the mSATA SSD was unreliable at this point. Apparently, the A18 firmware corrected some mSATA port settings. Also, this was a good opportunity to rid us of Intel’s SA-00075.

This isn’t the first case where disk behaviour suddenly changes to the worst on Latitude E-series laptops, only to be rectified by a firmware upgrade.

CRITICAL_PROCESS_DIED BSOD on Dell XPS 15 9550

Earlier this week, a student walked into my office with his Dell XPS 15 9550 in hand. Sometimes his computer would behave, and sometimes, during heavy load, it would die with a CRITICAL_PROCESS_DIED BSOD. Dell’s own recovery DVD image was unable to restore the computer to a working order. The support personnel at Dell suggested using Microsoft’s Media Creation Tool to download a Windows 10 ISO image. Burning the ISO image to a DVD and reinstalling Windows made the computer runnable to some degree. As soon as we installed the WiFi driver, we got that dreaded CRITICAL_PROCESS_DIED BSOD again. Googling for “Dell XPS 15 9550 CRITICAL_PROCESS_DIED” gave results about the NVMe disk device driver being a possible culprit. This issue has existed for almost a year and are hardly isolated to a few instances. Maybe the XPS 15 9550 model suffers from poor choice of hardware components or bad hardware design.

FreeBSD/i386, stable/10, OpenSSL from ports, optimized assembly code, Dell PowerEdge 1950, Xeon X5450@3.00GHz, and BIOS 2.5.0

The strange combination of FreeBSD/i386, stable/10, OpenSSL from ports, optimized assembly code, Dell PowerEdge 1950, Intel Xeon X5450@3.00GHz, and BIOS 2.5.0, resulted in core dumps for all applications linked with OpenSSL from ports. Continue reading FreeBSD/i386, stable/10, OpenSSL from ports, optimized assembly code, Dell PowerEdge 1950, Xeon X5450@3.00GHz, and BIOS 2.5.0

Loose camera connector in Dell Latitude E5540

A colleague came into my office claiming the camera in his Dell Latitude E5540 didn’t work. Here’s a link to the Dell Latitude E5540 Owner’s Manual.

After a bit of troubleshooting, I removed the display bezel. Lo and behold, the camera connector was halfway out of its socket. Once I pressed the connector into place, the camera immediately started working. But only after a few seconds the connector dislodged again, and Skype/Windows didn’t detect any camera.

I removed the display, rearranged the camera’s flat cable to lessen the stress, and reconnected the connector. As I began to fasten the display, the camera lost its connection again. Apparently, the socket is slightly too wide or the connector is slightly too narrow, or maybe both, and they slip easily apart.

I removed the display again. I reconnected the camera connector one final time and applied a drop of super glue of the kind I use for security markings. While the glue dried, the camera kept working. After 10 minutes or so, I reattached the display and the display bezel, and the camera was still working. Successful surgery!

Dell Latitude E7240 and Intel Dual Band Wireless-AC 7260

Intel Dual Band Wireless-AC 7260 fails to notify Windows 7 when the SSID changes. The result is that the wireless interface retains the previous and possibly invalid IP addresses and other settings. The latest driver, A11, only a few days old, isn’t helpful at all.

I usually avoid installing Intel’s own utility for managing wireless connections, as I feel this should be left in the capable hands of the operating system and the driver. Maybe I should think twice about that.

The current solution is to manually force Windows into releasing and renewing the IP addresses after switching to a different SSID.

@echo off

ipconfig /release
ipconfig /release6

ipconfig /renew
ipconfig /renew6

Dell Latitude E6430 and the firmware setting for Optimus video

A Dell Latitude E6430 had Windows 7 reinstalled this August, and the firmware was upgraded along to revision A15. Somehow the firmware setting for Optimus video got disabled and I regrettably missed the change.

Today, while upgrading the firmware to revision A16, I spotted the disabled Optimus video setting. Thus, I enabled the setting, and now both the Intel HD Graphics 4000 and the nVidia NVS 5300M graphics cards show up in Computer Management. Just remember to install the Intel HD Graphics 4000 driver prior to installing the nVidia NVS 5300M driver.

Hopefully, all stability issues we’ve seen lately should now be resolved.

I began to question if the firmware update process is always able to restore every setting. The moral of this story is to verify the firmware settings after each upgrade.

Autodesk Inventor Professional 2014 SP1 and Dell Inspiron 7520

A student had recently installed Autodesk Inventor Professional 2014 SP1 on his Dell Inspiron 7520, running Windows 8.1. Inventor refused to run and crashed with a more or less useless crash report.

It turns out that Dell or possibly someone else hadn’t properly installed the driver for the AMD Radeon HD graphics card. Catalyst Control Center was surely missing.

A trip to support.dell.com to download the current driver for the AMD Radeon HD graphics card was required. I ensured that Inventor always run using the high performance graphics card and that power savings are disabled regardless of the charger being used or not.

Inventor Professional 2014 SP1 now runs happy on said student’s Dell Inspiron 7520.

FreeBSD/i386 stable/8 on Dell OptiPlex GX260

None of the below is relevant as of 2014-06-06, other than the possible need of reverting sys/dev/pci/pci.c. I have confirmed that FreeBSD/i386 stable/8 r267147 works as expected on Dell OptiPlex GX260.

If you happen to run FreeBSD/i386 stable/8 on older Dell desktop PCs, like an OptiPlex GX260, you might want to back out r262226 prior to upgrading to the latest revision. The change done to sys/dev/pci/pci.c in r262226 renders the kernel unable to mount the root filesystem.

You’re in the clear if you run 8.4-RELEASE, or stable/9, or stable/10 for this particular hardware. Maybe it’s time to move on to stable/10 or stable/9.

Luckily, none of my PowerEdge servers running stable/8 are affected.

Here’s what you should do (once) prior to running make buildworld buildkernel on affected systems:

cd /usr/src
svn up
svn diff -r 262226:262225 sys/dev/pci/pci.c | patch

The above action will add the character M to your kernel’s global revision number, indicating one or more local changes.

Should sys/dev/pci/pci.c be corrected for this deficiency in the future, you might want to revert the changes made above by running:

cd /usr/src
svn revert sys/dev/pci/pci.c
svn up