linux-next: Tree for Aug 31
Hi all, Changes since 20180830: Dropped trees: xarray, ida (temporarily) Non-merge commits (relative to Linus' tree): 1248 1497 files changed, 48772 insertions(+), 16144 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc, an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu (with and without kvm enabled). Below is a summary of the state of the merge. I am currently merging 286 trees (counting Linus' and 66 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (fb6463856658 Merge tag 'for-linus-20180830' of git://git.kernel.dk/linux-block) Merging fixes/master (4db250925b08 disable stringop truncation warnings for now) Merging kbuild-current/fixes (ad1d69735878 Merge tag 'fuse-update-4.19' of git://git.kernel.org/pub/scm/linux/kernel/git/mszeredi/fuse) Merging arc-current/for-curr (fce0d0affdc5 ARC: cleanup show_faulting_vma()) Merging arm-current/fixes (afc9f65e01cd ARM: 8781/1: Fix Thumb-2 syscall return for binutils 2.29+) Merging arm64-fixes/for-next/fixes (755a8bf5579d arm/arm64: smccc-1.1: Handle function result as parameters) Merging m68k-current/for-linus (71a896687b85 m68k/defconfig: Update defconfigs for v4.18-rc6) Merging powerpc-fixes/fixes (cca19f0b684f powerpc/64s/radix: Fix missing global invalidations when removing copro) Merging sparc/master (df2def49c57b Merge tag 'acpi-4.19-rc1-2' of git://git.kernel.org/pub/scm/linux/kernel/git/rafael/linux-pm) Merging fscrypt-current/for-stable (ae64f9bd1d36 Linux 4.15-rc2) Merging net/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging bpf/master (dc6417949297 Merge branch 'net_sched-reject-unknown-tcfa_action-values') Merging ipsec/master (25432eba9cd8 openvswitch: meter: Fix setting meter id for new entries) Merging netfilter/master (0434ccdcf883 netfilter: nf_tables: rework ct timeout set support) Merging ipvs/master (feb9f55c33e5 netfilter: nft_dynset: allow dynamic updates of non-anonymous set) Merging wireless-drivers/master (53ae914d898e net/rds: Use rdma_read_gids to get connection SGID/DGID in IPv6) Merging mac80211/master (aa58acf325b4 mac80211: always account for A-MSDU header changes) Merging rdma-fixes/for-rc (5b394b2ddf03 Linux 4.19-rc1) Merging sound-current/for-linus (16037643969e ALSA: hda - Fix cancel_work_sync() stall from jackpoll work) Merging sound-asoc-fixes/for-linus (c4305768a542 Merge branch 'asoc-4.19' into asoc-linus) Merging regmap-fixes/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging regulator-fixes/for-linus (823f18f8b860 regulator: bd71837: Disable voltage monitoring for LDO3/4) Merging spi-fixes/for-linus (9a92a569272a Merge branch 'spi-4.19' into spi-linus) Merging pci-current/for-linus (5b394b2ddf03 Linux 4.19-rc1) Merging driver-core.current/driver-core-linus (5b394b2ddf03 Linux 4.19-rc1) Merging tty.current/tty-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb.current/usb-linus (5b394b2ddf03 Linux 4.19-rc1) Merging usb-gadget-fixes/fixes (5b394b2ddf03 Linux 4.19-rc1) Merging usb-serial-fixes/usb-linus (5dfdd24eb3d3 USB: serial: ti_usb_3410_5052: fix array underflow in completion handler) Merging usb-chipidea-fixes/ci-for-usb-stable (a930d8bd94d8 usb: chipidea: Always build ULPI code) Merging phy/fixes (ad5003300b07 phy: mapphone-mdm6600: Fix wrong enum used for status lines) Merging staging.current/staging-linus (f86cf25a6091 Revert "staging: erofs: disable compiling temporarile") Merging char-misc.current/char-misc-lin
linux-next: Tree for Aug 31
Hi all, Changes since 20170829: The nfsd tree still had its build failure so I used the version from next-20170824. The pm tree gained a conflict against the dmi tree. The sound-asoc tree lost its build failure. The tip tree gained a conflict against the net-next tree. The rcu tree lost its build failure. The xen-tip tree gained conflicts against the tip tree. The rpmsg tree gained a build failure so I used the version from next-20170829. The akpm-current tree gained a build failure due to an interaction with the block tree for which I applied a merge fix patch. The akpm tree lost 3 patches that turned up elsewhere. Non-merge commits (relative to Linus' tree): 10308 10029 files changed, 529793 insertions(+), 189196 deletions(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig (with CONFIG_BUILD_DOCSRC=n) for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), I do an x86_64 modules_install followed by builds for x86_64 allnoconfig, powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig, allyesconfig and pseries_le_defconfig and i386, sparc and sparc64 defconfig. And finally, a simple boot test of the powerpc pseries_le_defconfig kernel in qemu. Below is a summary of the state of the merge. I am currently merging 268 trees (counting Linus' and 41 trees of bug fix patches pending for the current merge release). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwell $ git checkout master $ git reset --hard stable Merging origin/master (36fde05f3fb5 Merge branch 'for-4.13-fixes' of git://git.kernel.org/pub/scm/linux/kernel/git/tj/cgroup) Merging fixes/master (b4b8cbf679c4 Cavium CNN55XX: fix broken default Kconfig entry) Merging kbuild-current/fixes (64236e315955 kbuild: update comments of Makefile.asm-generic) Merging arc-current/for-curr (e926d8fa5b68 ARC: Show fault information passed to show_kernel_fault_diag()) Merging arm-current/fixes (746a272e4414 ARM: 8692/1: mm: abort uaccess retries upon fatal signal) Merging m68k-current/for-linus (204a2be30a7a m68k: Remove ptrace_signal_deliver) Merging metag-fixes/fixes (b884a190afce metag/usercopy: Add missing fixups) Merging powerpc-fixes/fixes (1a92a80ad386 powerpc/mm: Ensure cpumask update is ordered) Merging sparc/master (6470812e2226 Merge git://git.kernel.org/pub/scm/linux/kernel/git/davem/sparc) Merging fscrypt-current/for-stable (42d97eb0ade3 fscrypt: fix renaming and linking special files) Merging net/master (183db4812794 drivers: net: xgene: Correct probe sequence handling) Merging ipsec/master (931e79d7a7dd xfrm_user: fix info leak in build_aevent()) Merging netfilter/master (f63ae01d890c Merge tag 'wireless-drivers-for-davem-2017-08-25' of git://git.kernel.org/pub/scm/linux/kernel/git/kvalo/wireless-drivers) Merging ipvs/master (f7fb77fc1235 netfilter: nft_compat: check extension hook mask only if set) Merging wireless-drivers/master (10a54d8196d1 iwlwifi: pcie: move rx workqueue initialization to iwl_trans_pcie_alloc()) Merging mac80211/master (d7f13f745036 cfg80211: Validate frequencies nested in NL80211_ATTR_SCAN_FREQUENCIES) Merging sound-current/for-linus (bcab3a6e64a9 ALSA: pcm: Fix power lock unbalance via OSS emulation) Merging pci-current/for-linus (8e1101d25164 PCI/MSI: Don't warn when irq_create_affinity_masks() returns NULL) Merging driver-core.current/driver-core-linus (ef954844c7ac Linux 4.13-rc5) Merging tty.current/tty-linus (ef954844c7ac Linux 4.13-rc5) Merging usb.current/usb-linus (ef954844c7ac Linux 4.13-rc5) Merging usb-gadget-fixes/fixes (b7d44c36a6f6 usb: renesas_usbhs: gadget: fix unused-but-set-variable warning) Merging usb-serial-fixes/usb-linus (fd1b8668af59 USB: serial: option: add D-Link DWM-222 device ID) Merging usb-chipidea-fixes/ci-for-usb-stable (cbb22ebcfb99 usb: chipidea: core: check before accessing ci_role in ci_role_show) Merging phy/fixes (5771a8c08880 Linux v4.13-rc1) Me
Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)
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)
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)
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(&supports_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", &percpu_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() an
Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)
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)
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)
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 > 7d
Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)
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 80677728
Re: linux-next: Tree for Aug 31 (new arm, arm64, s390 failures)
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)
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)
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)
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)
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)
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: Don'
linux-next: Tree for Aug 31
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(-) I have created today's linux-next tree at git://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git (patches at http://www.kernel.org/pub/linux/kernel/next/ ). If you are tracking the linux-next tree using git, you should not use "git pull" to do so as that will try to merge the new linux-next release with the old one. You should use "git fetch" and checkout or reset to the new master. You can see which trees have been included by looking in the Next/Trees file in the source. There are also quilt-import.log and merge.log files in the Next directory. Between each merge, the tree was built with a ppc64_defconfig for powerpc and an allmodconfig for x86_64, a multi_v7_defconfig for arm and a native build of tools/perf. After the final fixups (if any), it is also built with powerpc allnoconfig (32 and 64 bit), ppc44x_defconfig and allyesconfig (this fails its final link) and i386, sparc, sparc64 and arm defconfig. Below is a summary of the state of the merge. I am currently merging 225 trees (counting Linus' and 33 trees of patches pending for Linus' tree). Stats about the size of the tree over time can be seen at http://neuling.org/linux-next-size.html . Status of my local build tests will be at http://kisskb.ellerman.id.au/linux-next . If maintainers want to give advice about cross compilers/configs that work, we are always open to add more builds. Thanks to Randy Dunlap for doing many randconfig builds. And to Paul Gortmaker for triage and bug fixes. -- Cheers, Stephen Rothwells...@canb.auug.org.au $ git checkout master $ git reset --hard stable Merging origin/master (64291f7db5bd Linux 4.2) Merging fixes/master (c7e9ad7da219 Merge branch 'perf-urgent-for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip) Merging kbuild-current/rc-fixes (3d1450d54a4f Makefile: Force gzip and xz on module install) Merging arc-current/for-curr (e4140819dadc ARC: signal handling robustify) Merging arm-current/fixes (3939f3345050 ARM: 8418/1: add boot image dependencies to not generate invalid images) Merging m68k-current/for-linus (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation) Merging metag-fixes/fixes (0164a711c97b metag: Fix ioremap_wc/ioremap_cached build errors) Merging mips-fixes/mips-fixes (1795cd9b3a91 Linux 3.16-rc5) Merging powerpc-fixes/fixes (4d9aac397a5d powerpc/PCI: Disable MSI/MSI-X interrupts at PCI probe time in OF case) Merging powerpc-merge-mpe/fixes (bc0195aad0da Linux 4.2-rc2) Merging sparc/master (73958c651fbf sparc64: use ENTRY/ENDPROC in VISsave) Merging net/master (f892a84cc890 net/smsc911x: Fix deferred probe for interrupt) Merging ipsec/master (158cd4af8ded packet: missing dev_put() in packet_do_bind()) Merging sound-current/for-linus (c7cd0ef66aad ALSA: hda - Fix path power activation) Merging pci-current/for-linus (45ea2a5fed6d PCI: Don't use 64-bit bus addresses on PA-RISC) Merging wireless-drivers/master (741e3b9902d1 rtlwifi: rtl8723be: Add module parameter for MSI interrupts) Merging driver-core.current/driver-core-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging tty.current/tty-linus (cbfe8fa6cd67 Linux 4.2-rc4) Merging usb.current/usb-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging usb-gadget-fixes/fixes (c93e64e91248 usb: udc: core: add device_del() call to error pathway) Merging usb-serial-fixes/usb-linus (d071a3cdd2e1 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module) Merging staging.current/staging-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging char-misc.current/char-misc-linus (f7644cbfcdf0 Linux 4.2-rc6) Merging input-current/for-linus (e51e38494a8e Input: synaptics - fix handling of disabling gesture mode) Merging crypto-current/master (b310c178e6d8 crypto: caam - fix memory corruption in ahash_final_ctx) Merging ide/master (d681f1166919 ide: remove deprecated use of pci api) Merging devicetree-current/devicetree/merge (f76502aa9140 of/dynamic: Fix test for PPC_PSERIES) Merging rr-fixes/fixes (275d7d44d802 module: Fix locking in symbol_put_addr()) Merging vfio-fixes/for-linus (4bc94d5dc95d vfio: Fix lockdep issue) Merging kselftest-fixes/fixes (fee50f3c8427 selftests/futex: Fix futex_cmp_requeue_pi() error handling) Merging backlight-fixes/for-backlight-fixes (68feaca0b13e backlight: pwm: Handle EPROBE_DEFER while requesting the PWM) Merging ftrace-fixes/for-next-urgent (6224beb12e19 tracing: Have bra
