On Fri, Oct 11, 2019 at 10:18:18AM +0200, Paolo Bonzini wrote:
> On 11/10/19 08:05, Jan Glauber wrote:
> > On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> >>> ...but if I bump notify_me size to uint64_t the issue goes away.
> >>
> >> Ouch.
On Wed, Oct 09, 2019 at 11:15:04AM +0200, Paolo Bonzini wrote:
> On 09/10/19 10:02, Jan Glauber wrote:
> > I'm still not sure what the actual issue is here, but could it be some bad
> > interaction between the notify_me and the list_lock? The are both 4 byte
> > and side
On Mon, Oct 07, 2019 at 04:58:30PM +0200, Paolo Bonzini wrote:
> On 07/10/19 16:44, dann frazier wrote:
> > On Mon, Oct 07, 2019 at 01:06:20PM +0200, Paolo Bonzini wrote:
> >> On 02/10/19 11:23, Jan Glauber wrote:
> >>> I've looked into this on ThunderX
On Mon, Oct 07, 2019 at 01:06:20PM +0200, Paolo Bonzini wrote:
> On 02/10/19 11:23, Jan Glauber wrote:
> > I've looked into this on ThunderX2. The arm64 code generated for the
> > atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
> > memory barr
On Wed, Oct 02, 2019 at 11:45:19AM +0200, Paolo Bonzini wrote:
> On 02/10/19 11:23, Jan Glauber wrote:
> > I've tried to verify me theory with this patch and didn't run into the
> > issue for ~500 iterations (usually I would trigger the issue ~20
> > iterations).
Debug files for aio-posix generated on 18.04 on ThunderX2.
Compiler:
gcc version 7.4.0 (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04.1)
Distro:
Ubuntu 18.04.3 LTS
** Attachment added: "aio-posix.tar.xz"
https://bugs.launchpad.net/qemu/+bug/1805256/+attachment/5293619/+files/aio-posix.tar.xz
--
You r
I've looked into this on ThunderX2. The arm64 code generated for the
atomic_[add|sub] accesses of ctx->notify_me doesn't contain any
memory barriers. It is just plain ldaxr/stlxr.
>From my understanding this is not sufficient for SMP sync.
If I read this comment correct:
void aio_notify(AioC
Patches posted:
https://marc.info/?l=linux-kernel&m=152224242828223&w=2
https://marc.info/?l=linux-kernel&m=152224242228218&w=2
--
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.
https://bugs.launchpad.net/bugs/1755073
Title:
ubuntu_zr
This is a regression caused by CONFIG_VMAP_STACK. The driver uses __pa
(phys_to_virt)
on a stack address which does not work with virtual mapped stacks.
To solve this upstream will require a bit more work, I'm attaching a minimal
patch
to work-around by using kmalloc for the problematic allocati
I can reproduce this issue with 4.13.0-37-generic. The debugfs info for the zip
driver shows that 2 requests are pending. Either the requests are not submitted
properly (Decomp Req Submitted=0) or
not completed (DOORBELL regs = 0).
root@crb1s:/sys/kernel/debug/thunderx_zip# cat zip_stats
I've successfully verified that this issue is resolved after updating to
-proposed:
thunderx2 imp def:
bus_access_rd
[Bus access read]
bus_access_wr
[Bus access write]
l1d_cache_rd
Hi Stefan :)
I've successfully verified that this issue is resolved after updating to
-proposed:
ubuntu@ubuntu:~$ sudo perf stat -e l1d_cache_rd -- sleep 1
Performance counter stats for 'sleep 1':
159,369 l1d_cache_rd
1.001034006 seconds time elapsed
Linux ubuntu 4.13.
Public bug reported:
Not all Qlogic network drivers are enabled in the installer kernel (Ubuntu
16.04) so detection
of network interface fails during installer network dialog.
Please enable this drivers:
1) Add all E4 FastLinQ qed* drivers (qed, qede, qedr, qedi, qedf)
2) Add all E3 FastLinQ bnx
Comments from Jerin Jacob:
Secondary queue set (>8 queues per port) won't work in upstream kernel.
Can you please test with <=8 queues per port?
If more queues are needed use XFI over XAUI to make it 10G *4 instead
of 1 * 40G.
--
You received this bug notification because you are a member of Ub
14 matches
Mail list logo
