Cf Card Type Serial Device Is Busy

[euroclie]

Hi all,

I've been spending some time recently trying to make my EagleTec GSM/GPRS CF card work on the SL-C3000 Zaurus, but it seems I'm stuck right now...

I've tried various solutions / hints and right now the card is correctly recognized by a "cardctl ident" command, I can talk to it using /dev/ttyS3 using minicom (it answers OK to my AT commands, I can dial a number, etc...

That being said, anytime I try to connect using the GUI, I get a nice "CF card type serial device is busy" error dialog from the Dialup application. I've noticed, in addition, that whenever I insert the card in the Zaurus, it remains suspended (LED doesn't blink) until I enter a "cardctl resume" command in the terminal. The strange thing is that it always return a "ioctl(): Device or resource busy" error message, but as soon as I resume the card, the LED start blinking nonetheless and I can communicate with the card using minicom.

I tried issuying a "cardctl suspend" before connecting using the GUI, but I got only a nice crash and had to remove the battery to reboot...

FWIW, dmesg reports, when I insert the CF card:

ttyS03 at port 0xf60003f8 (irq = 135) is a 16C950/954
pxa_pcmcia_suspend(0)

I have installed the kernel and serial script from the docs at www.steyla.com (as advised by the Ambicom Cf Gprs Card thread, with no luck.

I even tried a factory reset, and install only the same steyla kernel and serial script, still the same problem...

I suspect that it's pcmcia-related, but my limited knowledge didn't lead me to an obvious solution...

What surprise me is that it seems to work OK with minicom, despite the initial ioctl() error when awaking the card, but not with the rest...  

Thanks to anyone that can provide a hint/pointer/help...

[euroclie]

Hi all,

Just wanted to let you know that the answer to my problem was rather simple - if unexpected for me.

It turns out that if I do not wake up the card (i.e. if I don't issue the "cardctl resume 0" command) on insertion, then the GUI dialer works OK. If on the other hand I wake up the card first (to use it with minicom, for instance), then the GUI give the "card busy" error, unless I suspend the card first.

My initial mistake (see previous post) was that when I decided to suspend the card first, I typed "cardctl suspend" without specifiying the slot number, so I suspended both the GSM/GPRS CF card (which was what I was looking for) and the internal hard drive (which is definitely NOT good on a running device, hence the crash). I should have typed "cardctl suspend 0" instead!

I still don't know why the GUI dialer complains when the card is already switched on but unused by any other application, but at least now that I pinned the problem, I can handle it, manually if needed.

[dhns]

I have a similar experience with the Audiovox RTM 8000 (which seems to be the same device).

My understanding is as follows:
1. if you do a cardctl resume on an already resumed card, you get the ioctl() error
2. if you do a cardctl suspend on an already suspended card, you get the ioctl() error
3. the RTM 8000 comes up in resumed state (contrary to several other cards I have, e.g. the Billionton CF GPS which starts suspended)

So, this explains your errors - the card is already in a resumed state and some software isn't prepared for that.

What I have not working any more (and reliably) is accessing the card. On my current test device (C860) it will not initialize the serial device or create a link to /dev/modem. It had been running once or twice using minicom but I have not yet figured out the proper sequences to do so reliably.

I have to note that I have added the modified serial_cs.o which should properly enable Vcc (as described in other threads). And I have a private audiovox.conf that should load the serial module - but lsmod remains empty.

And finally there is the setserial issue to install the proper UART device driver.

-- hns

[dhns]

Update #1:

the first issue has been solved: I forgot to issue

Code: [Select]

depmod -a
modprobe serial_vcc_cs during installation

Now the device shows up as /dev/modem

-- hns

[euroclie]

My understanding is as follows:
1. if you do a cardctl resume on an already resumed card, you get the ioctl() error
2. if you do a cardctl suspend on an already suspended card, you get the ioctl() error

I second your analysis: back when I did my first tests, I issued simply "cardctl resume" commands, so the command would try resuming both a suspended card in slot 0 (the GSM/GPRS CF card) and the (already running) builtin microdrive in slot 1, hence the ioctl() error I got. Now that I properly issue a "cardctl resume 0" command, the ioctl() error doesn't show up anymore.

3. the RTM 8000 comes up in resumed state (contrary to several other cards I have, e.g. the Billionton CF GPS which starts suspended)

So, this explains your errors - the card is already in a resumed state and some software isn't prepared for that.

Unlike the Audiovox, my Eagletec card comes up in a suspended state. Or maybe this can be setup somewhere in one of the various scripts which deal with CF cards? FWIW I do not have a serial_cs module that gets loaded upon card insertion, the serial support is builtin in the kernel. Maybe insmoding the appropriate module will as a side effect resume the associated slot? Can't really check that blind guess, though, I'd have first to recompile the kernel and set serial_cs (with the Vcc stuff) as a module. Too busy at the moment, I decided to just install the special steyla.com kernel!

And finally there is the setserial issue to install the proper UART device driver.

By chance I didn't have to play with setserial to get it working...