* Re: Question about mdadm commit d6508f0cfb60edf07b36f1532eae4d9cddf7178b "be more careful about add attempts"
From: NeilBrown @ 2011-10-31 9:19 UTC (permalink / raw)
To: Alexander Lyakas; +Cc: linux-raid
In-Reply-To: <CAGRgLy7G_M=FtdZ9mmDvxxN52+AF+L=0+OaEP=dK7Z+Z5YBYKw@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 7950 bytes --]
On Mon, 31 Oct 2011 10:57:25 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
wrote:
> Thank you for the clarification, Neil!
>
> I was looking at raid_disk, because I am trying to see whether it is
> possible to control into which raid slot a disk is being added (not
> re-added).
>
> Let's say we had raid6 with 4 drives (a,b,c,d), and drives c and d
> failed.Now let's say, that it is decided to replace drive d with a new
> drive e (--add for drive e). Then it's possible that drive e will take
> the raid slot of drive c. So later, if we want to bring back drive c
> into the array, it will have to go into a different slot, resulting in
> a full reconstruction, not bitmap-based reconstruction. While if we
> would have re-added drive c first, it would have done a bitmap-based
> reconstruction, so only the e drive would have required a full
> reconstruction.
>
> So do you think it makes sense to somehow (perhaps through
> disc.raid_disk) instruct the kernel into which slot to add a new
> drive?
You should be able to do that via sysfs.
echo frozen > sync_action
echo $major:$minor > new_dev
echo $slot > dev-$DEVNAME/slot
echo idle > sync_action
something like that.
Seems and odd sort of scenario though.
Note that with RAID1 this is not an issue. A re-added drive can take any
position in a RAID1 array - it doesn't have to be the same one.
NeilBrown
>
> Thanks,
> Alex.
>
>
>
>
>
> On Mon, Oct 31, 2011 at 1:16 AM, NeilBrown <neilb@suse.de> wrote:
> > On Thu, 27 Oct 2011 11:10:54 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
> > wrote:
> >
> >> Hello Neil,
> >> it makes perfect sense not to turn a device into a spare inadvertently.
> >>
> >> However, with mdadm 3.1.4 under gdb, I tried the following:
> >> - I had a raid6 with 4 drives (sda/b/c/d), their "desc_nr" in the
> >> kernel were respectively (according to GET_DISK_INFO): 0,1,2,3.
> >> - I failed the two last drives (c & d) via mdadm and removed them from the array
> >> - I wiped the superblock on drive d.
> >> - I added the drive d back to the array
> >> So now the array had the following setup:
> >> sda: disc_nr=0, raid_disk=0
> >> sdb: disc_nr=1, raid_disk=1
> >> sdd: disc_nr=4, raid_disk=2
> >> So sdd was added to the array into slot 2, and received disc_nr=4
> >>
> >> - Now I asked to re-add drive sdc back to array. In gdb I followed the
> >> re-add flow, to the place where it fills the mdu_disk_info_t structure
> >> from the superblock read from sdc. It put there the following content:
> >> disc.major = ...
> >> disc.minor = ...
> >> disc.number = 2
> >> disc.raid_disk = 2 (because previously this drive was in slot 2)
> >> disc.state = ...
> >>
> >> Now in gdb I changed disc.number to 4 (to match the desc_nr of sdd).
> >> And then issued ADD_NEW_DISK. It succeeded, and the sdc drive received
> >> disc_nr=2 (while it was asking for 4). Of course, it could not have
> >> received the same raid_disk, because this raid_disk was already
> >> occupied by sdd. So it was added as a spare.
> >>
> >> But you are saying:
> >> > If a device already exists with the same disk.number, a re-add cannot
> >> > succeed, so mdadm doesn't even try.
> >> while in my case it succeeded (while it actually did "add" and not "re-add").
> >
> > We seem to be using word differently.
> > If I ask mdadm to do a "re-add" and it does an "add", then I consider that to
> > be "failure", however you seem to consider it to be a "success".
> >
> > That seems to be the source of confusion.
> >
> >
> >>
> >> That's why I was thinking it makes more sense to check disc.raid_disk
> >> and not disc.number in this check. Since disc.number is not the
> >> drive's role within the array (right?), it is simply a position of the
> >> drive in the list of all drives.
> >> So if you check raid_disk, and see that this raid slot is already
> >> occupied, then, naturally, the drive will be converted to spare, which
> >> we want to avoid.
> >
> > It may well be appropriate to check raid_disk as well, yes. It isn't so easy
> > though which is maybe why I didn't.
> >
> > With 0.90 metadata, the disc.number is the same as disc.raid_disk for active
> > devices. That might be another reason for the code being the way that it is.
> >
> > Thanks,
> > NeilBrown
> >
> >
> >
> >>
> >> And the enough_fd() check protects us from adding a spare to a failed
> >> array (like you mentioned to me previously).
> >>
> >> What am I missing?
> >>
> >> Thanks,
> >> Alex.
> >>
> >>
> >>
> >>
> >>
> >>
> >>
> >> On Wed, Oct 26, 2011 at 11:51 PM, NeilBrown <neilb@suse.de> wrote:
> >> > On Wed, 26 Oct 2011 19:02:37 +0200 Alexander Lyakas <alex.bolshoy@gmail.com>
> >> > wrote:
> >> >
> >> >> Greetings everybody,
> >> >> I have a question about the following code in Manage.c:Manage_subdevs()
> >> >>
> >> >> disc.number = mdi.disk.number;
> >> >> if (ioctl(fd, GET_DISK_INFO, &disc) != 0
> >> >> || disc.major != 0 || disc.minor != 0
> >> >> || !enough_fd(fd))
> >> >> goto skip_re_add;
> >> >>
> >> >> I do not underatand why the checks: disc.major != 0 || disc.minor != 0
> >> >> are required. This basically means that the kernel already has an
> >> >> rdev->desc_nr equal to disc.number. But why fail the re-add procedure?
> >> >>
> >> >> Let's say that enough_fd() returns true, and we go ahead an issue
> >> >> ioctl(ADD_NEW_DISK). In this case, according to the kernel code in
> >> >> add_new_disk(), it will not even look at info->number. It will
> >> >> initialize rdev->desc_nr to -1, and will allocate a free desc_nr for
> >> >> the rdev later.
> >> >>
> >> >> Doing this with mdadm 3.1.4, where this check is not present, actually
> >> >> succeeds. I understand that this code was added for cases when
> >> >> enough_fd() returns false, which sounds perfectly fine to protect
> >> >> from.
> >> >>
> >> >> I was thinking that this code should actually check something like:
> >> >> if (ioctl(fd, GET_DISK_INFO, &disc) != 0
> >> >> || disk.raid_disk != mdi.disk.raid_disk
> >> >> || !enough_fd(fd))
> >> >> goto skip_re_add;
> >> >>
> >> >> That is to check that the slot that was being occupied by the drive we
> >> >> are trying to add, is already occupied by a different drive (need also
> >> >> to cover cases of raid_disk <0, raid_disk >= raid_disks etc...) and
> >> >> not the desc_nr, which does not have any persistent meaning.
> >> >>
> >> >> Perhaps there are some compatibility issues with old kernels? Or
> >> >> special considerations for ... containers? non-persistent arrays?
> >> >
> >> > The point of this code is to make --re-add fail unless mdadm is certain that
> >> > the kernel will accept the re-add, rather than turn the device into a spare.
> >> >
> >> > If a device already exists with the same disk.number, a re-add cannot
> >> > succeed, so mdadm doesn't even try.
> >> >
> >> > When you say in 3.1.4 it "actually succeeds" - what succeeds? Does it re-add
> >> > the device to the array, or does it turn the device into a spare?
> >> > I particularly do not want --re-add to turn a device into a spare because
> >> > people sometimes use it in cases where it cannot work, their device gets
> >> > turned into a spare, and they lose information that could have been used to
> >> > reconstruct the array.
> >> >
> >> > That that make sense?
> >> >
> >> > NeilBrown
> >> >
> >> >
> >> --
> >> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> >> the body of a message to majordomo@vger.kernel.org
> >> More majordomo info at http://vger.kernel.org/majordomo-info.html
> >
> >
> --
> To unsubscribe from this list: send the line "unsubscribe linux-raid" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 828 bytes --]
^ permalink raw reply
* Re: [MIPS]clocks_calc_mult_shift() may gen a too big mult value
From: Yong Zhang @ 2011-10-31 9:20 UTC (permalink / raw)
To: Chen Jie
Cc: linux-mips, LKML, johnstul, tglx, yanhua, 项宇,
zhangfx, 孙海勇
In-Reply-To: <CAGXxSxXmgzxN361Cko1fY_+oWwfgjXLhS61gtvqB8YYXHXZVyw@mail.gmail.com>
On Mon, Oct 31, 2011 at 5:00 PM, Chen Jie <chenj@lemote.com> wrote:
> Hi all,
>
> On MIPS, with maxsec=4, clocks_calc_mult_shift() may generate a very
> big mult, which may easily cause timekeeper.mult overflow within
> timekeeping jobs.
Hmmm, why not use clocksource_register_hz()/clocksource_register_khz()
instead? it's more convenient.
Thanks,
Yong
>
> e.g. when clock freq was 250000500(i.e. mips_hpt_frequency=250000500,
> and the CPU Freq will be 250000500*2=500001000), mult will be
> 0xffffde72
>
> Attachment is a script that calculates mult values for CPU Freq
> between 400050000 and 500050000, with 1KHz step. It outputs mult
> values greater than 0xf0000000:
> CPU Freq:500001000, mult:0xffffde72, shift:30
> CPU Freq:500002000, mult:0xffffbce4, shift:30
> CPU Freq:500003000, mult:0xffff9b56, shift:30
> CPU Freq:500004000, mult:0xffff79c9, shift:30
> ...
>
> The peak value appears around CPU_freq=500001000.
>
> To avoid this, it may need:
> 1. Supply a bigger maxsec value?
> 2. In clocks_calc_mult_shift(), pick next mult/shift pair if mult is
> too big? Then maxsec will not be strictly obeyed.
> 3. Change timekeeper.mult to u64?
> 4. ...
>
> Any idea?
>
>
>
> --
> Regards,
> - Chen Jie
>
--
Only stand for myself
^ permalink raw reply
* Re: [PATCH] Display change history as a diff between two dirs
From: Roland Kaufmann @ 2011-10-31 9:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vty6rrow8.fsf@alter.siamese.dyndns.org>
On 2011-10-30 07:09, Junio C Hamano wrote:
> I do not think any of our scripted Porcelains use "set -e"; rather
> they try to catch errors and produce messages that are more
> appropriate for specific error sites.
git-dirdiff being a wrapper script, I reasoned that the underlaying
command would already have printed a sufficient error message, so what
was left was just to exit. But you're right in that some of the commands
will not give sufficient context. I'll put in some more detailed error
handling.
> I do not think any of our scripted Porcelains use "mktemp"
> especially "mktemp -d". How portable is it?
Even if it is not part of Posix, I reckon since it is a part of the
coreutils, it is available in most GNU userlands, inclusive GnuWin32.
I don't have any live BSD systems available, but based on the man pages
it seems to be available there too, albeit with some different options.
--tmpdir seems to be more of a problem in than respect than -d. I'll see
if I can find a set of options that are digestable to most platforms.
I think it is unfortunate to use the current directory as scratch space;
it can be a network disk, or even read-only. mktemp can in contrast make
a directory in a place which is not spilled to disk.
> It is not clear to me why you need to grab the list of paths in toc
> and iterate over them one by one. IOW, why isn't this sufficient?
This design decision was probably appropriate in an earlier iteration,
but as you point out, it is indeed superfluous now! I apologize for not
realizing that myself.
> suspect is true), we would probably want to make it an option to
> "git diff" itself, and not a separate git subcommand like "dirdiff".
> I can see
Although being an able *user* of Git, I am not (yet) familiar enough
with the codebase to have a patch ready for `git diff` itself. It would
certainly require more rigorous testing.
> "git diff" (and possibly even things like "git log -p") populating
> two temporary directories (your old/ and new/) and running a custom
> program specified by GIT_EXTERNAL_TREEDIFF environment variable,
> instead of doing
Would it be better to have yet another configuration available for this
option instead of reusing the existing infrastructure for `git difftool`?
> It also is not clear what could be used in "$@". Obviously you would
> not want things like "-U20" and "--stat" fed to the first "list of
> paths" phase, but there may be some options you may want to give to
> the inner "external diff" thing.
Ideally, it should work the same way as `git difftool`.
> For example, how well does this approach work with -M/-C (I do not
> think it would do anything useful, but I haven't thought things
> through). It would be nice if we gave the hint to the external
As of now, files that are moved will turn up a different places in the
tree without any annotations, and off the top of my head I don't see any
obvious way to propagate such hints. If the diff tool is sophisticated
can probably use the same heuristics as Git currently does, but I am
unaware of any that is able to do that yet.
> I wouldn't mind carrying a polished version of this in contrib/ for
> a cycle or two in order to let people try it out and get kinks out of
> its design.
I would appreciate that! I'll submit a reworked proposal taking you
comments into account. It may take a few days due to unrelated
engagements, though.
--
Roland.
^ permalink raw reply
* [U-Boot] (no subject)
From: Bar Yasser @ 2011-10-31 9:21 UTC (permalink / raw)
To: u-boot
I am Bar Yasser, I have a very important Business matters i will like to
discuss with you.If this your Email is valid Contact me through my personal
email:rawashdeh.asseral11 at w.cn Thank you Mr. Yasser Al
^ permalink raw reply
* [LTP] [PATCH] runltp: fix printing of LTP Version
From: Carmelo AMOROSO @ 2011-10-31 9:21 UTC (permalink / raw)
To: ltp-list
Fix function 'version_of_ltp' to reference Version in the correct path
Fix Version's path when settign version_date
Signed-off-by: Carmelo Amoroso <carmelo.amoroso@st.com>
---
runltp | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/runltp b/runltp
index 4ef8b38..244cd2f 100755
--- a/runltp
+++ b/runltp
@@ -97,7 +97,7 @@ setup()
version_of_ltp()
{
- cat "$LTPROOT/Version"
+ cat "$LTPROOT/testcases/bin/Version"
exit 0
}
@@ -209,7 +209,7 @@ main()
local scenfile=
- version_date=$(cat "$LTPROOT/Version")
+ version_date=$(cat "$LTPROOT/testcases/bin/Version")
while getopts a:c:C:d:D:f:F:ehi:K:g:l:m:M:Nno:pqr:s:S:t:T:w:x:b:B: arg
do case $arg in
--
1.7.4.4
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
_______________________________________________
Ltp-list mailing list
Ltp-list@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/ltp-list
^ permalink raw reply related
* Re: [PATCH 3/5] drivers/hid/hid-roccat.c: eliminate a null
From: Arend van Spriel @ 2011-10-31 9:22 UTC (permalink / raw)
To: David Herrmann
Cc: Dan Carpenter, Julia Lawall, Jiri Kosina,
kernel-janitors@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CANq1E4QJoM+NYub9hfs3KnL1w212FK0MHo8ez2p1nyGmNVb-=A@mail.gmail.com>
On 10/29/2011 12:53 PM, David Herrmann wrote:
> On Sat, Oct 29, 2011 at 11:36 AM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 10/29/2011 08:24 AM, Dan Carpenter wrote:
>>> On Sat, Oct 29, 2011 at 01:58:15AM +0200, Julia Lawall wrote:
>>>> diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
>>>> index 2596321..36a28b8 100644
>>>> --- a/drivers/hid/hid-roccat.c
>>>> +++ b/drivers/hid/hid-roccat.c
>>>> @@ -163,14 +163,15 @@ static int roccat_open(struct inode *inode, struct file *file)
>>>>
>>>> device = devices[minor];
>>>>
>>>> - mutex_lock(&device->readers_lock);
>>>> -
>>>> if (!device) {
>>>> pr_emerg("roccat device with minor %d doesn't exist\n", minor);
>>>> - error = -ENODEV;
>>>> - goto exit_err;
>>>> + kfree(reader);
>>>> + mutex_lock(&devices_lock);
>>>
>>> Typo. mutex_unlock() instead of mutex_lock().
>>
>> This is no typo, but simply wrong. Remove the mutex_lock() as we are
>> leaving the function here in error flow.
>
> No, this one is definitely needed. Its devices_lock, not
> device->readers_lock! And devices_lock is locked before so we need to
> unlock it if we return in this branch.
You are right. I missed that. As usual Dan's eye is sharper ;-)
Gr. AvS
^ permalink raw reply
* Re: [PATCH 3/5] drivers/hid/hid-roccat.c: eliminate a null pointer dereference
From: Arend van Spriel @ 2011-10-31 9:22 UTC (permalink / raw)
To: David Herrmann
Cc: Dan Carpenter, Julia Lawall, Jiri Kosina,
kernel-janitors@vger.kernel.org, linux-input@vger.kernel.org,
linux-kernel@vger.kernel.org
In-Reply-To: <CANq1E4QJoM+NYub9hfs3KnL1w212FK0MHo8ez2p1nyGmNVb-=A@mail.gmail.com>
On 10/29/2011 12:53 PM, David Herrmann wrote:
> On Sat, Oct 29, 2011 at 11:36 AM, Arend van Spriel <arend@broadcom.com> wrote:
>> On 10/29/2011 08:24 AM, Dan Carpenter wrote:
>>> On Sat, Oct 29, 2011 at 01:58:15AM +0200, Julia Lawall wrote:
>>>> diff --git a/drivers/hid/hid-roccat.c b/drivers/hid/hid-roccat.c
>>>> index 2596321..36a28b8 100644
>>>> --- a/drivers/hid/hid-roccat.c
>>>> +++ b/drivers/hid/hid-roccat.c
>>>> @@ -163,14 +163,15 @@ static int roccat_open(struct inode *inode, struct file *file)
>>>>
>>>> device = devices[minor];
>>>>
>>>> - mutex_lock(&device->readers_lock);
>>>> -
>>>> if (!device) {
>>>> pr_emerg("roccat device with minor %d doesn't exist\n", minor);
>>>> - error = -ENODEV;
>>>> - goto exit_err;
>>>> + kfree(reader);
>>>> + mutex_lock(&devices_lock);
>>>
>>> Typo. mutex_unlock() instead of mutex_lock().
>>
>> This is no typo, but simply wrong. Remove the mutex_lock() as we are
>> leaving the function here in error flow.
>
> No, this one is definitely needed. Its devices_lock, not
> device->readers_lock! And devices_lock is locked before so we need to
> unlock it if we return in this branch.
You are right. I missed that. As usual Dan's eye is sharper ;-)
Gr. AvS
^ permalink raw reply
* Re: [PATCH 07/11] isci: Remove redundant isci_request.ttype field.
From: James Bottomley @ 2011-10-31 9:23 UTC (permalink / raw)
To: Dan Williams; +Cc: linux-scsi, Jeff Skirvin
In-Reply-To: <20111027220521.4941.68732.stgit@localhost6.localdomain6>
On Thu, 2011-10-27 at 15:05 -0700, Dan Williams wrote:
> @@ -3563,7 +3542,7 @@ static struct isci_request
> *isci_io_request_from_tag(struct isci_host *ihost,
>
> ireq = isci_request_from_tag(ihost, tag);
> ireq->ttype_ptr.io_task_ptr = task;
> - ireq->ttype = io_task;
> + clear_bit(IREQ_TMF, &ireq->flags);;
> task->lldd_task = ireq;
Double semicolon. checkpatch.pl should warn about this. I fixed it.
James
^ permalink raw reply
* Re: bigalloc and max file size
From: Coly Li @ 2011-10-31 9:35 UTC (permalink / raw)
To: Theodore Tso
Cc: Andreas Dilger, linux-ext4 development, Alex Zhuravlev, Tao Ma,
hao.bigrat@gmail.com
In-Reply-To: <F1D09DA1-3E1E-4D31-9F26-4AADAAF7A91D@mit.edu>
On 2011年10月31日 03:49, Theodore Tso Wrote:
>
> On Oct 30, 2011, at 1:37 AM, Coly Li wrote:
>
>> Forgive me if this is out of topic.
>> In our test, allocating directories W/ bigalloc and W/O inline-data may occupy most of disk space. By now Ext4
>> inline-data is not merged yet, I just wondering how Google uses bigalloc without inline-data patch set ?
>
> It depends on how many directories you have (i.e, how deep your directory structure is) and how many small files you have in the file system as to whether bigalloc w/o inline-data has an acceptable overhead or not.
[snip]
> I'm not against your patch set, however; I just haven't had time to look at them, at all (nor the secure delete patch set, etc.) . Between organizing the kernel summit, the kernel.org compromise, and some high priority bugs at $WORK, things have just been too busy. Sorry for that; I'll get to them after the merge window and post-merge bug fixing is under control.
Hi Ted,
In our test, bigalloc without inline-data dose not work very well with deep directory structure, e.g. Hadoop or Squid,
because small directories occupies all disk space. That's why I asked the question. Thanks for your patient reply, it
makes sense for me :-)
Back to our topic, Ext4 doesn't have too much on-disk incompatible flag-bits now. If we get current bigalloc code merged
now, we have to use another incompatible bit when we merge cluster/chunk based extent patch set. Further more, we
observe performance regression without cluster-based-extent on file system umount (as Tao mentioned in this thread).
IMHO, without inline-data and cluster-based-extent, current bigalloc code is a little bit inperfect for many users.
Bigalloc is a very useful feature, can we consider making it better before getting merged ?
Thanks.
--
Coly Li
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH DOCDAY] introduce an xl man page in pod format
From: Ian Campbell @ 2011-10-31 9:25 UTC (permalink / raw)
To: Stefano Stabellini; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <alpine.DEB.2.00.1110271659380.3519@kaball-desktop>
On Thu, 2011-10-27 at 17:19 +0100, Stefano Stabellini wrote:
> This is the initial version of an xl man page, based on the old xm man
> page.
> Almost every command implemented in xl should be present, a notable
> exception are the tmem commands that are currently missing.
> Further improvements and clarifications to this man page are very welcome.
I had a thought over the weekend... It took me a while to get used to
but the git style of a manpage per subcommand and having "git COMMAND
--help" spawn man of that page works really well.
A long list of subcommands such as this gets a bit unwieldy. Having a
page per command also means you can take advantage of e.g. a SEE ALSO
for each command individually and things like that.
I think you've got all the content already it's just a matter of
separating it.
If we were feeling sneaky we could probably arrange for the build to
fail if no man page is available for a command listed in
xl_cmdtable.c };-)
Ian.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> diff -r 39aa9b2441da docs/man/xl.pod.1
> --- /dev/null Thu Jan 01 00:00:00 1970 +0000
> +++ b/docs/man/xl.pod.1 Thu Oct 27 15:59:03 2011 +0000
> @@ -0,0 +1,805 @@
> +=head1 NAME
> +
> +XL - Xen management tool, based on LibXenlight
> +
> +=head1 SYNOPSIS
> +
> +B<xl> I<subcommand> [I<args>]
> +
> +=head1 DESCRIPTION
> +
> +The B<xl> program is the new tool for managing Xen guest
> +domains. The program can be used to create, pause, and shutdown
> +domains. It can also be used to list current domains, enable or pin
> +VCPUs, and attach or detach virtual block devices.
> +The old B<xm> tool is deprecated and should not be used.
> +
> +The basic structure of every B<xl> command is almost always:
> +
> +=over 2
> +
> +B<xl> I<subcommand> [I<OPTIONS>] I<domain-id>
> +
> +=back
> +
> +Where I<subcommand> is one of the subcommands listed below, I<domain-id>
> +is the numeric domain id, or the domain name (which will be internally
> +translated to domain id), and I<OPTIONS> are subcommand specific
> +options. There are a few exceptions to this rule in the cases where
> +the subcommand in question acts on all domains, the entire machine,
> +or directly on the Xen hypervisor. Those exceptions will be clear for
> +each of those subcommands.
> +
> +=head1 NOTES
> +
> +Most B<xl> operations rely upon B<xenstored> and B<xenconsoled>: make
> +sure you start the script B</etc/init.d/xencommons> at boot time to
> +initialize all the daemons needed by B<xl>.
> +
> +In the most common network configuration, you need to setup a bridge in dom0
> +named B<xenbr0> in order to have a working network in the guest domains.
> +Please refer to the documentation of your Linux distribution to know how to
> +setup the bridge.
> +
> +Most B<xl> commands require root privileges to run due to the
> +communications channels used to talk to the hypervisor. Running as
> +non root will return an error.
> +
> +=head1 DOMAIN SUBCOMMANDS
> +
> +The following subcommands manipulate domains directly. As stated
> +previously, most commands take I<domain-id> as the first parameter.
> +
> +=over 4
> +
> +=item B<create> [I<OPTIONS>] I<configfile>
> +
> +The create subcommand requires a config file: see L<xldomain.cfg> for
> +full details of that file format and possible options.
> +
> +I<configfile> can either be an absolute path to a file, or a relative
> +path to a file located in /etc/xen.
> +
> +Create will return B<as soon> as the domain is started. This B<does
> +not> mean the guest OS in the domain has actually booted, or is
> +available for input.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-q>, B<--quiet>
> +
> +No console output.
> +
> +=item B<-f=FILE>, B<--defconfig=FILE>
> +
> +Use the given configuration file.
> +
> +=item B<-n>, B<--dryrun>
> +
> +Dry run - prints the resulting configuration in SXP but does not create
> +the domain.
> +
> +=item B<-p>
> +
> +Leave the domain paused after it is created.
> +
> +=item B<-c>
> +
> +Attach console to the domain as soon as it has started. This is
> +useful for determining issues with crashing domains.
> +
> +=back
> +
> +B<EXAMPLES>
> +
> +=over 4
> +
> +=item I<with config file>
> +
> + xl create DebianLenny
> +
> +This creates a domain with the file /etc/xen/DebianLenny, and returns as
> +soon as it is run.
> +
> +=back
> +
> +=item B<console> I<domain-id>
> +
> +Attach to domain I<domain-id>'s console. If you've set up your domains to
> +have a traditional log in console this will look much like a normal
> +text log in screen.
> +
> +Use the key combination Ctrl+] to detach the domain console.
> +
> +=item B<vncviewer> [I<OPTIONS>] I<domain-id>
> +
> +Attach to domain's VNC server, forking a vncviewer process.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item I<--autopass>
> +
> +Pass VNC password to vncviewer via stdin.
> +
> +=back
> +
> +=item B<destroy> I<domain-id>
> +
> +Immediately terminate the domain I<domain-id>. This doesn't give the
> +domain OS any chance to react, and is the equivalent of ripping the
> +power cord out on a physical machine. In most cases you will want to
> +use the B<shutdown> command instead.
> +
> +=item B<domid> I<domain-name>
> +
> +Converts a domain name to a domain id.
> +
> +=item B<domname> I<domain-id>
> +
> +Converts a domain id to a domain name.
> +
> +=item B<rename> I<domain-id> I<new-name>
> +
> +Change the domain name of I<domain-id> to I<new-name>.
> +
> +=item B<dump-core> I<domain-id> [I<filename>]
> +
> +Dumps the virtual machine's memory for the specified domain to the
> +I<filename> specified, without pausing the domain. The dump file will
> +be written to a distribution specific directory for dump files. Such
> +as: /var/lib/xen/dump or /var/xen/dump.
> +
> +=item B<help> [I<--long>]
> +
> +Displays the short help message (i.e. common commands).
> +
> +The I<--long> option prints out the complete set of B<xl> subcommands,
> +grouped by function.
> +
> +=item B<list> [I<OPTIONS>] [I<domain-id> ...]
> +
> +Prints information about one or more domains. If no domains are
> +specified it prints out information about all domains.
> +
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-l>, B<--long>
> +
> +The output for B<xl list> is not the table view shown below, but
> +instead presents the data in SXP compatible format.
> +
> +=item B<-Z>, B<--context>
> +Also prints the security labels.
> +
> +=item B<-v>, B<--verbose>
> +
> +Also prints the domain UUIDs, the shutdown reason and security labels.
> +
> +=back
> +
> +B<EXAMPLE>
> +
> +An example format for the list is as follows:
> +
> + Name ID Mem VCPUs State Time(s)
> + Domain-0 0 750 4 r----- 11794.3
> + win 1 1019 1 r----- 0.3
> + linux 2 2048 2 r----- 5624.2
> +
> +Name is the name of the domain. ID the numeric domain id. Mem is the
> +desired amount of memory to allocate to the domain (although it may
> +not be the currently allocated amount). VCPUs is the number of
> +virtual CPUs allocated to the domain. State is the run state (see
> +below). Time is the total run time of the domain as accounted for by
> +Xen.
> +
> +B<STATES>
> +
> +The State field lists 6 states for a Xen domain, and which ones the
> +current domain is in.
> +
> +=over 4
> +
> +=item B<r - running>
> +
> +The domain is currently running on a CPU.
> +
> +=item B<b - blocked>
> +
> +The domain is blocked, and not running or runnable. This can be caused
> +because the domain is waiting on IO (a traditional wait state) or has
> +gone to sleep because there was nothing else for it to do.
> +
> +=item B<p - paused>
> +
> +The domain has been paused, usually occurring through the administrator
> +running B<xl pause>. When in a paused state the domain will still
> +consume allocated resources like memory, but will not be eligible for
> +scheduling by the Xen hypervisor.
> +
> +=item B<s - shutdown>
> +
> +FIXME: Why would you ever see this state?
> +
> +=item B<c - crashed>
> +
> +The domain has crashed, which is always a violent ending. Usually
> +this state can only occur if the domain has been configured not to
> +restart on crash. See L<xldomain.cfg> for more info.
> +
> +=item B<d - dying>
> +
> +The domain is in process of dying, but hasn't completely shutdown or
> +crashed.
> +
> +FIXME: Is this right?
> +
> +=back
> +
> +B<NOTES>
> +
> +=over 4
> +
> +The Time column is deceptive. Virtual IO (network and block devices)
> +used by domains requires coordination by Domain0, which means that
> +Domain0 is actually charged for much of the time that a DomainU is
> +doing IO. Use of this time value to determine relative utilizations
> +by domains is thus very suspect, as a high IO workload may show as
> +less utilized than a high CPU workload. Consider yourself warned.
> +
> +=back
> +
> +=item B<mem-max> I<domain-id> I<mem>
> +
> +Specify the maximum amount of memory the domain is able to use, appending 't'
> +for terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes and 'b'
> +for bytes.
> +
> +The mem-max value may not correspond to the actual memory used in the
> +domain, as it may balloon down its memory to give more back to the OS.
> +
> +=item B<mem-set> I<domain-id> I<mem>
> +
> +Set the domain's used memory using the balloon driver; append 't' for
> +terabytes, 'g' for gigabytes, 'm' for megabytes, 'k' for kilobytes and 'b' for
> +bytes.
> +
> +Because this operation requires cooperation from the domain operating
> +system, there is no guarantee that it will succeed. This command will
> +definitely not work unless the domain has the required paravirt
> +driver.
> +
> +B<Warning:> There is no good way to know in advance how small of a
> +mem-set will make a domain unstable and cause it to crash. Be very
> +careful when using this command on running domains.
> +
> +=item B<migrate> [I<OPTIONS>] I<domain-id> I<host>
> +
> +Migrate a domain to another host machine. By default B<xl> relies on ssh as a
> +transport mechanism between the two hosts.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-s> I<sshcommand>
> +
> +Use <sshcommand> instead of ssh. String will be passed to sh. If empty, run
> +<host> instead of ssh <host> xl migrate-receive [-d -e].
> +
> +=item B<-e>
> +
> +On the new host, do not wait in the background (on <host>) for the death of the
> +domain.
> +
> +=item B<-C> I<config>
> +
> +Send <config> instead of config file from creation.
> +
> +=back
> +
> +=item B<pause> I<domain-id>
> +
> +Pause a domain. When in a paused state the domain will still consume
> +allocated resources such as memory, but will not be eligible for
> +scheduling by the Xen hypervisor.
> +
> +=item B<reboot> [I<OPTIONS>] I<domain-id>
> +
> +Reboot a domain. This acts just as if the domain had the B<reboot>
> +command run from the console. The command returns as soon as it has
> +executed the reboot action, which may be significantly before the
> +domain actually reboots.
> +
> +The behavior of what happens to a domain when it reboots is set by the
> +B<on_reboot> parameter of the xldomain.cfg file when the domain was
> +created.
> +
> +=item B<restore> [I<OPTIONS>] [I<ConfigFile>] I<CheckpointFile>
> +
> +Build a domain from an B<xl save> state file. See B<save> for more info.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-p>
> +
> +Do not unpause domain after restoring it.
> +
> +=item B<-e>
> +
> +Do not wait in the background for the death of the domain on the new host.
> +
> +=item B<-d>
> +
> +Enable debug messages.
> +
> +=back
> +
> +=item B<save> [I<OPTIONS>] I<domain-id> I<CheckpointFile> [I<ConfigFile>]
> +
> +Saves a running domain to a state file so that it can be restored
> +later. Once saved, the domain will no longer be running on the
> +system, unless the -c option is used.
> +B<xl restore> restores from this checkpoint file.
> +Passing a config file argument allows the user to manually select the VM config
> +file used to create the domain.
> +
> +
> +=over 4
> +
> +=item B<-c>
> +
> +Leave domain running after creating the snapshot.
> +
> +=back
> +
> +
> +=item B<shutdown> [I<OPTIONS>] I<domain-id>
> +
> +Gracefully shuts down a domain. This coordinates with the domain OS
> +to perform graceful shutdown, so there is no guarantee that it will
> +succeed, and may take a variable length of time depending on what
> +services must be shutdown in the domain. The command returns
> +immediately after signally the domain unless that B<-w> flag is used.
> +
> +The behavior of what happens to a domain when it reboots is set by the
> +B<on_shutdown> parameter of the xldomain.cfg file when the domain was
> +created.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-w>
> +
> +Wait for the domain to complete shutdown before returning.
> +
> +=back
> +
> +=item B<sysrq> I<domain-id> I<letter>
> +
> +Send a I<Magic System Request> signal to the domain. For more
> +information on available magic sys req operations, see sysrq.txt in
> +your Linux Kernel sources.
> +
> +=item B<unpause> I<domain-id>
> +
> +Moves a domain out of the paused state. This will allow a previously
> +paused domain to now be eligible for scheduling by the Xen hypervisor.
> +
> +=item B<vcpu-set> I<domain-id> I<vcpu-count>
> +
> +Enables the I<vcpu-count> virtual CPUs for the domain in question.
> +Like mem-set, this command can only allocate up to the maximum virtual
> +CPU count configured at boot for the domain.
> +
> +If the I<vcpu-count> is smaller than the current number of active
> +VCPUs, the highest number VCPUs will be hotplug removed. This may be
> +important for pinning purposes.
> +
> +Attempting to set the VCPUs to a number larger than the initially
> +configured VCPU count is an error. Trying to set VCPUs to < 1 will be
> +quietly ignored.
> +
> +Because this operation requires cooperation from the domain operating
> +system, there is no guarantee that it will succeed. This command will
> +not work with a full virt domain.
> +
> +=item B<vcpu-list> [I<domain-id>]
> +
> +Lists VCPU information for a specific domain. If no domain is
> +specified, VCPU information for all domains will be provided.
> +
> +=item B<vcpu-pin> I<domain-id> I<vcpu> I<cpus>
> +
> +Pins the VCPU to only run on the specific CPUs. The keyword
> +B<all> can be used to apply the I<cpus> list to all VCPUs in the
> +domain.
> +
> +Normally VCPUs can float between available CPUs whenever Xen deems a
> +different run state is appropriate. Pinning can be used to restrict
> +this, by ensuring certain VCPUs can only run on certain physical
> +CPUs.
> +
> +=item B<button-press> I<domain-id> I<button>
> +
> +Indicate an ACPI button press to the domain. I<button> is may be 'power' or
> +'sleep'.
> +
> +=item B<trigger> I<domain-id> I<nmi|reset|init|power|sleep> [I<VCPU>]
> +
> +Send a trigger to a domain, where the trigger can be: nmi, reset, init, power
> +or sleep. Optionally a specific vcpu number can be passed as an argument.
> +
> +=item B<getenforce>
> +
> +Returns the current enforcing mode of the Flask Xen security module.
> +
> +=item B<setenforce> I<1|0|Enforcing|Permissive>
> +
> +Sets the current enforcing mode of the Flask Xen security module
> +
> +=item B<loadpolicy> I<policyfile>
> +
> +Loads a new policy int the Flask Xen security module.
> +
> +=back
> +
> +=head1 XEN HOST SUBCOMMANDS
> +
> +=over 4
> +
> +=item B<debug-keys> I<keys>
> +
> +Send debug I<keys> to Xen.
> +
> +=item B<dmesg> [B<-c>]
> +
> +Reads the Xen message buffer, similar to dmesg on a Linux system. The
> +buffer contains informational, warning, and error messages created
> +during Xen's boot process. If you are having problems with Xen, this
> +is one of the first places to look as part of problem determination.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-c>, B<--clear>
> +
> +Clears Xen's message buffer.
> +
> +=back
> +
> +=item B<info> [B<-n>, B<--numa>]
> +
> +Print information about the Xen host in I<name : value> format. When
> +reporting a Xen bug, please provide this information as part of the
> +bug report.
> +
> +Sample output looks as follows (lines wrapped manually to make the man
> +page more readable):
> +
> + host : talon
> + release : 2.6.12.6-xen0
> + version : #1 Mon Nov 14 14:26:26 EST 2005
> + machine : i686
> + nr_cpus : 2
> + nr_nodes : 1
> + cores_per_socket : 1
> + threads_per_core : 1
> + cpu_mhz : 696
> + hw_caps : 0383fbff:00000000:00000000:00000040
> + total_memory : 767
> + free_memory : 37
> + xen_major : 3
> + xen_minor : 0
> + xen_extra : -devel
> + xen_caps : xen-3.0-x86_32
> + xen_scheduler : credit
> + xen_pagesize : 4096
> + platform_params : virt_start=0xfc000000
> + xen_changeset : Mon Nov 14 18:13:38 2005 +0100
> + 7793:090e44133d40
> + cc_compiler : gcc version 3.4.3 (Mandrakelinux
> + 10.2 3.4.3-7mdk)
> + cc_compile_by : sdague
> + cc_compile_domain : (none)
> + cc_compile_date : Mon Nov 14 14:16:48 EST 2005
> + xend_config_format : 4
> +
> +B<FIELDS>
> +
> +Not all fields will be explained here, but some of the less obvious
> +ones deserve explanation:
> +
> +=over 4
> +
> +=item B<hw_caps>
> +
> +A vector showing what hardware capabilities are supported by your
> +processor. This is equivalent to, though more cryptic, the flags
> +field in /proc/cpuinfo on a normal Linux machine.
> +
> +=item B<free_memory>
> +
> +Available memory (in MB) not allocated to Xen, or any other domains.
> +
> +=item B<xen_caps>
> +
> +The Xen version and architecture. Architecture values can be one of:
> +x86_32, x86_32p (i.e. PAE enabled), x86_64, ia64.
> +
> +=item B<xen_changeset>
> +
> +The Xen mercurial changeset id. Very useful for determining exactly
> +what version of code your Xen system was built from.
> +
> +=back
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-n>, B<--numa>
> +
> +List host NUMA topology information
> +
> +=back
> +
> +=item B<top>
> +
> +Executes the B<xentop> command, which provides real time monitoring of
> +domains. Xentop is a curses interface, and reasonably self
> +explanatory.
> +
> +=item B<uptime>
> +
> +Prints the current uptime of the domains running.
> +
> +=item B<pci-list-assignable-devices>
> +
> +List all the assignable PCI devices.
> +
> +=back
> +
> +=head1 SCHEDULER SUBCOMMANDS
> +
> +Xen ships with a number of domain schedulers, which can be set at boot
> +time with the B<sched=> parameter on the Xen command line. By
> +default B<credit> is used for scheduling.
> +
> +=over 4
> +
> +=item B<sched-credit> [ B<-d> I<domain-id> [ B<-w>[B<=>I<WEIGHT>] | B<-c>[B<=>I<CAP>] ] ]
> +
> +Set credit scheduler parameters. The credit scheduler is a
> +proportional fair share CPU scheduler built from the ground up to be
> +work conserving on SMP hosts.
> +
> +Each domain (including Domain0) is assigned a weight and a cap.
> +
> +B<PARAMETERS>
> +
> +=over 4
> +
> +=item I<WEIGHT>
> +
> +A domain with a weight of 512 will get twice as much CPU as a domain
> +with a weight of 256 on a contended host. Legal weights range from 1
> +to 65535 and the default is 256.
> +
> +=item I<CAP>
> +
> +The cap optionally fixes the maximum amount of CPU a domain will be
> +able to consume, even if the host system has idle CPU cycles. The cap
> +is expressed in percentage of one physical CPU: 100 is 1 physical CPU,
> +50 is half a CPU, 400 is 4 CPUs, etc. The default, 0, means there is
> +no upper cap.
> +
> +=back
> +
> +=back
> +
> +=head1 CPUPOOLS COMMANDS
> +
> +Xen can group the physical cpus of a server in cpu-pools. Each physical CPU is
> +assigned at most to one cpu-pool. Domains are each restricted to a single
> +cpu-pool. Scheduling does not cross cpu-pool boundaries, so each cpu-pool has
> +an own scheduler.
> +Physical cpus and domains can be moved from one pool to another only by an
> +explicit command.
> +
> +=over 4
> +
> +=item B<cpupool-create> [I<OPTIONS>] I<ConfigFile>
> +
> +Create a cpu pool based an I<ConfigFile>.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item B<-f=FILE>, B<--defconfig=FILE>
> +
> +Use the given configuration file.
> +
> +=item B<-n>, B<--dryrun>
> +
> +Dry run - prints the resulting configuration.
> +
> +=back
> +
> +=item B<cpupool-list> [I<-c|--cpus> I<cpu-pool>]
> +
> +List CPU pools on the host.
> +If I<-c> is specified, B<xl> prints a list of CPUs used by I<cpu-pool>.
> +
> +=item B<cpupool-destroy> I<cpu-pool>
> +
> +Deactivates a cpu pool.
> +
> +=item B<cpupool-rename> I<cpu-pool> <newname>
> +
> +Renames a cpu pool to I<newname>.
> +
> +=item B<cpupool-cpu-add> I<cpu-pool> I<cpu-nr|node-nr>
> +
> +Adds a cpu or a numa node to a cpu pool.
> +
> +=item B<cpupool-cpu-remove> I<cpu-nr|node-nr>
> +
> +Removes a cpu or a numa node from a cpu pool.
> +
> +=item B<cpupool-migrate> I<domain-id> I<cpu-pool>
> +
> +Moves a domain into a cpu pool.
> +
> +=item B<cpupool-numa-split>
> +
> +Splits up the machine into one cpu pool per numa node.
> +
> +=back
> +
> +=head1 VIRTUAL DEVICE COMMANDS
> +
> +Most virtual devices can be added and removed while guests are
> +running. The effect to the guest OS is much the same as any hotplug
> +event.
> +
> +=head2 BLOCK DEVICES
> +
> +=over 4
> +
> +=item B<block-attach> I<domain-id> I<disc-spec-component(s)> ...
> +
> +Create a new virtual block device. This will trigger a hotplug event
> +for the guest.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item I<domain-id>
> +
> +The domain id of the guest domain that the device will be attached to.
> +
> +=item I<disc-spec-component>
> +
> +A disc specification in the same format used for the B<disk> variable in
> +the domain config file. See L<xldomain.cfg>.
> +
> +=back
> +
> +=item B<block-detach> I<domain-id> I<devid> [B<--force>]
> +
> +Detach a domain's virtual block device. I<devid> may be the symbolic
> +name or the numeric device id given to the device by domain 0. You
> +will need to run B<xl block-list> to determine that number.
> +
> +Detaching the device requires the cooperation of the domain. If the
> +domain fails to release the device (perhaps because the domain is hung
> +or is still using the device), the detach will fail. The B<--force>
> +parameter will forcefully detach the device, but may cause IO errors
> +in the domain.
> +
> +=item B<block-list> I<domain-id>
> +
> +List virtual block devices for a domain.
> +
> +=item B<cd-insert> I<domain-id> I<VirtualDevice> I<be-dev>
> +
> +Insert a cdrom into a guest domain's cd drive. Only works with HVM domains.
> +
> +B<OPTIONS>
> +
> +=over 4
> +
> +=item I<VirtualDevice>
> +
> +How the device should be presented to the guest domain; for example /dev/hdc.
> +
> +=item I<be-dev>
> +
> +the device in the backend domain (usually domain 0) to be exported; it can be a
> +path to a file (file://path/to/file.iso). See B<disk> in L<xldomain.cfg> for the
> +details.
> +
> +=back
> +
> +=item B<cd-eject> I<domain-id> I<VirtualDevice>
> +
> +Eject a cdrom from a guest's cd drive. Only works with HVM domains.
> +I<VirtualDevice> is the cdrom device in the guest to eject.
> +
> +=back
> +
> +=head2 NETWORK DEVICES
> +
> +=over 4
> +
> +=item B<network-attach> I<domain-id> I<network-device>
> +
> +Creates a new network device in the domain specified by I<domain-id>.
> +I<network-device> describes the device to attach, using the same format as the
> +B<vif> string in the domain config file. See L<xldomain.cfg> for the
> +description.
> +
> +=item B<network-detach> I<domain-id> I<devid|mac>
> +
> +Removes the network device from the domain specified by I<domain-id>.
> +I<devid> is the virtual interface device number within the domain
> +(i.e. the 3 in vif22.3). Alternatively the I<mac> address can be used to
> +select the virtual interface to detach.
> +
> +=item B<network-list> I<domain-id>
> +
> +List virtual network interfaces for a domain.
> +
> +=back
> +
> +=head2 PCI PASS-THROUGH
> +
> +=over 4
> +
> +=item B<pci-attach> I<domain-id> I<BDF>
> +
> +Hot-plug a new pass-through pci device to the specified domain.
> +B<BDF> is the PCI Bus/Device/Function of the physical device to pass-through.
> +
> +=item B<pci-detach> [I<-f>] I<domain-id> I<BDF>
> +
> +Hot-unplug a previously assigned pci device from a domain. B<BDF> is the PCI
> +Bus/Device/Function of the physical device to be removed from the guest domain.
> +
> +If B<-f> is specified, B<xl> is going to forcefully remove the device even
> +without guest's collaboration.
> +
> +=item B<pci-list> I<domain-id>
> +
> +List pass-through pci devices for a domain.
> +
> +=back
> +
> +=head1 SEE ALSO
> +
> +B<xldomain.cfg>(5), B<xentop>(1)
> +
> +=head1 AUTHOR
> +
> + Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> + Vincent Hanquez <vincent.hanquez@eu.citrix.com>
> + Ian Jackson <ian.jackson@eu.citrix.com>
> + Ian Campbell <Ian.Campbell@citrix.com>
> +
> +=head1 BUGS
> +
> +Send bugs to xen-devel@lists.xensource.com.
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xensource.com
> http://lists.xensource.com/xen-devel
^ permalink raw reply
* Re: i.MX: GPIO based SPI chip selects question
From: Wayne Tams @ 2011-10-31 9:26 UTC (permalink / raw)
To: Baruch Siach; +Cc: spi-devel-general-5NWGOfrQmneRv+LV9MX5uipxlwaOVQ5f
In-Reply-To: <20111029204450.GA31910@tarshish>
On Sat, Oct 29, 2011 at 9:44 PM, Baruch Siach <baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org> wrote:
> Hi Wayne,
>
> On Fri, Oct 28, 2011 at 02:06:16PM +0100, Wayne Tams wrote:
>> Can I use GPIO pins on my i.mx53 for SPI chip select, I have found little
>> on the web that can help me, I am hoping that it is straight-forward enough
>> for me to implement it? Perhaps there is a macro that I can use in the
>> spi_board_info structure that will let me declare the GPIO?
>
> If you are using the mainline kernel then the SPI driver
> (drivers/spi/spi-imx.c) supports the use of GPIO lines for chip-select
> exclusively. You can find an i.MX53 specific example in
> arch/arm/mach-mx5/board-mx53_evk.c (look for the mx53_evk_spi_data struct).
> This example demonstrate the use of two GPIOs for chip-select, but the list of
> chip-selects can be longer.
That looks promising, I assume you mean that your quoted example makes
use of the driver spi-imx?
>
> Since you appear to be using the Freescale supplied kernel (as I infer from
> your previous question on this list), you are probably using different driver.
> This driver (likely
> http://opensource.freescale.com/git?p=imx/linux-2.6-imx.git;a=blob;f=drivers/spi/mxc_spi.c;h=8c722686a0e1a419b417c0e2f98a4d6f028cf02e;hb=a1cd8a787a18da69ac4e48cfc876623bd7323799)
> does not support GPIOs for chip-select.
I should of added that I am using a kernel from a BSP supplied by
Emtrion, as you guessed correctly, it based on the Freescale kernel
which uses the mxc_spi driver.
>
> Freescale seem to have abandoned their in-house non mainlined SPI driver in a
> later version of their kernel (rel_imx_2.6.38_11.09.01 tag in
> http://opensource.freescale.com/git) so you may want to update your kernel.
I will have a look at how much of an impact using the mainlined kernel
will have on the operation of my SoM. A little off topic, bearing in
mind my inexperience with Linux, can I upgrade the kernel using git
and will the differences between the mainlined and Emtrion kernel be
highlighted? It is just that there could be some Emtrion kernel adds
that I could miss which may impact my board operation, memory mapping
etc.
Just to summarise, are these the options available to me? If so I will
figure out which method will be best for me to do:
1) Hack the existing mxc_spi driver and add support for GPIO chip-select
2) Upgrade the kernel to the latest mainlined version and use the
spi-imx driver included in that
3) Hack the kernel to use the spi_imx driver already included in the
BSP which has GPIO chip-select support
4) Update my BSP SPI driver to the mainlined version
Thank you for your help Baruch (and Grant) much appreciated,
>
> baruch
>
> --
> ~. .~ Tk Open Systems
> =}------------------------------------------------ooO--U--Ooo------------{=
> - baruch-NswTu9S1W3P6gbPvEgmw2w@public.gmane.org - tel: +972.2.679.5364, http://www.tkos.co.il -
>
------------------------------------------------------------------------------
Get your Android app more play: Bring it to the BlackBerry PlayBook
in minutes. BlackBerry App World™ now supports Android™ Apps
for the BlackBerry® PlayBook™. Discover just how easy and simple
it is! http://p.sf.net/sfu/android-dev2dev
^ permalink raw reply
* Re: [B.A.T.M.A.N.] [PATCH 0/6] DAT: Distributed ARP Table
From: Martin Hundebøll @ 2011-10-31 9:26 UTC (permalink / raw)
To: b.a.t.m.a.n
In-Reply-To: <20111031000347.GB10726@pandem0nium>
On 2011-10-31 01:03, Simon Wunderlich wrote:
> Hello Antonio,
>
> thanks for the patchset! I've tested it again in my kvm setup, it worked very
> well.
>
> There are some issues remaining, I'll comment the individual patches for this.
> About the general stuff:
>
> * maybe we should rename arp.{c|h} to dat.{c|h} to avoid confusion with
> other code in the linux kernel?
I propose "distributet-arp-tables.{c|h}" to avoid too many acronyms in our file names.
--
Kind regards
Martin Hundebøll
+45 61 65 54 61
martin@hundeboll.net
Nordborggade 57, 2. tv
8000 Aarhus C
Denmark
^ permalink raw reply
* [Qemu-devel] Performance of USB2.0
From: Til Obes @ 2011-10-31 9:27 UTC (permalink / raw)
To: qemu-devel
Hello all,
i want to use a virtual router which is connected to a cable box
via an usb ethernet controller. The device itself runs properly
at normal usage. But inside the virtual machine i get only about 7MBit.
I configured the the usb device with the following xml syntax of
libvirt:
<controller type='usb' index='0' model='ehci'>
<address type='pci' domain='0x0000' bus='0x00' slot='0x07'
function='0x0'/>
</controller>
<hostdev mode='subsystem' type='usb' managed='no'>
<source>
<vendor id='0x9710'/>
<product id='0x7830'/>
</source>
</hostdev>
Inside the guest i get this output of lsusb:
Bus 001 Device 002: ID 9710:7830 MosChip Semiconductor MCS7830 10/100
Mbps Ethernet adapter
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
lsusb -v shows this output for the root hub:
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Device Descriptor:
bLength 18
bDescriptorType 1
bcdUSB 2.00
bDeviceClass 9 Hub
bDeviceSubClass 0 Unused
bDeviceProtocol 0 Full speed (or root) hub
bMaxPacketSize0 64
idVendor 0x1d6b Linux Foundation
idProduct 0x0002 2.0 root hub
bcdDevice 2.06
iManufacturer 3 Linux 2.6.32-5-amd64 ehci_hcd
iProduct 2 EHCI Host Controller
iSerial 1 0000:00:07.0
Does this "Full speed" mean, that it is still running with 12MBit?
What is the status of High Speed USB (480Mbit) inside the guest?
What versions do i need? I currently use Debian Sid:
qemu-kvm (0.15.1)
libvirt0-dbg (0.9.6-2)
Kernel: Linux server 3.0.0-2-amd64 #1 SMP x86_64 GNU/Linux
Regards Til
^ permalink raw reply
* Re: [regression] CD-ROM polling blocks suspend on some machines (Re: [PATCH 1/2] cdrom: always check_disk_change() on open)
From: Matthijs Kooijman @ 2011-10-31 9:28 UTC (permalink / raw)
To: Tejun Heo
Cc: Gaudenz Steinlin, linux-kernel, Jameson Graef Rollins,
Jonathan Nieder, Jens Axboe, Amit Shah, David Zeuthen,
Martin Pitt
In-Reply-To: <20111030203503.GB7696@google.com>
[-- Attachment #1: Type: text/plain, Size: 772 bytes --]
Hi Tejun,
> The kworker submitted request but it got lost during queue destruction
> and blk_execute_rq() hangs. There have been a number of recent
> changes in block devel tree to address this issue. Can you please
> test the following branch?
>
> git://git.kernel.org/pub/scm/linux/kernel/git/tj/misc.git block-ref
I'm running this kernel now and the problem seems to have disappeared.
I've done a dozen or so undocks and suspends, without any problems.
Also, the "udisks-daemon" process in ps now says "not polling any
devices" after undocking, where it would continue to say "polling sr0"
before.
I'll continue running this kernel for a while and inform you if the
problem resurfaces.
Any other tests I should be doing?
Thanks,
Matthijs
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* [Buildroot] Building opencv for OMAP4430 / Armv7 / Cmake problem
From: Bruno Niklaus @ 2011-10-31 9:29 UTC (permalink / raw)
To: buildroot
Hi @all
i tried to build opencv for armv7 / omap4430 processor, i'm using
codesourcery toolchain with neon optimations enabled.
when cmake tries to build opencv i allways get strange error with
*"z_offset64_t"*
The generated "toolchainfile.cmake" file in the "buildroot/outpout"
directory sets additional CMAKE_C_FLAGS and CMAKE_CXX_FLAGS at the end:
*"-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64"*
I dont think these are the right flags, if i delete them and rebuild opencv
i runs trough without any errors.
but i dont know where the toolchainfile.cmake is generated? Where should i
apply a patch?
And is it okay to just delete the flags or should there be other flags?
best regards
Bruno
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.busybox.net/pipermail/buildroot/attachments/20111031/b2abbb6c/attachment.html>
^ permalink raw reply
* [PATCH] [kvm-autotest] tests.cgroup: Add TestFreezer
From: Lukas Doktor @ 2011-10-31 9:30 UTC (permalink / raw)
To: autotest, kvm, kvm-autotest, akong, lmr, ldoktor, jzupka
In-Reply-To: <1320053433-5190-1-git-send-email-ldoktor@redhat.com>
This subtest tests the 'freezer.state' cgroup functionality. It assignes the
virtual machine into freezer cgroup, schedule cpu-intensive work and verifies
the correct function in both states (frozen/thawed) during long and short
period of time.
* Adds TestFreezer (freezer) test
* Adds assign_vm_into_cgroup() function
* Code cleanup
Signed-off-by: Lukas Doktor <ldoktor@redhat.com>
---
client/tests/cgroup/cgroup_common.py | 16 +---
client/tests/kvm/tests/cgroup.py | 159 +++++++++++++++++++++++++++++++---
2 files changed, 146 insertions(+), 29 deletions(-)
diff --git a/client/tests/cgroup/cgroup_common.py b/client/tests/cgroup/cgroup_common.py
index 0c86398..7d5daf2 100755
--- a/client/tests/cgroup/cgroup_common.py
+++ b/client/tests/cgroup/cgroup_common.py
@@ -6,25 +6,11 @@ Helpers for cgroup testing.
@copyright: 2011 Red Hat Inc.
@author: Lukas Doktor <ldoktor@redhat.com>
"""
-import logging, os, shutil, subprocess, time, traceback
+import logging, os, shutil, subprocess, time
from tempfile import mkdtemp
from autotest_lib.client.bin import utils
from autotest_lib.client.common_lib import error
-def _traceback(name, exc_info):
- """
- Formats traceback into lines "name: line\nname: line"
- @param name: desired line preposition
- @param exc_info: sys.exc_info of the exception
- @return: string which contains beautifully formatted exception
- """
- out = "\n"
- for line in traceback.format_exception(exc_info[0], exc_info[1],
- exc_info[2]):
- out += "%s: %s" % (name, line)
- return out
-
-
class Cgroup(object):
"""
Cgroup handling class.
diff --git a/client/tests/kvm/tests/cgroup.py b/client/tests/kvm/tests/cgroup.py
index f31ef0c..b482bce 100644
--- a/client/tests/kvm/tests/cgroup.py
+++ b/client/tests/kvm/tests/cgroup.py
@@ -40,6 +40,20 @@ def run_cgroup(test, params, env):
raise error.TestFail("WM [%s] had to be recreated" % err[:-2])
+ def assign_vm_into_cgroup(vm, cgroup, pwd=None):
+ """
+ Assigns all threads of VM into cgroup
+ @param vm: desired VM
+ @param cgroup: cgroup handler
+ @param pwd: desired cgroup's pwd, cgroup index or None for root cgroup
+ """
+ if isinstance(pwd, int):
+ pwd = cgroup.cgroups[pwd]
+ cgroup.set_cgroup(vm.get_shell_pid(),pwd)
+ for pid in utils.get_children_pids(vm.get_shell_pid()):
+ cgroup.set_cgroup(int(pid), pwd)
+
+
def distance(actual, reference):
"""
Absolute value of relative distance of two numbers
@@ -118,10 +132,12 @@ def run_cgroup(test, params, env):
utils.system("dd if=/dev/zero of=%s bs=1M count=8 &>/dev/null"
% (host_file.name))
ret_file = host_file
- logging.debug("add_file_drive: new file %s as drive", host_file.name)
+ logging.debug("add_file_drive: new file %s as drive",
+ host_file.name)
else:
ret_file = None
- logging.debug("add_file_drive: using file %s as drive", host_file.name)
+ logging.debug("add_file_drive: using file %s as drive",
+ host_file.name)
out = vm.monitor.cmd("pci_add auto storage file=%s,if=%s,snapshot=off,"
"cache=off" % (host_file.name, driver))
@@ -277,10 +293,7 @@ def run_cgroup(test, params, env):
blkio.initialize(self.modules)
for i in range(2):
pwd.append(blkio.mk_cgroup())
- blkio.set_cgroup(self.vms[i].get_shell_pid(), pwd[i])
- # Move all existing threads into cgroup
- for tmp in utils.get_children_pids(self.vms[i].get_shell_pid()):
- blkio.set_cgroup(int(tmp), pwd[i])
+ assign_vm_into_cgroup(self.vms[i], blkio, pwd[i])
self.blkio.set_property("blkio.weight", 100, pwd[0])
self.blkio.set_property("blkio.weight", 1000, pwd[1])
@@ -475,9 +488,7 @@ def run_cgroup(test, params, env):
for i in range(len(self.cgroups)):
logging.info("Limiting speed to: %s", (self.speeds[i]))
# Assign all threads of vm
- self.cgroup.set_cgroup(self.vm.get_shell_pid(), self.cgroups[i])
- for pid in utils.get_children_pids(self.vm.get_shell_pid()):
- self.cgroup.set_cgroup(int(pid), self.cgroups[i])
+ assign_vm_into_cgroup(self.vm, self.cgroup, self.cgroups[i])
# Standard test-time is 60s. If the slice time is less than 30s,
# test-time is prolonged to 30s per slice.
@@ -668,10 +679,7 @@ def run_cgroup(test, params, env):
self.cgroup.initialize(self.modules)
self.cgroup.mk_cgroup()
- self.cgroup.set_cgroup(self.vm.get_shell_pid(),
- self.cgroup.cgroups[0])
- for pid in utils.get_children_pids(self.vm.get_shell_pid()):
- self.cgroup.set_cgroup(int(pid), self.cgroup.cgroups[0])
+ assign_vm_into_cgroup(self.vm, self.cgroup, 0)
# Test dictionary
# Beware of persistence of some setting to another round!!!
@@ -765,6 +773,128 @@ def run_cgroup(test, params, env):
return ("All restrictions enforced successfully.")
+
+ class TestFreezer:
+ """
+ Tests the freezer.state cgroup functionality. (it freezes the guest
+ and unfreeze it again)
+ """
+ def __init__(self, vms, modules):
+ """
+ Initialization
+ @param vms: list of vms
+ @param modules: initialized cgroup module class
+ """
+ self.vm = vms[0] # Virt machines
+ self.modules = modules # cgroup module handler
+ self.cgroup = Cgroup('freezer', '') # cgroup blkio handler
+ self.files = None # Temporary files (files of virt disks)
+ self.devices = None # Temporary virt devices
+
+
+ def cleanup(self):
+ err = ""
+ try:
+ self.cgroup.set_property('freezer.state', 'THAWED',
+ self.cgroup.cgroups[0])
+ except Exception, failure_detail:
+ err += "\nCan't unfreeze vm: %s" % failure_detail
+
+ try:
+ _ = self.vm.wait_for_login(timeout=30)
+ _.cmd('rm -f /tmp/freeze-lock')
+ _.close()
+ except Exception, failure_detail:
+ err += "\nCan't stop the stresses."
+
+ try:
+ del(self.cgroup)
+ except Exception, failure_detail:
+ err += "\nCan't remove Cgroup: %s" % failure_detail
+
+ if err:
+ logging.error("Some cleanup operations failed: %s", err)
+ raise error.TestFail("Some cleanup operations failed: %s" %
+ err)
+
+
+ def init(self):
+ """
+ Initialization
+ * prepares one cgroup and assign vm to it
+ """
+ self.cgroup.initialize(self.modules)
+ self.cgroup.mk_cgroup()
+ assign_vm_into_cgroup(self.vm, self.cgroup, 0)
+
+
+ def run(self):
+ """
+ Actual test:
+ * Freezes the guest and thaws it again couple of times
+ * verifies that guest is frozen and runs when expected
+ """
+ def get_stat(pid):
+ """
+ Gather statistics of pid+1st level subprocesses cpu usage
+ @param pid: PID of the desired process
+ @return: sum of all cpu-related values of 1st level subprocesses
+ """
+ out = None
+ for i in range(10):
+ try:
+ out = utils.system_output("cat /proc/%s/task/*/stat" %
+ pid)
+ except error.CmdError:
+ out = None
+ else:
+ break
+ out = out.split('\n')
+ ret = 0
+ for i in out:
+ ret += sum([int(_) for _ in i.split(' ')[13:17]])
+ return ret
+
+
+ session = self.vm.wait_for_serial_login(timeout=30)
+ session.cmd('touch /tmp/freeze-lock')
+ session.sendline('while [ -e /tmp/freeze-lock ]; do :; done')
+ cgroup = self.cgroup
+ pid = self.vm.get_pid()
+
+ for tsttime in [0.5,3,20]:
+ # Let it work for short, mid and long period of time
+ logging.info("FREEZING (%ss)", tsttime)
+ # Death line for freezing is 1s
+ cgroup.set_property('freezer.state', 'FROZEN',
+ cgroup.cgroups[0], check=False)
+ time.sleep(1)
+ _ = cgroup.get_property('freezer.state', cgroup.cgroups[0])
+ if 'FROZEN' not in _:
+ raise error.TestFail("Couldn't freeze the VM: state %s" % _)
+ stat_ = get_stat(pid)
+ time.sleep(tsttime)
+ stat = get_stat(pid)
+ if stat != stat_:
+ raise error.TestFail('Process was running in FROZEN state; '
+ 'iteration %s, stat=%s, stat_=%s, '
+ 'diff=%s' %
+ (i, stat, stat_, stat-stat_))
+ logging.info("THAWING (%ss)", tsttime)
+ self.cgroup.set_property('freezer.state', 'THAWED',
+ self.cgroup.cgroups[0])
+ stat_ = get_stat(pid)
+ time.sleep(tsttime)
+ stat = get_stat(pid)
+ if (stat - stat_) < (90*tsttime):
+ raise error.TestFail('Process was not active in FROZEN'
+ 'state; iteration %s, stat=%s, '
+ 'stat_=%s, diff=%s' %
+ (i, stat, stat_, stat-stat_))
+
+ return ("Freezer works fine")
+
+
# Setup
# TODO: Add all new tests here
tests = {"blkio_bandwidth_weigth_read" : TestBlkioBandwidthWeigthRead,
@@ -774,9 +904,10 @@ def run_cgroup(test, params, env):
"blkio_throttle_multiple_read" : TestBlkioThrottleMultipleRead,
"blkio_throttle_multiple_write" : TestBlkioThrottleMultipleWrite,
"devices_access" : TestDevicesAccess,
+ "freezer" : TestFreezer,
}
modules = CgroupModules()
- if (modules.init(['blkio', 'devices']) <= 0):
+ if (modules.init(['blkio', 'devices', 'freezer']) <= 0):
raise error.TestFail('Can\'t mount any cgroup modules')
# Add all vms
vms = []
--
1.7.6.4
^ permalink raw reply related
* Re: Fwd: Examples for using xl migrate -s ?
From: Ian Campbell @ 2011-10-31 9:30 UTC (permalink / raw)
To: Florian Heigl; +Cc: xen-devel
In-Reply-To: <CAFivhP=niHCDz_xsgdwTJxCd=8CU4sKA_v_TAh53WQPHSGF3gA@mail.gmail.com>
On Sat, 2011-10-29 at 20:38 +0100, Florian Heigl wrote:
> Hi,
>
> 2011/10/28 Ian Campbell <Ian.Campbell@citrix.com>:
> >> sorry to disturb, but are there any in-depth docs about migration in xl?
> >
> > Not that I know of, sorry.
>
> usage as an exercise left to the user. :>
As part of the documentation day last week Stefano Stabellini posted a
manpage for xl which no doubt contains a few words on this subject.
Please could you have a look in the archives and see if what is written
there would have helped.
> > Perhaps an option to xl migrate-receive to have it receive a single
> > connection on a specified socket from a given source instead of
> > expecting things on stdin would be a useful compromise? i.e. you should
> > use ssh to execute that command "securely" then pipe the data to the
> > unsecure socket?
>
> I don't write network protocols ... I don't know which way of
> connection setup would be best, but using ssh to securely initiate
> things definitely makes sense.
> On the other hand I don't like the initiator of (the migration)
> something telling the receiver where to listen. That's like the NAT
> traversal stuff in SIP.
>
> Maybe, uh, something like:
> ssh into migration target, saying hi, please spin up a receiver using
> (stdin|network)
> server says: receiver ready at (stdin|network ip+socket)
> client sends to the correct destination.
I think that could work, yes.
> The advantage would be that the server could have the final decision
> about which interface to use, it might well be different from the
> SSH-facing one.
>
> > It's the Unix way, surely ;-)
>
> Hehe, getting me from the Unix angle, I feel trapped!
:-)
Ian.
^ permalink raw reply
* [Cluster-devel] GFS2 git trees
From: Steven Whitehouse @ 2011-10-31 9:31 UTC (permalink / raw)
To: cluster-devel.redhat.com
Hi,
Linus has pulled the -nmw tree. I'll leave that tree empty for now as we
are not supposed to add patches to linux-next until the merge window has
closed. As soon as that has happened I'll get Bob's two readahead
patches queued up, plus anything else that has appeared in the meantime.
Now that I'm back from Prague and my kernel.org account is back working,
I hope to be able to get back to normal wrt dealing with patches. I'll
also be working through a small backlog of things I've been waiting to
do,
Steve.
^ permalink raw reply
* Re: [Xen-users] Re: Xen document day (Oct 12 or 26)
From: Ian Campbell @ 2011-10-31 9:31 UTC (permalink / raw)
To: Florian Heigl
Cc: xen-devel@lists.xensource.com, Konrad Rzeszutek Wilk,
Andrew Bobulsky, Lars Kurth, Joseph Glanville,
xen-users@lists.xensource.com
In-Reply-To: <CAFivhPk7Pk4DWHeDVTWvV26vQqU0-pqUqvV3GNx5JBDShQW85g@mail.gmail.com>
On Sun, 2011-10-30 at 20:58 +0000, Florian Heigl wrote:
> - most of the pages being immutable so you couldn't even fix stuff.
This one is a protective measure against spammers (which have been a big
problem in the past). I sure hope media wiki has some better mechanisms
than requiring every account to be manually authorised as an editor (I'm
sure it must do!). It's a big barrier to "drive by fixups" as well as
presenting an initial barrier which even longer term contributors have
to cross.
Ian.
^ permalink raw reply
* [U-Boot] [PATCH] 4xx_pci.c: add error checking, fix GCC 4.6 build warning
From: Stefan Roese @ 2011-10-31 9:32 UTC (permalink / raw)
To: u-boot
In-Reply-To: <1319917111-14323-1-git-send-email-wd@denx.de>
Hi Wolfgang,
On Saturday 29 October 2011 21:38:31 Wolfgang Denk wrote:
> Fix:
> 4xx_pci.c: In function 'pci_init_board':
> 4xx_pci.c:855:6: warning: variable 'busno' set but not used
> [-Wunused-but-set-variable]
Thanks.
Acked-by: Stefan Roese <sr@denx.de>
Best regards,
Stefan
--
DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-0 Fax: (+49)-8142-66989-80 Email: office at denx.de
^ permalink raw reply
* [B.A.T.M.A.N.] batman miss crc16 module after nico commit
From: Gioacchino Mazzurco @ 2011-10-31 9:32 UTC (permalink / raw)
To: riot-workshop, Nodi Roma List,
The list for a Better Approach To Mobile Ad-hoc Networking,
Marek Lindner
Hi all!
After nico commit [0] batman-adv stopped working in openwrt backfire (
the crc16 modules is still kmod-crc16 in openwrt stable )
the batman-adv module refuse to load without error message on stdout
but saying that crc16 is missing on dmesg
selecting manually kernel modules -> other modules -> kmod-crc16 it work again
[0] https://dev.openwrt.org/changeset/28657/packages/net/batman-adv/Makefile
^ permalink raw reply
* Re: [PATCH DOCDAY] introduce an xl man page in pod format
From: Ian Campbell @ 2011-10-31 9:32 UTC (permalink / raw)
To: Stefano Stabellini, Dan Magenheimer; +Cc: xen-devel@lists.xensource.com
In-Reply-To: <alpine.DEB.2.00.1110271659380.3519@kaball-desktop>
On Thu, 2011-10-27 at 17:19 +0100, Stefano Stabellini wrote:
>
> Almost every command implemented in xl should be present, a notable
> exception are the tmem commands that are currently missing.
That should be easy to fix -- Dan could you provide some words about
these commands please?
I assume Stefano is referring to:
$ grep \"tmem tools/libxl/xl_cmdtable.c
{ "tmem-list",
{ "tmem-freeze",
{ "tmem-destroy",
{ "tmem-thaw",
{ "tmem-set",
{ "tmem-shared-auth",
{ "tmem-freeable",
These mirror the xm commands but there's nothing we can crib there
either.
POD format per Stefano's original post would be ideal but if you don't
feel like learning that (although it is pretty simple) I think we can
offer to format stuff up if you just provide the words.
Ian.
^ permalink raw reply
* Re: [PATCH 0/2] ACPI: Re-factor and remove ./drivers/acpi/atomicio.[ch]
From: Thomas Renninger @ 2011-10-31 10:33 UTC (permalink / raw)
To: Bjorn Helgaas
Cc: Myron Stowe, Len Brown, bondd, lenb, linux-acpi, rjw, ying.huang
In-Reply-To: <CAErSpo7L1PNLo7TSuCPe3Az9ixSizQmoBWtynhHDZ-T9BhoNtw@mail.gmail.com>
On Friday 28 October 2011 17:14:39 Bjorn Helgaas wrote:
> On Thu, Oct 27, 2011 at 7:49 PM, Thomas Renninger <trenn@suse.de> wrote:
> > There is another problem. Would be great to get some opinions/feedback
> > on it already:
> > APEI GAR entries seem to have invalid bit_width entries on some platforms.
> > After looking at several tables, I expect that with APEI tables access width
> > (in bytes) should get used instead, Windows seem to ignore bit width fields,
> > at least for APEI tables.
>
> I'm confused. How can you tell that the bit_width is incorrect My
> understanding is that the bit_width is the size of the *register*,
> while the access_width is the size of access the processor must
> generate on the bus. The access_width may be larger, for example, if
> the hardware only supports 32-bit or 64-bit reads.
This also is my understanding.
> So I don't understand how you can derive bit_width from access_width.
The problem is that Windows seem to ignore the bit width field, at least
for APEI tables.
There you also have the mask value and bit width information is not
needed to determine the bits of interest.
While mostly bit width information is correct, I compared quite some
tables and especially IBM is adding some interesting values.
But I've also seen wrong bit widths on Supermicro and others.
> In the example below, I think we're supposed to do a 64-bit read, then
> extract 8 bits that contain the register of interest. If we keep all
> 64 bits, I don't see how that can be correct.
Yep. But "Get Error Address Range" is supposed to return/contain an iomem address.
Cutting it down to 8 bits produces below error when trying to
reserve a memory region from the retrieved value/address at 0x3f.
Using acpidump to evaluate the register's 8 byte shows:
acpidump --addr 0x7F8A8032 --length 8
0x000000007f8a803f
which perfectly fits into an unused e820 reserved memory region.
Same for "Get Error Address Length" on this machine:
[1D0h 0464 1] Action : 0E (Get Error Address Length)
[1D5h 0469 1] Bit Width : 08
[1D7h 0471 1] Encoded Access Width : 03 (DWord Access:32)
[1D8h 0472 8] Address : 000000007F8A803A
[1E8h 0488 8] Mask : 00000000FFFFFFFF
Reading 0x7F8A803A you get:
0x2000
which is exactly what you expect as "error memory length", but cut
down to 8 bits it's wrong.
Look at the mask value from which you could derive bit width (on APEI tables
only), it should be 0x16, but it's not needed (bit width info) and should
get ignored because it's sometimes wrong.
The question remains whether Windows (which versions?) is only ignoring bit
width in their APEI implementation (this is what I currently expect).
For now, as we have separate APEI GAR checking it should be fine to
only ignore bit width there. But keeping an eye open and check
other ACPI tables containing GAR structures out there in the field
is certainly a good idea.
Another "wrong" GAR definition I've found (only once) is that all fields
(bit width, byte access, ...) are zero, similar to optional FADT GAR structures.
I didn't runtime test it, but currently this should pass an error
and invalidate the whole table (for example should result in erst_disable=1).
Additional logic is needed to ignore and not use this serialization command
as if it does not exist.
Thomas
> > ...
> > Comparing different Generic Adress Register definitions of
> > different vendors it came out that bit width (at least in APEI
> > tables) is sometimes wrong or used different compared to older
> > ACPI BIOS definitions (e.g. older FACP tables).
> > It looks like Windows ignores the bit width field in
> > latest implementations. Either in APEI table parts only
> > (I'd say more likely) or in other ACPI parts as well.
> >
> > Worst case is that an address value to be read from a GAR structure
> > can have a 8 bit width definition resulting in:
> > ERST: Can not request iomem region <0x 3f-0x 3f>
> > while the access width is correct:
> > [1B0h 0432 1] Action : 0D (Get Error Address Range)
> > [1B4h 0436 12] Register Region : <Generic Address Structure>
> > [1B4h 0436 1] Space ID : 00 (SystemMemory)
> > [1B5h 0437 1] Bit Width : 08
> > [1B6h 0438 1] Bit Offset : 00
> > [1B7h 0439 1] Encoded Access Width : 04 (QWord Access:64)
> > [1B8h 0440 8] Address : 000000007F8A8032
>
> Bjorn
^ permalink raw reply
* Re: srp_transport: Fix atttribute registration race
From: James Bottomley @ 2011-10-31 9:33 UTC (permalink / raw)
To: Bart Van Assche
Cc: linux-scsi-u79uwXL29TY76Z2rM5mHXA,
linux-rdma-u79uwXL29TY76Z2rM5mHXA, Fujita Tomonori, Brian King,
David Dillow, Roland Dreier
In-Reply-To: <201110211857.23622.bvanassche-HInyCGIudOg@public.gmane.org>
On Fri, 2011-10-21 at 18:57 +0200, Bart Van Assche wrote:
> Register transport attributes after the attribute array has been
> set up instead of before. The current code is racy because there
> is no guarantee that the CPU examining the attribute container
> will see all values written to the container.
I don't agree with this change log. As far as the kernel is concerned,
nothing happens until that function returns because the only way to use
anything is to get a match to succeed, and they all check for
->transportt which will be NULL.
I can accept that it's best practise to initialise something before
registering it, because the reverse excites everyone's bogosity sensors,
it's just not a bug in this case.
James
--
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: [GIT PULL rcu/next] RCU commits for 3.1
From: Paul E. McKenney @ 2011-10-31 9:32 UTC (permalink / raw)
To: Li Zefan
Cc: Ingo Molnar, eric.dumazet, shaohua.li, ak, mhocko, alex.shi,
efault, linux-kernel, Peter Zijlstra, Paul Turner
In-Reply-To: <4EAE57AF.1060706@cn.fujitsu.com>
On Mon, Oct 31, 2011 at 04:09:19PM +0800, Li Zefan wrote:
> (Let's cc Peter and Paul Turner for this perf cgroup issue.)
>
> > Thank you for the analysis. Does the following patch fix this problem?
> >
> > Thanx, Paul
> >
> > ------------------------------------------------------------------------
> >
> > fs: Add RCU protection in set_task_comm()
> >
> > Running "perf stat true" results in the following RCU-lockdep splat:
> >
> > ===============================
> > [ INFO: suspicious RCU usage. ]
> > -------------------------------
> > include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!
> >
> > other info that might help us debug this:
> >
> > rcu_scheduler_active = 1, debug_locks = 0
> > 1 lock held by true/655:
> > #0: (&sig->cred_guard_mutex){+.+.+.}, at: [<810d1bd7>] prepare_bprm_creds+0x27/0x70
> >
> > stack backtrace:
> > Pid: 655, comm: true Not tainted 3.1.0-tip-01868-g1271bd2-dirty #161079
> > Call Trace:
> > [<81abe239>] ? printk+0x18/0x1a
> > [<81064920>] lockdep_rcu_suspicious+0xc0/0xd0
> > [<8108aa02>] perf_event_enable_on_exec+0x1d2/0x1e0
> > [<81063764>] ? __lock_release+0x54/0xb0
> > [<8108cca8>] perf_event_comm+0x18/0x60
> > [<810d1abd>] ? set_task_comm+0x5d/0x80
> > [<81af622d>] ? _raw_spin_unlock+0x1d/0x40
> > [<810d1ac4>] set_task_comm+0x64/0x80
> > [<810d25fd>] setup_new_exec+0xbd/0x1d0
> > [<810d1b61>] ? flush_old_exec+0x81/0xa0
> > [<8110753e>] load_elf_binary+0x28e/0xa00
> > [<810d2101>] ? search_binary_handler+0xd1/0x1d0
> > [<81063764>] ? __lock_release+0x54/0xb0
> > [<811072b0>] ? load_elf_library+0x260/0x260
> > [<810d2108>] search_binary_handler+0xd8/0x1d0
> > [<810d2060>] ? search_binary_handler+0x30/0x1d0
> > [<810d242f>] do_execve_common+0x22f/0x2a0
> > [<810d24b2>] do_execve+0x12/0x20
> > [<81009592>] sys_execve+0x32/0x70
> > [<81af7752>] ptregs_execve+0x12/0x20
> > [<81af76d4>] ? sysenter_do_call+0x12/0x36
> >
> > Li Zefan noted that this is due to set_task_comm() dropping the task
> > lock before invoking perf_event_comm(), which could in fact result in
> > the task being freed up before perf_event_comm() completed tracing in
> > the case where one task invokes set_task_comm() on another task -- which
> > actually does occur via comm_write(), which can be invoked via /proc.
> >
>
> This is not true. The caller should ensure @tsk is valid during
> set_task_comm().
>
> The warning comes from perf_cgroup_from_task(). We can trigger this warning
> in some other cases where perf cgroup is used, for example:
I must defer to your greater knowledge of this situation. What patch
would you propose?
Thanx, Paul
> # mount -t cgroup -o perf_event xxx /mnt
> # ./perf record -a -e 'sched:*' -G / true
>
> [ 171.603171] ===============================
> [ 171.603173] [ INFO: suspicious RCU usage. ]
> [ 171.603175] -------------------------------
> [ 171.603178] include/linux/cgroup.h:548 suspicious rcu_dereference_check() usage!
> [ 171.603180]
> [ 171.603181] other info that might help us debug this:
> [ 171.603182]
> [ 171.603184]
> [ 171.603185] rcu_scheduler_active = 1, debug_locks = 0
> [ 171.603188] 2 locks held by perf/2899:
> [ 171.603190] #0: (&cpuctx_mutex){+.+...}, at: [<c04b2fe7>] sys_perf_event_open+0x4ed/0x62a
> [ 171.603201] #1: (&cpuctx_lock){......}, at: [<c04ac4bc>] perf_ctx_lock+0xe/0x1d
> [ 171.603210]
> [ 171.603211] stack backtrace:
> [ 171.603214] Pid: 2899, comm: perf Not tainted 3.1.0+ #12
> [ 171.603216] Call Trace:
> [ 171.603222] [<c07e7234>] ? printk+0x25/0x29
> [ 171.603227] [<c046279d>] lockdep_rcu_suspicious+0x90/0x9b
> [ 171.603232] [<c04ac688>] perf_cgroup_from_task+0x5e/0x64
> [ 171.603236] [<c04adfe7>] update_cgrp_time_from_event.clone.18+0x16/0x25
> [ 171.603240] [<c04b01a1>] __perf_install_in_context+0xa0/0xcf
> [ 171.603244] [<c04ac355>] ? pmu_dev_release+0xa/0xa
> [ 171.603248] [<c04ac386>] remote_function+0x31/0x37
> [ 171.603253] [<c0468aaa>] smp_call_function_single+0x7d/0xf5
> [ 171.603257] [<c04ac41d>] cpu_function_call+0x29/0x2e
> [ 171.603261] [<c04b0101>] ? perf_pm_suspend_cpu+0x9f/0x9f
> [ 171.603264] [<c04ae85b>] perf_install_in_context+0x53/0x9f
> [ 171.603268] [<c04b3033>] sys_perf_event_open+0x539/0x62a
> [ 171.603273] [<c04566f5>] ? up_read+0x1b/0x2e
> [ 171.603277] [<c07ec856>] ? do_page_fault+0x2e6/0x314
> [ 171.603283] [<c07ef2df>] sysenter_do_call+0x12/0x38
>
> > This commit fixes this problem by entering an RCU read-side critical
> > section before acquiring the task lock and exiting this critical section
> > after perf_event_comm() returns.
> >
> > Reported-by: Ingo Molnar <mingo@elte.hu>
> > Signed-off-by: Paul E. McKenney <paulmck@linux.vnet.ibm.com>
> >
> > diff --git a/fs/exec.c b/fs/exec.c
> > index 25dcbe5..fb928d3 100644
> > --- a/fs/exec.c
> > +++ b/fs/exec.c
> > @@ -1056,6 +1056,7 @@ EXPORT_SYMBOL_GPL(get_task_comm);
> >
> > void set_task_comm(struct task_struct *tsk, char *buf)
> > {
> > + rcu_read_lock(); /* protect task pointer through tracing. */
> > task_lock(tsk);
> >
> > /*
> > @@ -1069,6 +1070,7 @@ void set_task_comm(struct task_struct *tsk, char *buf)
> > strlcpy(tsk->comm, buf, sizeof(tsk->comm));
> > task_unlock(tsk);
> > perf_event_comm(tsk);
> > + rcu_read_unlock();
> > }
> >
> > int flush_old_exec(struct linux_binprm * bprm)
> >
>
^ 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.