On Thu, Jul 05, 2012 at 04:38:51PM +0200, richard -rw- weinberger wrote:
> The article describes nothing that is not also doable with KVM these days.
> Anyway, UML is fun and nice to use. :-)
Doesn't KVM require the extra VM CPU features? For older CPU's, I thought
UML was more efficient.
Am I a
On Wed, Nov 30, 2011 at 12:20:24AM +0100, mattias wrote:
> are it possible from the host?
It's not ideal, but I use a script like this:
#!/bin/bash
for pid in $(ps aux |grep uml |awk '{print $2}') ; do
echo "Killing $pid..."
kill -9 $pid
done
This assumes that only one UML VM
On Tue, Sep 20, 2011 at 12:40:44AM +0200, richard -rw- weinberger wrote:
> > capget(0x20080522, 0, NULL) ? ? ? ? ? ? = 0
> > getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) =
> > -1 EOPNOTSUPP (Operation not supported)
> > write(2, "Failed to get capabilities of fi"..., 85
On Tue, Sep 20, 2011 at 12:28:53AM +0200, richard -rw- weinberger wrote:
> Can you run strace on it?
> Let's see what the system call returns...
I get this:
capget(0x20080522, 0, NULL) = 0
getxattr("/usr/libexec/pt_chown", "security.capability", 0xbf9444ac, 20) = -1
EOPNOTSUPP (Opera
Hi,
I'm running Fedora 15 in a UML VM, and during update, it tries to set
file capabilities on one file, and this appears to not be available.
When I run it manually, I get:
[root@fedora15 ~]# getcap /usr/libexec/pt_chown
Failed to get capabilities of file `/usr/libexec/pt_chown' (Operation not
On Thu, Oct 14, 2010 at 03:14:28PM +0200, Tejun Heo wrote:
> Hello,
>
> Can you please try this one then? It seems to work here but I can't
> reproduce the original problem reliably so I'm not really sure.
>
> Thanks.
>
> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
> in
Hi,
Is it possible to use libusb inside UML to access USB devices?
I see a note on the website regarding a patch for this from 2001,
so I'm assuming it is possible, but I'm having trouble turning
any USB options on in the kernel config.
Any tips appreciated.
Thanks,
- Chris
---
On Thu, Oct 07, 2010 at 09:58:16AM +0200, Jens Axboe wrote:
> So how about this? Note that I haven't even compiled this. The request
> handling logic really should be fixed in there, it's horribly
> inefficient.
Thanks. I fixed the compile error with:
> + .rq_offset 0, \
to
>
On Tue, Oct 05, 2010 at 10:23:19AM +0200, Tejun Heo wrote:
> H, can you please give a shot at the following one? Thank you.
I applied this patch on top of stock 2.6.35.5 as usual (no other patches)
and tested on my maverick image as before. I ran a fsck.ext3 on the
filesystem image from the
On Mon, Oct 04, 2010 at 06:37:36PM +0200, Tejun Heo wrote:
> Hello, sorry about chiming in later. I was off last week.
No problem, I'm eager to test patches to fix this.
> I think we're on the right track. The problem with Jens' patch was
> that it didn't consider the fact that blk_end_request
On Wed, Sep 29, 2010 at 02:21:07PM +0900, Jens Axboe wrote:
> This seems to imply that the original commit pin pointed is not
> the only issue we have in that code atm.
>
> I think we need to find the real fix here, just disabling merging
> is not a fix (it's just a nasty work-around for the real
On Wed, Sep 29, 2010 at 12:13:10AM +0200, Richard Weinberger wrote:
> Am Mittwoch 29 September 2010, 00:00:00 schrieb Andrew Morton:
> > This is a workaround, I think? Do we know what the actual bug is?
> > From the comment it appears to be a regression?
>
> Yes, it is a workaround.
> For more de
On Wed, Sep 29, 2010 at 08:10:06AM +0900, Jens Axboe wrote:
> It looks like that if we need to restart the requeue, then
> we use the initial position and not the current index. Does
> this help?
>
> diff --git a/arch/um/drivers/ubd_kern.c b/arch/um/drivers/ubd_kern.c
> index 1bcd208..81ee063 1006
On Wed, Sep 29, 2010 at 12:13:10AM +0200, Richard Weinberger wrote:
> Am Mittwoch 29 September 2010, 00:00:00 schrieb Andrew Morton:
> > This is a workaround, I think? Do we know what the actual bug is?
> > From the comment it appears to be a regression?
>
> Yes, it is a workaround.
> For more de
14 matches
Mail list logo
