New versions of fdisk and e2fsprogs

[TonyOlsen]

You are right.  Some of my attempts above were in bash but all of the sucessful mont/umounts were in su.

Thanks for letting me know about mount itself.

Here's the output of "cat /atc/fstab"

Code: [Select]

bash-2.05$ cat /etc/fstab
/dev/mtdblock2  /               jffs2   ro,noatime      1  1
/dev/mtdblock3  /home           jffs2   defaults,noatime        1  2
none            /dev/shm        tmpfs   size=1m,noauto  0  0
/dev/hda1       /mnt/cf         auto    noauto,owner    0  0
/dev/mmcda1     /mnt/card       auto    noauto,owner    0  0
none            /dev/pts        devpts  gid=5,mode=620  0  0
bash-2.05$
Cool...

...so ... what does it mean?        

[Greg2]

...so ... what does it mean?        

Well...it means your fstab is ok...
but I don't know what your prob is...sorry

Greg

[TonyOlsen]

--

[TonyOlsen]

Maybe my computer just has issues it needs to work through.  Maybe it needs to see a phychiatrist or something...  

Are there any physical settings/switches on the MMC itself which may need to be adjusted?

[lardman]

You are right. Some of my attempts above were in bash but all of the sucessful mont/umounts were in su.

Random point: You realise that bash is the program which you are using, while su simply changes the current user? So normally you run as user 'zaurus', but by using su (without an argument) you become user 'root'.

It's getting late for me. I'll take another look through your posts tomorrow, but I'd be tempted to start afresh (using root for everything, except when you want to prove a point):- remove current partitions, create anew, format, mount, then see what happens (I'm sure you've already done this, but, as I've indicated, I need some time to read through to work out what you were doing and when -- not now, too late, tomorrow.


Si

P.S. I don't think that MMC cards have a read-write tab on the side; If they do it's pretty obvious.

P.P.S you card seems to work after a fashion ;-), it might be worth summarising your current position... then we can go from there; tomorrow.

[iamasmith]

Tony,

Could I firstly ask for the following outputs.

Zaurus type and ROM version.

Type 'mount' on its own with the card mounted, I would like to see what switches it's mounting with. Probably most useful if you just plug in the card and let it automount.

ls -ld /mnt/card

(if symlinked please repeat to the syminked location).

Finally after attempting to write something to the card could you send the last few lines returned by the dmesg command.

Regards,

- Andy

[TonyOlsen]

Quick note before I address the questions above: In WhatsUpOnZ (version 0.3b) I notice the following threads in the list:

• sdmgr
• cardmgr

So... the Zaurus uses these threads to communicate to the CF and SD/MMC cards?  Could there be something wrong with these threads (or are these the drivers?)

Zaurus type and ROM version.

Sharp Zaurus SL-C860.  The QTopia ROM that came with the machien from Dynamism.  In system info, it says:

• Metrowerks OpenPDA, Version: 1.0, Incorporating: <nothing>
• QTopia for OpenPDA, Version: 1.5.4, Compiled by: Trolltech - www.trolltech.com, Built on: Nov 6 2003
• Linux Kernel, Version:, 2.4.18-rmk7-pxa3-embedix, Compiled by: SHARP, ROM Version : 1.20 JP

I'll list the rest from my Zaurus itself (copy and paste is easier that way...  )

[TonyOlsen]

Random point: You realise that bash is the program which you are using, while su simply changes the current user? So normally you run as user 'zaurus', but by using su (without an argument) you become user 'root'.

No, I didn't know that.  I had always assumed "su" was the "super user" or "root".  Thanjs for the note.

I'll take another look through your posts tomorrow, but I'd be tempted to start afresh (using root for everything, except when you want to prove a point):- remove current partitions, create anew, format, mount, then see what happens (I'm sure you've already done this, but, as I've indicated, I need some time to read through to work out what you were doing and when -- not now, too late, tomorrow.

I gone through the entire process from beginning to end maybe a dozen times during these posts.  I have the process memorized now...  

P.P.S you card seems to work after a fashion ;-), it might be worth summarising your current position..

My current position/status is that the card can be partitioned, formated, mounted, unmounted, and even pass (assuming I read the ouput I posted above correctly) a full surface scan... but as soon as new data gets written to the card in the Zaurus (this doesn't happen from Windows98) the write process never completes.  Suspending th Zaurus appears to kick the frozen process and the changes appear, but until that point the card is locked up and can't be unmounted.

Figuring out what process is locking up during a write attempt to the card and why it is locking up... that sounds like it may be the solution.  Outdated driver?  1 GB MMC card limit?  (Has anyone known someone to use a 1 GB MMC succesfully in the Zaurus?  Are we coming across somthing related to the new size?)

My mount info:

Code: [Select]

bash-2.05$ mount
/dev/root on / type jffs2 (ro)
/proc on /proc type proc (rw)
/dev/ram1 on /dev type minix (rw)
/dev/mtdblock3 on /home type jffs2 (rw,noatime)
none on /dev/shm type tmpfs (rw)
none on /dev/pts type devpts (rw)
/dev/mmcda1 on /usr/mnt.rom/card type vfat (rw)
bash-2.05$                                                                  
(My CF card isn't showing up because I don't currently have it plugged in... I'm instead using my CF Wireless card so that I can send this message)

ls -ld /mnt/card

(if symlinked please repeat to the syminked location).

Code: [Select]

bash-2.05$ ls -ld /mnt/card
lrwxrwxrwx    1 root     root           17 Nov 27  2003 /mnt/card -> /usr/mnt.rom/card
bash-2.05$ ls -ld /usr/mnt.rom/card
drwxrwxrwx   12 root     root        16384 Dec 31  1969 /usr/mnt.rom/card
bash-2.05$      

Finally after attempting to write something to the card could you send the last few lines returned by the dmesg command.

I did:
su
cd /mnt/card
mkdir test9
ls
(all of the previous directories showed up minus the new test9 directory)

Code: [Select]

...etc... (pages and pages of stuff)
SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
pxa_sd_wait_response: responce time out (cmd=07 MMC_STAT=0x2142)
sd_write_single(1) : select error
sd flush : ERROR adr = 32768 (0x8000) , len = 512 (0x200)
[SD]-R 46200 0200 ERROR!
#        
hm... a lot of errors.  hm...

[iamasmith]

Tony,

It seems from looking at some of the other threads that this is a common issue with some cards that work well with other devices but not with the Z.

If you have the opportunity I would see if you can exchange the card for a different brand, if not then it may be worth trying to acquire the mmcda driver from the 1.40JP ROM and see if this is updated (I suspect there is a possibility that it may be because there are some SD/MMC fixes in the description). Please note, however, that if you flash 1.40JP then you will probably have to run an English conversion against it to get it back to a workable state for you. Alternatively you could try stripping the driver from the jffs2 image in the update as I believe the base kernel is the same.

Regards,

Andy

[TonyOlsen]

Ok... now we're getting somewhere!  ...although the news isn't good.

So... it's most likely a software/driver issue then.  (I thought MMC cards are the same.  Maybe all MMC card interfaces are equal, but some are just more equal?    )

I can't return the new MMC card... it had a limited time frame to return it and I've already used that up.  That's ok, though... if worse comes to worst, then I'll simply use it in my digital camera (mega overkill, though).

Stripping the updated driver out and installing it here on my Zaurus sounds like a good idea.  Can anyone help with this?  I've never worked with the ROMs before.  Is it simply replacing a single file (the SDMGR file I noticed above?)?  Where would I find this new ROM?

Should I start a new thread for this, or should this continue here?

[iamasmith]

Tony,

OK, sorry, that was a bit lazy. Have grabbed the driver from this latest ROM and it seems to be the same version as the one in the current Cacko ROM (1.21b).

Drop to the command prompt and type :-

ls -l /lib/modules.rom/2.4.18-rmk7-pxa3-embedix/kernel/drivers/block

If this comes back with a file size for sharp_mmcsd_m.o of 40222 bytes then it sounds like you have the latest driver.

If not then leave a note and I will mail it to you.

Regards,

- Andy

[TonyOlsen]

No problem... you've already been extremely helpful to me here.

Code: [Select]

bash-2.05$ ls -l /lib/modules.rom/2.4.18-rmk7-pxa3-embedix/kernel/drivers/block
-rw-r--r--    1 root     root        40222 Oct 10  2003 sharp_mmcsd_m.o
bash-2.05$        
*sigh*  

Can we be pretty sure, though, that it isn' a hardware issue?  If so, then I'm sure that eventually there will be an updated driver.

Am I the first person to try to use a 1 GB MMC card on the Zaurus?  If not, has anyone gotten their 1 GB MMC working before?

I think I'll try partitioning it for 900 MB and see if that solves anything (in case the size is the probelm here...)

I AM relieved, though, that this doesn't appear to be due to any defect in the card itself.  Since I bought the card for so cheap (less than $100), that was one of my first concerns.  

[iamasmith]

Tony,

OK, that's a shame.

One last thing that has worked for some people (in other threads) although if it does work the only logic that I could apply would be some bizarre guesses is.

1. Create the partition table again with fdisk (o, n, primary partition 1, type 04, write).
2. Use mkfs.msdos /dev/mmcda1 (rather than vfat).
3. Eject the card, reinsert and give it a try.

For some inexplicable reason some people have managed to salvage their cards using this format - although why it would cause driver type issues causes for some deep speculation (logic on the card ?).

- Andy

[lardman]

My current position/status is that the card can be partitioned, formated, mounted, unmounted, and even pass (assuming I read the ouput I posted above correctly) a full surface scan... but as soon as new data gets written to the card in the Zaurus (this doesn't happen from Windows98) the write process never completes. Suspending th Zaurus appears to kick the frozen process and the changes appear, but until that point the card is locked up and can't be unmounted.

Sorry to labour the point; can you try this:

$ su
# mount /mnt/cf
# cd /
# touch /mnt/cf/test_file
# mkdir /mnt/cf/test_dir
# ls -rtl /mnt/cf
# umount /mnt/cf

# mount /mnt/cf

From what you've said I assume that one or both of mkdir and touch will not finish. If they do, then I assume that what you mean is that the changes won't be made, so ls shouldn't show anything. Your 'cat fstab' doesn't show the cf card so I can't tell whether sync is on or off (I think that's the right parameter), you might try looking into this before giving up - Linux caches disk writes, obviously umount'ing will cause the cache to be flushed to the disk, there's an option you can use in fstab to make writes happen immediately, though it's not recommeded as it can slow things down, but at least it'll eliminate a possibility.

See what happens (I'm sure you're bored of all of this by now, sorry ;-).


Si

[iamasmith]

From what you've said I assume that one or both of mkdir and touch will not finish. If they do, then I assume that what you mean is that the changes won't be made, so ls shouldn't show anything. Your 'cat fstab' doesn't show the cf card so I can't tell whether sync is on or off (I think that's the right parameter), you might try looking into this before giving up - Linux caches disk writes, obviously umount'ing will cause the cache to be flushed to the disk, there's an option you can use in fstab to make writes happen immediately, though it's not recommeded as it can slow things down, but at least it'll eliminate a possibility.

Lardman,

From the boxer-j file in linux/arch/arm/def-configs for the stock kernel source on the SL-C860 1.20JP (and 1.10JP) ROM...

CONFIG_FS_SYNC=y

This pararmeter was added by Sharp to force sync even without the mount options so it's probably going to make little difference with a stock kernel.

- Andy