Re: Link state change detection problem on Moschip MCS7832 again

[Jeroen Koekkoek]

On Wed, 2013-07-31 at 11:11 +0200, Jeroen Koekkoek wrote:
> 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
> 
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@xxxxxxxxxxxxxxx
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Oops, forgot to mention that I'm using a MCS7830 based adapter, not a
MCS7832 based one.

Best,
Jeroen


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/