synaesthesia

– Stable filesystem bookkeeping information should be replicated throughout the disk (such as ext’s backup superblocks).
– File UUID is updated for each file chunk whenever a new block is written.
– All file chunks should be tagged with metadata such as name, MIME type, and UUID, so that corrupted pointers do not prevent the file data from being located with a sequential scan.
– Each file chunk, as well as the entire file, has an embedded CRC that can be used in recovery as well as in detecting hardware (CPU, memory and/or disk subsystem) failure on the fly if enabled.
– User can choose the amount of parity redundancy.
– Data should be striped such that physical failure events are minimized by the parity information. Seek time profiling can be used to automatically determine the striping characteristics. This also ensures that a sequential overwrite does not lead to catastrophe.
– Directories point to files by UUID as well as by inode. Then directories can be reconstructed in a sequential scan.

The OpenAFS 1.4.2 client should be fairly NAT friendly. AFS only has UDP callback traffic unless you are using something experimental like Rx/TCP. Two ways to accomplish this:

1)
Set UDP timeouts to a higher value:
net.ipv4.netfilter.ip_conntrack_udp_timeout = 480
net.ipv4.netfilter.ip_conntrack_udp_timeout_stream = 900

This sets a 15 minute timeout. 30 minutes is recommended if you continue to have problems with timed out connections.

2)
Rewrite the client’s outgoing port 7001 traffic to a known “other” port that you assign.
For example, reserve port 7021 on the NAT box for this purpose. 192.168.1.5 is the internal AFS client and eth0 is the external interface of the NAT box.
Send all traffic arriving from the outside server on the assigned port to the inside client on its standard AFS callback port (7001):
# iptables -t nat -A PREROUTING -i eth0 –dport 7021 -j DNAT –to-destination 192.168.1.5:7001
Send all traffic destined to the server from the client out on the assigned port (7021) instead of port 7001:
# iptables -t nat -A POSTROUTING -o eth0 -s 192.168.1.5 –sport 7001 -j MASQUERADE –to-ports 7021

Then set up Linux IP masquerading as usual. (This must be done after at least all of the above POSTROUTING lines, otherwise this rule will match first since it is more general, and none of the other lines will be used.)
# iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

Note: If you are hopping off someone else’s wireless router, make sure traffic destined for the assigned ports, or for port 7001, on THEIR external interface is also being forwarded back to your network’s NAT gateway. Traffic destined for the designated external ports has to somehow be able to reach the NAT box that you control so that you can rewrite the port numbers with iptables.

This would be cool:
http://www.fpga4fun.com/PCI3.html

• Debug misbehaving PCI bridges and unfriendly cards
• Aid in reverse engineering of proprietary programming interfaces

– Find software paths by comparing performance of some commands and extensions to the equivalent done through the software driver. Allow the application to query whether a software path will be used or not.
– Amount of fast texture RAM. Since amount of local memory on card and texture compression may be enabled, consider this “cached” RAM compared to having to go to AGP or system memory. Also find the size of AGP aperture and benchmark AGP transfer rate and system memory speed. Application can decide how to manage its textures accordingly.
– Find fill rate and triangle rate. Application can decide level of detail.
– Find maximum multitexturing level. (Fill rate should decrease drastically when this is exceeded.)

This may violate OpenGL's transparency, but it is already violated when hardware rendered graphics do not match software rendered graphics pixel for pixel.

These issues are related to:
– CPU bugs
– Motherboard electrical bugs
– AGP/PCI Chipset hardware bugs
– Video hardware bugs
– Device driver bugs

http://www.daniel.nofftz.net/linux/Athlon-Powersaving-HOWTO.html

VIA and ATI chipsets AGP 3.0 AGP cycles to system memory do not work properly and cause memory corruption.

GA-6BX board has a 5A regulator instead of the 6A required by AGP specification, resulting in low voltage on the 3.3V power supply, crashing video cards which do not have their own power circuits.

AMD Irongate (AMD751) must be used in 1X mode with certain NVIDIA video cards. It is also possible for a Savage4 card to hang the AMD751 under specific circumstances unless . (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22564.pdf)

ALI 1541, 1647 is incompatible with G200's 2x AGP and must be run in 1X. NVIDIA disables AGP for ALI chipsets.

The condition where an Aureal A3D chip did not get a bus grant within a 4us (16 PCI clocks) window on a MMIO read causes a system lockup. (http://groups.google.com/group/alt.comp.hardware.overclocking.amd/msg/f4d69e1b45a054f7?dmode=source&hl=en)

Windows SBLive drivers constantly transfer data to the sound card when MIDI is enabled, even when no sound is being played, reducing the available bandwidth. (http://alive.singnet.com.sg/tech/via.htm)

Athlon north bridges can be programmed to disconnect the CPU when Stop Grant is asserted (a result of HLT instruction called during OS idle loop, or of south bridge asserting STPCLK as a result of ACPI), resulting in very good power saving and cooling. The BIOS vendors do not seem to program the appropriate bits in the north bridge, so the user can do it himself. There can be problems with this though. Disconnecting and reconnecting the processor bus adds latency and reduces bandwidth. It also may fail on Athlon Model 4 (Thunderbird) due to two errata involving the CPU multiplier and the CLK_CTRL MSR. (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/23614.pdf). Some AMD751 chipsets seem to have a problem with incomplete processor disconnects that cause hangs (http://www.amd.com/us-en/assets/content_type/white_papers_and_tech_docs/22564.pdf). Doing this behind the BIOS's back may also conflict with the BIOS ACPI implementation. The local APIC timer may also have problem.

Athlon Model 1/2 (slot) resume from suspend may fail due to L2 cache corruption on specific processors (errata). BIOS needs to check for this condition and leave L2 cache enabled at suspend.

VIA bugs

VIA chipsets are frequently relabeled. Some relabeled VIA chipsets are AMD-640 (VP2/97), Soyo ETEQ (MVP3), VIAgra (MVP4), etc. (http://www.hardwaresecrets.com/printpage/59/1)

A chipset such as Via Apollo Pro VPX is a set of chips under a product name (VT82C580VPX), such as the north bridge (CPU to AGP/PCI) and south bridge (PCI to ISA, some have integrated super I/O). A product name integrates a set of north bridge, south bridge and data buffers.

VT82C598MVP revision 'CD' (made as late as 9821) seems to have some compatibility problems with certain AGP video cards (like Intel i740). Revision 'CE' (made as early as 9825) seem to fix this, and FIC also produced a BIOS update that claimed to fix it.

VT82C597 only supports AGP 1.0.

586A does not support ACPI, 586B does.

The combination of SBLive, PCI 2.1 Delayed Transaction, and VIA 686B seems to cause data corruption when transferring between the 686B IDE channels in DMA mode. (http://www.realworldtech.com/page.cfm?ArticleID=RWT042501034500) (http://www.realworldtech.com/page.cfm?ArticleID=RWT051401003409) (http://lists.freebsd.org/pipermail/freebsd-chat/2003-May/000329.html) (http://web.archive.org/web/20010831022614/http://www.viahardware.com/686b_1.shtm)

VIA 691 (Apollo Pro), 693 (Apollo Pro Plus), 693A (Apollo Pro 133) and 694X (Apollo Pro 133A) all share the same PCI ID. 694X supports AGP 4X similar to KX133, but NVIDIA uses 2X AGP on 694X and KX133.

Many VIA PCI-ISA (and VLB-ISA) bridges have a bug that causes frequent ISA DMA transactions to hang the board. Intel 430FX (Triton) may suffer from the same bug.

Some instability problems with Western Digital hard disk drivers on VIA VPX/97, VP2/97-based boards using UDMA mode were reported. WD agreed to workaround their firmware to fix this incompatibility in future releases of their products.
VIA will also adress this issue in the next release of BusMaster drive (v. 2.13 has not implemented this fix and for v. 2.19 (not approved yet) it will be known after lab tests are finished).
Temporary solutions:
a) disable UDMA, or
b) disable 586B ISA refresh option (RX41 bit 0 set to 1, disable ISA refresh but Port 61 still Toggle)
WD releases Tucson CCC:C2 and Sedona CCC:B2 and later have updated firmware that solves the problem implemented. There have been no reports on problems for disks shipped after November 1997. In case you suspect your HDD has been affected by this, check your HDD firmware version.

PCI bridge performance

Several generic performance options can be set in order to speed up PCI operations. The locations differ per PCI chipset, and should be set up by BIOS, but on many systems are not. L2 cache as write-back instead of write-through, PCI posting (from CPU to memory, CPU to PCI, and PCI to memory), and PCI burst transfers are all helpful. Linux used to set these up in pci/quirks.c but no longer.

http://video.google.com/videoplay?docid=7326301549273570499
http://www.youtube.com/watch?v=oqA7RjTo6nw
http://www.youtube.com/watch?v=iNv45lrKZuc




http://www.youtube.com/watch?v=_Ueh9RNxSuM

The following /etc/dpkg/dpkg.cfg settings are useful when you have scripted apt-get to do automatic security updates:

# Choose the default action regarding conffiles
force-confdef
# If no default, keep the old conffile
force-confold

This will prevent an update from aborting because the local version of the conf file differed from the package maintainer's version and no user input was available.

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.