On Mon, 2 Apr 2007 19:03:16 +0400
Alexey Dobriyan <[EMAIL PROTECTED]> wrote:
> +int lookup_module_symbol_attrs(unsigned long addr, unsigned long *size,
> + unsigned long *offset, char *modname, char *name)
> +{
> + struct module *mod;
> +
> + mutex_lock(&module_mutex);
On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> Sparc does the same thing, it's a common convention and you really
> should not break it.
I thought that argument was lost many years ago. It _used_ to be a
common convention; we got better.
> Every powerpc and sparc system out that is usin
Hi all,
the following patch fixes a kernel bug in depca_platform_probe().
We don't use a dynamic pointer for pldev->dev.platform_data, so it seems
that the correct way to proceed if platform_device_add(pldev) fails is
to explicitly set the pldev->dev.platform_data pointer to NULL, before
calling
On Tue, Apr 03, 2007 at 07:57:22PM -0400, David Woodhouse wrote:
> > The TTY_MAJOR should have never belonged to 8250.c in the first place.
> > I know it's just my opinion, but I think this major device should be
> > owned by the serial core, and it shouldn't matter what chip drives each
> > indivi
On Tue, Apr 03, 2007 at 08:12:48PM -0400, David Woodhouse wrote:
> On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> > Sparc does the same thing, it's a common convention and you really
> > should not break it.
>
> I thought that argument was lost many years ago. It _used_ to be a
> common
On Tue, 2007-04-03 at 16:19 +1000, David Chinner wrote:
> Rusty, can you redo you patch on top of this one? I'll
> add it to my QA tree as well...
Done.
Cleanup and kernelify shrinker registration.
I can never remember what the function to register to receive VM pressure
is called. I have to tr
Ulrich Drepper wrote:
Davide Libenzi wrote:
It sucks when seen from a micro-bench POV, but does it really matter
overall? The vast majority of software usually calls
sysconf(_SC_NPROCESSORS_*) with very little frequency (mostly once at
initialization time) anyway. That's what 50us / call?
Th
On Tue, Apr 03, 2007 at 07:28:36PM -0400, David Woodhouse wrote:
> I agree to a certain extent -- but then again, why should a user know or
> care about the name /dev/ttyS0 _either_? A GUI PPP dialer should be
> listing the available serial ports in the system whatever their names
> are.
The momen
The ati_remote driver is a little too sensitive for my wife... if you
do anything but barely tap the button you can get multiple events
reported. We prefer a more conservative no-repeat setting. This is a
pretty trivial patch which just makes one hard coded value soft
configurable and does not c
H. Peter Anvin wrote:
> Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
J
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at
Jeremy Fitzhardinge wrote:
H. Peter Anvin wrote:
Sounds like it would need a device which can be waited upon for changes.
A vdso-like shared page could have a futex in it.
Yes, but a futex couldn't be waited upon with a bunch of other things as
part of a poll or a select. The cost of readi
On Apr 2 2007 18:59, Pavel Machek wrote in http://lkml.org/lkml/2007/4/3/85:
>
>> + * to give the victim some idea of what went wrong
>> + */
>> +void printk_all_partitions(void)
>> +{
>> +int n;
>> +struct gendisk* sgp;
>> +mutex_lock(&block_subsys_lock);
>
>tabs-vs-spaces problem
On Apr 2 2007 12:41, Eric Dumazet wrote:
>
>The following patch does the right thing for pipes, I let you doing
>the same for sockets...
Is struct sock->sk_receive_queue->qlen actually the thing I am
looking for? (Previously, I had struct sock->sk_rcvbuf, which was
obviously wrong.)
Thanks,
Jan
Arnd Bergmann wrote:
On Wednesday 04 April 2007, H. Peter Anvin wrote:
Note that at least for PIO-based devices, there is nothing that says you
can't implement PCI over another transport, if you wish. It's really
just a very simple RPC protocol.
The PIO aspect of PCI is simple, yes, except o
On Tue, 2007-04-03 at 15:10 -0700, Brad Boyer wrote:
> I suppose my opinion on this shows that I didn't come from the x86
> side of Linux.
Perhaps, yes -- if you were just an x86 user you'd be unlikely to care
about the issue at all -- mostly because it's never been a problem
there. Not for the re
Jiri Kosina wrote:
> Current implementation (as you can see it in -mm or in my hid.git tree) is
> creating hidraw interface for just every HID device/interface. But this
> will get changed before merge.
>
> Passing just everything to hidraw is not a good option, as this could lead
> to confusion
On Tue, 2007-04-03 at 20:12 -0400, David Woodhouse wrote:
> On Tue, 2007-04-03 at 17:02 -0700, David Miller wrote:
> > Sparc does the same thing, it's a common convention and you really
> > should not break it.
>
> I thought that argument was lost many years ago. It _used_ to be a
> common convent
On Tue, 2007-04-03 at 16:56 -0700, David Miller wrote:
> From: David Woodhouse <[EMAIL PROTECTED]>
> Date: Tue, 03 Apr 2007 19:28:36 -0400
>
> > Abusing the 8250 device numbers prevents the 8250 module from being
> > loaded at the same time as pmac_zilog, and means you can't have both
> > internal
This updates /proc/acpi/wakeup to be more informative, primarily by showing
the sysfs node associated with each wakeup-enabled device. Example:
Device S-state Status Sysfs node
PCI0 S4 disabled no-bus:pci:00
PS2M S4 disabled pnp:00:05
P
On Tue, 3 Apr 2007, Badari Pulavarty wrote:
> Seems to be an issue with calibrate_delay() spinning in a tight
> loop :(
>
> BTW, machine boots fine with SLAB code - not sure why ?
Interrupt disabled sigh.
Here is the fix:
SLUB: Fix numa bootstrap
NUMA bootstrap calls new_slab() if more tha
From: David Woodhouse <[EMAIL PROTECTED]>
Date: Tue, 03 Apr 2007 20:54:10 -0400
> Yes, it would be theoretically possible to come up with a way to share
> minor numbers so we can use 'ttyS0' for the first serial port regardless
> of what type of port it is. We could take the arch-specific hack tha
Randy Dunlap wrote:
On Tue, 03 Apr 2007 16:22:22 +0800 Carlo Florendo wrote:
Hello,
I'm not sure whether a fix is necessary for the following scenario.
The kernel configure target "make menuconfig" requires ncurses. FWIW, it
could probably be better if the error message would indicate that
> I totally agree with Paul, the onboard serial device should get
> ttyS0 regardless of what hardare is used to drive it.
Thats between you and udev.
> Generalizing this minor number allocation for ttyS? might be the
> best way to handle this.
Again this is a udev issue. udev can certainly do a
From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
Date: Wed, 04 Apr 2007 11:13:12 +1000
> It worked before the new serial core, we had a "tweak" in the old 8250
> driver to be able to share minors, but that got busted when Russell
> rewrote the whole thing. I remember asking him back when he still
From: Alan Cox <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 02:19:24 +0100
> > I totally agree with Paul, the onboard serial device should get
> > ttyS0 regardless of what hardare is used to drive it.
>
> Thats between you and udev.
That might be true when udev exists, but it doesn't for the consol
Jan Engelhardt wrote:
On Apr 3 2007 08:18, Randy Dunlap wrote:
Hi,
Without ncurses installed, you should see these messages:
echo " *** Unable to find the ncurses libraries."
echo " *** make menuconfig require the ncurses libraries"
echo " *** "
echo " *** Instal
> The TTY_MAJOR should have never belonged to 8250.c in the first place.
> I know it's just my opinion, but I think this major device should be
> owned by the serial core, and it shouldn't matter what chip drives each
> individual port. Each hardware driver should just register with the
> core how
On Tue, Apr 03, 2007 at 08:54:10PM -0400, David Woodhouse wrote:
> But why? There's nothing special and magical about the number 64 and the
> letters 't' 't' 'y' and 'S'. And if you have broken software which only
> works with ttyS[0123] then you can still create device nodes or symlinks
> to work
> I don't need to know anything about the inanrds of my computer to
> bring up the ethernet interface, me caveman me bringup eth0, me on
> network, caveman happy. The same should be true for serial ports.
You don't get machines with 64 ethernet ports on add-in cards. There are
good reasons for th
On Tue, 2007-04-03 at 18:17 -0700, David Miller wrote:
> From: Benjamin Herrenschmidt <[EMAIL PROTECTED]>
> Date: Wed, 04 Apr 2007 11:13:12 +1000
>
> > It worked before the new serial core, we had a "tweak" in the old 8250
> > driver to be able to share minors, but that got busted when Russell
> >
> Using different majors for different instances of the exact same kind
> of device is really not smart. It's a serial port, and if you try
> to dress it up to be something else you run into all kinds of problems.
Disagree. There are lots of good reasons you need to know which
port/which card/whi
Remove some unneeded include files from epoll code.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c
===
--- linux-2.6.21-rc5.mm4.orig/fs/eventpoll.c2007-04-03 17:59:54.0
-0700
+++
Epoll is either compiled it, or not (if EMBEDDED). Remove the module code
and use fs_initcall().
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c
===
--- linux-2.6.21-rc5.mm4.orig/fs/eventpoll.
Add "noreplace-smp" to disable SMP instruction replacement.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |6 ++
arch/i386/kernel/alternative.c | 23 +++
2 files changed, 25 insertions(+), 4 deletions(-)
==
Re-arrange epoll code to avoid static functions pre-declarations, and apply
akpm-filter on it.
Signed-off-by: Davide Libenzi
- Davide
Index: linux-2.6.21-rc5.mm4/fs/eventpoll.c
===
--- linux-2.6.21-rc5.mm4.orig/fs/eventpoll.c
> my opinion. I do understand that 8250 compatible chips are very common
> and are the most likely serial chips to be used with Linux. However, I
> will point out that the define is TTY_MAJOR, not 8250_MAJOR. It seems
> to me that whoever named it was thinking in more generic terms.
The define goe
On Mon, 02 Apr 2007 22:47:45 PDT, Andrew Morton said:
> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
So I was looking at a patch for ACPI_SLEEP that went around a moment ago,
and ended up doing a 'make menuconfig'.
I do a '/ACPI_SLEEP' inside that, and
Add "noreplace-paravirt" to disable paravirt_ops patching.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
---
Documentation/kernel-parameters.txt |3 +++
arch/i386/kernel/alternative.c | 13 +
2 files changed, 16 insertions(+)
On Wed, 4 Apr 2007, Alan Cox wrote:
I don't need to know anything about the inanrds of my computer to
bring up the ethernet interface, me caveman me bringup eth0, me on
network, caveman happy. The same should be true for serial ports.
You don't get machines with 64 ethernet ports on add-in ca
The other symbols used to delineate the alt-instructions sections have
the form __foo/__foo_end. Rename parainstructions to match.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
Cc: Rusty Russell <[EMAIL PROTECTED]>
---
arch/i386/kernel/alternative.c |
Hi Andi,
Here's a little batch of cleanups:
- re-enable VDSO when PARAVIRT is enabled
- make the parainstructions symbols match the
other altinstructions naming convention
- add kernel command-line options to disable altinstructions for
smp and pv_ops
Oh, and I'm mailing your noreplaceme
Everyone wants VDSO to be enabled by default. COMPAT_VDSO still needs
a fix, but with luck that will turn up soon.
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
---
arch/i386/kernel/sysenter.c |4
1 file changed, 4 deletions(-)
noreplacement is dangerous on modern systems because it will not replace the
context switch FNSAVE with SSE aware FXSAVE. But other places in the kernel
still assume
SSE and do FXSAVE and the CPU will then access FXSAVE information with
FNSAVE and cause corruption.
Easiest way to avoid this is to
The .smp_altinstructions section and its corresponding symbols are
completely unused, so remove them.
Also, remove stray #ifdef __KENREL__ in asm-i386/alternative.h
Signed-off-by: Jeremy Fitzhardinge <[EMAIL PROTECTED]>
Cc: Andi Kleen <[EMAIL PROTECTED]>
---
arch/i386/kernel/alternative.c | 3
> > You don't get machines with 64 ethernet ports on add-in cards. There are
> > good reasons for the naming schemes in use.
>
> I've seen machines offering up to 48, what's the magic number that makes you
> need to chagne nameing schemes?
Have you tried working with 48 ports when they are not n
On Tue, 2007-04-03 at 11:57 -0700, Daniel Walker wrote:
> With 2.6.21-rc5-rt8 / i386 . If I disable wakeup timing , and enable
> interrupt off timing with latency tracing I can cause,
>
> BUG: scheduling with irqs disabled: IRQ-16/0x/909
> caller is rt_spin_lock_slowlock+0x94/0x190
> [] s
From: Alan Cox <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 02:36:37 +0100
> I've no fundamental problem with S0->console port 1, S1 -> console port 2
> etc, but the general notion that type and positional information doesn't
> matter is complete and utter bollocks when you try and apply it to any
>
From: David Lang <[EMAIL PROTECTED]>
Date: Tue, 3 Apr 2007 18:07:06 -0700 (PDT)
> I've seen machines offering up to 48, what's the magic number that makes you
> need to chagne nameing schemes?
Yep, excellent point.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the
From: Alan Cox <[EMAIL PROTECTED]>
Date: Wed, 4 Apr 2007 02:44:00 +0100
> Well the better designed serial setups on Linux use numbering so that you
> can look on the multiplexor boxes and know straight away what the
> correlation between port number and name is. In the same was as "S0 is
> console
On Wed, 4 Apr 2007, Alan Cox wrote:
You don't get machines with 64 ethernet ports on add-in cards. There are
good reasons for the naming schemes in use.
I've seen machines offering up to 48, what's the magic number that makes you
need to chagne nameing schemes?
Have you tried working with 48
Hi;
The errno "-6" is defined as:
#define ENXIO6 /* No such device or address*/
You can try to retrieve the rootfs and add the necessary device file
to it, then reflash the rootfs.
I'm Sorry, I have no embedded environment to test.
Regards
dave
2007/4/3, Tom Strader <[EMAIL
On Tue, 3 Apr 2007, David Lang wrote:
so leave all the ports numbered 0-49, but let people who need to know run a
tool (even if it's dmesg -s 20 |grep ttyS) to learn the details of what
hardware is used to run what port.
and by the way, this is exactly what I do on machines with different
On Tue, 2007-04-03 at 18:06 -0700, Jeremy Fitzhardinge wrote:
> plain text document attachment (fix-parainstructions-name.patch)
> The other symbols used to delineate the alt-instructions sections have
> the form __foo/__foo_end. Rename parainstructions to match.
OK, I guess this is an area where
Andrew wrote:
> I'd have thought that in general an application should be querying its
> present affinity mask - something like sched_getaffinity()? That fixes the
> CPU hotplug issues too, of course.
The sched_getaffinity call is quick, too, and it nicely reflects any
cpuset constraints, while s
Paa Paa wrote:
Q: What conclusion can I make on "hdparm -t" results or can I make
any conclusions? Do I really have lower performance with NCQ or not?
If I do, is this because of my HD or because of kernel?
What IO scheduler are you using? If AS or CFQ, could you try with
deadline?
I was
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
> an abstraction of "serial port" as far as the user is concerned. On
> Solaris, I can say "/dev/term/a" and know that I will get the first
> serial port if it is available without needing to care if it is the
> zs, se or asy driver talking to the
On 04/03/2007 08:32 PM, Pekka J Enberg wrote:
Please enable CONFIG_DEBUG_SLAB now and reproduce. It should tell us
what's going wrong there.
Taking forever to reproduce in as far as getting the oops. The thing is
now just locking hard each time. Will keep on trying...
Rene.
-
To unsubscrib
Once upon a time, Brad Boyer <[EMAIL PROTECTED]> said:
>The point is that people are used to having "ttyS0" mean the first
>onboard serial port.
My first serial port is a USB dongle and is ttyUSB0. If the argument is
that all serials should be ttyS[0-9]+, are you going to change USB
adapters as
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
> On Mon, 02 Apr 2007 22:47:45 PDT, Andrew Morton said:
> > ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.21-rc5/2.6.21-rc5-mm4/
>
> So I was looking at a patch for ACPI_SLEEP that went around a moment ago,
> and ende
Eric Dumazet wrote:
Andrew Morton a écrit :
On Tue, 3 Apr 2007 16:29:37 -0400
Jakub Jelinek <[EMAIL PROTECTED]> wrote:
On Tue, Apr 03, 2007 at 01:17:09PM -0700, Ulrich Drepper wrote:
Andrew Morton wrote:
Ulrich, could you suggest a little test app which would demonstrate
this
behaviour?
On Tue, 3 Apr 2007, [EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 16:09:08 PDT, Brad Boyer said:
an abstraction of "serial port" as far as the user is concerned. On
Solaris, I can say "/dev/term/a" and know that I will get the first
serial port if it is available without needing to care if it i
lguest wants range checking, but unless there are other users I'm not
sure this is worth the pain. Putting it out there in case it's useful.
Cheers,
Rusty.
==
There are some places where we want to check if a value + length is
within a range. This can be tricky, so it's nice to have a single
rou
[EMAIL PROTECTED] wrote:
From: Divy Le Ray <[EMAIL PROTECTED]>
Ensure that the TCAM active region size is at least 16.
Signed-off-by: Divy Le Ray <[EMAIL PROTECTED]>
---
drivers/net/cxgb3/common.h|3 +++
drivers/net/cxgb3/cxgb3_main.c|7 +--
drivers/net/cxgb3/cxgb3_off
Adrian Bunk wrote:
On Fri, Mar 30, 2007 at 01:05:59AM -0700, Andrew Morton wrote:
...
Changes since 2.6.21-rc5-mm2:
...
git-netdev-all.patch
...
git trees
...
This patch makes the needlessly global PHY_DEVICES[] static.
Signed-off-by: Adrian Bunk <[EMAIL PROTECTED]>
---
BTW: Why is the n
This patch series introduces /proc/pid/pagemap and /proc/kpagemap,
which allow detailed run-time examination of process memory usage at a
page granularity.
The first several patches whip the page-walking code introduced for
/proc/pid/smaps and clear_refs into a more generic form, the next
couple m
Uninline some functions in the page walker
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:42.0 -0500
+++ mm/fs/proc/task_mmu.c 2007-03-2
Propagate errors from callback in page walker
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:52.0 -0500
+++ mm/fs/proc/task_mmu.c 2007-0
Add callbacks for each level to page walker
This allows iterating over all levels of the page tables. Recursion
continues to the depth of the lowest supplied callback.
This makes the page walker nearly completely generic and should allow
it to replace some other hand-rolled page table walkers.
S
Add /proc/kpagemap interface
This makes physical page flags and counts available to userspace.
Together with /proc/pid/pagemap and /proc/pid/clear_refs, this can be
used to measure memory usage on a per-page basis.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/proc_misc.c
===
Add /proc/pid/pagemap interface
This interface provides a mapping for each page in an address space to
its physical page frame number, allowing precise determination of what
pages are mapped and what pages are shared between processes.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs
Eliminate the pmd_walker struct in the page walker
This slightly simplifies things for the next few cleanups.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-2
Make /proc/pid/clear_refs option under CONFIG_EMBEDDED
This interface is primarily useful for doing memory profiling and not
much use on deployed embedded boxes. Make it optional. Together with
/proc/pid/smaps, this save a few K.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/
Remove vma from args in the page walker
This makes the walker more generic.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-24 21:33:50.0 -0500
+++ mm/
Make /proc/pid/smaps optional under CONFIG_EMBEDDED
This interface is primarily useful for doing memory profiling and not
much use on deployed embedded boxes. Make it optional. Together with
/proc/pid/clear_refs, this save a few K.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/pro
Move clear_refs code to task_mmu.c
This puts all the clear_refs code where it belongs and probably lets
things compile on MMU-less systems as well.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/base.c
===
--- mm.
Regroup task_mmu by interface
Reorder source so that all the code and data for each interface is
together.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-28 0
Simplify interdependence of /proc/pid/maps and smaps
This pulls the shared map display code out of show_map and puts it in
show_smap where it belongs.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
Signed-off-by: Matt Mackall <[EMAIL PROTECTED]>
Index: mm/fs/proc/task_mmu.c
===
--- mm.orig/fs/proc/task_mmu.c 2007-03-27 2
Hi Karl,
On Tuesday 03 April 2007 20:34, Karl Pickett wrote:
> The ati_remote driver is a little too sensitive for my wife... if you
> do anything but barely tap the button you can get multiple events
> reported. We prefer a more conservative no-repeat setting. This is a
> pretty trivial patch w
Andrew wrote:
> Paul, could you please describe what cpusets' policy is in the presence of
> CPU additional and removal?
Currently, if we remove the last CPU in a cpuset, we give that cpuset
the CPUs of its parent cpuset, in order to ensure that every cpuset
with tasks attached actually has some C
Ulrich Drepper wrote:
A solution for this problem is a madvise() operation with the following
property:
- the content of the address range can be discarded
- if an access to a page in the range happens in the future it must
succeed. The old page content can be provided or a new, empty
Andrew wrote:
> > But all this of course does not solve the issue sysconf() has. In
> > sysconf we cannot use sched_getaffinity since all the systems CPUs must
> > be reported.
>
> OK.
>
> This is excecptionally gruesome, but one could run sched_getaffinity()
> against pid 1 (init). Which will
Marko Macek wrote:
Ulrich Drepper wrote:
A solution for this problem is a madvise() operation with the following
property:
- the content of the address range can be discarded
- if an access to a page in the range happens in the future it must
succeed. The old page content can be provi
Ulrich wrote:
> But all this of course does not solve the issue sysconf() has. In
> sysconf we cannot use sched_getaffinity since all the systems CPUs must
> be reported.
Good point. Yes, sysconf(_SC_NPROCESSORS_CONF) really needs to continue
returning the number of CPUs online, to maintain comp
On Tue, Apr 03, 2007 at 10:49:49AM -0700, Paul Menage wrote:
> > Why is the hierarchy bit important here? Usually controllers need to
> > know "tell me what cpuset this task belongs to", which is answered
> > by tsk->nsproxy->ctlr_data[CPUSET_ID].
>
> I was thinking of queries from userspace.
Use
Ulrich wrote:
> For sysconf() we still need better support. Maybe now somebody will
> step up and say they need faster sysconf as well.
That won't be me ;).
For any kernel compiled with CONFIG_CPUSETS (which includes the major
distros I am aware of), one can just count the bits in the top cpuset
On Wed, 4 Apr 2007, Alan Cox wrote:
> You don't get machines with 64 ethernet ports on add-in cards. There are
> good reasons for the naming schemes in use.
If they made them I'd build one.
http://innerfire.net/pics/projects/21portfirewall_2.jpg
Gerhard
--
Gerhard Mack
[EMAIL PROTECTED
On Tue, Apr 03, 2007 at 07:45:16PM +0530, Gautham R Shenoy wrote:
> > Should we ignore this for the timebeing and take up later as and when
> > users report problems?
>
> In my case, the problem of freezer failing was due to the vfork freezer race
> in do_fork. The parent task was waiting_for_comp
On Wed, 04 Apr 2007 12:28:38 +1000 Rusty Russell wrote:
> lguest wants range checking, but unless there are other users I'm not
> sure this is worth the pain. Putting it out there in case it's useful.
>
> Cheers,
> Rusty.
> ==
> There are some places where we want to check if a value + length is
From: Randy Dunlap <[EMAIL PROTECTED]>
Fix section mismatch warnings in mtrr code.
Fix line length on one source line.
WARNING: arch/x86_64/kernel/built-in.o - Section mismatch: reference to
.init.data: from .text.get_mtrr_state after 'get_mtrr_state' (at offset 0x103)
WARNING: arch/x86_64/kerne
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
> On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
> > I do a '/ACPI_SLEEP' inside that, and I get this output:
> >
> > x Symbol: ACPI_SLEEP [=n] x
> > x Depends on: !X86_NUMAQ && !X
[EMAIL PROTECTED] wrote:
On Tue, 03 Apr 2007 19:20:04 PDT, Randy Dunlap said:
On Tue, 03 Apr 2007 21:35:54 -0400 [EMAIL PROTECTED] wrote:
I do a '/ACPI_SLEEP' inside that, and I get this output:
x Symbol: ACPI_SLEEP [=n] x
x Depends on: !X86_
On Fri, Mar 30, 2007 at 04:40:48AM +0200, Nick Piggin wrote:
>
> Well it would make life easier if we got rid of ZERO_PAGE completely,
> which I definitely wouldn't complain about ;)
So, what bad things (apart from my bugs in untested code) happen
if we do this? We can actually go further, and pr
vatsa wrote:
> User space queries like "what is the cpuset to which this task belongs",
> where the answer needs to be something of the form "/dev/cpuset/C1"?
I think that answer should be of the form "/C1", and not include the
cpuset file system mount point ... though for the purposes of the
pres
On Tue, 03 Apr 2007, Jeremy Fitzhardinge wrote:
> Attached. Is there some tool for decoding the DSDT?
iasl. The documentation is the ACPI Specification.
> >> ezr:pts/1; cat /proc/acpi/ibm/thermal
> >> temperatures: 72 55 -128 65 40 -128 35 -128 51 53 -128 -128 -128 -128
> >> -128 -128
> >
> >
Matt Mackall wrote:
Move the page walker code to lib/
This lets it get shared outside of proc/ and linked in only when
needed.
I think it would be better in mm/.
So would clear_refs_pte_range, and clear_refs_write (in a more
generic form), IMO.
Sweet patchset, though.
--
SUSE Labs, Novell I
please check the patch
YH
[PATCH] x86_64/acpi: make kernel to be compiled when CONFIG_ACPI_NUMA is set and power management with acpi is not enabled
when CONFIG_ACPI_NUMA is set, and power management with acpi is not used. the kernel can not be compiled.
drivers/acpi/bus.c: In function âacpi
Please pull from 'upstream-linus' branch of
master.kernel.org:/pub/scm/linux/kernel/git/jgarzik/netdev-2.6.git
upstream-linus
to receive the following updates:
drivers/net/b44.c |2 +-
drivers/net/cxgb3/common.h|9 +--
drivers/net/cxgb3/cxgb3_main.c| 3
This is a "first step" as there are still cleanups to be done in various
areas touched by that code but I think it's probably good to go as is and
at least enables me to implement what I need for PowerPC.
The current get_unmapped_area code calls the f_ops->get_unmapped_area or
the arch one (via th
Hi Yoichi,
Could you please try the patch below? It moves platform device creation
code into cobalt arch code to belletr follow driver model.
Thank you!
--
Dmitry
Input: cobalt buttons - separate device and driver registration
Create platform device for cobalt buttons as part of arch setup.
T
301 - 400 of 484 matches
Mail list logo
