* Linus Torvalds wrote:
> On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
> wrote:
> >
> > If the only immediate problem is the code generation size, then Andy
> > already had a (simpler) hack-around:
> >
> > #undef CONFIG_OPTIMIZE_INLINING
> > #undef CONFIG_X86_PPRO_FENCE
> >
> > in
On 03/10/2014 02:29 PM, stef...@seibold.net wrote:
>
> Do you except a complete new patch set or an incremental patch based on the
> current patch set?
>
An incremental patch is probably easier.
-hpa
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
On 03/10/2014 02:29 PM, stef...@seibold.net wrote:
Do you except a complete new patch set or an incremental patch based on the
current patch set?
An incremental patch is probably easier.
-hpa
--
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of
* Linus Torvalds torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
If the only immediate problem is the code generation size, then Andy
already had a (simpler) hack-around:
#undef CONFIG_OPTIMIZE_INLINING
On 03/10/2014 02:39 PM, Linus Torvalds wrote:
> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>>
>> This was discovered by me.
>
> Sorry for the misattribution.
>
>> But this is not a real solution, at least when vcpu function support
>> will be added, then the code size will exceed the page size.
On 03/10/2014 02:51 PM, Dave Jones wrote:
>
> Even when it worked, it was only a small performance increase anyway,
>
If it is performance rather then correctness, then let's kill it now.
I'd love to push that patchset already for 3.15, anyone want to write it
up (I'm on a trip)... otherwise
On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski wrote:
> On Mon, Mar 10, 2014 at 2:53 PM, wrote:
>> Zitat von Linus Torvalds :
>>
>>> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
This was discovered by me.
>>>
>>>
>>> Sorry for the misattribution.
>>>
But this is not a real
On Mon, Mar 10, 2014 at 2:53 PM, wrote:
> Zitat von Linus Torvalds :
>
>> On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>>>
>>>
>>> This was discovered by me.
>>
>>
>> Sorry for the misattribution.
>>
>>> But this is not a real solution, at least when vcpu function support
>>> will be added, then
Zitat von Linus Torvalds :
On Mon, Mar 10, 2014 at 2:25 PM, wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed the page size. Reserving
two pages for the VDSO
On Mon, Mar 10, 2014 at 02:20:34PM -0700, Linus Torvalds wrote:
> I also suspect we should get rid of CONFIG_X86_OOSTORE, or at least
> limit it to !SMP - I don't think anybody ever made SMP systems with
> those IDT/Centaur Winchip chips in them.
Given the number of people who ever used that
On Mon, Mar 10, 2014 at 2:20 PM, Linus Torvalds
wrote:
> On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
> wrote:
>>
>> If the only immediate problem is the code generation size, then Andy
>> already had a (simpler) hack-around:
>>
>> #undef CONFIG_OPTIMIZE_INLINING
>> #undef
On Mon, Mar 10, 2014 at 2:25 PM, wrote:
>
> This was discovered by me.
Sorry for the misattribution.
> But this is not a real solution, at least when vcpu function support
> will be added, then the code size will exceed the page size. Reserving
> two pages for the VDSO is a good option.
Quite
Zitat von "H. Peter Anvin" :
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
What is now the next step? Kick out the compat VDSO? Or should i
implement the dual VDSO. And what is now the preferred way to map the
VDSO into the user space? Using install_special_mapping() or map it
beyond the
Zitat von Linus Torvalds :
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin wrote:
The quick way to get something working is simply to reserve more than
one page (two should presumably be enough) in the fixmap and adjust the
link address of the VDSO accordingly. This is not where we want to
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
wrote:
>
> If the only immediate problem is the code generation size, then Andy
> already had a (simpler) hack-around:
>
> #undef CONFIG_OPTIMIZE_INLINING
> #undef CONFIG_X86_PPRO_FENCE
>
> in vclock_gettime.c
Btw, we should seriously consider
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin wrote:
>
> The quick way to get something working is simply to reserve more than
> one page (two should presumably be enough) in the fixmap and adjust the
> link address of the VDSO accordingly. This is not where we want to go
> in the long term,
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
>
> What is now the next step? Kick out the compat VDSO? Or should i
> implement the dual VDSO. And what is now the preferred way to map the
> VDSO into the user space? Using install_special_mapping() or map it
> beyond the user stack?
>
> The is
Am Montag, den 10.03.2014, 10:12 -0700 schrieb Andy Lutomirski:
> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
> wrote:
> >
> > On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
> >>
> >> I have mentioned in the past wanting to move the fixmap to the low part
> >> of the kernel space, because
On Sun, Mar 09, 2014 at 05:00:31PM -0700, H. Peter Anvin wrote:
> On 03/09/2014 12:08 AM, Stefani Seibold wrote:
> >
> > This was not addressed to you, it was addressed to the x86 intel kernel
> > developers to do more testing, since this piece of code has so many side
> > effects. I apologizes
On Mon, Mar 10, 2014 at 10:58 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
>>>
>>> Hint: where is your RIP? Where is the RIP of other processes?
>>>
>>
>> Whoa there, I'm not suggesting anything nearly that crazy :)
>>
>> I'm suggesting changing out the vvar page
On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
>>
>> Hint: where is your RIP? Where is the RIP of other processes?
>>
>
> Whoa there, I'm not suggesting anything nearly that crazy :)
>
> I'm suggesting changing out the vvar page *for that process*, which is
> not executable. The actual vdso
On Mon, Mar 10, 2014 at 10:48 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>>>
>>> Yes, we'd have to switch the vdso to using syscall access. Doing that
>>> from inside a system call is... "interesting".
>>
>> It's a little less interesting if it just involves
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>
> It might be nice in general for there to be a /dev/vdso and for the
> vdso to literally be a mapping of that device node. I bet that CRIU
> would appreciate this. (The mmap flags would be a little odd, since
> different pages have different
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
>>
>> Yes, we'd have to switch the vdso to using syscall access. Doing that
>> from inside a system call is... "interesting".
>
> It's a little less interesting if it just involves changing a vma.
> It's still tricky, though -- would each struct mm
On Mon, Mar 10, 2014 at 10:38 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
>>>
For 64-bit, this is an entirely different story. The vsyscall page is
stuck in the fixmap forever, although I want to add a way for
userspace to opt out. The vvar page,
On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
>>
>>> For 64-bit, this is an entirely different story. The vsyscall page is
>>> stuck in the fixmap forever, although I want to add a way for
>>> userspace to opt out. The vvar page, hpet, etc could move into vmas,
>>> though. I kind of want to do
On Mon, Mar 10, 2014 at 10:24 AM, H. Peter Anvin wrote:
> On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
>> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
>> wrote:
>>>
>>> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
I have mentioned in the past wanting to move the fixmap to the
On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
> On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
> wrote:
>>
>> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
>>>
>>> I have mentioned in the past wanting to move the fixmap to the low part
>>> of the kernel space, because the top isn't really
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
wrote:
>
> On Mar 10, 2014 8:01 AM, "H. Peter Anvin" wrote:
>>
>> I have mentioned in the past wanting to move the fixmap to the low part
>> of the kernel space, because the top isn't really fixed...
>
> How about the high part of the user address
On 03/09/2014 09:46 PM, Andy Lutomirski wrote:
> On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski wrote:
>> (Of course, I haven't the faintest idea what l_addr in glibc means.
>> If there was a way to arrange for l_addr to be zero, then maybe none
>> of this would matter. Hmm, I wonder if just
On 03/09/2014 09:46 PM, Andy Lutomirski wrote:
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski l...@amacapital.net wrote:
(Of course, I haven't the faintest idea what l_addr in glibc means.
If there was a way to arrange for l_addr to be zero, then maybe none
of this would matter. Hmm, I
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have mentioned in the past wanting to move the fixmap to the low part
of the kernel space, because the top isn't really fixed...
How
On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have mentioned in the past wanting to move the fixmap to the low part
of the kernel
On Mon, Mar 10, 2014 at 10:24 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:12 AM, Andy Lutomirski wrote:
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have
On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
For 64-bit, this is an entirely different story. The vsyscall page is
stuck in the fixmap forever, although I want to add a way for
userspace to opt out. The vvar page, hpet, etc could move into vmas,
though. I kind of want to do that anyway
On Mon, Mar 10, 2014 at 10:38 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:31 AM, Andy Lutomirski wrote:
For 64-bit, this is an entirely different story. The vsyscall page is
stuck in the fixmap forever, although I want to add a way for
userspace to opt out. The vvar
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
Yes, we'd have to switch the vdso to using syscall access. Doing that
from inside a system call is... interesting.
It's a little less interesting if it just involves changing a vma.
It's still tricky, though -- would each struct mm have its
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
It might be nice in general for there to be a /dev/vdso and for the
vdso to literally be a mapping of that device node. I bet that CRIU
would appreciate this. (The mmap flags would be a little odd, since
different pages have different
On Mon, Mar 10, 2014 at 10:48 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:46 AM, Andy Lutomirski wrote:
Yes, we'd have to switch the vdso to using syscall access. Doing that
from inside a system call is... interesting.
It's a little less interesting if it just involves
On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
Hint: where is your RIP? Where is the RIP of other processes?
Whoa there, I'm not suggesting anything nearly that crazy :)
I'm suggesting changing out the vvar page *for that process*, which is
not executable. The actual vdso code already
On Mon, Mar 10, 2014 at 10:58 AM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/10/2014 10:52 AM, Andy Lutomirski wrote:
Hint: where is your RIP? Where is the RIP of other processes?
Whoa there, I'm not suggesting anything nearly that crazy :)
I'm suggesting changing out the vvar page
On Sun, Mar 09, 2014 at 05:00:31PM -0700, H. Peter Anvin wrote:
On 03/09/2014 12:08 AM, Stefani Seibold wrote:
This was not addressed to you, it was addressed to the x86 intel kernel
developers to do more testing, since this piece of code has so many side
effects. I apologizes this miss
Am Montag, den 10.03.2014, 10:12 -0700 schrieb Andy Lutomirski:
On Mon, Mar 10, 2014 at 8:11 AM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mar 10, 2014 8:01 AM, H. Peter Anvin h...@linux.intel.com wrote:
I have mentioned in the past wanting to move the fixmap to the low part
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
What is now the next step? Kick out the compat VDSO? Or should i
implement the dual VDSO. And what is now the preferred way to map the
VDSO into the user space? Using install_special_mapping() or map it
beyond the user stack?
The is easiest
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin h...@linux.intel.com wrote:
The quick way to get something working is simply to reserve more than
one page (two should presumably be enough) in the fixmap and adjust the
link address of the VDSO accordingly. This is not where we want to go
in
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
If the only immediate problem is the code generation size, then Andy
already had a (simpler) hack-around:
#undef CONFIG_OPTIMIZE_INLINING
#undef CONFIG_X86_PPRO_FENCE
in vclock_gettime.c
Btw, we
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 1:06 PM, H. Peter Anvin h...@linux.intel.com wrote:
The quick way to get something working is simply to reserve more than
one page (two should presumably be enough) in the fixmap and adjust the
link address of
Zitat von H. Peter Anvin h...@linux.intel.com:
On 03/10/2014 01:03 PM, Stefani Seibold wrote:
What is now the next step? Kick out the compat VDSO? Or should i
implement the dual VDSO. And what is now the preferred way to map the
VDSO into the user space? Using install_special_mapping() or
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed the page size. Reserving
two pages for the VDSO is a good
On Mon, Mar 10, 2014 at 2:20 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
On Mon, Mar 10, 2014 at 1:19 PM, Linus Torvalds
torva...@linux-foundation.org wrote:
If the only immediate problem is the code generation size, then Andy
already had a (simpler) hack-around:
#undef
On Mon, Mar 10, 2014 at 02:20:34PM -0700, Linus Torvalds wrote:
I also suspect we should get rid of CONFIG_X86_OOSTORE, or at least
limit it to !SMP - I don't think anybody ever made SMP systems with
those IDT/Centaur Winchip chips in them.
Given the number of people who ever used that
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed
On Mon, Mar 10, 2014 at 2:53 PM, stef...@seibold.net wrote:
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu
On Mon, Mar 10, 2014 at 3:03 PM, Andy Lutomirski l...@amacapital.net wrote:
On Mon, Mar 10, 2014 at 2:53 PM, stef...@seibold.net wrote:
Zitat von Linus Torvalds torva...@linux-foundation.org:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry
On 03/10/2014 02:51 PM, Dave Jones wrote:
Even when it worked, it was only a small performance increase anyway,
If it is performance rather then correctness, then let's kill it now.
I'd love to push that patchset already for 3.15, anyone want to write it
up (I'm on a trip)... otherwise I'll
On 03/10/2014 02:39 PM, Linus Torvalds wrote:
On Mon, Mar 10, 2014 at 2:25 PM, stef...@seibold.net wrote:
This was discovered by me.
Sorry for the misattribution.
But this is not a real solution, at least when vcpu function support
will be added, then the code size will exceed the page
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski wrote:
> (Of course, I haven't the faintest idea what l_addr in glibc means.
> If there was a way to arrange for l_addr to be zero, then maybe none
> of this would matter. Hmm, I wonder if just not relocating the vdso
> at all would have the
On Sun, Mar 9, 2014 at 5:16 PM, H. Peter Anvin wrote:
> On 03/09/2014 12:47 AM, Stefani Seibold wrote:
>>
>> But let me ask an other question: Is the compat mode still needed
>> anymore?
>>
>> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
>> the __FIXADDR_TOP, there is
On 03/09/2014 12:47 AM, Stefani Seibold wrote:
>
> But let me ask an other question: Is the compat mode still needed
> anymore?
>
> Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
> the __FIXADDR_TOP, there is no fix place for the VDSO page. Also in the
> 32 bit emulation
On 03/09/2014 12:08 AM, Stefani Seibold wrote:
>
> This was not addressed to you, it was addressed to the x86 intel kernel
> developers to do more testing, since this piece of code has so many side
> effects. I apologizes this miss understanding.
>
I think you're misunderstanding.
We cannot
Am Freitag, den 07.03.2014, 15:07 -0800 schrieb Andy Lutomirski:
> On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold wrote:
> >
> > Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> >> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold
> >> wrote:
> >> > Hi Fengguang,
> >> >
> >> >
Am Samstag, den 08.03.2014, 07:44 +0800 schrieb Fengguang Wu:
> Hi Stefani,
>
> > So i tried my best, but without support it is impossible to find all
> > issues. But mostly what i get was bureaucracy afflictions
> >
> > I complied, but now it is time to help finding the issues. And not only
> >
Am Samstag, den 08.03.2014, 07:44 +0800 schrieb Fengguang Wu:
Hi Stefani,
So i tried my best, but without support it is impossible to find all
issues. But mostly what i get was bureaucracy afflictions
I complied, but now it is time to help finding the issues. And not only
do a
Am Freitag, den 07.03.2014, 15:07 -0800 schrieb Andy Lutomirski:
On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold stef...@seibold.net wrote:
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net
wrote:
Hi
On 03/09/2014 12:08 AM, Stefani Seibold wrote:
This was not addressed to you, it was addressed to the x86 intel kernel
developers to do more testing, since this piece of code has so many side
effects. I apologizes this miss understanding.
I think you're misunderstanding.
We cannot debug
On 03/09/2014 12:47 AM, Stefani Seibold wrote:
But let me ask an other question: Is the compat mode still needed
anymore?
Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
the __FIXADDR_TOP, there is no fix place for the VDSO page. Also in the
32 bit emulation layer
On Sun, Mar 9, 2014 at 5:16 PM, H. Peter Anvin h...@linux.intel.com wrote:
On 03/09/2014 12:47 AM, Stefani Seibold wrote:
But let me ask an other question: Is the compat mode still needed
anymore?
Since Lguest, XEN, OPLC and the reservetop kernel parameter will change
the __FIXADDR_TOP,
On Sun, Mar 9, 2014 at 8:18 PM, Andy Lutomirski l...@amacapital.net wrote:
(Of course, I haven't the faintest idea what l_addr in glibc means.
If there was a way to arrange for l_addr to be zero, then maybe none
of this would matter. Hmm, I wonder if just not relocating the vdso
at all would
Hi Stefani,
> So i tried my best, but without support it is impossible to find all
> issues. But mostly what i get was bureaucracy afflictions
>
> I complied, but now it is time to help finding the issues. And not only
> do a complain, sit back and wait.
I feel sorry if that's what you
On 03/07/2014 08:06 AM, Stefani Seibold wrote:
>>
>> wfg@bee /tmp% git clone --reference /c/linux
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
>
> As i wrote i already cloned the tip tree!!
>
> But i cannot see the changeset, there is also no VDSO changes set in the
> git
On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold wrote:
>
> Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
>> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
>> > Hi Fengguang,
>> >
>> > i have build a kernel with the config, but my kvm is unable to start it.
>> > I will
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
> On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
> > Hi Fengguang,
> >
> > i have build a kernel with the config, but my kvm is unable to start it.
> > I will try to find a way to test your kernek config.
> >
> > One thing
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold wrote:
> Hi Fengguang,
>
> i have build a kernel with the config, but my kvm is unable to start it.
> I will try to find a way to test your kernek config.
>
> One thing is the crash point:
>
> The function sysenter_setup was modified by Andy, maybe
Am Freitag, den 07.03.2014, 18:21 +0800 schrieb Fengguang Wu:
> Hi Stefani,
>
> On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
> > Hi Fengguang,
> >
> > did you test the config i had sent to you?
> >
> > My test was all done with current 3.14-rc tree. And with this i have no
>
Hi Stefani,
On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
> Hi Fengguang,
>
> did you test the config i had sent to you?
>
> My test was all done with current 3.14-rc tree. And with this i have no
> problem.
The regression is found on commit
Hi Fengguang,
did you test the config i had sent to you?
My test was all done with current 3.14-rc tree. And with this i have no
problem.
I just cloned the tip tree and i figured out that the patch was dropped
again (BTW: git log does not show that it was ever applied).
Okay, that's enough
Hi Stefani,
On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
> Hi Fengguang,
>
> i was now able to bring up the kernel on my KVM with some minior
> changes. I kick out the PARIDE, switched to IDE and activated the VT
> support. With this modifications the kernel boot and i get no
Hi Stefani,
On Fri, Mar 07, 2014 at 09:47:14AM +0100, Stefani Seibold wrote:
Hi Fengguang,
i was now able to bring up the kernel on my KVM with some minior
changes. I kick out the PARIDE, switched to IDE and activated the VT
support. With this modifications the kernel boot and i get no BUG,
Hi Fengguang,
did you test the config i had sent to you?
My test was all done with current 3.14-rc tree. And with this i have no
problem.
I just cloned the tip tree and i figured out that the patch was dropped
again (BTW: git log does not show that it was ever applied).
Okay, that's enough
Hi Stefani,
On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
Hi Fengguang,
did you test the config i had sent to you?
My test was all done with current 3.14-rc tree. And with this i have no
problem.
The regression is found on commit
Am Freitag, den 07.03.2014, 18:21 +0800 schrieb Fengguang Wu:
Hi Stefani,
On Fri, Mar 07, 2014 at 10:57:28AM +0100, Stefani Seibold wrote:
Hi Fengguang,
did you test the config i had sent to you?
My test was all done with current 3.14-rc tree. And with this i have no
problem.
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net wrote:
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One thing is the crash point:
The function sysenter_setup was modified by
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net wrote:
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One
On Fri, Mar 7, 2014 at 1:53 PM, Stefani Seibold stef...@seibold.net wrote:
Am Freitag, den 07.03.2014, 10:56 -0800 schrieb Andy Lutomirski:
On Thu, Mar 6, 2014 at 11:21 PM, Stefani Seibold stef...@seibold.net wrote:
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable
On 03/07/2014 08:06 AM, Stefani Seibold wrote:
wfg@bee /tmp% git clone --reference /c/linux
git://git.kernel.org/pub/scm/linux/kernel/git/tip/tip.git
As i wrote i already cloned the tip tree!!
But i cannot see the changeset, there is also no VDSO changes set in the
git log.
It
Hi Stefani,
So i tried my best, but without support it is impossible to find all
issues. But mostly what i get was bureaucracy afflictions
I complied, but now it is time to help finding the issues. And not only
do a complain, sit back and wait.
I feel sorry if that's what you perceived.
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One thing is the crash point:
The function sysenter_setup was modified by Andy, maybe he has an idea
what fails.
- Stefani
Am Freitag, den 07.03.2014,
Hi Fengguang,
i have build a kernel with the config, but my kvm is unable to start it.
I will try to find a way to test your kernek config.
One thing is the crash point:
The function sysenter_setup was modified by Andy, maybe he has an idea
what fails.
- Stefani
Am Freitag, den 07.03.2014,
88 matches
Mail list logo
