Posts Tagged ‘Linux’

XPS 13 Developer Edition (2015): Rushed

July 29, 2015

Dell’s XPS 13 Developer Edition from 2015 has some nice hardware, but it was rushed to market. The machine isn’t usable as delivered. Either no QA testing was done, or an impossible deadline was imposed. I’m pretty sure it was a deadline. It took the managers a while to realize this is a problem, but they finally decided to act by no longer selling it until they fix it. Someone with basic Linux sysadmin skills and some time to install the various fixes can get it working quite well so long as they aren’t a fast typist; key repeats are only mostly fixed as of now. With the fixes, I find it can still fail to resume from suspend, but it doesn’t happen often and leaves nothing logged to indicate the problem. Overall, I like the machine more than I should.

I went for a model with the 1920×1080 display and no touchscreen because I don’t like glossy displays. I do like resolution, and this is plenty for the small size. I’ll be using font anti-aliasing for a while longer; probably could turn that off with the higher resolution model.

Dell shipped it in a cardboard shipping box that distinguished itself by including a plastic handle so it can be carried around like a briefcase. Inside that is the power supply and cable, and a black box. A very nice looking black box. Inside that is the XPS 13 with foam above and a plastic tray below that is very well fitted. Clearly a lot of though went into this, more than I have managed to convey. Underneath the computer is a folded paper on using MS Windows. I know the Developer Edition uses the same hardware as the XPS 13 with Windows pre-installed, but I didn’t expect it would include the same, but useless, documentation. Not a big deal, but maybe a harbinger.

When turned on, the XPS 13 quickly boots and brings up a legal document. Fun stuff. After a short delay, although long enough that I thought it would let me read the document, a video starts playing full-screen. The video cannot be stopped, and trying to switch away doesn’t work. Alt-tab brings up the window switching menu, but it doesn’t switch. I also couldn’t mute the audio or change the volume; I’m used to pressing two keys to get the functions like volume control, but only one was required. I eventually figured that out, but it did make the compulsory video rather annoying. What made it obnoxious was that it was just an animation of logos zooming about put to music that meant nothing.

With the video done, I got back to reading the legalese. I needed to scroll the text, so I got to use the mouse. It occasionally quit working for two seconds or so before accepting more input. There is a fix for this from Dell, but not on the part of their website for supporting purchased products. That is, if you were to purchase a XPS 13 Developer Edition, log into your account on Dell’s site, find the item you bought, and try to download fixes, then you won’t find them. The fixes are on Dell’s website, just not there. It is apparently reserved for Windows related fixes and system firmware, aka BIOS. A search engine is the best way to find the Developer Edition fixes. Once applied, the mouse no longer ignores input, but occasionally when trying to scroll with it, the system will respond like alt-tab is down and cycles through the windows super fast. I have no idea how to reproduce the issue. It hasn’t happened in the last couple of weeks, but I’m not sure it won’t happen again.

Soon after that, I got to try typing. It regularly repeated key inputs until another key was pressed. This didn’t take fast typing to observe. A BIOS update mostly corrects it, but people who type really fast report that the change only mitigates the problem. The issue affects Windows as well. Considering that keyboards are common computer hardware that have generally worked well for decades, and that Dell botched it in 2015, it is amazing the rest of the hardware came out as well as it did. The group within Dell that put Ubuntu Linux on the XPS 13 clearly had a hard time dealing with this hardware.

After this, it was time to update the installed software. The Ubuntu Software Updater ran until it got to grub, then seemed to hang on the update while still responding to user input. After waiting half an hour, I killed it and what seemed to be a related process that was eating processor time. Then I used apt-get from a shell and ran whatever command it told me to run when it complained about some problem. Since then, updates have worked correctly. I have to wonder if an uncorrected hung update would render the system unbootable.

Following that, the system needed updates for the graphics to resume reliably from suspend. I still have an occasional issue with it, but matters greatly improved. A remaining issue is how the screen brightness automatically adjusts: it darkens for a mostly dark frame, brightens for a bright frame, and offers no user configurability at all. I was worried this would be an issue for working with photographs, but the screen’s limited color gamut, at least compared to another display I have, has proven a much bigger issue. I just have to learn to avoid over saturating the color.

Other than that is an occasional crash for no apparent reason. I’ve had it happen shortly after booting the computer and starting to browse the web. It was occurring twice a week, but hasn’t happened in a couple weeks or so; maybe something was fixed.

The XPS 13 Developer Edition was in no condition to ship. Asus did a much better job with their Eee PC line; they might have been limited by their Linux distribution, but they worked fine right out of the box. Still, I’d rather not buy a computer with Windows pre-installed, and I like that Dell is going through some effort to support Linux, including getting patches into the mainline kernel to improve hardware support. I’m guessing the XPS 13 issues were unexpectedly time consuming to fix and management didn’t want to wait.

Replacement I2C kernel module for Raspbian

January 8, 2014

A while ago, I got I2C repeated starts and SMBus support to work from the Linux kernel on a Raspberry Pi. I recently built a new 3.10.25 kernel from the foundation’s kernel fork on Github and updated my own fork of their fork with just the I2C update in a new branch. In the process, I managed to misuse git so that commits now attempt to go to the Raspberry Pi Foundation’s kernel fork rather than my own. I tested the module on the copy of Raspbian that I have. It is running the 3.10.24 kernel, but is quite happy with the new kernel module (or for 3.10.37, or 3.12.24) and my MLX90614 test program. I also built the kernel module for the BMP085, but it looks like that requires more than just a kernel module file to get it working. No big deal for me; I’ll just replace the whole kernel.  I just wanted to see if I could make it really easy for someone else.

To use the updated I2C module, first download it. The file will need to replace the one in /lib/modules/<kernel version>/kernel/drivers/i2c/busses. You may want to keep a copy of what is already there. After copying it, check to see if the i2c-bcm2708 module is loaded. If not, load it up and have fun! If it is, you can either reboot or unload the i2c-bcm2708 kernel module. Before unloading will work, any dependent modules must first be unloaded. It wasn’t loaded for me right after boot, so it hopefully won’t be any trouble.

Update: I finally got the code up on Github. I hope the kernel module has been working out for anyone who has tried it. Please do leave a comment about any success or failures with it. I have yet to get any feedback, so I only have my own test case to claim that it works.

I2C repeated starts implemented on the Raspberry Pi

July 13, 2013

Update: If you just want a kernel module for something close to kernel version 3.10.25, look here.

I’m working on a project that uses the Raspberry Pi and various sensors. One sensor is a MLX90614 IR thermometer; this communicates using SMBus. One of my goals is to avoid making the project specific to the target hardware, the hardware that actually runs my code. I want the code that communicates with the sensors to be Linux specific but not Raspberry Pi specific.

Communication with a MLX90614

Communication with a MLX90614

One of the problems a lot of people have had with the Raspberry Pi is with getting SMBus communication to work. SMBus is built on I2C, a way of managing serial communication between many devices with only two wires: clock and data. I2C is more flexible, while SMBus is made to be more reliable. As part of guaranteeing reliability, mostly in a multi-master setup, SMBus requires the use of I2C’s repeated starts for read operations. The I2C master driver for Linux on the Raspberry Pi does not support this, and I have been unable to find a patch or custom version anywhere that adds support. Most people have solved the problem by using code that directly interfaces with the Raspberry Pi’s hardware, ignoring the Linux kernel support altogether. This solution not only fails to meet my goal of avoiding code specific to the target hardware, it also won’t work well if more than one process on the same host attempts to use the I2c master hardware.

I decided to solve the problem by modifying the Linux kernel’s support for the I2C master of the Raspberry Pi. I succeeded. My implementation may not be the best or bug free (works for me is a weak guarantee), but it does allow for communication with a MLX90614 using the user-space (unprivileged code outside the kernel) SMBus interface provided by Linux. Since examples with SMBus are more difficult to find than I2C, here is my test code. I also tested with a BMP085 sensor using the support for it already in Linux. This sensor uses I2C rather than SMBus, and it also functions correctly. It doesn’t need a repeated start, but it gets one anyway.

To avoid causing extra trouble, I implemented repeated starts for a subset of conditions under which they could be valid. I focused on SMBus communication. With I2C, a slew of messages going back and forth can be requested, all with repeated starts, but this isn’t normally done or required.  Also, the hardware requires that once the first message has begun transmission, the second message be setup in the registers ahead of the stop condition. To make matters worse, there is no interrupt condition for this, so polling in a busy wait is required. I stuck all this inside the bcm2708_i2c_master_xfer() function of i2c-bcm2708.c so it isn’t in the interrupt handler. After the second message is configured, the interrupt handler is used to receive the data. That avoids additional polling at the cost of not allowing additional repeated starts.

If you’d rather see the kernel change in source control, I stuck it on Github. It is a 3.6.11 kernel, but not the latest revision out there. I’m still using it for now. There is no kernel or kernel module for download here because I’m running Gentoo on my Raspberry Pi and I build my own kernels. If I gave you my kernel, you may well find that something doesn’t work anymore.

Raspberry Pi + Linux Interrupt Latency: 10μs

March 1, 2013

I decided I wanted to use a capacitive relative humidity sensor in a project with a Raspberry Pi, but that meant timing the charing or discharging of the sensor in an RC circuit. These things don’t have much capacitance, and the data sheet suggests it might not give good results under 1kHz. That makes it look like it’ll need microsecond timing at least to provide usable data.

I first tried making two consecutive calls to clock_gettime() and found that it takes between 2 to 5μs to complete one call on an otherwise idle Raspberry Pi. This wasn’t good enough, so I figured I’d dip into the kernel to see what could be done. The impact of scheduling processes and context switches should be minimized by solving the problem in the kernel. Thus far, this is the most involved attempt I’ve made at messing with the Linux kernel. The result was a bit messy, but I got it working. If you want a peek, its on Github.

I modified the code in bcm2708_gpio.c to record the time from a free-running timer whenever the output of a GPIO was changed, or an input state change triggered an interrupt. After managing to get the code to do about what I intended (sysfs has an extra directory level that I haven’t figured out), I connected two GPIO lines together, set one to be an input and one an output, and set the edge of the input to falling. There is nothing special about the falling edge for this test, but the edge had to be set to trigger the interrupt. Then I set the output to one, then zero, and checked the results.

I found that the timing showed 10 to 11μs would elapse between the output state change and running the GPIO interrupt handler when an X server is also running. Without X, I saw a latency of just under 9μs. The timer was configured to increment once every 4ns, so its precision should be more than adequate for these results. I suppose I could have added a significant digit. I’m surprised the times were so high; given the times on the consecutive calls to clock_gettime(), I was hoping for something better.

I know there are people who will blame Linux for the poor result, but this result is the system timing itself; it includes the hardware. What I saw in the BCM2835 documentation seemed to suggest the processor has an interrupt vector table with one entry, just like Microchip’s PIC16F84, an old 8-bit microcontroller. If so, that would suggest something else causes so much latency that there wasn’t a point in having a larger interrupt table. Even some of Atmel’s AVR 8-bit microcontrollers, like the ATtiny25, have several entries, so it isn’t expensive to do.

While BCM2835 offers poor interrupt response times, it does have nice graphics, runs Linux, and can run all the development tools needed for all this messing around in the kernel. No microcontroller is going to do that, unless it is part of a Rube Goldberg machine. I did build the kernel on my AMD64 deskunder computer, though. It’s much faster.

My biggest surprise doing all this is that it is possible to cause a segmentation fault in the kernel and not crash a single process. Do it a few times, though, and it might crash something. It logged me out once.

Sun386i computer in Tron: Legacy; could Clu live?

June 5, 2011

I took a closer look at the screen of the computer Sam Flynn finds in Tron: Legacy that soon sends him to this grid place. It looks to be identifying itself as a system based on an Intel 386 processor running SunOS 4.0.1. Evidently this is one of Sun’s old Sun386i computers. This is consistent with the 1989 time frame; such systems were available in 1988. It also seems that security was configured to be somewhat lacking. Why would someone make a user account called “backdoor”?

Kevin Flynn appears to be a user of vi, one of the two text editors that have inspired an almost religious devotion. The other is emacs. One of the files previously edited is called last_will_and_testament.txt in Kevin’s home directory. Was he already worried about Clu, or about the health effects of going in and out of the computer?

I think the Sun386i computer was not the one running that grid setup where the Flynn’s existed for a time. The environment depicted is very intricate and detailed with plenty of the program-processes all running at once. (Tron fiction combines programs and processes into a single entity it calls a program.) Some of those program-processes have very complex behavior, and that may require a good sized program with plenty of data. I doubt it could all fit into 16MB of RAM, which is the most a Sun386i can take.

Further, the Sun386i was connected to a network, or the filmmakers made a mistake. Inside a partly obstructed terminal window is what appears to be output from the command top running on a modern Linux or similar system. Solaris, the successor to SunOS, has a different command, prstat, that it seems does the same sort of thing as top, but with a different formatting of the data. SunOS may have had prstat as well, but I don’t recall; I last used a SunOS/Solaris system over ten years ago.

The output of top shows a process called Xorg, which is very similar to X.Org, the name of a common X server. An X server runs the basic parts of a graphical console on most Unix-like systems. X client programs send commands to the server to draw things on the screen, and the server sends the clients user input. SunOS 4.0.1 has an X server, but it wasn’t X.Org. X.Org is a modern X server that was first released in 2004. I doubt anyone has bothered to port it to an old Sun system from 1988 that is mostly forgotten now. There are other processes on the list, like hald, that also suggest modern software.

The old Sun’s hardware includes an Ethernet interface, and SunOS supports IPv4. With a working Sun386i today, it should be possible to connect it to almost any Ethernet LAN, configure it manually with an IP address, subnet mask, default route, and DNS, and then be able to communicate with the modern Internet that uses IPv4, which is still almost all of it, if the LAN includes an Internet connection. Then telnet could be used to log into a remote machine, such as a modern Linux machine, and run top.

They seemed to give a lot of attention to the details of the Sun computer, so I’m not sure this was a mistake. If it isn’t, then the uptime of a little more than eight and a half days shown by top makes more sense. But that would mean that someone, or some process with access to the Sun386i, connected to and ran top on the remote machine sometime within eight and a half days before Sam Flynn began his adventure on a grid. Might Clu have access to the Sun system? Even if the Sun system isn’t running the grid environment, it likely is in contact with that system. But if Clu can contact the Sun386i, then the system running Clu likely has its own Ethernet interface and IPv4 stack. In that case, Clu wouldn’t need to go trough the Sun system to communicate with the remote Linux system, so maybe this is a mistake.

Maybe the Sun system has been modified by ENCOM so that it can run the grid place. Maybe it runs on a special board plugged into the Sun386i. In that case, Clu might have to go through the Sun system to communicate with the outside world. It does seem like the system would need some modification to have managed to run without hardware or power issues or even maintenance for a couple of decades. Even NASA’s deep space probes that have lasted at least that long have had hardware issues and were given software updates to work around the issues, but those probes were designed knowing that maintenance after launch would not be possible. A Sun computer, however, was made to sit in someone’s office or server farm where maintenance could be regularly administered. It still amazes me NASA made three (?) probes that functioned for over thirty years, and two of them still work and are still providing data about our solar system. I doubt any computer made for high-reliability by the likes of Sun, or HP, or IBM, could last that long without maintenance.

So, anyway, Sam Flynn finds an old Sun386i running SunOS 4.0.1 that could have been bought in 1988, using an unconventional display with touch input, although that was seen in the first Tron movie (1982), and that computer is in contact with a modern Linux system. That could open the possibility that a sequel movie could involve a copy of Clu. Such a movie could also have Rinzler/Tron; the program-process’s luminescent markings changed color as he sunk, but did not go dark.

Easy Peasy: the Linux that isn’t easy

October 13, 2009

I recently tried out Easy Peasy on my Asus Eee PC 901. It promises to be an easy to use system that is well adapted to computers like the Eee PC. Unfortunately, it comes up short of that promise.

I had problems with it right away. I downloaded Easy Peasy 1.5 and used Unetbootin 372 to put it on an SD card. The Easy Peasy site recommends Unetbootin, but the result wasn’t bootin’ anything. All I got was a blinking cursor on an otherwise black screen. Based on what I found in their forums, I used dd to write the Easy Peasy disk image to the card. This makes the card look a lot like a CD to a computer, albeit an 826MB one. That got the Eee PC booting Easy Peasy. It seemed to work well enough, although the touch pad mouse doesn’t move as easily for some reason.

Since it was just a minor issue getting the Easy Peasy image to boot, I decided it was working well enough to install to another SD card. I selected the install option, and after maybe a half hour it was done. The Eee PC rebooted, I told it to use the card, and I got a black screen with a blinking cursor.

That wasn’t enough to stop me because I don’t much care for the Xandros Linux distribution the Eee PC shipped with. I put the SD card into my Gentoo running deskunder computer and proceeded to re-install Grub on the card. That took some trickery. I also had to modify Grub’s menu.lst file and the /etc/fstab file because they referenced the SD card device incorrectly. I had used two cards during the installation. The one with the disk image was /dev/sdc, and the install target was /dev/sdd. Now that the install was over, there would be no disk image, and the root filesystem would be found on /dev/sdc.

I fixed all that up and put the card back in the Eee PC. This time it booted Easy Peasy from the card. After a while, it came up with a text menu like what can be found on Redhat installs a decade old. The age of the interface doesn’t bother me; that it worked a decade ago but not on the much newer Easy Peasy does bother me. It noticed that I had changed menu.lst and presented me with options. Pressing any keys in an attempt to select an option resulted in garbage text being put on the screen, just like from programs that are busy ignoring stdin.

After a while, I decided to use my Eee PC again with the old Xandros. Even with the Easy Peasy SD card removed, I get Grub error 21. Easy Peasy wrecked the Grub configuration on filesystems that I never asked it to mess with. This is a major problem. If you do give Easy Peasy a try and decide to  install it, be prepared for nothing to boot.

Since I still wanted to use the Eee PC, I booted Easy Peasy. I hit a few more keys when the menu came up and got lucky. I really don’t know what I pressed to get past the menu. After the X server came up, I logged in and tried to get the wireless connection to work. It didn’t. It did earlier when I used the Easy Peasy disk image, but it is broken after an install. It seems that it needs to open /etc/Wireless/RT2860STA/RT2860STA.dat, but there is no /etc/Wireless.

In the process, I decided to switch to a virtual terminal for some reason. I didn’t really need to, I just did. I was able to login and get a prompt from bash. But when I tried to return to the X server, all I got was a black screen. I could switch back to the terminal, but X wasn’t being useful. I tried the common keystroke to kill the X server without success. After about a half hour of sitting around on terminal, I found the computer brought up a graphical login on its own. I was logged out of my X session, and X was being useful again. Weird and obnoxious.

Overall, I would have to say that Gentoo is a little easier to install on a regular deskunder than Easy Peasy is on an Eee PC. Gentoo’s directions are clear, well written, and work. Easy Peasy has few directions, they often fail, and you’ve got to figure out how to fix it on your own. I wouldn’t recommend it.

Oh, the included Firefox doesn’t go to the previous page when backspace is pressed. I hate that about the Xandros install.


The wireless problem wasn’t fixed by restoring the missing /etc/Wireless files. After that attempt, I shutdown the system through the graphical interface for the first time. When I later started the system with the intention of seeing if any updates might help, the filesystem was not clean and was mounted read-only preventing the X server from starting. Using the shutdown command from a shell worked fine, but not the pretty GUI.

Don’t touch Easy Peasy unless you are ready to spend time fixing it.

Another update:

I put Eeebuntu standard on my Eee PC a couple months ago. It is working out quite well, and didn’t have the install trouble of Easy Peasy. Compiz gives it plenty of nice eye candy, and it runs acceptably fast. Unfortunately, Compiz and Google Earth don’t seem to play well together. It is no fault of Eeebuntu, and Eeebuntu doesn’t force the use of Compiz.

In any case, Eeebuntu is keeping me happy with my Eee PC for now.

False Steps

The Space Race as it might have been

You Control The Action!

High Frontier

the space colony simulation game

Simple Climate

Straightforwardly explaining climate change, so you can read, react and then get on with your life.