MSDOS FS / MMC / rtems_io_register_name too many
ppisa4lists at pikron.com
Sat Dec 31 00:42:00 UTC 2005
thanks for fast reply.
On Friday 30 December 2005 21:27, Thomas Doerfler (nt) wrote:
> Pavel Pisa schrieb:
> > Hello Thomas and others,
> > I have one question related to RTEMS block devices.
> > I observe, that rtems_io_register_name() reports "too many"
> > in RTEMS-051009 checkout during my driver registration.
> > Base filesystem holding /dev entry is full version of IMFS.
> RTEMS objects have a static allocation scheme. The "too_manny" error
> signals, that you cannot create a new object because it would exceed the
> object storage. In your case, either the "maximum devices" (most
> probable) or "maximum_drivers" or "number_of_device_drivers" entries
> should be increased, see your "system.h" file and the "confdefs.h" which
> is included there.
I hope, I understand that. There are some exceptions with free workspace
allocation for more objects which has been discussed on the list in the past.
That is OK with me, but as I have described, I do not observe any missing
object after failed rtems_io_register_name() call. The partition table
then registers even one more device (minor and named node) after that call.
Everything works as expected, only my rtems_io_register_name() call returns
error status. If you do not have idea, do not lost time with me, I try to
trace the cause step by step when I find some time for that.
My system configuration is attached at the end of the e-mail.
I have one more question, if you find time to answer.
The block swapper thread is declared with preemption disabled.
rc = rtems_task_create(
rtems_build_name('B', 'S', 'W', 'P'),
RTEMS_DEFAULT_MODES | RTEMS_NO_PREEMPT,
Then it changes preemption mode during run. When it calls BLKIO_REQUEST
the preemption seems to be disabled. I call MMC/SD routines directly
from these calls, but these routines are huge and sleeps, use semaphores
etc. So I change mode to preemptible and then again back to previous mode
before return. As I understand, the better model is to move BLKIO_REQUESTs
to private block driver queue, because I block whole BSWP this way.
I try to implement this in future but I would like to defer this for now.
Is that strictly necessary or it is not problem if only one block device
is used? Even if I add worker thread, I am not so much happy, that relatively
long pieces of the code are run in preemption disable state.
I have more drivers and event processing requiring fast reaction time done
in my worker threads and I do not like longer latencies from their IRQ
handlers. All my IRQ handlers are really only stop/disable IRQ source
and wake worker. Has somebody analyzed blkdev impact on latencies?
I have more fixes and changes for ARM targets in my stack.
Is there some possibility to synchronize these into CVS?
Should I register into GNATSWEB and add there problem
reports? Who is willing and have some time to audit ARM
/* configuration information */
#include <bsp.h> /* for device driver prototypes */
#define TICKS_PER_SECOND 1000
#define CONFIGURE_MAXIMUM_TIMERS 32
#define CONFIGURE_MAXIMUM_MESSAGE_QUEUES 32
#define CONFIGURE_MAXIMUM_SEMAPHORES 64
#define CONFIGURE_MAXIMUM_TASKS 32
#define CONFIGURE_LIBIO_MAXIMUM_FILE_DESCRIPTORS 32
#define CONFIGURE_MAXIMUM_DRIVERS (CONFIGURE_NUMBER_OF_DRIVERS+10)
#define CONFIGURE_MICROSECONDS_PER_TICK 1000
#define CONFIGURE_INIT_TASK_STACK_SIZE (10*1024)
#define CONFIGURE_INIT_TASK_PRIORITY 120
#define CONFIGURE_INIT_TASK_INITIAL_MODES (RTEMS_PREEMPT | \
RTEMS_NO_TIMESLICE | \
RTEMS_NO_ASR | \
/* end of include file */
More information about the users