lkml.org 
[lkml]   [2013]   [Jul]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: Link state change detection problem on Moschip MCS7832 again
From
Date
On Fri, 2013-01-11 at 11:15 +0100, Michael Hunold wrote:
> Hi,
>
> I have a no-name Moschip MCS7832-based adapter shows a strange behaviour
> in my system after a system upgrade. "lsusb -vv" for that device is
> attached to the end of the mail.
>
> I am using the adapter for embedded systems development, where it serves
> kernels via TFTP and root filesystems via NFS.
>
> I have recently upgrade my system to Kubuntu 12.10 which uses a 3.5.0-21
> kernel. Before that upgrade the device was working fine with Xubuntu 10.10.
>
> I have used the network-manager applet that comes with Kubuntu to assign
> a static IP address to that interface.
>
> The symptom is that when the remote system's bootloader (u-boot in my
> case) starts to fetch the kernel via TFTP, it usually starts fine (a
> couple of "#" are shown to indicate progress), then timeouts are
> happening ("T" is shown), then progress continues, then more timeouts
> and so on.
>
> I can see the following messages getting repeated in /var/log/syslog:
>
> [...]
> Jan 11 11:01:04 elmc-teemhu NetworkManager[1250]: <info> (eth1): carrier
> now OFF (device state 100, deferring action for 4 seconds)
> Jan 11 11:01:04 elmc-teemhu NetworkManager[1250]: <info> (eth1): carrier
> now ON (device state 100)
> [...]
>
> I found the following bug report and this got me going:
> https://bugzilla.kernel.org/show_bug.cgi?id=28532
>
> Here is what I investigated so far.
>
> 1. I noticed that the patch dabdaf0caa3af520dbc1df87b2fb4e77224037bd
> from Ondrej Zary is missing in the kernel Kubuntu is serving, so I
> downloaded the most-recent mcs7830.c from kernel.org and recompiled the
> module. The problem stays the same, there is no improvement.
>
> 2. I undid both commits dabdaf0caa3af520dbc1df87b2fb4e77224037bd and
> b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113 which added the "mcs7830:
> Implement link state detection" in the first place. Without that
> "feature" my adapter is now working reliably again.
>
> 3. Commit dabdaf0caa3af520dbc1df87b2fb4e77224037bd had the following
> comment:
>
> "The device had an undocumented "feature": it can provide a sequence of
> spurious link-down status data even if the link is up all the time.
> A sequence of 10 was seen so update the link state only after the device
> reports the same link state 20 times."
>
> I tried to increase the number from 20 gradually, but it did not help to
> fix the problem. In my desparation I tried 100 as well, but this only
> postponed the
>
> 4. In my desparation, I went back to the most recent driver and added
> the following code to mcs7830_status() in order to track after how many
> calls to that function the link state changes.
>
> [...]
> {
> static int xxx_counter = 0;
> static int xxx_link = -1;
> if (link != xxx_link) {
> printk("counter %4d -> link %d\n", xxx_counter, link);
> xxx_link = link;
> xxx_counter = 0;
> } else {
> xxx_counter++;
> }
> }
> [...]
>
> This resulted in the following output:
>
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.025109] counter 105 -> link 0
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.101840] counter 76 -> link 1
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.207724] counter 105 -> link 0
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.285582] counter 77 -> link 1
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.392416] counter 106 -> link 0
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.468149] counter 75 -> link 1
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.574036] counter 105 -> link 0
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.651893] counter 77 -> link 1
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.757719] counter 105 -> link 0
> Jan 11 11:01:04 elmc-teemhu NetworkManager[1250]: <info> (eth1): carrier
> now OFF (device state 100, deferring action for 4 seconds)
> Jan 11 11:01:04 elmc-teemhu kernel: [11627.834546] counter 76 -> link 1
> Jan 11 11:01:04 elmc-teemhu NetworkManager[1250]: <info> (eth1): carrier
> now ON (device state 100)
> Jan 11 11:01:05 elmc-teemhu kernel: [11627.939259] counter 104 -> link 0
> Jan 11 11:01:05 elmc-teemhu kernel: [11628.018204] counter 78 -> link 1
>
> So it seems the link state is constantly toggling and the network
> manager eventually picks that up and does some reconfiguratation to the
> network interface which disturbs both TFTP and NFS.
>
> As I already said above, when I undo both commits then everything is
> working fine again. Network manager is not complaining any more and TFTP
> and NFS is working fine.
>
> Any idea what is wrong with that adapter? Is it unable to report link
> state changes correctly at all?
>
> How to make the current driver work correctly without reverting the two
> commit completly?
>
> Best regards
> Michael.

Hi,

I'm experiencing the same problem. After reverting the commits below, my
problems disappeared.

commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
mcs7830: Implement link state detection

commit b1ff4f96fd1c63890d78d8939c6e0f2b44ce3113
mcs7830: Implement link state detection

I'm running Fedora 19 (Linux laptop.lan 3.10.3-300.fc19.x86_64 #1 SMP
Fri Jul 26 00:00:58 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux).

Best regards,
Jeroen Koekkoek



\
 
 \ /
  Last update: 2013-07-31 11:41    [W:0.058 / U:0.980 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site