>>> On 20.08.12 at 13:18, Andi Kleen wrote:
>> That's not the point: The point really is that you could allow the
>> alternative regardless of LTO, and just penalize the LTO case
>> by having even the asm clobber the registers that a function call
>> would not preserve.
>
> That's just what a no
Alex,
without even having run that code yet, I think I see two bugs here,
both of which I'm pretty sure I pointed out at least once during the
review cycle:
For one, while TLB_FLUSH_ALL gets passed as 'end' argument to
flush_tlb_others(), the Xen code was made to check its 'start'
parameter.
Sec
move those variables into registers) and generally results
in better code (because we know the arguments are in memory anyway,
and are frequently - if not always - used just once, with the second
[compiler visible] use in asmlinkage_protect() itself being a fake
one).
Signed-off-by: Jan Beulich
>>> On 15.02.13 at 17:26, Konrad Rzeszutek Wilk wrote:
> v3.7:
> - Initial support for ARM working under Xen as both guest and initial
> domain.
> - Security fixes.
> - Fix RCU warning, add fallback code for old hypervisors, fix memory leaks in
>gntdev driver, fix some pvops calls failing,
>>> On 15.02.13 at 17:34, Konrad Rzeszutek Wilk wrote:
> I know that the PVH patches are not in the Xen tree. I am hoping that
> at least the hypercalls _are_ OK with everybody so we can continue on
> with this.
Please don't commit to anything that isn't in the hypervisor tree
yet. IOW I'd like y
>>> On 10.10.12 at 12:45, Matt Fleming wrote:
> On Thu, 2012-10-04 at 11:01 +0100, Jan Beulich wrote:
>> >>> On 04.10.12 at 11:18, Matt Fleming wrote:
>> > On Thu, 2012-10-04 at 07:32 +0100, Jan Beulich wrote:
>> >> Btw., once this set of your
Michal,
is there any reason why that commit reverts two other changes
(to arch/x86/Makefile and scripts/Makefile.fwinst) without any
mention of the reason for this in the description?
Also, Greg, didn't this get merged into stable a little too quickly?
Thanks, Jan
--
To unsubscribe from this li
>>> On 20.11.12 at 23:42, Dan Magenheimer wrote:
> Konrad: Any chance this can get in for the upcoming window?
> (Or is it enough of a bug fix that it can go in at an -rcN?)
>
> It was just pointed out to me that some kernels have
> cleancache and frontswap and xen_tmem enabled but NOT
> xen_self
>>> On 21.11.12 at 16:42, Dan Magenheimer wrote:
>> From: Jan Beulich [mailto:jbeul...@suse.com]
>> Sent: Wednesday, November 21, 2012 1:21 AM
>> To: Dan Magenheimer
>> Cc: xen-de...@lists.xen.org; Konrad Wilk; linux-kernel@vger.kernel.org
>> Sub
>>> On 23.11.12 at 02:56, Andrew Cooper wrote:
> On 23/11/2012 01:38, H. Peter Anvin wrote:
>> I still don't really get why it can't be isolated from dom0, which would
> make more sense to me, even for a Xen crash.
>>
>
> The crash region (as specified by crashkernel= on the Xen command line)
>
>>> On 22.11.12 at 18:37, "H. Peter Anvin" wrote:
> I actually talked to Ian Jackson at LCE, and mentioned among other
> things the bogosity of requiring a PUD page for three-level paging in
> Linux -- a bogosity which has spread from Xen into native. It's a page
> wasted for no good reason, s
>>> On 23.11.12 at 11:37, Daniel Kiper wrote:
> On Fri, Nov 23, 2012 at 09:53:37AM +, Jan Beulich wrote:
>> >>> On 23.11.12 at 02:56, Andrew Cooper wrote:
>> > On 23/11/2012 01:38, H. Peter Anvin wrote:
>> >> I still don't really get why
.
Also get the Knight's Corner definitions in sync.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/perf_event_knc.c |4 ++--
arch/x86/kernel/cpu/perf_event_p6.c |2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
--- 3.7-rc6/arch/x86/kernel/cpu/perf_event_knc.c
+++ 3.7-rc6-x86
These items are only ever referenced from initialization code.
Signed-off-by: Jan Beulich
---
arch/x86/platform/efi/efi-bgrt.c |7 ---
1 file changed, 4 insertions(+), 3 deletions(-)
--- 3.7-rc6/arch/x86/platform/efi/efi-bgrt.c
+++ 3.7-rc6-x86-BGRT-init/arch/x86/platform/efi/efi
The first two are functions serving as initcalls; the SFI one is only
being called from __init code.
Signed-off-by: Jan Beulich
---
arch/x86/kernel/cpu/intel_cacheinfo.c |2 +-
arch/x86/mm/tlb.c |2 +-
arch/x86/platform/sfi/sfi.c |2 +-
3 files changed
Ondrej,
I see two problems with this patch: For one, on a system without
i8042 the code at the place it got inserted ought to incur a stall of
1s (50us * I8042_CTL_TIMEOUT [1] * 2). I believe that this
code should not be run before i8042_controller_check() completed
successfully, but at the ve
>>> On 14.01.13 at 09:29, Ondrej Zary wrote:
> On Monday 14 January 2013, Jan Beulich wrote:
>> Ondrej,
>>
>> I see two problems with this patch: For one, on a system without
>> i8042 the code at the place it got inserted ought to incur a stall of
>> 1s
This fixes three issues:
- missing parentheses around a flag test
- wrong memory type used for allocation intended to persist post-boot
- four similar build warnings on 32-bit (casts between different size
pointers and integers)
Signed-off-by: Jan Beulich
---
arch/x86/boot/compressed/eboot.c
>>> On 14.01.13 at 09:54, Ondrej Zary wrote:
> On Monday 14 January 2013, Jan Beulich wrote:
>> >>> On 14.01.13 at 09:29, Ondrej Zary wrote:
>> > On Monday 14 January 2013, Jan Beulich wrote:
>> >> Second, considering that enabling A20 (eve
>>> On 14.01.13 at 17:34, Borislav Petkov wrote:
> On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
>> --- a/drivers/acpi/processor_perflib.c
>> +++ b/drivers/acpi/processor_perflib.c
>> @@ -340,6 +340,9 @@ static void amd_fixup_frequency(struct acpi_processor_px
> *px
>> if
At the same time reduce the local buffers to 16 bytes each.
Signed-off-by: Jan Beulich
--- a/drivers/xen/cpu_hotplug.c
+++ b/drivers/xen/cpu_hotplug.c
@@ -25,10 +25,10 @@ static void disable_hotplug_cpu(int cpu)
static int vcpu_online(unsigned int cpu)
{
int err;
- char dir[32
>>> On 13.12.12 at 01:29, Daniel Santos wrote:
> Wow, it's really easy to miss parallel development on the same issue.
> Sorry for my late response to this thread. I started another thread
> addressing these issues (as well as a few others) back in September
> (https://lkml.org/lkml/2012/9/28
>>> On 11.12.12 at 21:50, Olaf Hering wrote:
> backend_changed might be called multiple times, which will leak
> be->mode. Make sure it will be called only once. Remove some unneeded
> checks. Also the be->mode string was leaked, release the memory on
> device shutdown.
So I decided to make an at
>>> On 15.12.12 at 19:35, Linus Torvalds wrote:
> On Sat, Dec 15, 2012 at 8:33 AM, Markus Trippelsdorf
> wrote:
>> On 2012.12.14 at 17:47 -0800, Linus Torvalds wrote:
>>>
>>> Ho humm. Anybody else see anything strange?
>>
>> Yes. I'm seeing a BUG early during boot on my machine (RIP=NULL):
>>
>>
>>> On 17.12.12 at 16:44, Linus Torvalds wrote:
> On Mon, Dec 17, 2012 at 1:04 AM, Jan Beulich wrote:
>>
>> How about this being caused by using the same lower level
>> page table entries that swapper_pg_dir uses, namely including
>> the _PAGE_GLOBAL bits? efi
>>> On 17.12.12 at 17:39, "H. Peter Anvin" wrote:
> Right, I think you nailed this one. This patch copies PTEs from the
> kernel PTEs and thus they will have the global bit set. It obviously
> makes no sense to *copy* PTEs from the kernel and yet leaving the global
> bit set, which means there a
>>> On 27.09.12 at 20:06, Daniel Kiper wrote:
> Some kexec/kdump implementations (e.g. Xen PVOPS) on different archs could
> not use default functions or require some changes in behavior of kexec/kdump
> generic code. To cope with that problem kexec_ops struct was introduced.
> It allows a develop
>>> On 27.09.12 at 20:06, Daniel Kiper wrote:
> Some implementations (e.g. Xen PVOPS) could not use part of identity page
> table
> to construct transition page table. It means that they require separate
> PUDs,
> PMDs and PTEs for virtual and physical (identity) mapping. To satisfy that
> requi
>>> On 27.09.12 at 20:06, Daniel Kiper wrote:
> Add i386 kexec/kdump implementation.
So this as well as the subsequent patch introduces quite a bit of
duplicate code. The old 2.6.18 kernel had an initial pair of cleanup
patches (attached in their forward ported form for 3.6-rc6) that
would allow
>>> On 28.09.12 at 18:21, Konrad Rzeszutek Wilk wrote:
> On Thu, Sep 27, 2012 at 08:06:32PM +0200, Daniel Kiper wrote:
>> +for (i = 0; i < cpus; ++i) {
>
> Any specific reason for using '++i' instead of 'i++' ?
For people occasionally also writing C++ code this is the
canonical form.
Jan
-
>>> On 01.10.12 at 14:52, Daniel Kiper wrote:
> On Fri, Sep 28, 2012 at 09:11:47AM +0100, Jan Beulich wrote:
>> Finally, as noticed in an earlier patch already, you appear to
>> re-introduce stuff long dropped from the kernel - the forward
>> ported kern
>>> On 15.01.13 at 18:53, Konrad Rzeszutek Wilk wrote:
> On Mon, Jan 14, 2013 at 05:34:45PM +0100, Borislav Petkov wrote:
>> On Mon, Jan 14, 2013 at 04:58:54PM +0100, Stefan Bader wrote:
>> > --- a/drivers/acpi/processor_perflib.c
>> > +++ b/drivers/acpi/processor_perflib.c
>> > @@ -340,6 +340,9 @
>>> On 17.01.13 at 13:22, Matt Wilson wrote:
> On Wed, Jan 16, 2013 at 04:22:49PM -0500, Konrad Rzeszutek Wilk wrote:
>> We have the framework to use v2, but there are no backends that
>> actually use it. The end result is that on PV we use v2 grants
>> and on PVHVM v1. The v1 has a capacity of 51
>>> On 17.01.13 at 13:29, Matt Fleming wrote:
> On Mon, 2013-01-14 at 08:59 +, Jan Beulich wrote:
>> This fixes three issues:
>> - missing parentheses around a flag test
>> - wrong memory type used for allocation intended to persist post-boot
>> - four sim
>>> "Xu, Dongxiao" 01/07/13 8:17 AM >>>
> From: Jan Beulich [mailto:jbeul...@suse.com]
> >>> On 20.12.12 at 02:23, "Xu, Dongxiao" wrote:
>> > Take the libata case as an example, the static DMA buffer locates
>> > (dev->lin
>>> On 04.01.13 at 18:25, Daniel Kiper wrote:
> Right, so where is virtual mapping of control page established?
> I could not find relevant code in SLES kernel which does that.
In the hypervisor (xen/arch/x86/machine_kexec.c:machine_kexec_load()).
xen/arch/x86/machine_kexec.c:machine_kexec() then
>>> On 07.01.13 at 13:52, Daniel Kiper wrote:
> On Mon, Jan 07, 2013 at 09:48:20AM +, Jan Beulich wrote:
>> >>> On 04.01.13 at 18:25, Daniel Kiper wrote:
>> > Right, so where is virtual mapping of control page established?
>> > I could not find
>>> On 07.01.13 at 16:08, Konrad Rzeszutek Wilk wrote:
> On Sat, Jan 05, 2013 at 02:18:46PM -0500, Nickolai Zeldovich wrote:
>> xen_add_device() in drivers/xen/pci.c allocates a struct
>> physdev_pci_device_add on the stack and then writes to optarr[0].
>> The previous declaration of struct physde
Stas, Petr,
I know it's been a while since this was discussed and integrated into
mainline, but I just now came across this, and following all of the
original discussion that I was able to locate I didn't see any mention
of a potential different approach to solving the problem which, as it
would a
be)
generated as a side effect of executing config targets, include/linux
should be created prior to running the respective sub-make.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
--- /home/jbeulich/tmp/linux-2.6.13/Makefile2005-08-29
01:41:01.0 +0200
+++ 2.6.13/Makefile 2
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Stack pointer comparisons for the NMI on debug stack check/fixup were
incorrect.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
/home/jbeulich/tmp/linux-2.6.13/arch/i386/kernel/entry.S2005
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Like previously done for i386, get the x86_64 watchdog tick
calculation
into a state where it can also be used on CPUs with frequencies beyond
4GHz.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
seems I'm afraid: With the version of this patch that just went
in, Jan Beulich <[EMAIL PROTECTED]> found a bug when building
vmlinux.lds on i386. He triggered it by by putting poisoned version.h
and
autoconf.h files in /usr/src/linux.
With the additional changes (rediff against linux-
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
A trivial addition to the EFL definitions.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/include/linux/elf.h 2.6.13-elf/include/linux/elf.h
--- 2.6.13/include/linux/elf.h 2005-08-29
for
i386 and x86_64) and doesn't require alternative boot-time interfaces.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/setup.c
2.6.13-early-ioremap/arch/i386/kernel/setup.c
--- 2.6.13/arch/i386/kernel/setup.c 2005-08-29 01:41:01.0
+0200
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
An adjustment to the SM_DOWN case of fbcon_scroll to match the behavior
of
SM_UP.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/drivers/video/console/fbcon.c
2.6.13-fbcon-logo-scrol
normal kernel code, such a guarantee seems rather desirable.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/drivers/video/console/fbcon.c
2.6.13-fonts-const/drivers/video/console/fbcon.c
--- 2.6.13/drivers/video/console/fbcon.c2005-08-29
01:41:01.0 +0200
+++
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Besides freeing initrd memory, also clear out the now dangling
pointers
to it, to make sure accidental late use attempts can be detected.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.1
>>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 16:32:16 >>>
>On Thu, Sep 08, 2005 at 04:30:03PM +0200, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> A trivial addition
ation communicated from the respective
interrupt
handler. For this to fully work, additional adjustments are necessary,
so this is meant ot only be the first step.)
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/irq.c
2.6.13-irqreturn/arch/i386/kernel/irq.c
---
a kernel debugger might obtain that before the initial mode change.
Finally, some return code corrections to fit the generic fb code.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/drivers/video/matrox/matroxfb_base.c
2.6.13-matroxfb/drivers/video/matrox/matroxfb_
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Debugging and maintenance support code occasionally needs to know not
only of module insertions, but also modulke removals. This adds a
notifier
chain for this purpose.
Signed-off-by: Jan Beulich <[EM
producing similar information for all C sources.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/entry.S
2.6.13-i386-cfi/arch/i386/kernel/entry.S
--- 2.6.13/arch/i386/kernel/entry.S 2005-08-29 01:41:01.0
+0200
+++ 2.6.13-i386-cfi/arch/i386/kernel/e
tless
increments).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/Makefile 2.6.13-version-update/Makefile
--- 2.6.13/Makefile 2005-08-29 01:41:01.0 +0200
+++ 2.6.13-version-update/Makefile 2005-09-01 11:32:13.0
+0200
@@ -624,8 +624,13 @@ quiet_cm
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
While strnicmp existed in the set of string support routines, stricmp
didn't, which this patch adjusts.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/include/linux/string.h
2.6
esn't support it (like was already happening for the byte, word,
and
long ones).
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/Kconfig
2.6.13-i386-cmpxchg/arch/i386/Kconfig
--- 2.6.13/arch/i386/Kconfig2005-08-29 01:41:01.0 +0200
+++ 2.6.13-i
>>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 17:16:24 >>>
>On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> Debugging and main
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Move some code unrelated to any dealing with hardware bugs from i386's
bugs.h to a more logical place.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/traps.c
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Rather than blindly re-enabling interrupts in die(), save their state
upon
entry and then restore that state.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/traps.c
>> Debugging and maintenance support code occasionally needs to know
not
>> only of module insertions, but also modulke removals. This adds a
>> notifier
>> chain for this purpose.
>>
>>
>> diff -Npru 2.6.13/kernel/module.c
>> 2.6.13-rmmod-notifier/kernel/module.c
>> --- 2.6.13/kernel/module.c 2
>>> Christoph Hellwig <[EMAIL PROTECTED]> 08.09.05 17:17:54 >>>
>On Thu, Sep 08, 2005 at 05:05:06PM +0200, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> While strnicmp exi
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
An addition and a fix to the static i386 initializers.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/include/asm-i386/processor.h
2.6.13-i386-init/include/asm-i386/processor.h
---
: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/cpu/mcheck/k7.c
2.6.13-i386-machine-check/arch/i386/kernel/cpu/mcheck/k7.c
--- 2.6.13/arch/i386/kernel/cpu/mcheck/k7.c 2005-08-29
01:41:01.0 +0200
+++
2.6.13-i386-machine-check/arch/i386/kernel/cpu/mcheck/k7.c 2
to use
per-
CPU stacks) will soon follow.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/asm-offsets.c
2.6.13-i386-THREAD_SIZE_asm/arch/i386/kernel/asm-offsets.c
--- 2.6.13/arch/i386/kernel/asm-offsets.c 2005-08-29
01:41:01.0 +0200
+++
2.6.1
>The only general, usable strnicmp safe for general kernel use would be
a
>full all singing all dancing UTF-8 symbol aware arbitary locale
>implementation. And that we *definitely* do not want in kernel.
Then you'd want to immediately get rid of the mentioned, pre-exisiting
strnicmp().
Jan
-
To u
s the situation.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/mach-generic/probe.c
2.6.13-i386-genapic/arch/i386/mach-generic/probe.c
--- 2.6.13/arch/i386/mach-generic/probe.c 2005-08-29
01:41:01.0 +0200
+++ 2.6.13-i386-genapic/arch/i386/mach-gene
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Don't call nmi_watchdog_tick() when this isn't enabled.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/traps.c
2.6.13-i386-watchdog-active/arch/i38
>It's possible to do this a bit differently, if I'm guessing right at
>what NLKD does. The following is from the KGDB patches (trimmed of
some
>other, unrelated to the notify part code):
Hmm, yes, this seems to be the better way to go.
Thanks, Jan
-
To unsubscribe from this list: send the line "
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Allow building the x86-64 kernels with frame pointers if so needed.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/lib/Kconfig.debug
2.6.13-x86_64-frame-pointer/lib/Kconfig.debug
---
sent
patch adding such annotations to i386 code) to enable them separatly
rather than only along with adding full debug information.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/x86_64/ia32/ia32entry.S
2.6.13-x86_64-cfi/arch/x86_64/ia32/ia32entry.S
--- 2.6.13/arch/
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Adjust, correct, and complete the HPET definitions for x86-64.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/include/asm-x86_64/hpet.h
2.6.13-x86_64-hpet/include/asm-x86_64/
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
While only cosmetic for x86-64, this adjusts the cmpxchg code
appearantly
inherited from i386 to use more generic constraints.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/inclu
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Set the stack pointer correctly in init_thread and init_tss.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/x86_64/kernel/init_task.c
2.6.13-x86_64-init/arch/x86_64/kernel/init_
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Declare NMI_VECTOR and handle it in the IPI sending code.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/include/asm-x86_64/hw_irq.h
2.6.13-x86_64-nmi-ipi/include/asm-x86_64/hw
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Rather than blindly re-enabling interrupts in oops_end(), save their
state
in oope_begin() and then restore that state.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/x86_64/
(Note: Patch also attached because the inline version is certain to get
line wrapped.)
Don't call nmi_watchdog_tick() when this isn't enabled.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/x86_64/kernel/io_apic.c
2.6.13-x86_64-watchdog-active/arch/x86_64/
>Index: linux/include/asm-x86_64/hw_irq.h
>===
>--- linux.orig/include/asm-x86_64/hw_irq.h
>+++ linux/include/asm-x86_64/hw_irq.h
>@@ -52,7 +52,7 @@ struct hw_interrupt_type;
> #define ERROR_APIC_VECTOR 0xfe
> #define RESCHEDULE_VE
>>> Tom Rini <[EMAIL PROTECTED]> 08.09.05 18:13:34 >>>
>On Thu, Sep 08, 2005 at 05:57:55PM +0200, Jan Beulich wrote:
>
>> >> + CFI_ADJUST_CFA_OFFSET 4;\
>> >> + /*CFI_REL_OFFSET es, 0;*/\
>> >> pushl %ds; \
>> >> + CF
>> >Index: linux/arch/x86_64/kernel/traps.c
>>
>===
>> >--- linux.orig/arch/x86_64/kernel/traps.c
>> >+++ linux/arch/x86_64/kernel/traps.c
>> >@@ -931,7 +931,7 @@ void __init trap_init(void)
>> >set_system_gate(IA32_SYSCALL_VECTOR,
handler
to
account for the fact that both GDT and TSS aren't in static kernel
space
anymore.
This patch depends upon the presence of THREAD_ORDER, as added in a
previously submitted patch.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
diff -Npru 2.6.13/arch/i386/kernel/cpu/common.c
>>> Andi Kleen <[EMAIL PROTECTED]> 09.09.05 09:14:07 >>>
>> ??? This is what the code doing the setup does. But the question was
-
>> what do you need the IDT entry for?
>
>Without an IDT entry you cannot receive it?
But that's the point - if it's delivered as an NMI, it'll arrive
through vector
>The UNWIND_INFO part has still some problems - in particular it is
lying
>on all other architectures which don't check it yet. I made it
dependent
>on X86_64 right now.
I don't think so. First, the i386 patch also adds the same (as I
indicated), and second this controls also the
-fasynchronous-ex
>>> Andi Kleen <[EMAIL PROTECTED]> 09.09.05 10:43:01 >>>
>On Thursday 08 September 2005 18:11, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> Don't call nmi_watchdog_tick(
Here it is.
>>> Andi Kleen <[EMAIL PROTECTED]> 09.09.05 10:50:01 >>>
On Thursday 08 September 2005 18:07, Jan Beulich wrote:
> (Note: Patch also attached because the inline version is certain to
get
> line wrapped.)
>
> Declare NMI_VECTOR and handle it in the
>>> Andi Kleen <[EMAIL PROTECTED]> 09.09.05 10:54:11 >>>
>On Thursday 08 September 2005 18:04, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> Allow building the x86-64 kernel
>>> Andi Kleen <[EMAIL PROTECTED]> 09.09.05 10:57:07 >>>
>On Thursday 08 September 2005 18:03, Jan Beulich wrote:
>> (Note: Patch also attached because the inline version is certain to
get
>> line wrapped.)
>>
>> While only cosmetic for x
>>> Tom Rini <[EMAIL PROTECTED]> 08.09.05 17:33:14 >>>
>On Thu, Sep 08, 2005 at 05:03:58PM +0200, Jan Beulich wrote:
>It's possible to do this a bit differently, if I'm guessing right at
>what NLKD does. The following is from the KGDB patches (trimmed o
> But why would anyone want frame pointers on x86-64?
I'd put the question differently: Why should x86-64 not allow what
other architectures do?
But of course, I'm not insisting on this patch to get in, it just
seemed an obvious inconsistency...
Jan
-
To unsubscribe from this list: send the line
>>> Zwane Mwaikambo <[EMAIL PROTECTED]> 08.09.05 19:37:20 >>>
>On Thu, 8 Sep 2005, Jan Beulich wrote:
>
>> diff -Npru 2.6.13/arch/i386/kernel/traps.c
>> 2.6.13-i386-die-irq/arch/i386/kernel/traps.c
>> --- 2.6.13/arch/i386/kernel/traps.c 2005-08-2
>I don't think it's a good idea to have two different ways
>to do kallsyms. Either we should always use your new
>way in standard KALLSYMS or not do it at all.
I agree, but I wanted to retain the old mechanism not the least because
of the space constraints you mention.
>The major decision factor
reduce x86-64 bug frame by 4 bytes
From: Jan Beulich <[EMAIL PROTECTED]>
(Note: Patch also attached because the inline version is certain to
get
line wrapped.)
As mentioned before, the size of the bug frame can be further reduced
while
continuing to use instructions to encode the infor
>> That's funny - on one hand I'm asked to not submit huge patches (not
by
>> you, but by others), but on the other hand not having the consuming
code
>> in the same patch as the providing one is now deemed to be a
problem.
>
>Nope.
>
>Each patch should do a single logical thing. That doesn't mean
>>> Andrew Morton <[EMAIL PROTECTED]> 25.12.07 23:05 >>>
>On Sun, 23 Dec 2007 12:26:21 + Christoph Hellwig <[EMAIL PROTECTED]> wrote:
>
>> On Thu, Dec 20, 2007 at 01:11:24PM +, Jan Beulich wrote:
>> > With more and more sub-systems/
>That change has been in the mainline tree for nearly three months. All
>these affected parties have left it until the eve of 2.6.24 to actually
>tell us about it. This is causing me sympathy problems :(
Not true - I complained about this on Dec 3rd (attached), with the result of
not getting a r
That's somewhat ugly, as it will need to be undone/modified for Dom0 and
physical device access support. Jan
>>> Jeremy Fitzhardinge <[EMAIL PROTECTED]> 08.01.08 23:00 >>>
The hypervisor doesn't allow PCD or PWT to be set on guest ptes, so
make sure they're masked out. Also, fix up some previous
>The "problem" is a BUG() in pageattr_64.c:change_page_attr(), which to
>me looks spurious. It arises because __PAGE_KERNEL_* doesn't contain
>_PAGE_GLOBAL, but PAGE_KERNEL_* does. When ioremap()
>change_page_attr(), it does so in a way that guarentees that the test
>
> if (pgprot_val(pr
>> +BLOCKING_NOTIFIER_HEAD(task_notifier_list);
>> +EXPORT_SYMBOL_GPL(task_notifier_list);
>> +ATOMIC_NOTIFIER_HEAD(atomic_task_notifier_list);
>> +EXPORT_SYMBOL_GPL(atomic_task_notifier_list);
>> +
>
>When these global notifier lists were proposed years ago folks at SGI
>loudly objected with conce
>> Am I to conclude then that there's no point in addressing the issues other
>> people pointed out? While I (obviously, since I submitted the patch
>> disagree),
>> I'm not certain how others feel. My main point for disagreement here is (I'm
>> sorry to repeat this) that as long as certain code i
No-one else is using these afaics.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
include/linux/module.h | 17 -
kernel/module.c| 16 +++-
2 files changed, 15 insertions(+), 18 deletions(-)
--- linux-2.6.24-rc7/include/linux/module.h 2008
When the newer export flavors were added, it was apparently forgotten
to add respective code here.
In order to not double the (source) size of the function, add some
abstraction to reduce code duplication.
Signed-off-by: Jan Beulich <[EMAIL PROTECTED]>
---
kernel/module.c
301 - 400 of 1374 matches
Mail list logo
