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
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
Unclassified
Subject: Kernel hang on CMOS_READ
References : http://lkml.org/lkml/2007/6/3/138
Submitter : Rodrigo Luiz <[EMAIL
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)(~0U>>1))
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,
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
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
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
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...
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
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
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
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
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
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 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,
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([0])))
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
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
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
> > 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,
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
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()
> > [] [] [] [] []
> > [] [] [] [] []
> > [] [] [] [] []
> > [] [] [] []
>
> Please, enable CONFIG_DEBUG_BUGVERBOSE, or decipher
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
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
>> > >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
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
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, 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
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
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
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
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:
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
>> ---
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
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
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
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.
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
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.
>
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
> > 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
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,
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
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
> @@
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
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
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.
> > ---
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 : 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
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
> > >
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
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
> 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
> > 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
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
> > 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
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)
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:' format)
> - */
> -#ifndef MODULE
> - char *option = NULL;
> -
> - if
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
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
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
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-
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
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 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
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
> 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
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
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> > ah, plain -rc3 hangs too. So it's one of these commits i guess:
> >
> > commit 1eeb66a1bb973534dc3d064920a5ca683823372e
> > commit 09198e68501a7e34737cd9264d266f42429abcdc
> > commit bbba11c35baaad3f70f32e185a2c1d40d7901fe9
> > commit
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
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> * Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > commenting out check_nmi_watchdog() produces a booting kernel too. So
> > it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
> > nmi.c changed in -mm1 AFAICS.
>
> ah, plain -rc3 hangs
> 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 X server for so far unknown reasons.
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> commenting out check_nmi_watchdog() produces a booting kernel too. So
> it's a side-effect of check_nmi_watchdog(). Problem is, nothing in
> nmi.c changed in -mm1 AFAICS.
ah, plain -rc3 hangs too. So it's one of these commits i guess:
commit
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> i have put an early_printk() into the NMI handler but it never
> triggers.
commenting out check_nmi_watchdog() produces a booting kernel too. So
it's a side-effect of check_nmi_watchdog(). Problem is, nothing in nmi.c
changed in -mm1 AFAICS.
On Tue, 2007-06-05 at 11:34 +0200, Stefan Seyfried wrote:
> On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
> > FWIW, on my old laptop apm beats any kernel solution hands down in terms
> > of speed
>
> This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
>
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> yeah. I tried !hres and !dynticks too and that doesnt make any
> difference to the end result - so my guess is on the NMI watchdog
> re-programming thing on K8 CPUs (running the 32-bit kernel), which is
> done in every NMI tick. check_watchdog() for
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 set, and boots back
On Tue, Jun 05, 2007 at 10:15:41AM +0200, Xavier Bestel wrote:
> FWIW, on my old laptop apm beats any kernel solution hands down in terms
> of speed
This might be true on 64MB systems. It is surely not true on multi-Gigabyte-
RAM setups. At least not if you actually use that memory for anything
* Andrew Morton <[EMAIL PROTECTED]> wrote:
> On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
>
> > hm, mm1 hangs during bootup on one of my boxes:
> >
> > Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
> > initcall 0xc0628d39:
On Thu, May 31, 2007 at 06:08:23PM -0500, Steve French wrote:
> With Samba 3.0.26pre it is now possible for a cifs client (one which
> supports the newest Unix/Posix cifs extensions) to request up to
> almost 8MB at a time on a cifs read request.
>
> A patch for the cifs client to support larger
Linus Torvalds wrote:
> So -rc4 is out there now, hopefully shrinking the regression list further.
>
> The diffstat (for those that look at those kinds of things) tells the
> story: lots of small stuff to random files. I think the single biggest
> file change was the patch-checking script,
* 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 * 1024
> while 1:
> b = a[1:] + "b"
> a = b[1:] + "c"
On Tue, 5 Jun 2007 11:11:51 +0200 Ingo Molnar <[EMAIL PROTECTED]> wrote:
> hm, mm1 hangs during bootup on one of my boxes:
>
> Calling initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44()
> initcall 0xc0628d39: pci_mmcfg_late_insert_resources+0x0/0x44() returned 0.
> initcall
* Ingo Molnar <[EMAIL PROTECTED]> wrote:
> the NMI watchdog warning is a bit weird:
>
> Calling initcall 0xc0613e4f: check_nmi_watchdog+0x0/0x1a8()
> Testing NMI watchdog ... CPU#0: NMI appears to be stuck (0->0)!
> CPU#1: NMI appears to be stuck (0->0)!
> initcall 0xc0613e4f:
On 06/05/2007 04:10 AM, WANG Cong wrote:
On Mon, Jun 04, 2007 at 01:57:51PM -0400, Jeff Garzik wrote:
A matter of opinion :) I tend to think goto is special enough to
warrant column 1 unconditionally. It is special, so it draws additional
attention over and above case labels.
I and others
On Mon, 4 Jun 2007, Robert Hancock wrote:
James Jarvis wrote:
I trust this is the right list...
The following patch enables reboot through BIOS on the Dell Optiplex 745
Small Form Factor base, on which reboot hangs. The larger form factor does
not require this, hence the match on
On 5 Jun, 05:40, "Mike Richards" <[EMAIL PROTECTED]> wrote:
Here's something that's been bugging me for a while now...
I have several Linux servers that have been given enough RAM that they
rarely ever use any swap space. For example, here's the typical output
of uptime and free:
[EMAIL
Mark Lord wrote:
> That's odd. Could you try that again,
> with the latest (either v7.3 or v7.4) version of hdparm
> (from sourceforge) ?
Using Debian's 7.3 via apt-get experimental - is that OK or would you like me to
compile the upstream?
2.6.21.1
cu:~# hdparm -V
hdparm v7.3
cu:~# hdparm -K1
On Mon, 2007-06-04 at 22:50 -0700, Andrew Morton wrote:
> I'd say go with the cleanups. The code I've seen is going to be quite
> unmaintainable by any kernel developer.
>
> Any fixes which come from upstream can be trivially applied by taking the
> diffs against the version of upstream we
Ingo Molnar wrote:
* Li Yu <[EMAIL PROTECTED]> wrote:
Eh, I wrong again~ I even took an experiment in last week end, this
idea is really bad! ;(
I think the most inner of source of my wrong again and again is
misunderstanding virtual time. For more better understanding this, I
try to
On 06/05/2007 01:09 AM, Christoph Lameter wrote:
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
Am Dienstag, 5. Juni 2007 06:08 schrieb Andrew Morton:
> Everything in USB appears to already be fixed, apart from the io_ti.c bug.
Yes, that's a bug. I've queued a patch.
Regards
Oliver
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body
Pavel Emelianov wrote:
>> +1. RSS controller
>> +2. Page Cache controller
>> +3. mlock(2) controller
>> +4. Kernel user memory accounting and slab control
>
> I would add the user-mappings-length controller
>
:-) I'll update the document
>> +The RSS controller is the first controller
301 - 400 of 876 matches
Mail list logo
