Hi, I've written a linux kernel module for an USB device. The USB driver provides 2 read-only character devices, which can be opened only exclusively by one process: - `/dev/cdev_a` - `/dev/cdev_b` The USB device can only handle one request at a time. The test setup is a follows: - Processes A reads data from 1st device: `dd if=/dev/cdev_a of=/tmp/a bs=X` - Processes B reads data from 2nd device: `dd if=/dev/cdev_b of=/tmp/b bs=X` - Process A and B run in parallel - After 10 seconds both processes are killed and size of both output files is compared. For certain values of `X` there is a significant difference in size between the two files, which I don't expect. A read call to the driver does the following: 1. `mutex_lock_interruptible(iolock)` 2. `usb_bulk_msg(dev, pipe, buf, X, timeout)` 3. `mutex_unlock(iolock)` 4. `copy_to_user(buf)` What I would expect is the following: 1. Proc A: `mutex_lock_interruptible(iolock)` 2. Proc A: `usb_bulk_msg(dev, pipe, buf, X, timeout)` 3. Scheduling: A -> B 4. Proc B: `mutex_lock_interruptible(iolock)` -> blocks 5. Scheduling: B -> A 6. Proc A: `mutex_unlock(iolock)` 7. Proc A: `copy_to_user(buf)` 8. Proc A: `mutex_lock_interruptible(iolock)` -> blocks 9. Scheduling: A -> B 10. Proc B: `usb_bulk_msg(dev, pipe, buf, X, timeout)` But what I see with ftrace is that in step 8, process A still continues. And it seems that for certain values of X the time inside the critical region is a multiple of the time slice, so that process B always gets the time slice when the critical region is blocked. What would be a best practise solution for this? I was thinking of calling `schedule()` each time after copying to user space or playing with nice values or using wait_queues? -- Dipl.-Inf. Martin Christian Senior Berater Entwicklung Hardware secunet Security Networks AG Tel.: +49 201 5454-3612, Fax +49 201 5454-1323 E-Mail: martin.christian@xxxxxxxxxxx Ammonstraße 74, 01067 Dresden www.secunet.com
Attachment:
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@xxxxxxxxxxxxxxxxx https://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
