netif_schedule and mpc5200_fec

netif_schedule and mpc5200_fec

[Jon Smirl]

I just updated to linus/master and mpc5200_fec won't boot.

Guessing it is this patch but I haven't looked at it yet.

commit 263ba3204a434d0ca851e1321b31cd58376b86cb
Author: David S. Miller <davem@davemloft.net>
Date:   Tue Jul 15 03:47:41 2008 -0700

    netdev: Convert all drivers away from netif_schedule().

    They logically all want to trigger a schedule for all device
    TX queues.

    Signed-off-by: David S. Miller <davem@davemloft.net>


Sending DHCP requests .<0>------------[ cut here ]------------
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
GPR08: c382dfb4 c0330000 00000000 c031e468 3181b461 ffffffff 03ffe000 ffffffff
GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
PHY: f0003000:00 - Link is Up - 100/Full
., OK


-- 
Jon Smirl
jonsmirl@gmail.com

Re: netif_schedule and mpc5200_fec

[Jon Smirl]

On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> I just updated to linus/master and mpc5200_fec won't boot.

It does boot, but this badness looks like it is coming from this
patch. I don't know enough about networking to debug it.

jonsmirl@terra:~/fs/drivers/net$ git diff
8b9835108f68938a5f7e74fd2c0fc65da2abad92 fec_mpc52xx.c
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index 329edd9..ae9ecb7 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,7 +197,7 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                if (priv->link == PHY_DOWN) {
                        new_state = 1;
                        priv->link = phydev->link;
-                       netif_schedule(dev);
+                       netif_tx_schedule_all(dev);
                        netif_carrier_on(dev);
                        netif_start_queue(dev);
                }
jonsmirl@terra:~/fs/drivers/net$


>
>  Guessing it is this patch but I haven't looked at it yet.
>
>  commit 263ba3204a434d0ca851e1321b31cd58376b86cb
>  Author: David S. Miller <davem@davemloft.net>
>  Date:   Tue Jul 15 03:47:41 2008 -0700
>
>     netdev: Convert all drivers away from netif_schedule().
>
>     They logically all want to trigger a schedule for all device
>     TX queues.
>
>     Signed-off-by: David S. Miller <davem@davemloft.net>
>
>
>  Sending DHCP requests .<0>------------[ cut here ]------------
>  Badness at c01da570 [verbose debug info unavailable]
>  NIP: c01da570 LR: c015b31c CTR: c015b234
>  REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
>  MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
>  TASK = c3815000[4] 'events/0' THREAD: c382c000
>  GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
>  GPR08: c382dfb4 c0330000 00000000 c031e468 3181b461 ffffffff 03ffe000 ffffffff
>  GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
>  GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
>  NIP [c01da570] __netif_schedule+0x3c/0xac
>  LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
>  Call Trace:
>  [c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
>  [c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
>  [c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
>  [c382df80] [c002eb0c] run_workqueue+0xb4/0x148
>  [c382dfa0] [c002f070] worker_thread+0x9c/0xb8
>  [c382dfd0] [c0032954] kthread+0x4c/0x88
>  [c382dff0] [c000f538] kernel_thread+0x44/0x60
>  Instruction dump:
>  7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
>  3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
>  PHY: f0003000:00 - Link is Up - 100/Full
>  ., OK
>
>
>
>  --
>  Jon Smirl
>  jonsmirl@gmail.com
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: netif_schedule and mpc5200_fec

[David Miller]

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 17:03:32 -0400

> On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I just updated to linus/master and mpc5200_fec won't boot.
> 
> It does boot, but this badness looks like it is coming from this
> patch. I don't know enough about networking to debug it.

The driver is doing a netif_wake_queue() when it should not.
I'll have a more detailed look at this and try to fix it
later.

Re: netif_schedule and mpc5200_fec

[David Miller]

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 17:03:32 -0400

> On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> > I just updated to linus/master and mpc5200_fec won't boot.
> 
> It does boot, but this badness looks like it is coming from this
> patch. I don't know enough about networking to debug it.

I just applied the following patch from Anton Vorontsov which
will fix this.

netdev: bunch of drivers: avoid WARN at net/core/dev.c:1328

The drivers were touching net queue before it has been started, so
without this patch, the drivers will potentially WARN at
net/core/dev.c:1328.

I don't have the hardware for the drivers below, so this patch is
untested, and thus should be carefully peer reviewed.

tc35815.c
au1000_eth.c
bfin_mac.c
macb.c
^ The four drivers are using phylib, they're calling netif_start_queue()
in open() callback. So trivially remove netif_tx_schedule_all().
Phylib will handle netif_carrier_*().

cpmac.c
fec_mpc52xx.c
fs_enet/fs_enet-main.c
sh_eth.c
^ The same as above, but these were also needlessly calling
netif_carrier_*() functions. So removed queue calls and also remove
carrier calls, since phylib will handle it. fs_enet-main.c also didn't
call netif_start_queue() at open(), this is fixed now.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
Signed-off-by: David S. Miller <davem@davemloft.net>
---
 drivers/net/au1000_eth.c           |    5 ++---
 drivers/net/bfin_mac.c             |    1 -
 drivers/net/cpmac.c                |    2 --
 drivers/net/fec_mpc52xx.c          |    5 -----
 drivers/net/fs_enet/fs_enet-main.c |    7 ++-----
 drivers/net/macb.c                 |    4 +---
 drivers/net/sh_eth.c               |    5 -----
 drivers/net/tc35815.c              |    1 -
 8 files changed, 5 insertions(+), 25 deletions(-)

diff --git a/drivers/net/au1000_eth.c b/drivers/net/au1000_eth.c
index 3ab61e4..cb8be49 100644
--- a/drivers/net/au1000_eth.c
+++ b/drivers/net/au1000_eth.c
@@ -911,9 +911,8 @@ au1000_adjust_link(struct net_device *dev)
 	if(phydev->link != aup->old_link) {
 		// link state changed
 
-		if (phydev->link) // link went up
-			netif_tx_schedule_all(dev);
-		else { // link went down
+		if (!phydev->link) {
+			/* link went down */
 			aup->old_speed = 0;
 			aup->old_duplex = -1;
 		}
diff --git a/drivers/net/bfin_mac.c b/drivers/net/bfin_mac.c
index a6a3da8..a8ec60e 100644
--- a/drivers/net/bfin_mac.c
+++ b/drivers/net/bfin_mac.c
@@ -357,7 +357,6 @@ static void bfin_mac_adjust_link(struct net_device *dev)
 		if (!lp->old_link) {
 			new_state = 1;
 			lp->old_link = 1;
-			netif_tx_schedule_all(dev);
 		}
 	} else if (lp->old_link) {
 		new_state = 1;
diff --git a/drivers/net/cpmac.c b/drivers/net/cpmac.c
index fbd4280..a7800e5 100644
--- a/drivers/net/cpmac.c
+++ b/drivers/net/cpmac.c
@@ -945,10 +945,8 @@ static void cpmac_adjust_link(struct net_device *dev)
 		if (!priv->oldlink) {
 			new_state = 1;
 			priv->oldlink = 1;
-			netif_tx_schedule_all(dev);
 		}
 	} else if (priv->oldlink) {
-		netif_tx_stop_all_queues(dev);
 		new_state = 1;
 		priv->oldlink = 0;
 		priv->oldspeed = 0;
diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index ae9ecb7..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
 		if (priv->link == PHY_DOWN) {
 			new_state = 1;
 			priv->link = phydev->link;
-			netif_tx_schedule_all(dev);
-			netif_carrier_on(dev);
-			netif_start_queue(dev);
 		}
 
 	} else if (priv->link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
 		priv->link = PHY_DOWN;
 		priv->speed = 0;
 		priv->duplex = -1;
-		netif_stop_queue(dev);
-		netif_carrier_off(dev);
 	}
 
 	if (new_state && netif_msg_link(priv))
diff --git a/drivers/net/fs_enet/fs_enet-main.c b/drivers/net/fs_enet/fs_enet-main.c
index 445763e..5291188 100644
--- a/drivers/net/fs_enet/fs_enet-main.c
+++ b/drivers/net/fs_enet/fs_enet-main.c
@@ -738,9 +738,6 @@ static void generic_adjust_link(struct  net_device *dev)
 		if (!fep->oldlink) {
 			new_state = 1;
 			fep->oldlink = 1;
-			netif_tx_schedule_all(dev);
-			netif_carrier_on(dev);
-			netif_start_queue(dev);
 		}
 
 		if (new_state)
@@ -750,8 +747,6 @@ static void generic_adjust_link(struct  net_device *dev)
 		fep->oldlink = 0;
 		fep->oldspeed = 0;
 		fep->oldduplex = -1;
-		netif_carrier_off(dev);
-		netif_stop_queue(dev);
 	}
 
 	if (new_state && netif_msg_link(fep))
@@ -826,6 +821,8 @@ static int fs_enet_open(struct net_device *dev)
 	}
 	phy_start(fep->phydev);
 
+	netif_start_queue(dev);
+
 	return 0;
 }
 
diff --git a/drivers/net/macb.c b/drivers/net/macb.c
index 0496d16..daba82b 100644
--- a/drivers/net/macb.c
+++ b/drivers/net/macb.c
@@ -164,9 +164,7 @@ static void macb_handle_link_change(struct net_device *dev)
 	}
 
 	if (phydev->link != bp->link) {
-		if (phydev->link)
-			netif_tx_schedule_all(dev);
-		else {
+		if (!phydev->link) {
 			bp->speed = 0;
 			bp->duplex = -1;
 		}
diff --git a/drivers/net/sh_eth.c b/drivers/net/sh_eth.c
index a4bc812..c69ba13 100644
--- a/drivers/net/sh_eth.c
+++ b/drivers/net/sh_eth.c
@@ -642,17 +642,12 @@ static void sh_eth_adjust_link(struct net_device *ndev)
 					| ECMR_DM, ioaddr + ECMR);
 			new_state = 1;
 			mdp->link = phydev->link;
-			netif_tx_schedule_all(ndev);
-			netif_carrier_on(ndev);
-			netif_start_queue(ndev);
 		}
 	} else if (mdp->link) {
 		new_state = 1;
 		mdp->link = PHY_DOWN;
 		mdp->speed = 0;
 		mdp->duplex = -1;
-		netif_stop_queue(ndev);
-		netif_carrier_off(ndev);
 	}
 
 	if (new_state)
diff --git a/drivers/net/tc35815.c b/drivers/net/tc35815.c
index 41d3ac4..a645e50 100644
--- a/drivers/net/tc35815.c
+++ b/drivers/net/tc35815.c
@@ -672,7 +672,6 @@ static void tc_handle_link_change(struct net_device *dev)
 			if (dev->flags & IFF_PROMISC)
 				tc35815_set_multicast_list(dev);
 #endif
-			netif_tx_schedule_all(dev);
 		} else {
 			lp->speed = 0;
 			lp->duplex = -1;
-- 
1.5.6.4.433.g09651

Re: netif_schedule and mpc5200_fec

[Jon Smirl]

On 7/22/08, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>  Date: Tue, 22 Jul 2008 17:03:32 -0400
>
>
> > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > > I just updated to linus/master and mpc5200_fec won't boot.
>  >
>  > It does boot, but this badness looks like it is coming from this
>  > patch. I don't know enough about networking to debug it.
>
>
> I just applied the following patch from Anton Vorontsov which
>  will fix this.

I applied this piece and still have the same error.

diff --git a/drivers/net/fec_mpc52xx.c b/drivers/net/fec_mpc52xx.c
index b487d6f..4e4f683 100644
--- a/drivers/net/fec_mpc52xx.c
+++ b/drivers/net/fec_mpc52xx.c
@@ -197,9 +197,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                if (priv->link == PHY_DOWN) {
                        new_state = 1;
                        priv->link = phydev->link;
-//                     netif_tx_schedule_all(dev);
-//                     netif_carrier_on(dev);
-//                     netif_start_queue(dev);
                }

        } else if (priv->link) {
@@ -207,8 +204,6 @@ static void mpc52xx_fec_adjust_link(struct net_device *dev)
                priv->link = PHY_DOWN;
                priv->speed = 0;
                priv->duplex = -1;
-//             netif_stop_queue(dev);
-//             netif_carrier_off(dev);
        }

        if (new_state && netif_msg_link(priv))
jonsmirl@terra:~/fs$


net eth0: attached phy 0 to driver Generic PHY
Sending DHCP requests .<0>------------[ cut here ]------------
Badness at c01da570 [verbose debug info unavailable]
NIP: c01da570 LR: c015b31c CTR: c015b234
REGS: c382de70 TRAP: 0700   Not tainted  (2.6.26-efika)
MSR: 00029032 <EE,ME,IR,DR>  CR: 22000082  XER: 00000000
TASK = c3815000[4] 'events/0' THREAD: c382c000
GPR00: 00000001 c382df20 c3815000 c031e468 c38f25a0 00000000 00000000 00000000
GPR08: c382dfb4 c0330000 00000000 c031e468 2f762097 ffffffff 03ffe000 ffffffff
GPR16: 00000001 00000000 007ffc00 00000000 00000000 03ff8838 00000000 00000004
GPR24: 00000000 00000000 c032b46c c0330000 c38a2e00 00000001 c38f2780 c38f2400
NIP [c01da570] __netif_schedule+0x3c/0xac
LR [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
Call Trace:
[c382df20] [c002eeb0] queue_work+0x58/0x6c (unreliable)
[c382df40] [c015b31c] mpc52xx_fec_adjust_link+0xe8/0x194
[c382df60] [c0158cd0] phy_state_machine+0xec/0x4e0
[c382df80] [c002eb0c] run_workqueue+0xb4/0x148
[c382dfa0] [c002f070] worker_thread+0x9c/0xb8
[c382dfd0] [c0032954] kthread+0x4c/0x88
[c382dff0] [c000f538] kernel_thread+0x44/0x60
Instruction dump:
7c6b1b78 3929e468 7f834800 39200002 90010024 38030024 bfa10014 40be0030
3d20c033 80099988 7c000034 5400d97e <0f000000> 2f800000 41be0054 38000001
PHY: f0003000:00 - Link is Up - 100/Full
., OK
IP-Config: Got DHCP answer from 192.168.1.1, my address is 192.168.1.11
IP-Config: Complete:
     device=eth0, addr=192.168.1.11, mask=255.255.255.0, gw=192.168.1.1,
     host=Phytec, domain=, nis-domain=(none),
     bootserver=192.168.1.1, rootserver=192.168.1.4, rootpath=


-- 
Jon Smirl
jonsmirl@gmail.com

Re: netif_schedule and mpc5200_fec

[David Miller]

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 18:54:18 -0400

> On 7/22/08, David Miller <davem@davemloft.net> wrote:
> > From: "Jon Smirl" <jonsmirl@gmail.com>
> >  Date: Tue, 22 Jul 2008 17:03:32 -0400
> >
> >
> > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >  > > I just updated to linus/master and mpc5200_fec won't boot.
> >  >
> >  > It does boot, but this badness looks like it is coming from this
> >  > patch. I don't know enough about networking to debug it.
> >
> >
> > I just applied the following patch from Anton Vorontsov which
> >  will fix this.
> 
> I applied this piece and still have the same error.

There are no calls to functions in mpc52xx_fec_adjust_link that
can lead to __netif_schedule() any more.

Therefore I can't see how your backtrace is even possible.

Please double check that you've really applied the patch
and that mpc52xx_fec_adjust_link lacks any calls to
netif_*_queue() and *netif_schedule().

Thanks.

Re: netif_schedule and mpc5200_fec

[Jon Smirl]

On 7/22/08, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>
> Date: Tue, 22 Jul 2008 18:54:18 -0400
>
>
>  > On 7/22/08, David Miller <davem@davemloft.net> wrote:
>  > > From: "Jon Smirl" <jonsmirl@gmail.com>
>  > >  Date: Tue, 22 Jul 2008 17:03:32 -0400
>  > >
>  > >
>  > > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
>  > >  > > I just updated to linus/master and mpc5200_fec won't boot.
>  > >  >
>  > >  > It does boot, but this badness looks like it is coming from this
>  > >  > patch. I don't know enough about networking to debug it.
>  > >
>  > >
>  > > I just applied the following patch from Anton Vorontsov which
>  > >  will fix this.
>  >
>  > I applied this piece and still have the same error.
>
>
> There are no calls to functions in mpc52xx_fec_adjust_link that
>  can lead to __netif_schedule() any more.
>
>  Therefore I can't see how your backtrace is even possible.
>
>  Please double check that you've really applied the patch
>  and that mpc52xx_fec_adjust_link lacks any calls to
>  netif_*_queue() and *netif_schedule().

You're right. That patch fixes it. Another thing I brought down made
my image file not get generated and I was using an old image.


>
>  Thanks.
>


-- 
Jon Smirl
jonsmirl@gmail.com

Re: netif_schedule and mpc5200_fec

[David Miller]

From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Tue, 22 Jul 2008 19:33:13 -0400

> On 7/22/08, David Miller <davem@davemloft.net> wrote:
> > From: "Jon Smirl" <jonsmirl@gmail.com>
> >
> > Date: Tue, 22 Jul 2008 18:54:18 -0400
> >
> >
> >  > On 7/22/08, David Miller <davem@davemloft.net> wrote:
> >  > > From: "Jon Smirl" <jonsmirl@gmail.com>
> >  > >  Date: Tue, 22 Jul 2008 17:03:32 -0400
> >  > >
> >  > >
> >  > > > On 7/22/08, Jon Smirl <jonsmirl@gmail.com> wrote:
> >  > >  > > I just updated to linus/master and mpc5200_fec won't boot.
> >  > >  >
> >  > >  > It does boot, but this badness looks like it is coming from this
> >  > >  > patch. I don't know enough about networking to debug it.
> >  > >
> >  > >
> >  > > I just applied the following patch from Anton Vorontsov which
> >  > >  will fix this.
> >  >
> >  > I applied this piece and still have the same error.
> >
> >
> > There are no calls to functions in mpc52xx_fec_adjust_link that
> >  can lead to __netif_schedule() any more.
> >
> >  Therefore I can't see how your backtrace is even possible.
> >
> >  Please double check that you've really applied the patch
> >  and that mpc52xx_fec_adjust_link lacks any calls to
> >  netif_*_queue() and *netif_schedule().
> 
> You're right. That patch fixes it. Another thing I brought down made
> my image file not get generated and I was using an old image.

Thanks for confirming this Jon.

Re: netif_schedule and mpc5200_fec

[Grant Likely]

On Tue, Jul 22, 2008 at 7:36 PM, David Miller <davem@davemloft.net> wrote:
> From: "Jon Smirl" <jonsmirl@gmail.com>
>> You're right. That patch fixes it. Another thing I brought down made
>> my image file not get generated and I was using an old image.
>
> Thanks for confirming this Jon.

Thanks for fixing it!

Cheers,
g.

-- 
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.