* [PATCH v2 6/6] luks2: Support key derival via Argon2
From: Patrick Steinhardt @ 2020-02-20 18:00 UTC (permalink / raw)
To: grub-devel
Cc: Patrick Steinhardt, Daniel Kiper, gmazyland, leif, agraf, pjones,
mjg59, phcoder
In-Reply-To: <cover.1582221462.git.ps@pks.im>
One addition with LUKS2 was support of the key derival function Argon2
in addition to the previously supported PBKDF2 algortihm. In order to
ease getting in initial support for LUKS2, we only reused infrastructure
to support LUKS2 with PBKDF2, but left out Argon2.
This commit now introduces support for Argon2 to enable decryption of
LUKS2 partitions using this key derival function. As the code for Argon2
has been added in a previous commit in this series, adding support is
now trivial.
Signed-off-by: Patrick Steinhardt <ps@pks.im>
---
Makefile.util.def | 6 +++++-
grub-core/Makefile.core.def | 2 +-
grub-core/disk/luks2.c | 13 +++++++++++--
3 files changed, 17 insertions(+), 4 deletions(-)
diff --git a/Makefile.util.def b/Makefile.util.def
index 94336392b..a50effce4 100644
--- a/Makefile.util.def
+++ b/Makefile.util.def
@@ -3,7 +3,7 @@ AutoGen definitions Makefile.tpl;
library = {
name = libgrubkern.a;
cflags = '$(CFLAGS_GNULIB)';
- cppflags = '$(CPPFLAGS_GNULIB) -I$(srcdir)/grub-core/lib/json';
+ cppflags = '$(CPPFLAGS_GNULIB) -I$(srcdir)/grub-core/lib/json -I$(srcdir)/grub-core/lib/argon2';
common = util/misc.c;
common = grub-core/kern/command.c;
@@ -36,6 +36,10 @@ library = {
common = grub-core/kern/misc.c;
common = grub-core/kern/partition.c;
common = grub-core/lib/crypto.c;
+ common = grub-core/lib/argon2/argon2.c;
+ common = grub-core/lib/argon2/core.c;
+ common = grub-core/lib/argon2/ref.c;
+ common = grub-core/lib/argon2/blake2/blake2b.c;
common = grub-core/lib/json/json.c;
common = grub-core/disk/luks.c;
common = grub-core/disk/luks2.c;
diff --git a/grub-core/Makefile.core.def b/grub-core/Makefile.core.def
index 7e96cb1ce..7ffd26528 100644
--- a/grub-core/Makefile.core.def
+++ b/grub-core/Makefile.core.def
@@ -1204,7 +1204,7 @@ module = {
common = disk/luks2.c;
common = lib/gnulib/base64.c;
cflags = '$(CFLAGS_POSIX) $(CFLAGS_GNULIB)';
- cppflags = '$(CPPFLAGS_POSIX) $(CPPFLAGS_GNULIB) -I$(srcdir)/lib/json';
+ cppflags = '$(CPPFLAGS_POSIX) $(CPPFLAGS_GNULIB) -I$(srcdir)/lib/json -I$(srcdir)/lib/argon2';
};
module = {
diff --git a/grub-core/disk/luks2.c b/grub-core/disk/luks2.c
index 767631198..3c79f14aa 100644
--- a/grub-core/disk/luks2.c
+++ b/grub-core/disk/luks2.c
@@ -27,6 +27,7 @@
#include <grub/partition.h>
#include <grub/i18n.h>
+#include <argon2.h>
#include <base64.h>
#include <json.h>
@@ -435,8 +436,16 @@ luks2_decrypt_key (grub_uint8_t *out_key,
{
case LUKS2_KDF_TYPE_ARGON2I:
case LUKS2_KDF_TYPE_ARGON2ID:
- ret = grub_error (GRUB_ERR_BAD_ARGUMENT, "Argon2 not supported");
- goto err;
+ ret = argon2_hash (k->kdf.u.argon2.time, k->kdf.u.argon2.memory, k->kdf.u.argon2.cpus,
+ passphrase, passphraselen, salt, saltlen, area_key, k->area.key_size,
+ k->kdf.type == LUKS2_KDF_TYPE_ARGON2I ? Argon2_i : Argon2_id,
+ ARGON2_VERSION_NUMBER);
+ if (ret)
+ {
+ grub_dprintf ("luks2", "Argon2 failed: %s\n", argon2_error_message (ret));
+ goto err;
+ }
+ break;
case LUKS2_KDF_TYPE_PBKDF2:
hash = grub_crypto_lookup_md_by_name (k->kdf.u.pbkdf2.hash);
if (!hash)
--
2.25.1
^ permalink raw reply related
* Re: [PATCH] openvswitch: Distribute switch variables for initialization
From: David Miller @ 2020-02-20 18:00 UTC (permalink / raw)
To: keescook; +Cc: pshelar, glider, netdev, dev, linux-kernel
In-Reply-To: <20200220062309.69077-1-keescook@chromium.org>
From: Kees Cook <keescook@chromium.org>
Date: Wed, 19 Feb 2020 22:23:09 -0800
> Variables declared in a switch statement before any case statements
> cannot be automatically initialized with compiler instrumentation (as
> they are not part of any execution flow). With GCC's proposed automatic
> stack variable initialization feature, this triggers a warning (and they
> don't get initialized). Clang's automatic stack variable initialization
> (via CONFIG_INIT_STACK_ALL=y) doesn't throw a warning, but it also
> doesn't initialize such variables[1]. Note that these warnings (or silent
> skipping) happen before the dead-store elimination optimization phase,
> so even when the automatic initializations are later elided in favor of
> direct initializations, the warnings remain.
>
> To avoid these problems, move such variables into the "case" where
> they're used or lift them up into the main function body.
>
> net/openvswitch/flow_netlink.c: In function ‘validate_set’:
> net/openvswitch/flow_netlink.c:2711:29: warning: statement will never be executed [-Wswitch-unreachable]
> 2711 | const struct ovs_key_ipv4 *ipv4_key;
> | ^~~~~~~~
>
> [1] https://bugs.llvm.org/show_bug.cgi?id=44916
>
> Signed-off-by: Kees Cook <keescook@chromium.org>
Applied.
^ permalink raw reply
* Re: [RESEND PATCH v2 0/2] Enable Odroid-XU3/4 to use Energy Model and Energy Aware Scheduler
From: Krzysztof Kozlowski @ 2020-02-20 18:00 UTC (permalink / raw)
To: Lukasz Luba
Cc: mark.rutland, devicetree, linux-samsung-soc, linux-pm,
b.zolnierkie, linux-kernel, robh+dt, cw00.choi, kyungmin.park,
kgene, myungjoo.ham, dietmar.eggemann, linux-arm-kernel
In-Reply-To: <20200220095636.29469-1-lukasz.luba@arm.com>
On Thu, Feb 20, 2020 at 09:56:34AM +0000, Lukasz Luba wrote:
> Hi all,
>
> This is just a resend, now with proper v2 in the patches subject.
>
> The Odroid-XU4/3 is a decent and easy accessible ARM big.LITTLE platform,
> which might be used for research and development.
>
> This small patch set provides possibility to run Energy Aware Scheduler (EAS)
> on Odroid-XU4/3 and experiment with it.
>
> The patch 1/2 provides 'dynamic-power-coefficient' in CPU DT nodes, which is
> then used by the Energy Model (EM).
> The patch 2/2 enables SCHED_MC (which adds another level in scheduling domains)
> and enables EM making EAS possible to run (when schedutil is set as a CPUFreq
> governor).
>
> 1. Test results
>
> Two types of different tests have been executed. The first is energy test
> case showing impact on energy consumption of this patch set. It is using a
> synthetic set of tasks (rt-app based). The second is the performance test
> case which is using hackbench (less time to complete is better).
> In both tests schedutil has been used as cpufreq governor. In all tests
> PROVE_LOCKING has not been compiled into the kernels.
>
> 1.1 Energy test case
>
> 10 iterations of 24 periodic rt-app tasks (16ms period, 10% duty-cycle)
> with energy measurement. The cpufreq governor - schedutil. Unit is Joules.
> The energy is calculated based on hwmon0 and hwmon3 power1_input.
> The goal is to save energy, lower is better.
>
> +-----------+-----------------+------------------------+
> | | Without patches | With patches |
> +-----------+--------+--------+----------------+-------+
> | benchmark | Mean | RSD* | Mean | RSD* |
> +-----------+--------+--------+----------------+-------+
> | 24 rt-app | 21.56 | 1.37% | 19.85 (-9.2%) | 0.92% |
> | tasks | | | | |
> +-----------+--------+--------+----------------+-------+
>
> 1.2 Performance test case
>
> 10 consecutive iterations of hackbench (hackbench -l 500 -s 4096),
> no delay between two successive executions.
> The cpufreq governor - schedutil. Units in seconds.
> The goal is to see not regression, lower completion time is better.
>
> +-----------+-----------------+------------------------+
> | | Without patches | With patches |
> +-----------+--------+--------+----------------+-------+
> | benchmark | Mean | RSD* | Mean | RSD* |
> +-----------+--------+--------+----------------+-------+
> | hackbench | 8.15 | 2.86% | 7.95 (-2.5%) | 0.60% |
> +-----------+--------+--------+----------------+-------+
>
> *RSD: Relative Standard Deviation (std dev / mean)
Nice measurements!
Applied both, thank you.
Best regards,
Krzysztof
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* Re: [PATCH kvmtool v2] Add emulation for CFI compatible flash memory
From: Andre Przywara @ 2020-02-20 18:00 UTC (permalink / raw)
To: Alexandru Elisei
Cc: Raphael Gault, Julien Thierry, Sami Mujawar, Will Deacon, kvmarm,
linux-arm-kernel
In-Reply-To: <9f51ac2e-c9a3-ef99-2d6a-2e31c4d5aa1c@arm.com>
On Thu, 20 Feb 2020 10:24:13 +0000
Alexandru Elisei <alexandru.elisei@arm.com> wrote:
Hi,
> On 2/19/20 5:26 PM, Andre Przywara wrote:
> > On Mon, 17 Feb 2020 17:20:43 +0000
> > Alexandru Elisei <alexandru.elisei@arm.com> wrote:
> >
> > Hi,
> >
> >> I guess the device hasn't been tested with Linux. This is what I'm getting when
> >> trying to boot a Linux guest using the command:
> > It was actually developed with a Linux guest, because that's more verbatim and easier to debug.
> >
> > And I just tested this again with Linux and it worked for me:
>
> The flash image you provided is 2 MB. The flash image that I used is 10 MB (it
> shows in the log that I sent). I guess you ran a different test.
What I stated below ... I guess there is some miscommunication here: I tested with Linux, just not with odd flash sizes. Which I agree should be either handled correctly or denied by kvmtool.
>
> > [ 2.164992] physmap-flash 20000.flash: physmap platform flash device: [mem 0x00020000-0x0021ffff]
> > [ 2.166539] 20000.flash: Found 2 x16 devices at 0x0 in 32-bit bank. Manufacturer ID 0x000000 Chip ID 0x00ffff
> > ...
> > # mtd_debug info /dev/mtd0
> > mtd.type = MTD_NORFLASH
> > mtd.flags = MTD_CAP_NORFLASH
> > mtd.size = 2097152 (2M)
> > mtd.erasesize = 65536 (64K)
> > mtd.writesize = 1
> > mtd.oobsize = 0
> > regions = 1
> >
> > I think what you are seeing are problems when you give a non-power-of-2 sized flash image. The current patch does not really support this (since it's hardly a thing in the real world). I originally wanted to expand any "uneven" size to the next power-of-2, but this doesn't work easily with mmap.
>
> I would expect that if kvmtool allows the user to specify a non-power-of-2 flash
> image size, then it should know how to deal with it and not present a broken
> device to a linux guest if that size is forbidden by the spec. Or it is allowed by
> the specification and kvmtool doesn't know how to deal with it?
I don't know, I would guess physical flash has always a power-of-2 size, at least on a per-chip base. So the "spec" doesn't even consider the other case.
> Instead of expanding the file provided by the user to fit a bigger flash, how
> about you use the highest power of two size that is smaller than the flash size?
The original idea was to avoid cutting off the flash file, but this doesn't really work easily, or at least is not worth the effort.
So I was suggesting the trimming you mentioned in the next sentence ;-)
vvvvvvvvvvvvv
> > So I now changed the code to downgrade, so you get 8MB with any file ranging from [8MB, 16MB(, for instance.
> > That fixed the Linux problems with those files for me.
> >
> >> $ ./lkvm run -c4 -m4096 -k /path/to/kernel -d /path/to/disk -p root="/dev/vda2" -F
> >> flash.img
> >>
> >> [ 0.659167] physmap-flash 2000000.flash: physmap platform flash device: [mem
> >> 0x02000000-0x029fffff]
> >> [ 0.660444] Number of erase regions: 1
> >> [ 0.661036] Primary Vendor Command Set: 0001 (Intel/Sharp Extended)
> >> [ 0.661688] Primary Algorithm Table at 0031
> >> [ 0.662168] Alternative Vendor Command Set: 0000 (None)
> >> [ 0.662711] No Alternate Algorithm Table
> >> [ 0.663120] Vcc Minimum: 4.5 V
> >> [ 0.663450] Vcc Maximum: 5.5 V
> >> [ 0.663779] No Vpp line
> >> [ 0.664039] Typical byte/word write timeout: 2 µs
> >> [ 0.664590] Maximum byte/word write timeout: 2 µs
> >> [ 0.665240] Typical full buffer write timeout: 2 µs
> >> [ 0.665775] Maximum full buffer write timeout: 2 µs
> >> [ 0.666373] Typical block erase timeout: 2 ms
> >> [ 0.666828] Maximum block erase timeout: 2 ms
> >> [ 0.667282] Chip erase not supported
> >> [ 0.667659] Device size: 0x800000 bytes (8 MiB)
> >> [ 0.668137] Flash Device Interface description: 0x0006
> >> [ 0.668697] - Unknown
> >> [ 0.668963] Max. bytes in buffer write: 0x40
> >> [ 0.669407] Number of Erase Block Regions: 1
> >> [ 0.669865] Erase Region #0: BlockSize 0x8000 bytes, 160 blocks
> >> [ 0.672299] 2000000.flash: Found 2 x16 devices at 0x0 in 32-bit bank.
> >> Manufacturer ID 0x000000 Chip ID 0x00ffff
> >> [ 0.681328] NOR chip too large to fit in mapping. Attempting to cope...
> >> [ 0.682046] Intel/Sharp Extended Query Table at 0x0031
> >> [ 0.682645] Using buffer write method
> >> [ 0.683031] Sum of regions (a00000) != total size of set of interleaved chips
> >> (1000000)
> >> [ 0.683854] gen_probe: No supported Vendor Command Set found
> >> [ 0.684441] physmap-flash 2000000.flash: map_probe failed
> >>
> >> I also defined DEBUG_CFI in drivers/mtd/chips/cfi_probe.c.
> >>
> >> The Flash Device Interface description that we provide is wrong, it should 0x05.
> >> More details below.
> >>
> >> On 2/7/20 12:19 PM, Andre Przywara wrote:
> >>> From: Raphael Gault <raphael.gault@arm.com>
> >>>
> >>> The EDK II UEFI firmware implementation requires some storage for the EFI
> >>> variables, which is typically some flash storage.
> >>> Since this is already supported on the EDK II side, we add a CFI flash
> >>> emulation to kvmtool.
> >>> This is backed by a file, specified via the --flash or -F command line
> >>> option. Any flash writes done by the guest will immediately be reflected
> >>> into this file (kvmtool mmap's the file).
> >>>
> >>> This implements a CFI flash using the "Intel/Sharp extended command
> >>> set", as specified in:
> >>> - JEDEC JESD68.01
> >>> - JEDEC JEP137B
> >>> - Intel Application Note 646
> >>> Some gaps in those specs have been filled by looking at real devices and
> >>> other implementations (QEMU, Linux kernel driver).
> >>>
> >>> At the moment this relies on DT to advertise the base address of the
> >>> flash memory (mapped into the MMIO address space) and is only enabled
> >>> for ARM/ARM64. The emulation itself is architecture agnostic, though.
> >>>
> >>> This is one missing piece toward a working UEFI boot with kvmtool on
> >>> ARM guests, the other is to provide writable PCI BARs, which is WIP.
> >>>
> >>> Signed-off-by: Raphael Gault <raphael.gault@arm.com>
> >>> [Andre: rewriting and fixing]
> >>> Signed-off-by: Andre Przywra <andre.przywara@arm.com>
> >>> ---
> >>> Hi,
> >>>
> >>> an update addressing Will's comments. I added coarse grained locking
> >>> to the MMIO handler, to prevent concurrent vCPU accesses from messing up
> >>> the internal CFI flash state machine.
> >>> I also folded the actual flash array read access into the MMIO handler
> >>> and fixed the other small issues.
> >>>
> >>> Cheers,
> >>> Andre
> >>>
> >>> Makefile | 6 +
> >>> arm/include/arm-common/kvm-arch.h | 3 +
> >>> builtin-run.c | 2 +
> >>> hw/cfi_flash.c | 546 ++++++++++++++++++++++++++++++
> >>> include/kvm/kvm-config.h | 1 +
> >>> include/kvm/util.h | 5 +
> >>> 6 files changed, 563 insertions(+)
> >>> create mode 100644 hw/cfi_flash.c
> >>>
> >>> diff --git a/Makefile b/Makefile
> >>> index 3862112c..7ed6fb5e 100644
> >>> --- a/Makefile
> >>> +++ b/Makefile
> >>> @@ -170,6 +170,7 @@ ifeq ($(ARCH), arm)
> >>> CFLAGS += -march=armv7-a
> >>>
> >>> ARCH_WANT_LIBFDT := y
> >>> + ARCH_HAS_FLASH_MEM := y
> >>> endif
> >>>
> >>> # ARM64
> >>> @@ -182,6 +183,7 @@ ifeq ($(ARCH), arm64)
> >>> ARCH_INCLUDE += -Iarm/aarch64/include
> >>>
> >>> ARCH_WANT_LIBFDT := y
> >>> + ARCH_HAS_FLASH_MEM := y
> >>> endif
> >>>
> >>> ifeq ($(ARCH),mips)
> >>> @@ -261,6 +263,10 @@ ifeq (y,$(ARCH_HAS_FRAMEBUFFER))
> >>> endif
> >>> endif
> >>>
> >>> +ifeq (y,$(ARCH_HAS_FLASH_MEM))
> >>> + OBJS += hw/cfi_flash.o
> >>> +endif
> >>> +
> >>> ifeq ($(call try-build,$(SOURCE_ZLIB),$(CFLAGS),$(LDFLAGS) -lz),y)
> >>> CFLAGS_DYNOPT += -DCONFIG_HAS_ZLIB
> >>> LIBS_DYNOPT += -lz
> >>> diff --git a/arm/include/arm-common/kvm-arch.h b/arm/include/arm-common/kvm-arch.h
> >>> index b9d486d5..2bb085f4 100644
> >>> --- a/arm/include/arm-common/kvm-arch.h
> >>> +++ b/arm/include/arm-common/kvm-arch.h
> >>> @@ -21,6 +21,9 @@
> >>> #define ARM_GIC_DIST_SIZE 0x10000
> >>> #define ARM_GIC_CPUI_SIZE 0x20000
> >>>
> >>> +#define ARM_FLASH_MMIO_BASE 0x2000000 /* 32 MB */
> >>> +#define KVM_FLASH_MMIO_BASE ARM_FLASH_MMIO_BASE
> >>> +
> >>> #define ARM_IOPORT_SIZE (ARM_MMIO_AREA - ARM_IOPORT_AREA)
> >>> #define ARM_VIRTIO_MMIO_SIZE (ARM_AXI_AREA - (ARM_MMIO_AREA + ARM_GIC_SIZE))
> >>> #define ARM_PCI_CFG_SIZE (1ULL << 24)
> >>> diff --git a/builtin-run.c b/builtin-run.c
> >>> index f8dc6c72..df8c6741 100644
> >>> --- a/builtin-run.c
> >>> +++ b/builtin-run.c
> >>> @@ -138,6 +138,8 @@ void kvm_run_set_wrapper_sandbox(void)
> >>> "Kernel command line arguments"), \
> >>> OPT_STRING('f', "firmware", &(cfg)->firmware_filename, "firmware",\
> >>> "Firmware image to boot in virtual machine"), \
> >>> + OPT_STRING('F', "flash", &(cfg)->flash_filename, "flash",\
> >>> + "Flash image to present to virtual machine"), \
> >>> \
> >>> OPT_GROUP("Networking options:"), \
> >>> OPT_CALLBACK_DEFAULT('n', "network", NULL, "network params", \
> >>> diff --git a/hw/cfi_flash.c b/hw/cfi_flash.c
> >>> new file mode 100644
> >>> index 00000000..d7c0e7e8
> >>> --- /dev/null
> >>> +++ b/hw/cfi_flash.c
> >>> @@ -0,0 +1,546 @@
> >>> +#include <stdbool.h>
> >>> +#include <stdlib.h>
> >>> +#include <string.h>
> >>> +#include <linux/bitops.h>
> >>> +#include <linux/err.h>
> >>> +#include <linux/sizes.h>
> >>> +#include <linux/types.h>
> >>> +
> >>> +#include "kvm/kvm.h"
> >>> +#include "kvm/kvm-arch.h"
> >>> +#include "kvm/devices.h"
> >>> +#include "kvm/fdt.h"
> >>> +#include "kvm/mutex.h"
> >>> +#include "kvm/util.h"
> >>> +
> >>> +/* The EDK2 driver hardcodes two 16-bit chips on a 32-bit bus. */
> >>> +#define CFI_NR_FLASH_CHIPS 2
> >>> +
> >>> +/* We always emulate a 32 bit bus width. */
> >>> +#define CFI_BUS_WIDTH 4
> >>> +
> >>> +/* The *effective* size of an erase block (over all chips) */
> >>> +#define FLASH_BLOCK_SIZE SZ_64K
> >>> +
> >>> +#define PROGRAM_BUFF_SIZE_BITS 7
> >>> +#define PROGRAM_BUFF_SIZE (1U << PROGRAM_BUFF_SIZE_BITS)
> >>> +
> >>> +/* CFI commands */
> >>> +#define CFI_CMD_LOCK_BLOCK 0x01
> >>> +#define CFI_CMD_ALTERNATE_WORD_PROGRAM_SETUP 0x10
> >>> +#define CFI_CMD_BLOCK_ERASE_SETUP 0x20
> >>> +#define CFI_CMD_WORD_PROGRAM_SETUP 0x40
> >>> +#define CFI_CMD_CLEAR_STATUS_REGISTER 0x50
> >>> +#define CFI_CMD_LOCK_BLOCK_SETUP 0x60
> >>> +#define CFI_CMD_READ_STATUS_REGISTER 0x70
> >>> +#define CFI_CMD_READ_JEDEC 0x90
> >>> +#define CFI_CMD_READ_CFI_QUERY 0x98
> >>> +#define CFI_CMD_BUFFERED_PROGRAM_CONFIRM 0xd0
> >>> +#define CFI_CMD_BLOCK_ERASE_CONFIRM 0xd0
> >>> +#define CFI_CMD_UNLOCK_BLOCK 0xd0
> >>> +#define CFI_CMD_BUFFERED_PROGRAM_SETUP 0xe8
> >>> +#define CFI_CMD_READ_ARRAY 0xff
> >>> +
> >>> +/*
> >>> + * CFI query table contents, as far as it is constant.
> >>> + */
> >>> +#define CFI_GEOM_OFFSET 0x27
> >>> +static u8 cfi_query_table[] = {
> >>> + /* offset 0x10: CFI query identification string */
> >>> + 'Q', 'R', 'Y', /* ID string */
> >>> + 0x01, 0x00, /* primary command set: Intel/Sharp extended */
> >>> + 0x31, 0x00, /* address of primary extended query table */
> >>> + 0x00, 0x00, /* alternative command set: unused */
> >>> + 0x00, 0x00, /* address of alternative extended query table*/
> >>> + /* offset 0x1b: system interface information */
> >>> + 0x45, /* minimum Vcc voltage: 4.5V */
> >>> + 0x55, /* maximum Vcc voltage: 5.5V */
> >>> + 0x00, /* minimum Vpp voltage: 0.0V (unused) */
> >>> + 0x00, /* maximum Vpp voltage: 0.0V *(unused) */
> >>> + 0x01, /* timeout for single word program: 2 us */
> >>> + 0x01, /* timeout for multi-byte program: 2 us */
> >>> + 0x01, /* timeout for block erase: 2 ms */
> >>> + 0x00, /* timeout for full chip erase: not supported */
> >>> + 0x00, /* max timeout for single word program: 1x */
> >>> + 0x00, /* max timeout for mulit-byte program: 1x */
> >>> + 0x00, /* max timeout for block erase: 1x */
> >>> + 0x00, /* max timeout for chip erase: not supported */
> >>> + /* offset 0x27: flash geometry information */
> >>> + 0x00, /* size in power-of-2 bytes, filled later */
> >>> + 0x06, 0x00, /* interface description: 32 and 16 bits */
> >> I don't think this is correct. From Intel StrataFlash Embedded Memory (P30)
> >> Family, table 34:
> >>
> >> ""n" such that n+1 specifies the bit field that represents the flash device width
> >> capabilities as described in the table".
> > Yeah, seems to be correct, but it looks this Intel Strata document is the only place which details this encoding (which looks like being retrofit somehow).
> > And I didn't really use this document, because it's a manufacturer data sheet and not a specification.
>
> The device is in the list of specification you provided in the commit message.
Where? I only see JEP137B, JESD68-01 and Intel AN-646 in the list up there.
> I
> think it would make the reviewers' life a lot easier if you posted all the
> documentation that you used, and drop documentation that you didn't. Where did you
> get the value 0x06 from? That was the only document from where I could infer what
> it means, maybe I didn't dig deep enough.
>
> > I will change it to 0x5, but for the records Linux worked even with 0x6 for me.
>
> I would say that in this case working != correct, because Linux 5.6-rc2 defines
> 0x05 as a x32/x16 interface, and 0x06 is undefined in the file that I mentioned in
> the previous reply. Did you check to see if the Linux driver recognized that
> interface type? Maybe it changed between versions. I also tried 0x00,0x00 for the
> interface description and Linux also worked.
I guess because the emulation doesn't really care about the access size (we use memcpy).
> Either way, I followed the trail of breadcrumbs starting at the comment for the
> define and I found this in Common Flash Memory Interface Specification release
> 2.0, Appendix:
>
> "Note: April 2000 -x16/x32 devices will be represented by hex value 0005h as
> requested by Intel in order to make them more software friendly. Changes will be
> made to the CFI drivers so that a bit-wise switch is created to represent
> different data widths. [..] For example, if we take the description for an x16/x32
> device (0005h) and we convert that to binary we get 0101b. If we add one to this
> value we get a bit pattern that looks like this: 0110b. This bit-wise switch
> indicates that the device a x16/x32 device".
>
> I guess the reason for the inconsistencies is that at some point it used to be
> different, but it was changed because Intel requested it.
Yeah, I found this one as well later.
> >> If you want to advertise 32 and 16 bit write capabilities, it should be 5 because
> >> 5+1=6. This is also the value that the Linux kernel checks for (see
> >> include/linux/mtd/cfi.h, define CFI_INTERFACE_X16_BY_X32_ASYNC"). 6 actually means
> >> 32, 16 and 8 bit accesses.
> >>
> >> This begs another question: why do we support both 16 and 32 bit accesses instead
> >> of supporting only 32 bit?
> > Because we can, there is no reason to restrict this. I feel like we should be as capable as possible, especially since it's trivial to emulate.
>
> Makes sense.
>
> >
> >>> + PROGRAM_BUFF_SIZE_BITS + 1 - CFI_NR_FLASH_CHIPS, 0x00,
> >>> + /* number of multi-byte writes */
> >> Shouldn't the comment be maximum number of bytes in the write buffer?
> > Yes, possibly.
> >
> >>> + 0x01, /* one erase block region */
> >>> + 0x00, 0x00, 0x00, 0x00, /* number and size of erase blocks, filled */
> >>> + /* offset 0x31: Intel primary algorithm extended query table */
> >>> + 'P', 'R', 'I',
> >>> + '1', '0', /* version 1.0 */
> >>> + 0xa0, 0x00, 0x00, 0x00, /* optional features: instant lock & pm-read */
> >>> + 0x00, /* no functions after suspend */
> >>> + 0x01, 0x00, /* only lock bit supported */
> >>> + 0x50, /* best Vcc value: 5.0V */
> >>> + 0x00, /* best Vpp value: 0.0V (unused) */
> >>> + 0x01, /* number of protection register fields */
> >>> + 0x00, 0x00, 0x00, 0x00, /* protection field 1 description */
> >>> +};
> >> As an aside, I found it impossible to review the cfi_query_table array in its
> >> current form. This is how I wrote the array so I could read it. I also took the
> >> liberty to remove the offset when indexing the array, making read_cfi less error
> >> prone, in my opinion:
> > Please don't post elaborate code sequences as a comment, especially not if it gets mangled (Thunderbird is annoyingly bad in this respect).
>
> I use Thunderbird and it showed fine for me, and I have sent large diffs before in
> replies and I got no complaints. I use the settings from
> Documentation/process/email-clients.rst.
Maybe it was a problem because (I guess) you copy&pasted the diff in?
Because I see a "...skipping..." line in there, bogus line breaks and all tabs were converted into spaces. Or there was some cocky mail server in the queue ;-)
Eventually I gave up with sending diffs other than for demonstration purposes through the Thunderbird editor because of various problems.
As a workaround you could try to save the email, fix it up with a proper editor (or insert the patch there), then send it via git send-email.
Or avoid sending patches this way at all ;-)
I will send v3 tomorrow morning after double checking that I didn't miss a comment.
Cheers,
Andre
> Thanks,
> Alex
> > I think I would have got what you mean by showing just one line ;-)
> >
> > Cheers,
> > Andre
> >
> >> diff --git a/hw/cfi_flash.c b/hw/cfi_flash.c
> >> index d7c0e7e80d69..65a90e288be8 100644
> >> --- a/hw/cfi_flash.c
> >> +++ b/hw/cfi_flash.c
> >> @@ -46,45 +46,43 @@
> >> */
> >> #define CFI_GEOM_OFFSET 0x27
> >> static u8 cfi_query_table[] = {
> >> - /* offset 0x10: CFI query identification string */
> >> - 'Q', 'R', 'Y', /* ID string */
> >> - 0x01, 0x00, /* primary command set: Intel/Sharp extended */
> >> - 0x31, 0x00, /* address of primary extended query table */
> >> - 0x00, 0x00, /* alternative command set: unused */
> >> - 0x00, 0x00, /* address of alternative extended query table*/
> >> - /* offset 0x1b: system interface information */
> >> - 0x45, /* minimum Vcc voltage: 4.5V */
> >> - 0x55, /* maximum Vcc voltage: 5.5V */
> >> - 0x00, /* minimum Vpp voltage: 0.0V (unused) */
> >> - 0x00, /* maximum Vpp voltage: 0.0V *(unused) */
> >> - 0x01, /* timeout for single word program: 2 us */
> >> - 0x01, /* timeout for multi-byte program: 2 us */
> >> - 0x01, /* timeout for block erase: 2 ms */
> >> - 0x00, /* timeout for full chip erase: not supported */
> >> - 0x00, /* max timeout for single word program: 1x */
> >> - 0x00, /* max timeout for mulit-byte program: 1x */
> >> - 0x00, /* max timeout for block erase: 1x */
> >> - 0x00, /* max timeout for chip erase: not supported */
> >> - /* offset 0x27: flash geometry information */
> >> - 0x00, /* size in power-of-2 bytes, filled later */
> >> - 0x06, 0x00, /* interface description: 32 and 16 bits */
> >> - PROGRAM_BUFF_SIZE_BITS + 1 - CFI_NR_FLASH_CHIPS, 0x00,
> >> + [0x10] = 'Q', 'R', 'Y', /* ID string */
> >> + [0x13] = 0x01, 0x00, /* primary command set: Intel/Sharp extended */
> >> + [0x15] = 0x31, 0x00, /* address of primary extended query table */
> >> + [0x17] = 0x00, 0x00, /* alternative command set: unused */
> >> + [0x19] = 0x00, 0x00, /* address of alternative extended query table*/
> >> + /* System interface information */
> >> + [0x1b] = 0x45, /* minimum Vcc voltage: 4.5V */
> >> + [0x1c] = 0x55, /* maximum Vcc voltage: 5.5V */
> >> + [0x1d] = 0x00, /* minimum Vpp voltage: 0.0V (unused) */
> >> + [0x1e] = 0x00, /* maximum Vpp voltage: 0.0V *(unused) */
> >> + [0x1f] = 0x01, /* timeout for single word program: 2 us */
> >> + [0x20] = 0x01, /* timeout for multi-byte program: 2 us */
> >> + [0x21] = 0x01, /* timeout for block erase: 2 ms */
> >> + [0x22] = 0x00, /* timeout for full chip erase: not supported */
> >> + [0x23] = 0x00, /* max timeout for single word program: 1x */
> >> + [0x24] = 0x00, /* max timeout for mulit-byte program: 1x */
> >> + [0x25] = 0x00, /* max timeout for block erase: 1x */
> >> + [0x26] = 0x00, /* max timeout for chip erase: not supported */
> >> + /* Flash geometry information */
> >> + [0x27] = 0x00, /* size in power-of-2 bytes, filled later */
> >> + [0x28] = 0x06, 0x00, /* interface description: 32 and 16 bits */
> >> + [0x2a] = PROGRAM_BUFF_SIZE_BITS + 1 - CFI_NR_FLASH_CHIPS, 0x00,
> >> /* number of multi-byte writes */
> >> - 0x01, /* one erase block region */
> >> - 0x00, 0x00, 0x00, 0x00, /* number and size of erase blocks, filled */
> >> - /* offset 0x31: Intel primary algorithm extended query table */
> >> - 'P', 'R', 'I',
> >> - '1', '0', /* version 1.0 */
> >> - 0xa0, 0x00, 0x00, 0x00, /* optional features: instant lock & pm-read */
> >> - 0x00, /* no functions after suspend */
> >> - 0x01, 0x00, /* only lock bit supported */
> >> - 0x50, /* best Vcc value: 5.0V */
> >> - 0x00, /* best Vpp value: 0.0V (unused) */
> >> - 0x01, /* number of protection register fields */
> >> - 0x00, 0x00, 0x00, 0x00, /* protection field 1 description */
> >> + [0x2c] = 0x01, /* one erase block region */
> >> + [0x2d] = 0x00, 0x00, 0x00, 0x00, /* number and size of erase blocks, filled */
> >> + /* Intel primary algorithm extended query table */
> >> + [0x31] = 'P', 'R', 'I', /* ID string */
> >> + [0x34] = '1', '0', /* version 1.0 */
> >> + [0x36] = 0xa0, 0x00, 0x00, 0x00, /* optional features: instant lock &
> >> pm-read */
> >> + [0x40] = 0x00, /* no functions after suspend */
> >> + [0x41] = 0x01, 0x00, /* only lock bit supported */
> >> ...skipping...
> >> + [0x10] = 'Q', 'R', 'Y', /* ID string */
> >> + [0x13] = 0x01, 0x00, /* primary command set: Intel/Sharp extended */
> >> + [0x15] = 0x31, 0x00, /* address of primary extended query table */
> >> + [0x17] = 0x00, 0x00, /* alternative command set: unused */
> >> + [0x19] = 0x00, 0x00, /* address of alternative extended query table*/
> >> + /* System interface information */
> >> + [0x1b] = 0x45, /* minimum Vcc voltage: 4.5V */
> >> + [0x1c] = 0x55, /* maximum Vcc voltage: 5.5V */
> >> + [0x1d] = 0x00, /* minimum Vpp voltage: 0.0V (unused) */
> >> + [0x1e] = 0x00, /* maximum Vpp voltage: 0.0V *(unused) */
> >> + [0x1f] = 0x01, /* timeout for single word program: 2 us */
> >> + [0x20] = 0x01, /* timeout for multi-byte program: 2 us */
> >> + [0x21] = 0x01, /* timeout for block erase: 2 ms */
> >> + [0x22] = 0x00, /* timeout for full chip erase: not supported */
> >> + [0x23] = 0x00, /* max timeout for single word program: 1x */
> >> + [0x24] = 0x00, /* max timeout for mulit-byte program: 1x */
> >> + [0x25] = 0x00, /* max timeout for block erase: 1x */
> >> + [0x26] = 0x00, /* max timeout for chip erase: not supported */
> >> + /* Flash geometry information */
> >> + [0x27] = 0x00, /* size in power-of-2 bytes, filled later */
> >> + [0x28] = 0x06, 0x00, /* interface description: 32 and 16 bits */
> >> + [0x2a] = PROGRAM_BUFF_SIZE_BITS + 1 - CFI_NR_FLASH_CHIPS, 0x00,
> >> /* number of multi-byte writes */
> >> - 0x01, /* one erase block region */
> >> - 0x00, 0x00, 0x00, 0x00, /* number and size of erase blocks, filled */
> >> - /* offset 0x31: Intel primary algorithm extended query table */
> >> - 'P', 'R', 'I',
> >> - '1', '0', /* version 1.0 */
> >> - 0xa0, 0x00, 0x00, 0x00, /* optional features: instant lock & pm-read */
> >> - 0x00, /* no functions after suspend */
> >> - 0x01, 0x00, /* only lock bit supported */
> >> - 0x50, /* best Vcc value: 5.0V */
> >> - 0x00, /* best Vpp value: 0.0V (unused) */
> >> - 0x01, /* number of protection register fields */
> >> - 0x00, 0x00, 0x00, 0x00, /* protection field 1 description */
> >> + [0x2c] = 0x01, /* one erase block region */
> >> + [0x2d] = 0x00, 0x00, 0x00, 0x00, /* number and size of erase blocks, filled */
> >> + /* Intel primary algorithm extended query table */
> >> + [0x31] = 'P', 'R', 'I', /* ID string */
> >> + [0x34] = '1', '0', /* version 1.0 */
> >> + [0x36] = 0xa0, 0x00, 0x00, 0x00, /* optional features: instant lock &
> >> pm-read */
> >> + [0x40] = 0x00, /* no functions after suspend */
> >> + [0x41] = 0x01, 0x00, /* only lock bit supported */
> >> + [0x43] = 0x50, /* best Vcc value: 5.0V */
> >> + [0x43] = 0x00, /* best Vpp value: 0.0V (unused) */
> >> + [0x44] = 0x01, /* number of protection register fields */
> >> + [0x45] = 0x00, 0x00, 0x00, 0x00,/* protection field 1 description */
> >> };
> >>
> >> -
> >> /*
> >> * Those states represent a subset of the CFI flash state machine.
> >> */
> >> @@ -141,10 +139,7 @@ static int nr_erase_blocks(struct cfi_flash_device *sfdev)
> >> */
> >> static u8 read_cfi(struct cfi_flash_device *sfdev, u64 addr)
> >> {
> >> - if (addr < 0x10) /* CFI information starts at 0x10 */
> >> - return 0;
> >> -
> >> - if (addr - 0x10 > sizeof(cfi_query_table)) {
> >> + if (addr > sizeof(cfi_query_table)) {
> >> pr_debug("CFI query read access beyond the end of table");
> >> return 0;
> >> }
> >> @@ -163,7 +158,7 @@ static u8 read_cfi(struct cfi_flash_device *sfdev, u64 addr)
> >> return ((FLASH_BLOCK_SIZE / 256 ) / CFI_NR_FLASH_CHIPS) >> 8;
> >> }
> >>
> >> - return cfi_query_table[addr - 0x10];
> >> + return cfi_query_table[addr];
> >> }
> >>
> >> static bool block_is_locked(struct cfi_flash_device *sfdev, u64 addr)
> >>
> >> Thanks,
> >> Alex
> >>> +
> >>> +
> >>> +/*
> >>> + * Those states represent a subset of the CFI flash state machine.
> >>> + */
> >>> +enum cfi_flash_state {
> >>> + READY,
> >>> + LOCK_SETUP,
> >>> + WP_SETUP,
> >>> + BP_SETUP,
> >>> + BP_LOAD,
> >>> + ERASE_SETUP,
> >>> +};
> >>> +
> >>> +/*
> >>> + * The device can be in several **Read** modes.
> >>> + * We don't implement the asynchronous burst mode.
> >>> + */
> >>> +enum cfi_read_mode {
> >>> + READ_ARRAY,
> >>> + READ_STATUS,
> >>> + READ_DEVICE_ID,
> >>> + READ_QUERY,
> >>> +};
> >>> +
> >>> +struct cfi_flash_device {
> >>> + struct device_header dev_hdr;
> >>> + /* Protects the CFI state machine variables in this data structure. */
> >>> + struct mutex mutex;
> >>> + u64 base_addr;
> >>> + u32 size;
> >>> +
> >>> + void *flash_memory;
> >>> + u8 program_buffer[PROGRAM_BUFF_SIZE * 4];
> >>> + unsigned long *lock_bm;
> >>> + u64 last_address;
> >>> + unsigned int buff_written;
> >>> + unsigned int program_length;
> >>> +
> >>> + enum cfi_flash_state state;
> >>> + enum cfi_read_mode read_mode;
> >>> + u16 rcr;
> >>> + u8 sr;
> >>> +};
> >>> +
> >>> +static int nr_erase_blocks(struct cfi_flash_device *sfdev)
> >>> +{
> >>> + return sfdev->size / FLASH_BLOCK_SIZE;
> >>> +}
> >>> +
> >>> +/*
> >>> + * CFI queries always deal with one byte of information, possibly mirrored
> >>> + * to other bytes on the bus. This is dealt with in the callers.
> >>> + * The address provided is the one for 8-bit addressing, and would need to
> >>> + * be adjusted for wider accesses.
> >>> + */
> >>> +static u8 read_cfi(struct cfi_flash_device *sfdev, u64 addr)
> >>> +{
> >>> + if (addr < 0x10) /* CFI information starts at 0x10 */
> >>> + return 0;
> >>> +
> >>> + if (addr - 0x10 > sizeof(cfi_query_table)) {
> >>> + pr_debug("CFI query read access beyond the end of table");
> >>> + return 0;
> >>> + }
> >>> +
> >>> + /* Fixup dynamic information in the geometry part of the table. */
> >>> + switch (addr) {
> >>> + case CFI_GEOM_OFFSET: /* device size in bytes, power of two */
> >>> + return pow2_size(sfdev->size / CFI_NR_FLASH_CHIPS);
> >>> + case CFI_GEOM_OFFSET + 6: /* number of erase blocks, minus one */
> >>> + return (nr_erase_blocks(sfdev) - 1) & 0xff;
> >>> + case CFI_GEOM_OFFSET + 7:
> >>> + return (nr_erase_blocks(sfdev) - 1) >> 8;
> >>> + case CFI_GEOM_OFFSET + 8: /* erase block size, in units of 256 */
> >>> + return ((FLASH_BLOCK_SIZE / 256 ) / CFI_NR_FLASH_CHIPS) & 0xff;
> >>> + case CFI_GEOM_OFFSET + 9:
> >>> + return ((FLASH_BLOCK_SIZE / 256 ) / CFI_NR_FLASH_CHIPS) >> 8;
> >>> + }
> >>> +
> >>> + return cfi_query_table[addr - 0x10];
> >>> +}
> >>> +
> >>> +static bool block_is_locked(struct cfi_flash_device *sfdev, u64 addr)
> >>> +{
> >>> + int block_nr = addr / FLASH_BLOCK_SIZE;
> >>> +
> >>> + return test_bit(block_nr, sfdev->lock_bm);
> >>> +}
> >>> +
> >>> +#define DEV_ID_MASK 0x7ff
> >>> +static u16 read_dev_id(struct cfi_flash_device *sfdev, u64 addr)
> >>> +{
> >>> + switch ((addr & DEV_ID_MASK) / CFI_BUS_WIDTH) {
> >>> + case 0x0: /* vendor ID */
> >>> + return 0x0000;
> >>> + case 0x1: /* device ID */
> >>> + return 0xffff;
> >>> + case 0x2:
> >>> + return block_is_locked(sfdev, addr & ~DEV_ID_MASK);
> >>> + case 0x5:
> >>> + return sfdev->rcr;
> >>> + default: /* Ignore the other entries. */
> >>> + return 0;
> >>> + }
> >>> +}
> >>> +
> >>> +static void lock_block(struct cfi_flash_device *sfdev, u64 addr, bool lock)
> >>> +{
> >>> + int block_nr = addr / FLASH_BLOCK_SIZE;
> >>> +
> >>> + if (lock)
> >>> + set_bit(block_nr, sfdev->lock_bm);
> >>> + else
> >>> + clear_bit(block_nr, sfdev->lock_bm);
> >>> +}
> >>> +
> >>> +static void word_program(struct cfi_flash_device *sfdev,
> >>> + u64 addr, void *data, int len)
> >>> +{
> >>> + if (block_is_locked(sfdev, addr)) {
> >>> + sfdev->sr |= 0x12;
> >>> + return;
> >>> + }
> >>> +
> >>> + memcpy(sfdev->flash_memory + addr, data, len);
> >>> +}
> >>> +
> >>> +/* Reset the program buffer state to prepare for follow-up writes. */
> >>> +static void buffer_setup(struct cfi_flash_device *sfdev)
> >>> +{
> >>> + memset(sfdev->program_buffer, 0, sizeof(sfdev->program_buffer));
> >>> + sfdev->last_address = ~0ULL;
> >>> + sfdev->buff_written = 0;
> >>> +}
> >>> +
> >>> +static bool buffer_program(struct cfi_flash_device *sfdev,
> >>> + u64 addr, void *buffer, int len)
> >>> +{
> >>> + unsigned int buf_addr;
> >>> +
> >>> + if (sfdev->buff_written >= sfdev->program_length)
> >>> + return false;
> >>> +
> >>> + /*
> >>> + * The first word written into the buffer after the setup command
> >>> + * happens to be the base address for the buffer.
> >>> + * All subsequent writes need to be within this address and this
> >>> + * address plus the buffer size, so keep this value around.
> >>> + */
> >>> + if (sfdev->last_address == ~0ULL)
> >>> + sfdev->last_address = addr;
> >>> +
> >>> + if (addr < sfdev->last_address)
> >>> + return false;
> >>> + buf_addr = addr - sfdev->last_address;
> >>> + if (buf_addr >= PROGRAM_BUFF_SIZE)
> >>> + return false;
> >>> +
> >>> + memcpy(sfdev->program_buffer + buf_addr, buffer, len);
> >>> + sfdev->buff_written++;
> >>> +
> >>> + return true;
> >>> +}
> >>> +
> >>> +static void buffer_confirm(struct cfi_flash_device *sfdev)
> >>> +{
> >>> + if (block_is_locked(sfdev, sfdev->last_address)) {
> >>> + sfdev->sr |= 0x12;
> >>> + return;
> >>> + }
> >>> + memcpy(sfdev->flash_memory + sfdev->last_address,
> >>> + sfdev->program_buffer,
> >>> + sfdev->buff_written * sizeof(u32));
> >>> +}
> >>> +
> >>> +static void block_erase_confirm(struct cfi_flash_device *sfdev, u64 addr)
> >>> +{
> >>> + if (block_is_locked(sfdev, addr)) {
> >>> + sfdev->sr |= 0x12;
> >>> + return;
> >>> + }
> >>> +
> >>> + memset(sfdev->flash_memory + addr, 0xFF, FLASH_BLOCK_SIZE);
> >>> +}
> >>> +
> >>> +static void cfi_flash_mmio(struct kvm_cpu *vcpu,
> >>> + u64 addr, u8 *data, u32 len, u8 is_write,
> >>> + void *context)
> >>> +{
> >>> + struct cfi_flash_device *sfdev = context;
> >>> + u64 faddr = addr - sfdev->base_addr;
> >>> + u32 value;
> >>> +
> >>> + if (!is_write) {
> >>> + u16 cfi_value = 0;
> >>> +
> >>> + mutex_lock(&sfdev->mutex);
> >>> +
> >>> + switch (sfdev->read_mode) {
> >>> + case READ_ARRAY:
> >>> + /* just copy the requested bytes from the array */
> >>> + memcpy(data, sfdev->flash_memory + faddr, len);
> >>> + goto out_unlock;
> >>> + case READ_STATUS:
> >>> + cfi_value = sfdev->sr;
> >>> + break;
> >>> + case READ_DEVICE_ID:
> >>> + cfi_value = read_dev_id(sfdev, faddr);
> >>> + break;
> >>> + case READ_QUERY:
> >>> + cfi_value = read_cfi(sfdev, faddr / CFI_BUS_WIDTH);
> >>> + break;
> >>> + }
> >>> + switch (len) {
> >>> + case 1:
> >>> + *data = cfi_value;
> >>> + break;
> >>> + case 8: memset(data + 4, 0, 4);
> >>> + /* fall-through */
> >>> + case 4:
> >>> + if (CFI_NR_FLASH_CHIPS == 2)
> >>> + memcpy(data + 2, &cfi_value, 2);
> >>> + else
> >>> + memset(data + 2, 0, 2);
> >>> + /* fall-through */
> >>> + case 2:
> >>> + memcpy(data, &cfi_value, 2);
> >>> + break;
> >>> + default:
> >>> + pr_debug("CFI flash: illegal access length %d for read mode %d",
> >>> + len, sfdev->read_mode);
> >>> + break;
> >>> + }
> >>> +
> >>> + goto out_unlock;
> >>> + }
> >>> +
> >>> + if (len > 4) {
> >>> + pr_info("CFI flash: MMIO %d-bit write access not supported",
> >>> + len * 8);
> >>> + return;
> >>> + }
> >>> +
> >>> + memcpy(&value, data, len);
> >>> +
> >>> + mutex_lock(&sfdev->mutex);
> >>> +
> >>> + switch (sfdev->state) {
> >>> + case READY: /* handled below */
> >>> + break;
> >>> +
> >>> + case LOCK_SETUP:
> >>> + switch (value & 0xff) {
> >>> + case CFI_CMD_LOCK_BLOCK:
> >>> + lock_block(sfdev, faddr, true);
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + case CFI_CMD_UNLOCK_BLOCK:
> >>> + lock_block(sfdev, faddr, false);
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + default:
> >>> + sfdev->sr |= 0x30;
> >>> + break;
> >>> + }
> >>> + sfdev->state = READY;
> >>> + goto out_unlock;
> >>> +
> >>> + case WP_SETUP:
> >>> + word_program(sfdev, faddr, data, len);
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + sfdev->state = READY;
> >>> + goto out_unlock;
> >>> +
> >>> + case BP_LOAD:
> >>> + if (buffer_program(sfdev, faddr, data, len))
> >>> + goto out_unlock;
> >>> +
> >>> + if ((value & 0xFF) == CFI_CMD_BUFFERED_PROGRAM_CONFIRM) {
> >>> + buffer_confirm(sfdev);
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + } else {
> >>> + pr_debug("CFI flash: BP_LOAD: expected CONFIRM(0xd0), got 0x%x @ 0x%llx",
> >>> + value, faddr);
> >>> + sfdev->sr |= 0x10;
> >>> + }
> >>> + sfdev->state = READY;
> >>> + goto out_unlock;
> >>> +
> >>> + case BP_SETUP:
> >>> + sfdev->program_length = (value & 0xffff) + 1;
> >>> + if (sfdev->program_length > PROGRAM_BUFF_SIZE / 4)
> >>> + sfdev->program_length = PROGRAM_BUFF_SIZE / 4;
> >>> + sfdev->state = BP_LOAD;
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + goto out_unlock;
> >>> +
> >>> + case ERASE_SETUP:
> >>> + if ((value & 0xff) == CFI_CMD_BLOCK_ERASE_CONFIRM)
> >>> + block_erase_confirm(sfdev, faddr);
> >>> + else
> >>> + sfdev->sr |= 0x30;
> >>> +
> >>> + sfdev->state = READY;
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + goto out_unlock;
> >>> + }
> >>> +
> >>> + /* write commands in READY state */
> >>> + switch (value & 0xFF) {
> >>> + case CFI_CMD_READ_JEDEC:
> >>> + sfdev->read_mode = READ_DEVICE_ID;
> >>> + break;
> >>> + case CFI_CMD_READ_STATUS_REGISTER:
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + case CFI_CMD_READ_CFI_QUERY:
> >>> + sfdev->read_mode = READ_QUERY;
> >>> + break;
> >>> + case CFI_CMD_CLEAR_STATUS_REGISTER:
> >>> + sfdev->sr = 0x80;
> >>> + break;
> >>> + case CFI_CMD_WORD_PROGRAM_SETUP:
> >>> + case CFI_CMD_ALTERNATE_WORD_PROGRAM_SETUP:
> >>> + sfdev->state = WP_SETUP;
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + case CFI_CMD_LOCK_BLOCK_SETUP:
> >>> + sfdev->state = LOCK_SETUP;
> >>> + break;
> >>> + case CFI_CMD_BLOCK_ERASE_SETUP:
> >>> + sfdev->state = ERASE_SETUP;
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + case CFI_CMD_BUFFERED_PROGRAM_SETUP:
> >>> + buffer_setup(sfdev);
> >>> + sfdev->state = BP_SETUP;
> >>> + sfdev->read_mode = READ_STATUS;
> >>> + break;
> >>> + case CFI_CMD_BUFFERED_PROGRAM_CONFIRM:
> >>> + pr_debug("CFI flash: unexpected confirm command 0xD0");
> >>> + break;
> >>> + default:
> >>> + pr_debug("CFI flash: unknown command 0x%x", value);
> >>> + /* fall through */
> >>> + case CFI_CMD_READ_ARRAY:
> >>> + sfdev->read_mode = READ_ARRAY;
> >>> + break;
> >>> + }
> >>> +
> >>> +out_unlock:
> >>> + mutex_unlock(&sfdev->mutex);
> >>> +}
> >>> +
> >>> +#ifdef CONFIG_HAS_LIBFDT
> >>> +static void generate_cfi_flash_fdt_node(void *fdt,
> >>> + struct device_header *dev_hdr,
> >>> + void (*generate_irq_prop)(void *fdt,
> >>> + u8 irq,
> >>> + enum irq_type))
> >>> +{
> >>> + struct cfi_flash_device *sfdev;
> >>> + u64 reg_prop[2];
> >>> +
> >>> + sfdev = container_of(dev_hdr, struct cfi_flash_device, dev_hdr);
> >>> + reg_prop[0] = cpu_to_fdt64(sfdev->base_addr);
> >>> + reg_prop[1] = cpu_to_fdt64(sfdev->size);
> >>> +
> >>> + _FDT(fdt_begin_node(fdt, "flash"));
> >>> + _FDT(fdt_property_cell(fdt, "bank-width", CFI_BUS_WIDTH));
> >>> + _FDT(fdt_property_cell(fdt, "#address-cells", 0x1));
> >>> + _FDT(fdt_property_cell(fdt, "#size-cells", 0x1));
> >>> + _FDT(fdt_property_string(fdt, "compatible", "cfi-flash"));
> >>> + _FDT(fdt_property_string(fdt, "label", "System-firmware"));
> >>> + _FDT(fdt_property(fdt, "reg", ®_prop, sizeof(reg_prop)));
> >>> + _FDT(fdt_end_node(fdt));
> >>> +}
> >>> +#else
> >>> +#define generate_cfi_flash_fdt_node NULL
> >>> +#endif
> >>> +
> >>> +static struct cfi_flash_device *create_flash_device_file(struct kvm *kvm,
> >>> + const char *filename)
> >>> +{
> >>> + struct cfi_flash_device *sfdev;
> >>> + struct stat statbuf;
> >>> + unsigned int value;
> >>> + int ret;
> >>> + int fd;
> >>> +
> >>> + fd = open(filename, O_RDWR);
> >>> + if (fd < 0)
> >>> + return ERR_PTR(-errno);
> >>> + if (fstat(fd, &statbuf) < 0) {
> >>> + close(fd);
> >>> + return ERR_PTR(-errno);
> >>> + }
> >>> +
> >>> + sfdev = malloc(sizeof(struct cfi_flash_device));
> >>> + if (!sfdev) {
> >>> + close(fd);
> >>> + return ERR_PTR(-ENOMEM);
> >>> + }
> >>> +
> >>> + sfdev->size = (statbuf.st_size + 4095) & ~0xfffUL;
> >>> + sfdev->flash_memory = mmap(NULL, statbuf.st_size,
> >>> + PROT_READ | PROT_WRITE, MAP_SHARED,
> >>> + fd, 0);
> >>> + if (sfdev->flash_memory == MAP_FAILED) {
> >>> + close(fd);
> >>> + free(sfdev);
> >>> + return ERR_PTR(-errno);
> >>> + }
> >>> + sfdev->base_addr = KVM_FLASH_MMIO_BASE;
> >>> + sfdev->state = READY;
> >>> + sfdev->read_mode = READ_ARRAY;
> >>> + sfdev->sr = 0x80;
> >>> + sfdev->rcr = 0xbfcf;
> >>> +
> >>> + value = roundup(nr_erase_blocks(sfdev), BITS_PER_LONG) / 8;
> >>> + sfdev->lock_bm = malloc(value);
> >>> + memset(sfdev->lock_bm, 0, value);
> >>> +
> >>> + sfdev->dev_hdr.bus_type = DEVICE_BUS_MMIO;
> >>> + sfdev->dev_hdr.data = generate_cfi_flash_fdt_node;
> >>> + mutex_init(&sfdev->mutex);
> >>> + ret = device__register(&sfdev->dev_hdr);
> >>> + if (ret) {
> >>> + free(sfdev->flash_memory);
> >>> + free(sfdev);
> >>> + return ERR_PTR(ret);
> >>> + }
> >>> +
> >>> + ret = kvm__register_mmio(kvm,
> >>> + sfdev->base_addr, sfdev->size,
> >>> + false, cfi_flash_mmio, sfdev);
> >>> + if (ret) {
> >>> + device__unregister(&sfdev->dev_hdr);
> >>> + free(sfdev->flash_memory);
> >>> + free(sfdev);
> >>> + return ERR_PTR(ret);
> >>> + }
> >>> +
> >>> + return sfdev;
> >>> +}
> >>> +
> >>> +static int flash__init(struct kvm *kvm)
> >>> +{
> >>> + struct cfi_flash_device *sfdev;
> >>> +
> >>> + if (!kvm->cfg.flash_filename)
> >>> + return 0;
> >>> +
> >>> + sfdev = create_flash_device_file(kvm, kvm->cfg.flash_filename);
> >>> + if (IS_ERR(sfdev))
> >>> + return PTR_ERR(sfdev);
> >>> +
> >>> + return 0;
> >>> +}
> >>> +dev_init(flash__init);
> >>> diff --git a/include/kvm/kvm-config.h b/include/kvm/kvm-config.h
> >>> index a052b0bc..f4a8b831 100644
> >>> --- a/include/kvm/kvm-config.h
> >>> +++ b/include/kvm/kvm-config.h
> >>> @@ -35,6 +35,7 @@ struct kvm_config {
> >>> const char *vmlinux_filename;
> >>> const char *initrd_filename;
> >>> const char *firmware_filename;
> >>> + const char *flash_filename;
> >>> const char *console;
> >>> const char *dev;
> >>> const char *network;
> >>> diff --git a/include/kvm/util.h b/include/kvm/util.h
> >>> index 4ca7aa93..5c37f0b7 100644
> >>> --- a/include/kvm/util.h
> >>> +++ b/include/kvm/util.h
> >>> @@ -104,6 +104,11 @@ static inline unsigned long roundup_pow_of_two(unsigned long x)
> >>> return x ? 1UL << fls_long(x - 1) : 0;
> >>> }
> >>>
> >>> +static inline int pow2_size(unsigned long x)
> >>> +{
> >>> + return (sizeof(x) * 8) - __builtin_clzl(x - 1);
> >>> +}
> >>> +
> >>> struct kvm;
> >>> void *mmap_hugetlbfs(struct kvm *kvm, const char *htlbfs_path, u64 size);
> >>> void *mmap_anon_or_hugetlbfs(struct kvm *kvm, const char *hugetlbfs_path, u64 size);
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* RE: [PATCH] usb: xhci: enable interrupt only after xhci_start()
From: Ajay Gupta @ 2020-02-20 18:01 UTC (permalink / raw)
To: Mathias Nyman, Ajay Gupta, mathias.nyman@intel.com
Cc: linux-usb@vger.kernel.org
In-Reply-To: <85ae3a52-f968-ce02-af51-e4d2aa140f8b@linux.intel.com>
Hi Mathias,
> On 19.2.2020 1.50, Ajay Gupta wrote:
> > From: Ajay Gupta <ajayg@nvidia.com>
> >
> > Xhci interrupt must be enabled only after controller is initialized
> > and started. Currently interrupt is enabled first in xhci_run() and
> > later hcd state is set to running in xhci_run_finished().
> >
> > On a slow system (such as FPGA based platform) the time difference
> > between enabling interrupt and setting the hcd state becomes huge
> > enough where interrupt is triggered but controller initialization is
> > not complete yet.
> >
> > Fixing the same by moving the interrupt enable (CMD_EIE) part of code
> > snippet from xhci_run() to xhci_run_finished().
> >
> > Signed-off-by: Ajay Gupta <ajayg@nvidia.com>
> > ---
>
> Sounds reasonable, but xHCI specs wants interrupts set and enabled before
> xHC is running state.
>
> I see this can be an issue if we get a port event for a USB 3 port before the
> USB3 hcd is added.
> What kind of issues did you see? I'd guess NULL pointer dereference in
> handle_port_status()?.
We saw a kernel soft lockup with following dump when a FPGA based system
is booted with ASUS xHCI (Gen 2) PCIe card attached. It was seen with kernel
v4.9.
[ 6.110120] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 6.110602] ehci-pci: EHCI PCI platform driver
[ 6.112104] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 6.112586] ohci-pci: OHCI PCI platform driver
[ 6.113982] ohci-platform: OHCI generic platform driver
[ 6.117577] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 6.118022] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus numb1
[ 6.131674] xhci_hcd 0000:01:00.0: hcc params 0x0200eec1 hci version 0x110 q0
[ 6.134882] usb usb1: New USB device found, idVendor=1d6b, idProduct=0002
[ 6.135731] usb usb1: New USB device strings: Mfr=3, Product=2, SerialNumber1
[ 6.136172] usb usb1: Product: xHCI Host Controller
[ 6.136488] usb usb1: Manufacturer: Linux 4.9.38-tegra-g0177c0b-dirty xhci-hd
[ 6.136917] usb usb1: SerialNumber: 0000:01:00.0
[ 6.142334] hub 1-0:1.0: USB hub found
[ 6.142866] hub 1-0:1.0: 2 ports detected
[ 6.148110] xhci_hcd 0000:01:00.0: xHCI Host Controller
[ 6.148500] xhci_hcd 0000:01:00.0: new USB bus registered, assigned bus numb2
[ 6.156660] random: fast init done
[ 6.754981] random: crng init done
[ 27.147341] INFO: rcu_preempt self-detected stall on CPU
[ 27.147757] 0-...: (5250 ticks this GP) idle=1ed/140000000000002/0 softirq=
[ 27.148243] (t=5250 jiffies g=622 c=621 q=12)
[ 27.148618] rcu_preempt kthread starved for 5250 jiffies! g622 c621 f0x0 RCU1
[ 27.149158] rcu_preempt S 0 7 2 0x00000000
[ 27.149563] Call trace:
[ 27.149799] [<ffffff8008085790>] __switch_to+0x3c/0x48
[ 27.150149] [<ffffff8008ee6374>] __schedule+0x25c/0x744
[ 27.150479] [<ffffff8008ee6898>] schedule+0x3c/0xa0
[ 27.150808] [<ffffff8008ee9aa8>] schedule_timeout+0x18c/0x37c
[ 27.151186] [<ffffff800811d988>] rcu_gp_kthread+0x4d8/0x79c
[ 27.151571] [<ffffff80080cb1a0>] kthread+0xf0/0x104
[ 27.151888] [<ffffff8008082ad0>] ret_from_fork+0x10/0x40
[ 27.152272] Task dump for CPU 0:
[ 27.152497] swapper/0 R running task 0 1 0 0x00000002
[ 27.153020] Call trace:
[ 27.153224] [<ffffff8008089c5c>] dump_backtrace+0x0/0x16c
[ 27.153582] [<ffffff8008089f70>] show_stack+0x14/0x1c
[ 27.153914] [<ffffff800819bc94>] sched_show_task.part.135+0x6c/0x78
[ 27.154318] [<ffffff80080deb30>] dump_cpu_task+0x88/0xc8
[ 27.154667] [<ffffff800819c0d4>] rcu_dump_cpu_stacks+0xa4/0xec
[ 27.155036] [<ffffff800811aacc>] check_cpu_stall.isra.61+0x334/0x5c8
[ 27.155419] [<ffffff800811ad94>] __rcu_pending+0x34/0x18c
[ 27.155772] [<ffffff800811e040>] rcu_check_callbacks+0x104/0x2c4
[ 27.156166] [<ffffff8008123e60>] update_process_times+0x60/0xac
[ 27.156547] [<ffffff8008134f80>] tick_sched_timer+0x6c/0xec
[ 27.156911] [<ffffff80081246e0>] __hrtimer_run_queues+0xd4/0x330
[ 27.157291] [<ffffff80081253c8>] hrtimer_interrupt+0x9c/0x1e0
[ 27.157679] [<ffffff80089e2f10>] arch_timer_handler_phys+0x2c/0x38
[ 27.158069] [<ffffff8008113444>] handle_percpu_devid_irq+0x80/0x248
[ 27.158483] [<ffffff800810e304>] __handle_domain_irq+0x70/0xc4
[ 27.158848] [<ffffff8008080de4>] gic_handle_irq+0x50/0xa0
[ 27.159196] [<ffffff8008082198>] el1_irq+0xd8/0x168
[ 27.159530] [<ffffff80080adf18>] irq_exit+0xbc/0xe8
[ 27.159850] [<ffffff800810e308>] __handle_domain_irq+0x74/0xc4
[ 27.160213] [<ffffff8008080de4>] gic_handle_irq+0x50/0xa0
[ 27.160560] [<ffffff8008082198>] el1_irq+0xd8/0x168
[ 27.160897] [<ffffff80088bca88>] xhci_handshake+0x38/0x90
[ 27.161250] [<ffffff80088bd3cc>] xhci_run+0x300/0x534
[ 27.161574] [<ffffff8008888ef8>] usb_add_hcd+0x2f0/0x868
[ 27.161929] [<ffffff80088d2598>] xhci_pci_probe+0x120/0x224
[ 27.162300] [<ffffff80084c1f10>] pci_device_probe+0x98/0x10c
[ 27.162671] [<ffffff8008655740>] driver_probe_device+0x29c/0x438
[ 27.163044] [<ffffff80086559ec>] __driver_attach+0x110/0x114
[ 27.163445] [<ffffff8008653038>] bus_for_each_dev+0x64/0xb4
[ 27.163801] [<ffffff8008654f9c>] driver_attach+0x20/0x28
[ 27.164147] [<ffffff8008654a74>] bus_add_driver+0x23c/0x2a8
[ 27.164506] [<ffffff80086569b0>] driver_register+0x74/0x10c
[ 27.164862] [<ffffff80084c0c44>] __pci_register_driver+0x44/0x4c
[ 27.165252] [<ffffff8009530614>] xhci_pci_init+0x54/0x60
[ 27.165601] [<ffffff80080831b4>] do_one_initcall+0x48/0x150
[ 27.165997] [<ffffff80094f0e54>] kernel_init_freeable+0x1d0/0x284
[ 27.166400] [<ffffff8008ee27f8>] kernel_init+0x10/0xfc
[ 27.166723] [<ffffff8008082ad0>] ret_from_fork+0x10/0x40
> We could move interrupt enabling to xhci_run_finished() before
> xhci_start() is called, then the USB3 hcd should be initialized before we receive
> interrupts.
> Does that work for you?
Let me check if I can find the system and test it.
Thanks
>nvpublic
>
> Details:
> xHCI section 4.2 "Host Controller Initialization" has the following sequence:
>
> - Enable host system interrupt (CMD_EIE),
> - Enable primary interupter (set IE bit in IMAN register)
> - set run bit in USBCMD register.
>
> And section 5.5.2 has a note:
>
> "All registers of the Primary Interrupter shall be initialized before setting the
> Run/Stop (RS) flag in the USBCMD register to ‘1’."
>
> -Mathias
^ permalink raw reply
* [PATCH] drm/msm/a6xx: Fix CP_MEMPOOL state name
From: Rob Clark @ 2020-02-20 18:00 UTC (permalink / raw)
To: dri-devel
Cc: Rob Clark, open list:DRM DRIVER FOR MSM ADRENO GPU, David Airlie,
open list:DRM DRIVER FOR MSM ADRENO GPU, open list, Sean Paul
From: Rob Clark <robdclark@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
index 68cccfa2870a..bbbec8d26870 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
@@ -370,7 +370,7 @@ static const struct a6xx_indexed_registers {
};
static const struct a6xx_indexed_registers a6xx_cp_mempool_indexed = {
- "CP_MEMPOOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
+ "CP_MEMPOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
REG_A6XX_CP_MEM_POOL_DBG_DATA, 0x2060,
};
--
2.24.1
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply related
* [PATCH] drm/msm/a6xx: Fix CP_MEMPOOL state name
From: Rob Clark @ 2020-02-20 18:00 UTC (permalink / raw)
To: dri-devel
Cc: Rob Clark, Rob Clark, Sean Paul, David Airlie, Daniel Vetter,
open list:DRM DRIVER FOR MSM ADRENO GPU,
open list:DRM DRIVER FOR MSM ADRENO GPU, open list
From: Rob Clark <robdclark@chromium.org>
Signed-off-by: Rob Clark <robdclark@chromium.org>
---
drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
index 68cccfa2870a..bbbec8d26870 100644
--- a/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
+++ b/drivers/gpu/drm/msm/adreno/a6xx_gpu_state.h
@@ -370,7 +370,7 @@ static const struct a6xx_indexed_registers {
};
static const struct a6xx_indexed_registers a6xx_cp_mempool_indexed = {
- "CP_MEMPOOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
+ "CP_MEMPOOL", REG_A6XX_CP_MEM_POOL_DBG_ADDR,
REG_A6XX_CP_MEM_POOL_DBG_DATA, 0x2060,
};
--
2.24.1
^ permalink raw reply related
* Re: [PATCH][net-next] net: neigh: remove unused NEIGH_SYSCTL_MS_JIFFIES_ENTRY
From: David Miller @ 2020-02-20 18:02 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1582181342-6498-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Thu, 20 Feb 2020 14:49:02 +0800
> this macro is never used, so remove it
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH][net-next] net: remove unused macro from fib_trie.c
From: David Miller @ 2020-02-20 18:02 UTC (permalink / raw)
To: lirongqing; +Cc: netdev
In-Reply-To: <1582181419-25079-1-git-send-email-lirongqing@baidu.com>
From: Li RongQing <lirongqing@baidu.com>
Date: Thu, 20 Feb 2020 14:50:19 +0800
> TNODE_KMALLOC_MAX and VERSION are not used, so remove them
>
> Signed-off-by: Li RongQing <lirongqing@baidu.com>
Applied.
^ permalink raw reply
* Re: [PATCH RFC] mmc: sdhci-msm: Toggle fifo write clk after ungating sdcc clk
From: Stephen Boyd @ 2020-02-20 18:02 UTC (permalink / raw)
To: Sayali Lokhande, adrian.hunter, asutoshd, bjorn.andersson,
georgi.djakov, mka, ppvk, rampraka, robh+dt, stummala,
ulf.hansson, vbadigan
Cc: linux-mmc, linux-kernel, linux-arm-msm, devicetree, agross,
linux-mmc-owner, Sayali Lokhande
In-Reply-To: <1582190446-4778-2-git-send-email-sayalil@codeaurora.org>
Quoting Sayali Lokhande (2020-02-20 01:20:46)
> From: Ram Prakash Gupta <rampraka@codeaurora.org>
>
> During GCC level clock gating of MCLK, the async FIFO
Is this automatic hardware clock gating?
> gets into some hang condition, such that for the next
> transfer after MCLK ungating, first bit of CMD response
> doesn't get written in to the FIFO. This cause the CPSM
> to hang eventually leading to SW timeout.
>
> To fix the issue, toggle the FIFO write clock after
> MCLK ungated to get the FIFO pointers and flags to
> valid states.
>
> Change-Id: Ibef2d1d283ac0b6983c609a4abc98bc574d31fa6
> Signed-off-by: Ram Prakash Gupta <rampraka@codeaurora.org>
> Signed-off-by: Sayali Lokhande <sayalil@codeaurora.org>
> ---
> drivers/mmc/host/sdhci-msm.c | 43 +++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 43 insertions(+)
>
> diff --git a/drivers/mmc/host/sdhci-msm.c b/drivers/mmc/host/sdhci-msm.c
> index c3a160c..eaa3e95 100644
> --- a/drivers/mmc/host/sdhci-msm.c
> +++ b/drivers/mmc/host/sdhci-msm.c
> @@ -1554,6 +1556,43 @@ static void __sdhci_msm_set_clock(struct sdhci_host *host, unsigned int clock)
> sdhci_enable_clk(host, clk);
> }
>
> +/*
> + * After MCLK ugating, toggle the FIFO write clock to get
What is ugating?
> + * the FIFO pointers and flags to valid state.
> + */
> +static void sdhci_msm_toggle_fifo_write_clk(struct sdhci_host *host)
> +{
> + struct sdhci_pltfm_host *pltfm_host = sdhci_priv(host);
> + struct sdhci_msm_host *msm_host = sdhci_pltfm_priv(pltfm_host);
> + const struct sdhci_msm_offset *msm_offset =
> + msm_host->offset;
> + struct mmc_card *card = host->mmc->card;
> +
> + if (msm_host->tuning_done ||
> + (card && card->ext_csd.strobe_support &&
> + card->host->ios.enhanced_strobe)) {
> + /*
> + * set HC_REG_DLL_CONFIG_3[1] to select MCLK as
> + * DLL input clock
> + */
^ permalink raw reply
* Re: [yocto] [psplash][PATCH 1/1] psplash-fb: Avoid racing issues on reading fb0
From: Khem Raj @ 2020-02-20 18:03 UTC (permalink / raw)
To: Andrei Gherzan; +Cc: yocto
In-Reply-To: <CAK18fxGX5O-yKSJPfFhsAahpowJVMbNmY_9waMxVjOKTFLeGoA@mail.gmail.com>
On 2/20/20 9:58 AM, Andrei Gherzan wrote:
> Hi,
>
> On Fri, Feb 14, 2020 at 7:32 AM Khem Raj <raj.khem@gmail.com
> <mailto:raj.khem@gmail.com>> wrote:
>
> On 2/13/20 2:30 AM, Andrei Gherzan wrote:
> > When starting psplash as early as possible in the boot process,
> the fb
> > device node might not be ready. This patch adds a loop on reading the
> > fb0 device with a timeout of 5 seconds.
> >
> > Signed-off-by: Andrei Gherzan <andrei@gherzan.ro
> <mailto:andrei@gherzan.ro>>
> > ---
> > psplash-fb.c | 5 ++++-
> > 1 file changed, 4 insertions(+), 1 deletion(-)
> >
> > diff --git a/psplash-fb.c b/psplash-fb.c
> > index 6603572..6700a3b 100644
> > --- a/psplash-fb.c
> > +++ b/psplash-fb.c
> > @@ -137,6 +137,7 @@ psplash_fb_new (int angle, int fbdev_id)
> > struct fb_fix_screeninfo fb_fix;
> > int off;
> > char fbdev[9] = "/dev/fb0";
> > + int retries = 0;
> >
> > PSplashFB *fb = NULL;
> >
> > @@ -156,7 +157,9 @@ psplash_fb_new (int angle, int fbdev_id)
> >
> > fb->fd = -1;
> >
> > - if ((fb->fd = open (fbdev, O_RDWR)) < 0)
> > + while ((fb->fd = open(fbdev, O_RDWR)) < 0 && retries++ <= 100)
> > + usleep(50000);
> > + if (fb->fd < 0)
>
> i wonder if there should be a different way to ensure this dependency
> perhaps sd_notify for systemd or udev notification maybe ..
>
>
> That makes sense. The only issue is that in my use-case, initramfs
> doesn't have systemd. And usually, you will be wanting to run a splash
> way before any init system. What is your proposal with udev
> notifications? Can you expand that?
>
something like
https://www.tecmint.com/udev-for-device-detection-management-in-linux/
> Regards,
> Andrei
^ permalink raw reply
* [PATCH] dm-integrity: Prevent RMW for full tag area writes
From: Lukas Straub @ 2020-02-20 18:04 UTC (permalink / raw)
To: linux-kernel; +Cc: Alasdair Kergon, Mike Snitzer, dm-devel
If a full tag area is being written, don't read it first. This prevents a
read-modify-write cycle and increases performance on HDDs considerably.
To do this we now calculate the checksums for all sectors in the bio in one
go in integrity_metadata and then pass the result to dm_integrity_rw_tag,
which now checks if we overwrite the whole tag area.
Benchmarking with a 5400RPM HDD with bitmap mode:
integritysetup format --no-wipe --batch-mode --interleave-sectors $((64*1024)) -t 4 -s 512 -I crc32c -B /dev/sdc
integritysetup open -I crc32c -B /dev/sdc hdda_integ
dd if=/dev/zero of=/dev/mapper/hdda_integ bs=64K count=$((16*1024*4)) conv=fsync oflag=direct status=progress
Without patch:
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 400.326 s, 10.7 MB/s
With patch:
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 41.2057 s, 104 MB/s
Signed-off-by: Lukas Straub <lukasstraub2@web.de>
---
drivers/md/dm-integrity.c | 80 ++++++++++++++++++++++-----------------
1 file changed, 46 insertions(+), 34 deletions(-)
diff --git a/drivers/md/dm-integrity.c b/drivers/md/dm-integrity.c
index b225b3e445fa..0e5ddcf44935 100644
--- a/drivers/md/dm-integrity.c
+++ b/drivers/md/dm-integrity.c
@@ -1309,9 +1309,16 @@ static int dm_integrity_rw_tag(struct dm_integrity_c *ic, unsigned char *tag, se
if (unlikely(r))
return r;
- data = dm_bufio_read(ic->bufio, *metadata_block, &b);
- if (IS_ERR(data))
- return PTR_ERR(data);
+ /* Don't read tag area from disk if we're going to overwrite it completely */
+ if (op == TAG_WRITE && *metadata_offset == 0 && total_size >= ic->metadata_run) {
+ data = dm_bufio_new(ic->bufio, *metadata_block, &b);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+ } else {
+ data = dm_bufio_read(ic->bufio, *metadata_block, &b);
+ if (IS_ERR(data))
+ return PTR_ERR(data);
+ }
to_copy = min((1U << SECTOR_SHIFT << ic->log2_buffer_sectors) - *metadata_offset, total_size);
dp = data + *metadata_offset;
@@ -1514,6 +1521,8 @@ static void integrity_metadata(struct work_struct *w)
{
struct dm_integrity_io *dio = container_of(w, struct dm_integrity_io, work);
struct dm_integrity_c *ic = dio->ic;
+ unsigned sectors_to_process = dio->range.n_sectors;
+ sector_t sector = dio->range.logical_sector;
int r;
@@ -1522,16 +1531,14 @@ static void integrity_metadata(struct work_struct *w)
struct bio_vec bv;
unsigned digest_size = crypto_shash_digestsize(ic->internal_hash);
struct bio *bio = dm_bio_from_per_bio_data(dio, sizeof(struct dm_integrity_io));
- char *checksums;
+ char *checksums, *checksums_ptr;
unsigned extra_space = unlikely(digest_size > ic->tag_size) ? digest_size - ic->tag_size : 0;
char checksums_onstack[HASH_MAX_DIGESTSIZE];
- unsigned sectors_to_process = dio->range.n_sectors;
- sector_t sector = dio->range.logical_sector;
if (unlikely(ic->mode == 'R'))
goto skip_io;
- checksums = kmalloc((PAGE_SIZE >> SECTOR_SHIFT >> ic->sb->log2_sectors_per_block) * ic->tag_size + extra_space,
+ checksums = kmalloc((dio->range.n_sectors >> ic->sb->log2_sectors_per_block) * ic->tag_size + extra_space,
GFP_NOIO | __GFP_NORETRY | __GFP_NOWARN);
if (!checksums) {
checksums = checksums_onstack;
@@ -1542,49 +1549,45 @@ static void integrity_metadata(struct work_struct *w)
}
}
+ checksums_ptr = checksums;
__bio_for_each_segment(bv, bio, iter, dio->orig_bi_iter) {
unsigned pos;
- char *mem, *checksums_ptr;
-
-again:
+ char *mem;
mem = (char *)kmap_atomic(bv.bv_page) + bv.bv_offset;
pos = 0;
- checksums_ptr = checksums;
do {
integrity_sector_checksum(ic, sector, mem + pos, checksums_ptr);
- checksums_ptr += ic->tag_size;
- sectors_to_process -= ic->sectors_per_block;
+
+ if (likely(checksums != checksums_onstack)) {
+ checksums_ptr += ic->tag_size;
+ } else {
+ r = dm_integrity_rw_tag(ic, checksums, &dio->metadata_block, &dio->metadata_offset,
+ ic->tag_size, !dio->write ? TAG_CMP : TAG_WRITE);
+ if (unlikely(r))
+ goto internal_hash_error;
+ }
+
pos += ic->sectors_per_block << SECTOR_SHIFT;
sector += ic->sectors_per_block;
- } while (pos < bv.bv_len && sectors_to_process && checksums != checksums_onstack);
+ sectors_to_process -= ic->sectors_per_block;
+ } while (pos < bv.bv_len && sectors_to_process);
kunmap_atomic(mem);
- r = dm_integrity_rw_tag(ic, checksums, &dio->metadata_block, &dio->metadata_offset,
- checksums_ptr - checksums, !dio->write ? TAG_CMP : TAG_WRITE);
- if (unlikely(r)) {
- if (r > 0) {
- DMERR_LIMIT("Checksum failed at sector 0x%llx",
- (unsigned long long)(sector - ((r + ic->tag_size - 1) / ic->tag_size)));
- r = -EILSEQ;
- atomic64_inc(&ic->number_of_mismatches);
- }
- if (likely(checksums != checksums_onstack))
- kfree(checksums);
- goto error;
- }
-
if (!sectors_to_process)
break;
+ }
- if (unlikely(pos < bv.bv_len)) {
- bv.bv_offset += pos;
- bv.bv_len -= pos;
- goto again;
+ if (likely(checksums != checksums_onstack)) {
+ r = dm_integrity_rw_tag(ic, checksums, &dio->metadata_block, &dio->metadata_offset,
+ (dio->range.n_sectors >> ic->sb->log2_sectors_per_block) * ic->tag_size,
+ !dio->write ? TAG_CMP : TAG_WRITE);
+ if (unlikely(r)) {
+ kfree(checksums);
+ goto internal_hash_error;
}
+ kfree(checksums);
}
- if (likely(checksums != checksums_onstack))
- kfree(checksums);
} else {
struct bio_integrity_payload *bip = dio->orig_bi_integrity;
@@ -1615,6 +1618,13 @@ static void integrity_metadata(struct work_struct *w)
skip_io:
dec_in_flight(dio);
return;
+internal_hash_error:
+ if (r > 0) {
+ DMERR_LIMIT("Checksum failed at sector 0x%llx",
+ (unsigned long long)(sector - ((r + ic->tag_size - 1) / ic->tag_size)));
+ r = -EILSEQ;
+ atomic64_inc(&ic->number_of_mismatches);
+ }
error:
dio->bi_status = errno_to_blk_status(r);
dec_in_flight(dio);
@@ -3019,6 +3029,8 @@ static void dm_integrity_io_hints(struct dm_target *ti, struct queue_limits *lim
limits->physical_block_size = ic->sectors_per_block << SECTOR_SHIFT;
blk_limits_io_min(limits, ic->sectors_per_block << SECTOR_SHIFT);
}
+
+ blk_limits_io_opt(limits, (1U << ic->sb->log2_interleave_sectors));
}
static void calculate_journal_section_size(struct dm_integrity_c *ic)
--
2.20.1
^ permalink raw reply related
* Re: [PATCH net-next 00/15] mlxsw: Preparation for RTNL removal
From: David Miller @ 2020-02-20 18:04 UTC (permalink / raw)
To: idosch; +Cc: netdev, jiri, mlxsw, idosch
In-Reply-To: <20200220070800.364235-1-idosch@idosch.org>
From: Ido Schimmel <idosch@idosch.org>
Date: Thu, 20 Feb 2020 09:07:45 +0200
> From: Ido Schimmel <idosch@mellanox.com>
>
> The driver currently acquires RTNL in its route insertion path, which
> contributes to very large control plane latencies. This patch set
> prepares mlxsw for RTNL removal from its route insertion path in a
> follow-up patch set.
>
> Patches #1-#2 protect shared resources - KVDL and counter pool - with
> their own locks. All allocations of these resources are currently
> performed under RTNL, so no locks were required.
>
> Patches #3-#7 ensure that updates to mirroring sessions only take place
> in case there are active mirroring sessions. This allows us to avoid
> taking RTNL when it is unnecessary, as updating of the mirroring
> sessions must be performed under RTNL for the time being.
>
> Patches #8-#10 replace the use of APIs that assume that RTNL is taken
> with their RCU counterparts. Specifically, patches #8 and #9 replace
> __in_dev_get_rtnl() with __in_dev_get_rcu() under RCU read-side critical
> section. Patch #10 replaces __dev_get_by_index() with
> dev_get_by_index_rcu().
>
> Patches #11-#15 perform small adjustments in the code to make it easier
> to later introduce a router lock instead of relying on RTNL.
Series applied, thanks!
^ permalink raw reply
* Re: [RFC PATCH 1/3] efi/x86: Use symbolic constants in PE header instead of bare numbers
From: Arvind Sankar @ 2020-02-20 18:04 UTC (permalink / raw)
To: Ard Biesheuvel
Cc: Arvind Sankar, linux-efi, Laszlo Ersek, Leif Lindholm,
Peter Jones, Matthew Garrett, Alexander Graf, Ilias Apalodimas,
Heinrich Schuchardt, Daniel Kiper, James Bottomley
In-Reply-To: <CAKv+Gu_QiXsJyR0X4au+r75DFoQmSUp38+J7BuD3HAH+rJ9gHQ@mail.gmail.com>
On Thu, Feb 20, 2020 at 06:32:39PM +0100, Ard Biesheuvel wrote:
> Another thing I wondered was whether we really need the .reloc
> section. We don't have one on ARM, and it works fine with the existing
> EDK2 loader.
> Peter: any idea whether the issue with .reloc you pointed out to me
> the other day still exists in EDK2 today?
commit 743628e868c5 ("x86, efi stub: Add .reloc section back into
image") says that
Some UEFI firmware will not load a .efi with a .reloc section
with a size of 0.
Is that the issue you're refering to? It is a bit odd, since we actually
leave base relocation table at a size of zero with an RVA of zero, so it
shouldn't even look at the .reloc section according to the spec. At
least current EKD2 code doesn't seem to -- I think it would even work if
you specify fewer tables than 6 so that the base relocation table is
missing altogether.
^ permalink raw reply
* Re: [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
From: Daniel Vetter @ 2020-02-20 18:04 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Christian König, intel-gfx, dri-devel,
moderated list:DMA BUFFER SHARING FRAMEWORK,
open list:DMA BUFFER SHARING FRAMEWORK
In-Reply-To: <ee929c93-c9d7-7243-810e-94c6f0fc64b0@shipmail.org>
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > <thomas_os@shipmail.org> wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > > > > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> > > > > > Implement the importer side of unpinned DMA-buf handling.
> > > > > >
> > > > > > v2: update page tables immediately
> > > > > >
> > > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
> > > > > > ++++++++++++++++++++-
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> > > > > > 2 files changed, 71 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > index 770baba621b3..48de7624d49c 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
> > > > > > drm_device *dev, struct dma_buf *dma_buf)
> > > > > > return ERR_PTR(ret);
> > > > > > }
> > > > > >
> > > > > > +/**
> > > > > > + * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
> > > > > > + *
> > > > > > + * @attach: the DMA-buf attachment
> > > > > > + *
> > > > > > + * Invalidate the DMA-buf attachment, making sure that
> > > > > > the we re-create the
> > > > > > + * mapping before the next use.
> > > > > > + */
> > > > > > +static void
> > > > > > +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> > > > > > +{
> > > > > > + struct drm_gem_object *obj = attach->importer_priv;
> > > > > > + struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
> > > > > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > > > > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > > > > > + struct ttm_operation_ctx ctx = { false, false };
> > > > > > + struct ttm_placement placement = {};
> > > > > > + struct amdgpu_vm_bo_base *bo_base;
> > > > > > + int r;
> > > > > > +
> > > > > > + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> > > > > > + return;
> > > > > > +
> > > > > > + r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
> > > > > > + if (r) {
> > > > > > + DRM_ERROR("Failed to invalidate DMA-buf
> > > > > > import (%d))\n", r);
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> > > > > > + struct amdgpu_vm *vm = bo_base->vm;
> > > > > > + struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
> > > > > > +
> > > > > > + if (ticket) {
> > > > > Yeah so this is kinda why I've been a total pain about the
> > > > > exact semantics
> > > > > of the move_notify hook. I think we should flat-out require
> > > > > that importers
> > > > > _always_ have a ticket attach when they call this, and that
> > > > > they can cope
> > > > > with additional locks being taken (i.e. full EDEADLCK) handling.
> > > > >
> > > > > Simplest way to force that contract is to add a dummy 2nd
> > > > > ww_mutex lock to
> > > > > the dma_resv object, which we then can take #ifdef
> > > > > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> > > > >
> > > > > Now the real disaster is how we handle deadlocks. Two issues:
> > > > >
> > > > > - Ideally we'd keep any lock we've taken locked until the
> > > > > end, it helps
> > > > > needless backoffs. I've played around a bit with that
> > > > > but not even poc
> > > > > level, just an idea:
> > > > >
> > > > > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> > > > >
> > > > >
> > > > > Idea is essentially to track a list of objects we had to
> > > > > lock as part of
> > > > > the ttm_bo_validate of the main object.
> > > > >
> > > > > - Second one is if we get a EDEADLCK on one of these
> > > > > sublocks (like the
> > > > > one here). We need to pass that up the entire callchain,
> > > > > including a
> > > > > temporary reference (we have to drop locks to do the
> > > > > ww_mutex_lock_slow
> > > > > call), and need a custom callback to drop that temporary reference
> > > > > (since that's all driver specific, might even be
> > > > > internal ww_mutex and
> > > > > not anything remotely looking like a normal dma_buf).
> > > > > This probably
> > > > > needs the exec util helpers from ttm, but at the
> > > > > dma_resv level, so that
> > > > > we can do something like this:
> > > > >
> > > > > struct dma_resv_ticket {
> > > > > struct ww_acquire_ctx base;
> > > > >
> > > > > /* can be set by anyone (including other drivers)
> > > > > that got hold of
> > > > > * this ticket and had to acquire some new lock. This
> > > > > lock might
> > > > > * protect anything, including driver-internal stuff, and isn't
> > > > > * required to be a dma_buf or even just a dma_resv. */
> > > > > struct ww_mutex *contended_lock;
> > > > >
> > > > > /* callback which the driver (which might be a dma-buf exporter
> > > > > * and not matching the driver that started this
> > > > > locking ticket)
> > > > > * sets together with @contended_lock, for the main
> > > > > driver to drop
> > > > > * when it calls dma_resv_unlock on the contended_lock. */
> > > > > void (drop_ref*)(struct ww_mutex *contended_lock);
> > > > > };
> > > > >
> > > > > This is all supremely nasty (also ttm_bo_validate would need to be
> > > > > improved to handle these sublocks and random new objects
> > > > > that could force
> > > > > a ww_mutex_lock_slow).
> > > > >
> > > > Just a short comment on this:
> > > >
> > > > Neither the currently used wait-die or the wound-wait algorithm
> > > > *strictly* requires a slow lock on the contended lock. For
> > > > wait-die it's
> > > > just very convenient since it makes us sleep instead of spinning with
> > > > -EDEADLK on the contended lock. For wound-wait IIRC one could just
> > > > immediately restart the whole locking transaction after an
> > > > -EDEADLK, and
> > > > the transaction would automatically end up waiting on the contended
> > > > lock, provided the mutex lock stealing is not allowed. There is however
> > > > a possibility that the transaction will be wounded again on another
> > > > lock, taken before the contended lock, but I think there are ways to
> > > > improve the wound-wait algorithm to reduce that probability.
> > > >
> > > > So in short, choosing the wound-wait algorithm instead of wait-die and
> > > > perhaps modifying the ww mutex code somewhat would probably help
> > > > passing
> > > > an -EDEADLK up the call chain without requiring passing the contended
> > > > lock, as long as each locker releases its own locks when receiving an
> > > > -EDEADLK.
> > > Hm this is kinda tempting, since rolling out the full backoff tricker
> > > across driver boundaries is going to be real painful.
> > >
> > > What I'm kinda worried about is the debug/validation checks we're
> > > losing with this. The required backoff has this nice property that
> > > ww_mutex debug code can check that we've fully unwound everything when
> > > we should, that we've blocked on the right lock, and that we're
> > > restarting everything without keeling over. Without that I think we
> > > could end up with situations where a driver in the middle feels like
> > > handling the EDEADLCK, which might go well most of the times (the
> > > deadlock will probably be mostly within a given driver, not across).
> > > Right up to the point where someone creates a deadlock across drivers,
> > > and the lack of full rollback will be felt.
> > >
> > > So not sure whether we can still keep all these debug/validation
> > > checks, or whether this is a step too far towards clever tricks.
> >
> > I think we could definitely find a way to keep debugging to make sure
> > everything is unwound before attempting to restart the locking
> > transaction. But the debug check that we're restarting on the contended
> > lock only really makes sense for wait-die, (and we could easily keep it
> > for wait-die). The lock returning -EDEADLK for wound-wait may actually
> > not be the contending lock but an arbitrary lock that the wounded
> > transaction attempts to take after it is wounded.
> >
> > So in the end IMO this is a tradeoff between added (possibly severe)
> > locking complexity into dma-buf and not being able to switch back to
> > wait-die efficiently if we need / want to do that.
> >
> > /Thomas
>
> And as a consequence an interface *could* be:
>
> *) We introduce functions
>
> void ww_acquire_relax(struct ww_acquire_ctx *ctx);
> int ww_acquire_relax_interruptible(struct ww_acquire_ctx *ctx);
>
> that can be used instead of ww_mutex_lock_slow() in the absence of a
> contending lock to avoid spinning on -EDEADLK. While trying to take the
> contending lock is probably the best choice there are various second best
> approaches that can be explored, for example waiting on the contending
> acquire to finish or in the wound-wait case, perhaps do nothing. These
> functions will also help us keep the debugging.
Hm ... I guess this could work. Trouble is, it only gets rid of the
slowpath locking book-keeping headaches, we still have quite a few others.
> *) A function returning -EDEADLK to a caller *must* have already released
> its own locks.
So this ties to another question, as in should these callbacks have to
drops the locks thei acquire (much simpler code) or not (less thrashing,
if we drop locks we might end up in a situation where threads thrash
around instead of realizing quicker that they're actually deadlocking and
one of them should stop and back off).
But keeping locks locked means massive amounts of book-keeping in dma_resv
layer, so goes all downhill from there.
> *) move_notify() explicitly takes a struct ww_acquire_ctx * to make sure
> there is no ambiguity. (I think it would be valuable if we could do the same
> for ttm_bo_validate()).
Yeah I think more explicit locking ctx would be really good no matter
what. Implicitly fishing the acquire_ctx out of the lock for the object
you're called on is kinda nasty.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
From: Daniel Vetter @ 2020-02-20 18:04 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Daniel Vetter, Christian König,
moderated list:DMA BUFFER SHARING FRAMEWORK, intel-gfx, dri-devel,
open list:DMA BUFFER SHARING FRAMEWORK
In-Reply-To: <ee929c93-c9d7-7243-810e-94c6f0fc64b0@shipmail.org>
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > <thomas_os@shipmail.org> wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > > > > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> > > > > > Implement the importer side of unpinned DMA-buf handling.
> > > > > >
> > > > > > v2: update page tables immediately
> > > > > >
> > > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
> > > > > > ++++++++++++++++++++-
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> > > > > > 2 files changed, 71 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > index 770baba621b3..48de7624d49c 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
> > > > > > drm_device *dev, struct dma_buf *dma_buf)
> > > > > > return ERR_PTR(ret);
> > > > > > }
> > > > > >
> > > > > > +/**
> > > > > > + * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
> > > > > > + *
> > > > > > + * @attach: the DMA-buf attachment
> > > > > > + *
> > > > > > + * Invalidate the DMA-buf attachment, making sure that
> > > > > > the we re-create the
> > > > > > + * mapping before the next use.
> > > > > > + */
> > > > > > +static void
> > > > > > +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> > > > > > +{
> > > > > > + struct drm_gem_object *obj = attach->importer_priv;
> > > > > > + struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
> > > > > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > > > > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > > > > > + struct ttm_operation_ctx ctx = { false, false };
> > > > > > + struct ttm_placement placement = {};
> > > > > > + struct amdgpu_vm_bo_base *bo_base;
> > > > > > + int r;
> > > > > > +
> > > > > > + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> > > > > > + return;
> > > > > > +
> > > > > > + r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
> > > > > > + if (r) {
> > > > > > + DRM_ERROR("Failed to invalidate DMA-buf
> > > > > > import (%d))\n", r);
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> > > > > > + struct amdgpu_vm *vm = bo_base->vm;
> > > > > > + struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
> > > > > > +
> > > > > > + if (ticket) {
> > > > > Yeah so this is kinda why I've been a total pain about the
> > > > > exact semantics
> > > > > of the move_notify hook. I think we should flat-out require
> > > > > that importers
> > > > > _always_ have a ticket attach when they call this, and that
> > > > > they can cope
> > > > > with additional locks being taken (i.e. full EDEADLCK) handling.
> > > > >
> > > > > Simplest way to force that contract is to add a dummy 2nd
> > > > > ww_mutex lock to
> > > > > the dma_resv object, which we then can take #ifdef
> > > > > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> > > > >
> > > > > Now the real disaster is how we handle deadlocks. Two issues:
> > > > >
> > > > > - Ideally we'd keep any lock we've taken locked until the
> > > > > end, it helps
> > > > > needless backoffs. I've played around a bit with that
> > > > > but not even poc
> > > > > level, just an idea:
> > > > >
> > > > > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> > > > >
> > > > >
> > > > > Idea is essentially to track a list of objects we had to
> > > > > lock as part of
> > > > > the ttm_bo_validate of the main object.
> > > > >
> > > > > - Second one is if we get a EDEADLCK on one of these
> > > > > sublocks (like the
> > > > > one here). We need to pass that up the entire callchain,
> > > > > including a
> > > > > temporary reference (we have to drop locks to do the
> > > > > ww_mutex_lock_slow
> > > > > call), and need a custom callback to drop that temporary reference
> > > > > (since that's all driver specific, might even be
> > > > > internal ww_mutex and
> > > > > not anything remotely looking like a normal dma_buf).
> > > > > This probably
> > > > > needs the exec util helpers from ttm, but at the
> > > > > dma_resv level, so that
> > > > > we can do something like this:
> > > > >
> > > > > struct dma_resv_ticket {
> > > > > struct ww_acquire_ctx base;
> > > > >
> > > > > /* can be set by anyone (including other drivers)
> > > > > that got hold of
> > > > > * this ticket and had to acquire some new lock. This
> > > > > lock might
> > > > > * protect anything, including driver-internal stuff, and isn't
> > > > > * required to be a dma_buf or even just a dma_resv. */
> > > > > struct ww_mutex *contended_lock;
> > > > >
> > > > > /* callback which the driver (which might be a dma-buf exporter
> > > > > * and not matching the driver that started this
> > > > > locking ticket)
> > > > > * sets together with @contended_lock, for the main
> > > > > driver to drop
> > > > > * when it calls dma_resv_unlock on the contended_lock. */
> > > > > void (drop_ref*)(struct ww_mutex *contended_lock);
> > > > > };
> > > > >
> > > > > This is all supremely nasty (also ttm_bo_validate would need to be
> > > > > improved to handle these sublocks and random new objects
> > > > > that could force
> > > > > a ww_mutex_lock_slow).
> > > > >
> > > > Just a short comment on this:
> > > >
> > > > Neither the currently used wait-die or the wound-wait algorithm
> > > > *strictly* requires a slow lock on the contended lock. For
> > > > wait-die it's
> > > > just very convenient since it makes us sleep instead of spinning with
> > > > -EDEADLK on the contended lock. For wound-wait IIRC one could just
> > > > immediately restart the whole locking transaction after an
> > > > -EDEADLK, and
> > > > the transaction would automatically end up waiting on the contended
> > > > lock, provided the mutex lock stealing is not allowed. There is however
> > > > a possibility that the transaction will be wounded again on another
> > > > lock, taken before the contended lock, but I think there are ways to
> > > > improve the wound-wait algorithm to reduce that probability.
> > > >
> > > > So in short, choosing the wound-wait algorithm instead of wait-die and
> > > > perhaps modifying the ww mutex code somewhat would probably help
> > > > passing
> > > > an -EDEADLK up the call chain without requiring passing the contended
> > > > lock, as long as each locker releases its own locks when receiving an
> > > > -EDEADLK.
> > > Hm this is kinda tempting, since rolling out the full backoff tricker
> > > across driver boundaries is going to be real painful.
> > >
> > > What I'm kinda worried about is the debug/validation checks we're
> > > losing with this. The required backoff has this nice property that
> > > ww_mutex debug code can check that we've fully unwound everything when
> > > we should, that we've blocked on the right lock, and that we're
> > > restarting everything without keeling over. Without that I think we
> > > could end up with situations where a driver in the middle feels like
> > > handling the EDEADLCK, which might go well most of the times (the
> > > deadlock will probably be mostly within a given driver, not across).
> > > Right up to the point where someone creates a deadlock across drivers,
> > > and the lack of full rollback will be felt.
> > >
> > > So not sure whether we can still keep all these debug/validation
> > > checks, or whether this is a step too far towards clever tricks.
> >
> > I think we could definitely find a way to keep debugging to make sure
> > everything is unwound before attempting to restart the locking
> > transaction. But the debug check that we're restarting on the contended
> > lock only really makes sense for wait-die, (and we could easily keep it
> > for wait-die). The lock returning -EDEADLK for wound-wait may actually
> > not be the contending lock but an arbitrary lock that the wounded
> > transaction attempts to take after it is wounded.
> >
> > So in the end IMO this is a tradeoff between added (possibly severe)
> > locking complexity into dma-buf and not being able to switch back to
> > wait-die efficiently if we need / want to do that.
> >
> > /Thomas
>
> And as a consequence an interface *could* be:
>
> *) We introduce functions
>
> void ww_acquire_relax(struct ww_acquire_ctx *ctx);
> int ww_acquire_relax_interruptible(struct ww_acquire_ctx *ctx);
>
> that can be used instead of ww_mutex_lock_slow() in the absence of a
> contending lock to avoid spinning on -EDEADLK. While trying to take the
> contending lock is probably the best choice there are various second best
> approaches that can be explored, for example waiting on the contending
> acquire to finish or in the wound-wait case, perhaps do nothing. These
> functions will also help us keep the debugging.
Hm ... I guess this could work. Trouble is, it only gets rid of the
slowpath locking book-keeping headaches, we still have quite a few others.
> *) A function returning -EDEADLK to a caller *must* have already released
> its own locks.
So this ties to another question, as in should these callbacks have to
drops the locks thei acquire (much simpler code) or not (less thrashing,
if we drop locks we might end up in a situation where threads thrash
around instead of realizing quicker that they're actually deadlocking and
one of them should stop and back off).
But keeping locks locked means massive amounts of book-keeping in dma_resv
layer, so goes all downhill from there.
> *) move_notify() explicitly takes a struct ww_acquire_ctx * to make sure
> there is no ambiguity. (I think it would be valuable if we could do the same
> for ttm_bo_validate()).
Yeah I think more explicit locking ctx would be really good no matter
what. Implicitly fishing the acquire_ctx out of the lock for the object
you're called on is kinda nasty.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
^ permalink raw reply
* Re: [Intel-gfx] [PATCH 5/5] drm/amdgpu: implement amdgpu_gem_prime_move_notify v2
From: Daniel Vetter @ 2020-02-20 18:04 UTC (permalink / raw)
To: Thomas Hellström (VMware)
Cc: Christian König, intel-gfx, dri-devel,
moderated list:DMA BUFFER SHARING FRAMEWORK,
open list:DMA BUFFER SHARING FRAMEWORK
In-Reply-To: <ee929c93-c9d7-7243-810e-94c6f0fc64b0@shipmail.org>
On Thu, Feb 20, 2020 at 10:39:06AM +0100, Thomas Hellström (VMware) wrote:
> On 2/19/20 7:42 AM, Thomas Hellström (VMware) wrote:
> > On 2/18/20 10:01 PM, Daniel Vetter wrote:
> > > On Tue, Feb 18, 2020 at 9:17 PM Thomas Hellström (VMware)
> > > <thomas_os@shipmail.org> wrote:
> > > > On 2/17/20 6:55 PM, Daniel Vetter wrote:
> > > > > On Mon, Feb 17, 2020 at 04:45:09PM +0100, Christian König wrote:
> > > > > > Implement the importer side of unpinned DMA-buf handling.
> > > > > >
> > > > > > v2: update page tables immediately
> > > > > >
> > > > > > Signed-off-by: Christian König <christian.koenig@amd.com>
> > > > > > ---
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c | 66
> > > > > > ++++++++++++++++++++-
> > > > > > drivers/gpu/drm/amd/amdgpu/amdgpu_object.c | 6 ++
> > > > > > 2 files changed, 71 insertions(+), 1 deletion(-)
> > > > > >
> > > > > > diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > index 770baba621b3..48de7624d49c 100644
> > > > > > --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > +++ b/drivers/gpu/drm/amd/amdgpu/amdgpu_dma_buf.c
> > > > > > @@ -453,7 +453,71 @@ amdgpu_dma_buf_create_obj(struct
> > > > > > drm_device *dev, struct dma_buf *dma_buf)
> > > > > > return ERR_PTR(ret);
> > > > > > }
> > > > > >
> > > > > > +/**
> > > > > > + * amdgpu_dma_buf_move_notify - &attach.move_notify implementation
> > > > > > + *
> > > > > > + * @attach: the DMA-buf attachment
> > > > > > + *
> > > > > > + * Invalidate the DMA-buf attachment, making sure that
> > > > > > the we re-create the
> > > > > > + * mapping before the next use.
> > > > > > + */
> > > > > > +static void
> > > > > > +amdgpu_dma_buf_move_notify(struct dma_buf_attachment *attach)
> > > > > > +{
> > > > > > + struct drm_gem_object *obj = attach->importer_priv;
> > > > > > + struct ww_acquire_ctx *ticket = dma_resv_locking_ctx(obj->resv);
> > > > > > + struct amdgpu_bo *bo = gem_to_amdgpu_bo(obj);
> > > > > > + struct amdgpu_device *adev = amdgpu_ttm_adev(bo->tbo.bdev);
> > > > > > + struct ttm_operation_ctx ctx = { false, false };
> > > > > > + struct ttm_placement placement = {};
> > > > > > + struct amdgpu_vm_bo_base *bo_base;
> > > > > > + int r;
> > > > > > +
> > > > > > + if (bo->tbo.mem.mem_type == TTM_PL_SYSTEM)
> > > > > > + return;
> > > > > > +
> > > > > > + r = ttm_bo_validate(&bo->tbo, &placement, &ctx);
> > > > > > + if (r) {
> > > > > > + DRM_ERROR("Failed to invalidate DMA-buf
> > > > > > import (%d))\n", r);
> > > > > > + return;
> > > > > > + }
> > > > > > +
> > > > > > + for (bo_base = bo->vm_bo; bo_base; bo_base = bo_base->next) {
> > > > > > + struct amdgpu_vm *vm = bo_base->vm;
> > > > > > + struct dma_resv *resv = vm->root.base.bo->tbo.base.resv;
> > > > > > +
> > > > > > + if (ticket) {
> > > > > Yeah so this is kinda why I've been a total pain about the
> > > > > exact semantics
> > > > > of the move_notify hook. I think we should flat-out require
> > > > > that importers
> > > > > _always_ have a ticket attach when they call this, and that
> > > > > they can cope
> > > > > with additional locks being taken (i.e. full EDEADLCK) handling.
> > > > >
> > > > > Simplest way to force that contract is to add a dummy 2nd
> > > > > ww_mutex lock to
> > > > > the dma_resv object, which we then can take #ifdef
> > > > > CONFIG_WW_MUTEX_SLOWPATH_DEBUG. Plus mabye a WARN_ON(!ticket).
> > > > >
> > > > > Now the real disaster is how we handle deadlocks. Two issues:
> > > > >
> > > > > - Ideally we'd keep any lock we've taken locked until the
> > > > > end, it helps
> > > > > needless backoffs. I've played around a bit with that
> > > > > but not even poc
> > > > > level, just an idea:
> > > > >
> > > > > https://cgit.freedesktop.org/~danvet/drm/commit/?id=b1799c5a0f02df9e1bb08d27be37331255ab7582
> > > > >
> > > > >
> > > > > Idea is essentially to track a list of objects we had to
> > > > > lock as part of
> > > > > the ttm_bo_validate of the main object.
> > > > >
> > > > > - Second one is if we get a EDEADLCK on one of these
> > > > > sublocks (like the
> > > > > one here). We need to pass that up the entire callchain,
> > > > > including a
> > > > > temporary reference (we have to drop locks to do the
> > > > > ww_mutex_lock_slow
> > > > > call), and need a custom callback to drop that temporary reference
> > > > > (since that's all driver specific, might even be
> > > > > internal ww_mutex and
> > > > > not anything remotely looking like a normal dma_buf).
> > > > > This probably
> > > > > needs the exec util helpers from ttm, but at the
> > > > > dma_resv level, so that
> > > > > we can do something like this:
> > > > >
> > > > > struct dma_resv_ticket {
> > > > > struct ww_acquire_ctx base;
> > > > >
> > > > > /* can be set by anyone (including other drivers)
> > > > > that got hold of
> > > > > * this ticket and had to acquire some new lock. This
> > > > > lock might
> > > > > * protect anything, including driver-internal stuff, and isn't
> > > > > * required to be a dma_buf or even just a dma_resv. */
> > > > > struct ww_mutex *contended_lock;
> > > > >
> > > > > /* callback which the driver (which might be a dma-buf exporter
> > > > > * and not matching the driver that started this
> > > > > locking ticket)
> > > > > * sets together with @contended_lock, for the main
> > > > > driver to drop
> > > > > * when it calls dma_resv_unlock on the contended_lock. */
> > > > > void (drop_ref*)(struct ww_mutex *contended_lock);
> > > > > };
> > > > >
> > > > > This is all supremely nasty (also ttm_bo_validate would need to be
> > > > > improved to handle these sublocks and random new objects
> > > > > that could force
> > > > > a ww_mutex_lock_slow).
> > > > >
> > > > Just a short comment on this:
> > > >
> > > > Neither the currently used wait-die or the wound-wait algorithm
> > > > *strictly* requires a slow lock on the contended lock. For
> > > > wait-die it's
> > > > just very convenient since it makes us sleep instead of spinning with
> > > > -EDEADLK on the contended lock. For wound-wait IIRC one could just
> > > > immediately restart the whole locking transaction after an
> > > > -EDEADLK, and
> > > > the transaction would automatically end up waiting on the contended
> > > > lock, provided the mutex lock stealing is not allowed. There is however
> > > > a possibility that the transaction will be wounded again on another
> > > > lock, taken before the contended lock, but I think there are ways to
> > > > improve the wound-wait algorithm to reduce that probability.
> > > >
> > > > So in short, choosing the wound-wait algorithm instead of wait-die and
> > > > perhaps modifying the ww mutex code somewhat would probably help
> > > > passing
> > > > an -EDEADLK up the call chain without requiring passing the contended
> > > > lock, as long as each locker releases its own locks when receiving an
> > > > -EDEADLK.
> > > Hm this is kinda tempting, since rolling out the full backoff tricker
> > > across driver boundaries is going to be real painful.
> > >
> > > What I'm kinda worried about is the debug/validation checks we're
> > > losing with this. The required backoff has this nice property that
> > > ww_mutex debug code can check that we've fully unwound everything when
> > > we should, that we've blocked on the right lock, and that we're
> > > restarting everything without keeling over. Without that I think we
> > > could end up with situations where a driver in the middle feels like
> > > handling the EDEADLCK, which might go well most of the times (the
> > > deadlock will probably be mostly within a given driver, not across).
> > > Right up to the point where someone creates a deadlock across drivers,
> > > and the lack of full rollback will be felt.
> > >
> > > So not sure whether we can still keep all these debug/validation
> > > checks, or whether this is a step too far towards clever tricks.
> >
> > I think we could definitely find a way to keep debugging to make sure
> > everything is unwound before attempting to restart the locking
> > transaction. But the debug check that we're restarting on the contended
> > lock only really makes sense for wait-die, (and we could easily keep it
> > for wait-die). The lock returning -EDEADLK for wound-wait may actually
> > not be the contending lock but an arbitrary lock that the wounded
> > transaction attempts to take after it is wounded.
> >
> > So in the end IMO this is a tradeoff between added (possibly severe)
> > locking complexity into dma-buf and not being able to switch back to
> > wait-die efficiently if we need / want to do that.
> >
> > /Thomas
>
> And as a consequence an interface *could* be:
>
> *) We introduce functions
>
> void ww_acquire_relax(struct ww_acquire_ctx *ctx);
> int ww_acquire_relax_interruptible(struct ww_acquire_ctx *ctx);
>
> that can be used instead of ww_mutex_lock_slow() in the absence of a
> contending lock to avoid spinning on -EDEADLK. While trying to take the
> contending lock is probably the best choice there are various second best
> approaches that can be explored, for example waiting on the contending
> acquire to finish or in the wound-wait case, perhaps do nothing. These
> functions will also help us keep the debugging.
Hm ... I guess this could work. Trouble is, it only gets rid of the
slowpath locking book-keeping headaches, we still have quite a few others.
> *) A function returning -EDEADLK to a caller *must* have already released
> its own locks.
So this ties to another question, as in should these callbacks have to
drops the locks thei acquire (much simpler code) or not (less thrashing,
if we drop locks we might end up in a situation where threads thrash
around instead of realizing quicker that they're actually deadlocking and
one of them should stop and back off).
But keeping locks locked means massive amounts of book-keeping in dma_resv
layer, so goes all downhill from there.
> *) move_notify() explicitly takes a struct ww_acquire_ctx * to make sure
> there is no ambiguity. (I think it would be valuable if we could do the same
> for ttm_bo_validate()).
Yeah I think more explicit locking ctx would be really good no matter
what. Implicitly fishing the acquire_ctx out of the lock for the object
you're called on is kinda nasty.
-Daniel
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: [PATCH] tcg: gdbstub: Fix single-step issue on arm target
From: Laurent Vivier @ 2020-02-20 18:06 UTC (permalink / raw)
To: Philippe Mathieu-Daudé, Changbin Du, alex.bennee; +Cc: qemu-devel
In-Reply-To: <269f16b4-e843-1058-4c3b-f11de45b04e1@redhat.com>
Le 20/02/2020 à 18:47, Philippe Mathieu-Daudé a écrit :
> On 2/20/20 4:58 PM, Changbin Du wrote:
>> Recently when debugging an arm32 system on qemu, I found sometimes the
>> single-step command (stepi) is not working. This can be reproduced by
>> below steps:
>> 1) start qemu-system-arm -s -S .. and wait for gdb connection.
>> 2) start gdb and connect to qemu. In my case, gdb gets a wrong value
>> (0x60) for PC.
>> 3) After connected, type 'stepi' and expect it will stop at next ins.
>>
>> But, it has never stopped. This because:
>> 1) We doesn't report ‘vContSupported’ feature to gdb explicitly and gdb
>> think we do not support it. In this case, gdb use a software
>> breakpoint
>> to emulate single-step.
>> 2) Since gdb gets a wrong initial value of PC, then gdb inserts a
>> breakpoint to wrong place (PC+4).
>>
>> Since we do support ‘vContSupported’ query command, so let's tell gdb
>> that
>> we support it.
>>
>> Before this change, gdb send below 'Z0' packet to implement single-step:
>> gdb_handle_packet: Z0,4,4
>>
>> After this change, gdb send "vCont;s.." which is expected:
>> gdb_handle_packet: vCont?
>> put_packet: vCont;c;C;s;S
>> gdb_handle_packet: vCont;s:p1.1;c:p1.-1
>
> You actually fixed this for all architectures :)
>
> This has been annoying me on MIPS since more than a year...
The problem started with an update of QEMU or of GDB?
At one point it seemed to work, so what happened?
Thanks,
Laurent
^ permalink raw reply
* Re: S variable for svn fetcher Was: State of OE world - 2020-02-18
From: Khem Raj @ 2020-02-20 18:08 UTC (permalink / raw)
To: Martin Jansa, Adrian Bunk; +Cc: openembeded-devel
In-Reply-To: <20200220173421.egafqfq25kbtr4a4@jama>
On 2/20/20 9:34 AM, Martin Jansa wrote:
> On Thu, Feb 20, 2020 at 05:23:12PM +0100, Martin Jansa wrote:
>> On Thu, Feb 20, 2020 at 06:11:59PM +0200, Adrian Bunk wrote:
>>> On Thu, Feb 20, 2020 at 04:37:58PM +0100, Martin Jansa wrote:
>>>> On Thu, Feb 20, 2020 at 05:16:20PM +0200, Adrian Bunk wrote:
>>>>> On Thu, Feb 20, 2020 at 03:48:48PM +0100, Martin Jansa wrote:
>>>>>> ...
>>>>>> Any idea why these aren't shown in our build?
>>>>>> ...
>>>>>
>>>>> What is your mirror configuration?
>>>>>
>>>>> Default configuration downloads the tarball from [1].
>>>>
>>>> Maybe I'm missing your point, but these aren't fetch issues.
>>>> ...
>>>
>>> MIRRORS = "" (and deleting the downloaded tar) is what I needed for
>>> getting a build failure.
>>
>> OK, I see now, sorry.
>>
>> That explains why it's not shown in khem's builds and might be broken
>> well before thud already, the tarball created here today:
>>
>> $ tar xvf ../downloads/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> gpio/
>> gpio/trunk/
>> gpio/trunk/doc/
>> gpio/trunk/doc/hardware/
>> gpio/trunk/doc/hardware/GTA01Bv3/
>> gpio/trunk/doc/hardware/GTA01Bv3/gpio.txt
>> gpio/trunk/doc/hardware/GTA01Bv3/pmu-voltage.txt
>> ...
>>
>> while the corresponding tarball on mirror:
>> http://sources.openembedded.org/gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> $ tar xvf gpio_svn.openmoko.org_.trunk.src.target_4949_.tar.gz
>> gpio/
>> gpio/gpio-s3c6410.c
>> gpio/Makefile
>> gpio/gpio.c
>> gpio/gpio-glamo.c
>> gpio/README
>>
>> Will check when it got broken before thud.
>
> It's still reproducible in pyro, so probably not caused by changes in OE.
>
> There is one more recipe using svn in meta-multimedia which works fine:
> meta-multimedia/recipes-dvb/oscam/oscam_svn.bb:SRC_URI = "svn://www.streamboard.tv/svn/oscam;module=trunk;protocol=http \
>
> The rest are all from svn.openmoko.org:
> meta-oe/recipes-support/samsung-soc-utils/s3c24xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
> meta-oe/recipes-support/samsung-soc-utils/s3c64xx-gpio_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=gpio;protocol=http"
> meta-oe/recipes-support/samsung-soc-utils/sjf2410-linux-native_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host/;module=sjf2410-linux;protocol=http \
> meta-oe/recipes-support/usbpath/usbpath_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/host;module=usbpath;protocol=http \
> meta-oe/recipes-support/wmiconfig/wmiconfig_svn.bb:SRC_URI = "svn://svn.openmoko.org/trunk/src/target;module=AR6kSDK.build_sw.18;protocol=http \
>
> And now this leads to do_fetch running:
> svn --non-interactive --trust-server-cert co --no-auth-cache --ignore-externals -r 4949 http://svn.openmoko.org/trunk/src/target/gpio@4949 gpio
> as before, but now it redirects to github:
>
> Redirecting to URL 'https://github.com/openmoko/openmoko-svn':
> A gpio/branches
> A gpio/branches/oe
> A gpio/branches/oe/pre-20070305
> A gpio/branches/oe/pre-20070305/README
> A gpio/branches/oe/pre-20070305/classes
> A gpio/branches/oe/pre-20070305/classes/autotools.bbclass
> A gpio/branches/oe/pre-20070305/classes/base.bbclass
> A gpio/branches/oe/pre-20070305/classes/openmoko-base.bbclass
> A gpio/branches/oe/pre-20070305/classes/openmoko-panel-plugin.bbclass
> ..
>
> and the svn bridge to github probably doesn't work exactly the same as the
> native svn repo used to work, but I don't see it explicitly mentioned in:
> https://help.github.com/en/github/importing-your-projects-to-github/support-for-subversion-clients
>
> So to resolve this quickly I'm going to send SRC_URI updates for
> these recipes to just use git fetcher from:
> https://github.com/openmoko/openmoko-svn
> directly. I don't think anyone is using these nowadays, so it's
> also fine with me to just delete them all, which I'll do in
> separate follow-up commit in case someone tries to resurrect them
> later in own layer.
>
I think plan looks good. Lets fix the SRC_URI and then delete them
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: decompressor: use by-VA cache maintenance for v7 cores
From: Ard Biesheuvel @ 2020-02-20 18:08 UTC (permalink / raw)
To: linux-efi, Arnd Bergmann
Cc: linux-arm-kernel, Russell King, Marc Zyngier, Nicolas Pitre,
Catalin Marinas, Tony Lindgren
In-Reply-To: <20200219094340.16597-1-ardb@kernel.org>
(+ Arnd)
On Wed, 19 Feb 2020 at 10:43, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> While making changes to the EFI stub startup code, I noticed that we are
> still doing set/way maintenance on the caches when booting on v7 cores.
> This works today on VMs by virtue of the fact that KVM traps set/way ops
> and cleans the whole address space by VA on behalf of the guest, and on
> most v7 hardware, the set/way ops are in fact sufficient when only one
> core is running, as there usually is no system cache. But on systems
> like SynQuacer, for which 32-bit firmware is available, the current cache
> maintenance only pushes the data out to the L3 system cache, where it
> is not visible to the CPU once it turns the MMU and caches off.
>
> So instead, switch to the by-VA cache maintenance that the architecture
> requires for v7 and later (and ARM1176, as a side effect).
>
> Changes since v1:
> - include the EFI patch that was sent out separately before (#1)
> - split the preparatory work to pass the region to clean in r0/r1 in a EFI
> specific one and one for the decompressor - this way, the first two patches
> can go on a stable branch that is shared between the ARM tree and the EFI
> tree
> - document the meaning of the values in r0/r1 upon entry to cache_clean_flush
> - take care to treat the region end address as exclusive
> - switch to clean+invalidate to align with the other implementations
> - drop some code that manages the stack pointer value before calling
> cache_clean_flush(), which is no longer necessary
> - take care to clean the entire region that is covered by the relocated zImage
> if it needs to relocate itself before decompressing
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm32-efi-cache-ops
>
Adding my own data point here: with these patches, I can reproducibly
boot on the SynQuacer platform (24x Cortex-A53 + GICv3 + L3 system
cache) until the point where /init is loaded, after which it hangs
(see below), whereas without them, it always crashes early with weird,
unreproducible errors, if it even makes it far enough through the
decompressor to produce any earlycon output.
There is some other weird stuff going on, but this is unlikely to be
related to cache maintenance:
- multiple occurrences of
OF: translation of DMA address(0) to CPU address failed node(...)
- /cpus/cpu@0: unsupported enable-method property: psci
Then, there is not enough vmalloc space to map the config space of
both PCIe RCs.
Also, due to the fact that this platform sadly honours the ARM
recommendation on memory maps, it seems there is no way to make useful
use of any memory beyond 2 GB, given that the hole between the lower 2
GB and the upper <30 GB eats up all the lowmem by being covered by the
memmap[] array. (Note that this platform supports up to 64 GB, in
which case another hole of 480 GB is created, so there is no way we
can even boot with that much memory reported to the kernel)
Shell> initrd initrd.gz
Shell> zImage
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.6.0-rc1-00084-g8602a0ff0200-dirty
(ardbie01@e123331-lin) (gcc version 7.4.0 (Ubuntu/Linaro
7.4.0-1ubuntu1~18.04.1)) #286 SMP Thu Feb 20 17:49:59 CET 2020
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=70c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: Socionext Developer Box
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0xffa1c000 MEMATTR=0xfd0b4010
ESRT=0xfdfbb910 MEMRESERVE=0xf8f2d010
[ 0.000000] OF: fdt: Ignoring memory block 0x880000000 - 0x1000000000
[ 0.000000] esrt: Reserving ESRT space from 0x00000000fdfbb910 to
0x00000000fdfbb948.
[ 0.000000] cma: Reserved 64 MiB at 0x00000000f9000000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] percpu: Embedded 20 pages/cpu s49356 r8192 d24372 u81920
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 522368
[ 0.000000] Kernel command line: zImage
[ 0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[ 0.000000] printk: log_buf_len total cpu_extra contributions: 94208 bytes
[ 0.000000] printk: log_buf_len min size: 131072 bytes
[ 0.000000] printk: log_buf_len: 262144 bytes
[ 0.000000] printk: early log buf free: 128828(98%)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7,
524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] software IO TLB: mapped [mem 0xaa90c000-0xae90c000] (64MB)
[ 0.000000] Memory: 1886672K/2097152K available (10240K kernel
code, 1811K rwdata, 5392K rodata, 2048K init, 414K bss, 144944K
reserved, 65536K cma-reserved, 1233168K highmem)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=24, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GICv3: 640 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: 16 PPIs implemented
[ 0.000000] GICv3: no VLPI support, no direct LPI support, no RVPEID support
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000030400000
[ 0.000000] ITS [mem 0x30020000-0x3003ffff]
[ 0.000000] GIC: enabling workaround for ITS: Socionext Synquacer pre-ITS
[ 0.000000] ITS@0x0000000030020000: allocated 524288 Devices
@aa400000 (flat, esz 8, psz 64K, shr 0)
[ 0.000000] ITS: using cache flushing for cmd queue
[ 0.000000] GICv3: using LPI property table @0x00000000aa080000
[ 0.000000] GIC: using cache flushing for LPI property table
[ 0.000000] GICv3: CPU0: using allocated LPI pending table
@0x00000000aa090000
[ 0.000000] random: get_random_bytes called from
start_kernel+0x469/0x5ca with crng_init=0
[ 0.000000] arch_timer: cp15 and mmio timer(s) running at 100.00MHz
(virt/phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[ 0.000004] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps
every 4398046511100ns
[ 0.000013] Switching to timer-based delay loop, resolution 10ns
[ 0.000890] Console: colour dummy device 80x30
[ 0.001344] printk: console [tty0] enabled
[ 0.001389] Calibrating delay loop (skipped), value calculated
using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
[ 0.001410] pid_max: default: 32768 minimum: 301
[ 0.001561] Mount-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[ 0.001581] Mountpoint-cache hash table entries: 2048 (order: 1,
8192 bytes, linear)
[ 0.002112] CPU: Testing write buffer coherency: ok
[ 0.002637] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.002926] Setting up static identity map for 0x80400000 - 0x80400160
[ 0.003448] rcu: Hierarchical SRCU implementation.
[ 0.003601] Platform MSI: gic-its@30020000 domain created
[ 0.003669] PCI/MSI:
/interrupt-controller@30000000/gic-its@30020000 domain created
[ 0.004751] Remapping and enabling EFI services.
[ 0.005305] smp: Bringing up secondary CPUs ...
[ 0.005895] GICv3: CPU1: found redistributor 1 region 0:0x0000000030420000
[ 0.005919] GICv3: CPU1: using allocated LPI pending table
@0x00000000aa0a0000
[ 0.005940] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.011149] GICv3: CPU2: found redistributor 100 region 0:0x0000000030440000
[ 0.011179] GICv3: CPU2: using allocated LPI pending table
@0x00000000aa0b0000
[ 0.011203] CPU2: thread -1, cpu 0, socket 1, mpidr 80000100
[ 0.014242] GICv3: CPU3: found redistributor 101 region 0:0x0000000030460000
[ 0.014264] GICv3: CPU3: using allocated LPI pending table
@0x00000000aa0c0000
[ 0.014284] CPU3: thread -1, cpu 1, socket 1, mpidr 80000101
[ 0.019622] GICv3: CPU4: found redistributor 200 region 0:0x0000000030480000
[ 0.019650] GICv3: CPU4: using allocated LPI pending table
@0x00000000aa0d0000
[ 0.019675] CPU4: thread -1, cpu 0, socket 2, mpidr 80000200
[ 0.022737] GICv3: CPU5: found redistributor 201 region 0:0x00000000304a0000
[ 0.022759] GICv3: CPU5: using allocated LPI pending table
@0x00000000aa0e0000
[ 0.022777] CPU5: thread -1, cpu 1, socket 2, mpidr 80000201
[ 0.028146] GICv3: CPU6: found redistributor 300 region 0:0x00000000304c0000
[ 0.028174] GICv3: CPU6: using allocated LPI pending table
@0x00000000aa0f0000
[ 0.028196] CPU6: thread -1, cpu 0, socket 3, mpidr 80000300
[ 0.031213] GICv3: CPU7: found redistributor 301 region 0:0x00000000304e0000
[ 0.031239] GICv3: CPU7: using allocated LPI pending table
@0x00000000aa100000
[ 0.031256] CPU7: thread -1, cpu 1, socket 3, mpidr 80000301
[ 0.036606] GICv3: CPU8: found redistributor 400 region 0:0x0000000030500000
[ 0.036634] GICv3: CPU8: using allocated LPI pending table
@0x00000000aa110000
[ 0.036657] CPU8: thread -1, cpu 0, socket 4, mpidr 80000400
[ 0.039719] GICv3: CPU9: found redistributor 401 region 0:0x0000000030520000
[ 0.039740] GICv3: CPU9: using allocated LPI pending table
@0x00000000aa120000
[ 0.039757] CPU9: thread -1, cpu 1, socket 4, mpidr 80000401
[ 0.045156] GICv3: CPU10: found redistributor 500 region 0:0x0000000030540000
[ 0.045187] GICv3: CPU10: using allocated LPI pending table
@0x00000000aa130000
[ 0.045210] CPU10: thread -1, cpu 0, socket 5, mpidr 80000500
[ 0.048241] GICv3: CPU11: found redistributor 501 region 0:0x0000000030560000
[ 0.048263] GICv3: CPU11: using allocated LPI pending table
@0x00000000aa140000
[ 0.048282] CPU11: thread -1, cpu 1, socket 5, mpidr 80000501
[ 0.053651] GICv3: CPU12: found redistributor 600 region 0:0x0000000030580000
[ 0.053681] GICv3: CPU12: using allocated LPI pending table
@0x00000000aa150000
[ 0.053706] CPU12: thread -1, cpu 0, socket 6, mpidr 80000600
[ 0.056742] GICv3: CPU13: found redistributor 601 region 0:0x00000000305a0000
[ 0.056765] GICv3: CPU13: using allocated LPI pending table
@0x00000000aa160000
[ 0.056785] CPU13: thread -1, cpu 1, socket 6, mpidr 80000601
[ 0.062113] GICv3: CPU14: found redistributor 700 region 0:0x00000000305c0000
[ 0.062144] GICv3: CPU14: using allocated LPI pending table
@0x00000000aa170000
[ 0.062166] CPU14: thread -1, cpu 0, socket 7, mpidr 80000700
[ 0.065238] GICv3: CPU15: found redistributor 701 region 0:0x00000000305e0000
[ 0.065263] GICv3: CPU15: using allocated LPI pending table
@0x00000000aa180000
[ 0.065282] CPU15: thread -1, cpu 1, socket 7, mpidr 80000701
[ 0.070661] GICv3: CPU16: found redistributor 800 region 0:0x0000000030600000
[ 0.070691] GICv3: CPU16: using allocated LPI pending table
@0x00000000aa190000
[ 0.070716] CPU16: thread -1, cpu 0, socket 8, mpidr 80000800
[ 0.073748] GICv3: CPU17: found redistributor 801 region 0:0x0000000030620000
[ 0.073774] GICv3: CPU17: using allocated LPI pending table
@0x00000000aa1a0000
[ 0.073794] CPU17: thread -1, cpu 1, socket 8, mpidr 80000801
[ 0.079132] GICv3: CPU18: found redistributor 900 region 0:0x0000000030640000
[ 0.079163] GICv3: CPU18: using allocated LPI pending table
@0x00000000aa1b0000
[ 0.079187] CPU18: thread -1, cpu 0, socket 9, mpidr 80000900
[ 0.082216] GICv3: CPU19: found redistributor 901 region 0:0x0000000030660000
[ 0.082239] GICv3: CPU19: using allocated LPI pending table
@0x00000000aa1c0000
[ 0.082257] CPU19: thread -1, cpu 1, socket 9, mpidr 80000901
[ 0.087755] GICv3: CPU20: found redistributor a00 region 0:0x0000000030680000
[ 0.087788] GICv3: CPU20: using allocated LPI pending table
@0x00000000aa1d0000
[ 0.087811] CPU20: thread -1, cpu 0, socket 10, mpidr 80000a00
[ 0.090897] GICv3: CPU21: found redistributor a01 region 0:0x00000000306a0000
[ 0.090922] GICv3: CPU21: using allocated LPI pending table
@0x00000000aa1e0000
[ 0.090939] CPU21: thread -1, cpu 1, socket 10, mpidr 80000a01
[ 0.096296] GICv3: CPU22: found redistributor b00 region 0:0x00000000306c0000
[ 0.096329] GICv3: CPU22: using allocated LPI pending table
@0x00000000aa1f0000
[ 0.096353] CPU22: thread -1, cpu 0, socket 11, mpidr 80000b00
[ 0.099356] GICv3: CPU23: found redistributor b01 region 0:0x00000000306e0000
[ 0.099381] GICv3: CPU23: using allocated LPI pending table
@0x00000000aa200000
[ 0.099400] CPU23: thread -1, cpu 1, socket 11, mpidr 80000b01
[ 0.099506] smp: Brought up 1 node, 24 CPUs
[ 0.100163] SMP: Total of 24 processors activated (4800.00 BogoMIPS).
[ 0.100175] CPU: All CPU(s) started in SVC mode.
[ 0.101193] devtmpfs: initialized
[ 0.103698] VFP support v0.3: implementor 41 architecture 3 part 40
variant 3 rev 4
[ 0.103980] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.104009] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
[ 0.106670] pinctrl core: initialized pinctrl subsystem
[ 0.107566] thermal_sys: Registered thermal governor 'step_wise'
[ 0.107754] SMBIOS 3.3.0 present.
[ 0.107788] DMI: Socionext SynQuacer E-series DeveloperBox, BIOS
build #1 Feb 20 2020
[ 0.108185] NET: Registered protocol family 16
[ 0.109556] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.110957] cpuidle: using governor menu
[ 0.111063] No ATAGs?
[ 0.111467] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
watchpoint registers.
[ 0.111490] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.112874] Serial: AMBA PL011 UART driver
[ 0.114349] OF: translation of DMA address(0) to CPU address failed
node(/uart@2a400000)
[ 0.114421] 2a400000.uart: ttyAMA0 at MMIO 0x2a400000 (irq = 22,
base_baud = 0) is a PL011 rev3
[ 1.117194] printk: console [ttyAMA0] enabled
[ 1.135592] AT91: Could not find identification node
[ 1.136261] iommu: Default domain type: Translated
[ 1.146225] vgaarb: loaded
[ 1.149407] SCSI subsystem initialized
[ 1.153506] usbcore: registered new interface driver usbfs
[ 1.159042] usbcore: registered new interface driver hub
[ 1.164477] usbcore: registered new device driver usb
[ 1.169950] pps_core: LinuxPPS API ver. 1 registered
[ 1.174911] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[ 1.184062] PTP clock support registered
[ 1.188042] EDAC MC: Ver: 3.0.0
[ 1.191660] Registered efivars operations
[ 1.196838] clocksource: Switched to clocksource arch_sys_counter
[ 2.103835] NET: Registered protocol family 2
[ 2.108658] tcp_listen_portaddr_hash hash table entries: 512
(order: 0, 6144 bytes, linear)
[ 2.117044] TCP established hash table entries: 8192 (order: 3,
32768 bytes, linear)
[ 2.124854] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 2.132103] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.138585] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.145223] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.152446] NET: Registered protocol family 1
[ 2.157108] RPC: Registered named UNIX socket transport module.
[ 2.163026] RPC: Registered udp transport module.
[ 2.167746] RPC: Registered tcp transport module.
[ 2.172445] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.178897] PCI: CLS 0 bytes, default 64
[ 2.183052] Trying to unpack rootfs image as initramfs...
[ 3.413006] Freeing initrd memory: 22816K
[ 3.418665] Initialise system trusted keyrings
[ 3.423276] workingset: timestamp_bits=30 max_order=19 bucket_order=0
[ 3.434628] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 3.441097] NFS: Registering the id_resolver key type
[ 3.446175] Key type id_resolver registered
[ 3.450375] Key type id_legacy registered
[ 3.454388] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 3.461111] ntfs: driver 2.1.32 [Flags: R/O].
[ 3.465747] Key type asymmetric registered
[ 3.469857] Asymmetric key parser 'x509' registered
[ 3.474765] bounce: pool size: 64 pages
[ 3.478629] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 247)
[ 3.486027] io scheduler mq-deadline registered
[ 3.490564] io scheduler kyber registered
[ 3.500170] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.508318] pci-host-generic 60000000.pcie: host bridge
/pcie@60000000 ranges:
[ 3.515556] pci-host-generic 60000000.pcie: IO
0x0067f00000..0x0067f0ffff -> 0x0000000000
[ 3.524276] pci-host-generic 60000000.pcie: MEM
0x0068000000..0x006fffffff -> 0x0068000000
[ 3.532987] pci-host-generic 60000000.pcie: MEM
0x3e00000000..0x3effffffff -> 0x3e00000000
[ 3.543045] pci-host-generic 60000000.pcie: ECAM at [mem
0x60000000-0x67efffff] for [bus 00-7e]
[ 3.551873] pci-host-generic 60000000.pcie: PCI host bridge to bus 0000:00
[ 3.558764] pci_bus 0000:00: root bus resource [bus 00-7e]
[ 3.564250] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.570438] pci_bus 0000:00: root bus resource [mem 0x68000000-0x6fffffff]
[ 3.577322] pci_bus 0000:00: root bus resource [mem
0x3e00000000-0x3effffffff]
[ 3.584574] pci 0000:00:00.0: [1b21:1184] type 01 class 0x060400
[ 3.590646] pci 0000:00:00.0: enabling Extended Tags
[ 3.595677] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[ 3.602874] PCI: bus0: Fast back to back transfers disabled
[ 3.608585] pci 0000:01:01.0: [1b21:1184] type 01 class 0x060400
[ 3.614645] pci 0000:01:01.0: enabling Extended Tags
[ 3.619672] pci 0000:01:01.0: PME# supported from D0 D3hot D3cold
[ 3.625969] pci 0000:01:03.0: [1b21:1184] type 01 class 0x060400
[ 3.632040] pci 0000:01:03.0: enabling Extended Tags
[ 3.637066] pci 0000:01:03.0: PME# supported from D0 D3hot D3cold
[ 3.643363] pci 0000:01:05.0: [1b21:1184] type 01 class 0x060400
[ 3.649431] pci 0000:01:05.0: enabling Extended Tags
[ 3.654449] pci 0000:01:05.0: PME# supported from D0 D3hot D3cold
[ 3.660753] pci 0000:01:07.0: [1b21:1184] type 01 class 0x060400
[ 3.666822] pci 0000:01:07.0: enabling Extended Tags
[ 3.671844] pci 0000:01:07.0: PME# supported from D0 D3hot D3cold
[ 3.678832] PCI: bus1: Fast back to back transfers disabled
[ 3.684517] pci 0000:02:00.0: [1b21:0612] type 00 class 0x010601
[ 3.690564] pci 0000:02:00.0: reg 0x10: [io 0x0028-0x002f]
[ 3.696147] pci 0000:02:00.0: reg 0x14: [io 0x0034-0x0037]
[ 3.701738] pci 0000:02:00.0: reg 0x18: [io 0x0020-0x0027]
[ 3.707329] pci 0000:02:00.0: reg 0x1c: [io 0x0030-0x0033]
[ 3.712912] pci 0000:02:00.0: reg 0x20: [io 0x0000-0x001f]
[ 3.718503] pci 0000:02:00.0: reg 0x24: [mem 0x68100000-0x681001ff]
[ 3.724781] pci 0000:02:00.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
[ 3.732590] PCI: bus2: Fast back to back transfers disabled
[ 3.738174] pci_bus 0000:02: busn_res: [bus 02-7e] end is updated to 02
[ 3.745751] PCI: bus3: Fast back to back transfers enabled
[ 3.751247] pci_bus 0000:03: busn_res: [bus 03-7e] end is updated to 03
[ 3.757969] pci 0000:04:00.0: [1912:0014] type 00 class 0x0c0330
[ 3.764012] pci 0000:04:00.0: reg 0x10: [mem 0x68000000-0x68001fff 64bit]
[ 3.770943] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[ 3.807778] PCI: bus4: Fast back to back transfers disabled
[ 3.813353] pci_bus 0000:04: busn_res: [bus 04-7e] end is updated to 04
[ 3.820943] PCI: bus5: Fast back to back transfers enabled
[ 3.826430] pci_bus 0000:05: busn_res: [bus 05-7e] end is updated to 05
[ 3.833058] pci_bus 0000:01: busn_res: [bus 01-7e] end is updated to 05
[ 3.839709] pci 0000:00:00.0: BAR 8: assigned [mem 0x68000000-0x681fffff]
[ 3.846498] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 3.852603] pci 0000:01:01.0: BAR 8: assigned [mem 0x68000000-0x680fffff]
[ 3.859402] pci 0000:01:05.0: BAR 8: assigned [mem 0x68100000-0x681fffff]
[ 3.866190] pci 0000:01:01.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 3.872294] pci 0000:02:00.0: BAR 6: assigned [mem
0x68000000-0x6800ffff pref]
[ 3.879529] pci 0000:02:00.0: BAR 5: assigned [mem 0x68010000-0x680101ff]
[ 3.886321] pci 0000:02:00.0: BAR 4: assigned [io 0x1000-0x101f]
[ 3.892425] pci 0000:02:00.0: BAR 0: assigned [io 0x1020-0x1027]
[ 3.898529] pci 0000:02:00.0: BAR 2: assigned [io 0x1028-0x102f]
[ 3.904627] pci 0000:02:00.0: BAR 1: assigned [io 0x1030-0x1033]
[ 3.910730] pci 0000:02:00.0: BAR 3: assigned [io 0x1034-0x1037]
[ 3.916834] pci 0000:01:01.0: PCI bridge to [bus 02]
[ 3.921799] pci 0000:01:01.0: bridge window [io 0x1000-0x1fff]
[ 3.927903] pci 0000:01:01.0: bridge window [mem 0x68000000-0x680fffff]
[ 3.934697] pci 0000:01:03.0: PCI bridge to [bus 03]
[ 3.939682] pci 0000:04:00.0: BAR 0: assigned [mem
0x68100000-0x68101fff 64bit]
[ 3.947012] pci 0000:01:05.0: PCI bridge to [bus 04]
[ 3.951979] pci 0000:01:05.0: bridge window [mem 0x68100000-0x681fffff]
[ 3.958780] pci 0000:01:07.0: PCI bridge to [bus 05]
[ 3.963754] pci 0000:00:00.0: PCI bridge to [bus 01-05]
[ 3.968985] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
[ 3.975081] pci 0000:00:00.0: bridge window [mem 0x68000000-0x681fffff]
[ 3.981914] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.990313] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.998662] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.007005] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.015339] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.023694] pci 0000:04:00.0: enabling device (0140 -> 0142)
[ 4.029447] OF: translation of DMA address(0) to CPU address failed
node(/pcie@70000000)
[ 4.037570] pci-host-generic 70000000.pcie: host bridge
/pcie@70000000 ranges:
[ 4.044805] pci-host-generic 70000000.pcie: IO
0x0077f00000..0x0077f0ffff -> 0x0000000000
[ 4.053523] pci-host-generic 70000000.pcie: MEM
0x0078000000..0x007fffffff -> 0x0078000000
[ 4.062236] pci-host-generic 70000000.pcie: MEM
0x3f00000000..0x3fffffffff -> 0x3f00000000
[ 4.071308] vmap allocation for size 1052672 failed: use
vmalloc=<size> to increase size
[ 4.079411] pci-host-generic 70000000.pcie: ECAM ioremap failed
[ 4.085525] pci-host-generic: probe of 70000000.pcie failed with error -12
[ 4.126494] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 4.134170] OF: translation of DMA address(0) to CPU address failed
node(/uart@51040000)
[ 4.142748] 51040000.uart: ttyS1 at MMIO 0x51040000 (irq = 23,
base_baud = 3906250) is a 16550A
[ 4.152099] SuperH (H)SCI(F) driver initialized
[ 4.156953] msm_serial: driver initialized
[ 4.161103] STMicroelectronics ASC driver initialized
[ 4.166594] STM32 USART driver initialized
[ 4.178363] brd: module loaded
[ 4.192943] loop: module loaded
[ 4.197009] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.205330] ahci 0000:02:00.0: SSS flag set, parallel bus scan disabled
[ 4.212015] ahci 0000:02:00.0: AHCI 0001.0200 32 slots 2 ports 6
Gbps 0x3 impl SATA mode
[ 4.220122] ahci 0000:02:00.0: flags: 64bit ncq sntf stag led clo
pmp pio slum part ccc sxs
[ 4.229431] scsi host0: ahci
[ 4.232675] scsi host1: ahci
[ 4.235694] ata1: SATA max UDMA/133 abar m512@0x68010000 port
0x68010100 irq 35
[ 4.243033] ata2: SATA max UDMA/133 abar m512@0x68010000 port
0x68010180 irq 35
[ 4.253906] libphy: Fixed MDIO Bus: probed
[ 4.258796] CAN device driver interface
[ 4.262933] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
[ 4.268942] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 4.274772] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 4.280739] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[ 4.287707] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 4.294603] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB
Ethernet driver
[ 4.302042] usbcore: registered new interface driver pegasus
[ 4.307736] usbcore: registered new interface driver asix
[ 4.313150] usbcore: registered new interface driver ax88179_178a
[ 4.319267] usbcore: registered new interface driver cdc_ether
[ 4.325122] usbcore: registered new interface driver smsc75xx
[ 4.330901] usbcore: registered new interface driver smsc95xx
[ 4.336663] usbcore: registered new interface driver net1080
[ 4.342350] usbcore: registered new interface driver cdc_subset
[ 4.348295] usbcore: registered new interface driver zaurus
[ 4.353894] usbcore: registered new interface driver cdc_ncm
[ 4.360347] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 4.366891] ehci-pci: EHCI PCI platform driver
[ 4.371359] ehci-platform: EHCI generic platform driver
[ 4.376646] ehci-orion: EHCI orion driver
[ 4.380714] SPEAr-ehci: EHCI SPEAr driver
[ 4.384767] ehci-st: EHCI STMicroelectronics driver
[ 4.389704] ehci-exynos: EHCI Exynos driver
[ 4.393931] ehci-atmel: EHCI Atmel driver
[ 4.397991] tegra-ehci: Tegra EHCI driver
[ 4.402048] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 4.408245] ohci-pci: OHCI PCI platform driver
[ 4.412714] ohci-platform: OHCI generic platform driver
[ 4.418003] SPEAr-ohci: OHCI SPEAr driver
[ 4.422057] ohci-st: OHCI STMicroelectronics driver
[ 4.426995] ohci-atmel: OHCI Atmel driver
[ 4.431085] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.439259] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 4.444497] xhci_hcd 0000:04:00.0: new USB bus registered, assigned
bus number 1
[ 4.457324] xhci_hcd 0000:04:00.0: hcc params 0x014051cf hci
version 0x100 quirks 0x0000000100000410
[ 4.467671] hub 1-0:1.0: USB hub found
[ 4.471449] hub 1-0:1.0: 4 ports detected
[ 4.475927] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 4.481175] xhci_hcd 0000:04:00.0: new USB bus registered, assigned
bus number 2
[ 4.488585] xhci_hcd 0000:04:00.0: Host supports USB 3.0 SuperSpeed
[ 4.494924] usb usb2: We don't know the algorithms for LPM for this
host, disabling LPM.
[ 4.503372] hub 2-0:1.0: USB hub found
[ 4.507155] hub 2-0:1.0: 4 ports detected
[ 4.511847] usbcore: registered new interface driver usb-storage
[ 4.519900] i2c /dev entries driver
[ 4.528493] /cpus/cpu@0: unsupported enable-method property: psci
[ 4.537114] sdhci: Secure Digital Host Controller Interface driver
[ 4.543297] sdhci: Copyright(c) Pierre Ossman
[ 4.548328] Synopsys Designware Multimedia Card Interface Driver
[ 4.554829] sdhci-pltfm: SDHCI platform and OF driver helper
[ 4.562104] ledtrig-cpu: registered to indicate activity on CPUs
[ 4.568594] usbcore: registered new interface driver usbhid
[ 4.574168] usbhid: USB HID core driver
[ 4.579546] drop_monitor: Initializing network drop monitor service
[ 4.586552] NET: Registered protocol family 10
[ 4.591887] Segment Routing with IPv6
[ 4.595614] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 4.602085] NET: Registered protocol family 17
[ 4.606537] can: controller area network core (rev 20170425 abi 9)
[ 4.612780] NET: Registered protocol family 29
[ 4.617248] can: raw protocol (rev 20170425)
[ 4.621524] can: broadcast manager protocol (rev 20170425 t)
[ 4.627198] can: netlink gateway (rev 20190810) max_hops=1
[ 4.632967] Key type dns_resolver registered
[ 4.637328] Registering SWP/SWPB emulation handler
[ 4.642410] Loading compiled-in X.509 certificates
[ 4.688987] OF: translation of DMA address(0) to CPU address failed
node(/gpio-keys)
[ 4.696780] irq: no irq domain found for interrupt-controller@510c0000 !
[ 4.703556] gpio-keys gpio-keys: Found button without gpio or irq
[ 4.709673] gpio-keys: probe of gpio-keys failed with error -22
[ 4.715621] hctosys: unable to open rtc device (rtc0)
[ 4.721044] uart-pl011 2a400000.uart: no DMA platform data
[ 4.746912] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4.754022] ata1.00: ATA-10: WDC WD10EZEX-22MFCA0, 01.01A01, max UDMA/133
[ 4.760826] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 4.768960] ata1.00: configured for UDMA/133
[ 4.773637] scsi 0:0:0:0: Direct-Access ATA WDC
WD10EZEX-22M 1A01 PQ: 0 ANSI: 5
[ 4.782675] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 4.790362] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 4.795635] sd 0:0:0:0: [sda] Write Protect is off
[ 4.800505] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4.846916] usb 1-3: new high-speed USB device number 2 using xhci_hcd
[ 4.865348] sda: sda1 sda2 sda3 sda4
[ 4.871475] sd 0:0:0:0: [sda] Attached SCSI disk
[ 4.887962] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 4.894715] scsi host2: usb-storage 1-3:1.0
[ 5.109059] ata2: SATA link down (SStatus 0 SControl 300)
[ 5.117814] Freeing unused kernel memory: 2048K
[ 5.122861] Run /init as init process
^ permalink raw reply
* Re: [PATCH v2 0/4] ARM: decompressor: use by-VA cache maintenance for v7 cores
From: Ard Biesheuvel @ 2020-02-20 18:08 UTC (permalink / raw)
To: linux-efi, Arnd Bergmann
Cc: Nicolas Pitre, Tony Lindgren, Marc Zyngier, Russell King,
Catalin Marinas, linux-arm-kernel
In-Reply-To: <20200219094340.16597-1-ardb@kernel.org>
(+ Arnd)
On Wed, 19 Feb 2020 at 10:43, Ard Biesheuvel <ardb@kernel.org> wrote:
>
> While making changes to the EFI stub startup code, I noticed that we are
> still doing set/way maintenance on the caches when booting on v7 cores.
> This works today on VMs by virtue of the fact that KVM traps set/way ops
> and cleans the whole address space by VA on behalf of the guest, and on
> most v7 hardware, the set/way ops are in fact sufficient when only one
> core is running, as there usually is no system cache. But on systems
> like SynQuacer, for which 32-bit firmware is available, the current cache
> maintenance only pushes the data out to the L3 system cache, where it
> is not visible to the CPU once it turns the MMU and caches off.
>
> So instead, switch to the by-VA cache maintenance that the architecture
> requires for v7 and later (and ARM1176, as a side effect).
>
> Changes since v1:
> - include the EFI patch that was sent out separately before (#1)
> - split the preparatory work to pass the region to clean in r0/r1 in a EFI
> specific one and one for the decompressor - this way, the first two patches
> can go on a stable branch that is shared between the ARM tree and the EFI
> tree
> - document the meaning of the values in r0/r1 upon entry to cache_clean_flush
> - take care to treat the region end address as exclusive
> - switch to clean+invalidate to align with the other implementations
> - drop some code that manages the stack pointer value before calling
> cache_clean_flush(), which is no longer necessary
> - take care to clean the entire region that is covered by the relocated zImage
> if it needs to relocate itself before decompressing
>
> https://git.kernel.org/pub/scm/linux/kernel/git/ardb/linux.git/log/?h=arm32-efi-cache-ops
>
Adding my own data point here: with these patches, I can reproducibly
boot on the SynQuacer platform (24x Cortex-A53 + GICv3 + L3 system
cache) until the point where /init is loaded, after which it hangs
(see below), whereas without them, it always crashes early with weird,
unreproducible errors, if it even makes it far enough through the
decompressor to produce any earlycon output.
There is some other weird stuff going on, but this is unlikely to be
related to cache maintenance:
- multiple occurrences of
OF: translation of DMA address(0) to CPU address failed node(...)
- /cpus/cpu@0: unsupported enable-method property: psci
Then, there is not enough vmalloc space to map the config space of
both PCIe RCs.
Also, due to the fact that this platform sadly honours the ARM
recommendation on memory maps, it seems there is no way to make useful
use of any memory beyond 2 GB, given that the hole between the lower 2
GB and the upper <30 GB eats up all the lowmem by being covered by the
memmap[] array. (Note that this platform supports up to 64 GB, in
which case another hole of 480 GB is created, so there is no way we
can even boot with that much memory reported to the kernel)
Shell> initrd initrd.gz
Shell> zImage
EFI stub: Booting Linux Kernel...
EFI stub: Using DTB from configuration table
EFI stub: Loaded initrd from LINUX_EFI_INITRD_MEDIA_GUID device path
EFI stub: Exiting boot services and installing virtual address map...
[ 0.000000] Booting Linux on physical CPU 0x0
[ 0.000000] Linux version 5.6.0-rc1-00084-g8602a0ff0200-dirty
(ardbie01@e123331-lin) (gcc version 7.4.0 (Ubuntu/Linaro
7.4.0-1ubuntu1~18.04.1)) #286 SMP Thu Feb 20 17:49:59 CET 2020
[ 0.000000] CPU: ARMv7 Processor [410fd034] revision 4 (ARMv7), cr=70c5383d
[ 0.000000] CPU: div instructions available: patching division code
[ 0.000000] CPU: PIPT / VIPT nonaliasing data cache, VIPT aliasing
instruction cache
[ 0.000000] OF: fdt: Machine model: Socionext Developer Box
[ 0.000000] Memory policy: Data cache writealloc
[ 0.000000] efi: EFI v2.70 by EDK II
[ 0.000000] efi: SMBIOS 3.0=0xffa1c000 MEMATTR=0xfd0b4010
ESRT=0xfdfbb910 MEMRESERVE=0xf8f2d010
[ 0.000000] OF: fdt: Ignoring memory block 0x880000000 - 0x1000000000
[ 0.000000] esrt: Reserving ESRT space from 0x00000000fdfbb910 to
0x00000000fdfbb948.
[ 0.000000] cma: Reserved 64 MiB at 0x00000000f9000000
[ 0.000000] psci: probing for conduit method from DT.
[ 0.000000] psci: PSCIv1.1 detected in firmware.
[ 0.000000] psci: Using standard PSCI v0.2 function IDs
[ 0.000000] psci: MIGRATE_INFO_TYPE not supported.
[ 0.000000] psci: SMC Calling Convention v1.0
[ 0.000000] percpu: Embedded 20 pages/cpu s49356 r8192 d24372 u81920
[ 0.000000] Built 1 zonelists, mobility grouping on. Total pages: 522368
[ 0.000000] Kernel command line: zImage
[ 0.000000] printk: log_buf_len individual max cpu contribution: 4096 bytes
[ 0.000000] printk: log_buf_len total cpu_extra contributions: 94208 bytes
[ 0.000000] printk: log_buf_len min size: 131072 bytes
[ 0.000000] printk: log_buf_len: 262144 bytes
[ 0.000000] printk: early log buf free: 128828(98%)
[ 0.000000] Dentry cache hash table entries: 131072 (order: 7,
524288 bytes, linear)
[ 0.000000] Inode-cache hash table entries: 65536 (order: 6, 262144
bytes, linear)
[ 0.000000] mem auto-init: stack:off, heap alloc:off, heap free:off
[ 0.000000] software IO TLB: mapped [mem 0xaa90c000-0xae90c000] (64MB)
[ 0.000000] Memory: 1886672K/2097152K available (10240K kernel
code, 1811K rwdata, 5392K rodata, 2048K init, 414K bss, 144944K
reserved, 65536K cma-reserved, 1233168K highmem)
[ 0.000000] SLUB: HWalign=64, Order=0-3, MinObjects=0, CPUs=24, Nodes=1
[ 0.000000] rcu: Hierarchical RCU implementation.
[ 0.000000] rcu: RCU event tracing is enabled.
[ 0.000000] rcu: RCU calculated value of scheduler-enlistment delay
is 10 jiffies.
[ 0.000000] NR_IRQS: 16, nr_irqs: 16, preallocated irqs: 16
[ 0.000000] GICv3: 640 SPIs implemented
[ 0.000000] GICv3: 0 Extended SPIs implemented
[ 0.000000] GICv3: Distributor has no Range Selector support
[ 0.000000] GICv3: 16 PPIs implemented
[ 0.000000] GICv3: no VLPI support, no direct LPI support, no RVPEID support
[ 0.000000] GICv3: CPU0: found redistributor 0 region 0:0x0000000030400000
[ 0.000000] ITS [mem 0x30020000-0x3003ffff]
[ 0.000000] GIC: enabling workaround for ITS: Socionext Synquacer pre-ITS
[ 0.000000] ITS@0x0000000030020000: allocated 524288 Devices
@aa400000 (flat, esz 8, psz 64K, shr 0)
[ 0.000000] ITS: using cache flushing for cmd queue
[ 0.000000] GICv3: using LPI property table @0x00000000aa080000
[ 0.000000] GIC: using cache flushing for LPI property table
[ 0.000000] GICv3: CPU0: using allocated LPI pending table
@0x00000000aa090000
[ 0.000000] random: get_random_bytes called from
start_kernel+0x469/0x5ca with crng_init=0
[ 0.000000] arch_timer: cp15 and mmio timer(s) running at 100.00MHz
(virt/phys).
[ 0.000000] clocksource: arch_sys_counter: mask: 0xffffffffffffff
max_cycles: 0x171024e7e0, max_idle_ns: 440795205315 ns
[ 0.000004] sched_clock: 56 bits at 100MHz, resolution 10ns, wraps
every 4398046511100ns
[ 0.000013] Switching to timer-based delay loop, resolution 10ns
[ 0.000890] Console: colour dummy device 80x30
[ 0.001344] printk: console [tty0] enabled
[ 0.001389] Calibrating delay loop (skipped), value calculated
using timer frequency.. 200.00 BogoMIPS (lpj=1000000)
[ 0.001410] pid_max: default: 32768 minimum: 301
[ 0.001561] Mount-cache hash table entries: 2048 (order: 1, 8192
bytes, linear)
[ 0.001581] Mountpoint-cache hash table entries: 2048 (order: 1,
8192 bytes, linear)
[ 0.002112] CPU: Testing write buffer coherency: ok
[ 0.002637] CPU0: thread -1, cpu 0, socket 0, mpidr 80000000
[ 0.002926] Setting up static identity map for 0x80400000 - 0x80400160
[ 0.003448] rcu: Hierarchical SRCU implementation.
[ 0.003601] Platform MSI: gic-its@30020000 domain created
[ 0.003669] PCI/MSI:
/interrupt-controller@30000000/gic-its@30020000 domain created
[ 0.004751] Remapping and enabling EFI services.
[ 0.005305] smp: Bringing up secondary CPUs ...
[ 0.005895] GICv3: CPU1: found redistributor 1 region 0:0x0000000030420000
[ 0.005919] GICv3: CPU1: using allocated LPI pending table
@0x00000000aa0a0000
[ 0.005940] CPU1: thread -1, cpu 1, socket 0, mpidr 80000001
[ 0.011149] GICv3: CPU2: found redistributor 100 region 0:0x0000000030440000
[ 0.011179] GICv3: CPU2: using allocated LPI pending table
@0x00000000aa0b0000
[ 0.011203] CPU2: thread -1, cpu 0, socket 1, mpidr 80000100
[ 0.014242] GICv3: CPU3: found redistributor 101 region 0:0x0000000030460000
[ 0.014264] GICv3: CPU3: using allocated LPI pending table
@0x00000000aa0c0000
[ 0.014284] CPU3: thread -1, cpu 1, socket 1, mpidr 80000101
[ 0.019622] GICv3: CPU4: found redistributor 200 region 0:0x0000000030480000
[ 0.019650] GICv3: CPU4: using allocated LPI pending table
@0x00000000aa0d0000
[ 0.019675] CPU4: thread -1, cpu 0, socket 2, mpidr 80000200
[ 0.022737] GICv3: CPU5: found redistributor 201 region 0:0x00000000304a0000
[ 0.022759] GICv3: CPU5: using allocated LPI pending table
@0x00000000aa0e0000
[ 0.022777] CPU5: thread -1, cpu 1, socket 2, mpidr 80000201
[ 0.028146] GICv3: CPU6: found redistributor 300 region 0:0x00000000304c0000
[ 0.028174] GICv3: CPU6: using allocated LPI pending table
@0x00000000aa0f0000
[ 0.028196] CPU6: thread -1, cpu 0, socket 3, mpidr 80000300
[ 0.031213] GICv3: CPU7: found redistributor 301 region 0:0x00000000304e0000
[ 0.031239] GICv3: CPU7: using allocated LPI pending table
@0x00000000aa100000
[ 0.031256] CPU7: thread -1, cpu 1, socket 3, mpidr 80000301
[ 0.036606] GICv3: CPU8: found redistributor 400 region 0:0x0000000030500000
[ 0.036634] GICv3: CPU8: using allocated LPI pending table
@0x00000000aa110000
[ 0.036657] CPU8: thread -1, cpu 0, socket 4, mpidr 80000400
[ 0.039719] GICv3: CPU9: found redistributor 401 region 0:0x0000000030520000
[ 0.039740] GICv3: CPU9: using allocated LPI pending table
@0x00000000aa120000
[ 0.039757] CPU9: thread -1, cpu 1, socket 4, mpidr 80000401
[ 0.045156] GICv3: CPU10: found redistributor 500 region 0:0x0000000030540000
[ 0.045187] GICv3: CPU10: using allocated LPI pending table
@0x00000000aa130000
[ 0.045210] CPU10: thread -1, cpu 0, socket 5, mpidr 80000500
[ 0.048241] GICv3: CPU11: found redistributor 501 region 0:0x0000000030560000
[ 0.048263] GICv3: CPU11: using allocated LPI pending table
@0x00000000aa140000
[ 0.048282] CPU11: thread -1, cpu 1, socket 5, mpidr 80000501
[ 0.053651] GICv3: CPU12: found redistributor 600 region 0:0x0000000030580000
[ 0.053681] GICv3: CPU12: using allocated LPI pending table
@0x00000000aa150000
[ 0.053706] CPU12: thread -1, cpu 0, socket 6, mpidr 80000600
[ 0.056742] GICv3: CPU13: found redistributor 601 region 0:0x00000000305a0000
[ 0.056765] GICv3: CPU13: using allocated LPI pending table
@0x00000000aa160000
[ 0.056785] CPU13: thread -1, cpu 1, socket 6, mpidr 80000601
[ 0.062113] GICv3: CPU14: found redistributor 700 region 0:0x00000000305c0000
[ 0.062144] GICv3: CPU14: using allocated LPI pending table
@0x00000000aa170000
[ 0.062166] CPU14: thread -1, cpu 0, socket 7, mpidr 80000700
[ 0.065238] GICv3: CPU15: found redistributor 701 region 0:0x00000000305e0000
[ 0.065263] GICv3: CPU15: using allocated LPI pending table
@0x00000000aa180000
[ 0.065282] CPU15: thread -1, cpu 1, socket 7, mpidr 80000701
[ 0.070661] GICv3: CPU16: found redistributor 800 region 0:0x0000000030600000
[ 0.070691] GICv3: CPU16: using allocated LPI pending table
@0x00000000aa190000
[ 0.070716] CPU16: thread -1, cpu 0, socket 8, mpidr 80000800
[ 0.073748] GICv3: CPU17: found redistributor 801 region 0:0x0000000030620000
[ 0.073774] GICv3: CPU17: using allocated LPI pending table
@0x00000000aa1a0000
[ 0.073794] CPU17: thread -1, cpu 1, socket 8, mpidr 80000801
[ 0.079132] GICv3: CPU18: found redistributor 900 region 0:0x0000000030640000
[ 0.079163] GICv3: CPU18: using allocated LPI pending table
@0x00000000aa1b0000
[ 0.079187] CPU18: thread -1, cpu 0, socket 9, mpidr 80000900
[ 0.082216] GICv3: CPU19: found redistributor 901 region 0:0x0000000030660000
[ 0.082239] GICv3: CPU19: using allocated LPI pending table
@0x00000000aa1c0000
[ 0.082257] CPU19: thread -1, cpu 1, socket 9, mpidr 80000901
[ 0.087755] GICv3: CPU20: found redistributor a00 region 0:0x0000000030680000
[ 0.087788] GICv3: CPU20: using allocated LPI pending table
@0x00000000aa1d0000
[ 0.087811] CPU20: thread -1, cpu 0, socket 10, mpidr 80000a00
[ 0.090897] GICv3: CPU21: found redistributor a01 region 0:0x00000000306a0000
[ 0.090922] GICv3: CPU21: using allocated LPI pending table
@0x00000000aa1e0000
[ 0.090939] CPU21: thread -1, cpu 1, socket 10, mpidr 80000a01
[ 0.096296] GICv3: CPU22: found redistributor b00 region 0:0x00000000306c0000
[ 0.096329] GICv3: CPU22: using allocated LPI pending table
@0x00000000aa1f0000
[ 0.096353] CPU22: thread -1, cpu 0, socket 11, mpidr 80000b00
[ 0.099356] GICv3: CPU23: found redistributor b01 region 0:0x00000000306e0000
[ 0.099381] GICv3: CPU23: using allocated LPI pending table
@0x00000000aa200000
[ 0.099400] CPU23: thread -1, cpu 1, socket 11, mpidr 80000b01
[ 0.099506] smp: Brought up 1 node, 24 CPUs
[ 0.100163] SMP: Total of 24 processors activated (4800.00 BogoMIPS).
[ 0.100175] CPU: All CPU(s) started in SVC mode.
[ 0.101193] devtmpfs: initialized
[ 0.103698] VFP support v0.3: implementor 41 architecture 3 part 40
variant 3 rev 4
[ 0.103980] clocksource: jiffies: mask: 0xffffffff max_cycles:
0xffffffff, max_idle_ns: 19112604462750000 ns
[ 0.104009] futex hash table entries: 8192 (order: 7, 524288 bytes, linear)
[ 0.106670] pinctrl core: initialized pinctrl subsystem
[ 0.107566] thermal_sys: Registered thermal governor 'step_wise'
[ 0.107754] SMBIOS 3.3.0 present.
[ 0.107788] DMI: Socionext SynQuacer E-series DeveloperBox, BIOS
build #1 Feb 20 2020
[ 0.108185] NET: Registered protocol family 16
[ 0.109556] DMA: preallocated 256 KiB pool for atomic coherent allocations
[ 0.110957] cpuidle: using governor menu
[ 0.111063] No ATAGs?
[ 0.111467] hw-breakpoint: found 5 (+1 reserved) breakpoint and 4
watchpoint registers.
[ 0.111490] hw-breakpoint: maximum watchpoint size is 8 bytes.
[ 0.112874] Serial: AMBA PL011 UART driver
[ 0.114349] OF: translation of DMA address(0) to CPU address failed
node(/uart@2a400000)
[ 0.114421] 2a400000.uart: ttyAMA0 at MMIO 0x2a400000 (irq = 22,
base_baud = 0) is a PL011 rev3
[ 1.117194] printk: console [ttyAMA0] enabled
[ 1.135592] AT91: Could not find identification node
[ 1.136261] iommu: Default domain type: Translated
[ 1.146225] vgaarb: loaded
[ 1.149407] SCSI subsystem initialized
[ 1.153506] usbcore: registered new interface driver usbfs
[ 1.159042] usbcore: registered new interface driver hub
[ 1.164477] usbcore: registered new device driver usb
[ 1.169950] pps_core: LinuxPPS API ver. 1 registered
[ 1.174911] pps_core: Software ver. 5.3.6 - Copyright 2005-2007
Rodolfo Giometti <giometti@linux.it>
[ 1.184062] PTP clock support registered
[ 1.188042] EDAC MC: Ver: 3.0.0
[ 1.191660] Registered efivars operations
[ 1.196838] clocksource: Switched to clocksource arch_sys_counter
[ 2.103835] NET: Registered protocol family 2
[ 2.108658] tcp_listen_portaddr_hash hash table entries: 512
(order: 0, 6144 bytes, linear)
[ 2.117044] TCP established hash table entries: 8192 (order: 3,
32768 bytes, linear)
[ 2.124854] TCP bind hash table entries: 8192 (order: 4, 65536 bytes, linear)
[ 2.132103] TCP: Hash tables configured (established 8192 bind 8192)
[ 2.138585] UDP hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.145223] UDP-Lite hash table entries: 512 (order: 2, 16384 bytes, linear)
[ 2.152446] NET: Registered protocol family 1
[ 2.157108] RPC: Registered named UNIX socket transport module.
[ 2.163026] RPC: Registered udp transport module.
[ 2.167746] RPC: Registered tcp transport module.
[ 2.172445] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 2.178897] PCI: CLS 0 bytes, default 64
[ 2.183052] Trying to unpack rootfs image as initramfs...
[ 3.413006] Freeing initrd memory: 22816K
[ 3.418665] Initialise system trusted keyrings
[ 3.423276] workingset: timestamp_bits=30 max_order=19 bucket_order=0
[ 3.434628] squashfs: version 4.0 (2009/01/31) Phillip Lougher
[ 3.441097] NFS: Registering the id_resolver key type
[ 3.446175] Key type id_resolver registered
[ 3.450375] Key type id_legacy registered
[ 3.454388] nfs4filelayout_init: NFSv4 File Layout Driver Registering...
[ 3.461111] ntfs: driver 2.1.32 [Flags: R/O].
[ 3.465747] Key type asymmetric registered
[ 3.469857] Asymmetric key parser 'x509' registered
[ 3.474765] bounce: pool size: 64 pages
[ 3.478629] Block layer SCSI generic (bsg) driver version 0.4
loaded (major 247)
[ 3.486027] io scheduler mq-deadline registered
[ 3.490564] io scheduler kyber registered
[ 3.500170] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.508318] pci-host-generic 60000000.pcie: host bridge
/pcie@60000000 ranges:
[ 3.515556] pci-host-generic 60000000.pcie: IO
0x0067f00000..0x0067f0ffff -> 0x0000000000
[ 3.524276] pci-host-generic 60000000.pcie: MEM
0x0068000000..0x006fffffff -> 0x0068000000
[ 3.532987] pci-host-generic 60000000.pcie: MEM
0x3e00000000..0x3effffffff -> 0x3e00000000
[ 3.543045] pci-host-generic 60000000.pcie: ECAM at [mem
0x60000000-0x67efffff] for [bus 00-7e]
[ 3.551873] pci-host-generic 60000000.pcie: PCI host bridge to bus 0000:00
[ 3.558764] pci_bus 0000:00: root bus resource [bus 00-7e]
[ 3.564250] pci_bus 0000:00: root bus resource [io 0x0000-0xffff]
[ 3.570438] pci_bus 0000:00: root bus resource [mem 0x68000000-0x6fffffff]
[ 3.577322] pci_bus 0000:00: root bus resource [mem
0x3e00000000-0x3effffffff]
[ 3.584574] pci 0000:00:00.0: [1b21:1184] type 01 class 0x060400
[ 3.590646] pci 0000:00:00.0: enabling Extended Tags
[ 3.595677] pci 0000:00:00.0: PME# supported from D0 D3hot D3cold
[ 3.602874] PCI: bus0: Fast back to back transfers disabled
[ 3.608585] pci 0000:01:01.0: [1b21:1184] type 01 class 0x060400
[ 3.614645] pci 0000:01:01.0: enabling Extended Tags
[ 3.619672] pci 0000:01:01.0: PME# supported from D0 D3hot D3cold
[ 3.625969] pci 0000:01:03.0: [1b21:1184] type 01 class 0x060400
[ 3.632040] pci 0000:01:03.0: enabling Extended Tags
[ 3.637066] pci 0000:01:03.0: PME# supported from D0 D3hot D3cold
[ 3.643363] pci 0000:01:05.0: [1b21:1184] type 01 class 0x060400
[ 3.649431] pci 0000:01:05.0: enabling Extended Tags
[ 3.654449] pci 0000:01:05.0: PME# supported from D0 D3hot D3cold
[ 3.660753] pci 0000:01:07.0: [1b21:1184] type 01 class 0x060400
[ 3.666822] pci 0000:01:07.0: enabling Extended Tags
[ 3.671844] pci 0000:01:07.0: PME# supported from D0 D3hot D3cold
[ 3.678832] PCI: bus1: Fast back to back transfers disabled
[ 3.684517] pci 0000:02:00.0: [1b21:0612] type 00 class 0x010601
[ 3.690564] pci 0000:02:00.0: reg 0x10: [io 0x0028-0x002f]
[ 3.696147] pci 0000:02:00.0: reg 0x14: [io 0x0034-0x0037]
[ 3.701738] pci 0000:02:00.0: reg 0x18: [io 0x0020-0x0027]
[ 3.707329] pci 0000:02:00.0: reg 0x1c: [io 0x0030-0x0033]
[ 3.712912] pci 0000:02:00.0: reg 0x20: [io 0x0000-0x001f]
[ 3.718503] pci 0000:02:00.0: reg 0x24: [mem 0x68100000-0x681001ff]
[ 3.724781] pci 0000:02:00.0: reg 0x30: [mem 0xffff0000-0xffffffff pref]
[ 3.732590] PCI: bus2: Fast back to back transfers disabled
[ 3.738174] pci_bus 0000:02: busn_res: [bus 02-7e] end is updated to 02
[ 3.745751] PCI: bus3: Fast back to back transfers enabled
[ 3.751247] pci_bus 0000:03: busn_res: [bus 03-7e] end is updated to 03
[ 3.757969] pci 0000:04:00.0: [1912:0014] type 00 class 0x0c0330
[ 3.764012] pci 0000:04:00.0: reg 0x10: [mem 0x68000000-0x68001fff 64bit]
[ 3.770943] pci 0000:04:00.0: PME# supported from D0 D3hot D3cold
[ 3.807778] PCI: bus4: Fast back to back transfers disabled
[ 3.813353] pci_bus 0000:04: busn_res: [bus 04-7e] end is updated to 04
[ 3.820943] PCI: bus5: Fast back to back transfers enabled
[ 3.826430] pci_bus 0000:05: busn_res: [bus 05-7e] end is updated to 05
[ 3.833058] pci_bus 0000:01: busn_res: [bus 01-7e] end is updated to 05
[ 3.839709] pci 0000:00:00.0: BAR 8: assigned [mem 0x68000000-0x681fffff]
[ 3.846498] pci 0000:00:00.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 3.852603] pci 0000:01:01.0: BAR 8: assigned [mem 0x68000000-0x680fffff]
[ 3.859402] pci 0000:01:05.0: BAR 8: assigned [mem 0x68100000-0x681fffff]
[ 3.866190] pci 0000:01:01.0: BAR 7: assigned [io 0x1000-0x1fff]
[ 3.872294] pci 0000:02:00.0: BAR 6: assigned [mem
0x68000000-0x6800ffff pref]
[ 3.879529] pci 0000:02:00.0: BAR 5: assigned [mem 0x68010000-0x680101ff]
[ 3.886321] pci 0000:02:00.0: BAR 4: assigned [io 0x1000-0x101f]
[ 3.892425] pci 0000:02:00.0: BAR 0: assigned [io 0x1020-0x1027]
[ 3.898529] pci 0000:02:00.0: BAR 2: assigned [io 0x1028-0x102f]
[ 3.904627] pci 0000:02:00.0: BAR 1: assigned [io 0x1030-0x1033]
[ 3.910730] pci 0000:02:00.0: BAR 3: assigned [io 0x1034-0x1037]
[ 3.916834] pci 0000:01:01.0: PCI bridge to [bus 02]
[ 3.921799] pci 0000:01:01.0: bridge window [io 0x1000-0x1fff]
[ 3.927903] pci 0000:01:01.0: bridge window [mem 0x68000000-0x680fffff]
[ 3.934697] pci 0000:01:03.0: PCI bridge to [bus 03]
[ 3.939682] pci 0000:04:00.0: BAR 0: assigned [mem
0x68100000-0x68101fff 64bit]
[ 3.947012] pci 0000:01:05.0: PCI bridge to [bus 04]
[ 3.951979] pci 0000:01:05.0: bridge window [mem 0x68100000-0x681fffff]
[ 3.958780] pci 0000:01:07.0: PCI bridge to [bus 05]
[ 3.963754] pci 0000:00:00.0: PCI bridge to [bus 01-05]
[ 3.968985] pci 0000:00:00.0: bridge window [io 0x1000-0x1fff]
[ 3.975081] pci 0000:00:00.0: bridge window [mem 0x68000000-0x681fffff]
[ 3.981914] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.990313] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 3.998662] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.007005] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.015339] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.023694] pci 0000:04:00.0: enabling device (0140 -> 0142)
[ 4.029447] OF: translation of DMA address(0) to CPU address failed
node(/pcie@70000000)
[ 4.037570] pci-host-generic 70000000.pcie: host bridge
/pcie@70000000 ranges:
[ 4.044805] pci-host-generic 70000000.pcie: IO
0x0077f00000..0x0077f0ffff -> 0x0000000000
[ 4.053523] pci-host-generic 70000000.pcie: MEM
0x0078000000..0x007fffffff -> 0x0078000000
[ 4.062236] pci-host-generic 70000000.pcie: MEM
0x3f00000000..0x3fffffffff -> 0x3f00000000
[ 4.071308] vmap allocation for size 1052672 failed: use
vmalloc=<size> to increase size
[ 4.079411] pci-host-generic 70000000.pcie: ECAM ioremap failed
[ 4.085525] pci-host-generic: probe of 70000000.pcie failed with error -12
[ 4.126494] Serial: 8250/16550 driver, 5 ports, IRQ sharing enabled
[ 4.134170] OF: translation of DMA address(0) to CPU address failed
node(/uart@51040000)
[ 4.142748] 51040000.uart: ttyS1 at MMIO 0x51040000 (irq = 23,
base_baud = 3906250) is a 16550A
[ 4.152099] SuperH (H)SCI(F) driver initialized
[ 4.156953] msm_serial: driver initialized
[ 4.161103] STMicroelectronics ASC driver initialized
[ 4.166594] STM32 USART driver initialized
[ 4.178363] brd: module loaded
[ 4.192943] loop: module loaded
[ 4.197009] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.205330] ahci 0000:02:00.0: SSS flag set, parallel bus scan disabled
[ 4.212015] ahci 0000:02:00.0: AHCI 0001.0200 32 slots 2 ports 6
Gbps 0x3 impl SATA mode
[ 4.220122] ahci 0000:02:00.0: flags: 64bit ncq sntf stag led clo
pmp pio slum part ccc sxs
[ 4.229431] scsi host0: ahci
[ 4.232675] scsi host1: ahci
[ 4.235694] ata1: SATA max UDMA/133 abar m512@0x68010000 port
0x68010100 irq 35
[ 4.243033] ata2: SATA max UDMA/133 abar m512@0x68010000 port
0x68010180 irq 35
[ 4.253906] libphy: Fixed MDIO Bus: probed
[ 4.258796] CAN device driver interface
[ 4.262933] bgmac_bcma: Broadcom 47xx GBit MAC driver loaded
[ 4.268942] e1000e: Intel(R) PRO/1000 Network Driver - 3.2.6-k
[ 4.274772] e1000e: Copyright(c) 1999 - 2015 Intel Corporation.
[ 4.280739] igb: Intel(R) Gigabit Ethernet Network Driver - version 5.6.0-k
[ 4.287707] igb: Copyright (c) 2007-2014 Intel Corporation.
[ 4.294603] pegasus: v0.9.3 (2013/04/25), Pegasus/Pegasus II USB
Ethernet driver
[ 4.302042] usbcore: registered new interface driver pegasus
[ 4.307736] usbcore: registered new interface driver asix
[ 4.313150] usbcore: registered new interface driver ax88179_178a
[ 4.319267] usbcore: registered new interface driver cdc_ether
[ 4.325122] usbcore: registered new interface driver smsc75xx
[ 4.330901] usbcore: registered new interface driver smsc95xx
[ 4.336663] usbcore: registered new interface driver net1080
[ 4.342350] usbcore: registered new interface driver cdc_subset
[ 4.348295] usbcore: registered new interface driver zaurus
[ 4.353894] usbcore: registered new interface driver cdc_ncm
[ 4.360347] ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
[ 4.366891] ehci-pci: EHCI PCI platform driver
[ 4.371359] ehci-platform: EHCI generic platform driver
[ 4.376646] ehci-orion: EHCI orion driver
[ 4.380714] SPEAr-ehci: EHCI SPEAr driver
[ 4.384767] ehci-st: EHCI STMicroelectronics driver
[ 4.389704] ehci-exynos: EHCI Exynos driver
[ 4.393931] ehci-atmel: EHCI Atmel driver
[ 4.397991] tegra-ehci: Tegra EHCI driver
[ 4.402048] ohci_hcd: USB 1.1 'Open' Host Controller (OHCI) Driver
[ 4.408245] ohci-pci: OHCI PCI platform driver
[ 4.412714] ohci-platform: OHCI generic platform driver
[ 4.418003] SPEAr-ohci: OHCI SPEAr driver
[ 4.422057] ohci-st: OHCI STMicroelectronics driver
[ 4.426995] ohci-atmel: OHCI Atmel driver
[ 4.431085] OF: translation of DMA address(0) to CPU address failed
node(/pcie@60000000)
[ 4.439259] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 4.444497] xhci_hcd 0000:04:00.0: new USB bus registered, assigned
bus number 1
[ 4.457324] xhci_hcd 0000:04:00.0: hcc params 0x014051cf hci
version 0x100 quirks 0x0000000100000410
[ 4.467671] hub 1-0:1.0: USB hub found
[ 4.471449] hub 1-0:1.0: 4 ports detected
[ 4.475927] xhci_hcd 0000:04:00.0: xHCI Host Controller
[ 4.481175] xhci_hcd 0000:04:00.0: new USB bus registered, assigned
bus number 2
[ 4.488585] xhci_hcd 0000:04:00.0: Host supports USB 3.0 SuperSpeed
[ 4.494924] usb usb2: We don't know the algorithms for LPM for this
host, disabling LPM.
[ 4.503372] hub 2-0:1.0: USB hub found
[ 4.507155] hub 2-0:1.0: 4 ports detected
[ 4.511847] usbcore: registered new interface driver usb-storage
[ 4.519900] i2c /dev entries driver
[ 4.528493] /cpus/cpu@0: unsupported enable-method property: psci
[ 4.537114] sdhci: Secure Digital Host Controller Interface driver
[ 4.543297] sdhci: Copyright(c) Pierre Ossman
[ 4.548328] Synopsys Designware Multimedia Card Interface Driver
[ 4.554829] sdhci-pltfm: SDHCI platform and OF driver helper
[ 4.562104] ledtrig-cpu: registered to indicate activity on CPUs
[ 4.568594] usbcore: registered new interface driver usbhid
[ 4.574168] usbhid: USB HID core driver
[ 4.579546] drop_monitor: Initializing network drop monitor service
[ 4.586552] NET: Registered protocol family 10
[ 4.591887] Segment Routing with IPv6
[ 4.595614] sit: IPv6, IPv4 and MPLS over IPv4 tunneling driver
[ 4.602085] NET: Registered protocol family 17
[ 4.606537] can: controller area network core (rev 20170425 abi 9)
[ 4.612780] NET: Registered protocol family 29
[ 4.617248] can: raw protocol (rev 20170425)
[ 4.621524] can: broadcast manager protocol (rev 20170425 t)
[ 4.627198] can: netlink gateway (rev 20190810) max_hops=1
[ 4.632967] Key type dns_resolver registered
[ 4.637328] Registering SWP/SWPB emulation handler
[ 4.642410] Loading compiled-in X.509 certificates
[ 4.688987] OF: translation of DMA address(0) to CPU address failed
node(/gpio-keys)
[ 4.696780] irq: no irq domain found for interrupt-controller@510c0000 !
[ 4.703556] gpio-keys gpio-keys: Found button without gpio or irq
[ 4.709673] gpio-keys: probe of gpio-keys failed with error -22
[ 4.715621] hctosys: unable to open rtc device (rtc0)
[ 4.721044] uart-pl011 2a400000.uart: no DMA platform data
[ 4.746912] ata1: SATA link up 6.0 Gbps (SStatus 133 SControl 300)
[ 4.754022] ata1.00: ATA-10: WDC WD10EZEX-22MFCA0, 01.01A01, max UDMA/133
[ 4.760826] ata1.00: 1953525168 sectors, multi 16: LBA48 NCQ (depth 32), AA
[ 4.768960] ata1.00: configured for UDMA/133
[ 4.773637] scsi 0:0:0:0: Direct-Access ATA WDC
WD10EZEX-22M 1A01 PQ: 0 ANSI: 5
[ 4.782675] sd 0:0:0:0: [sda] 1953525168 512-byte logical blocks:
(1.00 TB/932 GiB)
[ 4.790362] sd 0:0:0:0: [sda] 4096-byte physical blocks
[ 4.795635] sd 0:0:0:0: [sda] Write Protect is off
[ 4.800505] sd 0:0:0:0: [sda] Write cache: enabled, read cache:
enabled, doesn't support DPO or FUA
[ 4.846916] usb 1-3: new high-speed USB device number 2 using xhci_hcd
[ 4.865348] sda: sda1 sda2 sda3 sda4
[ 4.871475] sd 0:0:0:0: [sda] Attached SCSI disk
[ 4.887962] usb-storage 1-3:1.0: USB Mass Storage device detected
[ 4.894715] scsi host2: usb-storage 1-3:1.0
[ 5.109059] ata2: SATA link down (SStatus 0 SControl 300)
[ 5.117814] Freeing unused kernel memory: 2048K
[ 5.122861] Run /init as init process
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [linux-next:master 2356/3478] sound/usb/mixer_s1810c.c:178:9: warning: missing braces around initializer
From: kbuild test robot @ 2020-02-20 18:09 UTC (permalink / raw)
To: kbuild-all
[-- Attachment #1: Type: text/plain, Size: 3115 bytes --]
tree: https://git.kernel.org/pub/scm/linux/kernel/git/next/linux-next.git master
head: f4aba10148cd290bbbf4d0efae0e9789a13c2778
commit: 8dc5efe3d17cd572328ac4f1ebde629c83317f54 [2356/3478] ALSA: usb-audio: Add support for Presonus Studio 1810c
config: x86_64-randconfig-a003-20200220 (attached as .config)
compiler: gcc-4.9 (Debian 4.9.2-10+deb8u1) 4.9.2
reproduce:
git checkout 8dc5efe3d17cd572328ac4f1ebde629c83317f54
# save the attached .config to linux build tree
make ARCH=x86_64
If you fix the issue, kindly add following tag
Reported-by: kbuild test robot <lkp@intel.com>
All warnings (new ones prefixed by >>):
sound/usb/mixer_s1810c.c: In function 'snd_sc1810c_get_status_field':
>> sound/usb/mixer_s1810c.c:178:9: warning: missing braces around initializer [-Wmissing-braces]
struct s1810c_state_packet pkt_out = { 0 };
^
sound/usb/mixer_s1810c.c:178:9: warning: (near initialization for 'pkt_out.fields') [-Wmissing-braces]
sound/usb/mixer_s1810c.c:179:9: warning: missing braces around initializer [-Wmissing-braces]
struct s1810c_state_packet pkt_in = { 0 };
^
sound/usb/mixer_s1810c.c:179:9: warning: (near initialization for 'pkt_in.fields') [-Wmissing-braces]
vim +178 sound/usb/mixer_s1810c.c
164
165 /*
166 * When opening Universal Control the program periodicaly
167 * sends and receives state packets for syncinc state between
168 * the device and the host.
169 *
170 * Note that if we send only the request to get data back we'll
171 * get an error, we need to first send an empty state packet and
172 * then ask to receive a filled. Their seqnumbers must also match.
173 */
174 static int
175 snd_sc1810c_get_status_field(struct usb_device *dev,
176 u32 *field, int field_idx, uint16_t *seqnum)
177 {
> 178 struct s1810c_state_packet pkt_out = { 0 };
179 struct s1810c_state_packet pkt_in = { 0 };
180 int ret = 0;
181
182 pkt_out.fields[SC1810C_STATE_F1_IDX] = SC1810C_SET_STATE_F1;
183 pkt_out.fields[SC1810C_STATE_F2_IDX] = SC1810C_SET_STATE_F2;
184 ret = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
185 SC1810C_SET_STATE_REQ,
186 SC1810C_SET_STATE_REQTYPE,
187 (*seqnum), 0, &pkt_out, sizeof(pkt_out));
188 if (ret < 0) {
189 dev_warn(&dev->dev, "could not send state packet (%d)\n", ret);
190 return ret;
191 }
192
193 ret = snd_usb_ctl_msg(dev, usb_rcvctrlpipe(dev, 0),
194 SC1810C_GET_STATE_REQ,
195 SC1810C_GET_STATE_REQTYPE,
196 (*seqnum), 0, &pkt_in, sizeof(pkt_in));
197 if (ret < 0) {
198 dev_warn(&dev->dev, "could not get state field %u (%d)\n",
199 field_idx, ret);
200 return ret;
201 }
202
203 (*field) = pkt_in.fields[field_idx];
204 (*seqnum)++;
205 return 0;
206 }
207
---
0-DAY CI Kernel Test Service, Intel Corporation
https://lists.01.org/hyperkitty/list/kbuild-all(a)lists.01.org
[-- Attachment #2: config.gz --]
[-- Type: application/gzip, Size: 39795 bytes --]
^ permalink raw reply
* Re: [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
From: Frédéric Pierret @ 2020-02-20 18:09 UTC (permalink / raw)
To: Ilia Mirkin
Cc: David Airlie, nouveau, LKML, dri-devel, Ben Skeggs, Daniel Vetter
In-Reply-To: <CAKb7Uvh8Ob592LOizH9FGZz5ag=VJ3R=dh0G5iZSg2-JzWZFMQ-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
[-- Attachment #1.1.1: Type: text/plain, Size: 2574 bytes --]
Hi Ilia,
Well...if Ben made it's own version you mean using my patch given on comment https://bugzilla.kernel.org/show_bug.cgi?id=206299#c9 and then adding commit message without quoting me as reporter ok...
At least, upstream is patched.
Best,
Frédéric
On 2020-02-20 18:32, Ilia Mirkin wrote:
> Hi Frédéric,
>
> It appears Ben made his own version of this patch (probably based on
> the one you added to the kernel bz), and it's already upstream:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2
>
> Cheers,
>
> -ilia
>
> On Thu, Feb 20, 2020 at 12:19 PM Frédéric Pierret
> <frederic.pierret-aAmZIGRXKFlg9hUCZPvPmw@public.gmane.org> wrote:
>>
>> Hi,
>> Is anything missing here? How can I get this merged?
>>
>> Best regards,
>> Frédéric Pierret
>>
>> On 2020-02-08 20:43, Frédéric Pierret wrote:
>>> Pointer to structure array is assumed not NULL by default. It has
>>> the consequence to raise a kernel panic when it's not the case.
>>>
>>> Basically, running at least a RTX2080TI on Xen makes a bad mmio error
>>> which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
>>> code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
>>> which is the reason of the kernel panic. Simply check if the pointer
>>> is not NULL before continuing.
>>>
>>> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
>>> Cc: stable-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
>>> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
>>> ---
>>> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> index bcf32d92ee5a..50e3539f33d2 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
>>>
>>> if (debug > subdev->debug)
>>> return;
>>> + if (!mthd)
>>> + return;
>>>
>>> for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
>>> u32 base = chan->head * mthd->addr;
>>>
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
[-- Attachment #1.2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
[-- Attachment #2: Type: text/plain, Size: 182 bytes --]
_______________________________________________
Nouveau mailing list
Nouveau-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
https://lists.freedesktop.org/mailman/listinfo/nouveau
^ permalink raw reply
* [PATCH] arm64: dts: freescale: sl28: disable unused network port
From: Michael Walle @ 2020-02-20 18:09 UTC (permalink / raw)
To: devicetree, linux-kernel, linux-arm-kernel; +Cc: Shawn Guo, Michael Walle
By default (and on variant 3) the second network port is not available.
Disable it. Now that its disabled, we have to explicitly enable it again
for board variant 4.
Signed-off-by: Michael Walle <michael@walle.cc>
---
.../boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts | 1 +
arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts | 5 +++++
2 files changed, 6 insertions(+)
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
index f659e89face8..df212ed5bb94 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28-var4.dts
@@ -21,6 +21,7 @@
&enetc_port1 {
phy-handle = <&phy1>;
phy-connection-type = "rgmii-id";
+ status = "okay";
mdio {
#address-cells = <1>;
diff --git a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
index d221ed471cde..6b3e710f6a2b 100644
--- a/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
+++ b/arch/arm64/boot/dts/freescale/fsl-ls1028a-kontron-sl28.dts
@@ -35,6 +35,7 @@
&enetc_port0 {
phy-handle = <&phy0>;
phy-connection-type = "sgmii";
+ status = "okay";
mdio {
#address-cells = <1>;
@@ -48,6 +49,10 @@
};
};
+&enetc_port1 {
+ status = "disabled";
+};
+
&esdhc {
sd-uhs-sdr104;
sd-uhs-sdr50;
--
2.20.1
^ permalink raw reply related
* Re: [Nouveau] [PATCH] nv50_disp_chan_mthd: ensure mthd is not NULL
From: Frédéric Pierret @ 2020-02-20 18:09 UTC (permalink / raw)
To: Ilia Mirkin
Cc: Ben Skeggs, David Airlie, Daniel Vetter, dri-devel, nouveau, LKML
In-Reply-To: <CAKb7Uvh8Ob592LOizH9FGZz5ag=VJ3R=dh0G5iZSg2-JzWZFMQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 2495 bytes --]
Hi Ilia,
Well...if Ben made it's own version you mean using my patch given on comment https://bugzilla.kernel.org/show_bug.cgi?id=206299#c9 and then adding commit message without quoting me as reporter ok...
At least, upstream is patched.
Best,
Frédéric
On 2020-02-20 18:32, Ilia Mirkin wrote:
> Hi Frédéric,
>
> It appears Ben made his own version of this patch (probably based on
> the one you added to the kernel bz), and it's already upstream:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?h=v5.6-rc2&id=0e6176c6d286316e9431b4f695940cfac4ffe6c2
>
> Cheers,
>
> -ilia
>
> On Thu, Feb 20, 2020 at 12:19 PM Frédéric Pierret
> <frederic.pierret@qubes-os.org> wrote:
>>
>> Hi,
>> Is anything missing here? How can I get this merged?
>>
>> Best regards,
>> Frédéric Pierret
>>
>> On 2020-02-08 20:43, Frédéric Pierret wrote:
>>> Pointer to structure array is assumed not NULL by default. It has
>>> the consequence to raise a kernel panic when it's not the case.
>>>
>>> Basically, running at least a RTX2080TI on Xen makes a bad mmio error
>>> which causes having 'mthd' pointer to be NULL in 'channv50.c'. From the
>>> code, it's assumed to be not NULL by accessing directly 'mthd->data[0]'
>>> which is the reason of the kernel panic. Simply check if the pointer
>>> is not NULL before continuing.
>>>
>>> BugLink: https://bugzilla.kernel.org/show_bug.cgi?id=206299
>>> Cc: stable@vger.kernel.org
>>> Signed-off-by: Frédéric Pierret (fepitre) <frederic.pierret@qubes-os.org>
>>> ---
>>> drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c | 2 ++
>>> 1 file changed, 2 insertions(+)
>>>
>>> diff --git a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> index bcf32d92ee5a..50e3539f33d2 100644
>>> --- a/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> +++ b/drivers/gpu/drm/nouveau/nvkm/engine/disp/channv50.c
>>> @@ -74,6 +74,8 @@ nv50_disp_chan_mthd(struct nv50_disp_chan *chan, int debug)
>>>
>>> if (debug > subdev->debug)
>>> return;
>>> + if (!mthd)
>>> + return;
>>>
>>> for (i = 0; (list = mthd->data[i].mthd) != NULL; i++) {
>>> u32 base = chan->head * mthd->addr;
>>>
>>
>> _______________________________________________
>> Nouveau mailing list
>> Nouveau@lists.freedesktop.org
>> https://lists.freedesktop.org/mailman/listinfo/nouveau
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
^ 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.