On Fri, Jul 13, 2018 at 08:40:19AM +0200, Paolo Bonzini wrote:
> On 12/07/2018 18:30, Stefan Hajnoczi wrote:
> > On Wed, Jul 11, 2018 at 03:33:21PM +0200, Cornelia Huck wrote:
> >> The other qemu-nbds (the inet and the unix socket ones from the first
> >> run, the second inet one from the second ru
On 12/07/2018 18:30, Stefan Hajnoczi wrote:
> On Wed, Jul 11, 2018 at 03:33:21PM +0200, Cornelia Huck wrote:
>> The other qemu-nbds (the inet and the unix socket ones from the first
>> run, the second inet one from the second run) have a single thread with
>> the same backtrace I posted above.
>
>
On Wed, Jul 11, 2018 at 03:33:21PM +0200, Cornelia Huck wrote:
> The other qemu-nbds (the inet and the unix socket ones from the first
> run, the second inet one from the second run) have a single thread with
> the same backtrace I posted above.
We just discussed this on IRC, but for the record:
On Wed, 11 Jul 2018 15:15:45 +0200
Cornelia Huck wrote:
> On Wed, 11 Jul 2018 14:06:17 +0100
> Stefan Hajnoczi wrote:
>
> > On Mon, Jul 09, 2018 at 03:45:49PM +0200, Cornelia Huck wrote:
> > > Hi,
> > >
> > > I recently noticed that iotest 147 was hanging on my laptop, but worked
> > > fine
On Wed, 11 Jul 2018 14:06:17 +0100
Stefan Hajnoczi wrote:
> On Mon, Jul 09, 2018 at 03:45:49PM +0200, Cornelia Huck wrote:
> > Hi,
> >
> > I recently noticed that iotest 147 was hanging on my laptop, but worked
> > fine on my s390x LPAR. Turned out that the architecture was a red
> > herring; on
On Mon, Jul 09, 2018 at 03:45:49PM +0200, Cornelia Huck wrote:
> Hi,
>
> I recently noticed that iotest 147 was hanging on my laptop, but worked
> fine on my s390x LPAR. Turned out that the architecture was a red
> herring; on both platforms, things fail with the 'simple' trace backend
> and work
