linux-next: Tree for Aug 31

linux-next: Tree for Aug 31

[Stephen Rothwell]

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 Rothwell                    sfr@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 branch tracer use recursive field of task struct)
Merging mfd-fixes/for-mfd-fixes (fb9caeedafe6 mfd: Remove MFD_CROS_EC_SPI depends on OF)
Merging drm-intel-fixes/for-linux-next-fixes (c13dcf9f2d6f Linux 4.2-rc8)
Merging asm-generic/master (643165c8bbc8 Merge tag 'uaccess_for_upstream' of git://git.kernel.org/pub/scm/linux/kernel/git/mst/vhost into asm-generic)
Merging arc/for-next (3d5926599a6b ARCv2: entry: Fix reserved handler)
Merging arm/for-next (0986c811d54f Merge branch 'drm-dwhdmi-devel' into for-next)
CONFLICT (content): Merge conflict in arch/arm/include/asm/Kbuild
Merging arm-perf/for-next/perf (fa8ad7889d83 arm: perf: factor arm_pmu core out to drivers)
Merging arm-soc/for-next (38af586237cf arm-soc: document merges)
CONFLICT (modify/delete): drivers/cpufreq/exynos-cpufreq.c deleted in arm-soc/for-next and modified in HEAD. Version HEAD of drivers/cpufreq/exynos-cpufreq.c left in tree.
CONFLICT (modify/delete): arch/arm/kernel/psci.c deleted in HEAD and modified in arm-soc/for-next. Version arm-soc/for-next of arch/arm/kernel/psci.c left in tree.
$ git rm -f arch/arm/kernel/psci.c drivers/cpufreq/exynos-cpufreq.c
Applying: ARM: fix for PSCI code movement
Merging at91/at91-next (253ebd4df402 Merge branch 'at91-4.3-defconfig' into at91-next)
CONFLICT (content): Merge conflict in arch/arm/mach-at91/sama5.c
CONFLICT (content): Merge conflict in arch/arm/configs/at91_dt_defconfig
Merging bcm2835/for-next (b2776bf7149b Linux 3.18)
Merging berlin/berlin/for-next (d770e558e219 Linux 4.2-rc1)
Merging cortex-m/for-next (e799b6f37e6c ARM: zImage: add support for ARMv7-M)
Merging imx-mxs/for-next (c746ef1b64e9 Merge branch 'imx/defconfig' into for-next)
Merging keystone/next (a6ba4234e474 ARM: dts: k2l: fix the netcp range size)
CONFLICT (content): Merge conflict in arch/arm/boot/dts/k2l.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/k2hk.dtsi
CONFLICT (content): Merge conflict in arch/arm/boot/dts/k2e.dtsi
Merging mvebu/for-next (adfc8c76d84a Merge branch 'mvebu/config' into mvebu/for-next)
Merging omap/for-next (b2a882022a1e Merge branch 'omap-for-v4.3/dt-v2' into for-next)
Merging omap-pending/for-next (30aa18d3bea5 MAINTAINERS: add maintainer for OMAP hwmod data)
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod_7xx_data.c
CONFLICT (content): Merge conflict in arch/arm/mach-omap2/omap_hwmod_43xx_data.c
Merging qcom/qcom/for-next (4f4cd70a7f65 arm: dt: Add scm support for MSM8974)
Merging renesas/next (078e7cdb7497 Merge branch 'heads/fixes-for-v4.3' into next)
Merging rockchip/for-next (ed0450118b2f Merge branch 'v4.3-armsoc/soc' into for-next)
Merging rpi/for-rpi-next (bc0195aad0da Linux 4.2-rc2)
Merging samsung/for-next (112129267f1a Merge branch 'v4.3-next/dt64-samsung' into for-next)
Merging samsung-krzk/for-next (002528669469 Merge branch 'defconfig-for-next' into for-next)
Merging sunxi/sunxi/for-next (9d73c13a139c Merge branches 'sunxi/dt-for-4.3' and 'sunxi/defconfig-for-4.3' into sunxi/for-next)
Merging tegra/for-next (bea5a17a8beb Merge branch for-4.3/defconfig into for-next)
Merging arm64/for-next/core (674c242c9323 arm64: flush FP/SIMD state correctly after execve())
Merging blackfin/for-linus (d91e14b3b9e1 eth: bf609 eth clock: add pclk clock for stmmac driver probe)
Merging c6x/for-linux-next (960a2741d5fd c67: irq: Use __handle_domain_irq())
Merging cris/for-next (1e4d6e13d050 cris: don't use module_init for non-modular core eeprom.c code)
CONFLICT (content): Merge conflict in arch/cris/include/asm/Kbuild
Merging h8300/h8300-next (99bcfda85f66 Revert "asm-generic: {get,put}_user ptr argument evaluate only 1 time")
Merging hexagon/linux-next (15978bfde3bb hexagon/time: Migrate to new 'set-state' interface)
Merging ia64/next (ae40b7e28752 Merge branch 'misc-4.2' into next)
Merging m68k/for-next (1ecb40643a9a m68k/bootinfo: Use kmemdup rather than duplicating its implementation)
Merging m68knommu/for-next (50e48bd06731 m68k/coldfire: use PFN_DOWN macro)
Merging metag/for-next (3fe6942f0486 Documentation/features/vm: Meta2 is capable of THP)
Merging microblaze/next (bb88ba0946dd elf-em.h: move EM_MICROBLAZE to the common header)
Merging mips/mips-for-linux-next (016c3edb9815 Merge branch '4.2-fixes' into mips-for-linux-next)
Merging nios2/for-next (81c9517e7ab4 nios2/time: Migrate to new 'set-state' interface)
Merging parisc-hd/for-next (0c0f80b3f908 parisc: Define ioremap_uc and ioremap_wc)
Merging powerpc/next (390fd5929f52 cxl: Set up and enable PSL Timebase)
Merging powerpc-mpe/next (bc0195aad0da Linux 4.2-rc2)
Merging fsl/next (4524cd093fa8 powerpc/t1023rdb/dts: set ifc nand chip select from 2 to 1)
Merging mpc5xxx/next (9e813308a5c1 powerpc/thp: Add tracepoints to track hugepage invalidate)
Merging s390/features (e4ec73510812 s390/jump_label: Use %*ph to print small buffers)
Merging sparc-next/master (9f935675d41a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/dtor/input)
Merging tile/master (8d03bc56cc27 tile: correct some typos in opcode type names)
CONFLICT (content): Merge conflict in include/uapi/linux/elf-em.h
Merging uml/linux-next (bdbac7d0e2b3 um: Fix kernel mode fault condition)
Merging unicore32/unicore32 (d670878e2c9a unicore32: Remove ARCH_HAS_CPUFREQ config option)
Merging xtensa/for_next (895fb3159280 xtensa: improve vmlinux.lds.S sed post-processing)
CONFLICT (content): Merge conflict in arch/xtensa/include/asm/atomic.h
Merging btrfs/next (3a9508b0221d btrfs: fix compile when block cgroups are not enabled)
Merging ceph/master (64c1797a9371 libceph: Remove spurious kunmap() of the zero page)
Merging cifs/for-next (5fb4e288a025 cifs: Fix use-after-free on mid_q_entry)
Merging ecryptfs/next (0dad87fcb732 eCryptfs: Delete a check before the function call "key_put")
Merging ext3/for_next (9181f8bf5abf udf: Don't modify filesystem for read-only mounts)
Merging ext4/dev (bdfe0cbd746a Revert "ext4: remove block_device_ejected")
Merging f2fs/dev (19b2c30d3cce f2fs: update extent tree in batches)
Merging fscache/fscache (b00c2ae2ed3c FS-Cache: Don't override netfs's primary_index if registering failed)
Merging fuse/for-next (0a30f612d6cf fuse: update MAINTAINERS entry)
Merging gfs2/for-next (ea79f0ec7a38 GFS2: Make ht_parms static)
Merging jfs/jfs-next (26456955719b jfs: clean up jfs_rename and fix out of order unlock)
Merging nfs/linux-next (90816d1ddacf NFSv4.1/flexfiles: Don't mark the entire deviceid as bad for file errors)
Merging nfsd/nfsd-next (a8bd5e23a345 nfsd: Add Jeff Layton as co-maintainer)
Merging orangefs/for-next (600896a3b8b0 Orangefs: Swap order of include files)
Merging overlayfs/overlayfs-next (cdb672795876 ovl: lookup whiteouts outside iterate_dir())
Merging squashfs/master (62421645bb70 Squashfs: Add LZ4 compression configuration option)
Merging v9fs/for-next (b5ac1fb2717e 9p: fix return code of read() when count is 0)
Merging ubifs/linux-next (071a1f837f72 UGIFS: fix a typo in comment of ubifs_budget_req)
Merging xfs/for-next (70b33a7466ba Merge branch 'xfs-misc-fixes-for-4.3-3' into for-next)
Merging file-locks/linux-next (ee296d7c5709 locks: inline posix_lock_file_wait and flock_lock_file_wait)
Merging vfs/for-next (397d425dc26d vfs: Test for and handle paths that are unreachable from their mnt_root)
Merging pci/next (9ca678d1dff6 Merge branches 'pci/enumeration' and 'pci/misc' into next)
CONFLICT (content): Merge conflict in drivers/pci/host/pcie-iproc.c
CONFLICT (content): Merge conflict in drivers/pci/host/Kconfig
Merging hid/for-next (c5a0db1eed32 Merge branch 'for-4.3/wacom' into for-next)
Merging i2c/i2c/for-next (31bb26d67b48 Merge branch 'i2c/for-4.3' into i2c/for-next)
Merging jdelvare-hwmon/master (902fd32b7711 hwmon: (k10temp) Remove duplicate pci-id define)
Merging dmi/master (1dc51b828800 Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/viro/vfs)
Merging hwmon-staging/hwmon-next (1ed32160dba6 hwmon: (fam15h_power) Add ratio of Tsample to the PTSC period)
Merging v4l-dvb/master (cb72d295ed59 Merge branch 'patchwork' into to_next)
Merging kbuild/for-next (3161460642b5 Merge branch 'kbuild/misc' into kbuild/for-next)
Merging kconfig/for-next (c0ddc8c745b7 localmodconfig: Use Kbuild files too)
Merging libata/for-next (82908d67958c Merge branch 'for-4.2-fixes' into for-next)
Merging pm/linux-next (9ea77b2f6313 Merge branches 'pm-cpufreq' and 'pm-opp' into linux-next)
Merging idle/next (aba5686671dc Merge branch 'cpuidle' into release)
Merging apm/for-next (53675abbd1e5 x86, apm: Remove unused variable)
Merging thermal/next (6ce87b2a60f1 Merge branches 'for-rc' and 'release' of .git into next)
Merging thermal-soc/next (1afb9c539dae thermal/cpu_cooling: update policy limits if clipped_freq < policy->max)
Merging ieee1394/for-next (d71e6a11737f firewire: core: use correct vendor/model IDs)
Merging dlm/next (b3a5bbfd780d dlm: print error from kernel_sendpage)
Merging swiotlb/linux-next (023600f192be swiotlb: do not export map_single function)
Merging slave-dma/next (f53d906c6323 Merge branch 'for-linus' into next)
CONFLICT (content): Merge conflict in drivers/dma/Makefile
CONFLICT (content): Merge conflict in drivers/dma/Kconfig
Merging net-next/master (2573d78872f2 Merge branch 'ovs-vport-cleanup')
Merging ipsec-next/master (e69948a0a530 net: Document xfrm4_gc_thresh and xfrm6_gc_thresh)
Merging wireless-drivers-next/master (0ba3ac03c1f3 Merge ath-next from ath.git)
Merging bluetooth/master (2e3fbc533618 Bluetooth: hci_intel: Introduce LPM support)
Merging rdma/for-next (153b7306b7c6 Merge branch 'hfi1-v4' into to-be-rebased/for-4.3)
CONFLICT (content): Merge conflict in net/core/dev.c
Applying: net: merge change upper notifier changes
Merging mtd/master (5f867db63473 mtd: nand: Fix NAND_USE_BOUNCE_BUFFER flag conflict)
Merging l2-mtd/master (718e38b4d960 mtd: mtd_oobtest: Fix the address offset with vary_offset case)
Merging crypto/master (bf433416e675 crypto: algif_aead - fix for multiple operations on AF_ALG sockets)
CONFLICT (content): Merge conflict in arch/arm/configs/imx_v6_v7_defconfig
Merging drm/drm-next (879a37d00f18 Merge branch 'exynos-drm-next' of git://git.kernel.org/pub/scm/linux/kernel/git/daeinki/drm-exynos into drm-next)
CONFLICT (content): Merge conflict in arch/arm/configs/multi_v7_defconfig
Merging drm-panel/drm/panel/for-next (a33ee95f8f45 drm/bridge: Put Kconfig entries in a separate menu)
Merging drm-intel/for-linux-next (39d9b85a4d4f drm/i915: set CDCLK if DPLL0 enabled during resuming from S3)
Merging drm-tegra/drm/tegra/for-next (459cc2c6800b drm/tegra: sor: Add HDMI support)
Merging drm-misc/topic/drm-misc (6b976cc293b9 dtrm/edid: Allow comma separated edid binaries. (v3))
Merging drm-exynos/exynos-drm/for-next (1b647a166f07 Merge tag 'dmaengine-fix-4.2-rc8' of git://git.infradead.org/users/vkoul/slave-dma)
Merging drm-msm/msm-next (d248b61f6114 drm/msm/dsi: Introduce DSI configuration module)
Merging sound/for-next (22c103cd3dfa ALSA: fireworks/bebob/dice/oxfw: fix substreams counting at vmalloc failure)
Merging sound-asoc/for-next (91931320cfbb Merge remote-tracking branches 'asoc/topic/wm8996', 'asoc/topic/xtensa' and 'asoc/topic/zx296702' into asoc-next)
Merging modules/modules-next (5cfb203a304d modpost: abort if a module symbol is too long)
Merging input/next (d6f5aef298b5 Input: max8997_haptic - fix module alias)
Merging block/for-next (721cb0165e64 Merge branch 'for-4.3/drivers' into for-next)
CONFLICT (content): Merge conflict in fs/fs-writeback.c
CONFLICT (content): Merge conflict in fs/f2fs/data.c
CONFLICT (content): Merge conflict in fs/btrfs/volumes.c
CONFLICT (content): Merge conflict in fs/btrfs/scrub.c
CONFLICT (content): Merge conflict in fs/btrfs/raid56.c
CONFLICT (content): Merge conflict in fs/btrfs/inode.c
CONFLICT (content): Merge conflict in drivers/md/dm.c
CONFLICT (content): Merge conflict in crypto/ccm.c
CONFLICT (content): Merge conflict in block/bounce.c
Applying: block: lustre: temporary fix for bio_endio API change
Merging device-mapper/for-next (bd49784fd1e8 dm stats: report precise_timestamps and histogram in @stats_list output)
Merging pcmcia/master (e8e68fd86d22 pcmcia: do not break rsrc_nonstatic when handling anonymous cards)
Merging mmc/mmc-next (11bc9381b277 mmc: sdhci-s3c: use mmc_of_parse and remove the card_tasklet)
Merging mmc-uh/next (51269272a5dc mmc: core: fix race condition in mmc_wait_data_done)
Merging kgdb/kgdb-next (2d289f14f00a kdb: Fix handling of kallsyms_symbol_next() return value)
Merging md/for-next (8f4a806e5c12 md-cluster: remove inappropriate try_module_get from join())
CONFLICT (content): Merge conflict in drivers/md/raid5.c
CONFLICT (content): Merge conflict in drivers/md/raid0.c
Merging mfd/for-mfd-next (5a688c455066 mfd: jz4740-adc: Init mask cache in generic IRQ chip)
CONFLICT (content): Merge conflict in drivers/mfd/Kconfig
Merging backlight/for-backlight-next (13d20b3b618a backlight: tosa: Export I2C module alias information)
Merging battery/master (b68c3161430a bq2415x_charger: Allow to load and use driver even if notify device is not registered yet)
Merging omap_dss2/for-next (b06ece93cf96 video: fbdev: s3c-fb: Constify platform_device_id)
Merging regulator/for-next (f5164b883349 Merge remote-tracking branch 'regulator/topic/tps6586x' into regulator-next)
Merging security/next (3f1d44ae6401 Documentation/Changes: Now need OpenSSL devel packages for module signing)
CONFLICT (content): Merge conflict in security/yama/yama_lsm.c
Merging integrity/next (24fd03c87695 ima: update builtin policies)
Merging selinux/next (fda4d578ed0a selinux: explicitly declare the role "base_r")
Merging lblnet/next (b2776bf7149b Linux 3.18)
Merging watchdog/master (330de3d85671 Watchdog: Fix parent of watchdog_devices)
Merging iommu/next (4ad79562577a Merge branches 'arm/omap', 'arm/msm', 'arm/smmu', 'arm/tegra', 'x86/vt-d', 'x86/amd', 'ppc/pamu' and 'core' into next)
Merging dwmw2-iommu/master (5dbaf90a6780 iommu/vt-d: Add initial shell of SVM support)
Merging vfio/next (a714ea5fa416 MAINTAINERS: Add vfio-platform sub-maintainer)
Merging jc_docs/docs-next (ce14c5831364 Documentation, add kernel-parameters.txt entry for dis_ucode_ldr)
Merging trivial/for-next (e5f6450c3f40 MAINTAINERS: update my e-mail address)
CONFLICT (modify/delete): drivers/regulator/max77843.c deleted in HEAD and modified in trivial/for-next. Version trivial/for-next of drivers/regulator/max77843.c left in tree.
CONFLICT (content): Merge conflict in drivers/media/v4l2-core/videobuf2-memops.c
CONFLICT (content): Merge conflict in drivers/gpu/drm/nouveau/nvkm/engine/gr/nv10.c
$ git rm -f drivers/regulator/max77843.c
Merging audit/next (15ce414b82b0 fixup: audit: implement audit by executable)
CONFLICT (content): Merge conflict in kernel/audit.c
Merging devicetree/devicetree/next (48a9b733e644 of/irq: Rename "intc_desc" to "of_intc_desc" to fix OF on sh)
Merging dt-rh/for-next (126b16e2ad98 Docs: dt: add generic MSI bindings)
Merging mailbox/mailbox-for-next (86e488adaab7 mailbox: arm_mhu: reduce txpoll_period from 10ms to 1 ms)
Merging spi/for-next (b2ea64b01d83 Merge remote-tracking branches 'spi/topic/ti-qspi', 'spi/topic/xcomm' and 'spi/topic/xlp' into spi-next)
Merging tip/auto-latest (1e2d24a48445 Merge branch 'x86/platform')
CONFLICT (content): Merge conflict in arch/s390/lib/uaccess.c
CONFLICT (content): Merge conflict in arch/mips/include/asm/switch_to.h
CONFLICT (content): Merge conflict in arch/arm64/include/asm/barrier.h
CONFLICT (content): Merge conflict in arch/arm/mach-shmobile/setup-r8a7779.c
CONFLICT (modify/delete): arch/arm/mach-shmobile/intc-sh73a0.c deleted in HEAD and modified in tip/auto-latest. Version tip/auto-latest of arch/arm/mach-shmobile/intc-sh73a0.c left in tree.
$ git rm -f arch/arm/mach-shmobile/intc-sh73a0.c
Merging clockevents/clockevents/next (2b5cf544934f cris/time: Migrate to new 'set-state' interface)
Merging edac/linux_next (fa2ce64f85be sb_edac: support for Broadwell -EP and -EX)
Merging edac-amd/for-next (99e1dfb7d209 EDAC, mce_amd: Don't emit 'CE' for Deferred error)
Merging irqchip/irqchip/for-next (a8bcdc32fafb Merge branch 'irqchip/core' into irqchip/for-next)
Merging tiny/tiny/next (f114040e3ea6 Linux 3.18-rc1)
Merging ftrace/for-next (9f61668073a8 tracing: Allow triggers to filter for CPU ids and process names)
Merging rcu/rcu/next (95f2435b1f83 rcu: Change _wait_rcu_gp() to work around gcc 67055 bug)
Merging kvm/linux-next (4d283ec908e6 x86/kvm: Rename VMX's segment access rights defines)
Merging kvm-arm/next (054167b3d551 arm: KVM: keep arm vfp/simd exit handling consistent with arm64)
Merging kvm-ppc/kvm-ppc-next (c63517c2e381 KVM: PPC: Book3S: correct width in XER handling)
CONFLICT (content): Merge conflict in arch/powerpc/kvm/book3s_hv.c
Merging kvms390/next (152b28392a8d KVM: s390: Fix assumption that kvm_set_irq_routing is always run successfully)
Merging xen-tip/linux-next (50672d663eb7 xen: avoid another early crash of memory limited dom0)
CONFLICT (content): Merge conflict in arch/x86/xen/enlighten.c
Merging percpu/for-next (292c24a073ee percpu: clean up of schunk->map[] assignment in pcpu_setup_first_chunk)
Merging workqueues/for-next (355c06633e23 workqueue: fix some docbook warnings)
Merging drivers-x86/for-next (2508a45a924d surface pro 3: Add support driver for Surface Pro 3 buttons)
Merging chrome-platform/for-next (1d95e6f10fd8 platform/chrome: cros_ec: Fix possible leak in led_rgb_store())
Merging regmap/for-next (c04769e7c8bc Merge remote-tracking branches 'regmap/topic/lockdep' and 'regmap/topic/seq-delay' into regmap-next)
Applying: mfd: Fixup clients of multi_reg_write/register_patch
Merging hsi/for-next (d770e558e219 Linux 4.2-rc1)
Merging leds/for-next (4d59ed85451b leds: Export OF module alias information in missing drivers)
Merging ipmi/for-next (43ad3e6dcf35 ipmi:ssif: Add a module parm to specify that SMBus alerts don't work)
Merging driver-core/driver-core-next (71db87ba5700 bus: subsys: update return type of ->remove_dev() to void)
CONFLICT (content): Merge conflict in drivers/cpufreq/cpufreq.c
Merging tty/tty-next (c868cbb7e5c6 serial: imx: save and restore context in the suspend path)
Applying: serial: imx: partial revert of "introduce serial_imx_enable_wakeup()"
Merging usb/usb-next (44840dec6127 USB: qcserial: add HP lt4111 LTE/EV-DO/HSPA+ Gobi 4G Module)
Merging usb-gadget/next (2f3cc24f07b8 usb: musb: gadget: fix build break by adding missing 'break')
Merging usb-serial/usb-next (26c78daade0f USB: io_ti: Add heartbeat to keep idle EP/416 ports from disconnecting)
Merging staging/staging-next (415bcb5c6eff staging/lustre/o2iblnd: remove references to ib_reg_phsy_mr())
CONFLICT (modify/delete): drivers/staging/ozwpan/ozproto.c deleted in staging/staging-next and modified in HEAD. Version HEAD of drivers/staging/ozwpan/ozproto.c left in tree.
CONFLICT (content): Merge conflict in drivers/staging/lustre/lustre/include/linux/lustre_compat25.h
CONFLICT (content): Merge conflict in drivers/staging/lustre/lnet/klnds/o2iblnd/o2iblnd.h
CONFLICT (content): Merge conflict in drivers/staging/Makefile
CONFLICT (content): Merge conflict in drivers/staging/Kconfig
$ git rm -f drivers/staging/ozwpan/ozproto.c
Applying: staging/lustre: fix for bio_endio() API change
Merging char-misc/char-misc-next (672cfeeb93e5 Merge tag 'extcon-next-for-4.3' of git://git.kernel.org/pub/scm/linux/kernel/git/chanwoo/extcon into char-misc-testing)
CONFLICT (content): Merge conflict in drivers/misc/ti-st/st_kim.c
CONFLICT (content): Merge conflict in arch/x86/kernel/cpu/mshyperv.c
Applying: Drivers: hv: vmbus: fix for the removal of rdtscll()
Merging extcon/extcon-next (ac22a1d3386e extcon: palmas: Fix build break due to devm_gpiod_get_optional API change)
Merging kdbus/kdbus (a36324913ff2 kdbus: selftests: add more name registry tests)
Merging cgroup/for-next (eacb1e7d4bfa Merge branch 'for-4.3' into for-next)
Merging scsi/for-next (26a1d1ceda0a Merge branch 'misc' into for-next)
Merging target-updates/for-next (140373b074ba target/qla2xxx: Honor max_data_sg_nents I/O transfer limit)
CONFLICT (content): Merge conflict in include/scsi/scsi_eh.h
CONFLICT (content): Merge conflict in drivers/scsi/scsi_error.c
CONFLICT (content): Merge conflict in drivers/ata/libata-scsi.c
Merging target-merge/for-next-merge (db9e2f795915 mpt3sas: Refcount fw_events and fix unsafe list usage)
Merging pinctrl/for-next (1ab36387ea4f pinctrl: at91: fix null pointer dereference)
Merging vhost/linux-next (0c63b715912b PCI/MSI: Make pci_msi_shutdown(), pci_msix_shutdown() static)
Merging remoteproc/for-next (8de3dbd0895b remoteproc: fix !CONFIG_OF build breakage)
Merging rpmsg/for-next (b1b9891441fa rpmsg: use less buffers when vrings are small)
Merging gpio/for-next (0c9fc10df211 gpio: tc3589x: use static container helper)
Applying: tc358743: fix for devm_gpiod_get API change
$ git reset --hard HEAD^
Merging next-20150828 version of gpio
Applying: tc358743: fix for devm_gpiod_get API change
[master cd6c8715cd6c] next-20150828/gpio
Merging dma-mapping/dma-mapping-next (d770e558e219 Linux 4.2-rc1)
Merging pwm/for-next (01ec8472009c pwm-pca9685: Support changing the output frequency)
Merging dma-buf/for-next (86ea07ca846a Merge branch 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/s390/linux)
Merging userns/for-next (4b75de861505 fs: Set the size of empty dirs to 0.)
Merging ktest/for-next (b953c0d234bc Linux 4.1)
Merging clk/clk-next (ba3001157733 clk: s5pv210: add missing call to samsung_clk_of_add_provider())
CONFLICT (content): Merge conflict in drivers/gpu/drm/msm/dsi/pll/dsi_pll_28nm.c
CONFLICT (content): Merge conflict in drivers/clk/ti/Makefile
Merging random/dev (7185ad2672a7 crypto: memzero_explicit - make sure to clear out sensitive data)
Merging aio/master (5f785de58873 aio: Skip timer for io_getevents if timeout=0)
Merging llvmlinux/for-next (25d4aee23af2 arm: LLVMLinux: Use global stack register variable for percpu)
Merging kselftest/next (9fae100cbd10 selftests: breakpoints: fix installing error on the architecture except x86)
Merging y2038/y2038 (ed8c2241c1ae coredump: Use 64bit time for unix time of coredump)
CONFLICT (content): Merge conflict in drivers/staging/media/lirc/lirc_parallel.c
Merging luto-misc/next (a6c5170d1ede Merge branch 'for-4.0' of git://linux-nfs.org/~bfields/linux)
Merging access_once/linux-next (c231afa3ccf1 compiler.h: cast away attributes in WRITE_ONCE magic)
Merging livepatching/for-next (07d42d41dfc4 Merge branch 'for-4.3/upstream' into for-next)
Merging coresight/next (875a5c3bf336 Coresight: ETMv4: Prevent TRCRSCTLR0&1 from being accessed)
Merging rtc/rtc-next (c53d791e8e50 rtc: omap: Add external clock enabling support)
CONFLICT (content): Merge conflict in arch/arm/boot/dts/am437x-gp-evm.dts
Merging hwspinlock/for-next (bd5717a4632c hwspinlock: qcom: Correct msb in regmap_field)
Merging nvdimm/libnvdimm-for-next (004f1afbe199 libnvdimm, pmem: direct map legacy pmem by default)
CONFLICT (content): Merge conflict in mm/Kconfig
CONFLICT (content): Merge conflict in drivers/acpi/nfit.c
Merging akpm-current/current (0931fbddc5f2 lib: scatterlist: add sg splitting function)
CONFLICT (content): Merge conflict in mm/early_ioremap.c
CONFLICT (content): Merge conflict in mm/Makefile
CONFLICT (content): Merge conflict in mm/Kconfig
CONFLICT (content): Merge conflict in kernel/cgroup.c
CONFLICT (content): Merge conflict in include/linux/kexec.h
CONFLICT (modify/delete): fs/ext3/super.c deleted in HEAD and modified in akpm-current/current. Version akpm-current/current of fs/ext3/super.c left in tree.
CONFLICT (content): Merge conflict in drivers/video/console/Kconfig
CONFLICT (content): Merge conflict in arch/x86/entry/syscalls/syscall_32.tbl
$ git rm -f fs/ext3/super.c
Applying: userfaultfd: selftest: update userfaultfd x86 32bit syscall number
$ git checkout -b akpm remotes/origin/akpm/master
Applying: namei: fix warning while make xmldocs caused by namei.c
Applying: fs/seq_file: convert int seq_vprint/seq_printf/etc... returns to void
Applying: fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void-fix
Applying: fs-seq_file-convert-int-seq_vprint-seq_printf-etc-returns-to-void-fix-fix
Applying: mm: mark most vm_operations_struct const
Applying: mm, mpx: add "vm_flags_t vm_flags" arg to do_mmap_pgoff()
Applying: mm-mpx-add-vm_flags_t-vm_flags-arg-to-do_mmap_pgoff-fix
Applying: mm-mpx-add-vm_flags_t-vm_flags-arg-to-do_mmap_pgoff-fix-checkpatch-fixes
Applying: mm: make sure all file VMAs have ->vm_ops set
Applying: mm: use vma_is_anonymous() in create_huge_pmd() and wp_huge_pmd()
Applying: mm, madvise: use vma_is_anonymous() to check for anon VMA
Applying: sys_membarrier(): system-wide memory barrier (generic, x86)
Applying: selftests: add membarrier syscall test
Applying: selftests: enhance membarrier syscall test
Applying: dma-mapping: consolidate dma_{alloc,free}_{attrs,coherent}
Applying: dma-mapping: consolidate dma_{alloc,free}_noncoherent
Applying: dma-mapping: cosolidate dma_mapping_error
Applying: dma-mapping: consolidate dma_supported
Applying: dma-mapping: consolidate dma_set_mask
Applying: drivers/w1/w1_int.c: call put_device if device_register fails
Merging akpm/master (15e0fbc8a341 drivers/w1/w1_int.c: call put_device if device_register fails)

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: Don't deactivate interrupts forwarded to a guest
git bisect good 530bf353e4eb06bcba5078390c949650cd26a7c7
# first bad commit: [0b996fd35957a30568cddbce05b917c1897966e0] irqchip/GIC: Convert to EOImode == 1

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

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 <linux@roeck-us.net> 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.

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 <linux@roeck-us.net> 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.

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 <linux@roeck-us.net> 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

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 <linux@roeck-us.net> wrote:

> Hi Marc,
> 
> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 07:17:36 -0700
> > Guenter Roeck <linux@roeck-us.net> 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. Humpffff.

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

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 <linux@roeck-us.net> wrote:

> Hi Marc,
> 
> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 07:17:36 -0700
> > Guenter Roeck <linux@roeck-us.net> 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. Humpffff.

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

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 <linux@roeck-us.net> wrote:
>
>> Hi Marc,
>>
>> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
>>> On Mon, 31 Aug 2015 07:17:36 -0700
>>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
>
> - 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

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 <linux@roeck-us.net> wrote:

> Hi Marc,
> 
> On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 08:47:07 -0700
> > Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >> Hi Marc,
> >>
> >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> >>> On Mon, 31 Aug 2015 07:17:36 -0700
> >>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
> >
> > - 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 00000030
pgd = 80004000
[00000030] *pgd=00000000
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 : [<00000000>]    psr: 40000153
sp : 9f447d00  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000001  r8 : 9f49f280
r7 : 00000000  r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
r3 : 00000000  r2 : 00000000  r1 : 0000a4f4  r0 : 9f4ce400
Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8000406a  DAC: 00000055
Process swapper/0 (pid: 1, stack limit = 0x9f446210)
Stack: (0x9f447d00 to 0x9f448000)
7d00: 806aa2b4 8059aa5c 9f4ce210 00000001 9f4ce210 00000000 9f4ce210 9f49a610
7d20: 9f49f280 88000b18 00000000 00000000 00000000 802cb6a0 00000000 00000000
7d40: 802663ec 00000001 00000000 00000000 9f49f210 fffffdfb 00000000 00000000
7d60: 9f49aa50 9f4ce210 9f49f250 fffffdfb 00000000 802664cc 9f4ce210 9f4ce200
7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
7da0: 9f4ce210 806826d0 00000001 9f4ce210 9f4ce210 806826d0 fffffdfb 802b47f0
7dc0: 802b47ac 9f4ce210 806a805c 806826d0 00000001 802b2f80 00000000 9f447e08
7de0: 802b30e8 00000001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
7e00: 9f4ce244 802b2cb0 9f4ce210 00000001 9f4ce218 9f4ce218 9f4ce210 80677728
7e20: 00000000 802b23bc 9f4ce218 9f4ba000 9f4ce210 802b0784 00000000 00000001
7e40: 60000153 9f4ce200 9f4ce200 9f4ce210 00000000 9fbf02c4 00000000 9f4ba000
7e60: 00000000 80399190 00000000 9fbf0274 00000000 00000001 00000000 803992a8
7e80: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 8064d83c 00000000 80397ca8
7ea0: 00000000 9f447ea8 00000002 9fbf0274 9fbf0174 00000000 00000000 9f4ba000
7ec0: 00000001 8064d83c 00000000 803995f4 00000001 000000a5 8064d83c 9fbf0174
7ee0: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 80631b20 00000000 80666620
7f00: 80666620 80009770 8049a3ac 00000014 00000000 0000c000 cccccc00 801392ec
7f20: 00000000 8066924c 60000153 00000000 00000334 00000000 9fffce50 8003be10
7f40: 8056a05c 9fffce5b 00000002 00000002 80669234 00000000 8065b1c8 00000002
7f60: 8064d824 8068c000 8068c000 8064d83c 00000000 8061ae5c 00000002 00000002
7f80: 00000000 8061a598 00000000 80491d30 00000000 00000000 00000000 00000000
7fa0: 00000000 80491d38 00000000 8000f3e8 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<802c3e50>] (__regmap_init) from [<802cb6a0>] (vexpress_syscfg_regmap_init+0x11c/0x1d0)
[<802cb6a0>] (vexpress_syscfg_regmap_init) from [<802664cc>] (devm_regmap_init_vexpress_config+0x60/0xcc)
[<802664cc>] (devm_regmap_init_vexpress_config) from [<803a20bc>] (vexpress_osc_probe+0x30/0xf4)
[<803a20bc>] (vexpress_osc_probe) from [<802b47f0>] (platform_drv_probe+0x44/0xa4)
[<802b47f0>] (platform_drv_probe) from [<802b2f80>] (driver_probe_device+0x24c/0x2f0)
[<802b2f80>] (driver_probe_device) from [<802b1478>] (bus_for_each_drv+0x64/0x98)
[<802b1478>] (bus_for_each_drv) from [<802b2cb0>] (__device_attach+0xa4/0x104)
[<802b2cb0>] (__device_attach) from [<802b23bc>] (bus_probe_device+0x84/0x8c)
[<802b23bc>] (bus_probe_device) from [<802b0784>] (device_add+0x3e4/0x56c)
[<802b0784>] (device_add) from [<80399190>] (of_platform_device_create_pdata+0x84/0xb8)
[<80399190>] (of_platform_device_create_pdata) from [<803992a8>] (of_platform_bus_create+0xd8/0x2f8)
[<803992a8>] (of_platform_bus_create) from [<803995f4>] (of_platform_populate+0x5c/0xac)
[<803995f4>] (of_platform_populate) from [<80631b20>] (vexpress_config_init+0x9c/0xc8)
[<80631b20>] (vexpress_config_init) from [<80009770>] (do_one_initcall+0x8c/0x1d4)
[<80009770>] (do_one_initcall) from [<8061ae5c>] (kernel_init_freeable+0x1d8/0x278)
[<8061ae5c>] (kernel_init_freeable) from [<80491d38>] (kernel_init+0x8/0xe8)
[<80491d38>] (kernel_init) from [<8000f3e8>] (ret_from_fork+0x14/0x2c)
Code: e2933000 13a03001 e5c43132 e30a14f4 (e5973030) 
---[ end trace 5ab4f97e42f4e880 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

And it dies the same way whether I have these GIC patches in or not.
Talk about consistency...

> 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 had a quick look, and there is nothing I can immediately spot.
 
> > 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.

So this seems to be specific to qemu 2.4 then. Time to build the sucker.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

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 <linux@roeck-us.net> wrote:

> Hi Marc,
> 
> On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > On Mon, 31 Aug 2015 08:47:07 -0700
> > Guenter Roeck <linux@roeck-us.net> wrote:
> >
> >> Hi Marc,
> >>
> >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> >>> On Mon, 31 Aug 2015 07:17:36 -0700
> >>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
> >
> > - 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 00000030
pgd = 80004000
[00000030] *pgd=00000000
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 : [<00000000>]    psr: 40000153
sp : 9f447d00  ip : 00000000  fp : 00000000
r10: 00000000  r9 : 00000001  r8 : 9f49f280
r7 : 00000000  r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
r3 : 00000000  r2 : 00000000  r1 : 0000a4f4  r0 : 9f4ce400
Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
Control: 10c5387d  Table: 8000406a  DAC: 00000055
Process swapper/0 (pid: 1, stack limit = 0x9f446210)
Stack: (0x9f447d00 to 0x9f448000)
7d00: 806aa2b4 8059aa5c 9f4ce210 00000001 9f4ce210 00000000 9f4ce210 9f49a610
7d20: 9f49f280 88000b18 00000000 00000000 00000000 802cb6a0 00000000 00000000
7d40: 802663ec 00000001 00000000 00000000 9f49f210 fffffdfb 00000000 00000000
7d60: 9f49aa50 9f4ce210 9f49f250 fffffdfb 00000000 802664cc 9f4ce210 9f4ce200
7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
7da0: 9f4ce210 806826d0 00000001 9f4ce210 9f4ce210 806826d0 fffffdfb 802b47f0
7dc0: 802b47ac 9f4ce210 806a805c 806826d0 00000001 802b2f80 00000000 9f447e08
7de0: 802b30e8 00000001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
7e00: 9f4ce244 802b2cb0 9f4ce210 00000001 9f4ce218 9f4ce218 9f4ce210 80677728
7e20: 00000000 802b23bc 9f4ce218 9f4ba000 9f4ce210 802b0784 00000000 00000001
7e40: 60000153 9f4ce200 9f4ce200 9f4ce210 00000000 9fbf02c4 00000000 9f4ba000
7e60: 00000000 80399190 00000000 9fbf0274 00000000 00000001 00000000 803992a8
7e80: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 8064d83c 00000000 80397ca8
7ea0: 00000000 9f447ea8 00000002 9fbf0274 9fbf0174 00000000 00000000 9f4ba000
7ec0: 00000001 8064d83c 00000000 803995f4 00000001 000000a5 8064d83c 9fbf0174
7ee0: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 80631b20 00000000 80666620
7f00: 80666620 80009770 8049a3ac 00000014 00000000 0000c000 cccccc00 801392ec
7f20: 00000000 8066924c 60000153 00000000 00000334 00000000 9fffce50 8003be10
7f40: 8056a05c 9fffce5b 00000002 00000002 80669234 00000000 8065b1c8 00000002
7f60: 8064d824 8068c000 8068c000 8064d83c 00000000 8061ae5c 00000002 00000002
7f80: 00000000 8061a598 00000000 80491d30 00000000 00000000 00000000 00000000
7fa0: 00000000 80491d38 00000000 8000f3e8 00000000 00000000 00000000 00000000
7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
[<802c3e50>] (__regmap_init) from [<802cb6a0>] (vexpress_syscfg_regmap_init+0x11c/0x1d0)
[<802cb6a0>] (vexpress_syscfg_regmap_init) from [<802664cc>] (devm_regmap_init_vexpress_config+0x60/0xcc)
[<802664cc>] (devm_regmap_init_vexpress_config) from [<803a20bc>] (vexpress_osc_probe+0x30/0xf4)
[<803a20bc>] (vexpress_osc_probe) from [<802b47f0>] (platform_drv_probe+0x44/0xa4)
[<802b47f0>] (platform_drv_probe) from [<802b2f80>] (driver_probe_device+0x24c/0x2f0)
[<802b2f80>] (driver_probe_device) from [<802b1478>] (bus_for_each_drv+0x64/0x98)
[<802b1478>] (bus_for_each_drv) from [<802b2cb0>] (__device_attach+0xa4/0x104)
[<802b2cb0>] (__device_attach) from [<802b23bc>] (bus_probe_device+0x84/0x8c)
[<802b23bc>] (bus_probe_device) from [<802b0784>] (device_add+0x3e4/0x56c)
[<802b0784>] (device_add) from [<80399190>] (of_platform_device_create_pdata+0x84/0xb8)
[<80399190>] (of_platform_device_create_pdata) from [<803992a8>] (of_platform_bus_create+0xd8/0x2f8)
[<803992a8>] (of_platform_bus_create) from [<803995f4>] (of_platform_populate+0x5c/0xac)
[<803995f4>] (of_platform_populate) from [<80631b20>] (vexpress_config_init+0x9c/0xc8)
[<80631b20>] (vexpress_config_init) from [<80009770>] (do_one_initcall+0x8c/0x1d4)
[<80009770>] (do_one_initcall) from [<8061ae5c>] (kernel_init_freeable+0x1d8/0x278)
[<8061ae5c>] (kernel_init_freeable) from [<80491d38>] (kernel_init+0x8/0xe8)
[<80491d38>] (kernel_init) from [<8000f3e8>] (ret_from_fork+0x14/0x2c)
Code: e2933000 13a03001 e5c43132 e30a14f4 (e5973030) 
---[ end trace 5ab4f97e42f4e880 ]---
Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b

And it dies the same way whether I have these GIC patches in or not.
Talk about consistency...

> 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 had a quick look, and there is nothing I can immediately spot.
 
> > 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.

So this seems to be specific to qemu 2.4 then. Time to build the sucker.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny.

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 <marc.zyngier@arm.com> wrote:

Hi Guenter,

> On Mon, 31 Aug 2015 09:40:43 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
> 
> > Hi Marc,
> > 
> > On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > > On Mon, 31 Aug 2015 08:47:07 -0700
> > > Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > >> Hi Marc,
> > >>
> > >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > >>> On Mon, 31 Aug 2015 07:17:36 -0700
> > >>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
> > >
> > > - 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 00000030
> pgd = 80004000
> [00000030] *pgd=00000000
> 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 : [<00000000>]    psr: 40000153
> sp : 9f447d00  ip : 00000000  fp : 00000000
> r10: 00000000  r9 : 00000001  r8 : 9f49f280
> r7 : 00000000  r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
> r3 : 00000000  r2 : 00000000  r1 : 0000a4f4  r0 : 9f4ce400
> Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 8000406a  DAC: 00000055
> Process swapper/0 (pid: 1, stack limit = 0x9f446210)
> Stack: (0x9f447d00 to 0x9f448000)
> 7d00: 806aa2b4 8059aa5c 9f4ce210 00000001 9f4ce210 00000000 9f4ce210 9f49a610
> 7d20: 9f49f280 88000b18 00000000 00000000 00000000 802cb6a0 00000000 00000000
> 7d40: 802663ec 00000001 00000000 00000000 9f49f210 fffffdfb 00000000 00000000
> 7d60: 9f49aa50 9f4ce210 9f49f250 fffffdfb 00000000 802664cc 9f4ce210 9f4ce200
> 7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
> 7da0: 9f4ce210 806826d0 00000001 9f4ce210 9f4ce210 806826d0 fffffdfb 802b47f0
> 7dc0: 802b47ac 9f4ce210 806a805c 806826d0 00000001 802b2f80 00000000 9f447e08
> 7de0: 802b30e8 00000001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
> 7e00: 9f4ce244 802b2cb0 9f4ce210 00000001 9f4ce218 9f4ce218 9f4ce210 80677728
> 7e20: 00000000 802b23bc 9f4ce218 9f4ba000 9f4ce210 802b0784 00000000 00000001
> 7e40: 60000153 9f4ce200 9f4ce200 9f4ce210 00000000 9fbf02c4 00000000 9f4ba000
> 7e60: 00000000 80399190 00000000 9fbf0274 00000000 00000001 00000000 803992a8
> 7e80: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 8064d83c 00000000 80397ca8
> 7ea0: 00000000 9f447ea8 00000002 9fbf0274 9fbf0174 00000000 00000000 9f4ba000
> 7ec0: 00000001 8064d83c 00000000 803995f4 00000001 000000a5 8064d83c 9fbf0174
> 7ee0: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 80631b20 00000000 80666620
> 7f00: 80666620 80009770 8049a3ac 00000014 00000000 0000c000 cccccc00 801392ec
> 7f20: 00000000 8066924c 60000153 00000000 00000334 00000000 9fffce50 8003be10
> 7f40: 8056a05c 9fffce5b 00000002 00000002 80669234 00000000 8065b1c8 00000002
> 7f60: 8064d824 8068c000 8068c000 8064d83c 00000000 8061ae5c 00000002 00000002
> 7f80: 00000000 8061a598 00000000 80491d30 00000000 00000000 00000000 00000000
> 7fa0: 00000000 80491d38 00000000 8000f3e8 00000000 00000000 00000000 00000000
> 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<802c3e50>] (__regmap_init) from [<802cb6a0>] (vexpress_syscfg_regmap_init+0x11c/0x1d0)
> [<802cb6a0>] (vexpress_syscfg_regmap_init) from [<802664cc>] (devm_regmap_init_vexpress_config+0x60/0xcc)
> [<802664cc>] (devm_regmap_init_vexpress_config) from [<803a20bc>] (vexpress_osc_probe+0x30/0xf4)
> [<803a20bc>] (vexpress_osc_probe) from [<802b47f0>] (platform_drv_probe+0x44/0xa4)
> [<802b47f0>] (platform_drv_probe) from [<802b2f80>] (driver_probe_device+0x24c/0x2f0)
> [<802b2f80>] (driver_probe_device) from [<802b1478>] (bus_for_each_drv+0x64/0x98)
> [<802b1478>] (bus_for_each_drv) from [<802b2cb0>] (__device_attach+0xa4/0x104)
> [<802b2cb0>] (__device_attach) from [<802b23bc>] (bus_probe_device+0x84/0x8c)
> [<802b23bc>] (bus_probe_device) from [<802b0784>] (device_add+0x3e4/0x56c)
> [<802b0784>] (device_add) from [<80399190>] (of_platform_device_create_pdata+0x84/0xb8)
> [<80399190>] (of_platform_device_create_pdata) from [<803992a8>] (of_platform_bus_create+0xd8/0x2f8)
> [<803992a8>] (of_platform_bus_create) from [<803995f4>] (of_platform_populate+0x5c/0xac)
> [<803995f4>] (of_platform_populate) from [<80631b20>] (vexpress_config_init+0x9c/0xc8)
> [<80631b20>] (vexpress_config_init) from [<80009770>] (do_one_initcall+0x8c/0x1d4)
> [<80009770>] (do_one_initcall) from [<8061ae5c>] (kernel_init_freeable+0x1d8/0x278)
> [<8061ae5c>] (kernel_init_freeable) from [<80491d38>] (kernel_init+0x8/0xe8)
> [<80491d38>] (kernel_init) from [<8000f3e8>] (ret_from_fork+0x14/0x2c)
> Code: e2933000 13a03001 e5c43132 e30a14f4 (e5973030) 
> ---[ end trace 5ab4f97e42f4e880 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> 
> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> 
> And it dies the same way whether I have these GIC patches in or not.
> Talk about consistency...
> 
> > 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 had a quick look, and there is nothing I can immediately spot.
>  
> > > 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.
> 
> So this seems to be specific to qemu 2.4 then. Time to build the sucker.

[+Broonie, Markus]

I've now built qemu 2.4, and reverting these two patches doesn't fix a
single thing (the behaviour is the same as the one I described above).

Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann <mpa@pengutronix.de>
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 <mpa@pengutronix.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

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 <marc.zyngier@arm.com>
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 <marc.zyngier@arm.com>
---
 drivers/base/regmap/regmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 650d3b1..0fdde9d 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -574,8 +574,8 @@ struct regmap *__regmap_init(struct device *dev,
 	map->use_single_read = config->use_single_rw || !bus || !bus->read;
 	map->use_single_write = config->use_single_rw || !bus || !bus->write;
 	map->can_multi_write = config->can_multi_write && bus && bus->write;
-	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;
 	map->dev = dev;
 	map->bus = bus;
 	map->bus_context = bus_context;
-- 
2.1.4

I'd really like to understand why you observe failures with your
version of qemu, while I cannot reproduce them. What patches do you
have on top of qemu? Is your tree available somewhere?

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

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 <marc.zyngier@arm.com> wrote:

Hi Guenter,

> On Mon, 31 Aug 2015 09:40:43 -0700
> Guenter Roeck <linux@roeck-us.net> wrote:
> 
> > Hi Marc,
> > 
> > On 08/31/2015 09:18 AM, Marc Zyngier wrote:
> > > On Mon, 31 Aug 2015 08:47:07 -0700
> > > Guenter Roeck <linux@roeck-us.net> wrote:
> > >
> > >> Hi Marc,
> > >>
> > >> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
> > >>> On Mon, 31 Aug 2015 07:17:36 -0700
> > >>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
> > >
> > > - 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 00000030
> pgd = 80004000
> [00000030] *pgd=00000000
> 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 : [<00000000>]    psr: 40000153
> sp : 9f447d00  ip : 00000000  fp : 00000000
> r10: 00000000  r9 : 00000001  r8 : 9f49f280
> r7 : 00000000  r6 : 80697990  r5 : 80678034  r4 : 9f4ce400
> r3 : 00000000  r2 : 00000000  r1 : 0000a4f4  r0 : 9f4ce400
> Flags: nZcv  IRQs on  FIQs off  Mode SVC_32  ISA ARM  Segment kernel
> Control: 10c5387d  Table: 8000406a  DAC: 00000055
> Process swapper/0 (pid: 1, stack limit = 0x9f446210)
> Stack: (0x9f447d00 to 0x9f448000)
> 7d00: 806aa2b4 8059aa5c 9f4ce210 00000001 9f4ce210 00000000 9f4ce210 9f49a610
> 7d20: 9f49f280 88000b18 00000000 00000000 00000000 802cb6a0 00000000 00000000
> 7d40: 802663ec 00000001 00000000 00000000 9f49f210 fffffdfb 00000000 00000000
> 7d60: 9f49aa50 9f4ce210 9f49f250 fffffdfb 00000000 802664cc 9f4ce210 9f4ce200
> 7d80: 9f49f210 803a20bc 9f49be10 9f49bc30 9f4a0280 80597704 9f49be10 9f4ce210
> 7da0: 9f4ce210 806826d0 00000001 9f4ce210 9f4ce210 806826d0 fffffdfb 802b47f0
> 7dc0: 802b47ac 9f4ce210 806a805c 806826d0 00000001 802b2f80 00000000 9f447e08
> 7de0: 802b30e8 00000001 806a8038 802b1478 9f422970 9f49c0b8 9f4ce210 9f4ce210
> 7e00: 9f4ce244 802b2cb0 9f4ce210 00000001 9f4ce218 9f4ce218 9f4ce210 80677728
> 7e20: 00000000 802b23bc 9f4ce218 9f4ba000 9f4ce210 802b0784 00000000 00000001
> 7e40: 60000153 9f4ce200 9f4ce200 9f4ce210 00000000 9fbf02c4 00000000 9f4ba000
> 7e60: 00000000 80399190 00000000 9fbf0274 00000000 00000001 00000000 803992a8
> 7e80: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 8064d83c 00000000 80397ca8
> 7ea0: 00000000 9f447ea8 00000002 9fbf0274 9fbf0174 00000000 00000000 9f4ba000
> 7ec0: 00000001 8064d83c 00000000 803995f4 00000001 000000a5 8064d83c 9fbf0174
> 7ee0: 806a4e60 9f49f0c0 80631a84 00000000 000000a5 80631b20 00000000 80666620
> 7f00: 80666620 80009770 8049a3ac 00000014 00000000 0000c000 cccccc00 801392ec
> 7f20: 00000000 8066924c 60000153 00000000 00000334 00000000 9fffce50 8003be10
> 7f40: 8056a05c 9fffce5b 00000002 00000002 80669234 00000000 8065b1c8 00000002
> 7f60: 8064d824 8068c000 8068c000 8064d83c 00000000 8061ae5c 00000002 00000002
> 7f80: 00000000 8061a598 00000000 80491d30 00000000 00000000 00000000 00000000
> 7fa0: 00000000 80491d38 00000000 8000f3e8 00000000 00000000 00000000 00000000
> 7fc0: 00000000 00000000 00000000 00000000 00000000 00000000 00000000 00000000
> 7fe0: 00000000 00000000 00000000 00000000 00000013 00000000 00000000 00000000
> [<802c3e50>] (__regmap_init) from [<802cb6a0>] (vexpress_syscfg_regmap_init+0x11c/0x1d0)
> [<802cb6a0>] (vexpress_syscfg_regmap_init) from [<802664cc>] (devm_regmap_init_vexpress_config+0x60/0xcc)
> [<802664cc>] (devm_regmap_init_vexpress_config) from [<803a20bc>] (vexpress_osc_probe+0x30/0xf4)
> [<803a20bc>] (vexpress_osc_probe) from [<802b47f0>] (platform_drv_probe+0x44/0xa4)
> [<802b47f0>] (platform_drv_probe) from [<802b2f80>] (driver_probe_device+0x24c/0x2f0)
> [<802b2f80>] (driver_probe_device) from [<802b1478>] (bus_for_each_drv+0x64/0x98)
> [<802b1478>] (bus_for_each_drv) from [<802b2cb0>] (__device_attach+0xa4/0x104)
> [<802b2cb0>] (__device_attach) from [<802b23bc>] (bus_probe_device+0x84/0x8c)
> [<802b23bc>] (bus_probe_device) from [<802b0784>] (device_add+0x3e4/0x56c)
> [<802b0784>] (device_add) from [<80399190>] (of_platform_device_create_pdata+0x84/0xb8)
> [<80399190>] (of_platform_device_create_pdata) from [<803992a8>] (of_platform_bus_create+0xd8/0x2f8)
> [<803992a8>] (of_platform_bus_create) from [<803995f4>] (of_platform_populate+0x5c/0xac)
> [<803995f4>] (of_platform_populate) from [<80631b20>] (vexpress_config_init+0x9c/0xc8)
> [<80631b20>] (vexpress_config_init) from [<80009770>] (do_one_initcall+0x8c/0x1d4)
> [<80009770>] (do_one_initcall) from [<8061ae5c>] (kernel_init_freeable+0x1d8/0x278)
> [<8061ae5c>] (kernel_init_freeable) from [<80491d38>] (kernel_init+0x8/0xe8)
> [<80491d38>] (kernel_init) from [<8000f3e8>] (ret_from_fork+0x14/0x2c)
> Code: e2933000 13a03001 e5c43132 e30a14f4 (e5973030) 
> ---[ end trace 5ab4f97e42f4e880 ]---
> Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> 
> ---[ end Kernel panic - not syncing: Attempted to kill init! exitcode=0x0000000b
> 
> And it dies the same way whether I have these GIC patches in or not.
> Talk about consistency...
> 
> > 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 had a quick look, and there is nothing I can immediately spot.
>  
> > > 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.
> 
> So this seems to be specific to qemu 2.4 then. Time to build the sucker.

[+Broonie, Markus]

I've now built qemu 2.4, and reverting these two patches doesn't fix a
single thing (the behaviour is the same as the one I described above).

Actually, the kernel dies because of this:

commit adaac459759db4a1fd35baddbe47bac700095496
Author: Markus Pargmann <mpa@pengutronix.de>
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 <mpa@pengutronix.de>
    Signed-off-by: Mark Brown <broonie@kernel.org>

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 <marc.zyngier@arm.com>
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 <marc.zyngier@arm.com>
---
 drivers/base/regmap/regmap.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/drivers/base/regmap/regmap.c b/drivers/base/regmap/regmap.c
index 650d3b1..0fdde9d 100644
--- a/drivers/base/regmap/regmap.c
+++ b/drivers/base/regmap/regmap.c
@@ -574,8 +574,8 @@ struct regmap *__regmap_init(struct device *dev,
 	map->use_single_read = config->use_single_rw || !bus || !bus->read;
 	map->use_single_write = config->use_single_rw || !bus || !bus->write;
 	map->can_multi_write = config->can_multi_write && bus && bus->write;
-	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;
 	map->dev = dev;
 	map->bus = bus;
 	map->bus_context = bus_context;
-- 
2.1.4

I'd really like to understand why you observe failures with your
version of qemu, while I cannot reproduce them. What patches do you
have on top of qemu? Is your tree available somewhere?

Thanks,

	M.
-- 
Without deviation from the norm, progress is not possible.

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 <linux@roeck-us.net> wrote:
>
>> Hi Marc,
>>
>> On 08/31/2015 09:18 AM, Marc Zyngier wrote:
>>> On Mon, 31 Aug 2015 08:47:07 -0700
>>> Guenter Roeck <linux@roeck-us.net> wrote:
>>>
>>>> Hi Marc,
>>>>
>>>> On 08/31/2015 08:31 AM, Marc Zyngier wrote:
>>>>> On Mon, 31 Aug 2015 07:17:36 -0700
>>>>> Guenter Roeck <linux@roeck-us.net> 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. Humpffff.
>>>
>>> - 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

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 <mpa@pengutronix.de>
> 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 <mpa@pengutronix.de>
>      Signed-off-by: Mark Brown <broonie@kernel.org>
>
> 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 <marc.zyngier@arm.com>
> 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 <marc.zyngier@arm.com>

Yes, that fixes the vexpress failures.

Tested-by: Guenter Roeck <linux@roeck-us.net>

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

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 <linux@roeck-us.net> 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 <mpa@pengutronix.de>
> > 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 <mpa@pengutronix.de>
> >      Signed-off-by: Mark Brown <broonie@kernel.org>
> >
> > 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 <marc.zyngier@arm.com>
> > 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 <marc.zyngier@arm.com>
> 
> Yes, that fixes the vexpress failures.
> 
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> 
> 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 <marc.zyngier@arm.com>
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 <marc.zyngier@arm.com>
---
 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() and acpi_gsi_to_irq()).
 	 */
-	gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+	__gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
 	irq_set_default_host(gic_data[0].domain);
 
 	acpi_irq_model = ACPI_IRQ_MODEL_GIC;
-- 
2.1.4

Can you give it a whirl? It makes the PB-A8 emulation work correctly
here.

> 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 ?

I enable earlyprintk, which makes debugging much easier...  Of course,
earlyprintk comes with its own set of issues (it is the absolute
negation of any form of multiplatform kernel), which is why it is
disabled by default.

Thanks,

	M. 
-- 
Without deviation from the norm, progress is not possible.

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 <linux@roeck-us.net> 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 <mpa@pengutronix.de>
> > 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 <mpa@pengutronix.de>
> >      Signed-off-by: Mark Brown <broonie@kernel.org>
> >
> > 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 <marc.zyngier@arm.com>
> > 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 <marc.zyngier@arm.com>
> 
> Yes, that fixes the vexpress failures.
> 
> Tested-by: Guenter Roeck <linux@roeck-us.net>
> 
> 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 <marc.zyngier@arm.com>
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 <marc.zyngier@arm.com>
---
 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() and acpi_gsi_to_irq()).
 	 */
-	gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
+	__gic_init_bases(0, -1, dist_base, cpu_base, 0, NULL);
 	irq_set_default_host(gic_data[0].domain);
 
 	acpi_irq_model = ACPI_IRQ_MODEL_GIC;
-- 
2.1.4

Can you give it a whirl? It makes the PB-A8 emulation work correctly
here.

> 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 ?

I enable earlyprintk, which makes debugging much easier...  Of course,
earlyprintk comes with its own set of issues (it is the absolute
negation of any form of multiplatform kernel), which is why it is
disabled by default.

Thanks,

	M. 
-- 
Without deviation from the norm, progress is not possible.

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 <linux@roeck-us.net> 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 <mpa@pengutronix.de>
>>> 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 <mpa@pengutronix.de>
>>>       Signed-off-by: Mark Brown <broonie@kernel.org>
>>>
>>> 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 <marc.zyngier@arm.com>
>>> 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 <marc.zyngier@arm.com>
>>
>> Yes, that fixes the vexpress failures.
>>
>> Tested-by: Guenter Roeck <linux@roeck-us.net>
>>
>> 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 <marc.zyngier@arm.com>
> 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 <marc.zyngier@arm.com>

Yep, that fixes the problem.

Tested-by: Guenter Roeck <linux@roeck-us.net>

Thanks,
Guenter

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

[Mark Brown]

[-- Attachment #1: Type: text/plain, Size: 888 bytes --]

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 <marc.zyngier@arm.com>
> 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.

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]