Problem with mounting a device second time.
gedare at rtems.org
Mon Apr 23 12:25:24 UTC 2012
On Mon, Apr 23, 2012 at 3:26 AM, Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> 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.
That UC values looks like an integer underflow.
>> 1. First the obtain is called from the ioctl. the uses increase from 3 to
>> 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
> 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.
> rtems-users mailing list
> rtems-users at rtems.org
More information about the users