Hi Aaron,

I concur with Nick's assessment -- it's probably an incorrect IRQ assignment or an unfriendly shared IRQ.  Given that 
you're reporting that it doesn't work with apic either, that's some evidence pointing to the idea that the operating 
system isn't getting the correct IRQ.  I've had this happen when there were PCI-to-PCI bridges in the communications 
chain.    You can use the output of pci -vv to determine if your card is behind such a bridge: there would be an entry "
Class = Bridge (PCI/PCI)", and the "Secondary bus number" for the bridge entry would match the "Bus number" for your 
network controller.

Here are some things you could try:
- Manually override the interrupt assignment when launching the network driver with the 'irq=x' argument.   It's lame, 
but you could just try all possible values (1-15) to see if there's one where you consistently get back your 0.3s ping.
- Another way to find the correct IRQ: if the BIOS doesn't print out a page with the IRQ assignments, you could try and 
find out what the BIOS thought the IRQ should be by writing a little test program that manually invokes a PCI BIOS call 
to read the IRQ register on the card, and then run this program in your boot script before launching pci-bios.
- Alternately, I can pass along a patch I wrote for pci-bios-v2 from the 6.6 x86 BSP that adds the ability to map IRQs 
properly through PCI-to-PCI bridges.  If that is your problem, this patch might fix it for you.

If the problem is an unfriendly shared IRQ, you can use 'pidin irqs' to find out what other drivers are active on your 
IRQ line, and then try shutting them off one by one until you find the cuplrit.  You can sometimes influence IRQ sharing
 assignments by enabling or disabling various hardware in the BIOS, such as PS/2 mouse support or unused serial or 
ethernet ports.

Hope this is of some help,
-Will