Hi Richard,
On 03/26/2016 10:58 AM, Richard Weinberger wrote:
> On Sun, Jan 10, 2016 at 6:13 AM, Peter Hurley
> wrote:
>> Evaluate the conditions which prevent this tty being the controlling
>> terminal in one place, just before setting the controlling terminal.
>>
reference after signalling is complete.
cc: Jeff Dike
cc: Richard Weinberger
cc: user-mode-linux-devel@lists.sourceforge.net
Signed-off-by: Peter Hurley
---
arch/um/drivers/line.c | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/arch/um/drivers/line.c b/arch/um/drivers
s
> like overkill for a patch that mostly deletes code.
>
> Akpm, can you take this?
>
I'm fine with it as-is.
Acked-by: H. Peter Anvin
--
Want fast and easy access to all the code in your enterpri
On 01/13/2014 04:50 AM, Fengguang Wu wrote:
>> Fengguang, could we get UM builds added to the test robot?
>
> Yes, sure. Just added UML i386/x86_64 to the build tests.
>
Thank you! That will be highly useful.
-hpa
-
On 01/12/2014 06:52 AM, Richard Weinberger wrote:
> Commit "x86: Delete non-required instances of include "
> broke the UML build.
>
> arch/x86/um/vdso/vdso.S: Assembler messages:
> arch/x86/um/vdso/vdso.S:2: Error: no such instruction: `__initdata'
> arch/x86/um/vdso/vdso.S:9: Error: no such inst
If ARCH doesn't match uname for some definition of match?
Thorsten Glaser wrote:
>On Wed, 21 Aug 2013, Richard Weinberger wrote:
>
>> The series touches also m68k, sh, mips and unicore32.
>> These architectures magically select a cross compiler if ARCH !=
>SUBARCH.
>> Do really need that behavior
On 05/28/2013 08:43 AM, Arnd Bergmann wrote:
>
> Right, that is what the patch I just posted does.
>
> On a related note, I found that WARN_ON() can no longer be compiled
> out since there is already code that relies on the side-effects of
> the condition. I assume that was an intentional change
On 05/28/2013 01:19 AM, Ingo Molnar wrote:
>
> So I think the same principle applies to it as to any other debugging
> code: it's fine to be able to turn debugging off. It's a performance
> versus kernel robustness/determinism trade-off.
>
I suspect, rather, that BUG() should turn into a trap
Here's one more example, still the same setup, but this time crashing at
the same place as the original bug report. (BUG: failure at
block/blk-core.c:2978/blk_flush_plug_list()!) See below for output.
BTW my host setup is Linux Mint 14:
Linux ufo 3.5.0-17-generic #28-Ubuntu SMP Tue Oct 9 19:31:23
Here's another one where the crash is from startup rather than shutdown:
Core dump limits :
soft - 0
hard - NONE
Checking that ptrace can change system call numbers...OK
Checking syscall emulation patch for ptrace...OK
Checking advanced syscall emulation patch for ptrace...OK
Chec
OK setting SUBARCH did the trick. Thanks for that. :-)
Here's the output from a crash using the associated build. Too several
boots to trigger the crash - probably some sort of a race condition. Note
that I am doing nothing other than booting up the UML to trigger the crash
(that is, I am not
sets.s] Error 1
make: *** [arch/x86/um/user-offsets.s] Error 2
> Am Fri, 5 Apr 2013 10:13:24 -0400
> schrieb Peter Butler :
>
>> OK thanks - will get to that later tonight :-)
>
> Thanks for testing.
> I've fixed some odd bugs currently. The code is in Linus's tree
Running UML from vanilla kernel 3.8.5 compiled with default kernel
configuration and booted with Fedora 18 root fs (as downloaded from
http://fs.devloop.org.uk/). Boots fine about 3/4 of the time, the rest of
the time it crashes - see output below for an example.
command line:
./linux ubd0=Fed
Good thing, then,. otherwise we'd have a compat headache.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
LogMeIn Rescue: Anywhere, Anytim
On 12/13/2012 10:37 AM, Borislav Petkov wrote:
>>
>> If appropriate, the code could be changed to
>>
>> (void *)(unsigned long)m->ip
>
> Can we explicitly cast it to what it is so that we can be explicit as to
> what we're casting it? IOW:
>
> (void *)(__u64)m->ip;
>
> Does that even
Am Montag, 10. September 2012, 09:29:18 schrieb Jean Delvare:
> If everybody is happy with this, I'll queue it up for 3.7.
I'm happy with this ;)
Thanks,
Peter
--
Live Security Virtual Conference
Exclusi
/Kconfig | 14 +-
> drivers/i2c/muxes/Kconfig |2 +-
> 3 files changed, 15 insertions(+), 15 deletions(-)
I'm perfectly fine with this.
Signed-off-by: Peter Huewe
--
Live Security Virtual
st compiled it.
Thanks,
Peter
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will includ
part of the i2c/busses section.
And almost all of those drivers use ioremap.
For my stub driver I don't need any of that, I'd be fine with the move of
HAS_IOMEM as proposed by Jean.
Peter
--
Live Security Vi
g on UML is the ioremap function family
;/
Peter
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discuss
ur proposed solution, I moved the stub driver to the
end in order to have only one big if HAS_IOMEM.
Thanks,
Peter
---
>From 923bc2feac0a04ee35382e60bb523d08baf92d48 Mon Sep 17 00:00:00 2001
From: Peter Huewe
Date: Sun, 9 Sep 2012 14:10:05 +0200
Subject: [PATCH] i2c: Move HAS_IOMEM depend
the i2c maintainer (in CC).
Nevertheless it would probably be a good starting point for developers - if a
subsystem is available the probability that someone hacks on it is much higher
;)
Thanks,
Peter
---
>From 25268d4cdd4b1dd1e5d03c9b90c179758dd41e2e Mon Sep 17 00:00:00 2001
From: Peter
and start with driver and tools development for it ;)
I added the patch, in case you're interested.
Unfortunately some I2C drivers fail to build if CONFIG_HAS_IOMEM = n, but
don't have that dependency in Kconfig - I simply added it to prevent them from
inclusion.
Do you think I s
ints?
The main thing I'm lacking is a good idea how to register the 'stub devices'.
Or is this something that is not really desired by the uml project?
Thanks,
Peter
--
Live Security Virtual Conference
> They'd be pretty dumb to do that without reading the local comment,
> but still...
Methinks something simple like:
WARN_ON(cpu_online(cpu));
Ought to cure that worry, no? :-)
>
> >so its not like new tasks will ever get this cpu set in
> > + * t
On Mon, 2012-03-26 at 19:04 +0200, Oleg Nesterov wrote:
> Interesting... Why? I mean, why do you dislike stop_machine() in
> _cpu_down() ? Just curious.
It disturbs all cpus, the -rt people don't like that their FIFO tasks
don't get to run, the trading people don't like their RDMA poll loops to
b
On Sun, 2012-03-25 at 19:42 +0200, Oleg Nesterov wrote:
> __cpu_disable() is called by __stop_machine(), we know that nobody
> can preempt us and other CPUs can do nothing.
It would be very good to not rely on that though, I would love to get
rid of the stop_machine usage in cpu hotplug some day.
On Sat, 2012-03-24 at 20:21 +0400, Anton Vorontsov wrote:
> Just wonder how do you see the feature implemented?
>
> Something like this?
>
> #define __ret_cond_locked(l, c) __attribute__((ret_cond_locked(l, c)))
> #define __ret_value __attribute__((ret_value))
> #define __ret_loc
On Sat, 2012-03-24 at 14:30 +0400, Anton Vorontsov wrote:
> Traversing the tasks requires holding tasklist_lock, otherwise it
> is unsafe.
No it doesn't, it either requires tasklist_lock or rcu_read_lock().
--
This SF em
' -
> unexpected unlock
> CHECK mm/memcontrol.c
> ...
> mm/memcontrol.c:1130:17: warning: context imbalance in
> 'task_in_mem_cgroup' - unexpected unlock
>
> p.s. I know Peter Zijlstra detest the __cond_lock() stuff, but untill
> we have anything
On Sat, 2012-03-24 at 14:27 +0400, Anton Vorontsov wrote:
> +void clear_tasks_mm_cpumask(int cpu)
> +{
> + struct task_struct *p;
> +
> + read_lock(&tasklist_lock);
> + for_each_process(p) {
> + struct task_struct *t;
> +
> + t = find_lock_task_mm(p);
>
From: "H. Peter Anvin"
In case we need generated header files for the values in
user-offsets.h, make sure we build generated header files before
user-offsets.s is built.
Signed-off-by: H. Peter Anvin
---
arch/um/Makefile |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
From: "H. Peter Anvin"
Run the "archheaders" target for the host architecture, for
architectures (like x86, now) that want to generate some of the
necessary header files.
Add $(HOST_DIR)/include/generated to the include path so we then pick
them up.
Signed-off-by: H. Peter
From: "H. Peter Anvin"
Now when the native kernel uses a single style of generated system
call table, follow suite for UML and implement the same style, all in
C. This requires __NR_syscall_max and NR_syscalls to be generated; on
native this is done in asm-headers.h but that file is
From: "H. Peter Anvin"
The patch series currently in -tip as x86/syscall, which builds
syscall tables from a simple text file also broke UML.
I intend to apply this patch to tip:x86/syscall, but if the UML folks
would either holler or ack that would be appreciated.
This patch seri
On 12/04/2011 02:41 PM, Benjamin Herrenschmidt wrote:
>
> I agree with Russell, his approach is a lot easier to maintain long run,
> we should even consider converting existing definitions.
>
Thirded.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work f
On 08/23/2011 02:10 PM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
>> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>>>
>>> But no, I don't think the difference has disappeared - to the contrary,
>>> AFAIC
On 08/23/2011 02:10 PM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 05:06:03PM -0400, H. Peter Anvin wrote:
>> On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>>>
>>> But no, I don't think the difference has disappeared - to the contrary,
>>> AFAIC
On 08/23/2011 02:20 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 2:08 PM, H. Peter Anvin wrote:
>>
>> Again, can we steal one of the padding fields to use for that state
>> variable? We have two 16-bit padding fields; one for cs and one for ss.
>
> We can
On 08/23/2011 10:33 AM, Linus Torvalds wrote:
>
> It would be *nice* if we did the swizzling automatically at setregs()
> time too, but we simply don't have enough information in the kernel to
> do that. Again, exactly because pt_regs doesn't have a "state"
> variable, when user-space does the SET
On 08/23/2011 01:56 PM, Borislav Petkov wrote:
>
> But no, I don't think the difference has disappeared - to the contrary,
> AFAICT, the intention is for SYSCALL to be the fastest way to do
> syscalls on x86 due to diminished number of segment checks etc. INT80
> is legacy, slower, etc. I believe
On 08/23/2011 12:24 PM, Linus Torvalds wrote:
> On Tue, Aug 23, 2011 at 12:18 PM, H. Peter Anvin wrote:
>>
>> We could drop that information in a metaregister. It's not backward
>> compatible, but at least it will be obvious when that information is
>> availab
On 08/23/2011 09:48 AM, Al Viro wrote:
>
> Um... How would it know which syscall variant had that been, to start
> with? For int 0x80 it would need to use registers as-is. For SYSENTER
> it also could use them as-is - ebp will differ from what we put there
> when entering the sucker, but not cr
On 08/23/2011 09:22 AM, Borislav Petkov wrote:
> On Tue, Aug 23, 2011 at 12:11:43PM -0400, Andrew Lutomirski wrote:
>> In any case, this seems insanely overcomplicated. I'd be less afraid
>> of something like my approach (which, I think, makes all of the
>> SYSCALL weirdness pretty much transparen
On 08/22/2011 06:16 PM, Andrew Lutomirski wrote:
>
> I suspect that very few things care whether syscall arguments get
> clobbered. The only way it would matter is if gcc reuses the argument
> in the ecx slot after an inlined syscall later in the same function.
> Any code that does that is alrea
On 08/22/2011 05:03 PM, Al Viro wrote:
> On Mon, Aug 22, 2011 at 04:27:51PM -0700, Linus Torvalds wrote:
>
>> So I think the "let's fix the vdso case for sysenter" + "let's remove
>> the 32-bit syscall vdso" is the right solution. If somebody has
>> hardcoded syscall instructions, or generates the
On 08/22/2011 04:27 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 3:04 PM, H. Peter Anvin wrote:
>>
>> However, we could just issue a SIGILL or SIGSEGV at this point; the same
>> way we would if we got an #UD or #GP fault; SIGILL/#UD would be
>> cons
On 08/22/2011 02:52 PM, Andrew Lutomirski wrote:
>
> Even if it's ok, we still have to do *something* in the cstar entry
> point -- I don't think there's any way to turn SYSCALL in
> compatibility mode but leave it enabled in long mode. So if we're
> planning on killing off SYSCALL from outside t
On 08/22/2011 01:05 PM, Linus Torvalds wrote:
> On Mon, Aug 22, 2011 at 8:13 AM, Al Viro wrote:
>>
>> In __kernel_vsyscall() the problem is possible to deal with; there we control
>> the code around that sucker. It's SYSCALL in 32bit binary outside of
>> vdso32 that causes real PITA...
>
> I jus
On 08/21/2011 09:26 PM, Al Viro wrote:
> On Sun, Aug 21, 2011 at 09:11:54PM -0700, H. Peter Anvin wrote:
>>> lack of point - the *only* CPU where it would matter would be K6-2, IIRC,
>>> and (again, IIRC) it had some differences in SYSCALL semantics compared to
>>>
cleared?
The most likely reason for a binary to execute a stray SYSCALL is
because they read it out of the vdso. Totally daft, but we certainly
see a lot of stupid things as evidenced by the JIT thread earlier this
month.
In that sense, a "safe" thing would be to drop use of SYSCALL fo
ck to
int $0x80 or some other legacy-style domain crossing instruction for
32-bit system calls on AMD64 processors? We don't ever use SYSCALL in
legacy mode, so native i386 kernels are unaffected.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don
s also the option of just doing nothing in this case, I guess.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
uberSVN's rich system and us
);
with that amount of state we have all the information needed to *either*
extract the syscall arguments *or* the register contents. Without
those, we can only represent one of the two possible metalevels (right
now we represent the higher-level metalevel, the argument vector), but
we need both
is different, especially since SYSCALL is legal to execute from
anywhere in userspace (and no, as we have learned already doing EIP
checking is *NOT* acceptable.)
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
-
3] for the
> regs_return_value(). I have no idea which one is correct, but this patch now
> uses regs[3].
>
> Signed-off-by: Eric Paris
For the x86 portions:
Acked-by: H. Peter Anvin
-hpa
--
Si
3fceafa59b2
> > Author: Thomas Gleixner
> > Date: Wed Jan 26 21:32:01 2011 +0100
> >
> > rwsem: Remove redundant asmregparm annotation
> >
> >Peter Zijlstra pointed out, that the only user of asmregparm (x86) is
> >compiling the kernel already with
On Wed, 2011-02-09 at 17:14 +1100, Benjamin Herrenschmidt wrote:
> On Mon, 2011-02-07 at 14:54 +0100, Peter Zijlstra wrote:
> > On Mon, 2011-02-07 at 10:26 +1100, Benjamin Herrenschmidt wrote:
> > > You missed:
> > >
> > > diff --git a/arch/powerpc/kern
On Mon, 2011-02-07 at 10:26 +1100, Benjamin Herrenschmidt wrote:
> You missed:
>
> diff --git a/arch/powerpc/kernel/smp.c b/arch/powerpc/kernel/smp.c
> index 9813605..467d122 100644
> --- a/arch/powerpc/kernel/smp.c
> +++ b/arch/powerpc/kernel/smp.c
> @@ -98,6 +98,7 @@ void smp_message_recv(int ms
On Mon, 2011-01-17 at 14:49 -0500, Mike Frysinger wrote:
> On Mon, Jan 17, 2011 at 06:07, Peter Zijlstra wrote:
> > Also, while reading through all this, I noticed the blackfin SMP code
> > looks to be broken, it simply discards any IPI when low on memory.
>
> not really. se
ds any IPI when low on memory.
Signed-off-by: Peter Zijlstra
---
arch/alpha/kernel/smp.c |1 +
arch/arm/kernel/smp.c |1 +
arch/blackfin/mach-common/smp.c |3 ++-
arch/cris/arch-v32/kernel/smp.c | 13 -
arch/ia64/kernel/irq_ia64.c |2 ++
arc
On Mon, 2011-01-17 at 12:31 +0100, Peter Zijlstra wrote:
> On Mon, 2011-01-17 at 11:26 +, Russell King - ARM Linux wrote:
> > Maybe remove the comment "everything is done on the interrupt return path"
> > as with this function call, that is no longer the case.
(Re
On Mon, 2011-01-17 at 11:26 +, Russell King - ARM Linux wrote:
> On Mon, Jan 17, 2011 at 12:07:13PM +0100, Peter Zijlstra wrote:
> > diff --git a/arch/alpha/kernel/smp.c b/arch/alpha/kernel/smp.c
> > index 42aa078..c4a570b 100644
> > --- a/arch/alpha/kernel/smp.c
> &
On Tue, 2011-01-18 at 07:31 +1100, Benjamin Herrenschmidt wrote:
>
> Beware of false positive, I've used "fake" reschedule IPIs in the past
> for other things (like kicking a CPU out of sleep state for unrelated
> reasons). Nothing that I know that is upstream today but some of that
> might come b
here except UML ?
> >
> > A small update:
> > It seems that CONFIG_NO_HZ is broken on UML. :-(
> >
> > CONFIG_NO_HZ + CONFIG_SLAB: works
> > CONFIG_NO_HZ + CONFIG_SLAB + your patch: broken
> > CONFIG_NO_HZ + CONFIG_SLUB: broken
> >
> > CONFI
On 06/14/2010 09:08 AM, Boaz Harrosh wrote:
> On 06/09/2010 09:29 PM, H. Peter Anvin wrote:
>> On 06/09/2010 01:46 AM, Geert Uytterhoeven wrote:
>>>
>>> Peter, are you happy with this?
>>> Although we still don't know why UML cannot grok it, it
at mistake, especially b/c I use ccache
> too since years and didn't experienced any fault so far.
I have certainly seen a number of cases where ccache doesn't pick up
sublte differences, for reasons unknown.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Cen
On 06/09/2010 01:46 AM, Geert Uytterhoeven wrote:
>
> Peter, are you happy with this?
> Although we still don't know why UML cannot grok it, it does fix a
> regression in post-2.6.34.
>
Yes, I'
here:
>
That looks better to me, although I'm still wondering why UML can't
stomach the register-saving tricks... it is not at all "obvious" why
that can't be done.
Pe
mentally
broken in UML tryingto track the upstream architecture, and this is just
a bandage.
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work
Sam Ravnborg wrote:
> On Fri, May 01, 2009 at 09:33:13AM -0700, H. Peter Anvin wrote:
>> Tim Abbott wrote:
>>> On Fri, 1 May 2009, Sam Ravnborg wrote:
>>>
>>>> On Thu, Apr 30, 2009 at 03:54:08PM -0400, Tim Abbott wrote:
>>>>> +#define __PAG
we probably need to ask the binutils people...
-hpa
--
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel. I don't speak on their behalf.
--
Register Now & Save for Velocity, the We
?
>
> I believe that is correct.
>
... but that doesn't mean it's the right thing to do.
It's better to be fully explicit when macroizing this kind of stuff.
This is part of why macroizing it is good: it means we end up with *one*
place that determines this stuff, not som
On Fri, 2009-03-20 at 10:43 +0100, Miklos Szeredi wrote:
> Ingo,
>
> I tested this one, and I think it makes sense in any case as an
> optimization. It should also be good for -stable kernels.
>
> Does it look OK?
The idea is good, but there is a risk of preemption latencies here. Some
code pat
On Thu, 2009-03-19 at 23:23 +0100, Miklos Szeredi wrote:
> From: Miklos Szeredi
>
> This patch fixes bug #12208.
>
> This turned out to be not a scheduler regression, but an already
> existing problem in ptrace being triggered by subtle scheduler
> changes.
>
> The problem is this:
>
> - task
On Fri, 2008-12-12 at 10:35 +0100, Miklos Szeredi wrote:
> When the UML boot gets to the userspace part it gets really really
> slow. It takes about 20 times the normal time to fully boot. CPU
> seems to be idle.
>
> Guest version doesn't matter. Host version 2.6.27 was OK, latest git
> is not
?
--
Regards,
Peter Teoh
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Sou
On Thu, Nov 6, 2008 at 9:20 PM, Samuel Korpi <[EMAIL PROTECTED]> wrote:
> On Thu, Nov 6, 2008 at 12:45 PM, Peter Teoh <[EMAIL PROTECTED]> wrote:
>> When I run gdb ./linux (my UML-compiled kernel):
>>
>> (gdb) run ubda=/mnt/hd1/download/FedoraCore5-x86-root_fs mem=1
n linux_main (argc=3, argv=0xbffb46f4) at
/mnt/hd0/download/linux-2.6-latest/arch/um/kernel/um_arch.c:277
#7 0x0804ad16 in main (argc=3, argv=0xbffb46f4, envp=0xbffb4704) at
/mnt/hd0/download/linux-2.6-latest/arch/um/os-Linux/main.c:150
--
rage size of 'trace' isn't known
/mnt/sda2/download/linux-2.6_latest/kernel/trace/trace.c:710: warning:
unused variable 'trace'
make[3]: *** [kernel/trace/trace.o] Error 1
make[2]: *** [kernel/trace] Error 2
make[1]: *** [kernel] Error 2
make: *** [sub-make] Error 2
On Thu, Oct 30, 2008 at 4:31 PM, Geert Uytterhoeven
<[EMAIL PROTECTED]> wrote:
> On Thu, 30 Oct 2008, Peter Teoh wrote:
>> While compiling the latest 2.6.28-rc2 (make linux ARCH=um O=uml):
>>
>> CC arch/um/kernel/syscall.o
>> /hdc1/download/2.6/linux26-
download/2.6/linux26-acer/kernel/trace/trace.c:659: error:
implicit declaration of function 'irqs_disabled_flags'
make[3]: *** [kernel/trace/trace.o] Error 1
make[2]: *** [kernel/trace] Error 2
make[1]: *** [kernel] Error 2
make: *** [sub-make] Error 2
The .config as per attached.
--
R
oid);
> #endif
>
> #else
> +#if __GNUC__ == 4
> +# define __used__attribute__((__used__))
> +#endif
> +#endif
> +
> +#else
> #include
> #endif
> /* These are for everybody (although not all archs will actually
>
--
Regards,
Peter Teoh
The problem lies in the function:
static inline long do_syscall_stub(struct mm_id * mm_idp, void **addr)
{
int n, i;
long ret, offset;
unsigned long * data;
unsigned long * syscall;
int err, pid = mm_idp->u.pid;
if (proc_mm)
/* FIXME
dler+0x57/0x7e
0fc5cffc: [<>] 0x0
Terminated
Seems similar to that of:
http://www.gossamer-threads.com/lists/linux/kernel/944646
Any fix yet?
--
Regards,
Peter Teoh
-
This SF.Net email is sponsored by the M
Sorry for my mistake - I just read the source code for kqemu and they
do compile for x86_64, so the 64bit host version is supported.
My mistake.
On Mon, Jun 23, 2008 at 11:34 AM, Iustin Pop <[EMAIL PROTECTED]> wrote:
> On Mon, Jun 23, 2008 at 10:05:37AM +0800, Peter Teoh wrote:
>&g
QEMU running on 64bit host is still not available yet, although it can
emulate 64bit kernel. Other than UML, is there any other
alternatives that I can try to use, to trace through the early booting
up scenario in 64bit Linux Kernel?
Thank you for the reply.
--
Regards,
Peter Teoh
On 5/20/08, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Sun, May 18, 2008 at 11:30:13PM +0800, Peter Teoh wrote:
> > Thank you Jeff.what distros are u on? I think my machine(s) may
> > have some problem...or possibly the distros itself...
> > following your steps
ad_struct' has no member named 'mode'
make[2]: *** [arch/um/kernel/smp.o] Error 1
make[1]: *** [arch/um/kernel] Error 2
make: *** [sub-make] Error 2
What is happening, appreciate very much for any help rendered :-).
--
Regards,
Peter Teoh
-
On Sat, May 3, 2008 at 3:52 AM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Sat, May 03, 2008 at 01:49:40AM +0800, Peter Teoh wrote:
> > This is what I have done, not sure if anything wrong:
> >
> > a. mkdir obj;make oldconfig ARCH=um O=obj
> >
> > This
Not sure why, but your current instructions works!!!
On 5/2/08, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Fri, May 02, 2008 at 12:18:34AM +0800, Peter Teoh wrote:
> > In case if anyone is wondering what this line 107 means in the
> arch/um/Makefile:
> >
> &g
In case if anyone is wondering what this line 107 means in the arch/um/Makefile:
104 ifneq ($(KBUILD_SRC),)
105 $(shell mkdir -p $(ARCH_DIR) && ln -fsn
$(srctree)/$(ARCH_DIR)/Kconfig.$(SUBARCH) $(ARCH_DIR)/Kconfig.arch)
106 else
107 $(shell cd $(ARCH_DIR) && ln -sf Kconfig.$(SUBARC
On Thu, May 1, 2008 at 11:15 PM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, May 01, 2008 at 07:35:32AM +0800, Peter Teoh wrote:
> > /mnt/hd0/download/linux-2.6-latest>make -v
> > GNU Make 3.81
> > Copyright (C) 2006 Free Software Foundation, Inc.
> > T
On Thu, May 1, 2008 at 2:47 AM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Thu, May 01, 2008 at 12:24:21AM +0800, Peter Teoh wrote:
> > Mine is same:
> >
> > md5sum arch/um/Makefile
> > 9088cdab1c0b725568e8f269636dc6df arch/um/Makefile
>
> What make are
On Tue, Apr 29, 2008 at 11:37 PM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 08:02:06PM +0800, Peter Teoh wrote:
> > ErhI don't understand, is there something specifically called
> > "UML" with a version to it?
>
> What I m
n Wed, Apr 30, 2008 at 1:29 AM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Wed, Apr 30, 2008 at 12:15:26AM +0800, Peter Teoh wrote:
> > > Looks right to me.
> > >
> > > I'm suspecting that Makefile is mangled somehow. Does git-diff show
> > >
On 4/29/08, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Apr 29, 2008 at 08:02:06PM +0800, Peter Teoh wrote:
> > ErhI don't understand, is there something specifically called
> > "UML" with a version to it?
>
>
> What I meant was the kernel
On Tue, Apr 29, 2008 at 2:55 AM, Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Mon, Apr 28, 2008 at 11:53:48PM +0800, Peter Teoh wrote:
> > What is the following errors:
> >
> > make defconfig ARCH=um
> > /sda4/download/linux_linus/linux-2.6/arch/um/Makefile:100:
da4/download/linux_linus/linux-2.6>cat include/config/kernel.release
2.6.25-rc9
--
Regards,
Peter Teoh
-
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There
Andi Kleen wrote:
> On Wed, Jan 09, 2008 at 09:14:04PM -0500, Jeff Dike wrote:
>> On Wed, Jan 09, 2008 at 10:50:48PM +0100, Miklos Szeredi wrote:
FASTCALL is useless and should not make a difference. It enables
regparm on specific functions, but that should not make a difference
if i
1 - 100 of 131 matches
Mail list logo
