Bug 77121
| Summary: | Staging ethernet driver et131x started to give oops lately. | ||
|---|---|---|---|
| Product: | Drivers | Reporter: | Georgios Tsalikis (georgios) |
| Component: | Staging | Assignee: | drivers_staging (drivers_staging) |
| Status: | RESOLVED CODE_FIX | ||
| Severity: | normal | CC: | georgios, levex, mark.einon |
| Priority: | P1 | ||
| Hardware: | i386 | ||
| OS: | Linux | ||
| Kernel Version: | 3.14.4 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: | bisection log | ||
|
Description
Georgios Tsalikis
2014-05-29 17:53:06 UTC
Hi, it would be amazing if you could bisect it! Here is a link that can help you: http://landley.net/writing/git-bisect-howto.html Let me know if you need any help doing it. (I can't do this myself as I don't have this hardware sadly...) Thanks Levente Kurusa Hi and thanks for opening my eyes! This bisection feature is quite amazing. This was the final message. I will attach the log too. 87aa9f9c61ad56d505641681812e92ad976f8608 is the first bad commit commit 87aa9f9c61ad56d505641681812e92ad976f8608 Author: Florian Fainelli <f.fainelli@gmail.com> Date: Fri Dec 6 13:01:34 2013 -0800 net: phy: consolidate PHY reset in phy_init_hw() There are quite a lot of drivers touching a PHY device MII_BMCR register to reset the PHY without taking care of: 1) ensuring that BMCR_RESET is cleared after a given timeout 2) the PHY state machine resuming to the proper state and re-applying potentially changed settings such as auto-negotiation Introduce phy_poll_reset() which will take care of polling the MII_BMCR for the BMCR_RESET bit to be cleared after a given timeout or return a timeout error code. In order to make sure the PHY is in a correct state, phy_init_hw() first issues a software reset through MII_BMCR and then applies any fixups. Signed-off-by: Florian Fainelli <f.fainelli@gmail.com> Signed-off-by: David S. Miller <davem@davemloft.net> :040000 040000 8d43169b3a6a69f554472207759087dd0b6ca745 ee772cef693ce1768b41b89e4533644f2f7379d1 M Documentation :040000 040000 ec3ad443ef88819d0f58ceeb28df5dd4cb0b6299 eaeae7ce17856172e2473a4efe0382011663f13e M drivers Created attachment 137951 [details]
bisection log
Hi, can you please try to boot the latest mainline kernel booted with this driver as builtin? Tick 'Device Drivers->Staging Drivers->Agure ET1310 Gigabit...' to STAR. Try to boot the kernel and supply a dmesg please. Would be also awesome if you could tick 'Kernel hacking -> Compile-time checks... -> Compile kernel with debugging info' to STAR. Then, you could do a 'gdb vmlinux' to open up GDB where you would simply type 'list *<EIP from the oops without the relation symbols but with 0x prefixed>' to get where the oops happens. Thanks *** Bug 80751 has been marked as a duplicate of this bug. *** The crash has been fixed by commit b394745df2d9, but the cause (presumably phy_init_hw() failing) is still an issue. ------------ commit b394745df2d9d4c30bf1bcc55773bec6f3bc7c67 Author: Guenter Roeck <linux@roeck-us.net> Date: Wed May 14 13:12:49 2014 -0700 net: phy: Don't call phy_resume if phy_init_hw failed After the call to phy_init_hw failed in phy_attach_direct, phy_detach is called to detach the phy device from its network device. If the attached driver is a generic phy driver, this also detaches the driver. Subsequently phy_resume is called, which assumes without checking that a driver is attached to the device. This will result in a crash such as Unable to handle kernel paging request for data at address 0xffffffffffffff90 Faulting instruction address: 0xc0000000003a0e18 Oops: Kernel access of bad area, sig: 11 [#1] ... NIP [c0000000003a0e18] .phy_attach_direct+0x68/0x17c LR [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c Call Trace: [c0000003fc0475d0] [c0000000003a0e6c] .phy_attach_direct+0xbc/0x17c (unreliable) [c0000003fc047670] [c0000000003a0ff8] .phy_connect_direct+0x28/0x98 [c0000003fc047700] [c0000000003f0074] .of_phy_connect+0x4c/0xa4 Only call phy_resume if phy_init_hw was successful. Fix patch posted at http://marc.info/?l=linux-netdev&m=140727945201126&w=2 Fix now in mainline, v3.17-rc3. |