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
This would be cool:
http://www.fpga4fun.com/PCI3.html
Some hints for using mutt, spamassassin, razor, procmail, formail:
http://www.howtoforge.com/procmail_tips_recipes/
Reporting each mail as spam individually in mutt is too time consuming because spamassassin must usually contact several servers, some of which may time out, and there may be 20 or more spams in your inbox if you have not paid attention to it for a while.
It is tempting to use mutt’s message tagging feature to tag several messages and send them all to spamassassin at once.
set pipe_split = yes
macro index S "<enter-command>unset wait_key<enter><tag-prefix-cond>
<pipe-message>spamassassin --report<enter><tag-prefix-cond>
<delete-message><enter-command>set wait_key<enter>"
(tag-prefix-cond is a relatively new addition to mutt that aborts execution of the rest of the macro if no messages are tagged.)
The problem with this approach is that the only thing that both mutt produces and that spamassassin can accept is a single message.  Setting pipe_split = yes in muttrc has the intended effect, that spamassassin is invoked once for each message.  But spamassassin is quite slow in this mode because it must establish a new session with each of the spam reporting servers for each piece of mail.  It is possible to background spamassassin, but without some form of external serialization, many spamassassins will be started at once, overloading the VM and competing for the write lock on the user’s Bayesian database.
Setting pipe_split = no (the default) causes mutt to concatenate all of the messages and pipe them to the program once.  But spamassassin can’t accept this input since it is not in a format that spamassassin recognizes.  Since spamassassin can accept an mbox as input, it is tempting to use something like
pipe_sep = "From abuse@localhost\n"
to emulate a mbox output.  But the first message is ignored by spamassassin, because no separator is placed at the top of the output.
This last problem can be addressed with a script like the following (mutt-sa-report).  It adds a From_ line at the beginning of mutt’s output.  After processing with this script, mutt’s piped output is now a mbox that spamassassin can recognize:
#!/usr/bin/perl --
use warnings;
use strict;
use File::Temp qw/tempfile/;
use Fcntl qw/SEEK_SET/;
my $fh = tempfile;
my $back = "From abuse@localhost\n";
while (<STDIN>) { print $fh $back; $back = $_; }
seek $fh,0,SEEK_SET;
open my $sa, "| spamassassin --mbox --report" or die "Couldn't exec spamassassin ";
while (<$fh>) { print $sa $_; }
close $sa;
close $fh;
exit 0;
Now, this script can be called from mutt:
pipe_split = no
macro index S "<enter-command>unset wait_key<enter><tag-prefix-cond>
<pipe-message>mutt-sa-report >>/home/nemesis/Mail/logfile 2>&1<enter>
<tag-prefix-cond><delete-message><enter-command>set wait_key<enter>"
Look in logfile for the output of spamassassin. You should see “15 messages examined” or something to that effect. If so, it is working and you can remove everything but mutt-sa-report in between the pipe-message and enter tags.
So you pull your trusty TI-83, TI-85, etc calculator out of the closet only to find that it is apparently no longer working. Powering on displays nothing on the screen. Changing the AAA batteries and the lithium battery improves nothing.
Before giving up and junking the calculator, there are two things you should try.
1. Adjust the contrast. For some reason, TI-8x calculators seem to be prone to having their settings corrupted and the contrast zeroed. This is probably the case if you can still communicate with the calculator through the parallel link. To adjust the contract, power the calculator on, then (blindly) hit 2nd, then hold down the up arrow. It should take about two seconds for the screen to become visible. If not….
2. Reset the calculator to factory settings. One way to do this is to remove one battery, and hold ON for 10 seconds. You can also remove all the batteries and wait several hours.
3. Reset the calculator using self test. Press 2nd, Mode, Alpha, A, Enter. This will wipe the calculator memory.
If for some reason you need to open the calculator to try component swapping, there are exactly three screws; two short ones at the bottom, and one long one for the lithium battery. After removing all the batteries, the calculator will pop open with some effort.
You might notice that one day you get the dreaded OPC Failed or Power Calibration Failed on your trusty CDR drive when no other software, hardware or media has changed. You go through several discs wondering what to make of this, then change to a different brand of media with the same result.
The laser diode in a CD drive has a finite lifetime during which the laser output for a given amount of power flowing through it will gradually decrease. The useful life of the laser pickup depends upon the average power flow through the diode; a high power flow accelerates the degeneration of the laser beam. Eventually, this renders the pickup unusable because the circuit has a laser power ceiling at which point it will refuse to increase the power through the diode any more so that it avoids immediately burning out the diode. If your deck has reached the laser power ceiling, but the laser output is still low enough to render your discs unreadable, it is time for a new deck.
A CD pickup has a compensation circuit that sets the laser power to the minimum necessary to get a clean read. The laser power is increased when the disc is dirty or the lens is dirty. Cigarette smoke and dust from a poorly sealing drive will dirty the lens and increase the average laser power, thus shortening its life.
You might notice that even though your burner no longer writes discs, it will still read them. This is because the laser requires far more power to write a disc than to read it. Therefore, a weak pickup (one which has a low laser output to laser power ratio) will very often still function as a reader even when it is no longer useful as a writer.
Another fact to note is that the laser requires more power to write reliably at higher speeds. This means that a higher average write speed will mean a shorter laser life. It also means that if you have a CD writer that is failing power calibration at its maximum write speed because it is nearing the end of its useful life, you may be able to get extended service from it by simply lowering the write speed. If the OPC passes at a given speed, it is quite likely that the disc will be successfully written.
Also, just because a disc failed OPC does not mean it must be discarded. CD recordable discs have 100 OPC segments. So a disc that fails OPC in one recorder can simply be reused in another one, or in the same recorder at a sufficiently lowered speed.
http://www.mscience.com/fastcdr.html
Manufacturers currently do not have any incentive to supply repair parts and service literature for consumer electronics. Their profit is maximized if the unit fails immediately after the warranty runs out and they have a new product cycle at that point to replace it. Unfortunately this approach creates an environmental load as well as a broken window economy, all because some information is hidden from the consumer when they buy the product.
I propose a consumer electronics labeling scheme that gives the consumer several critical pieces of information:
– How long the manufacturer pledges to make service parts available- Maximum cost of each major service part for a given class of device
– If the manufacturer provides service literature to independent technicians covering at least several key topics, defined per class of device
cdrtools/cdrecord: The original cdrecord by Schilling. Was released under GPL, later combined with CDDL build tools to render it undistributable due to contributed GPL code. After Schilling obtained permission from contributors to distribute with CDDL build tools, then cdrecord is changed to use the library libscg (under CDDL) itself. This is undistributable in any case.
cdrecord-ProDVD: The cdrecord with DVD burning capabilities. Binary only with a 6 month license renewal. Some parts open sourced in 5/06?
dvdrtools: Fork of cdrtools by Bero to support DVD burners.
growisofs: Rewritten DVD-only burning software.
cdrkit: Fork of pre-CDDL cdrecord, using cmake build system.
wodim: The new derived cdrecord replacement in cdrkit.
Linux 2.6 SCSI/ATAPI support has been spotty and the various cdrecords floating around that distributions pinned to older versions due to the license change has not helped. cdrkit/wodim should support the Linux 2.6 ATAPI interface correctly (as well as latest versions of cdrtools). ossdvd is another project to support Linux 2.6 with a forked cdrecord.
Replacing a heatsink on your NVIDIA monster? The compound that’s on there might be a mess. Also, it might have migrated around/underneath memory chips, wreaking havoc along the way. Wiping the stuff just gets it all over your fingers and messes up a good microfiber cloth (since paper towels tear and other cloths leave lint).
Acetone and rubbing alcohol mitigate that a bit, but leave something to be desired.
The real solution is Goo Gone or Goof Off or a similar product, and a toothbrush.
Pour the Goo Gone over the ram chips and/or GeForce core, and use the toothbrush to scrub them clear of the heatsink goop. Rinse with water, making sure not to allow the goo to drip onto the other side of the card, and allow to thoroughly dry (24 hours) before reinstalling heatsink.
And for deity’s sake, use less goop next time! It does NOT take much.
You can use the same technique to remove goop from the cooler’s heatsink. I recommend removing the heatsink from the cooler first, because when you wash the solvent + goo off the heatsink, it has an uncanny attraction to plastic and will end up coating the plastic housing of the cooler with a sticky, cloudy layer. It doesn’t affect cooling but looks terrible.
– 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 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.
Name | Product name | North bridge | NB PCI ID | South bridge | SB PCI ID | IDE controller PCI ID |
---|---|---|---|---|---|---|
Apollo VP (VX Pro) | VT82C580VP | VT82C585VP | 0x585 | VT82C586 | 0x586 | 0x571 |
Apollo VPX (VX Pro+) | VT82C580VPX | VT82C585VPX | 0x585 | VT82C586B | 0x586 | 0x571 |
Apollo VP3 | VT82C597 | VT82C597 | 0x597 | VT82C586B | 0x586 | 0x571 |
Apollo MVP3 | VT82C598 | VT82C598[AT|MVP] | 0x598 | VT82C586B/VT82C596B/VT82C686A | 0x586/0x596/0x686 | 0x571 |
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.
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.
synaesthesia is Stephen Fry proof thanks to caching by WP Super Cache