Problem with mounting a device second time.

[ali nasir]

Hi,

Since i am still not able to figure out the problem of SYNCing while transfer is in progress, we have removed this call to the ioctl after the fopen, fwrite and fclose.

But we still do the BDBUF_SYNCDEV during the unmount of the device. 

But now we see another problem.
Sometimes, even if the unmount is successful and the mount of the next card is also successful, we see that when we do a 'ls' command on the mnt/sdcard, the contents we see is that of the card which was previously present in the system. We do not see any data of the current card. In this situation, the OS does not write anything on the current card. But when we debug on the low level driver, we see some writes happening because of the cp command. 

It does not happen always, but is more frequent. We do the following during the unmount:

unmount("/mnt/sdcard")
rmdir("/mnt/sdcard")
rtems_bdbuf_syncdev(dev)    //dev is created using the rtems_filesystem_make_dev_t(major, minor)
rtems_disk_delete(dev)
rtems_bdbuf_purge_dev(dev)
rtems_io_unregister_driver(major)

Do we miss something during the unmount? Do we have to clear something in the bdbuf also? If yes, how?

Regards,
Ali



------------------------------
On Mon 23 Apr, 2012 3:11 PM IST Sebastian Huber wrote:

>On 04/23/2012 11:19 AM, ali nasir wrote:
>> You are right. In idle state, just when i insert and mount the card, the usage
>> count is 1 for both the /dev/sdc0 and /dev/sdc01. Find the file
>> in_idle_state.JPG attached for the snapshot of the structure when the
>> rtems_disk_next (called via the do_bdls()) is just about to increase the usage
>> count. On the console we see it as 2 because of the increment in the
>> rtems_disk_next.
>
>Ok, this makes sense.
>
>> Find another snapshot attached (after_the_write_n_sync.JPG) which is taken
>> while exceuting the do_bdls, but this time after a couple of file operations
>> and calling the SYNCDEV ioctl. Here we see that the usage count of /dev/sdc01
>> is 2 just before the rtems_disk_next increments it.
>
>Here it seems that a transfer is in progress.  Once the transfer completes the usage count should decrease.  This is in function rtems_bdbuf_swapout_write().
>
>> Yes. We have a mitex in the low level driver of the card to prevent concurrent
>> read write access. You are talking of the low level driver. Right?
>
>Ok.
>
>> I still somehow feel that calling the ioctl for SYNCDEV when the swapout is
>> already busy writing data to the device causes this problem.
>
>The rtems_bdbuf_syncdev() looks like this:
>
>rtems_status_code
>rtems_bdbuf_syncdev (dev_t dev)
>{
>  rtems_status_code  sc = RTEMS_SUCCESSFUL;
>  rtems_disk_device *dd = NULL;
>
>  if (rtems_bdbuf_tracer)
>    printf ("bdbuf:syncdev: %08x\n", (unsigned) dev);
>
>  sc = rtems_bdbuf_obtain_disk (dev, 0, &dd, NULL, NULL);
>  if (sc != RTEMS_SUCCESSFUL)
>    return sc;
>
>  /*
>   * Take the sync lock before locking the cache. Once we have the sync lock we
>   * can lock the cache. If another thread has the sync lock it will cause this
>   * thread to block until it owns the sync lock then it can own the cache. The
>   * sync lock can only be obtained with the cache unlocked.
>   */
>  rtems_bdbuf_lock_sync ();
>  rtems_bdbuf_lock_cache ();
>
>  /*
>   * Set the cache to have a sync active for a specific device and let the swap
>   * out task know the id of the requester to wake when done.
>   *
>   * The swap out task will negate the sync active flag when no more buffers
>   * for the device are held on the "modified for sync" queues.
>   */
>  bdbuf_cache.sync_active    = true;
>  bdbuf_cache.sync_requester = rtems_task_self ();
>  bdbuf_cache.sync_device    = dev;
>
>  rtems_bdbuf_wake_swapper ();
>  rtems_bdbuf_unlock_cache ();
>  rtems_bdbuf_wait_for_event (RTEMS_BDBUF_TRANSFER_SYNC);
>  rtems_bdbuf_unlock_sync ();
>  rtems_bdbuf_release_disk (dd);
>
>  return RTEMS_SUCCESSFUL;
>}
>
>The sync operation is protected by the sync mutex.  All write transfers are done by the swapout task (rtems_bdbuf_wake_swapper() will only wake up the swapout task).
>
>-- 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 embedded-brains.de
>PGP     : Public key available on request.
>
>Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.