Created attachment 160801 [details] Working kernel dmesg (3.17.3) Starting with commit 89665a6a71408796565bfd29cfa6a7877b17a667, some (not all) variants of Broadcom tg3 network cards (drivers/net/ethernet/broadcom/tg3.c) stop working. Upon booting a kernel that has been equipped with the above mentioned patch, the tg3 NIC will not reach a properly configured state, its driver will issue a tg3 0000:02:00.0 enp2s0: No firmware running line in dmesg, and the card will not be working. I am attaching a dmesg taken on my machine booting a kernel without the patch (actually, 3.17.3) in dmesg_good.txt, as well as a non-working kernel with the patch applied (3.18.0) in dmesg_bad.txt. Also supplied is a lspci -vvv output, taken when the machine was running a working kernel. Finally, I'd like to add a reference to the thread at http://thread.gmane.org/gmane.linux.network/342566, especially the messages posted by Marcelo Leitner, who is also affected by the problem and has supplied some more useful debugging information in his postings to that thread.
Created attachment 160811 [details] Non-working kernel dmesg output (3.18.0)
Created attachment 160821 [details] lspci -vvv output
Reassigning to tg3 driver, per discussion here: http://lkml.kernel.org/r/20141213210251.GA12812@teela.fritz.box Apparently, in this path: tg3_init_one tg3_halt tg3_chip_reset pci_device_is_present pci_bus_read_dev_vendor_id the 5722 chipset can return 0x0001 for the Vendor ID. This is defined to be "Configuration Request Retry Status", but doesn't seem to be the intended behavior for the chipset. I think the tg3 driver will need to workaround this somehow.