On Wed, Jan 21, 2015, at 19:04, Borislav Petkov wrote:
> On Wed, Jan 21, 2015 at 05:20:09PM +0100, Alexander van Heukelum wrote:
> > On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
> > > On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> > > wrote:
> &
On Wed, Jan 21, 2015, at 14:44, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> wrote:
> > KERNEL_STACK_OFFSET is the offset from the top of the kernel stack
> > page to the value of the kernel_stack percpu variable. This patch
> > cha
On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
> wrote:
> > The macro THREAD_INFO(reg,offset) is used in assembly to compute the
> > offset between the user ptregs and the thread_info struct. Change
> > th
On Wed, Jan 21, 2015, at 14:26, Denys Vlasenko wrote:
> On Sun, Jan 18, 2015 at 4:47 PM, Alexander van Heukelum
> wrote:
> > On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
> >> Hi,
> >>
> >> btw, you might wanna sync with Denys who's doing cle
On Wed, Jan 21, 2015, at 19:04, Borislav Petkov wrote:
On Wed, Jan 21, 2015 at 05:20:09PM +0100, Alexander van Heukelum wrote:
On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
heuke...@fastmail.fm wrote:
The macro
On Wed, Jan 21, 2015, at 14:40, Denys Vlasenko wrote:
On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
heuke...@fastmail.fm wrote:
The macro THREAD_INFO(reg,offset) is used in assembly to compute the
offset between the user ptregs and the thread_info struct. Change
the macro
On Wed, Jan 21, 2015, at 14:26, Denys Vlasenko wrote:
On Sun, Jan 18, 2015 at 4:47 PM, Alexander van Heukelum
heuke...@fastmail.fm wrote:
On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
Hi,
btw, you might wanna sync with Denys who's doing cleanups in that area too:
https
On Wed, Jan 21, 2015, at 14:44, Denys Vlasenko wrote:
On Sun, Jan 18, 2015 at 12:45 PM, Alexander van Heukelum
heuke...@fastmail.fm wrote:
KERNEL_STACK_OFFSET is the offset from the top of the kernel stack
page to the value of the kernel_stack percpu variable. This patch
changes
On Sun, Jan 18, 2015, at 17:38, Andy Lutomirski wrote:
> On Sun, Jan 18, 2015 at 3:45 AM, Alexander van Heukelum
> wrote:
> > Create an IRET-compatible top of stack at syscall entry and use this
> > information to return to user mode in the sysret path. This re
On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
> Hi,
>
> btw, you might wanna sync with Denys who's doing cleanups in that area too:
>
> https://lkml.kernel.org/r/1421272101-16847-1-git-send-email-dvlas...@redhat.com
>
> and touching some of the stuff you're changing too.
Thanks. FWIW,
The macro THREAD_INFO(reg,offset) is used in assembly to compute the
offset between the user ptregs and the thread_info struct. Change
the macro and all its uses so that offset is given as the current
top of stack in the pt_regs frame. The generated code is identical.
Signed-off-by: Alexander van
multiple of 4 bytes, the minimal stack
alignment.
Signed-off-by: Alexander van Heukelum
---
arch/x86/include/asm/processor.h | 32 +++-
arch/x86/include/asm/thread_info.h | 10 ++
arch/x86/kernel/entry_32.S | 5 +++--
3 files changed, 16 insertions(+), 3
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum
---
arch/x86/kernel/entry_64.S | 75
to the automatic stack alignment
of interrupts, traps, and exceptions on x86_64.
Also change task_pt_regs to be independant of the thread's current
sp0 setting, like i386, and use it to initialize thread.sp0 in
copy_thread.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32entry.S
of 22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running on my
laptop.
Greetings,
Alexander
Alexander van Heukelum (4):
x86_64: cleanup THREAD_INFO(reg,offset) macro
x86_64: embrace KERNEL_STACK_OFFSET
i386: clean up KERNEL_STACK_OFFSET
x86_64, entry: Create
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch/x86/kernel/entry_64.S
to the automatic stack alignment
of interrupts, traps, and exceptions on x86_64.
Also change task_pt_regs to be independant of the thread's current
sp0 setting, like i386, and use it to initialize thread.sp0 in
copy_thread.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch/x86/ia32
of 22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running on my
laptop.
Greetings,
Alexander
Alexander van Heukelum (4):
x86_64: cleanup THREAD_INFO(reg,offset) macro
x86_64: embrace KERNEL_STACK_OFFSET
i386: clean up KERNEL_STACK_OFFSET
x86_64, entry: Create
The macro THREAD_INFO(reg,offset) is used in assembly to compute the
offset between the user ptregs and the thread_info struct. Change
the macro and all its uses so that offset is given as the current
top of stack in the pt_regs frame. The generated code is identical.
Signed-off-by: Alexander van
, the minimal stack
alignment.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch/x86/include/asm/processor.h | 32 +++-
arch/x86/include/asm/thread_info.h | 10 ++
arch/x86/kernel/entry_32.S | 5 +++--
3 files changed, 16 insertions(+), 31
On Sun, Jan 18, 2015, at 13:05, Borislav Petkov wrote:
Hi,
btw, you might wanna sync with Denys who's doing cleanups in that area too:
https://lkml.kernel.org/r/1421272101-16847-1-git-send-email-dvlas...@redhat.com
and touching some of the stuff you're changing too.
Thanks. FWIW, the
On Sun, Jan 18, 2015, at 17:38, Andy Lutomirski wrote:
On Sun, Jan 18, 2015 at 3:45 AM, Alexander van Heukelum
heuke...@fastmail.fm wrote:
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum
---
arch/x86/kernel/entry_64.S | 77
The syscall and sysenter code use KERNEL_STACK_OFFSET to set the
initial stack pointer a bit below the top of the kernel stack page.
Stop doing that.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32entry.S | 4 ++--
arch/x86/include/asm/thread_info.h | 6 ++
arch/x86
one on top of 22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running happily
on my laptop. I didn't try any benchmarking, though.
Greetings,
Alexander
Alexander van Heukelum (3):
x86_64: remove KERNEL_STACK_OFFSET from THREAD_INFO macro
x86_64: don't use KERNEL_STACK_OFFSET f
In the macro THREAD_INFO(reg,offset), the offset is relative to
KERNEL_STACK_OFFSET. Change the macro and all its uses so that
offset is given as the current top of stack in the pt_regs frame.
The generated code is identical.
Signed-off-by: Alexander van Heukelum
---
arch/x86/ia32/ia32entry.S
Create an IRET-compatible top of stack at syscall entry and use this
information to return to user mode in the sysret path. This removes
the need for the FIXUP_TOP_OF_STACK and RESTORE_TOP_OF_STACK macros.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch/x86/kernel/entry_64.S
The syscall and sysenter code use KERNEL_STACK_OFFSET to set the
initial stack pointer a bit below the top of the kernel stack page.
Stop doing that.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch/x86/ia32/ia32entry.S | 4 ++--
arch/x86/include/asm/thread_info.h | 6
of 22f2aa4a0361707a5cfb1de9d45260b39965dead
(x86/entry-devel in your tree) and this kernel is now running happily
on my laptop. I didn't try any benchmarking, though.
Greetings,
Alexander
Alexander van Heukelum (3):
x86_64: remove KERNEL_STACK_OFFSET from THREAD_INFO macro
x86_64: don't use KERNEL_STACK_OFFSET for syscall
In the macro THREAD_INFO(reg,offset), the offset is relative to
KERNEL_STACK_OFFSET. Change the macro and all its uses so that
offset is given as the current top of stack in the pt_regs frame.
The generated code is identical.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
arch
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
> >>> d. Trampoline in user space
> >>>
> >>> A return to the vdso with values set up in registers r8-r15 would enable
> >>> a trampoline in user space. Unfortunately there is no way
> >>> to do a far JMP entirely with register state so this
Hi,
> This is a writeup I did to a select audience before this was public:
I'ld like to add an option d.2. for your consideration. Can you think of a
fundamental problem with it?
Greetings,
Alexander
> > Some workarounds I have considered:
> >
> > a. Using paging in a similar way to the
Hi,
This is a writeup I did to a select audience before this was public:
I'ld like to add an option d.2. for your consideration. Can you think of a
fundamental problem with it?
Greetings,
Alexander
Some workarounds I have considered:
a. Using paging in a similar way to the 32-bit
On Sun, Apr 13, 2014, at 1:31, H. Peter Anvin wrote:
d. Trampoline in user space
A return to the vdso with values set up in registers r8-r15 would enable
a trampoline in user space. Unfortunately there is no way
to do a far JMP entirely with register state so this would require
; me that a change to dump_stack_32 I made may be wrong if current can
> be NULL (it can't), as there was a check for it by assigning task to
> current, and then checking if task is NULL.
>
> Reported-by: Dan Carpenter
> Cc: Jesper Juhl
> Cc: Alexander van Heukelum
Great archeology ;)
Acke
, and then checking if task is NULL.
Reported-by: Dan Carpenter dan.carpen...@oracle.com
Cc: Jesper Juhl jesper.j...@gmail.com
Cc: Alexander van Heukelum heuke...@fastmail.fm
Great archeology ;)
Acked-by: Alexander van Heukelum heuke...@fastmail.fm
Signed-off-by: Steven Rostedt rost...@goodmis.org
My Acer 8510TZ stops displaying anything when X starts with Linus' current
tree. I bisected it down to commit ee1452d74584.
This patch reverts commit ee1452d74584.
After the revert, everything works as before.
Signed-off-by: Alexander van Heukelum
---
drivers/gpu/drm/i915/intel_display.c
Hi all,
On my Acer 8510TZ, the backlight now turns off completely as soon as X
starts. I bisected the problem to ee1452d74584 "drm/i915: assume all GM45
Acer laptops use inverted backlight PWM", which says:
There is plenty of evidence suggesting all of the GM45 based Acer
laptops
My Acer 8510TZ stops displaying anything when X starts with Linus' current
tree. I bisected it down to commit ee1452d74584.
This patch reverts commit ee1452d74584.
After the revert, everything works as before.
Signed-off-by: Alexander van Heukelum heuke...@fastmail.fm
---
drivers/gpu/drm/i915
Hi all,
On my Acer 8510TZ, the backlight now turns off completely as soon as X
starts. I bisected the problem to ee1452d74584 drm/i915: assume all GM45
Acer laptops use inverted backlight PWM, which says:
There is plenty of evidence suggesting all of the GM45 based Acer
laptops
On Fri, Jun 7, 2013, at 8:01, Alexandre Courbot wrote:
> A framebuffer of this format is set up by SHIELD's bootloader. This
> allows us to use it as a framebuffer console.
>
> Signed-off-by: Alexandre Courbot
> Acked-by: Olof Johansson
> ---
> Changes from v1:
> - Added description to motivate
On Fri, Jun 7, 2013, at 8:01, Alexandre Courbot wrote:
A framebuffer of this format is set up by SHIELD's bootloader. This
allows us to use it as a framebuffer console.
Signed-off-by: Alexandre Courbot acour...@nvidia.com
Acked-by: Olof Johansson o...@lixom.net
---
Changes from v1:
-
On Fri, Apr 12, 2013, at 22:15, Hans de Bruin wrote:
> On 03/27/2013 10:18 PM, Alexander van Heukelum wrote:
> > On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
> >> On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> >>> Hi Al,
> >>>
On Fri, Apr 12, 2013, at 22:15, Hans de Bruin wrote:
On 03/27/2013 10:18 PM, Alexander van Heukelum wrote:
On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
Hi Al,
Hans de Bruin found a regression due to one of your
On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
> On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
> > Hi Al,
> >
> > Hans de Bruin found a regression due to one of your changes. I asked him to
> > test a fix and he reported back that it wo
17 00:00:00 2001
From: Alexander van Heukelum
Date: Tue, 26 Mar 2013 21:57:43 +0100
Subject: [PATCH] x86, vm86: fix VM86 syscalls: use asmlinkage calling convention
Commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
got rid of the pt_regs stub for sys_vm86old and sys_vm86
17 00:00:00 2001
From: Alexander van Heukelum heuke...@fastmail.fm
Date: Tue, 26 Mar 2013 21:57:43 +0100
Subject: [PATCH] x86, vm86: fix VM86 syscalls: use asmlinkage calling convention
Commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
got rid of the pt_regs stub
On Wed, Mar 27, 2013, at 20:46, Al Viro wrote:
On Wed, Mar 27, 2013 at 08:31:02PM +0100, Alexander van Heukelum wrote:
Hi Al,
Hans de Bruin found a regression due to one of your changes. I asked him to
test a fix and he reported back that it worked. (Thanks!) Can you see if
you agree
Hi Hans,
Could you check if the attached patch solves your problem?
Greetings,
Alexander van Heukelum
On Sun, Mar 24, 2013, at 22:19, Hans de Bruin wrote:
> commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
> somehow breaks the colors when I play 'civilization I'
Hi Hans,
Could you check if the attached patch solves your problem?
Greetings,
Alexander van Heukelum
On Sun, Mar 24, 2013, at 22:19, Hans de Bruin wrote:
commit 49cb25e9290 x86: 'get rid of pt_regs argument in vm86/vm86old'
somehow breaks the colors when I play 'civilization I' under
On Mon, 25 Feb 2008 10:13:17 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum wrote:
> >
> > arch/x86/kernel/head64.c | 45
> > +++--
> > 1 files changed, 27 insertions(+), 18 deletio
-by: Alexander van Heukelum <[EMAIL PROTECTED]>
--
I think this patch is against -x86.git#testing :-/.
Greetings,
Alexander
arch/x86/kernel/head64.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/he
On Sun, 24 Feb 2008 18:18:16 -0800, "H. Peter Anvin" <[EMAIL PROTECTED]>
said:
> Alexander van Heukelum wrote:
> > early res: 3 [9f000-9] EBDA
> >
> > Is it really necessary to force the allocation to a page boundary?
>
> It is, but that roundin
On Sun, 24 Feb 2008 18:18:16 -0800, H. Peter Anvin [EMAIL PROTECTED]
said:
Alexander van Heukelum wrote:
early res: 3 [9f000-9] EBDA
Is it really necessary to force the allocation to a page boundary?
It is, but that rounding gets done in reserve_bootmem() anyway, so
-by: Alexander van Heukelum [EMAIL PROTECTED]
--
I think this patch is against -x86.git#testing :-/.
Greetings,
Alexander
arch/x86/kernel/head64.c | 45 +++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/head64.c b
On Mon, 25 Feb 2008 10:13:17 -0800, H. Peter Anvin [EMAIL PROTECTED]
said:
Alexander van Heukelum wrote:
arch/x86/kernel/head64.c | 45
+++--
1 files changed, 27 insertions(+), 18 deletions(-)
diff --git a/arch/x86/kernel/head64.c b/arch
On Sun, 24 Feb 2008 20:41:21 +0100, "Ingo Molnar" <[EMAIL PROTECTED]> said:
>
> * Alexander van Heukelum <[EMAIL PROTECTED]> wrote:
>
> > Hi Andi,
> >
> > My eyes fell on the following table in the boot messages:
> >
> > ea
into the area normally
reserved for the VGA adaptor. It seems that you wanted to force
the allocation to cover whole pages, like:
early res: 3 [9f000-9] EBDA
This is what this patch implements.
Is it really necessary to force the allocation to a page boundary?
Signed-off-by: Alexander van
into the area normally
reserved for the VGA adaptor. It seems that you wanted to force
the allocation to cover whole pages, like:
early res: 3 [9f000-9] EBDA
This is what this patch implements.
Is it really necessary to force the allocation to a page boundary?
Signed-off-by: Alexander van
On Sun, 24 Feb 2008 20:41:21 +0100, Ingo Molnar [EMAIL PROTECTED] said:
* Alexander van Heukelum [EMAIL PROTECTED] wrote:
Hi Andi,
My eyes fell on the following table in the boot messages:
early res: 0 [0-fff] BIOS data page
early res: 1 [6000-7fff] SMP_TRAMPOLINE
early res: 2
check in modpost. We are no longer dependent on the actual
> configuration of for example HOTPLUG.
>
> I think that explains it.
I should have looked at that commit first. Indeed, it does explain
why it is better to keep the sections separate. Thanks.
--
Alexander van Heukelum
gs
go away. Same for MEMORY_HOTPLUG/meminit and HOTPLUG_CPU/cpuinit.
On the condition that someone with knowledge in this area confirms
that this approach is right and not for some reason undesirable:
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
include/asm-generic/vmlinux.lds.h | 98 +
with knowledge in this area confirms
that this approach is right and not for some reason undesirable:
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
include/asm-generic/vmlinux.lds.h | 98
include/linux/init.h | 27 ++
2 files
at that commit first. Indeed, it does explain
why it is better to keep the sections separate. Thanks.
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
--
To unsubscribe from this list: send the line unsubscribe linux-kernel
avoided.
Compile-tested on:
silly minimal config
defconfig x86_32
defconfig x86_64
defconfig x86_64 -HIBERNATION +MEMORY_HOTPLUG
Comments?
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
diff --git a/mm/internal.h b/mm/internal.h
index 953f941..5b46b32 100644
--- a/mm/internal.h
++
avoided.
Compile-tested on:
silly minimal config
defconfig x86_32
defconfig x86_64
defconfig x86_64 -HIBERNATION +MEMORY_HOTPLUG
Comments?
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
diff --git a/mm/internal.h b/mm/internal.h
index 953f941..5b46b32 100644
--- a/mm/internal.h
+++ b/mm
nto another one, however. My guess is
that you did not see the new warning due to inlining, but I
compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE=y.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - And now for something completely differentÂ…
--
T
it is guarded by
ACPI_HOTPLUG_CPU (which depends on HOTPLUG_CPU).
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
CC: Sam Ravnborg <[EMAIL PROTECTED]>
diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
index 78cbb65..e6757aa 100644
--- a/arch/x86/kernel/topo
it is guarded by
ACPI_HOTPLUG_CPU (which depends on HOTPLUG_CPU).
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
CC: Sam Ravnborg [EMAIL PROTECTED]
diff --git a/arch/x86/kernel/topology.c b/arch/x86/kernel/topology.c
index 78cbb65..e6757aa 100644
--- a/arch/x86/kernel/topology.c
+++ b
is
that you did not see the new warning due to inlining, but I
compiled with CONFIG_CC_OPTIMIZE_FOR_SIZE=y.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - And now for something completely differentÂ…
--
To unsubscribe from this list: send
-by: Alexander van Heukelum <[EMAIL PROTECTED]>
Oh, and the compile-problem still exists in git-99f1c97. The git-tree is
changing faster than I can test the patch and write an e-mail :-/.
diff --git a/drivers/base/core.c b/drivers/base/core.c
index edf3bbe..3751843 100644
--- a/drivers/base/core.c
nts to be warned in such cases
(initialisation
of a character array of specified length using a string constant) one
could
tell the compiler that the 0 at the end should really be there:
struct {char c[4];} s2 = {"abcd" "\0"};
Writing it like this will give them the expected
the expected warning.
Greetings,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Choose from over 50 domains or use your own
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
of the bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
> I'd prefer .bstext or .bs_text and .bsdata/.bs_data; possibly .bsecttext
> and .bsectdata. The term "boot sector" for
of the bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
Hi,
I hope the new section names are ok? Alternatives would be
.bstext/.bsdata or .floppytext/.floppydata.
Greetings,
Ale
of the bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
---
Hi,
I hope the new section names are ok? Alternatives would be
.bstext/.bsdata or .floppytext/.floppydata.
Greetings,
Alexander
arch
of the bootsector stub. It also moves
some code from the .header section (a data section) to .inittext.
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
---
I'd prefer .bstext or .bs_text and .bsdata/.bs_data; possibly .bsecttext
and .bsectdata. The term boot sector for that particular piece of
code
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
> > It doesn't probe the hardware in dangerous ways. (Search for mode_scan
> > in video.S) It works by trying to set a mode via the normal
> > AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
> > checks if the
On Thu, May 10, 2007 at 03:48:08PM -0700, H. Peter Anvin wrote:
It doesn't probe the hardware in dangerous ways. (Search for mode_scan
in video.S) It works by trying to set a mode via the normal
AH=0/AL=mode/int 0x10 method for all possible values of mode. It then
checks if the bios
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
> As far as I could tell, "scan" simply caused the nonstandard video
> driver scan modules (unsafe probes) to be invoked. Since those modules
> are no longer present, there appeared to be no need for them. The VGA
> and VESA probes
inking of a new kernel image format without
breaking bootloaders that use a bzImage in the intended way.
Good luck,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - A fast, anti-spam email service.
-
To unsubscribe from this list: send the line &qu
breaking bootloaders that use a bzImage in the intended way.
Good luck,
Alexander
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - A fast, anti-spam email service.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message
On Thu, May 10, 2007 at 11:08:10AM -0700, H. Peter Anvin wrote:
As far as I could tell, scan simply caused the nonstandard video
driver scan modules (unsafe probes) to be invoked. Since those modules
are no longer present, there appeared to be no need for them. The VGA
and VESA probes are
On Wed, May 09, 2007 at 09:51:36AM -0700, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> >
> > Hi!
> >
> > I'm making coffee now. I just don't see what I missed? Maybe you were
> > led astray by the new PARAM_VESA_PAD I added?
> >
>
> Again
On Wed, May 09, 2007 at 08:04:07AM +0800, Antonino A. Daplas wrote:
> On Tue, 2007-05-08 at 20:32 +0200, Alexander van Heukelum wrote:
> > diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
> > diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
> > i
On Wed, May 09, 2007 at 08:04:07AM +0800, Antonino A. Daplas wrote:
On Tue, 2007-05-08 at 20:32 +0200, Alexander van Heukelum wrote:
diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
diff --git a/arch/i386/boot/video.S b/arch/i386/boot/video.S
index 8143c95..8e404cb 100644
On Wed, May 09, 2007 at 09:51:36AM -0700, H. Peter Anvin wrote:
Alexander van Heukelum wrote:
Hi!
I'm making coffee now. I just don't see what I missed? Maybe you were
led astray by the new PARAM_VESA_PAD I added?
Again, I object to changing a documented interface when it's
On Tue, May 08, 2007 at 11:45:47AM -0700, H. Peter Anvin wrote:
> Alexander van Heukelum wrote:
> >
> > Oh! A padding hole in a struct! That could be a problem. If the freeze
> > is after decompression, could you test if this makes it work again?
> >
>
On Tue, May 08, 2007 at 03:28:17AM -0700, Andrew Morton wrote:
> On Sat, 5 May 2007 12:44:52 +0200 Alexander van Heukelum <[EMAIL PROTECTED]>
> wrote:
> > --- a/arch/i386/boot/bootsect.S
> > +++ b/arch/i386/boot/bootsect.S
> > @@ -44,7 +44,7 @@ #endif
> >
On Tue, May 08, 2007 at 03:28:17AM -0700, Andrew Morton wrote:
On Sat, 5 May 2007 12:44:52 +0200 Alexander van Heukelum [EMAIL PROTECTED]
wrote:
--- a/arch/i386/boot/bootsect.S
+++ b/arch/i386/boot/bootsect.S
@@ -44,7 +44,7 @@ #endif
_start:
# Normalize the start address
On Tue, May 08, 2007 at 11:45:47AM -0700, H. Peter Anvin wrote:
Alexander van Heukelum wrote:
Oh! A padding hole in a struct! That could be a problem. If the freeze
is after decompression, could you test if this makes it work again?
The correct fix is to apply __attribute__((packed
the intention was a 16:16-bit far jump.
This patch changes only x86_64.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
diff --git a/arch/x86_64/boot/bootsect.S b/arch/x86_64/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/x86_64/boot/bootsect.S
the intention was a 16:16-bit far jump.
This patch changes only i386.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum <[EMAIL PROTECTED]>
---
diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/i386/boot/bootsect.S
+++
the intention was a 16:16-bit far jump.
This patch changes only i386.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
---
diff --git a/arch/i386/boot/bootsect.S b/arch/i386/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/i386/boot/bootsect.S
+++ b/arch/i386
the intention was a 16:16-bit far jump.
This patch changes only x86_64.
Greetings,
Alexander
Signed-off-by: Alexander van Heukelum [EMAIL PROTECTED]
---
diff --git a/arch/x86_64/boot/bootsect.S b/arch/x86_64/boot/bootsect.S
index 011b7a4..ae9df0d 100644
--- a/arch/x86_64/boot/bootsect.S
+++ b
e linux-kernel"
> in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
>
>
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Does exactly what
Please read the FAQ at http://www.tux.org/lkml/
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Does exactly what it says on the tin
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo
of the compressed kernel image.
I have no idea what went wrong, but it went wrong in the build process
of the bzImage.
Hope this helps,
Alexander
> --
> Jean Delvare
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
> in
> the body of
of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
--
Alexander van Heukelum
[EMAIL PROTECTED]
--
http://www.fastmail.fm - Send your email first class
-
To unsubscribe from this list: send the line
99 matches
Mail list logo
