On 2/22/21 6:42 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_sq_thread':
> fs/io_uring.c:6787:3: error: implicit declaration of function
> 'io_ctx_disable_sqo_subm
Hi all,
On Tue, 2 Feb 2021 14:16:18 +1100 Stephen Rothwell
wrote:
>
> On Tue, 2 Feb 2021 13:57:14 +1100 Stephen Rothwell
> wrote:
> >
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > block/bio.c: In function 'bio_add_zone_appen
Both fixups look good to me, thanks.
Hi all,
On Tue, 2 Feb 2021 13:57:14 +1100 Stephen Rothwell
wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> block/bio.c: In function 'bio_add_zone_append_page':
> block/bio.c:860:31: error: 'struct bio' has no member named 'bi_d
Hi David,
On Mon, 14 Dec 2020 22:54:46 +0100 David Sterba wrote:
>
> On Tue, Dec 15, 2020 at 08:43:00AM +1100, Stephen Rothwell wrote:
> >
> > On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba wrote:
> > >
> > > On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> > > > On 12/14/20 1
On Tue, Dec 15, 2020 at 08:43:00AM +1100, Stephen Rothwell wrote:
> Hi David,
>
> On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba wrote:
> >
> > On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> > > On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> > > > Just a reminder that I am still
Hi David,
On Mon, 14 Dec 2020 22:36:12 +0100 David Sterba wrote:
>
> On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> > On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> > > Just a reminder that I am still applying the above merge fix.
> >
> > I sent in my core changes, but they ha
On Mon, Dec 14, 2020 at 01:12:46PM -0700, Jens Axboe wrote:
> On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> > Just a reminder that I am still applying the above merge fix.
>
> I sent in my core changes, but they haven't been pulled yet. So I guess
> we're dealing with a timing situation... David,
Hi all,
On Mon, 7 Dec 2020 14:09:51 +1100 Stephen Rothwell
wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_shutdown':
> fs/io_uring.c:3782:9: error: too many arguments to function 'sock_from_file'
Hi all,
On Wed, 2 Dec 2020 15:01:49 +1100 Stephen Rothwell
wrote:
>
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/btrfs/zoned.c: In function 'btrfs_get_dev_zone_info':
> fs/btrfs/zoned.c:168:21: error: 'struct block_device
On 12/14/20 1:09 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Wed, 2 Dec 2020 15:01:49 +1100 Stephen Rothwell
> wrote:
>>
>> Hi all,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> fs/btrfs/zoned.c: In function 'btrfs_get_dev_zone_inf
On Mon, 2020-12-07 at 14:09 +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/io_uring.c: In function 'io_shutdown':
> fs/io_uring.c:3782:9: error: too many arguments to function
> 'sock_from_fi
On Wed, Dec 02, 2020 at 03:01:49PM +1100, Stephen Rothwell wrote:
> I applied the following merge fix patch (which may, or may not, be
> correct but fixes the build).
The fixes are exactly what I would have done. Thanks!
On 7/15/20 9:22 AM, Geert Uytterhoeven wrote:
> Hi Jens,
>
>> On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe wrote:
>>> On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell
wrote:
> After merging the block tree, today's linux-next build (arm
>
Hi Jens,
> On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe wrote:
> > On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> > > On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell
> > > wrote:
> > >> After merging the block tree, today's linux-next build (arm
> > >> multi_v7_defconfig) failed like this:
> >
Hi Jens,
On Wed, Jul 15, 2020 at 5:08 PM Jens Axboe wrote:
> On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> > On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell
> > wrote:
> >> After merging the block tree, today's linux-next build (arm
> >> multi_v7_defconfig) failed like this:
> >>
> >> block
On 7/15/20 3:24 AM, Geert Uytterhoeven wrote:
> On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell
> wrote:
>> After merging the block tree, today's linux-next build (arm
>> multi_v7_defconfig) failed like this:
>>
>> block/blk-timeout.c: In function 'blk_round_jiffies':
>> block/blk-timeout.c:96:1
On 7/14/20 8:14 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-timeout.c: In function 'blk_round_jiffies':
> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first
> u
On Wed, Jul 15, 2020 at 4:26 AM Stephen Rothwell wrote:
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> block/blk-timeout.c: In function 'blk_round_jiffies':
> block/blk-timeout.c:96:14: error: 'CONFIG_HZ_ROUGH_MASK' undeclared (first
> us
On 5/25/20 10:36 PM, Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe wrote:
>>
>> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
>>>
>>> After merging the block tree, today's linux-next build (arm
>>> multi_v7_defconfig) failed like this:
>>>
>>> mm/filemap.c: In
Hi all,
On Mon, 25 May 2020 13:03:44 -0600 Jens Axboe wrote:
>
> On 5/24/20 11:08 PM, Stephen Rothwell wrote:
> >
> > After merging the block tree, today's linux-next build (arm
> > multi_v7_defconfig) failed like this:
> >
> > mm/filemap.c: In function 'generic_file_buffered_read':
> > mm/file
On 5/24/20 11:08 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> mm/filemap.c: In function 'generic_file_buffered_read':
> mm/filemap.c:2075:9: error: 'written' undeclared (first use in this
> funct
On 5/22/20 5:32 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> fs/libfs.c: In function 'generic_file_fsync':
> fs/libfs.c:1116:9: error: too few arguments to function 'blkdev_issue_flush'
> 1116 | ret
On 5/14/20 2:57 AM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allnoconfig) failed like this:
>
> In file included from include/linux/blk-cgroup.h:23,
> from include/linux/writeback.h:14,
> from include/
On 5/11/20 9:17 AM, Christoph Hellwig wrote:
> On Mon, May 11, 2020 at 09:06:41AM -0600, Jens Axboe wrote:
>> On 5/10/20 10:27 PM, Stephen Rothwell wrote:
>>> Hi all,
>>>
>>> After merging the block tree, today's linux-next build (x86_64
>>> allmodconfig) failed like this:
>>>
>>> drivers/block/aoe
On Mon, May 11, 2020 at 09:06:41AM -0600, Jens Axboe wrote:
> On 5/10/20 10:27 PM, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the block tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
> > d
On 5/10/20 10:27 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/block/aoe/aoeblk.c: In function 'aoeblk_gdalloc':
> drivers/block/aoe/aoeblk.c:410:21: error: 'struct backing_dev_info' has no
>
On 5/7/20 11:28 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/kernel.h:15,
> from include/linux/list.h:9,
> from include/linux/mod
On 7/11/19 2:17 PM, Tejun Heo wrote:
> Hello,
>
> Yeah, my patche series raced with 8648de2c581e ("f2fs: add bio cache
> for IPU"). Jens, can you please apply this one too?
I can't really, as that commit isn't in Linus's tree yet. I'll
keep an eye out for what hits mainline, I'll probably ship w
Hello,
Yeah, my patche series raced with 8648de2c581e ("f2fs: add bio cache
for IPU"). Jens, can you please apply this one too?
On Thu, Jul 11, 2019 at 03:15:07PM +1000, Stephen Rothwell wrote:
> From: Stephen Rothwell
> Date: Thu, 11 Jul 2019 15:13:21 +1000
> Subject: [PATCH] f2fs: fix for wbc
Hi Christoph,
On Fri, 21 Jun 2019 10:18:36 +0200 Christoph Hellwig wrote:
>
> On Fri, Jun 21, 2019 at 01:56:16PM +1000, Stephen Rothwell wrote:
> > Hi Jens,
> >
> > After merging the block tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: "css_next_descen
On Fri, Jun 21, 2019 at 01:56:16PM +1000, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "css_next_descendant_pre" [block/bfq.ko] undefined!
I think the culprit is "bfq-iosched: move bfq_stat_recu
On Wed, Jan 16, 2019 at 01:48:24PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> fs/gfs2/lops.c: In function 'gfs2_end_log_read':
> fs/gfs2/lops.c:394:39: error: macro "bio_for_each_segment_all" re
On Wed, Jan 16, 2019 at 01:35:52PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> net/sunrpc/xprtsock.c: In function 'xs_flush_bvec':
> net/sunrpc/xprtsock.c:390:2: error: implicit declaration of
Hi all,
On Thu, 26 Jul 2018 14:56:24 +1000 Stephen Rothwell
wrote:
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/nvme/target/rdma.c: In function 'nvmet_rdma_find_get_device':
> drivers/nvme/target/rdma.c:894:26: error: 'struct i
On 7/30/18 9:07 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/scsi/sd.o: In function `sd_done':
> sd.c:(.text+0x1050): undefined reference to `t10_pi_complete'
>
> Presuably caused by com
Hi Steve,
On Thu, 26 Jul 2018 07:32:16 -0500 "Steve Wise"
wrote:
>
> > diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> > index 86121a7a19b2..8c30ac7d8078 100644
> > --- a/drivers/nvme/target/rdma.c
> > +++ b/drivers/nvme/target/rdma.c
> > @@ -891,7 +891,7 @@ nvmet_rdma_fin
On 7/26/18 1:54 PM, Bart Van Assche wrote:
> On 07/26/18 10:48, Jens Axboe wrote:
>> On 7/26/18 1:48 AM, Christoph Hellwig wrote:
>>> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index 86121a7a19b2..
On 07/26/18 10:48, Jens Axboe wrote:
On 7/26/18 1:48 AM, Christoph Hellwig wrote:
On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
index 86121a7a19b2..8c30ac7d8078 100644
--- a/drivers/nvme/target/rdma.c
+++ b
ker...@vger.kernel.org>; Steve Wise
> Subject: Re: linux-next: build failure after merge of the block tree
>
> On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote:
> > >> inline_page_count = num_pages(port->inline_data_size);
> > >>
On Thu, Jul 26, 2018 at 10:48:21AM -0700, Jens Axboe wrote:
> >>inline_page_count = num_pages(port->inline_data_size);
> >>inline_sge_count = max(cm_id->device->attrs.max_sge_rd,
> >> - cm_id->device->attrs.max_sge) - 1;
> >> + cm_id->device
On 7/26/18 1:48 AM, Christoph Hellwig wrote:
> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
>> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
>> index 86121a7a19b2..8c30ac7d8078 100644
>> --- a/drivers/nvme/target/rdma.c
>> +++ b/drivers/nvme/target/rdma.c
Hey Stephen:
> I have applied the following merge fix patch for today:
>
> From: Stephen Rothwell
> Date: Thu, 26 Jul 2018 14:32:15 +1000
> Subject: [PATCH] nvme-dma: merge fix up for replacement of max_sge
>
> Signed-off-by: Stephen Rothwell
> ---
> drivers/nvme/host/rdma.c | 2 +-
> drive
Hi Christoph,
On Thu, 26 Jul 2018 10:48:33 +0200 Christoph Hellwig wrote:
>
> On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
> > diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> > index 86121a7a19b2..8c30ac7d8078 100644
> > --- a/drivers/nvme/target/rdma.c
On Thu, Jul 26, 2018 at 02:56:24PM +1000, Stephen Rothwell wrote:
> diff --git a/drivers/nvme/target/rdma.c b/drivers/nvme/target/rdma.c
> index 86121a7a19b2..8c30ac7d8078 100644
> --- a/drivers/nvme/target/rdma.c
> +++ b/drivers/nvme/target/rdma.c
> @@ -891,7 +891,7 @@ nvmet_rdma_find_get_device(s
Hi Christoph,
On Thu, 24 Aug 2017 10:44:10 +0200 Christoph Hellwig wrote:
>
> Keith already sent a patch for this, it was a rebase failure :(
Ah, OK, thanks.
> The documentation one is intentional - the document is completely
> out of data, so doctoring around a bit won't help. I'll try to fin
Hi Stephen,
Keith already sent a patch for this, it was a rebase failure :(
The documentation one is intentional - the document is completely
out of data, so doctoring around a bit won't help. I'll try to find
some time to replace it with a sane new doc that use the ReST stuff
to not duplicate t
Hi all,
On Thu, 24 Aug 2017 13:32:03 +1000 Stephen Rothwell
wrote:
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> block/bio-integrity.c: In function '__bio_integrity_endio':
> block/bio-integrity.c:388:51: error: 'struct bio' has no memb
Hi Guenter,
On Tue, 4 Jul 2017 08:15:57 -0700 Guenter Roeck wrote:
>
> On Tue, Jun 13, 2017 at 08:54:09PM +1000, Stephen Rothwell wrote:
> >
> > After merging the block tree, today's linux-next build (s390x
> > s390-defconfig) failed like this:
> >
> > drivers/s390/block/scm_blk.c:293:10: error
On Tue, Jun 13, 2017 at 08:54:09PM +1000, Stephen Rothwell wrote:
> Hi Jall,
>
> After merging the block tree, today's linux-next build (s390x
> s390-defconfig) failed like this:
>
> drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared
> (first use in this function)
> dr
Hi Jens,
On Wed, 28 Jun 2017 09:11:32 -0600 Jens Axboe wrote:
>
> On 06/28/2017 08:01 AM, Jens Axboe wrote:
> > But put_user() is fine? Just checking here, since the change adds
> > both a u64 put and get user.
Yes, put_user is fine (it does 2 4 byte moves. The asm is there to do
the 8 byte g
On 06/28/2017 08:01 AM, Jens Axboe wrote:
> On 06/28/2017 06:43 AM, Jens Axboe wrote:
>> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>>> Hi Jens,
>>>
>>> After merging the block tree, today's linux-next build (powerpc
>>> allnoconfig) failed like this:
>>>
>>> fs/fcntl.o: In function `do_fcntl'
On 06/28/2017 06:43 AM, Jens Axboe wrote:
> On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (powerpc
>> allnoconfig) failed like this:
>>
>> fs/fcntl.o: In function `do_fcntl':
>> fcntl.c:(.text+0x6d4): undefined reference to
On 06/28/2017 02:04 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (powerpc
> allnoconfig) failed like this:
>
> fs/fcntl.o: In function `do_fcntl':
> fcntl.c:(.text+0x6d4): undefined reference to `__get_user_bad'
> fcntl.c:(.text+0x730): undefi
Hi Sebastian,
On Mon, 19 Jun 2017 11:00:23 +0200 (CEST) Sebastian Ott
wrote:
>
> Ok, we should also adjust the return code to fix this:
>
> drivers/s390/block/scm_blk.c:426:2: warning: initialization from incompatible
> pointer type [enabled by default]
> .queue_rq = scm_blk_request,
> ^
>
On Thu, 15 Jun 2017, Sebastian Ott wrote:
> On Tue, 13 Jun 2017, Stephen Rothwell wrote:
> > After merging the block tree, today's linux-next build (s390x
> > s390-defconfig) failed like this:
> >
> > drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY'
> > undeclared (first use in
On Tue, 13 Jun 2017, Stephen Rothwell wrote:
> After merging the block tree, today's linux-next build (s390x
> s390-defconfig) failed like this:
>
> drivers/s390/block/scm_blk.c:293:10: error: 'BLK_MQ_RQ_QUEUE_BUSY' undeclared
> (first use in this function)
> drivers/s390/block/scm_blk.c:327:9: e
On May 1, 2017, at 7:37 PM, Stephen Rothwell wrote:
>
> Hi Jens,
>
>> On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe wrote:
>>
>> Indeed, I have warned Linus about it. Thanks Stephen.
>
> Thanks.
>
> BTW, (unusually) I did not see your pull request(s) ...
I CC'ed linux-block, so they showed
Hi Jens,
On Mon, 1 May 2017 19:09:34 -0600 Jens Axboe wrote:
>
> Indeed, I have warned Linus about it. Thanks Stephen.
Thanks.
BTW, (unusually) I did not see your pull request(s) ...
--
Cheers,
Stephen Rothwell
> On May 1, 2017, at 7:07 PM, Stephen Rothwell wrote:
>
> Hi all,
>
>> On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell
>> wrote:
>>
>> After merging the block tree, today's linux-next build (powerpc
>> ppc64_defconfig) failed like this:
>>
>> drivers/block/nbd.c: In function 'nbd_genl_c
Hi all,
On Tue, 18 Apr 2017 13:02:29 +1000 Stephen Rothwell
wrote:
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/block/nbd.c: In function 'nbd_genl_connect':
> drivers/block/nbd.c:1662:10: error: too few arguments to functio
On Sun, Jan 29, 2017 at 06:53:42PM -0700, Jens Axboe wrote:
> Huh, I wonder how that snuck past my allmodconfig builds, that looks
> like a clear failure.
I also did tons of test builds and never saw it, not sure why
the NVMe-SCSI code still someone how an implicit include of scsi_cmnd.h.
But in
On 01/29/2017 06:53 PM, Jens Axboe wrote:
> On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
>> Hi Jens,
>>
>> After merging the block tree, today's linux-next build (x86_64
>> allmodconfig) failed like this:
>>
>> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
>> drivers/nvme/host/scs
On 01/29/2017 06:43 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> drivers/nvme/host/scsi.c: In function 'nvme_scsi_translate':
> drivers/nvme/host/scsi.c:2350:9: error: 'BLK_MAX_CDB' undeclared (firs
On 11/30/2016 08:02 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe wrote:
>>
>> On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
>>>
>>> I love APIs changing :-(
>>
>> It's a necessary evil...
>
> Yeah
>
>> This could have been avoided with the XFS tre
Hi Jens,
On Wed, 30 Nov 2016 20:00:36 -0700 Jens Axboe wrote:
>
> On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
> >
> > I love APIs changing :-(
>
> It's a necessary evil...
Yeah
> This could have been avoided with the XFS tree pulling in the block
> changes, but that obviously has other
On 11/30/2016 07:55 PM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> fs/iomap.c: In function 'iomap_dio_zero':
> fs/iomap.c:725:38: error: 'WRITE_ODIRECT' undeclared (first use in this
> function)
On 11/07/2016 08:21 PM, Stephen Rothwell wrote:
Hi Jens,
After merging the block tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
block/blk-flush.c: In function 'flush_data_end_io':
block/blk-flush.c:369:20: error: 'REQ_STARTED' undeclared (first use in this
function)
On 09/19/2016 12:18 AM, Stephen Rothwell wrote:
Hi Jens,
After merging the block tree, today's linux-next build (powerpc
allnoconfig) failed like this:
In file included from block/blk-mq-pci.c:13:0:
include/linux/blk-mq.h:57:18: error: field 'kobj' has incomplete type
struct kobject kobj;
Thanks Stephen,
the fix looks good to me:
Reviewed-by: Christoph Hellwig
I had actually seen the error earlier, but for the setups I got builbot
results moving the code to this new pci-dependent file fixed it. I guess
that didn't went far enough.
On 09/15/2016 07:14 PM, Stephen Rothwell wrote:
Hi Jens,
After merging the block tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/block/nbd.c:884:2: error: unknown field 'map_queue' specified in
initializer
.map_queue = blk_mq_map_queue,
^
/home/sfr/next/n
On Wed, 27 Apr 2016, Michal Marek wrote:
> On 2016-04-26 22:48, Nicolas Pitre wrote:
> > On Wed, 27 Apr 2016, Stephen Rothwell wrote:
> >
> >> Hi Nicolas,
> >>
> >> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre
> >> wrote:
> >>>
> >>> If you can reproduce this build failure, could you
On 2016-04-26 22:48, Nicolas Pitre wrote:
> On Wed, 27 Apr 2016, Stephen Rothwell wrote:
>
>> Hi Nicolas,
>>
>> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre
>> wrote:
>>>
>>> If you can reproduce this build failure, could you try a make mrproper
>>> and attempt it again? I, too, woul
Hi Nicolas,
On Tue, 26 Apr 2016 16:48:44 -0400 (EDT) Nicolas Pitre
wrote:
>
> OK! After digging and diffing through 750 megabytes of make debug logs
> I finally found the explanation. The if_changed directive is useless
> against phony targets.
Thanks for working this out.
> @Stephen: coul
On Wed, 27 Apr 2016, Stephen Rothwell wrote:
> Hi Nicolas,
>
> On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre
> wrote:
> >
> > If you can reproduce this build failure, could you try a make mrproper
> > and attempt it again? I, too, would like to find an explanation and a
> > way to r
Hi Nicolas,
On Tue, 26 Apr 2016 10:40:57 -0400 (EDT) Nicolas Pitre
wrote:
>
> If you can reproduce this build failure, could you try a make mrproper
> and attempt it again? I, too, would like to find an explanation and a
> way to reproduce.
I reset my build tree to commit 9d67df654092 ("Merg
On 04/26/2016 08:40 AM, Nicolas Pitre wrote:
On Tue, 26 Apr 2016, Stephen Rothwell wrote:
Hi Michal,
On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek wrote:
On 2016-04-26 05:38, Stephen Rothwell wrote:
Hi Nicolas,
After merging the block tree, today's linux-next build (powerpc
ppc64_defcon
On Tue, 26 Apr 2016, Stephen Rothwell wrote:
> Hi Michal,
>
> On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek wrote:
> >
> > On 2016-04-26 05:38, Stephen Rothwell wrote:
> > > Hi Nicolas,
> > >
> > > After merging the block tree, today's linux-next build (powerpc
> > > ppc64_defconfig) failed l
Hi Michal,
On Tue, 26 Apr 2016 15:30:01 +0200 Michal Marek wrote:
>
> On 2016-04-26 05:38, Stephen Rothwell wrote:
> > Hi Nicolas,
> >
> > After merging the block tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ERROR: ".blk_queue_write_cache" [drivers/bloc
On 2016-04-26 05:38, Stephen Rothwell wrote:
> Hi Nicolas,
>
> After merging the block tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: ".blk_queue_write_cache" [drivers/block/virtio_blk.ko] undefined!
> ERROR: ".blk_queue_write_cache" [drivers/block/ps3disk
On 12/03/2015 05:42 PM, Christoph Hellwig wrote:
On Thu, Dec 03, 2015 at 12:07:23PM +0100, Matias Bjørling wrote:
What is the reason to keep the nvme_ns internally to the nvme core?
We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing I
have is that it moves a small part o
On Thu, Dec 03, 2015 at 12:07:23PM +0100, Matias Bjørling wrote:
> What is the reason to keep the nvme_ns internally to the nvme core?
>
> We can definitely move ->nsid and the lba_shift into nvm_dev. Only thing I
> have is that it moves a small part of nvme logic into the lightnvm core.
It's a s
On 12/03/2015 11:21 AM, Christoph Hellwig wrote:
On Thu, Dec 03, 2015 at 11:09:03AM +0100, Matias Bjørling wrote:
Similar to this?
For the interface yes. Now just get rid of using nvme_ns entirely -
seems like you just want ns_id and lba_shift, and those should fit
well into nvm_dev I think.
On Thu, Dec 03, 2015 at 11:09:03AM +0100, Matias Bjørling wrote:
> Similar to this?
For the interface yes. Now just get rid of using nvme_ns entirely -
seems like you just want ns_id and lba_shift, and those should fit
well into nvm_dev I think.
--
To unsubscribe from this list: send the line "un
On 12/03/2015 10:57 AM, Christoph Hellwig wrote:
On Thu, Dec 03, 2015 at 10:52:46AM +0100, Matias Bjørling wrote:
The identify geometry command and bad block commands are part of the admin
command set. Surely, as all these take a ns id, they can be moved and be
accessed naturally through the u
On Thu, Dec 03, 2015 at 10:52:46AM +0100, Matias Bjørling wrote:
> The identify geometry command and bad block commands are part of the admin
> command set. Surely, as all these take a ns id, they can be moved and be
> accessed naturally through the user queues.
Nah, these admin commands should
On 12/03/2015 10:06 AM, Christoph Hellwig wrote:
On Thu, Dec 03, 2015 at 09:39:01AM +0100, Matias Bjørling wrote:
A little crazy yes. The reason is that the NVMe admin queues and NVMe user
queues are driven by different request queues. Previously this was patched
up with having two queues in the
On Thu, Dec 03, 2015 at 09:39:01AM +0100, Matias Bjørling wrote:
> A little crazy yes. The reason is that the NVMe admin queues and NVMe user
> queues are driven by different request queues. Previously this was patched
> up with having two queues in the lightnvm core. One for admin and another
>
On 12/02/2015 10:07 PM, Jens Axboe wrote:
On 12/02/2015 09:45 AM, Christoph Hellwig wrote:
Looks like I didn't test with CONFIG_NVM enabled, and neither did
the build bot.
Most of this is really weird crazy shit in the lighnvm support, though.
Struct nvme_ns is a structure for the NVM I/O comm
On Wed, Dec 02, 2015 at 02:27:40PM -0700, Jens Axboe wrote:
> On 12/02/2015 02:14 PM, Keith Busch wrote:
>> On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
>>> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
>>
>> I forgot about this since I've merged this in my repo to f
On 12/02/2015 02:14 PM, Keith Busch wrote:
On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
Christoph, for-4.5/nvme also fails if integrity isn't enabled:
I forgot about this since I've merged this in my repo to fix:
https://lkml.org/lkml/2015/10/26/546
That ok, or should we handl
On Wed, Dec 02, 2015 at 02:07:34PM -0700, Jens Axboe wrote:
> Christoph, for-4.5/nvme also fails if integrity isn't enabled:
I forgot about this since I've merged this in my repo to fix:
https://lkml.org/lkml/2015/10/26/546
That ok, or should we handle this differently?
--
To unsubscribe from th
On 12/02/2015 09:45 AM, Christoph Hellwig wrote:
Looks like I didn't test with CONFIG_NVM enabled, and neither did
the build bot.
Most of this is really weird crazy shit in the lighnvm support, though.
Struct nvme_ns is a structure for the NVM I/O command set, and it has
no business poking into
Looks like I didn't test with CONFIG_NVM enabled, and neither did
the build bot.
Most of this is really weird crazy shit in the lighnvm support, though.
Struct nvme_ns is a structure for the NVM I/O command set, and it has
no business poking into it. Second this commit:
commit 47b3115ae7b799be8
On Tue, Oct 6, 2015 at 9:43 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (arm
> multi_v7_defconfig) failed like this:
>
> drivers/block/loop.c: In function 'lo_rw_aio_complete':
> drivers/block/loop.c:474:2: error: too few arguments to function
Hi Stephen,
[auto build test ERROR on next-20151002 -- if it's inappropriate base, please
ignore]
config: i386-randconfig-x006-201540 (attached as .config)
reproduce:
# save the attached .config to linux build tree
make ARCH=i386
All errors (new ones prefixed by >>):
driver
On Jul 30, 2015, at 12:17 AM, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
>
> drivers/staging/lustre/lustre/llite/../include/obd_support.h:42:0,
> from
> drivers/staging/lustre/lustre/ll
Hi Christoph,
On Thu, 30 Jul 2015 08:19:51 +0200 Christoph Hellwig wrote:
>
> Can you please drop staging and especially lustre from these runs?
One problem with that is that staging is expected to at least build.
and when Linus eventually merges this code in the block tree, he will
do an allmod
On Thu, Jul 30, 2015 at 02:17:13PM +1000, Stephen Rothwell wrote:
> Hi Jens,
>
> After merging the block tree, today's linux-next build (x86_64 allmodconfig)
> failed like this:
Can you please drop staging and especially lustre from these runs?
Conditions of the staging tree are they don't need t
On 11/16/2014 08:44 PM, Stephen Rothwell wrote:
Hi Jens,
After merging the block tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "blk_mq_free_request" [drivers/block/nvme.ko] undefined!
Caused by commit b94ebc3c7a0f ("NVMe: replace blk_put_request() with
blk_mq_fr
1 - 100 of 108 matches
Mail list logo
