[ECOS] umount leaks /dev/flash/ device slots

[ECOS] 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

[ECOS] 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

Re: [ECOS] 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 <jim.bradleigh1@btinternet.com>
To: eCos Discussion <ecos-discuss@ecos.sourceware.org>
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

[ECOS] Re: umount leaks /dev/flash/ device slots

[Daniel Zebralla]

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



--
View this message in context: http://sourceware-org.1504.n7.nabble.com/umount-leaks-dev-flash-device-slots-tp195700p250770.html
Sent from the Sourceware - ecos-discuss mailing list archive at Nabble.com.

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