* Re: [PATCH] ahci: add DT binding for Calxeda AHCI controller
From: Rob Herring @ 2011-10-24 14:20 UTC (permalink / raw)
To: Jeff Garzik; +Cc: linux-ide, linux-kernel, devicetree-discuss
In-Reply-To: <4E8A6FB3.4090909@gmail.com>
Jeff,
On 10/03/2011 09:30 PM, Rob Herring wrote:
> On 09/02/2011 10:10 AM, Rob Herring wrote:
>> From: Rob Herring <rob.herring@calxeda.com>
>>
>> Add devicetree match table to ahci platform driver for Calxeda Highbank
>> AHCI controller.
>>
>> Signed-off-by: Rob Herring <rob.herring@calxeda.com>
>> Cc: Jeff Garzik <jgarzik@pobox.com>
>> Cc: linux-ide@vger.kernel.org
>> Cc: linux-kernel@vger.kernel.org
>> Cc: devicetree-discuss@lists.ozlabs.org
>> ---
>
> Any comments on this?
>
Ping.
Can you please apply this for 3.2.
Regards,
Rob
>> .../devicetree/bindings/ata/calxeda-sata.txt | 17 +++++++++++++++++
>> drivers/ata/ahci_platform.c | 7 +++++++
>> 2 files changed, 24 insertions(+), 0 deletions(-)
>> create mode 100644 Documentation/devicetree/bindings/ata/calxeda-sata.txt
>>
>> diff --git a/Documentation/devicetree/bindings/ata/calxeda-sata.txt b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> new file mode 100644
>> index 0000000..79caa56
>> --- /dev/null
>> +++ b/Documentation/devicetree/bindings/ata/calxeda-sata.txt
>> @@ -0,0 +1,17 @@
>> +* Calxeda SATA Controller
>> +
>> +SATA nodes are defined to describe on-chip Serial ATA controllers.
>> +Each SATA controller should have its own node.
>> +
>> +Required properties:
>> +- compatible : compatible list, contains "calxeda,hb-ahci"
>> +- interrupts : <interrupt mapping for SATA IRQ>
>> +- reg : <registers mapping>
>> +
>> +Example:
>> + sata@ffe08000 {
>> + compatible = "calxeda,hb-ahci";
>> + reg = <0xffe08000 0x1000>;
>> + interrupts = <115>;
>> + };
>> +
>> diff --git a/drivers/ata/ahci_platform.c b/drivers/ata/ahci_platform.c
>> index 6fef1fa..9bfc970 100644
>> --- a/drivers/ata/ahci_platform.c
>> +++ b/drivers/ata/ahci_platform.c
>> @@ -171,11 +171,18 @@ static int __devexit ahci_remove(struct platform_device *pdev)
>> return 0;
>> }
>>
>> +static const struct of_device_id ahci_of_match[] = {
>> + { .compatible = "calxeda,hb-ahci", },
>> + {},
>> +};
>> +MODULE_DEVICE_TABLE(of, ahci_of_match);
>> +
>> static struct platform_driver ahci_driver = {
>> .remove = __devexit_p(ahci_remove),
>> .driver = {
>> .name = "ahci",
>> .owner = THIS_MODULE,
>> + .of_match_table = ahci_of_match,
>> },
>> };
>>
>
^ permalink raw reply
* Re: [PATCH 1/2] drm/kms: Make i2c buses faster
From: Eugeni Dodonov @ 2011-10-24 14:19 UTC (permalink / raw)
To: Alex Deucher; +Cc: dri-devel, Jean Delvare
In-Reply-To: <CADnq5_MH1qPr6zvZYJ4bCb2kBLHu=g57JKAgDqAAfeLMAMbmXQ@mail.gmail.com>
[-- Attachment #1.1: Type: text/plain, Size: 880 bytes --]
On Sat, Oct 22, 2011 at 12:38, Alex Deucher <alexdeucher@gmail.com> wrote:
> On Fri, Oct 21, 2011 at 3:29 PM, Jean Delvare <jdelvare@suse.de> wrote:
> > Hi Alex,
> >
> > On Friday 21 October 2011 08:05:48 pm Alex Deucher wrote:
> >> On Fri, Oct 21, 2011 at 10:16 AM, Jean Delvare <jdelvare@suse.de>
> >> > Does anyone know at which speed hardware I2C engines are running
> >> > the DDC bus on various graphics cards?
> >>
> >> IIRC, we generally target the radeon hw i2c engines to run at 50 khz.
> >
> > Then it doesn't seem unreasonable to try and achieve the same for bit-
> > banged I2C. That's exactly what my patch is doing.
>
> Seems fine to me then. I don't know why we set it so low to begin
> with, but I'm certainly not an i2c expert.
>
Seems fine for me as well.
Acked-by: Eugeni Dodonov <eugeni.dodonov@intel.com>
--
Eugeni Dodonov
<http://eugeni.dodonov.net/>
[-- Attachment #1.2: Type: text/html, Size: 1462 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel
^ permalink raw reply
* Re: [Xen-devel] Re: [PATCH 5/6] xen/netback: Enable netback on HVM guests
From: Konrad Rzeszutek Wilk @ 2011-10-24 14:19 UTC (permalink / raw)
To: David Miller; +Cc: Ian.Campbell, netdev, dgdegra, xen-devel, david.vrabel
In-Reply-To: <20111024.053419.1995560587557035685.davem@davemloft.net>
On Mon, Oct 24, 2011 at 05:34:19AM -0400, David Miller wrote:
> From: Ian Campbell <Ian.Campbell@citrix.com>
> Date: Mon, 24 Oct 2011 10:31:08 +0100
>
> > On Thu, 2011-10-20 at 16:35 +0100, Daniel De Graaf wrote:
> >> Signed-off-by: Daniel De Graaf <dgdegra@tycho.nsa.gov>
> >
> > Acked-by: Ian Campbell <ian.campbell@citrix.com>
> >
> > Normally netback patches would go in via the networking subsystem
> > maintainer's tree but since this depends on core Xen patches from this
> > series and is unlikely to conflict with anything in the net-next tree I
> > suspect it would make more sense for Konrad to take this one.
> >
> > David (Miller) does that work for you?
>
> Yes, it does.
OK, Can I stick Acked-by: David Miller on that patch?
Thank you.
^ permalink raw reply
* Re: [RFC PATCH 1/2] tools/perf: Don't set attr->disabled when doing grouping
From: David Ahern @ 2011-10-24 14:19 UTC (permalink / raw)
To: Deng-Cheng Zhu
Cc: linux-kernel, Peter Zijlstra, Paul Mackerras, Ingo Molnar,
Arnaldo Carvalho de Melo
In-Reply-To: <1319453820-12992-2-git-send-email-dczhu@mips.com>
On 10/24/2011 04:56 AM, Deng-Cheng Zhu wrote:
> Events will be created at the state PERF_EVENT_STATE_OFF if attr->disabled
> is set. When these events go to arch level validate_group(), the function
> won't do anything real because they are filtered out by the state check.
Seems like a bug with the group checks. You should be able to enable and
disable events - including creating them disabled.
David
>
> Signed-off-by: Deng-Cheng Zhu <dczhu@mips.com>
> Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Ingo Molnar <mingo@elte.hu>
> Cc: Arnaldo Carvalho de Melo <acme@ghostprotocols.net>
> ---
> tools/perf/builtin-record.c | 6 +++---
> tools/perf/builtin-stat.c | 3 ++-
> 2 files changed, 5 insertions(+), 4 deletions(-)
>
> diff --git a/tools/perf/builtin-record.c b/tools/perf/builtin-record.c
> index f4c3fbe..67e8e4c 100644
> --- a/tools/perf/builtin-record.c
> +++ b/tools/perf/builtin-record.c
> @@ -161,7 +161,6 @@ static void config_attr(struct perf_evsel *evsel, struct perf_evlist *evlist)
> struct perf_event_attr *attr = &evsel->attr;
> int track = !evsel->idx; /* only the first counter needs these */
>
> - attr->disabled = 1;
> attr->inherit = !no_inherit;
> attr->read_format = PERF_FORMAT_TOTAL_TIME_ENABLED |
> PERF_FORMAT_TOTAL_TIME_RUNNING |
> @@ -222,10 +221,11 @@ static void config_attr(struct perf_evsel *evsel, struct perf_evlist *evlist)
> attr->mmap = track;
> attr->comm = track;
>
> - if (target_pid == -1 && target_tid == -1 && !system_wide) {
> + if (!group)
> attr->disabled = 1;
> +
> + if (target_pid == -1 && target_tid == -1 && !system_wide)
> attr->enable_on_exec = 1;
> - }
> }
>
> static bool perf_evlist__equal(struct perf_evlist *evlist,
> diff --git a/tools/perf/builtin-stat.c b/tools/perf/builtin-stat.c
> index 5deb17d..ca95475 100644
> --- a/tools/perf/builtin-stat.c
> +++ b/tools/perf/builtin-stat.c
> @@ -284,7 +284,8 @@ static int create_perf_stat_counter(struct perf_evsel *evsel)
> return perf_evsel__open_per_cpu(evsel, evsel_list->cpus, group);
>
> if (target_pid == -1 && target_tid == -1) {
> - attr->disabled = 1;
> + if (!group)
> + attr->disabled = 1;
> attr->enable_on_exec = 1;
> }
>
^ permalink raw reply
* Re: bridge: HSR support
From: Arvid Brodin @ 2011-10-24 14:17 UTC (permalink / raw)
To: Stephen Hemminger; +Cc: netdev
In-Reply-To: <4E94D67A.9060207@enea.com>
Stephen Hemminger wrote:
> On Tue, 11 Oct 2011 20:25:08 +0200
> Arvid Brodin <arvid.brodin@enea.com> wrote:
>
>> Hi,
>>
>> I want to add support for HSR ("High-availability Seamless Redundancy",
>> IEC-62439-3) to the bridge code. With HSR, all connected units have two network
>> ports and are connected in a ring. All new Ethernet packets are sent on both
>> ports (or passed through if the current unit is not the originating unit). The
>> same packet is never passed twice. Non-HSR units are not allowed in the ring.
>>
>> This gives instant, reconfiguration-free failover.
>>
>> I'd like your input on how to design the user interface. To me it seems natural
>> to use bridge-utils, which of course today supports STP.
>>
>> One solution is to simply add an "hsr" command:
>>
>> # brctl hsr <bridge> on|off
>>
>> But HSR is mutually exclusive to other modes, and I think that STP and standard
>> bridge mode are mutually exclusive, too? Perhaps it would be better (more user-
>> friendly) to
>>
>> # brctl type <bridge> standard|stp|hsr
>>
>> ?
>>
>> 'brctl stp <bridge> on|off' would have to be kept for compatibility, but could
>> be a simple wrapper for 'brctl type <bridge> stp|standard'
>>
>> What do you think about this?
>>
>
> Why is it a bridge thing and not a standalone or bonding (or the new team
> device feature? Wouldn't users want to use it without all the stuff
> related to bridging. The fact that it doesn't work with STP is a big
> red flag that it doesn't belong in the bridge.
Ok, having read up some more on this it looks like STP is a standardised part of
bridging, so I guess you're right.
I need to do two things:
1) Bind two network interfaces into one (say, eth0 & eth1 => hsr0). Frames sent on
hsr0 should get an HSR tag (including the correct EtherType) and go out on both
eth0 and eth1.
2) Ingress frames on eth0 & eth1, with EtherType 0x88fb, should be captured and
handled specially (either received on hsr0 or forwarded to the other bound
physical interface).
Any ideas on the best way to implement this -- what's the nicest place to "hook
into" for this?
--
Arvid Brodin
Enea Services Stockholm AB
^ permalink raw reply
* [DRAFT PATCH] lvmcache and lvmetad
From: Petr Rockai @ 2011-10-24 14:17 UTC (permalink / raw)
To: lvm-devel
Hi,
I have been working on isolating lvmcache code from the rest of the
codebase. I am making progress slowly, since this is very tedious and
very error-prone. A lot of code is copied out around the code base and
cache internals are manipulated all over the place. I am attaching my
current state of the matters, which do not yet compile. When you expose
the internal structures, you can get things to compile though and pass
the tests as well. I will continue drilling down while trying to avoid
any new bugs.
The plan is to, when the lvmcache is finally walled off, to create a new
implementation (of the APIs) that only does the bare minimum to get LVM
going and passing the testsuite. The following step would then be to
factor this functionality out of lvmcache altogether, as far as that
turns out to be possible. After that is done, finally, I can resume work
on integrating lvmetad, which has been so far blocked out by lvmcache
mis-design. In the meantime, I'll try to integrate some lvmetad tests
into the suite (the daemon can be tested even without full LVM support).
Yours,
Petr
-------------- next part --------------
A non-text attachment was scrubbed...
Name: lvmcache.diff
Type: text/x-diff
Size: 39299 bytes
Desc: not available
URL: <http://listman.redhat.com/archives/lvm-devel/attachments/20111024/8036749b/attachment.bin>
-------------- next part --------------
--
id' Ash = Ash; id' Dust = Dust; id' _ = undefined
^ permalink raw reply
* Re: [CONSOLIDATED PULL 20/27] libtool: Upgrade from 2.4 -> 2.4.2
From: Richard Purdie @ 2011-10-24 14:10 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <3D2F5FE5-B1DC-44C4-8A5A-E81C41F00125@dominion.thruhere.net>
On Mon, 2011-10-24 at 15:37 +0200, Koen Kooi wrote:
> Op 24 okt. 2011, om 15:34 heeft Richard Purdie het volgende geschreven:
>
> > On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> >> From: Khem Raj <raj.khem@gmail.com>
> >>
> >> Adjust prefix.patch and delete resolve-sysroot.patch
> >> since its already applied upstream
> >>
> >> Signed-off-by: Khem Raj <raj.khem@gmail.com>
> >> ---
> >> .../libtool/{libtool.inc => libtool-2.4.2.inc} | 26 +++++++++---
> >> meta/recipes-devtools/libtool/libtool-2.4.inc | 13 ------
> >> ...libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} | 2 +-
> >> ...btool-native_2.4.bb => libtool-native_2.4.2.bb} | 2 +-
> >> ...nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} | 2 +-
> >> meta/recipes-devtools/libtool/libtool/prefix.patch | 46 ++++++++++----------
> >> .../libtool/libtool/resolve-sysroot.patch | 42 ------------------
> >> .../libtool/{libtool_2.4.bb => libtool_2.4.2.bb} | 2 +-
> >> 8 files changed, 47 insertions(+), 88 deletions(-)
> >> rename meta/recipes-devtools/libtool/{libtool.inc => libtool-2.4.2.inc} (57%)
> >> delete mode 100644 meta/recipes-devtools/libtool/libtool-2.4.inc
> >> rename meta/recipes-devtools/libtool/{libtool-cross_2.4.bb => libtool-cross_2.4.2.bb} (98%)
> >> rename meta/recipes-devtools/libtool/{libtool-native_2.4.bb => libtool-native_2.4.2.bb} (96%)
> >> rename meta/recipes-devtools/libtool/{libtool-nativesdk_2.4.bb => libtool-nativesdk_2.4.2.bb} (97%)
> >> delete mode 100644 meta/recipes-devtools/libtool/libtool/resolve-sysroot.patch
> >> rename meta/recipes-devtools/libtool/{libtool_2.4.bb => libtool_2.4.2.bb} (94%)
> >>
> >> diff --git a/meta/recipes-devtools/libtool/libtool.inc b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> similarity index 57%
> >> rename from meta/recipes-devtools/libtool/libtool.inc
> >> rename to meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> index ef9095b..1f652ef 100644
> >> --- a/meta/recipes-devtools/libtool/libtool.inc
> >> +++ b/meta/recipes-devtools/libtool/libtool-2.4.2.inc
> >> @@ -1,4 +1,3 @@
> >> -SUMMARY = "Generic library support script"
> >
> > Why drop the SUMMARY field?
>
> What's the difference between SUMMARY and DESCRIPTION? And what happens if both are set?
SUMMARY is a one line 74? character summary of the package, DESCRIPTION
is a multiple line stream of text containing a more verbose description.
What happens to the data is package backend specific, I know RPM has
uses for both. There was definitely discussion about this on the mailing
list at the time, I'm not sure what if anything made it into the manuals
but if its not there it should be added.
Cheers,
Richard
^ permalink raw reply
* Re: [Qemu-devel] [PATCH v2 3/4] Add cap reduction support to enable use as SUID
From: Corey Bryant @ 2011-10-24 14:13 UTC (permalink / raw)
To: Blue Swirl; +Cc: rmarwah, aliguori, qemu-devel
In-Reply-To: <CAAu8pHt0NGGEv7cpdvdtBc7Hrp2XBjJo79ce1RghVextptdVHA@mail.gmail.com>
On 10/23/2011 09:22 AM, Blue Swirl wrote:
> On Fri, Oct 21, 2011 at 15:07, Corey Bryant<coreyb@linux.vnet.ibm.com> wrote:
>> The ideal way to use qemu-bridge-helper is to give it an fscap of using:
>>
>> setcap cap_net_admin=ep qemu-bridge-helper
>>
>> Unfortunately, most distros still do not have a mechanism to package files
>> with fscaps applied. This means they'll have to SUID the qemu-bridge-helper
>> binary.
>>
>> To improve security, use libcap to reduce our capability set to just
>> cap_net_admin, then reduce privileges down to the calling user. This is
>> hopefully close to equivalent to fscap support from a security perspective.
>>
>> Signed-off-by: Anthony Liguori<aliguori@us.ibm.com>
>> Signed-off-by: Richa Marwaha<rmarwah@linux.vnet.ibm.com>
>> Signed-off-by: Corey Bryant<coreyb@linux.vnet.ibm.com>
>> ---
>> configure | 34 ++++++++++++++++++++++++++++++++++
>> qemu-bridge-helper.c | 39 +++++++++++++++++++++++++++++++++++++++
>> 2 files changed, 73 insertions(+), 0 deletions(-)
>>
>> diff --git a/configure b/configure
>> index 6c8b659..fed66b0 100755
>> --- a/configure
>> +++ b/configure
>> @@ -128,6 +128,7 @@ vnc_thread="no"
>> xen=""
>> xen_ctrl_version=""
>> linux_aio=""
>> +cap=""
>> attr=""
>> xfs=""
>>
>> @@ -653,6 +654,10 @@ for opt do
>> ;;
>> --enable-kvm) kvm="yes"
>> ;;
>> + --disable-cap) cap="no"
>> + ;;
>> + --enable-cap) cap="yes"
>> + ;;
>> --disable-spice) spice="no"
>> ;;
>> --enable-spice) spice="yes"
>> @@ -1032,6 +1037,8 @@ echo " --disable-vde disable support for vde network"
>> echo " --enable-vde enable support for vde network"
>> echo " --disable-linux-aio disable Linux AIO support"
>> echo " --enable-linux-aio enable Linux AIO support"
>> +echo " --disable-cap disable libcap-ng support"
>> +echo " --enable-cap enable libcap-ng support"
>> echo " --disable-attr disables attr and xattr support"
>> echo " --enable-attr enable attr and xattr support"
>> echo " --disable-blobs disable installing provided firmware blobs"
>> @@ -1638,6 +1645,29 @@ EOF
>> fi
>>
>> ##########################################
>> +# libcap-ng library probe
>> +if test "$cap" != "no" ; then
>> + cap_libs="-lcap-ng"
>> + cat> $TMPC<< EOF
>> +#include<cap-ng.h>
>> +int main(void)
>> +{
>> + capng_capability_to_name(CAPNG_EFFECTIVE);
>> + return 0;
>> +}
>> +EOF
>> + if compile_prog "" "$cap_libs" ; then
>> + cap=yes
>> + libs_tools="$cap_libs $libs_tools"
>> + else
>> + if test "$cap" = "yes" ; then
>> + feature_not_found "cap"
>> + fi
>> + cap=no
>> + fi
>> +fi
>> +
>> +##########################################
>> # Sound support libraries probe
>>
>> audio_drv_probe()
>> @@ -2735,6 +2765,7 @@ echo "fdatasync $fdatasync"
>> echo "madvise $madvise"
>> echo "posix_madvise $posix_madvise"
>> echo "uuid support $uuid"
>> +echo "libcap-ng support $cap"
>> echo "vhost-net support $vhost_net"
>> echo "Trace backend $trace_backend"
>> echo "Trace output file $trace_file-<pid>"
>> @@ -2846,6 +2877,9 @@ fi
>> if test "$vde" = "yes" ; then
>> echo "CONFIG_VDE=y">> $config_host_mak
>> fi
>> +if test "$cap" = "yes" ; then
>> + echo "CONFIG_LIBCAP=y">> $config_host_mak
>> +fi
>> for card in $audio_card_list; do
>> def=CONFIG_`echo $card | tr '[:lower:]' '[:upper:]'`
>> echo "$def=y">> $config_host_mak
>> diff --git a/qemu-bridge-helper.c b/qemu-bridge-helper.c
>> index db257d5..b1562eb 100644
>> --- a/qemu-bridge-helper.c
>> +++ b/qemu-bridge-helper.c
>> @@ -33,6 +33,10 @@
>>
>> #include "net/tap-linux.h"
>>
>> +#ifdef CONFIG_LIBCAP
>> +#include<cap-ng.h>
>> +#endif
>> +
>> #define MAX_ACLS (128)
>> #define DEFAULT_ACL_FILE CONFIG_QEMU_CONFDIR "/bridge.conf"
>>
>> @@ -185,6 +189,27 @@ static int send_fd(int c, int fd)
>> return sendmsg(c,&msg, 0);
>> }
>>
>> +#ifdef CONFIG_LIBCAP
>> +static int drop_privileges(void)
>> +{
>> + /* clear all capabilities */
>> + capng_clear(CAPNG_SELECT_BOTH);
>> +
>> + if (capng_update(CAPNG_ADD, CAPNG_EFFECTIVE | CAPNG_PERMITTED,
>> + CAP_NET_ADMIN)< 0) {
>> + return -1;
>> + }
>> +
>> + /* change to calling user's real uid and gid, retaining supplemental
>> + * groups and CAP_NET_ADMIN */
>> + if (capng_change_id(getuid(), getgid(), CAPNG_CLEAR_BOUNDING)) {
>> + return -1;
>> + }
>> +
>> + return 0;
>> +}
>> +#endif
>> +
>> int main(int argc, char **argv)
>> {
>> struct ifreq ifr;
>> @@ -198,6 +223,20 @@ int main(int argc, char **argv)
>> int acl_count = 0;
>> int i, access_allowed, access_denied;
>>
>> + /* if we're run from an suid binary, immediately drop privileges preserving
>> + * cap_net_admin -- exit immediately if libcap not configured */
>> + if (geteuid() == 0&& getuid() != geteuid()) {
>> +#ifdef CONFIG_LIBCAP
>> + if (drop_privileges() == -1) {
>> + fprintf(stderr, "failed to drop privileges\n");
>> + return 1;
>> + }
>> +#else
>> + fprintf(stderr, "failed to drop privileges\n");
>
> This makes the tool useless without CONFIG_LIBCAP. Wouldn't it be
> possible to use setfsuid() instead for Linux?
>
> Some fork+setuid helper could be used for other Unix and for the lame
> OSes without any file system DAC capabilities, a different syntax that
> does not rely on underlying FS may need to be introduced. Again, I
> don't know if the tool is even interesting for non-Linux.
>
I just want to make sure that there is no chance that the helper is run
as root beyond this point. Are you saying to seteuid(getuid) and
setfsuid(root)? I'm not sure that would drop the privileges enough.
>> + return 1;
>> +#endif
>> + }
>> +
>> /* parse arguments */
>> if (argc< 3 || argc> 4) {
>> fprintf(stderr, "Usage: %s [--use-vnet] BRIDGE FD\n", argv[0]);
>> --
>> 1.7.3.4
>>
>>
>>
>
--
Regards,
Corey
^ permalink raw reply
* dmesg full of DMAR errors
From: Sven Köhler @ 2011-10-24 14:17 UTC (permalink / raw)
To: linux-kernel
Hi,
I'm facing the same problems as described in
https://bugzilla.redhat.com/show_bug.cgi?id=605888
I'm not sure what the conclusion of the bugzilla discussion is:
1) you decided to not workaround the bug and I should disable VT-d instead
2) you decided to workaround the bug by blacklisting device IDs
The messages are:
DMAR:[DMA Read] Request device [04:00.0] fault addr fffff000
DRHD: handling fault status reg 2
The devices in question are:
04:00.0 SD Host controller: Ricoh Co Ltd MMC/SD Host Controller (rev 03)
04:00.4 FireWire (IEEE 1394): Ricoh Co Ltd FireWire Host Controller (rev 03)
or
04:00.0 0805: 1180:e822 (rev 03)
04:00.4 0c00: 1180:e832 (rev 03)
Product ID 0xe832 is not mentioned in the bug. Maybe it has not been
blacklisted if you went for (2)?
Regards,
Sven Köhler
^ permalink raw reply
* Re: xfs_symlink problem? 3.1 after rc10
From: Carlos Maiolino @ 2011-10-24 14:13 UTC (permalink / raw)
To: Arkadiusz Miśkiewicz; +Cc: xfs
In-Reply-To: <201110241540.01268.arekm@maven.pl>
> It happened again:
>
> http://ixion.pld-linux.org/~arekm/100_5434.JPG
> http://ixion.pld-linux.org/~arekm/100_5433.JPG
>
> The weird thing is that I never ever hit this before with pre 3.1rc10 git
> kernels. Was your bugfix a fix for new issue that was introduced in 3.1 cycle
> or for something old?
>
Hmm, sorry, my mistake here, I fixed a problem on xfs_readlink, not at xfs_symlink.
Although, by your last screenshots, it doesn't look to be related with the problem
I was working before.
On all screenshots the system is crashing while trying to acquire a mutex lock, I don't
know much about the code path where the crash is happening, but, maybe if you enable
CONFIG_XFS_DEBUG we can get some extra hints about where the system is crashing? Also,
have you fsck'ed this FS? maybe an `xfs_repair -nv` would give any clue if there is any
corrupted metadata which would cause this error
--
--Carlos
_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCHv3 2/3] batman-adv: check for tt_reponse packet real length
From: Marek Lindner @ 2011-10-24 14:13 UTC (permalink / raw)
To: The list for a Better Approach To Mobile Ad-hoc Networking
In-Reply-To: <1318789923-29405-2-git-send-email-ordex@autistici.org>
On Sunday, October 16, 2011 20:32:03 Antonio Quartulli wrote:
> Before accessing the TT_RESPONSE packet payload, the node has to ensure
> that the packet is long enough as it would expect to be.
Patch was applied in revision e096f38.
Thanks,
Marek
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Baruch Siach @ 2011-10-24 14:12 UTC (permalink / raw)
To: Nicolas Ferre
Cc: robherring2, grant.likely, devicetree-discuss, plagnioj,
linux-kernel, linux-arm-kernel
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>
Hi Nicolas,
On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
[snip]
> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
appropriate name?
> + /* Maintainer: Atmel */
> + .timer = &at91sam926x_timer,
> + .map_io = at91_map_io,
> + .init_early = ek_init_early,
> + .init_irq = at91_dt_init_irq,
> + .init_machine = at91_dt_device_init,
> + .dt_compat = at91_dt_board_compat,
> +MACHINE_END
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* Re: [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Baruch Siach @ 2011-10-24 14:12 UTC (permalink / raw)
To: Nicolas Ferre
Cc: devicetree-discuss, linux-kernel, grant.likely, plagnioj,
linux-arm-kernel
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>
Hi Nicolas,
On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
[snip]
> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
appropriate name?
> + /* Maintainer: Atmel */
> + .timer = &at91sam926x_timer,
> + .map_io = at91_map_io,
> + .init_early = ek_init_early,
> + .init_irq = at91_dt_init_irq,
> + .init_machine = at91_dt_device_init,
> + .dt_compat = at91_dt_board_compat,
> +MACHINE_END
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch@tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [PATCH V3 1/2] ARM: at91: dt: at91sam9g45 family and board device tree files
From: Baruch Siach @ 2011-10-24 14:12 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <15ab652499e7f6f8a26724bfd90643a8f3f96ad9.1319464310.git.nicolas.ferre@atmel.com>
Hi Nicolas,
On Mon, Oct 24, 2011 at 04:05:00PM +0200, Nicolas Ferre wrote:
> Create a new device tree source file for Atmel at91sam9g45 SoC family.
> The Evaluation Kit at91sam9m10g45ek includes it.
> This first basic support will be populated as drivers and boards will be
> converted to device tree.
> Contains serial, dma and interrupt controllers.
>
> The generic board file still takes advantage of platform data for early serial
> init. As we need a storage media and the NAND flash driver is not converted to
> DT yet, we keep old initialization for it.
>
> Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
> ---
[snip]
> +DT_MACHINE_START(at91sam9m10g45ek_dt, "Atmel AT91SAM (Device Tree)")
Since this is a generic AT91 machine descriptor, won't "at91sam_dt" be a more
appropriate name?
> + /* Maintainer: Atmel */
> + .timer = &at91sam926x_timer,
> + .map_io = at91_map_io,
> + .init_early = ek_init_early,
> + .init_irq = at91_dt_init_irq,
> + .init_machine = at91_dt_device_init,
> + .dt_compat = at91_dt_board_compat,
> +MACHINE_END
baruch
--
~. .~ Tk Open Systems
=}------------------------------------------------ooO--U--Ooo------------{=
- baruch at tkos.co.il - tel: +972.2.679.5364, http://www.tkos.co.il -
^ permalink raw reply
* [Buildroot] Call For Participation: buildroot + crosstool-NG Developpers' Day
From: Yann E. MORIN @ 2011-10-24 14:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <CAJaTeTrSYvCU-KtB=RmQeV1E5Jedq9TAwYasTN6drfuc_00USw@mail.gmail.com>
Mike, All,
On Monday 24 October 2011 155925 Mike Frysinger wrote:
> i'm leaving sat morn, but i'd like to meet up with you guys at some
> point if only to say "hi" :)
Sure! There will be plenty of possibilities, during the three days that
ELC-E and LinuxCon last, to have whatever ${BEVERAGE} together! :-)
That'll be nice to meet people, new and long-known alike, in person! :-)
Cheers,
Yann E. MORIN.
--
.-----------------.--------------------.------------------.--------------------.
| Yann E. MORIN | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software Designer | \ / CAMPAIGN | ^ |
| --==< O_o >==-- '------------.-------: X AGAINST | /e\ There is no |
| http://ymorin.is-a-geek.org/ | (*_*) | / \ HTML MAIL | """ conspiracy. |
'------------------------------'-------'------------------'--------------------'
^ permalink raw reply
* Re: [PATCH] block: Remove the control of complete cpu from bio.
From: Jens Axboe @ 2011-10-24 14:12 UTC (permalink / raw)
To: Tao Ma; +Cc: LKML
In-Reply-To: <4EA4DFAE.4030407@tao.ma>
On 2011-10-24 05:46, Tao Ma wrote:
> On 09/16/2011 05:41 PM, Tao Ma wrote:
>> From: Tao Ma <boyu.mt@taobao.com>
>>
>> bio originally has the functionality to set the complete cpu, but
>> it is broken.
>>
>> Chirstoph said that "This code is unused, and from the all the
>> discussions lately pretty obviously broken. The only thing keeping
>> it serves is creating more confusion and possibly more bugs."
>>
>> And Jens replied with "We can kill bio_set_completion_cpu(). I'm fine
>> with leaving cpu control to the request based drivers, they are the
>> only ones that can toggle the setting anyway".
>>
>> So this patch tries to remove all the work of controling complete cpu
>> from a bio.
Applied, thanks!
--
Jens Axboe
^ permalink raw reply
* Re: Converting from Raid 5 to 6
From: Mathias Burén @ 2011-10-24 14:11 UTC (permalink / raw)
To: Michael Busby; +Cc: linux-raid
In-Reply-To: <CAFsPQ_85omy81WkxKkFg+OCGmdD7A+UtyKo64qMLZBBVKpbBDw@mail.gmail.com>
On 24 October 2011 14:11, Michael Busby <michael.a.busby@gmail.com> wrote:
> At the moment i have a raid5 setup with 5 disks, i am looking to add a
> 6th disk and change from raid 5 to raid 6
>
> having looked at Neil's site i have found the following command, and
> just want to double check this is still the recommend way of
> converting
>
> mdadm --grow /dev/md0 --level=6 --raid-disks=6 --backup-file=/home/md.backup
>
> also would i need to add the extra disk before or after the command?
>
> cheers
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
Hi,
I grew my 6 disk RAID5 to a 7 disk RAID6. First, add the drive. Then
partition it as required. Then add the drive to the array (I think
it'll become a spare?). Then you can grow it.
Make sure you're using the latest mdadm tools available.
Regards,
Mathias
--
To unsubscribe from this list: send the line "unsubscribe linux-raid" 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
* [PATCH V3 (bugfix to fold)] ARM: at91: usb_a9g20.dts: fix memory location
From: Nicolas Ferre @ 2011-10-24 14:09 UTC (permalink / raw)
To: robherring2, grant.likely
Cc: linux-kernel, linux-arm-kernel, devicetree-discuss, plagnioj,
Nicolas Ferre
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/usb_a9g20.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/usb_a9g20.dts
index a060f6c..d66e2c0 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9g20.dts
@@ -16,7 +16,7 @@
bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:128k(at91bootstrap),256k(barebox)ro,128k(bareboxenv),128k(bareboxenv2),4M(kernel),120M(rootfs),-(data) root=/dev/mtdblock5 rw rootfstype=ubifs";
};
- memory@70000000 {
+ memory@20000000 {
reg = <0x20000000 0x4000000>;
};
--
1.7.5.4
^ permalink raw reply related
* Re: [PATCH] Fix a typo
From: Jens Axboe @ 2011-10-24 14:09 UTC (permalink / raw)
To: jeff.liu; +Cc: linux-kernel
In-Reply-To: <4EA56D60.2030208@oracle.com>
On 2011-10-24 15:51, Jeff Liu wrote:
> Signed-off-by: Jie Liu <jeff.liu@oracle.com>
Applied, but please next time use a more reasonable subject line.
--
Jens Axboe
^ permalink raw reply
* [PATCH V3 (bugfix to fold)] ARM: at91: usb_a9g20.dts: fix memory location
From: Nicolas Ferre @ 2011-10-24 14:09 UTC (permalink / raw)
To: robherring2-Re5JQEeQqe8AvxtiuMwx3w,
grant.likely-s3s/WqlpOiPyB63q8FvJNQ
Cc: devicetree-discuss-uLR06cmDAlY/bJ5BZ2RsiQ,
linux-kernel-u79uwXL29TY76Z2rM5mHXA,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
Signed-off-by: Nicolas Ferre <nicolas.ferre-AIFe0yeh4nAAvxtiuMwx3w@public.gmane.org>
---
arch/arm/boot/dts/usb_a9g20.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/usb_a9g20.dts
index a060f6c..d66e2c0 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9g20.dts
@@ -16,7 +16,7 @@
bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:128k(at91bootstrap),256k(barebox)ro,128k(bareboxenv),128k(bareboxenv2),4M(kernel),120M(rootfs),-(data) root=/dev/mtdblock5 rw rootfstype=ubifs";
};
- memory@70000000 {
+ memory@20000000 {
reg = <0x20000000 0x4000000>;
};
--
1.7.5.4
^ permalink raw reply related
* [PATCH V3 (bugfix to fold)] ARM: at91: usb_a9g20.dts: fix memory location
From: Nicolas Ferre @ 2011-10-24 14:09 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <d139db89b4e9830e813abf1329ce1ac499653f2c.1319464310.git.nicolas.ferre@atmel.com>
Signed-off-by: Nicolas Ferre <nicolas.ferre@atmel.com>
---
arch/arm/boot/dts/usb_a9g20.dts | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/arm/boot/dts/usb_a9g20.dts b/arch/arm/boot/dts/usb_a9g20.dts
index a060f6c..d66e2c0 100644
--- a/arch/arm/boot/dts/usb_a9g20.dts
+++ b/arch/arm/boot/dts/usb_a9g20.dts
@@ -16,7 +16,7 @@
bootargs = "mem=64M console=ttyS0,115200 mtdparts=atmel_nand:128k(at91bootstrap),256k(barebox)ro,128k(bareboxenv),128k(bareboxenv2),4M(kernel),120M(rootfs),-(data) root=/dev/mtdblock5 rw rootfstype=ubifs";
};
- memory at 70000000 {
+ memory at 20000000 {
reg = <0x20000000 0x4000000>;
};
--
1.7.5.4
^ permalink raw reply related
* Re: [Qemu-devel] [PATCH] Add Qemu A15 minimal support for ARM KVM
From: Peter Maydell @ 2011-10-24 14:09 UTC (permalink / raw)
To: bill4carson; +Cc: cdall, qemu-devel, android-virt
In-Reply-To: <1317281403-31992-2-git-send-email-bill4carson@gmail.com>
On 29 September 2011 08:30, <bill4carson@gmail.com> wrote:
> From: Bill Carson <bill4carson@gmail.com>
>
> This patch add some A15 codes which enables ARM KVM could run
> Guest OS build with Versatile Express Cortex-A15x4 tile.
Thanks for sending this; I have somewhat belatedly written
up some comments on it.
I see the a15mpcore.c code is based on a version of mpcore.c
which predates the MemoryRegion API changes -- we'll need to
update it to use MemoryRegions.
There are some relics of 11MPCore peripherals lurking in there
which need to be taken out. (I think we should probably clean
up mpcore.c to separate out A9 from 11MPCore, incidentally.)
The vexpress A9 and A15 init functions can probably share
code although I haven't looked too closely there.
For QEMU TCG we're going to want to model at least some
of the cp15 registers (although probably mostly dummy
implementations).
The A15 generic timer is accessed via cp15 registers rather
than being memory mapped -- we need to decide which side of
the KVM/QEMU boundary the model of that should live. (I'm
guessing the right answer is "qemu side" which means we'll
need an ABI between KVM and QEMU to pass (some) cp15 accesses
through.)
thanks again
-- PMM
^ permalink raw reply
* Re: [PATCH 03/11] powerpc/85xx: Rework PCI nodes on P1020RDB
From: Timur Tabi @ 2011-10-24 14:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org
In-Reply-To: <49F9A823-B7C3-4D53-A061-8AC1C8D22554@kernel.crashing.org>
Kumar Gala wrote:
> I would have hoped the bindings had made it clear already what was board info vs what was SoC.
When it comes to device trees, I never assume anything is "clear".
> If not, they should be clarify that in the binding specs.
I'm okay with that.
--
Timur Tabi
Linux kernel developer at Freescale
^ permalink raw reply
* Re: [CONSOLIDATED PULL 00/27] Various Updates and fixes
From: Richard Purdie @ 2011-10-24 13:59 UTC (permalink / raw)
To: Patches and discussions about the oe-core layer
In-Reply-To: <cover.1319394187.git.sgw@linux.intel.com>
On Sun, 2011-10-23 at 11:26 -0700, Saul Wold wrote:
> This pull requests adds some new recipes for supporting building
> oe-core with oe-core, also various patches and updates.
I've taken a chunk of this but there were some issues.
> I also included the MACHINE_KERNEL_PR change from Dmitry per my
> reading of the TSC Notes.
That isn't what I understood from the TSC meeting and this patch isn't
getting merged.
> Cliff Brake (1):
> squashfs-tools: add recipe
>
>Khem Raj (7):
> tcmode-default.inc: Add TRANSLATED_TARGET_ARCH suffix to
> binutils-cross-canadian
> binutils-cross-canadian: Point sysroot to correct location
> gcc-configure-sdk: Point sysroot to correct location
> xserver-xorg: Add mesa-dri to depends instead of virtual/libgl
> gcc-4.6: Backport fix for PR32219
> coreutils: Upgrade recipe 8.12 -> 8.14
>
>Martin Jansa (5):
> apr: add native support
> neon: add native support
> apr-util: add native support
> subversion-1.6.15: add native support too
> default-providers: switch virtual/libgl from mesa-xlib to mesa-dri
>
> Nitin A Kamble (2):
> tcl: upgrade from 8.5.9 to 8.5.10
> perl: upgrade from 5.12.3 to 5.14.2
>
> Otavio Salvador (4):
> bootimg.bbclass: add support to disable HDD image building
> useradd.bbclass: check if a group already exists manually
> base-passwd: move initial criation of group and passwd to preinst
> dbus: use useradd class to allow use in read-only filesystems
>
> Saul Wold (2):
> texi2html: Added recipe from OE
> oprofile: Update to 0.9.7 and convert cvs->git
The above were merged.
>Saul Wold (3):
> wget: Add recipe from OE
> abiword: convert to svn
> perl: remove debug set -x; pwd
I squashed the perl fix into the perl commit, I've commented on the
other two.
>Dmitry Eremin-Solenikov (1):
> kernel.bbclass: respect MACHINE_KERNEL_PR
>
>Khem Raj (1):
> libtool: Upgrade from 2.4 -> 2.4.2
>
>Martin Jansa (2):
> pulseaudio-0.9.23: inherit perlnative to work around build on host
> without XML/Parser.pm
> subversion: add 1.7.0 with native support and negative D_P for now
I've also given feedback on these. I'm holding off subversion 1.7 until
we can come up with a good plan for handling it, it likely needs bitbake
fetcher support.
Cheers,
Richard
^ permalink raw reply
* Re: [PATCH] gpiolib: Ensure struct gpio is always defined
From: Mark Brown @ 2011-10-24 14:05 UTC (permalink / raw)
To: Grant Likely; +Cc: Grant Likely, linux-kernel, patches
In-Reply-To: <20111024140421.GW8708@ponder.secretlab.ca>
On Mon, Oct 24, 2011 at 04:04:21PM +0200, Grant Likely wrote:
> What does "flob" mean?
It means "I should have deleted this non-empty changelog I wrote so I
could squash down the commit.".
^ 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.