umount leaks /dev/flash/ device slots

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

umount leaks /dev/flash/ device slots

Stanislav Meduna
Hi,

it looks like the mount/umount leak slots in the flashiodev_table.

I.e. if I repeatedly do mount/umount /dev/flash/fis/fs, each
mount allocates one slot, but umount fails to free it. After some
time all the CYGNUM_IO_FLASH_BLOCK_DEVICES slots of flashiodev_table
are filled with a reference to this partition and further mounts fail.

Flash is special in that a reference that is no more needed
has to be cleaned by calling CYG_IO_SET_CONFIG_CLOSE. My guess
is that the umount is not doing this, but I know these
layers too little to be able to quickly find the problem.

Thanks
--
                                   Stano

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

CPULoad on i386

Jim Bradleigh
Hi,

I`ve been trying to get an idea of my applications performance (was < 10% on windows machine) and have been running into problems with the cpuload feature.

cyg_cpuload_get returns zero for all the fields and I`ve debugged into the code and fouind the calibration value is (around) 0x64.

Shouldn`t the high priroty idle thread run more than ~100 times during 100ms? I would expect a massive figure here..(also 100 times in 100 ms sounds a bit like I executed per ms)

I`ve tried this with both my custom repository and a default "i386 with 8139" repository and the results are the same. I`ve removed network cards, ensured a single process CPU (AMD Sempron 2800+) without power managament is used and call the functions at the very start of main()

Anyone got any ideas?

James



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: CPULoad on i386

Jim Bradleigh
Hi,

I found out that by replacing the asm("hlt") command in hal_idle_thread_action with a "nop" causes the ticks reported to jump from 1 per millisecond to about ~160,000 ticks per ms..

Obviously the hlt command is causing the CPU to wait til the next maskable interrupt occurs, in my case this (normally) will be the timer as it is set to tick at 1ms (rather than the eCos default 10ms)

Quick questions:

Is there any harm in letting the Idle run as fast as it can?
How did the cpu load package ever work on an i386 platform?

Thanks,

Jim



----- Original Message ----
From: Jim Bradleigh <[hidden email]>
To: eCos Discussion <[hidden email]>
Sent: Friday, 4 September, 2009 11:11:15 AM
Subject: [ECOS] CPULoad on i386

Hi,

I`ve been trying to get an idea of my applications performance (was < 10% on windows machine) and have been running into problems with the cpuload feature.

cyg_cpuload_get returns zero for all the fields and I`ve debugged into the code and fouind the calibration value is (around) 0x64.

Shouldn`t the high priroty idle thread run more than ~100 times during 100ms? I would expect a massive figure here..(also 100 times in 100 ms sounds a bit like I executed per ms)

I`ve tried this with both my custom repository and a default "i386 with 8139" repository and the results are the same. I`ve removed network cards, ensured a single process CPU (AMD Sempron 2800+) without power managament is used and call the functions at the very start of main()

Anyone got any ideas?

James



--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss


--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss

Reply | Threaded
Open this post in threaded view
|

Re: umount leaks /dev/flash/ device slots

Daniel Zebralla
In reply to this post by Stanislav Meduna
Though this posting is from 2009, I just ran into the same problem recently.

We use a patched JFFS2 file system in eCos on a Freescale MPC5668 processor.
The umount-function there has not released the flash i/o handles, resulting in exactly the described problem: After CYGNUM_IO_FLASH_BLOCK_DEVICES remounts, mount failed because no flash handles were available any longer.

I now added the call to flashiodev_set_config to the umount function as follows:
    if (--n_fs_mounted == 0) {
    jffs2_destroy_slab_caches();
    jffs2_compressors_exit();

    // Release the flash device i/o handler
    flashiodev_set_config(
    jffs2_sb->s_dev,
    CYG_IO_SET_CONFIG_CLOSE,
    (void*) NULL,
    0);
        }

This results in the 'fs-test3.c' test case provided with eCos to run smoothly, re-mounting lots of times.

I wonder however:
1) The documentation "Using FLASH I/O devices" [1] speaks of the function 'cyg_io_setconfig' instead of 'flashiodev_set_config'. I haven't found anything regarding this function name in my eCos base package besides two occurrences in a manual file. Does this function even exist inside the code?
2) The function 'flashiodev_set_config' is statically declared inside 'flashiodev.c'. I had to mess up the code a bit to get this function to be known inside the jffs2-source file as well. Wouldn't it make more sense if functions like this would be declared inside a header file which can easily be included elsewhere?

Regards
- Daniel

[1] http://ecos.sourceware.org/docs-3.0/ref/ecos-flash-iodevice-usage.html