* Re: [PATCH] btrfs: ioctls would need unique id
From: Hugo Mills @ 2013-12-19 8:19 UTC (permalink / raw)
To: Anand Jain; +Cc: linux-btrfs
In-Reply-To: <1387425992-15268-1-git-send-email-anand.jain@oracle.com>
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
On Thu, Dec 19, 2013 at 12:06:32PM +0800, Anand Jain wrote:
> BTRFS_IOC_SET_FEATURES and BTRFS_IOC_GET_SUPPORTED_FEATURES
> conflicts with BTRFS_IOC_GET_FEATURES
>
> Signed-off-by: Anand Jain <anand.jain@oracle.com>
> ---
> include/uapi/linux/btrfs.h | 4 ++--
> 1 files changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/include/uapi/linux/btrfs.h b/include/uapi/linux/btrfs.h
> index 7d7f776..0fe736e 100644
> --- a/include/uapi/linux/btrfs.h
> +++ b/include/uapi/linux/btrfs.h
> @@ -634,9 +634,9 @@ struct btrfs_ioctl_fslist_args {
> struct btrfs_ioctl_fslist_args)
> #define BTRFS_IOC_GET_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 57, \
> struct btrfs_ioctl_feature_flags)
> -#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 57, \
> +#define BTRFS_IOC_SET_FEATURES _IOW(BTRFS_IOCTL_MAGIC, 58, \
> struct btrfs_ioctl_feature_flags[2])
> -#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 57, \
> +#define BTRFS_IOC_GET_SUPPORTED_FEATURES _IOR(BTRFS_IOCTL_MAGIC, 59, \
> struct btrfs_ioctl_feature_flags[3])
The ioctls are distinct as tehy are, as they have different-sized
parameters. Changing these numbers is changing the public interface,
which is a big no-no.
Hugo.
--
=== Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
--- I think that everything darkling says is actually a joke. ---
It's just that we haven't worked out most of them yet.
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* [PATCH 4/6] arm64: lib: Implement optimized memcmp routine
From: Deepak Saxena @ 2013-12-19 8:18 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20131216165647.GH20193@mudshark.cambridge.arm.com>
On 16 December 2013 08:56, Will Deacon <will.deacon@arm.com> wrote:
> On Wed, Dec 11, 2013 at 06:24:40AM +0000, zhichang.yuan at linaro.org wrote:
>> From: "zhichang.yuan" <zhichang.yuan@linaro.org>
>>
>> This patch, based on Linaro's Cortex Strings library, adds
>> an assembly optimized memcmp() function.
>
> [...]
>
>> +#ifndef __ARM64EB__
>> + rev diff, diff
>> + rev data1, data1
>> + rev data2, data2
>> +#endif
>
> Given that I can't see you defining __ARM64EB__, I'd take a guess at you
> never having tested this code on a big-endian machine.
We'll test it, but I believe __ARM64BE__ is a compiler constant that
is automagically present when building big endian, similar to
__ARMBE__
>
> Please can you fix that?
>
> Will
--
Deepak Saxena - Kernel Working Group Lead
Linaro.org | Open source software for ARM SoCs
Follow Linaro: http://www.facebook.com/pages/Linaro
^ permalink raw reply
* Re: [PATCH 1/2] android/tester: Add Socket test close and listen
From: Johan Hedberg @ 2013-12-19 8:18 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1387379717-1457-1-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Wed, Dec 18, 2013, Andrei Emeltchenko wrote:
> This test the situation when Android close file descriptor we passed to
> it and try to listen() again.
> ---
> android/android-tester.c | 55 ++++++++++++++++++++++++++++++++++++++++++++++++
> 1 file changed, 55 insertions(+)
>
> diff --git a/android/android-tester.c b/android/android-tester.c
> index 8a2861e..cb8fb4e 100644
> --- a/android/android-tester.c
> +++ b/android/android-tester.c
> @@ -1141,6 +1141,57 @@ clean:
> close(sock_fd);
> }
>
> +static void test_listen_close(const void *test_data)
> +{
> + struct test_data *data = tester_get_data();
> + const struct socket_data *test = data->test_data;
> + bt_status_t status;
> + int sock_fd = -1;
> +
> + status = data->if_sock->listen(test->sock_type,
> + test->service_name, test->service_uuid,
> + test->channel, &sock_fd, test->flags);
> + if (status != test->expected_status) {
> + tester_test_failed();
> + goto clean;
> + }
> +
> + /* Check that file descriptor is valid */
> + if (status == BT_STATUS_SUCCESS && fcntl(sock_fd, F_GETFD) == -1) {
We usually check for failures like this with < 0 instead of == -1.
> + status = data->if_sock->listen(test->sock_type,
> + test->service_name, test->service_uuid,
> + test->channel, &sock_fd, test->flags);
> + if (status != test->expected_status) {
> + tester_test_failed();
> + goto clean;
> + }
You've got many different conditions that can trigger
tester_test_failed but no tester_warn() logs for each one to make
debugging easy if these new tests start failing. Please add those.
Otherwise once there's a regression it's going to be a real pain for you
to track down exactly what's broken.
Johan
^ permalink raw reply
* Re: [Devel] [PATCH 1/6] slab: cleanup kmem_cache_create_memcg()
From: Vasily Averin @ 2013-12-19 8:17 UTC (permalink / raw)
To: Vladimir Davydov
Cc: Michal Hocko, Glauber Costa, linux-kernel, Pekka Enberg, linux-mm,
Johannes Weiner, cgroups, Christoph Lameter, Andrew Morton, devel
In-Reply-To: <6f02b2d079ffd0990ae335339c803337b13ecd8c.1387372122.git.vdavydov@parallels.com>
On 12/18/2013 05:16 PM, Vladimir Davydov wrote:
> --- a/mm/slab_common.c
> +++ b/mm/slab_common.c
> @@ -176,8 +176,9 @@ kmem_cache_create_memcg(struct mem_cgroup *memcg, const char *name, size_t size,
> get_online_cpus();
> mutex_lock(&slab_mutex);
>
> - if (!kmem_cache_sanity_check(memcg, name, size) == 0)
> - goto out_locked;
> + err = kmem_cache_sanity_check(memcg, name, size);
> + if (err)
> + goto out_unlock;
>
> /*
> * Some allocators will constraint the set of valid flags to a subset
Theoretically in future kmem_cache_sanity_check() can return positive value.
Probably it's better to check (err < 0) in caller ?
Thank you,
Vasily Averin
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* imx6 power consumption
From: Bjørn Erik Nilsen @ 2013-12-19 8:15 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <b43eb01926cf4b1f9413a66cc5791d9b@DM2PR03MB317.namprd03.prod.outlook.com>
Hi Anson,
On Thu, 2013-12-19 at 03:28 +0100, Anson.Huang at freescale.com wrote:
>
> Best Regards.
> Anson huang ???
>
> Freescale Semiconductor Shanghai
> ?????????192?A?2?
> 201203
> Tel:021-28937058
>
>
> >-----Original Message-----
> >From: linux-arm-kernel [mailto:linux-arm-kernel-bounces at lists.infradead.org]
> >On Behalf Of Shawn Guo
> >Sent: Wednesday, December 18, 2013 7:33 PM
> >To: Bj?rn Erik Nilsen
> >Cc: linux-arm-kernel at lists.infradead.org
> >Subject: Re: imx6 power consumption
> >
> >On Wed, Dec 18, 2013 at 12:12:05PM +0100, Bj?rn Erik Nilsen wrote:
> >> As far as I can tell, commit e95dddb34c8 "ARM: imx: enable anatop
> >> suspend/resume" is the common ancestor for mainline and freescale, and
> >> from there pm-imx6q.c starts to diverge.
> >>
> >> I haven not looked at it in great detail yet, but it seems there are
> >> not too many patches missing in mainline. Any idea why remaining
> >> patches haven't been upstreamed?
> >
> >Probably because no one cares and would spend time to upstream these patches.
>
> This root cause is we did NOT put the DSM code in IRAM and free DDR IO in DSM.
> We have done this in our internal v3.10 kernel, so I will do the upstream soon,
> Below is the DSM number of i.MX6Q SabreSD we got on v3.10 release:
>
> VDDARM_IN(R27) 0mA at 0.97V
> VDDSOC_IN(R21) 4.2 at 0.97V
> DDR(R25) 14.8mA at 1.5V
> VDDHIGH_IN + SNVS(SH17) 0.35mA at 2.98V, 0.9mA
I successfully managed to cherry-pick a handful of commits from
freescale 3.10 and got down to approximately half the consumption.
That's already very good news.
Looking forward to see these patches upstream. Will you be able upstream
them before 3.14 you think?
Good work!
Best regards,
Bj?rn Erik Nilsen
^ permalink raw reply
* Re: [PATCH_v4 3/7] android/pan: shutdown io channel on disconnect call
From: Johan Hedberg @ 2013-12-19 8:14 UTC (permalink / raw)
To: Ravi kumar Veeramally; +Cc: linux-bluetooth
In-Reply-To: <1387378396-6259-3-git-send-email-ravikumar.veeramally@linux.intel.com>
Hi Ravi,
On Wed, Dec 18, 2013, Ravi kumar Veeramally wrote:
> Shutdown io channel and send DISCONNECTING notification and send
> DISCONNECTED notification and free the device on callback.
> ---
> android/pan.c | 20 ++++++++++----------
> 1 file changed, 10 insertions(+), 10 deletions(-)
I've applied the first two patches, but one thing with this one:
> diff --git a/android/pan.c b/android/pan.c
> index b83f534..f64b09a 100644
> --- a/android/pan.c
> +++ b/android/pan.c
> @@ -269,7 +269,7 @@ static void bt_pan_disconnect(const void *buf, uint16_t len)
> {
> const struct hal_cmd_pan_disconnect *cmd = buf;
> struct pan_device *dev;
> - uint8_t status;
> + uint8_t status = HAL_STATUS_FAILED;
> GSList *l;
> bdaddr_t dst;
>
> @@ -278,20 +278,20 @@ static void bt_pan_disconnect(const void *buf, uint16_t len)
> android2bdaddr(&cmd->bdaddr, &dst);
>
> l = g_slist_find_custom(devices, &dst, device_cmp);
> - if (!l) {
> - status = HAL_STATUS_FAILED;
> + if (!l)
> goto failed;
Since we in general try to avoid initializations upon declaration I'd
keep the status = HAL_STATUS_FAILED here. Even if it would be ok to move
it it shouldn't be in this patch since it's unrelated.
Johan
^ permalink raw reply
* Re: btrfs balance on single device
From: Leonidas Spyropoulos @ 2013-12-19 8:14 UTC (permalink / raw)
To: linux-btrfs@vger.kernel.org; +Cc: Hugo Mills
In-Reply-To: <20131218112935.GA9705@pdb1.th.formicary.net>
On Wed, Dec 18, 2013 at 11:29 AM, Leonidas Spyropoulos
<artafinde@gmail.com> wrote:
> On Wed, Dec 18, 2013 at 11:05:29AM +0000, Hugo Mills wrote:
>> On Wed, Dec 18, 2013 at 10:44:43AM +0000, Leonidas Spyropoulos wrote:
>> > I'm using the same subject as it might be relevant, feel free to change it.#
>> >
>> > I'm trying to do some maintenance to the system running over a btrfs file system on root (/). I started a balance on the '/' partition and it failed with the below information:
>> > $ sudo btrfs balance start /
>> > [sudo] password for inglor:
>> > ERROR: error during balancing '/' - No space left on device
>> > There may be more info in syslog - try dmesg | tail
>> > $ dmesg | tail
>> > [93827.115887] btrfs: found 29461 extents
>> > [93827.481849] btrfs: relocating block group 29855055872 flags 1
>> > [93841.646011] btrfs: found 33171 extents
>> > [93851.421207] btrfs: found 33171 extents
>> > [93851.782054] btrfs: relocating block group 28781314048 flags 1
>> > [93866.815342] btrfs: found 52535 extents
>> > [93877.159354] btrfs: found 52534 extents
>> > [93877.356805] btrfs: relocating block group 28747759616 flags 34
>> > [93880.287185] btrfs: found 1 extents
>> > [93880.608798] btrfs: 1 enospc errors during balance
>>
>> You don't specify your kernel version, but if it's older than 3.11
>> or so, you should probably upgrade -- 3.10 and earlier had occasional
>> bugs where the block reserve system never kept enough blocks free to
>> add a new metadata chunk when it was needed, which led to exactly this
>> kind of symptom.
>
> You are right, apologies. It is an up to date Archlinux box with a kernel:
> $ uname -a
> Linux tiamat 3.12.5-1-ARCH #1 SMP PREEMPT Thu Dec 12 12:57:31 CET 2013 x86_64 GNU/Linux
>
>>
>> Alternatively, and this is a bit of a long shot given that the
>> error seems to have been while relocating your system chunk (which
>> argues against this particular diagnosis), but:
>>
>> Do you have a large file on that filesystem (larger than 1 GiB)?
>
> Unlikely since the btrfs file system in question is '/' exluding /opt and /media directories (these are other partitions)
> $ sudo find / -type f -size +1048576k -and -not -path "/media*" -print
> /proc/kcore
> find: `/proc/27221/task/27221/fd/5': No such file or directory
> find: `/proc/27221/task/27221/fdinfo/5': No such file or directory
> find: `/proc/27221/fd/5': No such file or directory
> find: `/proc/27221/fdinfo/5': No such file or directory
> find: `/run/user/1000/gvfs': Permission denied
> inglor@tiamat ~$
>
>>
>> If so, I would recommend switching to a 3.12 kernel, and running a
>> defrag on the file. There's a known and now-fixed bug where you can
>> get ENOSPC while balancing, if a file has an extent larger than 1 GiB
>> in size. (The bug being that there's an extent over 1 GiB in size in
>> the first place).
>
> I might try the defrag option anyway and restart the balance operation, see if this will help anyway.
Some progress on this. I managed to do a balance on data only. The
problem seems to be happening when doing a metadata balance
$ sudo btrfs balance start -m /
[sudo] password for inglor:
ERROR: error during balancing '/' - No space left on device
There may be more info in syslog - try dmesg | tail
$ dmesg | tail
[171492.384314] systemd-journald[183]: Deleted empty journal
/var/log/journal/64cfb6f6c9d1625e7fa463c200000475/user-120@8b61bc353813451babcaa25dfc82c64e-0000000000000000-0000000000000000.journal
(2924544 bytes).
[171492.384375] systemd-journald[183]: Vacuuming done, freed 2924544 bytes
[172242.011051] btrfs: relocating block group 109781712896 flags 36
[172242.075298] btrfs: relocating block group 109748158464 flags 34
[172242.286016] btrfs: found 1 extents
[172242.419286] btrfs: 1 enospc errors during balance
Is there a way to recreate the metadata? (I'm guessing the answer is balance..)
>
> Thanks,
> Leonidas
>
>>
>> Hugo.
>>
>> --
>> === Hugo Mills: hugo@... carfax.org.uk | darksatanic.net | lug.org.uk ===
>> PGP key: 65E74AC0 from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
>> --- I'd make a joke about UDP, but I don't know if ---
>> anyone's actually listening...
--
Caution: breathing may be hazardous to your health.
#include <stdio.h>
int main(){printf("%s","\x4c\x65\x6f\x6e\x69\x64\x61\x73");}
^ permalink raw reply
* Re: [Qemu-devel] [RFC qom-cpu v4 00/10] i386: add cpu hot remove support
From: Chen Fan @ 2013-12-19 8:10 UTC (permalink / raw)
To: Igor Mammedov; +Cc: qemu-devel, Andreas Färber
In-Reply-To: <20131128154139.6e9cbfe3@nial.usersys.redhat.com>
On Thu, 2013-11-28 at 15:41 +0100, Igor Mammedov wrote:
> On Wed, 9 Oct 2013 17:43:08 +0800
> Chen Fan <chen.fan.fnst@cn.fujitsu.com> wrote:
>
> > Via implementing ACPI standard methods _EJ0 in bios, after Guest OS hot remove
> > one vCPU, it is able to send a signal to QEMU, then QEMU could notify
> > the assigned vCPU of exiting. meanwhile, and intruduce the QOM command 'cpu-del' to remove
> > vCPU from QEMU itself.
>
> have you tried following sequence:
> cpu-add 1
> cpu-add 2
> cpu-del 1
> and then do migration?
Hi, igor,
I have one question to confirm, After I started VM with -smp 1,
maxcpus=4, then did following sequence:
1) cpu-add id=2
2) migrate
on the destination side,
when I configured the VM with -smp 2, maxcpus=4, then migration failed.
when I configured the VM with -smp 3, maxcpus=4, then the destination VM
has three VCPU threads and could not add cpu 1. was this a bug? or how
to do migration?
Thanks,
Chen
> >
> > this work is based on Andreas Färber's qom-cpu branch tree.
> > git://github.com/afaerber/qemu-cpu.git
> >
> > this series patches must be used with seabios patch and KVM patch together.
> >
> > for KVM patches:
> > http://comments.gmane.org/gmane.comp.emulators.kvm.devel/114347
> >
> > for seabios patches:
> > http://comments.gmane.org/gmane.comp.emulators.qemu/230460
> >
> > Chen Fan (10):
> > x86: move apic_state field from CPUX86State to X86CPU
> > apic: remove redundant variable 'apic_no' from apic_init_common()
> > apic: remove local_apics array and using CPU_FOREACH instead
> > x86: add x86_cpu_unrealizefn() for cpu apic remove
> > qmp: add 'cpu-del' command support
> > qom cpu: rename variable 'cpu_added_notifier' to
> > 'cpu_hotplug_notifier'
> > qom cpu: add UNPLUG cpu notifier support
> > i386: implement pc interface pc_hot_del_cpu()
> > piix4: implement function cpu_status_write() for vcpu ejection
> > cpus: reclaim allocated vCPU objects
> >
> > cpu-exec.c | 2 +-
> > cpus.c | 51 +++++++++++++++++++++--
> > hw/acpi/piix4.c | 66 ++++++++++++++++++++++++------
> > hw/i386/kvm/apic.c | 18 +++++++-
> > hw/i386/kvmvapic.c | 8 ++--
> > hw/i386/pc.c | 51 ++++++++++++++++++-----
> > hw/i386/pc_piix.c | 3 +-
> > hw/intc/apic.c | 91 ++++++++++++++++++++++-------------------
> > hw/intc/apic_common.c | 17 ++------
> > include/hw/boards.h | 2 +
> > include/hw/i386/apic_internal.h | 6 +--
> > include/hw/i386/pc.h | 1 +
> > include/qom/cpu.h | 20 +++++++++
> > include/sysemu/kvm.h | 1 +
> > include/sysemu/sysemu.h | 2 +-
> > kvm-all.c | 25 +++++++++++
> > qapi-schema.json | 12 ++++++
> > qmp-commands.hx | 23 +++++++++++
> > qmp.c | 9 ++++
> > qom/cpu.c | 26 +++++++++---
> > target-i386/cpu-qom.h | 5 +++
> > target-i386/cpu.c | 57 ++++++++++++++++++++------
> > target-i386/cpu.h | 4 --
> > target-i386/helper.c | 9 ++--
> > target-i386/kvm.c | 23 +++++------
> > target-i386/misc_helper.c | 8 ++--
> > 26 files changed, 403 insertions(+), 137 deletions(-)
> >
>
^ permalink raw reply
* Re: [PATCH] Makefile: fix endless make when 'make barebox.s'
From: Sascha Hauer @ 2013-12-19 8:10 UTC (permalink / raw)
To: u74147; +Cc: barebox
In-Reply-To: <1387194442-2607-1-git-send-email-u74147@gmail.com>
On Mon, Dec 16, 2013 at 07:47:22PM +0800, u74147@gmail.com wrote:
> From: Du Huanpeng <u74147@gmail.com>
>
> add the same target barebox.s (with a lowercase 's')
> to make both work with barebox.S and barebox.s.
>
> Signed-off-by: Du Huanpeng <u74147@gmail.com>
Applied, thanks
Sascha
> ---
> Makefile | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/Makefile b/Makefile
> index 5e17a49..d7b5d23 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -701,7 +701,7 @@ barebox.uimage: $(KBUILD_BINARY) FORCE
> $(call if_changed,barebox_mkimage)
>
> ifdef CONFIG_X86
> -barebox.S: barebox
> +barebox.S barebox.s: barebox
> ifdef CONFIG_X86_HDBOOT
> @echo "-------------------------------------------------" > barebox.S
> @echo " * MBR content" >> barebox.S
> @@ -723,7 +723,7 @@ endif
> @echo " * Init Calls content" >> barebox.S
> $(Q)$(OBJDUMP) -j .barebox_initcalls -d barebox >> barebox.S
> else
> -barebox.S: barebox FORCE
> +barebox.S barebox.s: barebox FORCE
> $(call if_changed,disasm)
> endif
>
> --
> 1.7.9.5
>
>
> _______________________________________________
> barebox mailing list
> barebox@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/barebox
>
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: GPMI-NAND ECC DT binding (was: Re: [PATCH v3 22/28] mtd: nand: pxa3xx: Introduce multiple page I/O support)
From: Huang Shijie @ 2013-12-19 7:39 UTC (permalink / raw)
To: Brian Norris; +Cc: devicetree, linux-mtd@lists.infradead.org, Ezequiel Garcia
In-Reply-To: <20131219073138.GB10846@norris-Latitude-E6410>
On Wed, Dec 18, 2013 at 11:31:38PM -0800, Brian Norris wrote:
> (Trim the CC list)
>
> Hi Huang,
>
> On Wed, Dec 04, 2013 at 01:41:25PM -0800, Brian Norris wrote:
> > I'd like to follow up on this question, since you didn't answer it, and
> > it's still relevant, since we haven't yet merged your GPMI DT binding
> > (it's queued for the next merge window):
> >
> > On Mon, Nov 18, 2013 at 10:50:59AM -0800, Brian Norris wrote:
> > > Do you have a good reason why you needed GPMI NAND to choose the ECC
> > > configuration (a la "miminum ECC") instead of fully specifying your ECC
> > > selection in device tree? I recall most of your arguments were about
> > > using an ECC strength that leaves room for user data in OOB (e.g., with
> > > JFFS2). But you could have done the same thing by creating a proper DT
> > > property to describe the desidered ECC strength, with no real
> > > disadvantage, right?
> >
> > I'll rephrase it: why can't/don't you define a GPMI binding for the
> > actual ECC level, like:
> >
> > fsl,nand-ecc-strength and fsl,nand-ecc-sector
> >
> > ?
> >
> > Then, you could still default to the old geometry if these properties
> > aren't present, and you don't have to rely on Linux auto-detecting ECC
> > properties for non-ONFI chips.
>
> Ping? Do you have any comment here? It seems like a more precise DT
sorry, i did not see this email.
> binding could still be useful for GPMI NAND.
agree.
but i suggest add a more common DT for it. I think other drivers may also
use it.
We have "nand-ecc-mode" now, why not add a more generic dt such as:
"nand-ecc-strength"
thanks
Huang Shijie
^ permalink raw reply
* Re: Porting barebox (devicetree) to Variscite iMX6 SOM
From: Sascha Hauer @ 2013-12-19 8:09 UTC (permalink / raw)
To: Michael Burkey; +Cc: barebox
In-Reply-To: <CAJyuEee+jyV6DTs3ZGYTercny4FNnxjj_PwWxNmjAEhe2eqeBg@mail.gmail.com>
On Wed, Dec 18, 2013 at 04:34:20PM -0500, Michael Burkey wrote:
> I have answered some of my own questions and got more working on the
> Variscite port.
>
> So, for anyone else trying to do basically the same thing I am:
>
> 1) The built-in devicetree does get probed and enumerated.
>
> 2) By the time the _init function in board.c gets called, the probing
> is complete and devices such as i2c are available.
>
> I also got my uart problem fixed -- which was actually a devicetree
> error on my part.
>
> However, I am still back to working on part of my problem. When
> configured correctly, the Variscite development board is SUPPOSED to
> gate the 3.3V line to the onboard peripherals using the 3.3V output of
> the PF0100 -- which, unfortunately, means that some of the devices
> that may need to be probed in devicetree probably won't respond until
> after I can use I2C to properly configure the PF0100.
>
> So...after I have configured the PF0100, can "oftree -p" be used to
> re-probe the current tree?? Or do I have to figure out a way to bring
> I2C up early as well?
For the kernel the correct solution is to add regulators to the device
nodes which need the 3.3V line, so that the drivers for these devices
request and enable the regulators before accessing the devices.
In barebox we are not (yet?) prepared for this. Right now your options
are:
a) make sure the PF0100 is available before the devices using it (that
may mean to move the i2c-imx driver and the PF0100 driver to an earlier
initcall level).
b) Use an 'early' i2c driver (For example arch/ppc/mach-mpc85xx/fsl_i2c.c
has this, the code should even work on i.MX)
c) implement regulator support for barebox
I would first try to get away with a), although from my point of view I
of course recommend c) ;)
Sascha
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: [PATCH 2/3] android/socket: Connect directly to RFCOMM chan is uuid is zero
From: Johan Hedberg @ 2013-12-19 8:09 UTC (permalink / raw)
To: Andrei Emeltchenko; +Cc: linux-bluetooth
In-Reply-To: <1387376336-17092-3-git-send-email-Andrei.Emeltchenko.news@gmail.com>
Hi Andrei,
On Wed, Dec 18, 2013, Andrei Emeltchenko wrote:
> From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
>
> Check uuid and connect to specified channel number directly.
> ---
> android/socket.c | 32 +++++++++++++++++++++++---------
> 1 file changed, 23 insertions(+), 9 deletions(-)
Please fix the commit message: capital UUID, s/is/if/ and
s/chan/channel/ in the subject.
> +static bool is_empty(const uint8_t *uuid)
> +{
> + static uint8_t zero_uuid[16];
> +
> + return memcmp(uuid, zero_uuid, sizeof(zero_uuid)) == 0;
> +}
> +
> static void handle_connect(const void *buf, uint16_t len)
> {
> const struct hal_cmd_sock_connect *cmd = buf;
> - struct rfcomm_sock *rfsock;
> + struct rfcomm_sock *rfsock = NULL;
Firstly this rfsock = NULL seems completely unrelated to this patch, and
secondly it's not even needed. Please remove it.
> uuid_t uuid;
> int hal_fd = -1;
>
> @@ -940,17 +947,21 @@ static void handle_connect(const void *buf, uint16_t len)
>
> android2bdaddr(cmd->bdaddr, &rfsock->dst);
>
> - memset(&uuid, 0, sizeof(uuid));
> - uuid.type = SDP_UUID128;
> - memcpy(&uuid.value.uuid128, cmd->uuid, sizeof(uint128_t));
> + if (is_empty(cmd->uuid)) {
> + if (!do_connect(rfsock, cmd->channel))
> + goto failed;
If this is_empty function was really needed it should at least be called
uuid_is_empty to make it clear what it's for. However, since it's a
one-line function and you've only got a single place needing it, I'd
just declare a static const uint8_t zero_uuuid[16] in handle_connect()
and do the memcmp directly there.
Johan
^ permalink raw reply
* [Buildroot] [PATCH 1/1] package: add <pkg>_VERSION_MAJOR variable
From: Thomas De Schampheleire @ 2013-12-19 8:09 UTC (permalink / raw)
To: buildroot
In-Reply-To: <52B2A7F3.3090105@trzebnica.net>
Hi Jerzy,
On Thu, Dec 19, 2013 at 9:01 AM, Jerzy Grzegorek
<jerzy.grzegorek@trzebnica.net> wrote:
>>
>> Jerzy: how did you determine the list of files to change? Manually
>> opening all of them, or some more automated method?
>
>
> I used the automated method.
That sounds interesting. Could you explain in more detail how you
achieved this? Which command did you use?
Thanks,
Thomas
^ permalink raw reply
* [RESEND PATCH v7 1/5] omap3isp: Modify clocks registration to avoid circular references
From: Mike Turquette @ 2013-12-19 8:07 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <52AF7B4D.2010305@gmail.com>
Quoting Sylwester Nawrocki (2013-12-16 14:14:37)
> Hi Mike,
>
> Laurent has already taken this patch into his tree, could you apply
> the remaining ones to your clk tree so this series has enough exposure
> in -next ?
I've taken this in privately to do a little testing. If all goes well
then I'll push it out to clk-next very soon.
Thanks!
Mike
>
> Thanks,
> Sylwester
^ permalink raw reply
* Re: [PATCH] mmc: atmel-mci: document clock properties
From: Ludovic Desroches @ 2013-12-19 8:04 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Arnd Bergmann, Rob Landley, Nicolas Ferre, devicetree, linux-doc,
linux-kernel
In-Reply-To: <1387272977-4523-1-git-send-email-b.brezillon@overkiz.com>
On Tue, Dec 17, 2013 at 10:36:17AM +0100, Boris BREZILLON wrote:
> Document the clock properties required by the atmel-mci driver.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> .../devicetree/bindings/mmc/atmel-hsmci.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> index 0a85c70..07ad020 100644
> --- a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> @@ -13,6 +13,9 @@ Required properties:
> - #address-cells: should be one. The cell is the slot id.
> - #size-cells: should be zero.
> - at least one slot node
> +- clock-names: tuple listing input clock names.
> + Required elements: "mci_clk"
> +- clocks: phandles to input clocks.
>
> The node contains child nodes for each slot that the platform uses
>
> @@ -24,6 +27,8 @@ mmc0: mmc@f0008000 {
> interrupts = <12 4>;
> #address-cells = <1>;
> #size-cells = <0>;
> + clock-names = "mci_clk";
> + clocks = <&mci0_clk>;
>
> [ child node definitions...]
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] mmc: atmel-mci: document clock properties
From: Ludovic Desroches @ 2013-12-19 8:04 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Arnd Bergmann, Rob Landley, Nicolas Ferre, devicetree, linux-doc,
linux-kernel
In-Reply-To: <1387272977-4523-1-git-send-email-b.brezillon@overkiz.com>
On Tue, Dec 17, 2013 at 10:36:17AM +0100, Boris BREZILLON wrote:
> Document the clock properties required by the atmel-mci driver.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> .../devicetree/bindings/mmc/atmel-hsmci.txt | 5 +++++
> 1 file changed, 5 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> index 0a85c70..07ad020 100644
> --- a/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> +++ b/Documentation/devicetree/bindings/mmc/atmel-hsmci.txt
> @@ -13,6 +13,9 @@ Required properties:
> - #address-cells: should be one. The cell is the slot id.
> - #size-cells: should be zero.
> - at least one slot node
> +- clock-names: tuple listing input clock names.
> + Required elements: "mci_clk"
> +- clocks: phandles to input clocks.
>
> The node contains child nodes for each slot that the platform uses
>
> @@ -24,6 +27,8 @@ mmc0: mmc@f0008000 {
> interrupts = <12 4>;
> #address-cells = <1>;
> #size-cells = <0>;
> + clock-names = "mci_clk";
> + clocks = <&mci0_clk>;
>
> [ child node definitions...]
> };
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] clk: at91: fix pmc_clk_ids data type attriubte
From: Mike Turquette @ 2013-12-19 7:56 UTC (permalink / raw)
To: Boris BREZILLON, Fengguang Wu, Nicolas Ferre
Cc: linux-arm-kernel, linux-kernel, Boris BREZILLON
In-Reply-To: <1387229127-7605-1-git-send-email-b.brezillon@overkiz.com>
Quoting Boris BREZILLON (2013-12-16 13:25:27)
> Fix pmc_clk_ids data type attribute (__initdata -> __initconst).
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
> Reported-by: Fengguang Wu <fengguang.wu@intel.com>
Acked-by: Mike Turquette <mturquette@linaro.org>
> ---
> drivers/clk/at91/pmc.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/drivers/clk/at91/pmc.c b/drivers/clk/at91/pmc.c
> index 7b9db60..4c03eda 100644
> --- a/drivers/clk/at91/pmc.c
> +++ b/drivers/clk/at91/pmc.c
> @@ -228,7 +228,7 @@ out_free_pmc:
> return NULL;
> }
>
> -static const struct of_device_id pmc_clk_ids[] __initdata = {
> +static const struct of_device_id pmc_clk_ids[] __initconst = {
> /* Main clock */
> {
> .compatible = "atmel,at91rm9200-clk-main",
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] arch: metag: kernel: export 'cpu_core_map' in "topology.c"
From: Chen Gang @ 2013-12-19 8:03 UTC (permalink / raw)
To: James Hogan; +Cc: linux-metag, linux-kernel@vger.kernel.org
Need export 'cpu_core_map', or cann't pass compiling with allmodconfig,
the related error:
MODPOST 2909 modules
ERROR: "cpu_core_map" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!
Signed-off-by: Chen Gang <gang.chen.5i5j@gmail.com>
---
arch/metag/kernel/topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/metag/kernel/topology.c b/arch/metag/kernel/topology.c
index bec3dec..4ba5957 100644
--- a/arch/metag/kernel/topology.c
+++ b/arch/metag/kernel/topology.c
@@ -19,6 +19,7 @@
DEFINE_PER_CPU(struct cpuinfo_metag, cpu_data);
cpumask_t cpu_core_map[NR_CPUS];
+EXPORT_SYMBOL(cpu_core_map);
static cpumask_t cpu_coregroup_map(unsigned int cpu)
{
--
1.7.11.7
^ permalink raw reply related
* [PATCH] arch: metag: kernel: export 'cpu_core_map' in "topology.c"
From: Chen Gang @ 2013-12-19 8:03 UTC (permalink / raw)
To: James Hogan
Cc: linux-metag-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
Need export 'cpu_core_map', or cann't pass compiling with allmodconfig,
the related error:
MODPOST 2909 modules
ERROR: "cpu_core_map" [drivers/staging/lustre/lustre/libcfs/libcfs.ko] undefined!
Signed-off-by: Chen Gang <gang.chen.5i5j-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
---
arch/metag/kernel/topology.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/metag/kernel/topology.c b/arch/metag/kernel/topology.c
index bec3dec..4ba5957 100644
--- a/arch/metag/kernel/topology.c
+++ b/arch/metag/kernel/topology.c
@@ -19,6 +19,7 @@
DEFINE_PER_CPU(struct cpuinfo_metag, cpu_data);
cpumask_t cpu_core_map[NR_CPUS];
+EXPORT_SYMBOL(cpu_core_map);
static cpumask_t cpu_coregroup_map(unsigned int cpu)
{
--
1.7.11.7
--
To unsubscribe from this list: send the line "unsubscribe linux-metag" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply related
* Re: [PATCH] i2c: at91: document clock properties
From: Ludovic Desroches @ 2013-12-19 8:02 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Rob Landley, Wolfram Sang, Nicolas Ferre, Arnd Bergmann,
Greg Kroah-Hartman, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, linux-i2c
In-Reply-To: <1387295644-7382-1-git-send-email-b.brezillon@overkiz.com>
On Tue, Dec 17, 2013 at 04:54:04PM +0100, Boris BREZILLON wrote:
> Document the clock properties required by the at91 i2c bus driver.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index b689a0d..4fade84 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -9,6 +9,7 @@ Required properties :
> - interrupts: interrupt number to the cpu.
> - #address-cells = <1>;
> - #size-cells = <0>;
> +- clocks: phandles to input clocks.
>
> Optional properties:
> - Child nodes conforming to i2c bus binding
> @@ -21,6 +22,7 @@ i2c0: i2c@fff84000 {
> interrupts = <12 4 6>;
> #address-cells = <1>;
> #size-cells = <0>;
> + clocks = <&twi0_clk>;
>
> 24c512@50 {
> compatible = "24c512";
> --
> 1.7.9.5
>
^ permalink raw reply
* [PATCH] i2c: at91: document clock properties
From: Ludovic Desroches @ 2013-12-19 8:02 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1387295644-7382-1-git-send-email-b.brezillon@overkiz.com>
On Tue, Dec 17, 2013 at 04:54:04PM +0100, Boris BREZILLON wrote:
> Document the clock properties required by the at91 i2c bus driver.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index b689a0d..4fade84 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -9,6 +9,7 @@ Required properties :
> - interrupts: interrupt number to the cpu.
> - #address-cells = <1>;
> - #size-cells = <0>;
> +- clocks: phandles to input clocks.
>
> Optional properties:
> - Child nodes conforming to i2c bus binding
> @@ -21,6 +22,7 @@ i2c0: i2c at fff84000 {
> interrupts = <12 4 6>;
> #address-cells = <1>;
> #size-cells = <0>;
> + clocks = <&twi0_clk>;
>
> 24c512 at 50 {
> compatible = "24c512";
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [PATCH] i2c: at91: document clock properties
From: Ludovic Desroches @ 2013-12-19 8:02 UTC (permalink / raw)
To: Boris BREZILLON
Cc: Rob Landley, Wolfram Sang, Nicolas Ferre, Arnd Bergmann,
Greg Kroah-Hartman, devicetree, linux-doc, linux-kernel,
linux-arm-kernel, linux-i2c
In-Reply-To: <1387295644-7382-1-git-send-email-b.brezillon@overkiz.com>
On Tue, Dec 17, 2013 at 04:54:04PM +0100, Boris BREZILLON wrote:
> Document the clock properties required by the at91 i2c bus driver.
>
> Signed-off-by: Boris BREZILLON <b.brezillon@overkiz.com>
Acked-by: Ludovic Desroches <ludovic.desroches@atmel.com>
> ---
> Documentation/devicetree/bindings/i2c/i2c-at91.txt | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/Documentation/devicetree/bindings/i2c/i2c-at91.txt b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> index b689a0d..4fade84 100644
> --- a/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> +++ b/Documentation/devicetree/bindings/i2c/i2c-at91.txt
> @@ -9,6 +9,7 @@ Required properties :
> - interrupts: interrupt number to the cpu.
> - #address-cells = <1>;
> - #size-cells = <0>;
> +- clocks: phandles to input clocks.
>
> Optional properties:
> - Child nodes conforming to i2c bus binding
> @@ -21,6 +22,7 @@ i2c0: i2c@fff84000 {
> interrupts = <12 4 6>;
> #address-cells = <1>;
> #size-cells = <0>;
> + clocks = <&twi0_clk>;
>
> 24c512@50 {
> compatible = "24c512";
> --
> 1.7.9.5
>
^ permalink raw reply
* Re: [XFS BUG] xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
From: arno @ 2013-12-19 8:02 UTC (permalink / raw)
To: Dave Chinner; +Cc: linux-kernel, xfs
In-Reply-To: <20131218223312.GP31386@dastard>
On 18-Dec-13 11:33 PM, Dave Chinner wrote:
> On Wed, Dec 18, 2013 at 04:00:42PM +0100, arno wrote:
>> Hello,
>>
>> (Please keep me in CC, I'm not subscribed)
>>
>> Just got "xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure
>> needs cleaning" when trying to grow a logical Volume. Sorry, I lost the
>> xfs_growfs output.
>>
>> After collecting some info, I ran xfs_repair, and that seemed to fix it,
>> so no harm done. After fixing, the FS had the new, increased size, if
>> that matters.
>
> This isn't the first time you've grown the filesystem, is it?
No, indeed it isn't.
> On older kernels, growfs could leave trailing garbage in the new
> secondary superblocks it created. This was fixed in kernel v3.8 by
> commit:
>
> 1375cb6 xfs: growfs: don't read garbage for new secondary superblocks
>
> This garbage is detected by other changes made in v3.8 that verify
> the secondary superblocks as they are read.
>
> 9802182 xfs: verify superblocks as they are read from disk
>
> So if you grew the filesystem on a kernel older than v3.8, growing
> it again on a v3.8+ kernel will detect the superblock corruption and
> throw this error.
I'm pretty sure that last time I grew it, it was with a pre v3.8-kernel.
> xfs_repair was recently fixed to detect the garbage in secondary
> superblocks and zero it:
>
> cbd7508 xfs_repair: zero out unused parts of superblocks
>
> So what you need to do is run xfs_repair built from the development
> git tree and run it on your filesystem. That will remove the garbage
> from the superblocks and make this problem go away forever.
Will do. Thanks!
--
Regards.
Arno.
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [XFS BUG] xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure needs cleaning
From: arno @ 2013-12-19 8:02 UTC (permalink / raw)
To: Dave Chinner; +Cc: xfs, linux-kernel
In-Reply-To: <20131218223312.GP31386@dastard>
On 18-Dec-13 11:33 PM, Dave Chinner wrote:
> On Wed, Dec 18, 2013 at 04:00:42PM +0100, arno wrote:
>> Hello,
>>
>> (Please keep me in CC, I'm not subscribed)
>>
>> Just got "xfs_growfs: XFS_IOC_FSGROWFSDATA xfsctl failed: Structure
>> needs cleaning" when trying to grow a logical Volume. Sorry, I lost the
>> xfs_growfs output.
>>
>> After collecting some info, I ran xfs_repair, and that seemed to fix it,
>> so no harm done. After fixing, the FS had the new, increased size, if
>> that matters.
>
> This isn't the first time you've grown the filesystem, is it?
No, indeed it isn't.
> On older kernels, growfs could leave trailing garbage in the new
> secondary superblocks it created. This was fixed in kernel v3.8 by
> commit:
>
> 1375cb6 xfs: growfs: don't read garbage for new secondary superblocks
>
> This garbage is detected by other changes made in v3.8 that verify
> the secondary superblocks as they are read.
>
> 9802182 xfs: verify superblocks as they are read from disk
>
> So if you grew the filesystem on a kernel older than v3.8, growing
> it again on a v3.8+ kernel will detect the superblock corruption and
> throw this error.
I'm pretty sure that last time I grew it, it was with a pre v3.8-kernel.
> xfs_repair was recently fixed to detect the garbage in secondary
> superblocks and zero it:
>
> cbd7508 xfs_repair: zero out unused parts of superblocks
>
> So what you need to do is run xfs_repair built from the development
> git tree and run it on your filesystem. That will remove the garbage
> from the superblocks and make this problem go away forever.
Will do. Thanks!
--
Regards.
Arno.
^ permalink raw reply
* Vanilla 3.10.22 kvm_arch_vcpu_uninit => WARNING: at kernel/jump_label.c:80 __static_key_slow_dec
From: Stefan Priebe @ 2013-12-19 8:02 UTC (permalink / raw)
To: LKML; +Cc: p.herz, dhecht, fweisbec, hpa, mingo
In-Reply-To: <52B1CCA8.7010100@profihost.ag>
Hello list,
while running Qemu 1.7.0 on vanilla kernel 3.10.22 i've seen several
times this error:
[99964.659578] WARNING: at kernel/jump_label.c:80
__static_key_slow_dec+0xb6/0xc0()
[99964.659579] jump label: negative count!
[99964.659579] Modules linked in: sch_htb act_police cls_u32 sch_ingress
vhost_net tun macvtap macvlan netconsole ipt_REJECT dlm sctp
iptable_filter ip_tables x_tables iscsi_tcp libiscsi_tcp libiscsi
scsi_transport_iscsi fuse nfsd auth_rpcgss oid_registry bonding ext2
8021q garp acpi_cpufreq mperf coretemp kvm_intel kvm crc32_pclmul
ghash_clmulni_intel microcode i2c_i801 button dm_mod raid1 md_mod usbhid
usb_storage ohci_hcd sg sd_mod ehci_pci ehci_hcd igb ahci i2c_algo_bit
libahci isci usbcore i2c_core usb_common ptp libsas ixgbe(O)
scsi_transport_sas pps_core
[99964.659595] CPU: 32 PID: 6616 Comm: kvm Tainted: G W O
3.10.22+63-ph #1
[99964.659596] Hardware name: Supermicro
X9DRW-3LN4F+/X9DRW-3TF+/X9DRW-3LN4F+/X9DRW-3TF+, BIOS 3.00 07/05/2013
[99964.659596] 0000000000000009 ffff882ff83359f8 ffffffff8151ba2d
ffff882ff8335a38
[99964.659599] ffffffff8104828b 00000000f8335a18 ffffffffa04d7c40
00000000000000fa
[99964.659602] ffffffffa04d7c60 ffff8817eca74160 ffff8817f92c51a0
ffff882ff8335a98
[99964.659605] Call Trace:
[99964.659606] [<ffffffff8151ba2d>] dump_stack+0x19/0x1b
[99964.659608] [<ffffffff8104828b>] warn_slowpath_common+0x6b/0xa0
[99964.659611] [<ffffffff81048361>] warn_slowpath_fmt+0x41/0x50
[99964.659613] [<ffffffff810e0036>] __static_key_slow_dec+0xb6/0xc0
[99964.659614] [<ffffffff810e0071>] static_key_slow_dec_deferred+0x11/0x20
[99964.659621] [<ffffffffa04bb010>] kvm_free_lapic+0x90/0xa0 [kvm]
[99964.659627] [<ffffffffa04a4fb3>] kvm_arch_vcpu_uninit+0x23/0x90 [kvm]
[99964.659632] [<ffffffffa048ba20>] kvm_vcpu_uninit+0x20/0x40 [kvm]
[99964.659636] [<ffffffffa01cec12>] vmx_free_vcpu+0x52/0x70 [kvm_intel]
[99964.659642] [<ffffffffa04a46af>] kvm_arch_vcpu_free+0x4f/0x60 [kvm]
[99964.659648] [<ffffffffa04a51d2>] kvm_arch_destroy_vm+0xf2/0x1f0 [kvm]
[99964.659650] [<ffffffff81070be8>] ? synchronize_srcu+0x18/0x20
[99964.659652] [<ffffffff81125b9a>] ? mmu_notifier_unregister+0xaa/0xe0
[99964.659658] [<ffffffffa048e80e>] kvm_put_kvm+0x10e/0x1b0 [kvm]
[99964.659663] [<ffffffffa048ea33>] kvm_vcpu_release+0x13/0x20 [kvm]
[99964.659665] [<ffffffff81142fb1>] __fput+0xe1/0x230
[99964.659667] [<ffffffff81143109>] ____fput+0x9/0x10
[99964.659669] [<ffffffff81068985>] task_work_run+0xb5/0xd0
[99964.659671] [<ffffffff8104d76c>] do_exit+0x2ac/0xa30
[99964.659673] [<ffffffff810925fc>] ? __unqueue_futex+0x2c/0x60
[99964.659675] [<ffffffff810937b2>] ? futex_wait+0x122/0x280
[99964.659677] [<ffffffff8104df6a>] do_group_exit+0x3a/0xa0
[99964.659679] [<ffffffff8105bf14>] get_signal_to_deliver+0x1a4/0x590
[99964.659681] [<ffffffff81002292>] do_signal+0x52/0x5f0
[99964.659683] [<ffffffff8109526d>] ? do_futex+0x12d/0x590
[99964.659685] [<ffffffff8105c8c2>] ? copy_siginfo_to_user+0x122/0x2c0
[99964.659687] [<ffffffff8105ccac>] ? SYSC_rt_sigtimedwait+0xac/0xd0
[99964.659689] [<ffffffff8107d020>] ? __enqueue_entity+0x70/0x80
[99964.659691] [<ffffffff81002895>] do_notify_resume+0x65/0x80
[99964.659693] [<ffffffff81521598>] int_signal+0x12/0x17
[99964.659694] ---[ end trace d92047d5c4d5d3d1 ]---
Stefan
^ 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.