Debugging why pps line discipline gets removed after 5 seconds

I got my udev rules all set up to use an NMEA GPS board which provides PPS with ntpd:

SUBSYSTEM=="pps", MODE="0664" GROUP="dialout"
KERNEL=="ttyS0" SYMLINK+="gps0"
KERNEL=="ttyS0", RUN+="/bin/setserial /dev/%k low_latency"
KERNEL=="ttyS0", RUN+="/usr/sbin/ldattach pps /dev/%k"
KERNEL=="pps0" SYMLINK+="gpspps0"

And it almost seems to work great:

$ sudo udevadm trigger -y ttyS0 ; ls -l /dev/gps*
lrwxrwxrwx 1 root root 5 Mar 19 09:43 /dev/gps0 -> ttyS0

What? Where’s the pps device? dmesg (or journalctl) reveals:

[ 4083.237473] pps pps0: new PPS source serial0
[ 4083.237479] pps pps0: source "/dev/ttyS0" added
[ 4086.238700] pps pps0: removed

If I immediately “systemctl start ntp” after triggering udev, it seems to keep it, and ntpd gets to use pps as expected. But that’s not going to work reliably on boot. So, something’s causing it to be removed. After a bit of frusturation, I decided to poke around a bit with the excellent perf-tools

I did a lot of poking around with execsnoop and functrace, but then when I was getting inconsistent behavior, I got to looking at what had /dev/ttyS0 open. A lot of things did. Several ldattach processes! Aha. So, I reread the ldattach man page and am reminded that it resets the line discipline when killed. Presumably udev just doesn’t allow these commands to stay running in the background. So, it seems like running it as a service from systemd is the way to go, e.g: LinuxPPS wiki In my case, I did:

Description=Line Discipline for GPS Timekeeping for %i

ExecStart=/usr/sbin/ldattach pps /dev/%i


And I commented out the line with ldattach in the udev rule.

Satisfying my curiousity about the original Cockroft-Walton voltage multiplier

I was reminded of the Cockroft-Walton voltage multiplier recently, because I was thinking about building a small one for fun, and upon seeing that their development of this started in 1932, I was curious about some of the details of how they built it. In particular:

  • Were there any sort of usable high voltage solid-state rectifiers then?
  • If not, what kind of tube rectifiers were they using?
  • If hot cathodes as I would expect, how did they provide the heater supply isolated at voltages in excess of 100 kV
  • What was the output of their original multiplier?

Turns out their 1932 articles are easy to find and fairly pleasant reading:

The first article is mostly about the high voltage generator, and the second is mostly about what they did with it. In essence they produced about +700 KV and beam currents (positive hydrogen ions) on the order of 10 microamps. Most of the current was lost to corona discharge, they state that it was over half a milliampere. The interesting thing is that they did use a custom-built version of the standard hot cathode vacuum diode. The filaments were each heated by “6-volt accumulators”, which in my understanding probably means a lead acid battery. There are a lot more details about the vacuum system, naturally it takes quite a while to completely pump down the apparatus to operational levels.

Anyway, if you are interested in high voltage gadgetry or experimental physics, you should read the linked papers, they’re quite enjoyable. (Edit: Actually, there are 6 papers in that series, see this search result.)

RF, time-nuttery, test equipment

Rather than just complaining about Linux stuff on my blog, I’m going to start posting more frequently about what I’ve been obsessing over in my spare time:

  • RF and microwave stuff (10 GHz ham transverter).
  • time-nuts stuff (GPSDOs, crystal oscillators, ridiculous time interval measurement).
  • A bad habit of collecting old test equipment
  • .

Some impressions of Ubuntu 13.10 “Saucy Salamander”

Since I have plenty of RAM in my Mac Mini and a fast connection, I decided to torrent the ISO and install it in VirtualBox.

Unlike current versions of Debian, fresh out of the “box” it doesn’t grok resizes of the VirtualBox display.

The magic search thing you get by hitting the Ubuntu logo responds rather slowly. Even after I turned on “3D acceleration” in VirtualBox. At least it helpfully suggests things that I can buy. It appears to be doing network IO with each keystroke (to offer incremental suggestions), but unlike Google search (on their web page), it seems to be slowing down the UI with each keystroke rather than doing that work completely asynchronously.

More playing around with the UI suggests that VirtualBox’s 3D acceleration isn’t enough and it’s just doomed to be slow in VirtualBox.

I continue to be unimpressed with recent Ubuntu changes.

Debian Wheezy (7.1) on Lenovo Ideapad S12

Here’s what I needed to do to get it to work. First, you need proprietary drivers for the 802.11bgn chipset (BCM4312 with LP-PHY). It should be possible to provide this non-free firmware at install time, but I never got that to work so instead I just installed with the wired ethernet and installed this firmware later on the running system by adding the “non-free” and “contrib” repositories to /etc/apt/sources.list and doing:

apt-get update
apt-get install firmware-b43-lpphy-installer

This may require a reboot to take effect, there’s probably another way, but it’s more effort.

You’ll probably also want the proprietary NVidia display driver if you have the NVidia ION chipset variant of the S12. Just follow the instructions at NvidiaGraphicsDrivers for installing the current version using DKMS. Reboot again, or you could reboot once for all three of these changes.

Suspend seems to immediately wakeup due to USB interrupts. Putting the following in /etc/rc.local (and rebooting or executing the script as root) seems to fix that:

for i in 0 1 2 3 ; do
echo USB$i >/proc/acpi/wakeup

Those are the USB controllers, it still wakes up fine from hitting a keypress.

You may also want to add some of the recommended tweaks from powertop. A way to get them in scriptable form is to run it as powertop --html=<filename> option and cut end paste some of that into rc.local. I got things down from about 17 watts to 12 watts on battery.

I haven’t tried to mess with the built-in camera yet.