* Re: [Qemu-devel] [PATCH v2] trace: Add wildcard trace event support
From: Stefan Hajnoczi @ 2011-10-31 14:05 UTC (permalink / raw)
To: Mark Wu; +Cc: Stefan Hajnoczi, qemu-devel
In-Reply-To: <1320031744-3016-1-git-send-email-wudxw@linux.vnet.ibm.com>
On Mon, Oct 31, 2011 at 11:29:04AM +0800, Mark Wu wrote:
> A basic wildcard matching is supported in both the monitor command
> "trace-event" and the events list file. That means you can enable/disable
> the events having a common prefix in a batch. For example, virtio-blk trace
> events could be enabled using:
> trace-event virtio_blk_* on
>
> Signed-off-by: Mark Wu <wudxw@linux.vnet.ibm.com>
> ---
> docs/tracing.txt | 9 ++++++++-
> net/queue.c | 1 +
> trace/simple.c | 19 +++++++++++++++++--
> trace/stderr.c | 17 ++++++++++++++++-
> 4 files changed, 42 insertions(+), 4 deletions(-)
Thanks, applied to the tracing tree:
http://repo.or.cz/w/qemu/stefanha.git/shortlog/refs/heads/tracing
I removed the net/queue.c hunk from the patch.
Stefan
^ permalink raw reply
* [Buildroot] [Bug 4429] buildroot 2011.08 does not build on Ubuntu 11.10
From: bugzilla at busybox.net @ 2011-10-31 14:05 UTC (permalink / raw)
To: buildroot
In-Reply-To: <bug-4429-163@https.bugs.busybox.net/>
https://bugs.busybox.net/show_bug.cgi?id=4429
--- Comment #3 from Robert Berger <busybox@reliableembeddedsystems.com> 2011-10-31 14:05:30 UTC ---
When I'm __not__ running screen or byubo, but, just ssh to a machine:
echo $SHELL
/bin/bash
it compiles.
---------------------------
When I'm running byubo (and bash)
echo $SHELL
/bin/bash
it breaks with the funny errors from above.
--
Configure bugmail: https://bugs.busybox.net/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.
^ permalink raw reply
* Re: [Qemu-devel] [libvirt] RFC decoupling VM NIC provisioning from VM NIC connection to backend networks
From: Markus Armbruster @ 2011-10-31 14:05 UTC (permalink / raw)
To: Daniel P. Berrange
Cc: libvir-list, David Wang (dwang2), Ram Durairaj (radurair),
qemu-devel, Sumit Naiksatam (snaiksat)
In-Reply-To: <20111031104905.GC27570@redhat.com>
"Daniel P. Berrange" <berrange@redhat.com> writes:
> On Fri, Oct 28, 2011 at 04:15:41PM -0700, Sumit Naiksatam (snaiksat) wrote:
>> Hi,
>>
>> In its current implementation Libvirt makes sure that the network
>> interfaces that it passes/provision to a VM (for example to qemu[-kvm])
>> are already connected to its backend (interfaces/networks) by the time
>> the VM starts its boot process. In a non virtualized setup it would be
>> like booting a machine with the Ethernet cable already plugged into a
>> router/switch port. While in a non virtualized setup you can boot a
>> machine first (with no physical connection to a router/switch) and later
>> connect its NIC/s to the switch/router, when you boot a VM via Libvirt
>> it is not possible to decouple the two actions (VM boot, cable
>> plug/unplug).
>>
>> An example of case where the capability of decoupling the two actions
>> mentioned above is a requirement in Quantum/NetStack which is the
>> network service leveraged by OpenStack. The modular design of OpenStack
>> allows you to:
>> - provision VMs with NIC/s
>> - create networks
>> - create ports on networks
>> - plug/unplug a VM NIC into/from a given port on a network (at runtime)
>>
>> Note that this runtime plug/unplug requirement has nothing to do with
>> hot plug/unplug of NICs.
>> The idea is more that of decoupling the provisioning of a VM from the
>> connection of the VM to the network/s.
>> This would make it possible to change (at run-time too) the networks the
>> NIC/s of a given VM are connected to.
>>
>> For example, when a VM boots, its interfaces should be in link down
>> state if the network admin has not connected the VM NIC/s to any
>> "network" yet.
>> Even though libvirt already provides a way to change the link state of
>> an a VM NIC, link state and physical connection are two different things
>> and should be manageable independently.
>>
>> Ideally the configuration syntax should be interface type and hypervisor
>> type agnostic.
>>
>> Let's take QEMU[-kvm] as an example - when Libvirt starts a QEMU VM, it
>> passes to QEMU a number of file descriptors that map to host backend
>> interfaces (for example macvtap interfaces).
>>
>> In order to introduce this runtime plug/unplug capability, we need a
>> mechanism that permits to delay the binding between the host macvtap
>> interfaces and the guest taps (because you cannot know the fd of the
>> macvtap interfaces before you create them). This means you need a
>> mechanism that allows you to change such fd/s at runtime:
>>
>> - you can close/reset an fd (ie, when you disconnect a VM NIC from its
>> network)
>> - you can open/set an fd (ie, when you connect a VM NIC to a network)
>>
>> This could probably be a libvirt command that translates to a QEMU
>> monitor command.
>>
>> Can the runtime plug/unplug capability described above be achieved
>> (cleanly) with another mechanism?
>>
>> Is anybody working on implementing something similar?
>
> No, but I've long thought about doing this & it is quite straightforward
> todo really. Ordinarily when we start QEMU we do
>
> qemu ... -device e1000,id=nic0,netdev=netdevnic0 \
> -netdev user,id=netdevnic0
>
> Todo what you describe we need to be able to:
>
> 1. Start QEMU with a NIC, but no netdev
> 2. Add a netdev to running QEMU.
> 3. Remove a netdev from a running QEMU
> 4. Associate a netdev with a NIC in running QEMU
>
> We can do 1:
>
> $ qemu ... -device e1000,id=nic0
>
> But QEMU prints an annoying warning
>
> Warning: nic nic0 has no peer
>
> We can do 2 via the monitor:
>
> (qemu) netdev_add type=user,id=netdevnic0
>
> We can do 3 via the monitor:
>
> (qemu) netdev_del netdevnic0
>
>
> The problem is 4 - AFAICT we can't connect the existing NIC upto the newly
> hotplugged netdev, since we can't update the 'netdev' property in the NIC
> device.
Yes, that's the missing piece.
> Also if we delete the netdev, we can't clear out the 'netdev'
> property in the NIC, so its dangling to a netdev that no longer exists.
Err, this sounds like we had a dangling pointer there. We don't.
Until commit a083a89d, netdev_del disconnected the backend netdev from
the frontend NIC (assigning null to property "netdev"), then deleted the
netdev.
Since then, we delay the actual deletion until the NIC goes away,
because "removing host netdev peer while guest is active leads to
guest-visible inconsistency and/or crashes".
I figure that needs to be fixed differently to enable dynamic network
backend switching.
> The latter is fairly harmless, since we can just re-use the name if adding
> a new backend later. The first problem is a bit of a pain, unless we plug
> in a 'user' backend on the CLI, and immediately netdev_del it before starting
> the CPUs. Ideally we'd have some way to set qdev properties for devices so we
> can associate the NIC with the new netdev.
>
> eg when adding a netdev:
>
> (qemu) netdev_add type=user,id=netdevnic0
> (qemu) set nic0 netdev=netdevnic0
>
> Or removing one
>
> (qemu) netdev_add netdevnic0
> (qemu) unset nic0 netdev
Please work with Anthony to get this use case covered in QOM.
> WRT to libvirt XML config. Normally you specifiy a NIC like
>
> <interface type='network'>
> <mac address='52:54:00:0f:7d:ad'/>
> <source network='default'/>
> <model type='virtio'/>
> </interface>
>
> To boot a guest without any netdev backend present, we'd introduce a
> new network type="none". eg
>
> <interface type='none'>
> <mac address='52:54:00:0f:7d:ad'/>
> <model type='virtio'/>
> </interface>
>
> The existing API 'virDomainUpdateDevice', can then be used to change
> the interface config on the fly, adding or removing the netdev by
> passing in new XML with a different 'type' attribute & <source>
> element.
>
> Finally, when adding & removing the netdev backends to a running guest,
> we likely want to be able to set the NIC's link carrier, so the guest
> OS sees that it has lost / gain its network connection & will thus
> retry DHCP / IPv6 autoconfig. There is already a QEMU montior command
> 'set_link' for changing the NIC link carrier. A minor problem is that,
> AFAICT, we can't specify the link carrier state on the command line
> when specifying the NIC hardware, eg we would want something like
> this when starting a guest without a netdev back
>
> qemu ... -device e1000,id=nic0,link=down
Should be easy enough to do.
> And when adding a netdev we would do
>
> (qemu) netdev_add user,id=netdevnic0
> (qemu) set nic0 netdev=netdevnic0
> (qemu) set_link nic0 up
>
> Or when removing a netdev
>
> (qemu) set_link nic0 down
> (qemu) unset nic0 netdev
> (qemu) netdev_del user,id=netdevnic0
^ permalink raw reply
* Re: barebox on gta04
From: Johannes Schauer @ 2011-10-31 14:05 UTC (permalink / raw)
To: Robert Schwebel; +Cc: gta04-owner, barebox
In-Reply-To: <20111031115748.GE21072@pengutronix.de>
Hi,
On Mon, Oct 31, 2011 at 12:57:48PM +0100, Robert Schwebel wrote:
> Does barebox now work on your gtk04?
nope, I'm relying on input from you guys ;)
> If not, I'd be willing to help with the port, but somebody would have
> to organze a hardware for us in that case.
if there are no leftover units in munich and you are located in germany
i could lend you mine for one or two weeks?
cheers, josch
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* dev->promiscuity can become negative in specific bridge + vlan configuration
From: Matthijs Kooijman @ 2011-10-31 13:44 UTC (permalink / raw)
To: netdev
[-- Attachment #1: Type: text/plain, Size: 2924 bytes --]
(Please CC me, I'm not subscribed)
Hi folks,
while debugging an issue on a wireless access point running Linux, I
encountered an issue with the promiscuity of interfaces when combining
vlans and bridges. When configuring them in a specific order, the
dev->promiscuity can become negative and the IFF_PROMISC flag will be
wrong.
I've reproduced this on an old 2.6.26 kernel as well as an
3.1.0-rc10-ish kernel from misc.git.
When a VLAN device is configured to be promiscuous, the underlying
physical device must be promiscuous as well. This is achieved in two
ways:
1. When a vlan device is brought up and its IFF_PROMISC flag is set, the
promiscuity of the underlying interface is increased. When a vlan
device is brought down and its IFF_PROMISC flag is set, the
promiscuity of the underlying interface is decreased. This happens in
vlan_dev_open() and vlan_dev_stop().
2. When the IFF_PROMISC flag changes on the vlan device, the promiscuity
value of the underlying device is increased or decreased, depending
on the value of the flag. This happens in vlan_dev_change_rx_flags().
However, 2. also happens when the interface is not up, which is
incorrect AFAICS. If a VLAN interface, which is promiscuous, is first
brought down and then has its promiscious flag reset, the promiscuity of
the underlying physical interface will be decreased twice.
This problem can be demonstrated with the following commands. It should
happen on any hardware and all recent (andn not-so-recent) kernels,
AFAICS. I've added the relevant kernel output and some comments inline
below.
$ vconfig add eth0 10
Added VLAN with VID == 10 to IF -:eth0:-
$ brctl addbr br0
$ ifconfig eth0.10 up
$ brctl addif br0 eth0.10
[14288.817391] device eth0.10 entered promiscuous mode
[14288.817397] device eth0 entered promiscuous mode
# eth0->promiscuity is now 1, as expected
$ ifconfig eth0.10 down
[14335.533019] device eth0 left promiscuous mode
# eth0->promiscuity is now 0, as expected
$ brctl delif br0 eth0.10
[14351.037666] device eth0.10 left promiscuous mode
# eth0->promiscuit is now -1!
$ brctl addif br0 eth0.10
[14383.549998] device eth0.10 entered promiscuous mode
# eth0->promiscuity is now 0, so eth0 is not entering promisciuous mode
# as it should
I've confirmed that the promiscuity actually gets set to -1 by some
added kernel prints on the 2.6.26 kernel, but the above behaviour is
also shown on the 3.1.0-rc10 kernel (which is consistent with
promiscuity diving below 0).
From looking at the code, I assume the same story applies for the
IFF_ALLMULTI flag, but I've not tested this.
I'm working on a (simple) patch to fix this issue, by simply not
updating the promiscuity of the underlying interface if the vlan
interface is down. I'll reply to this message with the patch after I've
finished and tested it.
Gr.
Matthijs
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Question: kick SDIO irq when resume
From: Jun Nie @ 2011-10-31 14:06 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Bing Zhao, frankh, yongd, tianfh, njun, linux-mmc
In-Reply-To: <alpine.LFD.2.02.1110310824120.3307@xanadu.home>
2011/10/31 Nicolas Pitre <nicolas.pitre@linaro.org>:
> On Mon, 31 Oct 2011, Jun Nie wrote:
>
>> Hi Nico,
>> We are debugging fake SDIO irq when 8787 SDIO card resume and
>> found below patch. The issue is that 8787 driver can not handle card
>> irq if neither 8787 nor host trigger resume event in some cases. Do
>> you remember what SDIO card need below patch? What's your idea on this
>> issue? How about add a SDIO function flag to decide the irq thread
>> kick off in resume?
>
> This is needed because in some cases the card interrupt is already
> consumed for the wake-up event. Kicking this thread shouldn't cause any
> issue though, as the card is just polled for the actual presence of an
> IRQ ...
>
> ... or maybe not. In this case commit 06e8935feb "optimized SDIO IRQ
> handling for single irq" may certainly cause problems.
>
> The fix here would be to clear card->sdio_single_irq before calling
> mmc_signal_sdio_irq() in mmc_sdio_resume() and restore its original
> value eventually, or better yet ignore that flag when the IRQ thread is
> ran for the first time after a resume.
8787 case(bug) is similar with sdio_signel_irq case, but not same.
8787 can not response to reading sdio card interrupt status correctly
if 8787 is still in suspend mode. The read operation will get value of
previous CMD52 read, no matter previous CMD52 is for what purpose. So
host should avoid read from 8787 before call sdio function resume in
normal resume process. Otherwise, 8787 may lead lead host to handle
fake interrupt and result further error.
>
> In any case you may disable that optimization in the IRQ demux handler
> to see if this fixes your problem.
So the fix to 8787 is either adding a flag, such as NO_LOST_WAKEUP_IRQ
for func/card, or moving kick off to after sdio function resume. I do
not know which one you prefer.
>
>
> Nicolas
>
^ permalink raw reply
* [PATCH] t7511: avoid use of reserved filename on Windows.
From: Pat Thoyts @ 2011-10-31 14:07 UTC (permalink / raw)
To: Git; +Cc: Junio C Hamano, msysGit, Pat Thoyts
PRN is a special filename on Windows to send data to the printer. As
this is generated during test 3 substitute an alternate prefix to avoid this.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
---
t/t7511-status-index.sh | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/t/t7511-status-index.sh b/t/t7511-status-index.sh
index bca359d..b5fdc04 100755
--- a/t/t7511-status-index.sh
+++ b/t/t7511-status-index.sh
@@ -24,7 +24,7 @@ check() {
check 1
check 2 p
-check 3 pr
+check 3 px
check 4 pre
check 5 pref
check 6 prefi
--
1.7.8.rc0.200.gbcc18
^ permalink raw reply related
* variable size array declarations
From: Dan Carpenter @ 2011-10-31 14:08 UTC (permalink / raw)
To: linux-sparse
[-- Attachment #1: Type: text/plain, Size: 618 bytes --]
I am trying to check something in Smatch with variable size arrays
and I'm running into problems. Here is the function I'm trying to
parse.
void func(int x)
{
char buf[x];
}
Array symbols have an ->array_size. It gets set correctly in parse.c
to expression of type EXPR_SYMBOL. But by the time I parse it in
Smatch the ->array_size is now an EXPR_PREOP (a dereference). In
fact all the variables seem to get change to dereferences of the
variables.
So if I have:
char buf[a + b + *c + 4];
Smatch gets:
char buf[*a + *b + **c + 4];
I'm not sure where this is getting changed or why.
regards,
dan carpenter
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: Xen dom0 linux kernel 3.1 boot failure ptwr_emulate: could not get_page_from_l1e
From: Konrad Rzeszutek Wilk @ 2011-10-31 14:08 UTC (permalink / raw)
To: Tobias Heinlein, 2013pfoley; +Cc: linux-kernel, xen-devel
In-Reply-To: <loom.20111031T140651-901@post.gmane.org>
On Mon, Oct 31, 2011 at 01:17:09PM +0000, Tobias Heinlein wrote:
> Hi,
>
> 2013pfoley <2013pfoley <at> tjhsst.edu> writes:
> > [..]
> >
> > [ 0.000000] last_pfn = 0x63b5ef max_arch_pfn = 0x400000000
> > [ 0.000000] last_pfn = 0xdf62d max_arch_pfn = 0x400000000
> > [ 0.000000] found SMP MP-table at [ffff8800000f4f80] f4f80
> > (XEN) mm.c:945:d0 Error getting mfn 100 (pfn 5555555555555555) from L1
> > entry 8000000000100461 for l1e_owner=0, pg_owner=0
> > (XEN) mm.c:5046:d0 ptwr_emulate: could not get_page_from_l1e()
> > [ 0.000000] BUG: unable to handle kernel NULL pointer dereference at
> > (null)
> > [ 0.000000] IP: [<ffffffff81008a5a>] xen_set_pte+0x3a/0x1f0
> > [ 0.000000] PGD 0
> > [ 0.000000] Oops: 0003 [#1] SMP
> > [ 0.000000] CPU 0
> > [ 0.000000] Modules linked in:
> > [ 0.000000]
> > [ 0.000000] Pid: 0, comm: swapper Not tainted 3.1.0 #4 HP ProLiant
> > DL380 G6
>
> I get the exact same error here. Reading from your output, it seems we have the
> same hardware; I have this problem on a HP ProLiant DL380 G6, too.
>
> After a wild hint from a guy on ##xen to play around with the BIOS settings, I
> was able to narrow down the problem to a setting called "MPS Table Mode". It is
> set to "Full Table APIC" by default (with which the crash occurs), but when it's
> set to "Disabled" Xen boots the kernel just fine.
>
> FWIW, the help text of the setting is: "Multi Processor Specification (MPS)
> Table / APIC Setting is used for interrupt routing. Certain unsupported
> operating systems may require setting the MPS Table Mode to APIC Disabled."
Oh nice. What does you /proc/interrupts look like compared to baremetal?
>
> (BTW, the kernel itself boots fine without Xen. So I'm not sure if this belongs
> to the LKML at all.)
It does not. But CC-ing xen-devel here for further tracking.
^ permalink raw reply
* Need some help about the build xen.efi
From: liang tang @ 2011-10-31 14:10 UTC (permalink / raw)
To: Jan Beulich, xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk
[-- Attachment #1.1: Type: text/plain, Size: 719 bytes --]
Hi,Jan
I have download xen unstable tree which include your efi patch,and try
to build xen.efi ,but there only have xen.gz ,don't have xen.efi .I find
the file xen\arch\x86\efi\disable have report some error : ld don't
support -m i386pep. my gcc version is 4.6.1.
if modify the i386pep to elf_x86_64 ,the build can continue ,and report
other error --subsystem=10 and --image-base=0xffff82c480000000 unrecognized.
do you have any suggestion about that? thank you very much!
the detail is follow.
ld: unrecognized option '--image-base=0xffff82c480000000'
In the xen/arch/x86/efi/disabled
ld: unrecognized emulation mode: i386pep
Supported emulations: elf_x86_64 elf32_x86_64 elf_i386 i386linux elf_l1om
liang.
[-- Attachment #1.2: Type: text/html, Size: 1746 bytes --]
[-- Attachment #2: Type: text/plain, Size: 138 bytes --]
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
^ permalink raw reply
* Designing a GATT write D-Bus API (was: Re: GATT Dbus API on BlueZ - attirbute-api.txt modifications)
From: Anderson Lizardo @ 2011-10-31 14:10 UTC (permalink / raw)
To: Ajay Pillai
Cc: Ganir, Chen, Luiz Augusto von Dentz, Mat Martineau,
Claudio Takahasi, linux-bluetooth@vger.kernel.org,
bgix@codeaurora.org, ingas@codeaurora.org
Hi Ajay,
Thanks for bringing these specific items. I took the liberty of
changing the subject so it goes in a separate, less generic thread.
On Mon, Oct 31, 2011 at 9:35 AM, Ajay Pillai <Ajay.Pillai@csr.com> wrote:
> Can we detail out the "write" API design once again, please? There has been too much discussion and hence I am not sure, which way it is going.
>
> There are two main aspects to write"
>
> 1) The write mechanism -
> a) Do we do a setproperty() or do we add a new API writeValue()?
Currently implemented (just verified): SetProperty() on the "Value"
property issues a GATT Write Command. Connection establishment is
attempted if not up yet, but no completion signal seems to be sent.
If we were to have a ReadValue() with specific semantics, we could
have WriteValue() with similar semantics (but for writing), at least
for consistency.
> b) Is the method blocking or non-blocking?
SetProperty() is non-blocking, and I think it is not appropriate to
block it (for compatibility with applications which use
SetProperty()).
Even for a WriteValue(), I strongly suggest going with a non-blocking
implementation, maybe with some completion signal or callback.
> c) If non-blocking,what is the mechanism like?
> My understanding - if the write is called while the connection is not active, then the value is going to be buffered in BlueZ while BlueZ tries to get the connection up. When the connection comes up, after the write operation is complete, BlueZ will emit a signal indicating that it is written.
This is how the current non-bloncking SetProperty() method works
(aside from the missing completion signal).
For a WriteValue(), a similar approach could be taken.
> 2) The choice of write operation - Does it lie within BlueZ or is it given to DBUS Apps. I guess Anderson is okay with giving some control to the DBUS App.
Then you mean Chen, as I'm with the "no full control to applications
by default" idea :)
> a) write without response, write with response, signed write without response -
> I believe the DBUS App must be allowed to indicate its preference among these to BlueZ. BlueZ must be able to meet this preference in most of the cases, but in cases where it cannot, BlueZ must throw an error. It would in most cases be a wrong request from App (using signed write on a long characteristic, for instance)
In this case, you are basically suggesting delegating characteristic
property and security level checks to each application and a more
extensive D-Bus API (like Chen's proposal). My only concern on this is
the "complex API by default" policy, instead of extending as
necessary. But I have no strong opinions on this (and it for sure does
not affect cross-application operation).
> b) Write long characteristics value
> This, I believe, is a value add to Apps, if done autonomously within BlueZ.
I agree. And would be consistent with the (already implemented) Read
Long Characteristic Value.
> c) reliable write of one characteristic
> Not covered in this discussion so far. But worth having a separate API like writeReliable(offset, value, {"prepare","execute"})?
> d) reliable write used for atomic write of multiple characteristics
> Not covered in this discussion so far. Same API as above. But an "execute" operation on any char object will do complete the reliable write operation.
I still have not suggestion regarding the Reliable Write API. I would
be happy to discuss on some API proposal specific to it.
> Regarding reliable writes, we will need to figure out a state machine within BlueZ that blocks out other operations on a remote server during a prepare-execute cycle and also an exit criteria from that "block-other-operations" state to cater to Aps that disappear after doing a "prepare".
Yes, and that requires more D-Bus API design experience than what I
currently have :). If anyone wants to try this, this API can be sent
later as extension.
Regards,
--
Anderson Lizardo
Instituto Nokia de Tecnologia - INdT
Manaus - Brazil
^ permalink raw reply
* Re: [Qemu-devel] [PATCH] qed: adjust the way to get nb_sectors
From: Stefan Hajnoczi @ 2011-10-31 14:11 UTC (permalink / raw)
To: Zhi Yong Wu; +Cc: Kevin Wolf, Zhi Yong Wu, qemu-devel, stefanha
In-Reply-To: <CAEH94LgtD2MBt0X6HQ9r+MX708qgC2L6X6qCpDGKe=1nL-ewew@mail.gmail.com>
On Mon, Oct 31, 2011 at 8:25 AM, Zhi Yong Wu <zwu.kernel@gmail.com> wrote:
> On Mon, Oct 31, 2011 at 4:10 PM, Kevin Wolf <kwolf@redhat.com> wrote:
>> Am 31.10.2011 04:01, schrieb Zhi Yong Wu:
>>> It is better to use qiov.size in qed-table.c to get nb_sectors than iov.iov_len.
>>>
>>> Signed-off-by: Zhi Yong Wu <wuzhy@linux.vnet.ibm.com>
>>
>> The commit message should probably say why it's better. Not saying
>> otherwise, but I can't see the different at the first sight.
> They are equal, but if the number of iov isn't ONE, they will be not
> equal. qiov.size contains the sum of all iov's size while iov.iov_len
> is only the size of one iov. Although in current scenario, they are
> equal, but i think that it is better if qiov.size is used.
I see your reasoning. Especially in qed_read_table_cb() it's nice to
use qiov->size because that function doesn't obviously use a single
struct iovec.
If you want to change it I agree but please send a patch with a proper
explanation that mentions that this is purely a refactoring (does not
change behavior) and why.
Stefan
^ permalink raw reply
* [PATCH 01/51] ARM: reset: introduce arm_arch_reset function pointer
From: Russell King - ARM Linux @ 2011-10-31 14:13 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <20111029135653.GA25057@mudshark.cambridge.arm.com>
On Sat, Oct 29, 2011 at 02:56:53PM +0100, Will Deacon wrote:
> The only downside is that I have to go over all of the platforms again
> unless I can polish up my Coccinelle-fu. Ho-hum.
Well, I've just given coccinelle a go, and having read all the hype about
it, I'm completely disappointed with it to the extent that I'm going to
uninstall the tool from my system (unless someone can point out what I'm
doing wrong.)
I thought I'd give it a spin on a nice simple change - deleting the
local_irq_disable() calls inside arch_reset() (irqs have already been
disabled by this time):
@@
identifier mode, cmd;
@@
arch_reset(char mode, const char *cmd)
{
...
- local_irq_disable();
...
}
$ spatch -sp_file arch_reset-1.cocci arch/arm/*/include/*/system.h > arch_reset-1.diff
The diff it created contains:
--- arch/arm/mach-ep93xx/include/mach/system.h 2011-03-04 19:52:46.419272878 +0000
+++ /tmp/cocci-output-380-f841cc-system.h 2011-10-31 13:54:52.066705107 +0000
...
--- arch/arm/mach-iop32x/include/mach/system.h 2011-03-04 19:52:46.445272534 +0000
+++ /tmp/cocci-output-380-c0e3f4-system.h 2011-10-31 13:54:52.072705051 +0000
...
--- arch/arm/mach-ixp2000/include/mach/system.h 2011-03-04 19:52:46.449272482 +0000
+++ /tmp/cocci-output-380-467f17-system.h 2011-10-31 13:54:52.079704984 +0000
...
which in total deletes 6 lines. However, the patch is rejected by
git apply and gnu patch as it stands - it needs the filenames to be
edited to something more reasonable. So that also takes six edits.
I might as well have used grep and an editor to do the job:
$ files=$(grep -l local_irq_disable arch/arm/*/include/*/system.h)
$ uemacs $files
$ git add $files
$ git commit
And for a more complex task, you're still going to have to mess about
editing filenames. This seems (to me) to make the tool rather awkward
to use. On the plus side, for complex changes it does help to make
you look at the generated patch rather than just believing it to be
correct.
^ permalink raw reply
* Implementation of name-resolve procedures in mgmtops
From: Ilia, Kolominsky @ 2011-10-31 14:14 UTC (permalink / raw)
To: johan.hedberg@gmail.com; +Cc: linux-bluetooth@vger.kernel.org
Hi Johan,
Could you please outline the intended mechanics for the new
Name-resolve procedures in mgmtops?
- What is the purpose of Confirm Name command?
( I see that you`d added it but not implemented )
- What are the main differences in the mechanics between
the hciops and mgmtops?
- Are there any changes in user behavior?
Regards
Ilia Kolominsky
iliak@ti.com
Direct: +972(9)7906231
Mobile: +972(54)909009
^ permalink raw reply
* [PATCH] Bluetooth: correct debug output
From: Emeltchenko Andrei @ 2011-10-31 14:17 UTC (permalink / raw)
To: linux-bluetooth
From: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
l2cap_set_timer function prints sk instead of chan pointer.
Signed-off-by: Andrei Emeltchenko <andrei.emeltchenko@intel.com>
---
net/bluetooth/l2cap_core.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/net/bluetooth/l2cap_core.c b/net/bluetooth/l2cap_core.c
index ded2068..c496e3e 100644
--- a/net/bluetooth/l2cap_core.c
+++ b/net/bluetooth/l2cap_core.c
@@ -220,7 +220,7 @@ static u16 l2cap_alloc_cid(struct l2cap_conn *conn)
static void l2cap_set_timer(struct l2cap_chan *chan, struct timer_list *timer, long timeout)
{
- BT_DBG("chan %p state %d timeout %ld", chan->sk, chan->state, timeout);
+ BT_DBG("chan %p state %d timeout %ld", chan, chan->state, timeout);
if (!mod_timer(timer, jiffies + msecs_to_jiffies(timeout)))
chan_hold(chan);
--
1.7.4.1
^ permalink raw reply related
* Re: [PATCH v3] usb: ehci: report Data Buffer Error in debug mode
From: Alan Stern @ 2011-10-31 14:17 UTC (permalink / raw)
To: Greg KH, Vikram Pandita; +Cc: USB list, linux-omap-u79uwXL29TY76Z2rM5mHXA
In-Reply-To: <1320004509-9411-1-git-send-email-vikram.pandita-l0cyMroinI0@public.gmane.org>
On Sun, 30 Oct 2011, Vikram Pandita wrote:
> From: Vikram Pandita <vikram.pandita-l0cyMroinI0@public.gmane.org>
>
> Data Buffer Error as per spec section 4.15.1.1.2
> results when there is Underrun or Overrun condition.
>
> This error is considered non-fatal and never gets reported.
> Its a very good indication on things going wrong at system level,
> like running memory at much slower speed.
>
> This is a good error to flag allowing system level corrections.
>
> An issue was found with OMAP4460 board where DDR had to be run
> at full speed and this logging helped.
>
> Signed-off-by: Vikram Pandita <vikram.pandita-l0cyMroinI0@public.gmane.org>
> Reviewed-by: Marek Vasut <marek.vasut-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
> Signed-off-by: Vikram Pandita <vikram.pandita-l0cyMroinI0@public.gmane.org>
> ---
> v1: original patch
>
> v2: fix review comments from Alan Stern
> * use usb_endpoint_num, usb_endpoint_dir_in
>
> v3: More comments from Alan Stern
> * indent, use qh
>
> drivers/usb/host/ehci-q.c | 11 +++++++++++
> 1 files changed, 11 insertions(+), 0 deletions(-)
>
> diff --git a/drivers/usb/host/ehci-q.c b/drivers/usb/host/ehci-q.c
> index 4e4066c..f136f7f1 100644
> --- a/drivers/usb/host/ehci-q.c
> +++ b/drivers/usb/host/ehci-q.c
> @@ -373,6 +373,17 @@ qh_completions (struct ehci_hcd *ehci, struct ehci_qh *qh)
> retry_xacterr:
> if ((token & QTD_STS_ACTIVE) == 0) {
>
> + /* Report Data Buffer Error: non-fatal but useful */
> + if (token & QTD_STS_DBE)
> + ehci_dbg(ehci,
> + "detected DataBufferErr for urb %p ep%d%s len %d, qtd %p [qh %p]\n",
> + urb,
> + usb_endpoint_num(&urb->ep->desc),
> + usb_endpoint_dir_in(&urb->ep->desc) ? "in" : "out",
> + urb->transfer_buffer_length,
> + qtd,
> + qh);
> +
> /* on STALL, error, and short reads this urb must
> * complete and all its qtds must be recycled.
> */
Signed-off-by: Alan Stern <stern-nwvwT67g6+6dFdvTe/nMLpVzexx5G7lz@public.gmane.org>
--
To unsubscribe from this list: send the line "unsubscribe linux-usb" 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: Prevent auto-mounting?
From: Gary Thomas @ 2011-10-31 14:17 UTC (permalink / raw)
To: Poky Project
In-Reply-To: <4EAA84DC.8010300@mlbassoc.com>
On 2011-10-28 04:33, Gary Thomas wrote:
> How do I keep a file system from being automatically mounted?
> In particular, I want to automate this sequence:
> * [re]partition a disk using sfdisk
> * format the partitions
> * mount & use the partitions
>
> The problem I have is that when sfdisk completes and the disk label
> is reread by the kernel, some process(?) goes off and tries to mount
> the partitions. This not only gets in the way of reformatting those
> partitions, but it may be 100% incorrect as the disk layout may have
> changed.
>
> Any ideas what process is doing this and how I stop it?
>
I found that adding the device to /etc/udev/mount.blacklist prevents
the device from being mounted just after being [re]partitioned. In
my case, this command does the trick:
# echo /dev/mmcblk0p1 >>/etc/udev/mount.blacklist
--
------------------------------------------------------------
Gary Thomas | Consulting for the
MLB Associates | Embedded world
------------------------------------------------------------
^ permalink raw reply
* Re: barebox on gta04
From: Robert Schwebel @ 2011-10-31 14:18 UTC (permalink / raw)
To: Johannes Schauer; +Cc: gta04-owner, barebox
In-Reply-To: <20111031140539.GA7387@hoothoot>
On Mon, Oct 31, 2011 at 03:05:39PM +0100, Johannes Schauer wrote:
> On Mon, Oct 31, 2011 at 12:57:48PM +0100, Robert Schwebel wrote:
> > Does barebox now work on your gtk04?
>
> nope, I'm relying on input from you guys ;)
>
> > If not, I'd be willing to help with the port, but somebody would
> > have to organze a hardware for us in that case.
>
> if there are no leftover units in munich and you are located in
> germany i could lend you mine for one or two weeks?
We are located in Germany (see signature). However, the variant with the
leftover units would be preferred :-)
rsc
--
Pengutronix e.K. | |
Industrial Linux Solutions | http://www.pengutronix.de/ |
Peiner Str. 6-8, 31137 Hildesheim, Germany | Phone: +49-5121-206917-0 |
Amtsgericht Hildesheim, HRA 2686 | Fax: +49-5121-206917-5555 |
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* RE: UDP -> IPoIB -> Verbs
From: Hefty, Sean @ 2011-10-31 14:18 UTC (permalink / raw)
To: Or Gerlitz
Cc: Kelly Burkhart,
linux-rdma-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
In-Reply-To: <4EAE5DBD.4050701-VPRAkNaXOzVWk0Htik3J/w@public.gmane.org>
> Sean, wait, the rdmacm IPoIB port space allows librdmacm consumers to
> subscribe to multicast groups created by IPoIB and vise versa, so for
> udp/multicast the answer is yes, agree?
Good point - for multicast it should work.
--
To unsubscribe from this list: send the line "unsubscribe linux-rdma" 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: [1/4] powerpc: Revert show_regs() define for readability
From: Kumar Gala @ 2011-10-31 14:18 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: Linuxppc-dev list
In-Reply-To: <1ADB010A-A48C-4E71-91E0-94D60A3E676F@pobox.com>
On Oct 28, 2011, at 2:40 PM, Jimi Xenidis wrote:
>
> On Oct 5, 2011, at 9:53 PM, Kumar Gala wrote:
>
>> We had an existing ifdef for 4xx & BOOKE processors that got changed to
>> CONFIG_PPC_ADV_DEBUG_REGS. The define has nothing to do with
>> CONFIG_PPC_ADV_DEBUG_REGS. The define really should be:
>>
>> #if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
>>
>> and not
>>
>> #ifdef CONFIG_PPC_ADV_DEBUG_REGS
>>
>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>
>> ---
>> arch/powerpc/kernel/process.c | 2 +-
>> 1 files changed, 1 insertions(+), 1 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/process.c b/arch/powerpc/kernel/process.c
>> index 8f53954..a1b5981 100644
>> --- a/arch/powerpc/kernel/process.c
>> +++ b/arch/powerpc/kernel/process.c
>> @@ -657,7 +657,7 @@ void show_regs(struct pt_regs * regs)
>> if ((regs->trap != 0xc00) && cpu_has_feature(CPU_FTR_CFAR))
>> printk("CFAR: "REG"\n", regs->orig_gpr3);
>> if (trap == 0x300 || trap == 0x600)
>> -#ifdef CONFIG_PPC_ADV_DEBUG_REGS
>> +#if defined(CONFIG_4xx) || defined(CONFIG_BOOKE)
>> printk("DEAR: "REG", ESR: "REG"\n", regs->dar, regs->dsisr);
>
> I'll be needing "|| defined(CONFIG_PPC_BOOK3E)" added to this please.
> -jx
Under what platform is CONFIG_PPC_BOOK3E set and CONFIG_BOOKE is not?
- k
^ permalink raw reply
* Re: 1.0 Hard Freeze Logistics
From: Stefan Hajnoczi @ 2011-10-31 14:19 UTC (permalink / raw)
To: qemu-devel; +Cc: kvm-devel, Anthony Liguori
In-Reply-To: <4EAEA278.7000901@us.ibm.com>
On Mon, Oct 31, 2011 at 1:28 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> To make the Test Day more successful, please sign up to test a specific area
> on the Test[3] wiki page.
[...]
> [3] http://wiki.qemu.org/Planning/1.0/Testing
I just signed up for several block and tracing tests and encourage
everyone to get involved.
If you're looking for something to do you can test CD-ROM support.
Both host CD-ROM passthrough (/dev/cdrom) and ISO CD-ROM need testing,
especially media change (eject and changing the CD-ROM). There have
been many code changes in the area and we need to make sure things are
working correctly :).
Stefan
^ permalink raw reply
* Re: [Qemu-devel] 1.0 Hard Freeze Logistics
From: Stefan Hajnoczi @ 2011-10-31 14:19 UTC (permalink / raw)
To: qemu-devel; +Cc: Anthony Liguori, kvm-devel
In-Reply-To: <4EAEA278.7000901@us.ibm.com>
On Mon, Oct 31, 2011 at 1:28 PM, Anthony Liguori <aliguori@us.ibm.com> wrote:
> To make the Test Day more successful, please sign up to test a specific area
> on the Test[3] wiki page.
[...]
> [3] http://wiki.qemu.org/Planning/1.0/Testing
I just signed up for several block and tracing tests and encourage
everyone to get involved.
If you're looking for something to do you can test CD-ROM support.
Both host CD-ROM passthrough (/dev/cdrom) and ISO CD-ROM need testing,
especially media change (eject and changing the CD-ROM). There have
been many code changes in the area and we need to make sure things are
working correctly :).
Stefan
^ permalink raw reply
* [lm-sensors] [PATCH 1/3] hwmon: (w83627ehf) Properly report PECI
From: Jean Delvare @ 2011-10-31 14:19 UTC (permalink / raw)
To: lm-sensors
When temperature sources are PECI or AMD-SI agents, it makes no sense
to report their type as diode or thermistor. Instead we must report
their digital nature.
Signed-off-by: Jean Delvare <khali@linux-fr.org>
Cc: stable@kernel.org
---
drivers/hwmon/w83627ehf.c | 9 ++++++++-
1 file changed, 8 insertions(+), 1 deletion(-)
--- linux-3.2-rc0.orig/drivers/hwmon/w83627ehf.c 2011-10-31 14:21:09.000000000 +0100
+++ linux-3.2-rc0/drivers/hwmon/w83627ehf.c 2011-10-31 14:24:39.000000000 +0100
@@ -1812,7 +1812,14 @@ static inline void __devinit w83627ehf_i
diode = 0x70;
}
for (i = 0; i < 3; i++) {
- if ((tmp & (0x02 << i)))
+ const char *label = data->temp_label[data->temp_src[i]];
+
+ /* Digital source overrides analog type */
+ if (strncmp(label, "PECI", 4) = 0)
+ data->temp_type[i] = 6;
+ else if (strncmp(label, "AMD", 3) = 0)
+ data->temp_type[i] = 5;
+ else if ((tmp & (0x02 << i)))
data->temp_type[i] = (diode & (0x10 << i)) ? 1 : 3;
else
data->temp_type[i] = 4; /* thermistor */
--
Jean Delvare
_______________________________________________
lm-sensors mailing list
lm-sensors@lm-sensors.org
http://lists.lm-sensors.org/mailman/listinfo/lm-sensors
^ permalink raw reply
* Re: RFC: ESR_I/DLK processing
From: Kumar Gala @ 2011-10-31 14:19 UTC (permalink / raw)
To: Jimi Xenidis; +Cc: linuxppc-dev
In-Reply-To: <00A1F69B-FCB7-4F45-8BE4-4C4B35D53D59@pobox.com>
On Oct 28, 2011, at 3:43 PM, Jimi Xenidis wrote:
> arch/powerpc/kernel/head_fsl_booke.S has the following code:
>> /* Data Storage Interrupt */
>> START_EXCEPTION(DataStorage)
>> NORMAL_EXCEPTION_PROLOG
>> mfspr r5,SPRN_ESR /* Grab the ESR, save it, pass =
arg3 */
>> stw r5,_ESR(r11)
>> mfspr r4,SPRN_DEAR /* Grab the DEAR, save it, pass =
arg2 */
>> andis. r10,r5,(ESR_ILK|ESR_DLK)@h
>> bne 1f
>> EXC_XFER_EE_LITE(0x0300, handle_page_fault)
>> 1:
>> addi r3,r1,STACK_FRAME_OVERHEAD
>> EXC_XFER_EE_LITE(0x0300, CacheLockingException)
>=20
>=20
> I need something similar for A2 (and all book3e) and was wondering, =
why this isn't just:
>=20
>> diff --git a/arch/powerpc/mm/fault.c b/arch/powerpc/mm/fault.c
>> index 88abe70..8451822 100644
>> --- a/arch/powerpc/mm/fault.c
>> +++ b/arch/powerpc/mm/fault.c
>> @@ -159,6 +159,14 @@ int __kprobes do_page_fault(struct pt_regs =
*regs, unsigned long address,
>> }
>> #endif
>>=20
>> +#ifdef CONFIG_PPC_BOOK3E
>> + if (error_code & (ESR_DLK|ESR_ILK)) {
>> + /* detect that this is a privileged op and SIGILL */
>> + _exception(SIGILL, regs, ILL_PRVOPC, regs->nip);
>> + return 0;
>> + }
>> +#endif
>> +
>> if (notify_page_fault(regs))
>> return 0;
>=20
> Its not like this need to be fast or anything.
> I'd be happy to submit a patch that adds to fault.c and removed the =
I/DLK processing from head_fsl_booke.S
>=20
> Thoughts?
> -jx
Probably because at one point in time DSI had a fast path handling for =
us. I've got no issues w/the proposed patch, just remember to mixup the =
CONFIG_PPC_BOOK3E as we don't define that in 32-bit fsl-booke=20
- k=
^ permalink raw reply
* [PATCH] bonding:update speed/duplex for NETDEV_CHANGE
From: Weiping Pan @ 2011-10-31 14:19 UTC (permalink / raw)
To: netdev; +Cc: fubar, andy, linux-kernel, Weiping Pan
In-Reply-To: <4EAE0D9A.9060408@gmail.com>
Zheng Liang(lzheng@redhat.com) found a bug that if we config bonding with
arp monitor, sometimes bonding driver cannot get the speed and duplex from
its slaves, it will assume them to be 100Mb/sec and Full, please see
/proc/net/bonding/bond0.
But there is no such problem when uses miimon.
(Take igb for example)
I find that the reason is that after dev_open() in bond_enslave(),
bond_update_speed_duplex() will call igb_get_settings()
, but in that function,
it runs ethtool_cmd_speed_set(ecmd, -1); ecmd->duplex = -1;
because igb get an error value of status.
So even dev_open() is called, but the device is not really ready to get its
settings.
Maybe it is safe for us to call igb_get_settings() only after
this message shows up, that is "igb: p4p1 NIC Link is Up 1000 Mbps Full Duplex,
Flow Control: RX".
So I prefer to update the speed and duplex for a slave when reseices
NETDEV_CHANGE/NETDEV_UP event.
Signed-off-by: Weiping Pan <wpan@redhat.com>
---
drivers/net/bonding/bond_main.c | 19 ++++++++-----------
1 files changed, 8 insertions(+), 11 deletions(-)
diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c
index c34cc1e..f5458eb 100644
--- a/drivers/net/bonding/bond_main.c
+++ b/drivers/net/bonding/bond_main.c
@@ -3220,6 +3220,7 @@ static int bond_slave_netdev_event(unsigned long event,
{
struct net_device *bond_dev = slave_dev->master;
struct bonding *bond = netdev_priv(bond_dev);
+ struct slave *slave = NULL;
switch (event) {
case NETDEV_UNREGISTER:
@@ -3230,20 +3231,16 @@ static int bond_slave_netdev_event(unsigned long event,
bond_release(bond_dev, slave_dev);
}
break;
+ case NETDEV_UP:
case NETDEV_CHANGE:
- if (bond->params.mode == BOND_MODE_8023AD || bond_is_lb(bond)) {
- struct slave *slave;
-
- slave = bond_get_slave_by_dev(bond, slave_dev);
- if (slave) {
- u32 old_speed = slave->speed;
- u8 old_duplex = slave->duplex;
-
- bond_update_speed_duplex(slave);
+ slave = bond_get_slave_by_dev(bond, slave_dev);
+ if (slave) {
+ u32 old_speed = slave->speed;
+ u8 old_duplex = slave->duplex;
- if (bond_is_lb(bond))
- break;
+ bond_update_speed_duplex(slave);
+ if (bond->params.mode == BOND_MODE_8023AD) {
if (old_speed != slave->speed)
bond_3ad_adapter_speed_changed(slave);
if (old_duplex != slave->duplex)
--
1.7.4
^ 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.