[00:18] *** DaRock has quit IRC (Quit: DaRock)
[01:08] *** crazy_imp has quit IRC (Ping timeout: 276 seconds)
[01:21] *** _franck__ has quit IRC (Ping timeout: 250 seconds)
[12:21] <pinchartl> posciak: ping
[12:25] <hverkuil> haven't been able to get hold of posciak for some time now :-(
[12:26] <pinchartl> :-/
[12:28] <pinchartl> I know that Pawel was still alive two weeks ago
[12:28] <pinchartl> hopefully that hasn't changed :-)
[12:47] <hverkuil> neg: ping
[12:58] <hverkuil> neg: mailed you instead
[13:03] <neg> hverkuil: pong
[13:03] <hverkuil> neg: see email
[13:04] <hverkuil> isn't it time to continue the metadata discussion? Or am I off by an hour?
[13:06] <neg> hverkuil: thanks got it, I'm writing up the commit msg right now. Final test and the patch should be out within the hour. Thanks for ping :-)
[13:15] <pinchartl> hverkuil: it can be
[14:07] <hverkuil> Hmm, no meeting at all?
[14:08] <mchehab> hverkuil, pinchartl: sorry, I won't be able to do it today
[14:08] <pinchartl> mchehab: ok
[14:08] <pinchartl> I'll be flying tomorrow so I won't be available
[14:08] <pinchartl> and visiting a customer on Thursday-Friday, so won't be available either
[14:08] <mchehab> ok. when you'll be available?
[14:09] <pinchartl> and will take the week off (with e-mail access in the evening) next week
[14:09] <pinchartl> I'll come back on the 7th of May
[14:09] <pinchartl> (or possibly earlier if the weather is really bad)
[14:10] <hverkuil> I'm traveling myself around that time and will be gone May 5-9.
[14:12] <mchehab> So, May, 10 seems to be the first available date
[14:12] <mchehab> I may need to travel on May, but the travel is not scheduled yet...
[14:13] <mchehab> so, we may try to reserve the date, subject to changes
[14:13] <pinchartl> I'll try to post a new patch series soon, we can discuss it over e-mail up to either an agreement or a lack of disagreement that would require IRC :-)
[14:13] <mchehab> OK
[14:14] <mchehab> I'd suggest you to write a RFC with the approach you want to take before the actual patches, as this helps ;)
[14:15] <pinchartl> well, the patches are already written, there's only minor changes left, so I can as well post the code too
[14:15] <pinchartl> it helps understanding the RFC :-)
[16:32] *** benjiG has left 
[17:16] *** awalls1 has left 
[17:33] *** koike_ is now known as koike
[17:55] <shuah> mchehab: okay I have a fix for you for the media_ioctl use-after-free problem with driver unbind case, tested it with 3 drivers (uvcvideo, em28xx, and au0828)
[17:56] <shuah> Changes are limited and should backport easily
[18:10] <mchehab> good
[18:33] <shuah> mchehab: there is a DEBUG_LOCKS_WARN_ON(chain_hlocks[chain->base + j] != id) error I am seeing when I remove em28xx usb device I have
[18:33] <shuah> This is on 4.6-rc5
[18:34] <shuah> This is a new check that went into 4.6-rc1 I think
[18:35] <mchehab> interesting. what does that mean?
[18:44] <shuah> potential lock collision - I haven't looked into it to understand more than that :)
[18:45] <shuah> PU: 2 PID: 1853 at kernel/locking/lockdep.c:2098 __lock_acquire+0x2f15/0x5f30
[18:45] <shuah> [  627.715866] DEBUG_LOCKS_WARN_ON(chain_hlocks[chain->base + j] != id)
[18:46] <shuah> http://pastebin.com/7eXpgDdG
[18:48] <mchehab> we had some false-positive lock warnings in the past
[18:48] <mchehab> not sure if this is the case of this one
[18:49] <mchehab> looking at the logs, it could be the case
[18:49] <mchehab> [  628.057660]  class_idx:43 ->  chain_key:000000000000002b (timekeeper_lock){-.-...}, at:  [<ffffffff81290d62>] update_wall_time+0x72/0x910
[18:49] <mchehab> [  628.066459]  class_idx:183 -> chain_key:00000000000000b7 (&dev->mutex){......}
[18:50] <mchehab> I've no idea about that timekeeper locks
[18:50] <mchehab> but we don't hold/release at em28xx
[18:52] <mchehab> on a very quick view, it seems a false positive
[19:10] <shuah> okay