Message-ID: <CA+icZUXfF1KNDYOqMMoShYWCN-Ra--v3SUvawCUAn7QpwwdQ3Q@mail.gmail.com>
Date:	Wed, 16 Jan 2013 13:51:37 +0100
From:	Sedat Dilek <sedat.dilek@...il.com>
To:	Takashi Iwai <tiwai@...e.de>
Cc:	Jiri Kosina <jkosina@...e.cz>, linux-fbdev@...r.kernel.org,
	LKML <linux-kernel@...r.kernel.org>, alan@...rguk.ukuu.org.uk,
	Andrew Morton <akpm@...ux-foundation.org>,
	"Rafael J. Wysocki" <rjw@...k.pl>,
	Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Jiri Slaby <jslaby@...e.cz>,
	linux-next <linux-next@...r.kernel.org>
Subject: Re: 3.8-rc2 lockdep complains about console_lock vs. fb_notifier_list.rwsem

On Wed, Jan 16, 2013 at 12:07 PM, Sedat Dilek <sedat.dilek@...il.com> wrote:
> On Wed, Jan 16, 2013 at 10:59 AM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>> On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@...il.com> wrote:
>>> On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@...e.de> wrote:
>>>> At Wed, 16 Jan 2013 10:21:46 +0100,
>>>> Sedat Dilek wrote:
>>>>>
>>>>> On Tue, Jan 15, 2013 at 3:25 PM, Takashi Iwai <tiwai@...e.de> wrote:
>>>>> > At Sat, 5 Jan 2013 13:13:27 +0100,
>>>>> > Sedat Dilek wrote:
>>>>> >>
>>>>> >> Hi Jiri,
>>>>> >>
>>>>> >> ...known issue (see thread in [1]), please feel free to test patches
>>>>> >> from Alan and Andrew (see [1], [2] and [3]) and report.
>>>>> >>
>>>>> >> Regards,
>>>>> >> - Sedat -
>>>>> >>
>>>>> >> [1] http://marc.info/?t=135309396400003&r=1&w=2
>>>>> >> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>>>> >> [3] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix.patch
>>>>> >> [4] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover-fix-2.patch
>>>>> >
>>>>> > I've hit this bug and tried the patch [2] ([3] and [4] are gone).
>>>>> > Unfortunately the deadlock is still reported, as seen below.
>>>>> >
>>>>> > A similar fix for fbcon_unbind(), splitting an unlocked version of
>>>>> > unbind_con_driver() and call it?
>>>>> >
>>>>> > (BTW, the patch [2] contains strange characters in the comments, and
>>>>> >  has a few coding issues easily detected by checkpatch.pl.)
>>>>> >
>>>>>
>>>>> [ CCing Rafael as he asked in another thread if I had sent a patch ]
>>>>>
>>>>> I noticed also some these "strange" chars in the patch from Andrew and
>>>>> a patch of mine was sent as
>>>>> "fb-Rework-locking-to-fix-lock-ordering-on-takeover-fix-comments.patch"
>>>>> to the lists.
>>>>>
>>>>> It is strange to me that Andrew or other maintainers himself did not
>>>>> check with "checkpatch.pl".
>>>>> This should be a common testcase!
>>>>> Hey, noone is perfect :-).
>>>>> ( /me has also not checked with that script - I just saw it. )
>>>>>
>>>>> Just as a note to the issue in general:
>>>>> Andrew took over the patch from Alan which is very honest - he is not
>>>>> the active TTY maintainer!
>>>>> Didn't Greg takeover maintenance from Alan (after a dispute and blaming Alan)?
>>>>> If this is true, why the hell is Greg not CCed?
>>>>
>>>> Let's do it :)
>>>>
>>>> Greg, Jiri, this bug hits already quite a few people.
>>>>
>>>> I can reproduce the bug easily on a machine with a radeon graphics.
>>>> It appears always at boot when lockdep is enabled.
>>>>
>>>>
>>>>> Thanks for the real patch in the followup of this thread!
>>>>> Who will take care of it :-)?
>>>>
>>>> Either tty maintainer, or fb maintainer, or Andrew?
>>>>
>>>> FWIW, Andrew took my patch in mm:
>>>>   http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>>>>   http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>>>
>>>
>>> [ CCing linux-next ML ]
>>>
>>> Thanks for all your efforts to get this fb-issue nailed down for mainline!
>>>
>>> Just as a note being a Linux-Next customer:
>>>
>>> "fb-yet-another-band-aid-for-fixing-lockdep-mess.patch" did not hit
>>> next-20130116!
>>> Thanks for the link!
>>>
>>> Normally Andrew sents out a mmotm release marking patches from his
>>> tree destinated for Linux-Next with a "*".
>>>
>>> To quote from the latest mmotm release-notes:
>>>
>>> "This mmotm tree contains the following patches against 3.8-rc3:
>>> (patches marked "*" will be included in linux-next)"
>>>
>>> But anyway this stuff is Linux-3.8 material as well.
>>>
>>
>> JYI: [1] now does NOT have anymore those "strange" chars, Thanks Takashi san.
>>
>> I will test next-20130116 with both fb-fixes as -2 kernel.
>> ( Running LTP-lite on my "naked" -1 kernel only with my kbuild/deb-pkg-fixes. )
>>
>> Thanks to everyone involved.
>>
>
> I have reverted the three fb-fixes from akpm-tree in next-20130116...
> ...and applied the two fb-fixes from mmotm-tree (see attached patches file).
>
> FYI: The 1st patch from mmotm-tree is a (proper) replacement for the 3
> patches in Linux-Next.
>
> Furthermore, I made some quick testing:
> Booting into the system is fine.
> Suspend + resume looks good (see dmesg.diff).
>
> See also attached files!
>

En plus, I have run successfully LTP-lite.

$ egrep -i 'error|fail'
runltplite-results_3.8.0-rc3-next20130116-2-iniza-generic.txt | egrep
-v -i 'expected' | wc -l
208

I do not want to flood the MLs, so people wanting full LTP-lite report
(~600KiB) can contact me.

- Sedat -

> - Sedat -
>
>> - Sedat -
>>
>> [1] http://ozlabs.org/~akpm/mmots/broken-out/fb-rework-locking-to-fix-lock-ordering-on-takeover.patch
>> [2] http://ozlabs.org/~akpm/mmots/broken-out/fb-yet-another-band-aid-for-fixing-lockdep-mess.patch
>>> - Sedat -
>>>
>>>>
>>>> thanks,
>>>>
>>>> Takashi

View attachment "ltplite_expected-failures_3.8.0-rc3-next20130116-2-iniza-generic.txt" of type "text/plain" (15254 bytes)

Powered by blists - more mailing lists