Problem found: kaweth fails to work on 2.6.12-rc[456]

Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

After doing some testing, I believe a patch that went into rc4 broke kaweth.
The kaweth driver itself did not change from rc2 through rc6.

As a test, I reverted a patch that went into rc4 which modified
net/core/link_watch.c.  Once I compiled the kernel, my netgear EA101 works
again.

The following is the patch that caused it to stop working:
--- BEGIN PATCH ---
diff -urN linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-rc4/net/core/link_watch.c
--- linux-2.6.12-rc3/net/core/link_watch.c	2005-03-01 23:37:30.000000000 -0800
+++ linux-2.6.12-rc4/net/core/link_watch.c	2005-05-06 22:59:27.439802792 -0700
@@ -74,6 +75,12 @@
 		clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state);
 
 		if (dev->flags & IFF_UP) {
+			if (netif_carrier_ok(dev)) {
+				WARN_ON(dev->qdisc_sleeping == &noop_qdisc);
+				dev_activate(dev);
+			} else
+				dev_deactivate(dev);
+
 			netdev_state_change(dev);
 		}
 
--- END PATCH ---
The above is not cut'n'paste.  There was 1 other addition (an include) that
I removed from the patch inorder to revert it.  The patch above was applied
to 2.6.12-rc6 using -Rp1.  This is why I believe that kaweth is broken. 
With my limited understanding of the kernel, it would appear that kaweth
doesn't support netif_carrier_ok properly.  
Anyway, I found what caused it to break, but at this point, I do not have
the required knowledge to do a proper fix.

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

Wakko Warner wrote:
> After doing some testing, I believe a patch that went into rc4 broke kaweth.
> The kaweth driver itself did not change from rc2 through rc6.
> 
> As a test, I reverted a patch that went into rc4 which modified
> net/core/link_watch.c.  Once I compiled the kernel, my netgear EA101 works
> again.
> 
> The following is the patch that caused it to stop working:
> --- BEGIN PATCH ---
> diff -urN linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-rc4/net/core/link_watch.c
> --- linux-2.6.12-rc3/net/core/link_watch.c	2005-03-01 23:37:30.000000000 -0800
> +++ linux-2.6.12-rc4/net/core/link_watch.c	2005-05-06 22:59:27.439802792 -0700
> @@ -74,6 +75,12 @@
>  		clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state);
>  
>  		if (dev->flags & IFF_UP) {
> +			if (netif_carrier_ok(dev)) {
> +				WARN_ON(dev->qdisc_sleeping == &noop_qdisc);
> +				dev_activate(dev);
> +			} else
> +				dev_deactivate(dev);
> +
>  			netdev_state_change(dev);
>  		}
>  
> --- END PATCH ---
> The above is not cut'n'paste.  There was 1 other addition (an include) that
> I removed from the patch inorder to revert it.  The patch above was applied
> to 2.6.12-rc6 using -Rp1.  This is why I believe that kaweth is broken. 
> With my limited understanding of the kernel, it would appear that kaweth
> doesn't support netif_carrier_ok properly.  
> Anyway, I found what caused it to break, but at this point, I do not have
> the required knowledge to do a proper fix.

Actually, removing the above broke my e1000 card.  So I added
dev_activate(dev) back in and all works now!

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Oliver Neukum]

Am Sonntag, 12. Juni 2005 02:41 schrieb Wakko Warner:
> After doing some testing, I believe a patch that went into rc4 broke kaweth.
> The kaweth driver itself did not change from rc2 through rc6.
> 
> As a test, I reverted a patch that went into rc4 which modified
> net/core/link_watch.c.  Once I compiled the kernel, my netgear EA101 works
> again.
> 
> The following is the patch that caused it to stop working:
> --- BEGIN PATCH ---
> diff -urN linux-2.6.12-rc3/net/core/link_watch.c linux-2.6.12-rc4/net/core/link_watch.c
> --- linux-2.6.12-rc3/net/core/link_watch.c	2005-03-01 23:37:30.000000000 -0800
> +++ linux-2.6.12-rc4/net/core/link_watch.c	2005-05-06 22:59:27.439802792 -0700
> @@ -74,6 +75,12 @@
>  		clear_bit(__LINK_STATE_LINKWATCH_PENDING, &dev->state);
>  
>  		if (dev->flags & IFF_UP) {
> +			if (netif_carrier_ok(dev)) {
> +				WARN_ON(dev->qdisc_sleeping == &noop_qdisc);
> +				dev_activate(dev);
> +			} else
> +				dev_deactivate(dev);
> +
>  			netdev_state_change(dev);
>  		}
>  
> --- END PATCH ---
> The above is not cut'n'paste.  There was 1 other addition (an include) that
> I removed from the patch inorder to revert it.  The patch above was applied
> to 2.6.12-rc6 using -Rp1.  This is why I believe that kaweth is broken. 
> With my limited understanding of the kernel, it would appear that kaweth
> doesn't support netif_carrier_ok properly.  
> Anyway, I found what caused it to break, but at this point, I do not have
> the required knowledge to do a proper fix.

static void int_callback(struct urb *u, struct pt_regs *regs)
is supposed to handle the link state. Maybe it fails in your case. Could you
add a printk to this callback to check linkstate?

	Regards
		Oliver
 

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

Oliver Neukum wrote:
> Am Sonntag, 12. Juni 2005 02:41 schrieb Wakko Warner:
> > After doing some testing, I believe a patch that went into rc4 broke kaweth.
> > The kaweth driver itself did not change from rc2 through rc6.
> > 
> > As a test, I reverted a patch that went into rc4 which modified
> > net/core/link_watch.c.  Once I compiled the kernel, my netgear EA101 works
> > again.
> > 
> > The above is not cut'n'paste.  There was 1 other addition (an include) that
> > I removed from the patch inorder to revert it.  The patch above was applied
> > to 2.6.12-rc6 using -Rp1.  This is why I believe that kaweth is broken. 
> > With my limited understanding of the kernel, it would appear that kaweth
> > doesn't support netif_carrier_ok properly.  
> > Anyway, I found what caused it to break, but at this point, I do not have
> > the required knowledge to do a proper fix.
> 
> static void int_callback(struct urb *u, struct pt_regs *regs)
> is supposed to handle the link state. Maybe it fails in your case. Could you
> add a printk to this callback to check linkstate?

I don't believe my case is very specific.  I've tested this on 4 different
systems with totally different configs.  If it is at all specific, I believe
it would be with the network adapter itself.  I don't have any other usb
adapters that use kaweth.

Can you tell me where I need to add the printks?

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Oliver Neukum]

Am Sonntag, 12. Juni 2005 15:05 schrieb Wakko Warner:
> Oliver Neukum wrote:
> > Am Sonntag, 12. Juni 2005 02:41 schrieb Wakko Warner:
> > > After doing some testing, I believe a patch that went into rc4 broke kaweth.
> > > The kaweth driver itself did not change from rc2 through rc6.
> > > 
> > > As a test, I reverted a patch that went into rc4 which modified
> > > net/core/link_watch.c.  Once I compiled the kernel, my netgear EA101 works
> > > again.
> > > 
> > > The above is not cut'n'paste.  There was 1 other addition (an include) that
> > > I removed from the patch inorder to revert it.  The patch above was applied
> > > to 2.6.12-rc6 using -Rp1.  This is why I believe that kaweth is broken. 
> > > With my limited understanding of the kernel, it would appear that kaweth
> > > doesn't support netif_carrier_ok properly.  
> > > Anyway, I found what caused it to break, but at this point, I do not have
> > > the required knowledge to do a proper fix.
> > 
> > static void int_callback(struct urb *u, struct pt_regs *regs)
> > is supposed to handle the link state. Maybe it fails in your case. Could you
> > add a printk to this callback to check linkstate?
> 
> I don't believe my case is very specific.  I've tested this on 4 different
> systems with totally different configs.  If it is at all specific, I believe
> it would be with the network adapter itself.  I don't have any other usb
> adapters that use kaweth.
> 
> Can you tell me where I need to add the printks?

In static void int_callback(struct urb *u, struct pt_regs *regs):

	/* we check the link state to report changes */
	if (kaweth->linkstate != (act_state = ( kaweth->intbuffer[STATE_OFFSET] | STATE_MASK) >> STATE_SHIFT)) {
<------- HERE please a printk for detecting a link state change
		if (!act_state)
			netif_carrier_on(kaweth->net);
		else
			netif_carrier_off(kaweth->net);

		kaweth->linkstate = act_state;
	}

<----------- HERE the value of linkstate is important
resubmit:
	kaweth_resubmit_int_urb(kaweth, GFP_ATOMIC);

	Regards
		Oliver

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

Here's my modified int_callback:
static void int_callback(struct urb *u, struct pt_regs *regs)
{
        struct kaweth_device *kaweth = u->context;
        int act_state;

printk(KERN_INFO "kaweth: begin callback\n");
printk(KERN_INFO "kaweth: u->status: %d\n", u->status);
        switch (u->status) {
        case 0:                 /* success */
                break;
        case -ECONNRESET:       /* unlink */
        case -ENOENT:   
        case -ESHUTDOWN:
                return;
        /* -EPIPE:  should clear the halt */
        default:                /* error */
                goto resubmit;
        }

        /* we check the link state to report changes */
        if (kaweth->linkstate != (act_state = ( kaweth->intbuffer[STATE_OFFSET]
printk(KERN_INFO "kaweth: Link state change.  kaweth->linkstate: %d act_state:
        kaweth->linkstate, act_state);
                if (!act_state) {
printk(KERN_INFO "kaweth: netif_carrier_on\n");
                        netif_carrier_on(kaweth->net);
                } else {
printk(KERN_INFO "kaweth: netif_carrier_off\n");
                        netif_carrier_off(kaweth->net);
                }

                kaweth->linkstate = act_state;
printk(KERN_INFO "kaweth: new link state: %d\n", act_state);
        }
resubmit:
        kaweth_resubmit_int_urb(kaweth, GFP_ATOMIC);
printk(KERN_INFO "kaweth: end callback\n");
}

Results (after ifconfig up, ethernet cable was plugged in at the time):
Jun 14 20:50:25 gonzales kernel: [80756.691742] kaweth: begin callback
Jun 14 20:50:25 gonzales kernel: [80756.691754] kaweth: u->status: 0
Jun 14 20:50:25 gonzales kernel: [80756.691759] kaweth: Link state change.  kaweth->linkstate: 0 act_state: 2
Jun 14 20:50:25 gonzales kernel: [80756.691764] kaweth: netif_carrier_off
Jun 14 20:50:25 gonzales kernel: [80756.691769] kaweth: new link state: 2
Jun 14 20:50:25 gonzales kernel: [80756.691776] kaweth: end callback

the next thing was:
Jun 14 20:50:25 gonzales kernel: [80756.819793] kaweth: begin callback
Jun 14 20:50:25 gonzales kernel: [80756.819800] kaweth: u->status: 0
Jun 14 20:50:25 gonzales kernel: [80756.819807] kaweth: end callback
many times, last occurence:
Jun 14 20:50:36 gonzales kernel: [80767.576134] kaweth: begin callback
Jun 14 20:50:36 gonzales kernel: [80767.576143] kaweth: u->status: 0
Jun 14 20:50:36 gonzales kernel: [80767.576157] kaweth: end callback

then I ifconfig down since it was spewing that information:
Jun 14 20:50:36 gonzales kernel: [80767.618157] kaweth: begin callback
Jun 14 20:50:36 gonzales kernel: [80767.618172] kaweth: u->status: -2

I assume it didn't print the end since the status was -2 (not sure what -2 is)

I'm working off a different ethernet card to stay on line while I debug.
-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Oliver Neukum]

Am Mittwoch, 15. Juni 2005 03:02 schrieb Wakko Warner:
> Here's my modified int_callback:
> static void int_callback(struct urb *u, struct pt_regs *regs)
> {
>         struct kaweth_device *kaweth = u->context;
>         int act_state;
> 
> printk(KERN_INFO "kaweth: begin callback\n");
> printk(KERN_INFO "kaweth: u->status: %d\n", u->status);
>         switch (u->status) {
>         case 0:                 /* success */
>                 break;
>         case -ECONNRESET:       /* unlink */
>         case -ENOENT:   
>         case -ESHUTDOWN:
>                 return;
>         /* -EPIPE:  should clear the halt */
>         default:                /* error */
>                 goto resubmit;
>         }
> 
>         /* we check the link state to report changes */
>         if (kaweth->linkstate != (act_state = ( kaweth->intbuffer[STATE_OFFSET]
> printk(KERN_INFO "kaweth: Link state change.  kaweth->linkstate: %d act_state:
>         kaweth->linkstate, act_state);
>                 if (!act_state) {
> printk(KERN_INFO "kaweth: netif_carrier_on\n");
>                         netif_carrier_on(kaweth->net);
>                 } else {
> printk(KERN_INFO "kaweth: netif_carrier_off\n");
>                         netif_carrier_off(kaweth->net);
>                 }
> 
>                 kaweth->linkstate = act_state;
> printk(KERN_INFO "kaweth: new link state: %d\n", act_state);
>         }
> resubmit:
>         kaweth_resubmit_int_urb(kaweth, GFP_ATOMIC);
> printk(KERN_INFO "kaweth: end callback\n");
> }

Very well.

> Results (after ifconfig up, ethernet cable was plugged in at the time):
> Jun 14 20:50:25 gonzales kernel: [80756.691742] kaweth: begin callback
> Jun 14 20:50:25 gonzales kernel: [80756.691754] kaweth: u->status: 0
> Jun 14 20:50:25 gonzales kernel: [80756.691759] kaweth: Link state change.  kaweth->linkstate: 0 act_state: 2
> Jun 14 20:50:25 gonzales kernel: [80756.691764] kaweth: netif_carrier_off

OK, that should not happen.

Could you remove the "!" at 'if (!act_state) {' and retest?
The documentation I got says that it should be there, but who knows
how accurate it is for all devices.

> Jun 14 20:50:25 gonzales kernel: [80756.691769] kaweth: new link state: 2
> Jun 14 20:50:25 gonzales kernel: [80756.691776] kaweth: end callback
> 
> the next thing was:
> Jun 14 20:50:25 gonzales kernel: [80756.819793] kaweth: begin callback
> Jun 14 20:50:25 gonzales kernel: [80756.819800] kaweth: u->status: 0
> Jun 14 20:50:25 gonzales kernel: [80756.819807] kaweth: end callback
> many times, last occurence:
> Jun 14 20:50:36 gonzales kernel: [80767.576134] kaweth: begin callback
> Jun 14 20:50:36 gonzales kernel: [80767.576143] kaweth: u->status: 0
> Jun 14 20:50:36 gonzales kernel: [80767.576157] kaweth: end callback
> 
> then I ifconfig down since it was spewing that information:
> Jun 14 20:50:36 gonzales kernel: [80767.618157] kaweth: begin callback
> Jun 14 20:50:36 gonzales kernel: [80767.618172] kaweth: u->status: -2
> 
> I assume it didn't print the end since the status was -2 (not sure what -2 is)

Killing the URB due to ifconfig.

	Thank you
		Oliver

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

Oliver Neukum wrote:
> Very well.
> 
> > Results (after ifconfig up, ethernet cable was plugged in at the time):
> > Jun 14 20:50:25 gonzales kernel: [80756.691742] kaweth: begin callback
> > Jun 14 20:50:25 gonzales kernel: [80756.691754] kaweth: u->status: 0
> > Jun 14 20:50:25 gonzales kernel: [80756.691759] kaweth: Link state change.  kaweth->linkstate: 0 act_state: 2
> > Jun 14 20:50:25 gonzales kernel: [80756.691764] kaweth: netif_carrier_off
> 
> OK, that should not happen.
> 
> Could you remove the "!" at 'if (!act_state) {' and retest?
> The documentation I got says that it should be there, but who knows
> how accurate it is for all devices.

Ok, I removed the ! and it now says "netif_carrier_on" and still blasting
the messages.  I'm unable to ping the other end when configured.

> > Jun 14 20:50:25 gonzales kernel: [80756.691769] kaweth: new link state: 2
> > Jun 14 20:50:25 gonzales kernel: [80756.691776] kaweth: end callback
> > 
> > the next thing was:
> > Jun 14 20:50:25 gonzales kernel: [80756.819793] kaweth: begin callback
> > Jun 14 20:50:25 gonzales kernel: [80756.819800] kaweth: u->status: 0
> > Jun 14 20:50:25 gonzales kernel: [80756.819807] kaweth: end callback
> > many times, last occurence:
> > Jun 14 20:50:36 gonzales kernel: [80767.576134] kaweth: begin callback
> > Jun 14 20:50:36 gonzales kernel: [80767.576143] kaweth: u->status: 0
> > Jun 14 20:50:36 gonzales kernel: [80767.576157] kaweth: end callback
> > 
> > then I ifconfig down since it was spewing that information:
> > Jun 14 20:50:36 gonzales kernel: [80767.618157] kaweth: begin callback
> > Jun 14 20:50:36 gonzales kernel: [80767.618172] kaweth: u->status: -2
> > 
> > I assume it didn't print the end since the status was -2 (not sure what -2 is)
> 
> Killing the URB due to ifconfig.

I meant I didn't know the name to number translation.

For the next tests, I think it would be best to remove the 3 printks I added
to show beginning, u->status, and ending.  Spews too much stuff =)

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Oliver Neukum]

 
> I meant I didn't know the name to number translation.

Sorry, ENOENT.

> For the next tests, I think it would be best to remove the 3 printks I added
> to show beginning, u->status, and ending.  Spews too much stuff =)

Please do so and try removing and reattaching the cable.

	Regards
		Oliver

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Wakko Warner]

Oliver Neukum wrote:
> > I meant I didn't know the name to number translation.
> 
> Sorry, ENOENT.

Ok.

> > For the next tests, I think it would be best to remove the 3 printks I added
> > to show beginning, u->status, and ending.  Spews too much stuff =)
> 
> Please do so and try removing and reattaching the cable.

I removed the printks that were spewing lines that are now no longer useful. 
I left the ones that are in the block for the if statement.   There is no
change when I unplug and replug the ethernet cable.  The link light on the
device does go off.  Is it possible that the hardware cannot report link
state?

-- 
 Lab tests show that use of micro$oft causes cancer in lab animals

Re: Problem found: kaweth fails to work on 2.6.12-rc[456]

[Oliver Neukum]

Am Mittwoch, 15. Juni 2005 18:53 schrieb Wakko Warner:
> Oliver Neukum wrote:
> > > I meant I didn't know the name to number translation.
> > 
> > Sorry, ENOENT.
> 
> Ok.
> 
> > > For the next tests, I think it would be best to remove the 3 printks I added
> > > to show beginning, u->status, and ending.  Spews too much stuff =)
> > 
> > Please do so and try removing and reattaching the cable.
> 
> I removed the printks that were spewing lines that are now no longer useful. 
> I left the ones that are in the block for the if statement.   There is no
> change when I unplug and replug the ethernet cable.  The link light on the
> device does go off.  Is it possible that the hardware cannot report link
> state?

It is unfortunately possible. It is even more unfortunately a violation
of the specifications I've got from the manifacturer. Even worse, I don't
know which devices have a working link detection and which don't.
This means that I'll make a patch disabling it for all for the time being.

	Regards
		Oliver