On Mon, Jan 04, 2016 at 11:07:43AM -0800, Andy Lutomirski wrote:
> On Mon, Jan 4, 2016 at 8:09 AM, Dominique Martinet
> wrote:
> > Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
> >> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> >> > [add cc's]
> >> >
> >> >
On Mon, Jan 4, 2016 at 8:09 AM, Dominique Martinet
wrote:
> Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
>> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
>> > [add cc's]
>> >
>> > Hi scheduler people:
>> >
>> > This is relatively easy for me to reproduce. Any
Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> > [add cc's]
> >
> > Hi scheduler people:
> >
> > This is relatively easy for me to reproduce. Any hints for debugging
> > it? Could we really have a bug in which
On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> [add cc's]
>
> Hi scheduler people:
>
> This is relatively easy for me to reproduce. Any hints for debugging
> it? Could we really have a bug in which processes that are
> schedulable as a result of mutex unlock aren't always
On Mon, Jan 04, 2016 at 11:07:43AM -0800, Andy Lutomirski wrote:
> On Mon, Jan 4, 2016 at 8:09 AM, Dominique Martinet
> wrote:
> > Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
> >> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> >> >
On Mon, Jan 4, 2016 at 8:09 AM, Dominique Martinet
wrote:
> Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
>> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
>> > [add cc's]
>> >
>> > Hi scheduler people:
>> >
>> > This is relatively
On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> [add cc's]
>
> Hi scheduler people:
>
> This is relatively easy for me to reproduce. Any hints for debugging
> it? Could we really have a bug in which processes that are
> schedulable as a result of mutex unlock aren't always
Peter Zijlstra wrote on Mon, Jan 04, 2016 at 04:59:15PM +0100:
> On Tue, Dec 29, 2015 at 10:43:26PM -0800, Andy Lutomirski wrote:
> > [add cc's]
> >
> > Hi scheduler people:
> >
> > This is relatively easy for me to reproduce. Any hints for debugging
> > it? Could we really have a bug in which
[add cc's]
Hi scheduler people:
This is relatively easy for me to reproduce. Any hints for debugging
it? Could we really have a bug in which processes that are
schedulable as a result of mutex unlock aren't always reliably
scheduled?
--Andy
On Thu, Dec 24, 2015 at 2:51 AM, Dominique Martinet
[add cc's]
Hi scheduler people:
This is relatively easy for me to reproduce. Any hints for debugging
it? Could we really have a bug in which processes that are
schedulable as a result of mutex unlock aren't always reliably
scheduled?
--Andy
On Thu, Dec 24, 2015 at 2:51 AM, Dominique Martinet
Andy Lutomirski wrote on Thu, Dec 17, 2015:
> This could be QEMU's analysis script screwing up. Is there a good way
> for me to gather more info?
I finally took some time to reproduce it (sorry for the delay)
Using your config, virtme commit (17363c2) and kernel tag v4.4-rc3 I was
able to
Andy Lutomirski wrote on Thu, Dec 17, 2015:
> This could be QEMU's analysis script screwing up. Is there a good way
> for me to gather more info?
I finally took some time to reproduce it (sorry for the delay)
Using your config, virtme commit (17363c2) and kernel tag v4.4-rc3 I was
able to
On Tue, Dec 8, 2015 at 10:45 PM, Al Viro wrote:
> On Wed, Dec 09, 2015 at 07:23:16AM +0100, Dominique Martinet wrote:
>> Andy Lutomirski wrote on Tue, Dec 08, 2015:
>> > Trace attached. I don't see anything wrong, but I also don't know
>> > what I'm looking for.
>>
>> Actually doesn't look good,
On Tue, Dec 8, 2015 at 10:45 PM, Al Viro wrote:
> On Wed, Dec 09, 2015 at 07:23:16AM +0100, Dominique Martinet wrote:
>> Andy Lutomirski wrote on Tue, Dec 08, 2015:
>> > Trace attached. I don't see anything wrong, but I also don't know
>> > what I'm looking for.
>>
>>
On Wed, Dec 09, 2015 at 07:23:16AM +0100, Dominique Martinet wrote:
> Andy Lutomirski wrote on Tue, Dec 08, 2015:
> > Trace attached. I don't see anything wrong, but I also don't know
> > what I'm looking for.
>
> Actually doesn't look good, not sure if trace could be missing messages
> but it
Dominique Martinet wrote on Wed, Dec 09, 2015:
> Andy Lutomirski wrote on Tue, Dec 08, 2015:
> > Trace attached. I don't see anything wrong, but I also don't know
> > what I'm looking for.
>
> Actually doesn't look good, not sure if trace could be missing messages
> but it looks like tags get
Andy Lutomirski wrote on Tue, Dec 08, 2015:
> Trace attached. I don't see anything wrong, but I also don't know
> what I'm looking for.
Actually doesn't look good, not sure if trace could be missing messages
but it looks like tags get reused...
Quick and dirty parse script (attached output, it
On Mon, Dec 7, 2015 at 6:33 PM, Al Viro wrote:
> On Mon, Dec 07, 2015 at 05:59:41PM -0800, Andy Lutomirski wrote:
>
>> If I dump all task states (see attached typescript), I see a bunch of
>> things blocked in 9p rpc. This makes me think it could be a QEMU bug,
>> not a kernel bug.
>
> Maybe,
On Mon, Dec 7, 2015 at 6:33 PM, Al Viro wrote:
> On Mon, Dec 07, 2015 at 05:59:41PM -0800, Andy Lutomirski wrote:
>
>> If I dump all task states (see attached typescript), I see a bunch of
>> things blocked in 9p rpc. This makes me think it could be a QEMU bug,
>> not a
Dominique Martinet wrote on Wed, Dec 09, 2015:
> Andy Lutomirski wrote on Tue, Dec 08, 2015:
> > Trace attached. I don't see anything wrong, but I also don't know
> > what I'm looking for.
>
> Actually doesn't look good, not sure if trace could be missing messages
> but it looks like tags get
Andy Lutomirski wrote on Tue, Dec 08, 2015:
> Trace attached. I don't see anything wrong, but I also don't know
> what I'm looking for.
Actually doesn't look good, not sure if trace could be missing messages
but it looks like tags get reused...
Quick and dirty parse script (attached output, it
On Wed, Dec 09, 2015 at 07:23:16AM +0100, Dominique Martinet wrote:
> Andy Lutomirski wrote on Tue, Dec 08, 2015:
> > Trace attached. I don't see anything wrong, but I also don't know
> > what I'm looking for.
>
> Actually doesn't look good, not sure if trace could be missing messages
> but it
On Mon, Dec 07, 2015 at 05:59:41PM -0800, Andy Lutomirski wrote:
> If I dump all task states (see attached typescript), I see a bunch of
> things blocked in 9p rpc. This makes me think it could be a QEMU bug,
> not a kernel bug.
Maybe, maybe not - I'd suggest dumping the 9p traffic and checking
On Mon, Dec 7, 2015 at 2:46 PM, Dominique Martinet
wrote:
> Andy Lutomirski wrote on Mon, Dec 07, 2015:
>> On Thu, Dec 3, 2015 at 9:52 PM, Andy Lutomirski wrote:
>> > Sometimes udevadm trigger --action=add hangs the system, and the splat
>> > below happens. This seems to be timing dependent,
Andy Lutomirski wrote on Mon, Dec 07, 2015:
> On Thu, Dec 3, 2015 at 9:52 PM, Andy Lutomirski wrote:
> > Sometimes udevadm trigger --action=add hangs the system, and the splat
> > below happens. This seems to be timing dependent, and I haven't been
> > able to trigger it yet with lockdep
On Mon, Dec 07, 2015 at 05:59:41PM -0800, Andy Lutomirski wrote:
> If I dump all task states (see attached typescript), I see a bunch of
> things blocked in 9p rpc. This makes me think it could be a QEMU bug,
> not a kernel bug.
Maybe, maybe not - I'd suggest dumping the 9p traffic and checking
Andy Lutomirski wrote on Mon, Dec 07, 2015:
> On Thu, Dec 3, 2015 at 9:52 PM, Andy Lutomirski wrote:
> > Sometimes udevadm trigger --action=add hangs the system, and the splat
> > below happens. This seems to be timing dependent, and I haven't been
> > able to trigger it yet
On Mon, Dec 7, 2015 at 2:46 PM, Dominique Martinet
wrote:
> Andy Lutomirski wrote on Mon, Dec 07, 2015:
>> On Thu, Dec 3, 2015 at 9:52 PM, Andy Lutomirski wrote:
>> > Sometimes udevadm trigger --action=add hangs the system, and the splat
>> > below
28 matches
Mail list logo