On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@xxxxxxxxxxxx> wrote: > On Tue, 2014-12-16 at 15:59 -0200, Marcelo Ricardo Leitner wrote: >> It's a >> 02:00.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5722 >> Gigabit Ethernet PCI Express >> over here >> >> I put a WARN_ON(1) after those printks, and this is what I got: >> >> [ 1.550640] pci 0000:02:00.0: 1st 1 1 >> [ 1.550643] pci 0000:02:00.0: crs_timeout: 0 >> [ 1.550645] ------------[ cut here ]------------ >> [ 1.550651] WARNING: CPU: 6 PID: 364 at drivers/pci/probe.c:1445 pci_bus_read_dev_vendor_id+0x1d4/0x1e0() >> [ 1.550652] Modules linked in: i915(+) raid0 i2c_algo_bit drm_kms_helper drm e1000e(+) tg3(+) ptp pps_core video >> [ 1.550660] CPU: 6 PID: 364 Comm: systemd-udevd Not tainted 3.18.0-rc6+ #8 >> [ 1.550661] Hardware name: Dell Inc. OptiPlex 9010/03K80F, BIOS A15 08/12/2013 >> [ 1.550662] 0000000000000000 000000004de2d8dc ffff8807eabdf948 ffffffff8173db46 >> [ 1.550665] 0000000000000000 0000000000000000 ffff8807eabdf988 ffffffff81094d41 >> [ 1.550667] ffff8807eabdf968 ffff8807f1e27000 0000000000000000 0000000000000000 >> [ 1.550669] Call Trace: >> [ 1.550675] [<ffffffff8173db46>] dump_stack+0x46/0x58 >> [ 1.550679] [<ffffffff81094d41>] warn_slowpath_common+0x81/0xa0 >> [ 1.550681] [<ffffffff81094e5a>] warn_slowpath_null+0x1a/0x20 >> [ 1.550683] [<ffffffff813b2864>] pci_bus_read_dev_vendor_id+0x1d4/0x1e0 >> [ 1.550687] [<ffffffff813b7c3e>] pci_device_is_present+0x2e/0x50 >> [ 1.550693] [<ffffffffa003364f>] tg3_chip_reset+0x2f/0x940 [tg3] >> [ 1.550697] [<ffffffffa0033f9f>] tg3_halt+0x3f/0x1e0 [tg3] >> [ 1.550701] [<ffffffffa0044f83>] tg3_init_one+0xb83/0x1a40 [tg3] > > So does it work if you use a non-zero crs_timeout? The driver has > called tg3_halt() which may affect configuration read responses. I need > to check with the hardware team to see if the 5722 will return CRS in > this scenario. Any updates from the hardware team? This is a pretty serious regression, but as far as I can tell, it is not a PCI bug. The device should respond to a config read of vendor ID. If the driver does something that make the read return CRS status, I think the driver is responsible for doing whatever delay or other fixup is required. I'm inclined to reassign this bug to the tg3 driver unless you think the PCI core is doing something wrong here. Bjorn -- To unsubscribe from this list: send the line "unsubscribe linux-pci" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
