On Fri, 17 Aug 2007, Nick Piggin wrote:
That's not obviously just taste to me. Not when the primitive has many
(perhaps, the majority) of uses that do not require said barriers. And
this is not solely about the code generation (which, as Paul says, is
relatively minor even on x86). I
On Friday 17 August 2007, Kay Sievers wrote:
Again,
Again?
the only sane solution is to provide MODALIAS=platform:name
from the platform bus, and adding the aliases to drivers who support
autoloading. Modalias strings are not free-text strings, they are
required to be prefixed by the
On Fri, Aug 17, 2007 at 02:47:27PM +0800, Fengguang Wu wrote:
Matt,
It's not easy to do direct performance comparisons between pmaps and
pagemap/kpagemap. However some close analyzes are still possible :)
1) code size
pmaps ~200 LOC
pagemap/kpagemap~300 LOC
On Fri, 17 Aug 2007, Andreas Jellinghaus [c] wrote:
I need some kernel event that has both DEVICE and MODALIAS set.
up to including kernel 2.6.21 this seems to come from
drivers/usb/core/driver.c if I read the code correctly, and then
it was removed.
udevmonitor --kernel --environment
Part of the motivation here is to fix heisenbugs. If I knew
where they
By the same token we should probably disable optimisations
altogether since that too can create heisenbugs.
Almost everything is a tradeoff; and so is this. I don't
believe most people would find disabling all compiler
Probably want to copy [EMAIL PROTECTED] on
wireless-related posts. Adding Michael Wu to the CC: as well...
John
On Fri, Aug 17, 2007 at 04:59:33PM +0100, Alan Jenkins wrote:
I've just acquired this buggy piece of hardware otherwise known as a
NetGear WG111v2. I googled and eventually found
atomic_dec() already has volatile behavior everywhere, so this is
semantically
okay, but this code (and any like it) should be calling cpu_relax()
each
iteration through the loop, unless there's a compelling reason not
to. I'll
allow that for some hardware drivers (possibly this one) such a
Here's a path to enable a command line option
that takes a string argument
cc-cmd
This modifies the @cc array to include whatever
output is produced by cc_cmd $patchfile
cccmd can be stored in a config settings file
previous versions of this patch were submitted
against an older
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
+ asm(\tRETI = %0;\n
+ \tRETX = %0;\n
+ \tRETN = %0;\n
+ : : p(early_trap));
general note, i dont think inserting whitespace by hand in asm() is a
good thing ... i see it as whitenoise personally ...
+int
The patch (for review - not inclusion - I will send to Bryan if no one has any
major objections, and he can push it via git) implements early printk for the
Blackfin architecture.
It also adds an early exception handler, so if an
interrupt/exception/violation happens before the kernel enables
On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
+int __init disable_early_printk(void)
+{
+ if (!early_console_initialized)
+ return 0;
+
+ printk(KERN_INFO Unregister %s%d\n,
early_console_initialized-name,
On Friday 17 August 2007 01:34, Al Viro wrote:
On Thu, Aug 16, 2007 at 03:57:24PM -0700, Linus Torvalds wrote:
I personally consider this an affront to everythign that is decent.
Why the *hell* would mkdir() be so magical as to need something like that?
Make it something sane, like a
On Fri, Aug 17, 2007 at 01:36:39PM -0400, Robin Getz wrote:
The patch (for review - not inclusion - I will send to Bryan if no one has
any
major objections, and he can push it via git) implements early printk for the
Blackfin architecture.
It also adds an early exception handler, so if
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
On Fri 17 Aug 2007 13:57, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
+int __init disable_early_printk(void)
+{
+ if (!early_console_initialized)
+ return 0;
+
+
Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some unbalanced rcu_read_{,un}lock() issues of
On Fri, Aug 17, 2007 at 08:53:57AM -0700, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 09:56:45AM +0200, Peter Zijlstra wrote:
On Thu, 2007-08-16 at 09:01 -0700, Paul E. McKenney wrote:
On Thu, Aug 16, 2007 at 04:25:07PM +0200, Peter Zijlstra wrote:
There seem to be some
On Wed, 15 Aug 2007 19:49:04 -0700
Paul E. McKenney [EMAIL PROTECTED] wrote:
Repost of http://lkml.org/lkml/2007/8/10/472 made available by request.
The locking used by get_random_bytes() can conflict with the
preempt_disable() and synchronize_sched() form of RCU. This patch changes
On Fri, 17 Aug 2007, Segher Boessenkool wrote:
atomic_dec() already has volatile behavior everywhere, so this is
semantically
okay, but this code (and any like it) should be calling cpu_relax() each
iteration through the loop, unless there's a compelling reason not to.
I'll
Linus Torvalds wrote:
- in other words, the *only* possible meaning for volatile is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the volatile is by definition pointless (because even
without a volatile, the compiler is required to make the
On Fri, 17 Aug 2007, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL)
On Aug 17 2007 11:22, Andrew Morton wrote:
Which is getting pretty idiotic:
akpm:/usr/src/25 grep ZERO_OR_NULL_PTR */*.c
mm/slab.c: BUG_ON(ZERO_OR_NULL_PTR(cachep-slabp_cache));
mm/slab.c: if (unlikely(ZERO_OR_NULL_PTR(cachep)))
mm/slab.c: if
On Fri, 2007-08-17 at 11:22 -0700, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
From: Kim Naru ([EMAIL PROTECTED])
Added support to offload TCP/UDP/IP checksum to the
VIA Technologies VT6105M chip.
Firstly, let the stack know this chip is capable of
doing its own checksum(IPV4 only).
Secondly offload checksum to VT6105M, if necessary.
Verbose Mode:
#1. Define 3
On Tuesday 07 August 2007, Bryan Wu wrote:
From: Michael Hennerich [EMAIL PROTECTED]
The patch description here is IMO misleading, and is clearly
weak-to-nonexistent ... what this patch does is
* Start tracking the label strings provided by gpio_request()
* Provide a new portmux mechanisms
On Tuesday 07 August 2007, Bryan Wu wrote:
- /* Enable UART0 RX and TX on pin 7 8 of PORT E */
- bfin_write_PORTE_FER(0x180 | bfin_read_PORTE_FER());
- bfin_write_PORTE_MUX(0x3C000 | bfin_read_PORTE_MUX());
+ peripheral_request(P_UART0_TX, DRIVER_NAME);
+
Again, the patch descriptions need work. This changes the
IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
neither does the description ...
On Tuesday 07 August 2007, Bryan Wu wrote:
--- a/arch/blackfin/mach-common/ints-priority-dc.c
+++
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu wrote:
First of all, I think this illustrates that what you want
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
kfree(ZERO_SIZE_PTR) is uncommon as well, so let's use unlikely() for
On Fri, 17 Aug 2007, Chris Friesen wrote:
I assume you mean except for IO-related code and 'random' values like
jiffies as you mention later on?
Yes. There *are* valid uses for volatile, but they have remained the
same for the last few years:
- jiffies
- internal per-architecture IO
On Sat, Aug 18, 2007 at 12:01:38AM +0530, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 01:09:08PM +0530, Satyam Sharma wrote:
On Thu, 16 Aug 2007, Paul E. McKenney wrote:
On Fri, Aug 17, 2007 at 07:59:02AM +0800, Herbert Xu
This patch adds just a check for granted memory
to prevent possible NULL pointer usage.
Signed-off-by: Cyrill Gorcunov [EMAIL PROTECTED]
---
fs/cifs/sess.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/fs/cifs/sess.c b/fs/cifs/sess.c
index 2ea027d..892be9b 100644
Andrew Morton wrote:
On Fri, 17 Aug 2007 11:09:41 +1000
Michael Neuling [EMAIL PROTECTED] wrote:
This adds items to the taststats struct to account for user and system
time based on scaling the CPU frequency and instruction issue rates.
Adds account_(user|system)_time_scaled callbacks
[EMAIL PROTECTED] wrote:
I suspect Kyle is not quite correct - it's probably the case that you don't
have to consider just the in-memory dentries, but *all* the descendent objects
in the entire file system.
If you have a clever proof that on-disk can't *possibly* be affected, feel
free to
On Fri, 17 Aug 2007 11:09:41 +1000
Michael Neuling [EMAIL PROTECTED] wrote:
This adds items to the taststats struct to account for user and system
time based on scaling the CPU frequency and instruction issue rates.
Adds account_(user|system)_time_scaled callbacks which architectures
can
On Fri, 2007-08-17 at 19:18 +0200, Anton Arapov wrote:
IPC code is good, EIDRM is justification of EINVAL. But neither SVr4 nor
SVID \
documents EIDRM. Single Unix Specification mentions EINVAL but not EIDRM as
a \
possible failure for shmctl(), so the current kernel behavior is not
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
Linus Torvalds wrote:
- in other words, the *only* possible meaning for volatile is a purely
single-CPU meaning. And if you only have a single CPU involved in the
process, the volatile is by definition pointless (because
(the explicit ack/nack from maintainers is wanted).
A typical implementation of atomic_add_unless() can return 0 immediately
after the first atomic_read() (before doing cmpxchg). In that case it doesn't
provide any barrier semantics. See include/asm-ia64/atomic.h as an example.
We should either
On Fri, Aug 17, 2007 at 11:54:33AM -0700, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 12:50 -0600, Chris Friesen wrote:
Linus Torvalds wrote:
- in other words, the *only* possible meaning for volatile is a purely
single-CPU meaning. And if you only have a single CPU involved
On Friday 17 August 2007, Kay Sievers wrote:
On Fri, 2007-08-17 at 09:55 -0700, David Brownell wrote:
On Friday 17 August 2007, Kay Sievers wrote:
Again,
Again?
We exchanges several mails a few weeks ago after the Debian bug caused
by a modprobe loop.
Which has been fixed for some
On 17/08/07, Arjan van de Ven [EMAIL PROTECTED] wrote:
On Fri, 2007-08-17 at 19:18 +0200, Anton Arapov wrote:
IPC code is good, EIDRM is justification of EINVAL. But neither SVr4 nor
SVID \
documents EIDRM. Single Unix Specification mentions EINVAL but not EIDRM
as a \
possible
On Aug 17 2007 12:50, David Brownell wrote:
On Friday 17 August 2007, Kay Sievers wrote:
On Fri, 2007-08-17 at 09:55 -0700, David Brownell wrote:
On Friday 17 August 2007, Kay Sievers wrote:
Again,
Again?
We exchanges several mails a few weeks ago after the Debian bug caused
by a
Isn't RDMA _part_ of the software net stack within Linux?
It very much is not so.
This is just nit-picking. You can draw the boundary of the software
net stack wherever you want, but I think Sean's point was just that
RDMA drivers already are part of Linux, and we all want them to get
On Fri, 2007-08-17 at 12:49 -0700, Paul E. McKenney wrote:
What about reading values modified in interrupt handlers, as in your
random case? Or is this a bug where the user of atomic_read() is
invalidly expecting a read each time it is called?
the interrupt handler case is an SMP
On Fri, 17 Aug 2007 06:59:18 -0400
Neil Horman [EMAIL PROTECTED] wrote:
Currently, there exists no method for a process to query the resource
limits of another process. They can be inferred via some mechanisms but they
cannot be explicitly determined. Given that this information can be
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
Again, the patch descriptions need work. This changes the
IRQ code (to add those labels). $SUBJECT doesn't mention IRQs,
neither does the description ...
On Tuesday 07 August 2007, Bryan Wu wrote:
---
This patch introduces architecture dependent kretprobe
blacklists to prohibit users from inserting return
probes on the function in which kprobes can be inserted
but kretprobes can not.
Signed-off-by: Masami Hiramatsu [EMAIL PROTECTED]
---
Problem Description
When a kretprobe is inserted in the
Hi Linus,
the attached patch fixes a flaw in the parent process death signal
when executing SUID binaries. An unprivileged user may send arbitrary
signal to a child process even if it is running with higher privileges.
The idea to fix this issue is to reset pdeath_signal not only on fork,
but
On Fri, Aug 17, 2007 at 11:53:56AM -0700, Andrew Morton wrote:
On Wed, 15 Aug 2007 19:49:04 -0700
Paul E. McKenney [EMAIL PROTECTED] wrote:
Repost of http://lkml.org/lkml/2007/8/10/472 made available by request.
The locking used by get_random_bytes() can conflict with the
Hi Dave,
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
Sent: Freitag, 17. August 2007 20:12
To: Bryan Wu
Cc: [EMAIL PROTECTED]; linux-kernel@vger.kernel.org;
[EMAIL PROTECTED]; Michael Hennerich
Subject: Re: [PATCH 01/12] Blackfin arch: add peripheral resource
(textually depends on
wait_task_zombie-remove-unneeded-child-signal-check.patch)
The p-exit_signal == -1 p-ptrace == 0 check and the comment are bogus.
We already did exactly the same check in eligible_child(), we did not drop
tasklist_lock since then, and both variables need
On Fri 17 Aug 2007 13:59, Sam Ravnborg pondered:
That seems to explain why I could not follow your code changes.
A more fine grained splitup would have helped here.
Sorry - see below. These aren't proper patches anymore, since it was
faster for me to split them by hand (but should be OK for
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these issues from the
IRQ infrastructure ... doing the pinmux and gpio claiming
On Fri, Aug 17, 2007 at 12:49:00PM -0700, Arjan van de Ven wrote:
On Fri, 2007-08-17 at 12:49 -0700, Paul E. McKenney wrote:
What about reading values modified in interrupt handlers, as in your
random case? Or is this a bug where the user of atomic_read() is
invalidly expecting a
The allocator deals with zonelists which indicate the order in which zones
should be targeted for an allocation. Similarly, direct reclaim of pages
iterates over an array of zones. For consistency, this patch converts direct
reclaim to use a zonelist. No functionality is changed by this patch.
Biggest changes are altering the embedding of zone IDs so that the type is
unsigned long instead of struct zone * and the removal of MPOL_BIND-specific
zonelists and filering based on node data instead. The biggest concern is the
last patch where FASTCALL doesn't appear to do the right thing in
Currently a node has a number of zonelists, one for each zone type in
the system. Based on the zones allowed by a gfp mask, one of these zonelists
is selected. All of these zonelists occupy memory and consume cache lines.
This patch replaces the multiple zonelists in the node with a single
Using one zonelist per node requires very frequent use of zone_idx(). This
is costly as it involves a lookup of another structure and a substraction
operation. struct zone is aligned on a node-interleave boundary so the
pointer values of plenty of 0's at the least significant bits of the address.
This patch is mainly the work of Kamezawa-san.
As there is only one zonelist, it must be filtered for zones that are unusable
by the GFP flags. As the zonelists very rarely change during the lifetime of
the system, it is known in advance how many zones can be skipped from the
beginning of the
The MPOL_BIND policy creates a zonelist that is used for allocations belonging
to that thread that can use the policy_zone. As the zonelist is already being
filtered based on a zone id, this patch adds a version of __alloc_pages()
that takes a nodemask for further filtering. This eliminates the
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these issues from the
On Friday 17 August 2007, Jan Engelhardt wrote:
We exchanges several mails a few weeks ago after the Debian bug caused
by a modprobe loop.
Which has been fixed for some time now; it was caused by legacy
drivers, which are incapable of hotplugging.
Speaking of which ... does not
On 8/17/07, Mike Frysinger [EMAIL PROTECTED] wrote:
as Michael pointed out, in the Blackfin world we tend to keep things
very dynamic as we have dev systems which allow for dropping in of
optional cards at will, so doing this in the bootloader is way too
inflexible.
oh, and another [smallish]
On Fri, 17 Aug 2007 12:45:47 PDT, Andrew Morton said:
On Fri, 17 Aug 2007 06:59:18 -0400
Neil Horman [EMAIL PROTECTED] wrote:
Currently, there exists no method for a process to query the resource
limits of another process. They can be inferred via some mechanisms but
they
cannot be
One PPC64 machine using gcc 3.4.6 the machine fails to boot when
__alloc_pages_nodemask() uses the FASTCALL calling convention. It is not
clear why this machine in particular is affected as other PPC64 machines
boot. The only usual aspect of the machine is that it has memoryless nodes
but I
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
On Friday 17 August 2007, Mike Frysinger wrote:
On 8/17/07, David Brownell [EMAIL PROTECTED] wrote:
...
Just for the record, this is an unusual way to use these calls.
Other platforms completely decouple these
On Fri, 17 Aug 2007, Peter Zijlstra wrote:
Currently we do:
dirty = total_dirty * bdi_completions_p * task_dirty_p
As dgc pointed out before, there is the issue of bdi/task correlation,
that is, we do not track task dirty rates per bdi, so now a task that
heavily dirties on one bdi will
On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
Why do you printk inside the timing period ? Filling the printk buffers
or outputting on things such as serial console could really hurt your
results.
It was easier to code?
I hope you run your system with idle=poll and without frequency scaling
On Fri, 17 Aug 2007, Mathieu Desnoyers wrote:
Actually, get_cycles() at least on some AMD cpus, do not synchronize the
core, which can skew the results. You might want to use
get_cycles_sync() there.
get_cycle() results as used here are bound to a single processor. If we
end up on a
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
be future callsites at which it is likely, who knows?
Thought about that myself but then there would be a
Hello everyone,
I am trying to port kernel 2.6.19 onto my system.so I need the c code
, which can show me where the program is running. I add -g when I
compile it.
after I got the vmlinux( uncompressed) I used arm-none-eabi-objcopy
--change-addresses 0x4000 to change the start address.
it
Fix section mismatch in the Adaptec DPT SCSI Raid driver.
Signed-off-by: Joe Korty [EMAIL PROTECTED]
Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c
===
--- 2.6.23-rc3-git1.orig/drivers/scsi/dpt_i2o.c 2007-08-17 16:36:05.0
On Fri, Aug 17, 2007 at 11:41:20AM -0400, John Blackwood wrote:
Hi Neil,
We've been having problems with this select patch change.
Specifically -- previously, when a ptrace attach was done to a task
blocked in a select() call and that task had a timeout value,
the task would restart the
On Thu, Aug 16, 2007 at 06:26:18PM -0700, Paul E. McKenney wrote:
On Tue, Aug 14, 2007 at 04:41:16PM -0700, Paul E. McKenney wrote:
Hello!
Work in progress, not for inclusion.
The attached patch passes multiple hours of rcutorture while hotplugging
CPUs every ten seconds on 64-bit
On Fri, 17 Aug 2007, Mel Gorman wrote:
+/* Returns the first zone at or below highest_zoneidx in a zonelist */
+static inline struct zone **first_zones_zonelist(struct zonelist *zonelist,
+ enum zone_type highest_zoneidx)
+{
+ struct zone **z;
+
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
Mike Frysinger wrote:
Hmm, sort of, although I didn't think about the case of no real console
replacing the early console. The intention of the patch is to have a
smooth handover from the boot console to the real console. And, yes, if
no
On Fri, 17 Aug 2007, Andrew Morton wrote:
On Wed, 15 Aug 2007 05:12:41 +0530 (IST)
Satyam Sharma [EMAIL PROTECTED] wrote:
[PATCH] {slub, slob}: use unlikely() for kfree(ZERO_OR_NULL_PTR) check
Considering kfree(NULL) would normally occur only in error paths and
kfree(ZERO_SIZE_PTR)
On Fri, Aug 17, 2007 at 12:45:47PM -0700, Andrew Morton wrote:
On Fri, 17 Aug 2007 06:59:18 -0400
Neil Horman [EMAIL PROTECTED] wrote:
Currently, there exists no method for a process to query the resource
limits of another process. They can be inferred via some mechanisms but
they
On Fri, 17 Aug 2007, Mel Gorman wrote:
+/*
+ * SMP will align zones to a large boundary so the zone ID will fit in the
+ * least significant biuts. Otherwise, ZONES_SHIFT must be 2 or less to
+ * fit
ZONES_SHIFT is always 2 or less
Acked-by: Christoph Lameter [EMAIL PROTECTED]
-
To
Is there any performance improvement because of this patch? It looks
like processing got more expensive since an additional cacheline needs to
be fetches to get the skip factor.
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there might
be future callsites at which it is likely, who knows?
On Fri, 17 Aug 2007, Mel Gorman wrote:
Opinions as to why FASTCALL breaks on one machine are welcome.
Could we get rid of FASTCALL? AFAIK the compiler should automatically
choose the right calling convention?
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body
Hi,
I don't like compiler warnings, especially not when they are easy to
avoid.
Building cyclades driver without CONFIG_PCI currently results in this :
CC drivers/char/cyclades.o
drivers/char/cyclades.c: In function 'cy_init':
drivers/char/cyclades.c:5488: warning: label 'err_unr'
On Fri, 17 Aug 2007 15:26:22 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
During hibernation and suspend on x86_64 save CPU registers in the
saved_context
structure rather than in a handful of separate variables.
You have -mm in the subject but afaict this patch is not dependent upon
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
On Fri 17 Aug 2007 03:49, Gerd Hoffmann pondered:
Mike Frysinger wrote:
Hmm, sort of, although I didn't think about the case of no real console
replacing the early console. The intention of the patch is to have a
smooth handover from the
On Sat, 18 Aug 2007, Satyam Sharma wrote:
page = get_object_page(object);
Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Oh yes,
On Fri, 17 Aug 2007 16:51:15 -0400
Joe Korty [EMAIL PROTECTED] wrote:
Fix section mismatch in the Adaptec DPT SCSI Raid driver.
Signed-off-by: Joe Korty [EMAIL PROTECTED]
Index: 2.6.23-rc3-git1/drivers/scsi/dpt_i2o.c
===
---
On Sat, 18 Aug 2007, Satyam Sharma wrote:
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Fri, 17 Aug 2007, Andrew Morton wrote:
are we seeing a pattern here? We could stick the unlikely inside
ZERO_OR_NULL_PTR() itself. That's a little bit sleazy though - there
might
be
Hi,
Easily avoidable compiler warnings bug me.
Building irmod without CONFIG_SYSCTL currently results in :
net/irda/irmod.c:132: warning: label 'out_err_2' defined but not used
But that can easily be avoided by simply moving the label inside
the existing #ifdef CONFIG_SYSCTL one line above
From: Roland Dreier [EMAIL PROTECTED]
Date: Fri, 17 Aug 2007 12:52:39 -0700
When using RDMA you lose the capability to do packet shaping,
classification, and all the other wonderful networking facilities
you've grown to love and use over the years.
Same thing with TSO and LRO and who
On Fri, 17 Aug 2007, Mel Gorman wrote:
@@ -696,6 +696,16 @@ static inline struct zonelist *node_zone
return NODE_DATA(nid)-node_zonelist;
}
+static inline int zone_in_nodemask(unsigned long zone_addr,
+ nodemask_t *nodes)
+{
+#ifdef CONFIG_NUMA
+
On Fri 17 Aug 2007 17:09, Mike Frysinger pondered:
On 8/17/07, Robin Getz [EMAIL PROTECTED] wrote:
Something like:
Index: kernel/printk.c
===
--- kernel/printk.c (revision 3568)
+++ kernel/printk.c (working
On Friday 17 August 2007, Hennerich, Michael wrote:
Hi Dave,
Right - our patch descriptions needs to be worked on.
Yes, please ... that makes reviewing easier!
For a well experienced
systems engineer being the same time the same guy who does the Hardware
and the Software this is not
On Friday 17 August 2007, Mike Frysinger wrote:
as Michael pointed out, in the Blackfin world we tend to keep things
very dynamic as we have dev systems which allow for dropping in of
optional cards at will, so doing this in the bootloader is way too
inflexible.
That's the tradeoff:
On Friday 17 August 2007, Hennerich, Michael wrote:
What Mike wants to point out is that a external IRQ is first a GPIO and
needs to be configured like an INPUT GPIO and then a specific bit needs
to be set unmask it as IRQ.
So why not use the GPIO infrastructure to setup this pin as GPIO?
On 17/08/07, Xu Yang [EMAIL PROTECTED] wrote:
Hello everyone,
I am trying to port kernel 2.6.19 onto my system.so I need the c code
, which can show me where the program is running. I add -g when I
compile it.
You shouldn't need to do that manually, simply go into make
menuconfig, enter the
On Fri, 17 Aug 2007, Christoph Lameter wrote:
On Sat, 18 Aug 2007, Satyam Sharma wrote:
Hmm, I didn't know ksize(NULL) was also allowed to succeed (and
return 0).
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated
On 8/18/07, Christoph Lameter [EMAIL PROTECTED] wrote:
That was merged over my objections. IMHO ksize(NULL) should fail since we
are determining the size of an unallocated object.
Agreed, especially as we have real zero-sized objects returned from
kmalloc() et al now.
-
To unsubscribe from this
On Fri 17 Aug 2007 14:24, David Brownell pondered:
Just for the record, this is an unusual way to use these calls.
That is part of the natural evolution of the kernel isn't it - per James's
keynote at OLS - you release something, and see how people [ab]use it until
it either grows, evolves, or
On Friday, 17 August 2007 23:08, Andrew Morton wrote:
On Fri, 17 Aug 2007 15:26:22 +0200
Rafael J. Wysocki [EMAIL PROTECTED] wrote:
During hibernation and suspend on x86_64 save CPU registers in the
saved_context
structure rather than in a handful of separate variables.
You have -mm
-Original Message-
From: David Brownell [mailto:[EMAIL PROTECTED]
On Friday 17 August 2007, Hennerich, Michael wrote:
What Mike wants to point out is that a external IRQ is first a GPIO
and
needs to be configured like an INPUT GPIO and then a specific bit
needs
to be set unmask it as
501 - 600 of 678 matches
Mail list logo
