Why CF are cards always "ejected" at suspension?

[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!  

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!  
So I suppose that the instruction for the CF memory cards is elsewhere!
 
the safeboot file is:

Code: [Select]

#!/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!  

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!  

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: [Select]

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    ) will quickly pop up!

Adalberto

[lardman]

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.