synaesthesia

You might notice in new versions of apt:
W: GPG error: http://ftp.debian.org testing Release: The following signatures couldn't be verified because the public key is not available: NO_PUBKEY 010908312D230C5F

Go to this link to fix it: http://www.debian-administration.org/articles/174

Short version:
For NO_PUBKEY 8899AABBCCDDEEFF:

# gpg –keyserver keyring.debian.org –recv-keys 8899AABBCCDDEEFF
# gpg –armor –export 8899AABBCCDDEEFF | apt-key add –

Some more information about how to add a key e.g. for your private repository: https://drupal.gulic.org/node/367

ISA interrupt sharing

Arbitrary ISA boards cannot share interrupt lines safely (though several ISA devices integrated onto a single board can).

There are several reasons for this. First of all, the interrupt line may be driven at all times by some other board, causing the first board's interrupt request to vanish; extra hardware would be required on both cards to prevent this.

ISA devices employ edge triggered interrupts, so the interrupt may be missed because it is pulsed after that interrupt was already asserted by another board and latched by the PIC.

The card may lock up (stall) if its interrupt status register is read when no interrupt is pending, causing the host to hang. One requirement of a shared-interrupt device driver is that it has to check interrupt status on all cards assigned to that interrupt.

It is also possible to have spurious interrupts (like a parallel port interrupt caused by external event while no parallel port driver is loaded, or a fluctuation at power up); if something else is on that IRQ line, its interrupt handler will get called. The other interrupt handler will not know how to clear the asserted interrupt in the device, leading to an interrupt storm and lockup.

If you design ISA devices that account for all of the above scenarios, you may be able to get away with sharing interrupts between them (but not with an arbitrary ISA card!)

Under DOS, there is another caveat. If you have several device drivers sharing a software or hardware interrupt, the most recently installed interrupt handler will “chain” to the old handlers. If a device driver takes over a hardware IRQ vector, the other driver probably issued a PIC EOI at the end of its IRQ handling routine. If you then issue a PIC EOI at the end of your routine after calling the other driver, the result will be that an interrupt could be lost. So you would have to be quite careful to ensure that you issue EOI if and only if your board was the one responsible for the interrupt.

Some things you might not know about PCI

A PCI bus only has 4 possible interrupt lines: INTA-D. These are connected to PIC lines (or mapped by the I/O-APIC) and set to level-trigger mode in the ELCR (Edge/Level Control Register) by the system firmware. If you have more than 4 interrupt-driven PCI devices attached to a PCI bus (most systems only have one PCI bus and an AGP bus), at least two of those devices will be sharing a PCI interrupt line. This implies that they share the same CPU interrupt vector.

While PCI devices are required by the specification to have level triggered interrupts so that interrupt sharing is possible, PCI devices are NOT required to support sharing that interrupt line in any sane fashion. So when that CPU interrupt vector is called, it usually will call several interrupt handlers (one for each device on the shared IRQ), and the interrupt handler will attempt to determine whether its card was the one that generated the interrupt. Frequently, there are bugs in logic that result in lockups or unexpected behavior. For example, some cards will lock up if their interrupt reason register is read while an interrupt is not pending. Others will automatically clear the interrupt flag and continue operation when the status register is read during the scan, leading to problems if you needed to service interrupts in a particular order. Better yet, hardware bugs may cause a device to appear to its driver to be the source of an interrupt when in fact it was not, causing lost interrupts from the other device it shares the IRQ with.

ISA DMA
The FreeBSD developer's handbook has a good overview of ISA DMA and the 8237 DMA controller: http://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/dma.html

Plug and Play (ISA)
Plug and Play is now a general PC industry term used to describe any hardware which should require no software installation or hardware configuration on the part of the user. ISA Plug and Play has a very specific meaning, however. The Plug and Play scheme consists of two special ports (0x279 and 0xA79) and a set of Plug and Play registers, implemented by system logic. 0x279 is ADDRESS and 0xA79 is WRITE_DATA. ADDRESS is the 8-bit address of an internal Plug and Play register, and WRITE_DATA is the value to be written.

Note: port 0x279 appears to conflict with the tertiary ISA parallel port; however, Plug & Play writes to this register, while parallel port driver software should only read from it.

The PnP card powers on in sleep mode; it only snoops the bus for writes to 0x279 and 0xA79. When software wants to configure a card, it disables interrupts, writes two zeroes, and then the 32-byte industry Plug and Play key (6A,B5,DA,ED,F6,FB,7D,BE,DF,6F,37,lB,0D,86,C3,61,B0,58,2C,16,8B,45,A2,D1,E8,74,3A,9D,CE,E7,73,39) to port 0x279. (This should be done twice, so that in case a previous key write failed to complete, the internal state machine in the card will be reset). Afterwards, a series of commands referred to as the isolation protocol attempts to isolate a particular PnP card for configuration by repeatedly relocating the PnP READ_DATA port and verifying the checksum of what is read from READ_DATA. If the checksum matches, the card is assigned a unique “Card Select Number” based on its serial number among other things, and the CSN is then used to configure the card. The process is repeated to isolate other PnP cards and configure them.

Most PnP cards also have a separate vendor-defined key that can be sent to place them into software configuration mode outside of the PnP scheme.

Because of the vendor key scheme, and due to the fact that most manufacturers of add-in boards do not bother to store a unique serial number in the board's EEPROM, it is rarely possible to have more than one identical ISA PnP card installed in the same system.

The PnP configuration can be performed by the BIOS, the operating system, or an operating system PnP driver (such as Intel's ICU for DOS).

If the PnP configuration is performed by the BIOS, the hardware resource configuration of the PnP device, as well as a list of all configurations it can support, is exported to the operating system via the 16-bit PnP BIOS interface. The operating system can use the configuration as-is, or it can change the configuration to any of several pre-set configurations provided by the card's PnP EEPROM. If the operating system changes the configuration via the PnP BIOS interface, the configuration will be stored in the ESCD, which is stored in non-volatile memory somewhere. When the system is reset, the BIOS will afterwards use the ESCD values to configure the card. Therefore, changes made to PnP cards in one operating system will persist to another operating system on the same computer via the PnP BIOS and ESCD.

Many systems will leave PnP cards unconfigured. In this case, the PnP BIOS is irrelevant and will show zero PnP cards. This is misleading, because there may very well be PnP cards in the system, but simply that the BIOS did not configure them! In this case, it is necessary for the operating system or driver software such as ICU, isapnptools, or the isapnp driver to use port 0x279 and 0xA79 to find and configure PnP devices.

This is the same case when 'PnP Operating System' or a similar function in the BIOS is set to 'Yes'. This simply means that the BIOS will not configure PnP cards, export cards through the PnPBIOS interface, or make use of the ESCD – thus leaving the configuration of the PnP cards wholly up to the operating system or drivers.

There are several hazards you want to avoid if your system can have its power removed at any point.

– Writing to an EEPROM. If this is to be done, the user should be warned that power removal will corrupt the EEPROM. If this is to be done by firmware (as in IBM Thinkpads and their security serial EEPROM), there should always be a backup EEPROM that can be used in the case that power is removed during the write.

– Hardware that requires several discrete I/O cycles to complete a write to a non-volatile (preserved across boot, and perhaps required by system firmware) region. For example, the PC RTC (Real Time Clock) is notorious for becoming corrupted when a NMI or SMI arrives at the wrong moment due to its index/data register pair design. The 8042 NMI mask bit is there for a reason; use it. The SMM infrastructure allows for restarting I/O instructions, but it does not know anything about the RTC. Therefore, the SMI handler must scan the region around EIP to ensure that the SMI didn't arrive between a write to port 0x70 and a read from port 0x71.

DO:

• Use the correct size and pitch tap to clean up the threads in the block. Make sure the tap is clean, free of burrs, and oiled, and do NOT continue turning it if significant resistance is encountered. A used head bolt with three grooves cut into it can substitute for a tap. You should be able to run it all the way down the hole with your fingers. Be extra careful in aluminum blocks because if the tap bottoms out, continuing to turn it will strip the threads from the hole.
• Make sure the holes are cleaned and completely free of oil and solvent or liquid lock may result.
• Clean the block surface with solvent or oven cleaner, a brass brush, and gentle scraping. Use lint free rags.
• Have the surface of the head machined if the previous gasket was blown.
• Ensure that the head surface is clean and that the cylinders are free of liquid solvent; otherwise when you go to place the head onto the block, the solvent will drip onto the gasket surface and carry carbon with it, compromising the seal.
• Ensure that any guide dowels have been reinserted into the block and that the NEW gasket has been placed over the dowels before lowering the head.
• Use a high quality assembly lube on the head bolt threads and between the bolt head and washer. If a bolt turns roughly, remove it, apply more assembly lube, and tighten it back to the torque for the current stage.
• Allow the assembled engine to rest for 24 hours, then one by one loosen and retorque the head bolts.
• If a bolt simply refuses to turn smoothly up to torque, do not “guess” at the torque. Bring another bolt up to the torque where the problem bolt begins to jump. Then count the number of turns that it takes to bring that bolt smoothly to final torque. Bring the problem bolt to the same starting torque, then apply that same number of turns to the problem bolt.
• Find and fix the overheating or lean running condition that caused the gasket failure. Check factory service bulletins through ALLDATA to ensure that you have taken any steps necessary to prevent repeat head gasket failure.

DON'T:

• Don't use a die on the bolt threads when reusing head bolts. Head bolt threads are cut differently than standard bolts (“J” cut). Clean the bolt threads with solvent and compressed air. If the bolts are TTY (Torque-To-Yield), where torque is specified with an angle, always replace them and be sure to install them with a torque/angle indicator.
• Don't use Scotch Brite or similar abrasive to clean the block surface. On engines that use a MLS (Multi Layer Steel) gasket, this can disturb the OEM mirror finish that is required for the gasket to seal. On ALL engines, allowing the fine aluminum oxide particles to fall into the cylinders and/or oil passages will lead to bearing failure within a few thousand miles because the particles are too small for the oil filter to catch and are extremely abrasive to bearings. (This failure tends to be blamed on other things, like coolant in the oil from the leaking gasket, or that the head was removed without draining the coolant first and the engine started without changing the oil.) If you do this, ensure that all oil holes and cylinders have been covered and taped, and that afterwards you blow the dust off with compressed air before uncovering.
• Don't use an uncalibrated ratcheting torque wrench. Don't use a torque wrench where the target torque is near the end of the torque range of that wrench. It is okay to use normal socket extensions on the torque wrench to reach the head bolts. Don't pay any attention to people who claim that the “twist” in the extension or the length of the extension somehow affects the delivered torque.
• Don't use any kind of gasket sealer unless it is provided with the gasket or otherwise specifically called for. Don't remove the gasket from the packaging until it is time to install it. This keeps it from getting dirty, and some gaskets have built in sealers that begin to set up when exposed to air.

Some tidbits about the Intel Pentium (P5) processor:
– It introduced MSR (Model Specific Registers)
– It introduced TSC (Time Stamp Counter)
– It has two pipelines (thus is superscalar) but executes instructions in-order, so code must be specifically optimized for the P5 pipeline for optimally-performing instruction scheduling
– It has a local APIC (Advanced Programmable Interrupt Controller), but the local APIC is disabled by a CPU pin rather than by software as in P6 and later CPUs (so Linux cannot enable it); the APIC is usually enabled on SMP Pentium boards
– It has Machine Check Exception, but many motherboards have a design flaw that causes false events, so the user must enable it with the 'mce' Linux boot parameter
– It has two significant bugs (FDIV and F00F)
– It introduced split core/IO voltage