Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

Oleg Verych wrote: On Fri, Nov 17, 2006 at 10:59:32PM -0800, H. Peter Anvin wrote: Oleg Verych wrote: It will burn CPU, until power cycle will be done (my AMD64 laptop and Intel's amd64 destop PC require that). In case of reboot timeout (or just reboot with jump to BIOS), i will just choose

Re: [rfc patch] Re: sched: incorrect argument used in task_hot()

* Chen, Kenneth W <[EMAIL PROTECTED]> wrote: > - if (sd->nr_balance_failed > sd->cache_nice_tries) > + if (sd->nr_balance_failed > sd->cache_nice_tries) { > + #ifdef CONFIG_SCHEDSTATS > + if (task_hot(p, rq->most_recent_timestamp, sd)) > +

Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

On Fri, Nov 17, 2006 at 10:59:32PM -0800, H. Peter Anvin wrote: > Oleg Verych wrote: > > > >It will burn CPU, until power cycle will be done (my AMD64 laptop and > >Intel's amd64 destop PC require that). In case of reboot timeout (or > >just reboot with jump to BIOS), i will just choose another

Re: [PATCH] Regard MSRs in lapic_suspend()/lapic_resume()

* Karsten Wiese <[EMAIL PROTECTED]> wrote: > Read/Write APIC_LVTPC and APIC_LVTTHMR only, if get_maxlvt() returns > certain values. This is done like everywhere else in > i386/kernel/apic.c, so I guess its correct. Suspends/Resumes to disk > fine and eleminates an smp_error_interrupt() here

Re: [RFC: -mm patch] remove kernel/timer.c:wall_jiffies

* Adrian Bunk <[EMAIL PROTECTED]> wrote: > "wall_jiffies" was added, but it's completely unused... > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> yeah, that's a merge leftover in: gtod-persistent-clock-support-core.patch Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - To

Re: [RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static

* Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch makes the needlessly global __next_timer_interrupt() static. > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> ok. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - To unsubscribe from this list: send the line "unsubscribe

Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

Oleg Verych wrote: It will burn CPU, until power cycle will be done (my AMD64 laptop and Intel's amd64 destop PC require that). In case of reboot timeout (or just reboot with jump to BIOS), i will just choose another image to boot or will press F8 to have another boot device. That's a fairly

Re: [RFC: 2.6 patch] remove kernel/lockdep.c:lockdep_internal

* Adrian Bunk <[EMAIL PROTECTED]> wrote: > This patch removes the no longer used lockdep_internal(). > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> agreed. Acked-by: Ingo Molnar <[EMAIL PROTECTED]> Ingo - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in

Re: [PATCH 1/2] input: make serio_register_driver() return error code

On Fri, Nov 17, 2006 at 01:37:34AM -0500, Dmitry Torokhov wrote: > I think I found a way to handle all errors when registering serio driver. > What do you think about the patch below? > Looks good to me. I also tested this patch with my patch 2/4 (which actually checking the return code of

Re: [RFC 6/7] Use an external declaration in exit.c for fs_cachep

On Sat, 18 Nov 2006 06:44:33 + Oleg Verych <[EMAIL PROTECTED]> wrote: > > > On 2006-11-18, Stephen Rothwell wrote: > [] > >> --- linux-2.6.19-rc5-mm2.orig/kernel/exit.c2006-11-15 > >> 16:48:11.485511089 -0600 > >> +++ linux-2.6.19-rc5-mm2/kernel/exit.c 2006-11-17

SCSI init discussion/SAN problem

I have a problem with the order that the SCSI subsystem attaches disk devices that shows up in a multipath environment. My understanding is that during the finishing phase of the SCSI subsystem the partition table is read from the drive and the bare drive and each partition are registered

Re: [PATCH 18/20] x86_64: Relocatable kernel support

On Sat, Nov 18, 2006 at 05:56:47AM +, Oleg Verych wrote: > > On 2006-11-17, Vivek Goyal wrote: > [] > > static void error(char *x) > > @@ -281,57 +335,8 @@ static void error(char *x) > > while(1); /* Halt */ > > } > > Is it possible to make this optional (using "panic" reboot

Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

Andi Kleen wrote: May hang be done optional? There was a discussion about applying "panic" reboot timeout here. Is it possible to implement somehow? It would be tricky, but might be possible. But that would be a completely new feature -- the kernel has always hung in this case. If you think

Re: [RFC 6/7] Use an external declaration in exit.c for fs_cachep

On 2006-11-18, Stephen Rothwell wrote: [] >> --- linux-2.6.19-rc5-mm2.orig/kernel/exit.c 2006-11-15 16:48:11.485511089 >> -0600 >> +++ linux-2.6.19-rc5-mm2/kernel/exit.c 2006-11-17 23:04:09.764530373 >> -0600 >> @@ -48,6 +48,8 @@ >> #include >> #include >> >> +extern kmem_cache_t

Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

> May hang be done optional? There was a discussion about applying > "panic" reboot timeout here. Is it possible to implement somehow? It would be tricky, but might be possible. But that would be a completely new feature -- the kernel has always hung in this case. If you think you need it

Re: [RFC 6/7] Use an external declaration in exit.c for fs_cachep

On Fri, 17 Nov 2006 21:44:13 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > > Use an external declaration in exit.c for fs_cachep. > > fs_cachep is only used in kernel/exit.c and in kernel/fork.c. > It is defined in kernel/fork.c so we need to add an external > declaration to

Re: [RFC 5/7] Use external declaration for filep_cachep

On Fri, 17 Nov 2006 21:44:08 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > > Use external declaration for filep_cachep. > > filp_cachep is used in fs/file_table.c. Its defined in fs/dcache.c. > The easiest solution here is to add an external declaration to > fs/file_table.c. > >

Re: [RFC 1/7] Remove declaration of sighand_cachep from slab.h

On Fri, 17 Nov 2006 21:43:47 -0800 (PST) Christoph Lameter <[EMAIL PROTECTED]> wrote: > > Remove declaration of sighand_cachep from slab.h > > The sighand cache is only used in fs/exec.c and kernel/fork.c. It is defined > in kernel/fork.c but also used in fs/exec.c. So add an extern declaration

Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, Nov 17, 2006 at 08:51:03PM -0800, Andrew Morton wrote: > On Fri, 17 Nov 2006 23:33:45 -0500 (EST) > Alan Stern <[EMAIL PROTECTED]> wrote: > > > On Fri, 17 Nov 2006, Paul E. McKenney wrote: > > > > > > Perhaps a better approach to the initialization problem would be to > > > > assume > >

[PATCH -mm] handle BUG=n

From: Randy Dunlap <[EMAIL PROTECTED]> Handle BUG=n, GENERIC_BUG=n to prevent build errors: arch/x86_64/kernel/built-in.o: In function `die': (.text+0x3b3c): undefined reference to `report_bug' arch/x86_64/kernel/built-in.o: In function `module_arch_cleanup': (.text+0x10b60): undefined reference

[PATCH -mm] profile_likely: export do_check_likely

From: Randy Dunlap <[EMAIL PROTECTED]> I see MODPOST warnings for all modules in some (random) configs; e.g.: (This is a short list; I see >100 of these.) WARNING: "do_check_likely" [net/sched/cls_basic.ko] undefined! WARNING: "do_check_likely" [net/netfilter/x_tables.ko] undefined! WARNING:

[PATCH] I2O: handle __copy_from_user

From: Randy Dunlap <[EMAIL PROTECTED]> Handle __copy_from_user() return value. Noticed by inspection, not from build warning. Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- drivers/message/i2o/i2o_config.c |6 +- 1 file changed, 5 insertions(+), 1 deletion(-) ---

[PATCH -mm] ipath needs HT_IRQ

From: Randy Dunlap <[EMAIL PROTECTED]> IPATH needs HT_IRQ to prevent these build errors: drivers/built-in.o: In function `ipath_ht_free_irq': ipath_iba6110.c:(.text+0x15c76b): undefined reference to `ht_destroy_irq' drivers/built-in.o: In function `ipath_setup_ht_config':

Re: [PATCH 18/20] x86_64: Relocatable kernel support

On 2006-11-17, Vivek Goyal wrote: [] > static void error(char *x) > @@ -281,57 +335,8 @@ static void error(char *x) > while(1); /* Halt */ > } Is it possible to make this optional (using "panic" reboot timeout)? - To unsubscribe from this list: send the line "unsubscribe

[RFC 4/7] Move files_cachep to file.h

Move files_cachep to file.h The proper place is in file.h since its related to file I/O. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5-mm2/include/linux/file.h === ---

[RFC 6/7] Use an external declaration in exit.c for fs_cachep

Use an external declaration in exit.c for fs_cachep. fs_cachep is only used in kernel/exit.c and in kernel/fork.c. It is defined in kernel/fork.c so we need to add an external declaration to kernel/exit.c to be able to avoid the declaration. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>

[RFC 7/7] Move names_cachep to fs.h

Move names_cachep to fs.h The names_cachep is used for getname() and putname(). So lets put it into fs.h. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5-mm2/include/linux/slab.h === ---

[RFC 0/7] Remove slab cache declarations in slab.h

One of the strange issues in include/linux/slab.h that it contains a list of global slab caches. The following patches remove all the global definitions from slab.h and find other ways of defining these caches. 6 of the 7 defined caches are rarely used. One is never used. - To unsubscribe from

[RFC 1/7] Remove declaration of sighand_cachep from slab.h

Remove declaration of sighand_cachep from slab.h The sighand cache is only used in fs/exec.c and kernel/fork.c. It is defined in kernel/fork.c but also used in fs/exec.c. So add an extern declaration to fs/exec.c and remove the definition from slab.h. Signed-off-by: Christoph Lameter <[EMAIL

[RFC 2/7] Remove bio_cachep from slab.h

Remove bio_cachep from slab.h bio_cachep is no longer used it seems. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5-mm2/include/linux/slab.h === --- linux-2.6.19-rc5-mm2.orig/include/linux/slab.h

[RFC 3/7] Move vm_area_cachep to mm.h

Move vm_area_cachep to mm.h vm_area_cachep is used to store vm_area_structs. So move to mm.h. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5-mm2/include/linux/mm.h === ---

[RFC 5/7] Use external declaration for filep_cachep

Use external declaration for filep_cachep. filp_cachep is used in fs/file_table.c. Its defined in fs/dcache.c. The easiest solution here is to add an external declaration to fs/file_table.c. Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]> Index: linux-2.6.19-rc5-mm2/include/linux/slab.h

Re: [PATCH 20/20] x86_64: Move CPU verification code to common file

Hallo. On 2006-11-17, Vivek Goyal wrote: [] > +no_longmode: > + /* This isn't an x86-64 CPU so hang */ > +1: > + hlt > + jmp 1b > + > +#include "../../kernel/verify_cpu.S" > + May hang be done optional? There was a discussion about applying "panic" reboot timeout here. Is it

Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, 17 Nov 2006 23:33:45 -0500 (EST) Alan Stern <[EMAIL PROTECTED]> wrote: > On Fri, 17 Nov 2006, Paul E. McKenney wrote: > > > > Perhaps a better approach to the initialization problem would be to > > > assume > > > that either: > > > > > > 1. The srcu_struct will be initialized

Re: We're still coping with GCC < 3.0

Hallo. On 2006-11-17, someone with nick Blaisorblade wrote: > In arch/i386/kernel/irq.c (current git head) I found this comment: > > /* > * These should really be __section__(".bss.page_aligned") as well, but > * gcc's 3.0 and earlier don't handle that correctly. > */ > static char

Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, 17 Nov 2006, Paul E. McKenney wrote: > > Perhaps a better approach to the initialization problem would be to assume > > that either: > > > > 1. The srcu_struct will be initialized before it is used, or > > > > 2. When it is used before initialization, the system is running >

RE: touch_cache() only touches two thirds

On Fri, 17 Nov 2006, dean gaudet wrote: > another pointer chase arranged to fill the L1 (or L2) using many many > pages. i.e. suppose i wanted to traverse 32KiB L1 with 64B cache lines > then i'd allocate 512 pages and put one line on each page (pages ordered > randomly), but colour them so

Re: "Unable to handle kernel NULL pointer dereference" in 2.6.18.2 (2.6.18-1.2239.fc5)

On 2006-11-17, somebody from ckeith.clara.net wrote: [] > dmesg is attached below, if anything else is needed please let me know. > And if any one knows of any older kernels that are more stable for this > hardware configuration (2x dual core opteron 2220SE's with aacraid) please > let me know.

Re: Read/Write multiple network FDs in a single syscall context switch?

On Fri, 17 Nov 2006 22:53:26 -0500 "Marc Snider" <[EMAIL PROTECTED]> wrote: > Sorry, I must have given the wrong impression with respect to the data. It > is not all the same. Each ingress socket is associated with an individual > egress socket and the packet data being received and

Re: FW: RTC , ds1307 I2C driver and NTP does not work.

> -Original Message- > From: > Sent: 17 November 2006 17:57 > To: Joakim Tjernlund > Cc: [EMAIL PROTECTED] > Subject: Re: RTC , ds1307 I2C driver and NTP does not work. > > > On Nov 17, 2006, at 10:38 AM, Joakim Tjernlund wrote: > >> I get this when I activathte NTP and ntp "sync" the

Re: Read/Write multiple network FDs in a single syscall context switch?

On Fri, Nov 17, 2006 at 04:40:30PM -0500, Marc Snider wrote: > I've searched long and hard prior to posting here, but have been unable to > locate a kernel mechanism providing the ability to read or write multiple FDs > in a single userspace to kernel context switch. > > We've got a userspace

RE: touch_cache() only touches two thirds

On Fri, 10 Nov 2006, Bela Lubkin wrote: > The corrected code in > covers the full cache range. Granted that modern CPUs may be able to track > multiple simultaneous cache access streams: how many such streams are they > likely to be able to

Re: Linux 2.6.19-rc6 - NFSD working again

Hi, I just wanted to report a 'it works again' for rc6: after encountering the very same problems with -rc3 Jeff Garzik described in [0], I upgraded to -rc5 and applied the proposed[1] patch[2]. Now, the knfsd behaved a bit better (nfs-mounted /home, X11 applications created thousands of

tests of kernel modules

Hi After resolving http://bugzilla.kernel.org/show_bug.cgi?id=7481 I was thinking about possibilities how to prevent such bugs with testing. Usually just few insmods and rmmods show, whether the initialization and cleanup code of module is ok or not. I created a script which do the automatic

[patch] smbfs: is obsolete, please use CIFS

Signed-off-by: Oleg Verych <[EMAIL PROTECTED]> -- Note, some white spaces were killed. --- linux-2.6-mm/fs/Kconfig~smbfs-is-obsolete+emacs-visiting2006-11-15 08:58:53.097867250 + +++ linux-2.6-mm/fs/Kconfig 2006-11-18 03:22:24.055118500 + @@ -1200,5 +1200,5 @@ help

Re: [PATCH 17/20] x86_64: Remove CONFIG_PHYSICAL_START

On Sat, Nov 18, 2006 at 10:14:31AM +0900, Magnus Damm wrote: > Hi Vivek, > > Sorry for not commenting on an earlier version. > > On 11/18/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: > >I am about to add relocatable kernel support which has essentially > >no cost so there is no point in retaining

Re: [PATCH] emit logging when a process receives a fatal signal

On Sat, Nov 18, 2006 at 03:04:13AM +0100, Folkert van Heusden wrote: > > > > I found that sometimes processes disappear on some heavily used system > > > > of mine without any logging. So I've written a patch against 2.6.18.2 > > > > which emits logging when a process emits a fatal signal. > > >

Re: [PATCH 1/7] paravirtualization: header and stubs for paravirtualizing critical operations

On Wed, 2006-11-01 at 21:27 +1100, Rusty Russell wrote: > Create a paravirt.h header for all the critical operations which need > to be replaced with hypervisor calls, and include that instead of > defining native operations, when CONFIG_PARAVIRT. > > This patch does the dumbest possible

Re: [PATCH] emit logging when a process receives a fatal signal

> > > I found that sometimes processes disappear on some heavily used system > > > of mine without any logging. So I've written a patch against 2.6.18.2 > > > which emits logging when a process emits a fatal signal. > > Why not to patch default signal handlers in glibc, to have not only > >

Re: [PATCH] emit logging when a process receives a fatal signal

Hi, > > I found that sometimes processes disappear on some heavily used system > > of mine without any logging. So I've written a patch against 2.6.18.2 > > which emits logging when a process emits a fatal signal. > Why not to patch default signal handlers in glibc, to have not only > stderr, but

[PATCH] Regard MSRs in lapic_suspend()/lapic_resume()

Read/Write APIC_LVTPC and APIC_LVTTHMR only, if get_maxlvt() returns certain values. This is done like everywhere else in i386/kernel/apic.c, so I guess its correct. Suspends/Resumes to disk fine and eleminates an smp_error_interrupt() here on a K8. Signed-off-by: Karsten Wiese <[EMAIL

Re: [PATCH 19/20] x86_64: Extend bzImage protocol for relocatable kernel

On Fri, Nov 17, 2006 at 04:45:46PM -0800, H. Peter Anvin wrote: > Vivek Goyal wrote: > >On Fri, Nov 17, 2006 at 04:30:04PM -0800, H. Peter Anvin wrote: > >>Vivek Goyal wrote: > >>>o Extend the bzImage protocol (same as i386) to allow bzImage loaders to > >>> load the protected mode kernel at

Re: [2.6 patch] mark pci_find_device() as __deprecated

On Sat, 18 Nov 2006 01:06:29 +0100 > Oh, and if anything starts complaining "But this adds some warnings to > my kernel build!", he should either first fix the 200 kB (sic) of > warnings I'm getting in 2.6.19-rc5-mm2 starting at MODPOST or go to hell. > > Signed-off-by: Adrian Bunk <[EMAIL

Re: [PATCH] emit logging when a process receives a fatal signal

On 2006-11-18, Folkert van Heusden wrote: > Hi, > > I found that sometimes processes disappear on some heavily used system > of mine without any logging. So I've written a patch against 2.6.18.2 > which emits logging when a process emits a fatal signal. Why not to patch default signal handlers in

Re: [PATCH 12/20] x86_64: wakeup.S Misc cleanup

On Sat, Nov 18, 2006 at 01:19:07AM +0100, Pavel Machek wrote: > Hi! > > > o Various cleanups. One of the main purpose of cleanups is that make > > wakeup.S as close as possible to trampoline.S. > > > > o Following are the changes > > - Indentations for comments. > > - Changed the gdt

Re: [PATCH 17/20] x86_64: Remove CONFIG_PHYSICAL_START

Hi Vivek, Sorry for not commenting on an earlier version. On 11/18/06, Vivek Goyal <[EMAIL PROTECTED]> wrote: I am about to add relocatable kernel support which has essentially no cost so there is no point in retaining CONFIG_PHYSICAL_START and retaining CONFIG_PHYSICAL_START makes

Re: How to go about debuging a system lockup?

"Jesper Juhl" <[EMAIL PROTECTED]> writes: > Or just try a few random older 2.6 kernels like 2.6.14, 2.6.9, > 2.6.whatever (of course it needs to be a version that git knows > about). One can also do "bisect" manually, works with all kernels. -- Krzysztof Halasa - To unsubscribe from this list:

[PATCH] emit logging when a process receives a fatal signal

Hi, I found that sometimes processes disappear on some heavily used system of mine without any logging. So I've written a patch against 2.6.18.2 which emits logging when a process emits a fatal signal. Signed-off-by: Folkert van Heusden <[EMAIL PROTECTED]> --- linux-2.6.18.2/kernel/signal.c

Re: Basic support for siemens sx1

* Pavel Machek <[EMAIL PROTECTED]> [061118 02:38]: > Hi! > > > * Pavel Machek <[EMAIL PROTECTED]> [061116 19:04]: > > > From: Vladimir Ananiev <[EMAIL PROTECTED]> > > > > > > This adds basic support for Siemens SX1. More patches are available, > > > with video driver, mixer, and serial ports

Re: [PATCH 19/20] x86_64: Extend bzImage protocol for relocatable kernel

Vivek Goyal wrote: On Fri, Nov 17, 2006 at 04:30:04PM -0800, H. Peter Anvin wrote: Vivek Goyal wrote: o Extend the bzImage protocol (same as i386) to allow bzImage loaders to load the protected mode kernel at non-1MB address. Now protected mode component is relocatable and can be loaded at

Re: [PATCH 9/20] x86_64: 64bit PIC SMP trampoline

On Fri 2006-11-17 19:33:52, Vivek Goyal wrote: > On Sat, Nov 18, 2006 at 01:27:10AM +0100, Pavel Machek wrote: > > Hi! > > > > > that long mode is supported. Asking if long mode is implemented is > > > down right silly but we have traditionally had some of these checks, > > > and they can't hurt

Re: Basic support for siemens sx1

Hi! > * Pavel Machek <[EMAIL PROTECTED]> [061116 19:04]: > > From: Vladimir Ananiev <[EMAIL PROTECTED]> > > > > This adds basic support for Siemens SX1. More patches are available, > > with video driver, mixer, and serial ports working. That is enough to > > do gsm calls with right userland. >

Re: [PATCH 19/20] x86_64: Extend bzImage protocol for relocatable kernel

On Fri, Nov 17, 2006 at 04:30:04PM -0800, H. Peter Anvin wrote: > Vivek Goyal wrote: > > > >o Extend the bzImage protocol (same as i386) to allow bzImage loaders to > > load the protected mode kernel at non-1MB address. Now protected mode > > component is relocatable and can be loaded at non-1MB

Re: [PATCH 19/20] x86_64: Extend bzImage protocol for relocatable kernel

Vivek Goyal wrote: o Extend the bzImage protocol (same as i386) to allow bzImage loaders to load the protected mode kernel at non-1MB address. Now protected mode component is relocatable and can be loaded at non-1MB addresses. o As of today kdump uses it to run a second kernel from a

Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, Nov 17, 2006 at 02:27:15PM -0500, Alan Stern wrote: > On Fri, 17 Nov 2006, Paul E. McKenney wrote: > > > > It works for me, but the overhead is still large. Before it would take > > > 8-12 jiffies for a synchronize_srcu() to complete without there actually > > > being any reader locks

Re: [PATCH 9/20] x86_64: 64bit PIC SMP trampoline

On Sat, Nov 18, 2006 at 01:27:10AM +0100, Pavel Machek wrote: > Hi! > > > that long mode is supported. Asking if long mode is implemented is > > down right silly but we have traditionally had some of these checks, > > and they can't hurt anything. So when the totally ludicrous happens > > we

[PATCH 11/20] x86_64: wakeup.S Rename labels to reflect right register names

o Use appropriate names for 64bit regsiters. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> --- arch/x86_64/kernel/acpi/wakeup.S | 36 ++-- include/asm-x86_64/suspend.h | 12 ++-- 2 files

Re: [PATCH 9/20] x86_64: 64bit PIC SMP trampoline

Hi! > that long mode is supported. Asking if long mode is implemented is > down right silly but we have traditionally had some of these checks, > and they can't hurt anything. So when the totally ludicrous happens > we just might handle it correctly. Well, it is silly, and it is 50 lines of

[PATCH 5/20] x86_64: Fix early printk to use standard ISA mapping

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> --- arch/x86_64/kernel/early_printk.c |3 +-- 1 file changed, 1 insertion(+), 2 deletions(-) diff -puN

Re: [PATCH 13/20] x86_64: 64bit PIC ACPI wakeup trampoline

On Fri 2006-11-17 17:51:03, Vivek Goyal wrote: > > > o Moved wakeup_level4_pgt into the wakeup routine so we can > run the kernel above 4G. > > o Now we first go to 64bit mode and continue to run from trampoline and > then then start accessing kernel symbols and restore processor context. >

Re: [PATCH 8/20] x86_64: Add EFER to the set registers saved by save_processor_state

Hi! > EFER varies like %cr4 depending on the cpu capabilities, and which cpu > capabilities we want to make use of. So save/restore it make certain > we have the same EFER value when we are done. I still think that comment is right: EFER is function(cpu capabilities, kernel version, kernel

[PATCH 9/20] x86_64: 64bit PIC SMP trampoline

This modifies the SMP trampoline and all of the associated code so it can jump to a 64bit kernel loaded at an arbitrary address. The dependencies on having an idenetity mapped page in the kernel page tables for SMP bootup have all been removed. In addition the trampoline has been modified to

[RFC][PATCH 0/20] x86_64: Relocatable bzImage (V3)

Hi All, Here is the third attempt on implementing relocatable bzImage for x86_64. Following are the changes since V2. - Broke suspend/resume code changes into smaller patches. Pavel, I hope now it is easier to review. - Moved cpu long mode and SSE verfication code into a single common

[PATCH 2/20] x86_64: Assembly safe page.h and pgtable.h

This patch makes pgtable.h and page.h safe to include in assembly files like head.S. Allowing us to use symbolic constants instead of hard coded numbers when refering to the page tables. This patch copies asm-sparc64/const.h to asm-x86_64 to get a definition of _AC() a very convinient macro

[PATCH 13/20] x86_64: 64bit PIC ACPI wakeup trampoline

o Moved wakeup_level4_pgt into the wakeup routine so we can run the kernel above 4G. o Now we first go to 64bit mode and continue to run from trampoline and then then start accessing kernel symbols and restore processor context. This enables us to resume even in relocatable kernel context

[PATCH 4/20] x86_64: Cleanup the early boot page table

- Merge physmem_pgt and ident_pgt, removing physmem_pgt. The merge is broken as soon as mm/init.c:init_memory_mapping is run. - As physmem_pgt is gone don't export it in pgtable.h. - Use defines from pgtable.h for page permissions. - Fix the physical memory identity mapping so it is at the

Re: [PATCH 11/20] x86_64: wakeup.S Rename labels to reflect right register names

On Fri 2006-11-17 17:48:22, Vivek Goyal wrote: > > > o Use appropriate names for 64bit regsiters. > > Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> > Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> ACK. > --- >

Re: [PATCH 10/20] x86_64: wakeup.S Remove dead code

On Fri 2006-11-17 17:47:02, Vivek Goyal wrote: > > > o Get rid of dead code in wakeup.S > > o We never restore from saved_gdt, saved_idt, saved_ltd, saved_tss, saved_cr3, > saved_cr4, saved_cr0, real_save_gdt, saved_efer, saved_efer2. Get rid > of of associated code. > > o Get rid of

[PATCH 15/20] x86_64: Remove the identity mapping as early as possible

With the rewrite of the SMP trampoline and the early page allocator there is nothing that needs identity mapped pages, once we start executing C code. So add zap_identity_mappings into head64.c and remove zap_low_mappings() from much later in the code. The functions are subtly different thus

[PATCH 19/20] x86_64: Extend bzImage protocol for relocatable kernel

o Extend the bzImage protocol (same as i386) to allow bzImage loaders to load the protected mode kernel at non-1MB address. Now protected mode component is relocatable and can be loaded at non-1MB addresses. o As of today kdump uses it to run a second kernel from a reserved memory area.

[PATCH 10/20] x86_64: wakeup.S Remove dead code

o Get rid of dead code in wakeup.S o We never restore from saved_gdt, saved_idt, saved_ltd, saved_tss, saved_cr3, saved_cr4, saved_cr0, real_save_gdt, saved_efer, saved_efer2. Get rid of of associated code. o Get rid of bogus_magic, bogus_31_magic and bogus_magic2. No longer being used.

RE: [rfc patch] Re: sched: incorrect argument used in task_hot()

Mike Galbraith wrote on Friday, November 17, 2006 2:19 PM > > And a changelog, then we're all set! > > > > Oh. And a patch, too. > > Co-opt rq->timestamp_last_tick to maintain a cache_hot_time evaluation > reference timestamp at both tick and sched times to prevent said > reference, formerly

Re: [patch] cpufreq: mark cpufreq_tsc() as core_initcall_sync

On Fri, Nov 17, 2006 at 09:39:45PM +0300, Oleg Nesterov wrote: > Paul E. McKenney wrote: > > > > int srcu_read_lock(struct srcu_struct *sp) > > { > > @@ -112,11 +126,24 @@ int srcu_read_lock(struct srcu_struct *s > > > > preempt_disable(); > > idx = sp->completed & 0x1; > > -

Re: [PATCH 12/20] x86_64: wakeup.S Misc cleanup

Hi! > o Various cleanups. One of the main purpose of cleanups is that make > wakeup.S as close as possible to trampoline.S. > > o Following are the changes > - Indentations for comments. > - Changed the gdt table to compact form and to resemble the > one in trampoline.S >

[2.6 patch] mark pci_find_device() as __deprecated

On Fri, Nov 17, 2006 at 09:32:36AM -0500, Alan Cox wrote: > On Fri, Nov 17, 2006 at 03:21:45PM +0100, Adrian Bunk wrote: > > This patch removes the no longer used pci_find_device_reverse(). > > > > Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> > > Acked-by: Alan Cox <[EMAIL PROTECTED]> > >

[PATCH 12/20] x86_64: wakeup.S Misc cleanup

o Various cleanups. One of the main purpose of cleanups is that make wakeup.S as close as possible to trampoline.S. o Following are the changes - Indentations for comments. - Changed the gdt table to compact form and to resemble the one in trampoline.S - Take

[PATCH 17/20] x86_64: Remove CONFIG_PHYSICAL_START

I am about to add relocatable kernel support which has essentially no cost so there is no point in retaining CONFIG_PHYSICAL_START and retaining CONFIG_PHYSICAL_START makes implementation of and testing of a relocatable kernel more difficult. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]>

[PATCH 18/20] x86_64: Relocatable kernel support

This patch modifies the x86_64 kernel so that it can be loaded and run at any 2M aligned address, below 512G. The technique used is to compile the decompressor with -fPIC and modify it so the decompressor is fully relocatable. For the main kernel the page tables are modified so the kernel

[PATCH 8/20] x86_64: Add EFER to the set registers saved by save_processor_state

EFER varies like %cr4 depending on the cpu capabilities, and which cpu capabilities we want to make use of. So save/restore it make certain we have the same EFER value when we are done. Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> ---

[RFC: -mm patch] make kernel/timer.c:__next_timer_interrupt() static

This patch makes the needlessly global __next_timer_interrupt() static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:11:49.0 +0100 +++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:12:02.0 +0100 @@ -621,7 +621,8

[RFC: -mm patch] remove kernel/timer.c:wall_jiffies

"wall_jiffies" was added, but it's completely unused... Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- linux-2.6.19-rc5-mm2/kernel/timer.c.old 2006-11-17 19:09:54.0 +0100 +++ linux-2.6.19-rc5-mm2/kernel/timer.c 2006-11-17 19:10:01.0 +0100 @@ -42,9 +42,6 @@ #include

[RFC: 2.6 patch] remove the broken HISAX_AMD7930 option

HISAX_AMD7930 was never anywhere near to being working, and this doesn't seem to change in the forseeable future. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- drivers/isdn/hisax/Kconfig |7 --- drivers/isdn/hisax/config.c | 18 -- drivers/isdn/hisax/hisax.h |

[RFC: 2.6 patch] make kernel/signal.c:kill_proc_info()

This patch makes the needlessly global kill_proc_info() static. Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]> --- include/linux/sched.h |1 - kernel/signal.c |3 +-- 2 files changed, 1 insertion(+), 3 deletions(-) --- linux-2.6.19-rc5-mm2/include/linux/sched.h.old

[PATCH 16/20] x86_64: __pa and __pa_symbol address space separation

Currently __pa_symbol is for use with symbols in the kernel address map and __pa is for use with pointers into the physical memory map. But the code is implemented so you can usually interchange the two. __pa which is much more common can be implemented much more cheaply if it is it doesn't

[PATCH 3/20] x86_64: Kill temp_boot_pmds

Early in the boot process we need the ability to set up temporary mappings, before our normal mechanisms are initialized. Currently this is used to map pages that are part of the page tables we are building and pages during the dmi scan. The core problem is that we are using the user portion

[PATCH 14/20] x86_64: Modify discover_ebda to use virtual address

Signed-off-by: Eric W. Biederman <[EMAIL PROTECTED]> Signed-off-by: Vivek Goyal <[EMAIL PROTECTED]> --- arch/x86_64/kernel/setup.c |4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff -puN arch/x86_64/kernel/setup.c~x86_64-Modify-discover_ebda-to-use-virtual-addresses

[RFC: 2.6 patch] remove broken video drivers

This patch removes video drivers that: - had already been marked as BROKEN in 2.6.0 three years ago and - are still marked as BROKEN. These are the following drivers: - FB_CYBER - FB_VIRGE - FB_RETINAZ3 - FB_ATARI - FB_SUN3 - FB_PM3 Drivers that had been marked as BROKEN for such a long time

[PATCH 7/20] x86_64: cleanup segments

Move __KERNEL32_CS up into the unused gdt entry. __KERNEL32_CS is used when entering the kernel so putting it first is useful when trying to keep boot gdt sizes to a minimum. Set the accessed bit on all gdt entries. We don't care so there is no need for the cpu to burn the extra cycles, and

[PATCH 1/20] x86_64: Align data segment to PAGE_SIZE boundary

o Explicitly align data segment to PAGE_SIZE boundary otherwise depending on config options and tool chain it might be placed on a non PAGE_SIZE aligned boundary and vmlinux loaders like kexec fail when they encounter a PT_LOAD type segment which is not aligned to PAGE_SIZE boundary.

[RFC: 2.6 patch] remove the broken VIDEO_ZR36120 driver

The VIDEO_ZR36120 driver has: - already been marked as BROKEN in 2.6.0 three years ago and - is still marked as BROKEN. Drivers that had been marked as BROKEN for such a long time seem to be unlikely to be revived in the forseeable future. But if anyone wants to ever revive this driver, the

  1   2   3   4   5   6   7   8   >