<!-- Some styling for better description lists --><style type='text/css'>dt { font-weight: bold;float: left;display:inline;margin-right: 1em} dd { display:block; margin-left: 2em}</style>

   mchehab: moikka!
   hverkuil: <u>sailus</u>: wow, documentation! :-)
   <br> <u>sailus</u>: BTW, I've picked up the cec.rstpatch
   sailus: <u>hverkuil</u>: Thank you!
   <br> I thought of documenting things because we're lacking it in a few places. I'll have a few more patches of the same.
   <br> <u>mchehab</u>: How do you do?
   mchehab: fine. and you?
   sailus: Fine, too, thanks!
   <br> I had a look on the DVB drivers and it seems at least some of the DVB interfaces suffer from similar issues than MC.
   <br> Specifically, releasing the memory of the device node is not serialised with IOCTL calls that access that memory.
   <br> I don't remember struct names right now, it's been a while since I read the code.
   <br> I was wondering whether to leave it as such for now.
   <br> It could possibly be fixed later on.
   mchehab: I don't remember the specifics from the DVB code, but I guess it uses cdev right, so it should be ok
   <br> I don't remember any issue at race issue the DVB side with fast plugging/unplugging devices (and I didn't get any of those on my fast bind/unbind loop with au0828 driver)...
   <br> except with regards to the frontend kthread, with is a bit sensible
   <br> and whose code had to be modified a few times to avoid race issues
   <br> there is still a patch pending to merge changing something there for a while...
   <br> but to be frank, I'm not too comfortable of merging it, as it could cause more harm than good
   <br> so, I keep postponing merging it until either me or someone else with experience would find some time to do a comprehensive test
   <br> the logic there properly handle disconnects when the USB driver notifies the core about it (this is a patch that shuah added to fix a race condition she found with her au0828 hardware)
   <br> <u>sailus</u>: ^
   __raven__: hi
   <br> after trying to install a dvb-s2 device my logitech webcam does not work any more. /dev/video0 not existent and modprobe "ERROR: could not insert 'uvcvideo': Invalid argument
   <br> what could be the issue? i tried to remove the changes and reinstalled uvc and v4l components but no change
   mchehab: what device? how did you install it?
   __raven__: lsusb sais " ID 046d:08ce Logitech, Inc. QuickCam Pro 5000"
   <br> i did not really install it. it just worked using v4l until i tried to install the dvb-s2 device
   sailus: <u>mchehab</u>: Ack.
   <br> The time window during which bad things can happen isn't large so it's difficult to hit it.
   <br> Nevertheless, I'll see how to best proceed with the current set, ensuring the serialisation issues are not made worse on DVB.
   mchehab: <u>sailus</u>: I ran ~10K continuous bind/unbind loops, while 4 other processes were running ioctls on the device, on a 4CPU machine... that's confident enough that a random user on a normal app won't have pains ;)
   <br> (in practice)
   <br> Ok, there are always space for improvements
   <br> but the probability of a race condition there seems low
   <br> I do have a compliant about one guy whose device driver is continually binding/unbinding, causing duplicate sysfs filenames
   <br> with is indeed a race condition
   <br> in his specific case, I suspect that the problem is due to a hardware error, as he's getting error -71
   <br> (with is a timeout error at the USB message send/receive)
   <br> not sure if the duplicated sysfs names is caused by a problem at the DVB driver or at the USB core
   <br> anyway, the error is not due to ioctl's being hit at the wrong moment...
   __raven__: mchehab?
   mchehab: but, instead, because the sysfs cdev is dropped too late
   <br> <u>__raven__</u>: I meant: how did you install the dvb driver?
   __raven__: <u>mchehab</u>: ii just installed xawtv, dvb-apps, dvbtune- dvb-tools and dvbv5-*
   mchehab: I guess the DVB driver - or core - is  de-reserved the adapter number too early, e. g. before the sysfs cdev struct device kref is dropped
   <br> <u>__raven__</u>: none of those should affect the webcam
   hverkuil: <u>mchehab</u>: have you seen this patch: "[PATCH v3 11/16] media: utilize new cdev_device_add helper function"
   <br> Even though linux-media was included, this series never made it to our mailinglist for some reason, but it should be in your personal mailbox.
   mchehab: I saw this series
   larsc: the sysfs file should be removed in the driver unregister() callback. If they are instead removed in the device release callback (or any other release callback) there is a race
   hverkuil: I acked it, looked good to me. But you should probably review it as well.
   __raven__: <u>mchehab</u>: what could i try to get the cam back?
   mchehab: <u>hverkuil</u>: the patch itself looks ok. didn't check the implementation, as I was not c/c on patch 01/16
   <br> <u>larsc</u>: I'm almost sure that the cdev's /bus/class sysfs file is created internally at the cdev's code
   <br> freeing it outside it seems wrong
   <br> <u>__raven__</u>: the ERROR: could not insert 'uvcvideo': Invalid argument
   <br> indicates an error when loading a Kernel module
   <br> installing userspace tools like xawtv, dvb-apps, dvbtune- dvb-tools and dvbv5-* wouldn't cause it
   __raven__: i did not change any kernelspace things. do you know where the module is included in?
   mchehab: you either: installed some Kernel modules, changed something at your /etc/modprobe.d/* or installed some proprietary software that damaged it
   __raven__: i didnt
   mchehab: dmesg may provide you more information about the error
   __raven__: that i am wondering about
   mchehab: if you didn't, then you got hacked ;-)
   larsc: <u>mchehab</u>: ok. Same comment applies to cdev_del() which will remove the sysfs files
   mchehab: (more likely that you did, by accident)
   __raven__: <u>mchehab</u>: it does but i do not know what to read out of it: http://pastebin.com/UaXVHkws
   mchehab: [    9.434970] uvcvideo: disagrees about version of symbol vb2_queue_release
   <br> you installed a new driver
   <br> with conflicts with an existing one
   <br> try reinstalling your Kernel
   <br> that should fix the issue
   __raven__: http://www.linuxforen.de/forums/showthread.php?274740-v4l-(dvb-s)-und-uvcvideo-(webcam) ?
   mchehab: no, I mean something like: apt-get install --reinstall kernel
   <br> or dnf reinstall kernel
   <br> (no idea what distro you use - but most distros have something similar to it)
   __raven__: and i am talking about a possible reason or how to avoid this to go on ;)
   -: mchehab doesn't read Deutsch
   __raven__: just reinstalled. brb...
   mchehab: but from the pictures, it seems to be in the right direction ;)
   <br> hard to tell, though
   __raven__: no still same issue
   mchehab: then you have duplicated drivers
   <br> you'll need to find and remove them
   <br> some distros (Ubuntu, Debian) uses a non-standard directory for drivers
   <br> I guess it is usually called extra/ (or something like that)
   <br> you could do something like:
   __raven__: its a debian
   mchehab: (dangerous)
   <br> # rm -rf /lib/modules/$(uname -r)
   <br> and reinstall the Kernel
   <br> but be careful that this will remove all drivers - if you boot the machine without reinstalling the Kernel, you may lose network
   <br> and other drivers
   <br> perhaps, you could do, instead:
   <br> # mv /lib/modules/$(uname -r) /lib/modules/$(uname -r).old
   <br> #apt-get install --reinstall kernel
   <br> this way, if something gets wrong, you'll still have your drivers at /lib/modules/$(uname -r).old
   <br> so you can rename it again
   <br> on Fedora, the two non-standard dirs are "extra" and "updates" - not sure about Debian
   __raven__: ok i will try that when i am back home. tnx so far :)
   mchehab: anytime
   __raven__: hey
   <br> cam works again - kernel reinstall...but a previous one
   ***: javier__ has quit IRC (Quit: leaving)