jschopp wrote:
This version brings a host of changes to cure false positives and
bugs detected on patches submitted to lkml and -mm. It also brings
a number of new tests in response to reviews, of particular note:
- catch use of volatile
- allow deprecated functions to be listed in
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem
When a task enters a new namespace via a clone()
On Tuesday 05 June 2007 08:21:23 Yinghai Lu wrote:
[PATCH] x86_64: change dmi_ioremap to ioremap
dmi_scan_machine==dmi_present==dmi_table==dmi_ioremap uses
early_ioremap in mm/init.c
dmi_scan_machine is called after init_memory_mappings, and could use
ioremap instead.
also remove extra
But TSC is a required feature, so cpu_has_tsc is always true.
Hmm? It isn't. What makes you think so?
cpufeature.h:
#define cpu_has_tsc boot_cpu_has(X86_FEATURE_TSC)
% grep -i tsc include/asm-i386/required-features.h
%
How about this patch:
===
Don't try to disable the TSC:
On Tuesday 05 June 2007 12:52:59 Mircea Bardac wrote:
Hi Peter,
This time with Kernel 2.6.21.3.
[...]
# echo 1 /sys/devices/system/cpu/cpu1/online
# cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 15
model : 72
model name : AMD
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
Signed-off-by: Vasily Averin [EMAIL PROTECTED]
diff --git a/fs/ext3/super.c
On Mon, Jun 04, 2007 at 05:05:51PM -0400, Jeff Garzik wrote:
This patch introduces struct pci_sysdata to x86 and x86-64, and
converts the existing two users (NUMA, Calgary) to use it.
This eliminates the conflict between NUMA and Calgary using the same
pointer for different uses, and lays
Vasily Averin wrote:
Customers claims to ext3-related errors, investigation showed that ext3 orphan
list has been corrupted and have the reference to non-ext3 inode. The following
debug helps to understand the reasons of this issue.
This looks like it might be related to the -as far as I recall-
This patch fixes a typo in Documentation/atomic_ops.txt
Thanks,
- Ratnadeep Joshi
diff --git a/Documentation/atomic_ops.txt b/Documentation/atomic_ops.txt
index 2a63d56..05851e9 100644
--- a/Documentation/atomic_ops.txt
+++ b/Documentation/atomic_ops.txt
@@ -149,7 +149,7 @@ defined which
On Tue, 05 Jun 2007 10:29:43 +0100, David Greaves wrote:
Linus Torvalds wrote:
[Linus' 2.6.22-rc4 announcement]
Compile warnings and a new regression: hang on boot during sata_promise
detection... :(
Please give us some details about your sata_promise problem:
- describe your hardware
Changes:
Names are renamed to task_context_switch_rates.
Patch makes available to the user the following
task and process performance statistics:
* Involuntary Context Switches (task_struct-nivcsw)
* Voluntary Context Switches (task_struct-nvcsw)
Matt, could you send me your .config too? Maybe i can reproduce it
with your config.
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read
On Tue, 2007-06-05 at 00:12 +0200, Adrian Bunk wrote:
This patch contains the following possible cleanups:
-
-int __init pm3fb_init(void)
-{
- /*
- * For kernel boot options (in 'video=pm3fb:options' format)
- */
-#ifndef MODULE
- char *option = NULL;
-
- if
Hi Peter,
This time with Kernel 2.6.21.3.
On Tuesday 05 June 2007 11:03:23 Peter Oruba wrote:
reagarding your Turion cpufreq issues - is that solved by now?
http://lkml.org/lkml/2007/4/8/59
/proc/cpuinfo shows half the bogomips it showed in my initial post
(maybe it is right now)
Andrew Morton [EMAIL PROTECTED] writes:
net/wan/lmc/lmc_main.c|2 +-
scsi/megaraid/megaraid_mm.c |2 +-
usb/serial/io_ti.c|2 +-
usb/serial/ti_usb_3410_5052.c |2 +-
usb/serial/whiteheat.c|6 +++---
5 files changed, 7 insertions(+), 7
The 32-bit sparc port has some but those PCMCIA controllers aren't
going to be supported in the foreseeable future, you have to abstract
out all the inb/outb etc. operations to go through the pcmcia
controller driver for one thing.
Thats one place iomap might actually save the day as you
I don't think it's a good idea.
Ditto (and glibc handles it for userspace posix APIs)
How?
-Andi
-
To unsubscribe from this list: send the line unsubscribe linux-kernel in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please
NAK
We have generic devices and generic DMA mapping. libata already uses
the generic stuff. Now fix the platform...
Nice theory but your generic helpers rely on the map functions working
even for generic hardware that doesn't need them, so at the very least
there is some clean up required.
Prevent mppe_decompress() from generating osize too small errors when checking
for output buffer size. When receiving a packet of mru size the output buffer
for decrypted data is 1 byte too small since mppe_decompress() tries to account
for possible PFC, however later in code it is assumed no PFC.
On Tue, 5 Jun 2007 14:07:20 +0300
Ivan Kuten [EMAIL PROTECTED] wrote:
I tried to test your patch on AT91RM9200 with Magic SysRq sequence,
unfortunately without
success - SysRq still does not work. You mention break count increments
where do you check it ? I have
cat
On Mon, 2007-06-04 at 23:53 -0700, David Miller wrote:
From: Sam Ravnborg [EMAIL PROTECTED]
Date: Sat, 2 Jun 2007 21:16:46 +0200
promcon_init() can be called again from visual_init() during
vc_allocate(). So anything referenced by promcon_init() should not be
marked __init.
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
Acked-by: Tero Roponen [EMAIL PROTECTED]
---
This fixes the following regression/bug reported as follows:
Subject: tty-related oops in latest
On Thu, 31 May 2007 21:31:31 +0200
Haavard Skinnemoen wrote:
It's been almost a year since the last patch I sent attempting to fix
this. Sorry for not following up any sooner.
Anyway, here's a new attempt. It should work even if we miss some
interrupts, and it should not break break
Am Dienstag, 5. Juni 2007 13:05 schrieb Yoann Padioleau:
Ok. Do you have a preference on the format ? a file:line format ?
Is there a place that gathered all those implicit programming rules
(that copy_from_user must not be called inside a spinlock, etc) so that
I can translate them in a
The pseudo_palette has room for 16 entries only, but in truecolor mode, it
attempts to write 256.
Signed-off-by: Antonino Daplas [EMAIL PROTECTED]
Acked-by: Tero Roponen [EMAIL PROTECTED]
---
This fixes the following regression/bug reported as follows:
Subject: tty-related oops in latest
Hello.
I looked at your long attachment. It seems, you have problems with hardware.
Would you please check your root drive (sde) by badblocks program?
Thanks,
Edward.
Berck E. Nash wrote:
All appears to work fine, until I try to boot a kernel with a Reiser4 /
partition. Then I get endless
David,
On Mon, Jun 04, 2007 at 07:40:53AM -0700, David Rientjes wrote:
include/asm-powerpc/thread_info.h:
- add TIF_PERFMON which is used for PMU context switching in
__switch_to()
You mean TIF_PERFMON_CTXSW and TIF_PERFMON_WORK.
Yes.
---
I'm just wondering why we have an inconsistency between several archs when
it comes to the definitions of atomic_t, atomic64_t, spinlock_t and their
accessors. Currently we have on most architectures something like
typedef struct { volatile int counter; } atomic_t;
except for i386/x86_64 which
On Mon, Jun 04, 2007 at 06:49:10PM -0600, Robert Hancock wrote:
This blacklist seems to be growing. Isn't there something better we can
do here? Can we just reboot through the BIOS by default, is that really
broken on some systems?
Yes, that breaks a separate set of machines. It would be
Sam wrote:
Andrey, in addition to Bjorn's patch, could you also apply
this one and try again:
diff --git a/drivers/net/irda/smsc-ircc2.c
b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644
--- a/drivers/net/irda/smsc-ircc2.c
+++ b/drivers/net/irda/smsc-ircc2.c
@@ -2463,7
Hi!
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix.patch
-drivers-ata-add-sw-ncq-support-to-sata_nv-for-mcp51-mcp55-mcp61-fix-tidy.patch
Merged into mainline or a subsystem tree
They aren't. They
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
Subject: [PATCH 1/1] containers: implement nsproxy containers subsystem
Here a version of the patch that drops the WARN_ONs
And now all that's done, how about yet another random person stepping in and
suggesting NIL or maybe NIL_PTR instead of ZERO_SIZE_PTR?
I understand the idea is that code need not necesarily care about zero sized
allocation meaning it
Andrey wrote:
And here is what PnP tells us:
{pts/1}% cat /sys/bus/pnp/devices/00:0a/options
port 0x100-0x130, align 0xf, size 0x8, 16-bit address decoding irq
3,4,5,6,7,10,11 High-Edge dma 1,2,3 16-bit compatible
Dependent: 01 - Priority acceptable
port 0x3f8-0x3f8, align 0x0, size
Hi,
sorry for the late reply on this.
At Tue, 29 May 2007 22:18:05 +0200 (MEST),
Jan Engelhardt wrote:
On May 29 2007 18:41, Takashi Iwai wrote:
Well, I find the change of CONFIG_SND to menuconfig is fine, too.
But CONFIG_SND_PCI_DRIVERS and others don't make much sense to me.
How is it
On Tue, Jun 05, 2007 at 10:19:59AM +0200, Sam Ravnborg wrote:
[]
So, there are some new scripts. What if my proposition will be better,
so to speak? Any problems i'm willing to fix/enhance.
Note: only one copy of the file required. Sym-linked name *diff* or
*patch* will process patches.
I've released the 2.6.22-rc4-ext4-1 tree, which can be downloaded from
the usual place:
http://ftp.kernel.org/pub/linux/kernel/people/tytso/ext4-patches
This is just a rebase versus 2.6.22-rc4, and reflects the bugfix patches
that have been accepted into mainline.
Hello.
Bartlomiej Zolnierkiewicz wrote:
The log of a typical IDE reset is available here:
http://petra.hos.u-szeged.hu/~wildy/syslog.gz
This was the worst case: the IDE bus was resetted during the system
boot.
Could you try setting HPT374_ALLOW_ATA133_6 to 0 in
At Tue, 05 Jun 2007 14:26:38 +0200,
I wrote:
At Tue, 29 May 2007 22:18:05 +0200 (MEST),
Jan Engelhardt wrote:
On May 29 2007 18:41, Takashi Iwai wrote:
Well, I find the change of CONFIG_SND to menuconfig is fine, too.
But CONFIG_SND_PCI_DRIVERS and others don't make much sense to
On 06/05/2007 02:07 PM, John Anthony Kazos Jr. wrote:
The name says exactly what it is. It's not at all dreadful. If we're going
to return a special value in the zero-size case (and in only that case) as
a valid pointer instead of actually allocating one byte and treating it as
zero, what we
On 6/5/2007, Linus Walleij (LD/EAB) [EMAIL PROTECTED]
wrote:
Sam wrote:
Andrey, in addition to Bjorn's patch, could you also apply
this one and try again:
diff --git a/drivers/net/irda/smsc-ircc2.c
b/drivers/net/irda/smsc-ircc2.c index 31c6233..800562a 100644
---
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
Subject: [PATCH 1/1] containers: implement nsproxy
On Tue, 2007-06-05 at 12:01 +0200, Andi Kleen wrote:
But TSC is a required feature, so cpu_has_tsc is always true.
Hmm? It isn't. What makes you think so?
Interestingly it seems to be only in -mm.
How about this patch:
===
Don't try to disable the TSC: it's a required feature under
Wakko Warner wrote:
Tom Moore wrote:
Thank you for the reply back. Your answer makes perfect sense to me,
and it is what I had suspected but was not sure about. The math seems
to indicate that 4Gb of ram plus 1Gb of PCI address space equals 5Gb of
memory space. So it does sound like I
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
Quoting Pavel Emelianov ([EMAIL PROTECTED]):
Serge E. Hallyn wrote:
From 190ea72d213393dd1440643b2b87b5b2128dff87 Mon Sep 17 00:00:00 2001
From: Serge E. Hallyn [EMAIL PROTECTED]
Date: Mon, 4 Jun 2007 14:18:52 -0400
On Tue, 5 Jun 2007, Andi Kleen wrote:
So the only safe thing we can do is not use memory that is not
write-back cached. That we can positively detect and is a
conservative action so if anything will work that will.
Jesse wrote such a patch (or rather it limitted end_pfn), but it broke
the
Richard Purdie wrote:
Index: linux-2.6.21/lib/Kconfig
===
--- linux-2.6.21.orig/lib/Kconfig 2007-06-04 12:19:37.0 +0100
+++ linux-2.6.21/lib/Kconfig 2007-06-04 12:19:46.0 +0100
@@ -71,6 +71,11 @@ config
On Tue, Jun 05, 2007 at 10:19:59AM +0200, Sam Ravnborg wrote:
[]
If on the other hand you are proposing a script to clean whitespace
damage in the code then git already does this nicely.
I've read that too quickly, sorry. What then all that clean scripts
are for?
I do not recall the actual
Well, I find the change of CONFIG_SND to menuconfig is fine, too.
But CONFIG_SND_PCI_DRIVERS and others don't make much sense to me.
How is it useful at all?
Hah, I just tell you some of my own experience.
In summer 2003, I bought the last new machine, and it got these
shiny new
On Tue, Jun 05, 2007 at 09:12:00AM -0400, Tom Moore wrote:
Ok, so it appears that this one is wrong also. If someone could explain
the rules that apply, I would be happy to prepare a patch to the Kconfig
script. I don't consider myself to be completely stupid, and if the
help text was a bit
On Tue, Jun 05, 2007 at 02:37:38PM +1000, Rusty Russell wrote:
On Mon, 2007-06-04 at 23:18 -0500, Matt Mackall wrote:
On Tue, Jun 05, 2007 at 12:31:15PM +1000, Rusty Russell wrote:
Does this solve it for you?
Nope. Doesn't accept input and hogs the CPU with lots of system time.
Dumb
On Monday 04 June 2007 12:56, Alexey Dobriyan wrote:
On 6/4/07, Biker [EMAIL PROTECTED] wrote:
WARNING: at mm/slab.c:777 __find_general_cachep()
[c016e0c4] [f943288c] [f9112bfa] [f90f8546] [c0104c90]
[c033702e] [f90f15dd] [f911de1d] [f911e123] [c01714d7]
[f911ba7c] [f94300c9]
On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
NAK
We have generic devices and generic DMA mapping. libata already uses
the generic stuff. Now fix the platform...
Nice theory but your generic helpers rely on the map functions working
even for generic hardware that doesn't
The name says exactly what it is. It's not at all dreadful. If we're going
to return a special value in the zero-size case (and in only that case) as a
valid pointer instead of actually allocating one byte and treating it as
zero, what we have is...a zero-size pointer.
No, what we have
On Tue, Jun 05, 2007 at 09:19:04AM +0200, Ingo Molnar wrote:
* Matt Mackall [EMAIL PROTECTED] wrote:
sleep_max: 57476665627
block_max: 18014060106626075
hm, this block_max looks a bit suspect, it's 003fffb1359e341b. Does your
box make any use
On Tue, Jun 05, 2007 at 11:23:44AM +0200, Ingo Molnar wrote:
* Matt Mackall [EMAIL PROTECTED] wrote:
Ok, my transcoding just finished as I was writing this. So I've
reproduced the problem with this Python script that I had handy:
memload.py:
#!/usr/bin/python
a = a * 16 * 1024 *
Stefan Seyfried wrote:
Hi,
On Sat, May 26, 2007 at 06:42:37PM -0400, Bill Davidsen wrote:
I was testing susp2disk in 2.6.21.1 under FC6, to support reliable computing
environment (RCE) needs. The idea is that if power fails, after some short
time on UPS the system does susp2disk with a time
For every valid ARRAY_SIZE() use sparse warns about
cannot size expression. This is somewhat annoying, because code is OK.
$ cat 1.c
#define BUILD_BUG_ON_ZERO(e) (sizeof(char[1 - 2 * !!(e)]) - 1)
#define __must_be_array(a)
BUILD_BUG_ON_ZERO(__builtin_types_compatible_p(typeof(a), typeof(a[0])))
On Tue, Jun 05, 2007 at 03:38:34PM +0200, Oleg Verych wrote:
On Tue, Jun 05, 2007 at 10:19:59AM +0200, Sam Ravnborg wrote:
[]
If on the other hand you are proposing a script to clean whitespace
damage in the code then git already does this nicely.
I've read that too quickly, sorry. What
Hello, I wrote:
I felt inspired by this explanation (thanks!) and took a look at
hpt374-opensource-v2.10 vendor driver. Here is something interesting:
glbdata.c:
...
#ifdef CLOCK_66MHZ
ULONG setting370_66[] = {
0xd029d5e, 0xd029d26, 0xc829ca6, 0xc829c84, 0xc829c62,
On Tue, Jun 05, 2007 at 09:56:08AM -0400, Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
NAK
We have generic devices and generic DMA mapping. libata already uses
the generic stuff. Now fix the platform...
Nice theory but your generic helpers rely
At Tue, 5 Jun 2007 15:25:07 +0200 (MEST),
Jan Engelhardt wrote:
Well, I find the change of CONFIG_SND to menuconfig is fine, too.
But CONFIG_SND_PCI_DRIVERS and others don't make much sense to me.
How is it useful at all?
Hah, I just tell you some of my own experience.
In
Hello All
I am forwarding one more improved patch related with fork
bombing attack. I have used printk_ratelimit function in my patch
and it works rellly well. it prints message as per printk_ratelimit
values stored in /proc/sys/kernel/printk_ratelimit
and
On Mon, 4 Jun 2007, Michael Hanselmann wrote:
On Sat, Jun 02, 2007 at 10:49:44AM -0400, Alan Stern wrote:
Then later on, when the hub driver is resumed it will see the flag and
disconnect all the devices below the root hub.
For instance, you could force ohci-hcd to report connect-change
On Tuesday 05 June 2007 15:11, Rusty Russell wrote:
On Tue, 2007-06-05 at 12:01 +0200, Andi Kleen wrote:
But TSC is a required feature, so cpu_has_tsc is always true.
Hmm? It isn't. What makes you think so?
Interestingly it seems to be only in -mm.
If it is then it doesn't come out of
On Tue, Jun 05, 2007 at 03:17:14PM +0100, Russell King wrote:
On Tue, Jun 05, 2007 at 09:56:08AM -0400, Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 12:22:18PM +0100, Alan Cox wrote:
NAK
We have generic devices and generic DMA mapping. libata already uses
the generic stuff. Now
On Jun 5 2007 16:17, Takashi Iwai wrote:
Hm, I guess Jens didn't know about this side-effect.
When I don't set default y, I'll be asked for each belonging item
even though I chose y manually for the top config
(CONFIG_*_DRIVERS).
Strangely, setting default y has no this effect...
Not in
At Tue, 5 Jun 2007 16:20:53 +0200 (MEST),
Jan Engelhardt wrote:
On Jun 5 2007 16:17, Takashi Iwai wrote:
Hm, I guess Jens didn't know about this side-effect.
When I don't set default y, I'll be asked for each belonging item
even though I chose y manually for the top config
On 06/05/2007 03:58 PM, John Anthony Kazos Jr. wrote:
So ZERO_SIZE_OBJ_PTR is the most correct form, and ZERO_SIZE_PTR is a
convenient shortening. ZERO_PTR is too short and also confuses with NULL
because NULL is a zero-value object, rather than a non-zero--value pointer to
a zero-size object.
BTW, please fix your mailer. It emits Mail-Followup-To headers that
hijack everyone on the thread into the To field, breaking the normal
LKML To/CC standard replying mechanism that has been working for a
decade.
Jeff
-
To unsubscribe from this list: send the line unsubscribe
I am using stock cooling in a well ventilated case, I was wondering if
these temps are normal, e.g. I see this in dmesg:
[ 60.505648] coretemp coretemp.0: Using undocumented features, absolute
temperature might be wrong!
[ 60.505792] coretemp coretemp.1: Using undocumented features,
Rene Herman wrote:
No, what we have is a sizeof(pointer) sized pointer pointing to an
object of size zero. ZERO_SIZE_PTR is butt-ugly. With a really ugly butt.
It doesn't matter. It will never, ever, be used by anything except the
kmalloc internals. No client code should ever use the
The kernel uses UINT_MAX defined from kernel.h in a variety of places.
While looking at the behaviour of the LZO code, I noticed it seemed to
think an int was 8 bytes large on my 32 bit i386 machine. It isn't but
why did it think that?
kernel.h says:
#define INT_MAX ((int)(~0U1))
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Unclassified
Subject: Kernel hang on CMOS_READ
References : http://lkml.org/lkml/2007/6/3/138
Submitter : Rodrigo Luiz [EMAIL
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
ACPI
Subject: ACPI_CPUFREQ fails to load - HP ML110 G4 Xeon 3040
References : http://bugzilla.kernel.org/show_bug.cgi?id=8570
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Networking
Subject: list_add corruption. prev-next should be next (f7d28794), but was
f0df8ed4 (prev=f0df8ed4) Kernel Bug at
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
SATA/PATA
Subject: 22-rc3 broke the CDROM in Dell notebook
References : http://lkml.org/lkml/2007/5/27/63
Submitter : Gregor
Hi all,
Here is a list of some known regressions in 2.6.22-rc4.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
USB
Subject: Unable to get HID descriptor (error sending control message:
Operation not permitted)
References :
Hello,
The 2.6.22-rc3 USB issue was because I did not have the deprecated USB
option enabled. Once I enabled it, the problem went away. That can be
bug can be considered resolved.
Justin.
On Tue, 5 Jun 2007, Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in
On Tue, Jun 05, 2007 at 04:12:54PM +0200, Sam Ravnborg wrote:
On Tue, Jun 05, 2007 at 03:38:34PM +0200, Oleg Verych wrote:
On Tue, Jun 05, 2007 at 10:19:59AM +0200, Sam Ravnborg wrote:
[]
If on the other hand you are proposing a script to clean whitespace
damage in the code then git
On Tue, 5 Jun 2007, Michal Piotrowski wrote:
SELinux
Subject: very high non-preempt latency in context_struct_compute_av()
References : http://lkml.org/lkml/2007/6/4/78
Submitter : Ingo Molnar [EMAIL PROTECTED]
Handled-By : Stephen Smalley [EMAIL PROTECTED]
James Morris
On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
BTW, please fix your mailer. It emits Mail-Followup-To headers that
hijack everyone on the thread into the To field, breaking the normal
LKML To/CC standard replying mechanism that has been working for a
decade.
Sorry, I will
wonderful long list :)
the 2.6.22 is the next unstable developing tree, the 2.7 tree? When
not, then so be the stabilization kernel and so be 2.6.22-rcX (
X-1..15 ), and 0 regression.
/* sorry for the spelling, but I learn English not. */
-
To unsubscribe from this list: send the line
Hi all,
Here is a list of some known regressions in 2.6.22-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
Block devices
Subject: loop devices limited to one single device
References :
Hi all,
Here is a list of some known regressions in 2.6.22-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
PCI
Subject: Oops on 2.6.22-rc2 when unloading the cciss driver
References :
Tony Luck wrote:
I used the sn2_defconfig in the tree :)
So there is something odd happening. Russ complained that he
was still seeing several errors from the sn2_defconfig build
too when I posted the last fix to Len. But I don't see them
when I build.
An additional data point. I
On Tue, Jun 05, 2007 at 03:51:49PM +0100, Russell King wrote:
On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
BTW, please fix your mailer. It emits Mail-Followup-To headers that
hijack everyone on the thread into the To field, breaking the normal
LKML To/CC standard
On 06/05/2007 04:40 PM, Jeremy Fitzhardinge wrote:
Rene Herman wrote:
No, what we have is a sizeof(pointer) sized pointer pointing to an
object of size zero. ZERO_SIZE_PTR is butt-ugly. With a really ugly butt.
It doesn't matter. It will never, ever, be used by anything except the
On Tue, Jun 05, 2007 at 10:56:03AM -0400, Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 03:51:49PM +0100, Russell King wrote:
On Tue, Jun 05, 2007 at 10:35:23AM -0400, Jeff Garzik wrote:
BTW, please fix your mailer. It emits Mail-Followup-To headers that
hijack everyone on the thread
On Tue, 2007-06-05 at 16:54 +0200, Michal Piotrowski wrote:
Hi all,
Here is a list of some known regressions in 2.6.22-rc4
with patches available.
Feel free to add new regressions/remove fixed etc.
http://kernelnewbies.org/known_regressions
PCI
Subject: Oops on 2.6.22-rc2
On Tue, Jun 05, 2007 at 04:57:59PM +0200, Oleg Verych wrote:
[]
expand | while read line
do case $line in
++*) echo $line;;
$p*) [ ${#line} -gt $w79 ] : ${long:=line}
echo $line | sed /^$p/{s_ *\$__;s_^$p$s7${s}_$p${t}_;s_$s7 _${t}_g}
;;
*) echo $line;;
On Tue, 2007-06-05 at 16:54 +0200, Michal Piotrowski wrote:
File systems
Subject: JFFS2 issues
References :
http://lists.infradead.org/pipermail/linux-mtd/2007-May/018426.html
Submitter : Haavard Skinnemoen [EMAIL PROTECTED]
Caused-By : commit
On Tue, Jun 05, 2007 at 03:59:46PM +0100, Russell King wrote:
It's the fact that I _am_ CC'd on replies, so I get one message from LKML
one from the original poster, maybe one via another mailing list if it's
also copied there. Add that in to the mix of all the other mail hitting
my MTA and
On 05/06/07, Matt Mackall [EMAIL PROTECTED] wrote:
[...]
Click into the lguest window and trigger the delay.
I did:
while true; do sleep 1; cat /proc/sched_debug sched_debug.txt; done
and got this, hopefully inside the window:
Sched Debug Version: v0.02
now at 257428593818894 nsecs
cpu:
The purpose of audit_bprm() is to log the argv array to a userspace daemon at
the end of the execve system call. Since user-space hasn't had time to run,
this array is still in pristine state on the process' stack; so no need to copy
it, we can just grab it from there.
In order to minimize the
This patch-set aims at removing the current limit on argv+env space aka.
MAX_ARG_PAGES.
The new mm is created before the binfmt code runs, the stack is placed at the
highest address supported by that architecture.
The argv+env data is then copied from the old mm into the new mm (which is
New arch macro STACK_TOP_MAX it gives the larges valid stack address for
the architecture in question.
It differs from STACK_TOP in that it will not distinguish between personalities
but will always return the largest possible address.
This is used to create the initial stack on execve, which we
Provide functions for moving page tables upwards.
Signed-off-by: Peter Zijlstra [EMAIL PROTECTED]
Signed-off-by: Ollie Wild [EMAIL PROTECTED]
---
include/linux/mm.h |7 +++
mm/mremap.c| 105 -
2 files changed, 110 insertions(+), 2
From: Ollie Wild [EMAIL PROTECTED]
Remove the arg+env limit of MAX_ARG_PAGES by copying the strings directly
from the old mm into the new mm.
We create the new mm before the binfmt code runs, and place the new stack
at the very top of the address space. Once the binfmt code runs and figures
out
On Tue, Jun 05, 2007 at 11:11:04AM -0400, Jeff Garzik wrote:
On Tue, Jun 05, 2007 at 03:59:46PM +0100, Russell King wrote:
It's the fact that I _am_ CC'd on replies, so I get one message from LKML
one from the original poster, maybe one via another mailing list if it's
also copied there.
501 - 600 of 876 matches
Mail list logo
