* [qemu-upstream-unstable test] 114014: regressions - FAIL
From: osstest service owner @ 2017-10-05 4:16 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 114014 qemu-upstream-unstable real [real]
http://logs.test-lab.xenproject.org/osstest/logs/114014/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-armhf-armhf-xl-credit2 16 guest-start/debian.repeat fail REGR. vs. 113699
Tests which did not succeed, but are not blocking:
test-armhf-armhf-libvirt 14 saverestore-support-check fail like 113668
test-armhf-armhf-libvirt-xsm 14 saverestore-support-check fail like 113699
test-armhf-armhf-xl-rtds 16 guest-start/debian.repeat fail like 113699
test-armhf-armhf-libvirt-raw 13 saverestore-support-check fail like 113699
test-amd64-amd64-xl-qemuu-ws16-amd64 10 windows-install fail never pass
test-amd64-amd64-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-i386-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-xsm 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt 13 migrate-support-check fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt 13 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 11 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-amd64-i386-libvirt-qcow2 12 migrate-support-check fail never pass
test-amd64-amd64-libvirt-vhd 12 migrate-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 13 guest-saverestore fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 13 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemuu-win10-i386 10 windows-install fail never pass
test-amd64-amd64-xl-qemuu-win10-i386 10 windows-install fail never pass
version targeted for testing:
qemuu 7434775abf8fb2ca3b9e805d30656f4da8c08816
baseline version:
qemuu 0b157f8d977a9425e2d8d510aa011c5d4f3ec247
Last test of basis 113699 2017-09-22 00:47:51 Z 13 days
Testing same since 114014 2017-10-04 17:49:35 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Gerd Hoffmann <kraxel@redhat.com>
Stefano Stabellini <sstabellini@kernel.org>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm pass
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemuu-win7-amd64 pass
test-amd64-i386-xl-qemuu-win7-amd64 pass
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 fail
test-armhf-armhf-xl-cubietruck pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-xl-qemuu-win10-i386 fail
test-amd64-i386-xl-qemuu-win10-i386 fail
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvh-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt pass
test-amd64-i386-libvirt pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair pass
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-amd64-i386-libvirt-qcow2 pass
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw pass
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds fail
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 7434775abf8fb2ca3b9e805d30656f4da8c08816
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon Aug 28 14:29:06 2017 +0200
vga: stop passing pointers to vga_draw_line* functions
Instead pass around the address (aka offset into vga memory).
Add vga_read_* helper functions which apply vbe_size_mask to
the address, to make sure the address stays within the valid
range, similar to the cirrus blitter fixes (commits ffaf857778
and 026aeffcb4).
Impact: DoS for privileged guest users. qemu crashes with
a segfault, when hitting the guard page after vga memory
allocation, while reading vga memory for display updates.
cherry picked from commit 3d90c6254863693a6b13d918d2b8682e08bbc681
Fixes: CVE-2017-13672
Cc: P J P <ppandit@redhat.com>
Reported-by: David Buchanan <d@vidbuchanan.co.uk>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Message-id: 20170828122906.18993-1-kraxel@redhat.com
commit 99207110178edf883c797035cc70d8d6a80f616c
Author: Gerd Hoffmann <kraxel@redhat.com>
Date: Mon Aug 28 14:33:07 2017 +0200
vga: fix display update region calculation (split screen)
vga display update mis-calculated the region for the dirty bitmap
snapshot in case split screen mode is used. This can trigger an
assert in cpu_physical_memory_snapshot_get_dirty().
Impact: DoS for privileged guest users.
(cherry picked from commit e65294157d4b69393b3f819c99f4f647452b48e3)
Fixes: CVE-2017-13673
Fixes: fec5e8c92becad223df9d972770522f64aafdb72
Cc: P J P <ppandit@redhat.com>
Reported-by: David Buchanan <d@vidbuchanan.co.uk>
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Message-id: 20170828123307.15392-1-kraxel@redhat.com
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [PATCH 1/5] comp128: GSM algorithm (comp128) implementation.
From: Harald Welte @ 2017-10-05 4:16 UTC (permalink / raw)
To: ofono
In-Reply-To: <1507048516-15623-1-git-send-email-james.prestwood@linux.intel.com>
[-- Attachment #1: Type: text/plain, Size: 754 bytes --]
Hi James,
there are three COMP128 algorithms: v1, v2 and v3.
The code you're submitting only implements COMP128v1, so I suggest you document
that in the commit log / subject to avoid any misunderstandings.
Just stating "COMP128" typically refers to the entire family of algorithms.
A GPLv2+ licensed implementation for v2 and v3 can be found at
http://cgit.osmocom.org/libosmocore/plain/src/gsm/comp in case you ever need it.
--
- Harald Welte <laforge@gnumonks.org> http://laforge.gnumonks.org/
============================================================================
"Privacy in residential applications is a desirable marketing option."
(ETSI EN 300 175-7 Ch. A6)
^ permalink raw reply
* Re: [v3,1/2] powerpc/mm: Export flush_all_mm()
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Frederic Barrat, linuxppc-dev, benh, andrew.donnellan, clombard,
vaibhav
Cc: alistair
In-Reply-To: <20170903181513.29635-1-fbarrat@linux.vnet.ibm.com>
On Sun, 2017-09-03 at 18:15:12 UTC, Frederic Barrat wrote:
> With the optimizations introduced by commit a46cc7a90fd8
> ("powerpc/mm/radix: Improve TLB/PWC flushes"), flush_tlb_mm() no
> longer flushes the page walk cache with radix. This patch introduces
> flush_all_mm(), which flushes everything, tlb and pwc, for a given mm.
>
> Signed-off-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Reviewed-By: Alistair Popple <alistair@popple.id.au>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/6110236b9bbd177debc045c5fc2922
cheers
^ permalink raw reply
* Re: [v2] cxl: Set the valid bit in PE for dedicated mode
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Vaibhav Jain, linuxppc-dev, Frederic Barrat
Cc: Philippe Bergheaud, Alastair D'Silva, Vaibhav Jain,
Andrew Donnellan, Christophe Lombard
In-Reply-To: <20170904084825.22172-1-vaibhav@linux.vnet.ibm.com>
On Mon, 2017-09-04 at 08:48:25 UTC, Vaibhav Jain wrote:
> Make sure to set the valid-bit in software-state field of the
> populated PE. This was earlier missing for dedicated mode AFUs, hence
> was causing a PSL freeze when the AFU was activated.
>
> Signed-off-by: Vaibhav Jain <vaibhav@linux.vnet.ibm.com>
> Acked-by: Frederic Barrat <fbarrat@linux.vnet.ibm.com>
> Acked-by: Andrew Donnellan <andrew.donnellan@au1.ibm.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/8512bffd6226fea259f94fd23fc3b6
cheers
^ permalink raw reply
* Re: [1/3] powerpc: oprofile: use setup_timer() helper.
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Allen Pais, paulus; +Cc: linuxppc-dev, Allen Pais
In-Reply-To: <1506080100-5660-2-git-send-email-allen.lkml@gmail.com>
On Fri, 2017-09-22 at 11:34:58 UTC, Allen Pais wrote:
> Use setup_timer function instead of initializing timer with the
> function and data fields.
>
> Signed-off-by: Allen Pais <allen.lkml@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/83ad1e6a1dc049dd04be4564125a7f
cheers
^ permalink raw reply
* Re: powerpc/powernv: Use early_radix_enabled in POWER9 tlb flush
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Meng YK Li, Jeremy Kerr, Nicholas Piggin
In-Reply-To: <20170927054558.26007-1-npiggin@gmail.com>
On Wed, 2017-09-27 at 05:45:58 UTC, Nicholas Piggin wrote:
> This code is used at boot and machine checks, so it should be using
> early_radix_enabled() (which is usable any time).
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/969a86a2855d484a00205a424df1c6
cheers
^ permalink raw reply
* Re: [v2, 1/6] powerpc/watchdog: do not panic from locked CPU's IPI handler
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Nicholas Piggin, linuxppc-dev; +Cc: Nicholas Piggin
In-Reply-To: <20170929032942.4321-2-npiggin@gmail.com>
On Fri, 2017-09-29 at 03:29:37 UTC, Nicholas Piggin wrote:
> The SMP watchdog will detect locked CPUs and IPI them to print a
> backtrace and registers. If panic on hard lockup is enabled, do
> not panic from this handler, because that can cause recursion into
> the IPI layer during the panic.
>
> The caller already panics in this case.
>
> Signed-off-by: Nicholas Piggin <npiggin@gmail.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/842dc1dbabb5e874550b52d896851e
cheers
^ permalink raw reply
* Re: [1/3] powerpc/lib/sstep: Add XER bits introduced in POWER ISA v3.0
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Sandipan Das; +Cc: linuxppc-dev, naveen.n.rao, paulus, anton
In-Reply-To: <20170929054410.12600-1-sandipan@linux.vnet.ibm.com>
On Fri, 2017-09-29 at 05:44:08 UTC, Sandipan Das wrote:
> This adds definitions for the OV32 and CA32 bits of XER that
> were introduced in POWER ISA v3.0. There are some existing
> instructions that currently set the OV and CA bits based on
> certain conditions.
>
> The emulation behaviour of all these instructions needs to
> be updated to set these new bits accordingly.
>
> Signed-off-by: Sandipan Das <sandipan@linux.vnet.ibm.com>
> Acked-by: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Series applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/924c8feb041c3ef22d46ac2e746816
cheers
^ permalink raw reply
* Re: [v2] powerpc: configs: Add Skiroot defconfig
From: Michael Ellerman @ 2017-10-05 4:21 UTC (permalink / raw)
To: Joel Stanley; +Cc: Stewart Smith, linuxppc-dev, Jeremy Kerr
In-Reply-To: <20171004042324.32129-1-joel@jms.id.au>
On Wed, 2017-10-04 at 04:23:24 UTC, Joel Stanley wrote:
> This configuration is used by the OpenPower firmware for it's
> Linux-as-bootloader implementation. Also known as the Petitboot kernel,
> this configuration broke in 4.12 (CPU_HOTPLUG=n), so add it to the
> upstream tree in order to get better coverage.
>
> Signed-off-by: Joel Stanley <joel@jms.id.au>
Applied to powerpc next, thanks.
https://git.kernel.org/powerpc/c/c3dda4b0db9cf5044010e4de88e5e5
cheers
^ permalink raw reply
* [PATCH 0/2] fix build failure for use-mainline-bsp
From: Hiraku Toyooka @ 2017-10-05 4:21 UTC (permalink / raw)
To: meta-freescale; +Cc: Hiraku Toyooka
Hello.
I'm working on MCIMX6Q-SDB.
I found two problems when I executed bitbake with use-mainline-bsp.
First problem is that SD card image is not generated appropriately because of
missing generation command.
Second problem is build failure of dtb files because of inconsistent dtb
filename list.
This patch series fix the above problems.
Hiraku Toyooka (2):
image_types_fsl: define SDCARD_GENERATION_COMMAND for use-mainline-bsp
machines: fix dtb build failure when use-mainline-bsp is used
classes/image_types_fsl.bbclass | 1 +
conf/machine/imx6qdlsabreauto.conf | 5 +++++
conf/machine/imx6qdlsabresd.conf | 5 +++++
conf/machine/imx6slevk.conf | 1 +
conf/machine/imx6sxsabreauto.conf | 1 +
conf/machine/imx6sxsabresd.conf | 1 +
conf/machine/imx6ulevk.conf | 1 +
conf/machine/imx7dsabresd.conf | 1 +
8 files changed, 16 insertions(+)
--
2.7.4
^ permalink raw reply
* [PATCH 1/2] image_types_fsl: define SDCARD_GENERATION_COMMAND for use-mainline-bsp
From: Hiraku Toyooka @ 2017-10-05 4:21 UTC (permalink / raw)
To: meta-freescale; +Cc: Hiraku Toyooka
In-Reply-To: <1507177263-6630-1-git-send-email-hiraku.toyooka@cybertrust.co.jp>
When we use the use-mainline-bsp override, SDCARD_GENERATION_COMMAND
becomes empty. As a result, incomplete SD card image is generated.
This patch fixes the problem by specifying appropriate command.
Signed-off-by: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
---
classes/image_types_fsl.bbclass | 1 +
1 file changed, 1 insertion(+)
diff --git a/classes/image_types_fsl.bbclass b/classes/image_types_fsl.bbclass
index 91b6c4e..7609e3d 100644
--- a/classes/image_types_fsl.bbclass
+++ b/classes/image_types_fsl.bbclass
@@ -91,6 +91,7 @@ SDCARD_GENERATION_COMMAND_mx5 = "generate_imx_sdcard"
SDCARD_GENERATION_COMMAND_mx6 = "generate_imx_sdcard"
SDCARD_GENERATION_COMMAND_mx7 = "generate_imx_sdcard"
SDCARD_GENERATION_COMMAND_vf = "generate_imx_sdcard"
+SDCARD_GENERATION_COMMAND_use-mainline-bsp = "generate_imx_sdcard"
#
--
2.7.4
^ permalink raw reply related
* Re: powerpc/mm: Call flush_tlb_kernel_range with interrupts enabled
From: Michael Ellerman @ 2017-10-05 4:22 UTC (permalink / raw)
To: Guenter Roeck, Benjamin Herrenschmidt
Cc: linux-kernel, Paul Mackerras, linuxppc-dev, Guenter Roeck
In-Reply-To: <1506274243-28540-1-git-send-email-linux@roeck-us.net>
On Sun, 2017-09-24 at 17:30:43 UTC, Guenter Roeck wrote:
> flush_tlb_kernel_range() may call smp_call_function_many() which expects
> interrupts to be enabled. This results in a traceback.
>
> WARNING: CPU: 0 PID: 1 at kernel/smp.c:416 smp_call_function_many+0xcc/0x2fc
> CPU: 0 PID: 1 Comm: swapper/0 Not tainted 4.14.0-rc1-00009-g0666f56 #1
> task: cf830000 task.stack: cf82e000
> NIP: c00a93c8 LR: c00a9634 CTR: 00000001
> REGS: cf82fde0 TRAP: 0700 Not tainted (4.14.0-rc1-00009-g0666f56)
> MSR: 00021000 <CE,ME> CR: 24000082 XER: 00000000
>
> GPR00: c00a9634 cf82fe90 cf830000 c050ad3c c0015a54 00000000 00000001 00000001
> GPR08: 00000001 00000000 00000000 cf82e000 24000084 00000000 c0003150 00000000
> GPR16: 00000000 00000000 00000000 00000000 00000000 00000001 00000000 c0510000
> GPR24: 00000000 c0015a54 00000000 c050ad3c c051823c c050ad3c 00000025 00000000
> NIP [c00a93c8] smp_call_function_many+0xcc/0x2fc
> LR [c00a9634] smp_call_function+0x3c/0x50
> Call Trace:
> [cf82fe90] [00000010] 0x10 (unreliable)
> [cf82fed0] [c00a9634] smp_call_function+0x3c/0x50
> [cf82fee0] [c0015d2c] flush_tlb_kernel_range+0x20/0x38
> [cf82fef0] [c001524c] mark_initmem_nx+0x154/0x16c
> [cf82ff20] [c001484c] free_initmem+0x20/0x4c
> [cf82ff30] [c000316c] kernel_init+0x1c/0x108
> [cf82ff40] [c000f3a8] ret_from_kernel_thread+0x5c/0x64
> Instruction dump:
> 7c0803a6 7d808120 38210040 4e800020 3d20c052 812981a0 2f890000 40beffac
> 3d20c051 8929ac64 2f890000 40beff9c <0fe00000> 4bffff94 7fc3f378 7f64db78
>
> Fixes: 3184cc4b6f6a ("powerpc/mm: Fix kernel RAM protection after freeing ...")
> Fixes: e611939fc8ec ("powerpc/mm: Ensure change_page_attr() doesn't ...")
> Cc: Christophe Leroy <christophe.leroy@c-s.fr>
> Signed-off-by: Guenter Roeck <linux@roeck-us.net>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/7c6a4f3b1641195119ddbb531200f4
cheers
^ permalink raw reply
* Re: powerpc: Fix action argument for cpufeatures-based TLB flush
From: Michael Ellerman @ 2017-10-05 4:22 UTC (permalink / raw)
To: Jeremy Kerr, linuxppc-dev; +Cc: Meng YK Li, Jeremy Kerr, Nicholas Piggin
In-Reply-To: <1506488151-9825-1-git-send-email-jk@ozlabs.org>
On Wed, 2017-09-27 at 04:55:51 UTC, Jeremy Kerr wrote:
> Commit 41d0c2ecde introduced calls to __flush_tlb_power[89] from the
> cpufeatures code, specifying the number of sets to flush.
>
> However, these functions take an action argument, not a number of sets.
> This means we hit the BUG() in __flush_tlb_{206,300} when using
> cpufeatures-style configuration.
>
> This change passes TLB_INVAL_SCOPE_GLOBAL instead.
>
> Signed-off-by: Jeremy Kerr <jk@ozlabs.org>
> CC: Nicholas Piggin <npiggin@gmail.com>
> Reviewed-by: Nicholas Piggin <npiggin@gmail.com>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/3b7af5c0fd9631762d1c4d7b4cee76
cheers
^ permalink raw reply
* Re: [v3] powerpc: fix compile error on 64K pages on 40x, 44x
From: Michael Ellerman @ 2017-10-05 4:22 UTC (permalink / raw)
To: Christian Lamparter, linuxppc-dev; +Cc: Paul Mackerras
In-Reply-To: <20171001143303.15671-1-chunkeey@gmail.com>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1128 bytes --]
On Sun, 2017-10-01 at 14:33:03 UTC, Christian Lamparter wrote:
> The mmu context on the 40x, 44x does not define pte_frag
> entry. This causes gcc abort the compilation due to:
>
> setup-common.c: In function ‘setup_arch’:
> setup-common.c:908: error: ‘mm_context_t’ has no ‘pte_frag’
>
> This patch fixes the issue by removing the pte_frag
> initialization in setup-common.c.
>
> This is possible, because the compiler will do the
> initialization, since the mm_context is a sub struct of
> init_mm. init_mm is declared in mm_types.h as external linkage.
> according to C99 6.2.4.3:
> "An object whose identifier is declared with external linkage
> [...] has static storage duration."
>
> C99 defines in 6.7.8.10 that: "
> If an object that has static storage duration is not
> initialized explicitly, then:
> - if it has pointer type, it is initialized to a null pointer
> [...]
> "
>
> Signed-off-by: Christian Lamparter <chunkeey@gmail.com>
> Reviewed-by: Christophe Leroy <christophe.leroy@c-s.fr>
Applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/070e004912fed099263408bf2ff1bb
cheers
^ permalink raw reply
* Re: [v2,1/2] powerpc/xive: fix IPI reset
From: Michael Ellerman @ 2017-10-05 4:22 UTC (permalink / raw)
To: Cédric Le Goater, linuxppc-dev; +Cc: David Gibson, Cédric Le Goater
In-Reply-To: <20171004091505.16776-2-clg@kaod.org>
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 305 bytes --]
On Wed, 2017-10-04 at 09:15:04 UTC, =?utf-8?q?C=C3=A9dric_Le_Goater?= wrote:
> When resetting an IPI, hw_ipi should also be set to zero.
>
> Signed-off-by: Cédric Le Goater <clg@kaod.org>
Series applied to powerpc fixes, thanks.
https://git.kernel.org/powerpc/c/74f1282114acc7d67e25745efe200f
cheers
^ permalink raw reply
* [PATCH 2/2] machines: fix dtb build failure when use-mainline-bsp is used
From: Hiraku Toyooka @ 2017-10-05 4:21 UTC (permalink / raw)
To: meta-freescale; +Cc: Hiraku Toyooka
In-Reply-To: <1507177263-6630-1-git-send-email-hiraku.toyooka@cybertrust.co.jp>
When the use-mainline-bsp is used, dtb files listed in KERNEL_DEVICETREE
are different from ones to be build, so the build fails. This patch fixes
it by adding KERNEL_DEVICETREE_use_mainline_bsp.
Signed-off-by: Hiraku Toyooka <hiraku.toyooka@cybertrust.co.jp>
---
conf/machine/imx6qdlsabreauto.conf | 5 +++++
conf/machine/imx6qdlsabresd.conf | 5 +++++
conf/machine/imx6slevk.conf | 1 +
conf/machine/imx6sxsabreauto.conf | 1 +
conf/machine/imx6sxsabresd.conf | 1 +
conf/machine/imx6ulevk.conf | 1 +
conf/machine/imx7dsabresd.conf | 1 +
7 files changed, 15 insertions(+)
diff --git a/conf/machine/imx6qdlsabreauto.conf b/conf/machine/imx6qdlsabreauto.conf
index 8967c15..8f2a4c1 100644
--- a/conf/machine/imx6qdlsabreauto.conf
+++ b/conf/machine/imx6qdlsabreauto.conf
@@ -26,6 +26,11 @@ KERNEL_DEVICETREE = " \
imx6dl-sabreauto.dtb imx6dl-sabreauto-gpmi-weim.dtb imx6dl-sabreauto-ecspi.dtb \
imx6dl-sabreauto-flexcan1.dtb imx6dl-sabreauto-enetirq.dtb \
"
+KERNEL_DEVICETREE_use-mainline-bsp = " \
+ imx6qp-sabreauto.dtb \
+ imx6q-sabreauto.dtb \
+ imx6dl-sabreauto.dtb \
+"
UBOOT_MACHINE ?= "mx6sabreauto_defconfig"
UBOOT_MAKE_TARGET = "all"
diff --git a/conf/machine/imx6qdlsabresd.conf b/conf/machine/imx6qdlsabresd.conf
index 92c9288..e85a4ac 100644
--- a/conf/machine/imx6qdlsabresd.conf
+++ b/conf/machine/imx6qdlsabresd.conf
@@ -26,6 +26,11 @@ KERNEL_DEVICETREE = " \
imx6dl-sabresd.dtb imx6dl-sabresd-ldo.dtb imx6dl-sabresd-hdcp.dtb \
imx6dl-sabresd-enetirq.dtb imx6dl-sabresd-btwifi.dtb \
"
+KERNEL_DEVICETREE_use-mainline-bsp = " \
+ imx6qp-sabresd.dtb \
+ imx6q-sabresd.dtb \
+ imx6dl-sabresd.dtb \
+"
UBOOT_MACHINE ?= "mx6sabresd_defconfig"
UBOOT_MAKE_TARGET = "all"
diff --git a/conf/machine/imx6slevk.conf b/conf/machine/imx6slevk.conf
index 52b4000..ffcbaaa 100644
--- a/conf/machine/imx6slevk.conf
+++ b/conf/machine/imx6slevk.conf
@@ -11,6 +11,7 @@ include conf/machine/include/tune-cortexa9.inc
KERNEL_DEVICETREE = "imx6sl-evk.dtb imx6sl-evk-csi.dtb imx6sl-evk-ldo.dtb \
imx6sl-evk-uart.dtb imx6sl-evk-btwifi.dtb"
+KERNEL_DEVICETREE_use-mainline-bsp = "imx6sl-evk.dtb"
UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG[sd] = "mx6slevk_config,sdcard"
diff --git a/conf/machine/imx6sxsabreauto.conf b/conf/machine/imx6sxsabreauto.conf
index 19a8d9f..ca5c974 100644
--- a/conf/machine/imx6sxsabreauto.conf
+++ b/conf/machine/imx6sxsabreauto.conf
@@ -10,6 +10,7 @@ require conf/machine/include/imx-base.inc
require conf/machine/include/tune-cortexa9.inc
KERNEL_DEVICETREE = "imx6sx-sabreauto.dtb imx6sx-sabreauto-m4.dtb"
+KERNEL_DEVICETREE_use-mainline-bsp = "imx6sx-sabreauto.dtb"
PREFERRED_PROVIDER_u-boot = "u-boot-imx"
PREFERRED_PROVIDER_virtual/bootloader = "u-boot-imx"
diff --git a/conf/machine/imx6sxsabresd.conf b/conf/machine/imx6sxsabresd.conf
index f794636..3a969e4 100644
--- a/conf/machine/imx6sxsabresd.conf
+++ b/conf/machine/imx6sxsabresd.conf
@@ -13,6 +13,7 @@ KERNEL_DEVICETREE = "imx6sx-sdb.dtb imx6sx-sdb-emmc.dtb imx6sx-sdb-m4.dtb \
imx6sx-sdb-sai.dtb imx6sx-sdb-lcdif1.dtb imx6sx-sdb-ldo.dtb \
imx6sx-sdb-reva-ldo.dtb imx6sx-sdb-reva.dtb \
imx6sx-sdb-btwifi.dtb imx6sx-sdb-mqs.dtb"
+KERNEL_DEVICETREE_use-mainline-bsp = "imx6sx-sdb.dtb imx6sx-sdb-sai.dtb imx6sx-sdb-reva.dtb"
UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG[sd] = "mx6sxsabresd_config,sdcard"
diff --git a/conf/machine/imx6ulevk.conf b/conf/machine/imx6ulevk.conf
index dadd525..86ad19c 100644
--- a/conf/machine/imx6ulevk.conf
+++ b/conf/machine/imx6ulevk.conf
@@ -14,6 +14,7 @@ MACHINE_FEATURES += " pci wifi bluetooth"
KERNEL_DEVICETREE = "imx6ul-14x14-evk.dtb imx6ul-14x14-evk-csi.dtb imx6ul-14x14-evk-btwifi.dtb \
imx6ul-14x14-evk-gpmi-weim.dtb imx6ul-14x14-evk-usb-certi.dtb \
imx6ul-14x14-evk-emmc.dtb "
+KERNEL_DEVICETREE_use-mainline-bsp = "imx6ul-14x14-evk.dtb"
UBOOT_SUFFIX = "img"
SPL_BINARY = "SPL"
diff --git a/conf/machine/imx7dsabresd.conf b/conf/machine/imx7dsabresd.conf
index 3a05d16..f77e537 100644
--- a/conf/machine/imx7dsabresd.conf
+++ b/conf/machine/imx7dsabresd.conf
@@ -16,6 +16,7 @@ KERNEL_DEVICETREE = "imx7d-sdb.dtb imx7d-sdb-epdc.dtb imx7d-sdb-gpmi-weim.dtb \
imx7d-sdb-reva.dtb imx7d-sdb-reva-epdc.dtb imx7d-sdb-reva-gpmi-weim.dtb \
imx7d-sdb-reva-hdmi-audio.dtb imx7d-sdb-reva-m4.dtb imx7d-sdb-reva-qspi.dtb \
imx7d-sdb-reva-touch.dtb imx7d-sdb-reva-wm8960.dtb"
+KERNEL_DEVICETREE_use-mainline-bsp = "imx7d-sdb.dtb"
UBOOT_CONFIG ??= "sd"
UBOOT_CONFIG[sd] = "mx7dsabresd_secure_config,sdcard"
--
2.7.4
^ permalink raw reply related
* Re: [PATCH] PCI MSI: allow alignment restrictions on vector allocation
From: Daniel Drake @ 2017-10-05 4:23 UTC (permalink / raw)
To: tglx; +Cc: linux-kernel, linux-pci, x86, linux-wireless, ath9k-devel, linux
In-Reply-To: <alpine.DEB.2.20.1710021540030.2185@nanos>
On Mon, Oct 2, 2017 at 10:38 PM, Thomas Gleixner <tglx@linutronix.de> wrote:
>> After checking out the new code and thinking this through a bit, I think
>> perhaps the only generic approach that would work is to make the
>> ath9k driver require a vector allocation that enables the entire block
>> of 4 MSI IRQs that the hardware supports (which is what Windows is doing).
>
> I wonder how Windows deals with the affinity problem for multi-MSI. Or does
> it just not allow to set it at all?
https://docs.microsoft.com/en-us/windows-hardware/drivers/kernel/interrupt-affinity-and-priority
Looks like IRQ affinity can only be set by registry or inf files. I assume
that means it is not dynamic and hence avoids the challenges related to
moving interrupts around at runtime.
> What's wrong with just using the legacy INTx emulation if you cannot
> allocate 4 MSI vectors?
The Legacy interrupt simply doesn't work for the wifi on at least 8 new Acer
laptop products based on Intel Apollo Lake.
Plus 4 Dell systems included in the patches in this thread:
https://lkml.org/lkml/2017/9/26/55
(the 2 which I can find specs for are also Apollo Lake)
We have tried taking the mini-PCIe wifi module out of one of the affected
Acer products and moved it to another computer, where it is working fine
with legacy interrupts. So this suggests that the wifi module itself is OK,
but we are facing a hardware limitation or BIOS limitation on the affected
products. In the Dell thread it says "Some platform(BIOS) blocks legacy
interrupts (INTx)".
If you have any suggestions for how we might solve this without getting into
the MSI mess then that would be much appreciated. If the BIOS blocks the
interrupts, can Linux unblock them?
Just for reference I'm attaching my latest attempt at enabling MULTI_PCI_MSI.
It would definitely need further work if we proceed here - so far I've
ignored the affinity considerations that you explained, and it's not
particularly clean.
I'll now have a look at polling for interrupts in the ath9k driver.
---
arch/x86/kernel/apic/msi.c | 3 +-
arch/x86/kernel/apic/vector.c | 75 ++++++++++++++++++++++++++++++++-----------
include/linux/irq.h | 3 +-
kernel/irq/matrix.c | 23 +++++++------
4 files changed, 74 insertions(+), 30 deletions(-)
diff --git a/arch/x86/kernel/apic/msi.c b/arch/x86/kernel/apic/msi.c
index 5b6dd1a85ec4..c57b6a7b9317 100644
--- a/arch/x86/kernel/apic/msi.c
+++ b/arch/x86/kernel/apic/msi.c
@@ -129,7 +129,8 @@ static struct msi_domain_ops pci_msi_domain_ops = {
static struct msi_domain_info pci_msi_domain_info = {
.flags = MSI_FLAG_USE_DEF_DOM_OPS | MSI_FLAG_USE_DEF_CHIP_OPS |
- MSI_FLAG_PCI_MSIX | MSI_FLAG_MUST_REACTIVATE,
+ MSI_FLAG_PCI_MSIX | MSI_FLAG_MUST_REACTIVATE |
+ MSI_FLAG_MULTI_PCI_MSI,
.ops = &pci_msi_domain_ops,
.chip = &pci_msi_controller,
.handler = handle_edge_irq,
diff --git a/arch/x86/kernel/apic/vector.c b/arch/x86/kernel/apic/vector.c
index 6789e286def9..2926fd92ea1c 100644
--- a/arch/x86/kernel/apic/vector.c
+++ b/arch/x86/kernel/apic/vector.c
@@ -35,7 +35,8 @@ struct apic_chip_data {
unsigned int move_in_progress : 1,
is_managed : 1,
can_reserve : 1,
- has_reserved : 1;
+ has_reserved : 1,
+ contig_allocation : 1;
};
struct irq_domain *x86_vector_domain;
@@ -198,7 +199,8 @@ static int reserve_irq_vector(struct irq_data *irqd)
return 0;
}
-static int allocate_vector(struct irq_data *irqd, const struct cpumask *dest)
+static int allocate_vector(struct irq_data *irqd, const struct cpumask *dest,
+ unsigned int num, unsigned int align_mask)
{
struct apic_chip_data *apicd = apic_chip_data(irqd);
bool resvd = apicd->has_reserved;
@@ -215,18 +217,21 @@ static int allocate_vector(struct irq_data *irqd, const struct cpumask *dest)
if (vector && cpu_online(cpu) && cpumask_test_cpu(cpu, dest))
return 0;
- vector = irq_matrix_alloc(vector_matrix, dest, resvd, &cpu);
+ vector = irq_matrix_alloc(vector_matrix, dest, resvd, &cpu,
+ num, align_mask);
if (vector > 0)
apic_update_vector(irqd, vector, cpu);
+
trace_vector_alloc(irqd->irq, vector, resvd, vector);
return vector;
}
static int assign_vector_locked(struct irq_data *irqd,
- const struct cpumask *dest)
+ const struct cpumask *dest,
+ unsigned int num, unsigned int align_mask)
{
struct apic_chip_data *apicd = apic_chip_data(irqd);
- int vector = allocate_vector(irqd, dest);
+ int vector = allocate_vector(irqd, dest, num, align_mask);
if (vector < 0)
return vector;
@@ -235,14 +240,15 @@ static int assign_vector_locked(struct irq_data *irqd,
return 0;
}
-static int assign_irq_vector(struct irq_data *irqd, const struct cpumask *dest)
+static int assign_irq_vector(struct irq_data *irqd, const struct cpumask *dest,
+ unsigned int num, unsigned int align_mask)
{
unsigned long flags;
int ret;
raw_spin_lock_irqsave(&vector_lock, flags);
cpumask_and(vector_searchmask, dest, cpu_online_mask);
- ret = assign_vector_locked(irqd, vector_searchmask);
+ ret = assign_vector_locked(irqd, vector_searchmask, num, align_mask);
raw_spin_unlock_irqrestore(&vector_lock, flags);
return ret;
}
@@ -257,18 +263,18 @@ static int assign_irq_vector_any_locked(struct irq_data *irqd)
goto all;
/* Try the intersection of @affmsk and node mask */
cpumask_and(vector_searchmask, cpumask_of_node(node), affmsk);
- if (!assign_vector_locked(irqd, vector_searchmask))
+ if (!assign_vector_locked(irqd, vector_searchmask, 1, 0))
return 0;
/* Try the node mask */
- if (!assign_vector_locked(irqd, cpumask_of_node(node)))
+ if (!assign_vector_locked(irqd, cpumask_of_node(node), 1, 0))
return 0;
all:
/* Try the full affinity mask */
cpumask_and(vector_searchmask, affmsk, cpu_online_mask);
- if (!assign_vector_locked(irqd, vector_searchmask))
+ if (!assign_vector_locked(irqd, vector_searchmask, 1, 0))
return 0;
/* Try the full online mask */
- return assign_vector_locked(irqd, cpu_online_mask);
+ return assign_vector_locked(irqd, cpu_online_mask, 1, 0);
}
static int
@@ -277,7 +283,7 @@ assign_irq_vector_policy(struct irq_data *irqd, struct irq_alloc_info *info)
if (irqd_affinity_is_managed(irqd))
return reserve_managed_vector(irqd);
if (info->mask)
- return assign_irq_vector(irqd, info->mask);
+ return assign_irq_vector(irqd, info->mask, 1, 0);
/*
* Make only a global reservation with no guarantee. A real vector
* is associated at activation time.
@@ -353,6 +359,9 @@ static void x86_vector_deactivate(struct irq_domain *dom, struct irq_data *irqd)
if (apicd->has_reserved)
return;
+ if (apicd->contig_allocation)
+ return;
+
raw_spin_lock_irqsave(&vector_lock, flags);
clear_irq_vector(irqd);
if (apicd->can_reserve)
@@ -411,6 +420,9 @@ static int x86_vector_activate(struct irq_domain *dom, struct irq_data *irqd,
if (!apicd->can_reserve && !apicd->is_managed)
return 0;
+ if (apicd->contig_allocation)
+ return 0;
+
raw_spin_lock_irqsave(&vector_lock, flags);
if (early || irqd_is_managed_and_shutdown(irqd))
vector_assign_managed_shutdown(irqd);
@@ -489,16 +501,25 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq,
unsigned int nr_irqs, void *arg)
{
struct irq_alloc_info *info = arg;
- struct apic_chip_data *apicd;
+ struct apic_chip_data *apicd, *first_apicd;
struct irq_data *irqd;
int i, err, node;
+ bool contig_allocation = false;
+ unsigned int align_mask = 0;
if (disable_apic)
return -ENXIO;
- /* Currently vector allocator can't guarantee contiguous allocations */
- if ((info->flags & X86_IRQ_ALLOC_CONTIGUOUS_VECTORS) && nr_irqs > 1)
- return -ENOSYS;
+ if ((info->flags & X86_IRQ_ALLOC_CONTIGUOUS_VECTORS) && nr_irqs > 1) {
+ contig_allocation = true;
+
+ if (info->type == X86_IRQ_ALLOC_TYPE_MSI) {
+ /* Contiguous allocations must be aligned for MSI */
+ align_mask = 1 << fls(nr_irqs - 1);
+ /* Convert from align requirement to align mask */
+ align_mask--;
+ }
+ }
for (i = 0; i < nr_irqs; i++) {
irqd = irq_domain_get_irq_data(domain, virq + i);
@@ -512,6 +533,7 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq,
}
apicd->irq = virq + i;
+ apicd->contig_allocation = contig_allocation;
irqd->chip = &lapic_controller;
irqd->chip_data = apicd;
irqd->hwirq = virq + i;
@@ -528,7 +550,24 @@ static int x86_vector_alloc_irqs(struct irq_domain *domain, unsigned int virq,
continue;
}
- err = assign_irq_vector_policy(irqd, info);
+ if (contig_allocation) {
+ /* Automatically activate */
+ if (i == 0) {
+ first_apicd = apicd;
+ err = assign_irq_vector(irqd, cpu_online_mask,
+ nr_irqs, align_mask);
+ } else {
+ apic_update_vector(irqd,
+ first_apicd->vector + i,
+ first_apicd->cpu);
+ apic_update_irq_cfg(irqd,
+ first_apicd->vector + i,
+ first_apicd->cpu);
+ err = 0;
+ }
+ } else {
+ err = assign_irq_vector_policy(irqd, info);
+ }
trace_vector_setup(virq + i, false, err);
if (err)
goto error;
@@ -733,7 +772,7 @@ static int apic_set_affinity(struct irq_data *irqd,
if (irqd_affinity_is_managed(irqd))
err = assign_managed_vector(irqd, vector_searchmask);
else
- err = assign_vector_locked(irqd, vector_searchmask);
+ err = assign_vector_locked(irqd, vector_searchmask, 1, 0);
raw_spin_unlock(&vector_lock);
return err ? err : IRQ_SET_MASK_OK;
}
diff --git a/include/linux/irq.h b/include/linux/irq.h
index fda8da7c45e7..2cb5c3a9c96f 100644
--- a/include/linux/irq.h
+++ b/include/linux/irq.h
@@ -1126,7 +1126,8 @@ int irq_matrix_alloc_managed(struct irq_matrix *m, unsigned int cpu);
void irq_matrix_reserve(struct irq_matrix *m);
void irq_matrix_remove_reserved(struct irq_matrix *m);
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
- bool reserved, unsigned int *mapped_cpu);
+ bool reserved, unsigned int *mapped_cpu, unsigned int num,
+ unsigned int align_mask);
void irq_matrix_free(struct irq_matrix *m, unsigned int cpu,
unsigned int bit, bool managed);
void irq_matrix_assign(struct irq_matrix *m, unsigned int bit);
diff --git a/kernel/irq/matrix.c b/kernel/irq/matrix.c
index a3cbbc8191c5..b5c4f054a650 100644
--- a/kernel/irq/matrix.c
+++ b/kernel/irq/matrix.c
@@ -106,14 +106,16 @@ void irq_matrix_offline(struct irq_matrix *m)
}
static unsigned int matrix_alloc_area(struct irq_matrix *m, struct cpumap *cm,
- unsigned int num, bool managed)
+ unsigned int num, bool managed,
+ unsigned int align_mask)
{
unsigned int area, start = m->alloc_start;
unsigned int end = m->alloc_end;
bitmap_or(m->scratch_map, cm->managed_map, m->system_map, end);
bitmap_or(m->scratch_map, m->scratch_map, cm->alloc_map, end);
- area = bitmap_find_next_zero_area(m->scratch_map, end, start, num, 0);
+ area = bitmap_find_next_zero_area(m->scratch_map, end, start, num,
+ align_mask);
if (area >= end)
return area;
if (managed)
@@ -171,7 +173,7 @@ int irq_matrix_reserve_managed(struct irq_matrix *m, const struct cpumask *msk)
struct cpumap *cm = per_cpu_ptr(m->maps, cpu);
unsigned int bit;
- bit = matrix_alloc_area(m, cm, 1, true);
+ bit = matrix_alloc_area(m, cm, 1, true, 0);
if (bit >= m->alloc_end)
goto cleanup;
cm->managed++;
@@ -319,7 +321,8 @@ void irq_matrix_remove_reserved(struct irq_matrix *m)
* @mapped_cpu: Pointer to store the CPU for which the irq was allocated
*/
int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
- bool reserved, unsigned int *mapped_cpu)
+ bool reserved, unsigned int *mapped_cpu,
+ unsigned int num, unsigned int align_mask)
{
unsigned int cpu;
@@ -330,14 +333,14 @@ int irq_matrix_alloc(struct irq_matrix *m, const struct cpumask *msk,
if (!cm->online)
continue;
- bit = matrix_alloc_area(m, cm, 1, false);
+ bit = matrix_alloc_area(m, cm, num, false, align_mask);
if (bit < m->alloc_end) {
- cm->allocated++;
- cm->available--;
- m->total_allocated++;
- m->global_available--;
+ cm->allocated += num;
+ cm->available -= num;
+ m->total_allocated += num;
+ m->global_available -= num;
if (reserved)
- m->global_reserved--;
+ m->global_reserved -= num;
*mapped_cpu = cpu;
trace_irq_matrix_alloc(bit, cpu, m, cm);
return bit;
--
2.11.0
^ permalink raw reply related
* Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command
From: Nicholas Piggin @ 2017-10-05 4:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells,
edumazet, fweisbec, oleg, Boqun Feng, Andrew Hunter,
Maged Michael, gromer, Avi Kivity, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Dave Watson, Alan Stern,
Will Deacon, Andy Lutomirski
In-Reply-To: <1507153075-12345-1-git-send-email-paulmck@linux.vnet.ibm.com>
On Wed, 4 Oct 2017 14:37:53 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>
> Provide a new command allowing processes to register their intent to use
> the private expedited command.
>
> This allows PowerPC to skip the full memory barrier in switch_mm(), and
> only issue the barrier when scheduling into a task belonging to a
> process that has registered to use expedited private.
>
> Processes are now required to register before using
> MEMBARRIER_CMD_PRIVATE_EXPEDITED, otherwise that command returns EPERM.
>
> Changes since v1:
> - Use test_ti_thread_flag(next, ...) instead of test_thread_flag() in
> powerpc membarrier_arch_sched_in(), given that we want to specifically
> check the next thread state.
> - Add missing ARCH_HAS_MEMBARRIER_HOOKS in Kconfig.
> - Use task_thread_info() to pass thread_info from task to
> *_ti_thread_flag().
>
> Changes since v2:
> - Move membarrier_arch_sched_in() call to finish_task_switch().
> - Check for NULL t->mm in membarrier_arch_fork().
> - Use membarrier_sched_in() in generic code, which invokes the
> arch-specific membarrier_arch_sched_in(). This fixes allnoconfig
> build on PowerPC.
> - Move asm/membarrier.h include under CONFIG_MEMBARRIER, fixing
> allnoconfig build on PowerPC.
> - Build and runtime tested on PowerPC.
>
> Changes since v3:
> - Simply rely on copy_mm() to copy the membarrier_private_expedited mm
> field on fork.
> - powerpc: test thread flag instead of reading
> membarrier_private_expedited in membarrier_arch_fork().
> - powerpc: skip memory barrier in membarrier_arch_sched_in() if coming
> from kernel thread, since mmdrop() implies a full barrier.
> - Set membarrier_private_expedited to 1 only after arch registration
> code, thus eliminating a race where concurrent commands could succeed
> when they should fail if issued concurrently with process
> registration.
> - Use READ_ONCE() for membarrier_private_expedited field access in
> membarrier_private_expedited. Matches WRITE_ONCE() performed in
> process registration.
>
> Changes since v4:
> - Move powerpc hook from sched_in() to switch_mm(), based on feedback
> from Nicholas Piggin.
For now, the powerpc approach is okay by me. I plan to test
others (e.g., taking runqueue locks) on larger systems, but that can
be sent as an incremental patch at a later time.
The main thing I would like is for people to review the userspace API.
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 3a19c253bdb1..4af1b719c65f 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -205,4 +205,54 @@ static inline void memalloc_noreclaim_restore(unsigned int flags)
> current->flags = (current->flags & ~PF_MEMALLOC) | flags;
> }
>
> +#ifdef CONFIG_MEMBARRIER
> +
> +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_HOOKS
> +#include <asm/membarrier.h>
> +#else
> +static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
> + struct mm_struct *next, struct task_struct *tsk)
> +{
> +}
This is no longer required in architecture independent code, is it?
^ permalink raw reply
* Re: [PATCH tip/core/rcu 1/3] membarrier: Provide register expedited private command
From: Nicholas Piggin @ 2017-10-05 4:23 UTC (permalink / raw)
To: Paul E. McKenney
Cc: linux-kernel, mingo, jiangshanlai, dipankar, akpm,
mathieu.desnoyers, josh, tglx, peterz, rostedt, dhowells,
edumazet, fweisbec, oleg, Boqun Feng, Andrew Hunter,
Maged Michael, gromer, Avi Kivity, Benjamin Herrenschmidt,
Paul Mackerras, Michael Ellerman, Dave Watson, Alan Stern,
Will Deacon, Andy Lutomirski, Ingo Molnar, Alexander Viro,
linuxppc-dev, linux-arch
In-Reply-To: <1507153075-12345-1-git-send-email-paulmck@linux.vnet.ibm.com>
On Wed, 4 Oct 2017 14:37:53 -0700
"Paul E. McKenney" <paulmck@linux.vnet.ibm.com> wrote:
> From: Mathieu Desnoyers <mathieu.desnoyers@efficios.com>
>
> Provide a new command allowing processes to register their intent to use
> the private expedited command.
>
> This allows PowerPC to skip the full memory barrier in switch_mm(), and
> only issue the barrier when scheduling into a task belonging to a
> process that has registered to use expedited private.
>
> Processes are now required to register before using
> MEMBARRIER_CMD_PRIVATE_EXPEDITED, otherwise that command returns EPERM.
>
> Changes since v1:
> - Use test_ti_thread_flag(next, ...) instead of test_thread_flag() in
> powerpc membarrier_arch_sched_in(), given that we want to specifically
> check the next thread state.
> - Add missing ARCH_HAS_MEMBARRIER_HOOKS in Kconfig.
> - Use task_thread_info() to pass thread_info from task to
> *_ti_thread_flag().
>
> Changes since v2:
> - Move membarrier_arch_sched_in() call to finish_task_switch().
> - Check for NULL t->mm in membarrier_arch_fork().
> - Use membarrier_sched_in() in generic code, which invokes the
> arch-specific membarrier_arch_sched_in(). This fixes allnoconfig
> build on PowerPC.
> - Move asm/membarrier.h include under CONFIG_MEMBARRIER, fixing
> allnoconfig build on PowerPC.
> - Build and runtime tested on PowerPC.
>
> Changes since v3:
> - Simply rely on copy_mm() to copy the membarrier_private_expedited mm
> field on fork.
> - powerpc: test thread flag instead of reading
> membarrier_private_expedited in membarrier_arch_fork().
> - powerpc: skip memory barrier in membarrier_arch_sched_in() if coming
> from kernel thread, since mmdrop() implies a full barrier.
> - Set membarrier_private_expedited to 1 only after arch registration
> code, thus eliminating a race where concurrent commands could succeed
> when they should fail if issued concurrently with process
> registration.
> - Use READ_ONCE() for membarrier_private_expedited field access in
> membarrier_private_expedited. Matches WRITE_ONCE() performed in
> process registration.
>
> Changes since v4:
> - Move powerpc hook from sched_in() to switch_mm(), based on feedback
> from Nicholas Piggin.
For now, the powerpc approach is okay by me. I plan to test
others (e.g., taking runqueue locks) on larger systems, but that can
be sent as an incremental patch at a later time.
The main thing I would like is for people to review the userspace API.
> diff --git a/include/linux/sched/mm.h b/include/linux/sched/mm.h
> index 3a19c253bdb1..4af1b719c65f 100644
> --- a/include/linux/sched/mm.h
> +++ b/include/linux/sched/mm.h
> @@ -205,4 +205,54 @@ static inline void memalloc_noreclaim_restore(unsigned int flags)
> current->flags = (current->flags & ~PF_MEMALLOC) | flags;
> }
>
> +#ifdef CONFIG_MEMBARRIER
> +
> +#ifdef CONFIG_ARCH_HAS_MEMBARRIER_HOOKS
> +#include <asm/membarrier.h>
> +#else
> +static inline void membarrier_arch_switch_mm(struct mm_struct *prev,
> + struct mm_struct *next, struct task_struct *tsk)
> +{
> +}
This is no longer required in architecture independent code, is it?
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 14/32] qapi: Rework generated code for built-in types
From: Markus Armbruster @ 2017-10-05 4:24 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: QEMU, Michael Roth
In-Reply-To: <CAJ+F1C+gsgG+Nbmj56DACRCAdWk==Ud=CCtfppc-jy4L41QoMw@mail.gmail.com>
Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> Hi
>
> On Mon, Oct 2, 2017 at 5:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> qapi-types.py and qapi-visit.py generate some C code for built-in
>> types. To make this work with multiple schemas, we generate code for
>> built-ins into .c files only when the user asks for it with -b. The
>> user is responsible for linking exactly one set of files generated
>> with -b per program. We generate code for built-ins into .h
>> regardless of -b, but guard it with a preprocessor symbol.
>>
>> This is cumbersome and inflexible. Move the code generated for
>> built-in types into separate files builtin-qapi-{types,visit}.{c,h}.
>> Run qapi-types.py and qapi-visit.py without a schema argument to
>> generate them. Drop their option -b.
>>
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>
>
> Good idea!
> I think I would still prefer to see a seperate argument to generate
> builtin files (rather than absence of schema), but this is minor
> detail.
An option to generate built-ins would have to conflict with -p and the
positional argument. I tried the stupidest solution that could possibly
work first.
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Thanks!
^ permalink raw reply
* Re: [PATCH] Staging: rtl8723bs: Externs should be avoided in .C file
From: Joe Perches @ 2017-10-05 4:26 UTC (permalink / raw)
To: Srinivasan Shanmugam, gregkh, devel, linux-kernel
In-Reply-To: <1507137894-21614-1-git-send-email-srinivasan.rns@gmail.com>
On Wed, 2017-10-04 at 19:24 +0200, Srinivasan Shanmugam wrote:
> Removed warning from 0001-Staging-rtl8723bs-Externs-should-be-avoided-in-.C-fi.patch file after running checkpatch.pl
>
> Signed-off-by: Srinivasan Shanmugam <srinivasan.rns@gmail.com>
> ---
> drivers/staging/rtl8723bs/core/rtw_recv.c | 3 ++-
> 1 file changed, 2 insertions(+), 1 deletion(-)
>
> diff --git a/drivers/staging/rtl8723bs/core/rtw_recv.c b/drivers/staging/rtl8723bs/core/rtw_recv.c
> index c0b501e..6b5e48c 100644
> --- a/drivers/staging/rtl8723bs/core/rtw_recv.c
> +++ b/drivers/staging/rtl8723bs/core/rtw_recv.c
> @@ -1226,7 +1226,8 @@ sint validate_recv_ctrl_frame(struct adapter *padapter, union recv_frame *precv_
>
> union recv_frame *recvframe_chk_defrag(struct adapter *padapter, union recv_frame *precv_frame);
>
> -static sint validate_recv_mgnt_frame(struct adapter *padapter, union recv_frame *precv_frame)
> +static int validate_recv_mgnt_frame(struct adapter *padapter,
> + union recv_frame *precv_frame)
> {
> /* struct mlme_priv *pmlmepriv = &adapter->mlmepriv; */
>
This patch does not match the commit message.
This patch changes the return from sint to int and does
some 80 column wrapping.
^ permalink raw reply
* Re: [Qemu-devel] [RFC PATCH 15/32] tests/qapi-schema: Improve simple union coverage
From: Markus Armbruster @ 2017-10-05 4:29 UTC (permalink / raw)
To: Marc-André Lureau; +Cc: QEMU, Michael Roth
In-Reply-To: <CAJ+F1CKSuJ2Zk6B4baESAdmM6RNeGFszJ1H41ZWxg+dXEcW7zQ@mail.gmail.com>
Marc-André Lureau <marcandre.lureau@gmail.com> writes:
> On Mon, Oct 2, 2017 at 5:25 PM, Markus Armbruster <armbru@redhat.com> wrote:
>> This demonstrates a bug in the lowering of simple unions: if more than
>> one schema uses the same built-in type T for a simple union member,
>> they all generate the same q_obj_T_wrapper into their qapi-types.h.
>> They clash when you include more than one schema's qapi-types.h.
>
> Ah, I don't remember seeing that when I splitted the schema in my
> qapi-if / conditional series.
Simple union members of built-in type are rare. I spotted the problem
with options, then realized it's already possible with simple unions.
> Could it happen with non-built-in types ?
Yes, but multiple q_obj_T_wrapper can clash only when their T also
clash. Name your types more wisely then.
>> Signed-off-by: Markus Armbruster <armbru@redhat.com>
>
> Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Thanks!
^ permalink raw reply
* Re: [Qemu-devel] [Qemu-arm] [PATCH 20/20] nvic: Add missing code for writing SHCSR.HARDFAULTPENDED bit
From: Philippe Mathieu-Daudé @ 2017-10-05 4:33 UTC (permalink / raw)
To: Peter Maydell, qemu-arm, qemu-devel; +Cc: patches
In-Reply-To: <1506092407-26985-21-git-send-email-peter.maydell@linaro.org>
On 09/22/2017 12:00 PM, Peter Maydell wrote:
> When we added support for the new SHCSR bits in v8M in commit
> 437d59c17e9 the code to support writing to the new HARDFAULTPENDED
> bit was accidentally only added for non-secure writes; the
> secure banked version of the bit should also be writable.
>
> Signed-off-by: Peter Maydell <peter.maydell@linaro.org>
> ---
> hw/intc/armv7m_nvic.c | 1 +
> 1 file changed, 1 insertion(+)
>
> diff --git a/hw/intc/armv7m_nvic.c b/hw/intc/armv7m_nvic.c
> index bd1d5d3..22d5e6e 100644
> --- a/hw/intc/armv7m_nvic.c
> +++ b/hw/intc/armv7m_nvic.c
> @@ -1230,6 +1230,7 @@ static void nvic_writel(NVICState *s, uint32_t offset, uint32_t value,
if (attrs.secure) {
if banked then arch is v8M,
> s->sec_vectors[ARMV7M_EXCP_BUS].enabled = (value & (1 << 17)) != 0;
> s->sec_vectors[ARMV7M_EXCP_USAGE].enabled =
> (value & (1 << 18)) != 0;
> + s->sec_vectors[ARMV7M_EXCP_HARD].pending = (value & (1 << 21)) != 0;
therefore this bit is present.
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> /* SecureFault not banked, but RAZ/WI to NS */
> s->vectors[ARMV7M_EXCP_SECURE].active = (value & (1 << 4)) != 0;
> s->vectors[ARMV7M_EXCP_SECURE].enabled = (value & (1 << 19)) != 0;
>
^ permalink raw reply
* Re: [PATCH] drm/i915: Allow null render state batchbuffers bigger than one page
From: Rodrigo Vivi @ 2017-10-05 4:34 UTC (permalink / raw)
To: Rodrigo Vivi; +Cc: Ben Widawsky, paulo.r.zanoni, intel-gfx
In-Reply-To: <CABVU7+s5r2cUKV+jCR=zmZEvjUiNVErNh6A0jUvhAGhANfTERw@mail.gmail.com>
On Thu, Aug 24, 2017 at 11:00:27PM +0000, Rodrigo Vivi wrote:
> On Thu, Aug 24, 2017 at 3:39 PM, Oscar Mateo <oscar.mateo@intel.com> wrote:
> >
> >
> > On 08/23/2017 05:01 PM, Rodrigo Vivi wrote:
> >>
> >> On Tue, Jul 18, 2017 at 8:15 AM, Oscar Mateo <oscar.mateo@intel.com>
> >> wrote:
> >>>
> >>>
> >>>
> >>> On 07/14/2017 08:08 AM, Chris Wilson wrote:
> >>>>
> >>>> Quoting Oscar Mateo (2017-07-14 15:52:59)
> >>>>>
> >>>>>
> >>>>>
> >>>>> On 07/13/2017 03:28 PM, Rodrigo Vivi wrote:
> >>>>>>
> >>>>>> On Wed, May 3, 2017 at 9:31 AM, Chris Wilson
> >>>>>> <chris@chris-wilson.co.uk>
> >>>>>> wrote:
> >>>>>>>
> >>>>>>> On Wed, May 03, 2017 at 09:12:18AM +0000, Oscar Mateo wrote:
> >>>>>>>>
> >>>>>>>> On 05/03/2017 08:52 AM, Mika Kuoppala wrote:
> >>>>>>>>
> >>>>>>>> Oscar Mateo [1]<oscar.mateo@intel.com> writes:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On 05/02/2017 09:17 AM, Mika Kuoppala wrote:
> >>>>>>>>
> >>>>>>>> Chris Wilson [2]<chris@chris-wilson.co.uk> writes:
> >>>>>>>>
> >>>>>>>>
> >>>>>>>> On Fri, Apr 28, 2017 at 09:11:06AM +0000, Oscar Mateo wrote:
> >>>>>>>>
> >>>>>>>> The new batchbuffer for CNL surpasses the 4096 byte mark.
> >>>>>>>>
> >>>>>>>> Cc: Mika Kuoppala [3]<mika.kuoppala@intel.com>
> >>>>>>>> Cc: Ben Widawsky [4]<ben@bwidawsk.net>
> >>>>>>>> Signed-off-by: Oscar Mateo [5]<oscar.mateo@intel.com>
> >>>>>>>>
> >>>>>>>> Evil, 4k+ of nothing-ness that userspace then has to configure
> >>>>>>>> for
> >>>>>>>> itself
> >>>>>>>> for correctness anyway.
> >>>>>>>>
> >>>>>>>> Patch looks ok, but still question the sanity.
> >>>>>>>>
> >>>>>>>> Is there a requirement for CNL to init the renderstate?
> >>>>>>>>
> >>>>>>>> I would like to drop the render state init from CNL if
> >>>>>>>> we can't find evidence that it needs it. Bspec indicates
> >>>>>>>> that it doesnt.
> >>>>>>
> >>>>>> I'd like to drop as well, and I was hearing people around telling we
> >>>>>> didn't need anymore,
> >>>>>> however without this during power on I had bad failures...
> >>>>>>
> >>>>> The best I could get from architecture (+Raf) is that setting valid and
> >>>>> coherent values for the whole render state is required as soon as the
> >>>>> context is created, no matter who does it. If you see failures when the
> >>>>> KMD does not do it, that means the UMD must be missing something,
> >>>>> right?
> >>>>
> >>>> That is my initial response as well. The kernel does load one context,
> >>>> just so that the hardware always has space to write to on power saving.
> >>>> The only batch executed for it is the golden render state. Easy enough
> >>>> to only initialise that kernel context to isolate whether it is
> >>>> self-inflicted or that userspace overlooked something in its state
> >>>> management. (I have the view that even if userspace doesn't think it
> >>>> needs to use a particular bit of state today, tomorrow it will so will
> >>>> need it anyway!)
> >>>> -Chris
> >>>
> >>>
> >>> Rodrigo, you have access to a CNL: can you make this test? The idea is to
> >>> find out if the root cause for the failures you were seeing is the kernel
> >>> default context or in the UMD-created contexts.
> >>
> >> I'm sorry for the delay on this one.
> >>
> >> On the parts I have now I couldn't reproduce the issues I saw during
> >> power-on
> >> where null context helped.
> >>
> >> But anyways apparently we need this right?!
> >>
> >> What about the 4k+ sanity that Chris raised? Anything we should address
> >> first?
> >
> >
> > I don't think Chris had any problem with the batchbuffer being bigger than
> > 4k per se. His concern was: "why do we need to send this batchbuffer from
> > the KMD at all if the UMD has to send something very similar anyway?".
> > Even if this was true (I haven't found anybody to confirm or deny it) there
> > is still the question of the kernel context (which would never get
> > initialized to valid values by the UMD).
>
> so, chris, rv-b? acked-by?
chris, mika, oscar...
what should we do with this?
just discard, ignore and move on without the null context for gen10+?
>
> > The test was to only send the
> > golden state for the kernel context (and nothing else) and see if your
> > issues went away.
> >
> > Since your issues went away on their own without any golden state
> > whatsoever... does that mean Mesa fixed something they were missing during
> > the PO?
>
> not sure what it was anymore
>
> >
> >
>
>
>
> --
> Rodrigo Vivi
> Blog: http://blog.vivi.eng.br
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [U-Boot] [PATCH] disk: part_dos: Use the original allocation scheme for the SPL case
From: Jonathan Gray @ 2017-10-05 4:36 UTC (permalink / raw)
To: u-boot
In-Reply-To: <CAF6AEGvVGs5-ndZh+26-UdaEae5OPVOriiLJ7pFA5eAp6bwqWg@mail.gmail.com>
On Wed, Oct 04, 2017 at 01:12:48PM -0400, Rob Clark wrote:
> On Wed, Oct 4, 2017 at 12:29 PM, Fabio Estevam <fabio.estevam@nxp.com> wrote:
> > Since commit ff98cb90514d ("part: extract MBR signature from partitions")
> > SPL boot on i.MX6 starts to fail:
> >
> > U-Boot SPL 2017.09-00221-g0d6ab32 (Oct 02 2017 - 15:13:19)
> > Trying to boot from MMC1
> > (keep in loop)
> >
> > Use the original allocation scheme for the SPL case, so that MX6 boards
> > can boot again.
> >
> > This is a temporary solution to avoid the boot regression.
> >
> > Signed-off-by: Fabio Estevam <fabio.estevam@nxp.com>
> > ---
> > Hi Tom,
> >
> > I do not have time this week to further investigate and narrow down
> > this problem.
> >
> > Using the old allocation scheme fixes the mx6 SPL boot problem.
> >
>
> Hi Tom, if you are ok with this as a temporary fix, then this is:
>
> Acked-by: Rob Clark <robdclark@gmail.com>
>
> I'm getting some help from some of the fedora-arm folks so hopefully I
> can get some idea what is going wrong, but I'd like to unblock folks
> w/ mx6 boards..
>
> BR,
> -R
This does not seem to be a complete fix, cubox is still broken when
U-Boot proper loads, unless the efi loader commits are to blame
for introducing unaligned accesses.
Works with 2017.09.
U-Boot SPL 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47)
Trying to boot from MMC1
U-Boot 2017.11-rc1-00026-g14b55fc833 (Oct 05 2017 - 15:17:47 +1100)
CPU: Freescale i.MX6Q rev1.5 996 MHz (running at 792 MHz)
CPU: Extended Commercial temperature grade (-20C to 105C) at 34C
Reset cause: WDOG
Board: MX6 Cubox-i
DRAM: 2 GiB
MMC: FSL_SDHC: 0
*** Warning - bad CRC, using default environment
No panel detected: default to HDMI
Display: HDMI (1024x768)
In: serial
Out: serial
Err: serial
Net: FEC
Hit any key to stop autoboot: 0
switch to partitions #0, OK
mmc0 is current device
Scanning mmc 0:1...
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
CACHE: Misaligned operation at range [8f89da30, 8f89e230]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89da30
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e230
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dca0, 8f89e4a0]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
CACHE: Misaligned operation at range [8f89dc68, 8f89e468]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc68
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e468
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
CACHE: Misaligned operation at range [8f89dab0, 8f89e2b0]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dab0
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e2b0
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
CACHE: Misaligned operation at range [8f89dca8, 8f89e4a8]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dca8
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e4a8
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
CACHE: Misaligned operation at range [8f89dc70, 8f89e470]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89dc70
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89e470
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88
CACHE: Misaligned operation at range [8f89e470, 8f89ec70]
CACHE: Misaligned operation at range [8f89e470, 8f89ec70]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70
CACHE: Misaligned operation at range [8f89e470, 8f89ec70]
CACHE: Misaligned operation at range [8f89e470, 8f89ec70]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e470
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec70
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
CACHE: Misaligned operation at range [8f89e488, 8f89ec88]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e488
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec88
CACHE: Misaligned operation at range [8f89e438, 8f89ec38]
CACHE: Misaligned operation at range [8f89e438, 8f89ec38]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38
CACHE: Misaligned operation at range [8f89e438, 8f89ec38]
CACHE: Misaligned operation at range [8f89e438, 8f89ec38]
ERROR: v7_outer_cache_inval_range - start address is not aligned - 0x8f89e438
ERROR: v7_outer_cache_inval_range - stop address is not aligned - 0x8f89ec38
AHCI 0001.0300 32 slots 1 ports 3 Gbps 0x1 impl SATA mode
flags: ncq stag pm led clo only pmp pio slum part
No port device detected!
Device 0: Model: Firm: Ser#:
Type: Hard Disk
Capacity: not available
... is now current device
** Bad device size - sata 0 **
starting USB...
USB0: Port not available.
USB1: USB EHCI 1.00
scanning bus 1 for devices... 1 USB Device(s) found
scanning usb for storage devices... 0 Storage Device(s) found
Device 0: device type unknown
... is now current device
** Bad device usb 0 **
** Bad device usb 0 **
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.