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

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).

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.