MC75 on Linux 2.4

Noener

Member
Joined
Sep 19, 2006
Messages
12
Have anyone ever tried to get a MC75 based Edge Modem (F@stlink mini USB modem) to work on linux kernel 2.4?

I've tried, but according to the system messages, the unit continue to enumerate and then denumerate.

Any ideas? (except to use a 2.6 kernel :) )

Regards
 

koffiejunkie

Executive Member
Joined
Aug 23, 2004
Messages
9,588
What seems to be the hinderance on the 2.4 kernel (I'm assuming you have it working on 2.6)?
 

nic777

Expert Member
Joined
Mar 29, 2005
Messages
2,063
We got a samba edge modem to work under 2.6 and working towards to get it working under 2.4

The driver is called usb-acm and its called usb modems in the kernel config.

But I think you got that already since you can see the modem. What program are you using to dial in? Wvdial?
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
Yes it works on a 2.6 kernel, I did not have to do anything actually.

On a 2.4 kernel, I get the following messages when I plug in the modem:

----------
hub.c: new USB device ......., assigned address 3
ttyACM0: USB ACM device
usb_control/bulk_msg: timeout
...
usb.c: USB disconnect on device..... address 3
hub.c: new USB device ......., assigned address 4
ttyACM0: USB ACM device
usb_control/bulk_msg: timeout
...
usb.c: USB disconnect on device..... address 4
hub.c: new USB device ......., assigned address 5

and so on forever. I also get a debounce error sometimes.

-------------

I'm not at even at the point of dialing in. I don't know the usb-acm driver, but I'll see if I can find anything. I currently trying with the supplied acm.c driver. I enabled debugging in the acm.c, but it seems that the problem must be at usb level.

Thanks for the replies, your help is greatly appreciated!

Regards
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
I've tried 2 different MC75 devices on various different machines (even on an embedded system), the same error.

Other usb devices seem to work fine, but I don't have any other acm devices than the MC75.

I unfortnately don't know how the how to disable ACPI, or is it the ACPI settings in the BIOS?

Thank you for the response!
 

YelloFever

MTN Company Representative
Joined
Mar 30, 2006
Messages
4,569
I've tried 2 different MC75 devices on various different machines (even on an embedded system), the same error.

Other usb devices seem to work fine, but I don't have any other acm devices than the MC75.

I unfortnately don't know how the how to disable ACPI, or is it the ACPI settings in the BIOS?

Thank you for the response!


Good day,

Noener

Has this been sorted?

MTNDD
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
Unfortunately no, but amm still working on it.

I got my hands on a USB packet analizer, but am still trying to figure at what it all means. It seems to enumerate ok, but after that you get hundreds of NAK packets - whatever that means in the greater scheme of thing I don't know :confused: .

Any ideas perhaps?

Regards.
 

YelloFever

MTN Company Representative
Joined
Mar 30, 2006
Messages
4,569
Unfortunately no, but amm still working on it.

I got my hands on a USB packet analizer, but am still trying to figure at what it all means. It seems to enumerate ok, but after that you get hundreds of NAK packets - whatever that means in the greater scheme of thing I don't know :confused: .

Any ideas perhaps?

Regards.

Good day,

Sorry, I have never attempted this before.

MTNDD
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
And on a 2.6 kernel...

Since the problem has not been resolved, I switched over to a 2.6 kernel. Unfortunately something similar happens on 2.6.

The main problem is that the MC75 module also dies after a undetermined time, rather than imediately as on a 2.4 kernel.

It may be several hours while there is an active dialup, and very regularly when die modem is idle. The modem then needs to be replugged.

At first glance enumeration seems a bit erratic.

kernel: usb 2-1: new full speed USB device using uhci_chd and address 3
kernel: usb 2-1: device descriptor read/64, error -71
kernel: usb 2-1: device descriptor read/64, error -71
kernel: usb 2-1: new full speed USB device using uhci_chd and address 4
kernel: usb 2-1: USB disconnect, address 4
kernel: usb 2-1: new full speed USB device using uhci_chd and address 5
kernel: usb 2-1: configuration #1 chosen from 1 choice
kernel: cdc_acm 2-1:1.0: ttyACM0: USB ACM device

After this you may get a "kernel: usb x-x: USB disconnect, address x" and the same erratic enumeration happens again. At times this may go on for a couple of minutes. This may also cause the MC75 module to die.

Back to the main problem. Does anyone know why this happens? How can this issue be resolved?
 

YelloFever

MTN Company Representative
Joined
Mar 30, 2006
Messages
4,569
Hi,

We have a similar problem with the Lotto terminals and they also use the Siemens MC75 module.


I'll test these again and advise?

MTNDD
 

WireFree

Well-Known Member
Joined
Oct 23, 2005
Messages
448
The main problem is that the MC75 module also dies after a undetermined time, rather than imediately as on a 2.4 kernel.

It may be several hours while there is an active dialup, and very regularly when die modem is idle. The modem then needs to be replugged.

We have a similar problem with the Lotto terminals and they also use the Siemens MC75 module.
I'll test these again and advise?
MTNDD

Are you'll using the MTN modem, the SAMBA 75 or some other MC75 device?

The MC75 works fine in with the 2.6 kernel - I've tested it with a number of kernels from 2.6.10. There is a bug in the 2.4 kernel. I managed to get it to work once last year on the 2.4 kernel, but I have not had much time to track down the exact code that needs to be fixed.

WireFree
 
Last edited:

Noener

Member
Joined
Sep 19, 2006
Messages
12
All of the above

Actually I've tested this on various MC75 based devices - so all of the above, plus more, I guess.

At first glance it works fine on 2.6 yes, but the module will die eventually. I have tested this is on Suse, Debian, Fedora, Redhat, Mandrake, etc. Even a couple of Live distros.

I you happen to remeber how you did it on a 2.4 kernel, please let me know.

Regards.
 

WireFree

Well-Known Member
Joined
Oct 23, 2005
Messages
448
Actually I've tested this on various MC75 based devices - so all of the above, plus more, I guess.

At first glance it works fine on 2.6 yes, but the module will die eventually.

After how long? Are you connected to the Internet when it dies?

I you happen to remeber how you did it on a 2.4 kernel, please let me know.
I'll get back to you on this. It wasn't easy.
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
After how long? Are you connected to the Internet when it dies?

There is no specific timeframe, rarely after a couple of minutes, but mosly after a couple of hours to a day.

It's very difficult to diagnose due to the lack of timeframe.

The funny thing is that when the modem is idle (ppp not active), then it actually happens very often, say 5min to an hour.

I hope that when an idle modem dies, its for the same reason as is when connected. I'm betting that if I can prevent a idle modem from dying it will solve the problem with a connected modem.

I'll get back to you on this. It wasn't easy.

I appreciate it. Thank you.
 

Noener

Member
Joined
Sep 19, 2006
Messages
12
cdc-acm Alternative?

I've done a couple of USB packet traces, and noticed that when the cdc-acm is not loaded there is not even a hint of trouble. But the moment I load the cdc-acm driver, Linux bombards the MC75 with hundreds of garbage/error packets. No wonder it dies.

I'm thinking about trying some other driver, but I have no idea where to start. Unfortunately the MC75 is not a soft modem, so usbserial does not work.

Is there an alternative to using the cdc-acm driver?
 

YelloFever

MTN Company Representative
Joined
Mar 30, 2006
Messages
4,569
Hi all,

We were unable to reproduce the problem in the lab. We have suggested to the Lotto guys that they request that trace software be loaded on a few of their modules. If the module is locking up, we are unable to catch the fault on the network. Hopefully it can be logged on the module itself. Murray Kruger from Siemens has been contacted and is looking into this possibillity.

Regards,

MTNDD
 
Top