MSDOS FS / MMC / rtems_io_register_name too many

Pavel Pisa ppisa4lists at
Sat Dec 31 00:42:00 UTC 2005

Hello Thomas,

thanks for fast reply.

On Friday 30 December 2005 21:27, Thomas Doerfler (nt) wrote:
> Pavel,
> 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'),

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
code changes?

Thanks again


/* configuration information */

#include <bsp.h> /* for device driver prototypes */


#define TICKS_PER_SECOND 1000

#define CONFIGURE_MAXIMUM_TIMERS                 32
#define CONFIGURE_MAXIMUM_TASKS                  32




                                           RTEMS_NO_TIMESLICE | \
                                           RTEMS_NO_ASR | \

#include <rtems/confdefs.h>

/* end of include file */

More information about the users mailing list