netdev - Re: [bisected] tg3 broken in 3.18.0?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAErSpo7sqZS+-4LHo3wbo-pa73mcP_3d0Z37U0tfnASaxp-D_g@mail.gmail.com>
Date:	Thu, 18 Dec 2014 12:15:38 -0700
From:	Bjorn Helgaas <bhelgaas@...gle.com>
To:	Michael Chan <mchan@...adcom.com>
Cc:	Marcelo Ricardo Leitner <marcelo.leitner@...il.com>,
	Rajat Jain <rajatxjain@...il.com>,
	Nils Holland <nholland@...ys.org>,
	David Miller <davem@...emloft.net>,
	netdev <netdev@...r.kernel.org>,
	"linux-pci@...r.kernel.org" <linux-pci@...r.kernel.org>,
	Rafael Wysocki <rjw@...ysocki.net>,
	Prashant Sreedharan <prashant@...adcom.com>
Subject: Re: [bisected] tg3 broken in 3.18.0?

On Tue, Dec 16, 2014 at 12:54 PM, Michael Chan <mchan@...adcom.com> 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 netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html