* [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
From: Aurelien Jarno @ 2011-02-08 10:06 UTC (permalink / raw)
To: Jan Kiszka
Cc: Anthony Liguori, Stefan Hajnoczi, Marcelo Tosatti,
qemu-devel@nongnu.org, Anthony Liguori, Paul Brook,
Edgar E. Iglesias, Paolo Bonzini, Arun Bharadwaj
In-Reply-To: <4D511500.1040303@siemens.com>
Jan Kiszka a écrit :
> On 2011-02-08 10:58, Aurelien Jarno wrote:
>> Jan Kiszka a écrit :
>>> On 2011-02-08 10:05, Aurelien Jarno wrote:
>>>> Jan Kiszka a écrit :
>>>>> On 2011-02-08 09:08, Paolo Bonzini wrote:
>>>>>> On 02/08/2011 08:26 AM, Aurelien Jarno wrote:
>>>>>>> I forget to remember when we decided that AIO should be implemented on
>>>>>>> any host OS. Any pointer?
>>>>>> To be fair, I/O-heavy workloads are almost unusable without AIO. For
>>>>>> Window targets, they also crash under SMP due to the Windows AP
>>>>>> watchdog. But then TCG and SMP do not go very well together anyway.
>>>>>>
>>>>>> However, I think deprecating Win32 support would be a very bad idea.
>>>>> It would be too early at this point.
>>>>>
>>>>> But if Windows is once the only reason to keep tons of hardly tested
>>>>> code paths around or to invest significant additional effort to change
>>>>> logic or interfaces in this area, than I would prefer that step. I'm
>>>>> hacking on IOTHREAD vs. !IOTHREAD for some weeks now, and all those
>>>>> subtle differences are really a PITA and source of various breakages.
>>>>>
>>>>> People interested in that platform should finally realize that its fate
>>>>> is coupled to reducing the #ifdefs as well as the design differences we
>>>>> see right now and even more in the future.
>>>>>
>>>> The guilty here is IOTHREAD. Windows support predates IOTHREAD concept,
>>>> it's just that people who introduce IOTHREAD didn't care about Windows
>>>> support at all and added these #ifdef. Disabling Windows support because
>>>> of that is not fair.
>>> The TCG execution model won't scale long-term. It's already a main to
>>> boot a quad or just dual core VM, even more when your host has at least
>>> as many real cores. I'm sure we'll see multi-threaded TCG CPUs in the
>>> future, and the iothread will just be one of 7, 17 or 257 threads.
>>>
>> And what's the issue with that? People don't always look for performance
>> when using QEMU. They even often try to emulate old machines (and non
>> x86 ones), which anyway only have one CPU. This won't change in 5 years,
>> the only thing is that those machines will be 5 years older.
>>
>> People have to keep in mind that QEMU doesn't mean only virtualization
>> and doesn't mean only x86.
>
> I'm not talking about virtualization here. I'm talking about usable
> emulation of today's (!) embedded multi-core platforms. It matters a lot
> if your test roundtrip for booting into a SMP guest and running some
> apps is a few 10 seconds, a few minutes or even not practically working.
> Ever tried to boot a 16 core VM in emulation mode? I did, for fun. I
> just hope I'll never depend on this for work.
Yes, it's slow. But is it a problem? You assume that people use QEMU
only for emulating SMP platforms. This is a wrong assumption. Beside the
x86 target, only sparc really supports SMP emulation.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
From: Paolo Bonzini @ 2011-02-08 10:06 UTC (permalink / raw)
To: Aurelien Jarno
Cc: Anthony Liguori, Stefan Hajnoczi, Jan Kiszka, Marcelo Tosatti,
qemu-devel@nongnu.org, Anthony Liguori, Paul Brook,
Arun Bharadwaj, Edgar E. Iglesias
In-Reply-To: <4D5113D3.9090802@aurel32.net>
On 02/08/2011 10:58 AM, Aurelien Jarno wrote:
> And what's the issue with that? People don't always look for performance
> when using QEMU. They even often try to emulate old machines (and non
> x86 ones), which anyway only have one CPU. This won't change in 5 years,
> the only thing is that those machines will be 5 years older.
>
> People have to keep in mind that QEMU doesn't mean only virtualization
> and doesn't mean only x86.
AFAIU nobody is proposing to rip linux-user or TCG, just to improve its
implementation.
You just as well have to understand that AIO means fewer Windows blue
screens of death and not only better performance.
Paolo
^ permalink raw reply
* Re: "git add -u" broken in git 1.7.4?
From: SZEDER Gábor @ 2011-02-08 10:05 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Matthieu Moy, Sebastian Pipping, Git ML
In-Reply-To: <20110207195035.GA13461@sigill.intra.peff.net>
On Mon, Feb 07, 2011 at 02:50:35PM -0500, Jeff King wrote:
> On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
>
> > I actually do not mind too much myself if all commands that can take
> > pathspecs consistently defaulted to "full-tree" pathspec given no
> > pathspec. But if we were to go that route, everybody should join their
> > voice to defend that decision when outside people say "in 1.8.0 'git grep'
> > run from a subdirectory shows matches from all the irrelevant parts of the
> > tree; with all the cruft its output is unreadable". I won't be the sole
> > champion of such a behaviour when I do not fully believe in it.
>
> The problem is that I don't feel comfortable writing an RFC that says
> "in 1.8.0 we will default to full-tree because it is somehow better".
> Because I don't think it is better; it is simply a different way of
> thinking about it, and different people will have different preferences.
>
> I think even the same people may different preferences from project to
> project. For most of my projects, the scope of the repo is well-defined,
> and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
> tweak and run the tests, and then want to "git add -u" the whole thing
> when everything looks good). But I also recently worked on a gigantic
> project that was split into several sub-components. I would cd 3 or 4
> levels deep into the sub-component that I was working on, and I would
> prefer my "git add -u" to stay in that sub-component, and my "git grep"
> to look only in that sub-component.
It sounds like your work focused solely on the sub-component you cd-d
into. Did you have any other changes outside of that sub-component?
Because when not, then both the current and the whole-tree "git add -u"
would have the same effect.
The current and the whole-tree "git grep" would behave differently, of
course. But even then a whole-tree "git grep" would be harmless and
easy to limit in scope, though might be a bit annoying in the "cd deep
down" case. In that case you would immediately see the matches
outside of cwd, know that you forgot to limit the operation to cwd, so
you hit the up key, simply append the "." to the last command, and you
get what you wanted.
As mentioned in this or other related threads, this is not at all that
simple the other way around, i.e. with current "git grep" when you are
in the sub-component and you happen to need a grep on the whole tree,
because you have to pay attention to use the right number of "../"s.
A whole-tree "git add -u" is just as easy to limit in scope as the
whole-tree "git grep" would be, but certainly more annoying when you
forget to limit it to cwd. But even in that case there is no harm
done, because all the changes you've made are there, but you have to
unstage changes from the index or split the commit.
Current "git add -u" is worst of all, because it's not just difficult
to circumvent (how many "../" do I need?), but it's downright
dangerous, because you can lose changes when forget that it's limited
in scope. I managed to do something like this while fixing two
already bisected bugs:
git checkout deadbeef # BugA was introduced in that commit
vim git.c # fix BugA
cd t
test ; vim test ; test
git add -u # again forgetting that a
# fundamentally whole-tree oriented
# tool has operations with
# non-whole-tree defaults...
git commit -m 'Fix BugA' # will write proper commit msg later
git branch fix_BugA # to find the commit later
git reset --hard babefeed # instead of "git checkout babefeed"
# BugB was introduced there
# goodbye bugfix!
# hack away to fix BugB # until realisation sets in
# Damn.
You could argue that there are several ways I could have prevented
shooting myself in the foot, e.g. using "git checkout" instead of "git
reset --hard", or by using plain "git commit" without the "-m" option
I might have noticed the unstaged changes in the commit template. I
would even tend to agree, but I still think that git should be
consistent with _itself_ in the first place, and since git's
fundamental concepts are whole-tree oriented and there are many
commands that only make sense on the whole tree, defaulting to
whole-tree operations for commands taking a pathspec is indeed better.
And safer too.
Best,
Gábor
^ permalink raw reply
* Re: [PATCH 14/18] wl1251: implement multicast address filtering
From: Kalle Valo @ 2011-02-08 10:05 UTC (permalink / raw)
To: David Gnedt
Cc: John W. Linville, linux-wireless, Grazvydas Ignotas,
Denis 'GNUtoo' Carikli
In-Reply-To: <4D45B7D3.90707@davizone.at>
David Gnedt <david.gnedt@davizone.at> writes:
> Port multicast address filtering from wl1271 driver.
> It sets up the hardware multicast address filter in configure_filter() with
> addresses supplied through prepare_multicast().
Thanks, looks good to me.
> Signed-off-by: David Gnedt <david.gnedt@davizone.at>
Acked-by: Kalle Valo <kvalo@adurom.com>
--
Kalle Valo
^ permalink raw reply
* ALSA: Reasonable buffer size / where should it be implemented?
From: Knut Petersen @ 2011-02-08 10:05 UTC (permalink / raw)
To: perex; +Cc: tiwai, linux-kernel, alsa-devel
I use a RME Digi 96 PAD audio card, and I do have
buffer overrun/underrun problems if I use the standard
rme96c linux driver.
I need a simple recording machine. It should not fail if
e.g. cron starts updatedb or if I start a make -j 15 icecream
compile job and decide to surf the internet while I record
the digital satellite radio 48kHz stream.
There is a lot of information about xrun problems, but
somehow that information either does not help to prevent
xruns on my system, is outdated, or asks for system
changes I do not accept.
No, JACK does not help. No, I do not need low latency.
No, I don't want to switch to rt kernels. No, I don't want
to use an audio PC without X, without cron, network, etc.
The hardware provides independent 64k ringbuffers for
capture and playback, that's not more than 85msec for a
96 kHz / 2 channel / 32 bit setup or ADAT. That's simply
not enough for reliable operation.
My private solution is a rme96.c that kmallocs 4 MB
software buffers for capture and playback, data transfer
between software and hardware buffer in the interrupt
service routine. That does efficiently prevent xruns even
on a really loaded system.
But I don't know if that is the right way to go.
Wouldn't it be better if there would be an (optional) software
buffer one layer above the hardware driver? That would
increase reliability for all audio hardware with insufficient
hardware buffers.
Is there any other audio hardware with similar small
buffers?
Has somebody already written an "extended alsa buffer"
patch? Did I miss something?
To put it into one question: How much buffer should be
provided by an alsa hardware driver module?
cu,
Knut
^ permalink raw reply
* Re: [patch 07/10] m68knommu: Convert 5272 intc irq_chip to new functions
From: Greg Ungerer @ 2011-02-08 10:03 UTC (permalink / raw)
To: Thomas Gleixner; +Cc: LKML, Greg Ungerer
In-Reply-To: <alpine.LFD.2.00.1102081047020.31804@localhost6.localdomain6>
Hi Thomas,
On 08/02/11 19:48, Thomas Gleixner wrote:
> On Tue, 8 Feb 2011, Greg Ungerer wrote:
>>> static void intc_external_irq(unsigned int irq, struct irq_desc *desc)
>>> {
>>> - desc->chip->ack(irq);
>>> + get_irq_desc_chip(i)->irq_ack(desc->irq_data);
>> ^^^ ^^^
>> should this be:
>>
>> get_irq_desc_chip(desc)->irq_ack(&desc->irq_data)
>
> Yes.
>
>> I can't runtime test this right at the moment, but otherwise:
>>
>> Acked-by: Greg Ungerer<gerg@uclinux.org>
>
> Can you push that stuff linus wards for 39 or want me to do it ? It
> has no dependencies whatsoever.
I am happy to push this for 39.
Thanks
Greg
------------------------------------------------------------------------
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
* [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
From: Jan Kiszka @ 2011-02-08 10:03 UTC (permalink / raw)
To: Aurelien Jarno
Cc: Anthony Liguori, Stefan Hajnoczi, Marcelo Tosatti,
qemu-devel@nongnu.org, Anthony Liguori, Paul Brook,
Edgar E. Iglesias, Paolo Bonzini, Arun Bharadwaj
In-Reply-To: <4D5113D3.9090802@aurel32.net>
On 2011-02-08 10:58, Aurelien Jarno wrote:
> Jan Kiszka a écrit :
>> On 2011-02-08 10:05, Aurelien Jarno wrote:
>>> Jan Kiszka a écrit :
>>>> On 2011-02-08 09:08, Paolo Bonzini wrote:
>>>>> On 02/08/2011 08:26 AM, Aurelien Jarno wrote:
>>>>>> I forget to remember when we decided that AIO should be implemented on
>>>>>> any host OS. Any pointer?
>>>>> To be fair, I/O-heavy workloads are almost unusable without AIO. For
>>>>> Window targets, they also crash under SMP due to the Windows AP
>>>>> watchdog. But then TCG and SMP do not go very well together anyway.
>>>>>
>>>>> However, I think deprecating Win32 support would be a very bad idea.
>>>> It would be too early at this point.
>>>>
>>>> But if Windows is once the only reason to keep tons of hardly tested
>>>> code paths around or to invest significant additional effort to change
>>>> logic or interfaces in this area, than I would prefer that step. I'm
>>>> hacking on IOTHREAD vs. !IOTHREAD for some weeks now, and all those
>>>> subtle differences are really a PITA and source of various breakages.
>>>>
>>>> People interested in that platform should finally realize that its fate
>>>> is coupled to reducing the #ifdefs as well as the design differences we
>>>> see right now and even more in the future.
>>>>
>>> The guilty here is IOTHREAD. Windows support predates IOTHREAD concept,
>>> it's just that people who introduce IOTHREAD didn't care about Windows
>>> support at all and added these #ifdef. Disabling Windows support because
>>> of that is not fair.
>>
>> The TCG execution model won't scale long-term. It's already a main to
>> boot a quad or just dual core VM, even more when your host has at least
>> as many real cores. I'm sure we'll see multi-threaded TCG CPUs in the
>> future, and the iothread will just be one of 7, 17 or 257 threads.
>>
>
> And what's the issue with that? People don't always look for performance
> when using QEMU. They even often try to emulate old machines (and non
> x86 ones), which anyway only have one CPU. This won't change in 5 years,
> the only thing is that those machines will be 5 years older.
>
> People have to keep in mind that QEMU doesn't mean only virtualization
> and doesn't mean only x86.
I'm not talking about virtualization here. I'm talking about usable
emulation of today's (!) embedded multi-core platforms. It matters a lot
if your test roundtrip for booting into a SMP guest and running some
apps is a few 10 seconds, a few minutes or even not practically working.
Ever tried to boot a 16 core VM in emulation mode? I did, for fun. I
just hope I'll never depend on this for work.
Jan
--
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
^ permalink raw reply
* Re: I do not know if this is the correct place to ask about this but...
From: dave b @ 2011-02-08 10:03 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: Linux Kernel
In-Reply-To: <4D511268.5040804@ladisch.de>
On 8 February 2011 20:52, Clemens Ladisch <clemens@ladisch.de> wrote:
> dave b wrote:
>> I do not know if this is the correct place to ask about this but...
>>
>> [Hardware Error]:
>
> This is a hardware error that was detected by the kernel.
>
>> I have only seen the following output output twice
>>
>> ... Corrected error
>> ... L3 ECC data cache error.
>
> There was a wrong bit in your CPU's level 3 cache, but with the help of
> the redundant error correction bits, this was caught and corrected.
Yep I got that.
> (If possible, enable background scrubbing of the caches in the BIOS ECC
> settings to catch these errors earlier.)
Ok I will look into that.
> If this is an overclocked CPU or one with an unlocked core, you deserve
> what you got. Otherwise, if this happens repeatedly, it indicates
> a hardware defect, and your warranty should cover this.
Ok fair enough.
Notes:
The cpu is not overclocked.
I forgot to list the hardware specifications:
cpu is a AMD Phenom(tm) II X6 1055T Processor
running on a ASUS M4A88TD-M motherboard.
^ permalink raw reply
* [PATCH 3/3] gprs-provision: update example with SPN
From: Jukka Saunamaki @ 2011-02-08 10:03 UTC (permalink / raw)
To: ofono
In-Reply-To: <1297159428-2409-1-git-send-email-jukka.saunamaki@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 1005 bytes --]
---
examples/provision.c | 8 +++++---
1 files changed, 5 insertions(+), 3 deletions(-)
diff --git a/examples/provision.c b/examples/provision.c
index 356b0b3..546a161 100644
--- a/examples/provision.c
+++ b/examples/provision.c
@@ -37,6 +37,7 @@
#include <ofono/log.h>
static int example_provision_get_settings(const char *mcc, const char *mnc,
+ const char *spn,
struct ofono_gprs_provision_data **settings,
int *count)
{
@@ -44,10 +45,11 @@ static int example_provision_get_settings(const char *mcc, const char *mnc,
*count = 0;
*settings = NULL;
- ofono_debug("Finding settings for MCC %s, MNC %s",
- mcc, mnc);
+ ofono_debug("Finding settings for MCC %s, MNC %s, SPN '%s'",
+ mcc, mnc, spn);
- if (strcmp(mcc, "246") != 0 || strcmp(mnc, "81") != 0)
+ if (strcmp(mcc, "246") != 0 || strcmp(mnc, "81") != 0 ||
+ strcmp(spn, "oFono") != 0)
return -ENOENT;
ofono_debug("Creating example settings for phonesim");
--
1.7.1
^ permalink raw reply related
* [PATCH 2/3] gprs,gprs-provision: add SPN to provisioning API
From: Jukka Saunamaki @ 2011-02-08 10:03 UTC (permalink / raw)
To: ofono
In-Reply-To: <1297159428-2409-1-git-send-email-jukka.saunamaki@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 5986 bytes --]
---
src/gprs-provision.c | 4 +-
src/gprs.c | 87 +++++++++++++++++++++++++++++++++++++------------
src/ofono.h | 2 +-
3 files changed, 68 insertions(+), 25 deletions(-)
diff --git a/src/gprs-provision.c b/src/gprs-provision.c
index 3cd84e8..011d5a8 100644
--- a/src/gprs-provision.c
+++ b/src/gprs-provision.c
@@ -48,7 +48,7 @@ void __ofono_gprs_provision_free_settings(
}
ofono_bool_t __ofono_gprs_provision_get_settings(const char *mcc,
- const char *mnc,
+ const char *mnc, const char *spn,
struct ofono_gprs_provision_data **settings,
int *count)
{
@@ -65,7 +65,7 @@ ofono_bool_t __ofono_gprs_provision_get_settings(const char *mcc,
DBG("Calling provisioning plugin '%s'", driver->name);
- if (driver->get_settings(mcc, mnc, settings, count) < 0)
+ if (driver->get_settings(mcc, mnc, spn, settings, count) < 0)
continue;
return TRUE;
diff --git a/src/gprs.c b/src/gprs.c
index 5ea864c..bb1b173 100644
--- a/src/gprs.c
+++ b/src/gprs.c
@@ -97,6 +97,7 @@ struct ofono_gprs {
const struct ofono_gprs_driver *driver;
void *driver_data;
struct ofono_atom *atom;
+ struct ofono_sim_context *sim_context;
};
struct ofono_gprs_context {
@@ -2291,6 +2292,9 @@ static void gprs_remove(struct ofono_atom *atom)
if (gprs->driver && gprs->driver->remove)
gprs->driver->remove(gprs);
+ if (gprs->sim_context)
+ ofono_sim_context_free(gprs->sim_context);
+
g_free(gprs);
}
@@ -2627,14 +2631,14 @@ static void provision_context(const struct ofono_gprs_provision_data *ap,
gprs->contexts = g_slist_append(gprs->contexts, context);
}
-static void provision_contexts(struct ofono_gprs *gprs, struct ofono_sim *sim)
+static void provision_contexts(struct ofono_gprs *gprs, const char *mcc,
+ const char *mnc, const char *spn)
{
struct ofono_gprs_provision_data *settings;
int count;
int i;
- if (__ofono_gprs_provision_get_settings(ofono_sim_get_mcc(sim),
- ofono_sim_get_mnc(sim),
+ if (__ofono_gprs_provision_get_settings(mcc, mnc, spn,
&settings, &count) == FALSE) {
ofono_warn("Provisioning failed");
return;
@@ -2646,13 +2650,15 @@ static void provision_contexts(struct ofono_gprs *gprs, struct ofono_sim *sim)
__ofono_gprs_provision_free_settings(settings, count);
}
-void ofono_gprs_register(struct ofono_gprs *gprs)
+static void ofono_gprs_finish_register(struct ofono_gprs *gprs)
{
DBusConnection *conn = ofono_dbus_get_connection();
struct ofono_modem *modem = __ofono_atom_get_modem(gprs->atom);
const char *path = __ofono_atom_get_path(gprs->atom);
struct ofono_atom *netreg_atom;
- struct ofono_atom *sim_atom;
+
+ if (gprs->contexts == NULL) /* Automatic provisioning failed */
+ add_context(gprs, NULL, OFONO_GPRS_CONTEXT_TYPE_INTERNET);
if (!g_dbus_register_interface(conn, path,
OFONO_CONNECTION_MANAGER_INTERFACE,
@@ -2661,29 +2667,13 @@ void ofono_gprs_register(struct ofono_gprs *gprs)
ofono_error("Could not create %s interface",
OFONO_CONNECTION_MANAGER_INTERFACE);
+ gprs_unregister(gprs->atom);
return;
}
ofono_modem_add_interface(modem,
OFONO_CONNECTION_MANAGER_INTERFACE);
- sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
-
- if (sim_atom) {
- const char *imsi;
- struct ofono_sim *sim = __ofono_atom_get_data(sim_atom);
-
- imsi = ofono_sim_get_imsi(sim);
- gprs_load_settings(gprs, imsi);
-
- if (gprs->contexts == NULL)
- provision_contexts(gprs, sim);
-
- }
-
- if (gprs->contexts == NULL)
- add_context(gprs, NULL, OFONO_GPRS_CONTEXT_TYPE_INTERNET);
-
gprs->netreg_watch = __ofono_modem_add_atom_watch(modem,
OFONO_ATOM_TYPE_NETREG,
netreg_watch, gprs, NULL);
@@ -2697,6 +2687,59 @@ void ofono_gprs_register(struct ofono_gprs *gprs)
__ofono_atom_register(gprs->atom, gprs_unregister);
}
+static void sim_spn_read_cb(int ok, int length, int record,
+ const unsigned char *data,
+ int record_length, void *userdata)
+{
+ struct ofono_gprs *gprs = userdata;
+ char *spn = NULL;
+ struct ofono_atom *sim_atom;
+ struct ofono_sim *sim = NULL;
+
+ if (ok)
+ spn = sim_string_to_utf8(data + 1, length - 1);
+
+ sim_atom = __ofono_modem_find_atom(__ofono_atom_get_modem(gprs->atom),
+ OFONO_ATOM_TYPE_SIM);
+ if (sim_atom) {
+ sim = __ofono_atom_get_data(sim_atom);
+ provision_contexts(gprs, ofono_sim_get_mcc(sim),
+ ofono_sim_get_mnc(sim), spn);
+ }
+
+ g_free(spn);
+ ofono_gprs_finish_register(gprs);
+}
+
+void ofono_gprs_register(struct ofono_gprs *gprs)
+{
+ struct ofono_modem *modem = __ofono_atom_get_modem(gprs->atom);
+ struct ofono_atom *sim_atom;
+ struct ofono_sim *sim = NULL;
+
+ sim_atom = __ofono_modem_find_atom(modem, OFONO_ATOM_TYPE_SIM);
+
+ if (sim_atom) {
+ const char *imsi;
+ sim = __ofono_atom_get_data(sim_atom);
+
+ imsi = ofono_sim_get_imsi(sim);
+ gprs_load_settings(gprs, imsi);
+ }
+
+ if (gprs->contexts == NULL && sim != NULL) {
+ /* Get Service Provider Name from SIM for provisioning */
+ gprs->sim_context = ofono_sim_context_create(sim);
+
+ if (ofono_sim_read(gprs->sim_context, SIM_EFSPN_FILEID,
+ OFONO_SIM_FILE_STRUCTURE_TRANSPARENT,
+ sim_spn_read_cb, gprs) >= 0)
+ return;
+ }
+
+ ofono_gprs_finish_register(gprs);
+}
+
void ofono_gprs_remove(struct ofono_gprs *gprs)
{
__ofono_atom_free(gprs->atom);
diff --git a/src/ofono.h b/src/ofono.h
index 6ba0187..0cdebf7 100644
--- a/src/ofono.h
+++ b/src/ofono.h
@@ -424,7 +424,7 @@ void __ofono_nettime_info_received(struct ofono_modem *modem,
#include <ofono/gprs-provision.h>
ofono_bool_t __ofono_gprs_provision_get_settings(const char *mcc,
- const char *mnc,
+ const char *mnc, const char *spn,
struct ofono_gprs_provision_data **settings,
int *count);
void __ofono_gprs_provision_free_settings(
--
1.7.1
^ permalink raw reply related
* [PATCH 1/3] gprs-provision: add SPN to provisioning API header
From: Jukka Saunamaki @ 2011-02-08 10:03 UTC (permalink / raw)
To: ofono
In-Reply-To: <1297159428-2409-1-git-send-email-jukka.saunamaki@nokia.com>
[-- Attachment #1: Type: text/plain, Size: 607 bytes --]
---
include/gprs-provision.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/include/gprs-provision.h b/include/gprs-provision.h
index bc021a8..e9eec61 100644
--- a/include/gprs-provision.h
+++ b/include/gprs-provision.h
@@ -42,7 +42,7 @@ struct ofono_gprs_provision_data {
struct ofono_gprs_provision_driver {
const char *name;
int priority;
- int (*get_settings)(const char *mcc, const char *mnc,
+ int (*get_settings)(const char *mcc, const char *mnc, const char *spn,
struct ofono_gprs_provision_data **settings,
int *count);
};
--
1.7.1
^ permalink raw reply related
* [PATCH 0/3] gprs-provision: Add SPN to provision API
From: Jukka Saunamaki @ 2011-02-08 10:03 UTC (permalink / raw)
To: ofono
[-- Attachment #1: Type: text/plain, Size: 677 bytes --]
Hello
This patchset adds Service Provider Name (SPN) into GPRS context provisioning API.
SPN is read (asynchronously) in the middle of gprs atom registration, if provisioning is needed.
--Jukka
Jukka Saunamaki (3):
gprs-provision: add SPN to provisioning API header
gprs,gprs-provision: add SPN to provisioning API
gprs-provision: update example with SPN
examples/provision.c | 8 +++--
include/gprs-provision.h | 2 +-
src/gprs-provision.c | 4 +-
src/gprs.c | 87 ++++++++++++++++++++++++++++++++++-----------
src/ofono.h | 2 +-
5 files changed, 74 insertions(+), 29 deletions(-)
^ permalink raw reply
* [PATCH 5/5] mtd: onenand_base: onenand_verify bugfix for writepage non-aligned address
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
In-Reply-To: <1297159362-8407-1-git-send-email-adrian.hunter@nokia.com>
From: Roman Tereshonkov <roman.tereshonkov@nokia.com>
In onenand_verify function the address can be writepage non-aligned.
When a page is read for comparing the right offset should be used
for "this->verify_buf" to get the right matching with compared
"buf" buffer.
Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
drivers/mtd/onenand/onenand_base.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index 38e6d76..4205b94 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1648,11 +1648,10 @@ static int onenand_verify(struct mtd_info *mtd, const u_char *buf, loff_t addr,
int ret = 0;
int thislen, column;
+ column = addr & (this->writesize - 1);
+
while (len != 0) {
- thislen = min_t(int, this->writesize, len);
- column = addr & (this->writesize - 1);
- if (column + thislen > this->writesize)
- thislen = this->writesize - column;
+ thislen = min_t(int, this->writesize - column, len);
this->command(mtd, ONENAND_CMD_READ, addr, this->writesize);
@@ -1666,12 +1665,13 @@ static int onenand_verify(struct mtd_info *mtd, const u_char *buf, loff_t addr,
this->read_bufferram(mtd, ONENAND_DATARAM, this->verify_buf, 0, mtd->writesize);
- if (memcmp(buf, this->verify_buf, thislen))
+ if (memcmp(buf, this->verify_buf + column, thislen))
return -EBADMSG;
len -= thislen;
buf += thislen;
addr += thislen;
+ column = 0;
}
return 0;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 4/5] mtd: tests : move ebcnt and pgcnt definitions before usage in printing.
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
In-Reply-To: <1297159362-8407-1-git-send-email-adrian.hunter@nokia.com>
From: Roman Tereshonkov <roman.tereshonkov@nokia.com>
ebcnt and pgcnt variable initialization is moved before printk which
uses them.
Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
---
drivers/mtd/tests/mtd_subpagetest.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/drivers/mtd/tests/mtd_subpagetest.c b/drivers/mtd/tests/mtd_subpagetest.c
index 11204e8..334eae5 100644
--- a/drivers/mtd/tests/mtd_subpagetest.c
+++ b/drivers/mtd/tests/mtd_subpagetest.c
@@ -394,6 +394,11 @@ static int __init mtd_subpagetest_init(void)
}
subpgsize = mtd->writesize >> mtd->subpage_sft;
+ tmp = mtd->size;
+ do_div(tmp, mtd->erasesize);
+ ebcnt = tmp;
+ pgcnt = mtd->erasesize / mtd->writesize;
+
printk(PRINT_PREF "MTD device size %llu, eraseblock size %u, "
"page size %u, subpage size %u, count of eraseblocks %u, "
"pages per eraseblock %u, OOB size %u\n",
@@ -413,11 +418,6 @@ static int __init mtd_subpagetest_init(void)
goto out;
}
- tmp = mtd->size;
- do_div(tmp, mtd->erasesize);
- ebcnt = tmp;
- pgcnt = mtd->erasesize / mtd->writesize;
-
err = scan_for_bad_eraseblocks();
if (err)
goto out;
--
1.7.0.4
^ permalink raw reply related
* [PATCH 2/5] mtd: tests: add count parameter to mtd_speedtest
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
In-Reply-To: <1297159362-8407-1-git-send-email-adrian.hunter@nokia.com>
By default mtd_speedtest uses all the eraseblocks of the
MTD partition being tested. For large partitions a
smaller number is sufficient and makes running the test
quicker. For that reason, add a parameter 'count' to
specify the maximum number of eraseblocks to use for
testing.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
drivers/mtd/tests/mtd_speedtest.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/tests/mtd_speedtest.c b/drivers/mtd/tests/mtd_speedtest.c
index 161feeb..9bd986e 100644
--- a/drivers/mtd/tests/mtd_speedtest.c
+++ b/drivers/mtd/tests/mtd_speedtest.c
@@ -16,7 +16,7 @@
*
* Test read and write speed of a MTD device.
*
- * Author: Adrian Hunter <ext-adrian.hunter@nokia.com>
+ * Author: Adrian Hunter <adrian.hunter@nokia.com>
*/
#include <linux/init.h>
@@ -33,6 +33,11 @@ static int dev;
module_param(dev, int, S_IRUGO);
MODULE_PARM_DESC(dev, "MTD device number to use");
+static int count;
+module_param(count, int, S_IRUGO);
+MODULE_PARM_DESC(count, "Maximum number of eraseblocks to use "
+ "(0 means use all)");
+
static struct mtd_info *mtd;
static unsigned char *iobuf;
static unsigned char *bbt;
@@ -326,7 +331,10 @@ static int __init mtd_speedtest_init(void)
printk(KERN_INFO "\n");
printk(KERN_INFO "=================================================\n");
- printk(PRINT_PREF "MTD device: %d\n", dev);
+ if (count)
+ printk(PRINT_PREF "MTD device: %d count: %d\n", dev, count);
+ else
+ printk(PRINT_PREF "MTD device: %d\n", dev);
mtd = get_mtd_device(NULL, dev);
if (IS_ERR(mtd)) {
@@ -353,6 +361,9 @@ static int __init mtd_speedtest_init(void)
(unsigned long long)mtd->size, mtd->erasesize,
pgsize, ebcnt, pgcnt, mtd->oobsize);
+ if (count > 0 && count < ebcnt)
+ ebcnt = count;
+
err = -ENOMEM;
iobuf = kmalloc(mtd->erasesize, GFP_KERNEL);
if (!iobuf) {
--
1.7.0.4
^ permalink raw reply related
* Serious Problem
From: Marco Sarzi Madidini @ 2011-02-08 10:03 UTC (permalink / raw)
To: linux-msdos
On Tue, Jan 11, 2011 at 5:58 AM, Marco Sarzi Madidini
<m.sarzi_madidini@saeimpianti.net> wrote:
> I have a problem with my Red Hat enterprise 5.5 distro and dosemu 1.4.0.
> Sometimes xdosemu don't work and show me an error message
> "/usr/local/bin/xdoemu: relocation error: /usr/local/bin/xdosemu: symbol
> localtime, version glibc 2.0 not define in file libc.so.6 with link time
> reference". Can you help me ??? Tanks for your disponibility and have a
nice
> 2011.
>
I have tried many version ( both rpm and tar ) but the problem is ever
present. Today I try to modify the compiletime-setting file and disable all
the unuseful features ( including the experimantal ) without improvements.
It' a very curious trouble, if i start for example 10 emulation ( with
xdosemu & ), only one can born the dosemu window. Boh ??? Someone can help
me ??? Thanks a lot !!!
^ permalink raw reply
* [PATCH 0/5] mtd: test patches and bug fixes
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
Hi
Here are a couple of patches for MTD tests
and also a couple of OneNAND bug fixes.
Adrian Hunter (2):
mtd: OneNAND: return read error for 4KiB page read
mtd: tests: add count parameter to mtd_speedtest
Roman Tereshonkov (3):
mtd: tests: add multiblock erase test to the mtd_speedtest
mtd: tests : move ebcnt and pgcnt definitions before usage in printing.
mtd: onenand_base: onenand_verify bugfix for writepage non-aligned address
drivers/mtd/onenand/onenand_base.c | 12 +++--
drivers/mtd/tests/mtd_speedtest.c | 74 +++++++++++++++++++++++++++++++++--
drivers/mtd/tests/mtd_subpagetest.c | 10 ++--
3 files changed, 82 insertions(+), 14 deletions(-)
Regards
Adrian
^ permalink raw reply
* [PATCH 3/5] mtd: tests: add multiblock erase test to the mtd_speedtest
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
In-Reply-To: <1297159362-8407-1-git-send-email-adrian.hunter@nokia.com>
From: Roman Tereshonkov <roman.tereshonkov@nokia.com>
New multiblock erase speed test is added to mtd_speedtest.
It consists of 2-, 4-, 8-, 16-, 32- and 64-blocks at once
multiblock erase tests.
Signed-off-by: Roman Tereshonkov <roman.tereshonkov@nokia.com>
---
drivers/mtd/tests/mtd_speedtest.c | 59 +++++++++++++++++++++++++++++++++++-
1 files changed, 57 insertions(+), 2 deletions(-)
diff --git a/drivers/mtd/tests/mtd_speedtest.c b/drivers/mtd/tests/mtd_speedtest.c
index 9bd986e..3ce6fce 100644
--- a/drivers/mtd/tests/mtd_speedtest.c
+++ b/drivers/mtd/tests/mtd_speedtest.c
@@ -94,6 +94,33 @@ static int erase_eraseblock(int ebnum)
return 0;
}
+static int multiblock_erase(int ebnum, int blocks)
+{
+ int err;
+ struct erase_info ei;
+ loff_t addr = ebnum * mtd->erasesize;
+
+ memset(&ei, 0, sizeof(struct erase_info));
+ ei.mtd = mtd;
+ ei.addr = addr;
+ ei.len = mtd->erasesize * blocks;
+
+ err = mtd->erase(mtd, &ei);
+ if (err) {
+ printk(PRINT_PREF "error %d while erasing EB %d, blocks %d\n",
+ err, ebnum, blocks);
+ return err;
+ }
+
+ if (ei.state == MTD_ERASE_FAILED) {
+ printk(PRINT_PREF "some erase error occurred at EB %d,"
+ "blocks %d\n", ebnum, blocks);
+ return -EIO;
+ }
+
+ return 0;
+}
+
static int erase_whole_device(void)
{
int err;
@@ -292,7 +319,10 @@ static long calc_speed(void)
ms = (finish.tv_sec - start.tv_sec) * 1000 +
(finish.tv_usec - start.tv_usec) / 1000;
k = goodebcnt * mtd->erasesize / 1024;
- speed = (k * 1000) / ms;
+ if (ms)
+ speed = (k * 1000) / ms;
+ else
+ speed = 0;
return speed;
}
@@ -325,7 +355,7 @@ out:
static int __init mtd_speedtest_init(void)
{
- int err, i;
+ int err, i, blocks, j, k;
long speed;
uint64_t tmp;
@@ -495,6 +525,31 @@ static int __init mtd_speedtest_init(void)
speed = calc_speed();
printk(PRINT_PREF "erase speed is %ld KiB/s\n", speed);
+ /* Multi-block erase all eraseblocks */
+ for (k = 1; k < 7; k++) {
+ blocks = 1 << k;
+ printk(PRINT_PREF "Testing %dx multi-block erase speed\n",
+ blocks);
+ start_timing();
+ for (i = 0; i < ebcnt; ) {
+ for (j = 0; j < blocks && (i + j) < ebcnt; j++)
+ if (bbt[i + j])
+ break;
+ if (j < 1) {
+ i++;
+ continue;
+ }
+ err = multiblock_erase(i, j);
+ if (err)
+ goto out;
+ cond_resched();
+ i += j;
+ }
+ stop_timing();
+ speed = calc_speed();
+ printk(PRINT_PREF "%dx multi-block erase speed is %ld KiB/s\n",
+ blocks, speed);
+ }
printk(PRINT_PREF "finished\n");
out:
kfree(iobuf);
--
1.7.0.4
^ permalink raw reply related
* [PATCH 1/5] mtd: OneNAND: return read error for 4KiB page read
From: Adrian Hunter @ 2011-02-08 10:02 UTC (permalink / raw)
To: David Woodhouse
Cc: Kyungmin Park, Adrian Hunter, linux-mtd Mailing List,
Roman Tereshonkov, Artem Bityutskiy
In-Reply-To: <1297159362-8407-1-git-send-email-adrian.hunter@nokia.com>
When reading using the 4KiB page read function, I/O
errors could be ignored if more than 1 page was read
at a time.
Signed-off-by: Adrian Hunter <adrian.hunter@nokia.com>
---
drivers/mtd/onenand/onenand_base.c | 2 ++
1 files changed, 2 insertions(+), 0 deletions(-)
diff --git a/drivers/mtd/onenand/onenand_base.c b/drivers/mtd/onenand/onenand_base.c
index bac41ca..38e6d76 100644
--- a/drivers/mtd/onenand/onenand_base.c
+++ b/drivers/mtd/onenand/onenand_base.c
@@ -1132,6 +1132,8 @@ static int onenand_mlc_read_ops_nolock(struct mtd_info *mtd, loff_t from,
onenand_update_bufferram(mtd, from, !ret);
if (ret == -EBADMSG)
ret = 0;
+ if (ret)
+ break;
}
this->read_bufferram(mtd, ONENAND_DATARAM, buf, column, thislen);
--
1.7.0.4
^ permalink raw reply related
* Re: Fwd: Fwd: [PATCH]Maintain Chinese Documentations♫
From: Harry Wei @ 2011-02-08 10:01 UTC (permalink / raw)
To: linux-kernel, akpm, joe, davem, greg, rdunlap, xiyou.wangcong,
w.sang
In-Reply-To: <AANLkTi=RgPS_tzBP+0=wxuh58cV=3_m+5=gYwG8ffkY0@mail.gmail.com>
> ---------- Forwarded message ----------
> From: Wolfram Sang <w.sang@pengutronix.de>
> Date: 2011/2/8
> Subject: Re: Fwd: [PATCH]Maintain Chinese Documentations
> To: Harry Wei <jiaweiwei.xiyou@gmail.com>
> Cc: linux-kernel@vger.kernel.org, xiyou.wangcong@gmail.com
>
>
> > > > +L: xiyoulinuxkernelgroup@googlegroups.com
> > >
> > > NAK.
> > >
> > > Clearly linux-kernel@zh-kernel.org is more "official".
>
> > Hi Brother Wang, I have mailed to linux-kernel@zh-kernel.org for some
> > translation problems but there is no response. So ... In fact, any
> > mailing list is ok if they are absolutely interested in kernel. We
> > will also send our translations for kernel-docs to
> > linux-kernel@zh-kernel.org. After talking with them we will patch for
> > kernel :)
>
> If it helps the case, you could also have two "L:" entries?
A good idea :)
Updated patcher like following.
Thanks.
Best Regards.
Harry Wei.
Signed-off-by: Harry Wei <harryxiyou@gmail.com>
Acked-by: Randy Dunlap <rdunlap@xenotime.net>
Acked-by: Wang Cong <xiyou.wangcong@gmail.com>
Acked-by: Wolfram Sang <w.sang@pengutronix.de>
---
MAINTAINERS | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/MAINTAINERS b/MAINTAINERS
index dc0279e..afb6f7c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -1692,6 +1692,12 @@ M: Andy Whitcroft <apw@canonical.com>
S: Supported
F: scripts/checkpatch.pl
+CHINESE DOCUMENTATION
+M: Harry Wei <harryxiyou@gmail.com>
+L: xiyoulinuxkernelgroup@googlegroups.com
+L: linux-kernel@zh-kernel.org(moderated for non-subscribers)
+S: Maintained
+F: Documentation/zh_CN/
+
CISCO VIC ETHERNET NIC DRIVER
M: Vasanthy Kolluri <vkolluri@cisco.com>
M: Roopa Prabhu <roprabhu@cisco.com>
--
1.7.0.4
>
> --
> Pengutronix e.K. | Wolfram Sang |
> Industrial Linux Solutions | http://www.pengutronix.de/ |
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk1RDmAACgkQD27XaX1/VRt4UACgmAEnPGGDTzAivTBUI0+ce+8A
> kv8An3QIH0SbS8LxZ2kkjna6anoHlRpZ
> =TCxh
> -----END PGP SIGNATURE-----
>
>
>
>
> --
> Best Regards.
> Harry Wei.
> Do what u like!
^ permalink raw reply related
* Re: I do not know if this is the correct place to ask about this but...
From: Borislav Petkov @ 2011-02-08 10:00 UTC (permalink / raw)
To: dave b; +Cc: Linux Kernel, borislav.petkov
In-Reply-To: <AANLkTi=1wjdu3kT6nimU0fnZStG01a57D3O5Up+oJRdr@mail.gmail.com>
On Tue, Feb 08, 2011 at 08:31:50PM +1100, dave b wrote:
> I do not know if this is the correct place to ask about this but...
> I have only seen the following output output twice and both times have
> been when I was running a 2.6.37 kernel.
>
> [152399.816058] [Hardware Error]: MC4_STATUS: Corrected error, other
> errors lost: no, CPU context corrupt: no, CECC Error
> [152399.816075] [Hardware Error]: Northbridge Error, node 0: , core:
> 1L3 ECC data cache error.
> [152399.816086] [Hardware Error]: Transaction: RD, Type: GEN, Cache
> Level: L3/GEN
> [152399.816092] Disabling lock debugging due to kernel taint
> [152399.816099] [Hardware Error]: Machine check events logged
>
> I assume it is just a coincidence. Also, I am not exactly sure what
> the message "means". (Yes I can read the text - but I haven't found
> good documentation which describes the impact it). Note: I submitted a
> bug[0] regarding 'the output' the first time this occurrence.
This is a L3 cache correctable error on an AMD F10h machine I'd guess.
You could go and install x86info from
http://codemonkey.org.uk/projects/x86info/ and do as root
for i in $(seq 0 3); do echo -e "\nCPU$i:"; lsmsr -c $i -a; done > lsmsr.log
[ ($seq 0 3) assumes you have 4 cores, adjust it according to your
machine. Also, you need msr.ko module support, i.e. CONFIG_X86_MSR in
your kernel .config. ]
and send me the lsmsr.log file to check whether there is some more info
about the L3 error.
If you don't have the msr.ko support (or CONFIG_X86_MSR is not set
to y in your config) that tool won't help. In that case, I'd suggest
you upgrade your kernel to 2.6.38-rc4 which is stable enough, enable
CONFIG_X86_MSR and catch the error again. Then retry the small bash
oneliner above again.
That should be all for now, feel free to ask questions should anything
be not clear.
Thanks.
--
Regards/Gruss,
Boris.
^ permalink raw reply
* [Qemu-devel] [PATCH] Handle icount for powerpc tbl/tbu/decr load and store.
From: Tristan Gingold @ 2011-02-08 9:59 UTC (permalink / raw)
To: qemu-devel
Handle option '-icount X' on powerpc targets.
Signed-off-by: Tristan Gingold <gingold@adacore.com>
---
target-ppc/translate_init.c | 36 ++++++++++++++++++++++++++++++++++++
1 files changed, 36 insertions(+), 0 deletions(-)
diff --git a/target-ppc/translate_init.c b/target-ppc/translate_init.c
index 907535e..7ef86ad 100644
--- a/target-ppc/translate_init.c
+++ b/target-ppc/translate_init.c
@@ -154,12 +154,24 @@ static void spr_read_ureg (void *opaque, int gprn, int sprn)
#if !defined(CONFIG_USER_ONLY)
static void spr_read_decr (void *opaque, int gprn, int sprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_load_decr(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
static void spr_write_decr (void *opaque, int sprn, int gprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_store_decr(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
#endif
@@ -167,12 +179,24 @@ static void spr_write_decr (void *opaque, int sprn, int gprn)
/* Time base */
static void spr_read_tbl (void *opaque, int gprn, int sprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_load_tbl(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
static void spr_read_tbu (void *opaque, int gprn, int sprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_load_tbu(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
__attribute__ (( unused ))
@@ -190,12 +214,24 @@ static void spr_read_atbu (void *opaque, int gprn, int sprn)
#if !defined(CONFIG_USER_ONLY)
static void spr_write_tbl (void *opaque, int sprn, int gprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_store_tbl(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
static void spr_write_tbu (void *opaque, int sprn, int gprn)
{
+ if (use_icount)
+ gen_io_start();
gen_helper_store_tbu(cpu_gpr[gprn]);
+ if (use_icount) {
+ gen_io_end();
+ gen_stop_exception(opaque);
+ }
}
__attribute__ (( unused ))
--
1.7.3.GIT
^ permalink raw reply related
* Re: [PATCH] ARM: omap1/nokia770: mark some functions __init
From: Uwe Kleine-König @ 2011-02-08 9:59 UTC (permalink / raw)
To: Tony Lindgren; +Cc: linux-omap, linux-arm-kernel
In-Reply-To: <20110203081508.GC30452@pengutronix.de>
On Thu, Feb 03, 2011 at 09:15:08AM +0100, Uwe Kleine-König wrote:
> Hey Tony,
>
> this patch below is now 4 months old and I didn't get any feedback. (Though I
> somehow missed to cc linux-omap@vger.kernel.org before, sorry for that.)
>
> There are two more patches in this thread that are not yet
> applied/commented. Should I resend?
ping
--
Pengutronix e.K. | Uwe Kleine-König |
Industrial Linux Solutions | http://www.pengutronix.de/ |
--
To unsubscribe from this list: send the line "unsubscribe linux-omap" 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] ARM: omap1/nokia770: mark some functions __init
From: Uwe Kleine-König @ 2011-02-08 9:59 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110203081508.GC30452@pengutronix.de>
On Thu, Feb 03, 2011 at 09:15:08AM +0100, Uwe Kleine-K?nig wrote:
> Hey Tony,
>
> this patch below is now 4 months old and I didn't get any feedback. (Though I
> somehow missed to cc linux-omap at vger.kernel.org before, sorry for that.)
>
> There are two more patches in this thread that are not yet
> applied/commented. Should I resend?
ping
--
Pengutronix e.K. | Uwe Kleine-K?nig |
Industrial Linux Solutions | http://www.pengutronix.de/ |
^ permalink raw reply
* [Qemu-devel] Re: [PATCH 2/7] Enable I/O thread and VNC threads by default
From: Aurelien Jarno @ 2011-02-08 9:58 UTC (permalink / raw)
To: Jan Kiszka
Cc: Anthony Liguori, Stefan Hajnoczi, Marcelo Tosatti,
qemu-devel@nongnu.org, Anthony Liguori, Paul Brook,
Edgar E. Iglesias, Paolo Bonzini, Arun Bharadwaj
In-Reply-To: <4D511221.9030505@siemens.com>
Jan Kiszka a écrit :
> On 2011-02-08 10:05, Aurelien Jarno wrote:
>> Jan Kiszka a écrit :
>>> On 2011-02-08 09:08, Paolo Bonzini wrote:
>>>> On 02/08/2011 08:26 AM, Aurelien Jarno wrote:
>>>>> I forget to remember when we decided that AIO should be implemented on
>>>>> any host OS. Any pointer?
>>>> To be fair, I/O-heavy workloads are almost unusable without AIO. For
>>>> Window targets, they also crash under SMP due to the Windows AP
>>>> watchdog. But then TCG and SMP do not go very well together anyway.
>>>>
>>>> However, I think deprecating Win32 support would be a very bad idea.
>>> It would be too early at this point.
>>>
>>> But if Windows is once the only reason to keep tons of hardly tested
>>> code paths around or to invest significant additional effort to change
>>> logic or interfaces in this area, than I would prefer that step. I'm
>>> hacking on IOTHREAD vs. !IOTHREAD for some weeks now, and all those
>>> subtle differences are really a PITA and source of various breakages.
>>>
>>> People interested in that platform should finally realize that its fate
>>> is coupled to reducing the #ifdefs as well as the design differences we
>>> see right now and even more in the future.
>>>
>> The guilty here is IOTHREAD. Windows support predates IOTHREAD concept,
>> it's just that people who introduce IOTHREAD didn't care about Windows
>> support at all and added these #ifdef. Disabling Windows support because
>> of that is not fair.
>
> The TCG execution model won't scale long-term. It's already a main to
> boot a quad or just dual core VM, even more when your host has at least
> as many real cores. I'm sure we'll see multi-threaded TCG CPUs in the
> future, and the iothread will just be one of 7, 17 or 257 threads.
>
And what's the issue with that? People don't always look for performance
when using QEMU. They even often try to emulate old machines (and non
x86 ones), which anyway only have one CPU. This won't change in 5 years,
the only thing is that those machines will be 5 years older.
People have to keep in mind that QEMU doesn't mean only virtualization
and doesn't mean only x86.
--
Aurelien Jarno GPG: 1024D/F1BCDB73
aurelien@aurel32.net http://www.aurel32.net
^ 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.