V1->V2
Some NR_OPEN were left unchanged for alpha, mips & sparc64.
As changing NR_OPEN from 1024*1024 to 16*1024*1024 was considered a litle
bit dangerous, just let it default to 1024*1024 but adds a new sysctl
to let sysadmins change this value.
Thank you
[PATCH] get rid of NR_OPEN and
I just did a very quick glance over the tree. Some extremly highlevel
comments to start with before actually starting the source review:
- why do you need your own libcrc? lib/crc32.c has a crc32_le
- libsa should go. Much of it is just wrappers of kernel functions
that should be used
Greg KH wrote:
> On Mon, Nov 26, 2007 at 08:31:16PM -0800, Andrew Morton wrote:
>> On Wed, 21 Nov 2007 15:16:59 -0700 Andrew Patterson <[EMAIL PROTECTED]>
>> wrote:
>>
>>> The buf in fs/sysfs.c:subsys_attr_store() does not seem to be updated
>>> correctly when returning a negative value
On Wed, 28 Nov 2007 12:47:19 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Andrew Morton wrote:
> > On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <[EMAIL PROTECTED]>
> > wrote:
> >
> >> Hi,
> >
> > (cc linux-scsi, for sym53c8xx)
> >
> >> Soft lockup is detected while bootup with
Andrew Morton wrote:
> On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>
> (cc linux-scsi, for sym53c8xx)
>
>> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
>
> I assume this is a post-2.6.23 regression?
>
>> BUG: soft lockup -
Len Brown <[EMAIL PROTECTED]> writes:
> commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
> (x86: avoid wasting IRQs for PCI devices)
> created a concept of "IRQ compression" on i386
> to conserve IRQ numbers on systems with many
> sparsely populated IO APICs.
>
> The
Vegard Nossum wrote:
General description: kmemcheck will trap every read and write to
memory that was
allocated dynamically (ie. with kmalloc()). If a memory address is
read that has
not previously been written to, a message is printed to the kernel log.
diff --git
On Wed, 28 Nov 2007 11:59:00 +0530 Kamalesh Babulal <[EMAIL PROTECTED]> wrote:
> Hi,
(cc linux-scsi, for sym53c8xx)
> Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
I assume this is a post-2.6.23 regression?
> BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
> NIP:
On Tue, 2007-11-27 at 02:02 -0800, Andrew Morton wrote:
> > +
> > +static pgd_t save_pgd __initdata;
> > +static unsigned long efi_flags __initdata;
> > +/* efi_lock protects efi physical mode call */
> > +static __initdata DEFINE_SPINLOCK(efi_lock);
>
> It's peculiar to have a spinlock in
Yakui,
Can you look at this. Seems to be coming from commit f79f06ab9f86
FixedHW support tries to read MSR with interrupts disabled.
Thanks,
Venki
>-Original Message-
>From: [EMAIL PROTECTED]
>[mailto:[EMAIL PROTECTED] On Behalf Of
>Rafael J. Wysocki
>Sent: Tuesday, November 27,
Hi,
Soft lockup is detected while bootup with 2.6.24-rc3-git2 on powerbox
BUG: soft lockup - CPU#1 stuck for 11s! [insmod:375]
NIP: c002f02c LR: d01414fc CTR: c002f018
REGS: c0077cbef0b0 TRAP: 0901 Not tainted (2.6.24-rc3-git2-autotest)
MSR: 80009032 CR:
commit c434b7a6aedfe428ad17cd61b21b125a7b7a29ce
(x86: avoid wasting IRQs for PCI devices)
created a concept of "IRQ compression" on i386
to conserve IRQ numbers on systems with many
sparsely populated IO APICs.
The same scheme was also added to x86_64,
but later
On Tue, Nov 27, 2007 at 05:49:15PM -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
> > On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:
> > > > From: James Huang [mailto:[EMAIL PROTECTED]
> > > > Sent: Monday, November 26, 2007 2:21 PM
Roland McGrath wrote::
> cf http://lkml.org/lkml/2007/10/3/41
>
> To summarize: on Linux, SA_ONSTACK decides whether you are already on the
> signal stack based on the value of the SP at the time of a signal. If
> you are not already inside the range, you are not "on the signal stack"
> and so
Current Linus tree give me this, with m68k allmodconfig:
FATAL: drivers/bluetooth/btsdio: sizeof(struct sdio_device_id)=12 is not a
modulo of the size of section __mod_sdio_device_table=30.
Fix definition of struct sdio_device_id in mod_devicetable.h
which I haven't seen before. Any ideas?
On Tue, 27 Nov 2007 15:43:57 -0500 "Thomas Tuttle" <[EMAIL PROTECTED]> wrote:
> Hey.
>
> I'm using a git snapshot that gentoo distributed mere hours ago (so I'm
> fairly confident it's current), and I'm getting an Oops when I try to
> load the iwl3945 driver. I've attached it as plain text.
>
On Tue, 27 Nov 2007 17:20:20 -0500 Jeff Dike <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 09:29:23PM +0100, Miklos Szeredi wrote:
> > Sure. The patch works for me, but please check that it also makes
> > sense.
>
> I did - it's a straight-forward leak and fix.
>
Do we have any idea
On Mon, 26 Nov 2007 22:36:17 -0600 Robert Hancock <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] wrote:
> > Question: Why is ksoftirqd eating about 5 to 10 percent of my CPU on an idle
> > system? The problem occurs if I config the kernel with tickless
> > support (i.e. CONFIG_TICK_ONESHOT=y).
On Mon, 26 Nov 2007 20:36:32 -0600 (CST) [EMAIL PROTECTED] wrote:
> Question: Why is ksoftirqd eating about 5 to 10 percent of my CPU on an idle
> system? The problem occurs if I config the kernel with tickless
> support (i.e. CONFIG_TICK_ONESHOT=y). (Thanks to "oprofile" for putting me
> onto
Robert Hancock wrote:
> Larry Finger wrote:
>> If a particular routine needs to lock a mutex, but it may be entered
>> with that mutex already locked,
>> would the following code be SMP safe?
>>
>> hold_lock = mutex_trylock()
>>
>> ..
>>
>> if (hold_lock)
>> mutex_unlock()
>
> Not if another
Sorry, I thought you want a preliminary one, here's the one
tested and including your comments except for one:
if caller holds gpio_lock, gpio_ensure_requested() is actually
safe.
please review:
---
include/asm-generic/gpio.h | 35 +++-
lib/gpiolib.c | 212
This removes the EF_* enum from . It is no longer used,
and duplicates the X86_EFLAGS_* constants from .
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
include/asm-x86/ptrace.h | 22 --
1 files changed, 0 insertions(+), 22 deletions(-)
diff --git
This cleans up arch/x86/kernel/setup64.c to use the X86_EFLAGS_* constants
from instead of the EF_* enum in .
Signed-off-by: Roland McGrath <[EMAIL PROTECTED]>
---
arch/x86/kernel/setup64.c |3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/kernel/setup64.c
On Dienstag 27 November 2007 23:12:20, you (Greg KH) wrote:
> Frank, want me to take the last version you just sent out and update my
> version?
Yes, that would be great.
Thanks a lot,
Frank
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
On Wed, 21 Nov 2007 12:17:14 +0200 Avi Kivity <[EMAIL PROTECTED]> wrote:
> Avi Kivity wrote:
> >
> >> The make headers_check fails,
> >>
> >> CHECK include/linux/usb/gadgetfs.h
> >> CHECK include/linux/usb/ch9.h
> >> CHECK include/linux/usb/cdc.h
> >>
Hi,
The environment of a device is as below:
kernel version is 2.6.14, it is OS distribution kernel Fedora 2. The
file system is ext3. The cpu type is arm9.
I use "yafc" to upload the file from sd card in the device to ftp
server through wifi.
I have tried two times,both of them calls below
Larry Finger wrote:
If a particular routine needs to lock a mutex, but it may be entered with that
mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
..
if (hold_lock)
mutex_unlock()
Not if another task could be acquiring that lock at the same
On 11/27/07 7:27 PM, "Rusty Russell" <[EMAIL PROTECTED]> wrote:
> On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
>> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
>> Explicitly documenting what comprises the kernel API (external,
>> supported) and what comprises the kernel
If a particular routine needs to lock a mutex, but it may be entered with that
mutex already locked,
would the following code be SMP safe?
hold_lock = mutex_trylock()
...
if (hold_lock)
mutex_unlock()
Thanks,
Larry
-
To unsubscribe from this list: send the line "unsubscribe
On Tue, 27 Nov 2007, Rafael J. Wysocki wrote:
> > in recent kernel, I got the following warnings while booting. It's ACPI
> > related. Does anybode care? Lenovo ThinkPad T61 (6465CTO).
Could we know the BIOS version, please?
--
"One disk to rule them all, One disk to find them. One disk to
Greg KH <[EMAIL PROTECTED]> wrote:
> Jonathan, I used your old lwn.net article about kobjects as the basis
> for this document, I hope you don't mind
Certainly I have no objections, I'm glad it was useful.
A few little things...
> It is rare (even unknown) for kernel code to create a
On Wed, 28 Nov 2007 01:49:54 +0100 =?utf-8?q?Ferenc_W=C3=A1gner?= wrote:
> Also remove trailing spaces from multivalued files.
>
> This fixes output like for example:
>
> $ od -c /sys/class/net/bond0/bonding/slaves
> 000 e t h - l e f t e t h - r i g
>
Update gpiolib to use a table of per-GPIO "struct gpio_desc" instead of
a table of "struct gpio_chip".
- Change "is_out" and "requested" from arrays in "struct gpio_chip" to
bit fields in "struct gpio_desc", eliminating ARCH_GPIOS_PER_CHIP.
- Stop overloading "requested" flag with "label"
On Tue, 27 Nov 2007 13:23:08 +0100 Pavel Machek <[EMAIL PROTECTED]> wrote:
> If hpet is not enabled in config, its init should not pretend to work,
> and people should not try to get time from it.
>
> Signed-off-by: Pavel Machek <[EMAIL PROTECTED]>
>
> diff --git a/include/asm-x86/hpet.h
On Tue, 2007-11-27 at 17:02 -0800, Fernando Lopez-Lezcano wrote:
> Hi Ingo... any hope of an updated realtime patch for 2.6.22.14? I'm
> having problems with 2.6.23.1 + rt11 (I spent the morning rediffing
> agains 2.6.23.9 and just _now_ pressed reload in my browser and there it
> is..., rt12 for
Christoph Lameter writes:
> On Wed, 28 Nov 2007, Paul Mackerras wrote:
>
> > Did you try both 32-bit (CONFIG_64BIT=n) and 64-bit (CONFIG_64BIT=y)
> > configurations? The paca only exists in 64-bit kernels.
>
> I build both and there is no dependency on 32bit or 64 bit in
>
On Tuesday 27 November 2007 16:35:42 Tom Tucker wrote:
> On Tue, 2007-11-27 at 15:49 +1100, Rusty Russell wrote:
> Explicitly documenting what comprises the kernel API (external,
> supported) and what comprises the kernel implementation (internal, not
> supported).
But the former is currently an
On Tuesday 27 November 2007 21:50:16 Andi Kleen wrote:
> Goals are:
> - Limit the interfaces available for out of tree modules to reasonably
> stable ones that are already used by a larger set of drivers.
Not the goals. I haven't seen the *problem* yet.
> - Limit size of exported API to make
On Wednesday 28 November 2007 05:14:47 Christoph Lameter wrote:
> On Tue, 27 Nov 2007, Rusty Russell wrote:
> > Have you considered moving x86-64's setup_per_cpu_areas into generic
> > code? It's a bit messier because some archs might not have set up NUMA
> > stuff yet, but it's logically
Adrian Bunk wrote:
On Tue, Nov 27, 2007 at 01:15:23PM -0800, Rick Jones wrote:
The real problem is that these drivers are not in the upstream kernel.
Are there common reasons why these drivers are not upstream?
One might be that upstream has not accepted them. Anything doing or
smelling
Nacked-by: "Eric W. Biederman" <[EMAIL PROTECTED]>
Andrew Morton <[EMAIL PROTECTED]> writes:
> I don't see why the schedule() will not return? Because the task has
> PF_EXITING set? Doesn't TASK_DEAD do that?
This appears to be a work around for an old bug only present in sles9.
It looks
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
>>
>> So you may need to apply this one too (this one is needed to fix the
>> second bug, my previous patch is needed after applying this one):
>
> thinking what happened once already, I think this would be more
> debuggable but maybe not... dunno.
[EMAIL PROTECTED] wrote:
The patch titled
git-nfsd-broke-reiser4
has been removed from the -mm tree. Its filename was
git-nfsd-broke-reiser4.patch
This patch was dropped because it was folded into reiser4.patch
--
Subject:
Pavel Machek wrote:
> Hi!
>
>>> kernel: [734344.717844] irq 21: nobody cared (try booting with the
>>> "irqpoll" option)
>>> kernel: [734344.717866]
>> Your machine decided to emit interrupt 21 without an apparent reason.
>> Whatever caused that made the kernel shut down IRQ 21 at which point
Andrea Arcangeli <[EMAIL PROTECTED]> writes:
> On Tue, Nov 27, 2007 at 02:38:52PM -0800, Andrew Morton wrote:
>> I don't see why the schedule() will not return? Because the task has
>> PF_EXITING set? Doesn't TASK_DEAD do that?
>
> Ouch, I assumed you couldn't sleep safely anymore in
On Mon, Nov 26, 2007 at 06:39:58PM -0800, Paul E. McKenney wrote:
> On Mon, Nov 26, 2007 at 02:48:08PM -0800, James Huang wrote:
> >
> > > -Original Message-
> > > From: James Huang [mailto:[EMAIL PROTECTED]
> > > Sent: Monday, November 26, 2007 2:21 PM
> > > To: James Huang
> > >
On Wed, Nov 28, 2007 at 02:21:29AM +0100, Andrea Arcangeli wrote:
> On Tue, Nov 27, 2007 at 02:38:52PM -0800, Andrew Morton wrote:
> > I don't see why the schedule() will not return? Because the task has
> > PF_EXITING set? Doesn't TASK_DEAD do that?
>
> Ouch, I assumed you couldn't sleep
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 27 Nov 2007 14:20:22 +0100
> Andrea Arcangeli <[EMAIL PROTECTED]> wrote:
>
>> Hi,
>>
>> this patch fixes a sles9 system hang in start_this_handle from a
>> customer with some heavy workload where all tasks are waiting on
>> kjournald to commit
On Tue, Nov 27, 2007 at 04:36:45PM +0100, Marco Pracucci wrote:
> Hi Dave,
> > This problem is caused by the workqueue in hci_sysfs.c, the del_conn
> > is scheduled after the add_conn with same bluetooth address.
> > Please try this patch:
> >
> >
> > The bluetooth hci
Hi Ingo... any hope of an updated realtime patch for 2.6.22.14? I'm
having problems with 2.6.23.1 + rt11 (I spent the morning rediffing
agains 2.6.23.9 and just _now_ pressed reload in my browser and there it
is..., rt12 for 2.6.23.9!, argh! :-) and wanted to compare with 2.6.22.x
and the latest I
On Tue, Nov 27, 2007 at 02:38:52PM -0800, Andrew Morton wrote:
> I don't see why the schedule() will not return? Because the task has
> PF_EXITING set? Doesn't TASK_DEAD do that?
Ouch, I assumed you couldn't sleep safely anymore in release_task
given it's the function that will free the task
Hi Linus,
Here's some more Ocfs2 patches for 2.6.24. This series also includes
a small performance fixup from Jan Kara. The rest of the patches are bug
fixes or very trivial cleanups.
Please pull from 'upstream-linus' branch of
Kjartan Maraas wrote:
> I get this exact error message on a normal first time boot here. I'm
> using the latest fedora development kernel which is 2.6.24-rc2-git6
> based. And I have the latest BIOS from HP IIRC.
>
> This is an HP nc6400 intel based laptop:
Care to post boot dmesg? Or does
Hi.
More than 2 years ago I wrote a small non-portable patch [1] to gather
some statistics
about keyboard usage[2] ( I show the counters with modulo 10 but still this is a
security risk. Perhaps some random noise should be added ).
[1]
Andrew Morton <[EMAIL PROTECTED]> writes:
> On Tue, 27 Nov 2007 10:56:43 +0100 Ferenc Wagner <[EMAIL PROTECTED]> wrote:
>
>>> - raise patches against the latest Linus tree
>>> (ftp://ftp.kernel.org/pub/linux/kernel/v2.6/snapshots/)
>>
>> I thought it was better to change to git. Isn't it so?
>>
Code for rendering multivalue sysfs files occurs three times
in this module. Rename 'buffer' to 'buf' in the first, for
the sake of consistency.
Signed-off-by: Ferenc Wágner <[EMAIL PROTECTED]>
---
drivers/net/bonding/bond_sysfs.c |9 -
1 files changed, 4 insertions(+), 5
On Wed, 28 Nov 2007 00:52:38 +0100 Willy Tarreau wrote:
> Tilman, there was a howto by Jeff Garzik I believe. It helped me
> a lot when I didn't understand a damn command, even if it was in
> the very old ages (version 0.5 or something like this). The tutorials
> on the GIT site are quite good
The previous code returned '\n' (that is, a single empty line)
from most files, with one exception (xmit_hash_policy), where
it returned 'NA\n'. This patch consolidates each file to return
nothing at all if not applicable, not even a '\n'.
I find this behaviour more usual, more useful, more
Also remove trailing spaces from multivalued files.
This fixes output like for example:
$ od -c /sys/class/net/bond0/bonding/slaves
000 e t h - l e f t e t h - r i g
020 h t \n \0
025
It mostly entails deleting '+1'-s after sprintf()
Neil Horman <[EMAIL PROTECTED]> writes:
>> Close. There are two options with virtual wire mode.
>> - Either the local apic is in virtual wire mode, and somehow the
>> legacy interrupts make it to the local cpu.
> I assume this is the case if the ioapic is also in virtual wire
> mode.
No.
On Wed, 28 Nov 2007 00:52:38 +0100
Willy Tarreau <[EMAIL PROTECTED]> wrote:
> On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> > Greetings,
> >
> > Google is your friend. If you're looking for irc channels you can always
> > try #git at irc.freenode.net
> > Git
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make hibernation messages start with one common prefix "PM: " and use
the word "hibernation" in messages as a synonym of "suspend to disk".
Turn some KERN_INFO messages into debug ones.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix a comment in kernel/power/disk.c so that it doesn't contain lines
longer that 80 characters.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/disk.c |4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
Index:
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Remove the unnecessary extern declaration of resume_file[]
from kernel/power/swap.c .
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/swap.c |2 --
1 file changed, 2 deletions(-)
Index: linux-2.6/kernel/power/swap.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make suspend messages start with one common prefix "PM: ".
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
---
kernel/power/main.c |6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
Index: linux-2.6/kernel/power/main.c
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Fix a comment in kernel/power/main.c so that it doesn't contain lines
longer that 80 characters.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek <[EMAIL PROTECTED]>
---
kernel/power/main.c |4 ++--
1 file changed, 2
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Move the low level restore code to kernel/power/disk.c , since the
corresponding low level hibernation code is already there.
Make restore fail if device_power_down(PMSG_PRETHAW) returns an
error.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Hi,
This is the second revision of the series of suspend and hibernation cleanup
patches I sent yesterday.
The patches are on top of the suspend branch of the linux-acpi-2.6 tree.
Please review.
Greetings,
Rafael
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
From: Rafael J. Wysocki <[EMAIL PROTECTED]>
Make the new suspend debug facility code depend on CONFIG_SUSPEND,
as appropriate, to remove the compiler warning printed when CONFIG_PM is set
and CONFIG_SUSPEND is not set.
Signed-off-by: Rafael J. Wysocki <[EMAIL PROTECTED]>
Acked-by: Pavel Machek
* Jeremy Fitzhardinge <[EMAIL PROTECTED]> wrote:
> This unifies the set/clear/test bit functions of asm/bitops.h.
great! I've added your 3 patches to x86.git. It built and booted fine.
Ingo
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a
[EMAIL PROTECTED] wrote:
Hello Robert,
I've attached additional detail on the config of the misbehaving system
including output from oprofile and PowerTop. PowerTop output leads me to
believe that maybe this is an interaction between my bridged ethernet
setup and dynticks? Hmmm...
Don't know
Adrian Bunk wrote, On 11/27/2007 11:53 PM:
> On Tue, Nov 27, 2007 at 11:15:48PM +0100, Jarek Poplawski wrote:
...
> Most Google hits are about abortion.
>
> The fact that people use this term in some completely different
> context does not give it the meaning you implied it had.
>
> Oh, and
Ben Woodard <[EMAIL PROTECTED]> writes:
> Eric W. Biederman wrote:
>> Neil Horman <[EMAIL PROTECTED]> writes:
>>
..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>>
>> Ben, what chipset is this?
>
> nVidia MCP55 pro
>
> It is the original version of
>
On Wed, 28 Nov 2007, Andi Kleen wrote:
> It was demonstrated useful for some specific cases, like context switch early
> fetch on IA64. But I agree the prefetch on each list_for_each() is probably
> a bad idea and should be removed. Will also help code size.
Looks like sum_vm_events() is only
On Tue, Nov 27, 2007 at 03:01:08PM -0800, Andrew Morton wrote:
> > +#ifdef UML_CONFIG_NO_HZ
>
> Nothing ever defines this?
$ grep HZ obj/arch/um/include/uml-config.h
#define UML_CONFIG_NO_HZ 1
uml-config.h is auto-generated to provide the config definitions to the
userspace side of UML.
On Tue, 27 Nov 2007, Andrew Morton wrote:
> I don't recall anyone ever demonstrating that prefetch is useful in-kernel.
vmstat: remove prefetch
Remove the prefetch logic in order to avoid touching impossible per cpu
areas.
Signed-off-by: Christoph Lameter <[EMAIL PROTECTED]>
---
mm/vmstat.c
> clean. Unless there are major problems with it this looks like 2.6.25
> stuff. Would you mind to send updates/fixes against this tree?
I'd be glad to. I'd be very happy to see this stuff make 2.6.25.
Thanks,
Roland
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
Christoph Lameter wrote:
On Tue, 27 Nov 2007, Randy Dunlap wrote:
+config ARCH_SETS_UP_PER_CPU_AREA
+ bool
+ default y
def_bool y
is the preferred form for those 2-liners above...
+
config ARCH_NO_VIRT_TO_BUS
def_bool y
Ok. Changed.
x86 should use
On Tue, 27 Nov 2007, Randy Dunlap wrote:
> > +config ARCH_SETS_UP_PER_CPU_AREA
> > + bool
> > + default y
>
> def_bool y
> is the preferred form for those 2-liners above...
>
>
> > +
> > config ARCH_NO_VIRT_TO_BUS
> > def_bool y
> >
Ok. Changed.
x86 should use
config
* Roland McGrath <[EMAIL PROTECTED]> wrote:
> > I did do an experimental will-it-apply and got a tremendous number
> > of rejects against the x86 git tree, almost all of which went away
> > when `patch -l' was used. Seems that someone has gone on a
> > whitespace rampage through
> Would anyone have any problems with code that simply verified that the
> state which we are restoring allowed interrupts to get to the processor
> that we are currently crashing on and if not, poked in a reasonable value.
Sounds reasonable by itself.
>
> Yes this would add some complexity
On Tue, Nov 27, 2007 at 11:55:11PM +0100, Kristoffer Ericson wrote:
> Greetings,
>
> Google is your friend. If you're looking for irc channels you can always try
> #git at irc.freenode.net
> Git howto/tutorial/... doesn't belong in the kernel mailinglist.
Well, I don't agree with you. His
On Tue, 27 Nov 2007, Andrew Morton wrote:
> On Tue, 27 Nov 2007 12:47:46 -0800 (PST)
> Davide Libenzi <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 27 Nov 2007, Andrew Morton wrote:
> >
> > > On Sun, 25 Nov 2007 14:14:19 -0800 Davide Libenzi <[EMAIL PROTECTED]>
> > > wrote:
> > >
> > > > +static
White space and coding style clean up.
Make process_32/64.c similar.
Signed-off-by: Hiroshi Shimamoto <[EMAIL PROTECTED]>
---
arch/x86/kernel/process_32.c | 20 ++--
arch/x86/kernel/process_64.c | 307 +-
2 files changed, 163 insertions(+), 164
This unifies the set/clear/test bit functions of asm/bitops.h.
I have not attempted to merge the bit-finding functions, since they
rely on the machine word size and can't be easily restructured to work
generically without a lot of #ifdefs. In particular, the 64-bit code
can assume the presence
On Tue, Nov 27, 2007 at 03:42:13PM -0800, Andrew Morton wrote:
> On Tue, 27 Nov 2007 15:22:56 -0800 (PST)
> Christoph Lameter <[EMAIL PROTECTED]> wrote:
>
> > On Tue, 27 Nov 2007, Andrew Morton wrote:
> >
> > > The prefetch however might still need some work - we can indeed do
> > > prefetch()
The patch to suppress bitops-related warnings added a pile of ugly
casts. Many of these were related to the management of x86 CPU
capabilities. Clean these up by adding specific set/clear_cpu_cap
macros, and use them consistently.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi
Add casts to appropriate places to silence spurious bitops warnings.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
arch/x86/kernel/setup_64.c | 31 ---
arch/x86/kernel/smpboot_64.c |4 ++--
arch/x86/mm/numa_64.c
I forgot to cc the list.
--mgross
- Forwarded message from mark gross <[EMAIL PROTECTED]> -
Date: Tue, 27 Nov 2007 15:46:09 -0800
From: mark gross <[EMAIL PROTECTED]>
To: Andrew Morton <[EMAIL PROTECTED]>
Reply-To: [EMAIL PROTECTED]
Subject: intel-iommu-PMEN-think-oh patch.
I screwed
On Tue, 27 Nov 2007 15:22:56 -0800 (PST)
Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007, Andrew Morton wrote:
>
> > The prefetch however might still need some work - we can indeed do
> > prefetch() against a not-possible CPU's memory here. And I do recall that
> > 4-5 years
On Mon, 26 Nov 2007 16:14:12 -0800 Christoph Lameter wrote:
> The use of the __GENERIC_PERCPU is a bit problematic since arches
> may want to run their own percpu setup while using the generic
> percpu definitions. Replace it through a kconfig variable.
>
> Cc: Rusty Russell <[EMAIL PROTECTED]>
On Tue, Nov 27, 2007 at 03:38:52PM -0700, Eric W. Biederman wrote:
> Neil Horman <[EMAIL PROTECTED]> writes:
>
> >>
> >> ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
>
> Ben, what chipset is this?
>
> >
> > Ok, I think from what I understand of what we're reading here, the apic2 =
> >
Andi Kleen wrote:
> On Wednesday 28 November 2007 00:01:26 Jeremy Fitzhardinge wrote:
>
>> Add casts to appropriate places to silence spurious bitops warnings.
>>
>
> Looks a bit ugly. Perhaps it would be better to define standard wrappers
>
> clear_bit_unaligned/any/bettername() etc. ?
Kyle Moffett wrote:
> On Nov 27, 2007, at 17:49:18, Jeremy Fitzhardinge wrote:
>> Rafael J. Wysocki wrote:
>>> Well, this is more-or-less how we all imagine that should be done
>>> eventually.
>>>
>>> The main problem is how to implement it without causing too much
>>> breakage. Also, there are
On Tue, Nov 27, 2007 at 06:10:42PM -0500, Kyle McMartin wrote:
> On Tue, Nov 27, 2007 at 03:02:52PM -0800, Greg KH wrote:
> > Last updated November 27, 2008
> >
>
> The future is now! ;-)
/me goes off to recharge the flux generator...
Heh, thanks, I'll go fix that.
greg k-h
-
To unsubscribe
Andi Kleen wrote:
Are we putting the system back in PIC mode or virtual wire mode? I have
not seen systems which support PIC mode. All latest systems seems
to be having virtual wire mode. I think in case of PIC mode, interrupts
Yes it's probably virtual wire. For real PIC mode we would need
On Tue, 27 Nov 2007, Andrew Morton wrote:
> The prefetch however might still need some work - we can indeed do
> prefetch() against a not-possible CPU's memory here. And I do recall that
> 4-5 years ago we did have a CPU (one of mine, iirc) which would oops when
> prefetching from a bad address.
On Tue, 27 Nov 2007 15:12:41 -0800
Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 27 Nov 2007 23:16:28 +0100
> Andi Kleen <[EMAIL PROTECTED]> wrote:
>
> > On Tue, Nov 27, 2007 at 01:50:53PM -0800, [EMAIL PROTECTED] wrote:
> > > Change loops controlled by 'for (i = 0; i < NR_CPUS; i++)' to
On Wed, Nov 28, 2007 at 12:02:08AM +0100, Jarek Poplawski wrote:
> Jarek Poplawski wrote, On 11/27/2007 11:15 PM:
> ...
>
> > Otherwise it's not so hard to overlook some stagnation.
>
> Btw., after this 'forking' thing etc. it seems I might have lost the point
> a little: which removed choices
Greg KH wrote:
> Based on an original article by Jon Corbet for lwn.net written October 1,
> 2003 and located at http://lwn.net/Articles/51437/
>
> Last updated November 27, 2008
^^^
Wow, that's impressive: both kobjects de-mystified and time travel made
possible!
1 - 100 of 760 matches
Mail list logo
