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-next>] [day] [month] [year] [list]
Date:	Tue, 17 Apr 2012 10:18:57 -0400
From:	Josh Boyer <jwboyer@...hat.com>
To:	Matt Carlson <mcarlson@...adcom.com>,
	Michael Chan <mchan@...adcom.com>
Cc:	netdev@...r.kernel.org, linux-kernel@...r.kernel.org
Subject: tg3 'No PHY devices' loading issue

Hi Matt and Michael,

I'm seeing an odd issue with the tg3 driver on one of my development
machines.  I've tried kernels 3.2.10, 3.3.0, 3.3.1, 3.3.2 and 3.4-rc3
and they all seem to exhibit this issue now.  When the machine boots
and the tg3 driver is loaded, it fails to find a PHY and then reports
'Problem fetching invariants of chip'.  If I do a rmmod/modprobe of
tg3 after login, the probe seems to work fine and ethernet works as
expected.  You can see this in the dmesg below:

[jwboyer@...er ~]$ dmesg | grep tg3
[    2.084969] tg3.c:v3.122 (December 7, 2011)
[    2.093511] tg3 mdio bus: probed
[    2.093513] tg3 0000:03:00.0: No PHY devices
[    2.093531] tg3 0000:03:00.0: Problem fetching invariants of chip, aborting
[   90.824697] tg3.c:v3.122 (December 7, 2011)
[   90.857068] tg3 mdio bus: probed
[   90.862540] tg3 0000:03:00.0: eth0: Tigon3 [partno(BCM57788) rev 57780001] (PCI Express) MAC address 18:03:73:e6:01:88
[   90.862547] tg3 0000:03:00.0: eth0: attached PHY driver [Broadcom BCM57780] (mii_bus:phy_addr=300:01)
[   90.862552] tg3 0000:03:00.0: eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] TSOcap[1]
[   90.862557] tg3 0000:03:00.0: eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[   90.919961] tg3 0000:03:00.0: irq 47 for MSI/MSI-X
[   91.863311] tg3 0000:03:00.0: p3p1: Link is down
[   92.864348] tg3 0000:03:00.0: p3p1: Link is up at 100 Mbps, full duplex
[   92.864352] tg3 0000:03:00.0: p3p1: Flow control is on for TX and on for RX

It has worked on some of the older kernels without the need for the
manual rmmod/modprobe step, so it seems to be somewhat timing related.
I'm not sure if there is a module load ordering issue, but that doesn't
seem to be the case.  I can't explain why a later modprobe would work
just fine though.

Do you have any thoughts on how to go about debugging/fixing this?  I'd
be happy to test and provide whatever information you need.

josh
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ