* Link state change detection problem on Moschip MCS7832 again
@ 2013-01-11 10:15 Michael Hunold
2013-07-31 9:11 ` Jeroen Koekkoek
0 siblings, 1 reply; 3+ messages in thread
From: Michael Hunold @ 2013-01-11 10:15 UTC (permalink / raw)
To: linux-kernel; +Cc: andi, linux, myxal.mxl, florian
[-- Attachment #1: Type: text/plain, Size: 4501 bytes --]
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.
[-- Attachment #2: lsusb-vv-moschip.txt --]
[-- Type: text/plain, Size: 2747 bytes --]
Bus 003 Device 016: ID 9710:7830 MosChip Semiconductor MCS7830 10/100 Mbps Ethernet adapter
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
idVendor 0x9710 MosChip Semiconductor
idProduct 0x7830 MCS7830 10/100 Mbps Ethernet adapter
bcdDevice 1.00
iManufacturer 1 Moschip Semiconductor
iProduct 2 USB-MAC Controller
iSerial 3 3b000021
bNumConfigurations 1
Configuration Descriptor:
bLength 9
bDescriptorType 2
wTotalLength 39
bNumInterfaces 1
bConfigurationValue 1
iConfiguration 0
bmAttributes 0xa0
(Bus Powered)
Remote Wakeup
MaxPower 500mA
Interface Descriptor:
bLength 9
bDescriptorType 4
bInterfaceNumber 0
bAlternateSetting 0
bNumEndpoints 3
bInterfaceClass 255 Vendor Specific Class
bInterfaceSubClass 0
bInterfaceProtocol 255
iInterface 0
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x81 EP 1 IN
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x02 EP 2 OUT
bmAttributes 2
Transfer Type Bulk
Synch Type None
Usage Type Data
wMaxPacketSize 0x0040 1x 64 bytes
bInterval 255
Endpoint Descriptor:
bLength 7
bDescriptorType 5
bEndpointAddress 0x83 EP 3 IN
bmAttributes 3
Transfer Type Interrupt
Synch Type None
Usage Type Data
wMaxPacketSize 0x0010 1x 16 bytes
bInterval 1
Device Qualifier (for other device speed):
bLength 10
bDescriptorType 6
bcdUSB 2.00
bDeviceClass 255 Vendor Specific Class
bDeviceSubClass 0
bDeviceProtocol 255
bMaxPacketSize0 64
bNumConfigurations 1
Device Status: 0x0000
(Bus Powered)
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Link state change detection problem on Moschip MCS7832 again
2013-01-11 10:15 Link state change detection problem on Moschip MCS7832 again Michael Hunold
@ 2013-07-31 9:11 ` Jeroen Koekkoek
2013-07-31 9:24 ` Jeroen Koekkoek
0 siblings, 1 reply; 3+ messages in thread
From: Jeroen Koekkoek @ 2013-07-31 9:11 UTC (permalink / raw)
To: linux-kernel; +Cc: Michael Hunold
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: Link state change detection problem on Moschip MCS7832 again
2013-07-31 9:11 ` Jeroen Koekkoek
@ 2013-07-31 9:24 ` Jeroen Koekkoek
0 siblings, 0 replies; 3+ messages in thread
From: Jeroen Koekkoek @ 2013-07-31 9:24 UTC (permalink / raw)
To: linux-kernel; +Cc: Michael Hunold
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@vger.kernel.org
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2013-07-31 9:24 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2013-01-11 10:15 Link state change detection problem on Moschip MCS7832 again Michael Hunold
2013-07-31 9:11 ` Jeroen Koekkoek
2013-07-31 9:24 ` Jeroen Koekkoek
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox