Help - Search - Members - Calendar
Full Version: Why CF are cards always "ejected" at suspension?
OESF Portables Forum > General Forums > General Discussion
amdonati
Hi,

Till now I never considered much more than "annoying" the fact that every time you suspend and resume the Z, a CF card is "soft ejected and inserted" (on my TKC ROM 1.0 rom).
This is because I only had a BT card and I never have it connected when I suspend! smile.gif

But now I have bought a 2.2 GB microdrive, and this problem is becoming a serious issue because:
1) I have crated a swap partition on it and it cannot, of course, work if the CF is continuously ejected and reiserted!
2) I have created 2 partitions, one VFAT and one EXT2. As long as I cannot solve my IDE.OPTS issue (how to automoutn both partition at card insertion!), I have to manually mount the second partition, and it is really irritating if I have to do it at every resume (and this would, for example running zdebiam almost inpossible!)
:cry:

Why cn an SD card stay in the Z without being continuously ejected and a CF no?
Is there a turnaround to this?

I would be really grateful for any help.

Adalberto
Foxdie
The reason CF cards are reset on a suspend / resume cycle was because it was causing problems with certain communications cards (for example bluetooth)

To disable the suspend / resume take a look in /etc/apm.d/ and there's 2 subfolders (this is on my Cacko Qtopia ROM which should be near identical) called resume.d and suspend.d and within each contain whatever scripts are set to run on suspend / resume etc.

You COULD tweak it so that it turns the swap file off when you suspend and turns it back on again after a resume.
tumnus
The suspend resume stuff should only eject and reinsert a card if it was a Bluetooth card. AFAIK there is not a problem with those scripts since my memory CF card does not get ejected on a suspend/resume cycle.

I have heard of the Z ejecting and reinserting some CF cards though and it seems to be quite random which cards it does it with.
amdonati
Does it make sense to turn off and on the swap at every suspend?
Especially if you have a big swap and have a high usage of Ram (which is what I expect if I have Zdebian and qtopia running together)?

I tried to see if it was possible to avoid the CF eject
at suspend and gave a look in /etc/apm.d.
In suspend.d I have 2 files S90Bluetooth and S10safeboot, while in resume.d I have only R45bluetooth
I tried to remove the bluetooth filesfrom the suspend and resume dirs and so the BT card was not ejected anymore, but the microdrive yes! sad.gif
So I suppose that the instruction for the CF memory cards is elsewhere!

the safeboot file is:
CODE
#!/bin/sh

#

# SafeBoot: Works in conjunction with a

# modified halt init script to stop the

# deadly double-reboot-hang bug.

#

# This should be run on every suspend



case $1 in

'suspend')

  echo `date +'%x %X'` > /tmp/has-suspended
;;

'resume')

  echo No resume action for safeboot

  exit 1
;;

*)

  echo Unknown argument for safeboot: $1

  exit 2
;;

esac



exit 0


Is it him who ejects the Microdrive?
If not, who is it?
On the other hand, if it makes sense to turn off and on the swap at every suspend/resume, what should I add in the suspend and resume dirs?

Thanks for the help!
Adalberto
amdonati
Sorry Tumnus, I was writing my reply at the same time as yours! biggrin.gif

From what I could see (and wrote in my previous post), the BT scripts only work for BT cards, I do not know if the safeboot script have something to do with it, but I doubt.

So apparently the problem is that the Z does not like my microdrive! sad.gif

Isn't there soem turnaround to this?

Adalberto
tumnus
The CF control stuff is in /etc/pcmcia/ide , but I'm not sure why a CF card would get ejected for one person and not another. There is a certain logic to turning off the swap and ejecting the card on suspend since you could take the card out while it is suspended and then turn it back on again. Yet the Zaurus doesn't seem to be very consistent about this.

You could try running the 'dmesg' command after resuming your Zaurus to see if it reports any errors.
amdonati
I have a 32 mb Sandisk CF card I use for Flashing, and indeed it does not eject at suspension!
So it is apparently a problem with the microdrive :-(

Is there some solution to this?

Otherwise, what should I do to have the swap automatically turned off and on and suspend/resume (eject/insert)?

Where should I enter the swapon swapoff commands?

Adalberto
tumnus
Does dmesg show any errors after you resume your Zaurus with the Microdrive in it?

The safeboot script is a simple example of how to get commands to run on suspend and resume. There is also an explanation here: http://www.cpinkney.org.uk/zaurus.html#susp-resume . Although if the microdrive is being ejected after the resume then you might have to put some commands in to wait until the microdrive has been remounted before enabling swap. Either way it would make suspending and resuming take a long time if you turn the swap off and on.
amdonati
I agree on the time needed for mounting the swap every time, this is why I would prefer to have it always on!
I could craete a big swap on the SD I have always in, but I have read that sd cards risk to be "consumed" very quickly with all the read/writes a swap requires ; and it would be Waaay slower than the microdrive!

Any way, here is the (relevant) dmesg part for when I suspend/resume:
CODE
monitor_hotplug: agent: usbd interface: monitor action: suspend

usbdcore: usbdcore 0.1 035 2002-06-12 20:00 exiting

monitor_pm_event: suspend finished (rc=0)

invalidate: busy buffer

sa1100_pcmcia_suspend(0)

screen backup!

suspend main adc = 579(579)

fatal chk = 373

suspend backup adc = 438(438)

screen restore!

comadj = 157,44414d43,44414d43

sa1100_pcmcia_init(0)

sa1100_pcmcia_init(0)

ide_release(0xc1b2c3e0)

in_interrupt

sa1100_pcmcia_init(1)

sd : cmd [ 0 ] response [ 03  ]

sd : cmd [ 55 ] response [ 05  ]

hotplug_schedule_bh: schedule bh

hotplug_bh:

monitor_connected: 1

monitor_restore: RESTORE_LOADED

monitor_hotplug: agent: usbd interface: monitor action: restore-loaded

usbdcore: usbdcore 0.1 035 2002-06-12 20:00 (dbg="")

net_fd 0.1 035 2002-06-12 20:00 (dbg="",alwaysup=0,OUT=64,IN=64)

vendorID: 4dd productID: 8004

sa1100_bi 0.2 035 2002-06-12 20:00 (dbg="")

bi_modinit: call udc_startup_events

bi_device_event: call udc_enable

bi_device_event: call udc_all_interrupts

ide_detach(0xc1b2c3e0)

ide_release(0xc1b2c3e0)

ide_attach()

ide_config(0xc1b2cde0)

hda: GS-Magicstor 1022C 23080803, ATA DISK drive

ide0 at 0xc5270000-0xc5270007,0xc527000e on irq 35

hda: 4194126 sectors (2147 MB) w/128KiB Cache,

CHS=4160/16/63

hda: [PTBL] [261/255/63] hda1 hda2 hda3

ide_cs: hda: Vcc = 3.3, Vpp = 0.0

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

EXT3-fs: Unrecognized mount option quiet

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

EXT2-fs: Unrecognized mount option quiet

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

cramfs: wrong magic

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Can't find a Minix or Minix V2 filesystem

on device 03:01.

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

VFS: Disk change detected on device ide0(3,1)

hda: hda1 hda2 hda3

MSDOS FS: IO charset utf8


Is this of any help?

Adalberto
maslovsky
This is the ARM kernel problem. It existed for ages. It also depends on particular CF card wether it will be reinserted on resume or not. It's rumored to be fixed in newver kernel versions, but they are not yet available on Zaurus.
Mickeyl
One more reason to start finishing 2.6... any takers?
amdonati
So, If it is unavoidable that the Microdrive reinserts at every resume, would this make impossible or barely unusable zdebian on it?

If I start a zdebian session and I suspend, at resume (and after the eject/restart ) will the zdebian session be there (after all, vnc and the vnc server should be running in RAM) or the connection to the chrooted environment will be broken?



Mickey, I really hope someone that has at least the basic skills needed to help on the kernel work (and this is, unfortunately, not me sad.gif ) will quickly pop up!

Adalberto
lardman
QUOTE
One more reason to start finishing 2.6... any takers?


Er, if I can get hold of it....

I might start off with looking at 2.4.18 and 2.4.21cl though; Mickeyl you provided me with a tarball of 2.4.21cl a long time ago, I presume changes have been made since then (though looking at the commits in the bitkeeper repository I couldn't see anything younger than 6 months old).

As I stated, I use Windows and the kernel source seems to have case-sensitivity issues (conflicts). Any ideas?

Thanks,

Si
gojira
Before I learnt how the search works, I started a new thread on this issue.

This is what I've found out since then: Apparently it only affects some CF cards and is a kernel bug only in the ARM version. There is a description of a PXA PCMCIA Suspend/Resume bug and a PXA patch for something to do with PCMCIA Suspend/Resume.

In addition to the questions I raised earlier, here are some others: Which cards are affected? Why only those? Does this patch fix the problem? Has anyone tried applying it to 2.4?

Thanks.
omega
This happens with my IBM 340MB microdrive... but not with my 1gig CF Flash. It seems from reading the above that this is a microdrive issue.
danr
QUOTE(omega @ Feb 2 2005, 11:10 AM)
This happens with my IBM 340MB microdrive... but not with my 1gig CF Flash. It seems from reading the above that this is a microdrive issue.
*


Alas this problem also occurs with my 256 MB Kingston CF card, both on an SL-C860 and SL5500, so it must be CF card device-specific. I wonder why some CF cards eject but not others?

Dan
xjqian
this occurs to me for my CF2 on the sled. and only to the Lexar 4x CF, but not Lexar 12x CF
systemparadox
QUOTE(amdonati @ Jan 22 2004, 12:09 PM)
I agree on the time needed for mounting the swap every time, this is why I would prefer to have it always on!
I could craete a big swap on the SD I have always in, but I have read that sd cards risk to be "consumed" very quickly with all the read/writes a swap requires ; and it would be Waaay slower than the microdrive!


Are you saying that SD cards are much slower than CF?

I have the eject/insert problem with my Maxell 64Mb CF Card (not a microdrive)- I would like to have it in all the time, but the eject/insert on resume adds an extra 8 seconds to my resume time, and it seems to cause stability issues.
zbones
my 128mb sandisk cf card works fine, no eject.
My 512mb kingston cf card gets ejected, but only on resume.

Peter
grog
Hi all. I was discussing this problem with lardman in this tread until he pointed me here. It seems I'm having the same problem with a Lexar High Speed (32x) SD card. So it doesn't seem restricted to just CF items.

Does anybody know if the 2.6 kernel will definitely fix this? There's currently a thread on what's happening with 2.6 & the possibility of it getting into OZ 3.5.3, so I for one am looking forward for that.
Mickeyl
QUOTE
Does anybody know if the 2.6 kernel will definitely fix this?


Of course.
grog
QUOTE(Mickeyl @ Feb 17 2005, 12:37 PM)
QUOTE(GROG)
Does anybody know if the 2.6 kernel will definitely fix this?
Of course.
*

Of course you know or of course it will? biggrin.gif (just kidding)

Kewl. Good to know. Now I'm really looking forward to 2.6. thks
This is a "lo-fi" version of our main content. To view the full version with more information, formatting and images, please click here.
Invision Power Board © 2001-2017 Invision Power Services, Inc.