On Fri, Nov 9, 2012 at 2:42 PM, Sasha Levin wrote:
> On 11/09/2012 02:34 PM, Hugh Dickins wrote:
>> On Thu, 8 Nov 2012, Alan Cox wrote:
>>> commit f35b3fbf24c4e4debb6a7a864b09854ccc2a22e7
>>> Author: Alan Cox
>>> Date: Wed Nov 7 16:35:08 2012 +
>>>
>>> fb: Rework locking to fix lock ord
On 11/09/2012 02:34 PM, Hugh Dickins wrote:
> On Thu, 8 Nov 2012, Alan Cox wrote:
>> commit f35b3fbf24c4e4debb6a7a864b09854ccc2a22e7
>> Author: Alan Cox
>> Date: Wed Nov 7 16:35:08 2012 +
>>
>> fb: Rework locking to fix lock ordering on takeover
>>
>> Adjust the console layer to
On Thu, 8 Nov 2012, Alan Cox wrote:
> commit f35b3fbf24c4e4debb6a7a864b09854ccc2a22e7
> Author: Alan Cox
> Date: Wed Nov 7 16:35:08 2012 +
>
> fb: Rework locking to fix lock ordering on takeover
>
> Adjust the console layer to allow a take over call where the caller
> already
commit f35b3fbf24c4e4debb6a7a864b09854ccc2a22e7
Author: Alan Cox
Date: Wed Nov 7 16:35:08 2012 +
fb: Rework locking to fix lock ordering on takeover
Adjust the console layer to allow a take over call where the caller already
holds the locks. Make the fb layer lock in order.
On Wed, 07 Nov 2012 17:15:45 +0100
Bjørn Mork wrote:
> Alan Cox writes:
>
> > +
> > +static int bind_con_driver(const struct consw *csw, int first, int last,
> > + int deflt)
> > +{
> > + int ret;
> > +
> > + console_unlock();
>
> console_lock() maybe...
Thanks I'l
Alan Cox writes:
> +
> +static int bind_con_driver(const struct consw *csw, int first, int last,
> +int deflt)
> +{
> + int ret;
> +
> + console_unlock();
console_lock() maybe...
> + ret = do_bind_con_driver(csw, first, last, deflt);
> + console_unlo
On Wed, 07 Nov 2012 08:47:08 -0500
Sasha Levin wrote:
> On 11/06/2012 12:38 PM, Alan Cox wrote:
> >> > The root
> >> > cause is loading two different framebuffers with one taking over from
> >> > another - that should be an obscure corner case and once the fuzz
> >> testing
> >> > can avoid.
On 11/06/2012 12:38 PM, Alan Cox wrote:
>> > The root
>> > cause is loading two different framebuffers with one taking over from
>> > another - that should be an obscure corner case and once the fuzz testing
>> > can avoid.
>> >
>> > I had a semi-informed poke at this and came up with a poss
On Tue, 6 Nov 2012, Hugh Dickins wrote:
>
> Ah, now I actually scan through it, I see references to blank screen:
> I'll try taking off your patch and seeing if it came up at screen
> blanking time, then put on your patch back on and try again.
> I'll report back in an hour or two.
Yes, that was
On Tue, 6 Nov 2012, Alan Cox wrote:
> On Mon, 5 Nov 2012 12:34:44 -0800 (PST)
> Hugh Dickins wrote:
> > On Mon, 5 Nov 2012, Alan Cox wrote:
> > > > The fbdev potential for deadlock may be years old, but the warning
> > > > (and consequent disabling of lockdep from that point on - making it
> > > >
> > The root
> > cause is loading two different framebuffers with one taking over from
> > another - that should be an obscure corner case and once the fuzz testing
> > can avoid.
> >
> > I had a semi-informed poke at this and came up with a possible patch (not
> very tested)
>
> If this f
On Tue, Nov 06, 2012 at 04:11:00PM +, Alan Cox wrote:
> > But a deadlock we have lived with for years. Without reverting,
> > we're prevented from discovering all the new deadlocks we're adding.
>
> We lived with it locking boxes up on users but not knowing why.
Circa 3.5 we got a lot m
On Mon, 5 Nov 2012 12:34:44 -0800 (PST)
Hugh Dickins wrote:
> On Mon, 5 Nov 2012, Alan Cox wrote:
> > > The fbdev potential for deadlock may be years old, but the warning
> > > (and consequent disabling of lockdep from that point on - making it
> > > useless to everybody else in need of it) is ne
On Mon, 5 Nov 2012, Alan Cox wrote:
> > The fbdev potential for deadlock may be years old, but the warning
> > (and consequent disabling of lockdep from that point on - making it
> > useless to everybody else in need of it) is new, and comes from the
> > commit below in linux-next.
> >
> > I rever
> The fbdev potential for deadlock may be years old, but the warning
> (and consequent disabling of lockdep from that point on - making it
> useless to everybody else in need of it) is new, and comes from the
> commit below in linux-next.
>
> I revert it in my own testing: if there is no quick fix
On Mon, 5 Nov 2012, Sasha Levin wrote:
> On 11/05/2012 12:59 PM, Alan Cox wrote:
> > On Mon, 5 Nov 2012 12:26:43 -0500
> > Sasha Levin wrote:
> >
> >> Ping? Should I bisect it?
> >>
> >> On Fri, Oct 26, 2012 at 9:37 AM, Alan Cox wrote:
> >>> On Thu, 25 Oct 2012 15:37:43 -0400
> >>> Sasha Levin
On 11/05/2012 12:59 PM, Alan Cox wrote:
> On Mon, 5 Nov 2012 12:26:43 -0500
> Sasha Levin wrote:
>
>> Ping? Should I bisect it?
>>
>> On Fri, Oct 26, 2012 at 9:37 AM, Alan Cox wrote:
>>> On Thu, 25 Oct 2012 15:37:43 -0400
>>> Sasha Levin wrote:
>>>
Hi all,
While fuzzing with trin
On Mon, 5 Nov 2012 12:26:43 -0500
Sasha Levin wrote:
> Ping? Should I bisect it?
>
> On Fri, Oct 26, 2012 at 9:37 AM, Alan Cox wrote:
> > On Thu, 25 Oct 2012 15:37:43 -0400
> > Sasha Levin wrote:
> >
> >> Hi all,
> >>
> >> While fuzzing with trinity inside a KVM tools (lkvm) guest running late
Ping? Should I bisect it?
On Fri, Oct 26, 2012 at 9:37 AM, Alan Cox wrote:
> On Thu, 25 Oct 2012 15:37:43 -0400
> Sasha Levin wrote:
>
>> Hi all,
>>
>> While fuzzing with trinity inside a KVM tools (lkvm) guest running latest
>> -next kernel,
>> I've stumbled on the following spew:
>
> Looks re
On Thu, 25 Oct 2012 15:37:43 -0400
Sasha Levin wrote:
> Hi all,
>
> While fuzzing with trinity inside a KVM tools (lkvm) guest running latest
> -next kernel,
> I've stumbled on the following spew:
Looks real enough but its not a tty/vt layer spew. This is all coming out
of the core framebuffer
Hi all,
While fuzzing with trinity inside a KVM tools (lkvm) guest running latest -next
kernel,
I've stumbled on the following spew:
[ 603.081796] ==
[ 603.081797] [ INFO: possible circular locking dependency detected ]
[ 603.081800] 3.7.0-r
21 matches
Mail list logo
