next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Mark Brown]

On Wed, Jul 11, 2018 at 05:23:59AM -0700, kernelci.org bot wrote:

Today's -next fails to boot on the Wandboards but only the i.MX
defconfg:

>     imx_v6_v7_defconfig:
>         imx6dl-wandboard_dual:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>         imx6dl-wandboard_solo:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>         imx6q-wandboard:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)

multi_v7_defconfig is fine, there are some failures on other platforms
but not i.MX.  The failures happen at a very similar point but the
precise oops varies (one was an illegal instruction):

| [    2.208738] caam 2100000.caam: job rings = 2, qi = 0
| [    2.227429] caam algorithms registered in /proc/crypto
| [    2.235409] Bad mode in data abort handler detected
| [    2.235433] caam_jr 2101000.jr0: job ring error: irqstate: 00000103
| [    2.240321] Internal error: Oops - bad mode: 0 [#1] SMP ARM
| [    2.252163] Modules linked in:

Full log and more details for the base wandboard at:

    https://kernelci.org/boot/id/5b45cf3b59b514f35b96ba95/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180711/eb11f5b1/attachment-0001.sig>

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Mark Brown]

On Wed, Jul 11, 2018 at 05:23:59AM -0700, kernelci.org bot wrote:

Today's -next fails to boot on a bunch of sunxi platforms  

>     sunxi_defconfig:
>         sun4i-a10-cubieboard:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>         sun7i-a20-bananapi:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>         sun7i-a20-cubietruck:
>             lab-baylibre-seattle: new failure (last pass: next-20180710)

multi_v7_defconfig seems fine.  It seems to get into userspace but not
far enough to get to a prompt, the failure seems similar on all the
platforms, full logs and other information can be found here:

    https://kernelci.org/boot/id/5b45cfd759b514f3e696ba93/
    https://kernelci.org/boot/id/5b45cfda59b514f41a96ba8f/
    https://kernelci.org/boot/id/5b45cfdd59b514f41796ba8e/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180711/a9e0bae0/attachment-0001.sig>

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Fabio Estevam]

Hi Mark,

On Wed, Jul 11, 2018 at 11:52 AM, Mark Brown <broonie@kernel.org> wrote:
> On Wed, Jul 11, 2018 at 05:23:59AM -0700, kernelci.org bot wrote:
>
> Today's -next fails to boot on the Wandboards but only the i.MX
> defconfg:
>
>>     imx_v6_v7_defconfig:
>>         imx6dl-wandboard_dual:
>>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>>         imx6dl-wandboard_solo:
>>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>>         imx6q-wandboard:
>>             lab-baylibre-seattle: new failure (last pass: next-20180710)
>
> multi_v7_defconfig is fine, there are some failures on other platforms
> but not i.MX.  The failures happen at a very similar point but the
> precise oops varies (one was an illegal instruction):
>
> | [    2.208738] caam 2100000.caam: job rings = 2, qi = 0
> | [    2.227429] caam algorithms registered in /proc/crypto
> | [    2.235409] Bad mode in data abort handler detected
> | [    2.235433] caam_jr 2101000.jr0: job ring error: irqstate: 00000103
> | [    2.240321] Internal error: Oops - bad mode: 0 [#1] SMP ARM
> | [    2.252163] Modules linked in:
>
> Full log and more details for the base wandboard at:
>
>     https://kernelci.org/boot/id/5b45cf3b59b514f35b96ba95/

This is caused by the following commit in linux-next:

commit f9b6e485fa ("crypto: caam: cleanup CONFIG_64BIT ifdefs when
using io{read|write}64")

I have already reported this issue on a linux-next tree from last week
and Stephen said he was going to drop such commit:
https://patchwork.kernel.org/patch/10507333/

but it reappeared today's linux-next.

Stephen, Andrew

Could you please drop it?

Thanks

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Stephen Rothwell]

Hi,

On Wed, 11 Jul 2018 12:09:15 -0300 Fabio Estevam <festevam@gmail.com> wrote:
>
> This is caused by the following commit in linux-next:
> 
> commit f9b6e485fa ("crypto: caam: cleanup CONFIG_64BIT ifdefs when
> using io{read|write}64")
> 
> I have already reported this issue on a linux-next tree from last week
> and Stephen said he was going to drop such commit:
> https://patchwork.kernel.org/patch/10507333/
> 
> but it reappeared today's linux-next.
> 
> Stephen, Andrew
> 
> Could you please drop it?

OK, I have dropped it (again).

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180712/9d1433ad/attachment.sig>

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Stephen Rothwell]

Hi Andrew,

On Thu, 12 Jul 2018 10:08:09 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
> On Wed, 11 Jul 2018 12:09:15 -0300 Fabio Estevam <festevam@gmail.com> wrote:
> >
> > This is caused by the following commit in linux-next:
> > 
> > commit f9b6e485fa ("crypto: caam: cleanup CONFIG_64BIT ifdefs when
> > using io{read|write}64")
> > 
> > I have already reported this issue on a linux-next tree from last week
> > and Stephen said he was going to drop such commit:
> > https://patchwork.kernel.org/patch/10507333/
> > 
> > but it reappeared today's linux-next.
> > 
> > Stephen, Andrew
> > 
> > Could you please drop it?  
> 
> OK, I have dropped it (again).

I have just imported the new mmotm, and that patch is still in there.
Has it been fixed, or do I need to remove it again?  (See the above
patchwork entry).

-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180714/a70f39da/attachment.sig>

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Logan Gunthorpe]

On 13/07/18 08:10 PM, Stephen Rothwell wrote:
> I have just imported the new mmotm, and that patch is still in there.
> Has it been fixed, or do I need to remove it again?  (See the above
> patchwork entry).

It has not been fixed. The consensus was to drop it.

@Andrew: I think we should drop the entire series seeing there was
another issue that cropped up earlier today after being in linux-next
(from Guenter Roeck). I will submit an updated v19 when I have a chance.
If you'd like me to handle this in a different way, let me know.

Thanks,

Logan

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Stephen Rothwell]

Hi Logan,

On Fri, 13 Jul 2018 20:19:23 -0600 Logan Gunthorpe <logang@deltatee.com> wrote:
>
> On 13/07/18 08:10 PM, Stephen Rothwell wrote:
> > I have just imported the new mmotm, and that patch is still in there.
> > Has it been fixed, or do I need to remove it again?  (See the above
> > patchwork entry).  
> 
> It has not been fixed. The consensus was to drop it.
> 
> @Andrew: I think we should drop the entire series seeing there was
> another issue that cropped up earlier today after being in linux-next
> (from Guenter Roeck). I will submit an updated v19 when I have a chance.
> If you'd like me to handle this in a different way, let me know.

OK, so I have removed the following from linux-next today:

0b845db3ac65 ntb: ntb_hw_switchtec: cleanup 64bit IO defines to use the common header
6d997075ea14 crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
9d235749060f ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
1a516b53c12d io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
ddc62940244b iomap: introduce io{read|write}64_{lo_hi|hi_lo}
6f595ae8ed85 parisc: iomap: introduce io{read|write}64
b68c7928b65d iomap: use non-raw io functions for io{read|write}XXbe

Let me know if that is correct or otherwise.
-- 
Cheers,
Stephen Rothwell
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://lists.infradead.org/pipermail/linux-arm-kernel/attachments/20180716/b16a9020/attachment.sig>

next/master boot: 184 boots: 13 failed, 171 passed (next-20180711)

[Logan Gunthorpe]

On 15/07/18 04:31 PM, Stephen Rothwell wrote:
> OK, so I have removed the following from linux-next today:
> 
> 0b845db3ac65 ntb: ntb_hw_switchtec: cleanup 64bit IO defines to use the common header
> 6d997075ea14 crypto: caam: cleanup CONFIG_64BIT ifdefs when using io{read|write}64
> 9d235749060f ntb: ntb_hw_intel: use io-64-nonatomic instead of in-driver hacks
> 1a516b53c12d io-64-nonatomic: add io{read|write}64[be]{_lo_hi|_hi_lo} macros
> ddc62940244b iomap: introduce io{read|write}64_{lo_hi|hi_lo}
> 6f595ae8ed85 parisc: iomap: introduce io{read|write}64
> b68c7928b65d iomap: use non-raw io functions for io{read|write}XXbe
> 
> Let me know if that is correct or otherwise.

That's correct.

Thanks,

Logan