* linux-next: build failure after merge of the scsi-mkp tree
@ 2017-12-07 3:57 Stephen Rothwell
2017-12-07 3:59 ` Bart Van Assche
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-12-07 3:57 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux-Next Mailing List, Linux Kernel Mailing List,
Bart Van Assche, Pavel Tikhomirov
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
Caused by commit
ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
I have used the scsi-mkp tree from next-20171206 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 3:57 linux-next: build failure after merge of the scsi-mkp tree Stephen Rothwell
@ 2017-12-07 3:59 ` Bart Van Assche
2017-12-07 4:25 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Bart Van Assche @ 2017-12-07 3:59 UTC (permalink / raw)
To: sfr, martin.petersen; +Cc: linux-kernel, linux-next, ptikhomirov
On Thu, 2017-12-07 at 14:57 +1100, Stephen Rothwell wrote:
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
>
> Caused by commit
>
> ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
>
> I have used the scsi-mkp tree from next-20171206 for today.
Does that mean I'm the first one who added RCU code to the SCSI core? Anyway,
I will fix this and repost the patch series that introduced this build failure.
Sorry for the inconvenience.
Bart.
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 3:59 ` Bart Van Assche
@ 2017-12-07 4:25 ` Stephen Rothwell
2017-12-07 4:42 ` Paul E. McKenney
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-12-07 4:25 UTC (permalink / raw)
To: Bart Van Assche
Cc: Martin K. Petersen, Linus Kernel Mailing List,
Linux Next Mailing List, Pavel Tikhomirov, Paul E. McKenney,
Josh Triplett
Hi Bart,
[cc'ing some RCU people ...]
On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
>
> On Thu, 2017-12-07 at 14:57 +1100, Stephen Rothwell wrote:
> > After merging the scsi-mkp tree, today's linux-next build (x86_64
> > allmodconfig) failed like this:
> >
> > ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> >
> > Caused by commit
> >
> > ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
> >
> > I have used the scsi-mkp tree from next-20171206 for today.
>
> Does that mean I'm the first one who added RCU code to the SCSI core?
The only other uses of init_rcu_head() are in drivers/iommu/intel-svm.c
and kernel/irq/irqdesc.c. destroy_rcu_head() appears to not be used
anywhere ...
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 4:25 ` Stephen Rothwell
@ 2017-12-07 4:42 ` Paul E. McKenney
2017-12-07 17:30 ` Bart Van Assche
0 siblings, 1 reply; 79+ messages in thread
From: Paul E. McKenney @ 2017-12-07 4:42 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Bart Van Assche, Martin K. Petersen, Linus Kernel Mailing List,
Linux Next Mailing List, Pavel Tikhomirov, Josh Triplett
On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote:
> Hi Bart,
>
> [cc'ing some RCU people ...]
>
> On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> >
> > On Thu, 2017-12-07 at 14:57 +1100, Stephen Rothwell wrote:
> > > After merging the scsi-mkp tree, today's linux-next build (x86_64
> > > allmodconfig) failed like this:
> > >
> > > ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > > ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > >
> > > Caused by commit
> > >
> > > ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
> > >
> > > I have used the scsi-mkp tree from next-20171206 for today.
> >
> > Does that mean I'm the first one who added RCU code to the SCSI core?
>
> The only other uses of init_rcu_head() are in drivers/iommu/intel-svm.c
> and kernel/irq/irqdesc.c. destroy_rcu_head() appears to not be used
> anywhere ...
The key point is that Bart appears to be the first to try using them in
a module, for which exports are needed. Does the patch below help?
Thanx, Paul
------------------------------------------------------------------------
commit cde4691a3a4591e7355295dd62610e3262159002
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Dec 6 20:39:38 2017 -0800
rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
Use of init_rcu_head() and destroy_rcu_head() from modules results in
the following build-time error:
ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
to be used by GPL-licensed kernel modules.
Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 8d591d8411fe..4c4d26e9a67b 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
{
debug_object_init(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(init_rcu_head);
void destroy_rcu_head(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(destroy_rcu_head);
static bool rcuhead_is_static_object(void *addr)
{
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 4:42 ` Paul E. McKenney
@ 2017-12-07 17:30 ` Bart Van Assche
2017-12-07 17:40 ` Paul E. McKenney
0 siblings, 1 reply; 79+ messages in thread
From: Bart Van Assche @ 2017-12-07 17:30 UTC (permalink / raw)
To: sfr, paulmck
Cc: josh, linux-kernel, linux-scsi, linux-next, martin.petersen, ptikhomirov
On Wed, 2017-12-06 at 20:42 -0800, Paul E. McKenney wrote:
> On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote:
> > On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
> > > On Thu, 2017-12-07 at 14:57 +1100, Stephen Rothwell wrote:
> > > > After merging the scsi-mkp tree, today's linux-next build (x86_64
> > > > allmodconfig) failed like this:
> > > >
> > > > ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > > > ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > > >
> > > > Caused by commit
> > > >
> > > > ac90420f17c9 ("scsi: core: Ensure that the SCSI error handler gets woken up")
> > > >
> > > > I have used the scsi-mkp tree from next-20171206 for today.
> > >
> > > Does that mean I'm the first one who added RCU code to the SCSI core?
> >
> > The only other uses of init_rcu_head() are in drivers/iommu/intel-svm.c
> > and kernel/irq/irqdesc.c. destroy_rcu_head() appears to not be used
> > anywhere ...
>
> The key point is that Bart appears to be the first to try using them in
> a module, for which exports are needed. Does the patch below help?
>
> Thanx, Paul
>
> ------------------------------------------------------------------------
>
> commit cde4691a3a4591e7355295dd62610e3262159002
> Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> Date: Wed Dec 6 20:39:38 2017 -0800
>
> rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
>
> Use of init_rcu_head() and destroy_rcu_head() from modules results in
> the following build-time error:
>
> ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
>
> This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
> to be used by GPL-licensed kernel modules.
>
> Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
> Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
>
> diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> index 8d591d8411fe..4c4d26e9a67b 100644
> --- a/kernel/rcu/update.c
> +++ b/kernel/rcu/update.c
> @@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
> {
> debug_object_init(head, &rcuhead_debug_descr);
> }
> +EXPORT_SYMBOL_GPL(init_rcu_head);
>
> void destroy_rcu_head(struct rcu_head *head)
> {
> debug_object_free(head, &rcuhead_debug_descr);
> }
> +EXPORT_SYMBOL_GPL(destroy_rcu_head);
>
> static bool rcuhead_is_static_object(void *addr)
> {
(+linux-scsi)
Hello Paul,
How about changing the commit message into "... fixes a build failure with
CONFIG_DEBUG_OBJECTS_RCU_HEAD=y"? Otherwise the above patch looks fine to me
and fixes the reported build failure on my setup.
However, what's not clear to me is through which tree this patch should be
sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
Martin perhaps queue it in his tree for v4.16-rc1?
Thanks,
Bart.
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 17:30 ` Bart Van Assche
@ 2017-12-07 17:40 ` Paul E. McKenney
2017-12-07 20:34 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Paul E. McKenney @ 2017-12-07 17:40 UTC (permalink / raw)
To: Bart Van Assche
Cc: sfr, josh, linux-kernel, linux-scsi, linux-next, martin.petersen,
ptikhomirov
On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> On Wed, 2017-12-06 at 20:42 -0800, Paul E. McKenney wrote:
> > On Thu, Dec 07, 2017 at 03:25:21PM +1100, Stephen Rothwell wrote:
> > > On Thu, 7 Dec 2017 03:59:30 +0000 Bart Van Assche <Bart.VanAssche@wdc.com> wrote:
[ . . . ]
> > commit cde4691a3a4591e7355295dd62610e3262159002
> > Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> > Date: Wed Dec 6 20:39:38 2017 -0800
> >
> > rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
> >
> > Use of init_rcu_head() and destroy_rcu_head() from modules results in
> > the following build-time error:
> >
> > ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> > ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
> >
> > This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
> > to be used by GPL-licensed kernel modules.
> >
> > Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
> > Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
> > index 8d591d8411fe..4c4d26e9a67b 100644
> > --- a/kernel/rcu/update.c
> > +++ b/kernel/rcu/update.c
> > @@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
> > {
> > debug_object_init(head, &rcuhead_debug_descr);
> > }
> > +EXPORT_SYMBOL_GPL(init_rcu_head);
> >
> > void destroy_rcu_head(struct rcu_head *head)
> > {
> > debug_object_free(head, &rcuhead_debug_descr);
> > }
> > +EXPORT_SYMBOL_GPL(destroy_rcu_head);
> >
> > static bool rcuhead_is_static_object(void *addr)
> > {
>
> (+linux-scsi)
>
> Hello Paul,
>
> How about changing the commit message into "... fixes a build failure with
> CONFIG_DEBUG_OBJECTS_RCU_HEAD=y"? Otherwise the above patch looks fine to me
> and fixes the reported build failure on my setup.
I have updated it as shown below.
> However, what's not clear to me is through which tree this patch should be
> sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> Martin perhaps queue it in his tree for v4.16-rc1?
I have to defer to you guys on that one. Left to myself, I will just
push it into the next merge window (as opposed to using my normal process,
which at this point would get it into the one following).
So please let me know how you would like to proceed.
Thanx, Paul
------------------------------------------------------------------------
commit 193dffdf4354f14b4f3369a85128817e5ba74e58
Author: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
Date: Wed Dec 6 20:39:38 2017 -0800
rcu: Export init_rcu_head() and destroy_rcu_head() to GPL modules
Use of init_rcu_head() and destroy_rcu_head() from modules results in
the following build-time error with CONFIG_DEBUG_OBJECTS_RCU_HEAD=y:
ERROR: "init_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
ERROR: "destroy_rcu_head" [drivers/scsi/scsi_mod.ko] undefined!
This commit therefore adds EXPORT_SYMBOL_GPL() for each to allow them
to be used by GPL-licensed kernel modules.
Reported-by: Bart Van Assche <Bart.VanAssche@wdc.com>
Reported-by: Stephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
diff --git a/kernel/rcu/update.c b/kernel/rcu/update.c
index 8d591d8411fe..4c4d26e9a67b 100644
--- a/kernel/rcu/update.c
+++ b/kernel/rcu/update.c
@@ -422,11 +422,13 @@ void init_rcu_head(struct rcu_head *head)
{
debug_object_init(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(init_rcu_head);
void destroy_rcu_head(struct rcu_head *head)
{
debug_object_free(head, &rcuhead_debug_descr);
}
+EXPORT_SYMBOL_GPL(destroy_rcu_head);
static bool rcuhead_is_static_object(void *addr)
{
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 17:40 ` Paul E. McKenney
@ 2017-12-07 20:34 ` Stephen Rothwell
2017-12-07 21:10 ` Paul E. McKenney
2017-12-07 21:11 ` Martin K. Petersen
0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2017-12-07 20:34 UTC (permalink / raw)
To: Paul E. McKenney
Cc: Bart Van Assche, josh, linux-kernel, linux-scsi, linux-next,
martin.petersen, ptikhomirov
Hi all,
On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
>
> On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> > However, what's not clear to me is through which tree this patch should be
> > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> > Martin perhaps queue it in his tree for v4.16-rc1?
>
> I have to defer to you guys on that one. Left to myself, I will just
> push it into the next merge window (as opposed to using my normal process,
> which at this point would get it into the one following).
>
> So please let me know how you would like to proceed.
Clearly, it needs to go via Martin's tree as otherwise his tree will
not build in some circumstances ... or if it going to cause problems
for Paul, then it should be in a separate non-rebasing branch (probably
of Paul's tree) that is merged into Pauls main branch and Marin's tree.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 20:34 ` Stephen Rothwell
@ 2017-12-07 21:10 ` Paul E. McKenney
2017-12-07 21:11 ` Martin K. Petersen
1 sibling, 0 replies; 79+ messages in thread
From: Paul E. McKenney @ 2017-12-07 21:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Bart Van Assche, josh, linux-kernel, linux-scsi, linux-next,
martin.petersen, ptikhomirov
On Fri, Dec 08, 2017 at 07:34:39AM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Thu, 7 Dec 2017 09:40:38 -0800 "Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> >
> > On Thu, Dec 07, 2017 at 05:30:03PM +0000, Bart Van Assche wrote:
> > > However, what's not clear to me is through which tree this patch should be
> > > sent to Linus? Should the above patch be sent as a v4.15-rc fix or should
> > > Martin perhaps queue it in his tree for v4.16-rc1?
> >
> > I have to defer to you guys on that one. Left to myself, I will just
> > push it into the next merge window (as opposed to using my normal process,
> > which at this point would get it into the one following).
> >
> > So please let me know how you would like to proceed.
>
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.
It is unlikely to cause problems, so please let it go up where convenient.
Just please let me know.
Thanx, Paul
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 20:34 ` Stephen Rothwell
2017-12-07 21:10 ` Paul E. McKenney
@ 2017-12-07 21:11 ` Martin K. Petersen
2017-12-08 1:00 ` Martin K. Petersen
1 sibling, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2017-12-07 21:11 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Paul E. McKenney, Bart Van Assche, josh, linux-kernel,
linux-scsi, linux-next, martin.petersen, ptikhomirov
Stephen,
>> I have to defer to you guys on that one. Left to myself, I will just
>> push it into the next merge window (as opposed to using my normal
>> process, which at this point would get it into the one following).
>>
>> So please let me know how you would like to proceed.
>
> Clearly, it needs to go via Martin's tree as otherwise his tree will
> not build in some circumstances ... or if it going to cause problems
> for Paul, then it should be in a separate non-rebasing branch (probably
> of Paul's tree) that is merged into Pauls main branch and Marin's tree.
I'm perfectly OK with taking it through the SCSI tree. Probably the path
of least resistance.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-07 21:11 ` Martin K. Petersen
@ 2017-12-08 1:00 ` Martin K. Petersen
2017-12-11 17:43 ` Paul E. McKenney
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2017-12-08 1:00 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Stephen Rothwell, Paul E. McKenney, Bart Van Assche, josh,
linux-kernel, linux-scsi, linux-next, ptikhomirov
> I'm perfectly OK with taking it through the SCSI tree. Probably the
> path of least resistance.
Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-12-08 1:00 ` Martin K. Petersen
@ 2017-12-11 17:43 ` Paul E. McKenney
0 siblings, 0 replies; 79+ messages in thread
From: Paul E. McKenney @ 2017-12-11 17:43 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Stephen Rothwell, Bart Van Assche, josh, linux-kernel,
linux-scsi, linux-next, ptikhomirov
On Thu, Dec 07, 2017 at 08:00:50PM -0500, Martin K. Petersen wrote:
>
> > I'm perfectly OK with taking it through the SCSI tree. Probably the
> > path of least resistance.
>
> Applied to 4.16/scsi-queue and rebased so it sits before Bart's patch.
Thank you! I have removed this patch from -rcu.
Thanx, Paul
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2024-04-12 5:46 Stephen Rothwell
2024-04-12 6:09 ` Christoph Hellwig
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2024-04-12 5:46 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Christoph Hellwig, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (arm
multi_v7_defconfig) failed like this:
drivers/usb/storage/uas.c: In function 'uas_slave_alloc':
drivers/usb/storage/uas.c:826:17: error: implicit declaration of function 'blk_queue_max_hw_sectors'; did you mean 'queue_max_hw_sectors'? [-Werror=implicit-function-declaration]
826 | blk_queue_max_hw_sectors(sdev->request_queue, 64);
| ^~~~~~~~~~~~~~~~~~~~~~~~
| queue_max_hw_sectors
cc1: some warnings being treated as errors
Caused by commit
a2ad002485c4 ("scsi: block: Remove now unused queue limits helpers")
I have used the scsi-mkp tree from next-20240411 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2024-04-12 5:46 Stephen Rothwell
@ 2024-04-12 6:09 ` Christoph Hellwig
2024-04-12 10:22 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Christoph Hellwig @ 2024-04-12 6:09 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Christoph Hellwig, Linux Kernel Mailing List,
Linux Next Mailing List
looks like the scsi tree failed to pick up:
uas: switch to using ->device_configure to configure queue limits
somehow, which was the commit just before the one removing
blk_queue_max_hw_sectors in the series.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2024-04-12 6:09 ` Christoph Hellwig
@ 2024-04-12 10:22 ` Martin K. Petersen
2024-04-12 10:44 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2024-04-12 10:22 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Stephen Rothwell, Martin K. Petersen, Linux Kernel Mailing List,
Linux Next Mailing List
Christoph,
> looks like the scsi tree failed to pick up:
>
> uas: switch to using ->device_configure to configure queue limits
>
> somehow, which was the commit just before the one removing
> blk_queue_max_hw_sectors in the series.
The v3.1 patch confused both b4 and patchwork. I'll get it fixed up.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2024-03-27 2:45 Stephen Rothwell
2024-03-28 0:18 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2024-03-27 2:45 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Igor Pylypiv, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 749 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (arm64
defconfig) failed like this:
aarch64-linux-gnu-ld: drivers/ata/libata-sata.o:drivers/ata/libata-sata.c:900: multiple definition of `dev_attr_ncq_prio_supported'; drivers/scsi/libsas/sas_ata.o:drivers/scsi/libsas/sas_ata.c:984: first defined here
aarch64-linux-gnu-ld: drivers/ata/libata-sata.o:drivers/ata/libata-sata.c:1026: multiple definition of `dev_attr_ncq_prio_enable'; drivers/scsi/libsas/sas_ata.o:drivers/scsi/libsas/sas_ata.c:1022: first defined here
Caused by commit
b4d3ddd2df75 ("scsi: libsas: Define NCQ Priority sysfs attributes for SATA devices")
I have used the scsi-mkp tree from next-20240326 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2024-03-27 2:45 Stephen Rothwell
@ 2024-03-28 0:18 ` Martin K. Petersen
0 siblings, 0 replies; 79+ messages in thread
From: Martin K. Petersen @ 2024-03-28 0:18 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Igor Pylypiv, Linux Kernel Mailing List,
Linux Next Mailing List
Stephen,
> Caused by commit
>
> b4d3ddd2df75 ("scsi: libsas: Define NCQ Priority sysfs attributes for SATA devices")
>
> I have used the scsi-mkp tree from next-20240326 for today.
Should now be addressed by commit 0ff10cb7f818 ("scsi: libsas: Fix
declaration of ncq priority attributes").
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2023-08-22 5:32 Stephen Rothwell
2023-08-23 22:55 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2023-08-22 5:32 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Manish Rangankar, Nilesh Javali, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: modpost: "nvme_fc_rcv_ls_req" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined!
Caused by commit
875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe")
# CONFIG_NVME_FC is not set
I have used the scsi-mkp tree from next-20230821 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2023-08-22 5:32 Stephen Rothwell
@ 2023-08-23 22:55 ` Stephen Rothwell
2023-08-23 22:59 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2023-08-23 22:55 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Manish Rangankar, Nilesh Javali, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 561 bytes --]
Hi all,
On Tue, 22 Aug 2023 15:32:23 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: modpost: "nvme_fc_rcv_ls_req" [drivers/scsi/qla2xxx/qla2xxx.ko] undefined!
>
> Caused by commit
>
> 875386b98857 ("scsi: qla2xxx: Add Unsolicited LS Request and Response Support for NVMe")
>
> # CONFIG_NVME_FC is not set
>
> I have used the scsi-mkp tree from next-20230821 for today.
Ping?
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2023-08-23 22:55 ` Stephen Rothwell
@ 2023-08-23 22:59 ` Martin K. Petersen
0 siblings, 0 replies; 79+ messages in thread
From: Martin K. Petersen @ 2023-08-23 22:59 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Manish Rangankar, Nilesh Javali,
Linux Kernel Mailing List, Linux Next Mailing List
Stephen,
>> I have used the scsi-mkp tree from next-20230821 for today.
>
> Ping?
Since it doesn't appear that a fix is imminent I'm going to drop this
series.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2023-06-15 3:43 Stephen Rothwell
2023-06-15 4:19 ` Damien Le Moal
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2023-06-15 3:43 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Damien Le Moal, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 786 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from <command-line>:
./usr/include/linux/ioprio.h:107:8: error: unknown type name '__always_inline'
107 | static __always_inline __u16 ioprio_value(int class, int level, int hint)
| ^~~~~~~~~~~~~~~
./usr/include/linux/ioprio.h:107:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ioprio_value'
107 | static __always_inline __u16 ioprio_value(int class, int level, int hint)
| ^~~~~~~~~~~~
Caused by commit
bfaaaa3d9d09 ("scsi: block: Improve ioprio value validity checks")
I have used the scsi-mkp tree from next-20230614 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2023-06-15 3:43 Stephen Rothwell
@ 2023-06-15 4:19 ` Damien Le Moal
2023-06-16 16:51 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Damien Le Moal @ 2023-06-15 4:19 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 6/15/23 12:43, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from <command-line>:
> ./usr/include/linux/ioprio.h:107:8: error: unknown type name '__always_inline'
> 107 | static __always_inline __u16 ioprio_value(int class, int level, int hint)
> | ^~~~~~~~~~~~~~~
> ./usr/include/linux/ioprio.h:107:30: error: expected '=', ',', ';', 'asm' or '__attribute__' before 'ioprio_value'
> 107 | static __always_inline __u16 ioprio_value(int class, int level, int hint)
> | ^~~~~~~~~~~~
>
> Caused by commit
>
> bfaaaa3d9d09 ("scsi: block: Improve ioprio value validity checks")
>
> I have used the scsi-mkp tree from next-20230614 for today.
Not sure how this is triggered as I have no error compiling (using gcc)...
Martin,
I believe this should fix the issue:
diff --git a/include/uapi/linux/ioprio.h b/include/uapi/linux/ioprio.h
index 7310449c0178..92a769b9786d 100644
--- a/include/uapi/linux/ioprio.h
+++ b/include/uapi/linux/ioprio.h
@@ -2,6 +2,9 @@
#ifndef _UAPI_LINUX_IOPRIO_H
#define _UAPI_LINUX_IOPRIO_H
+#include <linux/stddef.h>
+#include <linux/types.h>
+
/*
* Gives us 8 prio classes with 13-bits of data for each class
*/
Could you squash this fix in the ioprio patch you just queued ? Or I can send a fix.
Thanks !
--
Damien Le Moal
Western Digital Research
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2023-06-15 4:19 ` Damien Le Moal
@ 2023-06-16 16:51 ` Martin K. Petersen
0 siblings, 0 replies; 79+ messages in thread
From: Martin K. Petersen @ 2023-06-16 16:51 UTC (permalink / raw)
To: Damien Le Moal
Cc: Stephen Rothwell, Martin K. Petersen, Linux Kernel Mailing List,
Linux Next Mailing List
Damien,
>> bfaaaa3d9d09 ("scsi: block: Improve ioprio value validity checks")
>>
>> I have used the scsi-mkp tree from next-20230614 for today.
>
> I believe this should fix the issue:
Now fixed up.
Thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2023-01-16 2:24 Stephen Rothwell
2023-01-16 17:55 ` Mike Christie
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2023-01-16 2:24 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Mike Christie, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1181 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/cxlflash/superpipe.c: In function 'read_cap16':
drivers/scsi/cxlflash/superpipe.c:364:65: error: incompatible type for argument 8 of 'scsi_execute_cmd'
364 | CMD_BUFSIZE, to, CMD_RETRIES, exec_args);
| ^~~~~~~~~
| |
| struct scsi_exec_args
In file included from include/scsi/scsi_cmnd.h:12,
from drivers/scsi/cxlflash/superpipe.c:20:
include/scsi/scsi_device.h:471:51: note: expected 'const struct scsi_exec_args *' but argument is of type 'struct scsi_exec_args'
471 | const struct scsi_exec_args *args);
| ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~
Caused by commit
606375f1a869 ("scsi: cxlflash: Convert to scsi_execute_cmd()")
I have used the scsi-mkp tree from next-20230113 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2023-01-16 2:24 Stephen Rothwell
@ 2023-01-16 17:55 ` Mike Christie
2023-01-16 18:07 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Mike Christie @ 2023-01-16 17:55 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 1/15/23 8:24 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/cxlflash/superpipe.c: In function 'read_cap16':
> drivers/scsi/cxlflash/superpipe.c:364:65: error: incompatible type for argument 8 of 'scsi_execute_cmd'
> 364 | CMD_BUFSIZE, to, CMD_RETRIES, exec_args);
> | ^~~~~~~~~
Sorry and thanks. I'll send an updated patchset.
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2022-08-24 1:50 Stephen Rothwell
2022-08-29 4:54 ` Stephen Rothwell
2022-08-30 2:11 ` Martin K. Petersen
0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2022-08-24 1:50 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Sreekanth Reddy, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3565 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from arch/x86/include/asm/cpumask.h:5,
from arch/x86/include/asm/msr.h:11,
from arch/x86/include/asm/processor.h:22,
from arch/x86/include/asm/cpufeature.h:5,
from arch/x86/include/asm/thread_info.h:53,
from include/linux/thread_info.h:60,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:55,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/highmem.h:5,
from include/linux/bvec.h:10,
from include/linux/blk_types.h:10,
from include/linux/blkdev.h:9,
from drivers/scsi/mpi3mr/mpi3mr.h:13,
from drivers/scsi/mpi3mr/mpi3mr_transport.c:10:
drivers/scsi/mpi3mr/mpi3mr_transport.c: In function 'mpi3mr_update_mr_sas_port':
include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
40 | val = *addr & GENMASK(size - 1, offset);
| ^~~~~
drivers/scsi/mpi3mr/mpi3mr_transport.c:1610:27: note: while referencing 'phys_to_be_added'
1610 | u32 phy_mask_xor, phys_to_be_added, phys_to_be_removed;
| ^~~~~~~~~~~~~~~~
In file included from include/linux/bitmap.h:9,
from include/linux/cpumask.h:12,
from arch/x86/include/asm/cpumask.h:5,
from arch/x86/include/asm/msr.h:11,
from arch/x86/include/asm/processor.h:22,
from arch/x86/include/asm/cpufeature.h:5,
from arch/x86/include/asm/thread_info.h:53,
from include/linux/thread_info.h:60,
from arch/x86/include/asm/preempt.h:7,
from include/linux/preempt.h:78,
from include/linux/spinlock.h:55,
from include/linux/wait.h:9,
from include/linux/wait_bit.h:8,
from include/linux/fs.h:6,
from include/linux/highmem.h:5,
from include/linux/bvec.h:10,
from include/linux/blk_types.h:10,
from include/linux/blkdev.h:9,
from drivers/scsi/mpi3mr/mpi3mr.h:13,
from drivers/scsi/mpi3mr/mpi3mr_transport.c:10:
include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
40 | val = *addr & GENMASK(size - 1, offset);
| ^~~~~
drivers/scsi/mpi3mr/mpi3mr_transport.c:1610:45: note: while referencing 'phys_to_be_removed'
1610 | u32 phy_mask_xor, phys_to_be_added, phys_to_be_removed;
| ^~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Caused by commit
434726c4b89c ("scsi: mpi3mr: Refresh SAS ports during soft reset")
I have used the scsi-mkp tree from next-20220823 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2022-08-24 1:50 Stephen Rothwell
@ 2022-08-29 4:54 ` Stephen Rothwell
2022-08-30 2:11 ` Martin K. Petersen
1 sibling, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2022-08-29 4:54 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Sreekanth Reddy, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 3813 bytes --]
Hi all,
On Wed, 24 Aug 2022 11:50:57 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> In file included from include/linux/bitmap.h:9,
> from include/linux/cpumask.h:12,
> from arch/x86/include/asm/cpumask.h:5,
> from arch/x86/include/asm/msr.h:11,
> from arch/x86/include/asm/processor.h:22,
> from arch/x86/include/asm/cpufeature.h:5,
> from arch/x86/include/asm/thread_info.h:53,
> from include/linux/thread_info.h:60,
> from arch/x86/include/asm/preempt.h:7,
> from include/linux/preempt.h:78,
> from include/linux/spinlock.h:55,
> from include/linux/wait.h:9,
> from include/linux/wait_bit.h:8,
> from include/linux/fs.h:6,
> from include/linux/highmem.h:5,
> from include/linux/bvec.h:10,
> from include/linux/blk_types.h:10,
> from include/linux/blkdev.h:9,
> from drivers/scsi/mpi3mr/mpi3mr.h:13,
> from drivers/scsi/mpi3mr/mpi3mr_transport.c:10:
> drivers/scsi/mpi3mr/mpi3mr_transport.c: In function 'mpi3mr_update_mr_sas_port':
> include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
> 40 | val = *addr & GENMASK(size - 1, offset);
> | ^~~~~
> drivers/scsi/mpi3mr/mpi3mr_transport.c:1610:27: note: while referencing 'phys_to_be_added'
> 1610 | u32 phy_mask_xor, phys_to_be_added, phys_to_be_removed;
> | ^~~~~~~~~~~~~~~~
> In file included from include/linux/bitmap.h:9,
> from include/linux/cpumask.h:12,
> from arch/x86/include/asm/cpumask.h:5,
> from arch/x86/include/asm/msr.h:11,
> from arch/x86/include/asm/processor.h:22,
> from arch/x86/include/asm/cpufeature.h:5,
> from arch/x86/include/asm/thread_info.h:53,
> from include/linux/thread_info.h:60,
> from arch/x86/include/asm/preempt.h:7,
> from include/linux/preempt.h:78,
> from include/linux/spinlock.h:55,
> from include/linux/wait.h:9,
> from include/linux/wait_bit.h:8,
> from include/linux/fs.h:6,
> from include/linux/highmem.h:5,
> from include/linux/bvec.h:10,
> from include/linux/blk_types.h:10,
> from include/linux/blkdev.h:9,
> from drivers/scsi/mpi3mr/mpi3mr.h:13,
> from drivers/scsi/mpi3mr/mpi3mr_transport.c:10:
> include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
> 40 | val = *addr & GENMASK(size - 1, offset);
> | ^~~~~
> drivers/scsi/mpi3mr/mpi3mr_transport.c:1610:45: note: while referencing 'phys_to_be_removed'
> 1610 | u32 phy_mask_xor, phys_to_be_added, phys_to_be_removed;
> | ^~~~~~~~~~~~~~~~~~
> cc1: all warnings being treated as errors
>
> Caused by commit
>
> 434726c4b89c ("scsi: mpi3mr: Refresh SAS ports during soft reset")
>
> I have used the scsi-mkp tree from next-20220823 for today.
I am still seeing this failure.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2022-08-24 1:50 Stephen Rothwell
2022-08-29 4:54 ` Stephen Rothwell
@ 2022-08-30 2:11 ` Martin K. Petersen
1 sibling, 0 replies; 79+ messages in thread
From: Martin K. Petersen @ 2022-08-30 2:11 UTC (permalink / raw)
To: Sreekanth Reddy
Cc: Martin K. Petersen, Linux Kernel Mailing List,
Linux Next Mailing List, Stephen Rothwell
> drivers/scsi/mpi3mr/mpi3mr_transport.c: In function 'mpi3mr_update_mr_sas_port':
> include/linux/find.h:40:23: error: array subscript 'long unsigned int[0]' is partly outside array bounds of 'u32[1]' {aka 'unsigned int[1]'} [-Werror=array-bounds]
> 40 | val = *addr & GENMASK(size - 1, offset);
> | ^~~~~
Sreekanth: Please fix, thanks!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2022-04-27 3:38 Stephen Rothwell
2022-04-27 7:40 ` Sumit Saxena
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2022-04-27 3:38 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Sumit Saxena, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 21867 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from <command-line>:
./usr/include/scsi/scsi_bsg_mpi3mr.h:96:9: error: unknown type name '__le32'
96 | __le32 information_length;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:97:9: error: unknown type name 'u8'
97 | u8 driver_signature[12];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:98:9: error: unknown type name 'u8'
98 | u8 os_name[16];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:99:9: error: unknown type name 'u8'
99 | u8 os_version[12];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:100:9: error: unknown type name 'u8'
100 | u8 driver_name[20];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:101:9: error: unknown type name 'u8'
101 | u8 driver_version[32];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:102:9: error: unknown type name 'u8'
102 | u8 driver_release_date[20];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:103:9: error: unknown type name '__le32'
103 | __le32 driver_capabilities;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:128:9: error: unknown type name 'uint32_t'
128 | uint32_t adp_type;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:129:9: error: unknown type name 'uint32_t'
129 | uint32_t rsvd1;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:130:9: error: unknown type name 'uint32_t'
130 | uint32_t pci_dev_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:131:9: error: unknown type name 'uint32_t'
131 | uint32_t pci_dev_hw_rev;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:132:9: error: unknown type name 'uint32_t'
132 | uint32_t pci_subsys_dev_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:133:9: error: unknown type name 'uint32_t'
133 | uint32_t pci_subsys_ven_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:134:9: error: unknown type name 'uint32_t'
134 | uint32_t pci_dev:5;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:135:9: error: unknown type name 'uint32_t'
135 | uint32_t pci_func:3;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:136:9: error: unknown type name 'uint32_t'
136 | uint32_t pci_bus:8;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:137:9: error: unknown type name 'uint16_t'
137 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:138:9: error: unknown type name 'uint32_t'
138 | uint32_t pci_seg_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:139:9: error: unknown type name 'uint32_t'
139 | uint32_t app_intfc_ver;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:140:9: error: unknown type name 'uint8_t'
140 | uint8_t adp_state;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:141:9: error: unknown type name 'uint8_t'
141 | uint8_t rsvd3;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:142:9: error: unknown type name 'uint16_t'
142 | uint16_t rsvd4;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:143:9: error: unknown type name 'uint32_t'
143 | uint32_t rsvd5[2];
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:156:9: error: unknown type name 'uint8_t'
156 | uint8_t reset_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:157:9: error: unknown type name 'uint8_t'
157 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:158:9: error: unknown type name 'uint16_t'
158 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:169:9: error: unknown type name 'uint16_t'
169 | uint16_t change_count;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:170:9: error: unknown type name 'uint16_t'
170 | uint16_t rsvd;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:185:9: error: unknown type name 'uint16_t'
185 | uint16_t handle;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:186:9: error: unknown type name 'uint16_t'
186 | uint16_t perst_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:187:9: error: unknown type name 'uint32_t'
187 | uint32_t target_id;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:188:9: error: unknown type name 'uint8_t'
188 | uint8_t bus_id;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:189:9: error: unknown type name 'uint8_t'
189 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:190:9: error: unknown type name 'uint16_t'
190 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:203:9: error: unknown type name 'uint16_t'
203 | uint16_t num_devices;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:204:9: error: unknown type name 'uint16_t'
204 | uint16_t rsvd1;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:205:9: error: unknown type name 'uint32_t'
205 | uint32_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:218:9: error: unknown type name 'uint16_t'
218 | uint16_t max_entries;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:219:9: error: unknown type name 'uint16_t'
219 | uint16_t rsvd;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:231:9: error: unknown type name 'uint16_t'
231 | uint16_t pel_locale;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:232:9: error: unknown type name 'uint8_t'
232 | uint8_t pel_class;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:233:9: error: unknown type name 'uint8_t'
233 | uint8_t rsvd;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:246:9: error: unknown type name 'uint8_t'
246 | uint8_t valid_entry;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:247:9: error: unknown type name 'uint8_t'
247 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:248:9: error: unknown type name 'uint16_t'
248 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:249:9: error: unknown type name 'uint8_t'
249 | uint8_t data[1]; /* Variable length Array */
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:277:9: error: unknown type name 'uint8_t'
277 | uint8_t buf_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:278:9: error: unknown type name 'uint8_t'
278 | uint8_t status;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:279:9: error: unknown type name 'uint8_t'
279 | uint8_t trigger_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:280:9: error: unknown type name 'uint8_t'
280 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:281:9: error: unknown type name 'uint16_t'
281 | uint16_t size;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:282:9: error: unknown type name 'uint16_t'
282 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:283:9: error: unknown type name 'uint64_t'
283 | uint64_t trigger_data;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:284:9: error: unknown type name 'uint32_t'
284 | uint32_t rsvd3;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:285:9: error: unknown type name 'uint32_t'
285 | uint32_t rsvd4;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:303:9: error: unknown type name 'uint8_t'
303 | uint8_t num_hdb_types;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:304:9: error: unknown type name 'uint8_t'
304 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:305:9: error: unknown type name 'uint16_t'
305 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:306:9: error: unknown type name 'uint32_t'
306 | uint32_t rsvd3;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:319:9: error: unknown type name 'uint8_t'
319 | uint8_t buf_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:320:9: error: unknown type name 'uint8_t'
320 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:321:9: error: unknown type name 'uint16_t'
321 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:335:9: error: unknown type name 'uint8_t'
335 | uint8_t buf_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:336:9: error: unknown type name 'uint8_t'
336 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:337:9: error: unknown type name 'uint16_t'
337 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:338:9: error: unknown type name 'uint32_t'
338 | uint32_t start_offset;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:339:9: error: unknown type name 'uint32_t'
339 | uint32_t length;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:351:9: error: unknown type name 'uint8_t'
351 | uint8_t page_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:352:9: error: unknown type name 'uint8_t'
352 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:353:9: error: unknown type name 'uint16_t'
353 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:365:9: error: unknown type name 'uint8_t'
365 | uint8_t mrioc_id;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:366:9: error: unknown type name 'uint8_t'
366 | uint8_t opcode;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:367:9: error: unknown type name 'uint16_t'
367 | uint16_t rsvd1;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:368:9: error: unknown type name 'uint32_t'
368 | uint32_t rsvd2[4];
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:380:9: error: unknown type name 'uint8_t'
380 | uint8_t mpi_reply_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:381:9: error: unknown type name 'uint8_t'
381 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:382:9: error: unknown type name 'uint16_t'
382 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:383:9: error: unknown type name 'uint8_t'
383 | uint8_t reply_buf[1];
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:396:9: error: unknown type name 'uint8_t'
396 | uint8_t buf_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:397:9: error: unknown type name 'uint8_t'
397 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:398:9: error: unknown type name 'uint16_t'
398 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:399:9: error: unknown type name 'uint32_t'
399 | uint32_t buf_len;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:412:9: error: unknown type name 'uint8_t'
412 | uint8_t num_of_entries;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:413:9: error: unknown type name 'uint8_t'
413 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:414:9: error: unknown type name 'uint16_t'
414 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:415:9: error: unknown type name 'uint32_t'
415 | uint32_t rsvd3;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:428:9: error: unknown type name 'uint8_t'
428 | uint8_t mrioc_id;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:429:9: error: unknown type name 'uint8_t'
429 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:430:9: error: unknown type name 'uint16_t'
430 | uint16_t timeout;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:431:9: error: unknown type name 'uint32_t'
431 | uint32_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:446:9: error: unknown type name 'uint8_t'
446 | uint8_t cmd_type;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:447:9: error: unknown type name 'uint8_t'
447 | uint8_t rsvd1;
| ^~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:448:9: error: unknown type name 'uint16_t'
448 | uint16_t rsvd2;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:449:9: error: unknown type name 'uint32_t'
449 | uint32_t rsvd3;
| ^~~~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:463:9: error: unknown type name '__le16'
463 | __le16 host_tag;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:464:9: error: unknown type name 'u8'
464 | u8 ioc_use_only02;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:465:9: error: unknown type name 'u8'
465 | u8 function;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:466:9: error: unknown type name '__le16'
466 | __le16 ioc_use_only04;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:467:9: error: unknown type name 'u8'
467 | u8 ioc_use_only06;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:468:9: error: unknown type name 'u8'
468 | u8 msg_flags;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:469:9: error: unknown type name '__le16'
469 | __le16 change_count;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:470:9: error: unknown type name '__le16'
470 | __le16 dev_handle;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:471:9: error: unknown type name '__le16'
471 | __le16 encapsulated_command_length;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:472:9: error: unknown type name '__le16'
472 | __le16 flags;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:473:9: error: unknown type name '__le32'
473 | __le32 data_length;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:474:9: error: unknown type name '__le32'
474 | __le32 reserved14[3];
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:475:9: error: unknown type name '__le32'
475 | __le32 command[MPI3_NVME_ENCAP_CMD_MAX];
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:479:9: error: unknown type name '__le16'
479 | __le16 host_tag;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:480:9: error: unknown type name 'u8'
480 | u8 ioc_use_only02;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:481:9: error: unknown type name 'u8'
481 | u8 function;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:482:9: error: unknown type name '__le16'
482 | __le16 ioc_use_only04;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:483:9: error: unknown type name 'u8'
483 | u8 ioc_use_only06;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:484:9: error: unknown type name 'u8'
484 | u8 msg_flags;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:485:9: error: unknown type name '__le16'
485 | __le16 ioc_use_only08;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:486:9: error: unknown type name '__le16'
486 | __le16 ioc_status;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:487:9: error: unknown type name '__le32'
487 | __le32 ioc_log_info;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:488:9: error: unknown type name '__le32'
488 | __le32 nvme_completion_entry[4];
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:501:9: error: unknown type name '__le16'
501 | __le16 host_tag;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:502:9: error: unknown type name 'u8'
502 | u8 ioc_use_only02;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:503:9: error: unknown type name 'u8'
503 | u8 function;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:504:9: error: unknown type name '__le16'
504 | __le16 ioc_use_only04;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:505:9: error: unknown type name 'u8'
505 | u8 ioc_use_only06;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:506:9: error: unknown type name 'u8'
506 | u8 msg_flags;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:507:9: error: unknown type name '__le16'
507 | __le16 change_count;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:508:9: error: unknown type name '__le16'
508 | __le16 dev_handle;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:509:9: error: unknown type name '__le16'
509 | __le16 task_host_tag;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:510:9: error: unknown type name 'u8'
510 | u8 task_type;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:511:9: error: unknown type name 'u8'
511 | u8 reserved0f;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:512:9: error: unknown type name '__le16'
512 | __le16 task_request_queue_id;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:513:9: error: unknown type name '__le16'
513 | __le16 reserved12;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:514:9: error: unknown type name '__le32'
514 | __le32 reserved14;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:515:9: error: unknown type name 'u8'
515 | u8 lun[8];
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:530:9: error: unknown type name '__le16'
530 | __le16 host_tag;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:531:9: error: unknown type name 'u8'
531 | u8 ioc_use_only02;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:532:9: error: unknown type name 'u8'
532 | u8 function;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:533:9: error: unknown type name '__le16'
533 | __le16 ioc_use_only04;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:534:9: error: unknown type name 'u8'
534 | u8 ioc_use_only06;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:535:9: error: unknown type name 'u8'
535 | u8 msg_flags;
| ^~
./usr/include/scsi/scsi_bsg_mpi3mr.h:536:9: error: unknown type name '__le16'
536 | __le16 ioc_use_only08;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:537:9: error: unknown type name '__le16'
537 | __le16 ioc_status;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:538:9: error: unknown type name '__le32'
538 | __le32 ioc_log_info;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:539:9: error: unknown type name '__le32'
539 | __le32 termination_count;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:540:9: error: unknown type name '__le32'
540 | __le32 response_data;
| ^~~~~~
./usr/include/scsi/scsi_bsg_mpi3mr.h:541:9: error: unknown type name '__le32'
541 | __le32 reserved18;
| ^~~~~~
Caused by commit
a212ebe7d4b1 ("scsi: mpi3mr: Add support for driver commands")
455aac4f7a13 ("scsi: mpi3mr: Move data structures/definitions from MPI headers to uapi header")
I used the scsi-mkp tree from next-20220426 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2022-04-27 3:38 Stephen Rothwell
@ 2022-04-27 7:40 ` Sumit Saxena
2022-04-27 8:28 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Sumit Saxena @ 2022-04-27 7:40 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1079 bytes --]
On Wed, Apr 27, 2022 at 9:08 AM Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
Hi Stephen,
Could you please try if the below patch fixes this build failure:
From a78f9deaab456948b123c39950dff6f85b13875a Mon Sep 17 00:00:00 2001
From: Sumit Saxena <sumit.saxena@broadcom.com>
Date: Wed, 27 Apr 2022 03:35:34 -0400
Subject: [PATCH] uapi: include <linux/types.h> header in scsi_bsg_mpi3mr.h
Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
---
include/uapi/scsi/scsi_bsg_mpi3mr.h | 2 ++
1 file changed, 2 insertions(+)
diff --git a/include/uapi/scsi/scsi_bsg_mpi3mr.h
b/include/uapi/scsi/scsi_bsg_mpi3mr.h
index 46c33efcff19..a0ddad7d84f7 100644
--- a/include/uapi/scsi/scsi_bsg_mpi3mr.h
+++ b/include/uapi/scsi/scsi_bsg_mpi3mr.h
@@ -10,6 +10,8 @@
#ifndef SCSI_BSG_MPI3MR_H_INCLUDED
#define SCSI_BSG_MPI3MR_H_INCLUDED
+#include <linux/types.h>
+
/* Definitions for BSG commands */
#define MPI3MR_IOCTL_VERSION 0x06
Thanks,
Sumit
[-- Attachment #2: S/MIME Cryptographic Signature --]
[-- Type: application/pkcs7-signature, Size: 4209 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2022-04-27 7:40 ` Sumit Saxena
@ 2022-04-27 8:28 ` Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2022-04-27 8:28 UTC (permalink / raw)
To: Sumit Saxena
Cc: Martin K. Petersen, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 5730 bytes --]
Hi Sumit,
On Wed, 27 Apr 2022 13:10:57 +0530 Sumit Saxena <sumit.saxena@broadcom.com> wrote:
>
> Could you please try if the below patch fixes this build failure:
>
> From: Sumit Saxena <sumit.saxena@broadcom.com>
> Date: Wed, 27 Apr 2022 03:35:34 -0400
> Subject: [PATCH] uapi: include <linux/types.h> header in scsi_bsg_mpi3mr.h
>
> Signed-off-by: Sumit Saxena <sumit.saxena@broadcom.com>
> ---
> include/uapi/scsi/scsi_bsg_mpi3mr.h | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/include/uapi/scsi/scsi_bsg_mpi3mr.h
> b/include/uapi/scsi/scsi_bsg_mpi3mr.h
> index 46c33efcff19..a0ddad7d84f7 100644
> --- a/include/uapi/scsi/scsi_bsg_mpi3mr.h
> +++ b/include/uapi/scsi/scsi_bsg_mpi3mr.h
> @@ -10,6 +10,8 @@
> #ifndef SCSI_BSG_MPI3MR_H_INCLUDED
> #define SCSI_BSG_MPI3MR_H_INCLUDED
>
> +#include <linux/types.h>
> +
> /* Definitions for BSG commands */
> #define MPI3MR_IOCTL_VERSION 0x06
It does not, because the uapi headers should only use the __ prefixed
versions of the kernel data types (u8 etc) and need to include
stdint.h in the not __KERNEL__ case for unint8_t etc.
So ... (this needs white space cleanups - you should probably use TAB
characters before the field names.)
diff --git a/include/uapi/scsi/scsi_bsg_mpi3mr.h b/include/uapi/scsi/scsi_bsg_mpi3mr.h
index 6d866256f924..5167d4da478a 100644
--- a/include/uapi/scsi/scsi_bsg_mpi3mr.h
+++ b/include/uapi/scsi/scsi_bsg_mpi3mr.h
@@ -10,6 +10,11 @@
#ifndef SCSI_BSG_MPI3MR_H_INCLUDED
#define SCSI_BSG_MPI3MR_H_INCLUDED
+#ifndef __KERNEL__
+#include <stdint.h>
+#endif
+#include <linux/types.h>
+
/* Definitions for BSG commands */
#define MPI3MR_IOCTL_VERSION 0x06
@@ -94,12 +99,12 @@ enum command {
*/
struct mpi3_driver_info_layout {
__le32 information_length;
- u8 driver_signature[12];
- u8 os_name[16];
- u8 os_version[12];
- u8 driver_name[20];
- u8 driver_version[32];
- u8 driver_release_date[20];
+ __u8 driver_signature[12];
+ __u8 os_name[16];
+ __u8 os_version[12];
+ __u8 driver_name[20];
+ __u8 driver_version[32];
+ __u8 driver_release_date[20];
__le32 driver_capabilities;
};
@@ -461,11 +466,11 @@ struct mpi3mr_bsg_packet {
struct mpi3_nvme_encapsulated_request {
__le16 host_tag;
- u8 ioc_use_only02;
- u8 function;
+ __u8 ioc_use_only02;
+ __u8 function;
__le16 ioc_use_only04;
- u8 ioc_use_only06;
- u8 msg_flags;
+ __u8 ioc_use_only06;
+ __u8 msg_flags;
__le16 change_count;
__le16 dev_handle;
__le16 encapsulated_command_length;
@@ -477,11 +482,11 @@ struct mpi3_nvme_encapsulated_request {
struct mpi3_nvme_encapsulated_error_reply {
__le16 host_tag;
- u8 ioc_use_only02;
- u8 function;
+ __u8 ioc_use_only02;
+ __u8 function;
__le16 ioc_use_only04;
- u8 ioc_use_only06;
- u8 msg_flags;
+ __u8 ioc_use_only06;
+ __u8 msg_flags;
__le16 ioc_use_only08;
__le16 ioc_status;
__le32 ioc_log_info;
@@ -499,20 +504,20 @@ struct mpi3_nvme_encapsulated_error_reply {
/* MPI3: task management related definitions */
struct mpi3_scsi_task_mgmt_request {
__le16 host_tag;
- u8 ioc_use_only02;
- u8 function;
+ __u8 ioc_use_only02;
+ __u8 function;
__le16 ioc_use_only04;
- u8 ioc_use_only06;
- u8 msg_flags;
+ __u8 ioc_use_only06;
+ __u8 msg_flags;
__le16 change_count;
__le16 dev_handle;
__le16 task_host_tag;
- u8 task_type;
- u8 reserved0f;
+ __u8 task_type;
+ __u8 reserved0f;
__le16 task_request_queue_id;
__le16 reserved12;
__le32 reserved14;
- u8 lun[8];
+ __u8 lun[8];
};
#define MPI3_SCSITASKMGMT_MSGFLAGS_DO_NOT_SEND_TASK_IU (0x08)
@@ -528,11 +533,11 @@ struct mpi3_scsi_task_mgmt_request {
#define MPI3_SCSITASKMGMT_TASKTYPE_I_T_NEXUS_RESET (0x0b)
struct mpi3_scsi_task_mgmt_reply {
__le16 host_tag;
- u8 ioc_use_only02;
- u8 function;
+ __u8 ioc_use_only02;
+ __u8 function;
__le16 ioc_use_only04;
- u8 ioc_use_only06;
- u8 msg_flags;
+ __u8 ioc_use_only06;
+ __u8 msg_flags;
__le16 ioc_use_only08;
__le16 ioc_status;
__le32 ioc_log_info;
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2021-08-17 9:47 Stephen Rothwell
2021-08-17 9:51 ` John Garry
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2021-08-17 9:47 UTC (permalink / raw)
To: Martin K. Petersen
Cc: John Garry, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1462 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
In file included from include/linux/byteorder/big_endian.h:5,
from arch/powerpc/include/uapi/asm/byteorder.h:14,
from include/asm-generic/bitops/le.h:7,
from arch/powerpc/include/asm/bitops.h:265,
from include/linux/bitops.h:33,
from include/linux/kernel.h:12,
from include/linux/list.h:9,
from include/linux/module.h:12,
from drivers/scsi/ibmvscsi/ibmvfc.c:10:
drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_queuecommand':
drivers/scsi/ibmvscsi/ibmvfc.c:1959:39: error: 'struct scsi_cmnd' has no member named 'tag'
1959 | vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
| ^~
include/uapi/linux/byteorder/big_endian.h:37:51: note: in definition of macro '__cpu_to_be64'
37 | #define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
| ^
drivers/scsi/ibmvscsi/ibmvfc.c:1959:23: note: in expansion of macro 'cpu_to_be64'
1959 | vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
| ^~~~~~~~~~~
Caused by commit
c7c43e3c7147 ("scsi: core: Remove scsi_cmnd.tag")
I have used the scsi-mkp tree from next-20210816 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-08-17 9:47 Stephen Rothwell
@ 2021-08-17 9:51 ` John Garry
2021-08-18 3:07 ` Bart Van Assche
0 siblings, 1 reply; 79+ messages in thread
From: John Garry @ 2021-08-17 9:51 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-scsi
On 17/08/2021 10:47, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> In file included from include/linux/byteorder/big_endian.h:5,
> from arch/powerpc/include/uapi/asm/byteorder.h:14,
> from include/asm-generic/bitops/le.h:7,
> from arch/powerpc/include/asm/bitops.h:265,
> from include/linux/bitops.h:33,
> from include/linux/kernel.h:12,
> from include/linux/list.h:9,
> from include/linux/module.h:12,
> from drivers/scsi/ibmvscsi/ibmvfc.c:10:
> drivers/scsi/ibmvscsi/ibmvfc.c: In function 'ibmvfc_queuecommand':
> drivers/scsi/ibmvscsi/ibmvfc.c:1959:39: error: 'struct scsi_cmnd' has no member named 'tag'
> 1959 | vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
> | ^~
> include/uapi/linux/byteorder/big_endian.h:37:51: note: in definition of macro '__cpu_to_be64'
> 37 | #define __cpu_to_be64(x) ((__force __be64)(__u64)(x))
> | ^
> drivers/scsi/ibmvscsi/ibmvfc.c:1959:23: note: in expansion of macro 'cpu_to_be64'
> 1959 | vfc_cmd->task_tag = cpu_to_be64(cmnd->tag);
> | ^~~~~~~~~~~
>
> Caused by commit
>
> c7c43e3c7147 ("scsi: core: Remove scsi_cmnd.tag")
>
> I have used the scsi-mkp tree from next-20210816 for today.
>
sorry... I only built x86 and arm64 allmodconfig. Let me check this.
Thanks
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-08-17 9:51 ` John Garry
@ 2021-08-18 3:07 ` Bart Van Assche
2021-08-18 11:41 ` John Garry
0 siblings, 1 reply; 79+ messages in thread
From: Bart Van Assche @ 2021-08-18 3:07 UTC (permalink / raw)
To: John Garry, Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-scsi
On 8/17/21 2:51 AM, John Garry wrote:
> sorry... I only built x86 and arm64 allmodconfig. Let me check this.
Build testing for tree-wide changes is tricky. You may want to use a
build bot for such testing. From
https://01.org/lkp/documentation/0-day-test-service:
Q: Which git tree and which mailing list will be tested? How can I
opt-in or opt-out from it?
A: 0-Day monitors hundreds of git trees and tens of mailing lists. You
can obtain detailed tree and mailing list information from the source
code under the lkp-tests/repo directory. If you want to add or remove
your tree from the 0-Day test system, send an email to the LKML,
specifying your git tree URL.
Bart.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-08-18 3:07 ` Bart Van Assche
@ 2021-08-18 11:41 ` John Garry
0 siblings, 0 replies; 79+ messages in thread
From: John Garry @ 2021-08-18 11:41 UTC (permalink / raw)
To: Bart Van Assche, Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List, linux-scsi
On 18/08/2021 04:07, Bart Van Assche wrote:
> On 8/17/21 2:51 AM, John Garry wrote:
>> sorry... I only built x86 and arm64 allmodconfig. Let me check this.
> Build testing for tree-wide changes is tricky. You may want to use a
> build bot for such testing. From
> https://01.org/lkp/documentation/0-day-test-service:
>
> Q: Which git tree and which mailing list will be tested? How can I
> opt-in or opt-out from it?
>
> A: 0-Day monitors hundreds of git trees and tens of mailing lists. You
> can obtain detailed tree and mailing list information from the source
> code under the lkp-tests/repo directory. If you want to add or remove
> your tree from the 0-Day test system, send an email to the LKML,
> specifying your git tree URL.
Thanks for the info! Quite useful.
Unfortunately there is code which has internal build switches - like
qla1280.c and DEBUG_QLA1280, which Martin mentioned - so harder to spot.
I suppose that's the risk with internal build switches.
Thanks again,
John
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2021-05-27 3:47 Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2021-05-27 3:47 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Hannes Reinecke, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 574 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/scsi/pcmcia/nsp_cs.c: In function 'nsp_queuecommand_lck':
drivers/scsi/pcmcia/nsp_cs.c:224:22: error: 'CHECK_CONDITION' undeclared (first use in this function)
224 | SCpnt->SCp.Status = CHECK_CONDITION;
| ^~~~~~~~~~~~~~~
Caused by commit
57de15221f92 ("scsi: core: Drop obsolete Linux-specific SCSI status codes")
I have used the scsi-mkp tree from next-20210526 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* linux-next: build failure after merge of the scsi-mkp tree
@ 2021-03-12 3:17 Stephen Rothwell
2021-03-12 3:20 ` Jens Axboe
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2021-03-12 3:17 UTC (permalink / raw)
To: Martin K. Petersen, Jens Axboe
Cc: Christoph Hellwig, Douglas Gilbert, Linux Kernel Mailing List,
Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1612 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/sg.c: In function 'sg_mk_kern_bio':
drivers/scsi/sg.c:2958:17: error: 'BIO_MAX_PAGES' undeclared (first use in this function); did you mean 'BIO_MAX_VECS'?
2958 | if (bvec_cnt > BIO_MAX_PAGES)
| ^~~~~~~~~~~~~
| BIO_MAX_VECS
Caused by commit
b32ac463cb59 ("scsi: sg: NO_DXFER move to/from kernel buffers")
interacting with commit
a8affc03a9b3 ("block: rename BIO_MAX_PAGES to BIO_MAX_VECS")
from the block tree.
I have applied the following merge fix patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Fri, 12 Mar 2021 14:11:16 +1100
Subject: [PATCH] scsi: sg: fix up for BIO_MAX_PAGES rename
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/scsi/sg.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
index 2d4bbc1a1727..6b31b2bc8f9a 100644
--- a/drivers/scsi/sg.c
+++ b/drivers/scsi/sg.c
@@ -2955,7 +2955,7 @@ sg_mk_kern_bio(int bvec_cnt)
{
struct bio *biop;
- if (bvec_cnt > BIO_MAX_PAGES)
+ if (bvec_cnt > BIO_MAX_VECS)
return NULL;
biop = bio_alloc(GFP_ATOMIC, bvec_cnt);
if (!biop)
--
2.30.0
Jens, maybe you could create a topic branch with that block tree change
in it (and any other necessary ones) for Martin to merge into his tree.
Of course, you should do that be rebasing it onto v5.12-rc2 first to
get rid of the swapfile booby trap.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-03-12 3:17 Stephen Rothwell
@ 2021-03-12 3:20 ` Jens Axboe
0 siblings, 0 replies; 79+ messages in thread
From: Jens Axboe @ 2021-03-12 3:20 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Christoph Hellwig, Douglas Gilbert, Linux Kernel Mailing List,
Linux Next Mailing List
On 3/11/21 8:17 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
>
> drivers/scsi/sg.c: In function 'sg_mk_kern_bio':
> drivers/scsi/sg.c:2958:17: error: 'BIO_MAX_PAGES' undeclared (first use in this function); did you mean 'BIO_MAX_VECS'?
> 2958 | if (bvec_cnt > BIO_MAX_PAGES)
> | ^~~~~~~~~~~~~
> | BIO_MAX_VECS
>
> Caused by commit
>
> b32ac463cb59 ("scsi: sg: NO_DXFER move to/from kernel buffers")
>
> interacting with commit
>
> a8affc03a9b3 ("block: rename BIO_MAX_PAGES to BIO_MAX_VECS")
>
> from the block tree.
>
> I have applied the following merge fix patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Fri, 12 Mar 2021 14:11:16 +1100
> Subject: [PATCH] scsi: sg: fix up for BIO_MAX_PAGES rename
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/scsi/sg.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/scsi/sg.c b/drivers/scsi/sg.c
> index 2d4bbc1a1727..6b31b2bc8f9a 100644
> --- a/drivers/scsi/sg.c
> +++ b/drivers/scsi/sg.c
> @@ -2955,7 +2955,7 @@ sg_mk_kern_bio(int bvec_cnt)
> {
> struct bio *biop;
>
> - if (bvec_cnt > BIO_MAX_PAGES)
> + if (bvec_cnt > BIO_MAX_VECS)
> return NULL;
> biop = bio_alloc(GFP_ATOMIC, bvec_cnt);
> if (!biop)
Looks good - fwiw, the block change will go into 5.12-rc3 to avoid
having this issue over a merge window prep, so maybe SCSI can pull
in -rc3 and get this resolved locally in that tree.
I'll rebase the block-5.12 branch off -rc1 after this merge.
--
Jens Axboe
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2021-01-25 4:13 Stephen Rothwell
2021-01-25 5:53 ` Douglas Gilbert
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2021-01-25 4:13 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Douglas Gilbert, Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1428 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
drivers/scsi/sg.c:2908:4: error: expected '}' before 'else'
2908 | else
| ^~~~
drivers/scsi/sg.c:2902:16: warning: unused variable 'cptp' [-Wunused-variable]
2902 | const char *cptp = "pack_id=";
| ^~~~
drivers/scsi/sg.c:2896:5: error: label 'good' used but not defined
2896 | goto good;
| ^~~~
drivers/scsi/sg.c: At top level:
drivers/scsi/sg.c:2913:2: error: expected identifier or '(' before 'return'
2913 | return NULL;
| ^~~~~~
drivers/scsi/sg.c:2914:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
2914 | good:
| ^
drivers/scsi/sg.c:2917:2: error: expected identifier or '(' before 'return'
2917 | return srp;
| ^~~~~~
drivers/scsi/sg.c:2918:1: error: expected identifier or '(' before '}' token
2918 | }
| ^
drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
drivers/scsi/sg.c:2912:2: error: control reaches end of non-void function [-Werror=return-type]
2912 | }
| ^
Caused by commit
7323ad3618b6 ("scsi: sg: Replace rq array with xarray")
SG_LOG() degenerates to "{}" in some configs ...
I have used the scsi-mkp tree from next-20210122 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-01-25 4:13 Stephen Rothwell
@ 2021-01-25 5:53 ` Douglas Gilbert
2021-01-27 7:01 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Douglas Gilbert @ 2021-01-25 5:53 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List
On 2021-01-24 11:13 p.m., Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> drivers/scsi/sg.c:2908:4: error: expected '}' before 'else'
> 2908 | else
> | ^~~~
> drivers/scsi/sg.c:2902:16: warning: unused variable 'cptp' [-Wunused-variable]
> 2902 | const char *cptp = "pack_id=";
> | ^~~~
> drivers/scsi/sg.c:2896:5: error: label 'good' used but not defined
> 2896 | goto good;
> | ^~~~
> drivers/scsi/sg.c: At top level:
> drivers/scsi/sg.c:2913:2: error: expected identifier or '(' before 'return'
> 2913 | return NULL;
> | ^~~~~~
> drivers/scsi/sg.c:2914:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
> 2914 | good:
> | ^
> drivers/scsi/sg.c:2917:2: error: expected identifier or '(' before 'return'
> 2917 | return srp;
> | ^~~~~~
> drivers/scsi/sg.c:2918:1: error: expected identifier or '(' before '}' token
> 2918 | }
> | ^
> drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> drivers/scsi/sg.c:2912:2: error: control reaches end of non-void function [-Werror=return-type]
> 2912 | }
> | ^
>
> Caused by commit
>
> 7323ad3618b6 ("scsi: sg: Replace rq array with xarray")
>
> SG_LOG() degenerates to "{}" in some configs ...
>
> I have used the scsi-mkp tree from next-20210122 for today.
>
Hi,
I sent a new patchset to the linux-scsi list about 4 hours ago to
fix that.
Doug Gilbert
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-01-25 5:53 ` Douglas Gilbert
@ 2021-01-27 7:01 ` Stephen Rothwell
2021-01-27 17:10 ` Douglas Gilbert
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2021-01-27 7:01 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Douglas Gilbert, Linux Kernel Mailing List,
Linux Next Mailing List, James Bottomley
[-- Attachment #1: Type: text/plain, Size: 1890 bytes --]
Hi all,
On Mon, 25 Jan 2021 00:53:59 -0500 Douglas Gilbert <dgilbert@interlog.com> wrote:
>
> On 2021-01-24 11:13 p.m., Stephen Rothwell wrote:
> >
> > After merging the scsi-mkp tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> > drivers/scsi/sg.c:2908:4: error: expected '}' before 'else'
> > 2908 | else
> > | ^~~~
> > drivers/scsi/sg.c:2902:16: warning: unused variable 'cptp' [-Wunused-variable]
> > 2902 | const char *cptp = "pack_id=";
> > | ^~~~
> > drivers/scsi/sg.c:2896:5: error: label 'good' used but not defined
> > 2896 | goto good;
> > | ^~~~
> > drivers/scsi/sg.c: At top level:
> > drivers/scsi/sg.c:2913:2: error: expected identifier or '(' before 'return'
> > 2913 | return NULL;
> > | ^~~~~~
> > drivers/scsi/sg.c:2914:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
> > 2914 | good:
> > | ^
> > drivers/scsi/sg.c:2917:2: error: expected identifier or '(' before 'return'
> > 2917 | return srp;
> > | ^~~~~~
> > drivers/scsi/sg.c:2918:1: error: expected identifier or '(' before '}' token
> > 2918 | }
> > | ^
> > drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
> > drivers/scsi/sg.c:2912:2: error: control reaches end of non-void function [-Werror=return-type]
> > 2912 | }
> > | ^
> >
> > Caused by commit
> >
> > 7323ad3618b6 ("scsi: sg: Replace rq array with xarray")
> >
> > SG_LOG() degenerates to "{}" in some configs ...
> >
> > I have used the scsi-mkp tree from next-20210122 for today.
>
> I sent a new patchset to the linux-scsi list about 4 hours ago to
> fix that.
>
> Doug Gilbert
I am still getting this build failure.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2021-01-27 7:01 ` Stephen Rothwell
@ 2021-01-27 17:10 ` Douglas Gilbert
0 siblings, 0 replies; 79+ messages in thread
From: Douglas Gilbert @ 2021-01-27 17:10 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Kernel Mailing List, Linux Next Mailing List, James Bottomley
On 2021-01-27 2:01 a.m., Stephen Rothwell wrote:
> Hi all,
>
> On Mon, 25 Jan 2021 00:53:59 -0500 Douglas Gilbert <dgilbert@interlog.com> wrote:
>>
>> On 2021-01-24 11:13 p.m., Stephen Rothwell wrote:
>>>
>>> After merging the scsi-mkp tree, today's linux-next build (powerpc
>>> ppc64_defconfig) failed like this:
>>>
>>> drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
>>> drivers/scsi/sg.c:2908:4: error: expected '}' before 'else'
>>> 2908 | else
>>> | ^~~~
>>> drivers/scsi/sg.c:2902:16: warning: unused variable 'cptp' [-Wunused-variable]
>>> 2902 | const char *cptp = "pack_id=";
>>> | ^~~~
>>> drivers/scsi/sg.c:2896:5: error: label 'good' used but not defined
>>> 2896 | goto good;
>>> | ^~~~
>>> drivers/scsi/sg.c: At top level:
>>> drivers/scsi/sg.c:2913:2: error: expected identifier or '(' before 'return'
>>> 2913 | return NULL;
>>> | ^~~~~~
>>> drivers/scsi/sg.c:2914:5: error: expected '=', ',', ';', 'asm' or '__attribute__' before ':' token
>>> 2914 | good:
>>> | ^
>>> drivers/scsi/sg.c:2917:2: error: expected identifier or '(' before 'return'
>>> 2917 | return srp;
>>> | ^~~~~~
>>> drivers/scsi/sg.c:2918:1: error: expected identifier or '(' before '}' token
>>> 2918 | }
>>> | ^
>>> drivers/scsi/sg.c: In function 'sg_find_srp_by_id':
>>> drivers/scsi/sg.c:2912:2: error: control reaches end of non-void function [-Werror=return-type]
>>> 2912 | }
>>> | ^
>>>
>>> Caused by commit
>>>
>>> 7323ad3618b6 ("scsi: sg: Replace rq array with xarray")
>>>
>>> SG_LOG() degenerates to "{}" in some configs ...
>>>
>>> I have used the scsi-mkp tree from next-20210122 for today.
>>
>> I sent a new patchset to the linux-scsi list about 4 hours ago to
>> fix that.
>>
>> Doug Gilbert
>
> I am still getting this build failure.
Hi,
I resent the original patch set, with fixes, against the linux-scsi
list yesterday but that was not the form that Martin Petersen needs
it in. That was against his 5.12/scsi-queue branch which is roughly
lk 5.11.0-rc2. He has referred me to his 5.12/scsi-staging branch
which looks half applied from the 45 patch set that I have been
sending to the linux-scsi list. Trying to find out if that was the
intention or a mistake.
The other issue is a large patchset that removes the first function
argument from blk_execute_rq_nowait() which is used by the sg driver.
Doug Gilbert
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2020-12-08 9:28 Stephen Rothwell
2020-12-08 9:30 ` Christoph Hellwig
2020-12-08 9:38 ` Stephen Rothwell
0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2020-12-08 9:28 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Alan Stern, Bart Van Assche, Can Guo, Christoph Hellwig,
Hannes Reinecke, Jens Axboe, Stanley Chu,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 1997 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (sparc64
defconfig) failed like this:
drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
17 | #include <linux/mtd/nand_ecc.h>
| ^~~~~~~~~~~~~~~~~~~~~~
Caused by commit
81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
# CONFIG_PM is not set
I have applied the following patch:
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 8 Dec 2020 20:12:33 +1100
Subject: [PATCH] scsi: block: fix for "scsi: block: Do not accept any requests while suspended"
Fixes: 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
block/blk-core.c | 18 ++++++++++++++----
1 file changed, 14 insertions(+), 4 deletions(-)
diff --git a/block/blk-core.c b/block/blk-core.c
index a71a5c9429d6..9c9aec1382be 100644
--- a/block/blk-core.c
+++ b/block/blk-core.c
@@ -421,6 +421,18 @@ void blk_cleanup_queue(struct request_queue *q)
}
EXPORT_SYMBOL(blk_cleanup_queue);
+#ifdef CONFIG_PM
+static bool rq_suspended(struct request_queue *q)
+{
+ return q->rpm_status == RPM_SUSPENDED;
+}
+#else
+static bool rq_suspended(struct request_queue *q)
+{
+ return false;
+}
+#endif
+
/**
* blk_queue_enter() - try to increase q->q_usage_counter
* @q: request queue pointer
@@ -440,12 +452,10 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
* responsible for ensuring that that counter is
* globally visible before the queue is unfrozen.
*/
- if ((pm && q->rpm_status != RPM_SUSPENDED) ||
- !blk_queue_pm_only(q)) {
+ if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
success = true;
- } else {
+ else
percpu_ref_put(&q->q_usage_counter);
- }
}
rcu_read_unlock();
--
2.29.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-12-08 9:28 Stephen Rothwell
@ 2020-12-08 9:30 ` Christoph Hellwig
2020-12-08 10:01 ` Stephen Rothwell
2020-12-08 9:38 ` Stephen Rothwell
1 sibling, 1 reply; 79+ messages in thread
From: Christoph Hellwig @ 2020-12-08 9:30 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Alan Stern, Bart Van Assche, Can Guo,
Christoph Hellwig, Hannes Reinecke, Jens Axboe, Stanley Chu,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Dec 08, 2020 at 08:28:53PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
> 17 | #include <linux/mtd/nand_ecc.h>
The error message doesn't match up with your proposed solution.
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-12-08 9:30 ` Christoph Hellwig
@ 2020-12-08 10:01 ` Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2020-12-08 10:01 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Martin K. Petersen, Alan Stern, Bart Van Assche, Can Guo,
Hannes Reinecke, Jens Axboe, Stanley Chu,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 603 bytes --]
Hi Christoph,
On Tue, 8 Dec 2020 10:30:39 +0100 Christoph Hellwig <hch@lst.de> wrote:
>
> On Tue, Dec 08, 2020 at 08:28:53PM +1100, Stephen Rothwell wrote:
> > Hi all,
> >
> > After merging the scsi-mkp tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
> > 17 | #include <linux/mtd/nand_ecc.h>
>
> The error message doesn't match up with your proposed solution.
Yeah, semi automation gone wrong :-)
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-12-08 9:28 Stephen Rothwell
2020-12-08 9:30 ` Christoph Hellwig
@ 2020-12-08 9:38 ` Stephen Rothwell
2020-12-08 17:55 ` Alan Stern
1 sibling, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2020-12-08 9:38 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Alan Stern, Bart Van Assche, Can Guo, Christoph Hellwig,
Hannes Reinecke, Jens Axboe, Stanley Chu,
Linux Kernel Mailing List, Linux Next Mailing List
[-- Attachment #1: Type: text/plain, Size: 2533 bytes --]
Hi all,
On Tue, 8 Dec 2020 20:28:53 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (sparc64
> defconfig) failed like this:
>
> drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
> 17 | #include <linux/mtd/nand_ecc.h>
> | ^~~~~~~~~~~~~~~~~~~~~~
Clearly, it did not fail like that :-)
block/blk-core.c: In function 'blk_queue_enter':
block/blk-core.c:443:18: error: 'struct request_queue' has no member named 'rpm_status'; did you mean 'stats'?
if ((pm && q->rpm_status != RPM_SUSPENDED) ||
^~~~~~~~~~
stats
> Caused by commit
>
> 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
>
> # CONFIG_PM is not set
>
> I have applied the following patch:
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 8 Dec 2020 20:12:33 +1100
> Subject: [PATCH] scsi: block: fix for "scsi: block: Do not accept any requests while suspended"
>
> Fixes: 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> block/blk-core.c | 18 ++++++++++++++----
> 1 file changed, 14 insertions(+), 4 deletions(-)
>
> diff --git a/block/blk-core.c b/block/blk-core.c
> index a71a5c9429d6..9c9aec1382be 100644
> --- a/block/blk-core.c
> +++ b/block/blk-core.c
> @@ -421,6 +421,18 @@ void blk_cleanup_queue(struct request_queue *q)
> }
> EXPORT_SYMBOL(blk_cleanup_queue);
>
> +#ifdef CONFIG_PM
> +static bool rq_suspended(struct request_queue *q)
> +{
> + return q->rpm_status == RPM_SUSPENDED;
> +}
> +#else
> +static bool rq_suspended(struct request_queue *q)
> +{
> + return false;
> +}
> +#endif
> +
> /**
> * blk_queue_enter() - try to increase q->q_usage_counter
> * @q: request queue pointer
> @@ -440,12 +452,10 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
> * responsible for ensuring that that counter is
> * globally visible before the queue is unfrozen.
> */
> - if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> - !blk_queue_pm_only(q)) {
> + if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
> success = true;
> - } else {
> + else
> percpu_ref_put(&q->q_usage_counter);
> - }
> }
> rcu_read_unlock();
>
> --
> 2.29.2
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-12-08 9:38 ` Stephen Rothwell
@ 2020-12-08 17:55 ` Alan Stern
2020-12-08 19:56 ` Bart Van Assche
0 siblings, 1 reply; 79+ messages in thread
From: Alan Stern @ 2020-12-08 17:55 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Bart Van Assche, Can Guo, Christoph Hellwig,
Hannes Reinecke, Jens Axboe, Stanley Chu,
Linux Kernel Mailing List, Linux Next Mailing List
On Tue, Dec 08, 2020 at 08:38:59PM +1100, Stephen Rothwell wrote:
> Hi all,
>
> On Tue, 8 Dec 2020 20:28:53 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > Hi all,
> >
> > After merging the scsi-mkp tree, today's linux-next build (sparc64
> > defconfig) failed like this:
> >
> > drivers/mtd/nand/raw/intel-nand-controller.c:17:10: fatal error: linux/mtd/nand_ecc.h: No such file or directory
> > 17 | #include <linux/mtd/nand_ecc.h>
> > | ^~~~~~~~~~~~~~~~~~~~~~
>
> Clearly, it did not fail like that :-)
>
> block/blk-core.c: In function 'blk_queue_enter':
> block/blk-core.c:443:18: error: 'struct request_queue' has no member named 'rpm_status'; did you mean 'stats'?
> if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> ^~~~~~~~~~
> stats
>
> > Caused by commit
> >
> > 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
> >
> > # CONFIG_PM is not set
> >
> > I have applied the following patch:
> >
> > From: Stephen Rothwell <sfr@canb.auug.org.au>
> > Date: Tue, 8 Dec 2020 20:12:33 +1100
> > Subject: [PATCH] scsi: block: fix for "scsi: block: Do not accept any requests while suspended"
> >
> > Fixes: 81a395cdc176 ("scsi: block: Do not accept any requests while suspended")
> > Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> > ---
> > block/blk-core.c | 18 ++++++++++++++----
> > 1 file changed, 14 insertions(+), 4 deletions(-)
> >
> > diff --git a/block/blk-core.c b/block/blk-core.c
> > index a71a5c9429d6..9c9aec1382be 100644
> > --- a/block/blk-core.c
> > +++ b/block/blk-core.c
> > @@ -421,6 +421,18 @@ void blk_cleanup_queue(struct request_queue *q)
> > }
> > EXPORT_SYMBOL(blk_cleanup_queue);
> >
> > +#ifdef CONFIG_PM
> > +static bool rq_suspended(struct request_queue *q)
> > +{
> > + return q->rpm_status == RPM_SUSPENDED;
> > +}
> > +#else
> > +static bool rq_suspended(struct request_queue *q)
> > +{
> > + return false;
> > +}
> > +#endif
> > +
> > /**
> > * blk_queue_enter() - try to increase q->q_usage_counter
> > * @q: request queue pointer
> > @@ -440,12 +452,10 @@ int blk_queue_enter(struct request_queue *q, blk_mq_req_flags_t flags)
> > * responsible for ensuring that that counter is
> > * globally visible before the queue is unfrozen.
> > */
> > - if ((pm && q->rpm_status != RPM_SUSPENDED) ||
> > - !blk_queue_pm_only(q)) {
> > + if ((pm && !rq_suspended(q)) || !blk_queue_pm_only(q))
> > success = true;
> > - } else {
> > + else
> > percpu_ref_put(&q->q_usage_counter);
> > - }
> > }
> > rcu_read_unlock();
Yes, that certainly is the proper fix. It's all to easy to miss these
issues that depend on your kernel configuration.
Bart, can you fold it into a new version of the patch?
Alan Stern
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-12-08 17:55 ` Alan Stern
@ 2020-12-08 19:56 ` Bart Van Assche
0 siblings, 0 replies; 79+ messages in thread
From: Bart Van Assche @ 2020-12-08 19:56 UTC (permalink / raw)
To: Alan Stern, Stephen Rothwell
Cc: Martin K. Petersen, Can Guo, Christoph Hellwig, Hannes Reinecke,
Jens Axboe, Stanley Chu, Linux Kernel Mailing List,
Linux Next Mailing List
On 12/8/20 9:55 AM, Alan Stern wrote:
> Yes, that certainly is the proper fix. It's all to easy to miss these
> issues that depend on your kernel configuration.
>
> Bart, can you fold it into a new version of the patch?
Sure, I will do that.
Thanks,
Bart.
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2020-07-21 6:30 Stephen Rothwell
2020-07-23 5:54 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2020-07-21 6:30 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kiwoong Kim
[-- Attachment #1: Type: text/plain, Size: 1427 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
Caused by commits
c3b5e96ef515 ("scsi: ufs: exynos: Introduce command history")
957ee40d413b ("scsi: ufs: exynos: Implement dbg_register_dump")
I applied the following patch for now.
From 6535b25fb253c7f25bf924655edb2b22fdaeb545 Mon Sep 17 00:00:00 2001
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Tue, 21 Jul 2020 16:26:05 +1000
Subject: [PATCH] scsi: ufs: exynos: mark debugging as broken
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/scsi/ufs/Kconfig | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
index 2c31b33f0adc..925f8de62f6d 100644
--- a/drivers/scsi/ufs/Kconfig
+++ b/drivers/scsi/ufs/Kconfig
@@ -178,6 +178,7 @@ config SCSI_UFS_EXYNOS_DBG
bool "EXYNOS specific debug functions"
default n
depends on SCSI_UFS_EXYNOS
+ depends on BROKEN
help
This selects EXYNOS specific functions to get and even print
debug information to see what's happening at both command
--
2.27.0
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-07-21 6:30 Stephen Rothwell
@ 2020-07-23 5:54 ` Stephen Rothwell
2020-07-23 15:01 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2020-07-23 5:54 UTC (permalink / raw)
To: Martin K. Petersen, James Bottomley
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Kiwoong Kim
[-- Attachment #1: Type: text/plain, Size: 1639 bytes --]
Hi all,
On Tue, 21 Jul 2020 16:30:45 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
>
> Caused by commits
>
> c3b5e96ef515 ("scsi: ufs: exynos: Introduce command history")
> 957ee40d413b ("scsi: ufs: exynos: Implement dbg_register_dump")
>
> I applied the following patch for now.
>
> From 6535b25fb253c7f25bf924655edb2b22fdaeb545 Mon Sep 17 00:00:00 2001
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Tue, 21 Jul 2020 16:26:05 +1000
> Subject: [PATCH] scsi: ufs: exynos: mark debugging as broken
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/scsi/ufs/Kconfig | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/drivers/scsi/ufs/Kconfig b/drivers/scsi/ufs/Kconfig
> index 2c31b33f0adc..925f8de62f6d 100644
> --- a/drivers/scsi/ufs/Kconfig
> +++ b/drivers/scsi/ufs/Kconfig
> @@ -178,6 +178,7 @@ config SCSI_UFS_EXYNOS_DBG
> bool "EXYNOS specific debug functions"
> default n
> depends on SCSI_UFS_EXYNOS
> + depends on BROKEN
> help
> This selects EXYNOS specific functions to get and even print
> debug information to see what's happening at both command
> --
> 2.27.0
This build failure now applies to the scsi tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-07-23 5:54 ` Stephen Rothwell
@ 2020-07-23 15:01 ` Martin K. Petersen
2020-07-24 4:21 ` Kiwoong Kim
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2020-07-23 15:01 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, James Bottomley, Linux Next Mailing List,
Linux Kernel Mailing List, Kiwoong Kim, Alim Akhtar
Stephen,
>> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
>> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
>> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs-exynos.ko] undefined!
*sigh* sorry about that. I did verify yesterday's exynos build fix with
COMPILE_TEST but it looks like I didn't have the new driver debugging
option enabled.
Kiwoong/Alim: Please fix!
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* RE: linux-next: build failure after merge of the scsi-mkp tree
2020-07-23 15:01 ` Martin K. Petersen
@ 2020-07-24 4:21 ` Kiwoong Kim
0 siblings, 0 replies; 79+ messages in thread
From: Kiwoong Kim @ 2020-07-24 4:21 UTC (permalink / raw)
To: 'Martin K. Petersen', 'Stephen Rothwell'
Cc: 'James Bottomley', 'Linux Next Mailing List',
'Linux Kernel Mailing List', 'Alim Akhtar'
> >> ERROR: modpost: "exynos_ufs_dump_info" [drivers/scsi/ufs/ufs-exynos.ko]
> undefined!
> >> ERROR: modpost: "exynos_ufs_init_dbg" [drivers/scsi/ufs/ufs-exynos.ko]
> undefined!
> >> ERROR: modpost: "exynos_ufs_cmd_log_start" [drivers/scsi/ufs/ufs-
> exynos.ko] undefined!
>
> *sigh* sorry about that. I did verify yesterday's exynos build fix with
> COMPILE_TEST but it looks like I didn't have the new driver debugging
> option enabled.
>
> Kiwoong/Alim: Please fix!
>
> --
> Martin K. Petersen Oracle Linux Engineering
Hi, Martin.
Sorry for responding lately. I'll post a patch to fix soon.
Thanks.
Kiwoong Kim
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2020-01-22 4:10 Stephen Rothwell
2020-01-22 9:51 ` John Garry
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2020-01-22 4:10 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List, John Garry
[-- Attachment #1: Type: text/plain, Size: 442 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
ERROR: "irq_create_affinity_masks" [drivers/scsi/hisi_sas/hisi_sas_v2_hw.ko] undefined!
ERROR: "__irq_set_affinity" [drivers/scsi/hisi_sas/hisi_sas_v2_hw.ko] undefined!
Caused by commit
3869a618eb88 ("scsi: hisi_sas: Use reply map for v2 hw")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2020-01-22 4:10 Stephen Rothwell
@ 2020-01-22 9:51 ` John Garry
2020-01-23 2:22 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: John Garry @ 2020-01-22 9:51 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List,
James E . J . Bottomley
On 22/01/2020 04:10, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (x86_64
> allmodconfig) failed like this:
>
> ERROR: "irq_create_affinity_masks" [drivers/scsi/hisi_sas/hisi_sas_v2_hw.ko] undefined!
> ERROR: "__irq_set_affinity" [drivers/scsi/hisi_sas/hisi_sas_v2_hw.ko] undefined!
>
That's sloppy of me - I never build tested for this driver as a module.
And so these symbols are not exported.
> Caused by commit
>
Hi Martin,
> 3869a618eb88 ("scsi: hisi_sas: Use reply map for v2 hw")
>
Could you please drop this patch from your branch/revert it? Sorry for
the hassle.
I should have really talked with Thomas G about whether I should even
reference the first symbol at all. I'll do that now.
> I have reverted that commit for today.
>
Thanks,
John
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2019-10-25 3:07 Stephen Rothwell
2019-10-25 18:03 ` James Smart
2019-10-28 5:49 ` Stephen Rothwell
0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2019-10-25 3:07 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List, James Smart
[-- Attachment #1: Type: text/plain, Size: 1166 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_release':
drivers/scsi/lpfc/lpfc_debugfs.c:2109:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
2109 | vfree(debug->buffer);
| ^~~~~
| kvfree
drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_open':
drivers/scsi/lpfc/lpfc_debugfs.c:2150:18: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration]
2150 | debug->buffer = vmalloc(size);
| ^~~~~~~
| kvmalloc
drivers/scsi/lpfc/lpfc_debugfs.c:2150:16: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
2150 | debug->buffer = vmalloc(size);
| ^
Caused by commit
95bfc6d8ad86 ("scsi: lpfc: Make FW logging dynamically configurable")
I have used the scsi-mkp tree from next-20191024 for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-10-25 3:07 Stephen Rothwell
@ 2019-10-25 18:03 ` James Smart
2019-10-28 5:49 ` Stephen Rothwell
1 sibling, 0 replies; 79+ messages in thread
From: James Smart @ 2019-10-25 18:03 UTC (permalink / raw)
To: Stephen Rothwell, Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List
On 10/24/2019 8:07 PM, Stephen Rothwell wrote:
> Hi all,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_release':
> drivers/scsi/lpfc/lpfc_debugfs.c:2109:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
> 2109 | vfree(debug->buffer);
> | ^~~~~
> | kvfree
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_open':
> drivers/scsi/lpfc/lpfc_debugfs.c:2150:18: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration]
> 2150 | debug->buffer = vmalloc(size);
> | ^~~~~~~
> | kvmalloc
> drivers/scsi/lpfc/lpfc_debugfs.c:2150:16: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> 2150 | debug->buffer = vmalloc(size);
> | ^
>
> Caused by commit
>
> 95bfc6d8ad86 ("scsi: lpfc: Make FW logging dynamically configurable")
>
> I have used the scsi-mkp tree from next-20191024 for today.
>
I will resolve this quickly...
-- james
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-10-25 3:07 Stephen Rothwell
2019-10-25 18:03 ` James Smart
@ 2019-10-28 5:49 ` Stephen Rothwell
2019-10-29 2:28 ` Martin K. Petersen
1 sibling, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2019-10-28 5:49 UTC (permalink / raw)
To: Martin K. Petersen, James Bottomley
Cc: Linux Next Mailing List, Linux Kernel Mailing List, James Smart
[-- Attachment #1: Type: text/plain, Size: 1407 bytes --]
Hi all,
On Fri, 25 Oct 2019 14:07:36 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_release':
> drivers/scsi/lpfc/lpfc_debugfs.c:2109:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
> 2109 | vfree(debug->buffer);
> | ^~~~~
> | kvfree
> drivers/scsi/lpfc/lpfc_debugfs.c: In function 'lpfc_debugfs_ras_log_open':
> drivers/scsi/lpfc/lpfc_debugfs.c:2150:18: error: implicit declaration of function 'vmalloc'; did you mean 'kvmalloc'? [-Werror=implicit-function-declaration]
> 2150 | debug->buffer = vmalloc(size);
> | ^~~~~~~
> | kvmalloc
> drivers/scsi/lpfc/lpfc_debugfs.c:2150:16: warning: assignment to 'char *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> 2150 | debug->buffer = vmalloc(size);
> | ^
>
> Caused by commit
>
> 95bfc6d8ad86 ("scsi: lpfc: Make FW logging dynamically configurable")
>
> I have used the scsi-mkp tree from next-20191024 for today.
This build failure now appears in the scsi tree build. I have applied the
fix from James Smart for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-10-28 5:49 ` Stephen Rothwell
@ 2019-10-29 2:28 ` Martin K. Petersen
2019-10-29 2:48 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2019-10-29 2:28 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, James Bottomley, Linux Next Mailing List,
Linux Kernel Mailing List, James Smart
Stephen,
>> I have used the scsi-mkp tree from next-20191024 for today.
>
> This build failure now appears in the scsi tree build. I have applied
> the fix from James Smart for today.
Should be fixed in my for-next now.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-10-29 2:28 ` Martin K. Petersen
@ 2019-10-29 2:48 ` Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2019-10-29 2:48 UTC (permalink / raw)
To: Martin K. Petersen
Cc: James Bottomley, Linux Next Mailing List,
Linux Kernel Mailing List, James Smart
[-- Attachment #1: Type: text/plain, Size: 459 bytes --]
Hi Martin,
On Mon, 28 Oct 2019 22:28:03 -0400 "Martin K. Petersen" <martin.petersen@oracle.com> wrote:
>
> >> I have used the scsi-mkp tree from next-20191024 for today.
> >
> > This build failure now appears in the scsi tree build. I have applied
> > the fix from James Smart for today.
>
> Should be fixed in my for-next now.
Thanks. I also see that James B has merged your tree, so its all good
now.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2019-04-09 6:27 Stephen Rothwell
2019-04-10 1:21 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2019-04-09 6:27 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Bart Van Assche
[-- Attachment #1: Type: text/plain, Size: 1090 bytes --]
Hi all,
After merging the scsi-mkp tree, today's linux-next build (powerpc
allyesconfig) failed like this:
drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_init_lport':
drivers/scsi/qla2xxx/tcm_qla2xxx.c:1614:3: error: implicit declaration of function 'vzalloc'; did you mean 'kvzalloc'? [-Werror=implicit-function-declaration]
vzalloc(array_size(65536,
^~~~~~~
kvzalloc
drivers/scsi/qla2xxx/tcm_qla2xxx.c:1613:26: warning: assignment to 'struct tcm_qla2xxx_fc_loopid *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
lport->lport_loopid_map =
^
drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_make_lport':
drivers/scsi/qla2xxx/tcm_qla2xxx.c:1677:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
vfree(lport->lport_loopid_map);
^~~~~
kvfree
Caused by commit
523c106ad4b1 ("scsi: tcm_qla2xxx: Minimize #include directives")
I have reverted that commit for today.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-04-09 6:27 Stephen Rothwell
@ 2019-04-10 1:21 ` Stephen Rothwell
2019-04-10 1:33 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2019-04-10 1:21 UTC (permalink / raw)
To: James Bottomley
Cc: Martin K. Petersen, Linux Next Mailing List,
Linux Kernel Mailing List, Bart Van Assche
[-- Attachment #1: Type: text/plain, Size: 1258 bytes --]
Hi all,
On Tue, 9 Apr 2019 16:27:49 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> allyesconfig) failed like this:
>
> drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_init_lport':
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1614:3: error: implicit declaration of function 'vzalloc'; did you mean 'kvzalloc'? [-Werror=implicit-function-declaration]
> vzalloc(array_size(65536,
> ^~~~~~~
> kvzalloc
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1613:26: warning: assignment to 'struct tcm_qla2xxx_fc_loopid *' from 'int' makes pointer from integer without a cast [-Wint-conversion]
> lport->lport_loopid_map =
> ^
> drivers/scsi/qla2xxx/tcm_qla2xxx.c: In function 'tcm_qla2xxx_make_lport':
> drivers/scsi/qla2xxx/tcm_qla2xxx.c:1677:2: error: implicit declaration of function 'vfree'; did you mean 'kvfree'? [-Werror=implicit-function-declaration]
> vfree(lport->lport_loopid_map);
> ^~~~~
> kvfree
>
> Caused by commit
>
> 523c106ad4b1 ("scsi: tcm_qla2xxx: Minimize #include directives")
>
> I have reverted that commit for today.
This has now migrated to the scsi tree.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-04-10 1:21 ` Stephen Rothwell
@ 2019-04-10 1:33 ` Martin K. Petersen
2019-04-10 4:04 ` James Bottomley
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2019-04-10 1:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Bottomley, Martin K. Petersen, Linux Next Mailing List,
Linux Kernel Mailing List, Bart Van Assche
Stephen,
>> I have reverted that commit for today.
>
> This has now migrated to the scsi tree.
I have a fix in my tree but I haven't pushed it yet.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-04-10 1:33 ` Martin K. Petersen
@ 2019-04-10 4:04 ` James Bottomley
2019-04-10 4:57 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: James Bottomley @ 2019-04-10 4:04 UTC (permalink / raw)
To: Martin K. Petersen, Stephen Rothwell
Cc: Linux Next Mailing List, Linux Kernel Mailing List, Bart Van Assche
On Tue, 2019-04-09 at 21:33 -0400, Martin K. Petersen wrote:
> Stephen,
>
> > > I have reverted that commit for today.
> >
> > This has now migrated to the scsi tree.
>
> I have a fix in my tree but I haven't pushed it yet.
It's upstream in both trees now.
James
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2019-04-10 4:04 ` James Bottomley
@ 2019-04-10 4:57 ` Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2019-04-10 4:57 UTC (permalink / raw)
To: James Bottomley
Cc: Martin K. Petersen, Linux Next Mailing List,
Linux Kernel Mailing List, Bart Van Assche
[-- Attachment #1: Type: text/plain, Size: 471 bytes --]
Hi all,
On Wed, 10 Apr 2019 06:04:19 +0200 James Bottomley <James.Bottomley@HansenPartnership.com> wrote:
>
> On Tue, 2019-04-09 at 21:33 -0400, Martin K. Petersen wrote:
> >
> > > > I have reverted that commit for today.
> > >
> > > This has now migrated to the scsi tree.
> >
> > I have a fix in my tree but I haven't pushed it yet.
>
> It's upstream in both trees now.
Thanks, it'll be in -next tomorrow.
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2018-03-22 6:25 Stephen Rothwell
2018-03-22 16:33 ` Madhani, Himanshu
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2018-03-22 6:25 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, Darren Trapp,
Himanshu Madhani, Quinn Tran
[-- Attachment #1: Type: text/plain, Size: 2637 bytes --]
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
drivers/scsi/qla2xxx/qla_gs.c:3974:7: error: 'fc4type' undeclared (first use in this function); did you mean 'fc4type_t'?
if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
^~~~~~~
fc4type_t
drivers/scsi/qla2xxx/qla_gs.c:3974:7: note: each undeclared identifier is reported only once for each function it appears in
drivers/scsi/qla2xxx/qla_gs.c:3975:3: error: too few arguments to function 'qla24xx_async_gpnft'
qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
^~~~~~~~~~~~~~~~~~~
In file included from drivers/scsi/qla2xxx/qla_def.h:4633:0,
from drivers/scsi/qla2xxx/qla_gs.c:7:
drivers/scsi/qla2xxx/qla_gbl.h:661:5: note: declared here
int qla24xx_async_gpnft(scsi_qla_host_t *, u8, srb_t *);
^~~~~~~~~~~~~~~~~~~
Caused by commit
33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")
interacting with commit
2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
from Linus' tree.
I have added the following merge fix patch for today. Unfortunately it
produces this warning, so a better merge resolution is needed ...
drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
drivers/scsi/qla2xxx/qla_gs.c:3974:9: warning: 'rp' may be used uninitialized in this function [-Wmaybe-uninitialized]
if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
~~^~~~~~~~~
From: Stephen Rothwell <sfr@canb.auug.org.au>
Date: Thu, 22 Mar 2018 17:09:38 +1100
Subject: [PATCH] scsi: qla2xxx: merge fix in qla_gs.c
Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
---
drivers/scsi/qla2xxx/qla_gs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index f84807e850c3..d33f4619332e 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -3971,8 +3971,8 @@ void qla24xx_async_gnnft_done(scsi_qla_host_t *vha, srb_t *sp)
vha->scan.scan_flags &= ~SF_SCANNING;
spin_unlock_irqrestore(&vha->work_lock, flags);
- if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
- qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
+ if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
+ qla24xx_async_gpnft(vha, FC4_TYPE_NVME, NULL);
}
static void qla2x00_find_free_fcp_nvme_slot(struct scsi_qla_host *vha,
--
2.16.1
--
Cheers,
Stephen Rothwell
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 488 bytes --]
^ permalink raw reply related [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2018-03-22 6:25 Stephen Rothwell
@ 2018-03-22 16:33 ` Madhani, Himanshu
0 siblings, 0 replies; 79+ messages in thread
From: Madhani, Himanshu @ 2018-03-22 16:33 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, Linux-Next Mailing List,
Linux Kernel Mailing List, Trapp, Darren, Tran, Quinn
Hi Stephen,
> On Mar 21, 2018, at 11:25 PM, Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> Hi Martin,
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
> drivers/scsi/qla2xxx/qla_gs.c:3974:7: error: 'fc4type' undeclared (first use in this function); did you mean 'fc4type_t'?
> if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
> ^~~~~~~
> fc4type_t
> drivers/scsi/qla2xxx/qla_gs.c:3974:7: note: each undeclared identifier is reported only once for each function it appears in
> drivers/scsi/qla2xxx/qla_gs.c:3975:3: error: too few arguments to function 'qla24xx_async_gpnft'
> qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
> ^~~~~~~~~~~~~~~~~~~
> In file included from drivers/scsi/qla2xxx/qla_def.h:4633:0,
> from drivers/scsi/qla2xxx/qla_gs.c:7:
> drivers/scsi/qla2xxx/qla_gbl.h:661:5: note: declared here
> int qla24xx_async_gpnft(scsi_qla_host_t *, u8, srb_t *);
> ^~~~~~~~~~~~~~~~~~~
>
> Caused by commit
>
> 33b28357dd00 ("scsi: qla2xxx: Fix Async GPN_FT for FCP and FC-NVMe scan")
>
> interacting with commit
>
> 2b5b96473efc ("scsi: qla2xxx: Fix FC-NVMe LUN discovery")
>
> from Linus' tree.
>
> I have added the following merge fix patch for today. Unfortunately it
> produces this warning, so a better merge resolution is needed ...
>
> drivers/scsi/qla2xxx/qla_gs.c: In function 'qla24xx_async_gnnft_done':
> drivers/scsi/qla2xxx/qla_gs.c:3974:9: warning: 'rp' may be used uninitialized in this function [-Wmaybe-uninitialized]
> if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
> ~~^~~~~~~~~
>
>
> From: Stephen Rothwell <sfr@canb.auug.org.au>
> Date: Thu, 22 Mar 2018 17:09:38 +1100
> Subject: [PATCH] scsi: qla2xxx: merge fix in qla_gs.c
>
> Signed-off-by: Stephen Rothwell <sfr@canb.auug.org.au>
> ---
> drivers/scsi/qla2xxx/qla_gs.c | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
> index f84807e850c3..d33f4619332e 100644
> --- a/drivers/scsi/qla2xxx/qla_gs.c
> +++ b/drivers/scsi/qla2xxx/qla_gs.c
> @@ -3971,8 +3971,8 @@ void qla24xx_async_gnnft_done(scsi_qla_host_t *vha, srb_t *sp)
> vha->scan.scan_flags &= ~SF_SCANNING;
> spin_unlock_irqrestore(&vha->work_lock, flags);
>
> - if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
> - qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
> + if ((rp->fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
> + qla24xx_async_gpnft(vha, FC4_TYPE_NVME, NULL);
> }
>
> static void qla2x00_find_free_fcp_nvme_slot(struct scsi_qla_host *vha,
> --
> 2.16.1
>
> --
> Cheers,
> Stephen Rothwell
Thanks so much to attempt to fix the build failure. I was aware of this issue and had
send the diff yesterday with change that should be used for resolving merge conflict and
compile failure.
Please use following to fix for the merge conflict and compile failure.
diff --git a/drivers/scsi/qla2xxx/qla_gs.c b/drivers/scsi/qla2xxx/qla_gs.c
index 403fa096f8c8..21eff2d30266 100644
--- a/drivers/scsi/qla2xxx/qla_gs.c
+++ b/drivers/scsi/qla2xxx/qla_gs.c
@@ -3973,9 +3973,6 @@ void qla24xx_async_gnnft_done(scsi_qla_host_t *vha, srb_t *sp)
spin_lock_irqsave(&vha->work_lock, flags);
vha->scan.scan_flags &= ~SF_SCANNING;
spin_unlock_irqrestore(&vha->work_lock, flags);
-
- if ((fc4type == FC4_TYPE_FCP_SCSI) && vha->flags.nvme_enabled)
- qla24xx_async_gpnft(vha, FC4_TYPE_NVME);
}
static void qla2x00_async_gpnft_gnnft_sp_done(void *s, int res)
diff --git a/drivers/scsi/qla2xxx/qla_os.c b/drivers/scsi/qla2xxx/qla_os.c
index 5c5dcca4d1da..dab847ba4bce 100644
--- a/drivers/scsi/qla2xxx/qla_os.c
+++ b/drivers/scsi/qla2xxx/qla_os.c
@@ -4822,9 +4822,10 @@ void qla24xx_create_new_sess(struct scsi_qla_host *vha, struct qla_work_evt *e)
fcport->d_id = e->u.new_sess.id;
fcport->flags |= FCF_FABRIC_DEVICE;
fcport->fw_login_state = DSC_LS_PLOGI_PEND;
- if (e->u.new_sess.fc4_type == FC4_TYPE_FCP_SCSI) {
+ if (e->u.new_sess.fc4_type & FC4_TYPE_FCP_SCSI)
fcport->fc4_type = FC4_TYPE_FCP_SCSI;
- } else if (e->u.new_sess.fc4_type == FC4_TYPE_NVME) {
+
+ if (e->u.new_sess.fc4_type & FC4_TYPE_NVME) {
fcport->fc4_type = FC4_TYPE_OTHER;
fcport->fc4f_nvme = FC4_TYPE_NVME;
}
(END)
Thanks,
- Himanshu
^ permalink raw reply related [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2017-05-17 2:57 Stephen Rothwell
0 siblings, 0 replies; 79+ messages in thread
From: Stephen Rothwell @ 2017-05-17 2:57 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Linux-Next Mailing List, Linux Kernel Mailing List, James Smart,
Dick Kennedy, Hannes Reinecke
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
Caused by commit
a8cf5dfeb4d8 ("scsi: lpfc: Added recovery logic for running out of NVMET IO context resources")
CONFIG_NVME_TARGET_FC is not set for this build.
I have used the scsi-mkp tree from next-20170516 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* linux-next: build failure after merge of the scsi-mkp tree
@ 2017-02-23 3:12 Stephen Rothwell
2017-02-23 14:19 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-02-23 3:12 UTC (permalink / raw)
To: Martin K. Petersen
Cc: linux-next, linux-kernel, Nilesh Javali, Manish Rangankar,
Saurav Kashyap, Arun Easi, Chad Dupuis
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (x86_64
allmodconfig) failed like this:
drivers/scsi/qedf/qedf_io.c: In function 'qedf_trace_io':
drivers/scsi/qedf/qedf_io.c:1001:33: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
io_log->refcount = atomic_read(&io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from drivers/scsi/qedf/qedf_io.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
drivers/scsi/qedf/qedf_io.c: In function 'qedf_scsi_completion':
drivers/scsi/qedf/qedf_io.c:1343:27: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
refcount = atomic_read(&io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from drivers/scsi/qedf/qedf_io.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
drivers/scsi/qedf/qedf_io.c: In function 'qedf_scsi_done':
drivers/scsi/qedf/qedf_io.c:1428:25: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
refcount = atomic_read(&io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from drivers/scsi/qedf/qedf_io.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
In file included from drivers/scsi/qedf/qedf.h:28:0,
from drivers/scsi/qedf/qedf_io.c:11:
drivers/scsi/qedf/qedf_io.c: In function 'qedf_flush_els_req':
drivers/scsi/qedf/qedf_io.c:1559:18: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
atomic_read(&els_req->refcount.refcount));
^
drivers/scsi/qedf/qedf_dbg.h:83:13: note: in definition of macro 'QEDF_INFO'
## __VA_ARGS__)
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from drivers/scsi/qedf/qedf_io.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
drivers/scsi/qedf/qedf_els.c: In function 'qedf_rrq_compl':
drivers/scsi/qedf/qedf_els.c:186:25: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
refcount = atomic_read(&orig_io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mm_types.h:8,
from include/linux/kmemcheck.h:4,
from include/linux/skbuff.h:18,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from include/scsi/libfcoe.h:24,
from drivers/scsi/qedf/qedf.h:12,
from drivers/scsi/qedf/qedf_els.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
drivers/scsi/qedf/qedf_els.c: In function 'qedf_srr_compl':
drivers/scsi/qedf/qedf_els.c:477:25: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
refcount = atomic_read(&orig_io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mm_types.h:8,
from include/linux/kmemcheck.h:4,
from include/linux/skbuff.h:18,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from include/scsi/libfcoe.h:24,
from drivers/scsi/qedf/qedf.h:12,
from drivers/scsi/qedf/qedf_els.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
drivers/scsi/qedf/qedf_els.c: In function 'qedf_rec_compl':
drivers/scsi/qedf/qedf_els.c:761:25: error: passing argument 1 of 'atomic_read' from incompatible pointer type [-Werror=incompatible-pointer-types]
refcount = atomic_read(&orig_io_req->refcount.refcount);
^
In file included from arch/x86/include/asm/msr.h:66:0,
from arch/x86/include/asm/processor.h:20,
from arch/x86/include/asm/cpufeature.h:4,
from arch/x86/include/asm/thread_info.h:52,
from include/linux/thread_info.h:25,
from arch/x86/include/asm/preempt.h:6,
from include/linux/preempt.h:59,
from include/linux/spinlock.h:50,
from include/linux/mm_types.h:8,
from include/linux/kmemcheck.h:4,
from include/linux/skbuff.h:18,
from include/linux/if_ether.h:23,
from include/linux/etherdevice.h:25,
from include/scsi/libfcoe.h:24,
from drivers/scsi/qedf/qedf.h:12,
from drivers/scsi/qedf/qedf_els.c:9:
arch/x86/include/asm/atomic.h:24:28: note: expected 'const atomic_t * {aka const struct <anonymous> *}' but argument is of type 'refcount_t * {aka struct refcount_struct *}'
static __always_inline int atomic_read(const atomic_t *v)
^
Caused by commit
61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE driver framework")
being rebased on top of commit
10383aea2f44 ("kref: Implement 'struct kref' using refcount_t")
and not using kref_read() to access the refcounts.
I don't understand why you would rebase you work onto Linus' tree in
the middle of the merge window in any case. :-(
I have used the scsi-mkp tree from next-20170221 again.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-23 3:12 Stephen Rothwell
@ 2017-02-23 14:19 ` Martin K. Petersen
2017-02-23 15:04 ` Chad Dupuis
0 siblings, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2017-02-23 14:19 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, linux-next, linux-kernel, Nilesh Javali,
Manish Rangankar, Saurav Kashyap, Arun Easi, Chad Dupuis
>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:
Stephen,
Stephen> Caused by commit
Stephen> 61d8658b4a43 ("scsi: qedf: Add QLogic FastLinQ offload FCoE
Stephen> driver framework")
Stephen> being rebased on top of commit
Stephen> 10383aea2f44 ("kref: Implement 'struct kref' using
Stephen> refcount_t")
Stephen> and not using kref_read() to access the refcounts.
*sigh*
Chad: Please fix these up ASAP.
Stephen> I don't understand why you would rebase you work onto Linus'
Stephen> tree in the middle of the merge window in any case. :-(
I didn't rebase my existing patch queue. I started a new for-next based
on linus/master. Half of this new QLogic driver lives under net so I had
to wait for Linus to pull DaveM's tree before I could merge the SCSI
portion :(
We often have to do two-stage merge windows with SCSI because of
dependencies on changes in both block and net (the latter increasingly
so because of the popularity of converged adapters that do both networks
and storage).
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-23 14:19 ` Martin K. Petersen
@ 2017-02-23 15:04 ` Chad Dupuis
0 siblings, 0 replies; 79+ messages in thread
From: Chad Dupuis @ 2017-02-23 15:04 UTC (permalink / raw)
To: Martin K. Petersen
Cc: Stephen Rothwell, linux-next, linux-kernel, Nilesh Javali,
Manish Rangankar, Saurav Kashyap, Arun Easi
On Thu, 23 Feb 2017, 2:19pm -0000, Martin K. Petersen wrote:
>
> *sigh*
>
> Chad: Please fix these up ASAP.
>
>
Just submitted a patch to the list to fix this up. I tested against the
mainline which has the net-next merge and the kref refcount_t conversion
to verify.
^ permalink raw reply [flat|nested] 79+ messages in thread
* linux-next: build failure after merge of the scsi-mkp tree
@ 2017-02-22 2:41 Stephen Rothwell
2017-02-22 21:06 ` Stephen Rothwell
0 siblings, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-02-22 2:41 UTC (permalink / raw)
To: Martin K. Petersen
Cc: linux-next, linux-kernel, James Smart, Dick Kennedy, Hannes Reinecke
Hi Martin,
After merging the scsi-mkp tree, today's linux-next build (powerpc
ppc64_defconfig) failed like this:
ERROR: ".nvme_fc_unregister_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_unregister_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_rcv_ls_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_register_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvme_fc_register_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_register_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
ERROR: ".nvmet_fc_unregister_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
Caused by commit
462896e1808c ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")
# CONFIG_NVME_FC is not set
Presumably a missing dependency.
I have used the scsi-mkp from next-20170221 for today.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-22 2:41 Stephen Rothwell
@ 2017-02-22 21:06 ` Stephen Rothwell
2017-02-22 21:10 ` Martin K. Petersen
2017-02-27 1:54 ` Stephen Rothwell
0 siblings, 2 replies; 79+ messages in thread
From: Stephen Rothwell @ 2017-02-22 21:06 UTC (permalink / raw)
To: James Bottomley
Cc: Martin K. Petersen, linux-next, linux-kernel, James Smart,
Dick Kennedy, Hannes Reinecke
Hi James,
On Wed, 22 Feb 2017 13:41:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> After merging the scsi-mkp tree, today's linux-next build (powerpc
> ppc64_defconfig) failed like this:
>
> ERROR: ".nvme_fc_unregister_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvme_fc_unregister_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvmet_fc_rcv_ls_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvme_fc_register_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvme_fc_register_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvmet_fc_register_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> ERROR: ".nvmet_fc_unregister_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
>
> Caused by commit
>
> 462896e1808c ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")
>
> # CONFIG_NVME_FC is not set
>
> Presumably a missing dependency.
>
> I have used the scsi-mkp from next-20170221 for today.
Unfortunately, you have just merged this build failure into the scsi
tree :-(
James Smart has posted a fix:
"[PATCH v2] lpfc: add missing Kconfig NVME dependencies"
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-22 21:06 ` Stephen Rothwell
@ 2017-02-22 21:10 ` Martin K. Petersen
2017-02-22 21:13 ` James Bottomley
2017-02-27 1:54 ` Stephen Rothwell
1 sibling, 1 reply; 79+ messages in thread
From: Martin K. Petersen @ 2017-02-22 21:10 UTC (permalink / raw)
To: Stephen Rothwell
Cc: James Bottomley, Martin K. Petersen, linux-next, linux-kernel,
James Smart, Dick Kennedy, Hannes Reinecke
>>>>> "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au> writes:
Stephen,
Stephen> Unfortunately, you have just merged this build failure into the
Stephen> scsi tree :-(
Stephen> James Smart has posted a fix:
Stephen> "[PATCH v2] lpfc: add missing Kconfig NVME dependencies"
I'll get the queued up shortly.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-22 21:10 ` Martin K. Petersen
@ 2017-02-22 21:13 ` James Bottomley
2017-02-22 21:17 ` Martin K. Petersen
0 siblings, 1 reply; 79+ messages in thread
From: James Bottomley @ 2017-02-22 21:13 UTC (permalink / raw)
To: Martin K. Petersen, Stephen Rothwell
Cc: linux-next, linux-kernel, James Smart, Dick Kennedy, Hannes Reinecke
On Wed, 2017-02-22 at 16:10 -0500, Martin K. Petersen wrote:
> > > > > > "Stephen" == Stephen Rothwell <sfr@canb.auug.org.au>
> > > > > > writes:
>
> Stephen,
>
> Stephen> Unfortunately, you have just merged this build failure into
> the
> Stephen> scsi tree :-(
>
> Stephen> James Smart has posted a fix:
>
> Stephen> "[PATCH v2] lpfc: add missing Kconfig NVME dependencies"
>
> I'll get the queued up shortly.
Perhaps it would be nice to rebase so we don't get bisect into a build
failure.
James
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-22 21:13 ` James Bottomley
@ 2017-02-22 21:17 ` Martin K. Petersen
0 siblings, 0 replies; 79+ messages in thread
From: Martin K. Petersen @ 2017-02-22 21:17 UTC (permalink / raw)
To: James Bottomley
Cc: Martin K. Petersen, Stephen Rothwell, linux-next, linux-kernel,
James Smart, Dick Kennedy, Hannes Reinecke
>>>>> "James" == James Bottomley <James.Bottomley@HansenPartnership.com> writes:
James> Perhaps it would be nice to rebase so we don't get bisect into a
James> build failure.
My plan was to start 4.11/scsi-fixes based on linus/master. I need block
and net to satisfy dependencies for the remaining patches in the queue.
--
Martin K. Petersen Oracle Linux Engineering
^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-22 21:06 ` Stephen Rothwell
2017-02-22 21:10 ` Martin K. Petersen
@ 2017-02-27 1:54 ` Stephen Rothwell
2017-02-27 15:25 ` James Bottomley
1 sibling, 1 reply; 79+ messages in thread
From: Stephen Rothwell @ 2017-02-27 1:54 UTC (permalink / raw)
To: James Bottomley
Cc: Martin K. Petersen, linux-next, linux-kernel, James Smart,
Dick Kennedy, Hannes Reinecke
Hi James,
On Thu, 23 Feb 2017 08:06:39 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 22 Feb 2017 13:41:19 +1100 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >
> > After merging the scsi-mkp tree, today's linux-next build (powerpc
> > ppc64_defconfig) failed like this:
> >
> > ERROR: ".nvme_fc_unregister_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvme_fc_unregister_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvmet_fc_rcv_ls_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvme_fc_register_localport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvme_fc_register_remoteport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvmet_fc_register_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> > ERROR: ".nvmet_fc_unregister_targetport" [drivers/scsi/lpfc/lpfc.ko] undefined!
> >
> > Caused by commit
> >
> > 462896e1808c ("scsi: lpfc: NVME Initiator: bind to nvme_fc api")
> >
> > # CONFIG_NVME_FC is not set
> >
> > Presumably a missing dependency.
> >
> > I have used the scsi-mkp from next-20170221 for today.
>
> Unfortunately, you have just merged this build failure into the scsi
> tree :-(
>
> James Smart has posted a fix:
>
> "[PATCH v2] lpfc: add missing Kconfig NVME dependencies"
I am still getting this failure in the scsi tree even though a fix has
been merged into the scsi-mkp tree a few days ago.
--
Cheers,
Stephen Rothwell
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: linux-next: build failure after merge of the scsi-mkp tree
2017-02-27 1:54 ` Stephen Rothwell
@ 2017-02-27 15:25 ` James Bottomley
0 siblings, 0 replies; 79+ messages in thread
From: James Bottomley @ 2017-02-27 15:25 UTC (permalink / raw)
To: Stephen Rothwell
Cc: Martin K. Petersen, linux-next, linux-kernel, James Smart,
Dick Kennedy, Hannes Reinecke
On Mon, 2017-02-27 at 12:54 +1100, Stephen Rothwell wrote:
> Hi James,
>
> On Thu, 23 Feb 2017 08:06:39 +1100 Stephen Rothwell <
> sfr@canb.auug.org.au> wrote:
> >
> > On Wed, 22 Feb 2017 13:41:19 +1100 Stephen Rothwell <
> > sfr@canb.auug.org.au> wrote:
> > >
> > > After merging the scsi-mkp tree, today's linux-next build
> > > (powerpc
> > > ppc64_defconfig) failed like this:
> > >
> > > ERROR: ".nvme_fc_unregister_remoteport"
> > > [drivers/scsi/lpfc/lpfc.ko] undefined!
> > > ERROR: ".nvme_fc_unregister_localport"
> > > [drivers/scsi/lpfc/lpfc.ko] undefined!
> > > ERROR: ".nvmet_fc_rcv_ls_req" [drivers/scsi/lpfc/lpfc.ko]
> > > undefined!
> > > ERROR: ".nvmet_fc_rcv_fcp_req" [drivers/scsi/lpfc/lpfc.ko]
> > > undefined!
> > > ERROR: ".nvme_fc_register_localport" [drivers/scsi/lpfc/lpfc.ko]
> > > undefined!
> > > ERROR: ".nvme_fc_register_remoteport" [drivers/scsi/lpfc/lpfc.ko]
> > > undefined!
> > > ERROR: ".nvmet_fc_register_targetport"
> > > [drivers/scsi/lpfc/lpfc.ko] undefined!
> > > ERROR: ".nvmet_fc_unregister_targetport"
> > > [drivers/scsi/lpfc/lpfc.ko] undefined!
> > >
> > > Caused by commit
> > >
> > > 462896e1808c ("scsi: lpfc: NVME Initiator: bind to nvme_fc
> > > api")
> > >
> > > # CONFIG_NVME_FC is not set
> > >
> > > Presumably a missing dependency.
> > >
> > > I have used the scsi-mkp from next-20170221 for today.
> >
> > Unfortunately, you have just merged this build failure into the
> > scsi tree :-(
> >
> > James Smart has posted a fix:
> >
> > "[PATCH v2] lpfc: add missing Kconfig NVME dependencies"
>
> I am still getting this failure in the scsi tree even though a fix
> has been merged into the scsi-mkp tree a few days ago.
Sorry, was in meeting hell for the last part of last week. Everything
should be up to date now. The final pull for all of this should go out
Wed/Thu to give 0day a good run at the tree.
James
^ permalink raw reply [flat|nested] 79+ messages in thread
end of thread, other threads:[~2024-04-12 10:44 UTC | newest]
Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-12-07 3:57 linux-next: build failure after merge of the scsi-mkp tree Stephen Rothwell
2017-12-07 3:59 ` Bart Van Assche
2017-12-07 4:25 ` Stephen Rothwell
2017-12-07 4:42 ` Paul E. McKenney
2017-12-07 17:30 ` Bart Van Assche
2017-12-07 17:40 ` Paul E. McKenney
2017-12-07 20:34 ` Stephen Rothwell
2017-12-07 21:10 ` Paul E. McKenney
2017-12-07 21:11 ` Martin K. Petersen
2017-12-08 1:00 ` Martin K. Petersen
2017-12-11 17:43 ` Paul E. McKenney
-- strict thread matches above, loose matches on Subject: below --
2024-04-12 5:46 Stephen Rothwell
2024-04-12 6:09 ` Christoph Hellwig
2024-04-12 10:22 ` Martin K. Petersen
2024-04-12 10:44 ` Martin K. Petersen
2024-03-27 2:45 Stephen Rothwell
2024-03-28 0:18 ` Martin K. Petersen
2023-08-22 5:32 Stephen Rothwell
2023-08-23 22:55 ` Stephen Rothwell
2023-08-23 22:59 ` Martin K. Petersen
2023-06-15 3:43 Stephen Rothwell
2023-06-15 4:19 ` Damien Le Moal
2023-06-16 16:51 ` Martin K. Petersen
2023-01-16 2:24 Stephen Rothwell
2023-01-16 17:55 ` Mike Christie
2023-01-16 18:07 ` Martin K. Petersen
2022-08-24 1:50 Stephen Rothwell
2022-08-29 4:54 ` Stephen Rothwell
2022-08-30 2:11 ` Martin K. Petersen
2022-04-27 3:38 Stephen Rothwell
2022-04-27 7:40 ` Sumit Saxena
2022-04-27 8:28 ` Stephen Rothwell
2021-08-17 9:47 Stephen Rothwell
2021-08-17 9:51 ` John Garry
2021-08-18 3:07 ` Bart Van Assche
2021-08-18 11:41 ` John Garry
2021-05-27 3:47 Stephen Rothwell
2021-03-12 3:17 Stephen Rothwell
2021-03-12 3:20 ` Jens Axboe
2021-01-25 4:13 Stephen Rothwell
2021-01-25 5:53 ` Douglas Gilbert
2021-01-27 7:01 ` Stephen Rothwell
2021-01-27 17:10 ` Douglas Gilbert
2020-12-08 9:28 Stephen Rothwell
2020-12-08 9:30 ` Christoph Hellwig
2020-12-08 10:01 ` Stephen Rothwell
2020-12-08 9:38 ` Stephen Rothwell
2020-12-08 17:55 ` Alan Stern
2020-12-08 19:56 ` Bart Van Assche
2020-07-21 6:30 Stephen Rothwell
2020-07-23 5:54 ` Stephen Rothwell
2020-07-23 15:01 ` Martin K. Petersen
2020-07-24 4:21 ` Kiwoong Kim
2020-01-22 4:10 Stephen Rothwell
2020-01-22 9:51 ` John Garry
2020-01-23 2:22 ` Martin K. Petersen
2019-10-25 3:07 Stephen Rothwell
2019-10-25 18:03 ` James Smart
2019-10-28 5:49 ` Stephen Rothwell
2019-10-29 2:28 ` Martin K. Petersen
2019-10-29 2:48 ` Stephen Rothwell
2019-04-09 6:27 Stephen Rothwell
2019-04-10 1:21 ` Stephen Rothwell
2019-04-10 1:33 ` Martin K. Petersen
2019-04-10 4:04 ` James Bottomley
2019-04-10 4:57 ` Stephen Rothwell
2018-03-22 6:25 Stephen Rothwell
2018-03-22 16:33 ` Madhani, Himanshu
2017-05-17 2:57 Stephen Rothwell
2017-02-23 3:12 Stephen Rothwell
2017-02-23 14:19 ` Martin K. Petersen
2017-02-23 15:04 ` Chad Dupuis
2017-02-22 2:41 Stephen Rothwell
2017-02-22 21:06 ` Stephen Rothwell
2017-02-22 21:10 ` Martin K. Petersen
2017-02-22 21:13 ` James Bottomley
2017-02-22 21:17 ` Martin K. Petersen
2017-02-27 1:54 ` Stephen Rothwell
2017-02-27 15:25 ` James Bottomley
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).