* Re: Ethernet controller not starting
@ 2014-03-04 9:06 Christian Riesch
[not found] ` <CAMwGMjwtZVPVaENWqNODPqkM4jAAOsLPrz8_xzRBgGP6_-_usQ@mail.gmail.com>
0 siblings, 1 reply; 7+ messages in thread
From: Christian Riesch @ 2014-03-04 9:06 UTC (permalink / raw)
To: Jon Ringle
Cc: linux-omap, linux-kernel, rafael.j.wysocki, netdev,
davinci-linux-open-source
[cc'ed netdev and davinci-linux-open-source]
--On March 03, 2014 19:39 -0500 Jon Ringle <jon@ringle.org> wrote:
> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki <rjw@rjwysocki.net>
> wrote:
>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote:
>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
>>> the latest LTS kernel).
>>> I found that Ethernet controller on the board no longer comes up on
>>> linux-3.12. I was able to bisect the issue I'm having to the following
>>> commit:
>>>
>>> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
>>> > commit 45f0a85c8258741d11bda25c0a5669c06267204a
>>> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>> > Date: Mon Jun 3 21:49:52 2013 +0200
>>> >
>>> > PM / Runtime: Rework the "runtime idle" helper routine
>>> >
>>> > The "runtime idle" helper routine, rpm_idle(), currently ignores
>>> > return values from .runtime_idle() callbacks executed by it.
>>> > However, it turns out that many subsystems use
>>> > pm_generic_runtime_idle() which checks the return value of the
>>> > driver's callback and executes pm_runtime_suspend() for the
>>> > device unless that value is not 0. If that logic is moved to
>>> > rpm_idle() instead, pm_generic_runtime_idle() can be dropped
>>> > and its users will not need any .runtime_idle() callbacks any
>>> > more.
>>> >
>>> > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
>>> > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
>>> > ata_port_runtime_idle(), respectively, as well as a few drivers'
>>> > ones may be simplified if rpm_idle() calls rpm_suspend() after
>>> > 0 has been returned by the .runtime_idle() callback executed by
>>> > it.
>>> >
>>> > To reduce overall code bloat, make the changes described above.
>>> >
>>> > Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
>>> > Tested-by: Kevin Hilman <khilman@linaro.org>
>>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
>>> > Acked-by: Kevin Hilman <khilman@linaro.org>
>>> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
>>> > Acked-by: Alan Stern <stern@rowland.harvard.edu>
>>>
>>> Can anyone offer any suggestions on what I should be looking for to
>>> fix this on my board?
>>
>> Any pointers to the driver in question?
>
> drivers/net/ethernet/ti/davinci_emac.c
>
Hi Jon,
I have successfully used the davinci_emac driver on a custom board with an
AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should work.
Did you try more recent kernel versions than 3.12?
> I also get the following output:
>
> Starting Network Manager Wait Online...
> [ 30.946509] davinci_mdio davinci_mdio.0: resetting idled controller
> [ 30.953220] net net0: attached PHY driver [Generic PHY]
> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1)
> [ 30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready
> [ 31.082087] genirq: Flags mismatch irq 33. 00000000 (net0) vs.
> 00000000 (net0)
Is it correct that this warning can only appear in case of shared
interrupts? See kernel/irq/manage.c. Since we don't use shared interrupts
here: Are you sure your board configuration is correct with regard to emac
interrupts? Is your configuration using device tree or not (my
configuration is a none-devicetree one)? I also wonder why your network
device is net0, on my board it's eth0, maybe this triggers some bug?
Christian
^ permalink raw reply [flat|nested] 7+ messages in thread[parent not found: <CAMwGMjwtZVPVaENWqNODPqkM4jAAOsLPrz8_xzRBgGP6_-_usQ@mail.gmail.com>]
* Fwd: Ethernet controller not starting [not found] ` <CAMwGMjwtZVPVaENWqNODPqkM4jAAOsLPrz8_xzRBgGP6_-_usQ@mail.gmail.com> @ 2014-03-04 12:34 ` Jon Ringle 2014-03-04 14:06 ` Christian Riesch [not found] ` <09FBC53C1B46AC96B6483AA4@172.22.2.41> 0 siblings, 2 replies; 7+ messages in thread From: Jon Ringle @ 2014-03-04 12:34 UTC (permalink / raw) To: Christian Riesch Cc: linux-omap, linux-kernel, rafael.j.wysocki, netdev, davinci-linux-open-source On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch <christian.riesch@omicron.at> wrote: > [cc'ed netdev and davinci-linux-open-source] > > > --On March 03, 2014 19:39 -0500 Jon Ringle <jon@ringle.org> wrote: > >> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki <rjw@rjwysocki.net> >> wrote: >>> >>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >>>> >>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >>>> the latest LTS kernel). >>>> I found that Ethernet controller on the board no longer comes up on >>>> linux-3.12. I was able to bisect the issue I'm having to the following >>>> commit: >>>> >>>> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit >>>> > commit 45f0a85c8258741d11bda25c0a5669c06267204a >>>> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>>> > Date: Mon Jun 3 21:49:52 2013 +0200 >>>> > >>>> > PM / Runtime: Rework the "runtime idle" helper routine >>>> > >>>> > The "runtime idle" helper routine, rpm_idle(), currently ignores >>>> > return values from .runtime_idle() callbacks executed by it. >>>> > However, it turns out that many subsystems use >>>> > pm_generic_runtime_idle() which checks the return value of the >>>> > driver's callback and executes pm_runtime_suspend() for the >>>> > device unless that value is not 0. If that logic is moved to >>>> > rpm_idle() instead, pm_generic_runtime_idle() can be dropped >>>> > and its users will not need any .runtime_idle() callbacks any >>>> > more. >>>> > >>>> > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() >>>> > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and >>>> > ata_port_runtime_idle(), respectively, as well as a few drivers' >>>> > ones may be simplified if rpm_idle() calls rpm_suspend() after >>>> > 0 has been returned by the .runtime_idle() callback executed by >>>> > it. >>>> > >>>> > To reduce overall code bloat, make the changes described above. >>>> > >>>> > Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> >>>> > Tested-by: Kevin Hilman <khilman@linaro.org> >>>> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>>> > Acked-by: Kevin Hilman <khilman@linaro.org> >>>> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> >>>> > Acked-by: Alan Stern <stern@rowland.harvard.edu> >>>> >>>> Can anyone offer any suggestions on what I should be looking for to >>>> fix this on my board? >>> >>> >>> Any pointers to the driver in question? >> >> >> drivers/net/ethernet/ti/davinci_emac.c >> > > Hi Jon, > I have successfully used the davinci_emac driver on a custom board with an > AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should work. > Did you try more recent kernel versions than 3.12? I have not tried 3.13, but will do so today. Could I get a copy of your .config for comparison purposes? > > >> I also get the following output: >> >> Starting Network Manager Wait Online... >> [ 30.946509] davinci_mdio davinci_mdio.0: resetting idled controller >> [ 30.953220] net net0: attached PHY driver [Generic PHY] >> (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) >> [ 30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready >> [ 31.082087] genirq: Flags mismatch irq 33. 00000000 (net0) vs. >> 00000000 (net0) > > > Is it correct that this warning can only appear in case of shared > interrupts? See kernel/irq/manage.c. Since we don't use shared interrupts > here: Are you sure your board configuration is correct with regard to emac > interrupts? I added some additional printk's and see that emac_dev_open() seems to get called again and it is trying to call devm_request_irq() again for irq resources (33-36) and fails when trying to get irq 33: Starting Network Manager Wait Online... [ 30.687505] emac_dev_open: trying to get irq 33 [ 30.692314] emac_dev_open: got irq 33 [ 30.696034] emac_dev_open: trying to get irq 34 [ 30.700750] emac_dev_open: got irq 34 [ 30.704469] emac_dev_open: trying to get irq 35 [ 30.709088] emac_dev_open: got irq 35 [ 30.712887] emac_dev_open: trying to get irq 36 [ 30.717542] emac_dev_open: got irq 36 [ 30.721507] davinci_mdio davinci_mdio.0: resetting idled controller [ 30.728909] net net0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 30.738614] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready [ 30.847040] emac_dev_open: trying to get irq 33 [ 30.851809] genirq: Flags mismatch irq 33. 00000000 (net0) vs. 00000000 (net0) [ 30.859125] CPU: 0 PID: 677 Comm: NetworkManager Not tainted 3.12.13-fs1-003-g5ae24fe-dirty+ #1234 [ 30.868261] [<c000d9c4>] (unwind_backtrace+0x0/0x128) from [<c000be14>] (show_stack+0x10/0x14) [ 30.877020] [<c000be14>] (show_stack+0x10/0x14) from [<c0046970>] (__setup_irq+0x45c/0x4d4) [ 30.885499] [<c0046970>] (__setup_irq+0x45c/0x4d4) from [<c0046b18>] (request_threaded_irq+0xa4/0x130) [ 30.894935] [<c0046b18>] (request_threaded_irq+0xa4/0x130) from [<c00484e0>] (devm_request_threaded_irq+0x50/0x98) [ 30.905414] [<c00484e0>] (devm_request_threaded_irq+0x50/0x98) from [<c02db4b4>] (emac_dev_open+0x3f4/0x4b8) [ 30.915364] [<c02db4b4>] (emac_dev_open+0x3f4/0x4b8) from [<c0367b40>] (__dev_open+0xc0/0x130) [ 30.924086] [<c0367b40>] (__dev_open+0xc0/0x130) from [<c0367dc4>] (__dev_change_flags+0x90/0x148) [ 30.933154] [<c0367dc4>] (__dev_change_flags+0x90/0x148) from [<c0367f04>] (dev_change_flags+0x10/0x48) [ 30.942679] [<c0367f04>] (dev_change_flags+0x10/0x48) from [<c0374510>] (do_setlink+0x2fc/0x838) [ 30.951591] [<c0374510>] (do_setlink+0x2fc/0x838) from [<c0374dec>] (rtnl_newlink+0x2b4/0x458) [ 30.960328] [<c0374dec>] (rtnl_newlink+0x2b4/0x458) from [<c03740b8>] (rtnetlink_rcv_msg+0x168/0x210) [ 30.969692] [<c03740b8>] (rtnetlink_rcv_msg+0x168/0x210) from [<c037f50c>] (netlink_rcv_skb+0xac/0xc0) [ 30.979130] [<c037f50c>] (netlink_rcv_skb+0xac/0xc0) from [<c0373f40>] (rtnetlink_rcv+0x1c/0x2c) [ 30.988040] [<c0373f40>] (rtnetlink_rcv+0x1c/0x2c) from [<c037ee94>] (netlink_unicast+0x138/0x1e8) [ 30.997122] [<c037ee94>] (netlink_unicast+0x138/0x1e8) from [<c037f2a4>] (netlink_sendmsg+0x2bc/0x37c) [ 31.006552] [<c037f2a4>] (netlink_sendmsg+0x2bc/0x37c) from [<c0351f50>] (sock_sendmsg+0x84/0xa8) [ 31.015546] [<c0351f50>] (sock_sendmsg+0x84/0xa8) from [<c035338c>] (___sys_sendmsg.part.35+0x268/0x278) [ 31.025150] [<c035338c>] (___sys_sendmsg.part.35+0x268/0x278) from [<c03542e8>] (__sys_sendmsg+0x4c/0x7c) [ ) from [<c0009560>] (ret_fast_syscall+0x0/0x2c) [ 31.043691] genirq: out_mask [ 31.046723] genirq: out_thread [ 31.049820] genirq: out_mput [ 31.052825] net net0: DaVinci EMAC: devm_request_irq() failed > Is your configuration using device tree or not (my configuration > is a none-devicetree one)? No. > I also wonder why your network device is net0, on > my board it's eth0, maybe this triggers some bug? I doubt that this is the source of the problem. The davinci_emac interface is initiatially eth1 (we have a 2nd ethernet port on board that initially is assigned eth0), I rename them eth1 -> net0 and eth0 -> net1. See http://www.freedesktop.org/wiki/Software/systemd/PredictableNetworkInterfaceNames/ Jon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Fwd: Ethernet controller not starting 2014-03-04 12:34 ` Fwd: " Jon Ringle @ 2014-03-04 14:06 ` Christian Riesch [not found] ` <09FBC53C1B46AC96B6483AA4@172.22.2.41> 1 sibling, 0 replies; 7+ messages in thread From: Christian Riesch @ 2014-03-04 14:06 UTC (permalink / raw) To: Jon Ringle Cc: linux-omap, linux-kernel, rafael.j.wysocki, netdev, davinci-linux-open-source, Prabhakar Lad Hi Jon, [Now also cc'ed Prabhakar Lad] --On March 04, 2014 07:34 -0500 Jon Ringle <jon@ringle.org> wrote: > On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch > <christian.riesch@omicron.at> wrote: >> [cc'ed netdev and davinci-linux-open-source] >> >> >> --On March 03, 2014 19:39 -0500 Jon Ringle <jon@ringle.org> wrote: >> >>> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki <rjw@rjwysocki.net> >>> wrote: >>>> >>>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >>>>> >>>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >>>>> the latest LTS kernel). >>>>> I found that Ethernet controller on the board no longer comes up on >>>>> linux-3.12. I was able to bisect the issue I'm having to the following >>>>> commit: >>>>> >>>>> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit >>>>> > commit 45f0a85c8258741d11bda25c0a5669c06267204a >>>>> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>>>> > Date: Mon Jun 3 21:49:52 2013 +0200 >>>>> > [...] >>>>> >>>>> Can anyone offer any suggestions on what I should be looking for to >>>>> fix this on my board? >>>> >>>> >>>> Any pointers to the driver in question? >>> >>> >>> drivers/net/ethernet/ti/davinci_emac.c >>> >> >> Hi Jon, >> I have successfully used the davinci_emac driver on a custom board with >> an AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should >> work. Did you try more recent kernel versions than 3.12? > > I have not tried 3.13, but will do so today. Could I get a copy of > your .config for comparison purposes? > I would like to apologize, apparently my testing with 3.13 was quite bad. Ethernet comes up on my board and works fine after booting, but I can easily reproduce your problem by just doing ifconfig eth0 down /ifconfig eth0 up (which should call emac_dev_stop/emac_dev_open). # ifconfig eth0 up genirq: Flags mismatch irq 33. ..... So probably one of your start scripts (or dhcp or similar) does some ifconfig down/up, which then fails. I had a look at the code again, emac_dev_open requests the interrupts, whereas emac_dev_stop does not free them. If emac_dev_open is then called again by ifconfig eth0 up, it tries to request the interrupts again, resulting in the error above. I think the problem is a regression caused by Commit 6892b41d9701283085b655c6086fb57a5d63fa47 net: davinci: emac: Convert to devm_* api Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> This patch replaces request_irq() by devm_request_irq() in emac_dev_open and removes free_irq() from emac_dev_stop. But since emac_dev_open is called every time we do an ifconfig eth0 up, it tries to request the interrupts again and again and again (and fails). So I guess the correct solution would be to move the calls of devm_request_irq() to davinci_emac_probe(). I will send a patch to netdev, it solves the problem on my board. Christian ^ permalink raw reply [flat|nested] 7+ messages in thread
[parent not found: <09FBC53C1B46AC96B6483AA4@172.22.2.41>]
* Re: Fwd: Ethernet controller not starting [not found] ` <09FBC53C1B46AC96B6483AA4@172.22.2.41> @ 2014-03-04 15:08 ` Jon Ringle 0 siblings, 0 replies; 7+ messages in thread From: Jon Ringle @ 2014-03-04 15:08 UTC (permalink / raw) To: Christian Riesch Cc: linux-omap, linux-kernel, rafael.j.wysocki, netdev, davinci-linux-open-source, Prabhakar Lad On Tue, Mar 4, 2014 at 9:06 AM, Christian Riesch <christian.riesch@omicron.at> wrote: > Hi Jon, > > [Now also cc'ed Prabhakar Lad] > > > --On March 04, 2014 07:34 -0500 Jon Ringle <jon@ringle.org> wrote: > >> On Tue, Mar 4, 2014 at 4:06 AM, Christian Riesch >> <christian.riesch@omicron.at> wrote: >>> >>> [cc'ed netdev and davinci-linux-open-source] >>> >>> >>> --On March 03, 2014 19:39 -0500 Jon Ringle <jon@ringle.org> wrote: >>> >>>> On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki <rjw@rjwysocki.net> >>>> wrote: >>>>> >>>>> >>>>> On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >>>>>> >>>>>> >>>>>> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >>>>>> the latest LTS kernel). >>>>>> I found that Ethernet controller on the board no longer comes up on >>>>>> linux-3.12. I was able to bisect the issue I'm having to the following >>>>>> commit: >>>>>> >>>>>> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit >>>>>> > commit 45f0a85c8258741d11bda25c0a5669c06267204a >>>>>> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >>>>>> > Date: Mon Jun 3 21:49:52 2013 +0200 >>>>>> > > > [...] > >>>>>> >>>>>> Can anyone offer any suggestions on what I should be looking for to >>>>>> fix this on my board? >>>>> >>>>> >>>>> >>>>> Any pointers to the driver in question? >>>> >>>> >>>> >>>> drivers/net/ethernet/ti/davinci_emac.c >>>> >>> >>> Hi Jon, >>> I have successfully used the davinci_emac driver on a custom board with >>> an AM1808 SoC with Kernel 3.13 a few weeks ago. So at least 3.13 should >>> work. Did you try more recent kernel versions than 3.12? >> >> >> I have not tried 3.13, but will do so today. Could I get a copy of >> your .config for comparison purposes? >> > > I would like to apologize, apparently my testing with 3.13 was quite bad. > Ethernet comes up on my board and works fine after booting, but I can easily > reproduce your problem by just doing ifconfig eth0 down /ifconfig eth0 up > (which should call emac_dev_stop/emac_dev_open). > > # ifconfig eth0 up > genirq: Flags mismatch irq 33. ..... > > So probably one of your start scripts (or dhcp or similar) does some > ifconfig down/up, which then fails. > > I had a look at the code again, emac_dev_open requests the interrupts, > whereas emac_dev_stop does not free them. If emac_dev_open is then called > again by ifconfig eth0 up, it tries to request the interrupts again, > resulting in the error above. > > I think the problem is a regression caused by > > Commit 6892b41d9701283085b655c6086fb57a5d63fa47 > net: davinci: emac: Convert to devm_* api > Signed-off-by: Lad, Prabhakar <prabhakar.csengg@gmail.com> > > This patch replaces request_irq() by devm_request_irq() in emac_dev_open and > removes free_irq() from emac_dev_stop. But since emac_dev_open is called > every time we do an ifconfig eth0 up, it tries to request the interrupts > again and again and again (and fails). > > So I guess the correct solution would be to move the calls of > devm_request_irq() to davinci_emac_probe(). I will send a patch to netdev, > it solves the problem on my board. The posted patch also resolves the issue on my board. Thanks! Jon ^ permalink raw reply [flat|nested] 7+ messages in thread
* Ethernet controller not starting
@ 2014-03-03 19:41 Jon Ringle
2014-03-03 23:43 ` Rafael J. Wysocki
0 siblings, 1 reply; 7+ messages in thread
From: Jon Ringle @ 2014-03-03 19:41 UTC (permalink / raw)
To: linux-omap, linux-kernel; +Cc: rafael.j.wysocki
I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now
the latest LTS kernel).
I found that Ethernet controller on the board no longer comes up on linux-3.12.
I was able to bisect the issue I'm having to the following commit:
> 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit
> commit 45f0a85c8258741d11bda25c0a5669c06267204a
> Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Date: Mon Jun 3 21:49:52 2013 +0200
>
> PM / Runtime: Rework the "runtime idle" helper routine
>
> The "runtime idle" helper routine, rpm_idle(), currently ignores
> return values from .runtime_idle() callbacks executed by it.
> However, it turns out that many subsystems use
> pm_generic_runtime_idle() which checks the return value of the
> driver's callback and executes pm_runtime_suspend() for the device
> unless that value is not 0. If that logic is moved to rpm_idle()
> instead, pm_generic_runtime_idle() can be dropped and its users
> will not need any .runtime_idle() callbacks any more.
>
> Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle()
> routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and
> ata_port_runtime_idle(), respectively, as well as a few drivers'
> ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has
> been returned by the .runtime_idle() callback executed by it.
>
> To reduce overall code bloat, make the changes described above.
>
> Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com>
> Tested-by: Kevin Hilman <khilman@linaro.org>
> Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com>
> Acked-by: Kevin Hilman <khilman@linaro.org>
> Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org>
> Acked-by: Alan Stern <stern@rowland.harvard.edu>
Can anyone offer any suggestions on what I should be looking for to
fix this on my board?
Thanks,
Jon
^ permalink raw reply [flat|nested] 7+ messages in thread* Re: Ethernet controller not starting 2014-03-03 19:41 Jon Ringle @ 2014-03-03 23:43 ` Rafael J. Wysocki 2014-03-04 0:39 ` Jon Ringle 0 siblings, 1 reply; 7+ messages in thread From: Rafael J. Wysocki @ 2014-03-03 23:43 UTC (permalink / raw) To: Jon Ringle; +Cc: linux-omap, linux-kernel, rafael.j.wysocki On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: > I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now > the latest LTS kernel). > I found that Ethernet controller on the board no longer comes up on linux-3.12. > I was able to bisect the issue I'm having to the following commit: > > > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit > > commit 45f0a85c8258741d11bda25c0a5669c06267204a > > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Date: Mon Jun 3 21:49:52 2013 +0200 > > > > PM / Runtime: Rework the "runtime idle" helper routine > > > > The "runtime idle" helper routine, rpm_idle(), currently ignores > > return values from .runtime_idle() callbacks executed by it. > > However, it turns out that many subsystems use > > pm_generic_runtime_idle() which checks the return value of the > > driver's callback and executes pm_runtime_suspend() for the device > > unless that value is not 0. If that logic is moved to rpm_idle() > > instead, pm_generic_runtime_idle() can be dropped and its users > > will not need any .runtime_idle() callbacks any more. > > > > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() > > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and > > ata_port_runtime_idle(), respectively, as well as a few drivers' > > ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has > > been returned by the .runtime_idle() callback executed by it. > > > > To reduce overall code bloat, make the changes described above. > > > > Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> > > Tested-by: Kevin Hilman <khilman@linaro.org> > > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> > > Acked-by: Kevin Hilman <khilman@linaro.org> > > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> > > Acked-by: Alan Stern <stern@rowland.harvard.edu> > > Can anyone offer any suggestions on what I should be looking for to > fix this on my board? Any pointers to the driver in question? Rafael ^ permalink raw reply [flat|nested] 7+ messages in thread
* Re: Ethernet controller not starting 2014-03-03 23:43 ` Rafael J. Wysocki @ 2014-03-04 0:39 ` Jon Ringle 0 siblings, 0 replies; 7+ messages in thread From: Jon Ringle @ 2014-03-04 0:39 UTC (permalink / raw) To: Rafael J. Wysocki; +Cc: linux-omap, linux-kernel, rafael.j.wysocki On Mon, Mar 3, 2014 at 6:43 PM, Rafael J. Wysocki <rjw@rjwysocki.net> wrote: > On Monday, March 03, 2014 02:41:01 PM Jon Ringle wrote: >> I'm working on porting an ARM board from linux-3.10 to linux-3.12 (now >> the latest LTS kernel). >> I found that Ethernet controller on the board no longer comes up on linux-3.12. >> I was able to bisect the issue I'm having to the following commit: >> >> > 45f0a85c8258741d11bda25c0a5669c06267204a is the first bad commit >> > commit 45f0a85c8258741d11bda25c0a5669c06267204a >> > Author: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> > Date: Mon Jun 3 21:49:52 2013 +0200 >> > >> > PM / Runtime: Rework the "runtime idle" helper routine >> > >> > The "runtime idle" helper routine, rpm_idle(), currently ignores >> > return values from .runtime_idle() callbacks executed by it. >> > However, it turns out that many subsystems use >> > pm_generic_runtime_idle() which checks the return value of the >> > driver's callback and executes pm_runtime_suspend() for the device >> > unless that value is not 0. If that logic is moved to rpm_idle() >> > instead, pm_generic_runtime_idle() can be dropped and its users >> > will not need any .runtime_idle() callbacks any more. >> > >> > Moreover, the PCI, SCSI, and SATA subsystems' .runtime_idle() >> > routines, pci_pm_runtime_idle(), scsi_runtime_idle(), and >> > ata_port_runtime_idle(), respectively, as well as a few drivers' >> > ones may be simplified if rpm_idle() calls rpm_suspend() after 0 has >> > been returned by the .runtime_idle() callback executed by it. >> > >> > To reduce overall code bloat, make the changes described above. >> > >> > Tested-by: Mika Westerberg <mika.westerberg@linux.intel.com> >> > Tested-by: Kevin Hilman <khilman@linaro.org> >> > Signed-off-by: Rafael J. Wysocki <rafael.j.wysocki@intel.com> >> > Acked-by: Kevin Hilman <khilman@linaro.org> >> > Reviewed-by: Ulf Hansson <ulf.hansson@linaro.org> >> > Acked-by: Alan Stern <stern@rowland.harvard.edu> >> >> Can anyone offer any suggestions on what I should be looking for to >> fix this on my board? > > Any pointers to the driver in question? drivers/net/ethernet/ti/davinci_emac.c I also get the following output: Starting Network Manager Wait Online... [ 30.946509] davinci_mdio davinci_mdio.0: resetting idled controller [ 30.953220] net net0: attached PHY driver [Generic PHY] (mii_bus:phy_addr=davinci_mdio-0:00, id=7c0f1) [ 30.962938] IPv6: ADDRCONF(NETDEV_UP): net0: link is not ready [ 31.082087] genirq: Flags mismatch irq 33. 00000000 (net0) vs. 00000000 (net0) [ 31.089425] CPU: 0 PID: 679 Comm: NetworkManager Not tainted 3.12.13-fs1-003-g5ae24fe-dirty+ #1218 [ 31.098496] Function entered at [<c000d6dc>] from [<c000baa8>] [ 31.104398] Function entered at [<c000baa8>] from [<c0042d9c>] [ 31.110292] Function entered at [<c0042d9c>] from [<c0042fa4>] [ 31.116180] Function entered at [<c0042fa4>] from [<c0044794>] [ 31.122069] Function entered at [<c0044794>] from [<c02a7954>] [ 31.127958] Function entered at [<c02a7954>] from [<c03289b8>] [ 31.133852] Function entered at [<c03289b8>] from [<c0328bd8>] [ 31.139741] Function entered at [<c0328bd8>] from [<c0328ce4>] [ 31.145630] Function entered at [<c0328ce4>] from [<c03340fc>] [ 31.151523] Function entered at [<c03340fc>] from [<c0335104>] [ 31.157412] Function entered at [<c0335104>] from [<c033547c>] [ 31.163303] Function entered at [<c033547c>] from [<c033e858>] [ 31.169193] Function entered at [<c033e858>] from [<c0333db8>] [ 31.175080] Function entered at [<c0333db8>] from [<c033e238>] [ 31.180969] Function entered at [<c033e238>] from [<c033e6b4>] [ 31.186857] Function entered at [<c033e6b4>] from [<c0314460>] [ 31.192747] Function entered at [<c0314460>] from [<c0315598>] [ 31.198637] Function entered at [<c0315598>] from [<c0316580>] [ 31.204528] Function entered at [<c0316580>] from [<c00093c0>] [ 31.210600] net net0: DaVinci EMAC: devm_request_irq() failed [FAILED] Failed to start Network Manager Wait Online. Putting a breakpoint on the genirq message, the backtrace is: #0 __setup_irq (irq=irq@entry=33, desc=desc@entry=0xc0d24b10 <irq_desc+3960>, new=new@entry=0xc0a6a320) at kernel/irq/manage.c:1177 #1 0xc0042fa4 in request_threaded_irq (irq=irq@entry=33, handler=handler@entry=0xc02a6bbc <emac_irq>, thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=0, irqflags@entry=3234987536, devname=0xc2f87000 \"net0\", devname@entry=0xc02a7954 <emac_dev_open+284> \"\", dev_id=dev_id@entry=0xc2f87000) at kernel/irq/manage.c:1438 #2 0xc0044794 in devm_request_threaded_irq (dev=0xc0d1e688 <da8xx_emac_device+16>, irq=irq@entry=33, handler=handler@entry=0xc02a6bbc <emac_irq>, thread_fn=thread_fn@entry=0x0 <__vectors_start>, irqflags=irqflags@entry=0, devname=devname@entry=0xc2f87000 \"net0\", dev_id=dev_id@entry=0xc2f87000) at kernel/irq/devres.c:60 #3 0xc02a7954 in devm_request_irq (dev_id=0xc2f87000, devname=0xc2f87000 \"net0\", irqflags=0, handler=0xc02a6bbc <emac_irq>, irq=33, dev=<optimized out>) at include/linux/interrupt.h:158 #4 emac_dev_open (ndev=0xc2f87000) at drivers/net/ethernet/ti/davinci_emac.c:1569 #5 0xc03289b8 in __dev_open (dev=0xc2f87000) at net/core/dev.c:1256 #6 0xc0328bd8 in __dev_change_flags (dev=dev@entry=0xc2f87000, flags=4099) at net/core/dev.c:5042 #7 0xc0328ce4 in dev_change_flags (dev=dev@entry=0xc2f87000, flags=<optimized out>) at net/core/dev.c:5103 #8 0xc03340fc in do_setlink (dev=dev@entry=0xc2f87000, ifm=ifm@entry=0xc2e67ed0, tb=tb@entry=0xc0a5dc64, ifname=ifname@entry=0xc0a5dc18 \"\", modified=0) at net/core/rtnetlink.c:1437 #9 0xc0335104 in rtnl_newlink (skb=<optimized out>, nlh=0xc2e67ec0) at net/core/rtnetlink.c:1822 #10 0xc033547c in rtnetlink_rcv_msg (skb=0xc29aeb60, nlh=<optimized out>) at net/core/rtnetlink.c:2691 #11 0xc033e858 in netlink_rcv_skb (skb=skb@entry=0xc29aeb60, cb=cb@entry=0xc03352e0 <rtnetlink_rcv_msg>) at net/netlink/af_netlink.c:2774 #12 0xc0333db8 in rtnetlink_rcv (skb=0xc29aeb60) at net/core/rtnetlink.c:2697 #13 0xc033e238 in netlink_unicast_kernel (ssk=0xc2af0800, skb=0xc29aeb60, sk=0xc3857e00) at net/netlink/af_netlink.c:1708 #14 netlink_unicast (ssk=ssk@entry=0xc2af0800, skb=skb@entry=0xc29aeb60, portid=portid@entry=0, nonblock=<optimized out>) at net/netlink/af_netlink.c:1734 #15 0xc033e6b4 in netlink_sendmsg (kiocb=<optimized out>, sock=<optimized out>, msg=0xc0a5df7c, len=32) at net/netlink/af_netlink.c:2290 #16 0xc0314460 in __sock_sendmsg_nosec (size=32, msg=0xc0a5df7c, sock=0xc34220c0, iocb=0xc0a5ddd8) at net/socket.c:632 #17 __sock_sendmsg (size=32, msg=0xc0a5df7c, sock=0xc34220c0, iocb=0xc0a5ddd8) at net/socket.c:640 #18 sock_sendmsg (sock=sock@entry=0xc34220c0, msg=msg@entry=0xc0a5df7c, size=size@entry=32) at net/socket.c:651 #19 0xc0315598 in ___sys_sendmsg (sock=sock@entry=0xc34220c0, msg_sys=0xc0a5df7c, msg_sys@entry=0xc0a5df74, flags=flags@entry=0, used_address=0x0 <__vectors_start>, msg=0xbef014c4) at net/socket.c:2072 #20 0xc0316580 in ___sys_sendmsg (used_address=0x0 <__vectors_start>, flags=0, msg_sys=0xc0a5df74, msg=0xbef014c4, sock=0xc34220c0) at net/socket.c:2000 #21 __sys_sendmsg (fd=<optimized out>, msg=0xbef014c4, flags=0) at net/socket.c:2108 #22 0xc00093c0 in ?? () #23 0xc00093c0 in ?? () Backtrace stopped: previous frame identical to this frame (corrupt stack?) Jon ^ permalink raw reply [flat|nested] 7+ messages in thread
end of thread, other threads:[~2014-03-04 15:08 UTC | newest]
Thread overview: 7+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-03-04 9:06 Ethernet controller not starting Christian Riesch
[not found] ` <CAMwGMjwtZVPVaENWqNODPqkM4jAAOsLPrz8_xzRBgGP6_-_usQ@mail.gmail.com>
2014-03-04 12:34 ` Fwd: " Jon Ringle
2014-03-04 14:06 ` Christian Riesch
[not found] ` <09FBC53C1B46AC96B6483AA4@172.22.2.41>
2014-03-04 15:08 ` Jon Ringle
-- strict thread matches above, loose matches on Subject: below --
2014-03-03 19:41 Jon Ringle
2014-03-03 23:43 ` Rafael J. Wysocki
2014-03-04 0:39 ` Jon Ringle
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox
all inboxes | Powered by JetHome®