Archive for December, 2007

US Consumer Standards – A call for information

Friday, December 28th, 2007

So, I’m looking for some information about consumer standards organizations and the responsibilities of corporations in the US, under US law. Here’s a story…

I’ve been receiving “VEHICLE WARRANTY EXPIRATION” mailings from a company, claiming it’s in relation to a car that I may have purchased recently. The notice is from the “National Vehicle Headquarters” and comes on an official looking green piece of paper. Of course it’s a scam. This is obvious without even looking at it, however, the question is what to do next about it.

So I called them. And left a message. Then they called me, and we spoke at some length, and also to their management. Right before I had them take me off their list, I was able to ascertain that they got my information from Transunion (a US credit reference company, for those who don’t know – those outside of the US perhaps), and I asked them about the morality of sending out such notices. I asked them how they feel the poor, undereducated, and also certain senior citizens, might respond to such officialesque mailings, and whether they thought their actions were those of a responsible company.

I also asked them who regulates their industry. This is where we both drew a blank. In Europe, these actions would almost certainly be illegal, and in the UK, the company would be investigated by the Office of Fair Trading for false advertising. I’m quite sure that they’re running afoul of certain interstate commerce legislation, although I’m not sure of what yet, and would love to know who I should write to, if indeed there is anyone who can annoy these people on my behalf. I could just ignore them, but it’s the holiday season, and ’tis the time to spread the cheer by helping to do something about such monsterous sharks.

Jon.

HOWTO: Drive a convertible in a New England winter

Saturday, December 22nd, 2007

Photo: Driving an MX-5 in a New England winter.

So we’ve had a bit of snow over the past week, especially last Thursday. I was out earlier shoveling snow for the second time, all in the aid of driving my MX-5 in convertible mode, in the middle of winter. Zoom Zoom Zoom!

The first thing you need to know about New England winter is that it’s nothing like ye olde England winter. Here, we have actual snow – not frozen drizzle – and it comes down a few feet at a time, when it feels like it. The roads are generally cleared reasonably quickly (although in MA, they like to wait until the storm is over, which is ridiculous), but remain somewhat slippery, and obviously outside parking is quickly swamped.

I had my first real “digging out” experience on Tuesday. The weather having been bad enough to keep me from going outside over the weekend, and the several feet of snow covering my car having frozen into thick layers of ice, meant that it took 4 hours to get the car out again. At one point, the wheels were turning but the car was absolutely stuck. And I went through 4 packets of ice melt in the process.

But I learned a lesson. If you’re going to dig out, you need to do an all or nothing. There was more snow. This undid a lot of Tuesday’s effort. So, last night, I went out at midnight and spent a few hours completely removing all of the snow and ice from my parking – including many buckets of warm water, and scraping away of every last bit of ice. I shall now endeavor to keep it like this, and clear immediately after snow, because that’s the only way to prevent it getting that bad in future.

Anyway. A car covered in snow isn’t very usable as a convertible. It takes me about 45 minutes to fully desnow and deice a snow covered vehicle, dry her, reassure her that she’s still loved, and things of this nature. By 2am this morning, my car was completely clean, dry, and the soft top was functional again. I worked all night, then drove into the office, continuing in my pledge that I’m going to have that top down unless it’s actually snowing on me, or I have a passenger not quite as insane as I.

My driving gear consists of multiple layers, a winter coat, hat (with side ear protection), scarf, heavy duty gloves, and sunglasses. I’m still debating getting some ye olde British racing goggles. So far, I can tolerate temperatures of down to -5C (23F) without too much hassle, adding a little wind chill at highway speed, for good measure. I’m probably quite insane, but I’m not letting New England get between me and my Californian wannabe lifestyle.

Jon.

Boston Tea Party – 234th anniversary

Monday, December 17th, 2007

Photo: Jon Masters, displaying Common Sense.

So last night was the 234th anniversary of the Boston Tea party. I went down to the Old South Meeting House, and read some lines as a British “loyalist” (oh the irony…I’m far from it), in a pretentious British accent.

I’m fully aware that Common Sense wasn’t published until January 1776 (although somewhat disturbed that at least one of the folks in character costume did not know who Thomas Paine was – unless he was being highly historically accurate; Paine was unknown until he published said item) but I thought it was amusing to take a copy with me anyway. Afterward, I drank yet more tea, and went down to the Harbor to celebrate. Then, I had dinner at a little restaurant I like, and read some of Paine’s writings, over more tea.

Jon.

Brave New Jon – Photo Update

Saturday, December 15th, 2007


Photo: Thin Jon at Harvard University.

So I guess there’s nothing quite like a photo to show just how much I’ve changed over the last few years – from fat Jon to thin Jon (and there’s no going back now) – this year in particular, and it continues.

Brave New Jon started out as a giant pining exercise (and continues as such), an attempt at self distraction, and a way to do something about her. If you ever wondered why I’ve done all of the crazy things that I have this year, well, don’t wonder, the answer is somewhat obvious. I don’t think I’ll ever quite get over Karin (not having a reason really helps to cut you up inside), but life certainly does seem to move on, whether you always want it to or not.

Fat Jon existed for way too long. A combination of lack of interest in exercise, spending too much time in front of a computer eating junk food, being a meat eater, and trying all the most disgustingly good foods when traveling. To show you what I mean, here’s a historical photo of me at the Computer History Museum, taken back in 2005:


Photo: Fat Jon, at the Computer History Museum.

Since then, I’ve given up meat (I’m a pescetarian, with a slant toward fruitarianism), taken up exercise, changed in countless other ways beyond that person. I don’t even live in the same country any more (though the photos are all taken in the United States, where I used to spend most of my spare time anyway).

Here is a photo taken last weekend:


Photo: Thin Jon at Nantasket Beach.

One thing I thank her for is forcing me to finally do this.

Jon.

Everything you know about interrupts is wrong

Wednesday, December 12th, 2007

So it’s been a while since I wrote one of my “ludicrously technical”(TM) blogs, and I guess that makes it time for a little treatise on modern computing time yet again.

Computers have come a long way over the past few decades, and in particular since the personal computing boom of the 1990s. When I first got involved with computers, they were things like the BBC Master (naturalized Americans: think Apple II, Commodore, and other MOS Technology 6502 based systems), which was very limited indeed and had very little in the way of peripherals one could add. Ok, so I’ve never used punched cards directly – I’m too young for that guilty pleasure.

With the introduction of the IBM PC in the early 1980s (I still remember my dad’s 80386 computer, which he bought in 1988 for 3000GBP – that’s well over $10K in today’s monetary terms – I hated being “forced” to use a PC instead of my BBC, although he probably had the right idea in retrospect!), along came various user-extendable system buses – such as ISA, EISA, MCA, and later PCI, AGP, PCI-X and modern day PCIe used for the vast majority of “home” computing systems). These allowed users to install various add-on “expansion” cards.

Fundamentally, that peripheral card you plug into your computer is nothing more than a circuit board containing a few chips with a bus, or metallic pin, connector on the lower edge of the card. These pins convey signals to the computer, at various points during a “bus cycle”, and depending upon the bus in use, this can be very complicated indeed. One of the things that all of these devices need to do, no matter how complex, or how simple, is to signal to the computer when they need service. The CPU doesn’t just know when this is, it has to be explicitly told.

Interrupts are the mechanism through which devices tell the CPU that they would like to get some service, please, if you don’t mind (and can I get whip on that triple-extra-venti-frappa-interrupt?). Depending on the bus in use, legacy buses especially, an interrupt is simply an electrical signal transition on one of those pins on the lower edge of the card, conveyed to the processor via a bus line.

There are two kinds of legacy interrupt:

*). Edge. These are more common in legacy systems. An interrupt is signaled as the result of a rising (or falling) edge of the electrical voltage transition of the corresponding interrupt line. Only one device can signal an interrupt on the same line at the same time, and it’s possible to miss an interrupt if the processor doesn’t sample the bus at the right moment, or is too late responding.

*). Level. These are very common today. Especially “active low” (low voltage state signals that an interrupt line is active, whereas it’s default is to be pulled up to a higher voltage level). An interrupt is asserted as a voltage state transition and remains asserted until such time as it is cleared. Multiple devices can assert at the same time, after a wire-OR natured fashion, and the line remains asserted until all devices have quiesed from the interrupt state.

The original (XT) PC made use of an Intel 8259-type PIC – Programmable Interrupt Controller – whose job was to rely to the CPU whenever one of many devices had asserted an interrupt. The CPU would only be interrupted once (CPUs typically don’t have more than a couple of interrupt inputs even today – and usually only one of those is actually for normal external interrupts, more on that later on), and would inquire of the XT-PIC for the corresponding line that triggered it.

The XT-PIC (actually two of them, they were usually daisy-chained, limiting total irqs) was a very simple piece of technology but it had its day. Many of us recall actively configuring hardware devices for specific interrupt lines, using physical hardware jumpers to avoid conflicts with other devices, etc. PCI later made the latter easier, because devices could be configured automatically (that really helped to get end-users involved, because they didn’t need to understand).

Other computing systems advanced considerably over the PC Architecture, which is still largely antiquated and a waste of time – but is used by the vast majority of computer users today, so is nonetheless the most relevant. Nobody cares about the OpenPIC used on older PowerPC systems, even if it was ahead of its time. I am only focusing on PC technology here, because it’s what people use, not because I particularly find it the most interesting or the most enjoyable.

After the XT-PIC came the APIC. Intel invented the “Intel APIC Architecture”, which is essentially a fancy way of saying they invented the LAPIC – local APIC – and the IO-APIC, as well as the original APIC bus that was used to connect these two devices together. Every modern Intel-compatible processor has an LAPIC built right into it (and mapped at an address determined via MSR register, with a default up in the 0xFECO_0000 memory range), and this talks to one or more external IO-APICs over a designated bus – used to be the APIC bus, but it’s now the system bus, or the HyperTransport bus in AMD systems.

You can’t do SMP – multiprocessing – without something like an APIC architecture. The IO-APIC(s) in a system all talk to every LAPIC, using a prioritization algorithm to determine which CPU will get to deal with a given interrupt (there’s also a task register for this purpose, but nobody uses it properly). CPUs signal each other with IPIs (special Inter-processor interrupts) via their local LAPIC. End devices signal their interrupt to the processor as follows:

*). Device internally decides to assert an interrupt.
*). State transition on the interrupt line (active high/low, edge/level).
*). IO-APIC receives interrupt at one of its interrupt pins.
*). IO-APIC uses a vector table to map the pin to an IRQ vector.
*). IO-APIC assers interrupt on its APIC bus.
*). CPU LAPIC receives interrupt and vector.
*). CPU calls appropriate vector routine.
*). Operating System signals ACK/EOI.
*). LAPIC acknowledges with IO-APIC.
*). (Operating system might mask directly in the IO-APIC).
*). IO-APIC internally resets the line.

IO-APICs are not that complex, but interrupt routing is. There are many possible ways to hook up an interrupt from a physical device to the corresponding pin on a particular IO-APIC chip (each might support 24 interrupt lines, and there might be up to 6 or more of these in a particular system, though often fewer). Fortunately, the Operating System doesn’t have to guess this because the ACPI tables (provided by the system level firmware – you call it a BIOS in peecee land) supposedly provide comprehensive interrupt routing information.

When Linux boots, and initializes the IO-APIC(s), it reads the ACPI tables, checks the corresponding physical pin routing to physical APIC IDs in the system (every APIC has an individual ID – depending upon the mode it is, determined partly by the maximum number of CPUs in the system, e.g. flat virtual/physical mode, cluster mode, or other horrible modes besides) and wires those up to specific software vectors via the vector tables contained within each IO-APIC. These vectors are used to call different routines for different IRQs – in reality, typically the same routine, just via an extra set of jumping of hoops.

You can see your interrupt configuration on a sensible operating system (read: Linux) via the /proc/interrupts special kernel virtual psedo file:

CPU0 CPU1
0: 105 0 IO-APIC-edge timer
1: 17 32 IO-APIC-edge i8042
6: 0 6 IO-APIC-edge floppy
7: 0 0 IO-APIC-edge parport0
8: 149818 267265667 IO-APIC-edge rtc
9: 0 0 IO-APIC-fasteoi acpi
12: 592506 8616725 IO-APIC-edge i8042
14: 42 4229761 IO-APIC-edge libata
15: 0 0 IO-APIC-edge libata
16: 96132501 1629692 IO-APIC-fasteoi firewire_ohci, radeon@pci:0000:02:00.0
18: 0 15875643 IO-APIC-fasteoi eth0
20: 34727470 163 IO-APIC-fasteoi HDA Intel
21: 5933715 5746 IO-APIC-fasteoi sata_nv
22: 16715 177692 IO-APIC-fasteoi ohci_hcd:usb2
23: 15138783 1130425 IO-APIC-fasteoi ehci_hcd:usb1
NMI: 0 0
LOC: 413043921 418168360
ERR: 0

(notice the NMI line. These are special Non-Maskable Interrupts. They only happen when something really critical happens that needs to be handled right now, even if the CPU is otherwise ignoring interrupts – like the machine is on fire, or something similar is about to happen. Errors are also logged, as are total interrupts on the local APIC).

But this is all wrong on very recent systems. PCIe (PCI Express), PCI-X and PCI standard compliant devices meeting revision 2.2 of the standard mandate the use of Message Signalled Interrupts. But what are these? These are fake memory write operations from devices on the PCI bus. And they are used in order to do away with the need for out-of-band interrupt signalling lines, the hassle that causes, and the extra state machine complexity inherent in their usage.

A modern PCI device asserts an interrupt by signalling an MSI – a fake write to a special address window that is trapped by the PCI bridge, not propagated to the system memory directly, which signals an interrupt assertion message. Interrupts are de-asserted via a special interrupt message. They are not exactly “edge”, the are more “level”, since they are both asserted an de-asserted, but there’s no easy mapping for them in the sense of traditional wire interrupts (I’m sure the PC columnists will continue to missunderstand MSI in their columns).

The IO-APIC will still receive the interrupt, and the processor will handle it, even though it was never a direct assertion of an interrupt pin any longer. Things get more complex in legacy systems (that’s every system you buy today still, pretty much, as the still tend to support legacy PCI devices, or PCI-X, and even if you think your system doesn’t, it probably has ye olde PCI devices on board). In this case, the PCI(-X)-to-PCIe bridge(s) will propagate interrupts that aren’t already MSI(s) in the form of a conversion to Virtual Wire Interrupt Messages. These are pseudo-encapsulated ye olde interrupts, sent as MSIs.

You can tell an MSI on sensible Operating Systems, from the output in /proc/interrupts, or a similar file:

CPU0 CPU1 CPU2 CPU3
0: 1166 0 1 0 IO-APIC-edge timer
1: 1 0 0 1 IO-APIC-edge i8042
3: 10348681 56181 10332107 56041 IO-APIC-edge serial
6: 0 0 0 0 IO-APIC-edge myirq
8: 0 0 0 0 IO-APIC-edge rtc
9: 0 0 0 0 IO-APIC-fasteoi acpi
12: 0 2 1 1 IO-APIC-edge i8042
14: 466688 129920 459730 129979 IO-APIC-edge ide0
16: 0 0 0 0 IO-APIC-fasteoi qla2xxx
17: 557 1102 559 1079 IO-APIC-fasteoi qla2xxx
20: 352354 57654 51367 56437 IO-APIC-fasteoi uhci_hcd:usb2
21: 10 5 6 6 IO-APIC-fasteoi uhci_hcd:usb1, uhci_hcd:usb3, ehci_hcd:usb4
78: 2989449 1567 2854570 1555 IO-APIC-fasteoi megasas
8406: 89 90 1238035 4091 PCI-MSI-edge eth0
NMI: 0 0 0 0
LOC: 133189596 133312432 133346309 133841761
ERR: 0

(MSI interrupts always have high numbers, like 8406, on Linux anyway).

There’s more fun. Modern Linux systems tend to handle interrupts using the special EOI (or “fasteoi” naming), which is a fancy way of saying that you can tell the LAPIC that it’s EOI time and it’ll go tell the IO-APIC concerned to shutup. There’s just one write required to shut up an interrupt and get the next one. Except on even more modern Linux systems, using the realtime-preempt superuberdupermagicalness kernel patchset. These systems handle interrupts in the form of two additional “top half handlers”:

*). Receive the hardware interrupt, schedule a thread.
*). Thread takes care of processing.

Yes, Linux does threaded interrupts. Eat that Solaris, Windows, whatever. But to achieve this transition, interrupts must be masked out when first received (no fast EOI), and then re-enabled after the threaded interrupt handler has done its magic. You can’t call EOI later, because you might be running on a different CPU by then, and you don’t know what you’re EOIing about anyway any more.

This has been a random wibble on modern interrupts. I might turn this into a more comprehensive paper, if there’s interest. I’ve spent the last few weeks reading up on IO-APIC, APIC, PCI, PCI-X, PCIe and a lot more besides. We can discuss PCI sub-ordinate bridge enumeration in depth first fashion later.

Jon.