Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
> > I don't want to say the values aren't useful. I simply think there is > > a high noiselevel. > > The noise is reflected in the standard deviation he has on those rows. > The average +- stdev of one overlaps the average +- stdev of the > other, For the fairness test on cfs13 this simply is wrong. And for the test to be stable would require that avg of one is within avg+-stddev of the other (simple overlap does not suffice). Best, Michael -- Technosis GmbH, Geschäftsführer: Michael Gerdau, Tobias Dittmar Sitz Hamburg; HRB 89145 Amtsgericht Hamburg Vote against SPAM - see http://www.politik-digital.de/spam/ Michael Gerdau email: [EMAIL PROTECTED] GPG-keys available on request or at public keyserver pgpOZ4X7SfweE.pgp Description: PGP signature
Re: [SMP BUG] [clockevents: i386 drivers patch] introduces irqbalance-does-not-work-properly problem
On Sun, 2007-05-20 at 11:14 +0900, Komuro wrote: > Hi, > > > [clockevents: i386 drivers patch] introduces > irqbalance-does-not-work-properly problem. it disables irq balancing for IRQ0, but this does not affect any other interrupts. It is almost irrelevant as the PIT/HPET timer interrupt (irq0) is disabled anyway and the local apic timer is used. > >CPU0 CPU1 > > 0: 85 0 IO-APIC-edge timer There is no interrupt happening after bootup, so balancing is not a problem here. > Mr. Thomas Gleixner, > any idea to fix this problem? Which problem ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [2.6.22-rc1-mm1] vaio laptop (SZ72B) immediately resumes after STR
On Sat, May 19, 2007 at 11:47:23PM -0700, Andrew Morton wrote: > On Sun, 20 May 2007 15:14:08 +0900 Mattia Dongili <[EMAIL PROTECTED]> wrote: > > > On Sat, May 19, 2007 at 12:04:13AM -0700, Andrew Morton wrote: > > > On Sat, 19 May 2007 15:48:29 +0900 Mattia Dongili <[EMAIL PROTECTED]> > > > wrote: ... > > > > ok, git-acpi.patch is not the bad boy :) > > > > but very very close: > > acpi-driver-model-flags-and-platform_enable_wake.patch > > > > Thanks very much for working that out - it saves lots of people heaps of > pain. I dropped the patch. oh dear... and now, with the full series applied, I hit the immediately-resuspend-after-resume someone already reported... aargh -- mattia :wq! - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 1/9] readahead: introduce PG_readahead
On Sun, 20 May 2007, Fengguang Wu wrote: > The reuse code would look like the attached one. > It still needs more testing, and would fail if Christoph reuses > PG_reclaim in higher order pagecache in the future. Do not worry about that. All higher order pagecache patchsets remove that sharing because we will then need these pages on the LRU and thus PG_reclaim cannot be shared anymore. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
On Sun, 20 May 2007, Srihari Vijayaraghavan wrote: > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80 > RIP [...] slab_sysfs_init+0x49/0x98 > RSP [...] > kernel panic - not syncing: Attempted to kill init! sysfs? If you build without CONFIG_SLUB_DEBUG then SLUB will not use sysfs. You can switch that off in the embedded section. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] x86-64 highres/dyntick support 2.6.22-rc2-v1
I'm pleased to announce an updated version of the x86_64 highres/dyntick support patches against 2.6.22-rc2: http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc2-x86_64-highres-v1.patch Broken out version is available here: http://www.tglx.de/projects/hrtimers/2.6.22-rc1/linux-2.6.22-rc2-x86_64-highres-v1.patches.tar.bz2 Changes since the last version: - update to -rc2 - maxcpus=1 boot hang fix Comments, bug reports, patches are welcome as usual Thanks, tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Sched - graphic smoothness under load - cfs-v13 sd-0.48
On 5/19/07, Michael Gerdau <[EMAIL PROTECTED]> wrote: > > I don't want to say the values aren't useful. I simply think there is > > a high noiselevel. > > The noise is reflected in the standard deviation he has on those rows. > The average +- stdev of one overlaps the average +- stdev of the > other, For the fairness test on cfs13 this simply is wrong. Ah, you are correct. I was looking at the glxgears test and mostly ignoring the fairness one as I'm not sure what the test is doing. As the deviations seem erratic, the fairness test looks like it needs more passes to converge, but that's just a guess. I honestly don't know what's going on with that one. And for the test to be stable would require that avg of one is within avg+-stddev of the other (simple overlap does not suffice). Er, I think you took a different statistics class than I did :-). In general, the 'true' value we're trying to find/measure has a certain percentage chance of lying within the average +- n*deviation, with the percentage going up as n increases, right? (68% for n=1, 95% for n=2, etc.) Both distributions have that property, and so to consider one of the averages as the 'true' value and the other a mere distribution that has to overlap it is... somewhat inaccurate. In general, if they both overlap within one standard deviation of each other, you can say that the data has pretty good agreement with itself. Which for the glxgears case, it does. The fairness test isn't so cut and dried, but it's not horrifically out of whack, either. So I'll reserve judgment on that one :-). - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] increase struct page size?!
On Sat, 19 May 2007 11:15:01 -0700 William Lee Irwin III <[EMAIL PROTECTED]> wrote: >> Much the same holds for the atomic_t's; 32 + PAGE_SHIFT is >> 44 bits or more, about as much as is possible, and one reference per >> page per page is not even feasible. Full-length atomic_t's are just >> not necessary. On Sat, May 19, 2007 at 03:09:34PM -0700, Andrew Morton wrote: > You can overflow a page's refcount by mapping it 4G times. That requires > 32GB of pagetable memory. It's quite feasible with remap_file_pages(). Oh dear, worst-case app behavior. I'm just wrong. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
--- Christoph Lameter <[EMAIL PROTECTED]> wrote: > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote: > > > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80 > > RIP [...] slab_sysfs_init+0x49/0x98 > > RSP [...] > > kernel panic - not syncing: Attempted to kill init! > > sysfs? If you build without CONFIG_SLUB_DEBUG then SLUB will not use > sysfs. You can switch that off in the embedded section. Fair enough. Would you the section name it appears in 'menuconfig'? I looked under 'Kernel hacking' section (where the slab debugging appears if slab is turned on as 'Debug slab memory allocation') & in the 'General setup' section also. I unable to figure out how to disable slub debugging :-(. Pls give me a pointer to it. Thanks (Won't it be right to disable it by default when a user selects slub such that a user needs to manually turn on the slub debugging in menuconfig?) ___ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Extract common MODULE_INFO content into new moduleinfo.h.
Extract the common MODULE_INFO content found in both module.h and
moduleparam.h into a new header file moduleinfo.h, which at least
makes it possible for source files to someday stop including the
content from moduleparam.h when they don't need it.
Signed-off-by: Robert P. J. Day <[EMAIL PROTECTED]>
---
compile-tested with "make allmodconfig" on x86.
include/linux/module.h | 12 +++-
include/linux/moduleinfo.h | 18 ++
include/linux/moduleparam.h | 16 +---
3 files changed, 26 insertions(+), 20 deletions(-)
diff --git a/include/linux/module.h b/include/linux/module.h
index e6e0f86..d9a9a13 100644
--- a/include/linux/module.h
+++ b/include/linux/module.h
@@ -15,7 +15,8 @@
#include
#include
#include
-#include
+#include /* Ideally, this shouldn't be necessary. */
+#include
#include
#include
@@ -88,9 +89,6 @@ extern struct module __this_module;
#define THIS_MODULE ((struct module *)0)
#endif
-/* Generic info of form tag = "info" */
-#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
-
/* For userspace: you can also call me... */
#define MODULE_ALIAS(_alias) MODULE_INFO(alias, _alias)
@@ -130,11 +128,6 @@ extern struct module __this_module;
/* What your module does. */
#define MODULE_DESCRIPTION(_description) MODULE_INFO(description, _description)
-/* One for each parameter, describing how to use it. Some files do
- multiple of these per line, so can't just use MODULE_INFO. */
-#define MODULE_PARM_DESC(_parm, desc) \
- __MODULE_INFO(parm, _parm, #_parm ":" desc)
-
#define MODULE_DEVICE_TABLE(type,name) \
MODULE_GENERIC_TABLE(type##_device,name)
@@ -576,6 +569,7 @@ struct device_driver;
struct module;
extern struct kset module_subsys;
+struct kernel_param;
int mod_sysfs_init(struct module *mod);
int mod_sysfs_setup(struct module *mod,
diff --git a/include/linux/moduleinfo.h b/include/linux/moduleinfo.h
new file mode 100644
index 000..cee86a9
--- /dev/null
+++ b/include/linux/moduleinfo.h
@@ -0,0 +1,18 @@
+#ifndef _LINUX_MODULEINFO_H
+#define _LINUX_MODULEINFO_H
+
+#ifdef MODULE
+#include
+#define ___module_cat(a,b) __mod_ ## a ## b
+#define __module_cat(a,b) ___module_cat(a,b)
+#define __MODULE_INFO(tag, name, info) \
+static const char __module_cat(name,__LINE__)[]\
+ __attribute_used__ \
+ __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
+#else /* !MODULE */
+#define __MODULE_INFO(tag, name, info)
+#endif
+
+#define MODULE_INFO(tag, info) __MODULE_INFO(tag, tag, info)
+
+#endif // _LINUX_MODULEINFO_H
diff --git a/include/linux/moduleparam.h b/include/linux/moduleparam.h
index c83588c..650328d 100644
--- a/include/linux/moduleparam.h
+++ b/include/linux/moduleparam.h
@@ -4,6 +4,7 @@
#include
#include
#include
+#include
/* You can override this manually, but generally this should match the
module name. */
@@ -13,19 +14,12 @@
#define MODULE_PARAM_PREFIX KBUILD_MODNAME "."
#endif
-#ifdef MODULE
-#define ___module_cat(a,b) __mod_ ## a ## b
-#define __module_cat(a,b) ___module_cat(a,b)
-#define __MODULE_INFO(tag, name, info) \
-static const char __module_cat(name,__LINE__)[]
\
- __attribute_used__ \
- __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
-#else /* !MODULE */
-#define __MODULE_INFO(tag, name, info)
-#endif
-#define __MODULE_PARM_TYPE(name, _type)
\
+#define __MODULE_PARM_TYPE(name, _type)
\
__MODULE_INFO(parmtype, name##type, #name ":" _type)
+#define MODULE_PARM_DESC(_parm, desc) \
+ __MODULE_INFO(parm, _parm, #_parm ":" desc)
+
struct kernel_param;
/* Returns 0, or -errno. arg is in kp->arg. */
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix duplicated entry in Documentation/HOWTO
Commit 3f271008 introduced this section to Linus tree, but a later commit 722385f7 accepted almost the identical patch via Greg's tree, both from the same author. This kills the duplicated one. Signed-off-by: Junio C Hamano <[EMAIL PROTECTED]> --- Documentation/HOWTO | 20 1 files changed, 0 insertions(+), 20 deletions(-) diff --git a/Documentation/HOWTO b/Documentation/HOWTO index 48123db..ced9207 100644 --- a/Documentation/HOWTO +++ b/Documentation/HOWTO @@ -396,26 +396,6 @@ bugme-janitor mailing list (every change in the bugzilla is mailed here) -Managing bug reports - - -One of the best ways to put into practice your hacking skills is by fixing -bugs reported by other people. Not only you will help to make the kernel -more stable, you'll learn to fix real world problems and you will improve -your skills, and other developers will be aware of your presence. Fixing -bugs is one of the best ways to get merits among other developers, because -not many people like wasting time fixing other people's bugs. - -To work in the already reported bug reports, go to http://bugzilla.kernel.org. -If you want to be advised of the future bug reports, you can subscribe to the -bugme-new mailing list (only new bug reports are mailed here) or to the -bugme-janitor mailing list (every change in the bugzilla is mailed here) - - http://lists.osdl.org/mailman/listinfo/bugme-new - http://lists.osdl.org/mailman/listinfo/bugme-janitors - - - Mailing lists - - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via C3/C7: other flags possible ?
Simon Arlott schrieb: On 19/05/07 23:36, Christian Volkmann wrote: Christian Volkmann wrote: Claas asked for the NX flag for the Via C3 (?) processors in another thread. If you read the other thread properly you'd see that the BIOS has an option to enable or disable it... when enabled it shows up. Right, but my bios disables this after each boot-time :( Therefore it would be great if the kernel would not care about the BIOS and enable it anyway. This seems to be a severe bug in the BIOS, but VIA does not deliver a new BIOS since months. :( I can't reboot that box just to test cx8 detection (which is missing). It works here. claas - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Satyam Sharma wrote: > You'll learn about the "default .. if .." Kconfig idiom after you try > this, I have seen these in the rest of the patch which I didn't quote. However you fix it --- don't remove "depends on" or "select". You can interchange them, but not remove them, unless there wasn't a dependency to begin with. Games with default values will break the next time a genius patch submitter comes around with his ideas how people configure kernels. PS: I still believe that the saner approach would be to carry only the dependencies, prompt texts and help texts in Kconfig files, maybe amended by new machine-readable markers regarding the role of an option. The presentation and ways to select and deselect should be entirely left to UIs. -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/ata: Add the SW NCQ support to sata_nv for MCP51/MCP55/MCP61
Hi, Jeff Garzik írta: Alan Cox wrote: That shouldn't be a problem, libata default DMA mask is 32 bits (which isn't overridden with this controller) and so the block layer will bounce any data being read/written above that point with IOMMU or swiotlb. The comment is a bit unnecessarily scary. Adding a BUG_ON for this would be wise. Its trivial to check and a BUG rather than corruption if this assumption ever changes would be far preferable The default DMA mask -everywhere- is 32 bits. A lot of code will break if this assumption ever changes, not just libata. Jeff thanks for clarifying this. I tested the effect of this patch on 2.6.22-rc2 + CFS-v13 with the current CVS version of PostgreSQL 8.3devel. pgbench with 25 clients and some large number of transactions to make the result stable showed substantial increase in throughput. Without NCQ, I got around 446 tps, with NCQ I got around 680 via local TCP connection. Previously, I got this level of performance only over local unix socket and smaller number of simultaneous clients. The disk is Seagate 320GB (ST3320620AS). Again, thanks for this patch. Best regards, Zoltán Böszörményi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 0/5] make slab gfp fair
Ok, full reset.
I care about kernel allocations only. In particular about those that
have PF_MEMALLOC semantics.
The thing I need is that any memory allocated below
ALLOC_MIN|ALLOC_HIGH|ALLOC_HARDER
is only ever used by processes that have ALLOC_NO_WATERMARKS rights;
for the duration of the distress.
What this patch does:
- change the page allocator to try ALLOC_MIN|ALLOC_HIGH|ALLOC_HARDER
if ALLOC_NO_WATERMARKS, before the actual ALLOC_NO_WATERMARKS alloc
- set page->reserve nonzero for each page allocated with
ALLOC_NO_WATERMARKS; which by the previous point implies that all
available zones are below ALLOC_MIN|ALLOC_HIGH|ALLOC_HARDER
- when a page->reserve slab is allocated store it in s->reserve_slab
and do not update the ->cpu_slab[] (this forces subsequent allocs to
retry the allocation).
All ALLOC_NO_WATERMARKS enabled slab allocations are served from
->reserve_slab, up until the point where a !page->reserve slab alloc
succeeds, at which point the ->reserve_slab is pushed into the partial
lists and ->reserve_slab set to NULL.
Since only the allocation of a new slab uses the gfp zone flags, and
other allocations placement hints they have to be uniform over all slab
allocs for a given kmem_cache. Thus the s->reserve_slab/page->reserve
status is kmem_cache wide.
Any holes left?
---
Index: linux-2.6-git/mm/internal.h
===
--- linux-2.6-git.orig/mm/internal.h
+++ linux-2.6-git/mm/internal.h
@@ -12,6 +12,7 @@
#define __MM_INTERNAL_H
#include
+#include
static inline void set_page_count(struct page *page, int v)
{
@@ -37,4 +38,50 @@ static inline void __put_page(struct pag
extern void fastcall __init __free_pages_bootmem(struct page *page,
unsigned int order);
+#define ALLOC_HARDER 0x01 /* try to alloc harder */
+#define ALLOC_HIGH 0x02 /* __GFP_HIGH set */
+#define ALLOC_WMARK_MIN0x04 /* use pages_min watermark */
+#define ALLOC_WMARK_LOW0x08 /* use pages_low watermark */
+#define ALLOC_WMARK_HIGH 0x10 /* use pages_high watermark */
+#define ALLOC_NO_WATERMARKS0x20 /* don't check watermarks at all */
+#define ALLOC_CPUSET 0x40 /* check for correct cpuset */
+
+/*
+ * get the deepest reaching allocation flags for the given gfp_mask
+ */
+static int inline gfp_to_alloc_flags(gfp_t gfp_mask)
+{
+ struct task_struct *p = current;
+ int alloc_flags = ALLOC_WMARK_MIN | ALLOC_CPUSET;
+ const gfp_t wait = gfp_mask & __GFP_WAIT;
+
+ /*
+* The caller may dip into page reserves a bit more if the caller
+* cannot run direct reclaim, or if the caller has realtime scheduling
+* policy or is asking for __GFP_HIGH memory. GFP_ATOMIC requests will
+* set both ALLOC_HARDER (!wait) and ALLOC_HIGH (__GFP_HIGH).
+*/
+ if (gfp_mask & __GFP_HIGH)
+ alloc_flags |= ALLOC_HIGH;
+
+ if (!wait) {
+ alloc_flags |= ALLOC_HARDER;
+ /*
+* Ignore cpuset if GFP_ATOMIC (!wait) rather than fail alloc.
+* See also cpuset_zone_allowed() comment in kernel/cpuset.c.
+*/
+ alloc_flags &= ~ALLOC_CPUSET;
+ } else if (unlikely(rt_task(p)) && !in_interrupt())
+ alloc_flags |= ALLOC_HARDER;
+
+ if (likely(!(gfp_mask & __GFP_NOMEMALLOC))) {
+ if (!in_interrupt() &&
+ ((p->flags & PF_MEMALLOC) ||
+unlikely(test_thread_flag(TIF_MEMDIE
+ alloc_flags |= ALLOC_NO_WATERMARKS;
+ }
+
+ return alloc_flags;
+}
+
#endif
Index: linux-2.6-git/mm/page_alloc.c
===
--- linux-2.6-git.orig/mm/page_alloc.c
+++ linux-2.6-git/mm/page_alloc.c
@@ -1175,14 +1175,6 @@ failed:
return NULL;
}
-#define ALLOC_NO_WATERMARKS0x01 /* don't check watermarks at all */
-#define ALLOC_WMARK_MIN0x02 /* use pages_min watermark */
-#define ALLOC_WMARK_LOW0x04 /* use pages_low watermark */
-#define ALLOC_WMARK_HIGH 0x08 /* use pages_high watermark */
-#define ALLOC_HARDER 0x10 /* try to alloc harder */
-#define ALLOC_HIGH 0x20 /* __GFP_HIGH set */
-#define ALLOC_CPUSET 0x40 /* check for correct cpuset */
-
#ifdef CONFIG_FAIL_PAGE_ALLOC
static struct fail_page_alloc_attr {
@@ -1494,6 +1486,7 @@ zonelist_scan:
page = buffered_rmqueue(zonelist, zone, order, gfp_mask);
if (page)
+ page->reserve = (alloc_flags & ALLOC_NO_WATERMARKS);
break;
this_zone_full:
if (NUMA_BUILD)
@@ -1619,48 +1612,36 @@ restart:
* OK, we're below the kswapd watermark and have kicked background
* reclaim. Now things get more complex, so set up a
Re: it seems at XFS bug?!
On May 19 2007 22:24, Willy Tarreau wrote: >On Sat, May 19, 2007 at 09:50:43PM +0200, oliver pinter wrote: >> yeah, but how produziert? > >I *think* it is the unbreakable space. \xa0 is 160, aka the NBSP. But __only__ in ISO-8859. It is an invalid UTF-8 sequence (which is why you may not even "see" the nbsp :-) >Maybe you can enter it on >your keyboard using AltGr-spacebar or something like this. If this >is the case, it's possible that you got it right after a '>' during >a command like below : perl -e 'open F,">\xa0"'; Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Extract common MODULE_INFO content into new moduleinfo.h.
On Sun, 20 May 2007, Robert P. J. Day wrote:
> diff --git a/include/linux/moduleinfo.h b/include/linux/moduleinfo.h
> new file mode 100644
> index 000..cee86a9
> --- /dev/null
> +++ b/include/linux/moduleinfo.h
> @@ -0,0 +1,18 @@
> +#ifndef _LINUX_MODULEINFO_H
> +#define _LINUX_MODULEINFO_H
> +
> +#ifdef MODULE
> +#include
> +#define ___module_cat(a,b) __mod_ ## a ## b
> +#define __module_cat(a,b) ___module_cat(a,b)
> +#define __MODULE_INFO(tag, name, info) \
> +static const char __module_cat(name,__LINE__)[] \
> + __attribute_used__ \
> + __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
This isn't a function definition so __attribute_used__ (which is
deprecated anyway) doesn't mean anything. Please simply use
__maybe_unused and remove "unused" from the second attribute.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] increase struct page size?!
On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> The cache cost argument is specious. Even misaligned, smaller is >> smaller. On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > Of course smaller is smaller ;) Why would that make the cache cost > argument specious? It's not possible to ignore aggregation. For instance, for a subset of mem_map whose size ignoring alignment would otherwise fit in the cache to completely avoid sharing any cachelines between page structures requires page structures to be separated by at least one mem_map index. This is highly unlikely in uniform distributions. On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> The cache footprint reduction is merely amortized, >> probabilistic, etc. On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > I don't really know what you mean by this, or what part of my cache cost > argument you disagree with... > I think it is that you could construct mem_map access patterns, without > specifically looking at alignment, where a 56 byte struct page would suffer > about 75% more cache misses than a 64 byte aligned one (and you could also > get about 12% fewer cache misses with other access patterns). > I also think the kernel's mem_map access patterns would be more on the > random side, so overall would result in significantly fewer cache misses > with 64 byte aligned pages. > Which part do you disagree with? The lack of consideration of the average case. I'll see what I can smoke out there. On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> I'm not so sure about that. I doubt we have issues with that. I say On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > The issue is that userspace can DOS or crash the kernel by deliberately > overflowing count or mapcount. This was a flat out error. On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> if there's to be padding to 64B to use the of the whole additional >> space for additional flag bits. I'm sure fs's could make good use of >> 64 spare flag bits, or whatever's left over after the VM has its fill. >> Perhaps so many spare flag bits could be used in lieu of buffer_heads. On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > Really? 64-bit architectures can already use about maybe 16 or 32 more > page flag bits than 32-bit architectures, and I definitely do not want > to increase the size of 32-bit struct page, so I think this wouldn't > work. Actually they can't use most of those flag bits on account of portability to the 32-bit case. A 32-bit flags on 64-bit is rather plausible due to such. On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> page->virtual is the same old mistake as it was when it was removed. >> The virtual mem_map code should be used to resolve the computational On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > Don't get too hung up on the page->virtual thing. I'll send another > patch with atomic_t/atomic_long_t conversion. That's fine. On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: >> expense. Much the same holds for the atomic_t's; 32 + PAGE_SHIFT is >> 44 bits or more, about as much as is possible, and one reference per >> page per page is not even feasible. Full-length atomic_t's are just >> not necessary. On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > I don't know what your 32 + PAGE_SHIFT calculation is for, but yes you > can wrap these counters from userspace on 64-bit architectures. That's just an error. -- wli - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] GIT 1.5.2
The latest feature release GIT 1.5.2 is available at the usual
places:
http://www.kernel.org/pub/software/scm/git/
git-1.5.2.tar.{gz,bz2}(tarball)
git-htmldocs-1.5.2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.5.2.tar.{gz,bz2} (preformatted docs)
RPMS/$arch/git-*-1.5.2-1.$arch.rpm(RPM)
GIT v1.5.2 Release Notes
Updates since v1.5.1
* Plumbing level superproject support.
You can include a subdirectory that has an independent git
repository in your index and tree objects of your project
("superproject"). This plumbing (i.e. "core") level
superproject support explicitly excludes recursive behaviour.
The "subproject" entries in the index and trees of a superproject
are incompatible with older versions of git. Experimenting with
the plumbing level support is encouraged, but be warned that
unless everybody in your project updates to this release or
later, using this feature would make your project
inaccessible by people with older versions of git.
* Plumbing level gitattributes support.
The gitattributes mechanism allows you to add 'attributes' to
paths in your project, and affect the way certain git
operations work. Currently you can influence if a path is
considered a binary or text (the former would be treated by
'git diff' not to produce textual output; the latter can go
through the line endings conversion process in repositories
with core.autocrlf set), expand and unexpand '$Id$' keyword
with blob object name, specify a custom 3-way merge driver,
and specify a custom diff driver. You can also apply
arbitrary filter to contents on check-in/check-out codepath
but this feature is an extremely sharp-edged razor and needs
to be handled with caution (do not use it unless you
understand the earlier mailing list discussion on keyword
expansion). These conversions apply when checking files in
or out, and exporting via git-archive.
* The packfile format now optionally suports 64-bit index.
This release supports the "version 2" format of the .idx
file. This is automatically enabled when a huge packfile
needs more than 32-bit to express offsets of objects in the
pack.
* Comes with an updated git-gui 0.7.1
* Updated gitweb:
- can show combined diff for merges;
- uses font size of user's preference, not hardcoded in pixels;
- can now 'grep';
* New commands and options.
- "git bisect start" can optionally take a single bad commit and
zero or more good commits on the command line.
- "git shortlog" can optionally be told to wrap its output.
- "subtree" merge strategy allows another project to be merged in as
your subdirectory.
- "git format-patch" learned a new --subject-prefix=
option, to override the built-in "[PATCH]".
- "git add -u" is a quick way to do the first stage of "git
commit -a" (i.e. update the index to match the working
tree); it obviously does not make a commit.
- "git clean" honors a new configuration, "clean.requireforce". When
set to true, this makes "git clean" a no-op, preventing you
from losing files by typing "git clean" when you meant to
say "make clean". You can still say "git clean -f" to
override this.
- "git log" family of commands learned --date={local,relative,default}
option. --date=relative is synonym to the --relative-date.
--date=local gives the timestamp in local timezone.
* Updated behavior of existing commands.
- When $GIT_COMMITTER_EMAIL or $GIT_AUTHOR_EMAIL is not set
but $EMAIL is set, the latter is used as a substitute.
- "git diff --stat" shows size of preimage and postimage blobs
for binary contents. Earlier it only said "Bin".
- "git lost-found" shows stuff that are unreachable except
from reflogs.
- "git checkout branch^0" now detaches HEAD at the tip commit
on the named branch, instead of just switching to the
branch (use "git checkout branch" to switch to the branch,
as before).
- "git bisect next" can be used after giving only a bad commit
without giving a good one (this starts bisection half-way to
the root commit). We used to refuse to operate without a
good and a bad commit.
- "git push", when pushing into more than one repository, does
not stop at the first error.
- "git archive" does not insist you to give --format parameter
anymore; it defaults to "tar".
- "git cvsserver" can use backends other than sqlite.
- "gitview" (in contrib/ section) learned to better support
"git-annotate".
- "git diff $commit1:$path2 $commit2:$path2" can now report
mode changes between the two blobs.
- Local "git fetch" from a repository whose object store is
one of the alternates (e.g. fetching from the origin in a
repository created with "git clone -l -s") avoids
downloading objects unnecessarily.
- "git blame" uses .mailmap to c
Re: it seems at XFS bug?!
Jan Engelhardt <[EMAIL PROTECTED]> writes: > On May 19 2007 22:24, Willy Tarreau wrote: >>On Sat, May 19, 2007 at 09:50:43PM +0200, oliver pinter wrote: >>> yeah, but how produziert? >> >>I *think* it is the unbreakable space. > > \xa0 is 160, aka the NBSP. But __only__ in ISO-8859. It is an invalid > UTF-8 sequence (which is why you may not even "see" the nbsp :-) Actually, in a utf-8 environment you see it much better. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: it seems at XFS bug?!
On Sun, May 20, 2007 at 10:39:33AM +0200, Jan Engelhardt wrote: > > On May 19 2007 22:24, Willy Tarreau wrote: > >On Sat, May 19, 2007 at 09:50:43PM +0200, oliver pinter wrote: > >> yeah, but how produziert? > > > >I *think* it is the unbreakable space. > > \xa0 is 160, aka the NBSP. But __only__ in ISO-8859. It is an invalid > UTF-8 sequence (which is why you may not even "see" the nbsp :-) An even better reason is to be in ISO-8859 :-) Willy - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [rfc] increase struct page size?!
On Sun, May 20, 2007 at 01:46:47AM -0700, William Lee Irwin III wrote: > On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: > >> The cache cost argument is specious. Even misaligned, smaller is > >> smaller. > > On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > > Of course smaller is smaller ;) Why would that make the cache cost > > argument specious? > > It's not possible to ignore aggregation. For instance, for a subset > of mem_map whose size ignoring alignment would otherwise fit in the > cache to completely avoid sharing any cachelines between page > structures requires page structures to be separated by at least one > mem_map index. This is highly unlikely in uniform distributions. But that wasn't my argument. I _know_ there are cases where the smaller struct would be better, and I'm sure they would even arise in a running kernel. > On Sat, May 19, 2007 at 11:15:01AM -0700, William Lee Irwin III wrote: > >> The cache footprint reduction is merely amortized, > >> probabilistic, etc. > > On Sun, May 20, 2007 at 07:22:29AM +0200, Nick Piggin wrote: > > I don't really know what you mean by this, or what part of my cache cost > > argument you disagree with... > > I think it is that you could construct mem_map access patterns, without > > specifically looking at alignment, where a 56 byte struct page would suffer > > about 75% more cache misses than a 64 byte aligned one (and you could also > > get about 12% fewer cache misses with other access patterns). > > I also think the kernel's mem_map access patterns would be more on the > > random side, so overall would result in significantly fewer cache misses > > with 64 byte aligned pages. > > Which part do you disagree with? > > The lack of consideration of the average case. I'll see what I can smoke > out there. I _am_ considering the average case, and I consider the aligned structure is likely to win on average :) I just don't have numbers for it yet. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[ANNOUNCE] Staircase Deadline v1.00 cpu scheduler
The staircase deadline cpu scheduler continues to be the reference with respect to interactive fairness for many workloads especially with 3d gaming. This version is only trivially different from the version included in the -ck patchset which has been very stable. The version number has been incremented to version 1.00 purely to reflect that stability. Those on -ck are already running the equivalent of this version. http://www.kernel.org/pub/linux/kernel/people/ck/patches/staircase-deadline/2.6.22-rc2/2.6.22-rc2-sd-1.00.patch In comparison with the standalone version 0.48 of sd the changes are as follows: Default rr_interval was increased to 10ms on uniprocessor (it is scaled up on SMP) for throughput reasons. Note that -ck has 6ms and -cks has 10ms as defaults (on UP, double that for 2 cpus). This can be altered (as always) by modifying the value in /proc/sys/kernel/rr_interval. The PRIO value exported to userspace as seen by 'top', 'ps' etc will now reflect the relative priority of tasks on the expired array by their value being greater than 39. The interactive tunable patch was rolled into this patch and is enabled by default. Note the effect of this tunable is subtle except on 3d games. This can be altered by modifying /proc/sys/kernel/interactive. A summary of the interactive sysctl from Documentation/sysctl/kernel is: The staircase-deadline cpu scheduler can be set in either purely forward-looking mode for absolutely rigid fairness and cpu distribution according to nice level, or it can allow a small per-process history to smooth out cpu usage perturbations common in interactive tasks by enabling this sysctl. While small fairness issues can arise with this enabled, overall fairness is usually still strongly maintained and starvation is never possible. Enabling this can significantly smooth out 3d graphics and games. -- -ck - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sat, May 19, 2007 at 04:22:39PM -0700, Andrew Morton wrote: > On Sun, 20 May 2007 01:05:37 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > Look for example at the last one in drivers/input/mouse/Kconfig: > > > > config MOUSE_ATARI > > tristate "Atari mouse" > > depends on ATARI > > select ATARI_KBD_CORE > > > > This is perfectly correct (the select'ed symbol is only unavailable when > > the dependency can't be fulfilled), and all things to "fix" the warning > > will make it worse. > > If ATARI is unset then we shouldn't be generating the "'select' used by > config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'" > warnings, should we? Playing devils advocate here. What if "ATARI_KBD_CORE" never exists? Let's say you run 'make kconfig' and you select the ATARI option. When does the lack of ATARI_KBD_CORE get noticed and what is the expected result? Let's put it another way. Given the complexities of the configuration system as it is today, if we do not generate a warning at parse time, how do we find things like: config SHARPSL_PM bool select APM_EMULATION config PXA_SHARP_C7xx bool select PXA_SSP select SHARPSL_PM config MACH_CORGI bool "Enable Sharp SL-C700 (Corgi) Support" depends on PXA_SHARPSL_25x select PXA_SHARP_C7xx and (lets say for the sake of argument) APM_EMULATION were to go away. Do we really need an exhaustive set of configuration combinations to run through Kconfig to find possible missing symbols? Or do we need a Kconfig lint to find them? If we're going to make Kconfig warn on missing symbols only when they're attempted to be selected, you'll have to choose one of those two options. Choosing none is not an option. -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sun, May 20, 2007 at 02:02:35AM +0200, Adrian Bunk wrote: > On Sat, May 19, 2007 at 04:22:39PM -0700, Andrew Morton wrote: > > On Sun, 20 May 2007 01:05:37 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote: > > > > > Look for example at the last one in drivers/input/mouse/Kconfig: > > > > > > config MOUSE_ATARI > > > tristate "Atari mouse" > > > depends on ATARI > > > select ATARI_KBD_CORE > > > > > > This is perfectly correct (the select'ed symbol is only unavailable when > > > the dependency can't be fulfilled), and all things to "fix" the warning > > > will make it worse. > > > > If ATARI is unset then we shouldn't be generating the "'select' used by > > config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'" > > warnings, should we? > > Exactly. If we do that we need to try a million and one Kconfig option combinations to find undefined symbols. Not practical. (And no, allyconfig really doesn't hack it on non-x86 platforms, no matter how much people whinge that it should do. It's a pipedream to make it so.) -- Russell King Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/ maintainer of: - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: implement ata_wait_after_reset()
Indan Zupancic wrote: >> 1. We dropped libata specific suspend/resume implementation in favor of >> sd driven one. Unfortunately, the new implementation currently can't do >> background spinup, so that's probably why you can feel the delay. We >> need to figure out how to do background spinup with the new implementation. > > What are the advantages of that, except slower resume? ;-) The change was made primarily to make libata spin down disks properly on power down and hibernate. I don't like the added delay either but it's better than shortening the lifespan of harddisks. Making resuming asynchronous is planned but we need more infrastructure to do that properly. The previous implementation worked but it also might try to spin up a lot of disks at once which can't be good for PSU. I'm not sure yet how to do that properly with sd driving suspend/resume. >> 2. To make reset finish in defined time, each reset try now has defined >> deadlines. I was trying to be conservative so I chose 10sec for the >> first try. > > Right. So to me it seems that failed, because the undefined reset time is just > replaced with a fixed ad hoc sleep, which is longer than any undefined reset > mechanism. So where did the advantage go? Better to go back to how it was, > is my impression. Or make that deadline 10 seconds and after that give up, > instead of the other way round. Or just move to async reset. Well, yeah, your case degraded for sure but a lot of hotplug or error handling cases are now much better which often used to take more than 30 secs in many cases. There are just a lot of cases and a lot of weird devices. Aiming generally acceptable delay on most cases is of higher priority than optimizing specific cases. That said, the 10 sec delayed retry you're seeing is primarily caused by incorrect interpretation of 0xff status on sata_sil, so with that fixed, it shouldn't be too much of a problem. >> It's driven by timing table near the top of libata-eh.c, so >> adjusting the table is easy and maybe we can be a bit more aggressive >> with the first two tries. But if we solve #1, this shouldn't matter too >> much. > > #2 seems totally unrelated to #1, as #1 is about spinup, and #2 about reset. > Only relation is that #2 slows down #1 because #1 needs to wait on #2. Not that easy. Many drives don't respond to reset while they're spinning up. >>> Maybe a silly question, but why do we wait for the harddisk to show up? >>> Maybe that >>> makes a little bit of sense at bootup, but for resume from ram, where >>> nothing is >>> supposed to have changed, it seems a bit strange. Why not wait when >>> something tries >>> to access the harddisk or something? >> I hope it's explained now. > > Almost. Explained is why we wait on the disk, but that's only the sd_resume > part. > It's still unclear why resume must wait till the reset is done. Port reset itself is asynchronous. The wait is solely from sd_resume. >>> I wonder if sil_pci_device_resume() and sd_resume() know about each other... >>> I'll disable sd_resume() and see how that goes. >> Yeap, that should work. In most configurations, devices spin up >> immediately after power is restored. sd_resume() just waits for the >> device to be revalidated in such cases. > > And it kicks the disk into action. Why? Only thing it does is sending a > START_STOP > command. I assume that causes the disk to spin up. But for e.g. laptopmode I > can > imagine that's quite annoying. I think sd_resume() is totally unnecessary and > can > be removed, because it seems wrong to always force the harddisk to spin up, > background spin up or not. Most ATA drives would spin up immediately when power is reapplied unless configured otherwise and you can configure whether sd_resume issues START_STOP or not by echoing to sysfs node /sys/class/scsi_disk/h:c:i:l/manage_start_stop. The drawback here is you won't get proper spindown if you turn it off. Adding fine-grained control can be useful. Wanna give it a try? Shouldn't be too difficult and, as manage_start_stop is just added, I think we can still change its API. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sun, 20 May 2007, Satyam Sharma wrote: > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > On Sun, May 20, 2007 at 05:25:24AM +0530, Satyam Sharma wrote: > > > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > >> On Sun, May 20, 2007 at 05:06:33AM +0530, Satyam Sharma wrote: > > >> > On 5/20/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > > >> There are cases where "default .. if .." is the right idiom, but there > > >> are also cases where "select" is the right idiom. And for helper code > > >> like ATARI_KBD_CORE, "select" is the right idiom. > > > > > > ATARI_KBD_CORE, unlike MII, is defined only by some archs. And the > > > correct (most widely used or standard, in any case) idiom for that is > > > "default .. if ..". Or perhaps you can convert those helper code options > > > in > > > arch/.../config's over to select too, as an exercise? :-) > > > > Perhaps not as an exercise, but actually for real. > > > > We had "fixed" such warnings in the past similar to your patch, but that > > was actually a mistake. > > > > And "correct" can easily be the opposite of "most widely used or standard" > > if you discover that you did it wrong in the past. > > In that case the correct approach here too would be to _shift_ > ATARI_KBD_CORE from arch/m68k/Kconfig to drivers/input/Kconfig > and *then* use "select" from the config options that require it in > drivers/input/keyboard/Kconfig and drivers/input/mouse/Kconfig > > (and repeat for other such cases in arch/...) You don't need a huge '||' chain, you can always have more than one default line: config ATARI_KBD_CORE bool default y if KEYBOARD_ATARI default y if MOUSE_ATARI Basically a line "config A \n select B" is transformed into "config B \n default y if A". It's the same number of lines, they're just in a new place. Another alternative would be to shift the arch specific drivers to a file that's arch specific. e.g. move MOUSE_ATARI from drivers/input/mouse/Kconfig to arch/m68k/Kconfig. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
Indan Zupancic wrote: > On Sat, May 19, 2007 21:04, Tejun Heo wrote: >> Tejun Heo wrote: >>> Yeah, if SCR registers are accessible, 0xff doesn't indicate the device >>> isn't there, so the whole skip-0xff logic probably shouldn't apply in >>> such cases, but we can also achieve pretty good result by just making >>> the first reset tries a bit more aggressive. >> So, here's the patch. >> >> Paul, can you please test this patch without the previous patch? Indan, >> this should reduce the resume delay. Please test. But you'll still >> feel some added delay compared to 2.6.20 due to the mentioned >> suspend/resume change. > > This removed the COMRESET errors indeed, and with sd_resume() > disabled everything is speedy again (2s or so. Still a desktop pc). > I didn't try with sd_resume enabled. Can you try to measure with sd_resume in place? > Everything seems to work fine without sd_resume(), so why is it needed? Because not all disks spin up without being told to do so and like it or not spinning disks up on resume is the default behavior. As I wrote in the other reply, it would be worthwhile to make it configurable. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: building i386 requires s390: "driver/crypto/Kconfig" sourcing s390 arch
On Fri, May 18, 2007 at 11:47:05PM -0700, Linda Walsh wrote: > Randy Dunlap wrote: > >if S390 > >source "arch/s390/crypto/Kconfig" > >endif > > > Why bother? Why not just move the contents of s390's crypto "Kconfig" > in place of the "source" statement. All the options in s390's Kconfig > are already conditional depending on S390. > > The contents simply need to be [moved] in[to] the the main crypto > config file (./drivers/crypto/Kconfig). > > It "works" fine on i386, don't see why it wouldn't build on any other > arch. Send a patch. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: it seems at XFS bug?!
On May 20 2007 11:14, Andreas Schwab wrote: >Jan Engelhardt <[EMAIL PROTECTED]> writes: >> On May 19 2007 22:24, Willy Tarreau wrote: >>>On Sat, May 19, 2007 at 09:50:43PM +0200, oliver pinter wrote: yeah, but how produziert? >>> >>>I *think* it is the unbreakable space. >> >> \xa0 is 160, aka the NBSP. But __only__ in ISO-8859. It is an invalid >> UTF-8 sequence (which is why you may not even "see" the nbsp :-) > >Actually, in a utf-8 environment you see it much better. But only if invalid sequences are replaced by a question mark or whatever, which is not the case in xterm. Jan -- - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sun, May 20, 2007 at 10:40:33AM +0100, Russell King wrote: > > Do we really need an exhaustive set of configuration combinations to > run through Kconfig to find possible missing symbols? Or do we need a > Kconfig lint to find them? > > If we're going to make Kconfig warn on missing symbols only when they're > attempted to be selected, you'll have to choose one of those two options. > Choosing none is not an option. The best solution would be to give kconfig full knowledge of all Kconfig files. Then the "undefined symbol" is no longer a warning but an error. That would require a bit of kconfig surgery that we should do one day. But giving kconfig full knowledge would gain a lot in several scenarios. Turning the undefined symbol to an error is just one part of it. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] local_softirq_pending storm
On Sat, May 19, 2007 at 09:11:08PM +0200, Thomas Gleixner wrote: > On Sat, 2007-05-19 at 15:25 +0530, Anant Nitya wrote: > > > No idea. I uploaded a debug patch against 2.6.22-rc1 to > > > > > > http://www.tglx.de/private/tglx/2.6.22-rc1-hrt-debug.patch > > > > > > Can you give it a try and report the output ? > > Hi > > Here it goes > > [ 159.646196] NOHZ softirq pending 22 on CPU 0 > > [ 159.646207] task state: 1 > > 1 == TASK_INTERRUPTIBLE, so we know that ksoftirqd was not woken up. At > least it is not a scheduler problem. > > I work out a more complex debug patch and pester you to test once I'm > done. I've also tons of 'NOHZ: local_softirq_pending 08' that disappear with nohz=off. But I'm still running 2.6.21. Are there any patches that should fix this? Machine is a Lenovo T60p: i686 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux Besides that I get a lot of clock skews on 'make headers_check', but these are unrelated to nohz: CHECK include/asm/dasd.h make[2]: warning: Clock skew detected. Your build may be incomplete. make[2]: Warning: File `/dev/null' has modification time 5.1e+03 s in the future - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_sil: Greatly improve DMA support
Indan Zupancic wrote: > On Sun, May 20, 2007 00:03, Jeff Garzik wrote: >> Indan Zupancic wrote: >>> This patch seems to work with my SiI 3512, though I don't notice any >>> difference, neither a speedup, nor a slowdown. Hdparm gives the same >>> speeds (-tT), and cp -a'ing kernel sources is abysmal slow in both cases, >>> (need to look into that one) so I didn't really test it that well. >> >> It won't result in much of a speedup, except in situations where IOMMU >> or other situation that causes you to run into the 64k boundary being an >> issue -- generally only on huge transfers. >> >> A good measure is to dd(1) to/from the block device, rather than using a >> filesystem. As has been shown on LKML, the filesystem can really slow >> things down in some cases. > > I didn't really expect a speedup, it's more that I've no regression to report. > > I could benchmark the patch more thoroughly, but right now I'm more worried > about the crawling cp I just discovered. Talking about filesystems slowing > down > things... > > Test: > > $ cp -a linux-2.6/ /tmp/ > > done on the same ext3 partition. linux-2.6 contains source and git repo only, > I'm compiling stuff with O=../obj. > > $ vmstat 10 > procs ---memory-- ---swap-- -io -system-- cpu > r b swpd free buff cache si sobibo in cs us sy id wa > 0 1 0 4168 3316 19570000 739 494 530 393 15 3 66 16 > 0 3 4 4120 2040 19819600 14677 14111 1247 435 0 17 0 83 > 0 1 4 3588 1444 19969600 8892 9472 1362 438 0 12 0 88 > 1 0 4 3772 4228 19601200 764 454 1161 345 0 4 0 96 > 0 1 4 3548 6156 19308800 793 851 1158 340 0 4 0 96 > 0 1 4 3852 7608 18909600 798 523 1160 474 1 4 0 95 > 1 1 4 3612 8684 18604800 1244 864 1178 430 2 5 0 93 > 0 1 4 90660 9308 9639600 853 906 1244 578 7 6 0 87 > 0 1 4 72280 9816 11236800 830 854 1278 429 12 5 0 83 > 1 0 4 52488 10296 13056000 935 861 1178 418 1 6 0 94 > 0 1 4 30500 10788 14977600 977 858 1178 371 0 6 0 94 > 0 1 4 9792 11244 16785600 918 1394 1182 350 1 5 0 94 > 0 1 4 4016 11216 17250400 1017 858 1181 382 1 6 0 94 > 0 1 4 3660 11484 17148400 966 861 1182 410 1 6 0 94 > > It never finished, as I had no patience to copy about 900 Mb with this rate. > > As it's a git tree, I suppose it's heavily fragmented, but this is still > rather > pathetic. Should I blame cp, or is something else wrong? Any ideas how > to figure this one out would be appreciated. Sorry for the off-topicness. Do things improve if you change the io scheduler to deadline? # echo deadline > /sys/block/sda/queue/scheduler Also worth looking at is the following bug entry. http://bugzilla.kernel.org/show_bug.cgi?id=7372 There seems to be weird interaction among the scheduler / VM / IO. The exact cause is still not verified. :-( -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
On Sun, May 20, 2007 at 12:12:50PM +0200, Mariusz Kozlowski wrote: > Hello, > > I tried it on iMac G3. I got a bunch of warnings > and finally it failed to build. > > WARNING: "fee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol > WARNING: "ee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol > WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to > .init.data:.got2 from dt_string_start (offset 0x8) Most - but not all of these warnings should be gone when Linus pulls kbuild-fix.git. When -rc3 is ready can you then please post the result of a build. Then I can take a look at the remaining section mismatch warnings. Sam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] drivers/block/z2ram: Remove TRUE/FALSE defines
On Sun, 20 May 2007, Richard Knutsson wrote:
> Remove defines of TRUE and FALSE
> * not used in the file
> * the file is not included somewhere else
>
> Signed-off-by: Richard Knutsson <[EMAIL PROTECTED]>
Acked-by: Geert Uytterhoeven <[EMAIL PROTECTED]>
> ---
> Not compile-tested (don't have an Amiga-crosscompiler), but it is trivial.
> Diffed against Linus' git-tree.
>
>
> diff --git a/drivers/block/z2ram.c b/drivers/block/z2ram.c
> index 7cc2685..2abf94c 100644
> --- a/drivers/block/z2ram.c
> +++ b/drivers/block/z2ram.c
> @@ -44,9 +44,6 @@
> extern int m68k_realnum_memory;
> extern struct mem_info m68k_memory[NUM_MEMINFO];
>
> -#define TRUE (1)
> -#define FALSE (0)
> -
> #define Z2MINOR_COMBINED (0)
> #define Z2MINOR_Z2ONLY(1)
> #define Z2MINOR_CHIPONLY (2)
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Extract common MODULE_INFO content into new moduleinfo.h.
On Sun, 20 May 2007, David Rientjes wrote:
> On Sun, 20 May 2007, Robert P. J. Day wrote:
>
> > diff --git a/include/linux/moduleinfo.h b/include/linux/moduleinfo.h
> > new file mode 100644
> > index 000..cee86a9
> > --- /dev/null
> > +++ b/include/linux/moduleinfo.h
> > @@ -0,0 +1,18 @@
> > +#ifndef _LINUX_MODULEINFO_H
> > +#define _LINUX_MODULEINFO_H
> > +
> > +#ifdef MODULE
> > +#include
> > +#define ___module_cat(a,b) __mod_ ## a ## b
> > +#define __module_cat(a,b) ___module_cat(a,b)
> > +#define __MODULE_INFO(tag, name, info) \
> > +static const char __module_cat(name,__LINE__)[]\
> > + __attribute_used__ \
> > + __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
>
> This isn't a function definition so __attribute_used__ (which is
> deprecated anyway) doesn't mean anything. Please simply use
> __maybe_unused and remove "unused" from the second attribute.
i can do that as long as there's no way that those changes can (even
theoretically) make a difference in the build. in order to make sure
this patch didn't break anything, i went with a straight cut-and-paste
of the content to go into the new moduleinfo.h.
so while i agree that those changes shouldn't hurt, personally, i'd
prefer to just put this patch through as is and come back later to do
any tidying related to attribute rewording.
rday
--
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA
http://fsdev.net/wiki/index.php?title=Main_Page
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] lockdep: lock contention tracking
Add lock contention tracking to lockdep
[EMAIL PROTECTED] ~]# cat /proc/lockdep_contentions | sort -rnk 2 | head
dcache_lock: 3000 0 [618] [] _atomic_dec_and_lock+0x39/0x58
[17] [] sysfs_open_file+0x28/0x25a [160] []
d_instantiate+0x2a/0xad [52] [] __link_path_walk+0x270/0xde9
&inode->i_mutex: 235 0 [15] [] pipe_read+0x74/0x39d [23]
[] pipe_wait+0x86/0x8d [105] []
do_lookup+0x81/0x1ae [85] [] vfs_readdir+0x5c/0xa9
&zone->lru_lock: 141 0 [11] [] activate_page+0x37/0xd6 [75]
[] release_pages+0xb2/0x16c [42] []
__pagevec_lru_add_active+0x62/0xe5 [12] []
__pagevec_lru_add+0x63/0xe2
&rq->rq_lock_key: 93 0 [66] [] task_rq_lock+0x42/0x74 [24]
[] __sched_text_start+0x17a/0x869 [2] []
double_rq_lock+0x38/0x3d [1] [] double_lock_balance+0x41/0x52
&rq->rq_lock_key: 59 0 [15] [] __sched_text_start+0x17a/0x869
[27] [] task_rq_lock+0x42/0x74 [17] []
__sched_text_start+0x2e0/0x869
files_lock: 57 0 [28] [] file_move+0x1d/0x51 [29]
[] file_kill+0x15/0x39
&inode->i_data.i_mmap_lock: 52 0 [16] []
copy_process+0xe10/0x1684 [5] [] vma_link+0x40/0x107 [20]
[] unlink_file_vma+0x2c/0x53 [11] []
vma_adjust+0x154/0x452
&q->__queue_lock: 47 0 [16] [] __make_request+0x5e/0x663 [4]
[] __make_request+0x5bc/0x663 [2] []
generic_unplug_device+0x18/0x25 [1] []
generic_unplug_device+0x10/0x25
&dentry->d_lock: 26 0 [22] [] __d_lookup+0x7d/0x136 [4]
[] dnotify_parent+0x1f/0x6d
vfsmount_lock: 17 0 [16] [] lookup_mnt+0x19/0x4c [1]
[] __d_path+0xae/0x14c
read as:
<(write) contentiond>
( ){,4}
The 4 points are the first 4 unique callsites that cause lock contention
for the specified lock class.
writing a 0 to /proc/lockdep_contentions clears the stats
Signed-off-by: Peter Zijlstra <[EMAIL PROTECTED]>
---
include/linux/lockdep.h | 14 +++
kernel/lockdep.c| 96
kernel/lockdep_proc.c | 77 ++
kernel/mutex.c |7 +++
kernel/rwsem.c | 20 --
kernel/spinlock.c | 70 ---
6 files changed, 266 insertions(+), 18 deletions(-)
Index: linux-2.6/include/linux/lockdep.h
===
--- linux-2.6.orig/include/linux/lockdep.h 2007-04-03 13:58:27.0
+0200
+++ linux-2.6/include/linux/lockdep.h 2007-05-19 10:26:44.0 +0200
@@ -16,6 +16,7 @@ struct task_struct;
#include
#include
#include
+#include
/*
* Lock-class usage-state bits:
@@ -71,6 +72,11 @@ struct lock_class_key {
struct lockdep_subclass_key subkeys[MAX_LOCKDEP_SUBCLASSES];
};
+struct lockdep_contention_point {
+ unsigned long ip;
+ atomic_t count;
+};
+
/*
* The lock-class itself:
*/
@@ -114,6 +120,10 @@ struct lock_class {
const char *name;
int name_version;
+
+ atomic_tread_contentions;
+ atomic_twrite_contentions;
+ struct lockdep_contention_point contention_point[4];
};
/*
@@ -243,6 +253,9 @@ extern void lock_acquire(struct lockdep_
extern void lock_release(struct lockdep_map *lock, int nested,
unsigned long ip);
+extern void lock_contended(struct lockdep_map *lock, int read,
+ unsigned long ip);
+
# define INIT_LOCKDEP .lockdep_recursion = 0,
#define lockdep_depth(tsk) (debug_locks ? (tsk)->lockdep_depth : 0)
@@ -259,6 +272,7 @@ static inline void lockdep_on(void)
# define lock_acquire(l, s, t, r, c, i)do { } while (0)
# define lock_release(l, n, i) do { } while (0)
+# define lock_contended(l, r, i) do { } while (0)
# define lockdep_init()do { } while (0)
# define lockdep_info()do { } while (0)
# define lockdep_init_map(lock, name, key, sub)do { (void)(key); }
while (0)
Index: linux-2.6/kernel/lockdep.c
===
--- linux-2.6.orig/kernel/lockdep.c 2007-05-10 17:24:41.0 +0200
+++ linux-2.6/kernel/lockdep.c 2007-05-19 10:58:40.0 +0200
@@ -2261,6 +2261,33 @@ print_unlock_inbalance_bug(struct task_s
return 0;
}
+static int
+print_lock_contention_bug(struct task_struct *curr, struct lockdep_map *lock,
+ unsigned long ip)
+{
+ if (!debug_locks_off())
+ return 0;
+ if (debug_locks_silent)
+ return 0;
+
+ printk("\n=\n");
+ printk( "[ BUG: bad contention detected! ]\n");
+ printk( "-\n");
+ printk("%s/%d is trying to content lock (",
+ curr->comm, curr->pid);
+ print_lockdep_cache(lock);
+ printk(") at:\n");
+ print_ip_sym(ip);
+ printk("but there are no locks held
Re: it seems at XFS bug?!
Jan Engelhardt <[EMAIL PROTECTED]> writes: > On May 20 2007 11:14, Andreas Schwab wrote: >>Jan Engelhardt <[EMAIL PROTECTED]> writes: >>> On May 19 2007 22:24, Willy Tarreau wrote: On Sat, May 19, 2007 at 09:50:43PM +0200, oliver pinter wrote: > yeah, but how produziert? I *think* it is the unbreakable space. >>> >>> \xa0 is 160, aka the NBSP. But __only__ in ISO-8859. It is an invalid >>> UTF-8 sequence (which is why you may not even "see" the nbsp :-) >> >>Actually, in a utf-8 environment you see it much better. > > But only if invalid sequences are replaced by a question mark or whatever, > which is not the case in xterm. That depends on your font, I guess. The font I use has a visible replacement character. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP BUG] [clockevents: i386 drivers patch] introduces irqbalance-does-not-work-properly problem
On Sat, 19 May 2007 23:03:56 -0400 Jeff Garzik <[EMAIL PROTECTED]> wrote: > Do you mean userspace irqbalance daemon? Yes. I mean userspace irqbalance daemon. Best Regards Komuro > Komuro wrote: > > [clockevents: i386 drivers patch] introduces > > irqbalance-does-not-work-properly problem. > > > > > > (The irq is not distributed to two Core > > ,most of the irq is distributed to CPU1) > > > > > > Mr. Thomas Gleixner, > > any idea to fix this problem? > > Do you mean userspace irqbalance daemon? > > It might need to be modified to work properly with a new and unusual > event source. > > Also, for some irq events, it may be good to send most interrupts to one > core/CPU. That enhances caching effects, among other benefits. Again, > this is highly dependent on the event source, I'm not saying that is the > case here. > > Regards, > > Jeff > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP BUG] [clockevents: i386 drivers patch] introduces irqbalance-does-not-work-properly problem
On Sun, 20 May 2007 09:09:16 +0200 Thomas Gleixner <[EMAIL PROTECTED]> wrote: > > Mr. Thomas Gleixner, > > any idea to fix this problem? > > Which problem ? The problem is CPU1 receives 38239 interrupt-16 but CPU0 receives only 15 interrupt-16 CPU0 should receive more interrupts. CPU0 CPU1 0: 85 0 IO-APIC-edge timer 1: 0698 IO-APIC-edge i8042 6: 0 5 IO-APIC-edge floppy 8: 0 1 IO-APIC-edge rtc 9: 0 0 IO-APIC-fasteoi acpi 12: 0114 IO-APIC-edge i8042 14:369 2281 IO-APIC-edge ide0 15: 0 24 IO-APIC-edge ide1 16: 15 38239 IO-APIC-fasteoi yenta, pcnet_cs <<< problem 17: 0 0 IO-APIC-fasteoi yenta NMI: 0 0 LOC: 50548 50547 ERR: 0 MIS: 15503 Best Regards Komuro > On Sun, 2007-05-20 at 11:14 +0900, Komuro wrote: > > Hi, > > > > > > [clockevents: i386 drivers patch] introduces > > irqbalance-does-not-work-properly problem. > > it disables irq balancing for IRQ0, but this does not affect any other > interrupts. It is almost irrelevant as the PIT/HPET timer interrupt > (irq0) is disabled anyway and the local apic timer is used. > > > >CPU0 CPU1 > > > 0: 85 0 IO-APIC-edge timer > > There is no interrupt happening after bootup, so balancing is not a > problem here. > > > Mr. Thomas Gleixner, > > any idea to fix this problem? > > Which problem ? > > tglx > > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Kernel NFS lockd freezes notebook on shutdown (Linux 2.6.22-rc1 + CFS v12)
Hello Oleg, I've done some more tests and quite frankly I think this is really related to the dreaded ''fglrx.ko'' module. It seems to me that it is much easier to reproduce the problem if that damn module is loaded. It does uses workqueue. Then there is another driver ipw3945 loaded and it is required to run binary only ''ipw3945d'' daemon just to start using wireless driver ... In either way both these kernel modules are workqueue users. Btw, I had also tested kernel (compiled from the same source) but on different laptop (EVO N800v), single core, Pentium M 2GHz. Kernel is not freezing on shutdown, even loop nfs kernel stop/start - does not cause any kernel panic as on nx9420 (Dual Core) laptop. And that with or without any patch applied from Oleg. :(( I think this time it is really needed to stop here, kernel was tainted for a reason. :((( Thank you both, Oleg and Andrew. Zilvinas "Lucky ATI fglrx owner" Valinskas On Sat, 19 May 2007, Oleg Nesterov wrote: On 05/18, Zilvinas Valinskas wrote: On Thu, 2007-05-17 at 22:45 +0400, Oleg Nesterov wrote: However, I can't understand why cleanup_workqueue_thread() hangs anyway. It shouldn't. Looks like rpciod/1 was preempted, and can't get CPU. According to kernel-nfs-freeze.log it is TASK_RUNNING. Strange. It is very sad, because this code was supposed to be cleanuped anyway, but if it is really buggy, it would be great to know why. Can this be related to : CONFIG_PREEMPT=y Yes, but this preemption should be very unlikely, but it happens every time for you, strange. lockd in turn spins with preemption enabled, but somehow rpciod/1 can't make progress. system_state == SYSTEM_HALT, but this shouldn't affect preempt_schedule_irq(). So I think there is something else. workqueue.objdump - without any patch. So it hangs waiting for cwq->thread == NULL, as expected. OK. I still can't see how this code could be wrong, but it is bad anyway and should be changed. The 2nd patch was done more than a month ago, but was delayed for some stupid reasons. I'll send it today. Still, it is not clear to me what happens, and you have other crashes with nfs stop/start http://marc.info/?l=linux-kernel&m=117939027602591 http://marc.info/?l=linux-kernel&m=117939257630947 which probaly need some attention. Thanks! Oleg. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/5] 2.6.22-rc2: known regressions
Hello, Michal Piotrowski wrote: > SATA/PATA > > Subject: libata and legacy ide pcmcia failure > References : http://lkml.org/lkml/2007/5/17/305 > Submitter : Robert de Rooy <[EMAIL PROTECTED]> > Status : Unknown Doesn't look like a regression to me. Doubled timeout looks like a problem with timer. I'll follow up on the original thread. > Subject: pata_via appears to incorrectly detects 40-pin cable > References : http://lkml.org/lkml/2007/5/17/273 > http://bugzilla.kernel.org/show_bug.cgi?id=8142 > Submitter : Francis Russell <[EMAIL PROTECTED]> > Status : Unknown Not really a regression. Alan seems to have a general fix and I think we can also quirk the specific case. > Subject: libata crash on halt > References : http://marc.info/?l=linux-ide&m=117899827710565&w=2 > Submitter : Andrew Morton <[EMAIL PROTECTED]> > Caused-By : Tejun Heo <[EMAIL PROTECTED]> > commit 920a4b1038e442700a1cfac77ea7e20bd615a2c3 > Status : problem is being debugged This was fixed by the following commit. commit da071b42f73dabbd0daf7ea4c3ff157d53b00648 Author: Tejun Heo <[EMAIL PROTECTED]> Date: Mon May 14 17:26:18 2007 +0200 libata: fix shutdown warning message printing > Subject: libata reset-seq merge broke sata_sil on sh > References : http://lkml.org/lkml/2007/5/10/63 > Submitter : Paul Mundt <[EMAIL PROTECTED]> > Handled-By : Tejun Heo <[EMAIL PROTECTED]> > Caused-By : commit 4750def52cb2c21732dda9aa1d43a07db37b0186 > Status : problem is being debugged Possible fix proposed. http://lkml.org/lkml/2007/5/19/161 I'll push the fix once Paul verifies it. Thanks. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Trent Piepho wrote: > config ATARI_KBD_CORE > bool > default y if KEYBOARD_ATARI > default y if MOUSE_ATARI > > Basically a line "config A \n select B" is transformed into "config B \n > default y if A". It's the same number of lines, they're just in a new place. Basically you replace A... depends on B by B... serves A The latter variant is a pain to maintain. Dependencies change over time, therefore we should note the dependency always at the dependent option, not at the serving option. Iterating upwards and downwards the dependency graph is the duty of "make snafuconfig", not of the maintainers. Besides, the "serves" form cannot stand in for constructs like A... depends on (B && C) || D -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Race free attributes in sysfs
Hi Greg, I'm reworking the sysfs stuff in the MMC layer to be a bit more flexible, but there is one thing that has me baffled; how do you add attributes to an object in a race free manner when you have a dynamic set of attributes. I've looked at other parts of the kernel and they all use: 1. Add object. 2. Add attributes. To me, it seems like there's a window between 1 and 2 where the object is in /sys but doesn't have the proper attributes. Life for user space gets very annoying if it has to add artificial delays to avoid this window. So how do I do this properly? Something like this would, from my point of view, be the sane method: 1. Add hidden object. 2. Add attributes. 3. Show object. Rgds -- -- Pierre Ossman Linux kernel, MMC maintainerhttp://www.kernel.org PulseAudio, core developer http://pulseaudio.org rdesktop, core developer http://www.rdesktop.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On Sun, 20 May 2007, Russell King wrote:
> On Sat, May 19, 2007 at 04:22:39PM -0700, Andrew Morton wrote:
> > On Sun, 20 May 2007 01:05:37 +0200 Adrian Bunk <[EMAIL PROTECTED]> wrote:
> > > Look for example at the last one in drivers/input/mouse/Kconfig:
> > >
> > > config MOUSE_ATARI
> > > tristate "Atari mouse"
> > > depends on ATARI
> > > select ATARI_KBD_CORE
> > >
> > > This is perfectly correct (the select'ed symbol is only unavailable when
> > > the dependency can't be fulfilled), and all things to "fix" the warning
> > > will make it worse.
> >
> > If ATARI is unset then we shouldn't be generating the "'select' used by
> > config symbol 'KEYBOARD_ATARI' refers to undefined symbol 'ATARI_KBD_CORE'"
> > warnings, should we?
>
> Playing devils advocate here. What if "ATARI_KBD_CORE" never exists?
> Let's say you run 'make kconfig' and you select the ATARI option. When
> does the lack of ATARI_KBD_CORE get noticed and what is the expected
> result?
>
> Let's put it another way. Given the complexities of the configuration
> system as it is today, if we do not generate a warning at parse time,
> how do we find things like:
>
> config SHARPSL_PM
> bool
> select APM_EMULATION
>
> config PXA_SHARP_C7xx
> bool
> select PXA_SSP
> select SHARPSL_PM
>
> config MACH_CORGI
> bool "Enable Sharp SL-C700 (Corgi) Support"
> depends on PXA_SHARPSL_25x
> select PXA_SHARP_C7xx
>
> and (lets say for the sake of argument) APM_EMULATION were to go away.
It will probably fail to build :-)
> Do we really need an exhaustive set of configuration combinations to
> run through Kconfig to find possible missing symbols? Or do we need a
> Kconfig lint to find them?
Now let's say PXA_SHARPSL_25x goes away (or someone made a typo
in her `depends on')...
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [EMAIL PROTECTED]
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc2 built on ppc (3)
Hi, FYI, building the kernel with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... fs/partitions/check.c: In function 'add_partition': fs/partitions/check.c:392: warning: ignoring return value of 'kobject_add', declared with attribute warn_unused_result fs/partitions/check.c:395: warning: ignoring return value of 'sysfs_create_link', declared with attribute warn_unused_result fs/partitions/check.c:403: warning: ignoring return value of 'sysfs_create_file', declared with attribute warn_unused_result ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
Re: [5/5] 2.6.22-rc2: known regressions
Stephen Hemminger <[EMAIL PROTECTED]> wrote:
>
> Looks more like the IPV6 SNMP6 OOPS, I saw and fixed with:
>
> commit 5632c5152aa621885d87ea0b8fdd5a6bb9f69c6f
> Author: Stephen Hemminger <[EMAIL PROTECTED]>
> Date: Sat Apr 28 21:16:39 2007 -0700
>
>[IPV6]: Track device renames in snmp6.
>
>When network device's are renamed, the IPV6 snmp6 code
>gets confused. It doesn't track name changes so it will OOPS
>when network device's are removed.
>
>The fix is trivial, just unregister/re-register in notify handler.
>
>Signed-off-by: Stephen Hemminger <[EMAIL PROTECTED]>
>Signed-off-by: David S. Miller <[EMAIL PROTECTED]>
It's quite possible that this fixes it, especially since the version
in Ubuntu's bug report came out the day before your fix went in :)
However, I don't really get why it's crashing in the first place.
Without your patch, if the device is renamed the proc entry just
keeps the original name. When it goes down it should still get
removed correctly.
Could you explain this in a bit more detail?
Thanks,
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~} <[EMAIL PROTECTED]>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: signals logged / [RFC] log out-of-virtual-memory events
> I do not see such on i386, so why for x86_64?
> >>>So that you know that one of your programs crashed. That's a feature.
> >>This feature could be handy for i386 too.
> >Since 2.6.18.2 I use this patch. With 2.6.21.1 it still applies altough
> >with a small offsets. Works like a charm.
> >
> >Signed-off by: Folkert van Heusden <[EMAIL PROTECTED]>
> >--- linux-2.6.18.2/kernel/signal.c 2006-11-04 02:33:58.0 +0100
> >+++ linux-2.6.18.2.new/kernel/signal.c 2006-11-17 15:59:13.0 +0100
...
> >+ sig, t -> pid, t -> uid, t -> gid, t -> comm);
>
> Please check line 219 of Documentation/CodingStyle, Section 3.1: Spaces
> and no space around the '.' and "->" structure member operators.
New version without the spaces around '->' and a nice 'unlikely' added.
Signed-off by: Folkert van Heusden <[EMAIL PROTECTED]>
--- linux-2.6.18.2/kernel/signal.c 2006-11-04 02:33:58.0 +0100
+++ linux-2.6.18.2.new/kernel/signal.c 2006-11-17 15:59:13.0 +0100
@@ -706,6 +706,15 @@
struct sigqueue * q = NULL;
int ret = 0;
+ if (unlikely(sig == SIGQUIT || sig == SIGILL || sig == SIGTRAP ||
+ sig == SIGABRT || sig == SIGBUS || sig == SIGFPE ||
+ sig == SIGSEGV || sig == SIGXCPU || sig == SIGXFSZ ||
+ sig == SIGSYS || sig == SIGSTKFLT))
+ {
+ printk(KERN_WARNING "Sig %d send to %d owned by %d.%d (%s)\n",
+ sig, t->pid, t->uid, t->gid, t->comm);
+ }
+
/*
* fast-pathed signals for kernel-internal things like SIGSTOP
* or SIGKILL.
Folkert van Heusden
--
MultiTail cok yonlu kullanimli bir program, loglari okumak, verilen
kommandolari yerine getirebilen. Filter, renk verme, merge, 'diff-
view', vs. http://www.vanheusden.com/multitail/
--
Phone: +31-6-41278122, PGP-key: 1F28D8AE, www.vanheusden.com
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc2 built on ppc (4)
Hi, FYI, building the kernel with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... drivers/video/aty/radeon_base.c: In function 'radeonfb_pci_register': drivers/video/aty/radeon_base.c:2326: warning: ignoring return value of 'sysfs_create_bin_file', declared with attribute warn_unused_result drivers/video/aty/radeon_base.c:2328: warning: ignoring return value of 'sysfs_create_bin_file', declared with attribute warn_unused_result ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
Re: RFC: kconfig select warnings bogus?
On Sun, 20 May 2007, Stefan Richter wrote: > Trent Piepho wrote: > > config ATARI_KBD_CORE > > bool > > default y if KEYBOARD_ATARI > > default y if MOUSE_ATARI > > > > Basically a line "config A \n select B" is transformed into "config B \n > > default y if A". It's the same number of lines, they're just in a new > > place. > > Basically you replace > > A... depends on B > > by > > B... serves A > > The latter variant is a pain to maintain. Dependencies change over > time, therefore we should note the dependency always at the dependent > option, not at the serving option. The problem is that "B" will not exist on some architectures. If you put the dependency with "A", the dependency still exists when "B" is gone. If the dependency is with "B", it nicely goes away when "B" is gone. > Iterating upwards and downwards the dependency graph is the duty of > "make snafuconfig", not of the maintainers. > > Besides, the "serves" form cannot stand in for constructs like > > A... depends on (B && C) || D This is for replacing "select" lines, which can't look like that. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc2 built on ppc (5)
Hi, FYI, building the kernel with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_start (offset 0x8) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_end (offset 0xc) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_entry (offset 0x10) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom (offset 0x40) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from of_platform (offset 0x54) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from mem_reserve_cnt (offset 0x5c) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from mem_reserve_map (offset 0x64) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from alloc_bottom (offset 0x68) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from ram_top (offset 0x6c) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from alloc_top (offset 0x74) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_scratch (offset 0x90) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_header_start (offset 0xc0) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_struct_start (offset 0xc8) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_struct_end (offset 0xd0) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from of_stdout_device (offset 0x120) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_initrd_start (offset 0x150) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_initrd_end (offset 0x154) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from prom_cmd_line (offset 0x160) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from regbuf (offset 0x17c) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from rmo_top (offset 0x184) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from alloc_top_high (offset 0x18c) WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from disp_BAT (offset 0x25c) WARNING: arch/powerpc/mm/built-in.o - Section mismatch: reference to .init.text:early_get_page from .text between 'pte_alloc_one_kernel' (at offset 0x13e8) and 'v_mapped_by_bats' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0xd74e) and 'chrp_pci_fixup_winbond_ata' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:mv643xx_eth_pd_devs from .text between 'mv643xx_eth_add_pds' (at offset 0xd752) and 'chrp_pci_fixup_winbond_ata' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:note_scsi_host from __ksymtab between '__ksymtab_note_scsi_host' (at offset 0x8) and '__ksymtab_sys_ctrler' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from (offset 0x0) WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from bootx_dt_strend (offset 0x4) WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from bootx_node_chosen (offset 0x30) WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from bootx_info (offset 0x34) WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.data:.got2 from bootx_disp_path (offset 0x40) WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:pmac_probe from .machine.desc between 'mach_powermac' (at offset 0x4) and 'mach_chrp' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:pmac_setup_arch from .machine.desc between 'mach_powermac' (at offset 0x8) and 'mach_chrp' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:pmac_init_early from .machine.desc between 'mach_powermac' (at offset 0xc) and 'mach_chrp' WARNING: arch/powerpc/platforms/built-in.o - Section mismatch: reference to .init.text:pmac_pic_init from .machine.desc between 'mach_powermac' (at offset 0x18) and 'mach_chrp' WARNING: arch/powerpc/platforms/built-in.o -
Who is currently usb.ids maintainer?
Hi guys, can anybody help me find current usb.ids maintainer? David Brownell is not responding and latest official version is 5 mounths old. I could take ownership if nobody takes care. Thanks for reply Michal - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
2.6.22-rc2 built on ppc
Hi, FYI, building the kernel modules with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... fs/udf/balloc.c: In function 'udf_table_new_block': fs/udf/balloc.c:747: warning: 'goal_eloc.logicalBlockNum' may be used uninitialized in this function fs/udf/super.c: In function 'udf_fill_super': fs/udf/super.c:1359: warning: 'ino.partitionReferenceNum' may be used uninitialized in this function ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
Re: [PATCH] ubi: kill homegrown endian macros
On Sat, 2007-05-19 at 14:24 +0200, Segher Boessenkool wrote: > >> It's not the compiler who decides -- struct layout is > >> dictated by the ABI you're compiling for. > > > > This is true in the case of externally-visible stuff. I think the > > compiler is permitted to violate the ABI for purely unit-internal > > things > > if it makes sense though, isn't it? > > Sure. It isn't "violating the ABI" in that case though, > to be perfectly clear. Of course. It's not conforming to the ABI because there's no need to. > > The rule stands -- empirical testing of what the compiler will do isn't > > usually the right answer. > > It is *never* the right answer. You should always write > your code so that it will do the right thing no matter > what the compiler decides to do to it. Well, there's sometimes some benefit in _also_ checking that the output of the compiler matches your expectations. :) -- dwmw2 - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: libata and legacy ide pcmcia failure
1. Please apply timing-debug.patch on 2.6.22rc1-git5 or later and report
the log with timestamp as before. Let's see why the timeout has doubled.
2. Does the attached disable-dev_init_params.patch fix your problem?
--
tejun
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d5939e6..6e98c85 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1695,8 +1695,10 @@ int ata_dev_read_id(struct ata_device *d
*/
tf.flags |= ATA_TFLAG_POLLING;
+ ata_dev_printk(dev, KERN_INFO, "issuing IDENTIFY\n");
err_mask = ata_exec_internal(dev, &tf, NULL, DMA_FROM_DEVICE,
id, sizeof(id[0]) * ATA_ID_WORDS);
+ ata_dev_printk(dev, KERN_INFO, "IDENTIFY complete\n");
if (err_mask) {
if (err_mask & AC_ERR_NODEV_HINT) {
DPRINTK("ata%u.%d: NODEV after polling detection\n",
@@ -1779,7 +1781,9 @@ int ata_dev_read_id(struct ata_device *d
* Some drives were very specific about that exact sequence.
*/
if (ata_id_major_version(id) < 4 || !ata_id_has_lba(id)) {
+ ata_dev_printk(dev, KERN_INFO, "issuing DEV_INIT_PARAMS\n");
err_mask = ata_dev_init_params(dev, id[3], id[6]);
+ ata_dev_printk(dev, KERN_INFO, "DEV_INIT_PARAMS complete\n");
if (err_mask) {
rc = -EIO;
reason = "INIT_DEV_PARAMS failed";
@@ -6369,7 +6373,7 @@ int ata_host_register(struct ata_host *h
ehi->probe_mask = (1 << ATA_MAX_DEVICES) - 1;
ehi->action |= ATA_EH_SOFTRESET;
- ehi->flags |= ATA_EHI_NO_AUTOPSY | ATA_EHI_QUIET;
+ ehi->flags |= ATA_EHI_NO_AUTOPSY/* | ATA_EHI_QUIET*/;
ap->pflags &= ~ATA_PFLAG_INITIALIZING;
ap->pflags |= ATA_PFLAG_LOADING;
diff --git a/drivers/ata/libata-eh.c b/drivers/ata/libata-eh.c
index 5309c31..99b573e 100644
--- a/drivers/ata/libata-eh.c
+++ b/drivers/ata/libata-eh.c
@@ -1980,6 +1980,7 @@ static int ata_eh_recover(struct ata_por
"reset failed, giving up\n");
goto out;
}
+ ata_port_printk(ap, KERN_INFO, "reset complete\n");
ata_eh_thaw_port(ap);
}
diff --git a/drivers/ata/libata-core.c b/drivers/ata/libata-core.c
index d5939e6..25677f4 100644
--- a/drivers/ata/libata-core.c
+++ b/drivers/ata/libata-core.c
@@ -1769,6 +1769,7 @@ int ata_dev_read_id(struct ata_device *d
goto retry;
}
+#if 0
if ((flags & ATA_READID_POSTRESET) && class == ATA_DEV_ATA) {
/*
* The exact sequence expected by certain pre-ATA4 drives is:
@@ -1793,6 +1794,7 @@ int ata_dev_read_id(struct ata_device *d
goto retry;
}
}
+#endif
*p_class = class;
2.6.22-rc2 built on ppc (1)
Hi, FYI, building 2.6.22-rc2 with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... arch/powerpc/kernel/pci_32.c: In function 'pcibios_assign_resources': arch/powerpc/kernel/pci_32.c:562: warning: ignoring return value of 'pci_assign_resource', declared with attribute warn_unused_result arch/powerpc/kernel/pci_32.c: In function 'pcibios_add_platform_entries': arch/powerpc/kernel/pci_32.c:1053: warning: ignoring return value of 'device_create_file', declared with attribute warn_unused_result arch/powerpc/mm/mem.c: In function 'paging_init': arch/powerpc/mm/mem.c:313: warning: passing argument 1 of 'pmd_offset' from incompatible pointer type arch/powerpc/mm/mem.c:316: warning: passing argument 1 of 'pmd_offset' from incompatible pointer type ... drivers/base/core.c: In function 'device_add': drivers/base/core.c:714: warning: ignoring return value of 'sysfs_create_link', declared with attribute warn_unused_result drivers/base/core.c:719: warning: ignoring return value of 'sysfs_create_link', declared with attribute warn_unused_result drivers/base/core.c:722: warning: ignoring return value of 'sysfs_create_link', declared with attribute warn_unused_result drivers/base/core.c: In function 'device_rename': drivers/base/core.c:1197: warning: ignoring return value of 'sysfs_create_link', declared with attribute warn_unused_result drivers/base/dd.c:211: warning: 'device_probe_drivers' defined but not used ... drivers/ide/setup-pci.c: In function 'ide_scan_pcibus': drivers/ide/setup-pci.c:879: warning: ignoring return value of '__pci_register_driver', declared with attribute warn_unused_result drivers/pci/search.c: In function 'pci_find_slot': drivers/pci/search.c:99: warning: 'pci_find_device' is deprecated (declared at include/linux/pci.h:477) drivers/pci/search.c: At top level: drivers/pci/search.c:433: warning: 'pci_find_device' is deprecated (declared at drivers/pci/search.c:241) drivers/pci/search.c:433: warning: 'pci_find_device' is deprecated (declared at drivers/pci/search.c:241) ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
2.6.22-rc2 built on ppc (2)
Hi, FYI, building 2.6.22-rc2 with gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) on my powerbook (PPC) gives: ... kernel/time/ntp.c: In function 'do_adjtimex': kernel/time/ntp.c:307: warning: comparison of distinct pointer types lacks a cast kernel/time/ntp.c:310: warning: comparison of distinct pointer types lacks a cast ... If more info is needed, please contact me via PM, as I am not subscribed. Thanks for your patience Elimar -- Never make anything simple and efficient when a way can be found to make it complex and wonderful ;-) signature.asc Description: Digital signature
Re: RFC: kconfig select warnings bogus?
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > You'll learn about the "default .. if .." Kconfig idiom after you try > this, I have seen these in the rest of the patch which I didn't quote. However you fix it --- don't remove "depends on" or "select". You can interchange them, but not remove them, unless there wasn't a dependency to begin with. They _can_ be removed, with absolutely no build failures at all, because of the "default y if ..." on the dependency that is defined in some arch/.../Kconfig. In fact the whole _idea_ is to remove any mention of the arch-specific dependency from arch-agnostic stuff in drivers/.../Kconfig's (be it "depends" or "select") so as not to generate those "unknown symbols" warnings that would come on other archs. Hence, the normal practice to use the "default y if ..." idiom (for "bool" helper code like the original examples on this thread) in arch/.../Kconfig files. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [RFC] LZO1X de/compression support
Bill Rugolsky Jr. wrote: I'm certainly missing something but what are the advantages of this code (over current gzip etc.), and what will be using it? Richard's patchset added it to the crypto library and wired it into the JFFS2 file system. We recently started using LZO in a userland UDP proxy to do stateless per-packet payload compression over a WAN link. With ~1000 octet packets, our particular data stream sees 60% compression with zlib, and 50% compression with (mini-)LZO, but LZO runs at ~5.6x the speed of zlib. IIRC, that translates into > 700Mbps on the input side on a 2GHZ Opteron, without any further tuning. Once LZO is in the kernel, I'd like to see it wired into IPComp. Unfortunately, last I checked only the "deflate" algorithm had an assigned compression parameter index (CPI), so one will have to use a private index until an official one is assigned. I also though of using LZO compression for some of the diskless nodes which use iSCSI over 100 Mbit or slower. Certainly, a fast de/compression algorithm in the kernel could bring some new, innovative uses: - there are talks about compressed filesystems (jffs2, reiser4, LogFS) - why no one thought about a compressed tmpfs (should be way easier than a compressed on-disk filesystem, as we don't have to care about data recovery in event of a failure)? - using compression for networking (like Bill mentioned) - compressed caching - compressed suspend-to-disk images (should suspend/restore faster this way) -- Tomasz Chmielewski http://wpkg.org - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Trent Piepho wrote: > On Sun, 20 May 2007, Stefan Richter wrote: >> Basically you replace >> >> A... depends on B >> >> by >> >> B... serves A >> >> The latter variant is a pain to maintain. Dependencies change over >> time, therefore we should note the dependency always at the dependent >> option, not at the serving option. > > The problem is that "B" will not exist on some architectures. If you put the > dependency with "A", the dependency still exists when "B" is gone. If the > dependency is with "B", it nicely goes away when "B" is gone. If "make whateverconfig" works correctly,... >> Iterating upwards and downwards the dependency graph is the duty of >> "make snafuconfig", not of the maintainers. ...multi-level dependencies are no problem for it. There is nothing wrong with A... depends on B B... depends on C # CONFIG_C is not set -> A is unavailable. -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> However you fix it --- don't remove "depends on" or "select". You can >> interchange them, but not remove them, unless there wasn't a dependency >> to begin with. > > They _can_ be removed, with absolutely no build failures at all, because > of the "default y if ..." on the dependency that is defined in some > arch/.../Kconfig. You are right, they can be removed, and the Kconfig files can be turned into an unmaintainable mess. A requires B Maintainable. B serves A Logically equivalent, yet unmaintainable. -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: no DRQ after issuing MULTWRITE_EXT AND PCI: Bus #0b (-#0e) is hidden behind transparent bridge #0a (-#0a) (try 'pci=assign-busses')
Tjenarvi Tjenarvi wrote: > These dmesg if not as Tejun said, Which he said should only libata > drivers used to get more information. Frankly, I don't know which one I > have to take off in kernel configuration to comply this. I guess the > libata is in: > > Device Drivers ---> > SCSI device support ---> > > But, don't know which one to take off, so that only libata driver > compiled. Please tell me. Please turn off Device Drivers -> ATA/ATAPi/MFM/RLL support. I'm not sure which ide driver is grabbing the first port. Can you post the original .config? > The machine seems nothing wrong whether I used "pci=assign-busses" or > not. But, I found another message that I don't understand in the dmesg > whether I use "pci=assign-busses" or not, the message still occur, I > don't know this is related or not. The message is "PCI: If a device > doesn't work, try "pci=routeirq". If it helps, post a report". Should > I try this kernel option? I don't think you need to pay attention to the message. -- tejun - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> However you fix it --- don't remove "depends on" or "select". You can >> interchange them, but not remove them, unless there wasn't a dependency >> to begin with. > > They _can_ be removed, with absolutely no build failures at all, because > of the "default y if ..." on the dependency that is defined in some > arch/.../Kconfig. You are right, they can be removed, and the Kconfig files can be turned into an unmaintainable mess. A requires B Maintainable. B serves A Logically equivalent, yet unmaintainable. Well, whether it is readable / maintainable is subjective and hence debatable. I was only answering your *completely misplaced and incorrect* original comment against the patch where you claimed that the patch was "totally wrong" because of the way it removed the "select" ... etc ... And remember, like I said already, the whole _idea_ is such arch- specific helper code be not mentioned from arch-agnostic Kconfig files. You may not like it, but this is the standard / most common way such cases are handled for tons of other cases in arch/ Which is why Adrian's way of solving this (shifting all such arch-specific helper symbols also to drivers/... and then using depends on select on it) is not viable. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] wistron_btns: reduce polling frequency (to save power)
Hello,
I'm usually not a fashion victim, but I felt into the trap this time:
I've launched powertop. As I noticed that wistron_btns was part of the
topers (10 wake-up's per seconds), here is a patch that should reduce
the problem. The driver now polls the hardware only twice per second.
Actually, I've tried to decrease the timer to 1 Hz, using round_jiffies
it would have been an even bigger win, but latency was just too big from
a user point of view. It's pity, there doesn't seem to be any API to
synchronize a 2 Hz timer with the rounded timers :-(
It should apply against 2.6.22-rc2 (as well as input tree). It's
completely orthogonal to my previous patch "add led support", so you can
apply both in the order you like ;-) There is no particular urgency in
this patch, so I guess you can keep it for 2.6.23.
See you,
Eric
From: Eric Piel <[EMAIL PROTECTED]>
wriston_btns: Reduce polling frequency
Reduces the polling frequency from 10 Hz to 2 Hz, which should be less a burden
for laptops wrt energy saving. As it is multimedia keys, 500ms (maximum) of
latency should be still fine for the user. In order to keep fluent the feeling
when the user is pressing several keys in a raw (such as changing the volume),
the frequency is increased for a short duration after a key is pressed.
Signed-off-by: Eric Piel <[EMAIL PROTECTED]>
--- linux-2.6.21/drivers/input/misc/wistron_btns.c.bak 2007-05-18 00:37:42.0 +0200
+++ linux-2.6.21/drivers/input/misc/wistron_btns.c 2007-05-18 00:36:44.0 +0200
@@ -22,6 +22,7 @@
#include
#include
#include
+#include
#include
#include
#include
@@ -37,9 +38,10 @@
*/
#define MAX_POLL_ITERATIONS 64
-#define POLL_FREQUENCY 10 /* Number of polls per second */
+#define POLL_FREQUENCY 2 /* Number of polls per second when idle */
+#define POLL_FREQUENCY_BURST 10 /* Polls per second when a key was recently pressed */
-#if POLL_FREQUENCY > HZ
+#if POLL_FREQUENCY_BURST > HZ
#error "POLL_FREQUENCY too high"
#endif
@@ -1079,6 +1081,8 @@ static void handle_key(u8 code)
static void poll_bios(unsigned long discard)
{
+ static unsigned long jiffies_last_press;
+ unsigned long jiffies_now = jiffies;
u8 qlen;
u16 val;
@@ -1087,11 +1091,17 @@ static void poll_bios(unsigned long disc
if (qlen == 0)
break;
val = bios_pop_queue();
- if (val != 0 && !discard)
+ if (val != 0 && !discard) {
handle_key((u8)val);
+ jiffies_last_press = jiffies_now;
+ }
}
- mod_timer(&poll_timer, jiffies + HZ / POLL_FREQUENCY);
+ /* Increase precision if user is currently pressing keys (< 2s ago) */
+ if (time_after(jiffies_last_press, jiffies_now - (HZ * 2)))
+ mod_timer(&poll_timer, jiffies_now + HZ / POLL_FREQUENCY_BURST);
+ else
+ mod_timer(&poll_timer, jiffies_now + HZ / POLL_FREQUENCY);
}
static int __devinit wistron_probe(struct platform_device *dev)
Re: [PATCH] UDF: check for allocated memory for inode data
[Christoph Hellwig - Wed, May 16, 2007 at 06:56:00PM +0100] | On Wed, May 16, 2007 at 09:52:57PM +0400, Cyrill Gorcunov wrote: | > I've that documants even printed ;) Actually they are _very-very_ big | > indeed. I don't know may be just try to bring this code into Linux | > codying style? | | That's probably a good step. And while converting things to a proper | style you'll surely find various bugs and thinkgs you could improve. | Write them down somewhere and work on fixing them. And make sure every | actualy fix or behaviour change is a single patch separated from the | cleanups. | Hi Christoph, I almost have completed UDF style conversation (the only thing to do is to check all I've changed). And I've been striked down by the simple question: the conversion I've done is over 2.6.22-rc1 but meantime in -mm tree two my patches already exist so should I take them into account while converting UDF style? Cyrill - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc2 built on ppc (3)
On Sun, May 20, 2007 at 01:11:13PM +0200, Elimar Riesebieter wrote: >Hi, > >FYI, building the kernel with >gcc (GCC) 4.1.3 20070514 (prerelease) (Debian 4.1.2-7) >on my powerbook (PPC) gives: > >... >fs/partitions/check.c: In function 'add_partition': >fs/partitions/check.c:392: warning: ignoring return value of 'kobject_add', >declared with attribute warn_unused_result >fs/partitions/check.c:395: warning: ignoring return value of >'sysfs_create_link', declared with attribute warn_unused_result >fs/partitions/check.c:403: warning: ignoring return value of >'sysfs_create_file', declared with attribute warn_unused_result >... > >If more info is needed, please contact me via PM, as I am not >subscribed. > >Thanks for your patience >Elimar > I don't know why these warnings are still in kernel. We have fixed them yet. Could you please check and try this patch? http://marc.info/?l=linux-mm-commits&m=11762433536&w=2 CC: Andrew Morton <[EMAIL PROTECTED]> CC: Cornelia Huck <[EMAIL PROTECTED]> Regards! WANG Cong - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
something strange in libata-core.c for kernel 2.6.22-rc3
Mybe I am wrong, but if you are detecting 40-wire cable to set them to
DMA/33, why the check includes also 80-wire cables configuring them to
DMA/33 too?
With this patch my nvidia4 IDE controllers detects correctly and configure
correctly DMA/100 for my HD and DMA/33 for my DVD (the first uses a
80-wire cable, the second a 40-wire cable).
Am I wrong somewhere?
--- libata-core.c.orig 2007-05-20 14:31:25.0 +0200
+++ libata-core.c 2007-05-20 14:34:01.0 +0200
@@ -3901,8 +3901,7 @@
/* UDMA/44 or higher would be available */
if((ap->cbl == ATA_CBL_PATA40) ||
(ata_drive_40wire(dev->id) &&
-(ap->cbl == ATA_CBL_PATA_UNK ||
- ap->cbl == ATA_CBL_PATA80))) {
+(ap->cbl == ATA_CBL_PATA_UNK))) {
ata_dev_printk(dev, KERN_WARNING,
"limited to UDMA/33 due to 40-wire cable\n");
xfer_mask &= ~(0xF8 << ATA_SHIFT_UDMA);
regards
Luigi
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2: make -j makes it unresponsive
Hi, On Saturday, 19 May 2007 07:17, Linus Torvalds wrote: > > It's out there, both patches/tarballs and git trees are updated (although > mirroring might still be ongoing) > > Various random fixes all over - the shortlog (appended) is fairly > readable. The most notable ones are probably more SLUB fixes, and the > epoll optimizations and cleanups. > > But there's stuff in architectures (ia64, SH, AVR32, POWER), libata, > network drivers, sound.. Give it a try. > > I've been telling some people off on merging stuff, and I'll get even more > hard-nosed about it after -rc2, so please don't even try to send anything > but real fixes. > > I think the current situation looks reasonably good for 2.6.22, but I hope > everybody will take a good look at the regression lists (whether they > _think_ they are affected or not), and spend some time wondering "was that > anything I did, or is it something I can look at". Ok? Running 'make -j' kernel compilation on my test box (Athlon64 X2, 2 SATA drives with 6 software RAID1 ext3 and reiserfs partitions, 2 GB of RAM) makes it completely unresponsive. I can't even move the mouse pointer when it's running, I can't log to the box from the network etc. The anticipatory IO scheduler is used. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: radeonfb and X800 cards
Benjamin Herrenschmidt a écrit :
>> This is what I'm using here, it's still the same old patch (Solomon's
>> plus my stuff). I think I can coordinate with [EMAIL PROTECTED] to
>> create an incremental patch to fix radeonfb on his hardware (provided
>> that this mega-patch is suitable as baseline that is).
>
> Yes, I would very much appreciate if you guys managed to turn that into
> some incremental patch serie. That would make it much easier for me to
> review properly and track down possible regressions in fact.
>
> Ben.
>
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [EMAIL PROTECTED]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Hello,
i would be glad to help you to build an incremental patch.
Also, my goal was to make it possible to use the console radeon
framebuffer, to have a nice splash screen on a wide flat panel in its
native mode and to have it stay as much as possible compatible with xorg
dri and co. Also, it is working for me now.
Finally, i tried to modify/introduce as few codes as possible and make
it easier to X800 family card users to validate the patch, especially if
they use a flat panel connected to the dvi port without a vga
dongle/adaptator. If someone just tries it and tells if it works with
xorg without problem as it works for me, that would be great.
@Luca, if i remember well you have a X850, could you please try the
patch for me ?
The patch i introduced concerns the fact that my card doesn't handle
very well the dvi connector with the radeonfb kernel driver. The driver
just defaulted the connector to vga. However, the driver defines monid
but is never detected/used during auto detection. I just add it in
radeon_monitor.c. It seems pretty easy isn't it ;).
In fact, the code that made it possible to get something different than
a black screen, stays mostly in radeon_monitor.c:
@@ -552,6 +541,9 @@
#endif /* CONFIG_PPC_OF || CONFIG_SPARC */
#ifdef CONFIG_FB_RADEON_I2C
if (rinfo->mon1_type == MT_NONE)
+ rinfo->mon1_type = radeon_probe_i2c_connector(rinfo,
ddc_monid,
+
&rinfo->mon1_EDID);
+ if (rinfo->mon1_type == MT_NONE)
rinfo->mon1_type = radeon_probe_i2c_connector(rinfo,
ddc_dvi,
&rinfo->mon1_EDID);
if (rinfo->mon1_type == MT_NONE) {
@@ -643,7 +635,7 @@
Also, radeon_accel.c is important to get xorg work as well. In fact, you
will get FIFO errors in xorg and dri won't be able to be initialized, if
radeon_accel.c doesn't understand your card.
I tried the patch with an old agp 9700 radeon card with a dvi connector,
connected to a flat panel. The patch does nothing as expected and seems
rather harmless in that case.
It works great, with a "ATI Radeon X800XT (R423) 5D57 (PCIE)" (ChipID =
0x5d57).
you can apply aty-2.6.22.diff to a 2.6.22-rc1-mm1 kernel and 2.6.21
kernels as well.
(The patch needs to be applied directly in the drivers/video/aty directory)
Thank you for you great work and your interest in the radeon framebuffer
driver :).
Jj
--- radeon_accel.c.ori 2007-05-09 17:09:00.0 +0200
+++ radeon_accel.c 2007-05-09 18:59:25.0 +0200
@@ -203,9 +203,7 @@
host_path_cntl = INREG(HOST_PATH_CNTL);
rbbm_soft_reset = INREG(RBBM_SOFT_RESET);
- if (rinfo->family == CHIP_FAMILY_R300 ||
- rinfo->family == CHIP_FAMILY_R350 ||
- rinfo->family == CHIP_FAMILY_RV350) {
+ if (IS_R300_VARIANT(rinfo)) {
u32 tmp;
OUTREG(RBBM_SOFT_RESET, (rbbm_soft_reset |
@@ -241,9 +239,7 @@
INREG(HOST_PATH_CNTL);
OUTREG(HOST_PATH_CNTL, host_path_cntl);
- if (rinfo->family != CHIP_FAMILY_R300 ||
- rinfo->family != CHIP_FAMILY_R350 ||
- rinfo->family != CHIP_FAMILY_RV350)
+ if (IS_R300_VARIANT(rinfo))
OUTREG(RBBM_SOFT_RESET, rbbm_soft_reset);
OUTREG(CLOCK_CNTL_INDEX, clock_cntl_index);
@@ -254,16 +250,15 @@
{
unsigned long temp;
- /* disable 3D engine */
- OUTREG(RB3D_CNTL, 0);
-
radeonfb_engine_reset(rinfo);
radeon_fifo_wait (1);
- if ((rinfo->family != CHIP_FAMILY_R300) &&
- (rinfo->family != CHIP_FAMILY_R350) &&
- (rinfo->family != CHIP_FAMILY_RV350))
+ if (IS_R300_VARIANT(rinfo)) {
+ temp = INREG(RB2D_DSTCACHE_MODE);
+ OUTREG(RB2D_DSTCACHE_MODE, temp | (1<<17)); /* FIXME */
+ } else {
OUTREG(RB2D_DSTCACHE_MODE, 0);
+ }
radeon_fifo_wait (3);
/* We re-read MC_FB_LOCATION from card as it can have been
--- radeon_base.c.ori 2007-05-09 17:09:00.0 +0200
+++ radeon_base.c 2007-05-09 19:07:19.0 +0
Re: [rfc] increase struct page size?!
On Sunday 20 May 2007 06:10:16 Eric Dumazet wrote: > Christoph Lameter a écrit : > > On Sat, 19 May 2007, William Lee Irwin III wrote: > > > >> However, there are numerous optimizations and features made possible > >> with flag bits, which might as could be made cheap by padding struct > >> page up to the next highest power of 2 bytes with space for flag bits. > > > > Well the last time I tried to get this by Andi we became a bit concerned > > when we realized that the memory map would grow by 14% in size. Given > > that 4k page size challenged platforms have a huge amount of page structs > > that growth is significant. I think it would be fine to do it for IA64 > > with 16k page size but not for x86_64. > > This reminds me Andi attempted in the past to convert 'flags' to a 32 bits > field : > > http://marc.info/?l=linux-kernel&m=107903527523739&w=2 > > I wonder why this idea was not taken, saving 2MB per GB of memory is nice :) It made sense in 2.4, but in 2.6 it doesn't actually save any memory because there is no field to put into the freed padding. Besides with the scarcity of pageflags it might make sense to do "64 bit only" flags at some point. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2: make -j makes it unresponsive
"Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > Running 'make -j' kernel compilation on my test box (Athlon64 X2, 2 SATA > drives > with 6 software RAID1 ext3 and reiserfs partitions, 2 GB of RAM) makes it > completely unresponsive. I can't even move the mouse pointer when it's > running, I can't log to the box from the network etc. How many processes does it spawn? Try some sane limit. -- Krzysztof Halasa - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via C3: other flags possible ?
> C7 Esther: > Hmm, I expect the NX-Bit should be detected from linux during the > boot. The NX function bit seems to be at the same place where it's > located for other CPU. > Unfortunately I have no C7 hardware and I am too much a beginner > in kernel programming to prepare this "dry". > > May be a "senior kernel programmer" can easy check if the C7 runs > through the regular NX-function detection? If it's in CPUID (nx in /proc/cpuinfo flags) it should just work. NX also doesn't need to be handled in the early CPUID bits detection because the kernel can handle it not being there fine. Only bits who when missing cause the kernel to panic early or crash need to be tested there. -Andi - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Satyam Sharma wrote: > I was only answering your *completely misplaced and > incorrect* original comment against the patch where you claimed > that the patch was "totally wrong" because of the way it removed > the "select" ... etc ... I believe I have explained why I labeled it as totally wrong. > And remember, like I said already, the whole _idea_ is such arch- > specific helper code be not mentioned from arch-agnostic Kconfig > files. You may not like it, but this is the standard / most common way > such cases are handled for tons of other cases in arch/... The standard and maintainable way (for drivers at least) is config A bool-or-tristate "option A" depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X It is not a matter of me disliking something. It's a matter of that we can easily determine what A needs, but have a hard time to determine and maintain the dependencies in the reverse way. BTW, if A needs platform-specific helper N, then A is not platform-agnostic. If A is desired to be platform-agnostic, then either A has to be implemented independently of N or N has to be made available on all platforms. > Which is why Adrian's way of solving this (shifting all such > arch-specific helper symbols also to drivers/... and then using depends > on select on it) is not viable. I'm not advocating any specific fixes or pseudo-fixes. I'm advocating the notation of dependencies in the direction "A requires B". Since you mention "select": My opinion about the "select" dialect of "depends on" is that the UIs should be improved and "select" should be removed from the Kconfig language. What do we "select"? Typically we "select" an option on which /n/ other options depend on but which itself does depend on none or few options higher up. The UIs could be able to figure this out for themselves, or if necessary by a hint tacked onto library-type options. That is, instead of config A tristate "driver A" select L config B tristate "driver B" select L config L tristate "library L" write config A tristate "driver A" depends on L config B tristate "driver B" depends on L config L tristate "library L" hint THIS_IS_A_LIBRARY Now let UIs "make oldconfig", "make menuconfig", "make randconfig" deal with the hint or ignore the hint --- according to the purpose and usability requirements of the respective UI. The "hint THIS_IS_SOMETHING" isn't even necessary in many cases to detect roles of options, because their position in the dependency graph is already saying something about it. These things really should be shifted into the UIs as much as possible, because we can have a number of special-purpose UIs but we want all-purpose Kconfig files. -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Via C3/C7: other flags possible ?
Bit 20 in edx is set if NX is available for C7: eax in: 0x8001, eax = ebx = ecx = edx = 0010 ( from your posting "This kernel requires the following..." ) The official VIA Eden datasheet seems to be NDA. I have not found any official download link on the pages: http://www.via.com.tw/en/products/processors/c7/ The /c3/ pages contain the documentation for the C3 family. I do not think the NX feature can be switched on/off by regular registers. May be it helps to play around with the bios ? Load "default settings" => see how the NX flag acts. Load "optimized settings" => see how the NX flags acts. I suppose the bios developer had used one setting to test and work with the NX flag regular. Christian > If you read the other thread properly you'd see that the BIOS has an option > to enable or disable it... when enabled it shows up. PS: @Simon, sorry that I missed the other thread. Too much traffic and not enough time for me to read all. I suppose that's a fulltime job ;-) Claas Langbehn wrote: > Simon Arlott schrieb: >> On 19/05/07 23:36, Christian Volkmann wrote: >>> Christian Volkmann wrote: Claas asked for the NX flag for the Via C3 (?) processors in another thread. >> >> If you read the other thread properly you'd see that the BIOS has an >> option to enable or disable it... when enabled it shows up. > > Right, but my bios disables this after each boot-time :( > Therefore it would be great if the kernel would not care > about the BIOS and enable it anyway. > > This seems to be a severe bug in the BIOS, but VIA does not > deliver a new BIOS since months. :( > >> >> I can't reboot that box just to test cx8 detection (which is missing). >> > It works here. > > > > claas > - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [1/2] 2.6.22-rc2: known regressions with patches
Il Sun, May 20, 2007 at 12:06:42AM +0200, Michal Piotrowski ha scritto: > Hi all, > > Here is a list of some known regressions in 2.6.22-rc2 > with patches available. > > Cryptography > > Subject: cryptomgr oops > References : http://lkml.org/lkml/2007/5/14/283 > Submitter : Luca Tettamanti <[EMAIL PROTECTED]> > Handled-By : Herbert Xu <[EMAIL PROTECTED]> > Patch : http://lkml.org/lkml/2007/5/19/3 > Status : patch available Hello, I confirm that Herbert's patch fixes the OOPS. Luca -- Mi piace avere amici rispettabili; Mi piace essere il peggiore della compagnia. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: Linux 2.6.22-rc2: make -j makes it unresponsive
On Sunday, 20 May 2007 15:01, Krzysztof Halasa wrote: > "Rafael J. Wysocki" <[EMAIL PROTECTED]> writes: > > > Running 'make -j' kernel compilation on my test box (Athlon64 X2, 2 SATA > > drives > > with 6 software RAID1 ext3 and reiserfs partitions, 2 GB of RAM) makes it > > completely unresponsive. I can't even move the mouse pointer when it's > > running, I can't log to the box from the network etc. > > How many processes does it spawn? Try some sane limit. Do you think it works as a fork bomb? Well, it didn't work like that before, AFAIR, but then 2.6.21 also does it with the same settings, so sorry for the noise. Greetings, Rafael - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
On 5/20/07, Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote:
--- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> On Sun, 20 May 2007, Srihari Vijayaraghavan wrote:
>
> > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80
> > RIP [...] slab_sysfs_init+0x49/0x98
> > RSP [...]
> > kernel panic - not syncing: Attempted to kill init!
>
> sysfs? If you build without CONFIG_SLUB_DEBUG then SLUB will not use
> sysfs. You can switch that off in the embedded section.
Fair enough. Would you the section name it appears in 'menuconfig'?
I looked under 'Kernel hacking' section (where the slab debugging appears if
slab is turned on as 'Debug slab memory allocation') & in the 'General setup'
section also. I unable to figure out how to disable slub debugging :-(.
SLUB_DEBUG is both "bool if EMBEDDED" and "depends on SLUB", which
means just getting it to be visible in "menuconfig" is quite a challenge :-)
You first need to go into the choice where you pick the allocators ("Choose
allocator --->" which is the last option in General Setup), and then pick
SLUB as your allocator.
Then, from the General Setup again, turn on the "Configure standard
kernel features (for small systems) --->" just above the previous option
and then go into that menu. Now the option to disable SLUB_DEBUG
(which is y by default) becomes visible, so just deselect it to disable it.
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] libata: implement ata_wait_after_reset()
Hello Tejun, Thanks for your answers. On Sun, May 20, 2007 11:50, Tejun Heo wrote: > Indan Zupancic wrote: >>> 1. We dropped libata specific suspend/resume implementation in favor of >>> sd driven one. Unfortunately, the new implementation currently can't do >>> background spinup, so that's probably why you can feel the delay. We >>> need to figure out how to do background spinup with the new implementation. >> >> What are the advantages of that, except slower resume? ;-) > > The change was made primarily to make libata spin down disks properly on > power down and hibernate. I don't like the added delay either but it's > better than shortening the lifespan of harddisks. Ah, it fixes that "weird noise on shutdown" problem? Fair enough. > Making resuming > asynchronous is planned but we need more infrastructure to do that > properly. The previous implementation worked but it also might try to > spin up a lot of disks at once which can't be good for PSU. I'm not > sure yet how to do that properly with sd driving suspend/resume. Don't controllers support spread spin up of disks, to avoid the peak load? I think I saw something about that in the SiI 3512 spec I downloaded. So maybe something like a special spin up method which can be implemented by drivers, and if it isn't, the current start stop thing is used? >>> 2. To make reset finish in defined time, each reset try now has defined >>> deadlines. I was trying to be conservative so I chose 10sec for the >>> first try. >> >> Right. So to me it seems that failed, because the undefined reset time is >> just >> replaced with a fixed ad hoc sleep, which is longer than any undefined reset >> mechanism. So where did the advantage go? Better to go back to how it was, >> is my impression. Or make that deadline 10 seconds and after that give up, >> instead of the other way round. Or just move to async reset. > > Well, yeah, your case degraded for sure but a lot of hotplug or error > handling cases are now much better which often used to take more than 30 > secs in many cases. There are just a lot of cases and a lot of weird > devices. Aiming generally acceptable delay on most cases is of higher > priority than optimizing specific cases. What I meant is that the deadline isn't effective because if it can't be done within that time, it's just retried after 10 seconds or whatever, basically rendering the deadline useless. But now I understand that the retry is done in the background, and that it was just the sd_resume that caused everything to wait on it. > That said, the 10 sec delayed > retry you're seeing is primarily caused by incorrect interpretation of > 0xff status on sata_sil, so with that fixed, it shouldn't be too much of > a problem. True. >>> It's driven by timing table near the top of libata-eh.c, so >>> adjusting the table is easy and maybe we can be a bit more aggressive >>> with the first two tries. But if we solve #1, this shouldn't matter too >>> much. >> >> #2 seems totally unrelated to #1, as #1 is about spinup, and #2 about reset. >> Only relation is that #2 slows down #1 because #1 needs to wait on #2. > > Not that easy. Many drives don't respond to reset while they're > spinning up. Bugger. So it seems like a good idea to do the reset and spinup async together. Maybe a silly question, but why do we wait for the harddisk to show up? Maybe that makes a little bit of sense at bootup, but for resume from ram, where nothing is supposed to have changed, it seems a bit strange. Why not wait when something tries to access the harddisk or something? >>> I hope it's explained now. >> >> Almost. Explained is why we wait on the disk, but that's only the sd_resume >> part. >> It's still unclear why resume must wait till the reset is done. > > Port reset itself is asynchronous. The wait is solely from sd_resume. The whole resetting, or just the retry after 10 seconds? But it becomes clear now that you're right that the spinup problem is solved if sd_resume does background spin up. I wonder if sil_pci_device_resume() and sd_resume() know about each other... I'll disable sd_resume() and see how that goes. >>> Yeap, that should work. In most configurations, devices spin up >>> immediately after power is restored. sd_resume() just waits for the >>> device to be revalidated in such cases. >> >> And it kicks the disk into action. Why? Only thing it does is sending a >> START_STOP >> command. I assume that causes the disk to spin up. But for e.g. laptopmode I >> can >> imagine that's quite annoying. I think sd_resume() is totally unnecessary >> and can >> be removed, because it seems wrong to always force the harddisk to spin up, >> background spin up or not. > > Most ATA drives would spin up immediately when power is reapplied unless > configured otherwise and you can configure whether sd_resume issues > START_STOP or not by echoing to sysfs node > /sys/class/scsi_disk/h:c:
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
--- Srihari Vijayaraghavan <[EMAIL PROTECTED]> wrote: > --- Christoph Lameter <[EMAIL PROTECTED]> wrote: > > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote: > > > > > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80 > > > RIP [...] slab_sysfs_init+0x49/0x98 > > > RSP [...] > > > kernel panic - not syncing: Attempted to kill init! > > > > sysfs? If you build without CONFIG_SLUB_DEBUG then SLUB will not use > > sysfs. You can switch that off in the embedded section. > > Fair enough. Would you the section name it appears in 'menuconfig'? [Sorry for replying to my own email. I've made some progress since then, so here goes ...] Sorry for the noise. I've discovered it under "General setup - Configure standard kernel features (for small systems)". With no CONFIG_SLUB_DEBUG, things have slightly improved. No more panic. Good. Serial console is working. Good. But there is another problem: ... Freeing unused kernel memory: 308k freed BUG: spinlock bad magic on CPU#1, init/1 lock: 81011ec0a100, .magic: 8101, .owner: /-1, .owner_cpu: -1 Call Trace: [] _raw_spin_lock+0x22/0xf6 [] vma_adjust+0x219/0x454 [] vma_adjust+0x219/0x454 [] vma_merge+0x147/0x1f4 [] do_mmap_pgoff+0x414/0x7c7 [] _spin_unlock_irq+0x24/0x27 [] sys_mmap+0xe5/0x110 [] system_call+0x7e/0x83 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver ... PM: Adding info for No Bus:vcsa1 BUG: spinlock lockup on CPU#0, sh/385, 81011ca8ffc0 Call Trace: [] _raw_spin_lock+0xcf/0xf6 [] anon_vma_unlink+0x1c/0x68 [] anon_vma_unlink+0x1c/0x68 [] free_pgtables+0x69/0xc3 [] exit_mmap+0x91/0xeb [] mmput+0x45/0xb8 [] flush_old_exec+0x65f/0x941 [] vfs_read+0x13f/0x153 [] load_elf_binary+0x0/0x197f [] load_elf_binary+0x460/0x197f [] __alloc_pages+0x72/0x2d4 [] load_elf_binary+0x0/0x197f [] search_binary_handler+0xc4/0x25f [] do_execve+0x188/0x231 [] sys_execve+0x36/0x8a [] stub_execve+0x67/0xb0 It just simply hangs there. With slab all is well, of course. (If you want me to activate all kernel debugging options, do advise, I'm happy to do that. Nothing changed in ref to my .config from the past email save the CONFIG_SLUB_DEBUG is gone now.) The dmesg is attached for your reference. Thanks ___ How would you spend $50,000 to create a more sustainable environment in Australia? Go to Yahoo!7 Answers and share your idea. http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html Linux version 2.6.22-rc2-ahci-slub ([EMAIL PROTECTED]) (gcc version 4.1.2 20070502 (Red Hat 4.1.2-12)) #6 SMP Sun May 20 23:05:08 EST 2007 Command line: ro root=LABEL=/1234 console=ttyS0,115200 console=tty0 BIOS-provided physical RAM map: BIOS-e820: - 0009f000 (usable) BIOS-e820: 0009f000 - 000a (reserved) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - dfee (usable) BIOS-e820: dfee - dfee3000 (ACPI NVS) BIOS-e820: dfee3000 - dfef (ACPI data) BIOS-e820: dfef - dff0 (reserved) BIOS-e820: e000 - f000 (reserved) BIOS-e820: fec0 - 0001 (reserved) BIOS-e820: 0001 - 00012000 (usable) end_pfn_map = 1179648 DMI 2.4 present. ACPI: RSDP 000F8110, 0024 (r2 ATI ) ACPI: XSDT DFEE30C0, 0044 (r1 ATIASUSACPI 42302E31 AWRD0) ACPI: FACP DFEE83C0, 00F4 (r3 ATIASUSACPI 42302E31 AWRD0) ACPI: DSDT DFEE3240, 511E (r1 ATIASUSACPI 1000 MSFT 300) ACPI: FACS DFEE, 0040 ACPI: SSDT DFEE85C0, 02CC (r1 PTLTD POWERNOW1 LTP1) ACPI: MCFG DFEE8980, 003C (r1 ATIASUSACPI 42302E31 AWRD0) ACPI: APIC DFEE8500, 0068 (r1 ATIASUSACPI 42302E31 AWRD0) Scanning NUMA topology in Northbridge 24 No NUMA configuration found Faking a node at -00012000 Bootmem setup node 0 -00012000 Zone PFN ranges: DMA 0 -> 4096 DMA324096 -> 1048576 Normal1048576 -> 1179648 early_node_map[3] active PFN ranges 0:0 -> 159 0: 256 -> 917216 0: 1048576 -> 1179648 ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) ACPI: IOAPIC (id[0x02] address[0xfec0] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec0, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 low level) Setting APIC routing to flat Using ACPI (MADT) for SMP configuration information Allocating PCI resources starting at f100 (gap: f000
Re: [PROBLEM] 2.6.22-rc2 panics on x86-64 with slub
--- Satyam Sharma <[EMAIL PROTECTED]> wrote:
> On 5/20/07, Srihari Vijayaraghavan <[EMAIL PROTECTED]>
> wrote:
> > --- Christoph Lameter <[EMAIL PROTECTED]> wrote:
> > > On Sun, 20 May 2007, Srihari Vijayaraghavan wrote:
> > >
> > > > Code: 0f ob eb fe 48 8b 1b 48 8b 0x 0f 18 08 48 81 fb 60 cb 51 80
> > > > RIP [...] slab_sysfs_init+0x49/0x98
> > > > RSP [...]
> > > > kernel panic - not syncing: Attempted to kill init!
> > >
> > > sysfs? If you build without CONFIG_SLUB_DEBUG then SLUB will not use
> > > sysfs. You can switch that off in the embedded section.
> >
> > Fair enough. Would you the section name it appears in 'menuconfig'?
> >
> > I looked under 'Kernel hacking' section (where the slab debugging appears
> if
> > slab is turned on as 'Debug slab memory allocation') & in the 'General
> setup'
> > section also. I unable to figure out how to disable slub debugging :-(.
>
> SLUB_DEBUG is both "bool if EMBEDDED" and "depends on SLUB", which
> means just getting it to be visible in "menuconfig" is quite a challenge :-)
>
> You first need to go into the choice where you pick the allocators ("Choose
> allocator --->" which is the last option in General Setup), and then pick
> SLUB as your allocator.
>
> Then, from the General Setup again, turn on the "Configure standard
> kernel features (for small systems) --->" just above the previous option
> and then go into that menu. Now the option to disable SLUB_DEBUG
> (which is y by default) becomes visible, so just deselect it to disable it.
Thanks for that. I've just figured that out a few minutes ago :-). Was a
tricky one indeed. Then I captured and posted the current kernel bug report
while having slub just then.
Thanks
___
How would you spend $50,000 to create a more sustainable environment in
Australia? Go to Yahoo!7 Answers and share your idea.
http://advision.webevents.yahoo.com/aunz/lifestyle/answers/y7ans-babp_reg.html
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] sata_sil: Greatly improve DMA support
On Sun, May 20, 2007 12:19, Tejun Heo wrote: > Indan Zupancic wrote: >> On Sun, May 20, 2007 00:03, Jeff Garzik wrote: >>> Indan Zupancic wrote: This patch seems to work with my SiI 3512, though I don't notice any difference, neither a speedup, nor a slowdown. Hdparm gives the same speeds (-tT), and cp -a'ing kernel sources is abysmal slow in both cases, (need to look into that one) so I didn't really test it that well. >>> >>> It won't result in much of a speedup, except in situations where IOMMU >>> or other situation that causes you to run into the 64k boundary being an >>> issue -- generally only on huge transfers. >>> >>> A good measure is to dd(1) to/from the block device, rather than using a >>> filesystem. As has been shown on LKML, the filesystem can really slow >>> things down in some cases. >> >> I didn't really expect a speedup, it's more that I've no regression to >> report. >> >> I could benchmark the patch more thoroughly, but right now I'm more worried >> about the crawling cp I just discovered. Talking about filesystems slowing >> down >> things... >> >> Test: >> >> $ cp -a linux-2.6/ /tmp/ >> >> done on the same ext3 partition. linux-2.6 contains source and git repo only, >> I'm compiling stuff with O=../obj. >> >> $ vmstat 10 >> procs ---memory-- ---swap-- -io -system-- cpu >> r b swpd free buff cache si sobibo in cs us sy id wa >> 0 1 0 4168 3316 19570000 739 494 530 393 15 3 66 16 >> 0 3 4 4120 2040 19819600 14677 14111 1247 435 0 17 0 83 >> 0 1 4 3588 1444 19969600 8892 9472 1362 438 0 12 0 88 >> 1 0 4 3772 4228 19601200 764 454 1161 345 0 4 0 96 >> 0 1 4 3548 6156 19308800 793 851 1158 340 0 4 0 96 >> 0 1 4 3852 7608 18909600 798 523 1160 474 1 4 0 95 >> 1 1 4 3612 8684 18604800 1244 864 1178 430 2 5 0 93 >> 0 1 4 90660 9308 9639600 853 906 1244 578 7 6 0 87 >> 0 1 4 72280 9816 11236800 830 854 1278 429 12 5 0 83 >> 1 0 4 52488 10296 13056000 935 861 1178 418 1 6 0 94 >> 0 1 4 30500 10788 14977600 977 858 1178 371 0 6 0 94 >> 0 1 4 9792 11244 16785600 918 1394 1182 350 1 5 0 94 >> 0 1 4 4016 11216 17250400 1017 858 1181 382 1 6 0 94 >> 0 1 4 3660 11484 17148400 966 861 1182 410 1 6 0 94 >> >> It never finished, as I had no patience to copy about 900 Mb with this rate. >> >> As it's a git tree, I suppose it's heavily fragmented, but this is still >> rather >> pathetic. Should I blame cp, or is something else wrong? Any ideas how >> to figure this one out would be appreciated. Sorry for the off-topicness. > > Do things improve if you change the io scheduler to deadline? > > # echo deadline > /sys/block/sda/queue/scheduler I also tried noop, anticipatory, and now deadline, but it doesn't matter. > Also worth looking at is the following bug entry. > > http://bugzilla.kernel.org/show_bug.cgi?id=7372 > > There seems to be weird interaction among the scheduler / VM / IO. The > exact cause is still not verified. :-( I know, I posted a bugreport too, but for starvation with the anticipatory scheduler. Anyway, that bug seems unrelated to my case, as they have system unresponsiveness or other nastiness, while I only have a crawling cp, which I blame on weaknesses within ext3, a badly designed cp program and very fragmented filesystem. I just need to verify that, somehow. I'll try with older kernels later. Greetings, Indan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [SMP BUG] [clockevents: i386 drivers patch] introduces irqbalance-does-not-work-properly problem
On Sun, 2007-05-20 at 19:48 +0900, Komuro wrote: > The problem is CPU1 receives 38239 interrupt-16 > but CPU0 receives only 15 interrupt-16 > CPU0 should receive more interrupts. > >CPU0 CPU1 > 0: 85 0 IO-APIC-edge timer > 1: 0698 IO-APIC-edge i8042 > 6: 0 5 IO-APIC-edge floppy > 8: 0 1 IO-APIC-edge rtc > 9: 0 0 IO-APIC-fasteoi acpi > 12: 0114 IO-APIC-edge i8042 > 14:369 2281 IO-APIC-edge ide0 > 15: 0 24 IO-APIC-edge ide1 > 16: 15 38239 IO-APIC-fasteoi yenta, pcnet_cs <<< problem > 17: 0 0 IO-APIC-fasteoi yenta > NMI: 0 0 > LOC: 50548 50547 > ERR: 0 > MIS: 15503 And how exactly is this related to clock events ? tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [BUG] local_softirq_pending storm
On Sun, 2007-05-20 at 12:18 +0200, Heiko Carstens wrote: > > I work out a more complex debug patch and pester you to test once I'm > > done. > > I've also tons of 'NOHZ: local_softirq_pending 08' that disappear with > nohz=off. But I'm still running 2.6.21. Are there any patches that should > fix this? > Machine is a Lenovo T60p: > > i686 Intel(R) Core(TM)2 CPU T7600 @ 2.33GHz GenuineIntel GNU/Linux Hmm, that's a different problem than the 0x22 which shows up on hyperthreading enabled P4 systems. Are you using plip ? > Besides that I get a lot of clock skews on 'make headers_check', but > these are unrelated to nohz: > > CHECK include/asm/dasd.h > make[2]: warning: Clock skew detected. Your build may be incomplete. > make[2]: Warning: File `/dev/null' has modification time 5.1e+03 s in the > future Strange. tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: Satyam Sharma wrote: > I was only answering your *completely misplaced and > incorrect* original comment against the patch where you claimed > that the patch was "totally wrong" because of the way it removed > the "select" ... etc ... I believe I have explained why I labeled it as totally wrong. Because it is not "readable"? Umm, "*totally wrong*" is a pretty strong comment to make just because _you_ find something less readable / maintainable! Anyway, your initial post did give the impression that you weren't aware of the "default y if ..." mechanism at all, and so somehow thought the removal of select would cause some graver problems because somehow the "dependency on XYZ which was implied by select XYZ" had been lost by the removal of select ... etc. > And remember, like I said already, the whole _idea_ is such arch- > specific helper code be not mentioned from arch-agnostic Kconfig > files. You may not like it, but this is the standard / most common way > such cases are handled for tons of other cases in arch/... The standard and maintainable way (for drivers at least) is config A bool-or-tristate "option A" depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X ??? I didn't get this entry, can you give a solid example (you can consider the case at hand, MOUSE_ATARI and ATARI_KBD_CORE itself). Better still, if you really think that the above is a better way to solve the problem at hand, why don't you submit a patch instead? It is not a matter of me disliking something. It's a matter of that we can easily determine what A needs, but have a hard time to determine and maintain the dependencies in the reverse way. BTW, if A needs platform-specific helper N, then A is not platform-agnostic. If A is desired to be platform-agnostic, then either A has to be implemented independently of N or N has to be made available on all platforms. What you are suggesting is not practically possible / convenient. See, we _want_ MOUSE_ATARI to appear in the arch-agnostic area which is along with the other input devices and hence it is placed in drivers/input/Kconfig. However, it does depend on arch-specific helper code. This is a real issue, and we can't simply wish it away. > Which is why Adrian's way of solving this (shifting all such > arch-specific helper symbols also to drivers/... and then using depends > on select on it) is not viable. I'm not advocating any specific fixes or pseudo-fixes. I'm advocating the notation of dependencies in the direction "A requires B". See, if you really _still_ think this could / should be done some better way (which is more maintainable, does not cause build failures and also does not cause those bogus warnings to be printed etc etc), then please submit a patch instead. These things really should be shifted into the UIs as much as possible, because we can have a number of special-purpose UIs but we want all-purpose Kconfig files. Well, the shortcomings of Kconfig / build scripts that you mentioned are are somewhat valid indeed, but as I said, unless you or someone submits patches to clear up the above issues, we do need to solve problems within that framework itself, isn't it? Thanks, Satyam - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [realtime kernel 2.6.21-rt2 and up] Extremely slow bootup for x86_64
On Sun, 2007-05-20 at 14:25 +0200, Maarten Maathuis wrote: > When i try to boot a kernel higher than 2.6.21-rt1, it boots very > slowly. It takes minutes to even detect two cdrom players. I noticed > in the changelog: > > - x86/64 high-res timers and dynticks update (Thomas Gleixner) > > I included the .config from 2.6.21-rt1, which i ran make oldconfig on. > > I cannot provide any other information, since i estimate it will take > ages to bootup. Does the same problem show up with http://tglx.de/projects/hrtimers/2.6.22-rc2/linux-2.6.22-rc2-x86_64-highres-v1.patch tglx - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: sd_resume redundant? [was: [PATCH] libata: implement ata_wait_after_reset()]
On Sun, May 20, 2007 11:54, Tejun Heo wrote: > Indan Zupancic wrote: >> On Sat, May 19, 2007 21:04, Tejun Heo wrote: >>> Tejun Heo wrote: Yeah, if SCR registers are accessible, 0xff doesn't indicate the device isn't there, so the whole skip-0xff logic probably shouldn't apply in such cases, but we can also achieve pretty good result by just making the first reset tries a bit more aggressive. >>> So, here's the patch. >>> >>> Paul, can you please test this patch without the previous patch? Indan, >>> this should reduce the resume delay. Please test. But you'll still >>> feel some added delay compared to 2.6.20 due to the mentioned >>> suspend/resume change. >> >> This removed the COMRESET errors indeed, and with sd_resume() >> disabled everything is speedy again (2s or so. Still a desktop pc). >> I didn't try with sd_resume enabled. > > Can you try to measure with sd_resume in place? [2.173366] sd 0:0:0:0: [sda] Starting disk [2.475422] ata2: SATA link down (SStatus 0 SControl 310) [5.478403] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.481928] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485904] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.485913] ata1.00: configured for UDMA/100 [5.505109] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.505461] sd 0:0:0:0: [sda] Write Protect is off [5.505465] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.505612] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA ... [6.157259] Restarting tasks ... done. And with echo 0 > /sys/class/scsi_disk/0\:0\:0\:0/manage_start_stop: [2.476476] ata2: SATA link down (SStatus 0 SControl 310) ... [2.825479] Restarting tasks ... done. ... [5.022076] ata1: SATA link up 1.5 Gbps (SStatus 113 SControl 310) [5.025605] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028594] ata1.00: ata_hpa_resize 1: sectors = 234441648, hpa_sectors = 234441648 [5.028606] ata1.00: configured for UDMA/100 [5.028720] sd 0:0:0:0: [sda] 234441648 512-byte hardware sectors (120034 MB) [5.028767] sd 0:0:0:0: [sda] Write Protect is off [5.028773] sd 0:0:0:0: [sda] Mode Sense: 00 3a 00 00 [5.028831] sd 0:0:0:0: [sda] Write cache: enabled, read cache: enabled, doesn't support DPO or FUA So over all it takes half a second longer to detect the disk, but because everything waits on it, it takes more than three seconds longer to resume. Setting manage_start_stop to 0 fixes it and is good enough for me, I didn't notice anything bad yet because of the unmanaged stop. Implementing background spin up will fix it too. >> Everything seems to work fine without sd_resume(), so why is it needed? > > Because not all disks spin up without being told to do so and like it or > not spinning disks up on resume is the default behavior. As I wrote in > the other reply, it would be worthwhile to make it configurable. Not even after they receive a read command? Ugh. Greeting, Indan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [3/5] 2.6.22-rc2: known regressions
> > Subject: pata_via appears to incorrectly detects 40-pin cable > > References : http://lkml.org/lkml/2007/5/17/273 > > http://bugzilla.kernel.org/show_bug.cgi?id=8142 > > Submitter : Francis Russell <[EMAIL PROTECTED]> > > Status : Unknown > > Not really a regression. Alan seems to have a general fix and I think > we can also quirk the specific case. Fixed in my tree not a regression. I'll try and push some bits monday this included. Alan - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2o: destroy event queue only when drv->event is set
i2o_driver_register() initalizes event queue for driver
only when drv->event is set. So similarly the event queue
should be destroyed only when drv->event is set in the error path.
Otherwise destroy_workqueue() will called with NULL.
Cc: Markus Lidel <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
drivers/message/i2o/driver.c |8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
Index: 2.6-mm/drivers/message/i2o/driver.c
===
--- 2.6-mm.orig/drivers/message/i2o/driver.c
+++ 2.6-mm/drivers/message/i2o/driver.c
@@ -123,8 +123,12 @@ int i2o_driver_register(struct i2o_drive
}
rc = driver_register(&drv->driver);
- if (rc)
- destroy_workqueue(drv->event_queue);
+ if (rc) {
+ if (drv->event) {
+ destroy_workqueue(drv->event_queue);
+ drv->event_queue = NULL;
+ }
+ }
return rc;
};
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] i2o: fix notifiers when max_drivers is configured
Maxinum number of I2O drivers which could be registered is
configurable by max_drivers module parameter.
But the module parameter is ignored and default value (I2O_MAX_DRIVERS = 8)
is used in the loops to notify all registered drivers.
Cc: Markus Lidel <[EMAIL PROTECTED]>
Signed-off-by: Akinobu Mita <[EMAIL PROTECTED]>
---
drivers/message/i2o/driver.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
Index: 2.6-mm/drivers/message/i2o/driver.c
===
--- 2.6-mm.orig/drivers/message/i2o/driver.c
+++ 2.6-mm/drivers/message/i2o/driver.c
@@ -20,6 +20,7 @@
#include
#include
#include
+#include
#include "core.h"
#define OSM_NAME "i2o"
@@ -260,7 +261,7 @@ void i2o_driver_notify_controller_add_al
int i;
struct i2o_driver *drv;
- for (i = 0; i < I2O_MAX_DRIVERS; i++) {
+ for (i = 0; i < i2o_max_drivers; i++) {
drv = i2o_drivers[i];
if (drv)
@@ -280,7 +281,7 @@ void i2o_driver_notify_controller_remove
int i;
struct i2o_driver *drv;
- for (i = 0; i < I2O_MAX_DRIVERS; i++) {
+ for (i = 0; i < i2o_max_drivers; i++) {
drv = i2o_drivers[i];
if (drv)
@@ -299,7 +300,7 @@ void i2o_driver_notify_device_add_all(st
int i;
struct i2o_driver *drv;
- for (i = 0; i < I2O_MAX_DRIVERS; i++) {
+ for (i = 0; i < i2o_max_drivers; i++) {
drv = i2o_drivers[i];
if (drv)
@@ -318,7 +319,7 @@ void i2o_driver_notify_device_remove_all
int i;
struct i2o_driver *drv;
- for (i = 0; i < I2O_MAX_DRIVERS; i++) {
+ for (i = 0; i < i2o_max_drivers; i++) {
drv = i2o_drivers[i];
if (drv)
@@ -340,8 +341,7 @@ int __init i2o_driver_init(void)
spin_lock_init(&i2o_drivers_lock);
if ((i2o_max_drivers < 2) || (i2o_max_drivers > 64) ||
- ((i2o_max_drivers ^ (i2o_max_drivers - 1)) !=
-(2 * i2o_max_drivers - 1))) {
+ !is_power_of_2(i2o_max_drivers)) {
osm_warn("max_drivers set to %d, but must be >=2 and <= 64 and "
"a power of 2\n", i2o_max_drivers);
i2o_max_drivers = I2O_MAX_DRIVERS;
@@ -349,7 +349,7 @@ int __init i2o_driver_init(void)
osm_info("max drivers = %d\n", i2o_max_drivers);
i2o_drivers =
- kzalloc(i2o_max_drivers * sizeof(*i2o_drivers), GFP_KERNEL);
+ kcalloc(i2o_max_drivers, sizeof(*i2o_drivers), GFP_KERNEL);
if (!i2o_drivers)
return -ENOMEM;
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[PATCH] Fix "fs: convert core functions to zero_user_page"
The bug introduced by 01f2705daf5a36208e69d7cf95db9c330f843af6. It misses to convert the first argument, it should be "new_page". This became the cause of fatfs corruption. Cc: Nate Diller <[EMAIL PROTECTED]> Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]> --- fs/buffer.c |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff -puN fs/buffer.c~fix-zero_user_page-conversion fs/buffer.c --- linux-2.6/fs/buffer.c~fix-zero_user_page-conversion 2007-05-20 18:36:02.0 +0900 +++ linux-2.6-hirofumi/fs/buffer.c 2007-05-20 18:36:21.0 +0900 @@ -2109,7 +2109,7 @@ int cont_prepare_write(struct page *page PAGE_CACHE_SIZE, get_block); if (status) goto out_unmap; - zero_user_page(page, zerofrom, PAGE_CACHE_SIZE - zerofrom, + zero_user_page(new_page, zerofrom, PAGE_CACHE_SIZE - zerofrom, KM_USER0); generic_commit_write(NULL, new_page, zerofrom, PAGE_CACHE_SIZE); unlock_page(new_page); _ -- OGAWA Hirofumi <[EMAIL PROTECTED]> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] power: Fix sizeof(PAGE_SIZE) typo
Fix sizeof(PAGE_SIZE) typo. It should be just PAGE_SIZE for zeroing the
swsusp_header.
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
kernel/power/swap.c |2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff -puN kernel/power/swap.c~power-sizeof-page-size-fix kernel/power/swap.c
--- linux-2.6/kernel/power/swap.c~power-sizeof-page-size-fix2007-05-20
18:01:32.0 +0900
+++ linux-2.6-hirofumi/kernel/power/swap.c 2007-05-20 18:01:32.0
+0900
@@ -584,7 +584,7 @@ int swsusp_check(void)
resume_bdev = open_by_devnum(swsusp_resume_device, FMODE_READ);
if (!IS_ERR(resume_bdev)) {
set_blocksize(resume_bdev, PAGE_SIZE);
- memset(swsusp_header, 0, sizeof(PAGE_SIZE));
+ memset(swsusp_header, 0, PAGE_SIZE);
error = bio_read_page(swsusp_resume_block,
swsusp_header, NULL);
if (error)
_
--
OGAWA Hirofumi <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: RFC: kconfig select warnings bogus?
Satyam Sharma wrote: > On 5/20/07, Stefan Richter <[EMAIL PROTECTED]> wrote: >> config A >> bool-or-tristate "option A" >> depends on !PLATFORM_X || HELPER_N_ON_PLATFORM_X > > ??? I didn't get this entry, "A is available if N is there or if it's a platform other than X." That would be adequate if N is only present and required on platform X. > can you give a solid example Nothing exactly of this sort, but compare for example kernel/power/Kconfig: config SOFTWARE_SUSPEND bool "Software Suspend (Hibernation)" depends on PM && SWAP && (((X86 || PPC64_SWSUSP) && (!SMP || SUSPEND_SMP)) || ((FRV || PPC32) && !SMP)) Of course this could be written in a clearer fashion, for example as depends on PM depends on SWAP depends on (X86 && !SMP) || (X86 && SUSPEND_SMP) || (PPC64_SWSUSP && !SMP) || (PPC64_SWSUSP && SUSPEND_SMP) || (FRV && !SMP) || (PPC32 && !SMP) (Untested.) Anyway, the dependencies which we are looking at here should not (and partially even cannot) be declared in reverse. > (you can consider > the case at hand, MOUSE_ATARI and ATARI_KBD_CORE itself). Better > still, if you really think that the above is a better way to solve the > problem at hand, why don't you submit a patch instead? Because I am lazy and trust that the platform maintainers know best about the dependencies of MOUSE_ATARI. Could also be related to that I as an Amiga owner cannot really relate to Atari. ;-) Could also have something to do with my being busy enough fixing bugs in the drivers I am familiar with. (Granted, I should shut up, ignore how Kconfig is more and more turned into a mess, and concentrate on my primary business.) -- Stefan Richter -=-=-=== -=-= =-=-- http://arcgraph.de/sr/ - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
Am Sonntag, 20. Mai 2007 08:58 schrieben Sie: > On Sunday 20 May 2007, Al Viro wrote: > > On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: > > > Ken? Ball's in your court. As the patch isn't providing a killer > > > feature for 2.6.22, I'd suggest just reverting it for now until the > > > issues are ironed out. > > > > Hold it. The real question here is which logics do we want there. > > IOW, and how many device nodes do we want to appear and _when_ do > > we want them to appear? > > of course we'd like to use exactly as many (or few) nodes as are in use > right now and without fixed limit for their number; which implies that > nodes should appear and go on as needed basis. > > But right now there is no kernel mechanism that user level program could > use to request allocation of new loop node. I won't discuss whether it is > legitimate to mandate new version of util-linux for kernel 2.6.22; but it > is obvious that any kernel patch that adds such mechanism goes far beyond > simple bug fix and is not acceptable at this stage. > > So let's revert this change and discuss it for post-2.6.22 timeframe. Hi, I am of course not a fan of limiting the maximum of available loops to 8. My question / proposal for now would be: Could anybody of you please be kind enough and write / provide me a counter patch supplying me: a. a compilable 2.6.22-rc2 kernel b. a loop device that can mount up to 8 iso-images I would prefer this thing as outline attachment due to Email client wordwrapping problems. Looking happily forward to a functionable counter patch to resolve the current issue as a compromise solution, Best regards and thanks Uwe - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH 2.6.21-rt2] PowerPC: decrementer clockevent driver
Benjamin Herrenschmidt wrote: > On Sat, 2007-05-19 at 19:43 -0700, Daniel Walker wrote: > >> In terms of clocksources, gettimeofday() would have to switch to another >> clocksource if the decrementer started to act that way .. That's why it >> is possible to register more than one clocksource, to allow for the >> switching. The decrementer frequency doesn't change even with cpufreq? > > It's more than just gettimeofday. The linux ppc kernel port has strong > assumptions all over the place that the timbase and decrementer (which > always tick at the same rate) have a constant frequency. It might be > possible to "fix" those assumptions but right now, that is the case. > > For example, nowadays, udelay() also uses the timebase. Not only > gettimeofday() & friends. The scheduler ticking too. The precise process > accounting as well, etc... So.. if we get enough clocksources into the tree, can any of those parts of the code be reworked to use clocksources/clockevents and hrtimers quickly and easily? I noticed the patch just posted does some of it.. but not as much as Ben just mentioned. Or is it a development nightmare? I'm fairly sure on a PPC970 box even though the decrementer is monotonic and never changes frequency, one day it just might, and it would be better to anticipate this (and allow people to distribute their timing requirements across an entire system and not just the CPU core anyway, which I think is probably a good thing from a system integration and possibly the point of view of redundancy..) -- Matt Sealey <[EMAIL PROTECTED]> Genesi, Manager, Developer Relations - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
[PATCH] fat: gcc 4.3 warning fix
This patch fixes the following warnings.
fs/fat/dir.c: In function 'fat_parse_long':
include/linux/msdos_fs.h:294: warning: array subscript is above array bounds
include/linux/msdos_fs.h:295: warning: array subscript is above array bounds
include/linux/msdos_fs.h:295: warning: array subscript is above array bounds
The ->name is defined as "name[8], ext[3]", but fat_checksum() uses
those as name[11]. There is no actual problem, but it's not a good manner.
Signed-off-by: OGAWA Hirofumi <[EMAIL PROTECTED]>
---
fs/fat/dir.c | 31 ++-
fs/fat/inode.c |3 +--
include/linux/msdos_fs.h |2 +-
3 files changed, 20 insertions(+), 16 deletions(-)
diff -puN include/linux/msdos_fs.h~fat-gcc43-warning-fix
include/linux/msdos_fs.h
--- linux-2.6/include/linux/msdos_fs.h~fat-gcc43-warning-fix2007-05-20
18:58:42.0 +0900
+++ linux-2.6-hirofumi/include/linux/msdos_fs.h 2007-05-20 18:59:04.0
+0900
@@ -146,7 +146,7 @@ struct fat_boot_fsinfo {
};
struct msdos_dir_entry {
- __u8name[8],ext[3]; /* name and extension */
+ __u8name[MSDOS_NAME];/* name and extension */
__u8attr; /* attribute bits */
__u8lcase; /* Case for base and extension */
__u8ctime_cs; /* Creation time, centiseconds (0-199) */
diff -puN fs/fat/dir.c~fat-gcc43-warning-fix fs/fat/dir.c
--- linux-2.6/fs/fat/dir.c~fat-gcc43-warning-fix2007-05-20
18:59:28.0 +0900
+++ linux-2.6-hirofumi/fs/fat/dir.c 2007-05-20 22:23:40.0 +0900
@@ -313,7 +313,7 @@ int fat_search_long(struct inode *inode,
wchar_t bufuname[14];
unsigned char xlate_len, nr_slots;
wchar_t *unicode = NULL;
- unsigned char work[8], bufname[260];/* 256 + 4 */
+ unsigned char work[MSDOS_NAME], bufname[260]; /* 256 + 4 */
int uni_xlate = sbi->options.unicode_xlate;
int utf8 = sbi->options.utf8;
int anycase = (sbi->options.name_check != 's');
@@ -351,7 +351,8 @@ parse_record:
if (work[0] == 0x05)
work[0] = 0xE5;
for (i = 0, j = 0, last_u = 0; i < 8;) {
- if (!work[i]) break;
+ if (!work[i])
+ break;
chl = fat_shortname2uni(nls_disk, &work[i], 8 - i,
&bufuname[j++], opt_shortname,
de->lcase & CASE_LOWER_BASE);
@@ -365,13 +366,15 @@ parse_record:
}
j = last_u;
fat_short2uni(nls_disk, ".", 1, &bufuname[j++]);
- for (i = 0; i < 3;) {
- if (!de->ext[i]) break;
- chl = fat_shortname2uni(nls_disk, &de->ext[i], 3 - i,
+ for (i = 8; i < MSDOS_NAME;) {
+ if (!work[i])
+ break;
+ chl = fat_shortname2uni(nls_disk, &work[i],
+ MSDOS_NAME - i,
&bufuname[j++], opt_shortname,
de->lcase & CASE_LOWER_EXT);
if (chl <= 1) {
- if (de->ext[i] != ' ')
+ if (work[i] != ' ')
last_u = j;
} else {
last_u = j;
@@ -445,7 +448,7 @@ static int __fat_readdir(struct inode *i
int fill_len;
wchar_t bufuname[14];
wchar_t *unicode = NULL;
- unsigned char c, work[8], bufname[56], *ptname = bufname;
+ unsigned char c, work[MSDOS_NAME], bufname[56], *ptname = bufname;
unsigned long lpos, dummy, *furrfu = &lpos;
int uni_xlate = sbi->options.unicode_xlate;
int isvfat = sbi->options.isvfat;
@@ -527,7 +530,8 @@ parse_record:
if (work[0] == 0x05)
work[0] = 0xE5;
for (i = 0, j = 0, last = 0, last_u = 0; i < 8;) {
- if (!(c = work[i])) break;
+ if (!(c = work[i]))
+ break;
chl = fat_shortname2uni(nls_disk, &work[i], 8 - i,
&bufuname[j++], opt_shortname,
de->lcase & CASE_LOWER_BASE);
@@ -549,9 +553,10 @@ parse_record:
j = last_u;
fat_short2uni(nls_disk, ".", 1, &bufuname[j++]);
ptname[i++] = '.';
- for (i2 = 0; i2 < 3;) {
- if (!(c = de->ext[i2])) break;
- chl = fat_shortname2uni(nls_disk, &de->ext[i2], 3 - i2,
+ for (i2 = 8; i2 < MSDOS_NAME;) {
+ if (!(c = work[i2]))
+ break;
+ chl = fat_shortname2uni(nls_disk, &work[i2], MSDOS_NAME - i2,
&bufuname[j++], opt_s
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
On Sunday 20 May 2007, Stefan Richter wrote: > > > Note that this data structure only needs conversion on x86_64 and ia64, but > > not on powerpc and other 64 bit architectures that align __u64 also in > > 32 bit mode. > > Is this conversion just unnecessary or actually harmful on ppc64 and others? With the current patch, the compat_ioctl function does not handle the ppc32 version of the structure at all, so it's broken there, it would at least need a case RAW1394_IOC_GET_CYCLE_TIMER: err = raw1394_ioctl(NULL, file, cmd, arg); break; Arnd <>< - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
On 5/19/07, Al Viro <[EMAIL PROTECTED]> wrote: On Sat, May 19, 2007 at 11:16:59PM -0700, Ray Lee wrote: > Ken? Ball's in your court. As the patch isn't providing a killer > feature for 2.6.22, I'd suggest just reverting it for now until the > issues are ironed out. Hold it. The real question here is which logics do we want there. IOW, and how many device nodes do we want to appear and _when_ do we want them to appear? The when part is what looks to make it racy. I'm guessing that we're relying on udev to create those loop nodes. If so, I think any scheme that creates more on demand would give transient mount errors while it's waiting on udev to create more nodes. Perhaps if we were to start with 8 loop nodes at init (as we have in 2.6.21), and then always maintain a margin of 8 (or 4, or...) when they start being used or detached? - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: bug in 2.6.22-rc2: loop mount limited to one single iso image
On 5/20/07, Uwe Bugla <[EMAIL PROTECTED]> wrote: My question / proposal for now would be: Could anybody of you please be kind enough and write / provide me a counter patch supplying me: a. a compilable 2.6.22-rc2 kernel b. a loop device that can mount up to 8 iso-images If you revert all three patches in this thread, you should be okay. If you're having trouble with that, you can revert all the way back to the version in 2.6.21 (by just copying it), and then do a search/replace on loop.c to change any invalidate_bdev(bdev, 0) you find to invalidate_bdev(bdev) and that should work as well. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Re: [PATCH] Fix/add raw1394 CONFIG_COMPAT code
Arnd Bergmann wrote:
> On Sunday 20 May 2007, Stefan Richter wrote:
>>> Note that this data structure only needs conversion on x86_64 and ia64, but
>>> not on powerpc and other 64 bit architectures that align __u64 also in
>>> 32 bit mode.
>> Is this conversion just unnecessary or actually harmful on ppc64 and others?
>
> With the current patch, the compat_ioctl function does not handle the ppc32
> version of the structure at all, so it's broken there, it would at least
> need a
>
> case RAW1394_IOC_GET_CYCLE_TIMER:
> err = raw1394_ioctl(NULL, file, cmd, arg);
> break;
Dan,
maybe we should change
/* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
struct raw1394_cycle_timer {
/* contents of Isochronous Cycle Timer register,
as in OHCI 1.1 clause 5.13 (also with non-OHCI hosts) */
__u32 cycle_timer;
/* local time in microseconds since Epoch,
simultaneously read with cycle timer */
__u64 local_time;
};
to
/* argument to RAW1394_IOC_GET_CYCLE_TIMER ioctl */
struct raw1394_cycle_timer {
/*
* least significant 32 bits are contents of Isochronous Cycle
* Timer register, as in OHCI 1.1 clause 5.13 (also with
* non-OHCI hosts)
*/
__u64 cycle_timer;
/*
* local time in microseconds since Epoch,
* simultaneously read with cycle timer
*/
__u64 local_time;
};
before a libraw1394 with get-cycle-timer support is released.
Shall I prepare according patches for raw1394 and libraw1394?
--
Stefan Richter
-=-=-=== -=-= =-=--
http://arcgraph.de/sr/
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Re: 2.6.22-rc1-mm1
On May 20, 2007, at 5:21 AM, Sam Ravnborg wrote: On Sun, May 20, 2007 at 12:12:50PM +0200, Mariusz Kozlowski wrote: Hello, I tried it on iMac G3. I got a bunch of warnings and finally it failed to build. WARNING: "fee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol WARNING: "ee_restarts" [arch/powerpc/kernel/built-in] is COMMON symbol WARNING: arch/powerpc/kernel/built-in.o - Section mismatch: reference to .init.data:.got2 from dt_string_start (offset 0x8) Most - but not all of these warnings should be gone when Linus pulls kbuild-fix.git. When -rc3 is ready can you then please post the result of a build. Then I can take a look at the remaining section mismatch warnings. Also, I've got fixes for the COMMON symbol warnings. - k - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
