* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Raghavendra K T @ 2011-10-24 11:20 UTC (permalink / raw)
To: Avi Kivity
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Rik van Riel, Konrad Rzeszutek Wilk,
LKML, Suzuki Poulose, Srivatsa Vaddagiri, Peter Zijlstra
In-Reply-To: <4EA53A7D.300@redhat.com>
On 10/24/2011 03:44 PM, Avi Kivity wrote:
> On 10/23/2011 09:05 PM, Raghavendra K T wrote:
>> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>> +
>> +end_wait:
>> + finish_wait(&vcpu->wq,&wait);
>> +}
>
> This hypercall can be replaced by a HLT instruction, no?
>
> I'm pretty sure this misses a lot of stuff from kvm_vcpu_block().
Yes.. agree. HLT sounds better idea. 'll try this out.
>
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>
> Need to use smp memory barriers here.
Agree.
>
>> + wake_up_interruptible(&vcpu->wq);
>> + }
>> +}
>> +
>> int kvm_emulate_hypercall(struct kvm_vcpu *vcpu)
>> {
>> unsigned long nr, a0, a1, a2, a3, ret;
>>
>
^ permalink raw reply
* [Buildroot] x86_64 and grub
From: Rickard Lind @ 2011-10-24 11:18 UTC (permalink / raw)
To: buildroot
Hi,
I'm using buildroot-2011.08 with a x86_64 target to build an ext2 image and I would like to include grub, but building grub fails when linking for not finding libgcc. I think this is because grub wants to be built 32 bit (presumably something to do with booting) and gcc is only built with a 64 bit libgcc due to the --disable-multilib configure option. I tried to remove the --disable-multilib option but then the gcc build dies with "cannot find -lc" while building libgcc. I switched from the default gcc to the latest (4.6.1) but that made no difference. I could not find anything in the bugzilla; is there some workaround or should I file a bug? Or am I doing something wrong?
Regards, Rickard
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 1243 bytes
Desc: not available
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111024/a3a51aec/attachment.p7s>
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 11:18 UTC (permalink / raw)
To: Robert
In-Reply-To: <e966a6c.7f7f5548.4ea547f5.6fa69@domain.hid>
On 10/24/2011 01:11 PM, Robert wrote:
>
>
>
> Dnia 24 października 2011 13:07 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>
>> On 10/24/2011 12:59 PM, Robert wrote:
>>> Dnia 24 października 2011 12:37 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>>
>>>> Ok. Try calling /usr/xenomai/bin/xeno-test instead of cding to the
>>>> directory and runing ./xeno-test.
>>>
>>> No difference.
>>
>> I am unable to reproduce this issue, but I am using ash, not bash. last
>> attempt: could you try adding /usr/xenomai/bin to the PATH variable?
>
> The same.
Ok, that is strange, I will test with bash asap.
>
>>>> I have not received the config file.
>>
>>> CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
>>> # CONFIG_ARCH_OMAP2 is not set
>>> CONFIG_ARCH_OMAP3=y
>>> CONFIG_ARCH_OMAP4=y
>>> # CONFIG_ARCH_OMAP3430 is not set
>>> CONFIG_OMAP_PACKAGE_CBL=y
>>> CONFIG_OMAP_PACKAGE_CBS=y
>>
>> Could you try disabling CONFIG_OMAP3?
>
> No. While running "make oldconfig" CONFIG_OMAP3 automatically set to yes, so i didn't touch it.
> Ok, so now I will try to recompile kernel with new config.
>
It will probably not work if you do not disable CONFIG_OMAP3. Multi-omap
kernels are bad for latencies anyway, the next version of the patch will
probably forbid it.
--
Gilles.
^ permalink raw reply
* Re: [PATCH 1/1] mmc: core: Use delayed work in clock gating framework
From: Sujit Reddy Thumma @ 2011-10-24 11:16 UTC (permalink / raw)
To: Linus Walleij; +Cc: linux-mmc, linux-arm-msm, cjb
In-Reply-To: <CACRpkdY1WE8KrFW1qjLJk_sMivicqwDtBVzNDVN6H-3utw0isw@mail.gmail.com>
On 10/24/2011 12:53 PM, Linus Walleij wrote:
> On Wed, Oct 19, 2011 at 4:48 PM, Sujit Reddy Thumma
> <sthumma@codeaurora.org> wrote:
>
>> Current clock gating framework disables the MCI clock as soon as the
>> request is completed and enables it when a request arrives. This aggressive
>> clock gating framework when enabled cause following issues:
>>
>> When there are back-to-back requests from the Queue layer, we unnecessarily
>> end up disabling and enabling the clocks between these requests since 8 MCLK
>> clock cycles is a very short duration compared to the time delay between
>> back to back requests reaching the MMC layer. This overhead can effect the
>> overall performance depending on how long the clock enable and disable
>> calls take which is platform dependent. For example on some platforms we
>> can have clock control not on the local processor, but on a different
>> subsystem and the time taken to perform the clock enable/disable can add
>> significant overhead.
>
> OK I see the problem. At one point it was suggested to use the delayed
> disable facilities in runtime PM for avoiding this, but it never materialized.
>
>> Fix this by delaying turning off the clocks by posting request on
>> delayed workqueue. Also cancel the unscheduled pending work, if any,
>> when there is access to card.
>
> (...)
>> @@ -252,10 +252,11 @@ struct mmc_host {
>> int clk_requests; /* internal reference counter */
>> unsigned int clk_delay; /* number of MCI clk hold cycles */
>> bool clk_gated; /* clock gated */
>> - struct work_struct clk_gate_work; /* delayed clock gate */
>> + struct delayed_work clk_gate_work; /* delayed clock gate */
>> unsigned int clk_old; /* old clock value cache */
>> spinlock_t clk_lock; /* lock for clk fields */
>> struct mutex clk_gate_mutex; /* mutex for clock gating */
>> +#define MMC_CLK_GATE_DELAY 50 /* in milliseconds*/
>> #endif
>
> What's the rationale of having this in the middle of the struct
> in the .h-file?
>
> Move it inside the #ifdef in host.c instead, and also provide
> some rationale about the choice of 50 ms.
With my testing on a MSM platform, round-trip delay of 10ms to turn off
and on the clocks is seen. So I thought 50ms is a reasonable tradeoff.
There is no specific calculation behind this delay. We just relied on
the empirical data which again may vary with different platforms.
If you have any suggestions I would be happy to consider that. I am
planning to increase this to 200ms, any comments on that?
>
> Maybe we should even provide a sysfs or debugfs entry for
> tweaking that value, as has been suggested in the past.
> However that's no big deal for me...
Adding an entry in sysfs seems to be a good solution to tune the
required delay. I will add this.
>
> Do you have a patch to your msm_sdcc.c that enables the
> gating to take effect as well? Does it solve the problems
> pointed out by Russell when I tried the same type of patch
> to mmci.c?
> http://marc.info/?l=linux-mmc&m=129146545916794&w=2
Looking at the patch that you pointed out, I don't think it is required
for msm_sdcc.c to enable clock gating. The current code inherently takes
care of logic that is needed to ensure that MCLK is not turned off until
any pending register write in the host driver is completed. You might
want to have a look at set_ios function in
https://www.codeaurora.org/gitweb/quic/la/?p=kernel/msm.git;a=blob;f=drivers/mmc/host/msm_sdcc.c;h=b5a08d2b58e0cd6d18a8f1041139b6866c0cdc09;hb=refs/heads/msm-3.0
Please let me know if I am still missing anything.
--
Thanks & Regards,
Sujit Reddy Thumma
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] target-arm: Tidy up ARM1136 CPUID naming
From: Peter Maydell @ 2011-10-24 11:15 UTC (permalink / raw)
To: Andreas Färber; +Cc: Andrzej Zaborowski, qemu-devel
In-Reply-To: <4EA29BE0.8050307@web.de>
On 22 October 2011 11:33, Andreas Färber <andreas.faerber@web.de> wrote:
> Am 22.10.2011 12:20, schrieb Peter Maydell:
>> On 3 October 2011 11:32, Andreas Färber <andreas.faerber@web.de> wrote:
>>> -#define ARM_CPUID_ARM1136 0x4117b363
>>> -#define ARM_CPUID_ARM1136_R2 0x4107b362
>>> +#define ARM_CPUID_ARM1136_R1P3 0x4117b363
>>> +#define ARM_CPUID_ARM1136_R0P2 0x4107b362
>>
>> I don't think the patchlevels are important enough to
>> memorialise in the constant names. The important
>> distinction in behaviour is between the r0 and r1, so
>> I think that ARM1136_R0 vs _R1 would be better.
>
> Would you be okay if we do the following?
>
> #define ARM_CPUID_ARM1136_R0 ARM_CPUID_ARM1136_R0P2
> #define ARM_CPUID_ARM1136_R1 ARM_CPUID_ARM1136_R1P3
Not sure that makes it any better.
> My point is that the number is actually hardcoded in there, whatever we
> name the constant.
I think that's really the problem...
-- PMM
^ permalink raw reply
* Re: [Qemu-devel] qemu-kvm guest which won't 'cont' (emulation failure?)
From: Kevin Wolf @ 2011-10-24 11:18 UTC (permalink / raw)
To: Chris Webb; +Cc: qemu-devel, kvm
In-Reply-To: <20111024105826.GT9917@arachsys.com>
Am 24.10.2011 12:58, schrieb Chris Webb:
> Kevin Wolf <kwolf@redhat.com> writes:
>
>> Am 24.10.2011 12:00, schrieb Chris Webb:
>>> I have qemu monitor access and can even strace the relevant qemu process if
>>> necessary: is it possible to use this to diagnose what's caused this guest
>>> to stop, e.g. the unsupported instruction if it's an emulation failure?
>>
>> Another common cause for stopped VMs are I/O errors, for example writes
>> to a sparse image when the disk is full.
>
> This guest are backed by LVM LVs so I don't think they can return EFULL, but I
> could imagine read errors, so I've just done a trivial test to make sure I can
> read them end-to-end:
>
> 0015# dd if=/dev/mapper/guest\:e549f8e1-4c0e-4dea-826a-e4b877282c07\:ide\:0\:0 of=/dev/null bs=1M
> 3136+0 records in
> 3136+0 records out
> 3288334336 bytes (3.3 GB) copied, 20.898 s, 157 MB/s
>
> 0015# dd if=/dev/mapper/guest\:e549f8e1-4c0e-4dea-826a-e4b877282c07\:ide\:0\:1 of=/dev/null bs=1M
> 276+0 records in
> 276+0 records out
> 289406976 bytes (289 MB) copied, 1.85218 s, 156 MB/s
>
> Is there any way to ask qemu why a guest has stopped, so I can distinguish IO
> problems from emulation problems from anything else?
In qemu 1.0 we'll have an extended 'info status' that includes the stop
reason, but 0.14 doesn't have this yet (was committed to git master only
recently).
If you attach a QMP monitor (see QMP/README, don't forget to send the
capabilities command, it's part of creating the connection) you will
receive messages for I/O errors, though.
Kevin
^ permalink raw reply
* Re: [PATCH 00/22] Refactor to accept NUL in commit messages
From: Štěpán Němec @ 2011-10-24 11:09 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Junio C Hamano, git, Jeff King, Ævar Arnfjörð
In-Reply-To: <CACsJy8AsfQnS3L1fabzB-z7BdH=jvB=XNnmP2RZu0qp7C1uGYQ@mail.gmail.com>
On Mon, 24 Oct 2011 07:10:08 +0200
Nguyen Thai Ngoc Duy wrote:
> This is argument for the sake of argument because I don't use utf-16
> and do not care much. UTF-16 can have more code points and some may
> prefer utf-16 to utf-8.
I suspect this is really tangential to this thread, but I can't make
much sense of that last sentence -- if you meant that UTF-16 is somehow
more apt at encoding Unicode code points than UTF-8, then that's not the
case. Both can represent all Unicode characters. If anything, things are
_more_, not less complicated in UTF-16, which apart from the NUL and
endianness complications has to jump through the "surrogate pairs" hoop
for code points bigger than U+FFFF (so you'll actually find many apps
with buggy UTF-16 implementation which break for those code points,
unlike when using UTF-8).
--
Štěpán
^ permalink raw reply
* Re: Nested Virtualization Of Hyper-V 2K8R2
From: Jim @ 2011-10-24 11:13 UTC (permalink / raw)
To: kvm@vger.kernel.org
In-Reply-To: <4E9EE7C3.70407@suresafe.co.uk>
Hi
Anyone got any further ideas on how I get the Hyper-V guest to work ?
My kvm is 0.14 (Ubuntu 11.04 Server) - is this just too old ?
Jim
On 19/10/2011 16:07, Jim wrote:
>
>
> On 19/10/2011 16:06, Jim wrote:
>> Hi Joerg,
>>
>> I added the -cpu phenom,-hv but it made no difference. I then tried
>> to call it from the command line (rather then via virsh) and get this :
>>
>> # /usr/bin/kvm -cpu phenom,-hv
>> *CPU feature hv not found*
>>
>>
>> I played around a little and found 'svm' seemed to be a supported cpu
>> flag but both +svm and -svm made no difference either. Alas kvm -cpu
>> ? only listed CPUs and not the options the various ones support.
>>
>> Am I on too low a version of kvm perhaps ? This is an Ubuntu 11.04
>> server system and I've just used the Ubuntu packages - I did not
>> build kvm myself.
>>
>> Thanks
>> Jim
>>
>> My CPU reports as :
>>
>> *processor : 0-3 i.e. 4 cores*
>> vendor_id : AuthenticAMD
>> cpu family : 16
>> model : 2
>> model name : Quad-Core AMD Opteron(tm) Processor 1354
>> stepping : 3
>> cpu MHz : 1100.000
>> cache size : 512 KB
>> physical id : 0
>> siblings : 4
>> core id : 3
>> cpu cores : 4
>> apicid : 3
>> initial apicid : 3
>> fpu : yes
>> fpu_exception : yes
>> cpuid level : 5
>> wp : yes
>> flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge
>> mca cmov pat pse36 clflush mmx fxsr sse sse2 ht syscall nx mmxext
>> fxsr_opt pdpe1gb rdtscp lm 3dnowext 3dnow constant_tsc rep_good nopl
>> nonstop_tsc extd_apicid pni monitor cx16 popcnt lahf_lm cmp_legacy
>> svm extapic cr8_legacy abm sse4a misalignsse 3dnowprefetch osvw ibs
>> npt lbrv svm_lock
>> bogomips : 4400.04
>> TLB size : 1024 4K pages
>> clflush size : 64
>> cache_alignment : 64
>> address sizes : 48 bits physical, 48 bits virtual
>> power management: ts ttp tm stc 100mhzsteps hwpstate
>>
>>
>>
>> On 19/10/2011 15:19, Joerg Roedel wrote:
>>> Hi Jim,
>>>
>>> On Tue, Oct 18, 2011 at 07:28:52PM +0100, Jim wrote:
>>>> Sure, the KVM command is :
>>>>
>>>> /usr/bin/kvm -enable-nesting -no-kvm-irqchip -S -M pc-0.14 -enable-kvm
>>>> -m 2048 -smp 2,sockets=2,cores=1,threads=1 -name hyperv1 -uuid
>>>> 8c5d8f1f-5767-b388-d408-1b53a1b66e72 -nodefconfig -nodefaults -chardev
>>>> socket,id=charmonitor,path=/var/lib/libvirt/qemu/hyperv1.monitor,server,nowait
>>>>
>>>> -mon chardev=charmonitor,id=monitor,mode=readline -rtc base=localtime
>>>> -no-reboot -boot d -drive
>>>> file=/srv/hyperv/hyperv1.vmimg,if=none,id=drive-ide0-0-0,format=raw
>>>> -device ide-drive,bus=ide.0,unit=0,drive=drive-ide0-0-0,id=ide0-0-0
>>>> -drive
>>>> file=/srv/virtual-machines/fromiscsi/iso/W2K8ENTR2SP1.iso,if=none,media=cdrom,id=drive-ide0-1-0,readonly=on,format=raw
>>>>
>>>> -device ide-drive,bus=ide.1,unit=0,drive=drive-ide0-1-0,id=ide0-1-0
>>>> -drive
>>>> file=/srv/virtual-machines/fromiscsi/iso/virtio-win-1.1.16.iso,if=none,media=cdrom,id=drive-ide0-1-1,readonly=on,format=raw
>>>>
>>>> -device ide-drive,bus=ide.1,unit=1,drive=drive-ide0-1-1,id=ide0-1-1
>>>> -netdev tap,fd=17,id=hostnet0 -device
>>>> rtl8139,netdev=hostnet0,id=net0,mac=52:54:00:2a:be:2f,bus=pci.0,addr=0x3
>>>>
>>>> -chardev pty,id=charserial0 -device
>>>> isa-serial,chardev=charserial0,id=serial0 -usb -device
>>>> usb-tablet,id=input0 -vnc 127.0.0.1:0 -vga std -device
>>>> virtio-balloon-pci,id=balloon0,bus=pci.0,addr=0x4
>>> This is missing a -cpu parameter. Please try again with adding
>>> '-cpu phenom,-hv'. This is the combination I used during testing and
>>> development.
>>>
>>>
>>> Joerg
>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe kvm" in
>>> the body of a message tomajordomo@vger.kernel.org
>>> More majordomo info athttp://vger.kernel.org/majordomo-info.html
>>>
----------------------------------------------------------------------
All e-mail and telephone communications are subject to Suresafe Terms
And Conditions and may be monitored, recorded and processed for the
purposes contained therein and adherence to regulatory and legal
requirements.
Your further communication or reply to this e-mail indicates your
acceptance of this.
Any views or opinions expressed are the responsibility of the author
and may not reflect those of Suresafe Protection Limited.
Suresafe Protection Limited is registered in Scotland, number SC132827
The registered office is at 8 Kelvin Road, Cumbernauld, G67 2BA.
Telephone: 01236 727792 Fax: 01236 723301 VAT Number: 556 6950 02
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* [Buildroot] GnuPG
From: ilranzani @ 2011-10-24 11:12 UTC (permalink / raw)
To: buildroot
In-Reply-To: <0D753D10438DA54287A00B02708426976450C42C46@AUSP01VMBX24.collaborationhost.net>
Nobody?
(in buildroot there's already libgcrypt)
UP UP UP ! :)
--------------
H Hartley Sweeten wrote:
>
> Hello all,
>
> Does anyone had a Buildroot package for GnuPG?
>
> Thanks,
> Hartley
> _______________________________________________
> buildroot mailing list
> buildroot at busybox.net
> http://lists.busybox.net/mailman/listinfo/buildroot
>
>
--
View this message in context: http://old.nabble.com/GnuPG-tp29967586p32709446.html
Sent from the Buildroot (busybox) mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Ofono use
From: Pekka Pessi @ 2011-10-24 11:11 UTC (permalink / raw)
To: ofono
In-Reply-To: <1319449442.32429.141.camel@talinn.home>
[-- Attachment #1: Type: text/plain, Size: 604 bytes --]
Hi Jean,
2011/10/24 Jean Parpaillon <jean.parpaillon@free.fr>
> The point is setting Online property usually end with a timeout. It is
> the right workflow ? Must I look for other property ?
>
The registration might take some time (usually, however, much less than 25
seconds). Perhaps you have to adjust the SetProperty method timeout?
> In a few words, what is the right workflow to get a UMTS modem
> registered to its default network from the moment you plug it in ?
>
>
Sounds right to me. I would not wait for operator name, however.
--
Pekka.Pessi mail at nokia.com
[-- Attachment #2: attachment.html --]
[-- Type: text/html, Size: 1064 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH] KVM: Introduce direct MSI message injection for in-kernel irqchips
From: Avi Kivity @ 2011-10-24 11:09 UTC (permalink / raw)
To: Jan Kiszka; +Cc: Marcelo Tosatti, kvm, Michael S. Tsirkin
In-Reply-To: <4EA53BBF.2010704@siemens.com>
On 10/24/2011 12:19 PM, Jan Kiszka wrote:
> >
> > With the new feature it may be worthwhile, but I'd like to see the whole
> > thing, with numbers attached.
>
> It's not a performance issue, it's a resource limitation issue: With the
> new API we can stop worrying about user space device models consuming
> limited IRQ routes of the KVM subsystem.
>
Only if those devices are in the same process (or have access to the
vmfd). Interrupt routing together with irqfd allows you to disaggregate
the device model. Instead of providing a competing implementation with
new limitations, we need to remove the limitations of the old
implementation.
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] mmc: core: Assemble the codes of related to eMMC4.5
From: Chris Ball @ 2011-10-24 11:09 UTC (permalink / raw)
To: Seungwon Jeon; +Cc: linux-mmc, linux-samsung-soc, kgene.kim, dh.han
In-Reply-To: <001b01cc9238$156a65a0$403f30e0$%jun@samsung.com>
Hi Seungwon,
On Mon, Oct 24 2011, Seungwon Jeon wrote:
> Code cleanup. The codes of related to eMMC4.5 are scattered.
> This patch removes a duplicate if-statement and assembles all.
>
> Signed-off-by: Seungwon Jeon <tgih.jun@samsung.com>
> ---
> drivers/mmc/core/mmc.c | 20 +++++++++-----------
> 1 files changed, 9 insertions(+), 11 deletions(-)
>
> diff --git a/drivers/mmc/core/mmc.c b/drivers/mmc/core/mmc.c
> index fb5bf01..3627044 100644
> --- a/drivers/mmc/core/mmc.c
> +++ b/drivers/mmc/core/mmc.c
> @@ -467,29 +467,27 @@ static int mmc_read_ext_csd(struct mmc_card *card, u8 *ext_csd)
> card->ext_csd.rst_n_function = ext_csd[EXT_CSD_RST_N_FUNCTION];
> }
>
> - /* eMMC v4.5 or later */
> - if (card->ext_csd.rev >= 6)
> - card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> -
> card->ext_csd.raw_erased_mem_count = ext_csd[EXT_CSD_ERASED_MEM_CONT];
> if (ext_csd[EXT_CSD_ERASED_MEM_CONT])
> card->erased_byte = 0xFF;
> else
> card->erased_byte = 0x0;
>
> + /* eMMC v4.5 or later */
> if (card->ext_csd.rev >= 6) {
> + card->ext_csd.feature_support |= MMC_DISCARD_FEATURE;
> +
> card->ext_csd.generic_cmd6_time = 10 *
> ext_csd[EXT_CSD_GENERIC_CMD6_TIME];
> card->ext_csd.power_off_longtime = 10 *
> ext_csd[EXT_CSD_POWER_OFF_LONG_TIME];
> - } else
> - card->ext_csd.generic_cmd6_time = 0;
Your patch removes this line completely. Why is that? You should
explain it in the commit message.
>
> - card->ext_csd.cache_size =
> - ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> - ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + card->ext_csd.cache_size =
> + ext_csd[EXT_CSD_CACHE_SIZE + 0] << 0 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 1] << 8 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 2] << 16 |
> + ext_csd[EXT_CSD_CACHE_SIZE + 3] << 24;
> + }
>
> out:
> return err;
The rest looks good, thanks,
- Chris.
--
Chris Ball <cjb@laptop.org> <http://printf.net/>
One Laptop Per Child
^ permalink raw reply
* Re: [PATCH V2] i2c-designware: Change readl to readw and writel to writew
From: Rajeev kumar @ 2011-10-24 11:08 UTC (permalink / raw)
To: Baruch Siach
Cc: linux-i2c-u79uwXL29TY76Z2rM5mHXA@public.gmane.org, Shiraz HASHIM,
Viresh KUMAR, Bhupesh SHARMA, Pratyush ANAND, Vipin KUMAR,
Deepak SIKRI, Amit VIRDI, Vipul Kumar SAMAR, Armando VISCONTI
In-Reply-To: <20111024103316.GC26649-MwjkAAnuF3khR1HGirfZ1z4kX+cae0hd@public.gmane.org>
Hi Baruch
On 10/24/2011 4:03 PM, Baruch Siach wrote:
> Hi Rajeev,
>
> On Mon, Oct 24, 2011 at 03:28:02PM +0530, Rajeev Kumar wrote:
>> Since I2C designware registers are 16 bit wide and so we should use
>> readw/writew.
>>
>> Signed-off-by: Rajeev Kumar<rajeev-dlh.kumar-qxv4g6HH51o@public.gmane.org>
>> ---
>> drivers/i2c/busses/i2c-designware.c | 104 +++++++++++++++++-----------------
>> 1 files changed, 52 insertions(+), 52 deletions(-)
>>
>> diff --git a/drivers/i2c/busses/i2c-designware.c b/drivers/i2c/busses/i2c-designware.c
>> index 6eaa681..5149a10 100644
>> --- a/drivers/i2c/busses/i2c-designware.c
>> +++ b/drivers/i2c/busses/i2c-designware.c
>> @@ -216,11 +216,11 @@ struct dw_i2c_dev {
>> u32 abort_source;
>> int irq;
>> struct i2c_adapter adapter;
>> - unsigned int tx_fifo_depth;
>> - unsigned int rx_fifo_depth;
>> + u16 tx_fifo_depth;
>> + u16 rx_fifo_depth;
>> };
>
> This looks wrong. The {tx,rx}_fifo_depth fields do not represent bit fields,
> but numbers. So unsigned int should be better here.
Yes, I agree with you, but I do not see any possibility of value of
{tx,rx}_fifo_depth fields greater than 2^^16 - 1. So, would not it be
better to keep them as u16 and save just 4 bytes.
~Rajeev
>
> baruch
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] fw_cfg: Use g_file_get_contents instead of multiple fread() calls
From: Peter Maydell @ 2011-10-24 11:08 UTC (permalink / raw)
To: Pavel Borzenkov; +Cc: qemu-devel
In-Reply-To: <1319196934-17740-1-git-send-email-pavel.borzenkov@gmail.com>
On 21 October 2011 12:35, Pavel Borzenkov <pavel.borzenkov@gmail.com> wrote:
> Signed-off-by: Pavel Borzenkov <pavel.borzenkov@gmail.com>
Thanks; I think this looks a lot nicer than the raw file ops code did.
I think we could probably make the error messages slightly more user
friendly while we're here.
> + res = g_file_get_contents(filename, &content, (gsize *)file_sizep, &err);
> + if (res == FALSE) {
> + error_report("falied to read file '%s'", filename);
You've made a typo here ("failed"); also I think all the error messages
in this function should say "splash file" rather than just "file",
and include the filename.
> + if (*file_sizep < 30) {
> + error_report("file size is less than 30 bytes '%s'", filename);
> + g_free(content);
> + return NULL;
Rather than saying exactly what check failed (the user won't care)
we should just say "splash file '%s' format not recognized; must be JPEG
or 24 bit BMP".
> + error_report("'%s' not jpg/bmp file, head:0x%x.", filename, filehead);
and here also.
> if (bmp_bpp != 24) {
> error_report("only 24bpp bmp file is supported.");
and here I think.
-- PMM
^ permalink raw reply
* Re: [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability
From: J. Bruce Fields @ 2011-10-24 11:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aneesh Kumar K.V, agruen, akpm, viro, dhowells, linux-fsdevel,
linux-nfs, linux-kernel
In-Reply-To: <20111024094910.GA28693@infradead.org>
On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> >
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
>
> It really has to through the VFS tree.
Do we have a VFS tree right now?
> And to be honest despite the repostings there's been exactly zero
> progress on getting there.
Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?
> Please as a first thing submit the various small cleanups indepent
> of the other changes. If you can't even those in there's no point
> in trying. Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems. Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done. For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one. And please
> wire up all common filesystems to actually prove that point.
Sounds reasonable.
> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated. Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up. There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).
Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right? (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)
> After all this techical work (which was brought up before) has been
> done you can resubmit it. And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.
It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.
I don't know how to make the justification much longer than that.
--b.
^ permalink raw reply
* Re: [PATCH -V8 00/26] New ACL format for better NFSv4 acl interoperability
From: J. Bruce Fields @ 2011-10-24 11:07 UTC (permalink / raw)
To: Christoph Hellwig
Cc: Aneesh Kumar K.V, agruen-DgEjT+Ai2ygdnm+yROfE0A,
akpm-de/tnXTf+JLsfHDXvbKv3WD2FQJk+8+b,
viro-RmSDqhL/yNMiFSDQTTA3OLVCufUGDwFn,
dhowells-H+wXaHxf7aLQT0dZR+AlfA,
linux-fsdevel-u79uwXL29TY76Z2rM5mHXA,
linux-nfs-u79uwXL29TY76Z2rM5mHXA,
linux-kernel-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <20111024094910.GA28693-wEGCiKHe2LqWVfeAwA7xHQ@public.gmane.org>
On Mon, Oct 24, 2011 at 05:49:10AM -0400, Christoph Hellwig wrote:
> On Mon, Oct 24, 2011 at 05:17:16AM -0400, J. Bruce Fields wrote:
> > > How do we push these changes to Linus tree ? Andrew, Viro, any comment
> > > on how we can get this merged upstream ?
> >
> > Andrew, it sounds like you might be willing to shepherd these through?
> > Let us know what you'd need.
>
> It really has to through the VFS tree.
Do we have a VFS tree right now?
> And to be honest despite the repostings there's been exactly zero
> progress on getting there.
Apparently some review was missed--do you have pointers to it, if
there's anything that isn't covered below?
> Please as a first thing submit the various small cleanups indepent
> of the other changes. If you can't even those in there's no point
> in trying. Second do not repeat the mistakes of the old ACL code,
> that is don't do too much work inside the filesystems. Al, Linus
> and me spent a lot of working on pushing it into common code and
> it's not done. For any new ACL model I really want to see zero
> per-fs code except for callouts in chmod & co and actually
> setting the xattr vector to a genericly provided one. And please
> wire up all common filesystems to actually prove that point.
Sounds reasonable.
> I also really hate all the duplication - I want to see a really good
> reason why all this code needs to be duplicated. Just look at
> the mess done to check_acl and the ACL caching in the inode and
> any normal person would throw up. There is absolutely no reason
> to not implement Posix ACLs as a subset of the NFSv4 ACL (not actually
> a subset in the strict mathematical sense, but close enough).
Just to make sure I understand: you're just talking about the
implementation here--you want as much as possible to be done by routines
shared by NFSv4 and Posix ACLs--right? (You're not suggesting that e.g.
a user should be able to treat NFSv4 ACLs as if they were Posix ACLs.)
> After all this techical work (which was brought up before) has been
> done you can resubmit it. And that point you'd better have very
> good and very lengthy rationale for why adding an utterly stupid
> ACL model is supposed to be a good idea.
It's the ACL model that Samba and NFSv4 clients use, and we want to do a
better job of exporting linux filesystems to those clients.
I don't know how to make the justification much longer than that.
--b.
--
To unsubscribe from this list: send the line "unsubscribe linux-nfs" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [Xenomai-help] installing xenomai on pandaboard
From: Gilles Chanteperdrix @ 2011-10-24 11:07 UTC (permalink / raw)
To: Robert; +Cc: xenomai
In-Reply-To: <f8287c0.5ee210fc.4ea544fe.30636@domain.hid>
On 10/24/2011 12:59 PM, Robert wrote:
> Dnia 24 października 2011 12:37 Gilles Chanteperdrix <gilles.chanteperdrix@domain.hid> napisał(a):
>> Ok. Try calling /usr/xenomai/bin/xeno-test instead of cding to the
>> directory and runing ./xeno-test.
>
> No difference.
I am unable to reproduce this issue, but I am using ash, not bash. last
attempt: could you try adding /usr/xenomai/bin to the PATH variable?
>> I have not received the config file.
> CONFIG_ARCH_OMAP2PLUS_TYPICAL=y
> # CONFIG_ARCH_OMAP2 is not set
> CONFIG_ARCH_OMAP3=y
> CONFIG_ARCH_OMAP4=y
> # CONFIG_ARCH_OMAP3430 is not set
> CONFIG_OMAP_PACKAGE_CBL=y
> CONFIG_OMAP_PACKAGE_CBS=y
Could you try disabling CONFIG_OMAP3?
--
Gilles.
^ permalink raw reply
* Re: [PATCH 2/3] kvm: use this_cpu_xxx replace percpu_xxx funcs
From: Avi Kivity @ 2011-10-24 11:05 UTC (permalink / raw)
To: Alex,Shi
Cc: Christoph Lameter, tj@kernel.org, linux-kernel@vger.kernel.org,
eric.dumazet@gmail.com, Huang, Ying, tglx@linutronix.de,
mingo@redhat.com, akpm@linux-foundation.org, davem@davemloft.net,
kaber@trash.net, a.p.zijlstra@chello.nl, kvm@vger.kernel.org,
jeremy@xensource.com
In-Reply-To: <1319424608.5061.25.camel@debian>
On 10/24/2011 04:50 AM, Alex,Shi wrote:
> On Thu, 2011-10-20 at 15:34 +0800, Alex,Shi wrote:
> > percpu_xxx funcs are duplicated with this_cpu_xxx funcs, so replace them
> > for further code clean up.
> >
> > And in preempt safe scenario, __this_cpu_xxx funcs has a bit better
> > performance since __this_cpu_xxx has no redundant preempt_disable()
> >
>
> Avi:
> Would you like to give some comments of this?
>
Sorry, was travelling:
Acked-by: Avi Kivity <avi@redhat.com>
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [PATCH] drivers: create a pin control subsystem v8
From: Grant Likely @ 2011-10-24 11:05 UTC (permalink / raw)
To: Linus Walleij
Cc: Mike Frysinger, Linus Walleij, Stephen Warren, Sascha Hauer,
Barry Song, linux-kernel, Joe Perches, Russell King, Linaro Dev,
Lee Jones, David Brown, linux-arm-kernel, Stijn Devriendt
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
> >> I was more thinking along the lines of one device per GPIO controller,
> >> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
> >
> > And there is also the question of whether it is even a good idea to
> > export pinctrl manipulation to userspace.
>
> The application I've seen is in automatic control.
>
> I think people do things like connect they GPIO pins to electrical
> relays, plus on top of that they use all the stuff in drivers/staging/iio.
>
> All that from userspace. Controlling entire factories and industrial
> robots, weapon systems too, I'm afraid.
>
> The control of these dangerous things runs on a realtime-patched
> kernel, in a single userspace app with a few threads and they have
> done some realtime-tetris scheduling the beast more or less
> manually with SCHED_FIFO. Basically that app is all that runs on
> the board, and its threads take precedence over everything else
> on the system.
>
> That is the typical beast that is poking around on the GPIO sysfs
> interfaces...
... which maybe should be encouraged to use some form of uio driver. :-)
g.
^ permalink raw reply
* [Qemu-devel] KVM call agenda for October 25
From: Juan Quintela @ 2011-10-24 11:04 UTC (permalink / raw)
To: qemu-devel, KVM devel mailing list
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
^ permalink raw reply
* [PATCH] drivers: create a pin control subsystem v8
From: Grant Likely @ 2011-10-24 11:05 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <CACRpkdZ6DCeELLhiXF=oOMKB-DxeMuvbd_c6n4H1UDMhpHKZbA@mail.gmail.com>
On Mon, Oct 24, 2011 at 09:48:19AM +0200, Linus Walleij wrote:
> On Mon, Oct 24, 2011 at 9:36 AM, Grant Likely <grant.likely@secretlab.ca> wrote:
> > On Mon, Oct 24, 2011 at 09:26:38AM +0200, Linus Walleij wrote:
> (...)
> >> I was more thinking along the lines of one device per GPIO controller,
> >> then you ioctl() to ask /dev/gpio0 how many pins it has or so.
> >
> > And there is also the question of whether it is even a good idea to
> > export pinctrl manipulation to userspace.
>
> The application I've seen is in automatic control.
>
> I think people do things like connect they GPIO pins to electrical
> relays, plus on top of that they use all the stuff in drivers/staging/iio.
>
> All that from userspace. Controlling entire factories and industrial
> robots, weapon systems too, I'm afraid.
>
> The control of these dangerous things runs on a realtime-patched
> kernel, in a single userspace app with a few threads and they have
> done some realtime-tetris scheduling the beast more or less
> manually with SCHED_FIFO. Basically that app is all that runs on
> the board, and its threads take precedence over everything else
> on the system.
>
> That is the typical beast that is poking around on the GPIO sysfs
> interfaces...
... which maybe should be encouraged to use some form of uio driver. :-)
g.
^ permalink raw reply
* Hi Dear,
From: nafi.love@yahoo.com @ 2011-10-24 11:03 UTC (permalink / raw)
To: nafi.love
Hi Dear,
how are you today i hope that every things is ok with you as it is my great
pleassure to contact you in having communication with you, please i wish you
will have the desire with me so that we can get to know each other better and
see what happened in future.i will be very happy if you can write me through my
email for easiest communication and to know all about each other, and also give
you my pictures and details about me, here is my email (nafi.love@yahoo.com) i
will be waiting to hear from you as i wish you all the best for your day.
your new friend.
Nafisatu,
Please reply me in this email
(nafi.love@yahoo.com)
^ permalink raw reply
* KVM call agenda for October 25
From: Juan Quintela @ 2011-10-24 11:04 UTC (permalink / raw)
To: qemu-devel, KVM devel mailing list
Hi
Please send in any agenda items you are interested in covering.
Thanks, Juan.
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Raghavendra K T @ 2011-10-24 11:00 UTC (permalink / raw)
To: Sasha Levin
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra <peter>
In-Reply-To: <1319450510.5660.6.camel@lappy>
On 10/24/2011 03:31 PM, Sasha Levin wrote:
> On Mon, 2011-10-24 at 00:35 +0530, Raghavendra K T wrote:
>> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>>
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>> +
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>
> I'm not sure about it, but maybe we want a memory barrier over here?
Yes, Thanks for pointing this. Avi Kivity also pointed same. 'll add
barrier() here.
>
>> + wake_up_interruptible(&vcpu->wq);
>> + }
>> +}
^ permalink raw reply
* Re: [PATCH RFC V2 3/5] kvm hypervisor : Add two hypercalls to support pv-ticketlock
From: Raghavendra K T @ 2011-10-24 11:00 UTC (permalink / raw)
To: Sasha Levin
Cc: Raghavendra K T, Greg Kroah-Hartman, H. Peter Anvin, Gleb Natapov,
Virtualization, Jeremy Fitzhardinge, x86, KVM, Dave Jiang,
Thomas Gleixner, Stefano Stabellini, Xen, Sedat Dilek, Yinghai Lu,
Marcelo Tosatti, Ingo Molnar, Avi Kivity, Rik van Riel,
Konrad Rzeszutek Wilk, LKML, Suzuki Poulose, Srivatsa Vaddagiri,
Peter Zijlstra <peter
In-Reply-To: <1319450510.5660.6.camel@lappy>
On 10/24/2011 03:31 PM, Sasha Levin wrote:
> On Mon, 2011-10-24 at 00:35 +0530, Raghavendra K T wrote:
>> Add two hypercalls to KVM hypervisor to support pv-ticketlocks.
>>
>> +static void kvm_pv_kick_cpu_op(struct kvm *kvm, int cpu)
>> +{
>> + struct kvm_vcpu *vcpu = kvm_get_vcpu(kvm, cpu);
>> +
>> + if (vcpu) {
>> + vcpu->kicked = 1;
>
> I'm not sure about it, but maybe we want a memory barrier over here?
Yes, Thanks for pointing this. Avi Kivity also pointed same. 'll add
barrier() here.
>
>> + wake_up_interruptible(&vcpu->wq);
>> + }
>> +}
^ 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.