Why can’t I get easy hardware

When I bought my Latitude I complained that it seemed to me more and more like a mistake — until the kernel started shipping with the correct (and fixed) drivers, so the things that originally didn’t work right (the SD card reader, the shutdown process, the touchpad, …) started working quite nicely. As of September 2011 (one year and a quarter after I bought it), between Linux and firmware updates from Dell and Broadcom, the laptop worked almost completely — only missing par still is the fingerprint reader, which I really don’t care that much about.

Recently, you probably have seen my UEFI post where I complained that I couldn’t install Sabayon on the new Zenbook (which is where I’m writing from, right now, on Gentoo). Well, that wasn’t the only problem I got with this laptop, and I should really start reporting issues to the kernel itself, but in the mean time let me write down some notes here.

First off, the keyboard backlight is nice and all, but I don’t need it – I learnt to touch-type when I was eight – so it would just be a battery waste of time. While the keys are reported correctly, and upower supports setting the backlight, at least the stable version of KDE doesn’t seem to support the backlight setting. I should ask my KDE friends if they can point me in the right direction. Another interesting point is that while the backlight is turned on at boot, it’s off after suspension — which is probably a bug in the kernel, but it’s working fine for me.

Speaking about things not turning back on after suspension, the WLAN LED on the keyboard is not turning on, at resume. And related to that, the rfkill key doesn’t seem to work that well either. It’s not a big deal but it’s a bit bothersome, especially since I would like to turn off the bluetooth adapter only (and since that’s supposedly hardware-controlled, it should get me some more battery life).

The monitor’s backlight is even more troublesome: first problem is deciding who should be handling it — i’s either the ACPI video driver (by default), the ASUS WMI driver, or the Intel driver — of the three, the only one that make it work is the Intel driver, and I’m not even sure if that’s actually controlling the backlight or just the tint on the screen, even though, when set to zero, it turns the screen OFF, not just display it as black. It does make it bearable though.

The brightness keys on the keyboard don’t work, by the way, nor does the one that should turn on and off the light sensor — the latter, isn’t even recognized as a key by the asus-wmi driver, and I can’t be sure of the correct device ID that I should use to turn on/off said light sensor. After I hacked the driver to not expose either the ACPI or the WMI brightness interfaces, I’m able to set the brightness from KDE at least — but it does not seem to stick, if I take it down, and after some time it starts and gets back to the maximum (when the power is connected, at least).

And finally, there is the matter of the SD card reader. Yesterday I went to use it, and I found out that … it didn’t work. Even though it’s an USB device, it’s not mass-storage — it’s a Realtek USB MMC device, which does not use the standard USB interface for MMC readers at all! After some googling around, I found that Realtek actually released a driver for that, and after some more digging I found out that said driver is currently (3.7) in the staging drivers’ tree as a virtual SCSI driver (with its own MMC stack) — together with a PCI-E peer, which has been already rewritten for the next release (3.8) as three split drivers (a MFD base, a MMC driver, and a MemoryStick driver). I tried looking into working on porting the USB one as well, but it seems to be a lot of work, and Realtek (or rather, Realsil) seems to be already working on it to port it to the real kernel, so it might be worth waiting.

To be fair what dropped away the idea from me of working on the SD card driver is that to have an idea of what’s going on I have to run 3.8 — and at RC1 panics as soon as I re-connect the power cable. So even though I would like to find enough time to work on some kernel code, this is unlikely to happen now. I guess I’ll spend the next three days working on Gentoo bugs, then I have a customer to take care of, so this is just going to be dropped off my list quite quickly.

Dell was a definite mistake, and an expensive one

This week, my newly-bought laptop arrived; as I noted I was looking for a computer that had a Trackpoint device, to avoid touching the touchpad while I’m writing. This brought me to exactly two viable alternatives:

  • Lenovo, with their Thinkpad, had a good track record with Linux; they also have usually a decent price (doesn’t mean they are cheap but that they are worth their pricetag) and in general they were my first choice;
  • Dell and the Latitude E65xx series was the second choice; they didn’t have such a good track record, but most people didn’t complain much about them, beside for minor annoyances.

Again, as I said above, Lenovo doesn’t sell directly in Italy, who knows why; unfortunately this is also the cause for their price to be quite higher in Italy in general. Also, I don’t have many options for Lenovo resellers in my area; the nearest one (50Km from here) sent me the price for “the model I asked for” after a week I asked for it: after VAT it was €300 more than the same from Lenovo UK. I also quoted this being the model I asked for because it really wasn’t!

Not only they still forced me to pick up a Windows license (okay, not too nice but I can live with it), but they also forgot to upgrade the RAM to 4GiB as I asked and, quite a bad one, they didn’t provide me with an integrated smartcard reader. Indeed, the first time around the guy at the sales department of the reseller asked me if I was sure to ask for a BTO about that, given that all T510 already had (translated, but literal) “reader of smartcards of SD type, those for photo cameras”. When the price came, they actually were proposing me to buy a T510 and a smartcard reader, from GemAlto and Lenovo branded. Not a ExpressCard reader though, an USB reader. I guess you can tell what the problem is with that; if not, the problem was that I already have an USB card reader, it’s just difficult to use on, say, a train.

So I surveyed the Dell options; they didn’t allow me to forgo on Windows 7 from the website, so I called the hotline and asked for a sales person to help me out; they refused right away to switch my keyboard for an US one, which was unfortunate but bearable, then they told me that they’d let me know if it was possible to avoid Windows; in two days they came back with an offer… for the E6510 with Ubuntu Linux rather than Windows 7, base options (no 4GiB memory, which I asked for, and no webcam, fingerprint reader, RFID reader, which I didn’t ask for and I didn’t/don’t need)… but at a €500 premium over the same laptop from the website with Windows 7. For the same price, I could get the highest-level option, with Core i7, all the extras and so on.

So the Dell arrived, and I started installing Gentoo on it; beside a series of quirks, which I googled up, such as the smartcard reader needing patching of OpenSC/OpenCT to work, or the fact that the RFID and fingerprint readers not working under Linux (with Daniel confirming that there is realistically no hope of getting the new ones to work on Linux any time soon), everything seemed to go fine. The network card is definitely stable and fast; the wireless card required me to create a new firmware ebuild because of the many ucode ebuilds we have in portage, mine was missing, but it was a matter of minutes.

The problem started when it came down to run Xorg. The nVidia card works quite fine with the drivers, so that’s not a problem, but the touchpad, oh the touchpad. For apparently no reason first, the touchpad was being recognised as a simple mouse; and contrarily to what most people told me about the Thinkpad laptops, the touchpad and the trackpoint in Dell’s hardware are not separate (hardware) devices; they appear as separate devices in Linux because the ALPS driver in the kernel splits them after parsing their different protocols. Unfortunately, both the E6400 and the E6500 Latitude models have a new Alps Electric combined GlidePoint device with a protocol that is, as of now, unsupported by the Linux kernel; Ubuntu submitted some patches for it to the kernel but none that works yet. Right now the device is seen as a standard PS/2 mouse and entirely handled in BIOS, without special features or settings.

The second problem came when it was time to turn off the laptop: halting the system causes it to reboot instead; I thought the problem was related to ACPI, so I looked up if there were BIOS updates, and lo and behold, two were around. Unfortunately, applying them is not the usual matter of running flashrom, on a laptop. Dell used to develop Linux tools for their laptops, including firmware update software; as far as I know they were the first vendor doing so. Unfortunately, they either stopped, or this model is not covered, and the only BIOS updates are provided bundled within the Windows-based flasher (which most likely is not the real flasher at all, given that the system reboots itself before flashing both BIOS and the firmware of the Embedded Controller.

Now, not everything goes bad, luckily for me. I mailed Matthew Garrett, to ask him for pointers on what I could try to get it at least to halt properly, and he’s suggested me a git tree to try which I’m now building. He also pointed out that there is at least some work going on to solve the Alps touchpad problem (which makes me hopeful that this will be properly solved before end of the year). And of course he didn’t have to tell me why the external monitor button prints a ‘p’ since I knew the unfortunate reasons already.

On the bright side, the hardware looks, by itself, tremendously nice: the keyboard, while not as good as the Apple Aluminiums is quite solid and nice to write on, the touchpad is not as invasive as on the MacBook Pro, the monitor is gorgeous and it has all kind of expansion ports including eSATA. The battery lasts a lot even on Linux and even without setting up the governors properly, and so on so forth. I just hope the few problems will smooth themselves out soon.

You shall not suspend

This puts the word «end» to my various tries to have suspend to ram working on Enterprise.

Last night I tried the openSUSE wiki page that Slobodan D. Sredojevic linked on his documentation, and while trying to suspend the system in single user mode, without X running or anything, I finally found what causes the freeze after a few seconds from resume: a machine check exception (MCE).

The output is quite clear from the kernel already, the problem is in hardware; mcelog (which is quite useless considering the MCEs don’t get logged after resumes, so if you didn’t copy the output manually you’re screwed) reports it as CPU 0 0 data cache STATUS 0 MCGSTATUS 0, that seems to point to a data cache corruption in the CPU… duh!

I also tried updating the BIOS, just to make sure, but there is no change (and it scared me because it change the Promise controller setup from standard to RAID, and it wasn’t of course able to find any RAID array defined). Seems like my hardware don’t support suspend to ram, for some reason.

Sigh.

Update: I also now tried checking (and fixing) my ACPI DSDT, but that didn’t help. I’m not sure if I should submit my fixes to ASUS, and ask them if they have any clue, but this motherboard (A8V Deluxe) is three years old now, and I’m not sure if they care at all about it anymore.