* [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support
From: Maxime Ripard @ 2016-11-14 14:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <49cb76e1-cd3c-c912-8acf-74e98377f199@redhat.com>
On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
> > #ifdef CONFIG_SPL_SPI_SUNXI
> > @@ -143,7 +157,14 @@
> > #define CONFIG_GENERIC_MMC
> > #define CONFIG_MMC_SUNXI
> > #define CONFIG_MMC_SUNXI_SLOT 0
> > -#define CONFIG_ENV_IS_IN_MMC
> > +#endif
> > +
> > +#if defined(CONFIG_ENV_IS_IN_NAND)
> > +#define CONFIG_ENV_OFFSET 0xc00000
> > +#define CONFIG_ENV_SIZE 0x400000
> > +#elif defined(CONFIG_ENV_IS_IN_MMC)
> > +#define CONFIG_ENV_OFFSET (544 << 10) /* (8 + 24 + 512) KiB */
> > +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */
> > #define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC controller */
> > #endif
Oh, and this part is broken. It relies on the fact that all board
define ENV_IS_IN_MMC (which they should), while obviously they
don't. I'm not exactly sure about what the proper fix would be.
Maxime
--
Maxime Ripard, Free Electrons
Embedded Linux and Kernel engineering
http://free-electrons.com
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: not available
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20161114/84fe1854/attachment.sig>
^ permalink raw reply
* [U-Boot] [PATCH 3/7] sunxi: Enable UBI and NAND support
From: Hans de Goede @ 2016-11-14 14:12 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20161114140927.bubi4p2qcqffqol7@lukather>
Hi,
On 14-11-16 15:09, Maxime Ripard wrote:
> Hi,
>
> On Mon, Nov 14, 2016 at 12:18:06PM +0100, Hans de Goede wrote:
>>> #ifdef CONFIG_SPL_SPI_SUNXI
>>> @@ -143,7 +157,14 @@
>>> #define CONFIG_GENERIC_MMC
>>> #define CONFIG_MMC_SUNXI
>>> #define CONFIG_MMC_SUNXI_SLOT 0
>>> -#define CONFIG_ENV_IS_IN_MMC
>>> +#endif
>>> +
>>> +#if defined(CONFIG_ENV_IS_IN_NAND)
>>> +#define CONFIG_ENV_OFFSET 0xc00000
>>> +#define CONFIG_ENV_SIZE 0x400000
>>> +#elif defined(CONFIG_ENV_IS_IN_MMC)
>>> +#define CONFIG_ENV_OFFSET (544 << 10) /* (8 + 24 + 512) KiB */
>>> +#define CONFIG_ENV_SIZE (128 << 10) /* 128 KiB */
>>> #define CONFIG_SYS_MMC_ENV_DEV 0 /* first detected MMC controller */
>>> #endif
>>>
>>
>> I would greatly prefer putting the env in an UBI partition,
>> I thought that we had agreed on doing that ?
>
> That was mentionned a few times, but I didn't remember having a final
> decision. I'm not really sure that putting the environment in UBI
> would be a good idea.
>
> Attaching the UBI volume takes a very significant time. Doing so
> before the user can see that something is happening in the system
> feels pretty bad.
So maybe we need to print a message before doing so ?
We really need bad-block management for the environment, AFAICT
the current non UBI implementation does not even have a backup ?
Regards,
Hans
^ permalink raw reply
* [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Catalin Marinas @ 2016-11-14 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy@arm.com>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro@8bytes.org>
> Signed-off-by: Robin Murphy <robin.murphy@arm.com>
FWIW:
Reviewed-by: Catalin Marinas <catalin.marinas@arm.com>
^ permalink raw reply
* Re: [PATCH v4 1/2] iommu/dma: Implement dma_{map,unmap}_resource()
From: Catalin Marinas @ 2016-11-14 14:12 UTC (permalink / raw)
To: Robin Murphy
Cc: will.deacon-5wv7dgnIgG8,
iommu-cunTk1MwBs9QetFLy7KEm3xJsTq8ys+cHZ5vskTnxNA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d1cbd5ce714ce3c978aa8bfcb31def87d7919198.1479125555.git.robin.murphy-5wv7dgnIgG8@public.gmane.org>
On Mon, Nov 14, 2016 at 12:16:26PM +0000, Robin Murphy wrote:
> With the new dma_{map,unmap}_resource() functions added to the DMA API
> for the benefit of cases like slave DMA, add suitable implementations to
> the arsenal of our generic layer. Since cache maintenance should not be
> a concern, these can both be standalone callback implementations without
> the need for arch code wrappers.
>
> CC: Joerg Roedel <joro-zLv9SwRftAIdnm+yROfE0A@public.gmane.org>
> Signed-off-by: Robin Murphy <robin.murphy-5wv7dgnIgG8@public.gmane.org>
FWIW:
Reviewed-by: Catalin Marinas <catalin.marinas-5wv7dgnIgG8@public.gmane.org>
^ permalink raw reply
* Re: [PATCH BlueZ] core/adapter: Fix using wrong address type to listen ATT
From: Luiz Augusto von Dentz @ 2016-11-14 14:12 UTC (permalink / raw)
To: Trump DD; +Cc: linux-bluetooth@vger.kernel.org
In-Reply-To: <CABuKQigFTmsni5cGhgMdneez_K78-cKTrg1LG6qHZjmK2tpj7g@mail.gmail.com>
Hi,
On Mon, Nov 14, 2016 at 3:53 PM, Trump DD <wrxzzj@gmail.com> wrote:
> this patch look like fix part bug of BLE devices reconnect
>
> when I restart bluetoothd , all works fine.
> such as:
> systemctl stop bluetooth
> systemctl start bluetooth
> click BLE mouse button, reconnect success.
>
> but this issue existed after apply this patch
> 1. reboot computer, bluetoothd the first time startup, BLE mouse
> reconnect failed with loop
> Connected: yes
> Connected: no
> ...
> ...
Are you sure this is exact the same version after you reboot? Because
from the logs it looks like the exact same problem so perhaps you have
the older version being restored or something else is loading the old
binary, for me this works all the time even after rebooting, or
actually running a vm, but Im running it from source directly.
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v5 07/11] arm/arm64: gicv2: add an IPI test
From: Andrew Jones @ 2016-11-14 14:12 UTC (permalink / raw)
To: Andre Przywara
Cc: peter.maydell, kvm, marc.zyngier, qemu-devel, eric.auger,
qemu-arm, pbonzini, alex.bennee, kvmarm, christoffer.dall
In-Reply-To: <20161111131331.hndvzivzej2mzxiq@hawk.localdomain>
On Fri, Nov 11, 2016 at 02:13:31PM +0100, Andrew Jones wrote:
> On Fri, Nov 11, 2016 at 11:13:46AM +0000, Andre Przywara wrote:
> > Hi,
> >
> > more a comment loosely related to this patch ...
> >
> > > diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> > > index 3f6fa45c587e..68bf5cd6008f 100644
> > > --- a/arm/unittests.cfg
> > > +++ b/arm/unittests.cfg
> > > @@ -54,3 +54,10 @@ file = selftest.flat
> > > smp = $MAX_SMP
> > > extra_params = -append 'smp'
> > > groups = selftest
> > > +
> > > +# Test GIC emulation
> > > +[gicv2-ipi]
> > > +file = gic.flat
> > > +smp = $((($MAX_SMP < 8)?$MAX_SMP:8))
> >
> > So here we always go with the maximum number of VCPUs in the guest.
> > However (as you also noted in your cover-letter) running with a
> > different number of CPUs might be interesting, for instance with less
> > than 8 CPUs on a GICv2 (the ITARGETSR register must be masked) or in
> > general with an odd number (both literally and in the broader sense). I
> > have a test case with passes with 8 VCPUs but fails with less.
> >
> > Is there any good way to run some tests multiple times with different
> > numbers of VCPUS?
> > Shall we add some "set" functionality to the smp parameter, so that we
> > can specify a list of desired test points?
> >
>
> We can just add multiple entries, e.g.
>
> [gicv2-ipi]
> file = gic.flat
> smp = $((($MAX_SMP < 8)?$MAX_SMP:8))
> [gicv2-ipi-3]
> file = gic.flat
> smp = $((($MAX_SMP > 3)?3:$MAX_SMP))
>
> or whatever. But we need to always consider MAX_SMP, since some
> machines may less than 8.
>
Hmm, thinking about this some more, the unit test needs to know how
many processors the test wants, in order to ensure it's testing
correctly. We should provide the number to both -smp and -append,
like we do for selftest-setup.
So, we can have one test that doesn't care, just uses MAX_SMP or 8,
like this patch introduces, but then for each test that does care we
need, e.g.
smp = 3
extra_params = '... smp=3 ...'
Then the unit test will start exactly 2 secondaries (or abort if
they're not available)
Anyway, I don't think this is something we should extend the framework
for, but rather address it with unittests.cfg and unit test input
validation.
Thanks,
drew
^ permalink raw reply
* [PATCH V3 0/5] ARM64: More flexible HW watchpoint
From: Pratyush Anand @ 2016-11-14 14:02 UTC (permalink / raw)
To: will.deacon
Cc: linux-arm-kernel, labath, linux-kernel, jan.kratochvil, onestero,
Pratyush Anand
Currently, we do not support all the byte select option provided by ARM64
specs for a HW watchpoint.
This patch set will help user to instrument a watchpoint with all possible
byte select options.
Changes since v2:
- used __ffs() instead of ffs() - 1. Similarly for fls().
- fixed ptrace_hbp_get_addr() to report correct address to user space
- handling stepping for inexact watchpoint as well now.
Changes since v1:
- Introduced a new patch 3/5 where it takes care of the situation when HW
does not report a watchpoint hit with the address that matches one of the
watchpoints set.
- Added corresponding test case to test that functionality.
Pavel Labath (1):
arm64: hw_breakpoint: Handle inexact watchpoint addresses
Pratyush Anand (4):
hw_breakpoint: Allow watchpoint of length 3,5,6 and 7
arm64: Allow hw watchpoint at varied offset from base address
arm64: Allow hw watchpoint of length 3,5,6 and 7
selftests: arm64: add test for unaligned/inexact watchpoint handling
arch/arm64/include/asm/hw_breakpoint.h | 6 +-
arch/arm64/kernel/hw_breakpoint.c | 153 +++++++++----
arch/arm64/kernel/ptrace.c | 7 +-
include/uapi/linux/hw_breakpoint.h | 4 +
tools/include/uapi/linux/hw_breakpoint.h | 4 +
tools/testing/selftests/breakpoints/Makefile | 5 +-
.../selftests/breakpoints/breakpoint_test_arm64.c | 236 +++++++++++++++++++++
7 files changed, 372 insertions(+), 43 deletions(-)
create mode 100644 tools/testing/selftests/breakpoints/breakpoint_test_arm64.c
--
2.7.4
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Juan Quintela @ 2016-11-14 14:11 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marcelo Tosatti, kvm, qemu-devel, Dr. David Alan Gilbert,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <a3e00c38-4d4d-d353-231d-9eb0233139e2@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
>> + /* local (running VM) restore */
>> + if (s->clock_valid) {
>> + /*
>> + * if host does not support reliable KVM_GET_CLOCK,
>> + * read kvmclock value from memory
>> + */
>> + if (!kvm_has_adjust_clock_stable()) {
>> + time_at_migration = kvmclock_current_nsec(s);
>
> Just assign to s->clock here...
Agreed, I just wanted to make so many changes.
> Also, just another small nit: please make your scripts use the "-p"
> option on diff. :)
YESSSS
I was searching what functions the code belonged for :p
Thanks, Juan.
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Juan Quintela @ 2016-11-14 14:11 UTC (permalink / raw)
To: Paolo Bonzini
Cc: Marcelo Tosatti, kvm, qemu-devel, Dr. David Alan Gilbert,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <a3e00c38-4d4d-d353-231d-9eb0233139e2@redhat.com>
Paolo Bonzini <pbonzini@redhat.com> wrote:
> On 14/11/2016 13:36, Marcelo Tosatti wrote:
>> + /* local (running VM) restore */
>> + if (s->clock_valid) {
>> + /*
>> + * if host does not support reliable KVM_GET_CLOCK,
>> + * read kvmclock value from memory
>> + */
>> + if (!kvm_has_adjust_clock_stable()) {
>> + time_at_migration = kvmclock_current_nsec(s);
>
> Just assign to s->clock here...
Agreed, I just wanted to make so many changes.
> Also, just another small nit: please make your scripts use the "-p"
> option on diff. :)
YESSSS
I was searching what functions the code belonged for :p
Thanks, Juan.
^ permalink raw reply
* [U-Boot] [PATCH] Do not force master mode on unaffected PHY's
From: Olliver Schinagl @ 2016-11-14 14:11 UTC (permalink / raw)
To: u-boot
In-Reply-To: <b9479d92-487b-4992-de1a-6690b5be7580@redhat.com>
Hey Hans,
On 14-11-16 12:26, Hans de Goede wrote:
> Hi,
>
> On 08-11-16 17:38, Olliver Schinagl wrote:
>> The current implementation to force the PHY into master mode is to
>> have a
>> define which affects all realtek PHY's. This is not needed as the
>> problem
>> only exists in the RTL8211C chips. Let us thus turn this into a quirk
>> flag
>> instead.
>
> Series looks good to me:
>
> Reviewed-by: Hans de Goede <hdegoede@redhat.com>
Thanks, but keep your eye on the thread. I'm working on a v3 where i'm
pulling the eeprom stuff out of the sunxi stuff, and in the net-uclass
layer!
Olliver
>
> Regards,
>
> Hans
^ permalink raw reply
* Re: [Qemu-devel] [kvm-unit-tests PATCH v5 07/11] arm/arm64: gicv2: add an IPI test
From: Andrew Jones @ 2016-11-14 14:12 UTC (permalink / raw)
To: Andre Przywara; +Cc: kvm, marc.zyngier, qemu-devel, qemu-arm, pbonzini, kvmarm
In-Reply-To: <20161111131331.hndvzivzej2mzxiq@hawk.localdomain>
On Fri, Nov 11, 2016 at 02:13:31PM +0100, Andrew Jones wrote:
> On Fri, Nov 11, 2016 at 11:13:46AM +0000, Andre Przywara wrote:
> > Hi,
> >
> > more a comment loosely related to this patch ...
> >
> > > diff --git a/arm/unittests.cfg b/arm/unittests.cfg
> > > index 3f6fa45c587e..68bf5cd6008f 100644
> > > --- a/arm/unittests.cfg
> > > +++ b/arm/unittests.cfg
> > > @@ -54,3 +54,10 @@ file = selftest.flat
> > > smp = $MAX_SMP
> > > extra_params = -append 'smp'
> > > groups = selftest
> > > +
> > > +# Test GIC emulation
> > > +[gicv2-ipi]
> > > +file = gic.flat
> > > +smp = $((($MAX_SMP < 8)?$MAX_SMP:8))
> >
> > So here we always go with the maximum number of VCPUs in the guest.
> > However (as you also noted in your cover-letter) running with a
> > different number of CPUs might be interesting, for instance with less
> > than 8 CPUs on a GICv2 (the ITARGETSR register must be masked) or in
> > general with an odd number (both literally and in the broader sense). I
> > have a test case with passes with 8 VCPUs but fails with less.
> >
> > Is there any good way to run some tests multiple times with different
> > numbers of VCPUS?
> > Shall we add some "set" functionality to the smp parameter, so that we
> > can specify a list of desired test points?
> >
>
> We can just add multiple entries, e.g.
>
> [gicv2-ipi]
> file = gic.flat
> smp = $((($MAX_SMP < 8)?$MAX_SMP:8))
> [gicv2-ipi-3]
> file = gic.flat
> smp = $((($MAX_SMP > 3)?3:$MAX_SMP))
>
> or whatever. But we need to always consider MAX_SMP, since some
> machines may less than 8.
>
Hmm, thinking about this some more, the unit test needs to know how
many processors the test wants, in order to ensure it's testing
correctly. We should provide the number to both -smp and -append,
like we do for selftest-setup.
So, we can have one test that doesn't care, just uses MAX_SMP or 8,
like this patch introduces, but then for each test that does care we
need, e.g.
smp = 3
extra_params = '... smp=3 ...'
Then the unit test will start exactly 2 secondaries (or abort if
they're not available)
Anyway, I don't think this is something we should extend the framework
for, but rather address it with unittests.cfg and unit test input
validation.
Thanks,
drew
^ permalink raw reply
* Re: [PATHCv10 1/2] usb: USB Type-C connector class
From: Greg KH @ 2016-11-14 14:11 UTC (permalink / raw)
To: Heikki Krogerus
Cc: Guenter Roeck, Oliver Neukum, Felipe Balbi, Bin Gao, linux-kernel,
linux-usb
In-Reply-To: <20161114123235.GD22706@kuha.fi.intel.com>
On Mon, Nov 14, 2016 at 02:32:35PM +0200, Heikki Krogerus wrote:
> > > +static void __exit typec_exit(void)
> > > +{
> > > + class_unregister(&typec_class);
> >
> > You forgot to clean up your idr :(
>
> Sorry, what idr? The port ids get removed in typec_release().
You have a static idr structure in the driver, right? You have to clean
it up when your code is going away so that it will free any memory it
had allocated with a call to idr_destroy() on module exit.
thanks,
greg k-h
^ permalink raw reply
* Correct way to build patched kernel modules
From: Mert Can Ergun @ 2016-11-14 15:01 UTC (permalink / raw)
To: yocto
Hi!
I am currently using a kernel bbappend file to build my kernel and kernel
modules. My bbappend file looks like this:
linux-imx_%.bbappend
SUMMARY = "Patches applied to Freescale kernel"
DESCRIPTION = "blank"
FILESPATH_prepend := "${THISDIR}/patches:"
SRC_URI += " \
file://defconfig-mt \
**patches for kernel modules appear here**
"
do_configure_prepend() {
cp ${WORKDIR}/defconfig-mt ${WORKDIR}/defconfig
}
However, this approach doesn't feel right and I want to seperate kernel
and its modules from each other at build.
What I tried to do is remove patches from the bbappend file and keep
defconfig file intact. Create a new bb file and put patches inside there
instead. So new architecture looks like this:
linux-imx_%.bbappend
SUMMARY = "Patches applied to Freescale kernel"
DESCRIPTION = "MT6415CA"
FILESPATH_prepend := "${THISDIR}/patches:"
SRC_URI += " \
file://defconfig-mt \
"
do_configure_prepend() {
cp ${WORKDIR}/defconfig-mt ${WORKDIR}/defconfig
}
mt-module_0.1.bb
SUMMARY = "Patches applied to Freescale kernel"
DESCRIPTION = "blank"
LICENSE = "GPLv2"
inherit module
FILESPATH_prepend := "${THISDIR}/patches:"
SRC_URI += " \
**patches appear here**
"
Now my kernel append module doesn't even apply defconfig changes and new
bb file doesn't do anything either. What's the right way to do this?
-------------------------------
Mert Can Ergun
Yazilim Gelistirme Muhendisi
Mikro-Tasarim Ltd.
ODTU-Teknokent ODTU-MET Alani
A-1 Blok 4. Bolum Ofis 3/A
TR-06530 Ankara
T: +90 312 286 0103
F: +90 312 286 0104
U: www.mikro-tasarim.com.tr
E: mert.ergun@mikro-tasarim.com.tr
-------------------------------
^ permalink raw reply
* Re: [PATCH v2] doc: add sub-repositories information
From: Thomas Monjalon @ 2016-11-14 14:10 UTC (permalink / raw)
To: Ferruh Yigit; +Cc: dev, John McNamara, Pablo de Lara, Yuanhan Liu
In-Reply-To: <20161111133417.3894-1-ferruh.yigit@intel.com>
2016-11-11 13:34, Ferruh Yigit:
> DPDK switched to main and sub-repositories approach, this patch
> documents new approach and updates development process according.
>
> Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
> Acked-by: John McNamara <john.mcnamara@intel.com>
Applied, thanks
^ permalink raw reply
* Re: [PATCH v6 8/9] drm/hisilicon/hibmc: Add vblank interruput
From: Rongrong Zou @ 2016-11-14 14:10 UTC (permalink / raw)
To: Sean Paul, Rongrong Zou
Cc: Mark Rutland, Archit, shenhui, Tomeu Vizoso, Jonathan Corbet,
Dave Airlie, catalin.marinas, Emil Velikov, linuxarm, dri-devel,
Xinliang Liu, james.xiong, Daniel Stone, Daniel Vetter,
Will Deacon, lijianhua, Linux ARM Kernel, Benjamin Gaignard
In-Reply-To: <CAOw6vbKx88Bz4RcD3a0K7m-uomHx9wOGN6y7eOuq+yeUdRjZ5Q@mail.gmail.com>
在 2016/11/11 9:49, Sean Paul 写道:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add vblank interrupt.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 56 ++++++++++++++++++++++++-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
>> 2 files changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 4253603..b668e3e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -40,16 +40,46 @@
>>
>> static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +
>> return 0;
>> }
>>
>> static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +}
>> +
>> +irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>> +{
>> + struct drm_device *dev = (struct drm_device *)arg;
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> + struct drm_crtc *crtc = &hidev->crtc;
>> + u32 status;
>> +
>> + status = readl(hidev->mmio + HIBMC_RAW_INTERRUPT);
>> +
>> + if (status & HIBMC_RAW_INTERRUPT_VBLANK(1)) {
>> + writel(HIBMC_RAW_INTERRUPT_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT);
>> + drm_crtc_handle_vblank(crtc);
>> + }
>> +
>> + return IRQ_HANDLED;
>> }
>>
>> static struct drm_driver hibmc_driver = {
>> .driver_features = DRIVER_GEM | DRIVER_MODESET |
>> - DRIVER_ATOMIC,
>> + DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
>> .fops = &hibmc_fops,
>> .name = "hibmc",
>> .date = "20160828",
>> @@ -63,6 +93,7 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> .dumb_create = hibmc_dumb_create,
>> .dumb_map_offset = hibmc_dumb_mmap_offset,
>> .dumb_destroy = drm_gem_dumb_destroy,
>> + .irq_handler = hibmc_drm_interrupt,
>> };
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> @@ -242,6 +273,13 @@ static int hibmc_unload(struct drm_device *dev)
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> hibmc_fbdev_fini(hidev);
>> +
>> + if (dev->irq_enabled)
>> + drm_irq_uninstall(dev);
>> + if (hidev->msi_enabled)
>> + pci_disable_msi(dev->pdev);
>> + drm_vblank_cleanup(dev);
>> +
>> hibmc_kms_fini(hidev);
>> hibmc_mm_fini(hidev);
>> hibmc_hw_fini(hidev);
>> @@ -272,6 +310,22 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>> + if (ret) {
>> + DRM_ERROR("failed to initialize vblank.\n");
>> + goto err;
>> + }
>> +
>> + hidev->msi_enabled = 0;
>> + if (pci_enable_msi(dev->pdev)) {
>
> It would be useful to check and print the return value of this.
agreed, thanks.
>
>> + DRM_ERROR("Enabling MSI failed!\n");
>> + } else {
>> + hidev->msi_enabled = 1;
>> + ret = drm_irq_install(dev, dev->pdev->irq);
>> + if (ret)
>> + DRM_ERROR("install irq failed , ret = %d\n", ret);
>
> DRM_WARN might be more appropriate, given that this isn't considered fatal.
agreed, thanks.
>
>> + }
>> +
>> /* reset all the states of crtc/plane/encoder/connector */
>> drm_mode_config_reset(dev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 450247d..f1706fb 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -42,6 +42,7 @@ struct hibmc_drm_device {
>> void __iomem *fb_map;
>> unsigned long fb_base;
>> unsigned long fb_size;
>> + int msi_enabled;
>
> Why not bool?
agreed, thanks.
Regards,
Rongrong.
>
>>
>> /* drm */
>> struct drm_device *dev;
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel@lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm@huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
^ permalink raw reply
* [PATCH v6 8/9] drm/hisilicon/hibmc: Add vblank interruput
From: Rongrong Zou @ 2016-11-14 14:10 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CAOw6vbKx88Bz4RcD3a0K7m-uomHx9wOGN6y7eOuq+yeUdRjZ5Q@mail.gmail.com>
? 2016/11/11 9:49, Sean Paul ??:
> On Fri, Oct 28, 2016 at 3:28 AM, Rongrong Zou <zourongrong@gmail.com> wrote:
>> Add vblank interrupt.
>>
>> Signed-off-by: Rongrong Zou <zourongrong@gmail.com>
>> ---
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c | 56 ++++++++++++++++++++++++-
>> drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h | 1 +
>> 2 files changed, 56 insertions(+), 1 deletion(-)
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> index 4253603..b668e3e 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.c
>> @@ -40,16 +40,46 @@
>>
>> static int hibmc_enable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +
>> return 0;
>> }
>>
>> static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> {
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> +
>> + writel(HIBMC_RAW_INTERRUPT_EN_VBLANK(0),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT_EN);
>> +}
>> +
>> +irqreturn_t hibmc_drm_interrupt(int irq, void *arg)
>> +{
>> + struct drm_device *dev = (struct drm_device *)arg;
>> + struct hibmc_drm_device *hidev =
>> + (struct hibmc_drm_device *)dev->dev_private;
>> + struct drm_crtc *crtc = &hidev->crtc;
>> + u32 status;
>> +
>> + status = readl(hidev->mmio + HIBMC_RAW_INTERRUPT);
>> +
>> + if (status & HIBMC_RAW_INTERRUPT_VBLANK(1)) {
>> + writel(HIBMC_RAW_INTERRUPT_VBLANK(1),
>> + hidev->mmio + HIBMC_RAW_INTERRUPT);
>> + drm_crtc_handle_vblank(crtc);
>> + }
>> +
>> + return IRQ_HANDLED;
>> }
>>
>> static struct drm_driver hibmc_driver = {
>> .driver_features = DRIVER_GEM | DRIVER_MODESET |
>> - DRIVER_ATOMIC,
>> + DRIVER_ATOMIC | DRIVER_HAVE_IRQ,
>> .fops = &hibmc_fops,
>> .name = "hibmc",
>> .date = "20160828",
>> @@ -63,6 +93,7 @@ static void hibmc_disable_vblank(struct drm_device *dev, unsigned int pipe)
>> .dumb_create = hibmc_dumb_create,
>> .dumb_map_offset = hibmc_dumb_mmap_offset,
>> .dumb_destroy = drm_gem_dumb_destroy,
>> + .irq_handler = hibmc_drm_interrupt,
>> };
>>
>> static int hibmc_pm_suspend(struct device *dev)
>> @@ -242,6 +273,13 @@ static int hibmc_unload(struct drm_device *dev)
>> struct hibmc_drm_device *hidev = dev->dev_private;
>>
>> hibmc_fbdev_fini(hidev);
>> +
>> + if (dev->irq_enabled)
>> + drm_irq_uninstall(dev);
>> + if (hidev->msi_enabled)
>> + pci_disable_msi(dev->pdev);
>> + drm_vblank_cleanup(dev);
>> +
>> hibmc_kms_fini(hidev);
>> hibmc_mm_fini(hidev);
>> hibmc_hw_fini(hidev);
>> @@ -272,6 +310,22 @@ static int hibmc_load(struct drm_device *dev, unsigned long flags)
>> if (ret)
>> goto err;
>>
>> + ret = drm_vblank_init(dev, dev->mode_config.num_crtc);
>> + if (ret) {
>> + DRM_ERROR("failed to initialize vblank.\n");
>> + goto err;
>> + }
>> +
>> + hidev->msi_enabled = 0;
>> + if (pci_enable_msi(dev->pdev)) {
>
> It would be useful to check and print the return value of this.
agreed, thanks.
>
>> + DRM_ERROR("Enabling MSI failed!\n");
>> + } else {
>> + hidev->msi_enabled = 1;
>> + ret = drm_irq_install(dev, dev->pdev->irq);
>> + if (ret)
>> + DRM_ERROR("install irq failed , ret = %d\n", ret);
>
> DRM_WARN might be more appropriate, given that this isn't considered fatal.
agreed, thanks.
>
>> + }
>> +
>> /* reset all the states of crtc/plane/encoder/connector */
>> drm_mode_config_reset(dev);
>>
>> diff --git a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> index 450247d..f1706fb 100644
>> --- a/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> +++ b/drivers/gpu/drm/hisilicon/hibmc/hibmc_drm_drv.h
>> @@ -42,6 +42,7 @@ struct hibmc_drm_device {
>> void __iomem *fb_map;
>> unsigned long fb_base;
>> unsigned long fb_size;
>> + int msi_enabled;
>
> Why not bool?
agreed, thanks.
Regards,
Rongrong.
>
>>
>> /* drm */
>> struct drm_device *dev;
>> --
>> 1.9.1
>>
>>
>> _______________________________________________
>> linux-arm-kernel mailing list
>> linux-arm-kernel at lists.infradead.org
>> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
> _______________________________________________
> linuxarm mailing list
> linuxarm at huawei.com
> http://rnd-openeuler.huawei.com/mailman/listinfo/linuxarm
>
> .
>
^ permalink raw reply
* Re: Tracing sched_switch events for client application when process is switched back in
From: Milian Wolff @ 2016-11-14 14:10 UTC (permalink / raw)
To: Arnaldo Carvalho de Melo; +Cc: linux-perf-users
In-Reply-To: <20161011003655.GP4809@kernel.org>
[-- Attachment #1: Type: text/plain, Size: 4821 bytes --]
On Monday, October 10, 2016 9:36:55 PM CET Arnaldo Carvalho de Melo wrote:
> Em Thu, Oct 06, 2016 at 06:38:28PM +0200, Milian Wolff escreveu:
> > On Thursday, October 6, 2016 1:21:25 PM CEST Arnaldo Carvalho de Melo
wrote:
> > > Em Thu, Oct 06, 2016 at 05:52:51PM +0200, Milian Wolff escreveu:
> > > > Hey all,
> > > >
> > > > when you have an application like this:
> > > >
> > > > ~~~~~~
> > > > #include <unistd.h>
> > > >
> > > > int main()
> > > > {
> > > >
> > > > for (int i = 0; i < 100; ++i) {
> > > >
> > > > usleep(10);
> > > >
> > > > }
> > > >
> > > > }
> > > > ~~~~~~
> > > >
> > > > Then record sched:sched_switch events for it:
> > > >
> > > > ~~~~~~
> > > > $ perf record -e sched:sched_switch ./a.out
> > > > [ perf record: Woken up 1 times to write data ]
> > > > [ perf record: Captured and wrote 0.031 MB perf.data (100 samples) ]
> > > > ~~~~~~
> > > >
> > > > Note how it's only 100 samples, instead of 200 for both, the
> > > > switch-out
> > > > and
> > > > switch-in events. Apparently we only get the switch-out events:
> > > >
> > > > ~~~~~
> > > > $ perf script -F trace | uniq -c
> > > >
> > > > 99 a.out:3994 [120] S ==> swapper/7:0 [120]
> > > >
> > > > 1 a.out:3994 [120] S ==> swapper/7:0 [1
> > > >
> > > > ~~~~~
> > > >
> > > > Doing a global trace, or using LTTNG, we also see the switch-in
> > > > events:
> > > >
> > > > ~~~~~
> > > > $ perf record -e sched:sched_switch -a ./a.out
> > > > $ perf script -F trace | grep a.out | sort | uniq -c
> > > >
> > > > 100 a.out:11570 [120] S ==> swapper/4:0 [120]
> > > >
> > > > 1 a.out:11570 [120] x ==> swapper/4:0 [120]
> > > >
> > > > 100 swapper/4:0 [120] R ==> a.out:11570 [120]
> > > >
> > > > ~~~~~
> > > >
> > > > Is there any way I can get both sched switch events, i.e. not only the
> > > > one
> > > > with prev_tid=$client_tid, but also the one with next_tid=$client_tid?
> > > > One
> > > > way
> > >
> > > > that seems to work is the following:
> > > Have you considered using PERF_RECORD_SWITCH?
> > >
> > > [acme@jouet linux]$ perf record --switch-events sleep 1
> > > [ perf record: Woken up 1 times to write data ]
> > > [ perf record: Captured and wrote 0.020 MB perf.data (7 samples) ]
> > > [acme@jouet linux]$ perf script --show-switch-events
> > >
> > > sleep 20679 5578.172409: 1 cycles:u: 7fb4e5a51c80
> > >
> > > _start+0x0 (/usr/lib64/ld-2.23.so) sleep 20679 5578.172411: 1
> > > cycles:u: 7fb4e5a51c80 _start+0x0 (/usr/lib64/ld-2.23.so) sleep
> > > 20679
> > > 5578.172412: 12 cycles:u: 7fb4e5a51c80 _start+0x0
> > > (/usr/lib64/ld-2.23.so) sleep 20679 5578.172413: 397 cycles:u:
> > >
> > > 7fb4e5a51c80 _start+0x0 (/usr/lib64/ld-2.23.so) sleep 20679
5578.172414:
> > > 13936 cycles:u: ffffffffb77ee7a0 page_fault+0x0
> > >
> > > (/usr/lib/debug/lib/modules/4.7.5-200.fc24.x86_64/vmlinux) sleep 20679
> > > 5578.172431: 330542 cycles:u: 7fb4e5a5301f dl_main+0x6cf
> > > (/usr/lib64/ld-2.23.so) sleep 20679 5578.172700: PERF_RECORD_SWITCH OUT
> > >
> > > sleep 20679 5579.172821: PERF_RECORD_SWITCH IN
> > > sleep 20679 5579.172838: 802931 cycles:u: 7fb4e5a6122e
> > >
> > > _dl_fini+0x8e (/usr/lib64/ld-2.23.so) [acme@jouet linux]$
> >
> > First time I read about it, and the documentation is scarce, to not say
> > non- existing. It seems to record cycles for the switch events. But why
> > does it
> >
> >
> >
> > only find 7, whereas tracing sched_switch finds all 100 that actually take
> > place?
Hey there,
long delay but I looked at this again today.
> This is looking only for the sched switches for the monitored workload,
> which in this case is 'sleep 1', this wasn't a system wide session.
>
> add -a and you'll get those other switches, if I got what you described.
I've used the sources of the simple C application I showed in the first email
of this thread (still quoted above). Then I try:
perf record --switch-events -a ./a.out
And indeed, I get all switch events. But I now also profile all applications
on the machine, which is not what I want. I want to combine the following
features:
- sample CPU events for a given application with backtraces
perf record --call-graph dwarf ./foo
- record switch-out events with backtraces (`-e sched:sched_switch/fp=dwarf/`)
- somehow record the switch-in events, which are associated with a different
process and thus currently discarded
Any advise on where to look for the filtering? Not discarding the sched_switch
of a different process based on matching next_tid can't be that hard, or is
it?
Cheers
--
Milian Wolff | milian.wolff@kdab.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
[-- Attachment #2: smime.p7s --]
[-- Type: application/pkcs7-signature, Size: 5903 bytes --]
^ permalink raw reply
* [PATCH] gpio: tc3589x: fix up .get_direction()
From: Linus Walleij @ 2016-11-14 14:10 UTC (permalink / raw)
To: linux-gpio, Alexandre Courbot; +Cc: Linus Walleij, stable
The bit in the TC3589x direction register is 0 for input
and 1 for output, but the gpiolib expects the reverse.
Fix up the logic.
Cc: stable@vger.kernel.org
Fixes: 14063d71e5e6 ("gpio: tc3589x: add .get_direction() and small cleanup")
Signed-off-by: Linus Walleij <linus.walleij@linaro.org>
---
drivers/gpio/gpio-tc3589x.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpio/gpio-tc3589x.c b/drivers/gpio/gpio-tc3589x.c
index 65d380b2bad2..94ec262a99e0 100644
--- a/drivers/gpio/gpio-tc3589x.c
+++ b/drivers/gpio/gpio-tc3589x.c
@@ -97,7 +97,7 @@ static int tc3589x_gpio_get_direction(struct gpio_chip *chip,
if (ret < 0)
return ret;
- return !!(ret & BIT(pos));
+ return !(ret & BIT(pos));
}
static int tc3589x_gpio_set_single_ended(struct gpio_chip *chip,
--
2.7.4
^ permalink raw reply related
* Re: kvm: WARNING in kvm_arch_vcpu_ioctl_run
From: Dmitry Vyukov @ 2016-11-14 14:09 UTC (permalink / raw)
To: syzkaller
Cc: Radim Krčmář, Thomas Gleixner, Ingo Molnar,
H. Peter Anvin, x86@kernel.org, KVM list, LKML, Steve Rutherford
In-Reply-To: <2c7f4ed6-99af-afef-6d71-40a1f16b8f21@redhat.com>
On Mon, Nov 14, 2016 at 3:03 PM, Paolo Bonzini <pbonzini@redhat.com> wrote:
>
>
> On 14/11/2016 15:00, Dmitry Vyukov wrote:
>> Hello,
>>
>> The following program triggers WARNING in kvm_arch_vcpu_ioctl_run in
>> run in parallel loop:
>> https://gist.githubusercontent.com/dvyukov/08091eee6f38548ff9e6905c5e0eaaee/raw/8cae95f2e88eeb98c4ddc06d227670c1e248222f/gistfile1.txt
>>
>> On commit e234832afb623fe5c7d1d5703d6619494d8d703f (Nov 13)
>>
>> WARNING: CPU: 3 PID: 11141 at arch/x86/kvm/x86.c:6984
>> kvm_arch_vcpu_ioctl_run+0x1f0/0x4f50
>> CPU: 3 PID: 11141 Comm: syz-executor Not tainted 4.9.0-rc5+ #24
>> Hardware name: QEMU Standard PC (i440FX + PIIX, 1996), BIOS Bochs 01/01/2011
>> ffff880039cef698 ffffffff834c3959 ffffffff00000003 1ffff1000739de66
>> ffffed000739de5e 0000000041b58ab3 ffffffff89576450 ffffffff834c366b
>> 0000000041b58ab3 ffffffff894d2830 ffffffff81590020 ffffffff810d90f0
>> Call Trace:
>> [< inline >] __dump_stack lib/dump_stack.c:15
>> [<ffffffff834c3959>] dump_stack+0x2ee/0x3f5 lib/dump_stack.c:51
>> [<ffffffff81849908>] panic+0x200/0x425 kernel/panic.c:179
>> [<ffffffff813fd919>] __warn+0x1c9/0x1e0 kernel/panic.c:542
>> [<ffffffff813fdb81>] warn_slowpath_null+0x31/0x40 kernel/panic.c:585
>> [<ffffffff810ee930>] kvm_arch_vcpu_ioctl_run+0x1f0/0x4f50
>> arch/x86/kvm/x86.c:6984
>> [<ffffffff8107b328>] kvm_vcpu_ioctl+0x678/0x11c0
>> arch/x86/kvm/../../../virt/kvm/kvm_main.c:2557
>> [< inline >] vfs_ioctl fs/ioctl.c:43
>> [<ffffffff81abdb44>] do_vfs_ioctl+0x1c4/0x1630 fs/ioctl.c:679
>> [< inline >] SYSC_ioctl fs/ioctl.c:694
>> [<ffffffff81abf044>] SyS_ioctl+0x94/0xc0 fs/ioctl.c:685
>> [<ffffffff88144885>] entry_SYSCALL_64_fastpath+0x23/0xc6
>
> What I got for now is this dmesg splat:
I made dump_vmcs() no-op locally. You should see the warning
regardless, but probably it is difficult to notice. Or maybe tons of
output affect timings so that the warning does not happen.
> [31705.171034] *** Guest State ***
> [31705.171039] CR0: actual=0x0000000000000030, shadow=0x0000000060000010, gh_mask=fffffffffffffff7
> [31705.171040] CR4: actual=0x0000000000002050, shadow=0x0000000000000000, gh_mask=fffffffffffff871
> [31705.171040] CR3 = 0x00000000fffbc000
> [31705.171041] RSP = 0x0000000000000007 RIP = 0x0000000000100000
> [31705.171042] RFLAGS=0x00000ad0 DR7 = 0x0000000000000400
> [31705.171043] Sysenter RSP=0000000000000000 CS:RIP=0000:0000000000000000
> [31705.171044] CS: sel=0x0000, attr=0x0009b, limit=0x0000ffff, base=0x0000000000000000
> [31705.171045] DS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
> [31705.171046] SS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
> [31705.171046] ES: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
> [31705.171047] FS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
> [31705.171048] GS: sel=0x0000, attr=0x00093, limit=0x0000ffff, base=0x0000000000000000
> [31705.171049] GDTR: limit=0x0000ffff, base=0x0000000000000000
> [31705.171050] LDTR: sel=0x0000, attr=0x00082, limit=0x0000ffff, base=0x0000000000000000
> [31705.171050] IDTR: limit=0x0000ffff, base=0x0000000000000000
> [31705.171051] TR: sel=0x0000, attr=0x0008b, limit=0x0000ffff, base=0x0000000000000000
> [31705.171052] EFER = 0x0000000000000000 PAT = 0x0007040600070406
> [31705.171053] DebugCtl = 0x0000000000000000 DebugExceptions = 0x0000000000000000
> [31705.171054] Interruptibility = 00000000 ActivityState = 00000000
> [31705.171054] *** Host State ***
> [31705.171055] RIP = 0xffffffffc0be5138 RSP = 0xffff8a4bc8967cd0
> [31705.171056] CS=0010 SS=0018 DS=0000 ES=0000 FS=0000 GS=0000 TR=0040
> [31705.171057] FSBase=00007fe434945700 GSBase=ffff8a4bde240000 TRBase=ffff8a4bde256c80
> [31705.171058] GDTBase=ffff8a4bde249000 IDTBase=ffffffffff57b000
> [31705.171058] CR0=0000000080050033 CR3=00000001934aa000 CR4=00000000001426e0
> [31705.171059] Sysenter RSP=0000000000000000 CS:RIP=0010:ffffffff86803e10
> [31705.171060] EFER = 0x0000000000000d01 PAT = 0x0407010600070106
> [31705.171061] *** Control State ***
> [31705.171061] PinBased=0000003f CPUBased=b6a1edfe SecondaryExec=000000eb
> [31705.171062] EntryControls=0000d1ff ExitControls=002fefff
> [31705.171063] ExceptionBitmap=00060042 PFECmask=00000000 PFECmatch=00000000
> [31705.171064] VMEntry: intr_info=800000ff errcode=00000000 ilen=00000000
> [31705.171065] VMExit: intr_info=00000000 errcode=00000000 ilen=00000002
> [31705.171065] reason=80000021 qualification=0000000000000000
> [31705.171066] IDTVectoring: info=00000000 errcode=00000000
> [31705.171067] TSC Offset = 0xffffc75eb7825681
> [31705.171067] TPR Threshold = 0x00
> [31705.171068] EPT pointer = 0x000000019361301e
> [31705.171069] Virtual processor ID = 0x0001
>
> --
> You received this message because you are subscribed to the Google Groups "syzkaller" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to syzkaller+unsubscribe@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
^ permalink raw reply
* Re: [PATCHv4] shmem: avoid huge pages for small files
From: Kirill A. Shutemov @ 2016-11-14 14:09 UTC (permalink / raw)
To: Hugh Dickins
Cc: Kirill A. Shutemov, Andrea Arcangeli, Andrew Morton, Andi Kleen,
Dave Chinner, Michal Hocko, linux-mm, linux-kernel
In-Reply-To: <alpine.LSU.2.11.1611111247580.9200@eggly.anvils>
On Fri, Nov 11, 2016 at 01:41:11PM -0800, Hugh Dickins wrote:
> On Thu, 10 Nov 2016, Kirill A. Shutemov wrote:
> > On Mon, Nov 07, 2016 at 03:17:11PM -0800, Hugh Dickins wrote:
> >
> > > Treating the first extent differently is a hack, and does not respect
> > > that this is a filesystem, on which size is likely to increase.
> > >
> > > By all means refine the condition for huge=within_size, and by all means
> > > warn in transhuge.txt that huge=always may tend to waste valuable huge
> > > pages if the filesystem is used for small files without good reason
> >
> > Would it be okay, if I just replace huge=within_size logic with what I
> > proposed here for huge=always?
>
> In principle yes, that would be fine with me: I just don't care very
> much about this option, since we do not force "huge=always" on anyone,
> so everyone is free to use it where it's useful, and not where it's not.
>
> But perhaps your aim is to have "huge=within_size" set by default on /tmp,
> and so not behave badly there: I'd never aimed for that, and I'm a bit
> sceptical about it, but if you can get good enough behaviour out of it
> for that, I won't stand in your way.
Yeah, I would like one day add compile-time option to choose default huge=
allocation policy.
> > That's not what I intended initially for this option, but...
> >
> > > (but maybe the implementation needs to reclaim those more effectively).
> >
> > It's more about cost of allocation than memory pressure.
>
> Regarding that issue, I think you should reconsider the GFP flags used
> in shmem_alloc_hugepage(). GFP flags, and compaction latency avoidance,
> have been moving targets over the last year, and I've not rechecked;
> but I got the impression that your GFP flags are still asking for the
> compaction stalls that are now deprecated on the anon THP fault path?
> I repeat, I've not rechecked that before writing, maybe it's a libel!
Looks like you're right, we should clear __GFP_KSWAPD_RECLAIM from gfp
flags when allocate from fault path.
Anon-THP also takes into account VM_HUGEPAGE to choose gfp. It's not easy
to get this info into shmem_alloc_hugepage()...
> > -----8<-----
> >
> > From 287ab05c09bfd49c7356ca74b6fea36d8131edaf Mon Sep 17 00:00:00 2001
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > Date: Mon, 17 Oct 2016 14:44:47 +0300
> > Subject: [PATCH] shmem: avoid huge pages for small files
> >
> > Huge pages are detrimental for small file: they causes noticible
> > overhead on both allocation performance and memory footprint.
> >
> > This patch aimed to address this issue by avoiding huge pages until
> > file grown to size of huge page if the filesystem mounted with
> > huge=within_size option.
> >
> > This would cover most of the cases where huge pages causes regressions
> > in performance.
>
> It's not a regression if "huge=always" is worse than "huge=never" in
> some cases: just cases where it's better not to mount "huge=always".
I'm not sure what wording would be better. I mean slower comparing to
small pages.
> > The limit doesn't affect khugepaged behaviour: it still can collapse
> > pages based on its settings.
> >
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> > Documentation/vm/transhuge.txt | 7 ++++++-
> > mm/shmem.c | 6 ++----
> > 2 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> > index 2ec6adb5a4ce..14c911c56f4a 100644
> > --- a/Documentation/vm/transhuge.txt
> > +++ b/Documentation/vm/transhuge.txt
> > @@ -208,11 +208,16 @@ You can control hugepage allocation policy in tmpfs with mount option
> > - "always":
> > Attempt to allocate huge pages every time we need a new page;
> >
>
> Nit: please change the semi-colon to full-stop, and delete the blank line.
Okay.
>
> > + This option can lead to significant overhead if filesystem is used to
> > + store small files.
> > +
> > - "never":
> > Do not allocate huge pages;
> >
> > - "within_size":
> > - Only allocate huge page if it will be fully within i_size.
> > + Only allocate huge page if size of the file more than size of huge
> > + page. This helps to avoid overhead for small files.
> > +
> > Also respect fadvise()/madvise() hints;
> >
> > - "advise:
> > diff --git a/mm/shmem.c b/mm/shmem.c
> > index ad7813d73ea7..3589d36c7c63 100644
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -1681,10 +1681,8 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> > case SHMEM_HUGE_NEVER:
> > goto alloc_nohuge;
> > case SHMEM_HUGE_WITHIN_SIZE:
> > - off = round_up(index, HPAGE_PMD_NR);
> > - i_size = round_up(i_size_read(inode), PAGE_SIZE);
> > - if (i_size >= HPAGE_PMD_SIZE &&
> > - i_size >> PAGE_SHIFT >= off)
> > + i_size = i_size_read(inode);
> > + if (index >= HPAGE_PMD_NR || i_size >= HPAGE_PMD_SIZE)
> > goto alloc_huge;
>
> I said fine in principle above, but when I look at this, I'm puzzled.
>
> Certainly the new condition is easier to understand than the old condition:
> which is a plus, even though it's hackish (I do dislike hobbling the first
> extent, when it's an incomplete last extent which deserves to be hobbled -
> easier said than implemented of course).
Well, it's just heuristic that I found useful. I don't see a reason to
make more complex if it works.
> But isn't the new condition (with its ||) always weaker than the old
> condition (with its &&)? Whereas I thought you were trying to change
> it to be less keen to allocate hugepages, not more.
I tried to make it less keen to allocate hugepages comparing to
huge=always.
Current huge=within_size is fairly restrictive: we don't allocate huge
pages to grow the file. For shmem, it means we would allocate huge pages
if user did truncate(2) to set file size, before touching data in it
(shared memory APIs do this). This policy would be more useful for
filesystem with backing storage.
The patch relaxes condition: only require file size >= HPAGE_PMD_SIZE.
> What the condition ought to say, I don't know: I got too confused,
> and depressed by my confusion, so I'm just handing it back to you.
>
> And then there's the SHMEM_HUGE_WITHIN_SIZE case in shmem_huge_enabled()
> (for khugepaged), which you have explicitly not changed in this patch:
> looks strange to me, is it doing the right thing?
I missed that.
-----8<-----
>From b2158fdd8523e3e35a548857a1cb02fe6bcd1ea4 Mon Sep 17 00:00:00 2001
From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
Date: Mon, 17 Oct 2016 14:44:47 +0300
Subject: [PATCH] shmem: avoid huge pages for small files
Huge pages are detrimental for small file: they causes noticible
overhead on both allocation performance and memory footprint.
This patch aimed to address this issue by avoiding huge pages until
file grown to size of huge page if the filesystem mounted with
huge=within_size option.
This would cover most of the cases where huge pages causes slowdown
comparing to small pages.
Later we can consider huge=within_size as the default for tmpfs.
Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
---
Documentation/vm/transhuge.txt | 8 ++++++--
mm/shmem.c | 12 +++---------
2 files changed, 9 insertions(+), 11 deletions(-)
diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
index 2ec6adb5a4ce..7703e9c241ca 100644
--- a/Documentation/vm/transhuge.txt
+++ b/Documentation/vm/transhuge.txt
@@ -206,13 +206,17 @@ You can control hugepage allocation policy in tmpfs with mount option
"huge=". It can have following values:
- "always":
- Attempt to allocate huge pages every time we need a new page;
+ Attempt to allocate huge pages every time we need a new page.
+ This option can lead to significant overhead if filesystem is used to
+ store small files.
- "never":
Do not allocate huge pages;
- "within_size":
- Only allocate huge page if it will be fully within i_size.
+ Only allocate huge page if size of the file more than size of huge
+ page. This helps to avoid overhead for small files.
+
Also respect fadvise()/madvise() hints;
- "advise:
diff --git a/mm/shmem.c b/mm/shmem.c
index ad7813d73ea7..ef8fdadd0626 100644
--- a/mm/shmem.c
+++ b/mm/shmem.c
@@ -1677,14 +1677,11 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
goto alloc_huge;
switch (sbinfo->huge) {
loff_t i_size;
- pgoff_t off;
case SHMEM_HUGE_NEVER:
goto alloc_nohuge;
case SHMEM_HUGE_WITHIN_SIZE:
- off = round_up(index, HPAGE_PMD_NR);
- i_size = round_up(i_size_read(inode), PAGE_SIZE);
- if (i_size >= HPAGE_PMD_SIZE &&
- i_size >> PAGE_SHIFT >= off)
+ i_size = i_size_read(inode);
+ if (index >= HPAGE_PMD_NR || i_size >= HPAGE_PMD_SIZE)
goto alloc_huge;
/* fallthrough */
case SHMEM_HUGE_ADVISE:
@@ -3856,7 +3853,6 @@ bool shmem_huge_enabled(struct vm_area_struct *vma)
struct inode *inode = file_inode(vma->vm_file);
struct shmem_sb_info *sbinfo = SHMEM_SB(inode->i_sb);
loff_t i_size;
- pgoff_t off;
if (shmem_huge == SHMEM_HUGE_FORCE)
return true;
@@ -3868,10 +3864,8 @@ bool shmem_huge_enabled(struct vm_area_struct *vma)
case SHMEM_HUGE_ALWAYS:
return true;
case SHMEM_HUGE_WITHIN_SIZE:
- off = round_up(vma->vm_pgoff, HPAGE_PMD_NR);
i_size = round_up(i_size_read(inode), PAGE_SIZE);
- if (i_size >= HPAGE_PMD_SIZE &&
- i_size >> PAGE_SHIFT >= off)
+ if (i_size >= HPAGE_PMD_SIZE)
return true;
case SHMEM_HUGE_ADVISE:
/* TODO: implement fadvise() hints */
--
Kirill A. Shutemov
^ permalink raw reply related
* Re: [PATCHv4] shmem: avoid huge pages for small files
From: Kirill A. Shutemov @ 2016-11-14 14:09 UTC (permalink / raw)
To: Hugh Dickins
Cc: Kirill A. Shutemov, Andrea Arcangeli, Andrew Morton, Andi Kleen,
Dave Chinner, Michal Hocko, linux-mm, linux-kernel
In-Reply-To: <alpine.LSU.2.11.1611111247580.9200@eggly.anvils>
On Fri, Nov 11, 2016 at 01:41:11PM -0800, Hugh Dickins wrote:
> On Thu, 10 Nov 2016, Kirill A. Shutemov wrote:
> > On Mon, Nov 07, 2016 at 03:17:11PM -0800, Hugh Dickins wrote:
> >
> > > Treating the first extent differently is a hack, and does not respect
> > > that this is a filesystem, on which size is likely to increase.
> > >
> > > By all means refine the condition for huge=within_size, and by all means
> > > warn in transhuge.txt that huge=always may tend to waste valuable huge
> > > pages if the filesystem is used for small files without good reason
> >
> > Would it be okay, if I just replace huge=within_size logic with what I
> > proposed here for huge=always?
>
> In principle yes, that would be fine with me: I just don't care very
> much about this option, since we do not force "huge=always" on anyone,
> so everyone is free to use it where it's useful, and not where it's not.
>
> But perhaps your aim is to have "huge=within_size" set by default on /tmp,
> and so not behave badly there: I'd never aimed for that, and I'm a bit
> sceptical about it, but if you can get good enough behaviour out of it
> for that, I won't stand in your way.
Yeah, I would like one day add compile-time option to choose default huge=
allocation policy.
> > That's not what I intended initially for this option, but...
> >
> > > (but maybe the implementation needs to reclaim those more effectively).
> >
> > It's more about cost of allocation than memory pressure.
>
> Regarding that issue, I think you should reconsider the GFP flags used
> in shmem_alloc_hugepage(). GFP flags, and compaction latency avoidance,
> have been moving targets over the last year, and I've not rechecked;
> but I got the impression that your GFP flags are still asking for the
> compaction stalls that are now deprecated on the anon THP fault path?
> I repeat, I've not rechecked that before writing, maybe it's a libel!
Looks like you're right, we should clear __GFP_KSWAPD_RECLAIM from gfp
flags when allocate from fault path.
Anon-THP also takes into account VM_HUGEPAGE to choose gfp. It's not easy
to get this info into shmem_alloc_hugepage()...
> > -----8<-----
> >
> > From 287ab05c09bfd49c7356ca74b6fea36d8131edaf Mon Sep 17 00:00:00 2001
> > From: "Kirill A. Shutemov" <kirill.shutemov@linux.intel.com>
> > Date: Mon, 17 Oct 2016 14:44:47 +0300
> > Subject: [PATCH] shmem: avoid huge pages for small files
> >
> > Huge pages are detrimental for small file: they causes noticible
> > overhead on both allocation performance and memory footprint.
> >
> > This patch aimed to address this issue by avoiding huge pages until
> > file grown to size of huge page if the filesystem mounted with
> > huge=within_size option.
> >
> > This would cover most of the cases where huge pages causes regressions
> > in performance.
>
> It's not a regression if "huge=always" is worse than "huge=never" in
> some cases: just cases where it's better not to mount "huge=always".
I'm not sure what wording would be better. I mean slower comparing to
small pages.
> > The limit doesn't affect khugepaged behaviour: it still can collapse
> > pages based on its settings.
> >
> > Signed-off-by: Kirill A. Shutemov <kirill.shutemov@linux.intel.com>
> > ---
> > Documentation/vm/transhuge.txt | 7 ++++++-
> > mm/shmem.c | 6 ++----
> > 2 files changed, 8 insertions(+), 5 deletions(-)
> >
> > diff --git a/Documentation/vm/transhuge.txt b/Documentation/vm/transhuge.txt
> > index 2ec6adb5a4ce..14c911c56f4a 100644
> > --- a/Documentation/vm/transhuge.txt
> > +++ b/Documentation/vm/transhuge.txt
> > @@ -208,11 +208,16 @@ You can control hugepage allocation policy in tmpfs with mount option
> > - "always":
> > Attempt to allocate huge pages every time we need a new page;
> >
>
> Nit: please change the semi-colon to full-stop, and delete the blank line.
Okay.
>
> > + This option can lead to significant overhead if filesystem is used to
> > + store small files.
> > +
> > - "never":
> > Do not allocate huge pages;
> >
> > - "within_size":
> > - Only allocate huge page if it will be fully within i_size.
> > + Only allocate huge page if size of the file more than size of huge
> > + page. This helps to avoid overhead for small files.
> > +
> > Also respect fadvise()/madvise() hints;
> >
> > - "advise:
> > diff --git a/mm/shmem.c b/mm/shmem.c
> > index ad7813d73ea7..3589d36c7c63 100644
> > --- a/mm/shmem.c
> > +++ b/mm/shmem.c
> > @@ -1681,10 +1681,8 @@ static int shmem_getpage_gfp(struct inode *inode, pgoff_t index,
> > case SHMEM_HUGE_NEVER:
> > goto alloc_nohuge;
> > case SHMEM_HUGE_WITHIN_SIZE:
> > - off = round_up(index, HPAGE_PMD_NR);
> > - i_size = round_up(i_size_read(inode), PAGE_SIZE);
> > - if (i_size >= HPAGE_PMD_SIZE &&
> > - i_size >> PAGE_SHIFT >= off)
> > + i_size = i_size_read(inode);
> > + if (index >= HPAGE_PMD_NR || i_size >= HPAGE_PMD_SIZE)
> > goto alloc_huge;
>
> I said fine in principle above, but when I look at this, I'm puzzled.
>
> Certainly the new condition is easier to understand than the old condition:
> which is a plus, even though it's hackish (I do dislike hobbling the first
> extent, when it's an incomplete last extent which deserves to be hobbled -
> easier said than implemented of course).
Well, it's just heuristic that I found useful. I don't see a reason to
make more complex if it works.
> But isn't the new condition (with its ||) always weaker than the old
> condition (with its &&)? Whereas I thought you were trying to change
> it to be less keen to allocate hugepages, not more.
I tried to make it less keen to allocate hugepages comparing to
huge=always.
Current huge=within_size is fairly restrictive: we don't allocate huge
pages to grow the file. For shmem, it means we would allocate huge pages
if user did truncate(2) to set file size, before touching data in it
(shared memory APIs do this). This policy would be more useful for
filesystem with backing storage.
The patch relaxes condition: only require file size >= HPAGE_PMD_SIZE.
> What the condition ought to say, I don't know: I got too confused,
> and depressed by my confusion, so I'm just handing it back to you.
>
> And then there's the SHMEM_HUGE_WITHIN_SIZE case in shmem_huge_enabled()
> (for khugepaged), which you have explicitly not changed in this patch:
> looks strange to me, is it doing the right thing?
I missed that.
-----8<-----
^ permalink raw reply
* Re: [Qemu-devel] [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Juan Quintela @ 2016-11-14 14:09 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Paolo Bonzini,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <20161114123700.158592605@redhat.com>
Marcelo Tosatti <mtosatti@redhat.com> wrote:
> Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> that moment.
>
> For new machine types, use this value rather than reading
> from guest memory.
>
> This reduces kvmclock difference on migration from 5s to 0.1s
> (when max_downtime == 5s).
>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
But, if you have to respin it ....
> + /* whether machine supports reliable KVM_GET_CLOCK */
> + bool mach_use_reliable_get_clock;
> +
> + /* whether source host supported reliable KVM_GET_CLOCK */
> + bool src_use_reliable_get_clock;
This two names are really long, but I don't have better suggesitons :-()
> if (running) {
> struct kvm_clock_data data = {};
> - uint64_t time_at_migration = kvmclock_current_nsec(s);
> + uint64_t time_at_migration = 0;
This was not "time_at_migration", it was not already before, but just
now it looks really weird. (as it was already faulty, this is why it is
only a suggestion.)
>
> - s->clock_valid = false;
> + /* local (running VM) restore */
> + if (s->clock_valid) {
> + /*
> + * if host does not support reliable KVM_GET_CLOCK,
> + * read kvmclock value from memory
> + */
> + if (!kvm_has_adjust_clock_stable()) {
> + time_at_migration = kvmclock_current_nsec(s);
> + }
> + /* migration/savevm/init restore */
> + } else {
> + /*
> + * use s->clock in case machine uses reliable
> + * get clock and host where vm was executing
> + * supported reliable get clock
> + */
This comment is just weird. Simplifying
/* If A and B do C */
if (!A and || !B) {
then D();
}
Doing the opposite comment?
Migration code looks rigth.
Once said that, I continue hating clocks.
Later, Juan.
^ permalink raw reply
* Re: [HP Pavilion x2 - 12-b003nf] Synaptics touchpad not configured by HID RMI
From: Daniel Eriksson @ 2016-11-14 14:09 UTC (permalink / raw)
To: Benjamin Tissoires; +Cc: aduggan, jikos, linux-input
In-Reply-To: <CALYLGY0FcRPFjKFT9PeABtSPQ5DFpvp4YnWUR_bU5Cg5jWwO2A@mail.gmail.com>
Now I tried this branch as well :
https://github.com/bentiss/linux/commits/synaptics-rmi4-v4.8%2B
But I can't seem to get it to boot. I got a "gave up waiting for root
device". Something about missing modules and an alert followed by a
long UUID that does not exist. Probably has nothing to do with the hid
driver though, I probably just did something wrong when configuring or
compiling the kernel.
Thought I'd let you know. If there are other branches that needs
testing for this new hid driver I can do so. Especially good if there
are .debs available, so nothing get's screwed up along the compilation
process. :)
On Sun, Nov 6, 2016 at 4:51 PM, Daniel Eriksson <imerion@gmail.com> wrote:
> I managed to compile my own kernel, and can now confirm this branch:
> https://github.com/aduggan/linux/tree/development/hid-rmi
>
> Works perfect with the hardware I described. Two-finger scrolling,
> edge scrolling and correct acceleration all works as they should. :)
>
> Thanks to all involved! Now I only hope this gets pushed upstream soon. :)
>
>
> On Sat, Nov 5, 2016 at 3:10 AM, Daniel Eriksson <imerion@gmail.com> wrote:
>> On Fri, Nov 4, 2016 at 9:08 AM, Benjamin Tissoires
>> <benjamin.tissoires@redhat.com> wrote:
>>> On Nov 04 2016 or thereabouts, Daniel Eriksson wrote:
>>>> Hi! I'm having some trouble with my touchpad, so I figured I'd send a
>>>> report. Details can be seen below.
>>>>
>>>>
>>>> [1.] One line summary of the problem:
>>>>
>>>> Synaptics touchpad fail to be configured by HID RMI on a HP Pavilion
>>>> x2 (12-b003nf)
>>>>
>>>>
>>>> [2.] Full description of the problem/report:
>>>>
>>>> Touchpad on the HP Pavilion X2 12" does nothing after boot. dmesg shows:
>>>>
>>>> [ 6.032160] hid-rmi 0003:06CB:7D29.0001: No 2D sensor found, giving up.
>>>> [ 6.032273] hid-rmi 0003:06CB:7D29.0001: Error while initializing F11 (-19).
>>>
>>> Your sensor is probably using the F12 2D sensor, not the F11. We are
>>> aware of this issue, and patches has already been submitted. We need
>>> them to be pushed upstream...
>>>
>>> Meanwhile, if you can compile a kernel, you might be interested in:
>>> - https://github.com/aduggan/linux/tree/development/hid-rmi (branch
>>> hid-rmi) -> this has been tested against F12 on RMI4 over HID
>>> - https://github.com/bentiss/linux/commits/synaptics-rmi4-v4.8%2B (
>>> branch synaptics-rmi4-v4.8+) -> this is what matches the latest
>>> submission (the HID part has not been tested and thus not submitted)
>>>
>>> Any help in testing would be appreciated! :)
>>>
>>> Cheers,
>>> Benjamin
>>>
>>
>> I see, great to hear! Any idea how long it would take to get it pushed upstream?
>> I want to help you test, but I'm not sure I can get the kernel
>> compilation right. I'll give it a go and return if I get any results!
>>
>> Thanks!
>>
>> Daniel
>>
>>
>>>> [ 6.044758] hid-rmi 0003:06CB:7D29.0001: hiddev0,hidraw1: USB HID
>>>> v1.11 Mouse [SYNAPTICS Synaptics HIDUSB TouchPad V03] on
>>>> usb-0000:00:14.0-2.1/input0
>>>> [ 6.044761] hid-rmi 0003:06CB:7D29.0001: Device failed to be
>>>> properly configured
>>>>
>>>> Latest bios is installed.
>>>>
>>>>
>>>> [3.] Keywords
>>>>
>>>>
>>>> [4.] Kernel version
>>>>
>>>> Linux version 4.8.6-040806-generic (kernel@tangerine) (gcc version
>>>> 6.2.0 20161005 (Ubuntu 6.2.0-5ubuntu12) ) #201610310831 SMP Mon Oct 31
>>>> 12:33:48 UTC 2016
>>>>
>>>>
>>>> [5.] Output of Oops.. message
>>>>
>>>> Not applicable.
>>>>
>>>>
>>>> [6.] A small shell script or example program which triggers the problem
>>>>
>>>> Not applicable. Problem always appears.
^ permalink raw reply
* Re: [qemu patch 2/2] kvmclock: reduce kvmclock difference on migration
From: Juan Quintela @ 2016-11-14 14:09 UTC (permalink / raw)
To: Marcelo Tosatti
Cc: kvm, qemu-devel, Dr. David Alan Gilbert, Paolo Bonzini,
Radim Krcmar, Eduardo Habkost
In-Reply-To: <20161114123700.158592605@redhat.com>
Marcelo Tosatti <mtosatti@redhat.com> wrote:
> Check for KVM_CAP_ADJUST_CLOCK capability KVM_CLOCK_TSC_STABLE, which
> indicates that KVM_GET_CLOCK returns a value as seen by the guest at
> that moment.
>
> For new machine types, use this value rather than reading
> from guest memory.
>
> This reduces kvmclock difference on migration from 5s to 0.1s
> (when max_downtime == 5s).
>
> Signed-off-by: Marcelo Tosatti <mtosatti@redhat.com>
Acked-by: Juan Quintela <quintela@redhat.com>
But, if you have to respin it ....
> + /* whether machine supports reliable KVM_GET_CLOCK */
> + bool mach_use_reliable_get_clock;
> +
> + /* whether source host supported reliable KVM_GET_CLOCK */
> + bool src_use_reliable_get_clock;
This two names are really long, but I don't have better suggesitons :-()
> if (running) {
> struct kvm_clock_data data = {};
> - uint64_t time_at_migration = kvmclock_current_nsec(s);
> + uint64_t time_at_migration = 0;
This was not "time_at_migration", it was not already before, but just
now it looks really weird. (as it was already faulty, this is why it is
only a suggestion.)
>
> - s->clock_valid = false;
> + /* local (running VM) restore */
> + if (s->clock_valid) {
> + /*
> + * if host does not support reliable KVM_GET_CLOCK,
> + * read kvmclock value from memory
> + */
> + if (!kvm_has_adjust_clock_stable()) {
> + time_at_migration = kvmclock_current_nsec(s);
> + }
> + /* migration/savevm/init restore */
> + } else {
> + /*
> + * use s->clock in case machine uses reliable
> + * get clock and host where vm was executing
> + * supported reliable get clock
> + */
This comment is just weird. Simplifying
/* If A and B do C */
if (!A and || !B) {
then D();
}
Doing the opposite comment?
Migration code looks rigth.
Once said that, I continue hating clocks.
Later, Juan.
^ permalink raw reply
* Re: [PATCH v2] ARM: dts: vfxxx: Enable DMA for DSPI2 and DSPI3
From: Shawn Guo @ 2016-11-14 14:02 UTC (permalink / raw)
To: Sanchayan Maity; +Cc: stefan, linux-arm-kernel, devicetree, linux-kernel
In-Reply-To: <20161114123701.4355-1-maitysanchayan@gmail.com>
On Mon, Nov 14, 2016 at 06:07:01PM +0530, Sanchayan Maity wrote:
> Enable DMA for DSPI2 and DSPI3 on Vybrid.
>
> Signed-off-by: Sanchayan Maity <maitysanchayan@gmail.com>
Applied, thanks.
^ 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.