Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Mark Brown]

On Mon, Aug 31, 2015 at 07:26:57PM +0100, Marc Zyngier wrote:

> which never considers bus to be NULL in __regmap_init. With the
> following patch applied, I can boot to a prompt:
> 
> From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001

> From: Marc Zyngier 
> Date: Mon, 31 Aug 2015 19:16:16 +0100
> Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Please submit patches using the process documented in SubmittingPatches,
don't bury them in the middle of a reply to some random other thread
where they can't be applied without handholding :(

> - map->max_raw_read = bus->max_raw_read;
> - map->max_raw_write = bus->max_raw_write;
> + map->max_raw_read = bus ? bus->max_raw_read : 0;
> + map->max_raw_write = bus ? bus->max_raw_write : 0;

A more legible version of this patch was already applied.


signature.asc
Description: Digital signature

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On 08/31/2015 12:13 PM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 11:57:14 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 11:26 AM, Marc Zyngier wrote:
[ ... ]


Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann 
Date:   Sun Aug 30 09:33:53 2015 +0200

  regmap: Introduce max_raw_read/write for regmap_bulk_read/write

  There are some buses which have a limit on the maximum number of
  bytes that can be send/received. An example for this is
  I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
  more than 32 bytes. The regmap_bulk operations should still be able
  to utilize the full 32 bytes in this case.

  Signed-off-by: Markus Pargmann 
  Signed-off-by: Mark Brown 

which never considers bus to be NULL in __regmap_init. With the
following patch applied, I can boot to a prompt:

  From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 19:16:16 +0100
Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Commit adaac459759d ("regmap: Introduce max_raw_read/write
for regmap_bulk_read/write") added new fields to regmap_bus
and started using them in __regmap_init, but failed to
consider the case where bus would be NULL, like in the
vexpress-syscgf case. The box (actually its qemu version)
ends up dying painfully.

Fix it by testing bus before doing anything else.

Signed-off-by: Marc Zyngier 


Yes, that fixes the vexpress failures.

Tested-by: Guenter Roeck 

However, I still need to revert your patches to get my realview-pb-a8
and realview-eb tests to work again.

I am a bit concerned about the use of of_address_to_resource(),
which can return an error, leaving cpu_res undefined. Also, if
both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
is set to true by default. This is the configuration used in my
failing tests.

With that in mind, I ran a simple test.

-static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
+static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;

Bingo, problem solved. Can you try to find a clean solution ?


Yeah, I just came to the same conclusion, and to the following patch:

 From 059bc80a4fc433dda99d75a712f30a77ce4964bc Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 20:00:35 +0100
Subject: [PATCH] irqchip/gic: Fix EOImode settiing non-DT/ACPI systems

Non-DT/ACPI systems call directly into the GIC driver at init time.
Since 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1"), this
breaks old non firmware-driven platforms, as the driver only
works out the capability of the platform on the DT/ACPI paths.

Fix this thinko by forcing EOImode==0 on non-DT platforms,
which are not capable of supporting a hypervisor anyway.

Signed-off-by: Marc Zyngier 


Yep, that fixes the problem.

Tested-by: Guenter Roeck 

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 11:57:14 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 11:26 AM, Marc Zyngier wrote:
> [ ... ]
> >
> > Actually, the kernel dies because of this:
> >
> > commit adaac459759db4a1fd35baddbe47bac700095496
> > Author: Markus Pargmann 
> > Date:   Sun Aug 30 09:33:53 2015 +0200
> >
> >  regmap: Introduce max_raw_read/write for regmap_bulk_read/write
> >
> >  There are some buses which have a limit on the maximum number of
> >  bytes that can be send/received. An example for this is
> >  I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
> >  more than 32 bytes. The regmap_bulk operations should still be able
> >  to utilize the full 32 bytes in this case.
> >
> >  Signed-off-by: Markus Pargmann 
> >  Signed-off-by: Mark Brown 
> >
> > which never considers bus to be NULL in __regmap_init. With the
> > following patch applied, I can boot to a prompt:
> >
> >  From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier 
> > Date: Mon, 31 Aug 2015 19:16:16 +0100
> > Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL
> >
> > Commit adaac459759d ("regmap: Introduce max_raw_read/write
> > for regmap_bulk_read/write") added new fields to regmap_bus
> > and started using them in __regmap_init, but failed to
> > consider the case where bus would be NULL, like in the
> > vexpress-syscgf case. The box (actually its qemu version)
> > ends up dying painfully.
> >
> > Fix it by testing bus before doing anything else.
> >
> > Signed-off-by: Marc Zyngier 
> 
> Yes, that fixes the vexpress failures.
> 
> Tested-by: Guenter Roeck 
> 
> However, I still need to revert your patches to get my realview-pb-a8
> and realview-eb tests to work again.
> 
> I am a bit concerned about the use of of_address_to_resource(),
> which can return an error, leaving cpu_res undefined. Also, if
> both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
> is set to true by default. This is the configuration used in my
> failing tests.
> 
> With that in mind, I ran a simple test.
> 
> -static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
> +static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;
> 
> Bingo, problem solved. Can you try to find a clean solution ?

Yeah, I just came to the same conclusion, and to the following patch:

>From 059bc80a4fc433dda99d75a712f30a77ce4964bc Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 20:00:35 +0100
Subject: [PATCH] irqchip/gic: Fix EOImode settiing non-DT/ACPI systems

Non-DT/ACPI systems call directly into the GIC driver at init time.
Since 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1"), this
breaks old non firmware-driven platforms, as the driver only
works out the capability of the platform on the DT/ACPI paths.

Fix this thinko by forcing EOImode==0 on non-DT platforms,
which are not capable of supporting a hypervisor anyway.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 72bf81b..e6b7ed5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -993,7 +993,7 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
.xlate = gic_irq_domain_xlate,
 };
 
-void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
   void __iomem *dist_base, void __iomem *cpu_base,
   u32 percpu_offset, struct device_node *node)
 {
@@ -1103,6 +1103,19 @@ void __init gic_init_bases(unsigned int gic_nr, int 
irq_start,
gic_pm_init(gic);
 }
 
+void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+  void __iomem *dist_base, void __iomem *cpu_base,
+  u32 percpu_offset, struct device_node *node)
+{
+   /*
+* Non-DT/ACPI systems won't run a hypervisor, so let's not
+* bother with these...
+*/
+   static_key_slow_dec(_deactivate);
+   __gic_init_bases(gic_nr, irq_start, dist_base, cpu_base,
+percpu_offset, node);
+}
+
 #ifdef CONFIG_OF
 static int gic_cnt __initdata;
 
@@ -1137,7 +1150,7 @@ gic_of_init(struct device_node *node, struct device_node 
*parent)
if (of_property_read_u32(node, "cpu-offset", _offset))
percpu_offset = 0;
 
-   gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
+   __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
if (!gic_cnt)
gic_init_physaddr(node);
 
@@ -1265,7 +1278,7 @@ gic_v2_acpi_init(struct acpi_table_header *table)
 * as default IRQ domain to allow for GSI registration and GSI to IRQ
 * number translation (see acpi_register_gsi() and 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 11:26 AM, Marc Zyngier wrote:
[ ... ]


Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann 
Date:   Sun Aug 30 09:33:53 2015 +0200

 regmap: Introduce max_raw_read/write for regmap_bulk_read/write

 There are some buses which have a limit on the maximum number of
 bytes that can be send/received. An example for this is
 I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
 more than 32 bytes. The regmap_bulk operations should still be able
 to utilize the full 32 bytes in this case.

 Signed-off-by: Markus Pargmann 
 Signed-off-by: Mark Brown 

which never considers bus to be NULL in __regmap_init. With the
following patch applied, I can boot to a prompt:

 From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 19:16:16 +0100
Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Commit adaac459759d ("regmap: Introduce max_raw_read/write
for regmap_bulk_read/write") added new fields to regmap_bus
and started using them in __regmap_init, but failed to
consider the case where bus would be NULL, like in the
vexpress-syscgf case. The box (actually its qemu version)
ends up dying painfully.

Fix it by testing bus before doing anything else.

Signed-off-by: Marc Zyngier 


Yes, that fixes the vexpress failures.

Tested-by: Guenter Roeck 

However, I still need to revert your patches to get my realview-pb-a8
and realview-eb tests to work again.

I am a bit concerned about the use of of_address_to_resource(),
which can return an error, leaving cpu_res undefined. Also, if
both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
is set to true by default. This is the configuration used in my
failing tests.

With that in mind, I ran a simple test.

-static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
+static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;

Bingo, problem solved. Can you try to find a clean solution ?

I wonder how it comes that you get a console output from qemu, but I don't.
Did you use multi_v7_defconfig or some other configuration ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On 08/31/2015 10:09 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 09:40:43 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 09:18 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.


I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.


Looks like it.

I did a couple of tests.
- Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
Same problem.
- Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
and 'irqchip/GIC: Convert to EOImode == 1'.
Problem is no longer seen.


This is getting even more weird. I've upgraded my qemu to 2.3 (the
latest Debian seems to be carrying). I'm booting a A15-TC1 model with
the following:

emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
-kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
-serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
none



After building multi_v7_defconfig, this fails for me as well (qemu hang
without console output) with both qemu 2.2 and qemu 2.4. This is with
both your and my command line.

Yes, turns out there are more failures. The only problem fixed by reverting
your patches was arm:realview-pb-a8:qemu_arm_realview_pb_defconfig as well as
arm:realview-eb:qemu_arm_realview_eb_defconfig. All the vexpress tests still
fail.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 18:09:22 +0100
Marc Zyngier  wrote:

Hi Guenter,

> On Mon, 31 Aug 2015 09:40:43 -0700
> Guenter Roeck  wrote:
> 
> > Hi Marc,
> > 
> > On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > > On Mon, 31 Aug 2015 08:47:07 -0700
> > > Guenter Roeck  wrote:
> > >
> > >> Hi Marc,
> > >>
> > >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > >>> On Mon, 31 Aug 2015 07:17:36 -0700
> > >>> Guenter Roeck  wrote:
> > >>>
> > >>> Hi Guenter,
> > >>>
> >  Qemu test results:
> > total: 85 pass: 74 fail: 11
> >  Failed tests:
> > arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
> > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> > arm:realview-pb-a8:arm_realview_pb_defconfig
> > arm:realview-eb:arm_realview_eb_defconfig
> > mips:fuloong2e_defconfig
> > xtensa:dc232b:lx60:xtensa_defconfig
> > xtensa:dc232b:kc705:xtensa_defconfig
> > xtensa:dc233c:ml605:generic_kc705_defconfig
> > xtensa:dc233c:kc705:generic_kc705_defconfi
> > 
> >  Notable new failures (since next-20150828) are the s390 build failures,
> >  the arm64 build failure, and the arm qemu test failures.
> > 
> > >>>
> > >>> [...]
> > >>>
> >  The qemu arm tests all fail silently, meaning there is no console
> >  output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> >  Bisect log attached.
> > >>>
> > >>> Could you give me a qemu command-line I can use to track this down?
> > >>> Real HW seems happy enough, from what I can see...
> > >>>
> > >>
> > >> That is what I was most concerned about :-(. Unfortunately, it
> > >> affects many of the most widely used arm qemu emulations, so it
> > >> would be very desirable to get this fixed, either in the kernel
> > >> or in qemu.
> > >>
> > >> See https://github.com/groeck/linux-build-test, specifically
> > >> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> > >> run-qemu-arm.sh includes the various command lines and configurations.
> > >>
> > >> Note that some of the tests require a patched version of qemu.
> > >> The tests failing above should all work with the latest published
> > >> version of qemu (2.4), though.
> > >>
> > >> Please let me know if there is anything I can do to help tracking
> > >> this down.
> > >
> > > I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
> > > results are interesting:
> > >
> > > - With -next as of today, qemu segfaults. Hump.
> > >
> > > - If I use my branch that contains the EOImode==1 patch, the system
> > >boots normally.
> > >
> > > So there is an interaction between this patch and whatever is in -next
> > > at the moment, but that patch on its own is not what triggers the issue.
> > >
> > Looks like it.
> > 
> > I did a couple of tests.
> > - Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
> >Same problem.
> > - Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a 
> > guest'
> >and 'irqchip/GIC: Convert to EOImode == 1'.
> >Problem is no longer seen.
> 
> This is getting even more weird. I've upgraded my qemu to 2.3 (the
> latest Debian seems to be carrying). I'm booting a A15-TC1 model with
> the following:
> 
> emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
> -kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
> -serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
> none
> 
> The model dies with:
> 
> [...]
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Unable to handle kernel NULL pointer dereference at virtual address 0030
> pgd = 80004000
> [0030] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150831+ #18
> Hardware name: ARM-Versatile Express
> task: 9f458000 ti: 9f446000 task.ti: 9f446000
> PC is at __regmap_init+0x15c/0xb18
> LR is at 0x0
> pc : [<802c3e50>]lr : [<>]psr: 4153
> sp : 9f447d00  ip :   fp : 
> r10:   r9 : 0001  r8 : 9f49f280
> r7 :   r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
> r3 :   r2 :   r1 : a4f4  r0 : 9f4ce400
> Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 8000406a  DAC: 0055
> Process swapper/0 (pid: 1, stack limit = 0x9f446210)
> Stack: (0x9f447d00 to 0x9f448000)
> 7d00: 806aa2b4 8059aa5c 9f4ce210 0001 9f4ce210  9f4ce210 9f49a610
> 7d20: 9f49f280 88000b18    802cb6a0  
> 7d40: 802663ec 0001   9f49f210 fdfb  
> 7d60: 9f49aa50 9f4ce210 9f49f250 fdfb  802664cc 9f4ce210 9f4ce200
> 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 09:40:43 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 08:47:07 -0700
> > Guenter Roeck  wrote:
> >
> >> Hi Marc,
> >>
> >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> >>> On Mon, 31 Aug 2015 07:17:36 -0700
> >>> Guenter Roeck  wrote:
> >>>
> >>> Hi Guenter,
> >>>
>  Qemu test results:
>   total: 85 pass: 74 fail: 11
>  Failed tests:
>   arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:realview-pb-a8:arm_realview_pb_defconfig
>   arm:realview-eb:arm_realview_eb_defconfig
>   mips:fuloong2e_defconfig
>   xtensa:dc232b:lx60:xtensa_defconfig
>   xtensa:dc232b:kc705:xtensa_defconfig
>   xtensa:dc233c:ml605:generic_kc705_defconfig
>   xtensa:dc233c:kc705:generic_kc705_defconfi
> 
>  Notable new failures (since next-20150828) are the s390 build failures,
>  the arm64 build failure, and the arm qemu test failures.
> 
> >>>
> >>> [...]
> >>>
>  The qemu arm tests all fail silently, meaning there is no console
>  output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
>  Bisect log attached.
> >>>
> >>> Could you give me a qemu command-line I can use to track this down?
> >>> Real HW seems happy enough, from what I can see...
> >>>
> >>
> >> That is what I was most concerned about :-(. Unfortunately, it
> >> affects many of the most widely used arm qemu emulations, so it
> >> would be very desirable to get this fixed, either in the kernel
> >> or in qemu.
> >>
> >> See https://github.com/groeck/linux-build-test, specifically
> >> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> >> run-qemu-arm.sh includes the various command lines and configurations.
> >>
> >> Note that some of the tests require a patched version of qemu.
> >> The tests failing above should all work with the latest published
> >> version of qemu (2.4), though.
> >>
> >> Please let me know if there is anything I can do to help tracking
> >> this down.
> >
> > I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
> > results are interesting:
> >
> > - With -next as of today, qemu segfaults. Hump.
> >
> > - If I use my branch that contains the EOImode==1 patch, the system
> >boots normally.
> >
> > So there is an interaction between this patch and whatever is in -next
> > at the moment, but that patch on its own is not what triggers the issue.
> >
> Looks like it.
> 
> I did a couple of tests.
> - Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
>Same problem.
> - Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
>and 'irqchip/GIC: Convert to EOImode == 1'.
>Problem is no longer seen.

This is getting even more weird. I've upgraded my qemu to 2.3 (the
latest Debian seems to be carrying). I'm booting a A15-TC1 model with
the following:

emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
-kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
-serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
none

The model dies with:

[...]
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Unable to handle kernel NULL pointer dereference at virtual address 0030
pgd = 80004000
[0030] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150831+ #18
Hardware name: ARM-Versatile Express
task: 9f458000 ti: 9f446000 task.ti: 9f446000
PC is at __regmap_init+0x15c/0xb18
LR is at 0x0
pc : [<802c3e50>]lr : [<>]psr: 4153
sp : 9f447d00  ip :   fp : 
r10:   r9 : 0001  r8 : 9f49f280
r7 :   r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
r3 :   r2 :   r1 : a4f4  r0 : 9f4ce400
Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8000406a  DAC: 0055
Process swapper/0 (pid: 1, stack limit = 0x9f446210)
Stack: (0x9f447d00 to 0x9f448000)
7d00: 806aa2b4 8059aa5c 9f4ce210 0001 9f4ce210  9f4ce210 9f49a610
7d20: 9f49f280 88000b18    802cb6a0  
7d40: 802663ec 0001   9f49f210 fdfb  
7d60: 9f49aa50 9f4ce210 9f49f250 fdfb  802664cc 9f4ce210 9f4ce200
7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
7da0: 9f4ce210 806826d0 0001 9f4ce210 9f4ce210 806826d0 fdfb 802b47f0
7dc0: 802b47ac 9f4ce210 806a805c 806826d0 0001 802b2f80  9f447e08
7de0: 802b30e8 0001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
7e00: 9f4ce244 802b2cb0 9f4ce210 0001 9f4ce218 9f4ce218 9f4ce210 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 09:18 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.


I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
   boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.


Looks like it.

I did a couple of tests.
- Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
  Same problem.
- Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
  and 'irqchip/GIC: Convert to EOImode == 1'.
  Problem is no longer seen.

There are several other patches in drivers/irqchip/irq-gic.c since 4.2.

4c2880b31c70 irqchip/gic: Ensure gic_cpu_if_up/down() programs correct GIC 
instance
567e5a014848 irqchip/gic: Only allow the primary GIC to set the CPU map
4b979e4c611c Merge branch 'linus' into irq/core
0d3f2c92e004 irqchip/gic: Remove redundant gic_set_irqchip_flags
aec89ef72ba6 irqchip/gic: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
5b29264c659c irqchip: Use irq_desc_get_xxx() to avoid redundant lookup of 
irq_desc
4d83fcf8d615 irqchip/gic: Consolidate chained IRQ handler install/remove
41a83e06e2bb irqchip: Prepare for local stub header removal

Maybe there is an interaction between those and your patch ?


I need to build a more recent version of qemu, but the above doesn't
fill be with confidence...


My patched version of qemu 2.4 doesn't crash for me, it simply hangs.
Not that this is much better.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 07:17:36 -0700
> > Guenter Roeck  wrote:
> >
> > Hi Guenter,
> >
> >> Qemu test results:
> >>total: 85 pass: 74 fail: 11
> >> Failed tests:
> >>arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
> >>arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> >>arm:realview-pb-a8:arm_realview_pb_defconfig
> >>arm:realview-eb:arm_realview_eb_defconfig
> >>mips:fuloong2e_defconfig
> >>xtensa:dc232b:lx60:xtensa_defconfig
> >>xtensa:dc232b:kc705:xtensa_defconfig
> >>xtensa:dc233c:ml605:generic_kc705_defconfig
> >>xtensa:dc233c:kc705:generic_kc705_defconfi
> >>
> >> Notable new failures (since next-20150828) are the s390 build failures,
> >> the arm64 build failure, and the arm qemu test failures.
> >>
> >
> > [...]
> >
> >> The qemu arm tests all fail silently, meaning there is no console
> >> output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> >> Bisect log attached.
> >
> > Could you give me a qemu command-line I can use to track this down?
> > Real HW seems happy enough, from what I can see...
> >
> 
> That is what I was most concerned about :-(. Unfortunately, it
> affects many of the most widely used arm qemu emulations, so it
> would be very desirable to get this fixed, either in the kernel
> or in qemu.
> 
> See https://github.com/groeck/linux-build-test, specifically
> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> run-qemu-arm.sh includes the various command lines and configurations.
> 
> Note that some of the tests require a patched version of qemu.
> The tests failing above should all work with the latest published
> version of qemu (2.4), though.
> 
> Please let me know if there is anything I can do to help tracking
> this down.

I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
  boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.

I need to build a more recent version of qemu, but the above doesn't
fill be with confidence...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,

> Qemu test results:
>   total: 85 pass: 74 fail: 11
> Failed tests:
>   arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:realview-pb-a8:arm_realview_pb_defconfig
>   arm:realview-eb:arm_realview_eb_defconfig
>   mips:fuloong2e_defconfig
>   xtensa:dc232b:lx60:xtensa_defconfig
>   xtensa:dc232b:kc705:xtensa_defconfig
>   xtensa:dc233c:ml605:generic_kc705_defconfig
>   xtensa:dc233c:kc705:generic_kc705_defconfi
> 
> Notable new failures (since next-20150828) are the s390 build failures,
> the arm64 build failure, and the arm qemu test failures.
> 

[...]

> The qemu arm tests all fail silently, meaning there is no console
> output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> Bisect log attached.

Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Alexei Starovoitov]

On 8/31/15 7:17 AM, Guenter Roeck wrote:

s390:

kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x116a5c): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x118ee0): undefined reference to `strncpy_from_unsafe'

Appears to be due to 'bpf: add support for %s specifier to bpf_trace_printk()'.


working on a fix...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On Mon, Aug 31, 2015 at 07:54:20PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20150828:
> 
> I used the h8300 tree from next-20150828 since the current tree has been
> rebased onto linux-next :-(
> 
> The sound-asoc tree lost its build failure.
> 
> The trivial tree gained a conflict against the drm tree.
> 
> The tty tree still had its build failure for which I reverted part of
> a commit.
> 
> The gpio tree gained a build failure so I used the version form
> next-20150828.
> 
> Non-merge commits (relative to Linus' tree): 10761
>  9636 files changed, 583138 insertions(+), 252790 deletions(-)
> 
> 
> 

Build results:
total: 145 pass: 135 fail: 10
Failed builds:
alpha:allmodconfig
arm:rpc_defconfig
arm64:allmodconfig
mips:allmodconfig
mips:nlm_xlp_defconfig
s390:defconfig
s390:allmodconfig
xtensa:defconfig
xtensa:allmodconfig
xtensa:allnoconfig

Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.

arm64:

drivers/built-in.o: In function `mtk_cpufreq_ready':
:(.text+0x27e124): undefined reference to `of_cpufreq_cooling_register'
drivers/built-in.o: In function `mtk_cpufreq_exit':
:(.text+0x27e31c): undefined reference to `cpufreq_cooling_unregister'

Most likely caused by 'cpufreq: mediatek: Add MT8173 cpufreq driver", but
I did not bisect.

s390:

kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x116a5c): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x118ee0): undefined reference to `strncpy_from_unsafe'

Appears to be due to 'bpf: add support for %s specifier to bpf_trace_printk()'.
Not bisected.

The qemu arm tests all fail silently, meaning there is no console output.
Bisect points to 'irqchip/GIC: Convert to EOImode == 1'. Bisect log attached.

Guenter

---
qemu arm bisect log:

# bad: [4da7932545f1474564af3b2558b738c7a15ed853] Add linux-next specific files 
for 20150831
# good: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
git bisect start 'HEAD' 'v4.2'
# good: [0b82dd97c3ae2056d3b5b7db156923f77e3cb675] Merge remote-tracking branch 
'drm/drm-next'
git bisect good 0b82dd97c3ae2056d3b5b7db156923f77e3cb675
# bad: [b7299a186f496145dfe87a59054b876fe1677309] Merge remote-tracking branch 
'tty/tty-next'
git bisect bad b7299a186f496145dfe87a59054b876fe1677309
# good: [71247c5f3351adb3c69321f9f2ba3e16ccee589e] Merge remote-tracking branch 
'mailbox/mailbox-for-next'
git bisect good 71247c5f3351adb3c69321f9f2ba3e16ccee589e
# bad: [99df9788ac9bc648e78b3b2a3c641e750e184c01] manual merge of sched/core
git bisect bad 99df9788ac9bc648e78b3b2a3c641e750e184c01
# bad: [b8ad55972c02c9ca6049d1bf7764e1650c1c8e56] Merge branch 'locking/core'
git bisect bad b8ad55972c02c9ca6049d1bf7764e1650c1c8e56
# good: [27baa4737cb762851e4c6f085e45f087d26bab2d] Merge branch 'core/types'
git bisect good 27baa4737cb762851e4c6f085e45f087d26bab2d
# good: [8505a81bb036253213b109baf4178ea6861e2888] genirq: Use the proper 
parameter name in kernel doc
git bisect good 8505a81bb036253213b109baf4178ea6861e2888
# good: [0b6a3da9617a08e13afc09cb7e148470ed0eb280] irqchip/GICv3: Convert to 
EOImode == 1
git bisect good 0b6a3da9617a08e13afc09cb7e148470ed0eb280
# good: [3bbfafb77a06327fa1bc9f19bc55b5c558475091] x86, tsc, 
locking/static_keys: Employ static_branch_likely()
git bisect good 3bbfafb77a06327fa1bc9f19bc55b5c558475091
# good: [f5468ffde13fc991bd4d6bdec507ffd5777865bd] locking/lockref: Remove 
homebrew cmpxchg64_relaxed() macro definition
git bisect good f5468ffde13fc991bd4d6bdec507ffd5777865bd
# good: [d420acd816c07c7be31bd19d09cbcb16e5572fa6] jump_label/x86: Work around 
asm build bug on older/backported GCCs
git bisect good d420acd816c07c7be31bd19d09cbcb16e5572fa6
# bad: [01f779f4862b53810ba4eb247f57bd1ad31d1c18] irqchip/GIC: Don't deactivate 
interrupts forwarded to a guest
git bisect bad 01f779f4862b53810ba4eb247f57bd1ad31d1c18
# bad: [0b996fd35957a30568cddbce05b917c1897966e0] irqchip/GIC: Convert to 
EOImode == 1
git bisect bad 0b996fd35957a30568cddbce05b917c1897966e0
# good: [530bf353e4eb06bcba5078390c949650cd26a7c7] irqchip/GICv3: 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Alexei Starovoitov]

On 8/31/15 7:17 AM, Guenter Roeck wrote:

s390:

kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x116a5c): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x118ee0): undefined reference to `strncpy_from_unsafe'

Appears to be due to 'bpf: add support for %s specifier to bpf_trace_printk()'.


working on a fix...

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,

> Qemu test results:
>   total: 85 pass: 74 fail: 11
> Failed tests:
>   arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:realview-pb-a8:arm_realview_pb_defconfig
>   arm:realview-eb:arm_realview_eb_defconfig
>   mips:fuloong2e_defconfig
>   xtensa:dc232b:lx60:xtensa_defconfig
>   xtensa:dc232b:kc705:xtensa_defconfig
>   xtensa:dc233c:ml605:generic_kc705_defconfig
>   xtensa:dc233c:kc705:generic_kc705_defconfi
> 
> Notable new failures (since next-20150828) are the s390 build failures,
> the arm64 build failure, and the arm qemu test failures.
> 

[...]

> The qemu arm tests all fail silently, meaning there is no console
> output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> Bisect log attached.

Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 07:17:36 -0700
> > Guenter Roeck  wrote:
> >
> > Hi Guenter,
> >
> >> Qemu test results:
> >>total: 85 pass: 74 fail: 11
> >> Failed tests:
> >>arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
> >>arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> >>arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> >>arm:realview-pb-a8:arm_realview_pb_defconfig
> >>arm:realview-eb:arm_realview_eb_defconfig
> >>mips:fuloong2e_defconfig
> >>xtensa:dc232b:lx60:xtensa_defconfig
> >>xtensa:dc232b:kc705:xtensa_defconfig
> >>xtensa:dc233c:ml605:generic_kc705_defconfig
> >>xtensa:dc233c:kc705:generic_kc705_defconfi
> >>
> >> Notable new failures (since next-20150828) are the s390 build failures,
> >> the arm64 build failure, and the arm qemu test failures.
> >>
> >
> > [...]
> >
> >> The qemu arm tests all fail silently, meaning there is no console
> >> output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> >> Bisect log attached.
> >
> > Could you give me a qemu command-line I can use to track this down?
> > Real HW seems happy enough, from what I can see...
> >
> 
> That is what I was most concerned about :-(. Unfortunately, it
> affects many of the most widely used arm qemu emulations, so it
> would be very desirable to get this fixed, either in the kernel
> or in qemu.
> 
> See https://github.com/groeck/linux-build-test, specifically
> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> run-qemu-arm.sh includes the various command lines and configurations.
> 
> Note that some of the tests require a patched version of qemu.
> The tests failing above should all work with the latest published
> version of qemu (2.4), though.
> 
> Please let me know if there is anything I can do to help tracking
> this down.

I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
  boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.

I need to build a more recent version of qemu, but the above doesn't
fill be with confidence...

Thanks,

M.
-- 
Jazz is not dead. It just smells funny.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 09:18 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.


I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
   boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.


Looks like it.

I did a couple of tests.
- Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
  Same problem.
- Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
  and 'irqchip/GIC: Convert to EOImode == 1'.
  Problem is no longer seen.

There are several other patches in drivers/irqchip/irq-gic.c since 4.2.

4c2880b31c70 irqchip/gic: Ensure gic_cpu_if_up/down() programs correct GIC 
instance
567e5a014848 irqchip/gic: Only allow the primary GIC to set the CPU map
4b979e4c611c Merge branch 'linus' into irq/core
0d3f2c92e004 irqchip/gic: Remove redundant gic_set_irqchip_flags
aec89ef72ba6 irqchip/gic: Enable SKIP_SET_WAKE and MASK_ON_SUSPEND
5b29264c659c irqchip: Use irq_desc_get_xxx() to avoid redundant lookup of 
irq_desc
4d83fcf8d615 irqchip/gic: Consolidate chained IRQ handler install/remove
41a83e06e2bb irqchip: Prepare for local stub header removal

Maybe there is an interaction between those and your patch ?


I need to build a more recent version of qemu, but the above doesn't
fill be with confidence...


My patched version of qemu 2.4 doesn't crash for me, it simply hangs.
Not that this is much better.

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 09:40:43 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 08:47:07 -0700
> > Guenter Roeck  wrote:
> >
> >> Hi Marc,
> >>
> >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> >>> On Mon, 31 Aug 2015 07:17:36 -0700
> >>> Guenter Roeck  wrote:
> >>>
> >>> Hi Guenter,
> >>>
>  Qemu test results:
>   total: 85 pass: 74 fail: 11
>  Failed tests:
>   arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
>   arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
>   arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
>   arm:realview-pb-a8:arm_realview_pb_defconfig
>   arm:realview-eb:arm_realview_eb_defconfig
>   mips:fuloong2e_defconfig
>   xtensa:dc232b:lx60:xtensa_defconfig
>   xtensa:dc232b:kc705:xtensa_defconfig
>   xtensa:dc233c:ml605:generic_kc705_defconfig
>   xtensa:dc233c:kc705:generic_kc705_defconfi
> 
>  Notable new failures (since next-20150828) are the s390 build failures,
>  the arm64 build failure, and the arm qemu test failures.
> 
> >>>
> >>> [...]
> >>>
>  The qemu arm tests all fail silently, meaning there is no console
>  output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
>  Bisect log attached.
> >>>
> >>> Could you give me a qemu command-line I can use to track this down?
> >>> Real HW seems happy enough, from what I can see...
> >>>
> >>
> >> That is what I was most concerned about :-(. Unfortunately, it
> >> affects many of the most widely used arm qemu emulations, so it
> >> would be very desirable to get this fixed, either in the kernel
> >> or in qemu.
> >>
> >> See https://github.com/groeck/linux-build-test, specifically
> >> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> >> run-qemu-arm.sh includes the various command lines and configurations.
> >>
> >> Note that some of the tests require a patched version of qemu.
> >> The tests failing above should all work with the latest published
> >> version of qemu (2.4), though.
> >>
> >> Please let me know if there is anything I can do to help tracking
> >> this down.
> >
> > I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
> > results are interesting:
> >
> > - With -next as of today, qemu segfaults. Hump.
> >
> > - If I use my branch that contains the EOImode==1 patch, the system
> >boots normally.
> >
> > So there is an interaction between this patch and whatever is in -next
> > at the moment, but that patch on its own is not what triggers the issue.
> >
> Looks like it.
> 
> I did a couple of tests.
> - Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
>Same problem.
> - Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
>and 'irqchip/GIC: Convert to EOImode == 1'.
>Problem is no longer seen.

This is getting even more weird. I've upgraded my qemu to 2.3 (the
latest Debian seems to be carrying). I'm booting a A15-TC1 model with
the following:

emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
-kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
-serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
none

The model dies with:

[...]
NET: Registered protocol family 16
DMA: preallocated 256 KiB pool for atomic coherent allocations
Unable to handle kernel NULL pointer dereference at virtual address 0030
pgd = 80004000
[0030] *pgd=
Internal error: Oops: 5 [#1] SMP ARM
Modules linked in:
CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150831+ #18
Hardware name: ARM-Versatile Express
task: 9f458000 ti: 9f446000 task.ti: 9f446000
PC is at __regmap_init+0x15c/0xb18
LR is at 0x0
pc : [<802c3e50>]lr : [<>]psr: 4153
sp : 9f447d00  ip :   fp : 
r10:   r9 : 0001  r8 : 9f49f280
r7 :   r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
r3 :   r2 :   r1 : a4f4  r0 : 9f4ce400
Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8000406a  DAC: 0055
Process swapper/0 (pid: 1, stack limit = 0x9f446210)
Stack: (0x9f447d00 to 0x9f448000)
7d00: 806aa2b4 8059aa5c 9f4ce210 0001 9f4ce210  9f4ce210 9f49a610
7d20: 9f49f280 88000b18    802cb6a0  
7d40: 802663ec 0001   9f49f210 fdfb  
7d60: 9f49aa50 9f4ce210 9f49f250 fdfb  802664cc 9f4ce210 9f4ce200
7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
7da0: 9f4ce210 806826d0 0001 9f4ce210 9f4ce210 806826d0 fdfb 802b47f0
7dc0: 802b47ac 9f4ce210 806a805c 806826d0 0001 802b2f80  9f447e08
7de0: 802b30e8 0001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
7e00: 9f4ce244 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 18:09:22 +0100
Marc Zyngier  wrote:

Hi Guenter,

> On Mon, 31 Aug 2015 09:40:43 -0700
> Guenter Roeck  wrote:
> 
> > Hi Marc,
> > 
> > On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > > On Mon, 31 Aug 2015 08:47:07 -0700
> > > Guenter Roeck  wrote:
> > >
> > >> Hi Marc,
> > >>
> > >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > >>> On Mon, 31 Aug 2015 07:17:36 -0700
> > >>> Guenter Roeck  wrote:
> > >>>
> > >>> Hi Guenter,
> > >>>
> >  Qemu test results:
> > total: 85 pass: 74 fail: 11
> >  Failed tests:
> > arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
> > arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
> > arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
> > arm:realview-pb-a8:arm_realview_pb_defconfig
> > arm:realview-eb:arm_realview_eb_defconfig
> > mips:fuloong2e_defconfig
> > xtensa:dc232b:lx60:xtensa_defconfig
> > xtensa:dc232b:kc705:xtensa_defconfig
> > xtensa:dc233c:ml605:generic_kc705_defconfig
> > xtensa:dc233c:kc705:generic_kc705_defconfi
> > 
> >  Notable new failures (since next-20150828) are the s390 build failures,
> >  the arm64 build failure, and the arm qemu test failures.
> > 
> > >>>
> > >>> [...]
> > >>>
> >  The qemu arm tests all fail silently, meaning there is no console
> >  output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
> >  Bisect log attached.
> > >>>
> > >>> Could you give me a qemu command-line I can use to track this down?
> > >>> Real HW seems happy enough, from what I can see...
> > >>>
> > >>
> > >> That is what I was most concerned about :-(. Unfortunately, it
> > >> affects many of the most widely used arm qemu emulations, so it
> > >> would be very desirable to get this fixed, either in the kernel
> > >> or in qemu.
> > >>
> > >> See https://github.com/groeck/linux-build-test, specifically
> > >> https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
> > >> run-qemu-arm.sh includes the various command lines and configurations.
> > >>
> > >> Note that some of the tests require a patched version of qemu.
> > >> The tests failing above should all work with the latest published
> > >> version of qemu (2.4), though.
> > >>
> > >> Please let me know if there is anything I can do to help tracking
> > >> this down.
> > >
> > > I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
> > > results are interesting:
> > >
> > > - With -next as of today, qemu segfaults. Hump.
> > >
> > > - If I use my branch that contains the EOImode==1 patch, the system
> > >boots normally.
> > >
> > > So there is an interaction between this patch and whatever is in -next
> > > at the moment, but that patch on its own is not what triggers the issue.
> > >
> > Looks like it.
> > 
> > I did a couple of tests.
> > - Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
> >Same problem.
> > - Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a 
> > guest'
> >and 'irqchip/GIC: Convert to EOImode == 1'.
> >Problem is no longer seen.
> 
> This is getting even more weird. I've upgraded my qemu to 2.3 (the
> latest Debian seems to be carrying). I'm booting a A15-TC1 model with
> the following:
> 
> emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
> -kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
> -serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
> none
> 
> The model dies with:
> 
> [...]
> NET: Registered protocol family 16
> DMA: preallocated 256 KiB pool for atomic coherent allocations
> Unable to handle kernel NULL pointer dereference at virtual address 0030
> pgd = 80004000
> [0030] *pgd=
> Internal error: Oops: 5 [#1] SMP ARM
> Modules linked in:
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.2.0-next-20150831+ #18
> Hardware name: ARM-Versatile Express
> task: 9f458000 ti: 9f446000 task.ti: 9f446000
> PC is at __regmap_init+0x15c/0xb18
> LR is at 0x0
> pc : [<802c3e50>]lr : [<>]psr: 4153
> sp : 9f447d00  ip :   fp : 
> r10:   r9 : 0001  r8 : 9f49f280
> r7 :   r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
> r3 :   r2 :   r1 : a4f4  r0 : 9f4ce400
> Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 8000406a  DAC: 0055
> Process swapper/0 (pid: 1, stack limit = 0x9f446210)
> Stack: (0x9f447d00 to 0x9f448000)
> 7d00: 806aa2b4 8059aa5c 9f4ce210 0001 9f4ce210  9f4ce210 9f49a610
> 7d20: 9f49f280 88000b18    802cb6a0  
> 7d40: 802663ec 0001   9f49f210 fdfb  
> 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On 08/31/2015 10:09 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 09:40:43 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 09:18 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 08:47:07 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 08:31 AM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 07:17:36 -0700
Guenter Roeck  wrote:

Hi Guenter,


Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.



[...]


The qemu arm tests all fail silently, meaning there is no console
output. Bisect points to 'irqchip/GIC: Convert to EOImode == 1'.
Bisect log attached.


Could you give me a qemu command-line I can use to track this down?
Real HW seems happy enough, from what I can see...



That is what I was most concerned about :-(. Unfortunately, it
affects many of the most widely used arm qemu emulations, so it
would be very desirable to get this fixed, either in the kernel
or in qemu.

See https://github.com/groeck/linux-build-test, specifically
https://github.com/groeck/linux-build-test/tree/master/rootfs/arm/.
run-qemu-arm.sh includes the various command lines and configurations.

Note that some of the tests require a patched version of qemu.
The tests failing above should all work with the latest published
version of qemu (2.4), though.

Please let me know if there is anything I can do to help tracking
this down.


I give it a quick go with qemu 2.1.2 as installed on my laptop, and the
results are interesting:

- With -next as of today, qemu segfaults. Hump.

- If I use my branch that contains the EOImode==1 patch, the system
boots normally.

So there is an interaction between this patch and whatever is in -next
at the moment, but that patch on its own is not what triggers the issue.


Looks like it.

I did a couple of tests.
- Revert 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'.
Same problem.
- Revert both 'irqchip/GIC: Don't deactivate interrupts forwarded to a guest'
and 'irqchip/GIC: Convert to EOImode == 1'.
Problem is no longer seen.


This is getting even more weird. I've upgraded my qemu to 2.3 (the
latest Debian seems to be carrying). I'm booting a A15-TC1 model with
the following:

emu-system-arm -machine vexpress-a15 -cpu cortex-a15 -m 512M
-kernel arch/arm/boot/zImage -append "console=ttyAMA0 earlyprintk"
-serial stdio -dtb arch/arm/boot/dts/vexpress-v2p-ca15-tc1.dtb -display
none



After building multi_v7_defconfig, this fails for me as well (qemu hang
without console output) with both qemu 2.2 and qemu 2.4. This is with
both your and my command line.

Yes, turns out there are more failures. The only problem fixed by reverting
your patches was arm:realview-pb-a8:qemu_arm_realview_pb_defconfig as well as
arm:realview-eb:qemu_arm_realview_eb_defconfig. All the vexpress tests still
fail.

Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

Hi Marc,

On 08/31/2015 11:26 AM, Marc Zyngier wrote:
[ ... ]


Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann 
Date:   Sun Aug 30 09:33:53 2015 +0200

 regmap: Introduce max_raw_read/write for regmap_bulk_read/write

 There are some buses which have a limit on the maximum number of
 bytes that can be send/received. An example for this is
 I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
 more than 32 bytes. The regmap_bulk operations should still be able
 to utilize the full 32 bytes in this case.

 Signed-off-by: Markus Pargmann 
 Signed-off-by: Mark Brown 

which never considers bus to be NULL in __regmap_init. With the
following patch applied, I can boot to a prompt:

 From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 19:16:16 +0100
Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Commit adaac459759d ("regmap: Introduce max_raw_read/write
for regmap_bulk_read/write") added new fields to regmap_bus
and started using them in __regmap_init, but failed to
consider the case where bus would be NULL, like in the
vexpress-syscgf case. The box (actually its qemu version)
ends up dying painfully.

Fix it by testing bus before doing anything else.

Signed-off-by: Marc Zyngier 


Yes, that fixes the vexpress failures.

Tested-by: Guenter Roeck 

However, I still need to revert your patches to get my realview-pb-a8
and realview-eb tests to work again.

I am a bit concerned about the use of of_address_to_resource(),
which can return an error, leaving cpu_res undefined. Also, if
both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
is set to true by default. This is the configuration used in my
failing tests.

With that in mind, I ran a simple test.

-static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
+static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;

Bingo, problem solved. Can you try to find a clean solution ?

I wonder how it comes that you get a console output from qemu, but I don't.
Did you use multi_v7_defconfig or some other configuration ?

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Marc Zyngier]

On Mon, 31 Aug 2015 11:57:14 -0700
Guenter Roeck  wrote:

> Hi Marc,
> 
> On 08/31/2015 11:26 AM, Marc Zyngier wrote:
> [ ... ]
> >
> > Actually, the kernel dies because of this:
> >
> > commit adaac459759db4a1fd35baddbe47bac700095496
> > Author: Markus Pargmann 
> > Date:   Sun Aug 30 09:33:53 2015 +0200
> >
> >  regmap: Introduce max_raw_read/write for regmap_bulk_read/write
> >
> >  There are some buses which have a limit on the maximum number of
> >  bytes that can be send/received. An example for this is
> >  I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
> >  more than 32 bytes. The regmap_bulk operations should still be able
> >  to utilize the full 32 bytes in this case.
> >
> >  Signed-off-by: Markus Pargmann 
> >  Signed-off-by: Mark Brown 
> >
> > which never considers bus to be NULL in __regmap_init. With the
> > following patch applied, I can boot to a prompt:
> >
> >  From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
> > From: Marc Zyngier 
> > Date: Mon, 31 Aug 2015 19:16:16 +0100
> > Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL
> >
> > Commit adaac459759d ("regmap: Introduce max_raw_read/write
> > for regmap_bulk_read/write") added new fields to regmap_bus
> > and started using them in __regmap_init, but failed to
> > consider the case where bus would be NULL, like in the
> > vexpress-syscgf case. The box (actually its qemu version)
> > ends up dying painfully.
> >
> > Fix it by testing bus before doing anything else.
> >
> > Signed-off-by: Marc Zyngier 
> 
> Yes, that fixes the vexpress failures.
> 
> Tested-by: Guenter Roeck 
> 
> However, I still need to revert your patches to get my realview-pb-a8
> and realview-eb tests to work again.
> 
> I am a bit concerned about the use of of_address_to_resource(),
> which can return an error, leaving cpu_res undefined. Also, if
> both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
> is set to true by default. This is the configuration used in my
> failing tests.
> 
> With that in mind, I ran a simple test.
> 
> -static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
> +static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;
> 
> Bingo, problem solved. Can you try to find a clean solution ?

Yeah, I just came to the same conclusion, and to the following patch:

>From 059bc80a4fc433dda99d75a712f30a77ce4964bc Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 20:00:35 +0100
Subject: [PATCH] irqchip/gic: Fix EOImode settiing non-DT/ACPI systems

Non-DT/ACPI systems call directly into the GIC driver at init time.
Since 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1"), this
breaks old non firmware-driven platforms, as the driver only
works out the capability of the platform on the DT/ACPI paths.

Fix this thinko by forcing EOImode==0 on non-DT platforms,
which are not capable of supporting a hypervisor anyway.

Signed-off-by: Marc Zyngier 
---
 drivers/irqchip/irq-gic.c | 19 ---
 1 file changed, 16 insertions(+), 3 deletions(-)

diff --git a/drivers/irqchip/irq-gic.c b/drivers/irqchip/irq-gic.c
index 72bf81b..e6b7ed5 100644
--- a/drivers/irqchip/irq-gic.c
+++ b/drivers/irqchip/irq-gic.c
@@ -993,7 +993,7 @@ static const struct irq_domain_ops gic_irq_domain_ops = {
.xlate = gic_irq_domain_xlate,
 };
 
-void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+static void __init __gic_init_bases(unsigned int gic_nr, int irq_start,
   void __iomem *dist_base, void __iomem *cpu_base,
   u32 percpu_offset, struct device_node *node)
 {
@@ -1103,6 +1103,19 @@ void __init gic_init_bases(unsigned int gic_nr, int 
irq_start,
gic_pm_init(gic);
 }
 
+void __init gic_init_bases(unsigned int gic_nr, int irq_start,
+  void __iomem *dist_base, void __iomem *cpu_base,
+  u32 percpu_offset, struct device_node *node)
+{
+   /*
+* Non-DT/ACPI systems won't run a hypervisor, so let's not
+* bother with these...
+*/
+   static_key_slow_dec(_deactivate);
+   __gic_init_bases(gic_nr, irq_start, dist_base, cpu_base,
+percpu_offset, node);
+}
+
 #ifdef CONFIG_OF
 static int gic_cnt __initdata;
 
@@ -1137,7 +1150,7 @@ gic_of_init(struct device_node *node, struct device_node 
*parent)
if (of_property_read_u32(node, "cpu-offset", _offset))
percpu_offset = 0;
 
-   gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
+   __gic_init_bases(gic_cnt, -1, dist_base, cpu_base, percpu_offset, node);
if (!gic_cnt)
gic_init_physaddr(node);
 
@@ -1265,7 +1278,7 @@ 

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On 08/31/2015 12:13 PM, Marc Zyngier wrote:

On Mon, 31 Aug 2015 11:57:14 -0700
Guenter Roeck  wrote:


Hi Marc,

On 08/31/2015 11:26 AM, Marc Zyngier wrote:
[ ... ]


Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann 
Date:   Sun Aug 30 09:33:53 2015 +0200

  regmap: Introduce max_raw_read/write for regmap_bulk_read/write

  There are some buses which have a limit on the maximum number of
  bytes that can be send/received. An example for this is
  I2C_FUNC_SMBUS_I2C_BLOCK which does not support any reads/writes of
  more than 32 bytes. The regmap_bulk operations should still be able
  to utilize the full 32 bytes in this case.

  Signed-off-by: Markus Pargmann 
  Signed-off-by: Mark Brown 

which never considers bus to be NULL in __regmap_init. With the
following patch applied, I can boot to a prompt:

  From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 19:16:16 +0100
Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Commit adaac459759d ("regmap: Introduce max_raw_read/write
for regmap_bulk_read/write") added new fields to regmap_bus
and started using them in __regmap_init, but failed to
consider the case where bus would be NULL, like in the
vexpress-syscgf case. The box (actually its qemu version)
ends up dying painfully.

Fix it by testing bus before doing anything else.

Signed-off-by: Marc Zyngier 


Yes, that fixes the vexpress failures.

Tested-by: Guenter Roeck 

However, I still need to revert your patches to get my realview-pb-a8
and realview-eb tests to work again.

I am a bit concerned about the use of of_address_to_resource(),
which can return an error, leaving cpu_res undefined. Also, if
both CONFIG_OF and CONFIG_ACPI are not configured, supports_deactivate
is set to true by default. This is the configuration used in my
failing tests.

With that in mind, I ran a simple test.

-static struct static_key supports_deactivate = STATIC_KEY_INIT_TRUE;
+static struct static_key supports_deactivate = STATIC_KEY_INIT_FALSE;

Bingo, problem solved. Can you try to find a clean solution ?


Yeah, I just came to the same conclusion, and to the following patch:

 From 059bc80a4fc433dda99d75a712f30a77ce4964bc Mon Sep 17 00:00:00 2001
From: Marc Zyngier 
Date: Mon, 31 Aug 2015 20:00:35 +0100
Subject: [PATCH] irqchip/gic: Fix EOImode settiing non-DT/ACPI systems

Non-DT/ACPI systems call directly into the GIC driver at init time.
Since 0b996fd35957 ("irqchip/GIC: Convert to EOImode == 1"), this
breaks old non firmware-driven platforms, as the driver only
works out the capability of the platform on the DT/ACPI paths.

Fix this thinko by forcing EOImode==0 on non-DT platforms,
which are not capable of supporting a hypervisor anyway.

Signed-off-by: Marc Zyngier 


Yep, that fixes the problem.

Tested-by: Guenter Roeck 

Thanks,
Guenter

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Mark Brown]

On Mon, Aug 31, 2015 at 07:26:57PM +0100, Marc Zyngier wrote:

> which never considers bus to be NULL in __regmap_init. With the
> following patch applied, I can boot to a prompt:
> 
> From 031eae5a1b34f952ba3dcaecb4eb4ec9d3bda352 Mon Sep 17 00:00:00 2001

> From: Marc Zyngier 
> Date: Mon, 31 Aug 2015 19:16:16 +0100
> Subject: [PATCH] regmap: Fix max_raw_read/write handling when bus is NULL

Please submit patches using the process documented in SubmittingPatches,
don't bury them in the middle of a reply to some random other thread
where they can't be applied without handholding :(

> - map->max_raw_read = bus->max_raw_read;
> - map->max_raw_write = bus->max_raw_write;
> + map->max_raw_read = bus ? bus->max_raw_read : 0;
> + map->max_raw_write = bus ? bus->max_raw_write : 0;

A more legible version of this patch was already applied.


signature.asc
Description: Digital signature

Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)

[Guenter Roeck]

On Mon, Aug 31, 2015 at 07:54:20PM +1000, Stephen Rothwell wrote:
> Hi all,
> 
> Changes since 20150828:
> 
> I used the h8300 tree from next-20150828 since the current tree has been
> rebased onto linux-next :-(
> 
> The sound-asoc tree lost its build failure.
> 
> The trivial tree gained a conflict against the drm tree.
> 
> The tty tree still had its build failure for which I reverted part of
> a commit.
> 
> The gpio tree gained a build failure so I used the version form
> next-20150828.
> 
> Non-merge commits (relative to Linus' tree): 10761
>  9636 files changed, 583138 insertions(+), 252790 deletions(-)
> 
> 
> 

Build results:
total: 145 pass: 135 fail: 10
Failed builds:
alpha:allmodconfig
arm:rpc_defconfig
arm64:allmodconfig
mips:allmodconfig
mips:nlm_xlp_defconfig
s390:defconfig
s390:allmodconfig
xtensa:defconfig
xtensa:allmodconfig
xtensa:allnoconfig

Qemu test results:
total: 85 pass: 74 fail: 11
Failed tests:
arm:vexpress-a9:arm_vexpress_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:arm_vexpress_defconfig:vexpress-v2p-ca15-tc1
arm:vexpress-a9:multi_v7_defconfig:vexpress-v2p-ca9
arm:vexpress-a15:multi_v7_defconfig:vexpress-v2p-ca15-tc1
arm:realview-pb-a8:arm_realview_pb_defconfig
arm:realview-eb:arm_realview_eb_defconfig
mips:fuloong2e_defconfig
xtensa:dc232b:lx60:xtensa_defconfig
xtensa:dc232b:kc705:xtensa_defconfig
xtensa:dc233c:ml605:generic_kc705_defconfig
xtensa:dc233c:kc705:generic_kc705_defconfi

Notable new failures (since next-20150828) are the s390 build failures,
the arm64 build failure, and the arm qemu test failures.

arm64:

drivers/built-in.o: In function `mtk_cpufreq_ready':
:(.text+0x27e124): undefined reference to `of_cpufreq_cooling_register'
drivers/built-in.o: In function `mtk_cpufreq_exit':
:(.text+0x27e31c): undefined reference to `cpufreq_cooling_unregister'

Most likely caused by 'cpufreq: mediatek: Add MT8173 cpufreq driver", but
I did not bisect.

s390:

kernel/built-in.o: In function `bpf_trace_printk':
bpf_trace.c:(.text+0x116a5c): undefined reference to `strncpy_from_unsafe'
kernel/built-in.o: In function `fetch_memory_string':
trace_kprobe.c:(.text+0x118ee0): undefined reference to `strncpy_from_unsafe'

Appears to be due to 'bpf: add support for %s specifier to bpf_trace_printk()'.
Not bisected.

The qemu arm tests all fail silently, meaning there is no console output.
Bisect points to 'irqchip/GIC: Convert to EOImode == 1'. Bisect log attached.

Guenter

---
qemu arm bisect log:

# bad: [4da7932545f1474564af3b2558b738c7a15ed853] Add linux-next specific files 
for 20150831
# good: [64291f7db5bd8150a74ad2036f1037e6a0428df2] Linux 4.2
git bisect start 'HEAD' 'v4.2'
# good: [0b82dd97c3ae2056d3b5b7db156923f77e3cb675] Merge remote-tracking branch 
'drm/drm-next'
git bisect good 0b82dd97c3ae2056d3b5b7db156923f77e3cb675
# bad: [b7299a186f496145dfe87a59054b876fe1677309] Merge remote-tracking branch 
'tty/tty-next'
git bisect bad b7299a186f496145dfe87a59054b876fe1677309
# good: [71247c5f3351adb3c69321f9f2ba3e16ccee589e] Merge remote-tracking branch 
'mailbox/mailbox-for-next'
git bisect good 71247c5f3351adb3c69321f9f2ba3e16ccee589e
# bad: [99df9788ac9bc648e78b3b2a3c641e750e184c01] manual merge of sched/core
git bisect bad 99df9788ac9bc648e78b3b2a3c641e750e184c01
# bad: [b8ad55972c02c9ca6049d1bf7764e1650c1c8e56] Merge branch 'locking/core'
git bisect bad b8ad55972c02c9ca6049d1bf7764e1650c1c8e56
# good: [27baa4737cb762851e4c6f085e45f087d26bab2d] Merge branch 'core/types'
git bisect good 27baa4737cb762851e4c6f085e45f087d26bab2d
# good: [8505a81bb036253213b109baf4178ea6861e2888] genirq: Use the proper 
parameter name in kernel doc
git bisect good 8505a81bb036253213b109baf4178ea6861e2888
# good: [0b6a3da9617a08e13afc09cb7e148470ed0eb280] irqchip/GICv3: Convert to 
EOImode == 1
git bisect good 0b6a3da9617a08e13afc09cb7e148470ed0eb280
# good: [3bbfafb77a06327fa1bc9f19bc55b5c558475091] x86, tsc, 
locking/static_keys: Employ static_branch_likely()
git bisect good 3bbfafb77a06327fa1bc9f19bc55b5c558475091
# good: [f5468ffde13fc991bd4d6bdec507ffd5777865bd] locking/lockref: Remove 
homebrew cmpxchg64_relaxed() macro definition
git bisect good f5468ffde13fc991bd4d6bdec507ffd5777865bd
# good: [d420acd816c07c7be31bd19d09cbcb16e5572fa6] jump_label/x86: Work around 
asm build bug on older/backported GCCs
git bisect good d420acd816c07c7be31bd19d09cbcb16e5572fa6
# bad: [01f779f4862b53810ba4eb247f57bd1ad31d1c18] irqchip/GIC: Don't deactivate 
interrupts forwarded to a guest
git bisect bad 01f779f4862b53810ba4eb247f57bd1ad31d1c18
# bad: [0b996fd35957a30568cddbce05b917c1897966e0] irqchip/GIC: Convert to 
EOImode == 1
git bisect bad 0b996fd35957a30568cddbce05b917c1897966e0
# good: [530bf353e4eb06bcba5078390c949650cd26a7c7] irqchip/GICv3: