OESF Portables Forum
General Forums => General Discussion => Topic started by: amdonati on January 21, 2004, 12:47:06 pm
-
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
-
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.
-
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.
-
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:
#!/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
-
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
-
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.
-
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
-
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 (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.
-
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:
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
-
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.
-
One more reason to start finishing 2.6... any takers?
-
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
-
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
-
Before I learnt how the search works (https://www.oesf.org/forums/index.php?showtopic=5862&st=0&p=65026&#entry65026), I started a new thread on this issue (https://www.oesf.org/forums/index.php?showtopic=10482).
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 (http://www.google.com.au/search?hl=en&q=PXA+pcmcia+Suspend%2FResume+ide_cs+issues) and a PXA patch for something to do with PCMCIA Suspend/Resume (http://www.google.com.au/search?hl=en&q=Richard+Purdie+ARM+PATCH+PXA+PCMCIA+Suspend%2FResume+bugfix).
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.
-
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.
-
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.
[div align=\"right\"][a href=\"index.php?act=findpost&pid=65100\"][{POST_SNAPBACK}][/a][/div]
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
-
this occurs to me for my CF2 on the sled. and only to the Lexar 4x CF, but not Lexar 12x CF
-
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.
-
my 128mb sandisk cf card works fine, no eject.
My 512mb kingston cf card gets ejected, but only on resume.
Peter
-
Hi all. I was discussing this problem with lardman in this tread (https://www.oesf.org/forums/index.php?showtopic=10822&hl=) 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 (https://www.oesf.org/forums/index.php?showtopic=9157&hl=2\.6&st=15) 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.
-
Does anybody know if the 2.6 kernel will definitely fix this?
Of course.
-
Does anybody know if the 2.6 kernel will definitely fix this?
Of course.[div align=\"right\"][a href=\"index.php?act=findpost&pid=67529\"][{POST_SNAPBACK}][/a][/div]
Of course you know or of course it will? (just kidding)
Kewl. Good to know. Now I'm really looking forward to 2.6. thks