I
> >>> <<<< LOOK HERE
> >>> drivers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by
> >>> IA64_HP_SIM
> >>> arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice
> >>>
> >>> At any rate, a 3 mn gi
ers/acpi/Kconfig:6:symbol ARCH_SUPPORTS_ACPI is selected by
> IA64_HP_SIM
> arch/ia64/Kconfig:200:symbol IA64_HP_SIM is part of choice
>
> At any rate, a 3 mn git bisect tells me the circular dependency is
> exposed by this change:
>
> f3fd6cd74fedf99b6060f75df00943fda13b65
On Wednesday, January 2, 2019 5:56:10 AM IST Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 11 Dec 2018 10:13:22 +1100 Stephen Rothwell
> wrote:
> >
> > Today's linux-next merge of the f2fs tree got a conflict in:
> >
> > fs/f2fs/dir.c
> >
> > between commit:
> >
> > 848a010287e6 ("f2fs: u
On Friday, December 21, 2018 9:51:49 PM IST Guenter Roeck wrote:
> On Fri, Dec 21, 2018 at 07:32:44PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > News: there will be no linux-next release until Jan 2. Have a good break.
> >
> > Changes since 20181220:
> >
> > New tree: gpio-brgl
> >
> >
On Wednesday, December 12, 2018 12:42:20 AM IST Tony Lindgren wrote:
> Hi,
>
> Looks like commit 4de97efb578a ("fsverity: Move verity status check
> to fsverity_file_open") causes a boot regression for me with root
> on ext4 SDIO card, see below.
>
fsverity_file_open() used to incorrectly return
On Tuesday, December 11, 2018 11:11:17 PM IST Eric Biggers wrote:
> On Tue, Dec 11, 2018 at 03:15:53PM +0100, Krzysztof Kozlowski wrote:
> > Hi,
> >
> > Bisect from today's next pointed me to:
> > commit 4de97efb578a094e8fbf279522d41eb9ece1e3e0
> > Author: C
On Friday, June 29, 2018 11:48:39 AM IST Chandan Rajendra wrote:
> On Thursday, June 28, 2018 9:31:32 AM IST Ravi Bangoria wrote:
> > Hello Darrick,
> >
> > Lockdep is reporting a deadlock with following trace. Saw this on my
> > powerpc vm with 4GB of ram, running Lin
On Thursday, June 28, 2018 9:31:32 AM IST Ravi Bangoria wrote:
> Hello Darrick,
>
> Lockdep is reporting a deadlock with following trace. Saw this on my
> powerpc vm with 4GB of ram, running Linus/master kernel. Though, I
> don't have exact testcase to reproduce it. Is this something known?
I am
On Thursday, November 9, 2017 4:03:06 AM IST Stephen Rothwell wrote:
> Hi Miklos,
>
> After merging the overlayfs tree, today's linux-next build (powerpc
> ppc64_defconfig) produced this warning:
>
> fs/overlayfs/super.c: In function 'ovl_fill_super':
> fs/overlayfs/super.c:1070:25: warning: 'num
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 [
a fixed-size array
> again, but keeping the check for the array overflow.
>
> Fixes: 2df2c3402fc8 ("ext4: fix warning about stack corruption")
> Reported-by: Stefan Agner
> Signed-off-by: Arnd Bergmann
I executed xfstests on a ppc64 machine with both 4k and 64k block size
combination.
Tested-by: Chandan Rajendra
--
chandan
don't actually print the last two
> members of the array, as we loop though just the first 14 members.
> This could be easily addressed by adding two extra columns in the output,
> but that could in theory break parsers in user space, and should be
> a separate patch if we decide to modify it.
>
I executed xfstests on a ppc64 machine with both 4k and 64k block size
combination.
Tested-by: Chandan Rajendra
--
chandan
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
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
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 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
: Chandan Rajendra
---
fs/buffer.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/fs/buffer.c b/fs/buffer.c
index 1df2bd5..28484b3 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1660,7 +1660,7 @@ void clean_bdev_aliases(struct block_device *bdev,
sector_t block, sector_t len
On Tuesday 02 Feb 2016 10:22:16 Stephen Rothwell wrote:
> Hi David,
>
> Today's linux-next merge of the btrfs-kdave tree got a conflict in:
>
> fs/btrfs/file.c
>
> between commit:
>
> 5955102c9984 ("wrappers for ->i_mutex access")
>
> from Linus' tree and commit:
>
> 9703fefe0b13 ("Btrf
18 matches
Mail list logo