Stale cached data in bdbuf creates problems

ali nasir supremenasir at
Thu May 3 09:02:54 UTC 2012


I see that in your example code you use two different device file names (/dev/rda and dev/rdb). 
In our application, when we insert the SD card first time (there can be only one SD card at any time due to SPI bus limitation), we use the device file name as /dev/sdc0 and the /dev/sdc01 is mounted on /mnt/sdcard. Then, we unmount the card using the routines as mentioned earlier, and then insert a different card ans use the same device file name (/dev/sdc0) to mount the second card. 

Note that if i use a different device file name (for eg /dev/sdc1 and /dev/sdc11 (first partition)) for every new SD card insertion, then i do not see this problem of the bdbuf cache. Hence each time i need to increase the count (/dev/sdc2, /dev/sdc3) and then at some point, i need to limit it, which is not good for our application. 

I will put the trace on and take the traces. I tried to debug if the BDs are set as EMPTY when calling the purge_dev, but it is hard to debug due to the optimization. I have now put some prints also in the gather_purge_list function. Will update you soon.


On Wed 2 May, 2012 6:01 PM IST Sebastian Huber wrote:

>attached is a small example that demonstrates the disk usage with two RAM disks.  It shows also that the principal mechanics work in RTEMS 4.10.
>On 05/02/2012 12:27 PM, ali nasir wrote:
>> Hi,
>> After running the below unmount sequence, i put a break point at the said place.
>> Then when a new device is inserted, the system tries to read the MBR. When the control comes at the break point, the bd is in the state RTEMS_BDBUF_STATE_CACHED.
>Ok, there must be an error here.  The state should be RTEMS_BDBUF_STATE_EMPTY.  Maybe it helps to enable the bdbuf tracing (in bdbuf.c):
>bool rtems_bdbuf_tracer = true;
>-- Sebastian Huber, embedded brains GmbH
>Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany
>Phone   : +49 89 18 90 80 79-6
>Fax     : +49 89 18 90 80 79-9
>E-Mail  : sebastian.huber at
>PGP     : Public key available on request.
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the users mailing list