Comment 2 for bug 48287

Notice in the logs, the following errors which
most certainly explain why I don't have network
access after upgrade to dapper:

Jun 3 01:26:05 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:27:32 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:28:44 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:32:15 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:33:25 localhost last message repeated 3 times
Jun 3 01:38:01 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:38:39 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:45:56 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:47:08 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:47:36 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:49:03 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:51:41 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed
Jun 3 01:52:34 localhost kernel: 0000:00:0a.0: tulip_stop_rxtx() failed

Also notice this:

Jun 3 01:57:00 localhost kernel: PCI: Using ACPI for IRQ routing
Jun 3 01:57:00 localhost kernel: ** PCI interrupts are no longer routed automatically. If this
Jun 3 01:57:00 localhost kernel: ** causes a device to stop working, it is probably because the
Jun 3 01:57:00 localhost kernel: ** driver failed to call pci_enable_device(). As a temporary
Jun 3 01:57:00 localhost kernel: ** workaround, the "pci=routeirq" argument restores the old
Jun 3 01:57:00 localhost kernel: ** behavior. If this argument makes the device work again,
Jun 3 01:57:00 localhost kernel: ** please email the output of "lspci" to <email address hidden>
Jun 3 01:57:00 localhost kernel: ** so I can fix the driver.
J