| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |
| Who | What | When |
|---|---|---|
| zenergi | Can anyone help me figure out why `v4l2-ctl --list-formats` doesn't result in an h264 video capture method with either the logitech 910 or logitech 930? | [01:56] |
| ................................................................................................... (idle for 8h10mn) | ||
| mchehab | hverkuil_: I fixed compilation breakages with Kernel < 4.6-rc1 with media_build.... it would be good if you can re-run your build script and see if all errors have gone | [10:06] |
| ......................... (idle for 2h4mn) | ||
| ali1234 | what does this mean: http://paste.ubuntu.com/15559064/
after the timeout the card no longer works correctly | [12:10] |
| VBI capture stops. i can still capture video though
this happens after a couple of days of continuous use although it seems to be a new problem because it never happened before i just read a mailing list post saying to clean out the PCI slots... is that really a real thing? this is the only PCI card i have, it hasn't been unplugged for years and always worked fine before | [12:24] | |
| ........... (idle for 54mn) | ||
| *** | UukGoblin has quit IRC (Read error: Connection reset by peer) | [13:19] |
| .... (idle for 16mn) | ||
| mchehab | pinchartl, sailus, hverkuil, javier__, shuah: do you have some time today for a quick discuss? | [13:35] |
| shuah | shuah yes | [13:36] |
| pinchartl | mchehab: I'm afraid I won't have time before ELC
and Sakari is currently offline until tonight I believe what do you want to discuss ? | [13:36] |
| mchehab | pinchartl: basically, it is about the mutex patch proposed by sailus... | [13:38] |
| pinchartl | then you have a peculiar definition of "quick" :-) | [13:38] |
| mchehab | it is needed on 4.6-rc to fix some troubles with snd-usb-audio and au0828, introduced by Shuah's patch series
the question is: with the fix patch (that sailus tested and already acked), it seems that it doesn't introduce any troubles | [13:39] |
| pinchartl | as I said, no time before ELC, sorry | [13:40] |
| mchehab | so, it looks safe to send upstream
but, if it is not safe, then we'll need to revert Shuah's patch adding media controller to snd-usb-audio driver | [13:40] |
| pinchartl | to be honest, given that the previous broken patches that got send upstream were considered safe too (or at least I hope they were), I'd be cautious about these ones | [13:42] |
| mchehab | so, we need to decide if we'll either push the fix or push a patch reverting shuah's patch | [13:42] |
| shuah | pinchartl, mchehab: reverting that one patch won't work | [13:43] |
| mchehab | shuah: why not? | [13:43] |
| shuah | You will still have issues when you unbind/bind au0828 | [13:43] |
| mchehab | the notifiy() callback is used only there | [13:43] |
| shuah | okay - are you including kref patch | [13:44] |
| mchehab | the MC is utterly broken for unbind/bind
we tested on 4.3 with uvcvideo | [13:44] |
| shuah | right it is broken at the moment with or without the snd_usb_audio patch | [13:44] |
| mchehab | with the fixup patches we have so far, just binding/unbinding snd-usb-video won't cause any harm...
that would prevent someone to blame the USB maintainers for some mess at our side s/USB/ALSA/ gah... s/snd-usb-video/snd-usb-audio/ mchehab needs caffeine and with the current patches, things are more reliable... OK, it will still fail with stress testing... | [13:46] |
| pinchartl | mchehab: without looking at the proposed patch, if you ask me, I'd revert the broken fixes that got merged and implement a new clean on
that will be much easier to review | [13:48] |
| shuah | This is the first time we have two drivers using the same media device - so we have uncovered issues in the media controller core as well as the new code during testing | [13:48] |
| pinchartl | s/clean on/clean one/ | [13:48] |
| shuah | pinchartl: that is what mchehab has now in his fixes topic branch - I tested | [13:49] |
| mchehab | pinchartl: the mutex issue was just because find_entity() was taking the mutex, and so media_ioctl logic... so the mutex was held twice
the fix was to just remove mutex_lock() from find_entity() | [13:49] |
| shuah | right we need that one for sure on top of what we have in fixes topic branch | [13:50] |
| mchehab | javier__, shuah, sailus and I did several tests, with covered tests with uvcvideo, snd-usb-audio, au0828 and omap3isp with such fix
and it solved the issue | [13:51] |
| pinchartl | shuah: full reverts + clean fixes on top ? | [13:51] |
| shuah | pinchartl: no I am not recommending reverts - I am saying apply fixes on top | [13:52] |
| mchehab | pinchartl: the issues were not directly introduced by shuah's patch...
her patch(es) only exposed it | [13:52] |
| shuah | the reason for that is we have tested with fixes on top extensively, but not revert | [13:52] |
| mchehab | the issue is basically due to the fact that there is a mess on MC with regards to memory barriers... due to the usage of both a spin lock and a mutex to protect the data at the media graph
due to that, removing part of the graph causes troubles replacing the spinlock with a mutex fix it | [13:53] |
| shuah | bind/unbind tests the add/remove of audio part of the graph and au0828 part of the graph | [13:54] |
| pinchartl | mchehab: we have a few broken patches (including the one that takes the graph lock twice). if you ask for my opinion, I'd like to revert all that and implement clean fixes on top of the revert
memory barriers ? I don't see how that's related | [13:58] |
| shuah | pinchartl: are you suggesting reverting the entire set of patches that went into 4.6-rc1 | [14:01] |
| mchehab | pinchartl: basically, all functions that use the MC structs should serialize the memory access, because, when one of the drivers is unbind, it will destroy the graph elements it creates
shuah: from your 22 patch series, 21 patches there are preparation ones... patch 22 is the one that used the infrastructure you created tests needed, but I don't see any reason to revert the previous 21 patches | [14:01] |
| shuah | mchehab: that is correct - I still would like to be sure that reverting fixes the problems.
right we do need to run our tests with just reverting that one patch if we decide to do that way | [14:03] |
| mchehab | shuah: reverting patch 22 won't solve MC troubles with unbind
because they are there since day zero, it seems but, at least, it won't introduce regressions | [14:03] |
| shuah | what we tested extensively is the fixes on top with whatever we have in 4.6-rc1 - that is what I am confident about | [14:04] |
| mchehab | yes, I believe so
they'll fix most of the MC issues the only question is if the change from spin_lock to mutex won't introduce other regressions this is the kind of patch that I wouldn't rush to push upstream but, without that, the notify() callback is broken there's one alternative: we could merge this one upstream: https://patchwork.linuxtv.org/patch/33468/ this would fix the notify() callback issues granted, it won't avoid race issues.... | [14:05] |
| pinchartl | mchehab: we know that that patch is broken | [14:08] |
| mchehab | true
but we know that MC locks are all broken specially when drivers are unbind so, I guess it won't make it any worse see, I'm not defending applying it... I'm just enumerating the alternatives we have: 1) revert snd-usb-audio patch (patch 22 of Shuah's series); 2) push the fixes we have for 4.6, including the spinlock->mutex; 3) push patch #33468 and other patches that don't touch at the functions on the MC core that were not introduced by Shuah's changeset technically, I guess (2) is the best alternative, but it is riskier because it might affect other drivers alternative (1) is the most complex one, IMHO, as we'll need to negociate with ALSA people for its removal on 4.6, and for a new addition on 4.7 | [14:08] |
| pinchartl | (1) is the cleanest one though | [14:15] |
| mchehab | pinchartl: yes... at least it will hide our dirty locks on our subsystem
I actually believe that (2) is the cleanest one but, as I said, it is riskier and I don't want to go for it if we're not confident that it would be ok btw, the patch that fixed the mutex issue is this one: https://patchwork.linuxtv.org/patch/33728/ pinchartl, hverkuil, javier__, shuah: could you please review if this patch (on the top of the current media upstream) would be ok for 4.6? because, if not, we'll need to either do (1) or (3) or make SND_USB_AUDIO_USE_MEDIA_CONTROLLER depend on broken - with is technically equivalent to (1) | [14:17] |
| koike | sailus, Hi, I'll update the docs of streamon as you said, should I send another separated patch changing the docs or can I change the docs in that same patch? | [14:28] |
| mchehab | sorry, got disconnected... what was the last msg I wrote?
koike: I believe sailus prefers docs change on a separate patch | [14:28] |
| koike | ok, thank you | [14:30] |
| mchehab | (according with pinchartl, sailus won't be available today) | [14:30] |
| koike | mchehab, the last message you wrote was: or make SND_USB_AUDIO_USE_MEDIA_CONTROLLER depend on broken - with is
mchehab, sorry, the last was: technically equivalent to (1) | [14:30] |
| mchehab | koike: thanks!
so, it got everything I wrote... i got disconnection messages a few seconds after that one ;) | [14:31] |
| shuah | mchehab: SND_USB_AUDIO_USE_MEDIA_CONTROLLER depend on broken isokay
if need be - but testing wise it has the same unknowns | [14:33] |
| mchehab | shuah: please prepare such patch and test it
this could be the best way of handling it | [14:35] |
| pinchartl | why would you depend on BROKEN instead of reverting the patch ? | [14:36] |
| shuah | pinchartl: here is the thing, as I explained reverting and broken both are unknown paths as I far as I can tell
pinchartl what is your recommendation mchehab sugested 3 choices maybe 4 with broken option | [14:37] |
| pinchartl | we have merged several patches too fast. my favourite option would be to revert them, implement a proper and clean fix, and then apply the rebased patches again. this is cleaner as the fixes won't be on top of half-broken code, and will thus be self-contained and easier to review | [14:40] |
| shuah | pinchartl: more specifically which ones | [14:41] |
| pinchartl | the spinlock to mutex conversion is one of them. I'd also revert the kref and implement it cleanly on top of your latest media device allocator series | [14:42] |
| mchehab | pinchartl: kref affects only patch 22
if this is reverted, no need to revert kref and kref is needed anyway at the media allocator series | [14:44] |
| shuah | pinchartl: kref is needed for multiple reasons, nut just for snd_usb_audio
mchehab, ^^ | [14:45] |
| mchehab | kref is the safest way to prevent freeing things too early | [14:45] |
| shuah | right | [14:46] |
| pinchartl | mchehab: I'd still revert it to implement it cleanly on top of a clean code base
patches have been rushed in. we can either revert them and implement clean solutions, or stash fixes on top the later is the strategy that led to the current mess, and I don't like it | [14:46] |
| mchehab | what lead the current mess is the usage of both spin lock and mutex to protect the same data
unfortunately, we can't revert the patch that introduced it it is too late for that so, we need to add fixups on the top of what we have | [14:47] |
| pinchartl | feel free to ignore my comments, but then don't expect my ack. and don't be suprise when I'll complain that the fix broke something else | [14:50] |
| mchehab | pinchartl: your comments are very welcomed
I told you that several times basically, what we need to do is 2 things: 1) address the broken things on 4.6; (that could be reverting patches there and/or making things depend on broken - whatever works best) 2) be sure that the patches we add on the development tree won't break anything else for now, we should address (1), as | [14:50] |
| pinchartl | it's much more difficult to validate a patch by code review when it's applied on top of a broken base | [14:53] |
| mchehab | ALSA maintainers agreed to merge what it is needed to fix the mess for -rc2 | [14:53] |
| pinchartl | so my recommendation is to revert the spinlock to mutex conversion and the kref, and reimplement them with a proper solution | [14:53] |
| shuah | pinchartl: I have the rfc patches out that fix the problem, but they won't be ready unless we all review
I am working on v2 based on mchehab comments this patch series addresses the existing problems with media ioctls pinchartl: sounds like what you are saying is revert the spinlock to mutex conversion and the kref, leave 4.6-rc1 broken for bind/unbind and get the real solution in when ready | [14:55] |
| pinchartl | shuah: yes. bind/unbind was already broken before 4.6, I don't think we should rush to fix it at all cost before the fix is ready | [15:04] |
| shuah | pinchartl: right bind/unbind is broken already
mchehab: is that okay with you ? | [15:05] |
| mchehab | shuah, pinchartl: those patches weren't sent to 4.6-rc1
as far as I remember, trying to remove either snd-usb-audio or au0828 on 4.6-rc1, causes the Kernel to crash (and so unbinding) even not opening /dev/media | [15:06] |
| shuah | mchehab, pinchartl: yes there are no reverts involved - send the fixes we have for snd_us_audio and au0828 (dev_state)
that's what I am hearing pinchartl recommend - leave out kref and spinlock from the 4.6-rc2 patches | [15:08] |
| mchehab | so, basically, sending the fixes from https://git.linuxtv.org/media_tree.git/log/?h=fixes | [15:09] |
| shuah | right | [15:09] |
| mchehab | would be enough
knowing, in advance that unbind/bind both drivers will cause troubles hmm.... could be shuah: could you please test it and pastebin what happens when either one of the drivers get bind/unbind? and what happens when both gets unbind/bind? | [15:09] |
| shuah | I can tell you what happens when I run unbind on au0828
I wil do a patsebin as well | [15:11] |
| mchehab | ok, please pastebin it | [15:12] |
| shuah | okay
in a few minutes - I have wrong kernel booted | [15:12] |
| mchehab, pinchartl : http://pastebin.com/TLMebNMX
I did unbind au0828 and then bind au0828 | [15:20] | |
| mchehab | what's the status of au0828 after rebinding it? is it working?
what media-ctl and mc-nextgen-test presents? those use-after-free really bothers mes s/mes/me/ this is a regression on au0828 driver I don't think it is acceptable | [15:21] |
| shuah | mchehab: unbind works just fine
bind fails with what we see | [15:25] |
| mchehab | shuah: depending on how qemu is configured, it may unbind/rebind the device | [15:26] |
| shuah | I understand
So here is what I see - media_device_register_entity() this would happen as au0828 creates its graph | [15:26] |
| mchehab | this will cause troubles for the users, even for the ones not using the media controller | [15:27] |
| shuah | [ 284.488666] Call Trace:
[ 284.488675] [<ffffffff81ae9103>] dump_stack+0x67/0x94 [ 284.488681] [<ffffffff8152e632>] print_trailer+0x112/0x1a0 [ 284.488687] [<ffffffff81534354>] object_err+0x34/0x40 [ 284.488693] [<ffffffff815366f1>] kasan_report_error+0x221/0x530 [ 284.488700] [<ffffffff81536df9>] kasan_report+0x39/0x40 [ 284.488706] [<ffffffff81535f1a>] ? memset+0x1a/0x30 [ 284.488712] [<ffffffff81535b8d>] __asan_storeN+0x12d/0x180 [ 284.488717] [<ffffffff81535f1a>] memset+0x1a/0x30 [ 284.488723] [<ffffffff81aed1f1>] ida_get_new_above+0x1e1/0x430 Looks like ida_get_new_above() runs into trouble | [15:27] |
| mchehab | the kref patch very likely fix this issue | [15:27] |
| shuah | So did au0828 unibind/bind work on Linux 4.5 | [15:27] |
| mchehab | so, I guess we need at least to apply the kref one | [15:28] |
| shuah | btw unbind will also remove /dev/media1 without the kref patch
yes we do need kref patch | [15:28] |
| mchehab | could you please apply it and see what happens? | [15:28] |
| *** | benjiG has left | [15:29] |
| mchehab | the kref patch touches only on the functions used by au0828/snd-usb-audio, so it won't cause regressions on other drivers | [15:29] |
| shuah | I will apply it on top of fixes and let you know what happens | [15:29] |
| mchehab | ok, thanks
from my side, the hipotesis of just sending what's there on fixes should be discarded, as we'll still have regressions due to patch 22 I suspect that just the kref fix patch won't solve bind/unbind, because the notify() callback will be called with the spin lock hold If I'm right, we'll either need https://patchwork.linuxtv.org/patch/33468/ or spin lock->mutex convert patch, if we decide to keep patch 22 applied but I don't recall the exact scenario where we detected the troubles with the notify callback hmm... according with the testcase described at https://patchwork.linuxtv.org/patch/33467/: Tested with an HVR-950Q, under the following testcases: 1) load au0828 driver first, and then snd-usb-audio; 2) load snd-usb-audio driver first, and then au0828; 3) loading both drivers, and then connecting the device. I suspect that the issue happens when both snd-usb-audio and au0828 are modules (with is the usual case) and seems to be independent on the kref patch shuah: to get the above, you need to enable CONFIG_TRACING | [15:29] |
| shuah | okay - kref patch doesn't apply on top of fixes | [15:42] |
| mchehab | as the might_sleep message is produced by kmem_cache_alloc_trace()
#ifdef CONFIG_TRACING void * kmem_cache_alloc_trace(struct kmem_cache *cachep, gfp_t flags, size_t size) { shuah: isn't easy to rebase it to apply on fixes? | [15:42] |
| shuah | not sure I will check
I have CONFIG_TRACING=y - enabled | [15:43] |
| mchehab | it seems just context changes, due to the mutex patch | [15:44] |
| shuah | mchehab: do I need https://git.linuxtv.org/mchehab/experimental.git/commit/?h=au0828-unbind-fixes&id=9e9d02b386a3d2fe64d8bf85f64cb8a2ebc9fddc | [15:45] |
| mchehab | sounds ok too, as this one doesn't affect other drivers
but I guess the above is for the stress test fixup if we're assuming that Kernel OOPS at bind/unbind while MC is being used is OK, this won't be needed | [15:46] |
| shuah | okay rebase isn't that easy - rejects on both drivers/media/media-device.c and drivers/media/usb/au0828/au0828-core.c
in the meantime, I am building Linux 4.5 to see what unbind/bind on au0828 does | [15:49] |
| mchehab | shuah: rebase is easy
two trivial conflicts to be solved | [15:50] |
| shuah | okay | [15:50] |
| mchehab | just context changes
To ssh://linuxtv.org/git/mchehab/experimental.git * [new branch] devel/au0828-v4.6-fixes -> au0828-v4.6-fixes | [15:50] |
| shuah | okay did you try it - good - you are the author | [15:50] |
| mchehab | I fixed for you ;) | [15:50] |
| shuah | no don't mean it that way - I am saying it is easier for you see if rebase went well or not :)
thanks devel/au0828-v4.6-fixes have all the patches in fixes ? | [15:51] |
| mchehab | bbiab... lunch
it should... it is just fix branch + cherry pick kref | [15:53] |
| shuah | okay thanks | [15:54] |
| okay building now - will let you know how it goes | [16:03] | |
| .... (idle for 18mn) | ||
| mchehab | shuah: I'm looking at the result of kref patch... it may not be 100% correct...
--- a/drivers/media/usb/au0828/au0828-core.c +++ b/drivers/media/usb/au0828/au0828-core.c @@ -146,6 +146,9 @@ static void au0828_unregister_media_device(struct au0828_dev *dev) media_device_cleanup(dev->media_dev); dev->media_dev = NULL; } + + media_device_unregister_devres(dev->media_dev); + dev->media_dev = NULL; #endif } I guess it should not be calling media_device_cleanup() there yes, I solved one conflict wrong To ssh://linuxtv.org/git/mchehab/experimental.git 97a62e26d073..d7c87d7b3320 devel/au0828-v4.6-fixes -> au0828-v4.6-fixes I stored the change in a separate patch, just to make easier for you commit d7c87d7b332042d9f0315a6da1998b98d23fac78 - media_device_unregister(dev->media_dev); - media_device_cleanup(dev->media_dev); + media_device_unregister_devres(dev->media_dev); dev->media_dev = NULL; } - media_device_unregister_devres(dev->media_dev); | [16:21] |
| if you prefer a cleaner patch with that folded, you could use au0828-v4.6-fixes-v2 branch | [16:29] | |
| shuah | okay will switch to that | [16:32] |
| mchehab | I compared the rebased patch with the previous one, and it now looks identical, except for the context changes
but didn't tested, nor tried to build it also, as it uses a mutex for unregister, it probably won't work fine if /dev/media0 is opened... but this is the known bug that can be solved only with spin lock->mutex conversion so, if we decide to keep patch 22 and add this patch, it may make sense to change the mutex_lock by spin_lock() at do_media_device_unregister_devres() logic to at least improve a little bit the protection but, on the scenario where there's no concurrent processes accessing the media data, I suspect it should behave just fine | [16:35] |
| ........... (idle for 54mn) | ||
| *** | awalls1 has left | [17:33] |
| prabhakarlad has left | [17:40] | |
| larsc | hverkuil: you said you arrive on friday? | [17:42] |
| .................... (idle for 1h39mn) | ||
| mchehab | shuah: did it work? | [19:21] |
| shuah | Getting close - this compile is taking way too long on my system
mchehab: I am going to test this and them I will bisect Linux 4.6-rc1 to isolate the patch. I am not convinced that reverting patch 22 will solve the au0828 unbind/bind issue Maybe that is the case, but I want to be sure | [19:22] |
| mchehab | shuah: the problems with au0828 rmmod started after applying your 22 patch series
I'm almost sure that the guilty one was patch 22 but, of course, it doesn't hurt to double check | [19:26] |
| shuah | okay - I am going to limit the bisect from your pull commit in 4.6-rc1 to the prior one, so it will be faster and we include all the patches the pull request. | [19:28] |
| ........ (idle for 35mn) | ||
| mchehab: with kref patch /dev/media sticks around, but I am seeing use-after-free
patsebin coming up http://pastebin.com/UwvZjFAg | [20:03] | |
| ..... (idle for 21mn) | ||
| mchehab: don't we need this one - https://git.linuxtv.org/mchehab/experimental.git/commit/?h=au0828-unbind-fixes&id=26f2b92c7228d730c146e8a54f1219ffe419e390
au0828: Unregister notifiers | [20:26] | |
| mchehab | shuah: true, this is also needed | [20:28] |
| shuah | Without that we could see problems | [20:28] |
| mchehab | yeah, the pastebin messages you posted show that | [20:28] |
| shuah | right | [20:28] |
| mchehab | just porting it should fix this issue | [20:28] |
| shuah | yes - we definitely debugged this one before :) | [20:29] |
| mchehab | yes
as I said, if we apply patch 22, a bunch of patches are needed I suspect that this is the last one (again, assuming that it is ok if unbind/bind causes OOPS due to known MC bad memory protections) | [20:29] |
| shuah | right
yes - it will be hard to fix that problem without the work I am doing now with media dev allocator are you planning to push that one for me to test? au0828: Unregister notifiers i.e | [20:31] |
| mchehab | shuah: as I said, we need to solve the regressions for 4.6
and ALSA maintainer asked to send the pull request in time for -rc2 as he needs to pull back the changes made at snd-usb-audio it means that tomorrow is the last day to have the regressions fixed as they need to go to -next before upstream | [20:38] |
| shuah | okay - what is the plan of action - do you want to add au0828: Unregister notifiers to the fixes branch I am testing now
or ?? | [20:41] |
| mchehab | did the rebase for you
just checking it it builds | [20:43] |
| shuah | okay thanks | [20:43] |
| mchehab | I pushed the patch on the same branch
(still building it here) To ssh://linuxtv.org/git/mchehab/experimental.git d32b687160d7..ba68c32aee90 devel/au0828-v4.6-fixes-v2 -> au0828-v4.6-fixes-v2 | [20:44] |
| shuah | getting the change now
mchehab: we have to verify revret of patch 22 fixes the problem or not - something we need to do in parallel ? | [20:46] |
| mchehab | shuah: if the changeset with those fixes are comfortable for everyone, I guess the best is to send them...
specially as they don't affect other drivers (as it doesn't touch at the spin_lock) | [20:49] |
| shuah | right - I am compiling it now - let you know soon | [20:50] |
| ..... (idle for 24mn) | ||
| mchehab: success - ubind/bind on au0828 worked with the last patch | [21:14] | |
| mchehab | good
did you try to unbind/bind snd-usb-audio? | [21:15] |
| shuah | I am going do pastebin for you
I will try that now http://pastebin.com/GU0yXScD | [21:15] |
| mchehab | FYI, I just ran the same tests unbinding/binding au0828 and unbinding snd-usb-audio a few times (without any other process touching at /dev/media), and it worked, fine, but here sometimes I get this warning: http://pastebin.com/nXLfWRgT
this is my .config: http://pastebin.com/ipgXNsS4 | [21:16] |
| shuah | mchehab: I see au0828_media_graph_notify() - this is the spinlock issue in the notifier path
I did unbind/bind on snd_usb_audio and no issues snd_usb_audio is trying create links as they all go away during unbind | [21:18] |
| mchehab | a new bug?
or just the one that could be fixed with spin lock -> mutex or https://patchwork.linuxtv.org/patch/33468/ ? | [21:24] |
| shuah | no it is not - it is the same one the above fixes
media-device: Don't call notify callbacks holding a spinlock | [21:25] |
| mchehab | ok. So, as I said in the morning, there are 3 alternatives: | [21:25] |
| shuah | This is what's happening in this warnings | [21:25] |
| mchehab | (actually 4)
- revert patch adding MC support to snd-usb-audio; - make media support on snd-usb-audio depend on broken; - apply the fixes with patch #33468 - apply the fixes with spin lock -> mutex conversion one of the above alternatives is needed to avoid the regression introduced by the the patch that added MC support to snd-usb-audio. | [21:26] |
| shuah | is apply the fixes with patch #33468 not an option? | [21:28] |
| mchehab | it is
(option 3 on the above) | [21:28] |
| shuah | I am loosing track on objections to apply the fixes with patch #33468 vs. apply the fixes with spin lock -> mutex conversion
Why not take that then I have to step out for a bit - I can verify apply the fixes with patch #33468 option if you push that patch - at the very least we know what it takes ti fix the regression | [21:29] |
| .... (idle for 16mn) | ||
| zamba | hi guys! i just received a usb capture card that i believe is using the empia em2860 chipset (it's identified as eb1a:2861)..
the sticker on the device itself is "DC90" i have gotten video using mplayer and the following command: mplayer tv:// -tv device=/dev/video1:driver=v4l2:input=0:norm=NTSC but i had to modprobe using the option "card=35" | [21:46] |
| mchehab | shuah: yeah, please do the tests you need to better position yourself
I'm preparing an email with a summary of those things for us to discuss | [22:01] |
| .................. (idle for 1h26mn) | ||
| shuah | mchehab:I am back now
mchehab: do you want me to run any final tests with patch #33468? | [23:27] |
| mchehab | yeah, that would be ok | [23:29] |
| shuah | This option is limits the fixes scope to just the au0828 and snd_usb_audio and hence less risky | [23:30] |
| mchehab | it would be nice to also revert patch 22 (or, actually, disable the media stuff there, as reverting it would be too complex, as there are lots of patches after it) | [23:30] |
| shuah | do you want to push the change the branch I am testing? | [23:30] |
| mchehab | ? | [23:30] |
| shuah | okay - tell you what - give me a topic branch to test with just patch 22 revert, and push the patch #33468 to devel/au0828-v4.6-fixes-v2
I will run the same tests on both and send results to the email thread you started This way we are very sure where we stand My concern is if we need some of these fixes even with patch 22 reverted, we should know that now especially the au0828 patches | [23:31] |
| ↑back Search ←Prev date Next date→ Show only urls | (Click on time to select a line by its url) |