> I think with this patch from -rc6 the symptoms should be cured:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7
>
> if that theory is right.
The result with 4.13-rc6 is positive but mixed: the message about MSI-X
> I think with this patch from -rc6 the symptoms should be cured:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=c005390374957baacbc38eef96ea360559510aa7
>
> if that theory is right.
The result with 4.13-rc6 is positive but mixed: the message about MSI-X
> >> bisected to git commit 63e3027
> >
> > That's a merge commit that adds 100 different commits, and this happened
> > way back in March.
> >
> > Please find the exact dword access in:
> >
> > drivers/pci/pcie/portdrv_{core,pci,bus}.c
> >
> > that triggers this unaligned access so we can
> >> bisected to git commit 63e3027
> >
> > That's a merge commit that adds 100 different commits, and this happened
> > way back in March.
> >
> > Please find the exact dword access in:
> >
> > drivers/pci/pcie/portdrv_{core,pci,bus}.c
> >
> > that triggers this unaligned access so we can
> If rhashtable_walk_next detects a resize operation in progress, it jumps
> to the new table and continues walking that one. But it misses to drop
> the reference to it's current item, leading it to continue traversing
> the new table's bucket in which the current item is sorted into, and
> after
If rhashtable_walk_next detects a resize operation in progress, it jumps
to the new table and continues walking that one. But it misses to drop
the reference to it's current item, leading it to continue traversing
the new table's bucket in which the current item is sorted into, and
after
> > I'd like to know that your another problem is related to commit
> > bf0dea23a9c0 ("mm/slab: use percpu allocator for cpu cache"). So,
> > if the commit is reverted, your another problem is also gone
> > completely?
>
> The other problem has been present forever.
Umm? I am afraid I have been
I'd like to know that your another problem is related to commit
bf0dea23a9c0 (mm/slab: use percpu allocator for cpu cache). So,
if the commit is reverted, your another problem is also gone
completely?
The other problem has been present forever.
Umm? I am afraid I have been describing
> From: David Miller
> Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
>
> >
> > I'm getting tons of the following on sparc64:
> >
> > [603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
> > [603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
> >
From: David Miller da...@davemloft.net
Date: Sat, 11 Oct 2014 22:15:10 -0400 (EDT)
I'm getting tons of the following on sparc64:
[603965.383447] Kernel unaligned access at TPC[546b58] free_block+0x98/0x1a0
[603965.396987] Kernel unaligned access at TPC[546b60] free_block+0xa0/0x1a0
> Shit, you're right, sorry about that. Its odd, I'm running it here, and its
> not
> causing problems, but thats obviously wrong. Meelis, please add the above fix
> to your test and confirm that it sovles the problem. If you could keep the
> previous patch in place too that would be great,
Shit, you're right, sorry about that. Its odd, I'm running it here, and its
not
causing problems, but thats obviously wrong. Meelis, please add the above fix
to your test and confirm that it sovles the problem. If you could keep the
previous patch in place too that would be great, as we
This is todays fresh git with 3.15.0-rc6-00190-g1ee1cea on V210, THP
enabled & always on. Got this and a segfault on apt-spawned xz.
[ 142.599575] [ cut here ]
[ 142.660349] WARNING: CPU: 1 PID: 2237 at mm/mmap.c:2741
exit_mmap+0x140/0x160()
[ 142.756483] Modules
This is todays fresh git with 3.15.0-rc6-00190-g1ee1cea on V210, THP
enabled always on. Got this and a segfault on apt-spawned xz.
[ 142.599575] [ cut here ]
[ 142.660349] WARNING: CPU: 1 PID: 2237 at mm/mmap.c:2741
exit_mmap+0x140/0x160()
[ 142.756483] Modules
> Meelis and Aaro, I've found and fixed several THP bugs for sparc64
> over the last week or so.
>
> I cannot %100 account for the exit_mmap() WARN_ON that you two have
> been able to trigger, however I'd like you both to test the changes
> nonetheless.
>
> They are against 3.15 but they should
Meelis and Aaro, I've found and fixed several THP bugs for sparc64
over the last week or so.
I cannot %100 account for the exit_mmap() WARN_ON that you two have
been able to trigger, however I'd like you both to test the changes
nonetheless.
They are against 3.15 but they should apply
> > Just for the archives, I got one of these again with 3.14:
>
> Meelis and Aaro, thanks again for all of your reports.
>
> After pouring over a lot of the data and auditing some code I'm
> suspecting it's a problem with transparent huge pages.
>
> One thing you two can do to help me further
Just for the archives, I got one of these again with 3.14:
Meelis and Aaro, thanks again for all of your reports.
After pouring over a lot of the data and auditing some code I'm
suspecting it's a problem with transparent huge pages.
One thing you two can do to help me further confirm
> Signed-off-by: Steffen Klassert
Works fine, thanks!
Tested-by: Meelis Roos
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at
Signed-off-by: Steffen Klassert steffen.klass...@secunet.com
Works fine, thanks!
Tested-by: Meelis Roos mr...@linux.ee
--
Meelis Roos (mr...@linux.ee)
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to majord...@vger.kernel.org
More majordomo
20 matches
Mail list logo
