Category Archives: Dell


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 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

FreeBSD VT aka newcons in base/head

Update 2015-01-05:

I was more or less forced to adopt VT, UTF-8, KMS, and DRM2 when I upgraded my laptop from stable/9 to stable/10 in the time between Christmas of 2014 and New Year of 2015. My laptop, a Dell Latitude D531 of mid-2007 design, is equipped with the AMD/ATI Radeon X1270 GPU. What an awesome beast back in 2007/8! :P

Adding the two lines below to /boot/loader.conf, lets me watch the transition from a 80×25 text mode console, to a 80×30 graphics mode console, to a 210×65 graphics mode console, as the bootstrap firmware, the VGA driver, and subsequently, the KMS driver does their magic.


The VT console with the proper KMS driver truly rivals the old sc console in terms of geometry, UTF-8 capability, and speed.

Now, if only the former and latter were true for FreeBSD VMs running inside VirtualBox, which are still forced to run the VT console with the VGA driver or in the old text mode.

Update 2014-08-27:

I compiled and installed r270452 of base/head the other day, and the VT console is faster than ever before in VirtualBox 4.3.12. I imagine the speedups are similar on real hardware.

The VT console can’t compete with the old sc console in terms of speed, but, making room for a new line on a screen full of text, is considerably faster now than earlier this year.

Setting hw.vga.textmode="1" in /boot/loader.conf is even faster if you don’t need doublewidth characters. However, you may feel comfortably with the 30 lines of text provided by the graphical mode.

It’s nice to see the sc and the VT code being merged, making it possible to have both consoles compiled in the kernel for base/stable/10 and base/head. Only one of them may be active at a time, so set your /boot/loader.conf accordingly:

kern.vty="vt" for the VT console, or, kern.vty="sc" for the old sc console.

For last couple of days I’ve been playing with base/head and the VT kernel. It’s refreshing to finally be able to put Unicode with the UTF-8 encoding to use on the console. The console speed, at least when run in VirtualBox 4.3.6, reminds me of the console of the Sun SPARCstation IPCs I used to manage before they all died some years ago. I’ll see if I can find some idle equipment at work that’s not too old and see if the console speed is any different on real hardware. Anyway, this newcons business surely is a step in the right direction.