* Re: [PATCH] m68k: Revive lost DIO bus config option
From: Greg Ungerer @ 2011-10-31 3:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Greg Ungerer, linux-m68k, linux-kernel
In-Reply-To: <1319835295-19519-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 29/10/11 06:54, Geert Uytterhoeven wrote:
> commit 0e152d80507b75c00aac60f2ffc586360687cd52 ("m68k: reorganize Kconfig
> options to improve mmu/non-mmu selections") accidentally dropped the DIO
> bus config option. Re-add it to the "Bus support" section.
>
> Signed-off-by: Geert Uytterhoeven<geert@linux-m68k.org>
Oops, another one.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Are you going to push these to Linus, or do you want me to
collect these fixes and push?
Regards
Greg
> arch/m68k/Kconfig.bus | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
> index 7703b54..983e176 100644
> --- a/arch/m68k/Kconfig.bus
> +++ b/arch/m68k/Kconfig.bus
> @@ -2,6 +2,15 @@ if MMU
>
> comment "Bus Support"
>
> +config DIO
> + bool "DIO bus support"
> + depends on HP300
> + default y
> + help
> + Say Y here to enable support for the "DIO" expansion bus used in
> + HP300 machines. If you are using such a system you almost certainly
> + want this.
> +
> config NUBUS
> bool
> depends on MAC
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [PATCH] m68k: Revive lost DIO bus config option
From: Greg Ungerer @ 2011-10-31 3:51 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: Greg Ungerer, linux-m68k, linux-kernel
In-Reply-To: <1319835295-19519-1-git-send-email-geert@linux-m68k.org>
Hi Geert,
On 29/10/11 06:54, Geert Uytterhoeven wrote:
> commit 0e152d80507b75c00aac60f2ffc586360687cd52 ("m68k: reorganize Kconfig
> options to improve mmu/non-mmu selections") accidentally dropped the DIO
> bus config option. Re-add it to the "Bus support" section.
>
> Signed-off-by: Geert Uytterhoeven<geert@linux-m68k.org>
Oops, another one.
Acked-by: Greg Ungerer <gerg@uclinux.org>
Are you going to push these to Linus, or do you want me to
collect these fixes and push?
Regards
Greg
> arch/m68k/Kconfig.bus | 9 +++++++++
> 1 files changed, 9 insertions(+), 0 deletions(-)
>
> diff --git a/arch/m68k/Kconfig.bus b/arch/m68k/Kconfig.bus
> index 7703b54..983e176 100644
> --- a/arch/m68k/Kconfig.bus
> +++ b/arch/m68k/Kconfig.bus
> @@ -2,6 +2,15 @@ if MMU
>
> comment "Bus Support"
>
> +config DIO
> + bool "DIO bus support"
> + depends on HP300
> + default y
> + help
> + Say Y here to enable support for the "DIO" expansion bus used in
> + HP300 machines. If you are using such a system you almost certainly
> + want this.
> +
> config NUBUS
> bool
> depends on MAC
--
------------------------------------------------------------------------
Greg Ungerer -- Principal Engineer EMAIL: gerg@snapgear.com
SnapGear Group, McAfee PHONE: +61 7 3435 2888
8 Gardner Close FAX: +61 7 3217 5323
Milton, QLD, 4064, Australia WEB: http://www.SnapGear.com
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] tcg: Optimize some forms of deposit.
From: Alexander Graf @ 2011-10-31 3:47 UTC (permalink / raw)
To: Richard Henderson; +Cc: Blue Swirl, qemu-devel Developers
In-Reply-To: <1319750100-7592-1-git-send-email-rth@twiddle.net>
On 27.10.2011, at 23:15, Richard Henderson wrote:
> If the deposit replaces the entire word, optimize to a move.
>
> If we're inserting to the top of the word, avoid the mask of arg2
> as we'll be shifting out all of the garbage and shifting in zeros.
>
> If the host is 32-bit, reduce a 64-bit deposit to a 32-bit deposit
> when possible.
This patch breaks qemu-system-ppc64 on ppc32 hosts:
IN:
0x00000000fff08618: mfmsr r0
0x00000000fff0861c: ori r0,r0,48
0x00000000fff08620: mtmsr r0
OP:
---- 0xfff08618
mov_i32 r0_0,msr_0
mov_i32 r0_1,msr_1
---- 0xfff0861c
movi_i32 tmp0,$0x30
or_i32 r0_0,r0_0,tmp0
---- 0xfff08620
movi_i32 nip_0,$0xfff08624
movi_i32 nip_1,$0x0
mov_i32 tmp1,r0_0
movi_i32 tmp0,$store_msr
call tmp0,$0x0,$0,tmp2,tmp1
movi_i32 nip_0,$0xfff08624
movi_i32 nip_1,$0x0
exit_tb $0x0
OP after liveness analysis:
---- 0xfff08618
mov_i32 r0_0,msr_0
mov_i32 r0_1,msr_1
---- 0xfff0861c
movi_i32 tmp0,$0x30
or_i32 r0_0,r0_0,tmp0
---- 0xfff08620
movi_i32 nip_0,$0xfff08624
movi_i32 nip_1,$0x0
mov_i32 tmp1,r0_0
movi_i32 tmp0,$store_msr
call tmp0,$0x0,$0,tmp2,tmp1
movi_i32 nip_0,$0xfff08624
movi_i32 nip_1,$0x0
exit_tb $0x0
end
agraf@lychee:/home/agraf/release/qemu> ./ppc64-softmmu/qemu-system-ppc64 -kernel /boot/vmlinux -initrd /boot/initrd -nographic -d in_asm,cpu,int,op,op_opt,out_asm
/home/agraf/release/qemu/tcg/tcg.c:1929: tcg fatal error
Aborted
Alex
^ permalink raw reply
* [Bug 42409] New: Mesa 7.12-devel /dri/r600 compilation error: no makefile found
From: bugzilla-daemon @ 2011-10-31 3:44 UTC (permalink / raw)
To: dri-devel
https://bugs.freedesktop.org/show_bug.cgi?id=42409
Bug #: 42409
Summary: Mesa 7.12-devel /dri/r600 compilation error: no
makefile found
Classification: Unclassified
Product: Mesa
Version: git
Platform: x86-64 (AMD64)
OS/Version: All
Status: NEW
Severity: normal
Priority: medium
Component: Drivers/DRI/R600
AssignedTo: dri-devel@lists.freedesktop.org
ReportedBy: wolput@onsneteindhoven.nl
git mesa 7.72-devel compilation error:
drivers/dri/r600 no targets specified and no makefile found
---
make[5]: Entering directory
`/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri/r600'
make[5]: *** No targets specified and no makefile found. Stop.
make[5]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri/r600'
make[4]: *** [subdirs] Error 1
make[4]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/mesa/drivers/dri'
make[3]: *** [default] Error 1
make[3]: Leaving directory
`/home/jos/src/xorg/git-master/mesa/src/mesa/drivers'
make[2]: *** [driver_subdirs] Error 2
make[2]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src/mesa'
make[1]: *** [subdirs] Error 1
make[1]: Leaving directory `/home/jos/src/xorg/git-master/mesa/src'
make: *** [default] Error 1
---
--
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
^ permalink raw reply
* Re: [PATCH] echo: fix octal escaping with \1...\7
From: Herbert Xu @ 2011-10-31 3:41 UTC (permalink / raw)
To: Mike Frysinger; +Cc: dash
In-Reply-To: <1319579884-423-1-git-send-email-vapier@gentoo.org>
Mike Frysinger <vapier@gentoo.org> wrote:
> POSIX states that octal escape sequences should take the form \0num
> when using echo. dash however additionally treats \num as an octal
> sequence. This breaks some packages (like libtool) who attempt to
> use strings with these escape sequences via variables to execute sed
> (since sed ends up getting passed a byte instead of a literal \1).
OK this is a bit of problem. From our conversation I had the
impression that you were referring to the lack of support of
escape codes, rather than unwanted support.
If it was the former I could easily add it if POSIX said so,
however, as this is an existing feature there may well be scripts
out there that depend on it. So removing it is not an option
unless it is explicitly forbidden by POSIX.
In any case, scripts that rely on escape codes like this are
simply broken and should either be fixed to use printf or just
run with #!/bin/bash.
Cheers,
--
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
^ permalink raw reply
* profiling ceph
From: sheng qiu @ 2011-10-31 3:40 UTC (permalink / raw)
To: ceph-devel
hi,
is there any way to see how much time spend on each part of ceph when
running it. i just want to see which part of ceph codes spend more
time or have larger cost.
i tried to config ceph adding -pg, but when i use gprof command, it
said no gmon.out.
i also checked the ceph wiki, the profiling on cpu part do get an
output on time cost. but it does not show details on ceph (how much
time spend on each part).
Thanks,
Sheng
--
Sheng Qiu
Texas A & M University
Room 302 Wisenbaker
email: herbert1984106@gmail.com
College Station, TX 77843-3259
^ permalink raw reply
* Re: [dm-crypt] please HELP - can't acces encrypted LVM after linux reinstallation.
From: ingo.schmitt @ 2011-10-31 3:30 UTC (permalink / raw)
To: dm-crypt
In-Reply-To: <CAP8O3oNnSWO2q5-97XkcpxE-FK7nyyTF1YSSWCf+F+crpr2pEw@mail.gmail.com>
Another idea: Cryptsetup should offer to backup the header
on the same drive when changes to an existing header are requested.
I assume that headers size isn't an issue.
Thx,
Ingo
On 10/31/2011 01:30 AM, Aleksander Swirski wrote:
> I'm pretty sure this warning is only displayed when someone decides to
> create new crypto on some partition or fill encrypted device with random
> data in the next step after setting the password. but just setting the
> password on an existing device makes data unusable without warning. when
> the partitioning is finished there is a list of partitions that will be
> wiped out, and also, during my installation crypto-deviced and /home
> inside LVM was not listed there, but already lost few clicks earlier.
>
> i understand that it wasn't taken into consideration that someone can
> attach existing encrypted device, but only that a new one will be
> created. this is inconsistent with how it goes with unencrypted
> partitions, where you can reattach them without formatting and keep your
> data. so i guess with encrypted partition this should also work that
> way. or maybe i miss the point? i will try to make the whole scenario
> clear, and then send my proposition, to debian-boot@lists.debian.org
> <mailto:debian-boot@lists.debian.org>
>
> On 30 October 2011 23:25, Jonas Meurer <jonas@freesources.org
> <mailto:jonas@freesources.org>> wrote:
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Hi Aleksander,
>
> Am 30.10.2011 19:56, schrieb Aleksander Swirski:
> > I will also try to push this info to the debian devs. I'm not sure
> > how to do that properly (hint appreciated). I know, that the route
> > of installation I took is not a common one, but a simple warning
> > would suffice to avoid this kind of trouble. After all my encrypted
> > LVM and specifically the /home partition within LVM wasn't listed
> > among those, which are to be erased at any point during the
> > installation. (I marked them with - K - keep the data)
>
> I guess that you selected to configure the device which contained the
> LVM volume group as new encrypted device. Then you where asked for the
> new passphrase twice, and a new LUKS header was written to the device,
> overwriting the old LUKS header. That way you shredded all the
> encrypted data on that device, regardless what it was.
>
> The partitions you marked as "keep the data" weren't overwritten, just
> the LUKS header of underlying device was overwritten.
>
> I agree, that a warning in the Debian Installer is a good idea, but to
> be honest, there's already a big fat warning:
>
> > _Description: Really erase the data on ${DEVICE}? The data on
> > ${DEVICE} will be overwritten with random data. It can no longer be
> > recovered after this step has completed. This is the last
> > opportunity to abort the erase.
>
> (from
> http://anonscm.debian.org/gitweb/?p=d-i/partman-crypto.git;a=blob;f=debian/partman-crypto.templates)
>
> If you like to propose changes to the (warnings in the) process of
> configuring encrypted volumes during installation of Debian, feel free
> to discuss this on debian-boot@lists.debian.org
> <mailto:debian-boot@lists.debian.org>. You might as well
> take a look at the following page:
> http://wiki.debian.org/DebianInstaller/PartmanCrypto
>
> Greetings,
> jonas
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.11 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
>
> iQIcBAEBAgAGBQJOrc7tAAoJEFJi5/9JEEn+bo4P/0vX3AxnpXzWO3NUvYW2wh6H
> k7v8Dhx6Rw5HXttHuF8JSypkvcHuLfWyGLq0J4qlsw4GvK/cPtwdCuSe//uJvqSB
> 4Z6qj55E/3/M+aEBMzT9oBeZ5DVGPp0+76VWFNijGzHYMoT4YYm0pZBsmfZ7U2RJ
> +7xFyGP0d7oXJIqoW8aUyufgdYnRNdcZdJtY27XHgKW1m9ytllIuK0h7hl410/L0
> vy2t4IqSlO5Uko1/bOf3FETNkBRTUl4T2jWMP3dEpNMRobB1ZH5I5menXWSwzgR9
> c2QWRkwQ8iUsAdakofnl9O1jhtw3Z9MKxHQbnxh32oNuS5Aaf5xxfiI7jXf3yY/L
> GUKyIOa5nGtNtwUt4l0RTJAKoyY2J2KtBJm+JL51tQ3q/iyZsfRLVmyczlkzKUhj
> vMKgSzhV8/IyQ/snqftAMqmRXYgaOE3qDCe8MR+EChIFwX2Zr+eRWdRzVFDjQ0kP
> Cyc6Yw3TrthD8GuWWxU93tE3YMVxgI76+lDk/LBLZjviMTEfkR5e+gmuoff+Xdta
> aBYek7loOjkqb+gJ6qeqAKuDLAZnw/BmHfgpYQpatdSeiV6jpGPkGMbYTwDHLlXR
> rE72FJe1emdcDWQ6TE8SP+6KW22HirBPD5q6DPqJ2Oxcxx+AotXeLvDpnhd9S5b2
> fDNHacCUklPyCeH81nsH
> =PLsS
> -----END PGP SIGNATURE-----
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de <mailto:dm-crypt@saout.de>
> http://www.saout.de/mailman/listinfo/dm-crypt
>
>
>
>
> _______________________________________________
> dm-crypt mailing list
> dm-crypt@saout.de
> http://www.saout.de/mailman/listinfo/dm-crypt
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
From: Alexander Graf @ 2011-10-31 3:35 UTC (permalink / raw)
To: David Gibson; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-4-git-send-email-david@gibson.dropbear.id.au>
On 31.10.2011, at 04:16, David Gibson wrote:
> From: Nishanth Aravamudan <nacc@us.ibm.com>
>
> When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
> qemu monitor reports "dump_mmu: unimplemented". However, during
> bringup work, it can be quite handy to have the SLB entries, which are
> available in the CPUPPCState. This patch adds an implementation of
> info tlb for book3s, which dumps the SLB.
>
> Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
> Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> ---
> target-ppc/helper.c | 32 +++++++++++++++++++++++++++-----
> 1 files changed, 27 insertions(+), 5 deletions(-)
>
> diff --git a/target-ppc/helper.c b/target-ppc/helper.c
> index 137a494..29c7050 100644
> --- a/target-ppc/helper.c
> +++ b/target-ppc/helper.c
> @@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> }
> }
>
> +static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
> + CPUState *env)
> +{
> + int i;
> + uint64_t slbe, slbv;
> +
> + cpu_synchronize_state(env);
> +
> + cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
> + for (i = 0; i < env->slb_nr; i++) {
> + slbe = env->slb[i].esid;
> + slbv = env->slb[i].vsid;
From cpu.h:
#if defined(TARGET_PPC64)
/* Address space register */
target_ulong asr;
/* PowerPC 64 SLB area */
ppc_slb_t slb[64];
int slb_nr;
#endif
> + if (slbe == 0 && slbv == 0) {
> + continue;
> + }
> + cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
> + i, slbe, slbv);
> + }
> +}
> +
> void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
> {
> - switch (env->mmu_model) {
> - case POWERPC_MMU_BOOKE206:
> + if (env->mmu_model == POWERPC_MMU_BOOKE206) {
> mmubooke206_dump_mmu(f, cpu_fprintf, env);
> - break;
> - default:
> - cpu_fprintf(f, "%s: unimplemented\n", __func__);
> + } else {
> + if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
I would actually prefer to explicitly keep the switch and match on all implementations explicitly. Also, have you verified this works without CONFIG_PPC64 set? In cpu.h I see the following:
#if defined(TARGET_PPC64)
#define POWERPC_MMU_64 0x00010000
#define POWERPC_MMU_1TSEG 0x00020000
/* 64 bits PowerPC MMU */
POWERPC_MMU_64B = POWERPC_MMU_64 | 0x00000001,
/* 620 variant (no segment exceptions) */
POWERPC_MMU_620 = POWERPC_MMU_64 | 0x00000002,
/* Architecture 2.06 variant */
POWERPC_MMU_2_06 = POWERPC_MMU_64 | POWERPC_MMU_1TSEG | 0x00000003,
#endif /* defined(TARGET_PPC64) */
So POWERPC_MMU_64B shouldn't be defined for qemu-system-ppc.
Alex
^ permalink raw reply
* [Qemu-devel] [PATCH v2] trace: Add wildcard trace event support
From: Mark Wu @ 2011-10-31 3:29 UTC (permalink / raw)
To: Stefan Hajnoczi; +Cc: qemu-devel
A basic wildcard matching is supported in both the monitor command
"trace-event" and the events list file. That means you can enable/disable
the events having a common prefix in a batch. For example, virtio-blk trace
events could be enabled using:
trace-event virtio_blk_* on
Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
---
docs/tracing.txt | 9 ++++++++-
net/queue.c | 1 +
trace/simple.c | 19 +++++++++++++++++--
trace/stderr.c | 17 ++++++++++++++++-
4 files changed, 42 insertions(+), 4 deletions(-)
diff --git a/docs/tracing.txt b/docs/tracing.txt
index 95ca16c..ea29f2c 100644
--- a/docs/tracing.txt
+++ b/docs/tracing.txt
@@ -132,12 +132,19 @@ This functionality is also provided through monitor commands:
means disabled.
* trace-event NAME on|off
- Enable/disable a given trace event.
+ Enable/disable a given trace event or a group of events having common prefix
+ through wildcard.
The "-trace events=<file>" command line argument can be used to enable the
events listed in <file> from the very beginning of the program. This file must
contain one event name per line.
+A basic wildcard matching is supported in both the monitor command "trace
+-event" and the events list file. That means you can enable/disable the events
+having a common prefix in a batch. For example, virtio-blk trace events could
+be enabled using:
+ trace-event virtio_blk_* on
+
== Trace backends ==
The "tracetool" script automates tedious trace event code generation and also
diff --git a/net/queue.c b/net/queue.c
index 1ab5247..41ffda8 100644
--- a/net/queue.c
+++ b/net/queue.c
@@ -258,3 +258,4 @@ void qemu_net_queue_flush(NetQueue *queue)
g_free(packet);
}
}
+/* */
diff --git a/trace/simple.c b/trace/simple.c
index b639dda..6339152 100644
--- a/trace/simple.c
+++ b/trace/simple.c
@@ -324,14 +324,29 @@ void trace_print_events(FILE *stream, fprintf_function stream_printf)
bool trace_event_set_state(const char *name, bool state)
{
unsigned int i;
-
+ unsigned int len;
+ bool wildcard = false;
+ bool matched = false;
+
+ len = strlen(name);
+ if (len > 0 && name[len - 1] == '*') {
+ wildcard = true;
+ len -= 1;
+ }
for (i = 0; i < NR_TRACE_EVENTS; i++) {
+ if (wildcard) {
+ if (!strncmp(trace_list[i].tp_name, name, len)) {
+ trace_list[i].state = state;
+ matched = true;
+ }
+ continue;
+ }
if (!strcmp(trace_list[i].tp_name, name)) {
trace_list[i].state = state;
return true;
}
}
- return false;
+ return matched;
}
/* Helper function to create a thread with signals blocked. Use glib's
diff --git a/trace/stderr.c b/trace/stderr.c
index 7107c4a..0810d6f 100644
--- a/trace/stderr.c
+++ b/trace/stderr.c
@@ -15,14 +15,29 @@ void trace_print_events(FILE *stream, fprintf_function stream_printf)
bool trace_event_set_state(const char *name, bool state)
{
unsigned int i;
+ unsigned int len;
+ bool wildcard = false;
+ bool matched = false;
+ len = strlen(name);
+ if (len > 0 && name[len - 1] == '*') {
+ wildcard = true;
+ len -= 1;
+ }
for (i = 0; i < NR_TRACE_EVENTS; i++) {
+ if (wildcard) {
+ if (!strncmp(trace_list[i].tp_name, name, len)) {
+ trace_list[i].state = state;
+ matched = true;
+ }
+ continue;
+ }
if (!strcmp(trace_list[i].tp_name, name)) {
trace_list[i].state = state;
return true;
}
}
- return false;
+ return matched;
}
bool trace_backend_init(const char *events, const char *file)
--
1.7.1
^ permalink raw reply related
* Re: [PATCH v5] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-10-31 3:21 UTC (permalink / raw)
To: Barry Song
Cc: Arnd Bergmann, Jassi Brar, Linus Walleij, linux-kernel,
workgroup.linux, Rongjun Ying, Barry Song, linux-arm-kernel
In-Reply-To: <1319768559-24200-1-git-send-email-Barry.Song@csr.com>
On Thu, 2011-10-27 at 19:22 -0700, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying@csr.com>
>
> Cc: Jassi Brar <jaswinder.singh@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> -v5:
> fix checkpatch issues;
> fix compile warinings;
> Note: This tree
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git prima2-dma-for-Vinod
> merge both slave_dma interleaved branch and prima2 defconfig.
Applied thanks.
I will merge these after merging direction fixes.
--
~Vinod
^ permalink raw reply
* [PATCH v5] dmaengine: add CSR SiRFprimaII DMAC driver
From: Vinod Koul @ 2011-10-31 3:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <1319768559-24200-1-git-send-email-Barry.Song@csr.com>
On Thu, 2011-10-27 at 19:22 -0700, Barry Song wrote:
> From: Rongjun Ying <Rongjun.Ying@csr.com>
>
> Cc: Jassi Brar <jaswinder.singh@linaro.org>
> Cc: Arnd Bergmann <arnd@arndb.de>
> Cc: Linus Walleij <linus.walleij@linaro.org>
> Signed-off-by: Rongjun Ying <rongjun.ying@csr.com>
> Signed-off-by: Barry Song <Baohua.Song@csr.com>
> ---
> -v5:
> fix checkpatch issues;
> fix compile warinings;
> Note: This tree
> git://gitorious.org/sirfprima2-kernel/sirfprima2-kernel.git prima2-dma-for-Vinod
> merge both slave_dma interleaved branch and prima2 defconfig.
Applied thanks.
I will merge these after merging direction fixes.
--
~Vinod
^ permalink raw reply
* [U-Boot] [PATCH 2/6] mx53evk: Remove unused get_board_rev function
From: Jason Liu @ 2011-10-31 3:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-2-git-send-email-fabio.estevam@freescale.com>
2011/10/27 Fabio Estevam <fabio.estevam@freescale.com>:
> No board information is passed for MX53EVK, so remove get_board_rev function.
>
> Cc: Jason Liu <r64343@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> ?board/freescale/mx53evk/mx53evk.c | ? ?5 -----
> ?include/configs/mx53evk.h ? ? ? ? | ? ?1 -
> ?2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/board/freescale/mx53evk/mx53evk.c b/board/freescale/mx53evk/mx53evk.c
> index eab9c5f..335661f 100644
> --- a/board/freescale/mx53evk/mx53evk.c
> +++ b/board/freescale/mx53evk/mx53evk.c
> @@ -39,11 +39,6 @@
>
> ?DECLARE_GLOBAL_DATA_PTR;
>
> -u32 get_board_rev(void)
> -{
> - ? ? ? return get_cpu_rev();
> -}
> -
> ?int dram_init(void)
> ?{
> ? ? ? ?/* dram_init must store complete ramsize in gd->ram_size */
> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
> index a5d403f..f9fc149 100644
> --- a/include/configs/mx53evk.h
> +++ b/include/configs/mx53evk.h
> @@ -34,7 +34,6 @@
> ?#include <asm/arch/imx-regs.h>
>
> ?#define CONFIG_CMDLINE_TAG ? ? ? ? ? ? ? ? ? ? /* enable passing of ATAGs */
> -#define CONFIG_REVISION_TAG
> ?#define CONFIG_SETUP_MEMORY_TAGS
> ?#define CONFIG_INITRD_TAG
>
Acked-by: Jason Liu <r64343@freescale.com>
> --
> 1.7.1
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [U-Boot] [PATCH 5/6] mx53loco: Remove unused get_board_rev function
From: Jason Liu @ 2011-10-31 3:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319714985-26088-5-git-send-email-fabio.estevam@freescale.com>
2011/10/27 Fabio Estevam <fabio.estevam@freescale.com>:
> No board information is passed for MX53LOCO, so remove get_board_rev function.
>
> Cc: Jason Liu <r64343@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> ?board/freescale/mx53loco/mx53loco.c | ? ?5 -----
> ?include/configs/mx53loco.h ? ? ? ? ?| ? ?1 -
> ?2 files changed, 0 insertions(+), 6 deletions(-)
>
> diff --git a/board/freescale/mx53loco/mx53loco.c b/board/freescale/mx53loco/mx53loco.c
> index 156f8b5..b4c7f33 100644
> --- a/board/freescale/mx53loco/mx53loco.c
> +++ b/board/freescale/mx53loco/mx53loco.c
> @@ -38,11 +38,6 @@
>
> ?DECLARE_GLOBAL_DATA_PTR;
>
> -u32 get_board_rev(void)
> -{
> - ? ? ? return get_cpu_rev();
> -}
> -
> ?int dram_init(void)
> ?{
> ? ? ? ?u32 size1, size2;
> diff --git a/include/configs/mx53loco.h b/include/configs/mx53loco.h
> index f35bac1..d699010 100644
> --- a/include/configs/mx53loco.h
> +++ b/include/configs/mx53loco.h
> @@ -35,7 +35,6 @@
> ?#include <asm/arch/imx-regs.h>
>
> ?#define CONFIG_CMDLINE_TAG
> -#define CONFIG_REVISION_TAG
> ?#define CONFIG_SETUP_MEMORY_TAGS
> ?#define CONFIG_INITRD_TAG
Acked-by: Jason Liu <r64343@freescale.com>
BR,
Jason
>
> --
> 1.7.1
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* Re: Re: HT (Hyper Threading) aware process scheduling doesn't work as it should
From: Yong Zhang @ 2011-10-31 3:19 UTC (permalink / raw)
To: Artem S. Tashkinov; +Cc: arjan, linux-kernel, Ingo Molnar, Peter Zijlstra
In-Reply-To: <1179048211.51348.1320013764432.JavaMail.mail@webmail17>
On Sun, Oct 30, 2011 at 10:29:23PM +0000, Artem S. Tashkinov wrote:
> > On Oct 31, 2011, Arjan van de Ven wrote:
> >
> > On Sun, 30 Oct 2011 19:57:12 +0000 (GMT)
> > "Artem S. Tashkinov" wrote:
> >
> > > Hello,
> > >
> > > It's known that if you want to reach maximum performance on HT
> > > enabled Intel CPUs you should distribute the load evenly between
> > > physical cores, and when you have loaded all of them you should then
> > > load the remaining virtual cores.
> >
> > this is a bold statement, and patently false if you have to threads of
> > one process that heavily share data between eachother...
> > (but true for more independent workloads)
>
> In my initial message I was talking about completely unrelated tasks/
> processes which share no data/instructions/whatever else. You don't
> need to trust my test case as you can carry out this test on your own.
(Cc'ing more people)
Maybe you can also show your test case here?
Thanks,
Yong
^ permalink raw reply
* [Qemu-devel] [PATCH 2/3] pseries: Add partial support for PCI
From: David Gibson @ 2011-10-31 3:16 UTC (permalink / raw)
To: agraf; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-1-git-send-email-david@gibson.dropbear.id.au>
This patch adds a PCI bus to the pseries machine. This instantiates
the qemu generic PCI bus code, advertises a PCI host bridge in the
guest's device tree and implements the RTAS methods specified by PAPR
to access PCI config space. It also sets up the memory regions we
need to provide windows into the PCI memory and IO space, and
advertises those to the guest.
However, because qemu can't yet emulate an IOMMU, which is mandatory on
pseries, PCI devices which use DMA (i.e. most of them) will not work with
this code alone. Still, this is enough to support the virtio_pci device
(which probably _should_ use emulated PCI DMA, but is specced to use
direct hypervisor access to guest physical memory instead).
Signed-off-by: Alexey Kardashevskiy <aik@au1.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
Makefile.target | 1 +
hw/spapr.c | 36 ++++-
hw/spapr.h | 2 +
hw/spapr_pci.c | 508 +++++++++++++++++++++++++++++++++++++++++++++++++++++++
hw/spapr_pci.h | 59 +++++++
5 files changed, 602 insertions(+), 4 deletions(-)
create mode 100644 hw/spapr_pci.c
create mode 100644 hw/spapr_pci.h
diff --git a/Makefile.target b/Makefile.target
index fe5f6f7..2329df5 100644
--- a/Makefile.target
+++ b/Makefile.target
@@ -248,6 +248,7 @@ obj-ppc-y += ppc_newworld.o
# IBM pSeries (sPAPR)
obj-ppc-$(CONFIG_PSERIES) += spapr.o spapr_hcall.o spapr_rtas.o spapr_vio.o
obj-ppc-$(CONFIG_PSERIES) += xics.o spapr_vty.o spapr_llan.o spapr_vscsi.o
+obj-ppc-$(CONFIG_PSERIES) += spapr_pci.o device-hotplug.o pci-hotplug.o
# PowerPC 4xx boards
obj-ppc-y += ppc4xx_devs.o ppc4xx_pci.o ppc405_uc.o ppc405_boards.o
obj-ppc-y += ppc440.o ppc440_bamboo.o
diff --git a/hw/spapr.c b/hw/spapr.c
index 933af32..bdaa938 100644
--- a/hw/spapr.c
+++ b/hw/spapr.c
@@ -39,10 +39,12 @@
#include "hw/spapr.h"
#include "hw/spapr_vio.h"
+#include "hw/spapr_pci.h"
#include "hw/xics.h"
#include "kvm.h"
#include "kvm_ppc.h"
+#include "pci.h"
#include "exec-memory.h"
@@ -62,6 +64,11 @@
#define MAX_CPUS 256
#define XICS_IRQS 1024
+#define SPAPR_PCI_BUID 0x800000020000001ULL
+#define SPAPR_PCI_MEM_WIN_ADDR (0x10000000000ULL + 0xA0000000)
+#define SPAPR_PCI_MEM_WIN_SIZE 0x20000000
+#define SPAPR_PCI_IO_WIN_ADDR (0x10000000000ULL + 0x80000000)
+
#define PHANDLE_XICP 0x00001111
sPAPREnvironment *spapr;
@@ -146,6 +153,14 @@ static void *spapr_create_fdt_skel(const char *cpu_model,
&end_prop, sizeof(end_prop))));
_FDT((fdt_property_string(fdt, "qemu,boot-device", boot_device)));
+ /*
+ * Because we don't always invoke any firmware, we can't rely on
+ * that to do BAR allocation. Long term, we should probably do
+ * that ourselves, but for now, this setting (plus advertising the
+ * current BARs as 0) causes sufficiently recent kernels to to the
+ * BAR assignment themselves */
+ _FDT((fdt_property_cell(fdt, "linux,pci-probe-only", 0)));
+
_FDT((fdt_end_node(fdt)));
/* memory node(s) */
@@ -308,6 +323,7 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
{
int ret;
void *fdt;
+ sPAPRPHBState *phb;
fdt = g_malloc(FDT_MAX_SIZE);
@@ -320,6 +336,15 @@ static void spapr_finalize_fdt(sPAPREnvironment *spapr,
exit(1);
}
+ QLIST_FOREACH(phb, &spapr->phbs, list) {
+ ret = spapr_populate_pci_devices(phb, PHANDLE_XICP, fdt);
+ }
+
+ if (ret < 0) {
+ fprintf(stderr, "couldn't setup PCI devices in fdt\n");
+ exit(1);
+ }
+
/* RTAS */
ret = spapr_rtas_device_tree_setup(fdt, rtas_addr, rtas_size);
if (ret < 0) {
@@ -478,6 +503,12 @@ static void ppc_spapr_init(ram_addr_t ram_size,
}
}
+ /* Set up PCI */
+ spapr_create_phb(spapr, "pci", SPAPR_PCI_BUID,
+ SPAPR_PCI_MEM_WIN_ADDR,
+ SPAPR_PCI_MEM_WIN_SIZE,
+ SPAPR_PCI_IO_WIN_ADDR);
+
for (i = 0; i < nb_nics; i++) {
NICInfo *nd = &nd_table[i];
@@ -488,10 +519,7 @@ static void ppc_spapr_init(ram_addr_t ram_size,
if (strcmp(nd->model, "ibmveth") == 0) {
spapr_vlan_create(spapr->vio_bus, 0x1000 + i, nd);
} else {
- fprintf(stderr, "pSeries (sPAPR) platform does not support "
- "NIC model '%s' (only ibmveth is supported)\n",
- nd->model);
- exit(1);
+ pci_nic_init_nofail(&nd_table[i], nd->model, NULL);
}
}
diff --git a/hw/spapr.h b/hw/spapr.h
index 6657c33..df88f6a 100644
--- a/hw/spapr.h
+++ b/hw/spapr.h
@@ -4,10 +4,12 @@
#include "hw/xics.h"
struct VIOsPAPRBus;
+struct sPAPRPHBState;
struct icp_state;
typedef struct sPAPREnvironment {
struct VIOsPAPRBus *vio_bus;
+ QLIST_HEAD(, sPAPRPHBState) phbs;
struct icp_state *icp;
target_phys_addr_t ram_limit;
diff --git a/hw/spapr_pci.c b/hw/spapr_pci.c
new file mode 100644
index 0000000..2a5e637
--- /dev/null
+++ b/hw/spapr_pci.c
@@ -0,0 +1,508 @@
+/*
+ * QEMU sPAPR PCI host originated from Uninorth PCI host
+ *
+ * Copyright (c) 2011 Alexey Kardashevskiy, IBM Corporation.
+ * Copyright (C) 2011 David Gibson, IBM Corporation.
+ *
+ * Permission is hereby granted, free of charge, to any person obtaining a copy
+ * of this software and associated documentation files (the "Software"), to deal
+ * in the Software without restriction, including without limitation the rights
+ * to use, copy, modify, merge, publish, distribute, sublicense, and/or sell
+ * copies of the Software, and to permit persons to whom the Software is
+ * furnished to do so, subject to the following conditions:
+ *
+ * The above copyright notice and this permission notice shall be included in
+ * all copies or substantial portions of the Software.
+ *
+ * THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR
+ * IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
+ * FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
+ * THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
+ * LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM,
+ * OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN
+ * THE SOFTWARE.
+ */
+#include "hw.h"
+#include "pci.h"
+#include "pci_host.h"
+#include "hw/spapr.h"
+#include "hw/spapr_pci.h"
+#include "exec-memory.h"
+#include <libfdt.h>
+
+#include "hw/pci_internals.h"
+
+static const uint32_t bars[] = {
+ PCI_BASE_ADDRESS_0, PCI_BASE_ADDRESS_1,
+ PCI_BASE_ADDRESS_2, PCI_BASE_ADDRESS_3,
+ PCI_BASE_ADDRESS_4, PCI_BASE_ADDRESS_5
+ /*, PCI_ROM_ADDRESS*/
+};
+
+static PCIDevice *find_dev(sPAPREnvironment *spapr,
+ uint64_t buid, uint32_t config_addr)
+{
+ DeviceState *qdev;
+ int devfn = (config_addr >> 8) & 0xFF;
+ sPAPRPHBState *phb;
+
+ QLIST_FOREACH(phb, &spapr->phbs, list) {
+ if (phb->buid != buid) {
+ continue;
+ }
+
+ QLIST_FOREACH(qdev, &phb->host_state.bus->qbus.children, sibling) {
+ PCIDevice *dev = (PCIDevice *)qdev;
+ if (dev->devfn == devfn) {
+ return dev;
+ }
+ }
+ }
+
+ return NULL;
+}
+
+static void rtas_ibm_read_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ uint64_t buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
+ PCIDevice *dev = find_dev(spapr, buid, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ size = rtas_ld(args, 3);
+ addr = rtas_ld(args, 0) & 0xFF;
+ val = pci_default_read_config(dev, addr, size);
+ rtas_st(rets, 0, 0);
+ rtas_st(rets, 1, val);
+}
+
+static void rtas_read_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ PCIDevice *dev = find_dev(spapr, 0, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ size = rtas_ld(args, 1);
+ addr = rtas_ld(args, 0) & 0xFF;
+ val = pci_default_read_config(dev, addr, size);
+ rtas_st(rets, 0, 0);
+ rtas_st(rets, 1, val);
+}
+
+static void rtas_ibm_write_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ uint64_t buid = ((uint64_t)rtas_ld(args, 1) << 32) | rtas_ld(args, 2);
+ PCIDevice *dev = find_dev(spapr, buid, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ val = rtas_ld(args, 4);
+ size = rtas_ld(args, 3);
+ addr = rtas_ld(args, 0) & 0xFF;
+ pci_default_write_config(dev, addr, val, size);
+ rtas_st(rets, 0, 0);
+}
+
+static void rtas_write_pci_config(sPAPREnvironment *spapr,
+ uint32_t token, uint32_t nargs,
+ target_ulong args,
+ uint32_t nret, target_ulong rets)
+{
+ uint32_t val, size, addr;
+ PCIDevice *dev = find_dev(spapr, 0, rtas_ld(args, 0));
+
+ if (!dev) {
+ rtas_st(rets, 0, -1);
+ return;
+ }
+ val = rtas_ld(args, 2);
+ size = rtas_ld(args, 1);
+ addr = rtas_ld(args, 0) & 0xFF;
+ pci_default_write_config(dev, addr, val, size);
+ rtas_st(rets, 0, 0);
+}
+
+static int pci_spapr_map_irq(PCIDevice *pci_dev, int irq_num)
+{
+ /*
+ * Here we need to convert pci_dev + irq_num to some unique value
+ * which is less than number of IRQs on the specific bus (now it
+ * is 16). At the moment irq_num == device_id (number of the
+ * slot?)
+ * FIXME: we should swizzle in fn and irq_num
+ */
+ return (pci_dev->devfn >> 3) % SPAPR_PCI_NUM_LSI;
+}
+
+static void pci_spapr_set_irq(void *opaque, int irq_num, int level)
+{
+ /*
+ * Here we use the number returned by pci_spapr_map_irq to find a
+ * corresponding qemu_irq.
+ */
+ sPAPRPHBState *phb = opaque;
+
+ qemu_set_irq(phb->lsi_table[irq_num].qirq, level);
+}
+
+static int spapr_phb_init(SysBusDevice *s)
+{
+ sPAPRPHBState *phb = FROM_SYSBUS(sPAPRPHBState, s);
+ int i;
+
+ /* Initialize the LSI table */
+ for (i = 0; i < SPAPR_PCI_NUM_LSI; i++) {
+ qemu_irq qirq;
+ uint32_t num;
+
+ qirq = spapr_allocate_irq(0, &num);
+ if (!qirq) {
+ return -1;
+ }
+
+ phb->lsi_table[i].dt_irq = num;
+ phb->lsi_table[i].qirq = qirq;
+ }
+
+ return 0;
+}
+
+static int spapr_main_pci_host_init(PCIDevice *d)
+{
+ return 0;
+}
+
+static PCIDeviceInfo spapr_main_pci_host_info = {
+ .qdev.name = "spapr-pci-host-bridge",
+ .qdev.size = sizeof(PCIDevice),
+ .init = spapr_main_pci_host_init,
+};
+
+static void spapr_register_devices(void)
+{
+ sysbus_register_dev("spapr-pci-host-bridge", sizeof(sPAPRPHBState),
+ spapr_phb_init);
+ pci_qdev_register(&spapr_main_pci_host_info);
+}
+
+device_init(spapr_register_devices)
+
+static uint64_t spapr_io_read(void *opaque, target_phys_addr_t addr,
+ unsigned size)
+{
+ switch (size) {
+ case 1:
+ return cpu_inb(addr);
+ case 2:
+ return cpu_inw(addr);
+ case 4:
+ return cpu_inl(addr);
+ }
+ assert(0);
+}
+
+static void spapr_io_write(void *opaque, target_phys_addr_t addr,
+ uint64_t data, unsigned size)
+{
+ switch (size) {
+ case 1:
+ cpu_outb(addr, data);
+ return;
+ case 2:
+ cpu_outw(addr, data);
+ return;
+ case 4:
+ cpu_outl(addr, data);
+ return;
+ }
+ assert(0);
+}
+
+static MemoryRegionOps spapr_io_ops = {
+ .endianness = DEVICE_LITTLE_ENDIAN,
+ .read = spapr_io_read,
+ .write = spapr_io_write
+};
+
+void spapr_create_phb(sPAPREnvironment *spapr,
+ const char *busname, uint64_t buid,
+ uint64_t mem_win_addr, uint64_t mem_win_size,
+ uint64_t io_win_addr)
+{
+ DeviceState *dev;
+ SysBusDevice *s;
+ sPAPRPHBState *phb;
+ PCIBus *bus;
+ char namebuf[strlen(busname)+11];
+
+ dev = qdev_create(NULL, "spapr-pci-host-bridge");
+ qdev_init_nofail(dev);
+ s = sysbus_from_qdev(dev);
+ phb = FROM_SYSBUS(sPAPRPHBState, s);
+
+ phb->mem_win_addr = mem_win_addr;
+
+ sprintf(namebuf, "%s-mem", busname);
+ memory_region_init(&phb->memspace, namebuf, INT64_MAX);
+
+ sprintf(namebuf, "%s-memwindow", busname);
+ memory_region_init_alias(&phb->memwindow, namebuf, &phb->memspace,
+ SPAPR_PCI_MEM_WIN_BUS_OFFSET, mem_win_size);
+ memory_region_add_subregion(get_system_memory(), mem_win_addr,
+ &phb->memwindow);
+
+ phb->io_win_addr = io_win_addr;
+
+ /* On ppc, we only have MMIO no specific IO space from the CPU
+ * perspective. In theory we ought to be able to embed the PCI IO
+ * memory region direction in the system memory space. However,
+ * if any of the IO BAR subregions use the old_portio mechanism,
+ * that won't be processed properly unless accessed from the
+ * system io address space. This hack to bounce things via
+ * system_io works around the problem until all the users of
+ * old_portion are updated */
+ sprintf(namebuf, "%s-io", busname);
+ memory_region_init(&phb->iospace, namebuf, SPAPR_PCI_IO_WIN_SIZE);
+ /* FIXME: fix to support multiple PHBs */
+ memory_region_add_subregion(get_system_io(), 0, &phb->iospace);
+
+ sprintf(namebuf, "%s-iowindow", busname);
+ memory_region_init_io(&phb->iowindow, &spapr_io_ops, phb,
+ namebuf, SPAPR_PCI_IO_WIN_SIZE);
+ memory_region_add_subregion(get_system_memory(), io_win_addr,
+ &phb->iowindow);
+
+ phb->host_state.bus = bus = pci_register_bus(&phb->busdev.qdev, busname,
+ pci_spapr_set_irq,
+ pci_spapr_map_irq,
+ phb,
+ &phb->memspace, &phb->iospace,
+ PCI_DEVFN(0, 0),
+ SPAPR_PCI_NUM_LSI);
+
+ spapr_rtas_register("read-pci-config", rtas_read_pci_config);
+ spapr_rtas_register("write-pci-config", rtas_write_pci_config);
+ spapr_rtas_register("ibm,read-pci-config", rtas_ibm_read_pci_config);
+ spapr_rtas_register("ibm,write-pci-config", rtas_ibm_write_pci_config);
+
+ QLIST_INSERT_HEAD(&spapr->phbs, phb, list);
+
+ /* pci_bus_set_mem_base(bus, mem_va_start - SPAPR_PCI_MEM_BAR_START); */
+}
+
+/* Macros to operate with address in OF binding to PCI */
+#define b_x(x, p, l) (((x) & ((1<<(l))-1)) << (p))
+#define b_n(x) b_x((x), 31, 1) /* 0 if relocatable */
+#define b_p(x) b_x((x), 30, 1) /* 1 if prefetchable */
+#define b_t(x) b_x((x), 29, 1) /* 1 if the address is aliased */
+#define b_ss(x) b_x((x), 24, 2) /* the space code */
+#define b_bbbbbbbb(x) b_x((x), 16, 8) /* bus number */
+#define b_ddddd(x) b_x((x), 11, 5) /* device number */
+#define b_fff(x) b_x((x), 8, 3) /* function number */
+#define b_rrrrrrrr(x) b_x((x), 0, 8) /* register number */
+
+static uint32_t regtype_to_ss(uint8_t type)
+{
+ if (type & PCI_BASE_ADDRESS_MEM_TYPE_64) {
+ return 3;
+ }
+ if (type == PCI_BASE_ADDRESS_SPACE_IO) {
+ return 1;
+ }
+ return 2;
+}
+
+int spapr_populate_pci_devices(sPAPRPHBState *phb,
+ uint32_t xics_phandle,
+ void *fdt)
+{
+ PCIBus *bus = phb->host_state.bus;
+ int bus_off, node_off = 0, devid, fn, i, n, devices;
+ DeviceState *qdev;
+ char nodename[256];
+ struct {
+ uint32_t hi;
+ uint64_t addr;
+ uint64_t size;
+ } __attribute__((packed)) reg[PCI_NUM_REGIONS + 1],
+ assigned_addresses[PCI_NUM_REGIONS];
+ uint32_t bus_range[] = { cpu_to_be32(0), cpu_to_be32(0xff) };
+ struct {
+ uint32_t hi;
+ uint64_t child;
+ uint64_t parent;
+ uint64_t size;
+ } __attribute__((packed)) ranges[] = {
+ {
+ cpu_to_be32(b_ss(1)), cpu_to_be64(0),
+ cpu_to_be64(phb->io_win_addr),
+ cpu_to_be64(memory_region_size(&phb->iospace)),
+ },
+ {
+ cpu_to_be32(b_ss(2)), cpu_to_be64(SPAPR_PCI_MEM_WIN_BUS_OFFSET),
+ cpu_to_be64(phb->mem_win_addr),
+ cpu_to_be64(memory_region_size(&phb->memwindow)),
+ },
+ };
+ uint64_t bus_reg[] = { cpu_to_be64(phb->buid), 0 };
+ uint32_t interrupt_map_mask[] = {
+ cpu_to_be32(b_ddddd(-1)|b_fff(-1)), 0x0, 0x0, 0x0};
+ uint32_t interrupt_map[bus->nirq][7];
+
+ /* Start populating the FDT */
+ sprintf(nodename, "pci@%" PRIx64, phb->buid);
+ bus_off = fdt_add_subnode(fdt, 0, nodename);
+ if (bus_off < 0) {
+ return bus_off;
+ }
+
+#define _FDT(exp) \
+ do { \
+ int ret = (exp); \
+ if (ret < 0) { \
+ return ret; \
+ } \
+ } while (0)
+
+ /* Write PHB properties */
+ _FDT(fdt_setprop_string(fdt, bus_off, "device_type", "pci"));
+ _FDT(fdt_setprop_string(fdt, bus_off, "compatible", "IBM,Logical_PHB"));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#address-cells", 0x3));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#size-cells", 0x2));
+ _FDT(fdt_setprop_cell(fdt, bus_off, "#interrupt-cells", 0x1));
+ _FDT(fdt_setprop(fdt, bus_off, "used-by-rtas", NULL, 0));
+ _FDT(fdt_setprop(fdt, bus_off, "bus-range", &bus_range, sizeof(bus_range)));
+ _FDT(fdt_setprop(fdt, bus_off, "ranges", &ranges, sizeof(ranges)));
+ _FDT(fdt_setprop(fdt, bus_off, "reg", &bus_reg, sizeof(bus_reg)));
+ _FDT(fdt_setprop(fdt, bus_off, "interrupt-map-mask",
+ &interrupt_map_mask, sizeof(interrupt_map_mask)));
+
+ /* Populate PCI devices and allocate IRQs */
+ devices = 0;
+ QLIST_FOREACH(qdev, &bus->qbus.children, sibling) {
+ PCIDevice *dev = DO_UPCAST(PCIDevice, qdev, qdev);
+ int irq_index = pci_spapr_map_irq(dev, 0);
+ uint32_t *irqmap = interrupt_map[devices];
+ uint8_t *config = dev->config;
+
+ devid = dev->devfn >> 3;
+ fn = dev->devfn & 7;
+
+ sprintf(nodename, "pci@%u,%u", devid, fn);
+
+ /* Allocate interrupt from the map */
+ if (devid > bus->nirq) {
+ printf("Unexpected behaviour in spapr_populate_pci_devices,"
+ "wrong devid %u\n", devid);
+ exit(-1);
+ }
+ irqmap[0] = cpu_to_be32(b_ddddd(devid)|b_fff(fn));
+ irqmap[1] = 0;
+ irqmap[2] = 0;
+ irqmap[3] = 0;
+ irqmap[4] = cpu_to_be32(xics_phandle);
+ irqmap[5] = cpu_to_be32(phb->lsi_table[irq_index].dt_irq);
+ irqmap[6] = cpu_to_be32(0x8);
+
+ /* Add node to FDT */
+ node_off = fdt_add_subnode(fdt, bus_off, nodename);
+ if (node_off < 0) {
+ return node_off;
+ }
+
+ _FDT(fdt_setprop_cell(fdt, node_off, "vendor-id",
+ pci_get_word(&config[PCI_VENDOR_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "device-id",
+ pci_get_word(&config[PCI_DEVICE_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "revision-id",
+ pci_get_byte(&config[PCI_REVISION_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "class-code",
+ pci_get_long(&config[PCI_CLASS_REVISION]) >> 8));
+ _FDT(fdt_setprop_cell(fdt, node_off, "subsystem-id",
+ pci_get_word(&config[PCI_SUBSYSTEM_ID])));
+ _FDT(fdt_setprop_cell(fdt, node_off, "subsystem-vendor-id",
+ pci_get_word(&config[PCI_SUBSYSTEM_VENDOR_ID])));
+
+ /* Config space region comes first */
+ reg[0].hi = cpu_to_be32(
+ b_n(0) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(0/*config*/) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn));
+ reg[0].addr = 0;
+ reg[0].size = 0;
+
+ n = 0;
+ for (i = 0; i < PCI_NUM_REGIONS; ++i) {
+ if (0 == dev->io_regions[i].size) {
+ continue;
+ }
+
+ reg[n+1].hi = cpu_to_be32(
+ b_n(0) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(regtype_to_ss(dev->io_regions[i].type)) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn) |
+ b_rrrrrrrr(bars[i]));
+ reg[n+1].addr = 0;
+ reg[n+1].size = cpu_to_be64(dev->io_regions[i].size);
+
+ assigned_addresses[n].hi = cpu_to_be32(
+ b_n(1) |
+ b_p(0) |
+ b_t(0) |
+ b_ss(regtype_to_ss(dev->io_regions[i].type)) |
+ b_bbbbbbbb(0) |
+ b_ddddd(devid) |
+ b_fff(fn) |
+ b_rrrrrrrr(bars[i]));
+
+ /*
+ * Writing zeroes to assigned_addresses causes the guest kernel to
+ * reassign BARs
+ */
+ assigned_addresses[n].addr = cpu_to_be64(dev->io_regions[i].addr);
+ assigned_addresses[n].size = reg[n+1].size;
+
+ ++n;
+ }
+ _FDT(fdt_setprop(fdt, node_off, "reg", reg, sizeof(reg[0])*(n+1)));
+ _FDT(fdt_setprop(fdt, node_off, "assigned-addresses",
+ assigned_addresses,
+ sizeof(assigned_addresses[0])*(n)));
+ _FDT(fdt_setprop_cell(fdt, node_off, "interrupts",
+ pci_get_byte(&config[PCI_INTERRUPT_PIN])));
+
+ ++devices;
+ }
+
+ /* Write interrupt map */
+ _FDT(fdt_setprop(fdt, bus_off, "interrupt-map", &interrupt_map,
+ devices * sizeof(interrupt_map[0])));
+
+ return 0;
+}
diff --git a/hw/spapr_pci.h b/hw/spapr_pci.h
new file mode 100644
index 0000000..4bb8dfb
--- /dev/null
+++ b/hw/spapr_pci.h
@@ -0,0 +1,59 @@
+/*
+ * QEMU SPAPR PCI BUS definitions
+ *
+ * Copyright (c) 2011 Alexey Kardashevskiy <aik@au1.ibm.com>
+ *
+ * This library is free software; you can redistribute it and/or
+ * modify it under the terms of the GNU Lesser General Public
+ * License as published by the Free Software Foundation; either
+ * version 2 of the License, or (at your option) any later version.
+ *
+ * This library 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
+ * Lesser General Public License for more details.
+ *
+ * You should have received a copy of the GNU Lesser General Public
+ * License along with this library; if not, see <http://www.gnu.org/licenses/>.
+ */
+#if !defined(__HW_SPAPR_PCI_H__)
+#define __HW_SPAPR_PCI_H__
+
+#include "hw/pci_host.h"
+#include "hw/xics.h"
+
+typedef struct sPAPREnvironment sPAPREnvironment;
+
+#define SPAPR_PCI_NUM_LSI 16
+
+typedef struct sPAPRPHBState {
+ SysBusDevice busdev;
+ PCIHostState host_state;
+
+ uint64_t buid;
+
+ MemoryRegion memspace, iospace;
+ target_phys_addr_t mem_win_addr, io_win_addr;
+ MemoryRegion memwindow, iowindow;
+
+ struct {
+ uint32_t dt_irq;
+ qemu_irq qirq;
+ } lsi_table[SPAPR_PCI_NUM_LSI];
+
+ QLIST_ENTRY(sPAPRPHBState) list;
+} sPAPRPHBState;
+
+#define SPAPR_PCI_MEM_WIN_BUS_OFFSET 0x80000000ULL
+#define SPAPR_PCI_IO_WIN_SIZE 0x10000
+
+void spapr_create_phb(sPAPREnvironment *spapr,
+ const char *busname, uint64_t buid,
+ uint64_t mem_win_addr, uint64_t mem_win_size,
+ uint64_t io_win_addr);
+
+int spapr_populate_pci_devices(sPAPRPHBState *phb,
+ uint32_t xics_phandle,
+ void *fdt);
+
+#endif /* __HW_SPAPR_PCI_H__ */
--
1.7.7
^ permalink raw reply related
* [Qemu-devel] [PATCH 1/3] ppc: Alter CPU state to mask out TCG unimplemented instructions as appropriate
From: David Gibson @ 2011-10-31 3:16 UTC (permalink / raw)
To: agraf; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-1-git-send-email-david@gibson.dropbear.id.au>
The CPU state contains two bitmaps, initialized from the CPU spec
which describes which instructions are implemented on the CPU. A
couple of bits are defined which cover instructions (VSX and DFP)
which are not currently implemented in TCG. So far, these are only
used to handle the case of -cpu host because a KVM guest can use
the instructions when the host CPU supports them.
However, it's a mild layering violation to simply not include those
bits in the CPU descriptions for those CPUs that do support them,
just because we can't handle them in TCG. This patch corrects the
situation, so that the instruction bits _are_ shown correctly in the
cpu spec table, but are masked out from the cpu state in the non-KVM
case.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
target-ppc/cpu.h | 26 ++++++++++++++++++++++++++
target-ppc/translate_init.c | 20 +++++++++++++++++---
2 files changed, 43 insertions(+), 3 deletions(-)
diff --git a/target-ppc/cpu.h b/target-ppc/cpu.h
index 3ef4eba..e84108c 100644
--- a/target-ppc/cpu.h
+++ b/target-ppc/cpu.h
@@ -1856,6 +1856,30 @@ enum {
/* popcntw and popcntd instructions */
PPC_POPCNTWD = 0x8000000000000000ULL,
+#define PPC_TCG_INSNS (PPC_INSNS_BASE | PPC_POWER | PPC_POWER2 \
+ | PPC_POWER_RTC | PPC_POWER_BR | PPC_64B \
+ | PPC_64BX | PPC_64H | PPC_WAIT | PPC_MFTB \
+ | PPC_602_SPEC | PPC_ISEL | PPC_POPCNTB \
+ | PPC_STRING | PPC_FLOAT | PPC_FLOAT_EXT \
+ | PPC_FLOAT_FSQRT | PPC_FLOAT_FRES \
+ | PPC_FLOAT_FRSQRTE | PPC_FLOAT_FRSQRTES \
+ | PPC_FLOAT_FSEL | PPC_FLOAT_STFIWX \
+ | PPC_ALTIVEC | PPC_SPE | PPC_SPE_SINGLE \
+ | PPC_SPE_DOUBLE | PPC_MEM_TLBIA \
+ | PPC_MEM_TLBIE | PPC_MEM_TLBSYNC \
+ | PPC_MEM_SYNC | PPC_MEM_EIEIO \
+ | PPC_CACHE | PPC_CACHE_ICBI \
+ | PPC_CACHE_DCBZ | PPC_CACHE_DCBZT \
+ | PPC_CACHE_DCBA | PPC_CACHE_LOCK \
+ | PPC_EXTERN | PPC_SEGMENT | PPC_6xx_TLB \
+ | PPC_74xx_TLB | PPC_40x_TLB | PPC_SEGMENT_64B \
+ | PPC_SLBI | PPC_WRTEE | PPC_40x_EXCP \
+ | PPC_405_MAC | PPC_440_SPEC | PPC_BOOKE \
+ | PPC_MFAPIDI | PPC_TLBIVA | PPC_TLBIVAX \
+ | PPC_4xx_COMMON | PPC_40x_ICBT | PPC_RFMCI \
+ | PPC_RFDI | PPC_DCR | PPC_DCRX | PPC_DCRUX \
+ | PPC_POPCNTWD)
+
/* extended type values */
/* BookE 2.06 PowerPC specification */
@@ -1864,6 +1888,8 @@ enum {
PPC2_VSX = 0x0000000000000002ULL,
/* Decimal Floating Point (DFP) */
PPC2_DFP = 0x0000000000000004ULL,
+
+#define PPC_TCG_INSNS2 (PPC2_BOOKE206)
};
/*****************************************************************************/
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 4dfd7f3..854bc65 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -6519,9 +6519,7 @@ static void init_proc_970MP (CPUPPCState *env)
PPC_64B | PPC_ALTIVEC | \
PPC_SEGMENT_64B | PPC_SLBI | \
PPC_POPCNTB | PPC_POPCNTWD)
-/* FIXME: Should also have PPC2_VSX and PPC2_DFP, but we don't
- * implement those in TCG yet */
-#define POWERPC_INSNS2_POWER7 (PPC_NONE)
+#define POWERPC_INSNS2_POWER7 (PPC2_VSX | PPC2_DFP)
#define POWERPC_MSRM_POWER7 (0x800000000204FF36ULL)
#define POWERPC_MMU_POWER7 (POWERPC_MMU_2_06)
#define POWERPC_EXCP_POWER7 (POWERPC_EXCP_POWER7)
@@ -9848,6 +9846,22 @@ int cpu_ppc_register_internal (CPUPPCState *env, const ppc_def_t *def)
env->bus_model = def->bus_model;
env->insns_flags = def->insns_flags;
env->insns_flags2 = def->insns_flags2;
+ if (!kvm_enabled()) {
+ /* TCG doesn't (yet) emulate some groups of instructions that
+ * are implemented on some otherwise supported CPUs (e.g. VSX
+ * and decimal floating point instructions on POWER7). We
+ * remove unsupported instruction groups from the cpu state's
+ * instruction masks and hope the guest can cope. For at
+ * least the pseries machine, the unavailability of these
+ * instructions can be advertise to the guest via the device
+ * tree.
+ *
+ * FIXME: we should have a similar masking for CPU features
+ * not accessible under KVM, but so far, there aren't any of
+ * those. */
+ env->insns_flags &= PPC_TCG_INSNS;
+ env->insns_flags2 &= PPC_TCG_INSNS2;
+ }
env->flags = def->flags;
env->bfd_mach = def->bfd_mach;
env->check_pow = def->check_pow;
--
1.7.7
^ permalink raw reply related
* [Qemu-devel] [PATCH 3/3] monitor: add ability to dump SLB entries
From: David Gibson @ 2011-10-31 3:16 UTC (permalink / raw)
To: agraf; +Cc: qemu-ppc, qemu-devel
In-Reply-To: <1320031007-25884-1-git-send-email-david@gibson.dropbear.id.au>
From: Nishanth Aravamudan <nacc@us.ibm.com>
When run with a PPC Book3S (server) CPU Currently 'info tlb' in the
qemu monitor reports "dump_mmu: unimplemented". However, during
bringup work, it can be quite handy to have the SLB entries, which are
available in the CPUPPCState. This patch adds an implementation of
info tlb for book3s, which dumps the SLB.
Signed-off-by: Nishanth Aravamudan <nacc@us.ibm.com>
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
---
target-ppc/helper.c | 32 +++++++++++++++++++++++++++-----
1 files changed, 27 insertions(+), 5 deletions(-)
diff --git a/target-ppc/helper.c b/target-ppc/helper.c
index 137a494..29c7050 100644
--- a/target-ppc/helper.c
+++ b/target-ppc/helper.c
@@ -1545,14 +1545,36 @@ static void mmubooke206_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
}
}
+static void mmubooks_dump_mmu(FILE *f, fprintf_function cpu_fprintf,
+ CPUState *env)
+{
+ int i;
+ uint64_t slbe, slbv;
+
+ cpu_synchronize_state(env);
+
+ cpu_fprintf(f, "SLB\tESID\t\t\tVSID\n");
+ for (i = 0; i < env->slb_nr; i++) {
+ slbe = env->slb[i].esid;
+ slbv = env->slb[i].vsid;
+ if (slbe == 0 && slbv == 0) {
+ continue;
+ }
+ cpu_fprintf(f, "%d\t0x%016" PRIx64 "\t0x%016" PRIx64 "\n",
+ i, slbe, slbv);
+ }
+}
+
void dump_mmu(FILE *f, fprintf_function cpu_fprintf, CPUState *env)
{
- switch (env->mmu_model) {
- case POWERPC_MMU_BOOKE206:
+ if (env->mmu_model == POWERPC_MMU_BOOKE206) {
mmubooke206_dump_mmu(f, cpu_fprintf, env);
- break;
- default:
- cpu_fprintf(f, "%s: unimplemented\n", __func__);
+ } else {
+ if ((env->mmu_model & POWERPC_MMU_64B) != 0) {
+ mmubooks_dump_mmu(f, cpu_fprintf, env);
+ } else {
+ cpu_fprintf(f, "%s: unimplemented\n", __func__);
+ }
}
}
--
1.7.7
^ permalink raw reply related
* [Qemu-devel] [0/3] Further ppc & pseries updates
From: David Gibson @ 2011-10-31 3:16 UTC (permalink / raw)
To: agraf; +Cc: qemu-ppc, qemu-devel
Here are several more updates for the ppc target and the pseries
machine in particular. This obsoletes the earlier copies of the first
two patches I sent today.
The first patch more correctly handles CPU features which are present
on some CPUs we know about, but which are not yet emulated in TCG.
The second adds limited PCI support to the pseries machine (this copy
fixes a compile bug in the previous version that hits with some
compilers). The third adds support for the "info tlb" monitor command
on Book3S ppc cpus.
^ permalink raw reply
* [PATCH v3] drm/i915: Fix recursive calls to unmap
From: Ben Widawsky @ 2011-10-31 3:16 UTC (permalink / raw)
To: intel-gfx; +Cc: Ben Widawsky
After the ILK vt-d workaround patches it became clear that we had
introduced a bug. Chris tracked down the issue to recursive calls to
unmap. This happens because we try to optimize waiting on requests by
calling retire requests after the wait, which may drop the last
reference on an object and end up freeing the object (and then unmap the
object from the gtt).
The solution here is to add a new flag to the call chain which gives the
routines the information they need to possibly defer actions which may
cause us to recurse. A macro has been defined to replace i915_gpu_idle
which defaults to the old behavior.
Kudos to Chris for tracking this one down.
This fixes tests/gem_linear_blits in intel-gpu-tools.
v2: v1 used a global, v2 directly modified the call chain.
v3: As Keith pointed out, v2 changed retirement behavior. While it was
intentional, it wasn't related to the bugfix, and so has been removed.
To do this, changed i915_wait_request to be a macro to assure old
behavior is kept.
Cc: Keith Packard <keithp@keithp.com>
Cc: Chris Wilson <chris@chris-wilson.co.uk>
Reported-by: guang.a.yang@intel.com
Bugzilla: https://bugs.freedesktop.org/show_bug.cgi?id=42180
Signed-off-by: Ben Widawsky <ben@bwidawsk.net>
---
drivers/gpu/drm/i915/i915_drv.h | 9 ++++++---
drivers/gpu/drm/i915/i915_gem.c | 17 +++++++++--------
drivers/gpu/drm/i915/i915_gem_gtt.c | 2 +-
3 files changed, 16 insertions(+), 12 deletions(-)
diff --git a/drivers/gpu/drm/i915/i915_drv.h b/drivers/gpu/drm/i915/i915_drv.h
index 06a37f4..fc3e00c 100644
--- a/drivers/gpu/drm/i915/i915_drv.h
+++ b/drivers/gpu/drm/i915/i915_drv.h
@@ -1180,13 +1180,16 @@ void i915_gem_do_init(struct drm_device *dev,
unsigned long start,
unsigned long mappable_end,
unsigned long end);
-int __must_check i915_gpu_idle(struct drm_device *dev);
+int __must_check i915_gem_gpu_idle(struct drm_device *dev, bool strictly_idle);
+#define i915_gpu_idle(dev) i915_gem_gpu_idle(dev, false)
int __must_check i915_gem_idle(struct drm_device *dev);
int __must_check i915_add_request(struct intel_ring_buffer *ring,
struct drm_file *file,
struct drm_i915_gem_request *request);
-int __must_check i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno);
+int __must_check i915_gem_wait_request(struct intel_ring_buffer *ring,
+ uint32_t seqno,
+ bool defer_retirement);
+#define i915_wait_request(ring, seqno) i915_gem_wait_request(ring, seqno, false)
int i915_gem_fault(struct vm_area_struct *vma, struct vm_fault *vmf);
int __must_check
i915_gem_object_set_to_gtt_domain(struct drm_i915_gem_object *obj,
diff --git a/drivers/gpu/drm/i915/i915_gem.c b/drivers/gpu/drm/i915/i915_gem.c
index 6651c36..3ea017a 100644
--- a/drivers/gpu/drm/i915/i915_gem.c
+++ b/drivers/gpu/drm/i915/i915_gem.c
@@ -1942,8 +1942,9 @@ i915_gem_retire_work_handler(struct work_struct *work)
* request and object lists appropriately for that event.
*/
int
-i915_wait_request(struct intel_ring_buffer *ring,
- uint32_t seqno)
+i915_gem_wait_request(struct intel_ring_buffer *ring,
+ uint32_t seqno,
+ bool defer_retirement)
{
drm_i915_private_t *dev_priv = ring->dev->dev_private;
u32 ier;
@@ -2027,7 +2028,7 @@ i915_wait_request(struct intel_ring_buffer *ring,
* buffer to have made it to the inactive list, and we would need
* a separate wait queue to handle that.
*/
- if (ret == 0)
+ if (ret == 0 && !defer_retirement)
i915_gem_retire_requests_ring(ring);
return ret;
@@ -2172,7 +2173,7 @@ i915_gem_flush_ring(struct intel_ring_buffer *ring,
return 0;
}
-static int i915_ring_idle(struct intel_ring_buffer *ring)
+static int i915_ring_idle(struct intel_ring_buffer *ring, bool defer_retirement)
{
int ret;
@@ -2186,18 +2187,18 @@ static int i915_ring_idle(struct intel_ring_buffer *ring)
return ret;
}
- return i915_wait_request(ring, i915_gem_next_request_seqno(ring));
+ return i915_gem_wait_request(ring, i915_gem_next_request_seqno(ring),
+ defer_retirement);
}
-int
-i915_gpu_idle(struct drm_device *dev)
+int i915_gem_gpu_idle(struct drm_device *dev, bool strictly_idle)
{
drm_i915_private_t *dev_priv = dev->dev_private;
int ret, i;
/* Flush everything onto the inactive list. */
for (i = 0; i < I915_NUM_RINGS; i++) {
- ret = i915_ring_idle(&dev_priv->ring[i]);
+ ret = i915_ring_idle(&dev_priv->ring[i], strictly_idle);
if (ret)
return ret;
}
diff --git a/drivers/gpu/drm/i915/i915_gem_gtt.c b/drivers/gpu/drm/i915/i915_gem_gtt.c
index 6042c5e..b90b547 100644
--- a/drivers/gpu/drm/i915/i915_gem_gtt.c
+++ b/drivers/gpu/drm/i915/i915_gem_gtt.c
@@ -55,7 +55,7 @@ static bool do_idling(struct drm_i915_private *dev_priv)
if (unlikely(dev_priv->mm.gtt->do_idle_maps)) {
dev_priv->mm.interruptible = false;
- if (i915_gpu_idle(dev_priv->dev)) {
+ if (i915_gem_gpu_idle(dev_priv->dev, true)) {
DRM_ERROR("Couldn't idle GPU\n");
/* Wait a bit, in hopes it avoids the hang */
udelay(10);
--
1.7.7.1
^ permalink raw reply related
* [U-Boot] [PATCH v2 1/6] mx53evk: Remove unneeded '1' from mx53evk.h
From: Jason Liu @ 2011-10-31 3:16 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319715163-26173-1-git-send-email-fabio.estevam@freescale.com>
2011/10/27 Fabio Estevam <fabio.estevam@freescale.com>:
> Remove unneeded '1' from mx53evk.h.
>
> Cc: Jason Liu <r64343@freescale.com>
> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
> ---
> Changes since v1:
> - Fix board name in Subject
>
> ?include/configs/mx53evk.h | ? 16 ++++++++--------
> ?1 files changed, 8 insertions(+), 8 deletions(-)
>
> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
> index c1941e3..a5d403f 100644
> --- a/include/configs/mx53evk.h
> +++ b/include/configs/mx53evk.h
> @@ -33,12 +33,12 @@
>
> ?#include <asm/arch/imx-regs.h>
>
> -#define CONFIG_CMDLINE_TAG ? ? ? ? ? ? 1 ? ? ? /* enable passing of ATAGs */
> -#define CONFIG_REVISION_TAG ? ? ? ? ? ?1
> -#define CONFIG_SETUP_MEMORY_TAGS ? ? ? 1
> -#define CONFIG_INITRD_TAG ? ? ? ? ? ? ?1
> +#define CONFIG_CMDLINE_TAG ? ? ? ? ? ? ? ? ? ? /* enable passing of ATAGs */
> +#define CONFIG_REVISION_TAG
> +#define CONFIG_SETUP_MEMORY_TAGS
> +#define CONFIG_INITRD_TAG
>
> -#define CONFIG_OF_LIBFDT ? ? ? ? ? ? ? 1
> +#define CONFIG_OF_LIBFDT
>
> ?/* Size of malloc() pool */
> ?#define CONFIG_SYS_MALLOC_LEN ? ? ? ? ?(CONFIG_ENV_SIZE + 2 * 1024 * 1024)
> @@ -51,9 +51,9 @@
> ?#define CONFIG_SYS_MX53_UART1
>
> ?/* I2C Configs */
> -#define CONFIG_CMD_I2C ? ? ? ? ?1
> -#define CONFIG_HARD_I2C ? ? ? ? 1
> -#define CONFIG_I2C_MXC ? ? ? ? ?1
> +#define CONFIG_CMD_I2C
> +#define CONFIG_HARD_I2C
> +#define CONFIG_I2C_MXC
> ?#define CONFIG_SYS_I2C_MX53_PORT2 ? ? ? 1
> ?#define CONFIG_SYS_I2C_SPEED ? ? ? ? ? ?100000
> ?#define CONFIG_SYS_I2C_SLAVE ? ? ? ? ? ?0xfe
> --
> 1.7.1
Acked-by: Jason Liu <r64343@freescale.com>
BR,
Jason
>
>
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [U-Boot] [PATCH] mx53evk: Add RTC support
From: Jason Liu @ 2011-10-31 3:15 UTC (permalink / raw)
To: u-boot
In-Reply-To: <4EA6A6CF.40708@denx.de>
2011/10/25 Stefano Babic <sbabic@denx.de>:
> On 10/25/2011 01:44 PM, Fabio Estevam wrote:
>> MX53EVK has an MC13892 PMIC. Add RTC support.
>>
>> Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
>> ---
>> ?include/configs/mx53evk.h | ? ?2 ++
>> ?1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/include/configs/mx53evk.h b/include/configs/mx53evk.h
>> index c1941e3..6c4d34f 100644
>> --- a/include/configs/mx53evk.h
>> +++ b/include/configs/mx53evk.h
>> @@ -63,6 +63,7 @@
>> ?#define CONFIG_PMIC_I2C
>> ?#define CONFIG_PMIC_FSL
>> ?#define CONFIG_SYS_FSL_PMIC_I2C_ADDR ? ?8
>> +#define CONFIG_RTC_MC13XXX
>>
>> ?/* MMC Configs */
>> ?#define CONFIG_FSL_ESDHC
>> @@ -88,6 +89,7 @@
>> ?#define CONFIG_CMD_DHCP
>> ?#define CONFIG_CMD_MII
>> ?#define CONFIG_CMD_NET
>> +#define CONFIG_CMD_DATE
>>
>> ?/* allow to overwrite serial and ethaddr */
>> ?#define CONFIG_ENV_OVERWRITE
>
> Jason is not sent in CC as board maintainer - I have added him now.
Thanks Stefano. :)
Acked-by: Jason Liu < jason.hui@linaro.org>
BR,
Jason
>
> Stefano
>
> --
> =====================================================================
> DENX Software Engineering GmbH, ? ? MD: Wolfgang Denk & Detlev Zundel
> HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
> Phone: +49-8142-66989-0 Fax: +49-8142-66989-80 ?Email: office at denx.de
> =====================================================================
> _______________________________________________
> U-Boot mailing list
> U-Boot at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>
^ permalink raw reply
* [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Grant Likely @ 2011-10-31 3:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4025601.AfFCiixCcK@ax5200p>
On Sun, Oct 30, 2011 at 09:39:37PM +0100, Marc Dietrich wrote:
> On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> > I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> >
> > of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> >
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file. And further,
> > I assume that specifying "mem=" on the command-line overrides that, thus
> > solving the problem.
> >
> > It'd be awesome if you could validate this; the simplest way is probably
> > to:
> >
> > a) Remove mem= from the command-line
>
> I tested several variations. Without DT, the fixup can compensate a missing
> mem entry in the kernel command line, but with a mem= from the kernel command
> line, a fixup is not needed.
>
> With DT, the command line specified from nvflash is ignored and the one from
> DT comes into the game. If it is also missing there, system detects 512 MB
> (which is physical right, but we cannot reserve memory for the gpu). The fixup
> is indeed ignored in this case.
The /memreserve/ fields are supposed to allow you to do this.
>
> > b) Modify arch/arm/kernel/setup.c:parse_tag_mem32() to do nothing;
> > comment out the call to arm_add_memory()
>
> I leave this out because the bootloader does not send memory info in the
> ATAGS.
>
> > c) Test booting, and check what RAM size the kernel thinks you have.
>
> see above. RAM detection works, but it's not what we want ...
>
> > If that works, then ATAGs are the problem. We probably need to modify the
> > core ARM code not to use memory ATAGs when there is a DT?
> >
> > I'm mainly pushing on this because adding "mem=" to the command-line in
> > the DT file isn't a great solution; when people start using bootloaders
> > that rewrite the DT to include the user-specified command-line, then every
> > user is going to have to start specifying "mem=" in their command-lines.
>
> Well, I see two options for our case:
>
> a) use the mem=448M at 0 in the DT so the gpu can get its memory
> b) upstream the chromeos changes to reserve gpu memory "on the fly" from
> the autodetected 512M (as it should be IMHO).
b) is the ideal. a) is absolutely wrong. /memreserve/ should fix the
gpu memory problem when not passing a mem= parameter. If /memreserve/
isn't working, then I'd like to know why.
g.
^ permalink raw reply
* Re: [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
From: Grant Likely @ 2011-10-31 3:13 UTC (permalink / raw)
To: Marc Dietrich
Cc: Stephen Warren,
linux-tegra-u79uwXL29TY76Z2rM5mHXA@public.gmane.org,
Olof Johansson, Colin Cross,
linux-arm-kernel-IAPFreCvJWM7uuMidbF8XUB+6BGkLq7r@public.gmane.org
In-Reply-To: <4025601.AfFCiixCcK@ax5200p>
On Sun, Oct 30, 2011 at 09:39:37PM +0100, Marc Dietrich wrote:
> On Friday 28 October 2011 09:49:49 Stephen Warren wrote:
> > I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> >
> > of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> >
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file. And further,
> > I assume that specifying "mem=" on the command-line overrides that, thus
> > solving the problem.
> >
> > It'd be awesome if you could validate this; the simplest way is probably
> > to:
> >
> > a) Remove mem= from the command-line
>
> I tested several variations. Without DT, the fixup can compensate a missing
> mem entry in the kernel command line, but with a mem= from the kernel command
> line, a fixup is not needed.
>
> With DT, the command line specified from nvflash is ignored and the one from
> DT comes into the game. If it is also missing there, system detects 512 MB
> (which is physical right, but we cannot reserve memory for the gpu). The fixup
> is indeed ignored in this case.
The /memreserve/ fields are supposed to allow you to do this.
>
> > b) Modify arch/arm/kernel/setup.c:parse_tag_mem32() to do nothing;
> > comment out the call to arm_add_memory()
>
> I leave this out because the bootloader does not send memory info in the
> ATAGS.
>
> > c) Test booting, and check what RAM size the kernel thinks you have.
>
> see above. RAM detection works, but it's not what we want ...
>
> > If that works, then ATAGs are the problem. We probably need to modify the
> > core ARM code not to use memory ATAGs when there is a DT?
> >
> > I'm mainly pushing on this because adding "mem=" to the command-line in
> > the DT file isn't a great solution; when people start using bootloaders
> > that rewrite the DT to include the user-specified command-line, then every
> > user is going to have to start specifying "mem=" in their command-lines.
>
> Well, I see two options for our case:
>
> a) use the mem=448M@0 in the DT so the gpu can get its memory
> b) upstream the chromeos changes to reserve gpu memory "on the fly" from
> the autodetected 512M (as it should be IMHO).
b) is the ideal. a) is absolutely wrong. /memreserve/ should fix the
gpu memory problem when not passing a mem= parameter. If /memreserve/
isn't working, then I'd like to know why.
g.
^ permalink raw reply
* Re: PROBLEM: Kernel panic and system crash during RAID disk failure
From: Darko @ 2011-10-31 3:13 UTC (permalink / raw)
To: NeilBrown; +Cc: Thomas Gleixner, linux-kernel, linux-ext4
In-Reply-To: <20111030190548.2febafc0@notabene.brown>
Thank you for your reply!
I wanted to add to this that I was able to replicate the problem with ext3
and ext2 file systems as well. They both hard lock the system, and the
only way to recovery is to push the reset button. I can see the trace
error on the screen, but I am unable to do anything with it, since it goes
by so fast that the portion which says "kernel BUG" is invisible. I assume
they both have similar issues with the code in kernel/timer.c
On the other hand, I tried using raiserfs 3.5 tonight, and I got
input/output error as expected. The system did not crash. Just another
proof that a bug is laying somewhere in the ext2/3/4 file system.
When someone comes up with a patch, I am willing to try it out and feed
you back with the report.
Hope this helps.
Thank You,
Darko Kraus
On Sun, 30 Oct 2011, NeilBrown wrote:
> Date: Sun, 30 Oct 2011 19:05:48 +1100
> From: NeilBrown <neilb@suse.de>
> To: Darko <darko@hytron.net>
> Cc: Thomas Gleixner <tglx@linutronix.de>, linux-kernel@vger.kernel.org,
> linux-ext4@vger.kernel.org
> Subject: Re: PROBLEM: Kernel panic and system crash during RAID disk failure
>
> On Sun, 30 Oct 2011 03:27:28 -0400 (EDT) Darko <darko@hytron.net> wrote:
>
>> Hello,
>>
>> I have been doing some testing with the md RAID driver and I think I
>> discovered a problem with it.
>> Everything was performed on a system with a single hard drive using loop
>> devices as virtual raid devices.
>> So here is the setup:
>> /dev/sdc is my main drive that hold entire Linux OS and has one partition.
>> in the /tmp I created 7 files, 100MB each and associated them with loop
>> devices:
>>
>> losetup -a
>> /dev/loop0: [0821]:294820 (/var/tmp/raid-0)
>> /dev/loop1: [0821]:294857 (/var/tmp/raid-1)
>> /dev/loop2: [0821]:300120 (/var/tmp/raid-2)
>> /dev/loop3: [0821]:301073 (/var/tmp/raid-3)
>> /dev/loop4: [0821]:301074 (/var/tmp/raid-4)
>> /dev/loop5: [0821]:301075 (/var/tmp/raid-5)
>> /dev/loop6: [0821]:301076 (/var/tmp/raid-6)
>>
>> The next step was, created an RAID6 array:
>> mdadm --create /dev/md10 --level=6 -raid-deviced=7 /dev/loop[0-6]
>>
>> Here is how it looks so far:
>>
>> cat /proc/mdstat
>> Personalities : [raid0] [raid1] [raid10] [raid6] [raid5] [raid4]
>> md10 : active raid6 loop6[6] loop5[5] loop4[4] loop3[3] loop2[2] loop1[1] loop0[0]
>> 499200 blocks super 1.2 level 6, 512k chunk, algorithm 2 [7/7] [UUUUUUU]
>>
>>
>> Then the filesystem...
>> mkfs.ext4 -b 4096 -i 4096 -m 0 /dev/md10
>>
>> Mounting the file system to a folder called 'A' right in the root of my
>> system:
>>
>> mount /dev/md10 /A
>>
>> Then I copied a few files on that file system. So far everything is good.
>>
>> Then I purposly failed 2 drives:
>> mdadm --manage /dev/md10 --fail /dev/loop0
>> mdadm --manage /dev/md10 --fail /dev/loop1
>>
>> The array continues to run fine in degraded mode. I was wondering what
>> would happen if another drive fails. So while I was doing a write
>> operating right in that filesystem (/dev/md10) using:
>> dd if=/dev/zero of=testfile bs=1k count=360000 ...
>>
>> ...quickly switched to a different console and entered the command:
>> mdadm --manage /dev/md10 --fail /dev/loop2
>>
>> ...which made 3 failed drives and the array can no longer work...
>>
>> Well I would be happy to see just the array not working, but kernel panic
>> in both versions 2.6.37.4 and 3.0.8 made me worry that it is serious bug
>> and appears to be in older and newer kernels as well.
>> I repeated this several times, and mostly the machine gets locked up with
>> kernel panic. But once I was able to get it not to lock up all the way,
>> and that is how I have dmesg output.
>>
>> The attached files include dmesg from the system startup until the bug
>> trace, and some additional information regarding my system that might be
>> helpful.
>>
>> For any additional question, please feel free to contact me!
>>
>> I hope this info helps someone find and resolve the problem in the code.
>>
>
> The important part of your kernel log message is:
>
>
> [ 1227.766202] ------------[ cut here ]------------
> [ 1227.766259] kernel BUG at kernel/timer.c:681!
> [ 1227.766311] invalid opcode: 0000 [#1] SMP
> [ 1227.766365] last sysfs file: /sys/devices/virtual/block/md10/dev
> [ 1227.766419] Modules linked in:
> [ 1227.766471]
> [ 1227.766520] Pid: 1507, comm: mount Not tainted 2.6.37.6-v5.0 #7 MICRO-STAR INTERNATIONAL CO., LTD MS-7142/MS-7142
> [ 1227.766633] EIP: 0060:[<c104f960>] EFLAGS: 00010246 CPU: 0
> [ 1227.766690] EIP is at mod_timer+0x210/0x250
> [ 1227.766742] EAX: 00000000 EBX: f5494e1c ECX: 00000000 EDX: 00000000
> [ 1227.766796] ESI: 00000000 EDI: 05348416 EBP: f54a3c90 ESP: f54a3c74
> [ 1227.766851] DS: 007b ES: 007b FS: 00d8 GS: 00e0 SS: 0068
> [ 1227.766904] Process mount (pid: 1507, ti=f54a2000 task=f2068880 task.ti=f54a2000)
> [ 1227.767002] Stack:
> [ 1227.767003] f2068880 f54b159c 00000010 00000000 f1f8e400 f4efc57c 0000128d f54a3ca8
> [ 1227.767003] c11cb7ba c17d4e52 f4efc400 00000124 00000000 f54a3cb4 c11ce4e6 ecee6318
> [ 1227.767003] f54a3cdc c11cf7cc ecec7578 00000124 00000000 f4efc400 f54a3cd4 00000124
> [ 1227.767003] Call Trace:
> [ 1227.767003] [<c11cb7ba>] ? __save_error_info.clone.61+0x7a/0xf0
> [ 1227.767003] [<c11ce4e6>] ? save_error_info+0x16/0x30
> [ 1227.767003] [<c11cf7cc>] ? ext4_error_inode+0x4c/0xf0
> [ 1227.767003] [<c11b57e1>] ? __ext4_get_inode_loc+0x201/0x410
> [ 1227.767003] [<c110b62a>] ? inode_init_always+0x1aa/0x1c0
> [ 1227.767003] [<c11b72f9>] ? ext4_iget+0x59/0x6f0
> [ 1227.767003] [<c11d2716>] ? ext4_fill_super+0x1ab6/0x2c70
> [ 1227.767003] [<c114896f>] ? disk_name+0xbf/0xd0
> [ 1227.767003] [<c10fa119>] ? mount_bdev+0x179/0x1c0
> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
> [ 1227.767003] [<c11ca17f>] ? ext4_mount+0x1f/0x30
> [ 1227.767003] [<c11d0c60>] ? ext4_fill_super+0x0/0x2c70
> [ 1227.767003] [<c10f9835>] ? vfs_kern_mount+0x75/0x250
> [ 1227.767003] [<c110df03>] ? get_fs_type+0x33/0xb0
> [ 1227.767003] [<c11ca160>] ? ext4_mount+0x0/0x30
> [ 1227.767003] [<c10f9a6e>] ? do_kern_mount+0x3e/0xe0
> [ 1227.767003] [<c111080f>] ? do_mount+0x35f/0x6b0
> [ 1227.767003] [<c10d47c9>] ? strndup_user+0x49/0x70
> [ 1227.767003] [<c1110e0b>] ? sys_mount+0x6b/0xa0
> [ 1227.767003] [<c17b550c>] ? syscall_call+0x7/0xb
> [ 1227.767003] Code: fe ff ff 8b 0e 89 4d e4 8b 46 04 83 c6 08 89 f9 89 da ff 55 e4 8b 06 85 c0 89 45 e4 75 ea e9 aa fe ff ff 8b 75 ec e9 ee fe ff ff <0f> 0b 8b 55 04 89 d8 e8 34 f9 ff ff e9 2a fe ff ff 8b 35 30 b8
> [ 1227.767003] EIP: [<c104f960>] mod_timer+0x210/0x250 SS:ESP 0068:f54a3c74
> [ 1227.770073] ---[ end trace d7b3d7a67954d202 ]---
>
>
> which happens after:
>
> [ 1137.167043] Aborting journal on device md10-8.
> [ 1137.167058] Buffer I/O error on device md10, logical block 139265
> [ 1137.167060] lost page write due to I/O error on md10
> [ 1137.167065] JBD2: I/O error detected when updating journal superblock for md10-8.
> [ 1137.660922] Buffer I/O error on device md10, logical block 1
> [ 1137.660926] lost page write due to I/O error on md10
> [ 1137.660932] EXT4-fs error (device md10): ext4_journal_start_sb:260: Detected aborted journal
> [ 1137.661046] EXT4-fs (md10): Remounting filesystem read-only
> [ 1137.661103] EXT4-fs (md10): previous I/O error to superblock detected
> [ 1137.661313] Buffer I/O error on device md10, logical block 1
> [ 1137.661315] lost page write due to I/O error on md10
> [ 1219.891363] EXT4-fs (md10): previous I/O error to superblock detected
> [ 1220.050654] Buffer I/O error on device md10, logical block 1
> [ 1220.050657] lost page write due to I/O error on md10
> [ 1220.050663] EXT4-fs error (device md10): ext4_put_super:728: Couldn't clean up the journal
>
> and some more "Buffer I/O error"s.
>
> So it looks like an ext4 issue.
>
> I have Cc:ed the appropriate list.
>
> Thanks for the report.
>
> NeilBrown
>
>
--
Darko Kraus
Enterprise Network Administrator
^ permalink raw reply
* Re: [PATCH] cgroups: don't cache common ancestor in task counter subsys
From: Li Zefan @ 2011-10-31 3:14 UTC (permalink / raw)
To: Frederic Weisbecker
Cc: Ben Blum, Andrew Morton, Frederic Weisbecker, Paul Menage, LKML
In-Reply-To: <20111027151230.GE7974@somewhere.redhat.com>
Frederic Weisbecker wrote:
> On Mon, Oct 17, 2011 at 01:27:53PM -0400, Ben Blum wrote:
>> On Mon, Oct 17, 2011 at 07:25:41PM +0200, Frederic Weisbecker wrote:
>>> When we rollback there, we are dealing with oldcgrp of the last thread
>>> we have treated. All threads in the rollback list don't necessary belonged
>>> to that old_cgroup.
>>>
>>> And we can't try to retrieve these old_cgroup through task_cgroup_from_root() because
>>> the threads might have exited and thus could be assigned to the init cgroup.
>>>
>>> I believe we need to cache these old cgroups in the flex array.
>>>
>>
>> Doing this would fulfill the "TODO" in cgroup_attach_proc for being able
>> to pass the oldcgrp for each task in the loop around the ss->attach
>> call, so if you do that, remove the corresponding comment. :)
>>
>> -- Ben
>
> I don't know, looking at the code, there is a separate issue to solve there.
> The old cgroup passed in ->attach() is the one of a random task from the thread
> group. The migrations that happen right before leave oldcgrp with the
> old cgroup of the last thread in the group.
>
> This doesn't seem to make any sense. As far as I checked this is only used
> by the cpuset subsystem that does a migration in cpuset_attach() from
> the old cgroup to the new.
>
> I'm not sure about the details but that looks buggy.
>
I think you're right, and Tejun's patchset happens to fix this bug in
cpuset_attach() - it gets the mm of the thread leader and do migration.
^ 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.