On 06-12-2011 13:28, Mark Lord wrote:
On 11-12-06 08:56 AM, Devin Heitmueller wrote:
On Tue, Dec 6, 2011 at 8:43 AM, Mauro Carvalho Chehab
<mche...@redhat.com> wrote:
The driver who binds everything is the bridge driver. In your case, it is
the au0828 driver.
What you're experiencing seems to be some race issue inside it, and not at
xc5000.
On a quick look on it, I'm noticing that there's no lock at
au0828_usb_probe().
Also, it uses a separate lock for analog and for digital:
mutex_init(&dev->mutex);
mutex_init(&dev->dvb.lock);
Probably, the right thing to do would be to use just one lock for both
rising
it at usb_probe, lowering it just before return 0. This will avoid any open
operations while the device is not fully initialized. Btw, newer udev's open
the analog part of the driver just after V4L register, in order to get the
device capabilities. This is known to cause race conditions, if the locking
schema is not working properly.
Just to be clear, we're now talking about a completely different race
condition that has nothing to do with the subject at hand, and this
discussion should probably be moved to a new thread.
If this discussion does change threads, could you folks please copy me
on it? I'm already subscribed to several other kernel mailing lists
in my roles as developer and maintainer of various bits, but I would
like to avoid having yet another daily deluge added to my inbox. :)
That said, I can test possible fixes for this stuff,
and am rather interested to see it resolved.
..
The notion that this is something that has been there for over a year
is something I only learned of in the last couple of days. All the
complaints I had seen thus far were from existing users who were
perfectly happy until they upgraded their kernel a couple of months
ago and then started seeing the problem.
..
It's always exhibited races for me here. I have long since worked around
the issue(s), so my own systems currently behave. But with the newer
HVR-950Q revision (B4F0), the issue is far more prevalent than before.
I may try Mauro's locking suggestion -- more detail or a patch would be useful.
You may take a look at the lock changes applied on em28xx driver for some
examples.
You basically need to block access to DVB while the device is handling a V4L
syscall
and vice-versa.
Changing the locking schema is not trivial, as it may generate dead locks. So,
careful testing is required. It also helps to compile a kernel with the dead
lock
detection logic enabled, as it may help you to discover if you did something
wrong.
Regards,
Mauro
Mauro?
--
To unsubscribe from this list: send the line "unsubscribe linux-media" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
