* Re: [PATCH v4 0/4] ILK VT-d fix
From: Keith Packard @ 2011-10-24 15:37 UTC (permalink / raw)
To: Woodhouse, David, Ben Widawsky
Cc: Dave Airlie, intel-gfx@lists.freedesktop.org, Qu, Yan
In-Reply-To: <1319443974.13738.85.camel@shinybook.infradead.org>
[-- Attachment #1.1: Type: text/plain, Size: 396 bytes --]
On Mon, 24 Oct 2011 08:14:45 +0000, "Woodhouse, David" <david.woodhouse@intel.com> wrote:
> The IOMMU patches are now in Linus' tree and thus will be in the 3.1
> release. Are we going to push the graphics patches in time for the 3.1
> release too?
The graphics patches are in the 3.2 pull request; they'll be available
for the 3.1 stable series though.
--
keith.packard@intel.com
[-- Attachment #1.2: Type: application/pgp-signature, Size: 827 bytes --]
[-- Attachment #2: Type: text/plain, Size: 159 bytes --]
_______________________________________________
Intel-gfx mailing list
Intel-gfx@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/intel-gfx
^ permalink raw reply
* [PATCH 1/2] sparse, llvm: Use new LLVM type system API for structs
From: Pekka Enberg @ 2011-10-24 15:37 UTC (permalink / raw)
To: linux-sparse; +Cc: Pekka Enberg, Christopher Li, Jeff Garzik, Linus Torvalds
To fix an issue with structs that refer to themselves:
struct symbol {
struct symbol *next;
};
convert the code to use new type system API introduced in LLVM 3.0 so that
there's a LLVMTypeRef of the struct we can look up while walking through the
struct members.
Cc: Christopher Li <sparse@chrisli.org>
Cc: Jeff Garzik <jgarzik@redhat.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Pekka Enberg <penberg@kernel.org>
---
sparse-llvm.c | 15 +++++++++++++--
1 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/sparse-llvm.c b/sparse-llvm.c
index fc0c2e9..14744e5 100644
--- a/sparse-llvm.c
+++ b/sparse-llvm.c
@@ -40,15 +40,26 @@ static LLVMTypeRef sym_struct_type(struct symbol *sym)
{
LLVMTypeRef elem_types[MAX_STRUCT_MEMBERS];
struct symbol *member;
+ char buffer[256];
+ LLVMTypeRef ret;
unsigned nr = 0;
+ sprintf(buffer, "%.*s", sym->ident->len, sym->ident->name);
+
+ ret = LLVMStructCreateNamed(LLVMGetGlobalContext(), buffer);
+
FOR_EACH_PTR(sym->symbol_list, member) {
+ LLVMTypeRef member_type;
+
assert(nr < MAX_STRUCT_MEMBERS);
- elem_types[nr++] = symbol_type(member);
+ member_type = symbol_type(member);
+
+ elem_types[nr++] = member_type;
} END_FOR_EACH_PTR(member);
- return LLVMStructType(elem_types, nr, 0 /* packed? */);
+ LLVMStructSetBody(ret, elem_types, nr, 0 /* packed? */);
+ return ret;
}
static LLVMTypeRef sym_ptr_type(struct symbol *sym)
--
1.7.6.4
^ permalink raw reply related
* [Buildroot] libtool: Version mismatch error
From: marco_cantu_ranzani at libero.it @ 2011-10-24 15:36 UTC (permalink / raw)
To: buildroot
./libtool: line 1300: func_opt_split: command not found
libtool: Version mismatch error. This is libtool 2.2.10, but the
libtool: definition of this LT_INIT comes from an older release.
libtool: You should recreate aclocal.m4 with macros from libtool 2.2.10
The same problem but while compiling PTH 2.0.7
Anyone?
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 29/35] scsi-disk: remove cluster_size
From: Paolo Bonzini @ 2011-10-24 15:36 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel
In-Reply-To: <4EA57FD6.4070703@redhat.com>
On 10/24/2011 05:10 PM, Kevin Wolf wrote:
>> > - bdrv_get_geometry(s->qdev.conf.bs,&nb_sectors);
>> > - nb_sectors /= s->cluster_size;
>> > - if (nb_sectors) {
>> > - nb_sectors--;
>> > + if (s->qdev.blocksize) {
> When would it be 0? And wouldn't we crash with a zero blocksize anyway?
blocksize can be zero when passing through a removable medium and no
medium has ever been inserted in the disk since the guest was started.
In practice it won't crash because the guest will always send READ
CAPACITY first, will see a unit attention condition, and will not
attempt a read.
A more complete solution involves asking raw-posix for the logical block
size (right now logical_block_size acts as both the emulated and host
block size). This would also be useful to make cache=none work with
4k-sector disks without manually specifying logical_block_size.
However, it's not 1.0 material.
Paolo
^ permalink raw reply
* RE: [PATCHv4] DMAEngine: Define interleaved transfer request api
From: Vinod Koul @ 2011-10-24 15:27 UTC (permalink / raw)
To: Bounine, Alexandre, Russell King, Williams, Dan J
Cc: Jassi Brar, Barry Song, linux-kernel, DL-SHA-WorkGroupLinux,
Dave Jiang
In-Reply-To: <0CE8B6BE3C4AD74AB97D9D29BD24E5520236801F@CORPEXCH1.na.ads.idt.com>
On Mon, 2011-10-24 at 05:36 -0700, Bounine, Alexandre wrote:
> > I think we all agree that this fits the dma_slave case :)
> >
> > As for changing in dmaengine to u64, if we are thinking this as
> slave
> > usage, then ideally we should not make assumption of the address
> type
> > of
> > peripheral so we should only move the dma_slave_config address
> fields
> > to
> > u64, if that helps in RIO case. Moving other usages would be insane.
> >
> > At this point we have two proposals
> > a) to make RIO exceptional case and add RIO specific stuff.
> > b) make dmaengine transparent and add additional argument
> > in .device_prep_slave_sg() callback which is subsystem dependent.
> > Current dmacs and those who don't need it will ignore it.
> >
> > ATM, I am leaning towards the latter, for the main reason to keep
> > dmaengine away from subsystem details.
> >
> Both proposals will work for RapidIO but second option looks more
> universal and may be used by another subsystem in the future.
> My vote goes to the option b).
Thanks for the vote :D
I would really like to hear from Dan, Jassi and Russell as well.
--
~Vinod
^ permalink raw reply
* Re: [PATCH V2 2/4] MIPS: Add board support for Loongson1B
From: Giuseppe CAVALLARO @ 2011-10-24 15:35 UTC (permalink / raw)
To: Kelvin Cheung
Cc: Wu Zhangjin, linux-mips, linux-kernel, ralf, r0bertz, netdev
In-Reply-To: <CAJhJPsXxUAuF9HdivLd66MQC45mz-iYAuF1SdGdU=-duxJJ5bQ@mail.gmail.com>
On 10/24/2011 4:05 PM, Kelvin Cheung wrote:
> 2011/10/24, Giuseppe CAVALLARO <peppe.cavallaro@st.com>:
>> Hello Kelvin.
>>
>> On 10/24/2011 12:36 PM, Kelvin Cheung wrote:
>>
>> [snip]
>>
>>> According to datasheet of Loongson 1B, the buffer size in RX/TX
>>> descriptor is only 2KB. So the Loongson1B's GMAC could not handle
>>> jumbo frames. And the second buffer is useless in this case. Am I
>>> right? Is there a better way than ifdef CONFIG_MACH_LOONGSON1 to
>>> avoid duplicate code?
>>
>> Sorry for my misunderstanding.
>>
>> I think you have to use the normal descriptor and remove the enh_desc
>> from the platform w/o modifying the driver at all.
>>
>> The driver will be able to select/configure all automatically (also jumbo).
>>
>> Let me know.
>
> That's the problem.
> The bitfield definition of Loongson1B is also different from normal descriptor.
The problem is not in the Loongson1B gmac.
The normal descriptor fields in the stmmac refer to an old synopsys
databook.
New chips have the same structure you have added; so we should fix this
in the driver w/o breaking the compatibility for old chips.
I kindly ask you to confirm if the currently normal descriptor structure
(w/o your changes) doesn't work on your platform.
Did you test it?
> Moreover, I want to enable the TX checksum offload function which is
> not supported in normal descriptor.
> Any suggestions?
It is supported but you have to pass from the platform: tx_coe = 1.
Peppe
>
>> Note:
>> IIRC, there is a bit difference in case of normal descriptors for
>> Synopsys databook newer than the 1.91 (I used for testing this mode).
>> In any case, I remember that, on some platforms, the normal descriptors
>> have been used w/o problems also on these new chip generations.
>>
>> Peppe
>>
>>
>
>
^ permalink raw reply
* Re: [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 15:34 UTC (permalink / raw)
To: Linus Walleij, Russell King - ARM Linux
Cc: Sebastian Rasmussen, linux-mmc@vger.kernel.org,
linux-arm-kernel@lists.infradead.org
In-Reply-To: <4EA58368.6050704@stericsson.com>
Ulf Hansson wrote:
> Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>>> [Russell]
>>>> The MCIPWR signal controls the external power switch. This is the only
>>>> signal for it. This is the only connection for it. There is no other
>>>> control form for this power switch.
>>>>
>>> Then we are only left to use the variant struct I believe. In principle, a
>>> flag in the variant struct, could indicate whether it is OK to disable the
>>> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
>> Yep I think the best could be to add some variant named
>> bool external_card_power; and then document in the kerneldoc that this
>> means the driver can clear MMCIPWR without risk of cutting the power
>> to the card.
>>
>> This should be true for Ux500, U300 and Nomadik (just checked the designs -
>> they all have external regulators).
>>
>
> Could we assume that all boards which utilizes the ARM PL180 are using
> the MMCIPWR register to control power the card? Or should we add a new
> amba mmci platform member so this is configurable for each board?
>
> An option could also be if we might want to simplify code to just skip
> the entire runtime_suspend|idle|resume function (ie stubb it or
> something) for these kind of boards?
>
> What do you prefer?
By the way, there is also another option. In the runtime_suspend
function for ARM PL180 block we can use mmc_power_save_host (and then
also disable vcore etc) and vice verse in runtime_resume with
mmc_power_restore_host.
Of course, these kind of operations takes quite some time to execute and
therefore we use a much bigger timeout than 50 ms (for example 10 s
instead) for ARM PL180.
Just an idea...
>
>> So the state save/restore and amba_vcore_disable(adev); should be done
>> only for those variants.
>>
>> However this:
>>
>> clk_disable(host->clk);
>>
>> We ought to be able to do for *all* variants, provided we can create
>> pm_runtime_get/put and delay properly to cover all bus traffic
>> (looks like the patch already does that), plus all the time the card is
>> signalling busy. The best I can think of is to just return -EBUSY to runtime
>> PM like this:
>>
>> if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
>> return -EBUSY;
>>
>> Yours,
>> Linus Walleij
>>
>
>
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 35/35] scsi-disk: add scsi-block for device passthrough
From: Kevin Wolf @ 2011-10-24 15:38 UTC (permalink / raw)
To: Paolo Bonzini; +Cc: qemu-devel
In-Reply-To: <4EA5841A.2080406@redhat.com>
Am 24.10.2011 17:28, schrieb Paolo Bonzini:
> On 10/24/2011 05:28 PM, Kevin Wolf wrote:
>>> scsi-block is a new device that supports device passthrough of Linux
>>>> block devices (i.e. /dev/sda, not /dev/sg0). It uses SG_IO for commands
>>>> other than I/O commands, and regular AIO read/writes for I/O commands.
>>>> Besides being simpler to configure (no mapping required to scsi-generic
>>>> device names), this removes the need for a large bounce buffer and,
>>>> in the future, will get scatter/gather support for free from scsi-disk.
>>>>
>>>> Signed-off-by: Paolo Bonzini<pbonzini@redhat.com>
>>
>> This doesn't seem to use much of scsi-disk, so what about exporting
>> &scsi_disk_reqops and adding a separate file scsi-block.c? Would make
>> things a bit more symmetrical between scsi-disk and scsi-generic.
>>
>> Or will future patches add code that depends on internal interfaces of
>> scsi-disk?
>
> It already uses some internal interfaces: scsi_initfn, scsi_disk_reset,
> scsi_destroy, sizeof(SCSIDiskState).
Right... I don't like it much in scsi-disk.c, but what can you do.
Exporting everything wouldn't be nicer.
Kevin
^ permalink raw reply
* [PATCH] mmc: mmci: Improve runtime PM support
From: Ulf Hansson @ 2011-10-24 15:34 UTC (permalink / raw)
To: linux-arm-kernel
In-Reply-To: <4EA58368.6050704@stericsson.com>
Ulf Hansson wrote:
> Linus Walleij wrote:
>> On Mon, Oct 24, 2011 at 1:48 PM, Ulf Hansson <ulf.hansson@stericsson.com> wrote:
>>> [Russell]
>>>> The MCIPWR signal controls the external power switch. This is the only
>>>> signal for it. This is the only connection for it. There is no other
>>>> control form for this power switch.
>>>>
>>> Then we are only left to use the variant struct I believe. In principle, a
>>> flag in the variant struct, could indicate whether it is OK to disable the
>>> vcore regulator and thus clear the MCIPWR when doing runtime_suspend.
>> Yep I think the best could be to add some variant named
>> bool external_card_power; and then document in the kerneldoc that this
>> means the driver can clear MMCIPWR without risk of cutting the power
>> to the card.
>>
>> This should be true for Ux500, U300 and Nomadik (just checked the designs -
>> they all have external regulators).
>>
>
> Could we assume that all boards which utilizes the ARM PL180 are using
> the MMCIPWR register to control power the card? Or should we add a new
> amba mmci platform member so this is configurable for each board?
>
> An option could also be if we might want to simplify code to just skip
> the entire runtime_suspend|idle|resume function (ie stubb it or
> something) for these kind of boards?
>
> What do you prefer?
By the way, there is also another option. In the runtime_suspend
function for ARM PL180 block we can use mmc_power_save_host (and then
also disable vcore etc) and vice verse in runtime_resume with
mmc_power_restore_host.
Of course, these kind of operations takes quite some time to execute and
therefore we use a much bigger timeout than 50 ms (for example 10 s
instead) for ARM PL180.
Just an idea...
>
>> So the state save/restore and amba_vcore_disable(adev); should be done
>> only for those variants.
>>
>> However this:
>>
>> clk_disable(host->clk);
>>
>> We ought to be able to do for *all* variants, provided we can create
>> pm_runtime_get/put and delay properly to cover all bus traffic
>> (looks like the patch already does that), plus all the time the card is
>> signalling busy. The best I can think of is to just return -EBUSY to runtime
>> PM like this:
>>
>> if ((readl(base + MMCISTATUS) & (MCI_CMDACTIVE | MCI_TXACTIVE| MCI_RXACTIVE))
>> return -EBUSY;
>>
>> Yours,
>> Linus Walleij
>>
>
>
^ permalink raw reply
* Re: [Qemu-devel] KVM call agenda for October 25
From: Luiz Capitulino @ 2011-10-24 15:34 UTC (permalink / raw)
To: Peter Maydell; +Cc: Paolo Bonzini, qemu-devel, kvm
In-Reply-To: <CAFEAcA_5-ZsJZX3fYDq8bLy8MRPuqqO5CCz=Q7pZurr_5O6ghg@mail.gmail.com>
On Mon, 24 Oct 2011 13:02:05 +0100
Peter Maydell <peter.maydell@linaro.org> wrote:
> On 24 October 2011 12:35, Paolo Bonzini <pbonzini@redhat.com> wrote:
> > On 10/24/2011 01:04 PM, Juan Quintela wrote:
> >> Please send in any agenda items you are interested in covering.
> >
> > - What's left to merge for 1.0.
>
> Things on my list, FWIW:
> * current target-arm pullreq
> * PL041 support (needs another patch round to fix a minor bug
> Andrzej spotted)
> * cpu_single_env must be thread-local
I submitted today the second round of QAPI conversions, which converts all
existing QMP query commands to the QAPI (plus some fixes).
I expect that to make 1.0.
^ permalink raw reply
* Re: ALSA PulseAudio plugin: snd_pcm_rewindable() returns >0, but snd_pcm_rewind() is broken
From: Pierre-Louis Bossart @ 2011-10-24 15:34 UTC (permalink / raw)
To: 'Nikolay Nikolov', alsa-devel
In-Reply-To: <4EA567EA.1020603@gmail.com>
> I'm using the max buffer size, which is 1048576 frames (4MB buffer,
> 16-bit stereo). The buffer is almost full when I try to rewind. I first
> call snd_pcm_rewindable() and it returns a greater than zero value.
> Then
> I call snd_pcm_rewind() with this value and it returns success, i.e. a
> positive value of frames actually rewound. I then call snd_pcm_writei
> with the number of frames rewound and I get a weird pause (several
> seconds) in the audio on the next poll. Audio then continues from the
> middle; the beginning of the audio that was rewritten immediately after
> rewind() has been dropped.
You want to avoid rewinding completely. Your audio hardware might have
prefetched data with the DMA subsystem. Rewinding completely might result in
an inconsistent configuration and possibly underflows. If you look at the
PulseAudio code, we've introduced some thresholds beyond which we don't
rewind (128 bytes or 1ms off the top of my head).
You might argue that snd_pcm_rewindable is broken, but it's somewhat
difficult to fix as the amount of prefetched data isn't modeled in the
driver and it's very much hardware-specific. Using a less aggressive
approach works fine on most hardware.
-Pierre
^ permalink raw reply
* lib/md5.o build problem
From: Antony Pavlov @ 2011-10-24 15:33 UTC (permalink / raw)
To: barebox
Hi!
I can't build barebox with md5sum command.
Here is the log:
$ date
Mon Oct 24 19:29:51 MSD 2011
$ git clone --branch next git://git.pengutronix.de/git/barebox.git
barebox.git.next
$ cd barebox.git.next
$ make ARCH=arm versatilepb_defconfig
$ sed "s/# CONFIG_CMD_MD5SUM.*/CONFIG_CMD_MD5SUM=y/" -i .config
$ make ARCH=arm oldconfig
$ make -j 2 ARCH=arm CROSS_COMPILE=arm-realview-linux-gnueabi-
...
CC lib/show_progress.o
CC lib/decompress_unlzo.o
make[1]: *** No rule to make target `lib/md5.o', needed by
`lib/built-in.o'. Stop.
make[1]: *** Waiting for unfinished jobs....
CC lib/process_escape_sequence.o
make: *** [lib] Error 2
make: *** Waiting for unfinished jobs....
LD fs/built-in.o
--
Best regards,
Antony Pavlov
_______________________________________________
barebox mailing list
barebox@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/barebox
^ permalink raw reply
* Re: Eclipse Plugin: ADT Version too old
From: Joshua Lock @ 2011-10-24 15:33 UTC (permalink / raw)
To: yocto
In-Reply-To: <4EA52BEF.8000100@communistcode.co.uk>
On 24/10/11 02:12, Jack Mitchell wrote:
> On 24/10/2011 10:03, Jack Mitchell wrote:
>> I am trying to use the new eclipse plugin, which I have had working
>> fine for the past couple of weeks until I switched from the master
>> branch to edison.
>>
>> I performed a fresh build using the stable edison branch, installed
>> the new 1.1 eclipse plugin and now whenever I try to setup the Yocto
>> eclipse environment I receive the following error:
>>
>> Yocto Preferences Configuration Error!
>> OECORE related items are not found in envrionement setup files.
>> The ADT version you're using is too old.
>> Please upgrade to our latest ADT Version!
>>
>> This pops up in a message box, not the eclipse console. I have
>> followed the ADT Setup guide to the letter and it's not playing ball -
>> could someone confirm this as working or point me towards a reason why
>> I may be getting this error?
>>
>> Cheers,
>> Jack.
>>
>>
>> _______________________________________________
>> yocto mailing list
>> yocto@yoctoproject.org
>> https://lists.yoctoproject.org/listinfo/yocto
>
> This is a pastebin of my current environment setup file:
>
> http://pastebin.com/4vnWPAD2
>
I'm not ADT expert but I expect the problem is this line:
export OECORE_DISTRO_VERSION="1.1+snapshot-20111021"
By switching to the edison branch you'll now have a DISTRO_VERSION of
"1.1", without the snapshot and date - hence version mismatch.
I'm not sure if you need to change the plugin or just build a new
meta-ide-support, though.
Cheers,
Joshua
--
Joshua Lock
Yocto Project "Johannes factotum"
Intel Open Source Technology Centre
^ permalink raw reply
* A note from the maintainer
From: Junio C Hamano @ 2011-10-24 15:32 UTC (permalink / raw)
To: git
Welcome to git development community.
This message is written by the maintainer and talks about how Git
project is managed, and how you can work with it.
* Mailing list and the community
The development is primarily done on the Git mailing list. Help
requests, feature proposals, bug reports and patches should be sent to
the list address <git@vger.kernel.org>. You don't have to be
subscribed to send messages. The convention on the list is to keep
everybody involved on Cc:, so it is unnecessary to ask "Please Cc: me,
I am not subscribed".
Before sending patches, please read Documentation/SubmittingPatches
and Documentation/CodingGuidelines to familiarize yourself with the
project convention.
If you sent a patch and you did not hear any response from anybody for
several days, it could be that your patch was totally uninteresting,
but it also is possible that it was simply lost in the noise. Please
do not hesitate to send a reminder message in such a case. Messages
getting lost in the noise is a sign that people involved don't have
enough mental/time bandwidth to process them right at the moment, and
it often helps to wait until the list traffic becomes calmer before
sending such a reminder.
The list archive is available at a few public sites as well:
http://news.gmane.org/gmane.comp.version-control.git/
http://marc.theaimsgroup.com/?l=git
http://www.spinics.net/lists/git/
and some people seem to prefer to read it over NNTP:
nntp://news.gmane.org/gmane.comp.version-control.git
When you point at a message in a mailing list archive, using
gmane is often the easiest to follow by readers, like this:
http://thread.gmane.org/gmane.comp.version-control.git/27/focus=217
as it also allows people who subscribe to the mailing list as gmane
newsgroup to "jump to" the article.
Some members of the development community can sometimes also be found
on the #git IRC channel on Freenode. Its log is available at:
http://colabti.org/irclogger/irclogger_log/git
* Reporting bugs
When you think git does not behave as you expect, please do not stop your
bug report with just "git does not work". "I tried to do X but it did not
work" is not much better, neither is "I tried to do X and git did Y, which
is broken". It often is that what you expect is _not_ what other people
expect, and chances are that what you expect is very different from what
people who have worked on git have expected (otherwise, the behavior
would have been changed to match that expectation long time ago).
Please remember to always state
- what you wanted to do;
- what you did (the version of git and the command sequence to reproduce
the behavior);
- what you saw happen;
- what you expected to see; and
- how the last two are different.
See http://www.chiark.greenend.org.uk/~sgtatham/bugs.html for further
hints.
* Repositories, branches and documentation.
My public git.git repository is at:
git://git.kernel.org/pub/scm/git/git.git/
git://repo.or.cz/alt-git.git
https://github.com/git/git
https://code.google.com/p/git-core/
Impatient people might have better luck with the latter two (there are a
few other mirrors I push into at sourceforge and github as well).
Their gitweb interfaces are found at:
http://git.kernel.org/?p=git/git.git
http://repo.or.cz/w/alt-git.git
There are three branches in git.git repository that are not about the
source tree of git: "html", "man", and "todo".
The "html" and "man" are preformatted documentation from the tip of
the "master" branch; the tip of "html" is visible at:
http://www.kernel.org/pub/software/scm/git/docs/
http://git-core.googlecode.com/git-history/html/git.html
The above URL is the top-level documentation page, and it may have
links to documentation of older releases.
The "todo" branch was originally meant to contain a TODO list for me,
but is mostly used to keep some helper scripts I use to maintain git.
For example, the script that was used to maintain the two documentation
branches are found there as dodoc.sh, which may be a good demonstration
of how to use a post-update hook to automate a task after pushing into a
repository.
There are four branches in git.git repository that track the source tree
of git: "master", "maint", "next", and "pu".
The "master" branch is meant to contain what are very well tested and
ready to be used in a production setting. Every now and then, a "feature
release" is cut from the tip of this branch and they typically are named
with three dotted decimal digits. The last such release was 1.7.7 done on
Sept 30, 2011. You can expect that the tip of the "master" branch is always
more stable than any of the released versions.
Whenever a feature release is made, "maint" branch is forked off from
"master" at that point. Obvious, safe and urgent fixes after a feature
release are applied to this branch and maintenance releases are cut from
it. The maintenance releases are named with four dotted decimal, named
after the feature release they are updates to; the last such release was
1.7.7.1. New features never go to this branch. This branch is also
merged into "master" to propagate the fixes forward.
A new development does not usually happen on "master". When you send a
series of patches, after review on the mailing list, a separate topic
branch is forked from the tip of "master" and your patches are queued
there, and kept out of "master" while people test it out. The quality of
topic branches are judged primarily by the mailing list discussions.
Topic branches that are in good shape are merged to the "next" branch. In
general, the "next" branch always contains the tip of "master". It might
not be quite rock-solid production ready, but is expected to work more or
less without major breakage. The "next" branch is where new and exciting
things take place. A topic that is in "next" is expected to be polished to
perfection before it is merged to "master" (that's why "master" can be
expected to stay more stable than any released version).
The "pu" (proposed updates) branch bundles all the remaining topic
branches. The topics on the branch are not complete, well tested, nor well
documented and need further work. When a topic that was in "pu" proves to
be in testable shape, it is merged to "next".
You can run "git log --first-parent master..pu" to see what topics are
currently in flight. Sometimes, an idea that looked promising turns out
to be not so good and the topic can be dropped from "pu" in such a case.
The two branches "master" and "maint" are never rewound, and "next"
usually will not be either. After a feature release is made from
"master", however, "next" will be rebuilt from the tip of "master"
using the topics that didn't make the cut in the feature release.
Note that being in "next" is not a guarantee to appear in the next
release, nor even in any future release. There were cases that topics
needed reverting a few commits in them before graduating to "master",
or a topic that already was in "next" was reverted from "next" because
fatal flaws were found in it after it was merged.
* Other people's trees, trusted lieutenants and credits.
Documentation/SubmittingPatches outlines to whom your proposed changes
should be sent. As described in contrib/README, I would delegate fixes
and enhancements in contrib/ area to the primary contributors of them.
Although the following are included in git.git repository, they have their
own authoritative repository and maintainers:
- git-gui/ comes from git-gui project, maintained by Pat Thoyts:
git://repo.or.cz/git-gui.git
- gitk-git/ comes from Paul Mackerras's gitk project:
git://git.kernel.org/pub/scm/gitk/gitk.git
I would like to thank everybody who helped to raise git into the current
shape. Especially I would like to thank the git list regulars whose help
I have relied on and expect to continue relying on heavily:
- Linus Torvalds, Shawn Pearce, Johannes Schindelin, Nicolas Pitre,
René Scharfe, Jeff King, Jonathan Nieder, Johan Herland, Johannes
Sixt, Sverre Rabbelier, Michael J Gruber, Nguyễn Thái Ngọc Duy,
Ævar Arnfjörð Bjarmason and Thomas Rast on general design and
implementation issues and reviews on the mailing list.
- Shawn and Nicolas Pitre on pack issues.
- Martin Langhoff, Frank Lichtenheld and Ævar Arnfjörð Bjarmason on
cvsserver and cvsimport.
- Paul Mackerras on gitk.
- Eric Wong, David D. Kilzer and Sam Vilain on git-svn.
- Simon Hausmann and Pete Wyckoff on git-p4.
- Jakub Narebski, John Hawley, Petr Baudis, Luben Tuikov, Giuseppe Bilotta on
gitweb.
- J. Bruce Fields, Jonathan Nieder, Michael J Gruber and Thomas Rast on
documentation (and countless others for proofreading and fixing).
- Alexandre Julliard on Emacs integration.
- David Aguilar and Charles Bailey for taking good care of git-mergetool
(and Theodore Ts'o for creating it in the first place) and git-difftool.
- Johannes Schindelin, Johannes Sixt, Erik Faye-Lund, Pat Thoyts and others
for their effort to move things forward on the Windows front.
- People on non-Linux platforms for keeping their eyes on portability;
especially, Randal Schwartz, Theodore Ts'o, Jason Riedy, Thomas Glanzmann,
Brandon Casey, Jeff King, Alex Riesen and countless others.
* This document
The latest copy of this document is found in git.git repository,
on 'todo' branch, as MaintNotes.
^ permalink raw reply
* [Buildroot] [RFC] Slides "Using Buildroot for real projects"
From: Thomas Petazzoni @ 2011-10-24 15:32 UTC (permalink / raw)
To: buildroot
In-Reply-To: <20111023123755.GA2455@tarshish>
Le Sun, 23 Oct 2011 14:37:55 +0200,
Baruch Siach <baruch@tkos.co.il> a ?crit :
> 1. Slide 23: missing -e in the 'echo' command
>
> $ echo "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> /dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0
>
> $ echo -e "/dev/mtdblock7\t\t/applog\tjffs2\tdefaults\t\t0\t0"
> /dev/mtdblock7 /applog jffs2 defaults 0 0
-e is not needed with sh:
$ echo "bla\nbli"
bla
bli
$ echo -e "bla\nbli"
-e bla
bli
> 2. Slides 24-27: header should be "Project-specific packages (x/5)", instead
> of "... (x/4)". (Can't TeX do this automatically somehow?)
Fixed. I don't know if TeX can do this automatically. Maybe.
Thanks for the comments. I also fixed the various comments raised by
Thomas. Thanks again!
Thomas
--
Thomas Petazzoni, Free Electrons
Kernel, drivers, real-time and embedded Linux
development, consulting, training and support.
http://free-electrons.com
^ permalink raw reply
* [U-Boot] [PATCH] mx31pdk: Add MC13783 PMIC support
From: Fabio Estevam @ 2011-10-24 15:32 UTC (permalink / raw)
To: u-boot
Add MC13783 PMIC support.
Tested by using the 'date' command, which reads the MC13783 RTC registers:
MX31PDK U-Boot > date
Date: 1970-01-01 (Thursday) Time: 2:22:35
Signed-off-by: Fabio Estevam <fabio.estevam@freescale.com>
---
board/freescale/mx31pdk/mx31pdk.c | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/board/freescale/mx31pdk/mx31pdk.c b/board/freescale/mx31pdk/mx31pdk.c
index 0e7e0ce..9f8bc53 100644
--- a/board/freescale/mx31pdk/mx31pdk.c
+++ b/board/freescale/mx31pdk/mx31pdk.c
@@ -30,6 +30,8 @@
#include <asm/arch/imx-regs.h>
#include <asm/arch/sys_proto.h>
#include <watchdog.h>
+#include <pmic.h>
+#include <fsl_pmic.h>
DECLARE_GLOBAL_DATA_PTR;
@@ -79,6 +81,16 @@ int board_init(void)
int board_late_init(void)
{
+ u32 val;
+ struct pmic *p;
+
+ pmic_init();
+ p = get_pmic();
+
+ /* Enable RTC battery */
+ pmic_reg_read(p, REG_POWER_CTL0, &val);
+ pmic_reg_write(p, REG_POWER_CTL0, val | COINCHEN);
+ pmic_reg_write(p, REG_INT_STATUS1, RTCRSTI);
#ifdef CONFIG_HW_WATCHDOG
mxc_hw_watchdog_enable();
#endif
--
1.6.0.4
^ permalink raw reply related
* What's cooking in git.git (Oct 2011, #09; Sun, 23)
From: Junio C Hamano @ 2011-10-24 15:31 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'.
It probably is a good point to stop taking new topics and start
switching our focus to fixing bugs in the topics already in 'master'.
Here are the repositories that have my integration branches:
With maint, master, next, pu, todo, html and man:
git://git.kernel.org/pub/scm/git/git.git
git://repo.or.cz/alt-git.git
https://code.google.com/p/git-core/
https://github.com/git/git
With only maint, master, html and man:
git://git.sourceforge.jp/gitroot/git-core/git.git
git://git-core.git.sourceforge.net/gitroot/git-core/git-core
With all the topics and integration branches but not todo, html or man:
https://github.com/gitster/git
By the way, I am planning to stop pushing the generated documentation
branches to the above repositories in the near term, as they are not
sources. The only reason the source repository at k.org has hosted these
branches was because it was the only repository over there that was
writable by me; it was an ugly historical and administrative workaround
and not a demonstration of the best practice.
They are pushed to their own separate repositories instead:
git://git.kernel.org/pub/scm/git/git-{htmldocs,manpages}.git/
git://repo.or.cz/git-{htmldocs,manpages}.git/
https://code.google.com/p/git-{htmldocs,manpages}.git/
https://github.com/gitster/git-{htmldocs,manpages}.git/
--------------------------------------------------
[New Topics]
* nd/pretty-commit-log-message (2011-10-23) 2 commits
- pretty.c: use original commit message if reencoding fails
- pretty.c: free get_header() return value
--------------------------------------------------
[Graduated to "master"]
* cn/doc-config-bare-subsection (2011-10-16) 1 commit
(merged to 'next' on 2011-10-17 at a6412d4)
+ Documentation: update [section.subsection] to reflect what git does
* jc/broken-ref-dwim-fix (2011-10-19) 3 commits
(merged to 'next' on 2011-10-19 at 40cad95)
+ resolve_ref(): report breakage to the caller without warning
+ resolve_ref(): expose REF_ISBROKEN flag
+ refs.c: move dwim_ref()/dwim_log() from sha1_name.c
(this branch is tangled with jc/check-ref-format-fixup.)
This only takes good bits from the failed jc/check-ref-format-fixup topic
and implements saner workaround for the recent breakage on the 'master'.
* jc/maint-remove-renamed-ref (2011-10-12) 1 commit
(merged to 'next' on 2011-10-12 at 819c3e4)
+ branch -m/-M: remove undocumented RENAMED-REF
* jc/make-tags (2011-10-18) 1 commit
(merged to 'next' on 2011-10-19 at b0b91bf)
+ Makefile: ask "ls-files" to list source files if available
* jc/match-refs-clarify (2011-09-12) 2 commits
(merged to 'next' on 2011-10-19 at b295e1e)
+ rename "match_refs()" to "match_push_refs()"
+ send-pack: typofix error message
* jc/unseekable-bundle (2011-10-13) 2 commits
(merged to 'next' on 2011-10-19 at 2978ee0)
+ bundle: add parse_bundle_header() helper function
+ bundle: allowing to read from an unseekable fd
* jk/daemon-msgs (2011-10-15) 1 commit
(merged to 'next' on 2011-10-15 at 415cf53)
+ daemon: give friendlier error messages to clients
(this branch is used by cb/daemon-permission-errors.)
* jk/maint-pack-objects-compete-with-delete (2011-10-14) 2 commits
(merged to 'next' on 2011-10-15 at 49479e4)
+ downgrade "packfile cannot be accessed" errors to warnings
+ pack-objects: protect against disappearing packs
* mh/ref-api (2011-10-16) 7 commits
(merged to 'next' on 2011-10-17 at 219000f)
+ clear_ref_cache(): inline function
+ write_ref_sha1(): only invalidate the loose ref cache
+ clear_ref_cache(): extract two new functions
+ clear_ref_cache(): rename parameter
+ invalidate_ref_cache(): expose this function in the refs API
+ invalidate_ref_cache(): take the submodule as parameter
+ invalidate_ref_cache(): rename function from invalidate_cached_refs()
(this branch is used by mh/ref-api-2 and mh/ref-api-3.)
* ph/transport-with-gitfile (2011-10-11) 5 commits
(merged to 'next' on 2011-10-12 at 6d58417)
+ Fix is_gitfile() for files too small or larger than PATH_MAX to be a gitfile
(merged to 'next' on 2011-10-06 at 891b8b6)
+ Add test showing git-fetch groks gitfiles
+ Teach transport about the gitfile mechanism
+ Learn to handle gitfiles in enter_repo
+ enter_repo: do not modify input
* po/insn-editor (2011-10-17) 1 commit
(merged to 'next' on 2011-10-19 at cbf5e0b)
+ "rebase -i": support special-purpose editor to edit insn sheet
* pw/p4-update (2011-10-17) 6 commits
(merged to 'next' on 2011-10-17 at f69f6cc)
+ git-p4: handle files with shell metacharacters
+ git-p4: keyword flattening fixes
+ git-p4: stop ignoring apple filetype
+ git-p4: recognize all p4 filetypes
+ git-p4: handle utf16 filetype properly
+ git-p4 tests: refactor and cleanup
* sc/difftool-skip (2011-10-14) 2 commits
(merged to 'next' on 2011-10-14 at b91c581)
+ t7800: avoid arithmetic expansion notation
(merged to 'next' on 2011-10-11 at 38d7e84)
+ git-difftool: allow skipping file by typing 'n' at prompt
* ss/inet-ntop (2011-10-18) 1 commit
(merged to 'next' on 2011-10-19 at 85469f6)
+ inet_ntop.c: Work around GCC 4.6's detection of uninitialized variables
--------------------------------------------------
[Stalled]
* hv/submodule-merge-search (2011-10-13) 4 commits
- submodule.c: make two functions static
- allow multiple calls to submodule merge search for the same path
- push: Don't push a repository with unpushed submodules
- push: teach --recurse-submodules the on-demand option
What the topic aims to achieve may make sense, but the implementation
looked somewhat suboptimal.
The fix-up at the tip queued on fg/submodule-auto-push topic has been
moved to this topic.
* sr/transport-helper-fix-rfc (2011-07-19) 2 commits
- t5800: point out that deleting branches does not work
- t5800: document inability to push new branch with old content
Perhaps 281eee4 (revision: keep track of the end-user input from the
command line, 2011-08-25) would help.
* jc/lookup-object-hash (2011-08-11) 6 commits
- object hash: replace linear probing with 4-way cuckoo hashing
- object hash: we know the table size is a power of two
- object hash: next_size() helper for readability
- pack-objects --count-only
- object.c: remove duplicated code for object hashing
- object.c: code movement for readability
I do not think there is anything fundamentally wrong with this series, but
the risk of breakage far outweighs observed performance gain in one
particular workload.
* jc/verbose-checkout (2011-10-16) 2 commits
- checkout -v: give full status output after switching branches
- checkout: move the local changes report to the end
This is just to leave a record that the reason why we do not do this not
because we are incapable of coding this, but because it is not a good idea
to do this. I suspect people who are new to git that might think they need
it would soon realize the don't.
Will keep in 'pu' as a showcase for a while and then will drop.
--------------------------------------------------
[Cooking]
* tc/submodule-clone-name-detection (2011-10-21) 2 commits
(merged to 'next' on 2011-10-23 at c18af03)
+ submodule::module_clone(): silence die() message from module_name()
+ submodule: whitespace fix
"git submodule clone" used to show unnecessary error message when
submodule mapping from name to path is not found in .gitmodules file.
Will merge to 'master'.
* jm/maint-gitweb-filter-forks-fix (2011-10-21) 1 commit
(merged to 'next' on 2011-10-21 at debedcd)
+ gitweb: fix regression when filtering out forks
Will merge to 'master' shortly.
* lh/gitweb-site-html-head (2011-10-21) 1 commit
(merged to 'next' on 2011-10-23 at 65075df)
+ gitweb: provide a way to customize html headers
Will merge to 'master' shortly.
* mh/ref-api-3 (2011-10-19) 11 commits
(merged to 'next' on 2011-10-23 at 92e2d35)
+ is_refname_available(): reimplement using do_for_each_ref_in_array()
+ names_conflict(): simplify implementation
+ names_conflict(): new function, extracted from is_refname_available()
+ repack_without_ref(): reimplement using do_for_each_ref_in_array()
+ do_for_each_ref_in_array(): new function
+ do_for_each_ref(): correctly terminate while processesing extra_refs
+ add_ref(): take a (struct ref_entry *) parameter
+ create_ref_entry(): extract function from add_ref()
+ parse_ref_line(): add a check that the refname is properly formatted
+ repack_without_ref(): remove temporary
+ Rename another local variable name -> refname
(this branch uses mh/ref-api-2.)
* mm/mediawiki-author-fix (2011-10-20) 1 commit
(merged to 'next' on 2011-10-23 at 9f85b67)
+ git-remote-mediawiki: don't include HTTP login/password in author
Will merge to 'master' shortly.
* rr/revert-cherry-pick (2011-10-23) 5 commits
- revert: simplify communicating command-line arguments
- revert: allow mixed pick and revert instructions
- revert: make commit subjects in insn sheet optional
- revert: simplify getting commit subject in format_todo()
- revert: free msg in format_todo()
The internals of "git revert/cherry-pick" has been further refactored to
serve as the basis for the sequencer.
Will merge to 'next'.
* jn/libperl-git-config (2011-10-21) 2 commits
(merged to 'next' on 2011-10-21 at 76e2d4b)
+ Add simple test for Git::config_path() in t/t9700-perl-git.sh
+ libperl-git: refactor Git::config_*
Will merge to 'master' shortly.
* jc/check-ref-format-fixup (2011-10-19) 2 commits
(merged to 'next' on 2011-10-19 at 98981be)
+ Revert "Restrict ref-like names immediately below $GIT_DIR"
(merged to 'next' on 2011-10-15 at 8e89bc5)
+ Restrict ref-like names immediately below $GIT_DIR
This became a no-op except for the bottom one which is part of the other
topic now.
Will discard once the other topic graduates to 'master'.
* cb/daemon-permission-errors (2011-10-17) 2 commits
- daemon: report permission denied error to clients
- daemon: add tests
The tip commit might be loosening things a bit too much.
Will keep in 'pu' until hearing a convincing argument for the patch.
* kk/gitweb-side-by-side-diff (2011-10-17) 2 commits
- gitweb: add a feature to show side-by-side diff
- gitweb: change format_diff_line() to remove leading SP from $diff_class
Fun.
Will keep in 'pu' until the planned re-roll comes.
* mh/ref-api-2 (2011-10-17) 14 commits
(merged to 'next' on 2011-10-19 at cc89f0e)
+ resolve_gitlink_ref_recursive(): change to work with struct ref_cache
+ Pass a (ref_cache *) to the resolve_gitlink_*() helper functions
+ resolve_gitlink_ref(): improve docstring
+ get_ref_dir(): change signature
+ refs: change signatures of get_packed_refs() and get_loose_refs()
+ is_dup_ref(): extract function from sort_ref_array()
+ add_ref(): add docstring
+ parse_ref_line(): add docstring
+ is_refname_available(): remove the "quiet" argument
+ clear_ref_array(): rename from free_ref_array()
+ refs: rename parameters result -> sha1
+ refs: rename "refname" variables
+ struct ref_entry: document name member
+ cache.h: add comments for git_path() and git_path_submodule()
(this branch is used by mh/ref-api-3.)
It is either merge this quickly to 'master' and hope there won't be any
more unexpected breakage that forces us to delay the release, or hold it
on 'next' until the next cycle. I am inclined to do the former, but not
quite ready to commit to it yet.
* dm/pack-objects-update (2011-10-20) 4 commits
- pack-objects: don't traverse objects unnecessarily
- pack-objects: rewrite add_descendants_to_write_order() iteratively
- pack-objects: use unsigned int for counter and offset values
- pack-objects: mark add_to_write_order() as inline
Need to re-read this before deciding what to do; it came a bit too late in
the cycle for a series that touches a seriously important part of the
system.
* jk/git-tricks (2011-10-21) 3 commits
(merged to 'next' on 2011-10-23 at 7c9bf71)
+ completion: match ctags symbol names in grep patterns
+ contrib: add git-jump script
+ contrib: add diff highlight script
* jc/signed-commit (2011-10-21) 7 commits
(merged to 'next' on 2011-10-23 at 03eec25)
+ pretty: %G[?GS] placeholders
+ parse_signed_commit: really use the entire commit log message
+ test "commit -S" and "log --show-signature"
+ t7004: extract generic "GPG testing" bits
+ log: --show-signature
+ commit: teach --gpg-sign option
+ Split GPG interface into its own helper library
This is to replace the earlier "signed push" experiments.
Will keep in 'next' during this cycle.
* sg/complete-refs (2011-10-21) 9 commits
- completion: remove broken dead code from __git_heads() and __git_tags()
- completion: fast initial completion for config 'remote.*.fetch' value
- completion: improve ls-remote output filtering in __git_refs_remotes()
- completion: query only refs/heads/ in __git_refs_remotes()
- completion: support full refs from remote repositories
- completion: improve ls-remote output filtering in __git_refs()
- completion: make refs completion consistent for local and remote repos
- completion: optimize refs completion
- completion: document __gitcomp()
Will merge to 'next' but won't merge further until an Ack or two from
people who have worked on the completion in the past comes.
* cn/fetch-prune (2011-10-15) 5 commits
(merged to 'next' on 2011-10-16 at 02a449e)
+ fetch: treat --tags like refs/tags/*:refs/tags/* when pruning
+ fetch: honor the user-provided refspecs when pruning refs
+ remote: separate out the remote_find_tracking logic into query_refspecs
+ t5510: add tests for fetch --prune
+ fetch: free all the additional refspecs
"git fetch --prune" used to prune remote tracking branches by comparing
what was actually fetched and what was configured to be fetched, which was
wrong.
Will merge to 'master' shortly.
* jc/request-pull-show-head-4 (2011-10-15) 11 commits
(merged to 'next' on 2011-10-15 at 7e340ff)
+ fmt-merge-msg.c: Fix an "dubious one-bit signed bitfield" sparse error
(merged to 'next' on 2011-10-10 at 092175e)
+ environment.c: Fix an sparse "symbol not declared" warning
+ builtin/log.c: Fix an "Using plain integer as NULL pointer" warning
(merged to 'next' on 2011-10-07 at fcaeca0)
+ fmt-merge-msg: use branch.$name.description
(merged to 'next' on 2011-10-06 at fa5e0fe)
+ request-pull: use the branch description
+ request-pull: state what commit to expect
+ request-pull: modernize style
+ branch: teach --edit-description option
+ format-patch: use branch description in cover letter
+ branch: add read_branch_desc() helper function
+ Merge branch 'bk/ancestry-path' into jc/branch-desc
Allow setting "description" for branches and use it to help communications
between humans in various workflow elements.
Will keep in 'next' during this cycle.
^ permalink raw reply
* Re: NFS4 BAD_STATEID loop (kernel 3.0.4)
From: Trond Myklebust @ 2011-10-24 15:31 UTC (permalink / raw)
To: David Flynn; +Cc: linux-nfs, Chuck Lever
In-Reply-To: <20111024145027.GF32587@rd.bbc.co.uk>
On Mon, 2011-10-24 at 14:50 +0000, David Flynn wrote:
> No. Time Source Destination Protocol Size Info
> 39 15:33:59.077143 172.29.190.28 172.29.120.140 NFS 370 V4 COMPOUND Call (Reply In 40) <EMPTY> PUTFH;WRITE;GETATTR
>
> Frame 39: 370 bytes on wire (2960 bits), 370 bytes captured (2960 bits)
> Ethernet II, Src: ChelsioC_07:49:6f (00:07:43:07:49:6f), Dst: All-HSRP-routers_be (00:00:0c:07:ac:be)
> Internet Protocol, Src: 172.29.190.28 (172.29.190.28), Dst: 172.29.120.140 (172.29.120.140)
> Transmission Control Protocol, Src Port: omginitialrefs (900), Dst Port: nfs (2049), Seq: 40433, Ack: 7449, Len: 304
> Remote Procedure Call, Type:Call XID:0x43ce4e16
> Network File System
> [Program Version: 4]
> [V4 Procedure: COMPOUND (1)]
> Tag: <EMPTY>
> length: 0
> contents: <EMPTY>
> minorversion: 0
> Operations (count: 3)
> Opcode: PUTFH (22)
> filehandle
> length: 36
> [hash (CRC-32): 0x6e4b15f3]
> decode type as: unknown
> filehandle: 7df3a75d5e1cd908000ab44c5b000000efc80200000a0300...
> Opcode: WRITE (38)
> stateid
Do you have an example of the stateid argument's value? Does it change
at all between separate WRITE attempts?
Cheers
Trond
--
Trond Myklebust
Linux NFS client maintainer
NetApp
Trond.Myklebust@netapp.com
www.netapp.com
^ permalink raw reply
* Re: [Qemu-devel] [Question] dump memory when host pci device is used by guest
From: Avi Kivity @ 2011-10-24 15:30 UTC (permalink / raw)
To: Dave Anderson
Cc: Jan Kiszka, Richard W.M. Jones, qemu-devel, Luiz Capitulino,
KAMEZAWA Hiroyuki
In-Reply-To: <54c9dc1d-3104-4f42-9a20-d7f4da516bdc@zmail05.collab.prod.int.phx2.redhat.com>
On 10/24/2011 05:25 PM, Dave Anderson wrote:
>
> ----- Original Message -----
> > On 10/24/2011 04:25 PM, Dave Anderson wrote:
> > > > The question is that: 'virsh dump' can not be used when host pci device
> > > > is used by guest. We are discussing how to fix the problem. We have determined
> > > > that introduce a new monitor command dump. Jan suggested that the core file's
> > > > format is gdb standard core format. Does crash support such format? If no,
> > > > is it possible to support such format?
> > >
> > > If you are talking about an ELF core dump of the user-space qemu-kvm process
> > > running on the host, then it's certainly not supported.
> >
> > No, an ELF image of the guest's physical memory.
>
> Well then that should be pretty straight forward to support. Depending upon
> how similar it would be to the "standard" kdump ELF format, the only other
> issue is how to determine the physical base address at which the kernel is
> loaded, in order to be able to translate the mapped kernel-text/static-data
> virtual region of the x86_64 arch (the __START_KERNEL_map region).
>
I guess an elf note would work for that?
--
I have a truly marvellous patch that fixes the bug which this
signature is too narrow to contain.
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 5/5] qxl: support async monitor screen dump
From: Gerd Hoffmann @ 2011-10-24 15:29 UTC (permalink / raw)
To: Alon Levy; +Cc: qemu-devel, mlureau, armbru, lcapitulino
In-Reply-To: <1319457739-14562-6-git-send-email-alevy@redhat.com>
On 10/24/11 14:02, Alon Levy wrote:
> Split qxl_spice_update_area_complete from qxl_render_update, use
> SPICE_INTERFACE_QXL_MINOR 2 introduced spice_qxl_update_area_dirty_async
> to retrive the dirty rectangles asyncronously (the previous
> spice_qxl_update_area_async did not accept a dirty rectangles array).
>
> Introduce SpiceAsyncMonitorScreenDump for a screen_dump.
That one conflicts with the screendump/SDL fixes pushed to the spice.v44
branch. Have you seen the mail? Had you time to look at the patches?
cheers,
Gerd
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 35/35] scsi-disk: add scsi-block for device passthrough
From: Paolo Bonzini @ 2011-10-24 15:28 UTC (permalink / raw)
To: Kevin Wolf; +Cc: qemu-devel
In-Reply-To: <4EA5842F.8050807@redhat.com>
On 10/24/2011 05:28 PM, Kevin Wolf wrote:
>> scsi-block is a new device that supports device passthrough of Linux
>> > block devices (i.e. /dev/sda, not /dev/sg0). It uses SG_IO for commands
>> > other than I/O commands, and regular AIO read/writes for I/O commands.
>> > Besides being simpler to configure (no mapping required to scsi-generic
>> > device names), this removes the need for a large bounce buffer and,
>> > in the future, will get scatter/gather support for free from scsi-disk.
>> >
>> > Signed-off-by: Paolo Bonzini<pbonzini@redhat.com>
>
> This doesn't seem to use much of scsi-disk, so what about exporting
> &scsi_disk_reqops and adding a separate file scsi-block.c? Would make
> things a bit more symmetrical between scsi-disk and scsi-generic.
>
> Or will future patches add code that depends on internal interfaces of
> scsi-disk?
It already uses some internal interfaces: scsi_initfn, scsi_disk_reset,
scsi_destroy, sizeof(SCSIDiskState).
Paolo
^ permalink raw reply
* Re: [PATCH V2 10/11] libxl_qmp, Introduce libxl__qmp_pci_add.
From: Anthony PERARD @ 2011-10-24 15:27 UTC (permalink / raw)
To: Ian Campbell; +Cc: Xen Devel, Stefano Stabellini
In-Reply-To: <1319450467.3385.178.camel@zakaz.uk.xensource.com>
On Mon, Oct 24, 2011 at 11:01, Ian Campbell <Ian.Campbell@citrix.com> wrote:
>
>> + rc = qmp_synchronous_send(qmp, "device_add", &args, NULL, qmp->timeout);
>> + if (rc == 0) {
>> + rc = qmp_synchronous_send(qmp, "query-pci", NULL,
>> + &request, qmp->timeout);
>> + if (rc == 0) {
>> + rc = request.rc;
>> + }
>
> Is every caller going to want this behaviour? Perhaps it belongs in
> qmp_sync..._send?
Yes, I think we want to know if the command and the callback have been
a success or not. And, in case we want to know if it's a protocol
error or an error in the callback, then we will just need different
value return.
--
Anthony PERARD
^ permalink raw reply
* Re: [Qemu-devel] [PATCH 3/5] qxl: support concurrent async commands
From: Gerd Hoffmann @ 2011-10-24 15:26 UTC (permalink / raw)
To: Alon Levy; +Cc: qemu-devel, mlureau, armbru, lcapitulino
In-Reply-To: <1319457739-14562-4-git-send-email-alevy@redhat.com>
Hi,
> +SpiceAsyncCommand *push_spice_async_command(PCIQXLDevice *qxl,
> + uint32_t async_io, int size)
> +/* caller must call g_free */
> +static SpiceAsyncCommand *pop_spice_async_command(PCIQXLDevice *qxl,
> + uint64_t cookie)
> +{
push/pop naming implies stack-like operation, which isn't true though.
pop will lookup by cookie. Also an explicit release function would be
good (list unlink and g_free call can go there).
Maybe have spice_async_cmd_{alloc,lookup,free} ?
Have you considered passing down a SpiceAsyncCommand pointer instead of
the cookie value everywhere? Seems to be a bit cleaner and more
future-proof to me. Not sure it buys us much in practice though, so
maybe it isn't worth the trouble.
cheers,
Gerd
^ permalink raw reply
* GIC MULTI_IRQ_HANDLER branches
From: Marc Zyngier @ 2011-10-24 15:26 UTC (permalink / raw)
To: linux-arm-kernel
I've stashed my patches for MULTI_IRQ_HANDLER on the following branches:
git://github.com/mzyngier/arm-platforms.git gic-multi-irq
git://github.com/mzyngier/arm-platforms.git gic-multi-irq-asm
This is based on Russell's smp branch, plus my PPI patches that Russell
has already pulled for the upcoming merge window.
The difference between the two branches is that the second is keeping
the ASM version of the GIC handler instead of a C version.
The C version has been tested on VE, Realview, Tegra, and OMAP2/3/4.
The ASM version has only been tested on OMAP4.
Cheers,
M.
--
I'm the slime oozin' out from your TV set...
^ permalink raw reply
* Re: [PATCH 11/X] uprobes: x86: introduce xol_was_trapped()
From: Srikar Dronamraju @ 2011-10-24 14:55 UTC (permalink / raw)
To: Oleg Nesterov
Cc: Peter Zijlstra, Ingo Molnar, Steven Rostedt, Linux-mm,
Arnaldo Carvalho de Melo, Linus Torvalds, Jonathan Corbet,
Masami Hiramatsu, Hugh Dickins, Christoph Hellwig,
Ananth N Mavinakayanahalli, Thomas Gleixner, Andi Kleen,
Andrew Morton, Jim Keniston, Roland McGrath, LKML
In-Reply-To: <20111019215307.GE16395@redhat.com>
> diff --git a/arch/x86/include/asm/uprobes.h b/arch/x86/include/asm/uprobes.h
> index 1c30cfd..f0fbdab 100644
> --- a/arch/x86/include/asm/uprobes.h
> +++ b/arch/x86/include/asm/uprobes.h
> @@ -39,6 +39,7 @@ struct uprobe_arch_info {
>
> struct uprobe_task_arch_info {
> unsigned long saved_scratch_register;
> + unsigned long saved_trap_no;
> };
> #else
> struct uprobe_arch_info {};
one nit
I had to add saved_trap_no to #else part (i.e uprobe_arch_info ).
--
Thanks and Regards
Srikar
--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org. For more info on Linux MM,
see: http://www.linux-mm.org/ .
Fight unfair telecom internet charges in Canada: sign http://stopthemeter.ca/
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>
^ 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.