* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
@ 2008-12-11 2:37 ` Gabriel C
2008-12-11 7:19 ` Eric Anholt
2008-12-11 5:09 ` Arjan van de Ven
` (11 subsequent siblings)
12 siblings, 1 reply; 40+ messages in thread
From: Gabriel C @ 2008-12-11 2:37 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, Rafael J. Wysocki
While I got some time again I decided to test rc8 and noticed the following warning :
...
[ 23.090942] resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
[ 23.090948] ------------[ cut here ]------------
[ 23.090951] WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x2c9()
[ 23.090952] Modules linked in: i915 binfmt_misc acpi_cpufreq freq_table w83627ehf hwmon_vid fuse loop lp ppdev joydev i2c_i801 parport_pc button evdev parport intel_agp processor sg pcspkr
[ 23.090969] Pid: 4632, comm: X Not tainted 2.6.28-rc8-dirty #25
[ 23.090971] Call Trace:
[ 23.090976] [<ffffffff8024106f>] warn_on_slowpath+0x58/0x7d
[ 23.090979] [<ffffffff8022c255>] ? change_page_attr_set_clr+0x136/0x304
[ 23.090982] [<ffffffff8022c65b>] ? _set_memory_uc+0x22/0x24
[ 23.090985] [<ffffffff8022b0a3>] ? ioremap_change_attr+0x18/0x28
[ 23.090989] [<ffffffff8022b17a>] __ioremap_caller+0xc7/0x2c9
[ 23.090997] [<ffffffffa00b1e1e>] ? i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
[ 23.091000] [<ffffffff8022b46c>] ioremap_wc+0x1b/0x27
[ 23.091006] [<ffffffffa00b1e1e>] i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
[ 23.091010] [<ffffffff802a8f6f>] ? do_sync_write+0xe7/0x12d
[ 23.091014] [<ffffffff803e1e36>] drm_ioctl+0x1d6/0x25e
[ 23.091020] [<ffffffffa00b19cd>] ? i915_gem_entervt_ioctl+0x0/0x4e6 [i915]
[ 23.091024] [<ffffffff802b55d9>] vfs_ioctl+0x5f/0x78
[ 23.091026] [<ffffffff802b5984>] do_vfs_ioctl+0x392/0x3c0
[ 23.091030] [<ffffffff80554049>] ? _spin_unlock+0x9/0x32
[ 23.091033] [<ffffffff802b5a07>] sys_ioctl+0x55/0x77
[ 23.091036] [<ffffffff8020c15a>] system_call_fastpath+0x16/0x1b
[ 23.091038] ---[ end trace 79a035f1175c4e1d ]---
...
I'm sure this warning was not present on rc1/rc2 back when I've tested these.
Also this warning is not present in 2.6.27.*
Regards,
Gabriel C
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 2:37 ` Gabriel C
@ 2008-12-11 7:19 ` Eric Anholt
2008-12-11 16:07 ` Frans Pop
0 siblings, 1 reply; 40+ messages in thread
From: Eric Anholt @ 2008-12-11 7:19 UTC (permalink / raw)
To: Gabriel C; +Cc: Linus Torvalds, Linux Kernel Mailing List, Rafael J. Wysocki
[-- Attachment #1: Type: text/plain, Size: 2713 bytes --]
On Thu, 2008-12-11 at 03:37 +0100, Gabriel C wrote:
> While I got some time again I decided to test rc8 and noticed the following warning :
Unfortunately DRM comes second to the party, so it gets the backtrace
blame, but that framebuffer should really be mapped WC by vesafb.
You're just losing performance for having it mapped UC, and that should
be the only effect other than the whining in the log.
My recommended solution, of course, is to remove vesafb.
> [ 23.090942] resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
> [ 23.090948] ------------[ cut here ]------------
> [ 23.090951] WARNING: at arch/x86/mm/ioremap.c:226 __ioremap_caller+0xc7/0x2c9()
> [ 23.090952] Modules linked in: i915 binfmt_misc acpi_cpufreq freq_table w83627ehf hwmon_vid fuse loop lp ppdev joydev i2c_i801 parport_pc button evdev parport intel_agp processor sg pcspkr
> [ 23.090969] Pid: 4632, comm: X Not tainted 2.6.28-rc8-dirty #25
> [ 23.090971] Call Trace:
> [ 23.090976] [<ffffffff8024106f>] warn_on_slowpath+0x58/0x7d
> [ 23.090979] [<ffffffff8022c255>] ? change_page_attr_set_clr+0x136/0x304
> [ 23.090982] [<ffffffff8022c65b>] ? _set_memory_uc+0x22/0x24
> [ 23.090985] [<ffffffff8022b0a3>] ? ioremap_change_attr+0x18/0x28
> [ 23.090989] [<ffffffff8022b17a>] __ioremap_caller+0xc7/0x2c9
> [ 23.090997] [<ffffffffa00b1e1e>] ? i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
> [ 23.091000] [<ffffffff8022b46c>] ioremap_wc+0x1b/0x27
> [ 23.091006] [<ffffffffa00b1e1e>] i915_gem_entervt_ioctl+0x451/0x4e6 [i915]
> [ 23.091010] [<ffffffff802a8f6f>] ? do_sync_write+0xe7/0x12d
> [ 23.091014] [<ffffffff803e1e36>] drm_ioctl+0x1d6/0x25e
> [ 23.091020] [<ffffffffa00b19cd>] ? i915_gem_entervt_ioctl+0x0/0x4e6 [i915]
> [ 23.091024] [<ffffffff802b55d9>] vfs_ioctl+0x5f/0x78
> [ 23.091026] [<ffffffff802b5984>] do_vfs_ioctl+0x392/0x3c0
> [ 23.091030] [<ffffffff80554049>] ? _spin_unlock+0x9/0x32
> [ 23.091033] [<ffffffff802b5a07>] sys_ioctl+0x55/0x77
> [ 23.091036] [<ffffffff8020c15a>] system_call_fastpath+0x16/0x1b
> [ 23.091038] ---[ end trace 79a035f1175c4e1d ]---
>
> ...
>
>
> I'm sure this warning was not present on rc1/rc2 back when I've tested these.
> Also this warning is not present in 2.6.27.*
>
>
> Regards,
>
> Gabriel C
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
--
Eric Anholt
eric@anholt.net eric.anholt@intel.com
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 7:19 ` Eric Anholt
@ 2008-12-11 16:07 ` Frans Pop
2008-12-11 16:22 ` Linus Torvalds
0 siblings, 1 reply; 40+ messages in thread
From: Frans Pop @ 2008-12-11 16:07 UTC (permalink / raw)
To: Eric Anholt; +Cc: nix.or.die, torvalds, linux-kernel, rjw
Eric Anholt wrote:
> My recommended solution, of course, is to remove vesafb.
How is taking away useful functionality from users a better option than
just fixing the bug?
Cheers,
FJP
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 16:07 ` Frans Pop
@ 2008-12-11 16:22 ` Linus Torvalds
2008-12-11 16:35 ` Ingo Molnar
0 siblings, 1 reply; 40+ messages in thread
From: Linus Torvalds @ 2008-12-11 16:22 UTC (permalink / raw)
To: Frans Pop; +Cc: Eric Anholt, nix.or.die, linux-kernel, rjw
On Thu, 11 Dec 2008, Frans Pop wrote:
> Eric Anholt wrote:
> > My recommended solution, of course, is to remove vesafb.
>
> How is taking away useful functionality from users a better option than
> just fixing the bug?
Well, just to clarify: it's not a _bug_. It's a benign warnign that two
subsystems are trying to map the same memory differently.
In this case, we have:
resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
and what it means is that the caller (which is i915_gem_entervt_ioctl) is
trying to apparently ioremap the _whole_ graphics card MMIO resource
(0xd0000000-0xdfffffff), but the vesafb driver has already registered the
fact that it uses _part_ of that resource (0xd0000000-0xd07effff).
There's no bug there. It's a warning. It's usually a very odd situation
when somebody tries to ioremap something that crosses resource reservation
boundaries, but the thing is, in this case it's not really a problem.
It's triggered by a couple of oddities:
- fbcon (vesafb) is odd and only requests a partial resource, because it
only uses part of the MMIO window.
- the interaction between fbcon and X is odd to begin with, since they
both use the same physical resource.
so it's a generic warning that triggers because these things _shouldn't_
happen, but it's not actually an error in this case. We could just remove
the warning. Or leave it in, in case it finds other (real) issues, and
just ignore it.
Linus
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 16:22 ` Linus Torvalds
@ 2008-12-11 16:35 ` Ingo Molnar
2008-12-11 17:05 ` Linus Torvalds
0 siblings, 1 reply; 40+ messages in thread
From: Ingo Molnar @ 2008-12-11 16:35 UTC (permalink / raw)
To: Linus Torvalds
Cc: Frans Pop, Eric Anholt, nix.or.die, linux-kernel, rjw, Arjan van de Ven
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Thu, 11 Dec 2008, Frans Pop wrote:
>
> > Eric Anholt wrote:
> > > My recommended solution, of course, is to remove vesafb.
> >
> > How is taking away useful functionality from users a better option than
> > just fixing the bug?
>
> Well, just to clarify: it's not a _bug_. It's a benign warnign that two
> subsystems are trying to map the same memory differently.
>
> In this case, we have:
>
> resource map sanity check conflict: 0xd0000000 0xdfffffff 0xd0000000 0xd07effff vesafb
>
> and what it means is that the caller (which is i915_gem_entervt_ioctl) is
> trying to apparently ioremap the _whole_ graphics card MMIO resource
> (0xd0000000-0xdfffffff), but the vesafb driver has already registered the
> fact that it uses _part_ of that resource (0xd0000000-0xd07effff).
>
> There's no bug there. It's a warning. It's usually a very odd situation
> when somebody tries to ioremap something that crosses resource reservation
> boundaries, but the thing is, in this case it's not really a problem.
>
> It's triggered by a couple of oddities:
>
> - fbcon (vesafb) is odd and only requests a partial resource, because it
> only uses part of the MMIO window.
>
> - the interaction between fbcon and X is odd to begin with, since they
> both use the same physical resource.
>
> so it's a generic warning that triggers because these things
> _shouldn't_ happen, but it's not actually an error in this case. We
> could just remove the warning. Or leave it in, in case it finds other
> (real) issues, and just ignore it.
hm, the warning caught a couple of real bugs already. (one in some cpq
driver, another was in some networking driver iirc)
Ingo
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 16:35 ` Ingo Molnar
@ 2008-12-11 17:05 ` Linus Torvalds
2008-12-11 20:36 ` Ingo Molnar
0 siblings, 1 reply; 40+ messages in thread
From: Linus Torvalds @ 2008-12-11 17:05 UTC (permalink / raw)
To: Ingo Molnar
Cc: Frans Pop, Eric Anholt, nix.or.die, linux-kernel, rjw, Arjan van de Ven
On Thu, 11 Dec 2008, Ingo Molnar wrote:
>
> hm, the warning caught a couple of real bugs already. (one in some cpq
> driver, another was in some networking driver iirc)
Well, one thing that does irritate me is that it scares people who can't
do anything about it, and probably _shouldn't_ do anything about it.
I wonder if we should just change the "Warning" message to "Informational"
or something. Yes, they are often real bugs. But no, they're not
_automatically_ bugs. Almost all the time when a warning triggers, it's
really just a developer who wants to know about it, it's not something
that a user should really care/worry about.
Linus
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 17:05 ` Linus Torvalds
@ 2008-12-11 20:36 ` Ingo Molnar
2008-12-11 20:46 ` Pekka Enberg
0 siblings, 1 reply; 40+ messages in thread
From: Ingo Molnar @ 2008-12-11 20:36 UTC (permalink / raw)
To: Linus Torvalds
Cc: Frans Pop, Eric Anholt, nix.or.die, linux-kernel, rjw,
Arjan van de Ven, Yinghai Lu
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Thu, 11 Dec 2008, Ingo Molnar wrote:
> >
> > hm, the warning caught a couple of real bugs already. (one in some
> > cpq driver, another was in some networking driver iirc)
>
> Well, one thing that does irritate me is that it scares people who
> can't do anything about it, and probably _shouldn't_ do anything about
> it.
yeah - and false positives also tend to create apathy and resistence
against kernel warnings - thus drawing tester resources away from more
important bugs.
> I wonder if we should just change the "Warning" message to
> "Informational" or something. Yes, they are often real bugs. But no,
> they're not _automatically_ bugs. Almost all the time when a warning
> triggers, it's really just a developer who wants to know about it, it's
> not something that a user should really care/worry about.
ok. In this case i'd suggest we should just remove the warning. People do
get scared by needless kernel stack dumps - no matter whether it's marked
informational or not.
So how about the patch below, queued up in tip/x86/debug? Arjan, what do
you think?
Ingo
--------------->
>From 2dcae81e819fa5cc0e9310ef8b0c079940df3bf3 Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Thu, 11 Dec 2008 21:29:51 +0100
Subject: [PATCH] IO resources, x86: remove multi-BAR mapping sanity check
Impact: remove a debug warning
The ioremap() time multi-BAR map warning has been causing false positives:
http://lkml.org/lkml/2008/12/10/432
http://lkml.org/lkml/2008/12/11/136
So remove it for now.
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/ioremap.c | 6 ------
include/linux/ioport.h | 1 -
kernel/resource.c | 38 --------------------------------------
3 files changed, 0 insertions(+), 45 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..421b92d 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -220,12 +220,6 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
return (__force void __iomem *)phys_to_virt(phys_addr);
/*
- * Check if the request spans more than any BAR in the iomem resource
- * tree.
- */
- WARN_ON(iomem_map_sanity_check(phys_addr, size));
-
- /*
* Don't allow anybody to remap normal RAM that we're using..
*/
for (pfn = phys_addr >> PAGE_SHIFT;
diff --git a/include/linux/ioport.h b/include/linux/ioport.h
index 041e95a..0dde772 100644
--- a/include/linux/ioport.h
+++ b/include/linux/ioport.h
@@ -174,7 +174,6 @@ extern struct resource * __devm_request_region(struct device *dev,
extern void __devm_release_region(struct device *dev, struct resource *parent,
resource_size_t start, resource_size_t n);
-extern int iomem_map_sanity_check(resource_size_t addr, unsigned long size);
#endif /* __ASSEMBLY__ */
#endif /* _LINUX_IOPORT_H */
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..4b0bc70 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -829,41 +829,3 @@ static int __init reserve_setup(char *str)
}
__setup("reserve=", reserve_setup);
-
-/*
- * Check if the requested addr and size spans more than any slot in the
- * iomem resource tree.
- */
-int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
-{
- struct resource *p = &iomem_resource;
- int err = 0;
- loff_t l;
-
- read_lock(&resource_lock);
- for (p = p->child; p ; p = r_next(NULL, p, &l)) {
- /*
- * We can probably skip the resources without
- * IORESOURCE_IO attribute?
- */
- if (p->start >= addr + size)
- continue;
- if (p->end < addr)
- continue;
- if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
- PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
- continue;
- printk(KERN_WARNING "resource map sanity check conflict: "
- "0x%llx 0x%llx 0x%llx 0x%llx %s\n",
- (unsigned long long)addr,
- (unsigned long long)(addr + size - 1),
- (unsigned long long)p->start,
- (unsigned long long)p->end,
- p->name);
- err = -1;
- break;
- }
- read_unlock(&resource_lock);
-
- return err;
-}
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 20:36 ` Ingo Molnar
@ 2008-12-11 20:46 ` Pekka Enberg
2008-12-11 21:34 ` Suresh Siddha
2008-12-12 8:24 ` Ingo Molnar
0 siblings, 2 replies; 40+ messages in thread
From: Pekka Enberg @ 2008-12-11 20:46 UTC (permalink / raw)
To: Ingo Molnar
Cc: Linus Torvalds, Frans Pop, Eric Anholt, nix.or.die, linux-kernel,
rjw, Arjan van de Ven, Yinghai Lu
Hi Ingo,
On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> ok. In this case i'd suggest we should just remove the warning. People do
> get scared by needless kernel stack dumps - no matter whether it's marked
> informational or not.
>
> So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> you think?
How come we don't put it under CONFIG_X86_DEBUG or something and hide
somewhere in the "Kernel debugging" menu?
Pekka
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 20:46 ` Pekka Enberg
@ 2008-12-11 21:34 ` Suresh Siddha
2008-12-12 8:24 ` Ingo Molnar
1 sibling, 0 replies; 40+ messages in thread
From: Suresh Siddha @ 2008-12-11 21:34 UTC (permalink / raw)
To: Pekka Enberg
Cc: Ingo Molnar, Linus Torvalds, Frans Pop, Eric Anholt, nix.or.die,
linux-kernel, rjw, Arjan van de Ven, Yinghai Lu
On Thu, Dec 11, 2008 at 12:46:33PM -0800, Pekka Enberg wrote:
> Hi Ingo,
>
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
>
> How come we don't put it under CONFIG_X86_DEBUG or something and hide
> somewhere in the "Kernel debugging" menu?
On the same lines, can we enable this check with a debug boot option?
thanks,
suresh
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 20:46 ` Pekka Enberg
2008-12-11 21:34 ` Suresh Siddha
@ 2008-12-12 8:24 ` Ingo Molnar
2008-12-12 15:57 ` Arjan van de Ven
1 sibling, 1 reply; 40+ messages in thread
From: Ingo Molnar @ 2008-12-12 8:24 UTC (permalink / raw)
To: Pekka Enberg
Cc: Linus Torvalds, Frans Pop, Eric Anholt, nix.or.die, linux-kernel,
rjw, Arjan van de Ven, Yinghai Lu
* Pekka Enberg <penberg@cs.helsinki.fi> wrote:
> Hi Ingo,
>
> On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > ok. In this case i'd suggest we should just remove the warning. People do
> > get scared by needless kernel stack dumps - no matter whether it's marked
> > informational or not.
> >
> > So how about the patch below, queued up in tip/x86/debug? Arjan, what do
> > you think?
>
> How come we don't put it under CONFIG_X86_DEBUG or something and hide
> somewhere in the "Kernel debugging" menu?
okay - how about the following then instead - we still keep the warning,
but do various things to make it appear less scary.
Ingo
----------------->
>From 8808500f26a61757cb414da76b271bbd09d5958c Mon Sep 17 00:00:00 2001
From: Ingo Molnar <mingo@elte.hu>
Date: Fri, 12 Dec 2008 09:20:12 +0100
Subject: [PATCH] x86: soften multi-BAR mapping sanity check warning message
Impact: make debug warning less scary
The ioremap() time multi-BAR map warning has been causing false
positives:
http://lkml.org/lkml/2008/12/10/432
http://lkml.org/lkml/2008/12/11/136
So make it less scary by making it once-per-boot, by making it KERN_INFO
and by adding this text:
"Info: mapping multiple BARs. Your kernel is fine."
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
arch/x86/mm/ioremap.c | 3 ++-
1 files changed, 2 insertions(+), 1 deletions(-)
diff --git a/arch/x86/mm/ioremap.c b/arch/x86/mm/ioremap.c
index d4c4307..bd85d42 100644
--- a/arch/x86/mm/ioremap.c
+++ b/arch/x86/mm/ioremap.c
@@ -223,7 +223,8 @@ static void __iomem *__ioremap_caller(resource_size_t phys_addr,
* Check if the request spans more than any BAR in the iomem resource
* tree.
*/
- WARN_ON(iomem_map_sanity_check(phys_addr, size));
+ WARN_ONCE(iomem_map_sanity_check(phys_addr, size),
+ KERN_INFO "Info: mapping multiple BARs. Your kernel is fine.");
/*
* Don't allow anybody to remap normal RAM that we're using..
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 8:24 ` Ingo Molnar
@ 2008-12-12 15:57 ` Arjan van de Ven
2008-12-12 16:11 ` Linus Torvalds
0 siblings, 1 reply; 40+ messages in thread
From: Arjan van de Ven @ 2008-12-12 15:57 UTC (permalink / raw)
To: Ingo Molnar
Cc: Pekka Enberg, Linus Torvalds, Frans Pop, Eric Anholt, nix.or.die,
linux-kernel, rjw, Yinghai Lu
On Fri, 12 Dec 2008 09:24:56 +0100
Ingo Molnar <mingo@elte.hu> wrote:
>
> * Pekka Enberg <penberg@cs.helsinki.fi> wrote:
>
> > Hi Ingo,
> >
> > On Thu, Dec 11, 2008 at 10:36 PM, Ingo Molnar <mingo@elte.hu> wrote:
> > > ok. In this case i'd suggest we should just remove the warning.
> > > People do get scared by needless kernel stack dumps - no matter
> > > whether it's marked informational or not.
> > >
> > > So how about the patch below, queued up in tip/x86/debug? Arjan,
> > > what do you think?
> >
> > How come we don't put it under CONFIG_X86_DEBUG or something and
> > hide somewhere in the "Kernel debugging" menu?
>
> okay - how about the following then instead - we still keep the
> warning, but do various things to make it appear less scary.
another thing we could do is try to only warn if you cross bar
boundaries but not if you cross other user-of-the-resource boundaries.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 15:57 ` Arjan van de Ven
@ 2008-12-12 16:11 ` Linus Torvalds
2008-12-13 17:15 ` Arjan van de Ven
0 siblings, 1 reply; 40+ messages in thread
From: Linus Torvalds @ 2008-12-12 16:11 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Ingo Molnar, Pekka Enberg, Frans Pop, Eric Anholt, nix.or.die,
linux-kernel, rjw, Yinghai Lu
On Fri, 12 Dec 2008, Arjan van de Ven wrote:
>
> another thing we could do is try to only warn if you cross bar
> boundaries but not if you cross other user-of-the-resource boundaries.
Hmm. We could use the res->flags for this. But I'm not sure non-PCI
resources fill those in correctly.
A pure "busy" allocation (ie a driver marker) would generally have just
the IORESOURCE_BUSY bit set, while a real PCI hardware resource will have
other bits set (ie the IORESOURCE_IO/MEM bits) and not be marked BUSY.
Maybe just ignoring resources with BUSY set, as they are driver markers
rather than actual HW resources.
Linus
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 16:11 ` Linus Torvalds
@ 2008-12-13 17:15 ` Arjan van de Ven
2008-12-16 22:34 ` Ingo Molnar
0 siblings, 1 reply; 40+ messages in thread
From: Arjan van de Ven @ 2008-12-13 17:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: Ingo Molnar, Pekka Enberg, Frans Pop, Eric Anholt, nix.or.die,
linux-kernel, rjw, Yinghai Lu
On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
>
> On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> >
> > another thing we could do is try to only warn if you cross bar
> > boundaries but not if you cross other user-of-the-resource
> > boundaries.
>
> Hmm. We could use the res->flags for this. But I'm not sure non-PCI
> resources fill those in correctly.
>
> A pure "busy" allocation (ie a driver marker) would generally have
> just the IORESOURCE_BUSY bit set, while a real PCI hardware resource
> will have other bits set (ie the IORESOURCE_IO/MEM bits) and not be
> marked BUSY.
>
> Maybe just ignoring resources with BUSY set, as they are driver
> markers rather than actual HW resources.
something like this: ?
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sat, 13 Dec 2008 09:12:18 -0800
Subject: [PATCH] resource: Don't warn for driver originated resource structures
Some drivers (vesafb) only map/reserve a portion of a resource.
If then some other driver comes in and maps the whole resource,
the current code WARN_ON's. This is not the intent of the checks
in iomem_map_sanity_check(); rather these checks want to
warn when crossing *hardware* resources only.
This patch skips BUSY resources as suggested by Linus.
Note: having two drivers talk to the same hardware at the same
time is obviously not optimal behavior, but that's a separate story.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
---
kernel/resource.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..e633106 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -853,6 +853,15 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
continue;
+ /*
+ * if a resource is "BUSY", it's not a hardware resource
+ * but a driver mapping of such a resource; we don't want
+ * to warn for those; some drivers legitimately map only
+ * partial hardware resources. (example: vesafb)
+ */
+ if (p->flags & IORESOURCE_BUSY)
+ continue;
+
printk(KERN_WARNING "resource map sanity check conflict: "
"0x%llx 0x%llx 0x%llx 0x%llx %s\n",
(unsigned long long)addr,
--
1.6.0.4
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-13 17:15 ` Arjan van de Ven
@ 2008-12-16 22:34 ` Ingo Molnar
0 siblings, 0 replies; 40+ messages in thread
From: Ingo Molnar @ 2008-12-16 22:34 UTC (permalink / raw)
To: Arjan van de Ven
Cc: Linus Torvalds, Pekka Enberg, Frans Pop, Eric Anholt, nix.or.die,
linux-kernel, rjw, Yinghai Lu
* Arjan van de Ven <arjan@infradead.org> wrote:
> On Fri, 12 Dec 2008 08:11:35 -0800 (PST)
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> >
> >
> > On Fri, 12 Dec 2008, Arjan van de Ven wrote:
> > >
> > > another thing we could do is try to only warn if you cross bar
> > > boundaries but not if you cross other user-of-the-resource
> > > boundaries.
> >
> > Hmm. We could use the res->flags for this. But I'm not sure non-PCI
> > resources fill those in correctly.
> >
> > A pure "busy" allocation (ie a driver marker) would generally have
> > just the IORESOURCE_BUSY bit set, while a real PCI hardware resource
> > will have other bits set (ie the IORESOURCE_IO/MEM bits) and not be
> > marked BUSY.
> >
> > Maybe just ignoring resources with BUSY set, as they are driver
> > markers rather than actual HW resources.
>
> something like this: ?
okay, i've applied it in the form below, to tip/core/resources. This in
combination with the toning down of the messages should do the trick i
think.
btw., here's a bug that got caught by the sanity checks:
| commit d522af581c6abd0e064278345ca638b0553a93fa
| Author: Suresh Siddha <suresh.b.siddha@intel.com>
| Date: Mon Oct 20 17:57:02 2008 -0300
|
| V4L/DVB (9356): [PATCH] saa7134: fix resource map sanity check conflict
|
| Impact: driver could possibly stomp on resources outside of its scope
so it's not just nuisance.
> Note: having two drivers talk to the same hardware at the same
> time is obviously not optimal behavior, but that's a separate story.
it will be much more likely to be caught via other misbehavior i guess.
Ingo
------------------>
>From 3ac52669c7a24b93663acfcab606d1065ed1accd Mon Sep 17 00:00:00 2001
From: Arjan van de Ven <arjan@linux.intel.com>
Date: Sat, 13 Dec 2008 09:15:27 -0800
Subject: [PATCH] resources: skip sanity check of busy resources
Impact: reduce false positives in iomem_map_sanity_check()
Some drivers (vesafb) only map/reserve a portion of a resource.
If then some other driver comes in and maps the whole resource,
the current code WARN_ON's. This is not the intent of the checks
in iomem_map_sanity_check(); rather these checks want to
warn when crossing *hardware* resources only.
This patch skips BUSY resources as suggested by Linus.
Note: having two drivers talk to the same hardware at the same
time is obviously not optimal behavior, but that's a separate story.
Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
Signed-off-by: Ingo Molnar <mingo@elte.hu>
---
kernel/resource.c | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/kernel/resource.c b/kernel/resource.c
index 4337063..e633106 100644
--- a/kernel/resource.c
+++ b/kernel/resource.c
@@ -853,6 +853,15 @@ int iomem_map_sanity_check(resource_size_t addr, unsigned long size)
if (PFN_DOWN(p->start) <= PFN_DOWN(addr) &&
PFN_DOWN(p->end) >= PFN_DOWN(addr + size - 1))
continue;
+ /*
+ * if a resource is "BUSY", it's not a hardware resource
+ * but a driver mapping of such a resource; we don't want
+ * to warn for those; some drivers legitimately map only
+ * partial hardware resources. (example: vesafb)
+ */
+ if (p->flags & IORESOURCE_BUSY)
+ continue;
+
printk(KERN_WARNING "resource map sanity check conflict: "
"0x%llx 0x%llx 0x%llx 0x%llx %s\n",
(unsigned long long)addr,
^ permalink raw reply related [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
2008-12-11 2:37 ` Gabriel C
@ 2008-12-11 5:09 ` Arjan van de Ven
2008-12-11 7:57 ` Nick Piggin
` (10 subsequent siblings)
12 siblings, 0 replies; 40+ messages in thread
From: Arjan van de Ven @ 2008-12-11 5:09 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Wed, 10 Dec 2008 17:04:39 -0800 (PST)
Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs
> bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but
> most of that is all about fixes to the new i916 "GEM" code that is
> only used by development X servers, and is a new feature, so it
> shouldn't be able to cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody
> really wants the merge window to be around the holidays. So the
> question is really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after
> xmas
>
> I like this, because alledgely people are debugging things, and
> we'd get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending
> the merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
>
if you go for option (b) I would suggest doing an -rc in the middle, or
at least some snapshot release, to act as anchor point for the second
wave... maybe even a day or two of quiet around that to give people
time to regroup.
--
Arjan van de Ven Intel Open Source Technology Centre
For development, discussion and tips for power savings,
visit http://www.lesswatts.org
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
2008-12-11 2:37 ` Gabriel C
2008-12-11 5:09 ` Arjan van de Ven
@ 2008-12-11 7:57 ` Nick Piggin
2008-12-11 8:07 ` Andrew Morton
2008-12-11 8:06 ` Willy Tarreau
` (9 subsequent siblings)
12 siblings, 1 reply; 40+ messages in thread
From: Nick Piggin @ 2008-12-11 7:57 UTC (permalink / raw)
To: Linus Torvalds, Morton, Andrew; +Cc: Linux Kernel Mailing List
On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
I still have one fix for a reported regression (softlink code doesn't
honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
ago, but it didn't get anywhere.
I thought it would be good to have in 2.6.28, but it's been present in
a couple of releases now, so maybe Andrew didn't think it worth the
trouble?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 7:57 ` Nick Piggin
@ 2008-12-11 8:07 ` Andrew Morton
2008-12-11 8:45 ` Nick Piggin
0 siblings, 1 reply; 40+ messages in thread
From: Andrew Morton @ 2008-12-11 8:07 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > Nothing overly exciting here. Lots of small things, mostly in drivers
> > (with some defconfig updates for m68k and mips making the diffs bigger).
> >
> > There's some uncomfortably big changes to the intel DRI code, but most of
> > that is all about fixes to the new i916 "GEM" code that is only used by
> > development X servers, and is a new feature, so it shouldn't be able to
> > cause regressions.
> >
> > Perhaps more interesting is simply the release scheduling issue. I'm
> > getting slowly ready to do a real 2.6.28, but I don't think anybody really
> > wants the merge window to be around the holidays. So the question is
> > really whether to
> >
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
>
> I still have one fix for a reported regression (softlink code doesn't
> honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> ago, but it didn't get anywhere.
I don't have a clue what you're talking about.
<greps the tree>
./fs/affs/inode.c: case ST_SOFTLINK:
./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry, ST_SOFTLINK);
./include/linux/amigaffs.h:#define ST_SOFTLINK 3
really?
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 8:07 ` Andrew Morton
@ 2008-12-11 8:45 ` Nick Piggin
2008-12-12 3:02 ` Andrew Morton
0 siblings, 1 reply; 40+ messages in thread
From: Nick Piggin @ 2008-12-11 8:45 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Thursday 11 December 2008 19:07, Andrew Morton wrote:
> On Thu, 11 Dec 2008 18:57:36 +1100 Nick Piggin <nickpiggin@yahoo.com.au>
wrote:
> > On Thursday 11 December 2008 12:04, Linus Torvalds wrote:
> > > Nothing overly exciting here. Lots of small things, mostly in drivers
> > > (with some defconfig updates for m68k and mips making the diffs
> > > bigger).
> > >
> > > There's some uncomfortably big changes to the intel DRI code, but most
> > > of that is all about fixes to the new i916 "GEM" code that is only used
> > > by development X servers, and is a new feature, so it shouldn't be able
> > > to cause regressions.
> > >
> > > Perhaps more interesting is simply the release scheduling issue. I'm
> > > getting slowly ready to do a real 2.6.28, but I don't think anybody
> > > really wants the merge window to be around the holidays. So the
> > > question is really whether to
> > >
> > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after
> > > xmas
> > >
> > > I like this, because alledgely people are debugging things, and
> > > we'd get a more stable 2.6.28.
> >
> > I still have one fix for a reported regression (softlink code doesn't
> > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > ago, but it didn't get anywhere.
>
> I don't have a clue what you're talking about.
>
> <greps the tree>
>
> ./fs/affs/inode.c: case ST_SOFTLINK:
> ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
>
> really?
Oh, I thought I cc'ed you...
http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 8:45 ` Nick Piggin
@ 2008-12-12 3:02 ` Andrew Morton
2008-12-12 3:07 ` Nick Piggin
0 siblings, 1 reply; 40+ messages in thread
From: Andrew Morton @ 2008-12-12 3:02 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> > > I still have one fix for a reported regression (softlink code doesn't
> > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > ago, but it didn't get anywhere.
> >
> > I don't have a clue what you're talking about.
> >
> > <greps the tree>
> >
> > ./fs/affs/inode.c: case ST_SOFTLINK:
> > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> >
> > really?
>
> Oh, I thought I cc'ed you...
>
> http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
yes, but that stuff went round and round in circles and ended up all in
the air.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 3:02 ` Andrew Morton
@ 2008-12-12 3:07 ` Nick Piggin
2008-12-12 3:39 ` Andrew Morton
0 siblings, 1 reply; 40+ messages in thread
From: Nick Piggin @ 2008-12-12 3:07 UTC (permalink / raw)
To: Andrew Morton; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Friday 12 December 2008 14:02, Andrew Morton wrote:
> On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au>
wrote:
> > > > I still have one fix for a reported regression (softlink code doesn't
> > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > ago, but it didn't get anywhere.
> > >
> > > I don't have a clue what you're talking about.
> > >
> > > <greps the tree>
> > >
> > > ./fs/affs/inode.c: case ST_SOFTLINK:
> > > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> > >
> > > really?
> >
> > Oh, I thought I cc'ed you...
> >
> > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
>
> yes, but that stuff went round and round in circles and ended up all in
> the air.
Hmm, OK. I think we ended up agreeing after some review and things
fixed since my original posting.
But it was an honest question -- is this too late to go in 2.6.28,
given that it has been present in earlier releases too? Maybe if the
release date is pushed to after Christmas, then there is enough time.
Otherwise, perhaps it should go upstream afterwards, then filter into
-stable?
Anyway, I'll repost them, in case you'd care to put them in -mm in
the meantime.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 3:07 ` Nick Piggin
@ 2008-12-12 3:39 ` Andrew Morton
0 siblings, 0 replies; 40+ messages in thread
From: Andrew Morton @ 2008-12-12 3:39 UTC (permalink / raw)
To: Nick Piggin; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Fri, 12 Dec 2008 13:07:02 +1000 Nick Piggin <nickpiggin@yahoo.com.au> wrote:
> On Friday 12 December 2008 14:02, Andrew Morton wrote:
> > On Thu, 11 Dec 2008 19:45:53 +1100 Nick Piggin <nickpiggin@yahoo.com.au>
> wrote:
> > > > > I still have one fix for a reported regression (softlink code doesn't
> > > > > honour GFP_NOFS, caused by a patch of mine). Posted a couple of weeks
> > > > > ago, but it didn't get anywhere.
> > > >
> > > > I don't have a clue what you're talking about.
> > > >
> > > > <greps the tree>
> > > >
> > > > ./fs/affs/inode.c: case ST_SOFTLINK:
> > > > ./fs/affs/namei.c: error = affs_add_entry(dir, inode, dentry,
> > > > ST_SOFTLINK); ./include/linux/amigaffs.h:#define ST_SOFTLINK 3
> > > >
> > > > really?
> > >
> > > Oh, I thought I cc'ed you...
> > >
> > > http://marc.info/?l=linux-fsdevel&m=122777850302085&w=2
> > > http://marc.info/?l=linux-fsdevel&m=122777852502093&w=2
> >
> > yes, but that stuff went round and round in circles and ended up all in
> > the air.
>
> Hmm, OK. I think we ended up agreeing after some review and things
> fixed since my original posting.
>
> But it was an honest question -- is this too late to go in 2.6.28,
> given that it has been present in earlier releases too? Maybe if the
> release date is pushed to after Christmas, then there is enough time.
> Otherwise, perhaps it should go upstream afterwards, then filter into
> -stable?
Well we could do either.
But it's not completely obvious what the actual bug is. Deadlock?
Suboptimal memory allocation mode? Arbitrary stack windup? Other?
> Anyway, I'll repost them, in case you'd care to put them in -mm in
> the meantime.
Sure..
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (2 preceding siblings ...)
2008-12-11 7:57 ` Nick Piggin
@ 2008-12-11 8:06 ` Willy Tarreau
2008-12-11 8:40 ` Joerg Roedel
` (8 subsequent siblings)
12 siblings, 0 replies; 40+ messages in thread
From: Willy Tarreau @ 2008-12-11 8:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
>
> or
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.
>
> So I haven't quite decided on that thing yet, but I'm open to suggestions.
I'd suggest :
(c) release before holidays, and not extend merge window. That way,
users can test it during holidays, and we possibly merge less
things this time, leading to less changes and more focus on fixes
in 2.6.29, which I admit may imply more crap in 2.6.30. But that
could give a high quality 2.6.29 by spring.
Just my 2 cents,
Willy
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (3 preceding siblings ...)
2008-12-11 8:06 ` Willy Tarreau
@ 2008-12-11 8:40 ` Joerg Roedel
2008-12-11 22:57 ` Theodore Tso
2008-12-11 9:26 ` Jean Delvare
` (7 subsequent siblings)
12 siblings, 1 reply; 40+ messages in thread
From: Joerg Roedel @ 2008-12-11 8:40 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
I'll vote for a. An open merge window over the holidays possible results
in needless stresses for the developers at a time which some of them
want to use otherwise. Or if any merge introduces bad bugs and the
developers that can fix it are on xmax vacation we may end up with an
unusable upstream tree for a week or so. Same with merge conflicts.
So, I'd suggest to wait until everybody is back to work until opening
the merge window.
Joerg
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 8:40 ` Joerg Roedel
@ 2008-12-11 22:57 ` Theodore Tso
2008-12-11 23:12 ` Mike Travis
0 siblings, 1 reply; 40+ messages in thread
From: Theodore Tso @ 2008-12-11 22:57 UTC (permalink / raw)
To: Joerg Roedel; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> >
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
> >
>
> I'll vote for a. An open merge window over the holidays possible results
> in needless stresses for the developers at a time which some of them
> want to use otherwise. Or if any merge introduces bad bugs and the
> developers that can fix it are on xmax vacation we may end up with an
> unusable upstream tree for a week or so. Same with merge conflicts.
> So, I'd suggest to wait until everybody is back to work until opening
> the merge window.
I'd vote for (a) as well, and hopefully folks who are really
conscientious can do some integration testing of linux-next and can
report problems there to make the merge window go more smoothly after
the New Year's.
- Ted
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 22:57 ` Theodore Tso
@ 2008-12-11 23:12 ` Mike Travis
0 siblings, 0 replies; 40+ messages in thread
From: Mike Travis @ 2008-12-11 23:12 UTC (permalink / raw)
To: Theodore Tso, Joerg Roedel, Linus Torvalds, Linux Kernel Mailing List
Theodore Tso wrote:
> On Thu, Dec 11, 2008 at 09:40:58AM +0100, Joerg Roedel wrote:
>> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>>> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>>>
>>> I like this, because alledgely people are debugging things, and we'd
>>> get a more stable 2.6.28.
>>>
>> I'll vote for a. An open merge window over the holidays possible results
>> in needless stresses for the developers at a time which some of them
>> want to use otherwise. Or if any merge introduces bad bugs and the
>> developers that can fix it are on xmax vacation we may end up with an
>> unusable upstream tree for a week or so. Same with merge conflicts.
>> So, I'd suggest to wait until everybody is back to work until opening
>> the merge window.
>
> I'd vote for (a) as well, and hopefully folks who are really
> conscientious can do some integration testing of linux-next and can
> report problems there to make the merge window go more smoothly after
> the New Year's.
>
> - Ted
I'll second (or third?) this motion... ;-)
Thanks,
Mike
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (4 preceding siblings ...)
2008-12-11 8:40 ` Joerg Roedel
@ 2008-12-11 9:26 ` Jean Delvare
2008-12-11 10:38 ` Frederik Deweerdt
` (6 subsequent siblings)
12 siblings, 0 replies; 40+ messages in thread
From: Jean Delvare @ 2008-12-11 9:26 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
Hi Linus,
On Wed, 10 Dec 2008 17:04:39 -0800 (PST), Linus Torvalds wrote:
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
I vote for option (a).
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
>
> or
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.
>
> So I haven't quite decided on that thing yet, but I'm open to suggestions.
--
Jean Delvare
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (5 preceding siblings ...)
2008-12-11 9:26 ` Jean Delvare
@ 2008-12-11 10:38 ` Frederik Deweerdt
2008-12-11 16:59 ` Andrew Morton
2008-12-11 13:00 ` Sam Ravnborg
` (5 subsequent siblings)
12 siblings, 1 reply; 40+ messages in thread
From: Frederik Deweerdt @ 2008-12-11 10:38 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List, akpm
On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
>
> Nothing overly exciting here.
-rc8 could be made even less exciting, it seems, by adding this crutially
boring fix:
http://lkml.org/lkml/2008/12/1/345
It sits in -mm and fixes a regression in mainline (Bugzilla #12047).
Regards,
Frederik
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 10:38 ` Frederik Deweerdt
@ 2008-12-11 16:59 ` Andrew Morton
0 siblings, 0 replies; 40+ messages in thread
From: Andrew Morton @ 2008-12-11 16:59 UTC (permalink / raw)
To: Frederik Deweerdt
Cc: Linus Torvalds, Linux Kernel Mailing List, Len Brown, linux-acpi
On Thu, 11 Dec 2008 11:38:00 +0100 Frederik Deweerdt <frederik.deweerdt@xprog.eu> wrote:
> On Wed, Dec 10, 2008 at 05:04:39PM -0800, Linus Torvalds wrote:
> >
> > Nothing overly exciting here.
>
> -rc8 could be made even less exciting, it seems, by adding this crutially
> boring fix:
> http://lkml.org/lkml/2008/12/1/345
>
> It sits in -mm and fixes a regression in mainline (Bugzilla #12047).
>
I actually have two acpi patches which look like 2.6.28 material. I shall
resend them to Len.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (6 preceding siblings ...)
2008-12-11 10:38 ` Frederik Deweerdt
@ 2008-12-11 13:00 ` Sam Ravnborg
2008-12-11 13:23 ` Paolo Ciarrocchi
2008-12-11 13:44 ` Alexey Zaytsev
` (4 subsequent siblings)
12 siblings, 1 reply; 40+ messages in thread
From: Sam Ravnborg @ 2008-12-11 13:00 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.
Release before xmas but postpone start of merge window until 5th of January.
So we get the wider testing during xmas and we avoid to stress during xmas holiday.
Or maybe I should go back and drink more glögg..
Sam
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 13:00 ` Sam Ravnborg
@ 2008-12-11 13:23 ` Paolo Ciarrocchi
0 siblings, 0 replies; 40+ messages in thread
From: Paolo Ciarrocchi @ 2008-12-11 13:23 UTC (permalink / raw)
To: Sam Ravnborg; +Cc: Linus Torvalds, Linux Kernel Mailing List
On Thu, Dec 11, 2008 at 2:00 PM, Sam Ravnborg <sam@ravnborg.org> wrote:
>>
>> (c) some other crazy scheme that somebody comes up with in a drug-induced
>> stupor.
>
> Release before xmas but postpone start of merge window until 5th of January.
> So we get the wider testing during xmas and we avoid to stress during xmas holiday.
d) Release before xmas, postpone start of merge window until 7th of January.
Use the period of time between the release and the opening of the
merge window to collect bug fixes and release a stable version.
> Or maybe I should go back and drink more glögg..
Ciao,
--
Paolo
http://paolo.ciarrocchi.googlepages.com/
http://mypage.vodafone.it/
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (7 preceding siblings ...)
2008-12-11 13:00 ` Sam Ravnborg
@ 2008-12-11 13:44 ` Alexey Zaytsev
2008-12-11 13:48 ` Ingo Molnar
` (3 subsequent siblings)
12 siblings, 0 replies; 40+ messages in thread
From: Alexey Zaytsev @ 2008-12-11 13:44 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Thu, Dec 11, 2008 at 04:04, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
>
> (c) some other crazy scheme that somebody comes up with in a drug-induced
> stupor.
Open the .29 merge window in a separate branch before making the 28 release
and merge the late-rc patches there as they come. ;)
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (8 preceding siblings ...)
2008-12-11 13:44 ` Alexey Zaytsev
@ 2008-12-11 13:48 ` Ingo Molnar
2008-12-11 15:20 ` Pavel Machek
` (2 subsequent siblings)
12 siblings, 0 replies; 40+ messages in thread
From: Ingo Molnar @ 2008-12-11 13:48 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
* Linus Torvalds <torvalds@linux-foundation.org> wrote:
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs
> bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most
> of that is all about fixes to the new i916 "GEM" code that is only used
> by development X servers, and is a new feature, so it shouldn't be able
> to cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody
> really wants the merge window to be around the holidays. So the
> question is really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
i'd really vote for a) because there's nothing worse to overlap xmas with
than with merge window stress. A couple of key developers wont be around
either in that timeframe (whose stuff is pending) - making early reaction
to breakage in the merge window rather laggy and awkward.
A Dec 31 release would be perfect [ 84 days will have passed by then
since v2.6.27 which was released on Oct 9 ] and we would start 2009
exactly on point on the planned 3-months / 90 days schedule.
Here's our release cycle track record, and how much it deviates from the
max-90-days target:
2.6.28: 64 days [today]
on 31th: 84 days -6 days
2.6.27: 88 -2 days
2.6.26: 87 -3 days
2.6.25: 83 -7 days
2.6.24: 107 +17 days
2.6.23: 92 +2 days
2.6.22: 73 -17 days
2.6.21: 80 -10 days
2.6.20: 66 -26 days
2.6.19: 70 -20 days
2.6.18: 94 +4 days
2.6.17: 89 -1 day
2.6.16: 76 -14 days
2.6.15: 67 -23 days
2.6.14: 60 -30 days
2.6.13: 72 -18 days
We lost two and a half weeks with 2.6.24 that was released belatedly on
Jan 24 - we've made up all the ground for that already.
And the killer argument: there's nothing better to mask a nasty Jan 1
hangover with than with some merge window stress ;-)
Ingo
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (9 preceding siblings ...)
2008-12-11 13:48 ` Ingo Molnar
@ 2008-12-11 15:20 ` Pavel Machek
2008-12-11 15:29 ` David Howells
2008-12-11 20:12 ` Rafael J. Wysocki
12 siblings, 0 replies; 40+ messages in thread
From: Pavel Machek @ 2008-12-11 15:20 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Wed 2008-12-10 17:04:39, Linus Torvalds wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
I like (b)... to have some more interesrting holidays :-).
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (10 preceding siblings ...)
2008-12-11 15:20 ` Pavel Machek
@ 2008-12-11 15:29 ` David Howells
2008-12-12 3:19 ` David Miller
2008-12-11 20:12 ` Rafael J. Wysocki
12 siblings, 1 reply; 40+ messages in thread
From: David Howells @ 2008-12-11 15:29 UTC (permalink / raw)
To: Linus Torvalds; +Cc: dhowells, Linux Kernel Mailing List
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
Which would perhaps mean that the merge window is open during LCA, which will
be inconvenient for some people. On the other hand, it might put the culprits
where you can lay your hands on them.
David
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 15:29 ` David Howells
@ 2008-12-12 3:19 ` David Miller
2008-12-12 5:40 ` Linus Torvalds
2008-12-12 15:48 ` Alan Cox
0 siblings, 2 replies; 40+ messages in thread
From: David Miller @ 2008-12-12 3:19 UTC (permalink / raw)
To: dhowells; +Cc: torvalds, linux-kernel
From: David Howells <dhowells@redhat.com>
Date: Thu, 11 Dec 2008 15:29:06 +0000
> Linus Torvalds <torvalds@linux-foundation.org> wrote:
>
> > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> >
> > I like this, because alledgely people are debugging things, and we'd
> > get a more stable 2.6.28.
>
> Which would perhaps mean that the merge window is open during LCA, which will
> be inconvenient for some people. On the other hand, it might put the culprits
> where you can lay your hands on them.
That happened in Melbourne and it wasn't pleasant. Instead
of enjoying talks at the conference some of us were stressing
out on our laptops dealing with our merges instead.
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 3:19 ` David Miller
@ 2008-12-12 5:40 ` Linus Torvalds
2008-12-12 7:54 ` Joerg Roedel
2008-12-12 15:48 ` Alan Cox
1 sibling, 1 reply; 40+ messages in thread
From: Linus Torvalds @ 2008-12-12 5:40 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, linux-kernel
On Thu, 11 Dec 2008, David Miller wrote:
> From: David Howells <dhowells@redhat.com>
> Date: Thu, 11 Dec 2008 15:29:06 +0000
>
> > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> >
> > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > >
> > > I like this, because alledgely people are debugging things, and we'd
> > > get a more stable 2.6.28.
> >
> > Which would perhaps mean that the merge window is open during LCA, which will
> > be inconvenient for some people. On the other hand, it might put the culprits
> > where you can lay your hands on them.
>
> That happened in Melbourne and it wasn't pleasant. Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.
Yes. I definitely want to close the 29 merge window before LCA. In fact, I
want to close it far enough before that we can fix up any worst issues.
Which does argue for opening it up during the holidays, I guess.
Linus
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 5:40 ` Linus Torvalds
@ 2008-12-12 7:54 ` Joerg Roedel
0 siblings, 0 replies; 40+ messages in thread
From: Joerg Roedel @ 2008-12-12 7:54 UTC (permalink / raw)
To: Linus Torvalds; +Cc: David Miller, dhowells, linux-kernel
On Thu, Dec 11, 2008 at 09:40:21PM -0800, Linus Torvalds wrote:
>
>
> On Thu, 11 Dec 2008, David Miller wrote:
>
> > From: David Howells <dhowells@redhat.com>
> > Date: Thu, 11 Dec 2008 15:29:06 +0000
> >
> > > Linus Torvalds <torvalds@linux-foundation.org> wrote:
> > >
> > > > (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
> > > >
> > > > I like this, because alledgely people are debugging things, and we'd
> > > > get a more stable 2.6.28.
> > >
> > > Which would perhaps mean that the merge window is open during LCA, which will
> > > be inconvenient for some people. On the other hand, it might put the culprits
> > > where you can lay your hands on them.
> >
> > That happened in Melbourne and it wasn't pleasant. Instead
> > of enjoying talks at the conference some of us were stressing
> > out on our laptops dealing with our merges instead.
>
> Yes. I definitely want to close the 29 merge window before LCA. In fact, I
> want to close it far enough before that we can fix up any worst issues.
>
> Which does argue for opening it up during the holidays, I guess.
You can do a release around 29th/30th December. This gives the people
who are on vacation until the new year still a week for merging stuff
and the merge window closes 4-5 days before people are leaving for
LCA.
Joerg
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-12 3:19 ` David Miller
2008-12-12 5:40 ` Linus Torvalds
@ 2008-12-12 15:48 ` Alan Cox
1 sibling, 0 replies; 40+ messages in thread
From: Alan Cox @ 2008-12-12 15:48 UTC (permalink / raw)
To: David Miller; +Cc: dhowells, torvalds, linux-kernel
> That happened in Melbourne and it wasn't pleasant. Instead
> of enjoying talks at the conference some of us were stressing
> out on our laptops dealing with our merges instead.
That argues for doing the merges before LCA so only the fallout is after
(when people are easily located).
But is there *ever* a good time ?
Alan
^ permalink raw reply [flat|nested] 40+ messages in thread
* Re: Linux 2.6.28-rc8
2008-12-11 1:04 Linux 2.6.28-rc8 Linus Torvalds
` (11 preceding siblings ...)
2008-12-11 15:29 ` David Howells
@ 2008-12-11 20:12 ` Rafael J. Wysocki
12 siblings, 0 replies; 40+ messages in thread
From: Rafael J. Wysocki @ 2008-12-11 20:12 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Linux Kernel Mailing List
On Thursday, 11 of December 2008, Linus Torvalds wrote:
>
> Nothing overly exciting here. Lots of small things, mostly in drivers
> (with some defconfig updates for m68k and mips making the diffs bigger).
>
> There's some uncomfortably big changes to the intel DRI code, but most of
> that is all about fixes to the new i916 "GEM" code that is only used by
> development X servers, and is a new feature, so it shouldn't be able to
> cause regressions.
>
> Perhaps more interesting is simply the release scheduling issue. I'm
> getting slowly ready to do a real 2.6.28, but I don't think anybody really
> wants the merge window to be around the holidays. So the question is
> really whether to
>
> (a) just make the -rc's go on a few more weeks, and do 2.6.28 after xmas
>
> I like this, because alledgely people are debugging things, and we'd
> get a more stable 2.6.28.
>
> or
>
> (b) release in a week or two, but just allow for possibly extending the
> merge window due to people being drunk on eggnog..
>
> I like this because let's face it, we get more and better bug
> information after releases, and everything _should_ be ready for
> merging *before* the merge window anyway.
FWIW, I vote for this one.
Thanks,
Rafael
^ permalink raw reply [flat|nested] 40+ messages in thread