Problem with mounting a device second time.

[Sebastian Huber]

On 04/23/2012 06:34 AM, ali nasir wrote:
> I tried to debug further. I see the following when i put breakpoints in the rtems_disk_obtain and the rtems_disk_release. I enable these breakpoints when the control is in the rtems_blkdev_generic_ioctl, just before the call to rtems_bdbuf_syncdev.
> In idle state (no file operations), the dd->uses equals 2.

ffffffff:ffffffff P /dev/rda UC=4294967293 BB=0 BC=4000 BS=512 MBS=512
00000001:00000000 P /dev/nvda UC=4294967293 BB=0 BC=637 BS=512 MBS=512
00000004:00000000 P /dev/fdda UC=1 BB=0 BC=1504 BS=512 MBS=512
00000005:00000000 P /dev/sdc0 UC=2 BB=0 BC=3862528 BS=512 MBS=512
00000007:00000000 L /dev/sdc01 UC=2 BB=135 BC=3858489 BS=512 MBS=512

Is this the usage count of "/dev/sdc01"?  I think 2 might be wrong here.  The 
usage count of "/dev/sdc0" is 2 since "/dev/sdc01" is also a user of its 
physical disk and in addition to the 1 for a non-deleted disk.  But the logical 
disk "/dev/sdc01" should have a usage count of 1 in the idle state.  Also the 
UC=4294967293 is a bit weird.

> 1. First the obtain is called from the ioctl. the uses increase from 3 to 4.
> 2. Then the release is called from swapout task. The uses now decrease from 4 to 3.
> 3. Swapout task calls the obtain. The uses now increase from 3 to 4.
> 4. Swapout task calls release. uses now decrease from 4 to 3.
> 5. ioctl call the release. Swapout decreases from 3 to 2.
>
> After this if i call the bdls, then the uses show 3. But there is no call to the obtain after step 5 above.

The rtems_disk_next() will also increase the usage count by one (it uses the 
disk_lock() internal function).

>
> I also notice, that when i call the ioctl, the swapout task is still writing data to the card. Is is that calling the SYNCDEV ioctl while the swapout taks is also working on the same device causes some problems. This because i do not face any problem when the bdbuf_syncdev is called during the unmount sequence.

The SYNCDEV will trigger the swapout task since this task performs all write 
operations.  Has your driver a mutex to prevent concurrent read/write operations?


-- 
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.