Skip navigation

Tag Archives: BIOS

So many PC laptops, particularly those in the cheaper range, are now shipping with “special functions” such as screen brightness adjustment and wireless adapter on/off switching as the default action when you press the F1 through F12 function keys. On what planet was this a good idea? What kind of morons were sitting around at HP and Dell going “gee, no one ever uses F-keys, so let’s make them do something else?”

What’s the keyboard shortcut for closing a program? It’s Alt-F4. This has not changed since the days of Windows 3.1, and is a very commonly used keyboard shortcut with anyone that knows what keyboard shortcuts are at all. Not having to shuffle a mouse to the top-right corner of a box to close it literally saves many seconds of effort, and those seconds add up when multiplied across an entire day’s work. Now, however, Dell’s infinite wisdom has decided that the out-of-the-box configuration requires pressing the “Fn” function modifier key to use any of the F1-F12 keys for the functions they have maintained on their own for the past two decades. (Apparently Microsoft isn’t adding any extra combinations for “Alt-Brightness Down” anytime soon.) So, when  I get on a Dell Inspiron 1545 laptop to perform service work, I hit Alt+F4 to close windows and instead of having the intended behavior, I just accidentally turned down the LCD brightness. Now I’m on the hook to press F5 to bump up the brightness again, then hit Alt+Fn+F4 to do what I originally intended.

Oh, but if you think that’s bad, it gets far far worse! Let’s say I’m downloading a big driver file for a printer or display adapter, because these are always hundreds of megabytes in size, yet 98% of the download is extra crap that isn’t required for printing a document or making a video card show cute rotating boxes. I’m waiting on a 200MB HP printer driver to come down the pipe, and while I wait, I’m performing other tasks. I find a file I need to rename for some reason, so I click the file and hit F2 to bring up the renaming function in Windows Explorer.

Guess what? Some complete and total asshats at Dell assigned F2 to be the magical key that disables the internal wireless adapter. Instead of renaming a file as intended, I just killed my wireless connection and lost the entire download. All that time waiting is lost as well, so I now get the privilege of waiting even longer for something that never should have been aborted in the first place. Just to make matters even worse, F2 is immediately above the number 2. Anyone who needs to type a 2 and overshoots the stroke could easily end up killing off their Internet connection instead. HP isn’t much better; while they usually put the wireless switch control on the F11 key instead of F2, F11 is still above the last keys on the number row and is still easy to accidentally press. Other functions such as internal/external monitor switching are almost as annoying, but tend to self-correct when they notice there’s no monitor to switch to, and so are somewhat more forgivable.

In the BIOS settings for most of these systems, an option exists to restore the function keys to their normal function key behavior, as it should be! The user should never have to change a BIOS settings on a factory released computer just to make the keyboard work properly! My problem is that the default setting from the factory is the one which is in favor of accidentally killing off your Internet connection and messing up your screen brightness. In my extremely not-humble opinion, every manufacturer that does this is stupid. No one should purchase these computers. It’s not worth supporting this level of ignorance about how a computer is used. Combine this kind of foolishness with the “ClickPad” garbage that’s being put into lots of laptops nowadays, particularly in HP laptops, and some of the ridiculous keyboard layouts on cheap Compaqs from the past few years, and you have a recipe for a brain-dead, productivity-hostile pile of crap laptops that I wouldn’t accept for free.

Add one more thing to the growing list of “it’s not a bug, it’s a feature” nonsense I’m so tired of tolerating these days. Grumble, grumble.

those seconds

THE  PROBLEM: A Toshiba Satellite L305-S5933 laptop came into the shop recently with a non-functioning internal keyboard and touchpad. The keyboard worked fine in the BIOS and prior to booting an operating system, but in Windows neither device was functional at all, and in the Tritech Service System (a custom Linux distribution we use at Tritech Computer Solutions for checking out computers) keystrokes would be severely delayed or would miss completely. Either way, the keyboard clearly worked okay before an OS fully booted, and stopped functioning when an OS was running. USB input devices work fine.

THE SALT IN THE WOUND: There are posts all over the place mentioning problems similar to this, with theories about Windows updates and BIOS updates and drivers all over the place, but none of them are helpful and none of the posts were solved or had any kind of follow-up. In short, no one seems to have any solid lead on fixing this issue.

THE SOLUTION: In the case of the Toshiba we inspected, the touchpad was bad. The failed touchpad also kept the keyboard from being able to operate while in an operating system. To confirm this, we removed the keyboard and disconnected the touchpad, which immediately caused the keyboard to start operating correctly.

THE TECHNICAL EXPLANATION: On a laptop, the keyboard and mouse (touchpad) are what’s known as PS/2 devices. Since the days of the IBM PS/2 computer, a dedicated chip called the 8042 keyboard controller has existed in PCs, powering two special serial ports, one for the keyboard and one known as an AUX port which is always used for a mouse. Though the 8042 chip is no longer a standalone component, identically functioning circuits are in practically every PC laptop and desktop computer that exists. What does all this have to do with the touchpad knocking out the keyboard? It’s actually quite simple: the 8042 controls both devices, and the defective touchpad was flooding the 8042 chip with garbage data. If one channel is flooding the controller chip with data, the other channel is “starved” of bandwidth and can’t send its information through the 8042 chip. Think of it like someone yelling words rapidly into your left ear while you were also trying to listen to someone talking normally in the right ear. You can’t possibly follow both conversations because one is drowning out the other. That’s how your toasted touchpad can cause your keyboard to not function at all.

HOW WE FIGURED IT OUT: The key knowledge here is that the two PS/2 devices are attached to the same controller chip. Bringing up the “top”  command in the Tritech Service System shows us the CPU usage of running processes in decreasing order of CPU usage by default. We noticed that two of the “kworker” threads were eating 1.5% to 1.8% of the CPU at all times. (A kworker thread is a “helper” program that runs directly from the Linux kernel to help it perform various tasks, not as an actual program.) The next logical step after noticing this unusual behavior from a clean system that has worked very well on every Toshiba Satellite L300-series laptop prior to this one was to unplug the keyboard and touchpad, and see if anything changed (this requires minor disassembly of the keyboard area of the laptop to perform.)

Unplugging the keyboard ribbon cable had zero effect. However, sliding out the ribbon for the laptop touchpad caused the kworker threads to completely cease using CPU. Connecting the keyboard back up and attempting to use it confirmed that removal of the mouse/touchpad from the equation brought back full functionality in the keyboard. Diagnosis: bad touchpad.

One of the reasons that we advocate for aspiring technicians to seek general knowledge about how computers work instead of specific situational solutions like an A+ certification test would target is for situations like this one. The knowledge that the keyboard and mouse run through the same controller chip was the only thing that prevented an average technician from knowing where to troubleshoot further and solve the problem, and the diagnosis could just as easily have been performed in Windows as in Linux.

It’s important to understand as much as you can about the general workings of a computer; the standard PS/2 keyboard/mouse controller chip has been around for a very long time, and is easily ignored by an aspiring technician in an era where many new computers only use USB connectivity and have thrown PS/2 hardware out the window. Don’t ignore something just because it’s slightly obscure or because it’s an old carry-over from the computing days of old! You never know when that obscure knowledge will turn out to be a missing puzzle piece to a confounding and frustrating issue that you’ll waste many hours poking and prodding at.

I previously posted about a problem with my Sylvania G netbook (original model GNET13001 with a VIA C7-M CPU, not the Meso) that I recently upgraded to a 32GB KingSpec 1.8″ ZIF SSD, where it would boot Windows XP just fine, but a Windows 7 installation on the same hard drive would do something extremely unusual: the system would not only fail to boot Windows 7 at all, but the BIOS would not even load and execute the MBR at all, skipping the hard drive ENTIRELY in the boot order.

I figured this out late last night, powered by coffee, Doritos with jalapeno cheddar dip, and lots of forum posts about polyphasic sleep to distract me periodically and break the monotony. The major difference between XP and Windows 7 is the partitioning and MBR code, and the Windows 7 MBR code boots up Windows XP just fine, leaving partition tables as the most likely culprit. I modified the MBR assembly code to output a message indicating that the MBR was loaded and executed, and then halt the system. This way I would be certain that the MBR was executing at all and wouldn’t wonder if the code was somehow tripping over something that caused it to kick right back out. With a partition spanning the full disk, my message showed up. That was expected; XP worked fine, and the partition table was set up in the same fashion that it was under XP. Then, to test and see if we had some sort of issue relating to the cylinder/head/sector geometry values in the raw partition table data, I tweaked the values in the table to be slightly different, and saw no change. Then, to see if we were dealing with a problem with the starting sector for partition 1 being 2048 under Windows 7 instead of 63 under XP, I gradually bumped the partition entry up; first to 64, then 100, 200, 400, 1000, 2000, 2047, and 2048. None of these partition starting sectors caused the boot process to fail. Then, I started trimming the ending of the partition. From 31.6GB to 15GB, then to 4GB. No change, it still tried to boot.

I changed the ending cylinder from near 1000 all the way down to 100 and it stopped booting. YES!

From there, it was simply some intelligent logical bisection of the numbers: 200 failed, but 400 worked. Since 256 is 2^8 (powers of two being very significant) I tried 250, 255, and 256, which also failed. A greater jump straight to 300 passed, though; it was at that point that I realized I was dancing around another important number in terms of computer memory: 2,097,152 KB (4,194,304 512-byte sectors) which is also a power of 2, and happened to be right between the sector counts of 256 and 300 cylinders (these equations are in C/H/S format, and I’m ignoring the first 2048 or so skipped sectors just to annoy you):

256*255*63 = 4,112,640 sectors
300*255*63 = 4,819,500 sectors

With this new information, I changed over to LBA (sector) entry instead, and made the TOTAL number of sectors in this partition 4,194,303. It failed to boot.

When I set the total number of sectors in the first partition to 4,194,304 sectors (exactly 2GB), the Sylvania G loaded and executed the MBR normally, where just one sector less would cause the entire hard drive to be skipped in the boot order.

This effectively means that a stock Windows 7 can never boot on this system without major trickery. I consider this a very severe and stupid BIOS bug. What I don’t understand is how it is possible that this check even exists in the first place. The computer would have to read the MBR from the hard drive into memory and intentionally check the first partition’s size for a minimum amount to make this bug happen, so someone either at VIA, Phoenix (it’s a Phoenix BIOS), or Sylvania (Digital Gadgets, Inc.) had to go out of their way to put this bug into place. Worse yet, there are absolutely no BIOS updates in existence for the Sylvania G, and never will be, so this bug is permanent. Fortunately, if your first partition is larger than 2GB in size, you can blissfully ignore this problem, which means that Linux installations using a compatible partitioning scheme, Windows XP, and Windows Vista all should run on the Sylvania G without hitting this problem at all. Windows 7 is effectively not an option, though. In the next few days, I plan to attempt to overcome this bug and get Windows 7 working on the Sylvania G anyway, as a personal challenge if nothing else.

I am left to ponder what other systems might be having this same issue. The BIOS has no business whatsoever attempting to “verify” my partition table of choice, in my opinion, and I want to know at what point and for what purpose this bug/misfeature was introduced. If anyone has a system that seems to skip the hard drive in the boot order with Windows 7, when Windows Vista or especially Windows XP would work just fine, please leave a comment below with your experiences and insights. I’d love to engage in a discussion with anyone else who feels they may have hit this type of bug.

UPDATE: I have verified that the problem boils down to one single check against the LBA “number of sectors” in partition 1 on the drive being equal to 0x400000 (4194304) or higher, and nothing more. I was able to get Windows 7 to boot normally by copying everything from partition 1 into partition 2, deleting partition 1, then using a hex editor to change byte 0x1CC to 0x40. Since all other parts of partition 1’s table entry are zeroed out, it isn’t seen as a valid partition on the disk, but the BIOS is only checking the DWORD value at 0x1CA-0x1CD to be 0x400000 or greater, so it simultaneously bypasses the bug/misfeature in the BIOS and doesn’t confuse the MBR nor Windows 7 at all, as the partition structure is completely valid. If I was adventurous, I’d shuffle the partition down to sector 2048 and reclaim the missing 100MB, but since I’d lose that space under Windows 7’s out-of-the-box partitioning scheme anyway, and it’s 0.1GB of a 31.6GB SSD, that kind of capacity loss isn’t significant at all.

Since the workaround is as simple as using a dummy entry where partition 1 is supposed to be, this trick should work for any operating system. Just start partitions at number 2 instead of 1, and apply the change 1 with a hex editor when you’re done, and you can have a tiny “first” partition without consequence! The only time you’ll ever need to redo the hack is if you run something that rewrites that portion of the partition table.

%d bloggers like this: