* Re: [GIT] pull request for x86 platform drivers tree
From: Matthew Garrett @ 2011-10-31 22:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: platform-driver-x86
In-Reply-To: <CA+55aFwKz+-FeoZQB_Y1Oj1dEBo8LxjgLPUP=Nz0TXSTcdN2Ng@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 481 bytes --]
On Mon, Oct 31, 2011 at 03:49:19PM -0700, Linus Torvalds wrote:
> On Mon, Oct 31, 2011 at 6:24 AM, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> >
> > are available in the git repository at:
> > git://cavan.codon.org.uk/platform-drivers-x86.git for_linus
>
> So I've never seen this host before, and have no idea whose it is or
> why I should trust it..
>
> Please make me feel better about it.
Is this any help?
--
Matthew Garrett | mjg59@cavan.codon.org.uk
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Problems with 'xl create winxp' (hvm) on xen 4.1.2 (also affects GPLPV)
From: jim burns @ 2011-10-31 23:00 UTC (permalink / raw)
To: Ian Campbell, xen-devel, xen-users
In-Reply-To: <1320060379.23193.72.camel@zakaz.uk.xensource.com>
On Mon October 31 2011, 11:26:19 AM, Ian Campbell wrote:
> On Mon, 2011-10-31 at 10:50 +0000, Ian Campbell wrote:
> > On Sat, 2011-10-29 at 06:57 +0100, jim burns wrote:
> > > [...]
> > > New to 4.1.2:
> > >
> > > 1) Starting winxp with xl does not create a vif interface - only a
> > > tap one. More exactly, the vif is created, but does not get an ipv6
> > > address - it shows up in 'ifconfig -a', or 'ifconfig vifn.0' - and
> > > does not get added to the bridge. If you are using James' GPLPV
> > > drivers, you end up with no network connectivity, as they use vif,
> > > not tap. I'd be surprised if other pvhvm solutions don't see this
> > > also.
> >
> > I see this with the tip of xen-4.1-testing too but not with
> > xen-unstable. I'll see if I can figure out which backport is missing...
>
> 23047:4ca13a170482 "libxl: provide full path to vif hotplug script
> script" seems like a very plausible candidate, I bet
> "script=/etc/xen/scripts/vif-bridge" would function as a workaround.
Yep - that works. Should have guessed. You have to supply the full path to the
config file too, or it can't find it (doesn't default to searching /etc/xen).
> > [...]
> >
> > > 2) If your vif= line in your config specifies a bridge, such as
> > > 'bridge=virbr0', the '-net tap' option to qemu-dm remains as
> > > 'bridge=xenbr0', as if it was hard coded. Again, this is an hvm
> > > problem. 'xl create'-ing a pv domu correctly puts the vif on the
> > > requested bridge. (If memory serves, under xen 4.1.1, when the vif
> > > for an hvm domain was being put on a bridge, I believe it was on
> > > the bridge requested, so the problem is just with tap.)>
> > Similarly I can reproduce this too but only on 4.1.
>
> Actually this one is broken in unstable too.
>
> The handling of leading and trailing whitespace in the vif option seems
> to be completely b0rked in xl and e.g. "bridge = virbr1" ends up as key
> "bridge " and key " virbr1". That entire parser (actually, both of them
> -- there's a whole nother one in main_networkattach!) is a mess.
>
> There's probably a bandaid which can be applied but really the whole
> thing need ripping out and making sensible.
>
> As a workaround in the meantime you can probably avoid whitespace around
> the "=" and "," in the vif line.
>
Yep - that works too:
root@insp6400 10/31/11 6:31PM:~
[512] > xl create /etc/xen/winxp; brctl show; ps -A|grep qemu; netstat -tlp|
grep 59; renice -11 `pidof qemu-dm`; ps -A|grep vncv; ifconfig vif3.0 mtu
9000
Parsing config file /etc/xen/winxp
xc: info: VIRTUAL MEMORY ARRANGEMENT:
Loader: 0000000000100000->000000000017b270
TOTAL: 0000000000000000->000000002fc00000
ENTRY ADDRESS: 00000000001015a0
xc: info: PHYSICAL MEMORY ALLOCATION:
4KB PAGES: 0x0000000000009a00
2MB PAGES: 0x0000000000000131
1GB PAGES: 0x0000000000000000
Daemon running with PID 6804
bridge name bridge id STP enabled interfaces
virbr0 8000.feffffffffff yes tap3.0
xenbr0 8000.0015c5047d4f no bond0
6809 pts/1 S+ 0:00 grep --color=auto qemu
6758 ? RLsl 0:00 qemu-dm -d 3 -domain-name winxp -vnc 0.0.0.0:3 -k
en-us -serial pty -videoram 4 -boot cda -usb -usbdevice tablet -soundhw es1370
-acpi -vcpus 2 -vcpu_avail 0x3 -net
nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
tap,vlan=0,ifname=tap3.0,bridge=virbr0,script=no -M xenfv
tcp 0 0 *:5901 *:*
LISTEN 3283/Xvnc
tcp 0 0 *:5903 *:*
LISTEN 6758/qemu-dm
6758 (process ID) old priority 0, new priority -11
6907 pts/1 S+ 0:00 grep --color=auto vncv
root@insp6400 10/31/11 6:32PM:~
[513] > brctl show
bridge name bridge id STP enabled interfaces
virbr0 8000.feffffffffff yes tap3.0
vif3.0
xenbr0 8000.0015c5047d4f no bond0
For 4):
On Mon October 31 2011, 10:56:51 AM, Ian Campbell wrote:
> On Sat, 2011-10-29 at 07:17 +0100, jim burns wrote:
> > On Sat October 29 2011, 1:57:12 AM, jim burns wrote:
> > > For the remaining problems, note that 'xl create winxp' creates a
> > > qemu-dm process with the following parameters:
> > >
> > > qemu-dm -d 8 -domain-name winxp -vnc 0.0.0.0:3 -k en-us -serial pty
> > > -videoram 4 -boot cda -usb -usbdevice tablet -soundhw es1370 -acpi
> > > -vcpus 2 -vcpu_avail 0x3 -net
> > > nic,vlan=0,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > > tap,vlan=0,ifname=tap8.0,bridge=xenbr0,script=no -M xenfv>
> > Note, starting the domain with 'xm create' with the same config results
> > in:
> >
> > /usr/lib/xen/bin/qemu-dm -d 11 -domain-name winxp -videoram 4 -k en-us
> > -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3 -boot cda -soundhw
> > es1370 - localtime -serial pty -acpi -usbdevice tablet -net
> > nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
> > tap,vlan=1,ifname=tap11.0,bridge=xenbr0 -M xenfv
> >
> > Note, 'xl create' does not pass the '-localtime' option,
>
> that's the source of one of the missing features. Fixing it should be a
> case of adding the option to libxl_domain_build_info in the IDL,
> reacting to it in libxl__build_device_model_args_old and
> libxl__build_device_model_args_new and parsing the config file option
> into it in parse_config_data().
Hopefully, the fix for 3) (vncconsole=1) is just as simple.
> > and its '-net tap' specifies 'script=no', unlike 'xm create'.
>
> This is expected, with xl the script for tap devices is run via the
> hotplug mechanism (i.e. the same as vif) whereas xend apparently runs it
> via qemu. Either _should_ work.
>
> > Also, for some reason, the vlan numbers are different between xl and xm.
>
> That's ok, they are effectively arbitrary and just serve to bind the
> "-net nic,..." and "-net tap,..." options to one another (IOW the vlan
> ID needs to be consistent across those two options but is otherwise
> unimportant).
Thanx for the explanations.
On Mon October 31 2011, 10:50:32 AM, Ian Campbell wrote:
> > 5) Anything other than 'videoram=4' in your config will be ignored when
> > starting with xl, but not with xm. You will get an error in your qemu-dm
> > log file of the form:
> >
> >
> > -videoram option does not work with cirrus vga device model. Videoram
> > set to 4M.
>
> I'm not sure what's going on here, since this appears to be a qemu thing
> and that is the same for xend and xl. Perhaps they are choosing
> differing graphics card device models? How do the command lines differ
> if you use this option?
With videoram=8, and 'xm create', you get what you expect:
6026 ? RLl 0:00 /usr/lib/xen/bin/qemu-dm -d 2 -domain-name
winxp -videoram 8 -k en-us -vnc 0.0.0.0:3 -monitor vc -vcpus 2 -vcpu_avail 0x3
-boot cda -soundhw es1370 -localtime -serial pty -acpi -usbdevice tablet -net
nic,vlan=1,macaddr=00:16:3e:23:1d:36,model=rtl8139 -net
tap,vlan=1,ifname=tap2.0,bridge=xenbr0 -M xenfv
Thanx for the thorough review.
^ permalink raw reply
* Re: [PATCH] ramoops appears geared to not support ARM
From: Bryan Freed @ 2011-10-31 23:03 UTC (permalink / raw)
To: Marco Stornelli; +Cc: linux-kernel, akpm, msb, seiji.aguchi
In-Reply-To: <4EAE630A.6040309@gmail.com>
On Mon, Oct 31, 2011 at 1:57 AM, Marco Stornelli
<marco.stornelli@gmail.com> wrote:
> Il 31/10/2011 07:03, Bryan Freed ha scritto:
>>
>> On Sun, Oct 30, 2011 at 4:33 AM, Marco Stornelli
>> <marco.stornelli@gmail.com> wrote:
>>>
>>> Il 30/10/2011 03:07, Bryan Freed ha scritto:
>>>>
>>>> Right, and that is what I do to get ARM working. The reserve() function
>>>> calls memblock_reserve() to reserve the memory for RAMOOPS. Keeping it
>>>> part of main memory (by not using memblock_remove()) gets the memory
>>>> properly mapped.
>>>>
>>>
>>> According to Russell, it needs to use memblock_remove to exclude that
>>> piece of memory.
>>>
>>>> The problem I think we need to resolve is that this makes the ramoops
>>>> driver messy.
>>>
>>> I agree. Indeed I think we don't need to do anything in the driver. The
>>> problem is only how to exclude a piece of memory from kernel main memory
>>> view. For x86 it's trivial, for ARM it doesn't, but it's still possible.
>>>
>>> Marco
>>
>> I will give that (using mem_remove()) a shot tomorrow.
>> My recollection on using it in last week's investigation showed the
>> ramoops driver ioremap() giving a mapping that did not correspond with
>> what the /dev/mem expected to see. I vaguely recall /dev/mem was
>> effectively calling __va(0x02000000) which added a base address of
>> 0xc0000000 giving 0xc2000000 as the resulting virtual address. The
>> ramoops ioremap(), however, gave some arbitrary virtual address for
>> this memory.
>> The result was that using /dev/mem to read 0x02000000 caused a panic.
>
> I don't understand this point. We have different virtual addresses and then?
Yes, we get different virtual addresses.
The /dev/mem xlate_dev_mem_ptr() is defined (for ARM) as __va(), so it
gives 0xc2000000.
The ramoops ioremap() gives 0xef90000 because
__arm_ioremap_pfn_caller() makes a fresh get_vm_area_caller() call.
On x86, the /dev/mem xlate_dev_mem_ptr() gives an ioremap_cache()
address rather than a __va() address because it (properly?) detects
the memory is not RAM (because it was reserved by BIOS, so it was not
configured with system memory).
> The linear transformation with a fixed offset is the normal way for the
> kernel to have a virtual address from a physical one when you are using a
> memory address directly mapped. The virtual address returned by ioremap it
> can be an address not directly mapped, I mean it isn't a simple linear
> transformation of the physical address used in input.
Right, that is what I see on the ARM side as well.
__arm_ioremap_pfn_caller() gets a virtual address with
get_vm_area_caller().
> It isn't normal to have a kernel panic, even if there is something wrong,
> you should receive EINVAL or something similar.
Yeah, /dev/mem will give an EFAULT on ARM if (addr + count >
__pa(high_memory)). But we are not beyond the end of our physical
memory. We are somewhere in the middle. So read_mem() gets the
virtual address with xlate_dev_mem_ptr() which on ARM is just __va().
If this memory is memblock_removed, then that virtual address is not mapped.
Now that I look closer, we use copy_to_user(). So we should be
catching this fault.
I will take a closer look at this.
Either way, /dev/mem will not give us proper access to the ARM ramoops buffer.
>
>>
>> Another problem was that removing just 512KiB of memory for ramoops
>> screwed up the system memory initialization. It appeared to me that
>> the ARM memory code expected sections to be 1MiB aligned. I could
>> memblock_reserve anything, but I could only memblock_remove on a 1MiB
>> boundary.
>>
>
> It's an arch problem not related to the driver.
Yes, that is an arch problem. But it is another reason to move away
from memblock_remove() and toward memblock_reserve().
>> And I cannot shake the feeling that we have a fairly simple disconnect
>> here. Ramoops expects to use _device_ memory because it uses
>> ioremap(). But the buffer itself is accessed through /dev/mem which
>> (as we use it with no mmap() calls) expects to give access to _system_
>
> no mmap calls?! I don't understand how you are using /dev/mem.
open(), lseek(), read(). No mmap is required for RAM, right?
dd if=/dev/mem bs=1 count=1000 skip=32M
My point above about the disconnect between system memory and device
memory would be resolved if ramoops provided its own access to the
buffer. What do you think of that idea?
bryan.
> Marco
>
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Linus Torvalds @ 2011-10-31 23:03 UTC (permalink / raw)
To: H. Peter Anvin
Cc: Junio C Hamano, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <4EAF2724.8040001@zytor.com>
On Mon, Oct 31, 2011 at 3:54 PM, H. Peter Anvin <hpa@zytor.com> wrote:
> On 10/31/2011 03:52 PM, Linus Torvalds wrote:
>>
>> Save it in the commit we generate. BAM! Useful, readable, permanent,
>> and independently verifiable.
>>
>
> Note: this means creating a commit even for a fast-forward merge. Not
> that there is any technical problem with that, of course.
Well, only for the signed case, but yes. And for that case it's likely
a good thing.
In fact, even without signing, some projects always use --no-ff,
because they want the merge messages with the nice summary in them.
I've played around with it too, but haven't generally found it to be
worth it, and tend to think that it aggrandizes the merger too much.
It generates nice merge summaries, and it can look nice, but if the
*only* upside is the merge summary I think it's borderline worth it.
But with a signature, it would suddenly actually contain real
information, and I think that changes the equation.
Linus
^ permalink raw reply
* [U-Boot] [PATCH 4/4] PXA: Adapt Voipac PXA270 to OneNAND SPL
From: Scott Wood @ 2011-10-31 23:03 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1320067393-18822-5-git-send-email-marek.vasut@gmail.com>
On 10/31/2011 08:23 AM, Marek Vasut wrote:
> Signed-off-by: Marek Vasut <marek.vasut@gmail.com>
> Cc: Albert ARIBAUD <albert.u.boot@aribaud.net>
> ---
> board/vpac270/Makefile | 6 ++
> board/vpac270/onenand.c | 136 +++++++++++++++++++++++++++++++++++++++++++++
> board/vpac270/vpac270.c | 2 +
> include/configs/vpac270.h | 25 +++++++--
> 4 files changed, 164 insertions(+), 5 deletions(-)
> create mode 100644 board/vpac270/onenand.c
>
> diff --git a/board/vpac270/Makefile b/board/vpac270/Makefile
> index b5c60fd..f25822f 100644
> --- a/board/vpac270/Makefile
> +++ b/board/vpac270/Makefile
> @@ -23,7 +23,13 @@ include $(TOPDIR)/config.mk
>
> LIB = $(obj)lib$(BOARD).o
>
> +ifndef CONFIG_SPL_BUILD
> COBJS := vpac270.o
> +endif
> +
> +ifdef CONFIG_SPL_BUILD
> +COBJS := onenand.o
> +endif
else?
> SRCS := $(COBJS:.o=.c)
> OBJS := $(addprefix $(obj),$(COBJS))
> diff --git a/board/vpac270/onenand.c b/board/vpac270/onenand.c
> new file mode 100644
> index 0000000..50de2ab
> --- /dev/null
> +++ b/board/vpac270/onenand.c
> @@ -0,0 +1,136 @@
> +/*
> + * Voipac PXA270 OneNAND SPL
> + *
> + * Copyright (C) 2011 Marek Vasut <marek.vasut@gmail.com>
> + *
> + * See file CREDITS for list of people who contributed to this
> + * project.
> + *
> + * This program is free software; you can redistribute it and/or
> + * modify it under the terms of the GNU General Public License as
> + * published by the Free Software Foundation; either version 2 of
> + * the License, or (at your option) any later version.
> + *
> + * This program is distributed in the hope that it will be useful,
> + * but WITHOUT ANY WARRANTY; without even the implied warranty of
> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
> + * GNU General Public License for more details.
> + *
> + * You should have received a copy of the GNU General Public License
> + * along with this program; if not, write to the Free Software
> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston,
> + * MA 02111-1307 USA
> + */
> +
> +#include <common.h>
> +#include <config.h>
> +#include <asm/io.h>
> +#include <onenand_uboot.h>
> +
> +extern void pxa_dram_init(void);
> +
> +inline void spl_copy_self(void)
> +{
> + extern uint32_t _end;
> + struct spl_onenand_data data;
> + uint32_t page;
> + uint32_t total_bytes = (uint32_t)&_end - CONFIG_SPL_TEXT_BASE;
> + uint32_t total_pages;
> + uint8_t *addr = (uint8_t *)CONFIG_SPL_TEXT_BASE;
> + int ret;
> +
> + spl_onenand_get_geometry(&data);
> +
> + /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
> + total_pages = total_bytes >> 11;
> + if (data.pagesize == 4096)
> + total_pages >>= 1;
total_bytes / 2048 and total_pages / 2 are more readable and should
generate exactly the same code.
> + for (page = 0; page <= total_pages; page++) {
> + ret = spl_onenand_read_page(0, page, addr, data.pagesize);
> + if (ret)
> + total_pages++;
> + else
> + addr += data.pagesize;
> + }
> +}
You want to skip to the next block if spl_onenand_read_page() fails
(which can occur after you've already read some of the block).
How much of this is board-specific?
> +inline void spl_copy_uboot(void)
> +{
> + uint8_t *addr = (uint8_t *)CONFIG_SYS_TEXT_BASE;
> + struct spl_onenand_data data;
> + uint32_t total_pages;
> + uint32_t block;
> + uint32_t page, rpage;
> + int ret;
> +
> + spl_onenand_get_geometry(&data);
> +
> + /* The page can be either 2k or 4k, avoid using DIV_ROUND_UP. */
> + total_pages = CONFIG_SPL_ONENAND_LOAD_SIZE >> 11;
> + page = CONFIG_SPL_ONENAND_LOAD_ADDR >> 11;
> + if (data.pagesize == 4096) {
> + total_pages >>= 1;
> + page >>= 1;
> + }
> +
> + for (; page <= total_pages; page++) {
> + block = page >> 6;
> + rpage = page & 0xff;
> + ret = spl_onenand_read_page(block, rpage, addr, data.pagesize);
> + if (ret)
> + total_pages++;
> + else
> + addr += data.pagesize;
> + }
> +}
What is so different about this compared to spl_copy_self, that warrants
such duplication? Can't you just pass in offset, length, and
destination as parameters? Or just have the OneNAND SPL driver export
nand_spl_load_image(), as any other NAND SPL driver would?
> +inline void board_init_f(unsigned long unused)
> +{
> + uint32_t tmp;
> +
> + asm volatile("mov %0, pc" : "=r"(tmp));
> + tmp >>= 24;
> +
> + /* The code runs from OneNAND RAM, copy SPL to SRAM and execute it. */
> + if (tmp == 0) {
> + spl_copy_self();
> + asm volatile("mov pc, %0" : : "r"(CONFIG_SPL_TEXT_BASE));
> + }
Is it not possible to use a simple memcpy for spl_copy_self()? If the
CPU can run the code, you'd think it could read it.
> +inline void board_init_r(gd_t *id, ulong dest_addr)
> +{
> + for (;;)
> + ;
> +}
This doesn't seem like a useful board_init_r(). If you don't need it,
maybe make sure it's not called, and save yourself some bytes in the
SPL. Likewise for the other stub functions, where practical.
> +inline int printf(const char *fmt, ...)
> +{
> + return 0;
> +}
> +
> +inline void __coloured_LED_init(void) {}
> +inline void __red_LED_on(void) {}
> +void coloured_LED_init(void)
> + __attribute__((weak, alias("__coloured_LED_init")));
> +void red_LED_on(void)
> + __attribute__((weak, alias("__red_LED_on")));
> +void hang(void) __attribute__ ((noreturn));
> +void hang(void)
> +{
> + for (;;)
> + ;
> +}
> +
> +inline void icache_disable(void) {}
> +inline void dcache_disable(void) {}
Why are you specifying inline on just about everything, even functions
that are not used in this file?
Why are you not specifying static on things that are not needed outside
this file?
> diff --git a/board/vpac270/vpac270.c b/board/vpac270/vpac270.c
> index 43bbdff..f146009 100644
> --- a/board/vpac270/vpac270.c
> +++ b/board/vpac270/vpac270.c
> @@ -56,7 +56,9 @@ struct serial_device *default_serial_console(void)
> extern void pxa_dram_init(void);
> int dram_init(void)
> {
> +#ifndef CONFIG_ONENAND
> pxa_dram_init();
> +#endif
> gd->ram_size = PHYS_SDRAM_1_SIZE;
> return 0;
> }
Should this really be about whether OneNAND support is present, or
should it be based on whether you're using the OneNAND SPL?
-Scott
^ permalink raw reply
* Re: [PATCH 09/11] iptables: upgrade to version 1.4.12.1
From: Richard Purdie @ 2011-10-31 22:57 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <83141bc3f748c34d7f19a03c0517d804fadc6024.1319772853.git.dongxiao.xu@intel.com>
On Fri, 2011-10-28 at 11:35 +0800, Dongxiao Xu wrote:
> Remove the do_configure_prepend() since some m4 files are needed when
> doing configuration.
I think we're going to have to specifically delete the libtool m4 files
here. I know we've had problems with them being present in the past.
Also, there is no mention of the licence change here in the commit
message?
Cheers,
Richard
> Define correct FILE for iptables and iptables-dbg packages.
>
> Signed-off-by: Dongxiao Xu <dongxiao.xu@intel.com>
> ---
> .../{iptables_1.4.9.bb => iptables_1.4.12.1.bb} | 16 ++++++----------
> 1 files changed, 6 insertions(+), 10 deletions(-)
> rename meta/recipes-extended/iptables/{iptables_1.4.9.bb => iptables_1.4.12.1.bb} (69%)
>
> diff --git a/meta/recipes-extended/iptables/iptables_1.4.9.bb b/meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> similarity index 69%
> rename from meta/recipes-extended/iptables/iptables_1.4.9.bb
> rename to meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> index 7c9fbea..59a1bcb 100644
> --- a/meta/recipes-extended/iptables/iptables_1.4.9.bb
> +++ b/meta/recipes-extended/iptables/iptables_1.4.12.1.bb
> @@ -4,8 +4,8 @@ filtering code in Linux."
> HOMEPAGE = "http://www.netfilter.org/"
> BUGTRACKER = "http://bugzilla.netfilter.org/"
> LICENSE = "GPLv2+"
> -LIC_FILES_CHKSUM = "file://COPYING;md5=8ca43cbc842c2336e835926c2166c28b \
> - file://iptables.c;firstline=13;endline=25;md5=f1028f2401da1c120df27594b2be50ef"
> +LIC_FILES_CHKSUM = "file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263\
> + file://iptables/iptables.c;firstline=13;endline=25;md5=f1028f2401da1c120df27594b2be50ef"
>
> PR = "r0"
>
> @@ -18,19 +18,15 @@ RRECOMMENDS_${PN} = "kernel-module-x-tables \
> kernel-module-nf-conntrack-ipv4 \
> kernel-module-nf-nat \
> kernel-module-ipt-masquerade"
> -FILES_${PN}-dbg =+ "${libexecdir}/xtables/.debug"
> +FILES_${PN} =+ "${libdir}/xtables/"
> +FILES_${PN}-dbg =+ "${libdir}/xtables/.debug"
>
> SRC_URI = "http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.bz2"
>
> -SRC_URI[md5sum] = "db1312f7ce5a4c11dc981a2ac76b26e8"
> -SRC_URI[sha256sum] = "1ac719d6265cf64220c80c0974ed9d35febdac2986bb96eeaa9c8c7959a1d306"
> +SRC_URI[md5sum] = "b08a1195ec2c1ebeaf072db3c55fdf43"
> +SRC_URI[sha256sum] = "77e6581f21f15946a814fa311236e5f3f7c6593180f9d695cea06aa95e464aba"
>
> inherit autotools
>
> EXTRA_OECONF = "--with-kernel=${STAGING_INCDIR} \
> ${@base_contains('DISTRO_FEATURES', 'ipv6', '', '--disable-ipv6', d)}"
> -
> -do_configure_prepend() {
> - # they are all libtool m4 files
> - rm -rf ${S}/m4
> -}
^ permalink raw reply
* [Qemu-devel] [PATCH] MAINTAINERS: Add PReP maintainer
From: Andreas Färber @ 2011-10-31 23:03 UTC (permalink / raw)
To: qemu-devel; +Cc: Andreas Färber, Hervé Poussineau, Alexander Graf
Officially take on maintainership for PReP and upgrade to Odd Fixes.
Signed-off-by: Andreas Färber <andreas.faerber@web.de>
Cc: Alexander Graf <agraf@suse.de>
Cc: Hervé Poussineau <hpoussin@reactos.org>
---
MAINTAINERS | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index 4535eeb..bccdd4f 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -303,9 +303,9 @@ M: Alexander Graf <agraf@suse.de>
S: Maintained
F: hw/ppc_oldworld.c
-Prep
-M: qemu-devel@nongnu.org
-S: Orphan
+PReP
+M: Andreas Färber <andreas.faerber@web.de>
+S: Odd Fixes
F: hw/ppc_prep.c
SH4 Machines
--
1.7.7
^ permalink raw reply related
* Sony DualShock3 - Detected but no events
From: Alon Bar-Lev @ 2011-10-31 23:04 UTC (permalink / raw)
To: linux-input
Hello,
I feel uncomfortable, as people reports that it does work...
Bluetooth pairing is not working and almost no documentation of
bluez-4 success....
So I thought starting in USB will be easier....
I am using linux-3.1.0
When doing cat /dev/input/js0 or cat /dev/input/event15 or usbhid-dump
I get no activity.
Can anyone please help? or acknowledge that it actually work?
Can I provide more information?
Thanks,
Alon.
lsusb
---
Bus 006 Device 002: ID 054c:0268 Sony Corp. Batoh Device / PlayStation
3 Controller
---
When plugged, I get:
---
usb 6-1: new full speed USB device number 2 using uhci_hcd
sony 0003:054C:0268.000A: Fixing up Sony Sixaxis report descriptor
input: Gasia Co.,Ltd PS(R) Gamepad as
/devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/input/input23
sony 0003:054C:0268.000A: input: USB HID v1.11 Joystick [Gasia Co.,Ltd
PS(R) Gamepad] on usb-0000:00:1d.0-1/input0
---
/proc/bus/input/devices
---
I: Bus=0003 Vendor=054c Product=0268 Version=0111
N: Name="Gasia Co.,Ltd PS(R) Gamepad"
P: Phys=usb-0000:00:1d.0-1/input0
S: Sysfs=/devices/pci0000:00/0000:00:1d.0/usb6/6-1/6-1:1.0/input/input23
U: Uniq=
H: Handlers=event15 js0
B: PROP=0
B: EV=1b
B: KEY=70000 0 0 0 0 0 0 ffff00000000 0 0 0 0
B: ABS=7fffff0000000027
B: MSC=10
---
# usbhid-dump -f --entity="both" 6 2
---
000:DESCRIPTOR 1320102071.430309
05 01 09 04 A1 01 A1 02 85 01 75 08 95 01 15 00
26 FF 00 81 03 75 01 95 13 15 00 25 01 35 00 45
01 05 09 19 01 29 13 81 02 75 01 95 0D 06 00 FF
81 03 15 00 26 FF 00 05 01 09 01 A1 00 75 08 95
04 35 00 46 FF 00 09 30 09 31 09 32 09 35 81 02
C0 05 01 75 08 95 27 09 01 81 02 75 08 95 30 09
01 91 02 75 08 95 30 09 01 B1 02 C0 A1 02 85 02
75 08 95 30 09 01 B1 02 C0 A1 02 85 EE 75 08 95
30 09 01 B1 02 C0 A1 02 85 EF 75 08 95 30 09 01
B1 02 C0 C0
---
^ permalink raw reply
* Re: [git patches] libata updates, GPG signed (but see admin notes)
From: Junio C Hamano @ 2011-10-31 23:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: H. Peter Anvin, git, James Bottomley, Jeff Garzik, Andrew Morton,
linux-ide, LKML
In-Reply-To: <7vvcr4ojvp.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
> ...
> As I already said, I do not think notes is a good match as a tool to do
> this.
>
>> matters is that "git push" and "git pull" would JustWork(tm), and
>> check the signature if one exists, without having to cut-and-paste
>> data that simply shouldn't be visible to the user.
>>
>> I abhor the interface Ingo suggested, for example....
>
> Some cut-and-paste (or piping the e-mail to a command) would be necessary
> evil, though, as you would have GPG keys from more than one trusted person
> in your keyring, and when you are responding to a pull-request from person
> A, finding a valid commit signed by person B should not be a success, but
> at least should raise a warning.
So here is a quick hack that does not involve cut-and-paste (it depends on
the signed-commit topic in 'next').
$ git pull --require-signature
would trigger signature verification and stops you after fetching but
before merging.
git-pull.sh | 25 ++++++++++++++++++++++++-
1 files changed, 24 insertions(+), 1 deletions(-)
diff --git a/git-pull.sh b/git-pull.sh
index 9868a0b..f3b4c93 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -39,7 +39,7 @@ test -z "$(git ls-files -u)" || die_conflict
test -f "$GIT_DIR/MERGE_HEAD" && die_merge
strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
-log_arg= verbosity= progress= recurse_submodules=
+log_arg= verbosity= progress= recurse_submodules= must_be_signed=
merge_args=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short="${curr_branch#refs/heads/}"
@@ -60,6 +60,8 @@ do
diffstat=--no-stat ;;
--stat|--summary)
diffstat=--stat ;;
+ --require-signature)
+ must_be_signed=yes ;;
--log|--no-log)
log_arg=$1 ;;
--no-c|--no-co|--no-com|--no-comm|--no-commi|--no-commit)
@@ -208,6 +210,27 @@ orig_head=$(git rev-parse -q --verify HEAD)
git fetch $verbosity $progress $dry_run $recurse_submodules --update-head-ok "$@" || exit 1
test -z "$dry_run" || exit 0
+if test -n "$must_be_signed"
+then
+ signature=$(git show -s --format='%G?' FETCH_HEAD)
+ case "$signature" in
+ G)
+ case "$verbosity" in
+ *' '-v*)
+ git show -s --show-signature FETCH_HEAD ;;
+ esac
+ ;;
+ B)
+ echo >&2 "Bad signature on the tip commit"
+ exit 1
+ ;;
+ *)
+ echo >&2 "Tip commit must be signed"
+ exit 1
+ ;;
+ fi
+fi
+
curr_head=$(git rev-parse -q --verify HEAD)
if test -n "$orig_head" && test "$curr_head" != "$orig_head"
then
^ permalink raw reply related
* Re: [GIT] pull request for x86 platform drivers tree
From: Linus Torvalds @ 2011-10-31 23:09 UTC (permalink / raw)
To: Matthew Garrett; +Cc: platform-driver-x86
In-Reply-To: <20111031225748.GA13356@srcf.ucam.org>
On Mon, Oct 31, 2011 at 3:57 PM, Matthew Garrett
<mjg59@cavan.codon.org.uk> wrote:
>
> Is this any help?
Ok, mutt seems to like that key, and it's signed by at least Jesse
Barnes who is in my keyring, so.. Yes.
Linus
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Jan Kara @ 2011-10-31 23:10 UTC (permalink / raw)
To: Andy Lutomirski
Cc: Jan Kara, Andreas Dilger, linux-kernel@vger.kernel.org,
linux-mm@kvack.org, linux-ext4@vger.kernel.org
In-Reply-To: <CALCETrWoZeFpznU5Nv=+PvL9QRkTnS4atiGXx0jqZP_E3TJPqw@mail.gmail.com>
On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
> >> - Why are we calling file_update_time at all? Presumably we also
> >> update the time when the page is written back (if not, that sounds
> >> like a bug, since the contents may be changed after something saw the
> >> mtime update), and, if so, why bother updating it on the first write?
> >> Anything that relies on this behavior is, I think, unreliable, because
> >> the page could be made writable arbitrarily early by another program
> >> that changes nothing.
> > We don't update timestamp when the page is written back. I believe this
> > is mostly because we don't know whether the data has been changed by a
> > write syscall, which already updated the timestamp, or by mmap. That is
> > also the reason why we update the timestamp at page fault time.
> >
> > The reason why file_update_time() blocks for you is probably that it
> > needs to get access to buffer where inode is stored on disk and because a
> > transaction including this buffer is committing at the moment, your thread
> > has to wait until the transaction commit finishes. This is mostly a problem
> > specific to how ext4 works so e.g. xfs shouldn't have it.
> >
> > Generally I believe the attempts to achieve any RT-like latencies when
> > writing to a filesystem are rather hopeless. How much hopeless depends on
> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
> > can imagine some tweaks could reduce your latencies to an acceptable level
> > but once the disk gets loaded you'll be screwed). So I'd suggest that
> > having RT thread just store log in memory (or write to a pipe) and have
> > another non-RT thread write the data to disk would be a much more robust
> > design.
>
> Windows seems to do pretty well at this, and I think it should be fixable on
> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
> page_mkclean_one. The fallout from that might be unpleasant, though, but
> it would probably speed up a number of workloads.
Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
unlikely to go away in a forseeable future. The reason is that we need to
reliably account the number of dirty pages so that we can throttle
processes that dirty too much of memory and also protect agaist system
going into out-of-memory problems when too many pages would be dirty (and
thus hard to reclaim). Thus we create clean pages as write-protected, when
they are first written to, we account them as dirtied and unprotect them.
When pages are cleaned by writeback, we decrement number of dirty pages
accordingly and write-protect them again.
> Adding a whole separate process just to copy data from memory to disk sounds
> a bit like a hack -- that's what mmap + mlock would do if it worked better.
Well, always only guarantees you cannot hit major fault when accessing
the page. And we keep that promise - we only hit a minor fault. But I agree
that for your usecase this is impractical.
I can see as theoretically feasible for writeback to skip mlocked pages
which would help your case. But practically, I do not see how to implement
that efficiently (just skipping a dirty page when we find it's mlocked
seems like a way to waste CPU needlessly).
> Incidentally, pipes are no good. I haven't root-caused it yet, but both
> reading to and writing from pipes, even if O_NONBLOCK, can block. I
> haven't root-caused it yet.
Interesting. I imagine they could block on memory allocation but I guess
you don't put that much pressure on your system. So it might be interesting
to know where else they block...
Honza
--
Jan Kara <jack@suse.cz>
SUSE Labs, CR
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Multiple instances of same characteristics (was: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications)
From: Claudio Takahasi @ 2011-10-31 23:11 UTC (permalink / raw)
To: Tsai, Mike; +Cc: linux-bluetooth
Hi Mike,
> [MT]How can this handle the multiple instances of same characteristics within a single service? The characteristic UUID will not be unique in that case. Also, how is the profile specific characteristic descriptor handled?
>
> Cheers,
>
> Mike
I am moving your question to another thread. The original thread is
almost impossible to follow.
Do you mean support for client characteristic configuration and other
characteristics per device?
In the Generic Attribute API(client), the represented characteristics
are always per device. The abstraction for per device characteristic
value needs to implemented in the server.
The current attribute server supports CCC only, before implementing
per device characteristics we need to cleanup the code.
BR,
Claudio.
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 0/6] DAT: Distributed ARP Table
From: Simon Wunderlich @ 2011-10-31 23:11 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <4EAEEE96.9040808@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 407 bytes --]
Hey,
seems the Wiki was edited just recently, have a look here:
http://www.open-mesh.org/wiki/batman-adv/GSOC2011_DAT
Cheers,
Simon
On Mon, Oct 31, 2011 at 11:53:10AM -0700, Gus Wirth wrote:
>
> The link to the Wiki page doesn't work.
>
> The actual link:
>
> http://www.open-mesh.org/wiki/batman-adv/DistributedArpTable
>
> Except there is no information there :(
>
> Gus
>
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* git-p4: problem with commit 97a21ca50ef8
From: Michael Wookey @ 2011-10-31 23:11 UTC (permalink / raw)
To: Git Mailing List, Pete Wyckoff, Luke Diamand
[ please CC me as I am not subscribed to the list ]
Hi,
Commit 97a21ca50ef893a171a50c863fe21a924935fd2a "git-p4: stop ignoring
apple filetype" isn't correct. Without knowing too much about how
git-p4 works, it appears that the "apple" filetype includes the
resource fork, and the "p4 print" that is used to obtain the content
from the perforce server doesn't take this into account, or maybe some
post processing of the file needs to be done to include the data, but
not the resource fork, before inclusion into the git repo.
With the above commit, a binary blob that literally contains the
resource fork and data is included within the git repo. Of course,
without the above commit, the intended file was never included in the
git repo at all. Perhaps the resource fork issue was a known problem
by the original git-p4 author.
A sample file that that demonstrates what the above commit produces is
here (use curl/wget):
http://dl.dropbox.com/u/1006983/sample_image_fail.png
This is literally a binary blob with about 110 KiB of resource fork
plus the PNG data. The same image, minus about 110 KiB of resource
fork is here:
http://dl.dropbox.com/u/1006983/sample_image_correct.png
I'm happy to test patches as we have a perforce repository with files
of the "apple" filetype.
Thanks
^ permalink raw reply
* How to test multiusermount?
From: Stef Bon @ 2011-10-31 23:12 UTC (permalink / raw)
To: linux-cifs
Hi,
I would like to test the multiusermounts?
I know to set:
echo 1 > /proc/fs/cifs/MultiuserMount
and add an option to the mount command, but I can remember/read somewhere
that one have to add some mapping somehwere:
local user : remote user
...
Is this correct?
Stef Bon
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] MAINTAINERS: Add PReP maintainer
From: Alexander Graf @ 2011-10-31 23:12 UTC (permalink / raw)
To: Andreas Färber; +Cc: Hervé Poussineau, qemu-devel@nongnu.org
In-Reply-To: <1320102187-18955-1-git-send-email-andreas.faerber@web.de>
On 31.10.2011, at 16:03, Andreas Färber <andreas.faerber@web.de> wrote:
> Officially take on maintainership for PReP and upgrade to Odd Fixes.
>
> Signed-off-by: Andreas Färber <andreas.faerber@web.de>
> Cc: Alexander Graf <agraf@suse.de>
> Cc: Hervé Poussineau <hpoussin@reactos.org>
Acked-by: Alexander Graf <agraf@suse.de>
Anthony, could you please take this in directly?
Alex
> ---
> MAINTAINERS | 6 +++---
> 1 files changed, 3 insertions(+), 3 deletions(-)
>
> diff --git a/MAINTAINERS b/MAINTAINERS
> index 4535eeb..bccdd4f 100644
> --- a/MAINTAINERS
> +++ b/MAINTAINERS
> @@ -303,9 +303,9 @@ M: Alexander Graf <agraf@suse.de>
> S: Maintained
> F: hw/ppc_oldworld.c
>
> -Prep
> -M: qemu-devel@nongnu.org
> -S: Orphan
> +PReP
> +M: Andreas Färber <andreas.faerber@web.de>
> +S: Odd Fixes
> F: hw/ppc_prep.c
>
> SH4 Machines
> --
> 1.7.7
>
^ permalink raw reply
* Re: [PATCH -v2 00/16] PCI: Re-factor PCI's 'latency timer' setup
From: Myron Stowe @ 2011-10-31 23:14 UTC (permalink / raw)
To: Mike Frysinger
Cc: Myron Stowe, jbarnes, linux-pci, linux, dhowells, ysato,
tony.luck, fenghua.yu, monstr, ralf, benh, paulus, lethal, davem,
cmetcalf, gxt, tglx, mingo, chris, linux-kernel
In-Reply-To: <CAJaTeTq6p_ToKuB3+3XBQV2xgfNtPxKE-E7KkYhuHD-JFABmtA@mail.gmail.com>
On Fri, Oct 28, 2011 at 6:46 PM, Mike Frysinger <vapier@gentoo.org> wrote:
> On Fri, Oct 28, 2011 at 23:47, Myron Stowe wrote:
>> - * blackfin and h8300 architectures do not seem to support PCI (no
>> root bus scanning etc. exists within them) but they do have PCI header
>> files.
>
> correct, all Blackfin parts in current mainline lack any sort of PCI
> support. the header existence (iirc) is two fold:
> - a lot of drivers like to use the pci/dma interface to manage memory
> instead of a pure dma interface
> - BF535 has pci support, but we don't support that, and have largely
> dropped anything related to it
>
> so if this compile passes for Blackfin, it should be fine. however,
> i'm lazy, so i don't suppose you've got a branch somewhere for me to
> pull to quickly compile test ?
I created a 'pci-latency-v2' branch at git://github.com/myron-stowe/linux.git
that maintainers of the various architectures can use to pull from for a compile
test of this patch series.
Myron
> if not, simply putting it into a
> branch that gets into linux-next should be sufficient as i think
> Stephen had Blackfin coverage in there ...
> -mike
> --
> To unsubscribe from this list: send the line "unsubscribe linux-pci" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Andy Lutomirski @ 2011-10-31 23:14 UTC (permalink / raw)
To: Jan Kara
Cc: Andreas Dilger, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-ext4@vger.kernel.org
In-Reply-To: <20111031231031.GD10107@quack.suse.cz>
On Mon, Oct 31, 2011 at 4:10 PM, Jan Kara <jack@suse.cz> wrote:
> On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
>> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
>> >> - Why are we calling file_update_time at all? Presumably we also
>> >> update the time when the page is written back (if not, that sounds
>> >> like a bug, since the contents may be changed after something saw the
>> >> mtime update), and, if so, why bother updating it on the first write?
>> >> Anything that relies on this behavior is, I think, unreliable, because
>> >> the page could be made writable arbitrarily early by another program
>> >> that changes nothing.
>> > We don't update timestamp when the page is written back. I believe this
>> > is mostly because we don't know whether the data has been changed by a
>> > write syscall, which already updated the timestamp, or by mmap. That is
>> > also the reason why we update the timestamp at page fault time.
>> >
>> > The reason why file_update_time() blocks for you is probably that it
>> > needs to get access to buffer where inode is stored on disk and because a
>> > transaction including this buffer is committing at the moment, your thread
>> > has to wait until the transaction commit finishes. This is mostly a problem
>> > specific to how ext4 works so e.g. xfs shouldn't have it.
>> >
>> > Generally I believe the attempts to achieve any RT-like latencies when
>> > writing to a filesystem are rather hopeless. How much hopeless depends on
>> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
>> > can imagine some tweaks could reduce your latencies to an acceptable level
>> > but once the disk gets loaded you'll be screwed). So I'd suggest that
>> > having RT thread just store log in memory (or write to a pipe) and have
>> > another non-RT thread write the data to disk would be a much more robust
>> > design.
>>
>> Windows seems to do pretty well at this, and I think it should be fixable on
>> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
>> page_mkclean_one. The fallout from that might be unpleasant, though, but
>> it would probably speed up a number of workloads.
> Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
> unlikely to go away in a forseeable future. The reason is that we need to
> reliably account the number of dirty pages so that we can throttle
> processes that dirty too much of memory and also protect agaist system
> going into out-of-memory problems when too many pages would be dirty (and
> thus hard to reclaim). Thus we create clean pages as write-protected, when
> they are first written to, we account them as dirtied and unprotect them.
> When pages are cleaned by writeback, we decrement number of dirty pages
> accordingly and write-protect them again.
What about skipping pte_wrprotect for mlocked pages and continuing to
account them dirty even if they're actually clean? This should be a
straightforward patch except for the effect on stable pages for
writeback. (It would also have unfortunate side effects on
ctime/mtime without my other patch to rearrange that code.)
>
>> Adding a whole separate process just to copy data from memory to disk sounds
>> a bit like a hack -- that's what mmap + mlock would do if it worked better.
> Well, always only guarantees you cannot hit major fault when accessing
> the page. And we keep that promise - we only hit a minor fault. But I agree
> that for your usecase this is impractical.
Not really true. We never fault in the page, but make_write can wait
for I/O (for hundreds of ms) which is just as bad.
>
> I can see as theoretically feasible for writeback to skip mlocked pages
> which would help your case. But practically, I do not see how to implement
> that efficiently (just skipping a dirty page when we find it's mlocked
> seems like a way to waste CPU needlessly).
>
>> Incidentally, pipes are no good. I haven't root-caused it yet, but both
>> reading to and writing from pipes, even if O_NONBLOCK, can block. I
>> haven't root-caused it yet.
> Interesting. I imagine they could block on memory allocation but I guess
> you don't put that much pressure on your system. So it might be interesting
> to know where else they block...
I'll figure it out in a couple of days, I imagine.
--Andy
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: git rev-parse --since=1970-01-01 does not work reliably
From: Nguyen Thai Ngoc Duy @ 2011-10-31 23:13 UTC (permalink / raw)
To: Dmitry V. Levin; +Cc: git
In-Reply-To: <20111031161708.GA29924@altlinux.org>
On Mon, Oct 31, 2011 at 08:17:09PM +0400, Dmitry V. Levin wrote:
> Hi,
>
> git rev-parse --since=1970-01-01 (and other git commands that take
> date string arguments like --since) may fail when --since=1970-01-01 is
> given. Whether it fails or not depends on current time and timezone data.
> For example, "TZ=Europe/Paris git rev-parse --since=1970-01-01" fails two
> hours a day (between 00:00 and 02:00 CET), and those who use more eastern
> timezones are even less lucky. In artificial timezones like UTC-24 it
> always fails:
>
> $ TZ=UTC-24 git rev-parse --since=1970-01-01
> --max-age=18446744073709523490
Out of curiosity, why do you need to work with a time so close to that
date?
> The problem is that several internal git functions implicitly convert
> time_t to unsigned long, so when time_t gets negative, all date string
> processing breaks.
I don't think it's worth supporting negative time_t, but we should at
least avoid misconversion.
-- 8< --
Subject: [PATCH] Do not accept negative time_t
We use unsigned long internally to present time, negative value just
breaks thing.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
date.c | 8 +++++++-
1 files changed, 7 insertions(+), 1 deletions(-)
diff --git a/date.c b/date.c
index 353e0a5..9cbd521 100644
--- a/date.c
+++ b/date.c
@@ -653,8 +653,12 @@ int parse_date_basic(const char *date, unsigned long *timestamp, int *offset)
if (*timestamp == -1)
return -1;
- if (!tm_gmt)
+ if (!tm_gmt) {
+ if ((time_t)*timestamp < (time_t)*offset * 60)
+ die("unsupported time before Epoch");
*timestamp -= *offset * 60;
+ }
+
return 0; /* success */
}
@@ -722,6 +726,8 @@ static unsigned long update_tm(struct tm *tm, struct tm *now, unsigned long sec)
n = mktime(tm) - sec;
localtime_r(&n, tm);
+ if (n < 0)
+ die("unsupported time before Epoch");
return n;
}
--
1.7.4.74.g639db
-- 8< --
^ permalink raw reply related
* Re: Latency writing to an mlocked ext4 mapping
From: Andy Lutomirski @ 2011-10-31 23:14 UTC (permalink / raw)
To: Jan Kara
Cc: Andreas Dilger, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-ext4@vger.kernel.org
In-Reply-To: <20111031231031.GD10107@quack.suse.cz>
On Mon, Oct 31, 2011 at 4:10 PM, Jan Kara <jack@suse.cz> wrote:
> On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
>> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
>> >> - Why are we calling file_update_time at all? Presumably we also
>> >> update the time when the page is written back (if not, that sounds
>> >> like a bug, since the contents may be changed after something saw the
>> >> mtime update), and, if so, why bother updating it on the first write?
>> >> Anything that relies on this behavior is, I think, unreliable, because
>> >> the page could be made writable arbitrarily early by another program
>> >> that changes nothing.
>> > We don't update timestamp when the page is written back. I believe this
>> > is mostly because we don't know whether the data has been changed by a
>> > write syscall, which already updated the timestamp, or by mmap. That is
>> > also the reason why we update the timestamp at page fault time.
>> >
>> > The reason why file_update_time() blocks for you is probably that it
>> > needs to get access to buffer where inode is stored on disk and because a
>> > transaction including this buffer is committing at the moment, your thread
>> > has to wait until the transaction commit finishes. This is mostly a problem
>> > specific to how ext4 works so e.g. xfs shouldn't have it.
>> >
>> > Generally I believe the attempts to achieve any RT-like latencies when
>> > writing to a filesystem are rather hopeless. How much hopeless depends on
>> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
>> > can imagine some tweaks could reduce your latencies to an acceptable level
>> > but once the disk gets loaded you'll be screwed). So I'd suggest that
>> > having RT thread just store log in memory (or write to a pipe) and have
>> > another non-RT thread write the data to disk would be a much more robust
>> > design.
>>
>> Windows seems to do pretty well at this, and I think it should be fixable on
>> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
>> page_mkclean_one. The fallout from that might be unpleasant, though, but
>> it would probably speed up a number of workloads.
> Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
> unlikely to go away in a forseeable future. The reason is that we need to
> reliably account the number of dirty pages so that we can throttle
> processes that dirty too much of memory and also protect agaist system
> going into out-of-memory problems when too many pages would be dirty (and
> thus hard to reclaim). Thus we create clean pages as write-protected, when
> they are first written to, we account them as dirtied and unprotect them.
> When pages are cleaned by writeback, we decrement number of dirty pages
> accordingly and write-protect them again.
What about skipping pte_wrprotect for mlocked pages and continuing to
account them dirty even if they're actually clean? This should be a
straightforward patch except for the effect on stable pages for
writeback. (It would also have unfortunate side effects on
ctime/mtime without my other patch to rearrange that code.)
>
>> Adding a whole separate process just to copy data from memory to disk sounds
>> a bit like a hack -- that's what mmap + mlock would do if it worked better.
> Well, always only guarantees you cannot hit major fault when accessing
> the page. And we keep that promise - we only hit a minor fault. But I agree
> that for your usecase this is impractical.
Not really true. We never fault in the page, but make_write can wait
for I/O (for hundreds of ms) which is just as bad.
>
> I can see as theoretically feasible for writeback to skip mlocked pages
> which would help your case. But practically, I do not see how to implement
> that efficiently (just skipping a dirty page when we find it's mlocked
> seems like a way to waste CPU needlessly).
>
>> Incidentally, pipes are no good. I haven't root-caused it yet, but both
>> reading to and writing from pipes, even if O_NONBLOCK, can block. I
>> haven't root-caused it yet.
> Interesting. I imagine they could block on memory allocation but I guess
> you don't put that much pressure on your system. So it might be interesting
> to know where else they block...
I'll figure it out in a couple of days, I imagine.
--Andy
^ permalink raw reply
* Re: Latency writing to an mlocked ext4 mapping
From: Andy Lutomirski @ 2011-10-31 23:14 UTC (permalink / raw)
To: Jan Kara
Cc: Andreas Dilger, linux-kernel@vger.kernel.org, linux-mm@kvack.org,
linux-ext4@vger.kernel.org
In-Reply-To: <20111031231031.GD10107@quack.suse.cz>
On Mon, Oct 31, 2011 at 4:10 PM, Jan Kara <jack@suse.cz> wrote:
> On Fri 28-10-11 16:37:03, Andy Lutomirski wrote:
>> On Tue, Oct 25, 2011 at 5:26 AM, Jan Kara <jack@suse.cz> wrote:
>> >> - Why are we calling file_update_time at all? Presumably we also
>> >> update the time when the page is written back (if not, that sounds
>> >> like a bug, since the contents may be changed after something saw the
>> >> mtime update), and, if so, why bother updating it on the first write?
>> >> Anything that relies on this behavior is, I think, unreliable, because
>> >> the page could be made writable arbitrarily early by another program
>> >> that changes nothing.
>> > We don't update timestamp when the page is written back. I believe this
>> > is mostly because we don't know whether the data has been changed by a
>> > write syscall, which already updated the timestamp, or by mmap. That is
>> > also the reason why we update the timestamp at page fault time.
>> >
>> > The reason why file_update_time() blocks for you is probably that it
>> > needs to get access to buffer where inode is stored on disk and because a
>> > transaction including this buffer is committing at the moment, your thread
>> > has to wait until the transaction commit finishes. This is mostly a problem
>> > specific to how ext4 works so e.g. xfs shouldn't have it.
>> >
>> > Generally I believe the attempts to achieve any RT-like latencies when
>> > writing to a filesystem are rather hopeless. How much hopeless depends on
>> > the load of the filesystem (e.g., in your case of mostly idle filesystem I
>> > can imagine some tweaks could reduce your latencies to an acceptable level
>> > but once the disk gets loaded you'll be screwed). So I'd suggest that
>> > having RT thread just store log in memory (or write to a pipe) and have
>> > another non-RT thread write the data to disk would be a much more robust
>> > design.
>>
>> Windows seems to do pretty well at this, and I think it should be fixable on
>> Linux too. "All" that needs to be done is to remove the pte_wrprotect from
>> page_mkclean_one. The fallout from that might be unpleasant, though, but
>> it would probably speed up a number of workloads.
> Well, but Linux's mm pretty much depends the pte_wrprotect() so that's
> unlikely to go away in a forseeable future. The reason is that we need to
> reliably account the number of dirty pages so that we can throttle
> processes that dirty too much of memory and also protect agaist system
> going into out-of-memory problems when too many pages would be dirty (and
> thus hard to reclaim). Thus we create clean pages as write-protected, when
> they are first written to, we account them as dirtied and unprotect them.
> When pages are cleaned by writeback, we decrement number of dirty pages
> accordingly and write-protect them again.
What about skipping pte_wrprotect for mlocked pages and continuing to
account them dirty even if they're actually clean? This should be a
straightforward patch except for the effect on stable pages for
writeback. (It would also have unfortunate side effects on
ctime/mtime without my other patch to rearrange that code.)
>
>> Adding a whole separate process just to copy data from memory to disk sounds
>> a bit like a hack -- that's what mmap + mlock would do if it worked better.
> Well, always only guarantees you cannot hit major fault when accessing
> the page. And we keep that promise - we only hit a minor fault. But I agree
> that for your usecase this is impractical.
Not really true. We never fault in the page, but make_write can wait
for I/O (for hundreds of ms) which is just as bad.
>
> I can see as theoretically feasible for writeback to skip mlocked pages
> which would help your case. But practically, I do not see how to implement
> that efficiently (just skipping a dirty page when we find it's mlocked
> seems like a way to waste CPU needlessly).
>
>> Incidentally, pipes are no good. I haven't root-caused it yet, but both
>> reading to and writing from pipes, even if O_NONBLOCK, can block. I
>> haven't root-caused it yet.
> Interesting. I imagine they could block on memory allocation but I guess
> you don't put that much pressure on your system. So it might be interesting
> to know where else they block...
I'll figure it out in a couple of days, I imagine.
--Andy
--
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/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ permalink raw reply
* Re: How to test multiusermount?
From: Steve French @ 2011-10-31 23:14 UTC (permalink / raw)
To: Stef Bon; +Cc: linux-cifs
In-Reply-To: <CANXojcwxf0aD=_18_6D6=WkG86F9Qx4PTf7F=2husGbASac6hA-JsoAwUIsXosN+BqQ9rBEUg@public.gmane.org>
Jeff has a writeup that explains it more nicely but don't have the
link in front of me. Note that it works best with Kerberos (sec=krb5
or sec=krb5i)
On Mon, Oct 31, 2011 at 6:12 PM, Stef Bon <stefbon-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
> Hi,
>
> I would like to test the multiusermounts?
>
> I know to set:
>
> echo 1 > /proc/fs/cifs/MultiuserMount
>
> and add an option to the mount command, but I can remember/read somewhere
> that one have to add some mapping somehwere:
>
> local user : remote user
> ...
>
> Is this correct?
>
> Stef Bon
> --
> To unsubscribe from this list: send the line "unsubscribe linux-cifs" in
> the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Thanks,
Steve
^ permalink raw reply
* BUG: hid_add_device
From: Alon Bar-Lev @ 2011-10-31 23:15 UTC (permalink / raw)
To: linux-input
Hello,
While experimenting in bluetooth and DualShock3 controller and the
compat of bluez-4, I've found that only:
---
hidd --server --nocheck -n --nosdp
---
Reacts to the device, I don't know why the --nosdp has a difference,
but this is how far could go, in other cases, I get either:
---
Oct 31 23:39:11 localhost hidd[15164]: HID create error 4 (Interrupted
system call)
Oct 31 21:30:46 localhost hidd[26720]: HID create error 115 (Operation
now in progress)
---
However, while hidd tries to setup the device I get the fulling BUG:
(this I guess should not happen)
---
Oct 31 21:39:04 localhost hidd[8955]: Bluetooth HID daemon
Oct 31 21:39:17 localhost kernel: input: Bluetooth HID Boot Protocol
Device as /devices/pci0000:00/0000:00:1a.1/usb4/4-2/4-2:1.0/bluetooth/hci0/hci0:11/input15
Oct 31 21:39:17 localhost hidd[8955]: New HID device 00:26:5C:31:E2:79 ()
Oct 31 21:39:17 localhost kernel: BUG: unable to handle kernel paging
request at 0000000000001b00
Oct 31 21:39:17 localhost kernel: IP: [<ffffffffa03d7039>]
hid_add_device+0x9/0x200 [hid]
Oct 31 21:39:17 localhost kernel: PGD 0
Oct 31 21:39:17 localhost kernel: Oops: 0000 [#1] PREEMPT SMP
Oct 31 21:39:17 localhost kernel: CPU 1
Oct 31 21:39:17 localhost kernel: Modules linked in: uinput hidp hid
autofs4 bridge stp llc tun nf_nat_ftp nf_nat_irc nf_conntrack_ftp
nf_conntrack_irc ipt_MASQUERADE iptable_nat nf_nat ipt_REJECT
xt_tcpudp xt_state ipt_LOG xt_limit nf_conntrack_ipv4 nf_conntrack
nf_defrag_ipv4 iptable_filter ip_tables x_tables bnep ppp_generic slhc
cfq_iosched blk_cgroup ioatdma dca cpufreq_powersave cpufreq_ondemand
cpufreq_conservative acpi_cpufreq freq_table mperf coretemp fan
af_packet nls_cp1255 nls_iso8859_1 nls_utf8 rfcomm aes_x86_64
aes_generic ecb crypto_blkcipher btusb bluetooth uvcvideo videodev
cryptomgr aead arc4 crypto_algapi snd_hda_codec_conexant snd_hda_intel
snd_hda_codec iwlagn joydev thinkpad_acpi mac80211 snd_pcm snd_timer
uhci_hcd ehci_hcd sdhci_pci hwmon cfg80211 snd sdhci sr_mod battery
usbcore snd_page_alloc thermal psmouse pcspkr e1000e mmc_core
soundcore i2c_i801 cdrom processor ac rfkill rtc_cmos power_supply
nvram sg unix evdev ext4 crc16 jbd2 mbcache loop ahci libahci libata
sd_mod scsi_mod
Oct 31 21:39:17 localhost kernel:
Oct 31 21:39:17 localhost kernel: Pid: 8955, comm: hidd Not tainted
3.1.0-gentoo #1 LENOVO 406226U/406226U
Oct 31 21:39:17 localhost kernel: RIP: 0010:[<ffffffffa03d7039>]
[<ffffffffa03d7039>] hid_add_device+0x9/0x200 [hid]
Oct 31 21:39:17 localhost kernel: RSP: 0018:ffff8801358f3c48 EFLAGS: 00010296
Oct 31 21:39:17 localhost kernel: RAX: 0000000000000000 RBX:
0000000000000000 RCX: ffff88011a801368
Oct 31 21:39:17 localhost kernel: RDX: ffff88011a801368 RSI:
0000000000000212 RDI: 0000000000000000
Oct 31 21:39:17 localhost kernel: RBP: ffff88011a801360 R08:
0000000000000000 R09: 0000000000000000
Oct 31 21:39:17 localhost kernel: R10: 0000000000000000 R11:
0000000000000001 R12: ffff8801358f3c88
Oct 31 21:39:17 localhost kernel: R13: ffff880136f98000 R14:
ffff8801358f3ca0 R15: ffff880136f98000
Oct 31 21:39:17 localhost kernel: FS: 00007f18c7345700(0000)
GS:ffff88013bd00000(0000) knlGS:0000000000000000
Oct 31 21:39:17 localhost kernel: CS: 0010 DS: 0000 ES: 0000 CR0:
000000008005003b
Oct 31 21:39:17 localhost kernel: CR2: 0000000000001b00 CR3:
000000011abc1000 CR4: 00000000000006e0
Oct 31 21:39:17 localhost kernel: DR0: 0000000000000000 DR1:
0000000000000000 DR2: 0000000000000000
Oct 31 21:39:17 localhost kernel: DR3: 0000000000000000 DR6:
00000000ffff0ff0 DR7: 0000000000000400
Oct 31 21:39:17 localhost kernel: Process hidd (pid: 8955, threadinfo
ffff8801358f2000, task ffff880136f98000)
Oct 31 21:39:17 localhost kernel: Stack:
Oct 31 21:39:17 localhost kernel: 0000000000000212 ffffffff8105dc5a
ffff88011a801200 ffff88011a801200
Oct 31 21:39:17 localhost kernel: ffff88011a801360 ffffffffa0308bc5
0000000000000000 ffff880127b89800
Oct 31 21:39:17 localhost kernel: 0000000000000000 ffff880136f98000
ffffffff8105db00 ffff8801358f3ca0
Oct 31 21:39:17 localhost kernel: Call Trace:
Oct 31 21:39:17 localhost kernel: [<ffffffff8105dc5a>] ? finish_wait+0x3a/0x90
Oct 31 21:39:17 localhost kernel: [<ffffffffa0308bc5>] ?
hidp_add_connection+0x395/0x8c0 [hidp]
Oct 31 21:39:17 localhost kernel: [<ffffffff8105db00>] ? wake_up_bit+0x40/0x40
Oct 31 21:39:17 localhost kernel: [<ffffffffa03095a1>] ?
hidp_sock_ioctl+0x221/0x2e0 [hidp]
Oct 31 21:39:17 localhost kernel: [<ffffffff8113cae4>] ? fsnotify+0x1c4/0x2e0
Oct 31 21:39:17 localhost kernel: [<ffffffff811b98c0>] ? n_tty_ioctl+0xc0/0xc0
Oct 31 21:39:17 localhost kernel: [<ffffffff812ecc52>] ?
sockfd_lookup_light+0x22/0x90
Oct 31 21:39:17 localhost kernel: [<ffffffff812ee7cc>] ? sys_sendto+0x13c/0x1a0
Oct 31 21:39:17 localhost kernel: [<ffffffff81104254>] ?
do_readv_writev+0x1c4/0x210
Oct 31 21:39:17 localhost kernel: [<ffffffff812ec139>] ? sock_ioctl+0x69/0x2a0
Oct 31 21:39:17 localhost kernel: [<ffffffff811152e6>] ? do_vfs_ioctl+0x96/0x500
Oct 31 21:39:17 localhost kernel: [<ffffffffa02d7931>] ?
l2cap_sock_getsockopt+0xa1/0x340 [bluetooth]
Oct 31 21:39:17 localhost kernel: [<ffffffff811157e8>] ? sys_ioctl+0x98/0xa0
Oct 31 21:39:17 localhost kernel: [<ffffffff8138333b>] ?
system_call_fastpath+0x16/0x1b
Oct 31 21:39:17 localhost kernel: Code: 00 00 48 89 ef 48 c7 c3 f4 ff
ff ff e8 e1 07 ee e0 eb b6 66 66 66 66 66 66 2e 0f 1f 84 00 00 00 00
00 55 53 48 89 fb 48 83 ec 18 <f6> 87 00 1b 00 00 01 0f 85 c1 01 00 00
8b af 08 1b 00 00 f7 c5
Oct 31 21:39:17 localhost kernel: RIP [<ffffffffa03d7039>]
hid_add_device+0x9/0x200 [hid]
Oct 31 21:39:17 localhost kernel: RSP <ffff8801358f3c48>
Oct 31 21:39:17 localhost kernel: CR2: 0000000000001b00
Oct 31 21:39:17 localhost kernel: ---[ end trace 326cc646c2b87b83 ]---
---
^ 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.