* [Bug 98505] [radeon, amdgpu] Regression introduced in 4.8-rc3
From: bugzilla-daemon @ 2016-11-14 10:52 UTC (permalink / raw)
To: dri-devel
In-Reply-To: <bug-98505-502@http.bugs.freedesktop.org/>
[-- Attachment #1.1: Type: text/plain, Size: 311 bytes --]
https://bugs.freedesktop.org/show_bug.cgi?id=98505
--- Comment #28 from Peter Wu <peter@lekensteyn.nl> ---
Ok, when possible, please try to obtain a dmesg with CONFIG_ACPI_DEBUG=y and
the trace_state option as described above.
--
You are receiving this mail because:
You are the assignee for the bug.
[-- Attachment #1.2: Type: text/html, Size: 1089 bytes --]
[-- Attachment #2: Type: text/plain, Size: 160 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Qemu-devel] facing issue with qemu amd-v support
From: Paolo Bonzini @ 2016-11-14 10:51 UTC (permalink / raw)
To: Anand J, qemu-devel
In-Reply-To: <CANDALvkw3Su6NvA27vKJVyri4rwR-xPxH7Lqi5okmrQFo5_GDQ@mail.gmail.com>
On 14/11/2016 11:08, Anand J wrote:
> Hi,
>
> Further investigation to the issue revealed that this happens before the
> guest OS get to execute. KVM is not able to emulate a PF happened during a
> jump to 0x40000000.
>
> Folowing is the trace of instructions at which the emulation error is
> happening.
>
> ----------------
> IN:
> CR3: 00000000b8590000
> CR2: 0000000000000000
> 0x00000000000eeccf: setl %al
> 0x00000000000eecd2: movzbl %al,%eax
> 0x00000000000eecd5: neg %eax
> 0x00000000000eecd7: or $0x1,%eax
> 0x00000000000eecda: jmp 0xeece3
>
> ----------------
> IN:
> CR3: 00000000b8590000
> CR2: 0000000000000000
> 0x00000000000eece3: pop %ebx
> *0x00000000000eece4: ret *
>
> vmexit(0000004e, 0000000000000000, 0000000040000000, 0000000040000000)!
> CR2: 0000000000000000
> vmsave! 00000000b8592000
> FS: 0000000000000000 | 0000000000000000
> ----------------
>
> Bold ret instruction causes a VMEXIT due to page fault. Can anyone please
> help me figure out possible causes for this issue?
Sorry, I cannot really guess what's going on. All I can suggest is to
look at KVM's trace normally and under QEMU, and find the difference.
Paolo
> Thanks,
> Anand
>
> On Mon, Oct 24, 2016 at 2:35 PM, Anand J <anand.indukala@gmail.com> wrote:
>
>>
>> ---------- Forwarded message ----------
>> From: Anand J <anand.indukala@gmail.com>
>> Date: Mon, Oct 24, 2016 at 4:28 AM
>> Subject: facing issue with qemu amd-v support
>> To: qemu-discuss@nongnu.org
>>
>>
>> Hi,
>>
>> I'm running fedora-24_x86_64 inside qemu in software mode. I configured
>> KVM in the guest OS and want to run qemu inside the guest with kvm enabled.
>> But qemu is throwing the following error. Does anybody know how to fix this?
>>
>> KVM internal error. Suberror: 1
>> emulation failure
>> EAX=ffffffff EBX=4000004b ECX=00000000 EDX=000f5ea0
>> ESI=00000000 EDI=00000000 EBP=00000000 ESP=00006fd0
>> EIP=40000000 EFL=00000086 [--S--P-] CPL=0 II=0 A20=1 SMM=0 HLT=0
>> ES =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
>> CS =0008 00000000 ffffffff 00c09b00 DPL=0 CS32 [-RA]
>> SS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
>> DS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
>> FS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
>> GS =0010 00000000 ffffffff 00c09300 DPL=0 DS [-WA]
>> LDT=0000 00000000 0000ffff 00008200 DPL=0 LDT
>> TR =0000 00000000 0000ffff 00008b00 DPL=0 TSS32-busy
>> GDT= 000f7180 00000037
>> IDT= 000f71be 00000000
>> CR0=00000011 CR2=00000000 CR3=00000000 CR4=00000000
>> DR0=0000000000000000 DR1=0000000000000000 DR2=0000000000000000
>> DR3=0000000000000000
>> DR6=00000000ffff0ff0 DR7=0000000000000400
>> EFER=0000000000000000
>> Code=00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 <00> 00
>> 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
>> 00 00 00
>>
>>
>> Thanks,
>> Anand
>>
>>
>
^ permalink raw reply
* Re: [PATCH v2] kexec: Increase the upper limit for RAM segments
From: Xunlei Pang @ 2016-11-14 10:51 UTC (permalink / raw)
To: Sameer Goel, geoff; +Cc: kexec, bhe
In-Reply-To: <1478902871-13800-1-git-send-email-sgoel@codeaurora.org>
On 2016/11/12 at 06:21, Sameer Goel wrote:
> On a newer UEFI based Qualcomm target the number of system ram regions
> retrieved from /proc/iomem are ~40. So increasing the current hardcoded
> values to 64 from 16.
I am a little confused, memory regions from /proc/iomem should be MAX_MEMORY_RANGES used
as the elfcorehdr, while KEXEC_SEGMENT_MAX stands for the kexec segments passed to the kexec
syscall, like kernel image, initrd image, purgatory, etc.
Do you mean KEXEC_SEGMENT_MAX or MAX_MEMORY_RANGES?
Regards,
Xunlei
>
> Signed-off-by: Sameer Goel <sgoel@codeaurora.org>
> ---
> kexec/arch/arm64/kexec-arm64.h | 2 +-
> kexec/kexec-syscall.h | 2 +-
> 2 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/kexec/arch/arm64/kexec-arm64.h b/kexec/arch/arm64/kexec-arm64.h
> index bac62f8..bd4c20e 100644
> --- a/kexec/arch/arm64/kexec-arm64.h
> +++ b/kexec/arch/arm64/kexec-arm64.h
> @@ -11,7 +11,7 @@
> #include "image-header.h"
> #include "kexec.h"
>
> -#define KEXEC_SEGMENT_MAX 16
> +#define KEXEC_SEGMENT_MAX 64
>
> #define BOOT_BLOCK_VERSION 17
> #define BOOT_BLOCK_LAST_COMP_VERSION 16
> diff --git a/kexec/kexec-syscall.h b/kexec/kexec-syscall.h
> index c0d0bea..f84c937 100644
> --- a/kexec/kexec-syscall.h
> +++ b/kexec/kexec-syscall.h
> @@ -115,7 +115,7 @@ static inline long kexec_file_load(int kernel_fd, int initrd_fd,
> #define KEXEC_ARCH_MIPS ( 8 << 16)
> #define KEXEC_ARCH_CRIS (76 << 16)
>
> -#define KEXEC_MAX_SEGMENTS 16
> +#define KEXEC_MAX_SEGMENTS 64
>
> #ifdef __i386__
> #define KEXEC_ARCH_NATIVE KEXEC_ARCH_386
_______________________________________________
kexec mailing list
kexec@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/kexec
^ permalink raw reply
* Re: [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: Arnd Bergmann
Cc: linuxppc-dev@lists.ozlabs.org, Geert Uytterhoeven,
Greg Kroah-Hartman, Yangbo Lu, Simon Horman, Magnus Damm,
Rob Herring, Mark Rutland, devicetree@vger.kernel.org, Dirk Behme,
linux-kernel@vger.kernel.org, Linux-Renesas,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <25057157.YlGi2v6RrE@wuerfel>
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [PATCH v2 7/7] soc: renesas: Identify SoC and register with the SoC bus
From: Geert Uytterhoeven @ 2016-11-14 10:51 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <25057157.YlGi2v6RrE@wuerfel>
Hi Arnd,
On Thu, Nov 10, 2016 at 12:37 PM, Arnd Bergmann <arnd@arndb.de> wrote:
> On Thursday, November 10, 2016 11:19:20 AM CET Geert Uytterhoeven wrote:
>> On Wed, Nov 9, 2016 at 5:55 PM, Arnd Bergmann <arnd@arndb.de> wrote:
>> > On Monday, October 31, 2016 12:30:55 PM CET Geert Uytterhoeven wrote:
>> >> v2:
>> >> - Drop SoC families and family names; use fixed "Renesas" instead,
>> >
>> > I think I'd rather have seen the family names left in there, but it's
>> > not important, so up to you.
>>
>> They're not useful for matching, as family names may change anytime, and don't
>> always say much about the hardware capabilities.
>> E.g. SH-Mobile -> R-Mobile -> R-Car | RZ/A | RZ/G
>> Some SH-Mobile (even some R-Car) parts are SuperH only, others have ARM and
>> SuperH.
>>
>> At least the SoC part numbers are stable (hmm, sh73a0 == r8a73a0).
>
> I think the marketing names are much more useful for humans looking
> at the sysfs files than the kernel doing matching on, but both use
> cases are important.
OK, I'll re-add the family names for humans reading sysfs.
>> >> - Use "renesas,prr" and "renesas,cccr" device nodes in DT if
>> >> available, else fall back to hardcoded addresses for compatibility
>> >> with existing DTBs,
>> > It does seem wrong to have a device node for a specific register though.
>> > Shouldn't the node be for the block of registers that these are inside
>> > of?
>>
>> On R-Mobile APE6, R-Car Gen2 and Gen3, PRR is a lone register.
>> On R-Car Gen1, it's not even documented (and doesn't exist on all parts).
>
> It just seems odd to have it at address 0xff000044 when all the other
> devices are at page-aligned addresses. Do you mean that accessing
> 0xff000040 or 0xff000048 will result in a bus-level exception for a
> missing register and just 0xff000044 is actually valid for access,
> or is it just the only thing that is documented?
For PRR, all other registers in the page read as all zeroes on all SoCs that
have it. So it really is a lone register.
>> On SH-Mobile/R-Mobile, CCCR may be part of the HPB/APB register block, which
>> we further don't touch at all.
>> On R-Car Gen2, it's not documented, but does exist.
>
> This is where the family names would come in handy ;-) I now have
> no idea which chip(s) you are referring to.
SH/R-Mobile are r8a7740, r8a73a4, sh73a0.
R-Car Gen2 are r8a779[0-4].
> If you know the name of the register block, just put it into DT with
> that name. The driver can trivially add the right offset.
CCCR is different. The amount of registers that read as non-zero depends a lot
on the actual SoC.
HPB/APB is gonna need real DT bindings, which needs some more investigation.
Hence if you don't mind, I'd like to postpone that part, which only affects
the older SoCs. And I'll drop the "renesas,cccr" binding.
For now, having revision detection for R-Car Gen3 (r8a779[56]) using PRR is
most urgent, as several drivers (e.g. HDMI, Ethernet, clocks, pinctrl) are
waiting for this support. So I'd like to have that dependency in v4.10.
>> >> - Don't register the SoC bus if the chip ID register is missing,
>> >
>> > Why? My objection was to hardcoding the register, not to registering
>> > the device? I think I'd rather see the device registered with an
>> > empty revision string.
>>
>> If there's no chip ID register, there's no reason to use soc_device_match(),
>> as we can always look at a compatible value. All SoCs listed in this driver
>> have a chip ID register.
>
> But you may still have user space tools looking into sysfs, e.g. to
> figure out how to install a kernel that the boot loader can find,
> or which hardware specific distro packages to install.
>
>> if you want me to register the soc_bus for those SoCs regardless, I want to
>> re-add r7s72100 (RZ/A) and r8a7778 (R-Car M1A), who don't have chip ID
>> registers ;-)
>
> Right. Just don't encode too much knowledge about the SoCs into the
> driver, so we are prepared for adding new ones: We should still look
> for the registers in DT on all chips.
OK, will re-add.
>> >> +static int __init renesas_soc_init(void)
>> >> +{
>> >> + struct soc_device_attribute *soc_dev_attr;
>> >> + const struct of_device_id *match;
>> >> + void __iomem *chipid = NULL;
>> >> + struct soc_device *soc_dev;
>> >> + struct device_node *np;
>> >> + unsigned int product;
>> >> +
>> >> + np = of_find_matching_node_and_match(NULL, renesas_socs, &match);
>> >> + if (!np)
>> >> + return -ENODEV;
>> >> +
>> >> + of_node_put(np);
>> >> +
>> >> + /* Try PRR first, then CCCR, then hardcoded fallback */
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,prr");
>> >> + if (!np)
>> >> + np = of_find_compatible_node(NULL, NULL, "renesas,cccr");
>> >> + if (np) {
>> >> + chipid = of_iomap(np, 0);
>> >> + of_node_put(np);
>> >> + } else if (match->data) {
>> >> + chipid = ioremap((uintptr_t)match->data, 4);
>> >> + }
>> >> + if (!chipid)
>> >>
>> >
>> > Here, I'd turn the order around and look for the DT nodes of the
>> > devices first. Only if they are not found, look at the compatible
>> > string of the root node. No need to search for a node though,
>> > you know which one it is when you look for a compatible =
>> > "renesas,r8a73a4".
>>
>> "renesas,r8a73a4" is the root node, not the device, so it does not have the
>> "reg" property for reading the chip ID?
>
> I mean replace of_find_matching_node_and_match() with
> of_match_node(renesas_socs, of_root).
>
> It does the same thing, just more efficiently.
OK (didn't know "of_root" was available for public use ;-)
>> There is no SoC part number in the "renesas,prr" and "renesas,cccr" nodes.
>> Hence I always need to look at the root nodes.
>
> Not sure what that would protect you from. Could you have a renesas,cccr
Looks like you forgot to finish your sentence?
Thanks!
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert at linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* [Patch v1] mmc: sd: update sd_bus_speed when sd card speed switch fails
From: Gao Pan @ 2016-11-14 10:33 UTC (permalink / raw)
To: linux-mmc, ulf.hansson; +Cc: pandy.gao, frank.li, fugang.duan
In sd_set_bus_speed_mode(), sd card speed is switched to sd_bus_speed.
However, the switch process may fail. When it happens, sd card is in
default speed mode, which is SDR12 as described in Spec3.0.
In such case, the sd_bus_speed should be updated according to status[16].
Signed-off-by: Gao Pan <pandy.gao@nxp.com>
Reviewed-by: Fugang Duan <B38611@freescale.com>
---
drivers/mmc/core/sd.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/drivers/mmc/core/sd.c b/drivers/mmc/core/sd.c
index 73c762a..ac456ec 100644
--- a/drivers/mmc/core/sd.c
+++ b/drivers/mmc/core/sd.c
@@ -471,9 +471,11 @@ static int sd_set_bus_speed_mode(struct mmc_card *card, u8 *status)
if (err)
return err;
- if ((status[16] & 0xF) != card->sd_bus_speed)
+ if ((status[16] & 0xF) != card->sd_bus_speed) {
+ card->sd_bus_speed = status[16] & 0xF;
pr_warn("%s: Problem setting bus speed mode!\n",
mmc_hostname(card->host));
+ }
else {
mmc_set_timing(card->host, timing);
mmc_set_clock(card->host, card->sw_caps.uhs_max_dtr);
--
1.9.1
^ permalink raw reply related
* [PATCH] mixer: Don't install smixer modules unless python is enabled
From: Takashi Iwai @ 2016-11-14 10:50 UTC (permalink / raw)
To: alsa-devel
Currently the whole smixer stuff depends on python, so it doesn't make
sense to install plugins partially when the python support is
disabled.
This patch changes Makefile.am not to install the smixer stuff at all
when the python support is disabled via configure script.
Signed-off-by: Takashi Iwai <tiwai@suse.de>
---
modules/mixer/simple/Makefile.am | 4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/modules/mixer/simple/Makefile.am b/modules/mixer/simple/Makefile.am
index cb64ee8ca665..c21dd07d5180 100644
--- a/modules/mixer/simple/Makefile.am
+++ b/modules/mixer/simple/Makefile.am
@@ -1,3 +1,4 @@
+if BUILD_PYTHON
alsaplugindir = @ALSA_PLUGIN_DIR@
pkglibdir = $(alsaplugindir)/smixer
@@ -9,9 +10,7 @@ pkglib_LTLIBRARIES = smixer-sbase.la \
smixer-ac97.la \
smixer-hda.la
-if BUILD_PYTHON
pkglib_LTLIBRARIES += smixer-python.la
-endif
noinst_HEADERS = sbase.h
@@ -27,7 +26,6 @@ smixer_hda_la_SOURCES = hda.c sbasedl.c
smixer_hda_la_LDFLAGS = -module -avoid-version $(LDFLAGS_NOUNDEFINED)
smixer_hda_la_LIBADD = ../../../src/libasound.la -ldl
-if BUILD_PYTHON
smixer_python_la_SOURCES = python.c
smixer_python_la_LDFLAGS = -module -avoid-version $(LDFLAGS_NOUNDEFINED)
smixer_python_la_CFLAGS = $(PYTHON_INCLUDES)
--
2.10.2
^ permalink raw reply related
* Re: stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Jerome Brunet @ 2016-11-14 10:49 UTC (permalink / raw)
To: André Roth
Cc: Martin Blumenstingl, Johnson Leung, Giuseppe CAVALLARO,
linux-amlogic, Alexandre Torgue, netdev
In-Reply-To: <20161113201339.667ac1f7@gmail.com>
On Sun, 2016-11-13 at 20:13 +0100, André Roth wrote:
> >
> > Andre, the 3.14 kernel you are talking, is it this one ? :
> > https://github.com/hardkernel/linux/tree/odroidc2-3.14.y
>
> yes
>
> >
> > Because in drivers/net/phy/realtek.c, they disable EEE, but
> > also 1000Base-T Full Duplex advertisement ?
> >
> > + /* disable 1000m adv*/
> > + val = phy_read(phydev, 0x9);
> > + phy_write(phydev, 0x9, val&(~(1<<9)));
> >
> > If this is the kernel you are running, you should not be able to
> > have
> > ethernet at 1000MB/s ? Or is it in half duplex mode ?
>
> ethtool shows 1000Mb/s Full-Duplex and the bandwith is around 300Mb/s
> (as measured by scp). kernel version: 3.14.65-73
Andre,
I checked again the kernel at https://github.com/hardkernel/linux/tree/
odroidc2-3.14.y. The version you mention (3.14.65-73) seems to be:
sha1: c75d5f4d1516cdd86d90a9d1c565bb0ed9251036
tag: jenkins-deb s905 kernel-73
In this particular version, both realtek drivers:
- drivers/net/phy/realtek.c
- drivers/amlogic/ethernet/phy/am_realtek.c
have the hack to disable 1000M advertisement. I don't understand how it
possible for you to have 1000Base-T Full Duplex with this, maybe I'm
missing something here ?
If you did compile the kernel yourself, could you check the 2 file
mentioned above ? Just to be sure there was no patch applied at the
last minute, which would not show up in the git history of hardkernel ?
Thx
Jerome
>
>
^ permalink raw reply
* stmmac/RTL8211F/Meson GXBB: TX throughput problems
From: Jerome Brunet @ 2016-11-14 10:49 UTC (permalink / raw)
To: linus-amlogic
In-Reply-To: <20161113201339.667ac1f7@gmail.com>
On Sun, 2016-11-13 at 20:13 +0100, Andr? Roth wrote:
> >
> > Andre, the 3.14 kernel you are talking, is it this one ? :?
> > https://github.com/hardkernel/linux/tree/odroidc2-3.14.y
>
> yes
> ?
> >
> > Because in drivers/net/phy/realtek.c, they disable EEE, but
> > also?1000Base-T Full Duplex advertisement ?
> >
> > + /* disable 1000m adv*/
> > + val = phy_read(phydev, 0x9);
> > + phy_write(phydev, 0x9, val&(~(1<<9)));
> >
> > If this is the kernel you are running, you should not be able to
> > have
> > ethernet at 1000MB/s ? Or is it in half duplex mode ?
>
> ethtool shows 1000Mb/s Full-Duplex and the bandwith is around 300Mb/s
> (as measured by scp). kernel version: 3.14.65-73
Andre,
I checked again the kernel at?https://github.com/hardkernel/linux/tree/
odroidc2-3.14.y. The version you mention (3.14.65-73) seems to be:
sha1:?c75d5f4d1516cdd86d90a9d1c565bb0ed9251036
tag: jenkins-deb s905 kernel-73
In this particular version, both realtek drivers:
- drivers/net/phy/realtek.c
- drivers/amlogic/ethernet/phy/am_realtek.c
have the hack to disable 1000M advertisement. I don't understand how it
possible for you to have 1000Base-T Full Duplex with this, maybe I'm
missing something here ?
If you did compile the kernel yourself, could you check the 2 file
mentioned above ? Just to be sure there was no patch applied at the
last minute, which would not show up in the git history of hardkernel ?
Thx
Jerome
>
>
^ permalink raw reply
* [xen-unstable baseline-only test] 68030: regressions - FAIL
From: Platform Team regression test user @ 2016-11-14 10:49 UTC (permalink / raw)
To: xen-devel, osstest-admin
[-- Attachment #1: Type: text/plain, Size: 20139 bytes --]
This run is configured for baseline tests only.
flight 68030 xen-unstable real [real]
http://osstest.xs.citrite.net/~osstest/testlogs/logs/68030/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
test-amd64-amd64-libvirt-pair 9 xen-boot/src_host fail REGR. vs. 68020
Regressions which are regarded as allowable (not blocking):
test-xtf-amd64-amd64-1 10 xtf-fep fail like 68020
test-xtf-amd64-amd64-5 10 xtf-fep fail like 68020
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 9 windows-install fail like 68020
test-xtf-amd64-amd64-4 10 xtf-fep fail like 68020
test-xtf-amd64-amd64-2 10 xtf-fep fail like 68020
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 9 windows-install fail like 68020
test-xtf-amd64-amd64-3 10 xtf-fep fail like 68020
test-amd64-i386-xl-qemuu-win7-amd64 16 guest-stop fail like 68020
test-amd64-amd64-qemuu-nested-intel 16 debian-hvm-install/l1/l2 fail like 68020
Tests which did not succeed, but are not blocking:
test-amd64-amd64-rumprun-amd64 1 build-check(1) blocked n/a
test-amd64-i386-rumprun-i386 1 build-check(1) blocked n/a
build-i386-rumprun 6 xen-build fail never pass
build-amd64-rumprun 6 xen-build fail never pass
test-armhf-armhf-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-xsm 14 guest-saverestore fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 12 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 13 saverestore-support-check fail never pass
test-amd64-i386-libvirt-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-qcow2 13 guest-saverestore fail never pass
test-armhf-armhf-xl-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 12 saverestore-support-check fail never pass
test-armhf-armhf-libvirt-raw 11 migrate-support-check fail never pass
test-armhf-armhf-libvirt-raw 13 guest-saverestore fail never pass
test-amd64-amd64-libvirt-vhd 11 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 12 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 13 saverestore-support-check fail never pass
test-armhf-armhf-xl-xsm 12 migrate-support-check fail never pass
test-armhf-armhf-xl-xsm 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-pvh-amd 11 guest-start fail never pass
test-armhf-armhf-xl-midway 12 migrate-support-check fail never pass
test-armhf-armhf-xl-midway 13 saverestore-support-check fail never pass
test-amd64-i386-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-libvirt-xsm 12 migrate-support-check fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-xl-pvh-intel 11 guest-start fail never pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 10 migrate-support-check fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 16 guest-stop fail never pass
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 12 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 saverestore-support-check fail never pass
test-amd64-amd64-qemuu-nested-amd 16 debian-hvm-install/l1/l2 fail never pass
test-armhf-armhf-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-libvirt 14 guest-saverestore fail never pass
test-amd64-i386-libvirt 12 migrate-support-check fail never pass
version targeted for testing:
xen 67b5b302f5319f70288587dc98ab505c4deada1e
baseline version:
xen bcb13635fa503113c981c6ea7423f930c1548452
Last test of basis 68020 2016-11-09 13:18:16 Z 4 days
Testing same since 68030 2016-11-13 21:47:02 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Boris Ostrovsky <boris.ostrovsky@oracle.com>
Cédric Bosdonnat <cbosdonnat@suse.com>
Daniel De Graaf <dgdegra@tycho.nsa.gov>
Jan Beulich <jbeulich@suse.com>
Julien Grall <julien.grall@arm.com>
Quan Xu <xuquan8@huawei.com>
Roger Pau Monne <roger.pau@citrix.com>
Roger Pau Monné <roger.pau@citrix.com>
Stefano Stabellini <sstabellini@kernel.org>
Wei Liu <wei.liu2@citrix.com>
jobs:
build-amd64-xsm pass
build-armhf-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt pass
build-armhf-libvirt pass
build-i386-libvirt pass
build-amd64-oldkern pass
build-i386-oldkern pass
build-amd64-prev pass
build-i386-prev pass
build-amd64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
build-amd64-rumprun fail
build-i386-rumprun fail
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-libvirt-xsm pass
test-armhf-armhf-libvirt-xsm fail
test-amd64-i386-libvirt-xsm pass
test-amd64-amd64-xl-xsm pass
test-armhf-armhf-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvh-amd fail
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-rumprun-amd64 blocked
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-amd64-i386-freebsd10-i386 pass
test-amd64-i386-rumprun-i386 blocked
test-amd64-amd64-qemuu-nested-intel fail
test-amd64-amd64-xl-pvh-intel fail
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt pass
test-armhf-armhf-libvirt fail
test-amd64-i386-libvirt pass
test-armhf-armhf-xl-midway pass
test-amd64-amd64-migrupgrade pass
test-amd64-i386-migrupgrade pass
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair fail
test-amd64-i386-libvirt-pair pass
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub pass
test-armhf-armhf-libvirt-qcow2 fail
test-amd64-amd64-xl-qcow2 pass
test-armhf-armhf-libvirt-raw fail
test-amd64-i386-xl-raw pass
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-amd64-i386-xl-qemut-winxpsp3-vcpus1 fail
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 fail
test-amd64-amd64-libvirt-vhd pass
test-armhf-armhf-xl-vhd pass
test-amd64-amd64-xl-qemut-winxpsp3 pass
test-amd64-i386-xl-qemut-winxpsp3 pass
test-amd64-amd64-xl-qemuu-winxpsp3 pass
test-amd64-i386-xl-qemuu-winxpsp3 pass
------------------------------------------------------------
sg-report-flight on osstest.xs.citrite.net
logs: /home/osstest/logs
images: /home/osstest/images
Logs, config files, etc. are available at
http://osstest.xs.citrite.net/~osstest/testlogs/logs
Test harness code can be found at
http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary
Push not applicable.
------------------------------------------------------------
commit 67b5b302f5319f70288587dc98ab505c4deada1e
Author: Jan Beulich <JBeulich@suse.com>
Date: Thu Nov 10 09:06:30 2016 -0700
x86/EFI: meet further spec requirements for runtime calls
So far we didn't guarantee 16-byte alignment of the stack: While (so
far) we don't tell the compiler to use smaller alignment, we also don't
guarantee 16-byte alignment when establishing stack pointers for new
vCPU-s. Runtime service functions using SSE instructions may end with
Note that -mpreferred-stack-boundary=3 is can be used only from gcc 4.8
onwards, and -mincoming-stack-boundary=3 only from 5.3 onwards. It is
for that reason that an alternative approach (using higher than
necessary alignment) is being used when building with such older
compilers.
Furthermore we should avoid #MF to be raised on the FLDCW we do.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 1a5245528ee3d3287f940a44b6cf91fea3dbae32
Author: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Date: Thu Nov 10 09:50:24 2016 -0500
libxc/x86: Report consistent initial APIC value for PV guests
Currently hypervisor provides PV guest's CPUID(1).EBX[31:24] (initial
APIC ID) with contents of that field on the processor that launched
the guest. This results in the guest reporting different initial
APIC IDs across runs.
We should be consistent in how this value is reported, let's set
it to 0 (which is also what Linux guests expect).
Signed-off-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
[ wei: remove trailing whitespace in comment ]
Signed-off-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 8dd7b8a8934e5d8bda9a07ef281cd8f8a4ee1e26
Author: Jan Beulich <JBeulich@suse.com>
Date: Thu Nov 10 05:29:32 2016 -0700
x86emul: suppress alignment check for {,v}mov{d,q}
When introducing support for these instructions, adjustment for the
alignment check logic (generating #GP(0)) was overlooked.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 043ad80d4fad75651e825ef3f935be52f2d6fda0
Author: Jan Beulich <jbeulich@suse.com>
Date: Fri Nov 11 17:19:12 2016 +0100
x86: always supply .cpuid() handler to x86_emulate()
With us incremementally adding proper CPUID checks to x86_emulate()
(see commit de05bd965a ["x86emul: correct {,F}CMOV and F{,U}COMI{,P}
emulation"]) it is no longer appropriate to invoke the function with
that hook being NULL, as long as respective instructions may get used
in that case.
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Paul Durrant <paul.durrant@citrix.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 9fdffbbab3ada427bac07076f042f0265e5ae05f
Author: Cédric Bosdonnat <cbosdonnat@suse.com>
Date: Thu Nov 10 10:23:31 2016 +0100
Fix misleading indentation warnings
Gcc6 build reports misleading indentation as warnings. Fix a few
warnings in stubdom.
Signed-off-by: Cédric Bosdonnat <cbosdonnat@suse.com>
Acked-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
Acked-by: Quan Xu <xuquan8@huawei.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 88f21a0c2a4c8d59cf25ba2d6e6f13d6ce5a42ae
Author: Roger Pau Monne <roger.pau@citrix.com>
Date: Tue Nov 8 17:22:15 2016 +0100
libxc: fix unmap of ACPI guest memory region
Commit fac7f7 changed the value of ptr so that it points to the right memory
area, taking the page offset into account, but failed to remove this when
doing the unmap, which caused the region to not be unmapped. Fix this by not
modifying ptr and instead adding the page offset directly in the memcpy
call.
Coverity-ID: 1394285
Reported-by: Andrew Cooper <andrew.cooper3@citrix.com>
Signed-off-by: Roger Pau Monné <roger.pau@citrix.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 0a34e43d0f74ecaf815bf094443925857b9e83a1
Author: Jan Beulich <jbeulich@suse.com>
Date: Thu Nov 10 18:12:56 2016 +0100
x86emul: correct direction of FPU insn emulations
There are two cases where this was wrong, albeit in a benign way (the
compiler - according to my checking - didn't leverage the wrongness
for any optimizations affecting overall outcome).
Signed-off-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Andrew Cooper <andrew.cooper3@citrix.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit a0b4e3c0681a11b765fe218fba0ba4ebb9fa56c5
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Nov 2 14:36:49 2016 +0000
x86/svm: Don't clobber eax and edx if an RDMSR intercept fails
The original code has a bug; eax and edx get unconditionally updated even when
hvm_msr_read_intercept() doesn't return X86EMUL_OKAY.
It is only by blind luck (vmce_rdmsr() eagerly initialising its msr_content
pointer) that this isn't an information leak into guests.
While fixing this bug, reduce the scope of msr_content and initialise it to 0.
This makes it obvious that a stack leak won't occur, even if there were to be
a buggy codepath in hvm_msr_read_intercept().
Also make some non-functional improvements. Make the insn_len calculation
common, and reduce the quantity of explicit casting by making better use of
the existing register names.
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Reviewed-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
commit 420596c8685d2c413ef4fc11fc942739b856a049
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Tue Nov 8 11:42:43 2016 -0800
Partially revert 21550029f709072aacf3b90edd574e7d3021b400
Commit 21550029f709072aacf3b90edd574e7d3021b400 removed the
PLATFORM_QUIRK_GIC_64K_STRIDE quirk and introduced a way to
automatically detect that the two GICC pages have a 64K stride.
However the heuristic requires that the device tree for the platform
reports a GICC size == 128K, which is not the case for some versions of
XGene.
Fix the issue by partially reverting
21550029f709072aacf3b90edd574e7d3021b400:
- reintroduce PLATFORM_QUIRK_GIC_64K_STRIDE for XGene
- force csize and vsize to SZ_128K if csize is initially 4K and if
PLATFORM_QUIRK_GIC_64K_STRIDE
Also add a warning in case GICC is SZ_128K but not aliased.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
Acked-by: Julien Grall <julien.grall@arm.com>
commit 79c9f5ef82b6964f03fa0171c23a73d00bc971c5
Author: Stefano Stabellini <sstabellini@kernel.org>
Date: Tue Nov 8 11:42:42 2016 -0800
Revert "xen/arm: platform: Drop the quirks callback"
This reverts commit 14fa16961b03a23e9b883e5f0ed06b6837a489d8.
Do not reintroduce platform_dom0_evtchn_ppi.
Signed-off-by: Stefano Stabellini <sstabellini@kernel.org>
Acked-by: Julien Grall <julien.grall@arm.com>
Release-acked-by: Wei Liu <wei.liu2@citrix.com>
(qemu changes not included)
[-- Attachment #2: Type: text/plain, Size: 127 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* [PATCH 5/7 v2] x86/mcheck: reorganize the hotplug callbacks
From: Sebastian Andrzej Siewior @ 2016-11-14 10:47 UTC (permalink / raw)
To: Borislav Petkov; +Cc: linux-kernel, tglx, rt, Tony Luck, linux-edac, x86
In-Reply-To: <20161111195737.i2p35ax6km2ilcng@pd.tnic>
Initially I wanted to remove mcheck_cpu_init() from identify_cpu() and let it
become an independent early hotplug callback. The main problem here was that
the init on the boot CPU may happen too late
(device_initcall_sync(mcheck_init_device)) and nobody wanted to risk receiving
and MCE event at boot time leading to a shutdown (if the MCE feature is not yet
enabled).
Here is attempt two: the timing stays as-is but the ordering of the functions
is changed:
- mcheck_cpu_init() (which is run from identify_cpu()) will setup the timer
struct but won't fire the timer. This is moved to CPU_ONLINE since its
cleanup part is in CPU_DOWN_PREPARE. So if it is okay to stop the timer early
in the shutdown phase, it should be okay to start it late in the bring up phase.
- CPU_DOWN_PREPARE disables the MCE feature flags for !INTEL CPUs in
mce_disable_cpu(). If a failure occurs it would be re-enabled on all vendor
CPUs (including Intel where it was not disabled during shutdown). To keep this
working I am moving it to CPU_ONLINE. smp_call_function_single() is dropped
because the notifier runs on the target CPU (since core code rework).
- CPU_ONLINE is invoking mce_device_create() + mce_threshold_create_device()
but its cleanup part is in CPU_DEAD (mce_threshold_remove_device() and
mce_device_remove()). In order to keep this symmetrical I am moving the clean
up from CPU_DEAD to CPU_DOWN_PREPARE.
Cc: Tony Luck <tony.luck@intel.com>
Cc: Borislav Petkov <bp@alien8.de>
Cc: linux-edac@vger.kernel.org
Cc: x86@kernel.org
Signed-off-by: Sebastian Andrzej Siewior <bigeasy@linutronix.de>
---
On 2016-11-11 20:57:37 [+0100], Borislav Petkov wrote:
> Then please do it right:
>
> static void __mcheck_cap_setup_timer(void)
> {
> struct timer_list *t = this_cpu_ptr(&mce_timer);
> unsigned int cpu = smp_processor_id();
>
> setup_pinned_timer(t, mce_timer_fn, cpu);
> }
>
> and call that function then.
I can't believe that you ask for this but here it is.
arch/x86/kernel/cpu/mcheck/mce.c | 36 ++++++++++++++++++++----------------
1 file changed, 20 insertions(+), 16 deletions(-)
--- a/arch/x86/kernel/cpu/mcheck/mce.c
+++ b/arch/x86/kernel/cpu/mcheck/mce.c
@@ -1745,6 +1745,14 @@ static void mce_start_timer(unsigned int
add_timer_on(t, cpu);
}
+static void __mcheck_cap_setup_timer(void)
+{
+ struct timer_list *t = this_cpu_ptr(&mce_timer);
+ unsigned int cpu = smp_processor_id();
+
+ setup_pinned_timer(t, mce_timer_fn, cpu);
+}
+
static void __mcheck_cpu_init_timer(void)
{
struct timer_list *t = this_cpu_ptr(&mce_timer);
@@ -1796,7 +1804,7 @@ void mcheck_cpu_init(struct cpuinfo_x86
__mcheck_cpu_init_generic();
__mcheck_cpu_init_vendor(c);
__mcheck_cpu_init_clear_banks();
- __mcheck_cpu_init_timer();
+ __mcheck_cap_setup_timer();
}
/*
@@ -2470,28 +2478,25 @@ static void mce_device_remove(unsigned i
}
/* Make sure there are no machine checks on offlined CPUs. */
-static void mce_disable_cpu(void *h)
+static void mce_disable_cpu(void)
{
- unsigned long action = *(unsigned long *)h;
-
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
- if (!(action & CPU_TASKS_FROZEN))
+ if (!cpuhp_tasks_frozen)
cmci_clear();
vendor_disable_error_reporting();
}
-static void mce_reenable_cpu(void *h)
+static void mce_reenable_cpu(void)
{
- unsigned long action = *(unsigned long *)h;
int i;
if (!mce_available(raw_cpu_ptr(&cpu_info)))
return;
- if (!(action & CPU_TASKS_FROZEN))
+ if (!cpuhp_tasks_frozen)
cmci_reenable();
for (i = 0; i < mca_cfg.banks; i++) {
struct mce_bank *b = &mce_banks[i];
@@ -2510,6 +2515,7 @@ mce_cpu_callback(struct notifier_block *
switch (action & ~CPU_TASKS_FROZEN) {
case CPU_ONLINE:
+ case CPU_DOWN_FAILED:
mce_device_create(cpu);
@@ -2517,11 +2523,10 @@ mce_cpu_callback(struct notifier_block *
mce_device_remove(cpu);
return NOTIFY_BAD;
}
-
+ mce_reenable_cpu();
+ mce_start_timer(cpu, t);
break;
case CPU_DEAD:
- mce_threshold_remove_device(cpu);
- mce_device_remove(cpu);
mce_intel_hcpu_update(cpu);
/* intentionally ignoring frozen here */
@@ -2529,12 +2534,11 @@ mce_cpu_callback(struct notifier_block *
cmci_rediscover();
break;
case CPU_DOWN_PREPARE:
- smp_call_function_single(cpu, mce_disable_cpu, &action, 1);
+ mce_disable_cpu();
del_timer_sync(t);
- break;
- case CPU_DOWN_FAILED:
- smp_call_function_single(cpu, mce_reenable_cpu, &action, 1);
- mce_start_timer(cpu, t);
+
+ mce_threshold_remove_device(cpu);
+ mce_device_remove(cpu);
break;
}
^ permalink raw reply
* Re: [PATCH libdrm v2] xf86drm: Parse the separate files to retrieve the vendor, ... info
From: Emil Velikov @ 2016-11-14 10:46 UTC (permalink / raw)
To: Michel Dänzer; +Cc: Mauro Santos, Michel Dänzer, ML dri-devel
In-Reply-To: <f580c939-5168-0f9a-758c-1dba3883cc46@daenzer.net>
On 14 November 2016 at 09:56, Michel Dänzer <michel@daenzer.net> wrote:
> On 10/11/16 10:38 PM, Emil Velikov wrote:
>> On 10 November 2016 at 12:40, Nicolai Hähnle <nhaehnle@gmail.com> wrote:
>>> On 09.11.2016 19:08, Emil Velikov wrote:
>>>>
>>>> From: Emil Velikov <emil.velikov@collabora.com>
>>>>
>>>> Parsing config sysfs file wakes up the device. The latter of which may
>>>> be slow and isn't required to begin with.
>>>>
>>>> Reading through config is/was required since the revision is not
>>>> available by other means, although with a kernel patch in the way that
>>>> is about to change.
>>>>
>>>> Since returning 0 when one might expect a valid value is a no-go add a
>>>> workaround drmDeviceUseRevisionFile() which one can use to say "I don't
>>>> care if the revision file returns 0."
>>>>
>>>> v2: Complete rework - add new API to control the method, instead of
>>>> changing it underneat the users' feet.
>>>>
>>>> Cc: Michel Dänzer <michel.daenzer@amd.com>
>>>> Cc: Mauro Santos <registo.mailling@gmail.com>
>>>> Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=98502
>>>> Signed-off-by: Emil Velikov <emil.velikov@collabora.com>
>>>> ---
>>>> I don't have a strong preference for/against this or v1.
>>>>
>>>> With this Mesa will require a 2 line patch. With v1 things will get
>>>> fixed magically, when rebuilt against newer libdrm.
>>>>
>>>> Mauro I'll send the mesa patch in a second. Feel free to give it a spin.
>>>>
>>>> Thanks
>>>> ---
>>>> xf86drm.c | 70
>>>> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---
>>>> xf86drm.h | 11 ++++++++++
>>>> 2 files changed, 78 insertions(+), 3 deletions(-)
>>>>
>>>> diff --git a/xf86drm.c b/xf86drm.c
>>>> index 52add5e..676effc 100644
>>>> --- a/xf86drm.c
>>>> +++ b/xf86drm.c
>>>> @@ -113,6 +113,13 @@ void drmSetServerInfo(drmServerInfoPtr info)
>>>> drm_server_info = info;
>>>> }
>>>>
>>>> +static bool use_revision_file;
>>>> +
>>>> +void drmDeviceUseRevisionFile(void)
>>>> +{
>>>> + use_revision_file = true;
>>>> +}
>>>
>>>
>>> I think this API of setting a magic hidden global variable is really nasty.
>>>
>>> Can we add new drmGetDevice[s] entry points with a flags parameter and a
>>> flag (per Michel's suggestion) which says "I don't care about the revision
>>> ID"? It kind of sucks because they'll have to get a silly name like
>>> drmGetDevice[s]2, but I think that's still better than magic global state.
>>>
>> AFACS Michel suggested (in his latest reply) to have
>> parse_separate_sysfs_files always and make the lack of revision file
>> fatal - falling back to ./config. Not a separate API [+ flags] ?
>
> You're mixing up two separate issues. Sorry if I was unclear before, let
> me try again:
>
> My first comment was about the "drmDeviceUseRevisionFile" name being
> misleading and not reflecting the intent. For this issue, I think
> Nicolai's suggestion is even better than just fixing the name.
>
> My other comment was that parse_separate_sysfs_files should be tried
> first even if the revision information is needed, and should only bail
> in that case if the separate revision sysfs files are missing, in which
> case parse_config_sysfs_file can be used as a fallback.
>
>
Makes perfect sense, tyvm !
>> P.S. /me is dreaming of the day when [wh]e'll get to drop 90% of
>> libdrm and it's hacks - viva la libdrm3 !
>
> Given the issues with bumping SONAME, I'm afraid you'll have to continue
> dreaming for a long time. :)
>
Sticking with libdrm3.so.X + libdrm3.pc should sort that, right ? That
plus a simple sed job to make the symbols different/unique.
Regardless, anything libdrm3 is unrelated to the topic in question.
Emil
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [PATCH 1/3] perf: add PERF_RECORD_NAMESPACES to include namespaces related info
From: Peter Zijlstra @ 2016-11-14 10:46 UTC (permalink / raw)
To: Hari Bathini
Cc: ast, lkml, acme, alexander.shishkin, mingo, daniel, rostedt,
Ananth N Mavinakayanahalli, ebiederm, sargun, Aravinda Prasad,
brendan.d.gregg
In-Reply-To: <334ecc4f-aacf-4cbe-8858-7ec674f98b24@linux.vnet.ibm.com>
On Mon, Nov 14, 2016 at 04:02:30PM +0530, Hari Bathini wrote:
> >> PERF_RECORD_SWITCH_CPU_WIDE = 15,
> >>+ /*
> >>+ * struct {
> >>+ * struct perf_event_header header;
> >>+ *
> >>+ * u32 pid, tid;
> >>+ * u64 time;
> >>+ * u32 uts_ns_inum;
> >>+ * u32 ipc_ns_inum;
> >>+ * u32 mnt_ns_inum;
> >>+ * u32 pid_ns_inum;
> >>+ * u32 net_ns_inum;
> >>+ * u32 cgroup_ns_inum;
> >>+ * u32 user_ns_inum;
> >>+ * struct sample_id sample_id;
> >>+ * };
> >>+ */
> >>+ PERF_RECORD_NAMESPACES = 16,
> >So this format is not extensible, that is, if someone adds yet another
> >namespace, we'll need to introduce PERF_RECORD_NAMESPACES2.
> >
> >Is there a 'natural' and exposed namespace index that we can use to
> >change it like:
> >
> > u32 nr_nss;
> > u32 namespace[nr_nss];
> >
> >?
>
> Nothing of that sort exists, currently.
> Maybe, time to introduce with this patch-set..?
Would be good, but you'll have to sort that with the namespace folks.
^ permalink raw reply
* [PATCH] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-11-14 10:46 UTC (permalink / raw)
To: dev; +Cc: mac_leehk, yongwang, Stefan Puiu
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
Signed-off-by: Stefan Puiu <stefan.puiu@gmail.com>
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* Re: min/max mtu field in struct net_device
From: Arend Van Spriel @ 2016-11-14 10:46 UTC (permalink / raw)
To: Johannes Berg, backports@vger.kernel.org
In-Reply-To: <1479115859.7899.3.camel@sipsolutions.net>
[-- Attachment #1: Type: text/plain, Size: 849 bytes --]
On 14-11-2016 10:30, Johannes Berg wrote:
> On Mon, 2016-11-14 at 09:49 +0100, Arend Van Spriel wrote:
>> Just wondering. Does anyone have any ideas on how to backport the two
>> patches below. The struct net_device now holds mtu range which
>> network subsystem checks. For a number of drivers and mac80211 it
>> means they no longer have .ndo_change_mtu callback. My guess is that
>> we need patches in backport of some sort to tackle this.
>
> Yeah, I kinda saw this coming. Since in almost all cases using the new
> min/max the ndo_change_mtu was actually removed, perhaps we can come up
> with a way to spatch it back in?
Me too. This is what I got so far, but the callback is generated twice
for net/mac80211/iface.c for obvious reasons (data and monitor ops).
These are my first baby steps with spatch so not sure how to solve it.
Gr. AvS
[-- Attachment #2: 0073-netdevice-mtu-range.cocci --]
[-- Type: text/plain, Size: 395 bytes --]
@r1@
expression ndev, e1, e2;
identifier func;
@@
func(...) {
<...
- ndev->min_mtu = e1;
- ndev->max_mtu = e2;
...>
}
@@
expression r1.e1, r1.e2;
identifier OPS;
@@
+ static int __change_mtu(struct net_device *ndev, int new_mtu)
+ {
+ if (new_mtu < e1 || new_mtu > e2)
+ return -EINVAL;
+ ndev->mtu = new_mtu;
+ }
+
struct net_device_ops OPS = {
+ .ndo_change_mtu = __change_mtu,
...
};
^ permalink raw reply
* Re: [PATCH v11 3/4] drm/i915: Use new CRC debugfs API
From: Jani Nikula @ 2016-11-14 10:44 UTC (permalink / raw)
To: Tomeu Vizoso, linux-kernel
Cc: Ville Syrjälä, Sean Paul, Daniel Vetter, Emil Velikov,
Thierry Reding, Tomeu Vizoso, intel-gfx, dri-devel, David Airlie
In-Reply-To: <1475767268-14379-4-git-send-email-tomeu.vizoso@collabora.com>
On Thu, 06 Oct 2016, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 23a6c7213eca..7412a05fa5d9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14636,6 +14636,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
> .page_flip = intel_crtc_page_flip,
> .atomic_duplicate_state = intel_crtc_duplicate_state,
> .atomic_destroy_state = intel_crtc_destroy_state,
> + .set_crc_source = intel_crtc_set_crc_source,
> };
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 737261b09110..31894b7c6517 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1844,6 +1844,14 @@ void intel_color_load_luts(struct drm_crtc_state *crtc_state);
> /* intel_pipe_crc.c */
> int intel_pipe_crc_create(struct drm_minor *minor);
> void intel_pipe_crc_cleanup(struct drm_minor *minor);
> +#ifdef CONFIG_DEBUG_FS
> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
> + size_t *values_cnt);
> +#else
> +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> + const char *source_name,
> + size_t *values_cnt) { return 0; }
> +#endif
"inline" here doesn't work because it's used as a function pointer.
Is it better to have a function that returns 0 for .set_crc_source, or
to set .set_crc_source to NULL when CONFIG_DEBUG_FS=n?
BR,
Jani.
> extern const struct file_operations i915_display_crc_ctl_fops;
>
> #endif /* __INTEL_DRV_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 6c38d4fdcaef..1a51e174e9e5 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -615,6 +615,22 @@ static int ivb_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> return 0;
> }
>
> +static int get_new_crc_ctl_reg(struct drm_i915_private *dev_priv,
> + enum pipe pipe,
> + enum intel_pipe_crc_source *source, u32 *val)
> +{
> + if (IS_GEN2(dev_priv))
> + return i8xx_pipe_crc_ctl_reg(source, val);
> + else if (INTEL_GEN(dev_priv) < 5)
> + return i9xx_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + return vlv_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> + else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
> + return ilk_pipe_crc_ctl_reg(source, val);
> + else
> + return ivb_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> +}
> +
> static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> enum pipe pipe,
> enum intel_pipe_crc_source source)
> @@ -640,17 +656,7 @@ static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> return -EIO;
> }
>
> - if (IS_GEN2(dev_priv))
> - ret = i8xx_pipe_crc_ctl_reg(&source, &val);
> - else if (INTEL_GEN(dev_priv) < 5)
> - ret = i9xx_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> - else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - ret = vlv_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> - else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
> - ret = ilk_pipe_crc_ctl_reg(&source, &val);
> - else
> - ret = ivb_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> -
> + ret = get_new_crc_ctl_reg(dev_priv, pipe, &source, &val);
> if (ret != 0)
> goto out;
>
> @@ -691,7 +697,7 @@ static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> POSTING_READ(PIPE_CRC_CTL(pipe));
>
> /* real source -> none transition */
> - if (source == INTEL_PIPE_CRC_SOURCE_NONE) {
> + if (!source) {
> struct intel_pipe_crc_entry *entries;
> struct intel_crtc *crtc =
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> @@ -813,6 +819,11 @@ display_crc_ctl_parse_source(const char *buf, enum intel_pipe_crc_source *s)
> {
> int i;
>
> + if (!buf) {
> + *s = INTEL_PIPE_CRC_SOURCE_NONE;
> + return 0;
> + }
> +
> for (i = 0; i < ARRAY_SIZE(pipe_crc_sources); i++)
> if (!strcmp(buf, pipe_crc_sources[i])) {
> *s = i;
> @@ -941,3 +952,62 @@ void intel_pipe_crc_cleanup(struct drm_minor *minor)
> drm_debugfs_remove_files(info_list, 1, minor);
> }
> }
> +
> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
> + size_t *values_cnt)
> +{
> + struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> + struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[crtc->index];
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum intel_display_power_domain power_domain;
> + enum intel_pipe_crc_source source;
> + u32 val = 0; /* shut up gcc */
> + int ret = 0;
> +
> + if (display_crc_ctl_parse_source(source_name, &source) < 0) {
> + DRM_DEBUG_DRIVER("unknown source %s\n", source_name);
> + return -EINVAL;
> + }
> +
> + power_domain = POWER_DOMAIN_PIPE(crtc->index);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n");
> + return -EIO;
> + }
> +
> + ret = get_new_crc_ctl_reg(dev_priv, crtc->index, &source, &val);
> + if (ret != 0)
> + goto out;
> +
> + if (source) {
> + /*
> + * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> + * enabled and disabled dynamically based on package C states,
> + * user space can't make reliable use of the CRCs, so let's just
> + * completely disable it.
> + */
> + hsw_disable_ips(intel_crtc);
> + }
> +
> + I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
> + POSTING_READ(PIPE_CRC_CTL(crtc->index));
> +
> + if (!source) {
> + if (IS_G4X(dev_priv))
> + g4x_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + vlv_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_HASWELL(dev_priv) && crtc->index == PIPE_A)
> + hsw_trans_edp_pipe_A_crc_wa(dev_priv, false);
> +
> + hsw_enable_ips(intel_crtc);
> + }
> +
> + pipe_crc->skipped = 0;
> + *values_cnt = 5;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> +}
--
Jani Nikula, Intel Open Source Technology Center
^ permalink raw reply
* Re: [PATCH v11 3/4] drm/i915: Use new CRC debugfs API
From: Jani Nikula @ 2016-11-14 10:44 UTC (permalink / raw)
To: linux-kernel
Cc: Tomeu Vizoso, David Airlie, intel-gfx, dri-devel, Thierry Reding,
Daniel Vetter
In-Reply-To: <1475767268-14379-4-git-send-email-tomeu.vizoso@collabora.com>
On Thu, 06 Oct 2016, Tomeu Vizoso <tomeu.vizoso@collabora.com> wrote:
> diff --git a/drivers/gpu/drm/i915/intel_display.c b/drivers/gpu/drm/i915/intel_display.c
> index 23a6c7213eca..7412a05fa5d9 100644
> --- a/drivers/gpu/drm/i915/intel_display.c
> +++ b/drivers/gpu/drm/i915/intel_display.c
> @@ -14636,6 +14636,7 @@ static const struct drm_crtc_funcs intel_crtc_funcs = {
> .page_flip = intel_crtc_page_flip,
> .atomic_duplicate_state = intel_crtc_duplicate_state,
> .atomic_destroy_state = intel_crtc_destroy_state,
> + .set_crc_source = intel_crtc_set_crc_source,
> };
>
> /**
> diff --git a/drivers/gpu/drm/i915/intel_drv.h b/drivers/gpu/drm/i915/intel_drv.h
> index 737261b09110..31894b7c6517 100644
> --- a/drivers/gpu/drm/i915/intel_drv.h
> +++ b/drivers/gpu/drm/i915/intel_drv.h
> @@ -1844,6 +1844,14 @@ void intel_color_load_luts(struct drm_crtc_state *crtc_state);
> /* intel_pipe_crc.c */
> int intel_pipe_crc_create(struct drm_minor *minor);
> void intel_pipe_crc_cleanup(struct drm_minor *minor);
> +#ifdef CONFIG_DEBUG_FS
> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
> + size_t *values_cnt);
> +#else
> +static inline int intel_crtc_set_crc_source(struct drm_crtc *crtc,
> + const char *source_name,
> + size_t *values_cnt) { return 0; }
> +#endif
"inline" here doesn't work because it's used as a function pointer.
Is it better to have a function that returns 0 for .set_crc_source, or
to set .set_crc_source to NULL when CONFIG_DEBUG_FS=n?
BR,
Jani.
> extern const struct file_operations i915_display_crc_ctl_fops;
>
> #endif /* __INTEL_DRV_H__ */
> diff --git a/drivers/gpu/drm/i915/intel_pipe_crc.c b/drivers/gpu/drm/i915/intel_pipe_crc.c
> index 6c38d4fdcaef..1a51e174e9e5 100644
> --- a/drivers/gpu/drm/i915/intel_pipe_crc.c
> +++ b/drivers/gpu/drm/i915/intel_pipe_crc.c
> @@ -615,6 +615,22 @@ static int ivb_pipe_crc_ctl_reg(struct drm_i915_private *dev_priv,
> return 0;
> }
>
> +static int get_new_crc_ctl_reg(struct drm_i915_private *dev_priv,
> + enum pipe pipe,
> + enum intel_pipe_crc_source *source, u32 *val)
> +{
> + if (IS_GEN2(dev_priv))
> + return i8xx_pipe_crc_ctl_reg(source, val);
> + else if (INTEL_GEN(dev_priv) < 5)
> + return i9xx_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + return vlv_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> + else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
> + return ilk_pipe_crc_ctl_reg(source, val);
> + else
> + return ivb_pipe_crc_ctl_reg(dev_priv, pipe, source, val);
> +}
> +
> static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> enum pipe pipe,
> enum intel_pipe_crc_source source)
> @@ -640,17 +656,7 @@ static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> return -EIO;
> }
>
> - if (IS_GEN2(dev_priv))
> - ret = i8xx_pipe_crc_ctl_reg(&source, &val);
> - else if (INTEL_GEN(dev_priv) < 5)
> - ret = i9xx_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> - else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> - ret = vlv_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> - else if (IS_GEN5(dev_priv) || IS_GEN6(dev_priv))
> - ret = ilk_pipe_crc_ctl_reg(&source, &val);
> - else
> - ret = ivb_pipe_crc_ctl_reg(dev_priv, pipe, &source, &val);
> -
> + ret = get_new_crc_ctl_reg(dev_priv, pipe, &source, &val);
> if (ret != 0)
> goto out;
>
> @@ -691,7 +697,7 @@ static int pipe_crc_set_source(struct drm_i915_private *dev_priv,
> POSTING_READ(PIPE_CRC_CTL(pipe));
>
> /* real source -> none transition */
> - if (source == INTEL_PIPE_CRC_SOURCE_NONE) {
> + if (!source) {
> struct intel_pipe_crc_entry *entries;
> struct intel_crtc *crtc =
> to_intel_crtc(dev_priv->pipe_to_crtc_mapping[pipe]);
> @@ -813,6 +819,11 @@ display_crc_ctl_parse_source(const char *buf, enum intel_pipe_crc_source *s)
> {
> int i;
>
> + if (!buf) {
> + *s = INTEL_PIPE_CRC_SOURCE_NONE;
> + return 0;
> + }
> +
> for (i = 0; i < ARRAY_SIZE(pipe_crc_sources); i++)
> if (!strcmp(buf, pipe_crc_sources[i])) {
> *s = i;
> @@ -941,3 +952,62 @@ void intel_pipe_crc_cleanup(struct drm_minor *minor)
> drm_debugfs_remove_files(info_list, 1, minor);
> }
> }
> +
> +int intel_crtc_set_crc_source(struct drm_crtc *crtc, const char *source_name,
> + size_t *values_cnt)
> +{
> + struct drm_i915_private *dev_priv = crtc->dev->dev_private;
> + struct intel_pipe_crc *pipe_crc = &dev_priv->pipe_crc[crtc->index];
> + struct intel_crtc *intel_crtc = to_intel_crtc(crtc);
> + enum intel_display_power_domain power_domain;
> + enum intel_pipe_crc_source source;
> + u32 val = 0; /* shut up gcc */
> + int ret = 0;
> +
> + if (display_crc_ctl_parse_source(source_name, &source) < 0) {
> + DRM_DEBUG_DRIVER("unknown source %s\n", source_name);
> + return -EINVAL;
> + }
> +
> + power_domain = POWER_DOMAIN_PIPE(crtc->index);
> + if (!intel_display_power_get_if_enabled(dev_priv, power_domain)) {
> + DRM_DEBUG_KMS("Trying to capture CRC while pipe is off\n");
> + return -EIO;
> + }
> +
> + ret = get_new_crc_ctl_reg(dev_priv, crtc->index, &source, &val);
> + if (ret != 0)
> + goto out;
> +
> + if (source) {
> + /*
> + * When IPS gets enabled, the pipe CRC changes. Since IPS gets
> + * enabled and disabled dynamically based on package C states,
> + * user space can't make reliable use of the CRCs, so let's just
> + * completely disable it.
> + */
> + hsw_disable_ips(intel_crtc);
> + }
> +
> + I915_WRITE(PIPE_CRC_CTL(crtc->index), val);
> + POSTING_READ(PIPE_CRC_CTL(crtc->index));
> +
> + if (!source) {
> + if (IS_G4X(dev_priv))
> + g4x_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_VALLEYVIEW(dev_priv) || IS_CHERRYVIEW(dev_priv))
> + vlv_undo_pipe_scramble_reset(dev_priv, crtc->index);
> + else if (IS_HASWELL(dev_priv) && crtc->index == PIPE_A)
> + hsw_trans_edp_pipe_A_crc_wa(dev_priv, false);
> +
> + hsw_enable_ips(intel_crtc);
> + }
> +
> + pipe_crc->skipped = 0;
> + *values_cnt = 5;
> +
> +out:
> + intel_display_power_put(dev_priv, power_domain);
> +
> + return ret;
> +}
--
Jani Nikula, Intel Open Source Technology Center
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* Re: linux-next: unable to fetch the arm tree
From: Stephen Rothwell @ 2016-11-14 10:42 UTC (permalink / raw)
To: Russell King; +Cc: linux-next, linux-kernel
In-Reply-To: <20161114102219.GE17314@flint.armlinux.org.uk>
Hi Russell,
On Mon, 14 Nov 2016 10:22:19 +0000 Russell King <rmk@armlinux.org.uk> wrote:
>
> Gah, that's down to selinux having an argument over how the repository
> should be labelled - different parts of the system want different
> labels on that. selinux is sometimes a nightmare.
>
> Should be fixed now.
Yep, looks good, thanks.
--
Cheers,
Stephen Rothwell
^ permalink raw reply
* Re: [PATCH 8/9] DT: stm32f469-disco: add node for SDIO controller
From: Alexandre Torgue @ 2016-11-14 10:42 UTC (permalink / raw)
To: andrea.merello; +Cc: Ulf Hansson, Maxime Coquelin, linux-mmc, Bruno Herrera
In-Reply-To: <CAN8YU5PKU7iP1he6MvPCOZ0pf-4fdKgBi8gWmppjdyMU9c=u5Q@mail.gmail.com>
Hi Andrea
On 11/14/2016 11:36 AM, Andrea Merello wrote:
> On Thu, Nov 10, 2016 at 11:54 AM, Alexandre Torgue
> <alexandre.torgue@st.com> wrote:
>> Hi Andrea
>>
>>
>> On 11/08/2016 02:43 PM, Andrea Merello wrote:
>>>
>>> Signed-off-by: Andrea Merello <andrea.merello@gmail.com>
>>> ---
>>> arch/arm/boot/dts/stm32f429.dtsi | 2 +-
>>> arch/arm/boot/dts/stm32f469-disco.dts | 30 ++++++++++++++++++++++++++++++
>>> 2 files changed, 31 insertions(+), 1 deletion(-)
>>>
>>> diff --git a/arch/arm/boot/dts/stm32f429.dtsi
>>> b/arch/arm/boot/dts/stm32f429.dtsi
>>> index d6d0548..23e6a5e 100644
>>> --- a/arch/arm/boot/dts/stm32f429.dtsi
>>> +++ b/arch/arm/boot/dts/stm32f429.dtsi
>>> @@ -185,7 +185,7 @@
>>> interrupts = <1>, <2>, <3>, <6>, <7>, <8>, <9>,
>>> <10>, <23>, <40>, <41>, <42>, <62>, <76>;
>>> };
>>>
>>> - pin-controller {
>>> + pinctrl:pin-controller {
>>> #address-cells = <1>;
>>> #size-cells = <1>;
>>> compatible = "st,stm32f429-pinctrl";
>>> diff --git a/arch/arm/boot/dts/stm32f469-disco.dts
>>> b/arch/arm/boot/dts/stm32f469-disco.dts
>>> index e911af8..e16dfc3 100644
>>> --- a/arch/arm/boot/dts/stm32f469-disco.dts
>>> +++ b/arch/arm/boot/dts/stm32f469-disco.dts
>>> @@ -64,12 +64,42 @@
>>> aliases {
>>> serial0 = &usart3;
>>> };
>>> +
>>> + mmc_vcard: mmc_vcard {
>>> + compatible = "regulator-fixed";
>>> + regulator-name = "mmc_vcard";
>>> + regulator-min-microvolt = <3300000>;
>>> + regulator-max-microvolt = <3300000>;
>>
>> As I assume you will send a v2 (due to kbuild issue) remove empty line
>> please.
>
> Sure. I will do. (But unfortunately it will not happen very soon :( )
No pb.
>
> In the meantime comments and testing are appreciated. Also, I forgot
> to say that, if one wants to try this, he/she will need the bootloader
> to set properly the 48MHz clk for SD (for afboot use my tree -
> pull-req pending on Maxime Coquelin tree). For clk driver probably my
> patch for making it aware of the 48MHz setting is still needed (I've
> not looked into other recent clk patches yet)..
did you see patches sent by Gabriel Fernandez: "[PATCH 0/6] Add STM32F4
missing clocks". This series should add support for 48 MHz. So it is
needed to check first if Gabriel's series is enough.
Thanks
Alex
>
>>> +
>>> + };
>>> };
>>>
>>> &clk_hse {
>>> clock-frequency = <8000000>;
>>> };
>>>
>>> +&pinctrl {
>>> + sdio-cd {
>>> + sdio_cd: sdio-cd {
>>> + pins {
>>> + pinmux = <STM32F429_PG2_FUNC_GPIO>;
>>> + bias-pull-up;
>>> + };
>>> + };
>>> + };
>>> +};
>>> +
>>> +&sdio {
>>> + status = "okay";
>>> + vmmc-supply = <&mmc_vcard>;
>>> + cd-gpios = <&gpiog 2 0>;
>>> + cd-inverted;
>>> + pinctrl-names = "default", "opendrain", "cd";
>>> + pinctrl-0 = <&sdio_pins>, <&sdio_cd>;
>>> + pinctrl-1 = <&sdio_pins_od>, <&sdio_cd>;
>>> + bus-width = <4>;
>>> +};
>>> +
>>> &usart3 {
>>> status = "okay";
>>> };
>>>
>>
^ permalink raw reply
* [xen-unstable-smoke test] 102210: tolerable all pass - PUSHED
From: osstest service owner @ 2016-11-14 10:42 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 102210 xen-unstable-smoke real [real]
http://logs.test-lab.xenproject.org/osstest/logs/102210/
Failures :-/ but no regressions.
Tests which did not succeed, but are not blocking:
test-amd64-amd64-libvirt 12 migrate-support-check fail never pass
test-armhf-armhf-xl 12 migrate-support-check fail never pass
test-armhf-armhf-xl 13 saverestore-support-check fail never pass
version targeted for testing:
xen d4e202c39f0e464dfcec0e28f56725d516e190c6
baseline version:
xen 67b5b302f5319f70288587dc98ab505c4deada1e
Last test of basis 102149 2016-11-12 07:01:51 Z 2 days
Testing same since 102210 2016-11-14 08:01:56 Z 0 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Jan Beulich <jbeulich@suse.com>
jobs:
build-amd64 pass
build-armhf pass
build-amd64-libvirt pass
test-armhf-armhf-xl pass
test-amd64-amd64-xl-qemuu-debianhvm-i386 pass
test-amd64-amd64-libvirt pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Pushing revision :
+ branch=xen-unstable-smoke
+ revision=d4e202c39f0e464dfcec0e28f56725d516e190c6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push xen-unstable-smoke d4e202c39f0e464dfcec0e28f56725d516e190c6
+ branch=xen-unstable-smoke
+ revision=d4e202c39f0e464dfcec0e28f56725d516e190c6
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=xen
+ xenbranch=xen-unstable-smoke
+ qemuubranch=qemu-upstream-unstable
+ '[' xxen = xlinux ']'
+ linuxbranch=
+ '[' xqemu-upstream-unstable = x ']'
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-unstable-smoke
+ prevxenbranch=xen-4.7-testing
+ '[' xd4e202c39f0e464dfcec0e28f56725d516e190c6 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://xenbits.xen.org/xtf.git
++ : osstest@xenbits.xen.org:/home/xen/git/xtf.git
++ : git://xenbits.xen.org/xtf.git
++ : git://xenbits.xen.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : git
++ : git://xenbits.xen.org/osstest/rumprun.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' xgit://xenbits.xen.org/linux-pvops.git = x ']'
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : daily-cron.xen-unstable-smoke
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.xen-unstable-smoke
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPRUN=osstest@xenbits.xen.org:/home/xen/git/osstest/rumprun.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ TREE_XTF=osstest@xenbits.xen.org:/home/xen/git/xtf.git
+ info_linux_tree xen-unstable-smoke
+ case $1 in
+ return 1
+ case "$branch" in
+ cd /home/osstest/repos/xen
+ git push osstest@xenbits.xen.org:/home/xen/git/xen.git d4e202c39f0e464dfcec0e28f56725d516e190c6:refs/heads/smoke
To osstest@xenbits.xen.org:/home/xen/git/xen.git
67b5b30..d4e202c d4e202c39f0e464dfcec0e28f56725d516e190c6 -> smoke
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ permalink raw reply
* Re: [Qemu-devel] virsh dump (qemu guest memory dump?): KASLR enabled linux guest support
From: Paolo Bonzini @ 2016-11-14 10:41 UTC (permalink / raw)
To: Dave Anderson, Andrew Jones
Cc: bhe, Dave Young, qemu-devel, qiaonuohan, lersek
In-Reply-To: <1985884093.14085561.1478705300645.JavaMail.zimbra@redhat.com>
On 09/11/2016 16:28, Dave Anderson wrote:
> I'm not sure whether this "guest userspace agent" is still in play here,
> but if there were such a thing, it could theoretically do the same
> thing that crash currently does when running on a live system.
>
> Both of those are available or calculatable from the contents of
> a kdump header. However, on a live system, it's done like this:
>
> - /proc/kallsyms is queried for the symbol value of "_text", which would
> be relocated if KASLR is in play. That value is compared against the
> "_text" symbol value compiled into the vmlinux file to determine the
> relocation value generated by CONFIG_RANDOMIZE_BASE.
>
> [...] in order to read kernel symbols from the
> statically-mapped kernel region based at __START_KERNEL_map, it
> translates a (possibly relocated) kernel virtual address into a
> physical address like this:
>
> physical-address = virtual-address - __START_KERNEL_map + phys_base
>
> But it's a chicken-and-egg deal, because the contents of the "phys_base"
> symbol are needed to calculate the physical address, but it can't
> read the "phys_base" symbol contents without first knowing its contents.
>
> So on a live system, the "phys_base" is calculated by reading
> the "Kernel Code:" value from /proc/iomem, and then doing this:
>
> phys_base = [Kernel Code: value] - ["_text" symbol value] - __START_KERNEL_map
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
Should there be parentheses around this? The physical-address formula
above is equivalent to
phys_base = physical-address - (virtual-address - __START_KERNEL_map)
>
> So theoretically, the guest agent could read /proc/iomem and /proc/kallsyms
> for the information required. (I think...)
Then yes, the guest-agent could add a command get-kernel-text-start with an output like:
{ 'virtual': 0xffffffff86000000, 'physical': 0xb6000000 }
and libvirt can expose it to crash. In this case, phys_base would be 0xb0000000
if I did the math right, and the relocation value is obtained by comparing the
"virtual" address with the vmlinux "_text".
IIRC the guest agent runs as root, so reading /proc/iomem is not a problem.
Paolo
^ permalink raw reply
* Re: [PATCH] [STYLE]staging:xgifb:XGI_main.h Align columns
From: Dan Carpenter @ 2016-11-14 10:40 UTC (permalink / raw)
To: Walt Feasel; +Cc: arnaud.patard, devel, gregkh, linux-kernel
In-Reply-To: <1479115354-27631-1-git-send-email-waltfeasel@gmail.com>
Your subjects are still wrong...
regards,
dan carpenter
^ permalink raw reply
* Re: [PATCH] irqdomain: fix compiling when IRQ_DOMAIN unset
From: Marc Zyngier @ 2016-11-14 10:41 UTC (permalink / raw)
To: Stefan Christ, alexander.deucher, christian.koenig; +Cc: linux-kernel
In-Reply-To: <1479052766-1525-1-git-send-email-contact@stefanchrist.eu>
Hi Stephan,
On 13/11/16 15:59, Stefan Christ wrote:
> When config option IRQ_DOMAIN is unset, compiling the file
> 'drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c' fails:
>
> CC drivers/gpu/drm/amd/amdgpu/amdgpu_irq.o
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c: In function ‘amdgpu_irq_dispatch’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:345:3: error: implicit declaration of
> function ‘irq_find_mapping’ [-Werror=implicit-function-declaration]
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c: In function ‘amdgpu_irq_add_domain’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:529:2: error: implicit declaration of
> function ‘irq_domain_add_linear’ [-Werror=implicit-function-declaration]
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c: In function ‘amdgpu_irq_remove_domain’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:550:3: error: implicit declaration of
> function ‘irq_domain_remove’ [-Werror=implicit-function-declaration]
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c: In function ‘amdgpu_irq_create_mapping’:
> drivers/gpu/drm/amd/amdgpu/amdgpu_irq.c:569:2: error: implicit declaration of
> function ‘irq_create_mapping’ [-Werror=implicit-function-declaration]
>
> Adding the functions stubs in the header file so it compiles cleanly.
> Maybe the drm driver 'amdgpu' should select the config option IRQ_DOMAIN
> if it cannot work without it. But I don't know if that's necessary.
This looks like the wrong fix to me, as you just end-up with a
non-functional driver which will compiles just fine, making it even
harder to find out what's wrong with it.
Selecting IRQ_DOMAIN is a much saner option.
Thanks,
M.
--
Jazz is not dead. It just smells funny...
^ permalink raw reply
* [PATCH] vmxnet3: fix Rx deadlock
From: Stefan Puiu @ 2016-11-14 10:40 UTC (permalink / raw)
To: dev; +Cc: mac_leehk, yongwang, Stefan Puiu
Our use case is that we have an app that needs to keep mbufs around
for a while. We've seen cases when calling vmxnet3_post_rx_bufs() from
vmxet3_recv_pkts(), it might not succeed to add any mbufs to any RX
descriptors (where it returns -err). Since there are no mbufs that the
virtual hardware can use, and since nobody calls
vmxnet3_post_rx_bufs() after that, no packets will be received after
this. I call this a deadlock for lack of a better term - the virtual
HW waits for free mbufs, while the app waits for the hardware to
notify it for data. Note that after this, the app can't recover.
This fix is a rework of this patch by Marco Lee:
http://dpdk.org/dev/patchwork/patch/6575/. I had to forward port it,
address review comments and also reverted the allocation failure
handing to the first version of the patch
(http://dpdk.org/ml/archives/dev/2015-July/022079.html), since that's
the only approach that seems to work, and seems to be what other
drivers are doing (I checked ixgbe and em). Reusing the mbuf that's
getting passed to the application doesn't seem to make sense, and it
was causing weird issues in our app. Also, reusing rxm without
checking if it's NULL could cause the code to crash.
---
drivers/net/vmxnet3/vmxnet3_rxtx.c | 38 ++++++++++++++++++++++++++++++++++++--
1 file changed, 36 insertions(+), 2 deletions(-)
diff --git a/drivers/net/vmxnet3/vmxnet3_rxtx.c b/drivers/net/vmxnet3/vmxnet3_rxtx.c
index b109168..c9d2488 100644
--- a/drivers/net/vmxnet3/vmxnet3_rxtx.c
+++ b/drivers/net/vmxnet3/vmxnet3_rxtx.c
@@ -518,6 +518,32 @@ vmxnet3_xmit_pkts(void *tx_queue, struct rte_mbuf **tx_pkts,
return nb_tx;
}
+static inline void
+vmxnet3_renew_desc(vmxnet3_rx_queue_t *rxq, uint8_t ring_id,
+ struct rte_mbuf *mbuf)
+{
+ uint32_t val = 0;
+ struct vmxnet3_cmd_ring *ring = &rxq->cmd_ring[ring_id];
+ struct Vmxnet3_RxDesc *rxd =
+ (struct Vmxnet3_RxDesc *)(ring->base + ring->next2fill);
+ vmxnet3_buf_info_t *buf_info = &ring->buf_info[ring->next2fill];
+
+ if (ring_id == 0)
+ val = VMXNET3_RXD_BTYPE_HEAD;
+ else
+ val = VMXNET3_RXD_BTYPE_BODY;
+
+ buf_info->m = mbuf;
+ buf_info->len = (uint16_t)(mbuf->buf_len - RTE_PKTMBUF_HEADROOM);
+ buf_info->bufPA = rte_mbuf_data_dma_addr_default(mbuf);
+
+ rxd->addr = buf_info->bufPA;
+ rxd->btype = val;
+ rxd->len = buf_info->len;
+ rxd->gen = ring->gen;
+
+ vmxnet3_cmd_ring_adv_next2fill(ring);
+}
/*
* Allocates mbufs and clusters. Post rx descriptors with buffer details
* so that device can receive packets in those buffers.
@@ -657,9 +683,17 @@ vmxnet3_recv_pkts(void *rx_queue, struct rte_mbuf **rx_pkts, uint16_t nb_pkts)
}
while (rcd->gen == rxq->comp_ring.gen) {
+ struct rte_mbuf *newm;
if (nb_rx >= nb_pkts)
break;
+ newm = rte_mbuf_raw_alloc(rxq->mp);
+ if (unlikely(newm == NULL)) {
+ PMD_RX_LOG(ERR, "Error allocating mbuf");
+ rxq->stats.rx_buf_alloc_failure++;
+ break;
+ }
+
idx = rcd->rxdIdx;
ring_idx = (uint8_t)((rcd->rqID == rxq->qid1) ? 0 : 1);
rxd = (Vmxnet3_RxDesc *)rxq->cmd_ring[ring_idx].base + idx;
@@ -759,8 +793,8 @@ rcd_done:
VMXNET3_INC_RING_IDX_ONLY(rxq->cmd_ring[ring_idx].next2comp,
rxq->cmd_ring[ring_idx].size);
- /* It's time to allocate some new buf and renew descriptors */
- vmxnet3_post_rx_bufs(rxq, ring_idx);
+ /* It's time to renew descriptors */
+ vmxnet3_renew_desc(rxq, ring_idx, newm);
if (unlikely(rxq->shared->ctrl.updateRxProd)) {
VMXNET3_WRITE_BAR0_REG(hw, rxprod_reg[ring_idx] + (rxq->queue_id * VMXNET3_REG_ALIGN),
rxq->cmd_ring[ring_idx].next2fill);
--
1.9.1
^ permalink raw reply related
* Re: [PATCH v8] This is ABI for the two halves of a Para-virtual sound driver to communicate with each to other.
From: Jan Beulich @ 2016-11-14 10:39 UTC (permalink / raw)
To: Oleksandr Andrushchenko, Konrad Rzeszutek Wilk
Cc: lars.kurth, iurii.konovalenko, xen-devel, ian.campbell,
vlad.babchuk, tim, dario.faggioli, ian.jackson, andrii.anisov,
olekstysh, embedded-pv-devel, al1img, keir.fraser,
oleksandr.dmytryshyn, joculator
In-Reply-To: <20161111212414.GB2304@char.us.oracle.com>
>>> On 11.11.16 at 22:24, <konrad.wilk@oracle.com> wrote:
> On Fri, Nov 04, 2016 at 10:51:33PM +0200, Andrushchenko, Oleksandr wrote:
>> + *-------------------------------- Addressing ---------------------------------
>> + *
>> + * Indices used to address frontends, driver instances, cards,
>> + * devices and streams.
>> + *
>> + * frontend-id
>> + * Values: <uint>
>> + *
>> + * Domain ID of the sound frontend.
>> + *
>> + * drv_idx
>
> How come you use _ here but frontend-id has an '-'? Do you want to keep
> them all the same?
>
>> + * Values: <uint>
>> + *
>> + * Zero based index of the virtualized sound driver instance in this domain.
>> + * Multiple PV drivers are allowed in the domain at the same time.
>
> I think that is given. You can have multiple NICs for example. I woudl
> remove that sentence.
Is that a given? Multiple devices yes, but multiple drivers?
Jan
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
https://lists.xen.org/xen-devel
^ 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.