On Wed, Jan 16, 2013 at 10:52 AM, Sedat Dilek <sedat.dilek@xxxxxxxxx> wrote: > On Wed, Jan 16, 2013 at 10:35 AM, Takashi Iwai <tiwai@xxxxxxx> 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@xxxxxxx> 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. - 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 -- To unsubscribe from this list: send the line "unsubscribe linux-next" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html