* Re: [PATCH] fs: make block fiemap mapping length at least blocksize long
From: Andrew Morton @ 2011-02-01 20:28 UTC (permalink / raw)
To: Steven Whitehouse; +Cc: Josef Bacik, linux-fsdevel
In-Reply-To: <1296560810.2586.12.camel@dolmen>
On Tue, 01 Feb 2011 11:46:50 +0000
Steven Whitehouse <swhiteho@redhat.com> wrote:
> On Wed, 2010-12-08 at 12:03 -0500, Josef Bacik wrote:
> > Some filesystems don't deal well with being asked to map less than blocksize
> > blocks (GFS2 for example). Since we are always mapping at least blocksize
> > sections anyway, just make sure len is at least as big as a blocksize so we
> > don't trip up any filesystems. Thanks,
> >
> > Signed-off-by: Josef Bacik <josef@redhat.com>
> > ---
> > fs/ioctl.c | 7 +++++++
> > 1 files changed, 7 insertions(+), 0 deletions(-)
> >
> > diff --git a/fs/ioctl.c b/fs/ioctl.c
> > index d6cc164..6b53c24 100644
> > --- a/fs/ioctl.c
> > +++ b/fs/ioctl.c
> > @@ -273,6 +273,13 @@ int __generic_block_fiemap(struct inode *inode,
> > len = isize;
> > }
> >
> > + /*
> > + * Some filesystems can't deal with being asked to map less than
> > + * blocksize, so make sure our len is at least block length.
> > + */
> > + if (logical_to_blk(inode, len) == 0)
> > + len = blk_to_logical(inode, 1);
> > +
> > start_blk = logical_to_blk(inode, start);
> > last_blk = logical_to_blk(inode, start + len - 1);
> >
(top-posting repaired)
> Hi,
>
> Is there any reason this cannot be sent to Linus now?
>
I sent it to viro a couple of weeks back and it was ignored. I don't
know why this happens :(
^ permalink raw reply
* Re: [PATCH v2] release kvmclock page on reset
From: Jan Kiszka @ 2011-02-01 20:28 UTC (permalink / raw)
To: Glauber Costa; +Cc: kvm, linux-kernel, aliguori
In-Reply-To: <1296587800-19589-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]
On 2011-02-01 20:16, Glauber Costa wrote:
> When a vcpu is reset, kvmclock page keeps being writen to this days.
> This is wrong and inconsistent: a cpu reset should take it to its
> initial state.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> CC: Jan Kiszka <jan.kiszka@siemens.com>
> ---
> arch/x86/kvm/x86.c | 20 ++++++++++++--------
> 1 files changed, 12 insertions(+), 8 deletions(-)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index bcc0efc..c39ab4a 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1453,6 +1453,14 @@ static int kvm_pv_enable_async_pf(struct kvm_vcpu *vcpu, u64 data)
> return 0;
> }
>
> +static void kvmclock_reset(struct kvm_vcpu *vcpu)
> +{
> + if (vcpu->arch.time_page) {
> + kvm_release_page_dirty(vcpu->arch.time_page);
> + vcpu->arch.time_page = NULL;
> + }
> +}
> +
> int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> {
> switch (msr) {
> @@ -1510,10 +1518,7 @@ int kvm_set_msr_common(struct kvm_vcpu *vcpu, u32 msr, u64 data)
> break;
> case MSR_KVM_SYSTEM_TIME_NEW:
> case MSR_KVM_SYSTEM_TIME: {
> - if (vcpu->arch.time_page) {
> - kvm_release_page_dirty(vcpu->arch.time_page);
> - vcpu->arch.time_page = NULL;
> - }
> + kvmclock_reset(vcpu);
>
> vcpu->arch.time = data;
> kvm_make_request(KVM_REQ_CLOCK_UPDATE, vcpu);
> @@ -5814,10 +5819,7 @@ void kvm_put_guest_fpu(struct kvm_vcpu *vcpu)
>
> void kvm_arch_vcpu_free(struct kvm_vcpu *vcpu)
> {
> - if (vcpu->arch.time_page) {
> - kvm_release_page_dirty(vcpu->arch.time_page);
> - vcpu->arch.time_page = NULL;
> - }
> + kvmclock_reset(vcpu);
>
> free_cpumask_var(vcpu->arch.wbinvd_dirty_mask);
> fx_free(vcpu);
> @@ -5878,6 +5880,8 @@ int kvm_arch_vcpu_reset(struct kvm_vcpu *vcpu)
> kvm_make_request(KVM_REQ_EVENT, vcpu);
> vcpu->arch.apf.msr_val = 0;
>
> + kvmclock_reset(vcpu);
> +
> kvm_clear_async_pf_completion_queue(vcpu);
> kvm_async_pf_hash_reset(vcpu);
> vcpu->arch.apf.halted = false;
Looks good.
Thanks,
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [Qemu-devel] Re: KVM call minutes for Feb 1
From: Anthony Liguori @ 2011-02-01 20:28 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Chris Wright, qemu-devel@nongnu.org, kvm@vger.kernel.org
In-Reply-To: <4D48443A.80108@siemens.com>
On 02/01/2011 11:34 AM, Jan Kiszka wrote:
> On 2011-02-01 18:20, Anthony Liguori wrote:
>
>> On 02/01/2011 11:03 AM, Jan Kiszka wrote:
>>
>>> On 2011-02-01 17:53, Anthony Liguori wrote:
>>>
>>>
>>>> On 02/01/2011 10:36 AM, Jan Kiszka wrote:
>>>>
>>>>
>>>>> On 2011-02-01 16:54, Chris Wright wrote:
>>>>>
>>>>>
>>>>>
>>>>>> KVM upstream merge: status, plans, coordination
>>>>>> - Jan has a git tree, consolidating
>>>>>> - qemu-kvm io threading is still an issue
>>>>>> - Anthony wants to just merge
>>>>>> - concerns with non-x86 arch and merge
>>>>>> - concerns with big-bang patch merge and following stability
>>>>>> - post 0.14 conversion to glib mainloop, non-upstreamed qemu-kvm will be
>>>>>> a problem if it's not there by then
>>>>>> - testing and nuances are still an issue (e.g. stefan berger's mmio read issue)
>>>>>> - qemu-kvm still evolving, needs to get sync'd or it will keep diverging
>>>>>> - 2 implementations of main init, cpu init, Jan has merged them into one
>>>>>> - qemu-kvm-x86.c file that's only a few hundred lines
>>>>>> - review as one patch to see the fundamental difference
>>>>>>
>>>>>>
>>>>>>
>>>>> More precisely, my current work flow is to pick some function(s), e.g.
>>>>> kvm_cpu_exec/kvm_run, and start wondering "What needs to be done to
>>>>> upstream so that qemu-kvm could use that implementation?". If they
>>>>> differ, the reasons need to be understood and patched away, either by
>>>>> fixing/enhancing upstream or simplifying qemu-kvm. Once the upstream
>>>>> changes are merged back, a qemu-kvm patch is posted to switch to that
>>>>> version.
>>>>>
>>>>> Any help will be welcome, either via review of my subtle regressions or
>>>>> on resolving concrete differences.
>>>>>
>>>>> E.g. posix-aio-compat.c: Why does qemu-kvm differ here? If it's because
>>>>> of its own iothread code, can we wrap that away or do we need to
>>>>> consolidate the threading code first? Or do we need to fix something in
>>>>> upstream?
>>>>>
>>>>>
>>>>>
>>>> I bet it's the eventfd thing. It's arbitrary. If you've got a small
>>>> diff post your series, I'd be happy to take a look at it and see what I
>>>> can explain.
>>>>
>>>>
>>>>
>>> Looks like it's around signalfd and its emulation:
>>>
>>>
>> I really meant the compatfd thing.
>>
>> signalfd can't really be emulated properly so in upstream we switched to
>> a pipe() which Avi didn't like.
>>
>> But with glib, this all goes away anyway so we should just drop the
>> qemu-kvm changes and use the upstream version. Once we enable I/O
>> thread in qemu.git, we no longer need to use signals for I/O completion
>> which I think everyone would agree is a better solution.
>>
> Don't understand: If we do not need SIGIO for AIO emulation in threaded
> mode, why wasn't that stubbed out already?
Historically, we used posix-aio which only notifies completion based on
signals.
However, because of the signal/select race, there's nothing useful that
can be done in the signal handler. So we then added signalfd such that
we could poll the signal safely from the select loop.
However, signalfd cannot be emulated reliably which was the approach we
had been using since signalfd is only available in newer kernels. So we
switched to having the signal handler write to a pipe() which gives us
an fd based notification mechanism. While qemu.git made that change,
qemu-kvm.git carried the signalfd version probably because we just
didn't argue about it enough back then.
Now, since we haven't used posix-aio in a very long time, there's really
no reason to go through this signal non-sense in the first place. We
can just make the helper threads write to a file descriptor (eventfd or
pipe). At one point, that's what we did in the tree. However, when TCG
does TB chaining, the only thing that will break a guest out of a tight
loop is a signal delivery. In single threaded TCG, if the guest doesn't
have a periodic timer enabled and issues an I/O operation, the
signalling is posix-aio-compat would break it out of the TB loop to let
it handle the completion. When we got rid of it, we broke these guests
with the symptom of I/Os not completing until you typed a key in the
serial console.
However, once we enable the I/O thread for TCG, the I/O thread can issue
a select() statement while the TCG thread is doing chaining. As long as
we send a signal to the TCG thread after select() returns and then wait
for qemu_mutex to be released, this problem doesn't exist anymore.
So enabling the I/O thread universally means we can drop signaling in
posix-aio.
Regards,
Anthony Liguori
> If that helps reducing
> worries about the signalfd emulation (which is likely a non-issue anyway
> as anyone with serious workload should run a kernel with such support).
>
> Jan
>
>
^ permalink raw reply
* [Qemu-devel] Re: [PATCH] make tsc stable over migration and machine start
From: Jan Kiszka @ 2011-02-01 20:26 UTC (permalink / raw)
To: Glauber Costa; +Cc: mtosatti, qemu-devel, kvm, avi
In-Reply-To: <1296587851-19621-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On 2011-02-01 20:17, Glauber Costa wrote:
> If the machine is stopped, we should not record two different tsc values
> upon a save operation. The same problem happens with kvmclock.
>
> But kvmclock is taking a different diretion, being now seen as a separate
> device. Since this is unlikely to happen with the tsc, I am taking the
> approach here of simply registering a handler for state change, and
> using a per-CPUState variable that prevents double updates for the TSC.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
> target-i386/cpu.h | 1 +
> target-i386/kvm.c | 19 ++++++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 6d619e8..7f1c4f8 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -732,6 +732,7 @@ typedef struct CPUX86State {
> uint32_t sipi_vector;
> uint32_t cpuid_kvm_features;
> uint32_t cpuid_svm_features;
> + uint8_t update_tsc;
bool please.
>
> /* in order to simplify APIC support, we leave this pointer to the
> user */
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index ecb8405..c3925be 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
>
> static int _kvm_arch_init_vcpu(CPUState *env);
>
> +static void cpu_update_state(void *opaque, int running, int reason)
> +{
> + CPUState *env = opaque;
> +
> + if (!running) {
> + env->update_tsc = 1;
> + }
> +}
> +
> +
Additional blank line.
> int kvm_arch_init_vcpu(CPUState *env)
> {
> int r;
> @@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
> }
> #endif
>
> + qemu_add_vm_change_state_handler(cpu_update_state, env);
> +
> return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
> }
>
> @@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
> msrs[n++].index = MSR_STAR;
> if (kvm_has_msr_hsave_pa(env))
> msrs[n++].index = MSR_VM_HSAVE_PA;
> - msrs[n++].index = MSR_IA32_TSC;
> +
> + if (env->update_tsc) {
> + msrs[n++].index = MSR_IA32_TSC;
> + env->update_tsc = 0;
> + }
> +
> #ifdef TARGET_X86_64
> if (lm_capable_kernel) {
> msrs[n++].index = MSR_CSTAR;
Not quite the logic I'm using for kvmclock:
cpu_update_state()
if running
tsc_valid = false;
kvm_get_msrs()
...
if (!tsc_valid)
read_tsc
tsc_valid = !vm_running;
That ensure we always read the tsc while the VM is running, and not only
after it was stopped (might otherwise be "surprising" when once
visualizing the MSRs).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: [PATCH] make tsc stable over migration and machine start
From: Jan Kiszka @ 2011-02-01 20:26 UTC (permalink / raw)
To: Glauber Costa; +Cc: kvm, qemu-devel, avi, mtosatti
In-Reply-To: <1296587851-19621-1-git-send-email-glommer@redhat.com>
[-- Attachment #1: Type: text/plain, Size: 2761 bytes --]
On 2011-02-01 20:17, Glauber Costa wrote:
> If the machine is stopped, we should not record two different tsc values
> upon a save operation. The same problem happens with kvmclock.
>
> But kvmclock is taking a different diretion, being now seen as a separate
> device. Since this is unlikely to happen with the tsc, I am taking the
> approach here of simply registering a handler for state change, and
> using a per-CPUState variable that prevents double updates for the TSC.
>
> Signed-off-by: Glauber Costa <glommer@redhat.com>
> ---
> target-i386/cpu.h | 1 +
> target-i386/kvm.c | 19 ++++++++++++++++++-
> 2 files changed, 19 insertions(+), 1 deletions(-)
>
> diff --git a/target-i386/cpu.h b/target-i386/cpu.h
> index 6d619e8..7f1c4f8 100644
> --- a/target-i386/cpu.h
> +++ b/target-i386/cpu.h
> @@ -732,6 +732,7 @@ typedef struct CPUX86State {
> uint32_t sipi_vector;
> uint32_t cpuid_kvm_features;
> uint32_t cpuid_svm_features;
> + uint8_t update_tsc;
bool please.
>
> /* in order to simplify APIC support, we leave this pointer to the
> user */
> diff --git a/target-i386/kvm.c b/target-i386/kvm.c
> index ecb8405..c3925be 100644
> --- a/target-i386/kvm.c
> +++ b/target-i386/kvm.c
> @@ -302,6 +302,16 @@ void kvm_inject_x86_mce(CPUState *cenv, int bank, uint64_t status,
>
> static int _kvm_arch_init_vcpu(CPUState *env);
>
> +static void cpu_update_state(void *opaque, int running, int reason)
> +{
> + CPUState *env = opaque;
> +
> + if (!running) {
> + env->update_tsc = 1;
> + }
> +}
> +
> +
Additional blank line.
> int kvm_arch_init_vcpu(CPUState *env)
> {
> int r;
> @@ -444,6 +454,8 @@ int kvm_arch_init_vcpu(CPUState *env)
> }
> #endif
>
> + qemu_add_vm_change_state_handler(cpu_update_state, env);
> +
> return kvm_vcpu_ioctl(env, KVM_SET_CPUID2, &cpuid_data);
> }
>
> @@ -1093,7 +1105,12 @@ static int kvm_get_msrs(CPUState *env)
> msrs[n++].index = MSR_STAR;
> if (kvm_has_msr_hsave_pa(env))
> msrs[n++].index = MSR_VM_HSAVE_PA;
> - msrs[n++].index = MSR_IA32_TSC;
> +
> + if (env->update_tsc) {
> + msrs[n++].index = MSR_IA32_TSC;
> + env->update_tsc = 0;
> + }
> +
> #ifdef TARGET_X86_64
> if (lm_capable_kernel) {
> msrs[n++].index = MSR_CSTAR;
Not quite the logic I'm using for kvmclock:
cpu_update_state()
if running
tsc_valid = false;
kvm_get_msrs()
...
if (!tsc_valid)
read_tsc
tsc_valid = !vm_running;
That ensure we always read the tsc while the VM is running, and not only
after it was stopped (might otherwise be "surprising" when once
visualizing the MSRs).
Jan
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 259 bytes --]
^ permalink raw reply
* Re: Selecting multiple radio access technologies in oFono
From: Aki Niemi @ 2011-02-01 20:25 UTC (permalink / raw)
To: ofono
In-Reply-To: <4D46C032.60405@tieto.com>
[-- Attachment #1: Type: text/plain, Size: 1909 bytes --]
Hi Paavo,
On Mon, 2011-01-31 at 15:59 +0200, ext Paavo Leinonen wrote:
> Could it be possible to extend current TechnologyPreference setting in
> radio-settings-api in a way which would enable user to limit usage of
> certain
> radio accesses? For example user could choose to limit technology usage to
> technologies like GSM and UMTS even if the LTE coverage would be available.
> Following value could be introduced to current API to enable this kind of
> selection:
>
> "gsm" Only GSM used for radio access.
> "umts" Only UMTS used for radio access.
> "gsm_umts" Only GSM or UMTS used for radio access.
> "lte" Only LTE used for radio access.
The current API has 'gsm', 'umts', 'lte' and 'any'. I think you are
suggesting something like 'all-but-lte', right?
> Other approach could be that we would rephrase existing API so that
> instead of
> using "only" LTE, we would use LTE whenever available and some older
> technology
> when LTE coverage is lacking. So user would select "highest" allowed radio
> access without restrictions to use only one technology which has been
> selected.
This is what 'any' essentially is for.
> This would save us from polluting value selection with options like
> "gsm_umts",
> a decision we'd be grateful when we'll run oFono on 10G modems. ;)
>
> Use case for this could be energy conservation. At least I have habit to set
> network preference to 'GSM' to conserve battery life when I know I'm
> going to
> travel places where 3G coverage is not that good or I'm not going to
> need it.
I think this will also get gradually better as networks and handsets are
upgraded to use better power saving features, such as CPC.
Cheers,
Aki
> Br,
> Paavo
>
> _______________________________________________
> ofono mailing list
> ofono(a)ofono.org
> http://lists.ofono.org/listinfo/ofono
^ permalink raw reply
* Re: Network performance with small packets
From: Shirley Ma @ 2011-02-01 20:25 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: David Miller, steved, netdev, kvm
In-Reply-To: <20110201201715.GA30050@redhat.com>
On Tue, 2011-02-01 at 22:17 +0200, Michael S. Tsirkin wrote:
> On Tue, Feb 01, 2011 at 12:09:03PM -0800, Shirley Ma wrote:
> > On Tue, 2011-02-01 at 19:23 +0200, Michael S. Tsirkin wrote:
> > > On Thu, Jan 27, 2011 at 01:30:38PM -0800, Shirley Ma wrote:
> > > > On Thu, 2011-01-27 at 13:02 -0800, David Miller wrote:
> > > > > > Interesting. Could this is be a variant of the now famuous
> > > > > bufferbloat then?
> > > > >
> > > > > Sigh, bufferbloat is the new global warming... :-/
> > > >
> > > > Yep, some places become colder, some other places become warmer;
> > > Same as
> > > > BW results, sometimes faster, sometimes slower. :)
> > > >
> > > > Shirley
> > >
> > > Sent a tuning patch (v2) that might help.
> > > Could you try it and play with the module parameters please?
> >
> > Hello Michael,
> >
> > Sure I will play with this patch to see how it could help.
> >
> > I am looking at guest side as well, I found a couple issues on guest
> > side:
> >
> > 1. free_old_xmit_skbs() should return the number of skbs instead of
> the
> > total of sgs since we are using ring size to stop/start netif queue.
> > static unsigned int free_old_xmit_skbs(struct virtnet_info *vi)
> > {
> > struct sk_buff *skb;
> > unsigned int len, tot_sgs = 0;
> >
> > while ((skb = virtqueue_get_buf(vi->svq, &len)) != NULL) {
> > pr_debug("Sent skb %p\n", skb);
> > vi->dev->stats.tx_bytes += skb->len;
> > vi->dev->stats.tx_packets++;
> > tot_sgs += skb_vnet_hdr(skb)->num_sg;
> > dev_kfree_skb_any(skb);
> > }
> > return tot_sgs; <---- should return numbers of skbs to track
> > ring usage here, I think;
> > }
> >
> > Did the old guest use number of buffers to track ring usage before?
> >
> > 2. In start_xmit, I think we should move capacity +=
> free_old_xmit_skbs
> > before netif_stop_queue(); so we avoid unnecessary netif queue
> > stop/start. This condition is heavily hit for small message size.
> >
> > Also we capacity checking condition should change to something like
> half
> > of the vring.num size, instead of comparing 2+MAX_SKB_FRAGS?
> >
> > if (capacity < 2+MAX_SKB_FRAGS) {
> > netif_stop_queue(dev);
> > if (unlikely(!virtqueue_enable_cb(vi->svq))) {
> > /* More just got used, free them then
> recheck.
> > */
> > capacity += free_old_xmit_skbs(vi);
> > if (capacity >= 2+MAX_SKB_FRAGS) {
> > netif_start_queue(dev);
> > virtqueue_disable_cb(vi->svq);
> > }
> > }
> > }
> >
> > 3. Looks like the xmit callback is only used to wake the queue when
> the
> > queue has stopped, right? Should we put a condition check here?
> > static void skb_xmit_done(struct virtqueue *svq)
> > {
> > struct virtnet_info *vi = svq->vdev->priv;
> >
> > /* Suppress further interrupts. */
> > virtqueue_disable_cb(svq);
> >
> > /* We were probably waiting for more output buffers. */
> > ---> if (netif_queue_stopped(vi->dev))
> > netif_wake_queue(vi->dev);
> > }
> >
> >
> > Shirley
>
> Well the return value is used to calculate capacity and that counts
> the # of s/g. No?
Nope, the current guest kernel uses descriptors not number of sgs. I am
not sure the old guest.
> From cache utilization POV it might be better to read from the skb and
> not peek at virtio header though...
> Pls Cc the lists on any discussions in the future.
>
> --
> MST
Sorry I missed reply all. :(
Shirley
^ permalink raw reply
* [GIT PULL] staging: tidspbridge for 2.6.39
From: Omar Ramirez Luna @ 2011-02-01 20:13 UTC (permalink / raw)
To: Greg Kroah-Hartman; +Cc: Omar Ramirez Luna, Felipe Contreras, lk, devel
The following changes since commit c56eb8fb6dccb83d9fe62fd4dc00c834de9bc470:
Linux 2.6.38-rc1 (2011-01-18 15:14:02 -0800)
are available in the git repository at:
git://dev.omapzoom.org/pub/scm/tidspbridge/kernel-dspbridge.git tidspbridge-for-2.6.39
Armando Uribe (6):
staging: tidspbridge: Eliminate direct manipulation of OMAP_SYSC_BASE
staging: tidspbridge: Remove unused defined constants
staging: tidspbridge: Remove unused functions
staging: tidspbridge: Remove unused structs
staging: tidspbridge: Remove unused typedefs
staging: tidspbridge: Remove trivial header files
Felipe Contreras (1):
staging: tidspbridge: fix mgr_enum_node_info
Guzman Lugo, Fernando (2):
staging: tidspbridge: configure full L1 MMU range
staging: tidspbridge: make sync_wait_on_event interruptible
Ionut Nicu (13):
staging: tidspbridge: mgr_enum_node_info cleanup
staging: tidspbridge: fix kernel oops in bridge_io_get_proc_load
staging: tidspbridge: remove gs memory allocator
staging: tidspbridge: remove utildefs
staging: tidspbridge: switch to linux bitmap API
staging: tidspbridge: remove gb bitmap implementation
staging: tidspbridge: convert core to list_head
staging: tidspbridge: convert pmgr to list_head
staging: tidspbridge: convert rmgr to list_head
staging: tidspbridge: remove custom linked list
staging: tidspbridge: core code cleanup
staging: tidspbridge: pmgr code cleanup
staging: tidspbridge: rmgr/node.c code cleanup
Laurent Pinchart (1):
staging: tidspbridge: Fix atoi to support hexadecimal numbers correctly
Omar Ramirez Luna (2):
staging: tidspbridge: replace mbox callback with notifier_call
staging: tidspbridge: use the right type for list_is_last
Ramos Falcon, Ernesto (1):
staging: tidspbridge: remove code referred by OPT_ZERO_COPY_LOADER
Rene Sapiens (12):
staging: tidspbridge: set1 remove hungarian from structs
staging: tidspbridge: set2 remove hungarian from structs
staging: tidspbridge: set3 remove hungarian from structs
staging: tidspbridge: set4 remove hungarian from structs
staging: tidspbridge: set5 remove hungarian from structs
staging: tidspbridge: set6 remove hungarian from structs
staging: tidspbridge: set7 remove hungarian from structs
staging: tidspbridge: set8 remove hungarian from structs
staging: tidspbridge: set9 remove hungarian from structs
staging: tidspbridge: set10 remove hungarian from structs
staging: tidspbridge: set11 remove hungarian from structs
staging: tidspbridge: set12 remove hungarian from structs
Sapiens, Rene (1):
staging: tidspbridge: overwrite DSP error codes
drivers/staging/tidspbridge/Makefile | 2 +-
drivers/staging/tidspbridge/TODO | 1 -
drivers/staging/tidspbridge/core/_deh.h | 2 +-
drivers/staging/tidspbridge/core/_msg_sm.h | 16 +-
drivers/staging/tidspbridge/core/_tiomap.h | 30 +-
drivers/staging/tidspbridge/core/chnl_sm.c | 676 ++++++-------
drivers/staging/tidspbridge/core/dsp-clock.c | 52 +-
drivers/staging/tidspbridge/core/io_sm.c | 680 ++++++-------
drivers/staging/tidspbridge/core/msg_sm.c | 619 +++++-------
drivers/staging/tidspbridge/core/tiomap3430.c | 214 ++--
drivers/staging/tidspbridge/core/tiomap3430_pwr.c | 112 +-
drivers/staging/tidspbridge/core/tiomap_io.c | 96 +-
drivers/staging/tidspbridge/core/ue_deh.c | 28 +-
drivers/staging/tidspbridge/dynload/cload.c | 102 +--
.../staging/tidspbridge/dynload/dload_internal.h | 6 +-
drivers/staging/tidspbridge/gen/gb.c | 166 ---
drivers/staging/tidspbridge/gen/gh.c | 38 +-
drivers/staging/tidspbridge/gen/gs.c | 88 --
drivers/staging/tidspbridge/gen/uuidutil.c | 22 +-
.../tidspbridge/include/dspbridge/_chnl_sm.h | 26 +-
.../tidspbridge/include/dspbridge/brddefs.h | 2 -
.../tidspbridge/include/dspbridge/cfgdefs.h | 50 +-
.../staging/tidspbridge/include/dspbridge/chnl.h | 21 -
.../tidspbridge/include/dspbridge/chnldefs.h | 9 +-
.../tidspbridge/include/dspbridge/chnlpriv.h | 21 +-
.../staging/tidspbridge/include/dspbridge/cmm.h | 2 +-
.../tidspbridge/include/dspbridge/cmmdefs.h | 39 +-
.../staging/tidspbridge/include/dspbridge/cod.h | 13 +-
.../tidspbridge/include/dspbridge/dbdcddef.h | 14 +-
.../staging/tidspbridge/include/dspbridge/dbdefs.h | 98 +--
.../tidspbridge/include/dspbridge/dbldefs.h | 141 ---
.../staging/tidspbridge/include/dspbridge/dbll.h | 6 -
.../tidspbridge/include/dspbridge/dblldefs.h | 65 --
.../tidspbridge/include/dspbridge/dehdefs.h | 32 -
.../staging/tidspbridge/include/dspbridge/dev.h | 65 +--
.../staging/tidspbridge/include/dspbridge/disp.h | 15 +-
.../tidspbridge/include/dspbridge/dispdefs.h | 35 -
.../staging/tidspbridge/include/dspbridge/drv.h | 40 +-
.../tidspbridge/include/dspbridge/drvdefs.h | 25 -
.../tidspbridge/include/dspbridge/dspapi-ioctl.h | 216 ++--
.../tidspbridge/include/dspbridge/dspdefs.h | 88 +-
.../staging/tidspbridge/include/dspbridge/dspdrv.h | 2 -
.../staging/tidspbridge/include/dspbridge/dspio.h | 4 +-
.../tidspbridge/include/dspbridge/dspioctl.h | 13 +-
.../tidspbridge/include/dspbridge/dynamic_loader.h | 2 -
drivers/staging/tidspbridge/include/dspbridge/gb.h | 79 --
drivers/staging/tidspbridge/include/dspbridge/gs.h | 59 --
.../tidspbridge/include/dspbridge/host_os.h | 9 -
drivers/staging/tidspbridge/include/dspbridge/io.h | 29 +-
.../staging/tidspbridge/include/dspbridge/io_sm.h | 164 +---
.../staging/tidspbridge/include/dspbridge/iodefs.h | 36 -
.../staging/tidspbridge/include/dspbridge/ldr.h | 29 -
.../staging/tidspbridge/include/dspbridge/list.h | 225 ----
.../staging/tidspbridge/include/dspbridge/mbx_sh.h | 40 -
.../tidspbridge/include/dspbridge/mgrpriv.h | 4 +-
.../tidspbridge/include/dspbridge/nldrdefs.h | 24 +-
.../staging/tidspbridge/include/dspbridge/node.h | 20 +-
.../tidspbridge/include/dspbridge/nodepriv.h | 10 +-
.../staging/tidspbridge/include/dspbridge/pwr.h | 8 +-
.../staging/tidspbridge/include/dspbridge/pwr_sh.h | 33 -
.../include/dspbridge/resourcecleanup.h | 11 -
.../staging/tidspbridge/include/dspbridge/rms_sh.h | 9 -
.../staging/tidspbridge/include/dspbridge/strm.h | 62 --
.../tidspbridge/include/dspbridge/strmdefs.h | 6 +-
.../staging/tidspbridge/include/dspbridge/sync.h | 14 +-
.../tidspbridge/include/dspbridge/utildefs.h | 39 -
drivers/staging/tidspbridge/pmgr/chnl.c | 4 +-
drivers/staging/tidspbridge/pmgr/cmm.c | 675 +++++-------
drivers/staging/tidspbridge/pmgr/cod.c | 20 +-
drivers/staging/tidspbridge/pmgr/dbll.c | 53 +-
drivers/staging/tidspbridge/pmgr/dev.c | 355 +++----
drivers/staging/tidspbridge/pmgr/dspapi.c | 272 +++---
drivers/staging/tidspbridge/pmgr/io.c | 9 +-
drivers/staging/tidspbridge/pmgr/ioobj.h | 4 +-
drivers/staging/tidspbridge/pmgr/msg.c | 4 +-
drivers/staging/tidspbridge/rmgr/dbdcd.c | 66 +-
drivers/staging/tidspbridge/rmgr/disp.c | 124 +--
drivers/staging/tidspbridge/rmgr/drv.c | 202 ++---
drivers/staging/tidspbridge/rmgr/drv_interface.c | 1 -
drivers/staging/tidspbridge/rmgr/mgr.c | 66 +-
drivers/staging/tidspbridge/rmgr/nldr.c | 117 +--
drivers/staging/tidspbridge/rmgr/node.c | 1092 +++++++++-----------
drivers/staging/tidspbridge/rmgr/proc.c | 170 ++--
drivers/staging/tidspbridge/rmgr/pwr.c | 8 +-
drivers/staging/tidspbridge/rmgr/rmm.c | 93 +--
drivers/staging/tidspbridge/rmgr/strm.c | 86 +-
86 files changed, 3028 insertions(+), 5297 deletions(-)
delete mode 100644 drivers/staging/tidspbridge/gen/gb.c
delete mode 100644 drivers/staging/tidspbridge/gen/gs.c
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dbldefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dehdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/dispdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/drvdefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/gb.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/gs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/iodefs.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/ldr.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/list.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/pwr_sh.h
delete mode 100644 drivers/staging/tidspbridge/include/dspbridge/utildefs.h
Regards,
Omar
^ permalink raw reply
* Re: [1.8.0] forbid full fetchspecs in git-pull
From: Dmitry Potapov @ 2011-02-01 20:23 UTC (permalink / raw)
To: Thomas Rast; +Cc: Junio C Hamano, git, Sean Estabrooks, Björn Steinbrink
In-Reply-To: <201102011614.57366.trast@student.ethz.ch>
On Tue, Feb 01, 2011 at 04:14:57PM +0100, Thomas Rast wrote:
> Dmitry Potapov wrote:
> > As to disallowing ':' in refspec completely, I am not so sure... Not
> > that I think it is very useful, but also I don't see how it can hurt
> > someone provided that the target branch cannot be the current branch.
>_
> IRC experience shows that people, while on some topic branch, run
>_
> git pull origin master:master
>_
> expecting it to "pull master into master" (or even worse with three
> different branch names). So no, the current branch safeguard does
> not prevent the fundamental mistake.
I am not sure what you mean by three different branches names. You
referred to item 1, and I agree it is confusing, but it can be prevented
by the current branch safeguard.
and the current semantic of "git pull" is very clear:
"git pull repo refspec" = "git fetch repo refspec && git merge FETCH_HEAD"
IMHO, the full confusion was caused by incorrect information on github,
which was corrected a long time ago. Have you heard about any new
users who are confused by git-pull?
And if we really want to disallow ':' in git pull refspec then the
documentation should be corrected too. For instance, if there are
options to git fetch that make no sense if you cannot specify lbranch.
Also description of refspec should be corrected in git pull man page.
Dmitry
^ permalink raw reply
* Kernel 2.6.32-5-amd64 fails to boot.
From: Leslie Rhorer @ 2011-02-01 20:23 UTC (permalink / raw)
To: 'Linux RAID'
I have been attempting to upgrade a Debian "Squeeze" Linux box from
2.6.32-3-amd64 to 2.6.32-5-amd64, but the upgrade is a non-starter. GRUB2
comes up just fine, but when I select the new kernel version, a number of
announcements flash by too fast to seen. I am not 100% certain, but I
believe the initrd starts to load OK. Some text flies by far too quickly to
be seen, but then an error pops up concerning an address space collision of
some PCI device. Then it shows three errors for RAID devices md1. md2, and
md3, saying they are already in use. Immediately thereafter the system shows
errors concerning the RAID targets being already in use, after which point
the system complains it can't mount / (md2), /dev, /sys, or /proc (in that
order) because the sources do not exist (if /dev/md2 does not exist, how can
it be busy?). Thereafter, of course, it fails to find init, since / is not
mounted. It then tries to run BusyBox, but Busybox complains:
/bin/sh: can't access tty; job control turned off
After that, it attempts to put up an initramfs prompt, but of course with no
tty access, it just hangs completely. Not surprisingly, recovery mode
doesn't boot, either. It gives a bit more detail in the output, but nothing
illuminating. The old kernel (2.6.32-3-amd64) boots just fine.
Obviously there is a problem in the initramfs, probably with mdadm, but
what? What should I try to manipulate in the initrd so I can find out what
is failing?
^ permalink raw reply
* Re: Features from GitSurvey 2010
From: Matthieu Moy @ 2011-02-01 20:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Dmitry S. Kravtsov, git, Jakub Narebski
In-Reply-To: <20110201184213.GF3771@burratino>
Jonathan Nieder <jrnieder@gmail.com> writes:
> An rcs-style workflow (lockable files absent from worktree until
> locked) on top of git sounds fun.
They need not be absent, they can just be read-only (and lock would do
a chmod u+w on the file).
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* [lm-sensors] How to distinguish sensors on Xeon multi-socket system
From: Alexey Chernov @ 2011-02-01 20:23 UTC (permalink / raw)
To: lm-sensors
Hello,
I have two socket motherboard with two Xeon's 5345 installed on them, so
overall it's 8 cores. Using lm_sensors all of them are detected correctly out
of the box, but the problem is that after certain Linux kernel upgrade (I
believe it's somewhere around 2.6.32) matching kernel on both processors
started to be called identically. I have two 'Core 0', two 'Core 1' etc. and
it drives mad many applications which use lm_sensors. Here's the output of
'sensors' command:
sensors
radeon-pci-0700
Adapter: PCI adapter
temp1: +77.0°C
coretemp-isa-0000
Adapter: ISA adapter
Core 0: +70.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0001
Adapter: ISA adapter
Core 2: +63.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0002
Adapter: ISA adapter
Core 0: +69.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0003
Adapter: ISA adapter
Core 2: +69.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0004
Adapter: ISA adapter
Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0005
Adapter: ISA adapter
Core 3: +65.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0006
Adapter: ISA adapter
Core 1: +68.0°C (high = +86.0°C, crit = +100.0°C)
coretemp-isa-0007
Adapter: ISA adapter
Core 3: +67.0°C (high = +86.0°C, crit = +100.0°C)
I try to fix the KDE sensors applet as it shows only 4 cores and ignores
remaining ones due to name collision. But I really don't know how to
distinguish the certain cores of the processors. Could you please give me a
reference how can I tell, for instance one 'Core 0' from another? The ideal
case is if they can be addressed as 'Processor 1/Core 0' but I can't find the
right way.
Thanks in advance!
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:21 UTC (permalink / raw)
To: Russell King - ARM Linux
Cc: Uwe Kleine-König, Nicolas Pitre, Dima Zavin,
Lorenzo Pieralisi, Vincent Guittot, linux-sh, Ben Herrenschmidt,
Sascha Hauer, Paul Mundt, linux-kernel, Ben Dooks, Jeremy Kerr,
linux-arm-kernel
In-Reply-To: <20110201195604.GS31216@n2100.arm.linux.org.uk>
On 02/01/2011 11:56 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-König wrote:
>> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
>>> So? You're not _supposed_ to call it from any atomic context ever.
>>
>> My motivation for a more complicated clk_prepare was to make clk_prepare
>> atomic when that's possible (i.e. when the clk is already prepared) and
>> call it before the enable callback in clk_enable. Then everything
>> behaves nicely even if clk_enable is called from atomic context provided
>> that the clock was prepared before (or doesn't need to).
>
> You really don't get the point of clk_prepare() do you. I'm not
> going to bother trying to educate you anymore.
>
> Hopefully someone with more patience can give you the necessary
> teaching to make you understand.
Uwe,
If the driver is calling clk_prepare() right next to clk_enable()
knowing it's been already prepared and will hence be "atomic" (this is
actually not true), then by your description, it's pointless to call
clk_prepare().
If you want the driver to call clk_prepare() in atomic context because
it will be atomic in most cases -- well, that's wrong. It's either
atomic or is NOT atomic. There is no in between. If a call is NOT
atomic, it can't be called in atomic context. Long story short, if you
expect clk_prepare() to be atomic under any circumstance, it beats the
point of introducing clk_prepare().
Hope I helped.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201195604.GS31216@n2100.arm.linux.org.uk>
On 02/01/2011 11:56 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-K?nig wrote:
>> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
>>> So? You're not _supposed_ to call it from any atomic context ever.
>>
>> My motivation for a more complicated clk_prepare was to make clk_prepare
>> atomic when that's possible (i.e. when the clk is already prepared) and
>> call it before the enable callback in clk_enable. Then everything
>> behaves nicely even if clk_enable is called from atomic context provided
>> that the clock was prepared before (or doesn't need to).
>
> You really don't get the point of clk_prepare() do you. I'm not
> going to bother trying to educate you anymore.
>
> Hopefully someone with more patience can give you the necessary
> teaching to make you understand.
Uwe,
If the driver is calling clk_prepare() right next to clk_enable()
knowing it's been already prepared and will hence be "atomic" (this is
actually not true), then by your description, it's pointless to call
clk_prepare().
If you want the driver to call clk_prepare() in atomic context because
it will be atomic in most cases -- well, that's wrong. It's either
atomic or is NOT atomic. There is no in between. If a call is NOT
atomic, it can't be called in atomic context. Long story short, if you
expect clk_prepare() to be atomic under any circumstance, it beats the
point of introducing clk_prepare().
Hope I helped.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: Locking in the clk API, part 2: clk_prepare/clk_unprepare
From: Saravana Kannan @ 2011-02-01 20:21 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20110201195604.GS31216@n2100.arm.linux.org.uk>
On 02/01/2011 11:56 AM, Russell King - ARM Linux wrote:
> On Tue, Feb 01, 2011 at 08:32:01PM +0100, Uwe Kleine-König wrote:
>> On Tue, Feb 01, 2011 at 05:06:37PM +0000, Russell King - ARM Linux wrote:
>>> So? You're not _supposed_ to call it from any atomic context ever.
>>
>> My motivation for a more complicated clk_prepare was to make clk_prepare
>> atomic when that's possible (i.e. when the clk is already prepared) and
>> call it before the enable callback in clk_enable. Then everything
>> behaves nicely even if clk_enable is called from atomic context provided
>> that the clock was prepared before (or doesn't need to).
>
> You really don't get the point of clk_prepare() do you. I'm not
> going to bother trying to educate you anymore.
>
> Hopefully someone with more patience can give you the necessary
> teaching to make you understand.
Uwe,
If the driver is calling clk_prepare() right next to clk_enable()
knowing it's been already prepared and will hence be "atomic" (this is
actually not true), then by your description, it's pointless to call
clk_prepare().
If you want the driver to call clk_prepare() in atomic context because
it will be atomic in most cases -- well, that's wrong. It's either
atomic or is NOT atomic. There is no in between. If a call is NOT
atomic, it can't be called in atomic context. Long story short, if you
expect clk_prepare() to be atomic under any circumstance, it beats the
point of introducing clk_prepare().
Hope I helped.
-Saravana
--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.
^ permalink raw reply
* Re: [1.8.0] reorganize the mess that the source tree has become
From: Jonathan Nieder @ 2011-02-01 11:22 UTC (permalink / raw)
To: Thomas Rast; +Cc: Nicolas Pitre, Jeff King, Junio C Hamano, git
In-Reply-To: <20110201111429.GA10165@elie>
Jonathan Nieder wrote:
> mkdir output
> cd output
> echo COMPUTE_HEADER_DIRECTORIES=1 >config.mak
> make -f ../Makefile GIT_SRC=$(pwd)/../ -j2
Erm, COMPUTE_HEADER_DEPENDENCIES. Anyway, if someone wants to make
setting GIT_SRC take care of making the directories automatically, I
wouldn't mind. ;-)
^ permalink raw reply
* Bootable Raid-1
From: Naira Kaieski @ 2011-02-01 20:20 UTC (permalink / raw)
To: linux-raid
Hi,
I have read several articles on the internet and researched in the
messages list, but I'm still having trouble configuring a raid level 1
array that is bootable.
I configured a server some time agowith Gentoo Linux, Kernel
2.6.28-hardened-r9, mdadm - v3.0 and 2 IDE hard drives, this is working
correctly. For this installation iused as a basis for consultation
Article http://en.gentoo-wiki.com/wiki/Migrate_to_RAID
Now, I want to use two SATA drives in raid level 1,
Now i have Gentoo Linux with kernel 2.6.36-hardened-r6 and mdadm -
v3.1.4 and the instructions of Article dont work. The kernel was
configured with support for disks raid autodetect and supported the raid
level 1. But in the logs of dmesg does not run the auto-detection of the
disks to the array, so in the boot when mounting the root device /
dev/md2 the system can not find the device.
When I run mdadm - auto-detect the array are found somewhere but still
displays message indicating that the raid device is not a valid
partition table.
How can you configure a raid level 1 with bootable disks / dev / sda and
/ dev / sdb?
I want three partitions:
/dev/md1 - swap - /dev/sda1, /dev/sdb1
/dev/md2 - boot - /dev/sda2, /dev/sdb2
/dev/md3 - / - /dev/sda3, /dev/sdb3
I am using grub as bootloader.
Thanks,
Naira Kaieski
^ permalink raw reply
* [U-Boot] [PATCH] Introduce a new linker flag LDFLAGS_FINAL
From: Wolfgang Denk @ 2011-02-01 20:20 UTC (permalink / raw)
To: u-boot
In-Reply-To: <20110201135136.0817fe5a@udp111988uds.am.freescale.net>
Dear Scott Wood,
In message <20110201135136.0817fe5a@udp111988uds.am.freescale.net> you wrote:
>
> > > Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was
> > > used? So before, anything that board/cpu code adds directly to LDFLAGS
> > > (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was
> > > used in the final link. After 8aba9dc, only things in
> > > PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.
> >
> > And this is correct for all boards?
>
> By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the
> switch back to LDFLAGS? It's not obvious to me that the dropping of
I don;t understand why you contine to talk about "switch to
PLATFORM_LDFLAGS in 8aba9dc". There was no such switch - at least I
cannot see it.
I see only a switch in your patch. This is why I'm asking.
Best regards,
Wolfgang Denk
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically
Charged Particles Moving at Velocities in Excess of Five Hundred
Million Miles Per Hour.
^ permalink raw reply
* Re: [PATCH v2 4/6] KVM-GST: KVM Steal time registration
From: Venkatesh Pallipadi @ 2011-02-01 20:20 UTC (permalink / raw)
To: Peter Zijlstra
Cc: Glauber Costa, Avi Kivity, kvm, linux-kernel, aliguori,
Rik van Riel, Jeremy Fitzhardinge
In-Reply-To: <1296582252.26581.255.camel@laptop>
On Tue, Feb 1, 2011 at 9:44 AM, Peter Zijlstra <peterz@infradead.org> wrote:
> On Tue, 2011-02-01 at 15:00 -0200, Glauber Costa wrote:
>>
>> > What you can do is: steal_ticks = steal_time_clock() / TICK_NSEC, or
>> > simply keep a steal time delta and every time it overflows
>> > cputime_one_jiffy insert a steal-time tick.
>>
>> What do you think about keeping accounting in msec/usec resolution and
>> (thus allowing us to compute half a tick to user/system, other half to
>> steal time) only change it to cputime in the last minute?
>
> its only accounting full tick..
>
Yes. The way we ended up dealing with this in irq time case is track
it in fine granularity and accumulate over time (internally) but
account it (make it visible externally) only in terms of ticks, only
when the value being accumulated crosses the tick boundary. This does
has a hole when we use 99% of time on tick on irq and use 1% just
before the tick on some system, then whole tick will be system and on
next tick if there is 1% irq and 99% system then that will be
accounted as irq as our accumulated value crosses the tick boundary
then. But, such holes on avg should not be worse than not having fine
granularity.
Thanks,
Venki
^ permalink raw reply
* Re: [PATCH] TODO: SMS Validity Period
From: Aki Niemi @ 2011-02-01 20:19 UTC (permalink / raw)
To: ofono
In-Reply-To: <1296477735.1520.202.camel@aeonflux>
[-- Attachment #1: Type: text/plain, Size: 1419 bytes --]
Hi Marcel,
On Mon, 2011-01-31 at 13:42 +0100, ext Marcel Holtmann wrote:
> > > How does a normal user actually know what this means for him and the
> > > network he is using? Is the network actually honoring these values at
> > > all these days?
> >
> > These are not clear to me either, so I don't see the point in exposing
> > this setting over the D-Bus interface. I would, however, err on the
> > side of flexibility here, and make this a configuration option in
> > main.conf (once that support is available in oFono).
>
> we did talk a bit about expected operator defaults especially in the
> context of default character set etc. I think Portugal is such an
> exception where you have to start out with a proper character set if
> your SIM card is originated from there.
>
> Maybe this is another one case where just picking a proper operator
> default is better than actually providing any option to change it.
Yes, some of these language variants are mandated by certain regulators,
some by operators. So certainly the default SMS alphabet should be a
main.conf item.
Whether or not to provide a corresponding D-Bus property is then a
separate question. Neither the validity period nor the alphabet strike
me as ones desperately needing a property, but especially the alphabet
might actually need one since it has such nasty backwards compatibility
issues.
Cheers,
Aki
^ permalink raw reply
* Re: User space RAID-6 access
From: NeilBrown @ 2011-02-01 20:18 UTC (permalink / raw)
To: Piergiorgio Sartor; +Cc: linux-raid
In-Reply-To: <20110201192154.GA2696@lazy.lzy>
On Tue, 1 Feb 2011 20:21:54 +0100 Piergiorgio Sartor
<piergiorgio.sartor@nexgo.de> wrote:
> On Tue, Feb 01, 2011 at 07:52:59AM +1100, NeilBrown wrote:
> > On Mon, 31 Jan 2011 21:20:55 +0100 Piergiorgio Sartor
> > <piergiorgio.sartor@nexgo.de> wrote:
> >
> > > Hi all,
> > >
> > > some times ago, I think was Neil, it was mentioned
> > > about the possibility to access consistently a RAID-6
> > > array from user space, in order to be able to perform
> > > some checks, like the notorius "which HDD has wrong data".
> > >
> > > Is there any reference or documentation or source code
> > > which can be taken as example for such a case?
> > >
> >
> > Look in the mdadm source code, particularly at restripe.c
> >
> > Also
> > make test_stripe
> >
> > make a program the the test suite uses for verify data correctness.
> >
> > That should give you enough hints to get you started.
>
>
> Hi Neil, thanks for the pointer.
>
> I had a look at the code and there is something I did not get.
>
> It seems to me the HDDs composing the array are "simply"
> opened with "open".
>
> In case the array is in use, how is avoided a race condition
> between the "test_stripe" program and the md device?
>
> I mean, the first could start to read from the HDDs and the
> other could write something in the same place, leading to an
> inconsistent parity, from the "test_stripe" point of view,
> since it missed some update.
>
> Or there is a locking inside md (in "test_stripe" I could
> not see and it would also be dangerous)?
>
> Thanks again,
>
> bye,
>
I didn't realise that you wanted to look at the members of the array while
the array was active!! That is a bit harder. But not impossible.
If you write a couple of numbers to 'suspend_lo' and 'suspend_hi' in sysfs,
then writes to blocks between those two array addresses will be blocked.
So you could suspend a region, look at the blocks, then un-suspend.
NeilBrown
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 0/2] virtagent - fsfreeze support
From: Richard W.M. Jones @ 2011-02-01 20:17 UTC (permalink / raw)
To: Vasiliy G Tolstov; +Cc: mdroth, Jes.Sorensen, qemu-devel, agl
In-Reply-To: <1296590687.8629.8.camel@mobile>
On Tue, Feb 01, 2011 at 11:04:47PM +0300, Vasiliy G Tolstov wrote:
> On Tue, 2011-02-01 at 16:04 +0000, Richard W.M. Jones wrote:
>
> > There are some experimental patches to libguestfs to do live
> > filesystem and partition manipulations now:
> >
> > https://www.redhat.com/archives/libguestfs/2011-January/msg00096.html
> >
> > Rich.
> >
>
> Sorry, but i can't found any info about operating on already mounted
> disk. As i known, libguestfs allows operating inside virtual machine via
> userspace daemon.
Yes you're right that 'guestfsd' running in the guest cannot change
the partition table seen by the kernel when partitions are mounted as
filesystems. This would require some changes to the kernel.
I was just pointing out you can use libguestfs "live" now and do a
huge range of filesystem operations, including changing the partition
table on disk.
Rich.
--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org
^ permalink raw reply
* Re: What's the typical RAID10 setup?
From: Keld Jørn Simonsen @ 2011-02-01 20:16 UTC (permalink / raw)
To: Roberto Spadim; +Cc: Keld Jørn Simonsen, David Brown, linux-raid
In-Reply-To: <AANLkTim_JD8g9Kcg8xrBSEQCRrD3K-sTQNjPPBg=2ckS@mail.gmail.com>
On Tue, Feb 01, 2011 at 04:09:03PM -0200, Roberto Spadim wrote:
> ok, but you are wrong...
> > well, raid0 is for reading sequentially, about double as fast as raid1.
> > https://raid.wiki.kernel.org/index.php/Performance
>
> it?s true for a mix of write/read (write is the time of slowest drive)
>
> but if you just read, raid0 and raid1 have the same read time (depend
> on implementation, but can have the same speed)
For sequential reading, this is not true. For random reading and
writing I agree with you in theory, but benchmarks show that it is not
so, at least for Linux RAID, viz the above URL.
Have you got benchmarks to shed some light on this?
best regards
keld
^ permalink raw reply
* Re: Patch to fix backlight on GM45
From: Niccolò Belli @ 2011-02-01 20:17 UTC (permalink / raw)
To: intel-gfx
In-Reply-To: <1296252789.2154.9.camel@localhost>
Il 28/01/2011 23:13, Peter Clifton ha scritto:
> Without this, querying the backlight value returns half of the value it
> has been set to. Hilarity ensues, as my user-space likes to query first
> before incrementing / decrementing brightness, leading to brightness
> collapsing to near as I try to adjust.
It works flawlessly, thank you! Unfortunately I have not been able to
apply the attached patch (for unknown reasons), so I modified the file
manually.
Will it ever be merged into drm-intel? Intel-drm-fixes is still bugged...
Darkbasic
^ permalink raw reply
* [Qemu-devel] [PATCHv3 0.14] vhost: force vhost off for non-MSI guests
From: Michael S. Tsirkin, Alex Williamson @ 2011-02-01 20:13 UTC (permalink / raw)
To: Michael S. Tsirkin; +Cc: kvm, Juan Quintela, Jes.Sorensen, jasowang, qemu-devel
When MSI is off, each interrupt needs to be bounced through the io
thread when it's set/cleared, so vhost-net causes more context switches and
higher CPU utilization than userspace virtio which handles networking in
the same thread.
We'll need to fix this by adding level irq support in kvm irqfd,
for now disable vhost-net in these configurations.
Added a vhostforce flag to force vhost-net back on.
Signed-off-by: Michael S. Tsirkin <mst@redhat.com>
---
OK this is 0.14 material so quick review would be appreciated.
This version's compiled only, I'll naturally test more before I
queue it.
Changes from v2:
get rid of EVIRTIO, add a separate API to query
for fast guest notifiers
Changes from v1:
add vhostforce flag
hw/vhost.c | 10 +++++++++-
hw/vhost.h | 4 +++-
hw/vhost_net.c | 24 ++++++++++++++++++------
hw/vhost_net.h | 3 ++-
hw/virtio-net.c | 6 +++++-
hw/virtio-pci.c | 7 +++++++
hw/virtio.h | 1 +
net/tap.c | 6 ++++--
qemu-options.hx | 4 +++-
9 files changed, 52 insertions(+), 13 deletions(-)
diff --git a/hw/vhost.c b/hw/vhost.c
index 6082da2..38cc3b3 100644
--- a/hw/vhost.c
+++ b/hw/vhost.c
@@ -581,7 +581,7 @@ static void vhost_virtqueue_cleanup(struct vhost_dev *dev,
0, virtio_queue_get_desc_size(vdev, idx));
}
-int vhost_dev_init(struct vhost_dev *hdev, int devfd)
+int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force)
{
uint64_t features;
int r;
@@ -613,6 +613,7 @@ int vhost_dev_init(struct vhost_dev *hdev, int devfd)
hdev->log_enabled = false;
hdev->started = false;
cpu_register_phys_memory_client(&hdev->client);
+ hdev->force = force;
return 0;
fail:
r = -errno;
@@ -627,6 +628,13 @@ void vhost_dev_cleanup(struct vhost_dev *hdev)
close(hdev->control);
}
+bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev)
+{
+ return !vdev->binding->query_guest_notifiers ||
+ vdev->binding->query_guest_notifiers(vdev->binding_opaque) ||
+ hdev->force;
+}
+
int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev)
{
int i, r;
diff --git a/hw/vhost.h b/hw/vhost.h
index 86dd834..c8c595a 100644
--- a/hw/vhost.h
+++ b/hw/vhost.h
@@ -38,10 +38,12 @@ struct vhost_dev {
bool log_enabled;
vhost_log_chunk_t *log;
unsigned long long log_size;
+ bool force;
};
-int vhost_dev_init(struct vhost_dev *hdev, int devfd);
+int vhost_dev_init(struct vhost_dev *hdev, int devfd, bool force);
void vhost_dev_cleanup(struct vhost_dev *hdev);
+bool vhost_dev_query(struct vhost_dev *hdev, VirtIODevice *vdev);
int vhost_dev_start(struct vhost_dev *hdev, VirtIODevice *vdev);
void vhost_dev_stop(struct vhost_dev *hdev, VirtIODevice *vdev);
diff --git a/hw/vhost_net.c b/hw/vhost_net.c
index c068be1..420e05f 100644
--- a/hw/vhost_net.c
+++ b/hw/vhost_net.c
@@ -81,7 +81,8 @@ static int vhost_net_get_fd(VLANClientState *backend)
}
}
-struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
+struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
+ bool force)
{
int r;
struct vhost_net *net = qemu_malloc(sizeof *net);
@@ -98,7 +99,7 @@ struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
(1 << VHOST_NET_F_VIRTIO_NET_HDR);
net->backend = r;
- r = vhost_dev_init(&net->dev, devfd);
+ r = vhost_dev_init(&net->dev, devfd, force);
if (r < 0) {
goto fail;
}
@@ -121,6 +122,11 @@ fail:
return NULL;
}
+bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
+{
+ return vhost_dev_query(&net->dev, dev);
+}
+
int vhost_net_start(struct vhost_net *net,
VirtIODevice *dev)
{
@@ -188,15 +194,21 @@ void vhost_net_cleanup(struct vhost_net *net)
qemu_free(net);
}
#else
-struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd)
+struct vhost_net *vhost_net_init(VLANClientState *backend, int devfd,
+ bool force)
+{
+ return NULL;
+}
+
+bool vhost_net_query(VHostNetState *net, VirtIODevice *dev)
{
- return NULL;
+ return false;
}
int vhost_net_start(struct vhost_net *net,
VirtIODevice *dev)
{
- return -ENOSYS;
+ return -ENOSYS;
}
void vhost_net_stop(struct vhost_net *net,
VirtIODevice *dev)
@@ -209,7 +221,7 @@ void vhost_net_cleanup(struct vhost_net *net)
unsigned vhost_net_get_features(struct vhost_net *net, unsigned features)
{
- return features;
+ return features;
}
void vhost_net_ack_features(struct vhost_net *net, unsigned features)
{
diff --git a/hw/vhost_net.h b/hw/vhost_net.h
index 6c18ff7..91e40b1 100644
--- a/hw/vhost_net.h
+++ b/hw/vhost_net.h
@@ -6,8 +6,9 @@
struct vhost_net;
typedef struct vhost_net VHostNetState;
-VHostNetState *vhost_net_init(VLANClientState *backend, int devfd);
+VHostNetState *vhost_net_init(VLANClientState *backend, int devfd, bool force);
+bool vhost_net_query(VHostNetState *net, VirtIODevice *dev);
int vhost_net_start(VHostNetState *net, VirtIODevice *dev);
void vhost_net_stop(VHostNetState *net, VirtIODevice *dev);
diff --git a/hw/virtio-net.c b/hw/virtio-net.c
index ccb3e63..16ac103 100644
--- a/hw/virtio-net.c
+++ b/hw/virtio-net.c
@@ -119,7 +119,11 @@ static void virtio_net_vhost_status(VirtIONet *n, uint8_t status)
return;
}
if (!n->vhost_started) {
- int r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
+ int r;
+ if (!vhost_net_query(tap_get_vhost_net(n->nic->nc.peer), &n->vdev)) {
+ return;
+ }
+ r = vhost_net_start(tap_get_vhost_net(n->nic->nc.peer), &n->vdev);
if (r < 0) {
error_report("unable to start vhost net: %d: "
"falling back on userspace virtio", -r);
diff --git a/hw/virtio-pci.c b/hw/virtio-pci.c
index d07ff97..3911b09 100644
--- a/hw/virtio-pci.c
+++ b/hw/virtio-pci.c
@@ -595,6 +595,12 @@ static int virtio_pci_set_guest_notifier(void *opaque, int n, bool assign)
return 0;
}
+static bool virtio_pci_query_guest_notifiers(void *opaque)
+{
+ VirtIOPCIProxy *proxy = opaque;
+ return msix_enabled(&proxy->pci_dev);
+}
+
static int virtio_pci_set_guest_notifiers(void *opaque, bool assign)
{
VirtIOPCIProxy *proxy = opaque;
@@ -658,6 +664,7 @@ static const VirtIOBindings virtio_pci_bindings = {
.save_queue = virtio_pci_save_queue,
.load_queue = virtio_pci_load_queue,
.get_features = virtio_pci_get_features,
+ .query_guest_notifiers = virtio_pci_query_guest_notifiers,
.set_host_notifier = virtio_pci_set_host_notifier,
.set_guest_notifiers = virtio_pci_set_guest_notifiers,
.vmstate_change = virtio_pci_vmstate_change,
diff --git a/hw/virtio.h b/hw/virtio.h
index d8546d5..31d16e1 100644
--- a/hw/virtio.h
+++ b/hw/virtio.h
@@ -93,6 +93,7 @@ typedef struct {
int (*load_config)(void * opaque, QEMUFile *f);
int (*load_queue)(void * opaque, int n, QEMUFile *f);
unsigned (*get_features)(void * opaque);
+ bool (*query_guest_notifiers)(void * opaque);
int (*set_guest_notifiers)(void * opaque, bool assigned);
int (*set_host_notifier)(void * opaque, int n, bool assigned);
void (*vmstate_change)(void * opaque, bool running);
diff --git a/net/tap.c b/net/tap.c
index eada34a..b8cd252 100644
--- a/net/tap.c
+++ b/net/tap.c
@@ -491,8 +491,10 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
}
}
- if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd"))) {
+ if (qemu_opt_get_bool(opts, "vhost", !!qemu_opt_get(opts, "vhostfd") ||
+ qemu_opt_get_bool(opts, "vhostforce", false))) {
int vhostfd, r;
+ bool force = qemu_opt_get_bool(opts, "vhostforce", false);
if (qemu_opt_get(opts, "vhostfd")) {
r = net_handle_fd_param(mon, qemu_opt_get(opts, "vhostfd"));
if (r == -1) {
@@ -502,7 +504,7 @@ int net_init_tap(QemuOpts *opts, Monitor *mon, const char *name, VLANState *vlan
} else {
vhostfd = -1;
}
- s->vhost_net = vhost_net_init(&s->nc, vhostfd);
+ s->vhost_net = vhost_net_init(&s->nc, vhostfd, force);
if (!s->vhost_net) {
error_report("vhost-net requested but could not be initialized");
return -1;
diff --git a/qemu-options.hx b/qemu-options.hx
index 898561d..11c93a2 100644
--- a/qemu-options.hx
+++ b/qemu-options.hx
@@ -1050,7 +1050,7 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
"-net tap[,vlan=n][,name=str],ifname=name\n"
" connect the host TAP network interface to VLAN 'n'\n"
#else
- "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h]\n"
+ "-net tap[,vlan=n][,name=str][,fd=h][,ifname=name][,script=file][,downscript=dfile][,sndbuf=nbytes][,vnet_hdr=on|off][,vhost=on|off][,vhostfd=h][,vhostforce=on|off]\n"
" connect the host TAP network interface to VLAN 'n' and use the\n"
" network scripts 'file' (default=" DEFAULT_NETWORK_SCRIPT ")\n"
" and 'dfile' (default=" DEFAULT_NETWORK_DOWN_SCRIPT ")\n"
@@ -1061,6 +1061,8 @@ DEF("net", HAS_ARG, QEMU_OPTION_net,
" use vnet_hdr=off to avoid enabling the IFF_VNET_HDR tap flag\n"
" use vnet_hdr=on to make the lack of IFF_VNET_HDR support an error condition\n"
" use vhost=on to enable experimental in kernel accelerator\n"
+ " (only has effect for virtio guests which use MSIX)\n"
+ " use vhostforce=on to force vhost on for non-MSIX virtio guests\n"
" use 'vhostfd=h' to connect to an already opened vhost net device\n"
#endif
"-net socket[,vlan=n][,name=str][,fd=h][,listen=[host]:port][,connect=host:port]\n"
--
1.7.3.2.91.g446ac
^ permalink raw reply related
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.