Test runs on a ppc64 BE guest succeeded.
Signed-off-by: Chandan Rajendra
---
The "yet to be upstreamed" fstests test
(https://github.com/chandanr/xfstests/commit/c2ce6196711e02792b434448e29f45b5f9a955f6)
was used to test the syscall. The test in turn depends on the usage o
On Thursday 14 Jan 2016 09:53:31 Michael Ellerman wrote:
> On Wed, 2016-01-13 at 22:20 +0530, Chandan Rajendra wrote:
> > Test runs on a ppc64 BE guest succeeded.
>
> Were the tests built 64-bit or 32-bit?
>
The test tool (xfs_io to be precise) was built as a 64-bit bi
e have to be more careful with s2. So check if it's within 8
> bytes of a 4K boundary and if so go to the byte-by-byte loop.
>
> Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in
> powerpc64 memcmp()")
> Cc: sta...@vger.kernel.org # v4.19+
> Repor
e have to be more careful with s2. So check if it's within 8
> bytes of a 4K boundary and if so go to the byte-by-byte loop.
>
> Fixes: 2d9ee327adce ("powerpc/64: Align bytes before fall back to .Lshort in
> powerpc64 memcmp()")
> Cc: sta...@vger.kernel.org # v4.19+
> Repor
When executing fstests' generic/026 test, I hit the following call trace,
[ 417.061038] BUG: Unable to handle kernel data access at 0xc0062ac4
[ 417.062172] Faulting instruction address: 0xc0092240
[ 417.062242] Oops: Kernel access of bad area, sig: 11 [#1]
[ 417.062299] LE SMP
On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote:
> Michael Ellerman writes:
>
> > Adding Simon who wrote the code.
> >
> > Chandan Rajendra writes:
> >> When executing fstests' generic/026 test, I hit the following call trace,
> >
On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote:
> Chandan Rajendra writes:
> > On Friday, February 1, 2019 4:43:52 PM IST Michael Ellerman wrote:
> >> Michael Ellerman writes:
> >>
> >> > Adding Simon who wrote the code.
> >>
On Thursday, February 7, 2019 5:27:09 AM IST Michael Ellerman wrote:
> Chandan Rajendra writes:
> > On Wednesday, February 6, 2019 5:20:04 PM IST Michael Ellerman wrote:
> >> Chandan Rajendra writes:
> >> > On Friday, February 1, 2019 4:43:52 PM IST Michael E
On Monday, March 13, 2017 03:33:07 AM Chris Packham wrote:
> Hi,
>
> I've just attempted to build a powerpc kernel from 4.11-rc2 using a
> custom defconfig (available on request) and I'm hitting the following
> error in the early stages of compilation.
>
> :1325:2: error: #warning syscall statx
of test-statx.c
Signed-off-by: Chandan Rajendra
---
arch/powerpc/include/asm/systbl.h | 1 +
arch/powerpc/include/asm/unistd.h | 2 +-
arch/powerpc/include/uapi/asm/unistd.h | 1 +
3 files changed, 3 insertions(+), 1 deletion(-)
diff --git a/arch/powerpc/include/asm/systbl.h
b/arch
Executing fstests' generic/036 test in a loop on next-20171013 kernel causes
BUG_ON()'s condition to evaluate to true,
run fstests generic/036 at 2017-10-14 09:23:29
[ cut here ]
kernel BUG at /root/repos/linux/kernel/irq_work.c:138!
Oops: Exception in kernel mode, sig: 5 [
On Wednesday, January 04, 2017 04:18:08 PM Anton Blanchard wrote:
> Hi,
>
> I'm consistently seeing ext4 filesystem corruption using a mainline
> kernel. It doesn't take much to trigger it - download a ppc64le Ubuntu
> cloud image, boot it in KVM and run:
>
> sudo apt-get update
> sudo apt-get di
on an ext4 filesystem with 64k as the block size and
when using a virtio based disk (having 512 byte as the logical block
size) inside a kvm guest.
This commit fixes the bug by using inode->i_blkbits to compute the
number of blocks to be cleaned.
Signed-off-by: Chandan Rajendra
---
fs/direct
On Wednesday, January 04, 2017 10:28:37 AM Theodore Ts'o wrote:
> On Wed, Jan 04, 2017 at 11:32:42AM +0530, Chandan Rajendra wrote:
> > On Wednesday, January 04, 2017 04:18:08 PM Anton Blanchard wrote:
> > > I'm consistently seeing ext4 filesystem corruption using
more detailed problem
> description and reproducer.
>
> Fixes: 20ce44d545844
> Signed-off-by: Jeff Moyer
>
> ---
> Chandan, can you please test this to ensure this still fixes your problem?
This patch fixes the failure,
Tested-by: Chandan Rajendra
--
chandan
'border' variable is set to a value of 2 times the block size of the
underlying filesystem. With 64k block size, the resulting value won't
fit into a 16-bit variable. Hence this commit changes the data type of
'border' to 'unsigned int'.
Signed-off-by: Chandan R
16 matches
Mail list logo