From: Shuah Khan <shuahkh@osg.samsung.com>
To: Mauro Carvalho Chehab <mchehab@osg.samsung.com>
Cc: Javier Martinez Canillas <javier@osg.samsung.com>,
Linux Media Mailing List <linux-media@vger.kernel.org>,
Shuah Khan <shuahkh@osg.samsung.com>
Subject: Re: Slow path and cpu lock warnings - MC Next Gen
Date: Wed, 11 Nov 2015 20:25:47 -0700 [thread overview]
Message-ID: <564406BB.8020308@osg.samsung.com> (raw)
In-Reply-To: <5643DC88.10300@osg.samsung.com>
On 11/11/2015 05:25 PM, Shuah Khan wrote:
> On 11/11/2015 08:49 AM, Shuah Khan wrote:
>> On 11/11/2015 08:36 AM, Mauro Carvalho Chehab wrote:
>>> Em Wed, 11 Nov 2015 07:22:47 -0700
>>> Shuah Khan <shuahkh@osg.samsung.com> escreveu:
>>>
>>>> On 11/11/2015 05:30 AM, Mauro Carvalho Chehab wrote:
>>>>> Em Mon, 09 Nov 2015 08:55:06 -0700
>>>>> Shuah Khan <shuahkh@osg.samsung.com> escreveu:
>>>>>
>>>>>> On 11/09/2015 08:51 AM, Shuah Khan wrote:
>>>>>>> As I mentioned on the IRC, here is the log for the problems I am seeing.
>>>>>>> I have to do eject HVR 950Q TV stick to see the problem.
>>>>>>>
>>>>>>> mc_next_gen.v8.4 branch with no changes.
>>>>>>>
>>>>>>> I can test and debug this week.
>>>>>>>
>>>>>>> thanks,
>>>>>>> -- Shuah
>>>>>>>
>>>>>>
>>>>>> Forgot to cc linux-media, just in case others are interested
>>>>>> and have ideas on debugging.
>>>>>>
>
> snip
>
>>>>>
>>>>> Sorry, but I fail to see how this is related to the V4L2 subsystem.
>>>>>
>>>>> At least on my eyes, it seems that the bug is somewhere at the Radeon
>>>>> driver.
>>>>>
>>>>
>>>> Mauro,
>>>>
>>>> I think you didn't look down the dmesg far enough. The following is the
>>>> problem I am talking about and you will see media_device_unregister()
>>>> on the stack. This occurs as soon as the device is removed.
>>>
>>> Shuah,
>>>
>>> I saw that, but it is clear, from the above log, that the Radeon
>>> driver is broken and it has some bad lock dependencies with the
>>> driver_attach locks. Any other bad lock report related to the
>>> Radeon driver or driver binding/unbiding code are very likely
>>> related to the above bug.
>>>
>>> You should either fix the bad lock at the Radeon driver or not
>>> load it at all, in order to be able to get any reliable results
>>> about possible locking troubles with the MC drivers with the Kernel
>>> lock tests.
>>>
>>
>> Yeah Radeon driver bug could be making things worse. Did you see
>> any problems with device removal during your testing?
>>
>> ok found the following commit that fixes the problem:
>> 7231ed1a813e0a9d249bbbe58e66ca058aee83e1
>>
>> This went into 4.2-rc4 or rc5. I will test applying just this
>> one patch to mc_next_gen.v8.4 branch and see if device removal
>> problem also goes away.
>>
>
> Applied the acpi backlight fix and now kernel hangs solid when
> device is removed. I managed to get stack trace enabling sysrq
> and that showed media_device_unregister_entity() attempt to hold
> spin_lock() -> raw_spin_lock() on the stack trace. It is same as
> the one seen in the dmesg I sent.
>
> I think we have several calls to media_device_unregister_entity()
> from various media core drivers (dvb, v4l2, bridge driver) during
> device removal from their unregister paths. This adds lot of
> contention on the mdev->lock.
>
> media_device_unregister() calls media_device_unregister_entity()
> as well on all the mdev entities.
>
> I am not testing with my ALSA patches at the moment. When that
> gets added, media_devnode_is_registered() check to ensure only
> one of them (bridge driver or snd-usb-audio) runs
> media_device_unregister() won't work as the MEDIA_FLAG_REGISTERED
> flag gets cleared towards the end of media_device_unregister().
> media_device_unregister() needs to be safe to be run by these two
> drivers and still do the work only once. media_device_unregister()
> does a lot (removes interface links, interfaces, and then then
> unregister entities before it removes the media device devnode
> file and call media_devnode_unregister() to clear the
> MEDIA_FLAG_REGISTERED bit.
>
> I see two problems to solve:
>
> - ensure media_device_unregister() is safe to be called by one
> or more drivers during device removal (usb disconnect in this
> case)
> - Reduce contention on mdev->lock during device removal
>
> I have some ideas on how to do this. I can work on them and send
> patches. Sounds like a plan?
>
Found a two line fix to the problem. Will send patch tomorrow.
I was able to do device inserts and removals in a row with the
change. It hangs every time device removed without the change.
thanks,
-- Shuah
--
Shuah Khan
Sr. Linux Kernel Developer
Open Source Innovation Group
Samsung Research America (Silicon Valley)
shuahkh@osg.samsung.com | (970) 217-8978
prev parent reply other threads:[~2015-11-12 3:25 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <5640C0F2.9070000@osg.samsung.com>
[not found] ` <5640C1DA.7040100@osg.samsung.com>
2015-11-11 12:30 ` Slow path and cpu lock warnings - MC Next Gen Mauro Carvalho Chehab
2015-11-11 14:22 ` Shuah Khan
2015-11-11 15:36 ` Mauro Carvalho Chehab
2015-11-11 15:49 ` Shuah Khan
2015-11-12 0:25 ` Shuah Khan
2015-11-12 3:25 ` Shuah Khan [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=564406BB.8020308@osg.samsung.com \
--to=shuahkh@osg.samsung.com \
--cc=javier@osg.samsung.com \
--cc=linux-media@vger.kernel.org \
--cc=mchehab@osg.samsung.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox