Compact Flash - can only be used as not-removable!

Hi. Here is a problem: I have a Compact Flash attached in true IDE mode to a board running

2.6.14 Linux. I had problems with putting a file system on it, among others - failing to run mke2fs on a partition of this CF (/dev/ hda1).

After some (much...) debug, I found out that marking it not-removable (do_identify, ide-probe.c) solves all the FS problems.

I have 2 questions:

  1. Can I use a CF connected in true IDE mode (directly to the board, no controller) as "removable"? Let's say I don't really intend to remove it - but I'd like to keep the kernel source intact.

  1. How does the "removable" thing work (or not work in my case) - is there any sensing of the "CF detect" bits, or some other mechanism?

Some details (thanks for still listening...):

strace mke2fs /dev/hda1

... (get to the sad part) stat64("/dev/hda1", {st_mode=S_IFBLK|0660, st_rdev=makedev(3,

1), ...}) = 0 open("/dev/hda1", O_RDONLY|O_EXCL) = 3 close(3) = 0 open("/dev/hda1", O_RDONLY|O_LARGEFILE) = -1 ENOENT (No such file or directory) write(2, "mke2fs", 6mke2fs) = 6

As you can see, the second open fails. I tried calling open("/dev/hda1", O_RDONLY|O_EXCL) both times - it fails the second time anyway. Calling open() by dd works, no matter how many consecutive calls are involved.

Some prints on the kernel side: dmesg -c [ 630.143471] fs/block_dev.c, blkdev_open: 690 [ 630.148512] fs/block_dev.c, do_open: 566 [ 630.153908] fs/block_dev.c, blkdev_get: 680 [ 630.159771] fs/block_dev.c, do_open: 566 [ 630.164983] drivers/ide/ide-disk.c, idedisk_open: 1133 [ 630.171814] In idedisk_open: after ide_disk_get [ 630.177660] drivers/ide/ide-disk.c, idedisk_media_changed: 1197 [ 630.185213] drivers/ide/ide-disk.c, idedisk_revalidate_disk: 1210 [ 630.201560] drivers/ide/ide-disk.c, idedisk_revalidate_disk: 1210 [ 630.208776] hda: hda1 [ 630.227984] fs/block_dev.c, do_open: 644 --- normal exit [ 630.234522] fs/block_dev.c, do_open: 644 --- normal exit

As you can see, the blkdev_open is only called once. I wonder where the second call gets lost... The answer to it all may well lay there.

Thanks a lot, /Michael

Reply to
Mic
Loading thread data ...

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.