[PATCH] flush icache before set_pte() take 5.
Appliled comments on take 4. patches are against 2.6.23-rc1. Changes: - changes flush_icache_page to be flush_cache_page() in remove_migration_pte(). - removed sync_icache_dcahe() in page reuse case of do_wp_page(). Considerations: - I can add CONFIG_MONTECITO if necessary. But it will be confusing, I think. Thanks, -Kame - 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: mm/sparse.c:482: error: implicit declaration of function ‘sparse_early_usemap_alloc’
On Fri, 27 Jul 2007 23:00:54 -0700 Miles Lane wrote: > Do you need my .config file? Ideally, yes. Is this for 2.6.23-rc1-mm1? > CC mm/sparse.o > mm/sparse.c: In function 'sparse_init': > mm/sparse.c:482: error: implicit declaration of function > 'sparse_early_usemap_alloc' > mm/sparse.c:482: warning: assignment makes pointer from integer without a cast > make[1]: *** [mm/sparse.o] Error 1 --- ~Randy *** Remember to use Documentation/SubmitChecklist when testing your code *** - 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] flush icache before set_pte() take 5. [1/2] cache flush in migration
In migration, a new page should be cache flushed before set_pte() in some archs which have virtually-tagged cache.. V4 -> V5: * changed flush_icache_page to flush_cache_page. Signed-Off-By: KAMEZAWA Hiruyoki <[EMAIL PROTECTED]> --- mm/migrate.c |1 + 1 file changed, 1 insertion(+) Index: linux-2.6.23-rc1.test/mm/migrate.c === --- linux-2.6.23-rc1.test.orig/mm/migrate.c +++ linux-2.6.23-rc1.test/mm/migrate.c @@ -172,6 +172,7 @@ static void remove_migration_pte(struct pte = pte_mkold(mk_pte(new, vma->vm_page_prot)); if (is_write_migration_entry(entry)) pte = pte_mkwrite(pte); + flush_cache_page(vma, addr, pte_pfn(pte)); set_pte_at(mm, addr, ptep, pte); if (PageAnon(new)) - 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] flush icache before set_pte() take 5. [2/2] sync icache dcache for ia64
flush icache for ia64 take4.
This patch is against 2.6.23-rc1.
Changes V4 -> V5:
- removed sync_icache_dcache from do_wp_page() page reuse case.
Changes v3 -> v4:
- avoid implementing flush_(i)cache_pages().
- added sync_icache_dcache() call.
- change Documentation/cachetlb.txt
Current ia64 kernel flushes icache by lazy_mmu_prot_update() *after*
set_pte(). This is wrong. This patch removes lazy_mmu_prot_update and
add sync_icache_dcache(). sync_icache_dcache() is called before set_pte()
if necessary and synchronize icache with dcache (fc.i instruction).
This patch fixes SIGILL problem on NFS/ia64.
About Icache-Dcache inconsistency in ia64
- When the cache line is modified, Icache and Dcache are purged.
- When I-cache misses, I-cache will access just the lower layer cache(memory).
Then, If the lower_layer_cache is not up-to-date, I-cache will see
old information. For avoiding this case, Icache-Dcache synchronization(fc.i)
is necessary. (Icache-Dcache synchronization means making Dcache and lower
layer unified cache(memory) consistent.)
Details:
- In general, cache flushing macro are used for virtually tagged caches.
IA64 has physically tagged caches but doesn't guarantee consistency
between Icache and Dcache. So, new macro, sync_icache_dcache() is added.
This is NO-OP in other archs.
- sync_icache_dcache() only works if pte is executable.
- sync_icache_dcache must be called before set_pte().
- A page which is consistent is marked as PG_arch_1.
About changes in generic codes:
- do_wp_page() need to sync newly copied page.
Here, lazy_mmu_prot_update() was done before set_pte().
This was because someone mets SIGILL in JAVA and small
fix was applied.
- do_anonymous_page() newly installed anon pages doesn't contains any
instruction when set_pte() is executed, icache-dcache
synchronization is not necessary.
- __do_fault() need to sync newly-installed page.
- handle_pte_fault() just changes access bit...then, no need to sync.
- remove_migration_pte() need to sync newly-installed page.
- change_pte_range() need to sync icache-dcache. When a user writes
instruction into the page and modifies protection to be
executable, it should be synced.
- hugetlb_change_protection() Maybe cache will be expired...but
it is safe to sync Icache before set_pte().
- page_mkclean_one() no need to sync icache-dcache. There is no page
contents modification. And there is no protection
change.
Thanks to Zoltan Menyhart for his advices.
Signed-Off-By: KAMEZAWA Hiroyuki <[EMAIL PROTECTED]>
---
Documentation/cachetlb.txt| 11 +++
arch/ia64/mm/init.c |6 ++
include/asm-generic/pgtable.h |8
include/asm-ia64/pgtable.h| 15 ++-
mm/hugetlb.c |3 +--
mm/memory.c |7 ++-
mm/migrate.c |2 +-
mm/mprotect.c |2 +-
mm/rmap.c |1 -
9 files changed, 28 insertions(+), 27 deletions(-)
Index: linux-2.6.23-rc1.test/include/asm-generic/pgtable.h
===
--- linux-2.6.23-rc1.test.orig/include/asm-generic/pgtable.h
+++ linux-2.6.23-rc1.test/include/asm-generic/pgtable.h
@@ -124,14 +124,14 @@ static inline void ptep_set_wrprotect(st
#define pgd_offset_gate(mm, addr) pgd_offset(mm, addr)
#endif
-#ifndef __HAVE_ARCH_LAZY_MMU_PROT_UPDATE
-#define lazy_mmu_prot_update(pte) do { } while (0)
-#endif
-
#ifndef __HAVE_ARCH_MOVE_PTE
#define move_pte(pte, prot, old_addr, new_addr)(pte)
#endif
+#ifndef __HAVE_ARCH_SYNC_ICACHE_DCACHE
+#define sync_icache_dcache(pte)do {} while (0)
+#endif
+
/*
* A facility to provide lazy MMU batching. This allows PTE updates and
* page invalidations to be delayed until a call to leave lazy MMU mode
Index: linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
===
--- linux-2.6.23-rc1.test.orig/include/asm-ia64/pgtable.h
+++ linux-2.6.23-rc1.test/include/asm-ia64/pgtable.h
@@ -484,11 +484,17 @@ extern struct page *zero_page_memmap_ptr
#endif
/*
- * IA-64 doesn't have any external MMU info: the page tables contain all the
necessary
- * information. However, we use this routine to take care of any (delayed)
i-cache
- * flushing that may be necessary.
+ * IA-64 doesn't guarantee Icache is consistent with Dcache. For ensure
+ * Icache consistency, we have to synchronize them before setting pte
+ * as an executable pte.
*/
-extern void lazy_mmu_prot_update (pte_t pte);
+extern void __sync_icache_dcache(pte_t pte);
+static inline void sync_icache_dcache(pte_t pte) {
+ if
Re: [PATCH] ia64: fix a few section mismatch warnings
On Fri, Jul 27, 2007 at 03:32:13PM -0700, Luck, Tony wrote: > - mca_data = alloc_bootmem(sizeof(struct ia64_mca_cpu) > - * NR_CPUS + KERNEL_STACK_SIZE); > + mca_data = mca_bootmem(NR_CPUS + KERNEL_STACK_SIZE); > > Oops. You moved the multiply by sizeof(struct ia64_mca_cpu) up into > the mca_bootmem() function to make it very specific to this use. But > mutiply has higher precedence than addition. Oh crap - good catch. Shall I resubmit a corrected patch? 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: mm/sparse.c:482: error: impl icit declaration of function ‘sparse_early_usemap _alloc’
On Fri, Jul 27, 2007 at 11:00:54PM -0700, Miles Lane wrote: > Do you need my .config file? Please always send the .config - it makes reproducing an error and verifying a fix much easier. This list has a 400 kB per email limit, and as long as you don't hit this limit you have never sent too much information. > CC mm/sparse.o > mm/sparse.c: In function 'sparse_init': > mm/sparse.c:482: error: implicit declaration of function > 'sparse_early_usemap_alloc' > mm/sparse.c:482: warning: assignment makes pointer from integer without a cast > make[1]: *** [mm/sparse.o] Error 1 The .config also tells which kernel you are using. This doesn't seem to be Linus' tree. This seems to be 2.6.23-rc1-mm1? cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: mm/sparse.c:482: error: implicit declaration of function ‘sparse_early_usemap_alloc’
On 7/27/07, Adrian Bunk <[EMAIL PROTECTED]> wrote: > On Fri, Jul 27, 2007 at 11:00:54PM -0700, Miles Lane wrote: > > Do you need my .config file? > > Please always send the .config - it makes reproducing an error and > verifying a fix much easier. > > This list has a 400 kB per email limit, and as long as you don't hit > this limit you have never sent too much information. > > > CC mm/sparse.o > > mm/sparse.c: In function 'sparse_init': > > mm/sparse.c:482: error: implicit declaration of function > > 'sparse_early_usemap_alloc' > > mm/sparse.c:482: warning: assignment makes pointer from integer without a > > cast > > make[1]: *** [mm/sparse.o] Error 1 > > The .config also tells which kernel you are using. > > This doesn't seem to be Linus' tree. > This seems to be 2.6.23-rc1-mm1? Rats. I almost always remember to specify the kernel version. Sorry. Yes, it's the Andrew's latest tree, plus hotfixes. Miles - 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.23-rc1-mm1 + hotfixes -- Section mismatches
On Fri, Jul 27, 2007 at 10:16:35PM -0700, Miles Lane wrote: > MODPOST vmlinux.o > WARNING: vmlinux.o(.text+0x183): Section mismatch: reference to > .init.text.1:start_kernel (between 'is386' and 'check_x87') This one is not fixed - yet. The rest are fixed in latest -linus. modpost choked over the added number following the section name. Like in .init.text.4 below. ^^ > WARNING: vmlinux.o(.data+0x53c0): Section mismatch: reference to > .init.text.4:native_smp_prepare_boot_cpu (between 'smp_ops' and > 'call_lock') 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: mm/sparse.c:482: error: implicit declaration of function ‘sparse_early_usemap_alloc’
On Fri, 27 Jul 2007 23:14:04 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote: > On 7/27/07, Miles Lane <[EMAIL PROTECTED]> wrote: > > Do you need my .config file? > > > > CC mm/sparse.o > > mm/sparse.c: In function 'sparse_init': > > mm/sparse.c:482: error: implicit declaration of function > > 'sparse_early_usemap_alloc' > > mm/sparse.c:482: warning: assignment makes pointer from integer without a > > cast > > make[1]: *** [mm/sparse.o] Error 1 > > > > # > # Automatically generated make config: don't edit > # Linux kernel version: 2.6.23-rc1-mm1 > # Fri Jul 27 22:54:36 2007 Whatever it is was gone away in the current -mm lineup so I guess one of the post-2.6.23-rc1-mm1 patches I merged fixed 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: request for patches: showing mount options
On Fri, 2007-07-27 at 17:40 +0200, Miklos Szeredi wrote: > > all - fs has options, but doesn't define ->show_options() > > some - fs defines ->show_options(), but some options are not shown > > noopt - fs does not have options > > good - fs shows all options > > patch - I have a patch > > [...] > > > > autofs all > > > > I'm not sure I understand this. > > How does autofs show it's options without a ->show_options method? > > It doesn't. The "all" means, all of them need to be added to > ->show_options(), not that all are shown. Oh .. sorry, I wasn't paying enough attention. But now might be a good time to propose the removal of autofs and rename autofs4 to autofs. I would need to provide some way to map autofs4 module load requests to autofs for backward compatibility but haven't thought about that yet. > > I can see now that this is slightly confusing, sorry. > > So the ones that need attention are "all" and "some". The others are > fine in theory. Of course I may have missed something. > > > > autofs4 some > > > > OK, uid and gid aren't shown. > > That should be straight forward to fix. > > What's your time frame for this? > > ASAP ;) > > 2.6.24 would be a nice, but it won't be easy... The autofs4 (and, if needed autofs) should be straight forward. I'll do these. Ian - 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: pluggable scheduler thread (was Re: Volanomark slows by 80% under CFS)
Andrea Arcangeli wrote: On Fri, Jul 27, 2007 at 11:43:23PM -0400, Chris Snook wrote: I'm pretty sure the point of posting a patch that triples CFS performance on a certain benchmark and arguably improves the semantics of sched_yield was to improve CFS. You have a point, but it is a point for a different thread. I have taken the liberty of starting this thread for you. I've no real interest in starting or participating in flamewars (especially the ones not backed by hard numbers). So I adjusted the subject a bit in the hope the discussion will not degenerate as you predicted, hope you don't mind. Not at all. I clearly misread your tone. I'm pretty sure the point of posting that email was to show the remaining performance regression with the sched_yield fix applied too. Given you considered my post both offtopic and inflammatory, I guess you think it's possible and reasonably easy to fix that remaining regression without a pluggable scheduler, right? So please enlighten us on your intend to achieve it. There are four possibilities that are immediately obvious to me: a) The remaining difference is due mostly to the algorithmic complexity of the rbtree algorithm in CFS. If this is the case, we should be able to vary the test parameters (CPU count, thread count, etc.) graph the results, and see a roughly logarithmic divergence between the schedulers as some parameter(s) vary. If this is the problem, we may be able to fix it with data structure tweaks or optimized base cases, like how quicksort can be optimized by using insertion sort below a certain threshold. b) The remaining difference is due mostly to how the scheduler handles volanomark. vmstat can give us a comparison of context switches between O(1), CFS, and CFS+patch. If the decrease in throughput correlates with an increase in context switches, we may be able to induce more O(1)-like behavior by charging tasks for context switch overhead. c) The remaining difference is due mostly to how the scheduler handles something other than volanomark. If context switch count is not the problem, context switch pattern still could be. I doubt we'd see a 40% difference due to cache misses, but it's possible. Fortunately, oprofile can sample based on cache misses, so we can debug this too. d) The remaining difference is due mostly to some implementation detail in CFS. It's possible there's some constant-factor overhead in CFS that is magnified heavily by the context switching volanomark deliberately induces. If this is the case, oprofile sampling on clock cycles should catch it. Tim -- Since you're already set up to do this benchmarking, would you mind varying the parameters a bit and collecting vmstat data? If you want to run oprofile too, that wouldn't hurt. Also consider the other numbers likely used nptl so they shouldn't be affected by sched_yield changes. Sure there is. We can run a fully-functional POSIX OS without using any block devices at all. We cannot run a fully-functional POSIX OS without a scheduler. Any feature without which the OS cannot execute userspace code is sufficiently primitive that somewhere there is a device on which it will be impossible to debug if that feature fails to initialize. It is quite reasonable to insist on only having one implementation of such features in any given kernel build. Sounds like a red-herring to me... There aren't just pluggable I/O schedulers in the kernel, there are pluggable packet schedulers too (see `tc qdisc`). And both are switchable at runtime (not just at boot time). Can you run your fully-functional POSIX OS without a packet scheduler and without an I/O scheduler? I wonder where are you going to read/write data without HD and network? If I'm missing both, I'm pretty screwed, but if either one is functional, I can send something out. Also those pluggable things don't increase the risk of crash much, if compared to the complexity of the schedulers. Whether or not these alternatives belong in the source tree as config-time options is a political question, but preserving boot-time debugging capability is a perfectly reasonable technical motivation. The scheduler is invoked very late in the boot process (printk and serial console, kdb are working for ages when scheduler kicks in), so it's fully debuggable (no debugger depends on the scheduler, they run inside the nmi handler...), I don't really see your point. I'm more concerned about embedded systems. These are the same people who want userspace character drivers to control their custom hardware. Having the robot point to where it hurts is a lot more convenient than hooking up a JTAG debugger. And even if there would be a subtle bug in the scheduler you'll never trigger it at boot with so few tasks and so few context switches. Sure, but it's the non-subtle bugs that worry me. These are usually related to low-level hardware setup, so they could miss the
Re: [ck] Re: Linus 2.6.23-rc1
On Fri, 27 Jul 2007, Linus Torvalds wrote: On Sat, 28 Jul 2007, Kasper Sandberg wrote: Im still not so keen about this, Ingo never did get CFS to match SD in smoothness for 3d applications, where my test subjects are quake(s), world of warcraft via wine, unreal tournament 2004. And this is despite many patches he sent me to try and tweak it. You realize that different people get different behaviour, don't you? Maybe not. People who think SD was "perfect" were simply ignoring reality. Sadly, that seemed to include Con too, which was one of the main reasons that I never ended entertaining the notion of merging SD for very long at all: Con ended up arguing against people who reported problems, rather than trying to work with them. I don't really want to keep all that -ck flamewar going but this sum-up is a little strange for me: If Con was thinking SD was "perfect" why he released 30+ versions of it? And who knows how many versions of his previous scheduler? Besides Con always tried to help people and improve his code if some bugs or problems were reported. Archives of this list prove that. I reported several problems (on list and privately) and all were fixed very fast and with very kind responses. I had run -ck for months and years and it was always very stable (I remember one broken "stable" version). I don't know what exactly are you refering to when you say about those unaddressed reports but maybe it depends on who was asking, how and to do what (for example - purely theoretical one, I don't remember exact emails you refering to so I am not saying it happened - stating at the beginning that the whole design is unacceptable and interactivity hacks are a must-have won't make a friend from any maintainer and for sure lowers his desire to get anything fixed for that guy). Or maybe Con had some bad day or was depressed. Happens. But I really don't remember Con ignoring too many valuable user reports in last 3 years... And no - I am not thinking that SD was "perfect". Nothing is perfect, especially not software. But it was based on months and years of Con's experience with desktop and gaming workloads and extensively tested in similar uses by _many_ others. In nearly all possible desktop configurations, with most games and all video drivers. This is why it was perfectly designed and tuned for such workloads while still being general enough and without any ugly hacks. And because of these tests and Con's believe that the desktop is very (most?) important all bugs and problems in this area were probably killed long ago. I think even design was changed and tuned a little at the early stages to help solve such interactivity/dekstop/gaming problems. So it does not surprise me that CFS is worse in such workloads (at least for some people) because I strongly suspect that the number of people who played games with current version of CFS is limited to about 5, maybe 10. And I also suspect that you (and Ingo) will get many regression reports when 2.6.23 is released (and months later too... or maybe you won't because users will be to "scared" to report such hard to mensure and reproduce "unimportant" bugs). Hopefully such problems when reported will be addressed as soon as they can. And hopefully they will be easy enough to solve without rewriting or redesigning CFS and causing that way even more regressions in other areas. If not people will probably be patching O(1) scheduler back privately... Thanks, Grzegorz Kulewski - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: On 07/27/2007 07:45 PM, Daniel Hazelton wrote: Questions about it: Q) Does swap-prefetch help with this? A) [From all reports I've seen (*)] Yes, it does. No it does not. If updatedb filled memory to the point of causing swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and swap-prefetch hasn't any memory to prefetch into -- updatedb itself doesn't use any significant memory. however there are other programs which are known to take up significant amounts of memory and will cause the issue being described (openoffice for example) please don't get hung up on the text 'updatedb' and accept that there are programs that do run intermittently and do use a significant amount of ram and then free it. Different issue. One that's worth pursueing perhaps, but a different issue from the VFS caches issue that people have been trying to track down. Rene. - 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: How can we make page replacement smarter (was: swap-prefetch)
Al Boldi wrote: Chris Snook wrote: Resource size has been outpacing processing latency since the dawn of time. Disks get bigger much faster than seek times shrink. Main memory and cache keep growing, while single-threaded processing speed has nearly ground to a halt. In the old days, it made lots of sense to manage resource allocation in pages and blocks. In the past few years, we started reserving blocks in ext3 automatically because it saves more in seek time than it costs in disk space. Now we're taking preallocation and antifragmentation to the next level with extent-based allocation in ext4. Well, we're still using bitmap-style allocation for pages, and the prefetch-less swap mechanism adheres to this design as well. Maybe it's time to start thinking about memory in a somewhat more extent-like fashion. With swap prefetch, we're only optimizing the case when the box isn't loaded and there's RAM free, but we're not optimizing the case when the box is heavily loaded and we need for RAM to be free. This is a complete reversal of sane development priorities. If swap batching is an optimization at all (and we have empirical evidence that it is) then it should also be an optimization to swap out chunks of pages when we need to free memory. So, how do we go about this grouping? I suggest that if we keep per-VMA reference/fault/dirty statistics, we can tell which logically distinct chunks of memory are being regularly used. This would also us to apply different page replacement policies to chunks of memory that are being used in different fashions. With such statistics, we could then page out VMAs in 2MB chunks when we're under memory pressure, also giving us the option of transparently paging them back in to hugepages when we have the memory free, once anonymous hugepage support is in place. I'm inclined to view swap prefetch as a successful scientific experiment, and use that data to inform a more reasoned engineering effort. If we can design something intelligent which happens to behave more or less like swap prefetch does under the circumstances where swap prefetch helps, and does something else smart under the circumstances where swap prefetch makes no discernable difference, it'll be a much bigger improvement. Because we cannot prove why the existing patch helps, we cannot say what impact it will have when things like virtualization and solid state drives radically change the coefficients of the equation we have not solved. Providing a sysctl to turn off a misbehaving feature is a poor substitute for doing it right the first time, and leaving it off by default will ensure that it only gets used by the handful of people who know enough to rebuild with the patch anyway. Let's talk about how we can make page replacement smarter, so it naturally accomplishes what swap prefetch accomplishes, as part of a design we can reason about. CC-ing linux-mm, since that's where I think we should take this next. Good idea, but unless we understand the problems involved, we are bound to repeat it. So my first question would be: Why is swap-in so slow? As I have posted in other threads, swap-in of consecutive pages suffers a 2x slowdown wrt swap-out, whereas swap-in of random pages suffers over 6x slowdown. Because it is hard to quantify the expected swap-in speed for random pages, let's first tackle the swap-in of consecutive pages, which should be at least as fast as swap-out. So again, why is swap-in so slow? If I'm writing 20 pages to swap, I can find a suitable chunk of swap and write them all in one place. If I'm reading 20 pages from swap, they could be anywhere. Also, writes get buffered at one or more layers of hardware. At best, reads can be read-ahead and cached, which is why sequential swap-in sucks less. On-demand reads are as expensive as I/O can get. Once we understand this problem, we may be able to suggest a smart improvement. There are lots of page replacement schemes that optimize for different access patterns, and they all suck at certain other access patterns. We tweak our behavior slightly based on fadvise and madvise hints, but most of the memory we're managing is an opaque mass. With more statistics, we could do a better job of managing chunks of unhinted memory with disparate access patterns. Of course, this imposes overhead. I suggested VMA granularity because a VMA represents a logically distinct piece of address space, though this may not be suitable for shared mappings. -- Chris - 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: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Thursday 26 July 2007 16:55, Linus Torvalds wrote: > Anyway, I think the ACPI problem really is as trivial as the following > three-liner removal fix. If the user doesn't want suspend, ACPI shouldn't > force it on him. ... > - # for sleep > - select HOTPLUG_CPU if X86 && SMP > - select SUSPEND_SMP if X86 && SMP That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. While cpu0 is in a known state when the power goes out, without HOTPLUG_CPU the other cpus (and the memory they touch) are in an indeterminate state. Yes, we could invent a new mechanism to offline the other CPUS before suspend and online them upon resume, but that is what the more general HOTPLUG_CPU code does for us already. Indeed, that is pretty much _all_ that HOTPLUG_CPU code does on X86 -- as we don't have any physical hotplug support today beneath this the logical hotplug support -- you could call it CONFIG_CPU_OFFLINE_ONLINE... > A nicer fix might be to also make some of the ACPI helper routines depend > on whether they are needed or not (which in turn will depend on whether > suspend support has been compiled into the kernel), but quite frankly, > that's secondary at least for me. > > So if we have a few ACPI routines that will never get called (because we > don't even enable the interfaces that would *cause* them to be called), I > don't think that's a huge problem. It's a beauty wart, but nobody really > cares (and it's even something that we could get the compiler to optimize > away for us if we really cared). Re: warts, I agree. My question is why the HOTPLUG_CPU=y code is any different. When I compile HOTPLUG_CPU out of an x86_64 kernel, the kernel shrinks by only 18KB, which on a kernel that has ACPI+SMP doesn't seem like such a big wart. Yes, now that you brought it up, I think it would be just dandy if HOTPLUG_CPU simply got folded into SMP -- for I see little to no benefit to having it as its own config option. But on the assumption that you are not swayed (when was the last time you were?) and you still feel strongly we should be able to exclude ACPI_SLEEP and HOTPLUG_CPU from ACPI+SMP kernels, I'll send you a patch do to that properly. It will largely restores things to how we had them in 2.6.22. It looks like a step backwards to me, but you may see it differently. -Len - 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] ACPI: restore CONFIG_ACPI_SLEEP
From: Len Brown <[EMAIL PROTECTED]> Restore the 2.6.22 CONFIG_ACPI_SLEEP build option, with a few differences: 1. selects HOTPLUG_CPU rather than depends on HOTPLUG_CPU. 2. ACPI_SLEEP can be enabled on IA64 Disabling this option shrinks the kernel by 16KB. Disabling this option on SMP allows the user to deselect HOTPLUG_CPU and save an addition 18KB. Signed-off-by: Len Brown <[EMAIL PROTECTED]> --- arch/i386/kernel/acpi/Makefile |2 +- arch/i386/kernel/setup.c |2 +- arch/x86_64/kernel/acpi/Makefile |2 +- arch/x86_64/kernel/head.S|2 +- arch/x86_64/kernel/setup.c |2 +- drivers/acpi/Kconfig | 17 + drivers/acpi/sleep/Makefile |4 ++-- drivers/acpi/sleep/poweroff.c|2 ++ drivers/acpi/sleep/proc.c|2 +- drivers/pci/pci-acpi.c |4 drivers/pnp/pnpacpi/core.c |4 include/acpi/acpi_drivers.h |4 kernel/sysctl.c |2 +- 13 files changed, 40 insertions(+), 9 deletions(-) diff --git a/arch/i386/kernel/acpi/Makefile b/arch/i386/kernel/acpi/Makefile index 223f58f..7f7be01 100644 --- a/arch/i386/kernel/acpi/Makefile +++ b/arch/i386/kernel/acpi/Makefile @@ -2,7 +2,7 @@ obj-$(CONFIG_ACPI) += boot.o ifneq ($(CONFIG_PCI),) obj-$(CONFIG_X86_IO_APIC) += earlyquirk.o endif -obj-$(CONFIG_ACPI) += sleep.o wakeup.o +obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup.o ifneq ($(CONFIG_ACPI_PROCESSOR),) obj-y += cstate.o processor.o diff --git a/arch/i386/kernel/setup.c b/arch/i386/kernel/setup.c index 7fe5da3..d474cd6 100644 --- a/arch/i386/kernel/setup.c +++ b/arch/i386/kernel/setup.c @@ -422,7 +422,7 @@ void __init setup_bootmem_allocator(void) */ reserve_bootmem(PAGE_SIZE, PAGE_SIZE); #endif -#ifdef CONFIG_ACPI +#ifdef CONFIG_ACPI_SLEEP /* * Reserve low memory region for sleep support. */ diff --git a/arch/x86_64/kernel/acpi/Makefile b/arch/x86_64/kernel/acpi/Makefile index 17595d2..080b996 100644 --- a/arch/x86_64/kernel/acpi/Makefile +++ b/arch/x86_64/kernel/acpi/Makefile @@ -1,6 +1,6 @@ obj-y := boot.o boot-y := ../../../i386/kernel/acpi/boot.o -obj-y += sleep.o wakeup.o +obj-$(CONFIG_ACPI_SLEEP) += sleep.o wakeup.o ifneq ($(CONFIG_ACPI_PROCESSOR),) obj-y += processor.o diff --git a/arch/x86_64/kernel/head.S b/arch/x86_64/kernel/head.S index 3a16e41..e89abcd 100644 --- a/arch/x86_64/kernel/head.S +++ b/arch/x86_64/kernel/head.S @@ -120,7 +120,7 @@ ident_complete: addq%rbp, trampoline_level4_pgt + 0(%rip) addq%rbp, trampoline_level4_pgt + (511*8)(%rip) #endif -#ifdef CONFIG_ACPI +#ifdef CONFIG_ACPI_SLEEP addq%rbp, wakeup_level4_pgt + 0(%rip) addq%rbp, wakeup_level4_pgt + (511*8)(%rip) #endif diff --git a/arch/x86_64/kernel/setup.c b/arch/x86_64/kernel/setup.c index 0f400f3..af838f6 100644 --- a/arch/x86_64/kernel/setup.c +++ b/arch/x86_64/kernel/setup.c @@ -333,7 +333,7 @@ void __init setup_arch(char **cmdline_p) reserve_bootmem_generic(SMP_TRAMPOLINE_BASE, 2*PAGE_SIZE); #endif -#ifdef CONFIG_ACPI +#ifdef CONFIG_ACPI_SLEEP /* * Reserve low memory region for sleep support. */ diff --git a/drivers/acpi/Kconfig b/drivers/acpi/Kconfig index 22b401b..f38db44 100644 --- a/drivers/acpi/Kconfig +++ b/drivers/acpi/Kconfig @@ -42,6 +42,23 @@ menuconfig ACPI if ACPI +config ACPI_SLEEP + bool "ACPI hooks for system sleep and wakeup" + select HOTPLUG_CPU if X86 && SMP + select SUSPEND_SMP if X86 && SMP + default X86 + ---help--- + Say Y to include ACPI hooks for system sleep and wakeup. + This options is needed for suspend to RAM on ACPI-enabled + machines, for it includes the wakup vector support, + as well as wakeup-device support. + + System Hibernate to disk can function without this option, + but wakeup devices may work better with it. + + Disabling ACPI_SLEEP saves about 16 KB, and allows + disabling HOTPLUG_CPU, which saves an additional 18 KB. + config ACPI_PROCFS bool "Deprecated /proc/acpi files" depends on PROC_FS diff --git a/drivers/acpi/sleep/Makefile b/drivers/acpi/sleep/Makefile index 01a993a..195a4f6 100644 --- a/drivers/acpi/sleep/Makefile +++ b/drivers/acpi/sleep/Makefile @@ -1,5 +1,5 @@ obj-y := poweroff.o wakeup.o -obj-y += main.o -obj-$(CONFIG_X86) += proc.o +obj-$(CONFIG_ACPI_SLEEP) += main.o +obj-$(CONFIG_ACPI_SLEEP) += proc.o EXTRA_CFLAGS += $(ACPI_CFLAGS) diff --git a/drivers/acpi/sleep/poweroff.c b/drivers/acpi/sleep/poweroff.c index b3f68ef..39e40d5 100644 --- a/drivers/acpi/sleep/poweroff.c +++ b/drivers/acpi/sleep/poweroff.c @@ -18,6
Re: [ck] Re: Linus 2.6.23-rc1
On 7/28/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > People who think SD was "perfect" were simply ignoring reality. Sadly, > that seemed to include Con too, which was one of the main reasons that I > never ended entertaining the notion of merging SD for very long at all: > Con ended up arguing against people who reported problems, rather than > trying to work with them. Not even Con thought SD was perfect, so this is being more than a little dishonest. One of his parting comments on the ck list was a list of things that could be fixed/improved. My experience is vastly different to yours, perhaps because I have been subscribed to his mailing list for many years (too many to count) and have run his patchset in various environments in that period - and you have not. Con was always very helpful to people experiencing problems and did in fact work with them to get them resolved. The list is web-archived so everyone is free to go see that for themselves. He also tried to get others interested and involved in kernel development at large. SD itself went through 46 revisions because of things people encountered using it, and it would have been more still considering what Con had in the works had he not been pushed out. I can see how on LKML your viewpoint differs, though to be fair in my recollection there was only one person Con argued with, and that man is a belligerent troll. Its my honest opinion that the problems that troll encountered were completely made up, which is backed by the evidence that no-one else had encountered or indeed could even reproduce them. I recall Con himself catching the troll out in a lie-based "proof" on one occasion. I'll hunt gmane for the link as I believe people like that need to be exposed and stopped. There certainly was a lot of hot air and handwaving, and now that one other tiny portion of Con's work has been raised its still going on. Its interesting that the same cycle repeats even when Con is no longer involved, which proves Con could not have been the issue. I'm sorry you in particular haven't been able to have the same experience with Con as so many others have, especially considering who you are and the weight your words have. You've lost a really great asset and aren't even aware of it. That's really sad for everyone. (fwiw the -ck list did a lot of the testing for CFS recently, and over the years various other things too. Generally a good bunch of folks keen to try anything to make their Linux experience better. And definitely devoid of these petty politics and egos that are plagueing other Linux-related lists. You've not only lost Con, but perhaps one of the better testbeds also). -- Matt - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 07/28/2007 01:15 AM, Björn Steinbrink wrote: On 2007.07.27 20:16:32 +0200, Rene Herman wrote: Here's swap-prefetch's author saying the same: http://lkml.org/lkml/2007/2/9/112 | It can't help the updatedb scenario. Updatedb leaves the ram full and | swap prefetch wants to cost as little as possible so it will never | move anything out of ram in preference for the pages it wants to swap | back in. Now please finally either understand this, or tell us how we're wrong. Con might have been wrong there for boxes with really little memory. Note -- with "the updatedb scenario" both he in the above and I are talking about the "VFS caches filling memory cause the problem" not updatedb in particular. My desktop box has not even 300k inodes in use (IIRC someone posted a df -i output showing 1 million inodes in use). Still, the memory footprint of the "sort" process grows up to about 50MB. Assuming that the average filename length stays, that would mean 150MB for the 1 million inode case, just for the "sort" process. Even if it's not 150MB, 50MB is already a lot on a 128 or even a 256MB box. So, yes, we're now at the expected scenario of some hog pushing out things and freeing it upon exit again and it's something swap-prefetch definitely has potential to help with. Said early in the thread it's hard to imagine how it would not help in any such situation so that the discussion may as far as I'm concerned at that point concentrate on whether swap-prefetch hurts anything in others. Some people I believe are not convinced it helps very significantly due to at that point _everything_ having been thrown out but a copy of openoffice with a large spreadsheet open should come back to life much quicker it would seem. Any faults in that reasoning? No. If the machine goes idle after some memory hog _itself_ pushes things out and then exits, swap-prefetch helps, at the veryvery least potentially. By the way -- I'm unable to make my slocate grow substantial here but I'll try what GNU locate does. If it's really as bad as I hear then regardless of anything else it should really be either fixed or dumped... Rene. - 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: Problems with reading DVD using 2.6.21.5
Robert Hancock wrote: I don't think this is a bug, the drive was told to read a sector and returned error SK=03, ASC=02, ASCQ=00 which is "NO SEEK COMPLETE", in other words it couldn't find that sector. Could be that the disc is marginally readable and only sometimes causes read errors. The disc is OK. No scratches and no fingerprints on the data side. The "position" of this error also seems to be not static. One boot before the one, where I saved the "ls -l" output, the directory "kde" has been unreadable. I unmounted and remounted the disc and immediately after that, all directories have been readable, again. I was able to read exactly this disc with exactly this drive to get the MD5sum of the ISO on the disc. The MD5sum was OK. Even the gpgverify, I did immediately after the MD5sum, was OK. No read errors or any other problems. The major problem is, that this one drove me nuts while installing Slackware, as I always was unsure if this silly installer now installed anything correctly or if I had read errors, again. Why is this error gone after unmount/mount? Why isn't the kernel able to "reread" (retry) a part of the DVD, without the need to remount the whole disc? Thanks very much in advance CU Manuel - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Fri, 2007-07-27 at 18:51 -0400, Daniel Hazelton wrote: > Now, once more, I'm going to ask: What is so terribly wrong with swap > prefetch? Why does it seem that everyone against it says "Its treating a > symptom, so it can't go in"? And once again, I personally have nothing against swap-prefetch, or something like it. I can see how it or something like it could be made to improve the lives of people who get up in the morning to find their apps sitting on disk due to memory pressure generated by over-night system maintenance operations. The author himself however, says his implementation can't help with updatedb (though people seem to be saying that it does), or anything else that leaves memory full. That IMHO, makes it of questionable value toward solving what people are saying they want swap-prefetch for in the first place. I personally don't care if swap-prefetch goes in or not. -Mike - 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: [GIT PATCH] ACPI patches for 2.6.23-rc1
Andreas Schwab wrote: > Jan Dittmer <[EMAIL PROTECTED]> writes: > >> Len Brown wrote: >>> Hi Linus, >>> >>> please pull from: >>> >>> git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6.git >>> release >> This seems to break ia64 defconfig: >> >> Building modules, stage 2. >> MODPOST 157 modules >> FATAL: drivers/acpi/button: sizeof(struct acpi_device_id)=20 is not a modulo >> of the size of section __mod_acpi_device_table=144. > > Are you cross-compiling? The definition of kernel_ulong_t won't work on > x86. Yes, sorry, should have mentioned that. Build system is x86. Still, it didn't happen before the recent acpi merge. 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/
Testing of CPRM on SD Card
Hi All, Our product development requires that we use the CPRM security feature of SD card for protecting our material. I have been searching the web for a SD host controller / Software which is CPRM capable, so that we can write/read an encrypted SD card with the testing keys provided by the 4C Entity) and test our prototype. But I could find none. There are IP cores but no manufactured chips. Has anybody of you done similar stuff ? How do I go about testing the CPRM feature of the SD card on our prototype ? Thanks, Midhun. - 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.23-rc1-mm1 -- INFO: possible recursive locking detected -- (>hb_spinlock){....}, at: [] irias_seq_show+0xba/0x1a8
On Sat, 28 Jul 2007 00:01:23 -0700 "Miles Lane" <[EMAIL PROTECTED]> wrote:
> Looking to see whether reading /proc files made things unhappy:
>
>find /proc/ | xargs cat
>find /proc/ -name "[g-z]*" | xargs cat
>find /proc/ -name "[a-g]*" | xargs file
>
> dmesg shows:
I'm unable to reproduce this.
> process `cat' is using deprecated sysctl (syscall)
> net.ipv6.neigh.default.retrans_time; Use
> net.ipv6.neigh.default.retrans_time_ms instead.
>
> =
> [ INFO: possible recursive locking detected ]
> 2.6.23-rc1-mm1 #15
> -
> cat/5333 is trying to acquire lock:
> (>hb_spinlock){}, at: [] irias_seq_show+0xba/0x1a8
>
> but task is already holding lock:
> (>hb_spinlock){}, at: [] irias_seq_start+0x14/0x4e
>
> other info that might help us debug this:
> 2 locks held by cat/5333:
> #0: (>lock){--..}, at: [] mutex_lock+0x1c/0x1f
> #1: (>hb_spinlock){}, at: []
> irias_seq_start+0x14/0x4e
>
> stack backtrace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_trace+0x12/0x14
> [] dump_stack+0x16/0x18
> [] __lock_acquire+0x18d/0xc20
> [] lock_acquire+0x71/0x8b
> [] _spin_lock+0x35/0x42
> [] irias_seq_show+0xba/0x1a8
> [] seq_read+0x192/0x266
> [] proc_reg_read+0x63/0x76
> [] vfs_read+0x8e/0x117
> [] sys_read+0x3d/0x61
> [] sysenter_past_esp+0x5f/0x99
> ===
It'd be useful if you could display the name of each /proc file as it is
read, so we know which one went boom.
> BUG: unable to handle kernel NULL pointer dereference at virtual
> address 003c
> printing eip:
> c01536a7
> *pde =
> Oops: [#1]
> PREEMPT SMP
> Modules linked in: binfmt_misc cpufreq_conservative cpufreq_powersave
> cpufreq_performance sbp2 parport_pc lp parport snd_intel8x0
> snd_ac97_codec ac97_bus snd_pcm_oss snd_mixer_oss pcmcia snd_pcm
> snd_seq_dummy snd_seq_oss snd_seq_midi snd_rawmidi snd_seq_midi_event
> snd_seq firewire_ohci snd_timer yenta_socket firewire_core
> snd_seq_device sdhci rsrc_nonstatic tifm_7xx1 crc_itu_t tifm_core
> pcmcia_core mmc_core ipw2200 snd rng_core iTCO_wdt iTCO_vendor_support
> soundcore shpchp pci_hotplug snd_page_alloc rtc 8139cp 8139too mii
> ehci_hcd uhci_hcd ohci1394 ieee1394 usbcore
> CPU:0
> EIP:0060:[]Not tainted VLI
> EFLAGS: 00210286 (2.6.23-rc1-mm1 #15)
> EIP is at container_path+0x20/0x7b
> eax: c6e8b05f ebx: c6e8b060 ecx: 1000 edx: c0880434
> esi: edi: c6e8a060 ebp: c5ccff14 esp: c5ccff00
> ds: 007b es: 007b fs: 00d8 gs: 0033 ss: 0068
> Process cat (pid: 5412, ti=c5ccf000 task=c6cf6390 task.ti=c5ccf000)
> Stack: c6e8a060 c0880434 c1c58000 c6f01c60 c6e8a060 c5ccff30 c0154ad2 c10dd100
>fffd c5c9f500 c6f01c60 0001 c5ccff70 c01976b1 0400 08054000
>c5c9f500 c6f01c80 c5ccff60 08054000 0400 c5ccffb0
> Call Trace:
> [] show_trace_log_lvl+0x1a/0x2f
> [] show_stack_log_lvl+0x9d/0xac
> [] show_registers+0x1f1/0x332
> [] die+0x112/0x247
> [] do_page_fault+0x4ea/0x5c8
> [] error_code+0x72/0x78
> [] proc_cpuset_show+0x5e/0xb9
> [] seq_read+0xef/0x266
> [] vfs_read+0x8e/0x117
> [] sys_read+0x3d/0x61
> [] sysenter_past_esp+0x5f/0x99
> ===
> INFO: lockdep is turned off.
> Code: 00 89 d8 83 c4 0c 5b 5e 5f 5d c3 55 89 e5 57 56 53 83 ec 08 89
> 45 f0 89 55 ec 89 d3 01 cb 8d 43 ff c6 43 ff 00 8b 55 f0 8b 72 1c <8b>
> 56 3c 29 d0 3b 45 ec 72 45 89 d1 c1 e9 02 8b 76 40 89 c7 f3
> EIP: [] container_path+0x20/0x7b SS:ESP 0068:c5ccff00
Ditto, thanks.
-
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 patch] let SUSPEND select HOTPLUG_CPU
Adrian Bunk wrote: > On Sat, Jul 28, 2007 at 12:47:37AM +0200, Stefan Richter wrote: >> Yes, that's the price to pay if you want to select something that in >> turn depends on a number of other things. > > Yes, but a good user interface is worth it. That's right. But a hypothetical other way would be to leave Kconfigs minimal ands put the necessary features into scripts/kconfig. -- Stefan -ENOPATCH 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 07/28/2007 09:35 AM, Rene Herman wrote: By the way -- I'm unable to make my slocate grow substantial here but I'll try what GNU locate does. If it's really as bad as I hear then regardless of anything else it should really be either fixed or dumped... Yes. GNU locate is broken and nobody should be using it. The updatedb from (my distribution standard) "slocate" uses around 2M allocated total during an entire run while GNU locate allocates some 30M to the sort process alone. GNU locate is also close to 4 times as slow (although that ofcourse only matters on cached runs anyways). So, GNU locate is just a pig pushing things out, with or without any added VFS cache pressure from the things it does by design. As such, we can trust people complaining about it but should first tell them to switch to halfway sane locate implementation. If you run memory hogs on small memory boxes, you're going to suffer. Leaves the fact that swap-prefetch sometimes helps alleviate these and other kinds of memory-hog situations and as such, might not (again) be a bad idea in itself. Rene. - 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 patch] SOFTWARE_SUSPEND: handle HOTPLUG_CPU automatically
Adrian Bunk wrote: > On Fri, Jul 27, 2007 at 03:57:39PM -0700, Linus Torvalds wrote: >> [ For extra bonus points: the SUSPEND_POSSIBLE thing is still pretty >> complicated, and it might actually be a better idea to make it a >> per-arch config option, ... > This would give you "trying to assign nonexistent symbol SUSPEND_POSSIBLE" > kconfig warnings on architectures without SUSPEND_POSSIBLE. Unless /all/ architectures define it, of course. -- 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] MIPS: add smp_call_function_single()
On Fri, Jul 27, 2007 at 06:53:23AM -0700, Stephane Eranian wrote:
> Ralf,
>
> Here is take 2.
>
> [MIPS] add smp_call_function_single (take 2)
>
> signed-off-by: Stephane Eranian <[EMAIL PROTECTED]>
> signed-off-by: Phil Mucci <[EMAIL PROTECTED]>
>
> diff --git a/arch/mips/kernel/smp.c b/arch/mips/kernel/smp.c
> index be7362b..d47234c 100644
> --- a/arch/mips/kernel/smp.c
> +++ b/arch/mips/kernel/smp.c
> @@ -193,6 +193,53 @@ void smp_call_function_interrupt(void)
> }
> }
>
> +int smp_call_function_single(int cpu, void (*func) (void *info), void *info,
> int retry,
> + int wait)
> +{
> + struct call_data_struct data;
> + int me = smp_processor_id();
> +
> + /*
> + * Can die spectacularly if this CPU isn't yet marked online
> + */
> + BUG_ON(!cpu_online(me));
> + if (cpu == me) {
> + WARN_ON(1);
> + return -EBUSY;
> + }
> +
> + /* Can deadlock when called with interrupts disabled */
> + WARN_ON(irqs_disabled());
> +
> + data.func = func;
> + data.info = info;
> + atomic_set(, 0);
> + data.wait = wait;
> + if (wait)
> + atomic_set(, 0);
> +
> + spin_lock(_call_lock);
> + call_data =
> + mb();
> +
> + /* Send a message to the other CPU */
> + core_send_ipi(cpu, SMP_CALL_FUNCTION);
> +
> + /* Wait for response */
> + /* FIXME: lock-up detection, backtrace on lock-up */
> + while (atomic_read() != 1)
> + barrier();
> +
> + if (wait)
> + while (atomic_read() != 1)
> + barrier();
> + call_data = NULL;
> + spin_unlock(_call_lock);
> +
> + return 0;
> +}
> +EXPORT_SYMBOL(smp_call_function_single);
> +
> static void stop_this_cpu(void *dummy)
> {
This will not do the right thing. Semantics of smp_call_function_single()
changed recently. It now is supposed to call func() locally with irqs
disabled if cpu == smp_processor_id(). See i386/x86_64 and powerpc.
Unfortunately ia64 hasn't been changed yet, so it will behave differently.
-
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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Sat, 28 Jul 2007, Rene Herman wrote: On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: On Fri, 27 Jul 2007, Rene Herman wrote: > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > > > Questions about it: > > Q) Does swap-prefetch help with this? > > A) [From all reports I've seen (*)] > > Yes, it does. > > No it does not. If updatedb filled memory to the point of causing > swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and > swap-prefetch hasn't any memory to prefetch into -- updatedb itself > doesn't use any significant memory. however there are other programs which are known to take up significant amounts of memory and will cause the issue being described (openoffice for example) please don't get hung up on the text 'updatedb' and accept that there are programs that do run intermittently and do use a significant amount of ram and then free it. Different issue. One that's worth pursueing perhaps, but a different issue from the VFS caches issue that people have been trying to track down. people are trying to track down the problem of their machine being slow until enough data is swapped back in to operate normally. in at some situations swap prefetch can help becouse something that used memory freed it so there is free memory that could be filled with data (which is something that Linux does agressivly in most other situations) in some other situations swap prefetch cannot help becouse useless data is getting cached at the expense of useful data. nobody is arguing that swap prefetch helps in the second cast. what people are arguing is that there are situations where it helps for the first case. on some machines and version of updatedb the nighly run of updatedb can cause both sets of problems. but the nightly updatedb run is not the only thing that can cause problems but let's talk about the concept here for a little bit the design is to use CPU and I/O capacity that's otherwise idle to fill free memory with data from swap. pro: more ram has potentially useful data in it con: it takes a little extra effort to give this memory to another app (the page must be removed from the list and zeroed at the time it's needed, I assume that the data is left in swap so that it doesn't have to be written out again) it adds some complexity to the kernel (~500 lines IIRC from this thread) by undoing recent swapouts it can potentially mask problems with swapout it looks to me like unless the code was really bad (and after 23 months in -mm it doesn't sound like it is) that the only significant con left is the potential to mask other problems. however there are many legitimate cases where it is definantly dong the right thing (swapout was correct in pushing out the pages, but now the cause of that preasure is gone). the amount of benifit from this will vary from situation to situation, but it's not reasonable to claim that this provides no benifit (you have benchmark numbers that show it in synthetic benchmarks, and you have user reports that show it in the real-worlk) there are lots of things in the kernel who's job is to pre-fill the memroy with data that may (or may not) be useful in the future. this is just another method of filling the cache. it does so my saying "the user wanted these pages in the recent past, so it's a reasonable guess to say that the user will want them again in the future" David Lang - 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: serial flow control appears broken
On Fri, Jul 27, 2007 at 12:22:57PM -0600, Robert Hancock wrote: > Maciej W. Rozycki wrote: > > The TTY line discipline driver could do that based on the amount of > >received data present in its buffer. And it should if asked to (a brief > >look at drivers/char/n_tty.c reveals it does; obviously there may be a bug > > Really, where? In my look through the code I haven't found any mechanism > that would result in RTS being lowered based on TTY buffers filling up, > at least not in the 8250 case. That's something for the line discipline to decide. > In this situation, though, it appears it's not the TTY buffers that are > filling but the UART's own buffer. I would think this must be caused by > some kind of interrupt latency that results in not draining the FIFO in > time. Correct, and suggested approach to tracking down the culpret has been mentioned in a previous email. Also note that there's nothing the serial driver can do to detect this condition before it occurs. The problem occurs because the serial driver is starved of CPU time due to other parts of the system, and the driver has precisely zero knowledge as to when that's going to happen. There are two possible scenarios when such starvation can occur: 1. interrupts are disabled for a long period. 2. the serial interrupt has started to run, but has been interrupted by _another_ interrupt which runs for a long period. Essentially, any complex interrupt handler (such as an IDE interrupt doing a multi-sector PIO transfer _in interrupt context_) can cause this kind of starvation. That's why Linux 1.x had bottom halves - so that the time consuming work could be moved out of the interrupt handler, thereby causing minimal the blockage of other interrupts. Unfortunately, that kind of design has been long since forgotten. Apparantly modern machines are fast enough that it doesn't have to be worried about anymore... Or are they? -- 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: serial flow control appears broken
On Fri, Jul 27, 2007 at 09:51:25PM -0700, Lee Howard wrote: > Curiously, the session at 38400 bps that skipped 858 bytes... coincided, > not just in sequence but also in precice timing within the session, with > a small but noticeable disk load that I caused by grepping through a > hundred session logs. (I can't reproduce it easily, though, because of > disk caching.) If you have other parts of the system which run with IRQs disabled for a significant time period, then you will get serial corruption. That's not the serial driver's fault - that's a problem with the other device drivers/rest of the system. You may be table to track down where IRQs are being held off for too long by hooking into the 8250 interrupt handler, and when an overrun error is reported, printk a _minimal_ message reporting the instruction pointer obtained via get_irq_regs(). Note, however, that I don't actively maintain serial anymore. -- 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: -mm merge plans for 2.6.23
Daniel Cheng wrote: > but merging maps2 have higher risk which should be done in a development > branch (er... 2.7, but we don't have it now). This is off-topic and has been discussed to death, but: Rather than one stable branch and one development branch, we have a few stable branches and a lot of development branches. Some are located at git.kernel.org. Among else, this gives you a predictable release rythm and very timely updated stable branches. -- 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: Linus 2.6.23-rc1
On Fri, 2007-07-27 at 19:35 -0700, Linus Torvalds wrote: > > On Sat, 28 Jul 2007, Kasper Sandberg wrote: > > > > Im still not so keen about this, Ingo never did get CFS to match SD in > > smoothness for 3d applications, where my test subjects are quake(s), > > world of warcraft via wine, unreal tournament 2004. And this is despite > > many patches he sent me to try and tweak it. > > You realize that different people get different behaviour, don't you? > Maybe not. Sure. > > People who think SD was "perfect" were simply ignoring reality. Sadly, > that seemed to include Con too, which was one of the main reasons that I > never ended entertaining the notion of merging SD for very long at all: > Con ended up arguing against people who reported problems, rather than > trying to work with them. Im not saying its perfect, not at all, neither am i saying CFS is bad, surely CFS is much better than the old one, and i agree with what that university test you mentioned on kerneltrap says, that CFS and SD is basically impossible to feel difference in, EXCEPT for 3d under load, where CFS simply can not compete with SD, theres no but, this is how it has acted on every system ive tested, and YES, others reported it too, whether you choose to see it or not. and others people who run games on linux tells me the exact same thing, and i have had quite a few people try this. > > Andrew also reported an oops in the scheduler when SD was merged into -mm, > so there were other issues. And whats the point here? If you are trying to pull the old "Con just runs away", forget it, its a certainty that he would have put the required time into fixing whatever issues arise. > > > As far as im concerned, i may be forced to unofficially maintain SD for > > my own systems(allthough lots in the gaming community is bound to be > > interrested, as it does make games lots better) > > You know what? You can do whatever you want to. That's kind of the point > of open source. Keep people honest by having alternatives. True that > > But the the thing is, if you want to do a good job of doing that, here's a > big hint: instead of keeping to your isolated world, instead of just > talking about your own machine and ignoring other peoples machines and First off, i've personally run tests on many more machines than my own, i've had lots of people try on their machines, and i've seen totally unrelated posts to lkml, plus i've seen the experiences people are writing about on IRC. Frankly, im not just thinking of myself. > issues and instead of just denying that problems may exist, and instead of > attacking people who report problems, how about working with them? As i recall, there was only 1 persons reports that were attacked, and that was because the person repeatedly reported the EXPECTED behavior as broken, simply because it was FAIRLY allocating the cpu time, and this did not meet with the dudes expectations. And it was after multiple mails he was "attacked" > > That was where the SD patches fell down. They didn't have a maintainer > that I could trust to actually care about any other issues than his own. You may not have been able to trust Con, but thats because you havent taken the time to actually really see whats been going on, if you just read the threads for SD you'd realize that he was more than willing to maintain it, after all, why do you think he wrote and submitted it? you think he just wrote it to piss you off by having it merged and leave? > > So here's a hint: if you think that your particular graphics card setup is > the only one that matters, it's not going to be very interesting for > anybody else. as explained earlier, its not just my particular setup, but actually that of alot of people, with lots of different hardware. > > > [ I realize that this comes as a shock to some of the SD people, but I'm > told that there was a university group that did some double-blind > testing of the different schedulers - old, SD and CFS - and that > everybody agreed that both SD and CFS were better than the old, but that > there was no significant difference between SD and CFS. You can try > asking Thomas Gleixner for more details. ] > > I'm happy that SD was perfect for you. It wasn't for others, and it had > nobody who was even interested in trying to solve those issues. > > As a long-term maintainer, trust me, I know what matters. And a person who > can actually be bothered to follow up on problem reports is a *hell* of a > lot more important than one who just argues with reporters. Okay, i wasnt going to ask, but ill do it anyway, did you even read the threads about SD? Con was extremely polite to everyone, and he did work with a multitude of people, you seem to be totally deadlocked into the ONE incident with a person that was unhappy with SD, simply for being a fair scheduler. > > Linus > - > To unsubscribe from this list: send the line "unsubscribe
Re: [PATCH 2/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe
Hi Neil,
thanks a lot for your work on this!
Neil Horman [2007-07-27 16:08 -0400]:
> Hey
> Patch 2/3 of my core_pattern enhancements. This patch is a rewrite of
> my previous post for this enhancement. It uses jeremy's split_argv/free_argv
> library functions to translate core_pattern into an argv array to be passed to
> the user mode helper process.
> [...]
> if (ispipe) {
> core_limit = RLIM_INFINITY;
> + helper_argv = argv_split(GFP_KERNEL, corename+1, _argc);
I just want to mention a potential problem with this: If you first
expand the macros (from pattern to corename) and then split corename
into an argv, then this breaks macro expansions containing spaces.
This mostly affects the executable name, of course.
In fact we considered this macro approach when doing the original
patches in the Ubuntu kernel, but we eventually used environment
variables because they are much easier and more robust to implement
than doing a robust macro expansion (i. e. first split core_pattern
into an argv and then call the macro expansion for each element).
I would love to use macros instead since it looks a bit cleaner, and
personally I do not care about the "executable name" macro for Apport
[1] (I grab it from /proc/pid/exe), but I wanted to mention this
possible caveat before it goes upstream.
Thank you,
Martin
[1] https://wiki.ubuntu.com/Apport
--
Martin Pitthttp://www.piware.de
Ubuntu Developer http://www.ubuntu.com
Debian Developer http://www.debian.org
signature.asc
Description: Digital signature
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 07/28/2007 10:55 AM, [EMAIL PROTECTED] wrote: in at some situations swap prefetch can help becouse something that used memory freed it so there is free memory that could be filled with data (which is something that Linux does agressivly in most other situations) in some other situations swap prefetch cannot help becouse useless data is getting cached at the expense of useful data. nobody is arguing that swap prefetch helps in the second cast. Oh yes they are. Daniel for example did twice, telling me to turn my brain on in between (if you read it, you may have noticed I got a little annoyed at that point). but let's talk about the concept here for a little bit the design is to use CPU and I/O capacity that's otherwise idle to fill free memory with data from swap. pro: more ram has potentially useful data in it con: it takes a little extra effort to give this memory to another app (the page must be removed from the list and zeroed at the time it's needed, I assume that the data is left in swap so that it doesn't have to be written out again) It is. Prefetched pages can be dropped on the floor without additional I/O. it adds some complexity to the kernel (~500 lines IIRC from this thread) by undoing recent swapouts it can potentially mask problems with swapout it looks to me like unless the code was really bad (and after 23 months in -mm it doesn't sound like it is) Not to sound pretentious or anything but I assume that Andrew has a fairly good overview of exactly how broken -mm can be at times. How many -mm users use it anyway? He himself said he's not convinced of usefulness having not seen it help for him (and notice that most developers are also users), turned it off due to it annoying him at some point and hasn't seen a serious investigation into potential downsides. that the only significant con left is the potential to mask other problems. Which is not a madeup issue, mind you. As an example, I just now tried GNU locate and saw it's a complete pig and specifically unsuitable for the low memory boxes under discussion. Upon completion, it actually frees enough memory that swap-prefetch _could_ help on some boxes, while the real issue is that they should first and foremost dump GNU locate. however there are many legitimate cases where it is definantly dong the right thing (swapout was correct in pushing out the pages, but now the cause of that preasure is gone). the amount of benifit from this will vary from situation to situation, but it's not reasonable to claim that this provides no benifit (you have benchmark numbers that show it in synthetic benchmarks, and you have user reports that show it in the real-worlk) I certainly would not want to argue anything of the sort no. As said a few times, I agree that swap-prefetch makes sense and has at least the potential to help some situations that you really wouldnt even want to try and fix any other way, simply because nothing's broken. there are lots of things in the kernel who's job is to pre-fill the memroy with data that may (or may not) be useful in the future. this is just another method of filling the cache. it does so my saying "the user wanted these pages in the recent past, so it's a reasonable guess to say that the user will want them again in the future" Well, _that_ is what the kernel is already going to great lengths at doing, and it decided that those pages us poor overnight OO.o users want in in the morning weren't reasonable guesses. The kernel also won't any time soon be reading our minds, so any solution would need either user intervention (we could devise a way to tell the kernel "hey ho, I consider these pages to be very important -- try not to swap them out" possible even with a "and if you do, please pull them back in when possible") or we can let swap-prefetch do the "just in case" thing it is doing. While swap-prefetch may not be the be all end all of solutions I agree that having a machine sit around with free memory and applications in swap seems not too useful if (as is the case) fetched pages can be dropped immediately when it turns out swap-prefetch made the wrong decision. So that's for the concept. As to implementation, if I try and look at the code, it seems to be trying hard to really be free and as such, potential downsides seem limited. It's a rather core concept though and as such needs someone with a _lot_ more VM clue to ack. Sorry for not knowing, but who's maintaining/submitting the thing now that Con's not? He or she should preferably address any concerns it seems. Rene. - 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: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Linus Torvalds: > On Sat, 28 Jul 2007, Kasper Sandberg wrote: > > Im still not so keen about this, Ingo never did get CFS to match SD > > in smoothness for 3d applications, where my test subjects are > > quake(s), world of warcraft via wine, unreal tournament 2004. And > > this is despite many patches he sent me to try and tweak it. [...] > I'm happy that SD was perfect for you. It wasn't for others, and it had > nobody who was even interested in trying to solve those issues. Linus, I seen somethimg *completely* different on the CK mailinglist. Con Koliva worked up to his limits and likely beyond them to fix any and all issues reported. Heck, he maintained that thing out of the kernel tree for a long time and the version number 1.0 does not come from nothing, it has gone through at least 50 iterations. The only thing I know of where Con did not want to "fix" a problem, was with renicing X, cause he didn't want to introduce a special case in the scheduler, where a simple nice would do the trick. That said I never saw serious problems with X unreniced at all. So I think your statements here are simply not accurate and also not fair, cause I have the impression that you did not look carefully before writing them. You speak about working together, but now I ask you: Did you ever have a personal word with Con, did you ever tell him that you don't trust that he can maintain the SD scheduler when its mainline? Did you ever outspoke your concerns to *him*? Granted, from a health point of view and maybe also from looking at how much time a maintainer will be able to spend more time on the scheduler Ingo *may* can do more than Con - if he doesn't do too much else;-). But looking at personal committment actually I saw no difference between Con and Ingo. So while it may be good that CFS went in from that point of view, the way the decision was made was very suitable to piss off a very talented developer. Anyway, the decision is done, Con resigned already, he gave up on it. And actually when I read your mail I can understand why he did so[1]. Sure, he is involved as well and I think he felt hurt on some things that in my perception were meant neutral or even supporting and postive, but still I disagree a lot on the tone in LKML and understand exactly why Linux users, Linux desktop users away from it as much as they can. Actually I do not get that as you state in one of your latest interviews that you are actually very interested into the desktop, cause its a very suitable kernel test case[2]. Well I for sure will patch whatever into my kernels that I think should be in there for me to have a *pleasant* desktop experience, including, but not limited to, TuxOnIce ;-). Oh, but that might possibly not be mainted nicely enough as well then. (Yes, here is sarcastic irony, lots of it. So no offence intended, Nigel;-) [1] http://apcmag.com/6735/interview_con_kolivas [2] http://www.oneopensource.it/interview-linus-torvalds/ Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 signature.asc Description: This is a digitally signed message part.
Re: [ck] Re: Linus 2.6.23-rc1
Am Samstag 28 Juli 2007 schrieb Matthew Hawkins: > On 7/28/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > > People who think SD was "perfect" were simply ignoring reality. > > Sadly, that seemed to include Con too, which was one of the main > > reasons that I never ended entertaining the notion of merging SD for > > very long at all: Con ended up arguing against people who reported > > problems, rather than trying to work with them. > > Not even Con thought SD was perfect, so this is being more than a > little dishonest. > One of his parting comments on the ck list was a list of things that > could be fixed/improved. [...] > I'm sorry you in particular haven't been able to have the same > experience with Con as so many others have, especially considering who > you are and the weight your words have. You've lost a really great > asset and aren't even aware of it. That's really sad for everyone. > > (fwiw the -ck list did a lot of the testing for CFS recently, and over > the years various other things too. Generally a good bunch of folks > keen to try anything to make their Linux experience better. And > definitely devoid of these petty politics and egos that are plagueing > other Linux-related lists. You've not only lost Con, but perhaps one > of the better testbeds also). I fully agree to this. Being part of the ck mailing list community was fun and I really appreciate the friendly and supporting tone here. From the mails I ever read from the LKML - I do not read it regularily at all - I got the impression that its members can learn *a lot* from the ck mailing list community. And also from the TuxOnNice mailing list community. For example on how to encourage users to send in their feedback and test kernel subsystems. And from what I heard again and again its exactly testing that is lacking to a great degree. Actually even CFS was helped by the ck mailinglist community. The tone on the ck mailinglist community encouraged me to compile kernel patches, try out latest ck patchsets and then when CFS could not do the same smooth music playback on my Amarok machine than SD try out a ton of patches from Ingo Molnar to get those regressions (compared to SD) fixed. But all the times I stayed away from LKML and still do not feel that much motivation to read in it regularily. Actually my own perceptions matches what Con said in his goodbye interview[1]: It *scares* me away. Its this elitist "I know it better than you and what do you want anyway" that in my eyes demotivate a lot of users to bring in their feedback. There are just about 9000 bugs in the kernel bugtracker and about 15 bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of applications, but still I think the number of bug reports in the kernel bugtracker is ridicolously low. And I think thats because many users don't bother to report bugs upstream for the Linux kernel, not because that those bugs aren't there. I hope that the ck mailing list community will continue to be active and possibly try to get swap prefetch and some other goodies of the ck patchset into mainline. And I think it would also be a good idea for ck mailing list community to report desktop related issues in the kernel bugtracker. I think I will take the courage next time I find anything, and report it straight there. Maybe some talented developer will take up on the ck patchset and maybe once in a while he will find a friendlier environment to merge in parts of the ck patchset that should have gone mainline years ago. Maybe at least that is learned out of what happened here. I do think that a *friendly* tone matters and makes a difference. Being friendly and honestly saying the own oppinion on technical matters simply do not have to contradict themselves. Still I got the impression that some do think "Either I say it harsh and true or I be friendly and lie what goes". [1] http://apcmag.com/6735/interview_con_kolivas Regards, -- Martin 'Helios' Steigerwald - http://www.Lichtvoll.de GPG: 03B0 0D6C 0040 0710 4AFA B82F 991B EAAC A599 84C7 - 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: [ck] Re: Linus 2.6.23-rc1
Up till now i haven't read the interview with Linus. > [2] http://www.oneopensource.it/interview-linus-torvalds/ > It is interesting, he mentiones a lesson to learn from Microsoft: "'Well, historically, the most important lesson from Microsoft - and one they themselves seem to have forgotten - is simply 'Give your customers what they want'." But as i see all the discussion here that's what's _not_ being honored. People request swap prefetch, it wouldn't be hard to give it to them but they probably won't get it (or it takes a 5 days, 200+ messages discussion(in the ck list alone were already 190 messages posted about this)). Give the people plugshed so everyone can happily be using SD instead of CFS - no way! There sure are more examples to be given. Dirk. signature.asc Description: This is a digitally signed message part.
Re: How can we make page replacement smarter (was: swap-prefetch)
Chris Snook wrote: > Al Boldi wrote: > > Because it is hard to quantify the expected swap-in speed for random > > pages, let's first tackle the swap-in of consecutive pages, which should > > be at least as fast as swap-out. So again, why is swap-in so slow? > > If I'm writing 20 pages to swap, I can find a suitable chunk of swap and > write them all in one place. If I'm reading 20 pages from swap, they > could be anywhere. Also, writes get buffered at one or more layers of > hardware. Ok, this explains swap-in of random pages. Makes sense, but it doesn't explain the awful tmpfs performance degradation of consecutive read-in runs from swap, which should have at least stayed constant > At best, reads can be read-ahead and cached, which is why > sequential swap-in sucks less. On-demand reads are as expensive as I/O > can get. Which means that it should be at least as fast as swap-out, even faster because write to disk is usually slower than read on modern disks. But linux currently shows a distinct 2x slowdown for sequential swap-in wrt swap-out. And to prove this point, just try suspend to disk where you can see sequential swap-out being reported at about twice the speed of sequential swap-in on resume. Why is that? Thanks! -- Al - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
> It is. Prefetched pages can be dropped on the floor without additional I/O. Which is essentially free for most cases. In addition your disk access may well have been in idle time (and should be for this sort of stuff) and if it was in the same chunk as something nearby was effectively free anyway. Actual physical disk ops are precious resource and anything that mostly reduces the number will be a win - not to stay swap prefetch is the right answer but accidentally or otherwise there are good reasons it may happen to help. Bigger more linear chunks of writeout/readin is much more important I suspect than swap prefetching. > good overview of exactly how broken -mm can be at times. How many -mm users > use it anyway? He himself said he's not convinced of usefulness having not I've been using it for months with no noticed problem. I turn it on because it might as well get tested. I've not done comparison tests so I can't comment on if its worth it. Lots of -mm testers turn *everything* on because its a test kernel. - 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: How to register block device as read-only
On Fri, 2007-07-27 at 13:07 -0500, [EMAIL PROTECTED] wrote: > Hello, > > In a block device driver, how do you tell the kernel that your block device > is read-only? Is it in the registration of the gendisk, or is there an > ioctl I should be catching to inform the kernel (and user) that this disk > is read-only? Unless I misunderstand the question, the "write" and "writev" function of the "struct file_operations" should return an appropriate error value (which is here -EACCES). You may think of returning an error in the "open" if someone wants to open it to write to it (so that the must open it read-only). But I don't know if that is common practice or not (or even disliked) as it may interfere with not properly implemented tools which open devices read-write even if they never write to it. Bernd -- Firmix Software GmbH http://www.firmix.at/ mobil: +43 664 4416156 fax: +43 1 7890849-55 Embedded Linux Development and Services - 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: How to register block device as read-only
On Jul 28 2007 13:36, Bernd Petrovitsch wrote: > >Unless I misunderstand the question, the "write" and "writev" function >of the "struct file_operations" should return an appropriate error value >(which is here -EACCES). >You may think of returning an error in the "open" if someone wants to >open it to write to it (so that the must open it read-only). >But I don't know if that is common practice or not (or even disliked) as >it may interfere with not properly implemented tools which open devices >read-write even if they never write to it. Yes it is, I believe. When mount(8) gets an error from mount(2), it retries with MS_RDONLY enabled. 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/
zd1211b question.
Greetings all;
A net friend of mine has a Gateway m305CRV laptop, with this radio in it:
Bus 003 Device 003: ID 050d:705c Belkin Components
Its apparently sitting on the usb bus, and from my grepping of the kernel
srcs, it looks as if the zd1211b driver might be the correct one:
drivers/net/wireless/zd1211rw/zd_usb.c: /* ZD1211B */
drivers/net/wireless/zd1211rw/zd_usb.c: { USB_DEVICE(0x0ace,
0x1215), .driver_info = DEVICE_ZD1211B },
drivers/net/wireless/zd1211rw/zd_usb.c: { USB_DEVICE(0x157e,
0x300d), .driver_info = DEVICE_ZD1211B },
drivers/net/wireless/zd1211rw/zd_usb.c: { USB_DEVICE(0x079b,
0x0062), .driver_info = DEVICE_ZD1211B },
drivers/net/wireless/zd1211rw/zd_usb.c: { USB_DEVICE(0x1582,
0x6003), .driver_info = DEVICE_ZD1211B },
drivers/net/wireless/zd1211rw/zd_usb.c: { USB_DEVICE(0x050d,
0x705c), .driver_info = DEVICE_ZD1211B },
This last one is the right set of numbers. However, I'll be dipped but I
can't find anyplace in a make xconfig in the 2.6.22.1-rt9 tree, to turn on
the building of that driver.
Am I blind, don't know how to run grep, or does the xconfig script need more
tlc?
Can somebody toss me a bone of info here?
Thanks everybody.
--
Cheers, Gene
"There are four boxes to be used in defense of liberty:
soap, ballot, jury, and ammo. Please use in that order."
-Ed Howdershelt (Author)
Thus spake the master programmer:
"When a program is being tested, it is too late to make design changes."
-- Geoffrey James, "The Tao of Programming"
-
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: serial flow control appears broken
> Curiously, the session at 38400 bps that skipped 858 bytes... coincided, > not just in sequence but also in precice timing within the session, with > a small but noticeable disk load that I caused by grepping through a > hundred session logs. (I can't reproduce it easily, though, because of > disk caching.) Can you send me a dmesg, there are some cases when high disk load can cause high interrupt latency in both 2.2 and 2.6 depending upon what is configured. I don't think thats related to the main problem but it is worth knowing about hdparm -u1 > as it leaves the DCE. I mention this in case there is any limitation to > how the 8250 driver performs when two modems are being run simultaneously. It means more load but that shouldn't matter much, and the transmit side if under load with asynchronous traffic will not lose bytes sending. 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/
Re: Problems with reading DVD using 2.6.21.5
Hello, I tried to reproduce this bug by mounting/unmounting the drive several times. It seems like this problem is caused, if the drive is at speed 0 after some time without access. In this situation, sometimes the drive seems to take a bit longer to speed up. Whenever it takes a bit longer, I get the error in dmesg and parts of the mounted disc are unreadable... Any chance to get this debugged? CU Manuel - 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: Volanomark slows by 80% under CFS
On 28/07/07, Tim Chen <[EMAIL PROTECTED]> wrote: > [ ... ] > It may make sense to queue the > yielding process a bit further behind in the queue. > I made a slight change by zeroing out wait_runtime > (i.e. have the process gives > up cpu time due for it to run) for experimentation. But that's wrong. The 'wait_runtime' might have been negative at this point (i.e. a task is in the negative 'run-time' balance wrt the 'etalon' nice-0 task). Your change ends up helping such a task to actually stay closer to the 'left most' element of the tree (or to be it) and not "further behind in the queue" as your intention is. I don't know Volanomark's details so refrain from speculating on why this change "improves" benchmark results indeed (maybe some afected tasks have positive 'wait_runtime's on average for this setup). If you want to make sure (just for a test) a yeilding task is not the left-most (at least) for some short interval of time (likely to be <= 1 tick), take a look at yield_task_fair() in e.g. cfs-v15. > Volanomark runs better > and is only 40% (instead of 80%) down from old scheduler > without CFS. 40 or 80 % is still a huge regression. > > Regards, > Tim > -- Best regards, Dmitry Adamushko - 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/
BSG: BLK_DEV_BSG=y , BLOCK=n compile error
Hi, BSG does not compile without BLOCK set : ... block/bsg.c: In function 'blk_fill_sgv4_hdr_rq': block/bsg.c:186: error: 'BLK_MAX_CDB' undeclared (first use in this function) block/bsg.c:186: error: (Each undeclared identifier is reported only once block/bsg.c:186: error: for each function it appears in.) block/bsg.c:186: error: dereferencing pointer to incomplete type block/bsg.c:186: error: dereferencing pointer to incomplete type block/bsg.c:186: error: dereferencing pointer to incomplete type block/bsg.c:186: error: dereferencing pointer to incomplete type block/bsg.c:188: error: dereferencing pointer to incomplete type block/bsg.c:193: error: implicit declaration of function 'blk_verify_command' block/bsg.c:193: error: dereferencing pointer to incomplete type block/bsg.c:201: error: dereferencing pointer to incomplete type block/bsg.c:202: error: dereferencing pointer to incomplete type block/bsg.c:202: error: 'REQ_TYPE_BLOCK_PC' undeclared (first use in this function) block/bsg.c:204: error: dereferencing pointer to incomplete type block/bsg.c:205: error: dereferencing pointer to incomplete type block/bsg.c:206: error: dereferencing pointer to incomplete type block/bsg.c:206: error: dereferencing pointer to incomplete type block/bsg.c:207: error: dereferencing pointer to incomplete type block/bsg.c:208: error: dereferencing pointer to incomplete type block/bsg.c:208: error: 'BLK_DEFAULT_SG_TIMEOUT' undeclared (first use in this function) block/bsg.c: In function 'bsg_validate_sgv4_hdr': block/bsg.c:223: error: 'BLK_MAX_CDB' undeclared (first use in this function) block/bsg.c:225: error: dereferencing pointer to incomplete type block/bsg.c:226: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_map_hdr': block/bsg.c:270: error: implicit declaration of function 'blk_get_request' block/bsg.c:270: warning: assignment makes pointer from integer without a cast block/bsg.c:279: error: 'QUEUE_FLAG_BIDI' undeclared (first use in this function) block/bsg.c:279: error: dereferencing pointer to incomplete type block/bsg.c:279: error: dereferencing pointer to incomplete type block/bsg.c:284: warning: assignment makes pointer from integer without a cast block/bsg.c:289: error: dereferencing pointer to incomplete type block/bsg.c:292: error: implicit declaration of function 'blk_rq_map_user' block/bsg.c:313: error: implicit declaration of function 'blk_put_request' block/bsg.c:315: error: implicit declaration of function 'blk_rq_unmap_user' block/bsg.c:315: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_rq_end_io': block/bsg.c:327: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_add_command': block/bsg.c:351: error: dereferencing pointer to incomplete type block/bsg.c:352: error: dereferencing pointer to incomplete type block/bsg.c:358: error: dereferencing pointer to incomplete type block/bsg.c:359: error: dereferencing pointer to incomplete type block/bsg.c:360: error: dereferencing pointer to incomplete type block/bsg.c:368: error: dereferencing pointer to incomplete type block/bsg.c:369: error: implicit declaration of function 'blk_execute_rq_nowait' block/bsg.c: In function 'blk_complete_sgv4_hdr_rq': block/bsg.c:426: error: dereferencing pointer to incomplete type block/bsg.c:427: error: dereferencing pointer to incomplete type block/bsg.c:428: error: dereferencing pointer to incomplete type block/bsg.c:432: error: dereferencing pointer to incomplete type block/bsg.c:435: error: dereferencing pointer to incomplete type block/bsg.c:436: error: dereferencing pointer to incomplete type block/bsg.c:440: error: dereferencing pointer to incomplete type block/bsg.c:447: error: dereferencing pointer to incomplete type block/bsg.c:449: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_put_device': block/bsg.c:723: error: implicit declaration of function 'blk_put_queue' block/bsg.c: In function 'bsg_add_device': block/bsg.c:745: error: dereferencing pointer to incomplete type block/bsg.c:753: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_ioctl': block/bsg.c:884: error: implicit declaration of function 'scsi_cmd_ioctl' block/bsg.c:898: error: dereferencing pointer to incomplete type block/bsg.c:899: error: dereferencing pointer to incomplete type block/bsg.c:900: error: dereferencing pointer to incomplete type block/bsg.c:901: error: implicit declaration of function 'blk_execute_rq' block/bsg.c: In function 'bsg_unregister_queue': block/bsg.c:933: error: dereferencing pointer to incomplete type block/bsg.c:939: error: dereferencing pointer to incomplete type block/bsg.c: In function 'bsg_register_queue': block/bsg.c:967: error: dereferencing pointer to incomplete type block/bsg.c:970: error: dereferencing pointer to incomplete type block/bsg.c:1005: error: dereferencing pointer to incomplete type block/bsg.c:1006: error: dereferencing pointer to incomplete type
[PATCH] fix IDE legacy mode resource
Hi,
I got the following error on MIPS Cobalt.
MIPS Cobalt has the 0x1000 offset between resource and bus region.
PCI: Unable to reserve I/O region #1:[EMAIL PROTECTED] for device :00:09.1
pata_via :00:09.1: failed to request/iomap BARs for port 0 (errno=-16)
PCI: Unable to reserve I/O region #3:[EMAIL PROTECTED] for device :00:09.1
pata_via :00:09.1: failed to request/iomap BARs for port 1 (errno=-16)
pata_via :00:09.1: no available native port
At this point, these resources should be the bus regions.
Signed-off-by: Yoichi Yuasa <[EMAIL PROTECTED]>
diff -pruN -X generic/Documentation/dontdiff generic-orig/drivers/pci/probe.c
generic/drivers/pci/probe.c
--- generic-orig/drivers/pci/probe.c2007-07-26 17:07:44.151670750 +0900
+++ generic/drivers/pci/probe.c 2007-07-26 17:25:42.227046250 +0900
@@ -744,22 +744,40 @@ static int pci_setup_device(struct pci_d
*/
if (class == PCI_CLASS_STORAGE_IDE) {
u8 progif;
+ struct pci_bus_region region;
+ struct resource resource;
pci_read_config_byte(dev, PCI_CLASS_PROG, );
if ((progif & 1) == 0) {
- dev->resource[0].start = 0x1F0;
- dev->resource[0].end = 0x1F7;
- dev->resource[0].flags = LEGACY_IO_RESOURCE;
- dev->resource[1].start = 0x3F6;
- dev->resource[1].end = 0x3F6;
- dev->resource[1].flags = LEGACY_IO_RESOURCE;
+ resource.start = 0x1F0;
+ resource.end = 0x1F7;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[0].start = region.start;
+ dev->resource[0].end = region.end;
+ dev->resource[0].flags = resource.flags;
+ resource.start = 0x3F6;
+ resource.end = 0x3F6;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[1].start = region.start;
+ dev->resource[1].end = region.end;
+ dev->resource[1].flags = resource.flags;
}
if ((progif & 4) == 0) {
- dev->resource[2].start = 0x170;
- dev->resource[2].end = 0x177;
- dev->resource[2].flags = LEGACY_IO_RESOURCE;
- dev->resource[3].start = 0x376;
- dev->resource[3].end = 0x376;
- dev->resource[3].flags = LEGACY_IO_RESOURCE;
+ resource.start = 0x170;
+ resource.end = 0x177;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[2].start = region.start;
+ dev->resource[2].end = region.end;
+ dev->resource[2].flags = resource.flags;
+ resource.start = 0x376;
+ resource.end = 0x376;
+ resource.flags = LEGACY_IO_RESOURCE;
+ pcibios_resource_to_bus(dev, ,
);
+ dev->resource[3].start = region.start;
+ dev->resource[3].end = region.end;
+ dev->resource[3].flags = resource.flags;
}
}
break;
-
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 10/68] 0 -> NULL, for arch/mips
Usually it's not only cleaner, it's what you want to do... AFAIK
'NULL' is implemented/defined by the compiler, so if you've got a
compiler which defines NULL otherwise than( a pointer to) zero you're
screwed. ;)
//Markus
On 27 Jul, 2007, at 11:45 , Yoann Padioleau wrote:
When comparing a pointer, it's clearer to compare it to NULL than
to 0.
Here is an excerpt of the semantic patch:
@@
expression *E;
@@
E ==
- 0
+ NULL
@@
expression *E;
@@
E !=
- 0
+ NULL
Signed-off-by: Yoann Padioleau <[EMAIL PROTECTED]>
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
Cc: [EMAIL PROTECTED]
---
ops-emma2rh.c |2 +-
ops-pnx8550.c | 12 ++--
2 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/arch/mips/pci/ops-emma2rh.c b/arch/mips/pci/ops-emma2rh.c
index 38f1816..d31bfc6 100644
--- a/arch/mips/pci/ops-emma2rh.c
+++ b/arch/mips/pci/ops-emma2rh.c
@@ -45,7 +45,7 @@ static int check_args(struct pci_bus *bu
/* check if the bus is top-level */
if (bus->parent != NULL) {
*bus_num = bus->number;
- db_assert(bus_num != 0);
+ db_assert(bus_num != NULL);
} else
*bus_num = 0;
diff --git a/arch/mips/pci/ops-pnx8550.c b/arch/mips/pci/ops-pnx8550.c
index f556b7a..d610646 100644
--- a/arch/mips/pci/ops-pnx8550.c
+++ b/arch/mips/pci/ops-pnx8550.c
@@ -117,7 +117,7 @@ read_config_byte(struct pci_bus *bus, un
unsigned int data = 0;
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
err = config_access(PCI_CMD_CONFIG_READ, bus, devfn, where, ~(1
<< (where & 3)), );
@@ -145,7 +145,7 @@ read_config_word(struct pci_bus *bus, un
unsigned int data = 0;
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
if (where & 0x01)
@@ -168,7 +168,7 @@ static int
read_config_dword(struct pci_bus *bus, unsigned int devfn, int
where, u32 * val)
{
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
if (where & 0x03)
@@ -185,7 +185,7 @@ write_config_byte(struct pci_bus *bus, u
unsigned int data = (unsigned int)val;
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
switch (where & 0x03) {
@@ -213,7 +213,7 @@ write_config_word(struct pci_bus *bus, u
unsigned int data = (unsigned int)val;
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
if (where & 0x01)
@@ -235,7 +235,7 @@ static int
write_config_dword(struct pci_bus *bus, unsigned int devfn, int
where, u32 val)
{
int err;
- if (bus == 0)
+ if (bus == NULL)
return -1;
if (where & 0x03)
___
Mr Markus Gothe
Software Engineer
Phone: +46 (0)13 21 81 20 (ext. 1046)
Fax: +46 (0)13 21 21 15
Mobile: +46 (0)73 718 72 80
Diskettgatan 11, SE-583 35 Linköping, Sweden
www.27m.com
PGP.sig
Description: This is a digitally signed message part
Re: [ck] Re: Linus 2.6.23-rc1
On 7/27/07, Linus Torvalds <[EMAIL PROTECTED]> wrote: > Con ended up arguing against people who reported problems, rather than > trying to work with them. I do recall there is one issue on which Con wouldn't budge -- anything that involved boosting certain kinds of processes in the kernel. He said that it would defeat the whole point of the way he had designed it, and that nicing could work just as well. Perhaps there could have been a better way of handling that issue, such as adding (yet another) kernel compilation configuration option for this code (since Con didn't believe it would help all users). > Andrew also reported an oops in the scheduler when SD was merged into -mm, > so there were other issues. I don't know how you can blame Con for not finding a PPC oops before SD was merged into -mm, considering he seemed to be coding solely on an x86-based architecture. Of course, you could say that his design should have factored in all the architectures and such, but even the best design can fall apart if it doesn't get tested somewhere. Again, this is probably a subjective case in that Con might have pushed SD to -mm rather early; but considering the readership of his -ck list, I don't think it would have been tested on anything other than X86 until it went into -mm because I've ever seen anyone on -ck report "it works on ". I don't know what made it on to other lists, but Con tried his best to fix this oops, and unless it was done privately, this oops was never re-reported. (Now, if SD was _STILL_ causing this oops on PPC, I can see how this might be a concern.) > > As far as im concerned, i may be forced to unofficially maintain SD for > > my own systems(allthough lots in the gaming community is bound to be > > interrested, as it does make games lots better) > > You know what? You can do whatever you want to. That's kind of the point > of open source. Keep people honest by having alternatives. > > But the the thing is, if you want to do a good job of doing that, here's a > big hint: instead of keeping to your isolated world, instead of just > talking about your own machine and ignoring other peoples machines and > issues and instead of just denying that problems may exist, and instead of > attacking people who report problems, how about working with them? > > That was where the SD patches fell down. They didn't have a maintainer > that I could trust to actually care about any other issues than his own. So if we found a better maintainer who would commit to maintaining the SD patches, would you still be willing to consider merging them? Is this what you're saying? > I'm happy that SD was perfect for you. It wasn't for others, and it had > nobody who was even interested in trying to solve those issues. -- Michael Chang Please avoid sending me Word or PowerPoint attachments. Send me ODT, RTF, or HTML instead. See http://www.gnu.org/philosophy/no-word-attachments.html Thank you. - 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] Documentation: document HFSPlus
Hi Randy, > >> --- >> >> Patched against 2.6.22.1 > > FYI: Patches should be against the latest -rc or -git (when > available), but it probably doesn't matter in this case. > Thanks for the tip and corrections. Here's the latest. From: Wyatt Banks <[EMAIL PROTECTED]> Documentation: document HFSPlus filesystem and its mount options. Signed-off-by: Wyatt Banks <[EMAIL PROTECTED]> diff -uprN linux-2.6.23-rc1/Documentation/filesystems/hfsplus.txt linux-2.6.23-rc1-devel/Documentation/filesystems/hfsplus.txt --- linux-2.6.23-rc1/Documentation/filesystems/hfsplus.txt 1969-12-31 19:00:00.0 -0500 +++ linux-2.6.23-rc1-devel/Documentation/filesystems/hfsplus.txt 2007-07-28 09:14:46.0 -0400 @@ -0,0 +1,59 @@ + +Macintosh HFSPlus Filesystem for Linux +== + +HFSPlus is a filesystem first introduced in MacOS 8.1. +HFSPlus has several extensions to HFS, including 32-bit allocation +blocks, 255-character unicode filenames, and file sizes of 2^63 bytes. + + +Mount options += + +When mounting an HFSPlus filesystem, the following options are accepted: + + creator=, type= + Specifies the creator/type values as shown by the MacOS finder + used for creating new files. Default values: ''. + + uid=n, gid=n + Specifies the user/group that owns all files on the filesystem + that have uninitialized permissions structures. + Default: user/group id of the mounting process. + + umask=n + Specifies the umask (in octal) used for files and directories + that have uninitialized permissions structures. + Default: umask of the mounting process. + + session=n + Select the CDROM session to mount as HFSPlus filesystem. Defaults to + leaving that decision to the CDROM driver. This option will fail + with anything but a CDROM as underlying devices. + + part=n + Select partition number n from the devices. This option only makes + sense for CDROMs because they can't be partitioned under Linux. + For disk devices the generic partition parsing code does this + for us. Defaults to not parsing the partition table at all. + + decompose + Decompose file name characters. + + nodecompose + Do not decompose file name characters. + + force + Used to force write access to volumes that are marked as journalled + or locked. Use at your own risk. + + nls= + Encoding to use when presenting file names. + + +References +== + +kernel source: + +Apple Technote 1150http://developer.apple.com/technotes/tn/tn1150.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: Volanomark slows by 80% under CFS
On 28/07/07, Chris Snook <[EMAIL PROTECTED]> wrote: > [ ... ] > Under CFS, the yielding process will still be leftmost in the rbtree, > otherwise it would have already been scheduled out. Not actually true. The position of the 'current' task within the rb-tree is updated with a timer tick's frequency. Being called somewhere in between 2 ticks, sched_yield() may trigger a reschedule which would otherwise take place upon the next tick. Moreover, 'scheduling granularity' may also take effect. e.g. effectively, the yielding task's 'fair_key' was already != 'left_most' upon the previous timer tick but an actual reschedule has been delayed due to the 'scheduling granularity' taking effect... and sched_yield() may trigger it. > Zeroing out wait_runtime on sched_yield strikes me as completely appropriate. > If the process wanted to sleep a finite duration, it should actually call a > sleep function, but sched_yield is essentially saying "I don't have anything > else to do right now", so it's hardly fair to claim you've been waiting for > your > chance when you just gave it up. 'wait_runtime' describes dynamic behavior of a task on the rq. It doesn't matter what the task is about to do as 'wait_runtime' is something it fully deserves. Note, 'wait_runtime' can be both positive and negative, meaning credit/punishment appropriately. When it's negative, 'zeroing it out' effectively means the task gets helped -- in the sense that it doen't get 'punished' for some amount of time it actually spent running. Which is wrong. One more thing: we don't take time accounted to 'wait_runtime' just from the thin air. e.g. sleepers get an additional bonus to their 'wait_runtime' upon a wakeup _but_ the amount of "wait_runtime" == "a given bonus" will be additionally substracted from tasks which happen to run later on (grep for "sleeper_bonus" in sched_fair.c). That said, the sum (of additionally given/taken wait_runtime) is zero. All in all, I doubt the "zeroing out wait_runtime on sched_yield" thing is really appropriate. > > -- Chris > -- Best regards, Dmitry Adamushko - 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: zd1211b question.
On Jul 28 2007 07:55, Gene Heskett wrote: >Greetings all; > >A net friend of mine has a Gateway m305CRV laptop, with this radio in it: >Bus 003 Device 003: ID 050d:705c Belkin Components > >Its apparently sitting on the usb bus, and from my grepping of the kernel >srcs, it looks as if the zd1211b driver might be the correct one: >[...] >This last one is the right set of numbers. However, I'll be dipped but I >can't find anyplace in a make xconfig in the 2.6.22.1-rt9 tree, to turn on >the building of that driver. > >Am I blind, don't know how to run grep, or does the xconfig script need more >tlc? > >Can somebody toss me a bone of info here? cat drivers/net/wireless/zd1211rw/Kconfig? 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 2/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe
On Sat, Jul 28, 2007 at 11:23:55AM +0200, Martin Pitt wrote:
> Hi Neil,
>
> thanks a lot for your work on this!
>
> Neil Horman [2007-07-27 16:08 -0400]:
> > Hey
> > Patch 2/3 of my core_pattern enhancements. This patch is a rewrite of
> > my previous post for this enhancement. It uses jeremy's
> > split_argv/free_argv
> > library functions to translate core_pattern into an argv array to be passed
> > to
> > the user mode helper process.
> > [...]
> > if (ispipe) {
> > core_limit = RLIM_INFINITY;
> > + helper_argv = argv_split(GFP_KERNEL, corename+1, _argc);
>
> I just want to mention a potential problem with this: If you first
> expand the macros (from pattern to corename) and then split corename
> into an argv, then this breaks macro expansions containing spaces.
> This mostly affects the executable name, of course.
>
I never intended for this core_pattern argument passing to be able to expand
macros, other than the macros specified by the core_pattern code. If you want
it to do that, we can address that with a later patch.
> In fact we considered this macro approach when doing the original
> patches in the Ubuntu kernel, but we eventually used environment
> variables because they are much easier and more robust to implement
> than doing a robust macro expansion (i. e. first split core_pattern
> into an argv and then call the macro expansion for each element).
>
I disagree. While it might be nice to be able to specify environment variables
as command line arguments, it would be much easier to just let the core_pattern
executable inherit the crashing processes environment. we don't do that
currently, but we easily could. That way any information that the crashing
process wants the dying process to know can be inherited and vetted easily by
apport (or whatever the core_pattern points to). I'll do a patch later for that
if you don't like it.
> I would love to use macros instead since it looks a bit cleaner, and
> personally I do not care about the "executable name" macro for Apport
> [1] (I grab it from /proc/pid/exe), but I wanted to mention this
> possible caveat before it goes upstream.
>
If you don't want to use a given macro, fine, don't use it. If you want to use
a macro, thats fine too, but I really don't want to offer the ability to pass
macro's in core_pattern (it really just makes the parsing too hairy and prone to
error). If you want to pass macros to apport, or whatever, we'll just let the
user mode helper inherit the crashing processes environment. Its much easier
work, just as usefull, and more importantly, can be done later as a separate
piece of work.
Regards
Neil
> Thank you,
>
> Martin
>
> [1] https://wiki.ubuntu.com/Apport
>
> --
> Martin Pitthttp://www.piware.de
> Ubuntu Developer http://www.ubuntu.com
> Debian Developer http://www.debian.org
--
/***
*Neil Horman
*Software Engineer
*Red Hat, Inc.
[EMAIL PROTECTED]
*gpg keyid: 1024D / 0x92A74FA1
*http://pgp.mit.edu
***/
-
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.23-rc1-mm1
On 7/26/07, Torsten Kaiser <[EMAIL PROTECTED]> wrote: > DISCONTIGMEM+SLUB: > [ 39.833272] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 40.016659] Kernel panic - not syncing: IO-APIC + timer doesn't > work! Try using the 'noapic' kernel parameter > DISCONTIGMEM+SLAB: > Boots until it can't find / because I didn't append the correct initrd > It also hit the MP-BIOS bug, but was not bothered by it: > [ 36.696965] ..MP-BIOS bug: 8254 timer not connected to IO-APIC > [ 36.880537] Using local APIC timer interrupts. > [ 36.932215] result 12500283 > [ 36.940581] Detected 12.500 MHz APIC timer. > > So I think, I will postpone SPARSEMEM until -mm2, as there are seem to > be some problems in that area (Re: 2.6.23-rc1-mm1 sparsemem_vmemamp > fix) > > But maybee I will get SLUB to work. ;) SLUB works, if I reboot (Alt+SysRq+B) from a 2.6.22-rc6-mm1 kernel. Otherwise it will panic with IO-APIC + timer not working. Differences in dmesg 2.6.22-rc6-mm1 has: [0.00] Nvidia board detected. Ignoring ACPI timer override. [0.00] If you got timer trouble try acpi_use_timer_override and [0.00] ACPI: BIOS IRQ0 pin2 override ignored. and [0.00] TSC calibrated against PM_TIMER 23-rc1-mm1 has: [0.00] ACPI: IRQ0 used by override. [0.00] ACPI: IRQ2 used by override. and [ 37.340319] ..MP-BIOS bug: 8254 timer not connected to IO-APIC I did not need to use acpi_use_timer_override with the older kernel. Do you need more info about my board/ BIOS/ ACPI tables? After the warm-boot trick 2.6.23-rc1-mm1 seems stable right now... Torsten - 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: zd1211b question.
Gene Heskett wrote: This last one is the right set of numbers. However, I'll be dipped but I can't find anyplace in a make xconfig in the 2.6.22.1-rt9 tree, to turn on the building of that driver. Sounds like you haven't satisfied the dependencies or are looking in the wrong menu. Under menuconfig you can type: /ZD1211 That will tell you where abouts it resides, and it's dependencies. You'll also need firmware with this driver. See http://www.linuxwireless.org/en/users/Drivers/zd1211rw Daniel - 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: BSG: BLK_DEV_BSG=y , BLOCK=n compile error
From: Gabriel C <[EMAIL PROTECTED]> Subject: BSG: BLK_DEV_BSG=y , BLOCK=n compile error Date: Sat, 28 Jul 2007 14:54:02 +0200 > Hi, > > BSG does not compile without BLOCK set : Thanks, this has already been addressed. http://marc.info/?l=linux-kernel=118534836402440=2 James, could you add the patch to scsi-rc-fixes? Thanks. --- From: Paul Mundt <[EMAIL PROTECTED]> Subject: [PATCH] bsg: Fix build for CONFIG_BLOCK=n BLK_DEV_BSG was added outside of the if BLOCK check, which allows it to be enabled when CONFIG_BLOCK=n. This leads to many screenlengths of errors, starting with a parse error on the request_queue_t definition. Obviously this wasn't intended for CONFIG_BLOCK=n usage, so just move the option back in to the block. Caught with a randconfig on sh. Signed-off-by: Paul Mundt <[EMAIL PROTECTED]> Acked-by: Jens Axboe <[EMAIL PROTECTED]> Acked-by: FUJITA Tomonori <[EMAIL PROTECTED]> --- block/Kconfig |4 ++-- 1 files changed, 2 insertions(+), 2 deletions(-) diff --git a/block/Kconfig b/block/Kconfig index ca2ef4e..2484e0e 100644 --- a/block/Kconfig +++ b/block/Kconfig @@ -49,8 +49,6 @@ config LSF If unsure, say Y. -endif # BLOCK - config BLK_DEV_BSG bool "Block layer SG support v4 (EXPERIMENTAL)" depends on EXPERIMENTAL @@ -64,4 +62,6 @@ config BLK_DEV_BSG protocols (e.g. Task Management Functions and SMP in Serial Attached SCSI). +endif # BLOCK + source block/Kconfig.iosched -- 1.5.2.4 - 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 patch] let SUSPEND select HOTPLUG_CPU
On Sat, 2007-07-28 at 00:47 +0200, Stefan Richter wrote: > Adrian Bunk wrote: > > The dependency of SUSPEND_SMP on HOTPLUG_CPU is quite unintuitive, > > It's not entirely unintuitive. That option's full name is "Support for > suspend on SMP and hot-pluggable CPUs". > I have to give reason to Len Brown on limit the options else this is much more difficult. Make sense define SUSPEND_SMP without define HOTPLUG_CPU ? or make sense define HOTPLUG_CPU without define SUSPEND_SMP ? Even if both options could make sense, we have to have the code prepare for it, which couldn't be prepared. But it is more easier and more importante focus on major cases which is: "I don't care" and force some configuration and everybody test the same code. Else in ACPI we have many issues to resolve like with this define and without other, which philosophically could be interesting but is not the major case and don't let us focus on stability. Thanks, -- Sérgio M. B. smime.p7s Description: S/MIME cryptographic signature
[PATCH] Framebuffer: Fix 16bpp colour output in Dreamcast pvr2fb
Tony, This patch - on top of your others - fixes the colour output for 16bpp RGB565 output in the Dreamcast - it was a simple out by one error in the bit shift. Still looking at the 24bpp and 32bpp issues. Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> diff --git a/drivers/video/pvr2fb.c b/drivers/video/pvr2fb.c index 3ac32f3..383e87e 100644 --- a/drivers/video/pvr2fb.c +++ b/drivers/video/pvr2fb.c @@ -330,27 +331,28 @@ static int pvr2fb_setcolreg(unsigned int regno, unsigned int red, case 16: /* RGB 565 */ tmp = (red & 0xf800) | ((green & 0xfc00) >> 5) | - ((blue & 0xf800) >> 11); + ((blue & 0xf800) >> 10); pvr2fb_set_pal_entry(par, regno, tmp);
Re: Linus 2.6.23-rc1
Hmm - Linus 2.6.23-rc1 + Linux 2.6.23-rc1 Or are *you* now under versioning? Or maybe a silent namechange of the kernel? /ronni - 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] Documentation - update Documentation/fb/pvr2fb.txt
The current version is very old and does not correctly specify how to set the video mode. Signed-off by: Adrian McMenamin <[EMAIL PROTECTED]> diff --git a/Documentation/fb/pvr2fb.txt b/Documentation/fb/pvr2fb.txt index 2bf6c23..1489f9b 100644 --- a/Documentation/fb/pvr2fb.txt +++ b/Documentation/fb/pvr2fb.txt @@ -9,14 +9,13 @@ one found in the Dreamcast. Advantages: * It provides a nice large console (128 cols + 48 lines with 1024x768) - without using tiny, unreadable fonts. + without using tiny, unreadable fonts (NOT on the Dreamcast) * You can run XF86_FBDev on top of /dev/fb0 * Most important: boot logo :-) Disadvantages: - * Driver is currently limited to the Dreamcast PowerVR 2 implementation - at the time of this writing. + * Driver is largely untested on non-Dremcast systems. Configuration = @@ -29,11 +28,15 @@ Accepted options: font:X- default font to use. All fonts are supported, including the SUN12x22 font which is very nice at high resolutions. -mode:X- default video mode. The following video modes are supported: -640x240-60, 640x480-60. +mode:X- default video mode with format [xres]x[yres]-@ +The following video modes are supported: +[EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] The Dreamcast + defaults to [EMAIL PROTECTED] At the time of writing the +24bpp and 32bpp modes function poorly. Work to fix that is +ongoing Note: the 640x240 mode is currently broken, and should not be -used for any reason. It is only mentioned as a reference. +used for any reason. It is only mentioned here as a reference. inverse - invert colors on screen (for LCD displays) @@ -52,10 +55,10 @@ output:X - output type. This can be any of the following: pal, ntsc, and X11 === -XF86_FBDev should work, in theory. At the time of this writing it is -totally untested and may or may not even portray the beginnings of -working. If you end up testing this, please let me know! +XF86_FBDev has been shown to work on the Dremcast in the past - though not yet +on any 2.6 series kernel. -- Paul Mundt <[EMAIL PROTECTED]> +Updated by Adrian McMenamin <[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: BSG: BLK_DEV_BSG=y , BLOCK=n compile error
FUJITA Tomonori wrote: > From: Gabriel C <[EMAIL PROTECTED]> > Subject: BSG: BLK_DEV_BSG=y , BLOCK=n compile error > Date: Sat, 28 Jul 2007 14:54:02 +0200 > >> Hi, >> >> BSG does not compile without BLOCK set : > > Thanks, this has already been addressed. > > http://marc.info/?l=linux-kernel=118534836402440=2 > Upss , sorry I didn't find that one is why I reported it. Gabriel - 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 patch] arch/powerpc/Kconfig: fix the EMBEDDED6xx dependencies
On Mon, Dec 04, 2006 at 02:06:34PM +1100, Paul Mackerras wrote: > Adrian Bunk writes: > > > This patch changes the EMBEDDED6xx dependencies to the equivalent > > dependency that seems to have been intended. > > Nack - CONFIG_EMBEDDED6xx is going away entirely, soon. Still there - and still with this strange dependency. > Paul. cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 03:48:13 Mike Galbraith wrote: > On Fri, 2007-07-27 at 18:51 -0400, Daniel Hazelton wrote: > > Now, once more, I'm going to ask: What is so terribly wrong with swap > > prefetch? Why does it seem that everyone against it says "Its treating a > > symptom, so it can't go in"? > > And once again, I personally have nothing against swap-prefetch, or > something like it. I can see how it or something like it could be made > to improve the lives of people who get up in the morning to find their > apps sitting on disk due to memory pressure generated by over-night > system maintenance operations. > > The author himself however, says his implementation can't help with > updatedb (though people seem to be saying that it does), or anything > else that leaves memory full. That IMHO, makes it of questionable value > toward solving what people are saying they want swap-prefetch for in the > first place. Okay. I have to agree with the author that, in such a situation, it wouldn't help. However there are, without a doubt, other situations where it would help immensely. (memory hogs forcing everything to disk and quitting, one off tasks that don't balloon the cache (kernel compiles, et al) - in those situations swap prefetch would really shine.) DRH -- Dialup is like pissing through a pipette. Slow and excruciatingly painful. - 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: serial flow control appears broken
Alan Cox wrote: Curiously, the session at 38400 bps that skipped 858 bytes... coincided, not just in sequence but also in precice timing within the session, with a small but noticeable disk load that I caused by grepping through a hundred session logs. (I can't reproduce it easily, though, because of disk caching.) Can you send me a dmesg, there are some cases when high disk load can cause high interrupt latency in both 2.2 and 2.6 depending upon what is configured. I've attached dmesg output. The os version I used yesterday to run those tests was Debian 4.0r0 (kernel 2.6.18-4-686). It's still running, and that's where I give you this dmesg output from. I don't think thats related to the main problem but it is worth knowing about hdparm -u1 # hdparm -u1 /dev/hda /dev/hda: setting unmaskirq to 1 (on) unmaskirq= 1 (on) # After doing this I re-ran the 5 test sends at 115200 bps. The number of lost bytes were: 0, 14, 8, 0, and 3. Compared with yesterday's 63, 5, 44, 48, and 2 this may indicate an improvement. Note also that in the 4th session where no bytes were lost there was still one element of corrupt data as detected by the image decoder. Thanks, Lee. Linux version 2.6.18-4-686 (Debian 2.6.18.dfsg.1-12) ([EMAIL PROTECTED]) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Mon Mar 26 17:17:36 UTC 2007 BIOS-provided physical RAM map: BIOS-e820: - 000a (usable) BIOS-e820: 000f - 0010 (reserved) BIOS-e820: 0010 - 0e00 (usable) BIOS-e820: - 0001 (reserved) 0MB HIGHMEM available. 224MB LOWMEM available. On node 0 totalpages: 57344 DMA zone: 4096 pages, LIFO batch:0 Normal zone: 53248 pages, LIFO batch:15 DMI 2.0 present. ACPI: Unable to locate RSDP Allocating PCI resources starting at 1000 (gap: 0e00:f1ff) Detected 400.953 MHz processor. Built 1 zonelists. Total pages: 57344 Kernel command line: root=/dev/hda3 ro Local APIC disabled by BIOS -- you can enable it with "lapic" mapped APIC to d000 (011c9000) Enabling fast FPU save and restore... done. Initializing CPU#0 PID hash table entries: 1024 (order: 10, 4096 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 32768 (order: 5, 131072 bytes) Inode-cache hash table entries: 16384 (order: 4, 65536 bytes) Memory: 219828k/229376k available (1544k kernel code, 9052k reserved, 577k data, 196k init, 0k highmem) Checking if this processor honours the WP bit even in supervisor mode... Ok. Calibrating delay using timer specific routine.. 802.59 BogoMIPS (lpj=1605193) Security Framework v1.0.0 initialized SELinux: Disabled at boot. Capability LSM initialized Mount-cache hash table entries: 512 CPU: After generic identify, caps: 0183f9ff CPU: After vendor identify, caps: 0183f9ff CPU: L1 I cache: 16K, L1 D cache: 16K CPU: L2 cache: 512K CPU: After all inits, caps: 0183f9ff 0040 Intel machine check architecture supported. Intel machine check reporting enabled on CPU#0. Compat vDSO mapped to e000. Checking 'hlt' instruction... OK. SMP alternatives: switching to UP code Freeing SMP alternatives: 16k freed CPU0: Intel Pentium II (Deschutes) stepping 03 SMP motherboard not detected. Local APIC not detected. Using dummy APIC emulation. Brought up 1 CPUs migration_cost=0 checking if image is initramfs... it is Freeing initrd memory: 4375k freed NET: Registered protocol family 16 PCI: PCI BIOS revision 2.10 entry at 0xfb4a0, last bus=1 PCI: Using configuration type 1 Setting up standard PCI resources ACPI: Interpreter disabled. Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI: disabled PnPBIOS: Scanning system for PnP BIOS support... PnPBIOS: Found PnP BIOS installation structure at 0xc00fc0f0 PnPBIOS: PnP BIOS version 1.0, entry 0xf:0xc118, dseg 0xf PnPBIOS: 14 nodes reported by PnP BIOS; 14 recorded by driver PCI: Probing PCI hardware PCI: Probing PCI hardware (bus 00) PCI: Firmware left :00:0b.0 e100 interrupts enabled, disabling Boot video device is :01:00.0 PCI: Bridge: :00:01.0 IO window: c000-cfff MEM window: e400-e5ff PREFETCH window: e700-e77f PCI: Setting latency timer of device :00:01.0 to 64 NET: Registered protocol family 2 IP route cache hash table entries: 2048 (order: 1, 8192 bytes) TCP established hash table entries: 8192 (order: 4, 65536 bytes) TCP bind hash table entries: 4096 (order: 3, 32768 bytes) TCP: Hash tables configured (established 8192 bind 4096) TCP reno registered audit: initializing netlink socket (disabled) audit(1185563327.604:1): initialized VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 1024 (order 0, 4096 bytes) Initializing Cryptographic API io scheduler noop registered io scheduler anticipatory
Re: swap-prefetch: A smart way to make good use of idle resources (was: updatedb)
El Sat, 28 Jul 2007 02:03:19 +0200 (CEST), "Indan Zupancic" <[EMAIL PROTECTED]> escribió: > Perhaps one of the reasons is that this is core kernel code. And that it > isn't a new > feature, but a performance improvement with doubtful trade-offs. The problem > statement isn't clear either. It seems like a natural enhancement, but is > that enough > reason to merge it? Maybe, maybe not. But if slow swap-in is the problem, > shouldn't > that be fixed instead of bypassed? The problem AFAIK it's clear: Swap in is slow by nature because it's random. Well, it "looks" like it should be random. Now that would be a interesting thing to analyze: locality of the swapped-in stuff for different worloads - if the swapped-in stuff has some locality, then it certainly should possible to fix the swapin code to do some kind of "swapahead". But if the stuff is swapped in completely randomly, only stuff like swap prefetch is going to help. The good thing about swap prefetch is that it fixes the problem today without forbidding future improvements to the VM. - 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: UML: remove MODE_TT?
On Tue, Dec 12, 2006 at 11:18:37PM -0500, Jeff Dike wrote: > On Wed, Dec 13, 2006 at 12:35:33AM +0100, Adrian Bunk wrote: > > MODE_TT is both marked as deprecated and marked as BROKEN. > > > > Would a patch to remove MODE_TT, always enable MODE_SKAS, and doing all > > possible cleanups after this be accepted? > > Thanks, but not yet. > > I've got that queued up in my tree now, waiting for SMP to work. SMP is > the one remaining justification for TT mode, so I'll get that in, then remove > MODE_TT and do the associated cleanups. MODE_TT is still marked as broken and still not compiling... Will anyone fix it or can it finally be removed? > Jeff cu Adrian -- "Is there not promise of rain?" Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. "Only a promise," Lao Er said. Pearl S. Buck - Dragon Seed - 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/
NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
Hi, I got this compile error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). ... net/core/netpoll.c: In function 'netpoll_poll': net/core/netpoll.c:155: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c:159: error: 'struct net_device' has no member named 'poll_controller' net/core/netpoll.c: In function 'netpoll_setup': net/core/netpoll.c:670: error: 'struct net_device' has no member named 'poll_controller' make[2]: *** [net/core/netpoll.o] Error 1 make[1]: *** [net/core] Error 2 make: *** [net] Error 2 make: *** Waiting for unfinished jobs ... I think is because KGDBOE selects just NETPOLL. Regards, Gabriel - 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: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On Saturday 28 July 2007 04:55:58 [EMAIL PROTECTED] wrote: > On Sat, 28 Jul 2007, Rene Herman wrote: > > On 07/27/2007 09:43 PM, [EMAIL PROTECTED] wrote: > >> On Fri, 27 Jul 2007, Rene Herman wrote: > >> > On 07/27/2007 07:45 PM, Daniel Hazelton wrote: > >> > > Questions about it: > >> > > Q) Does swap-prefetch help with this? > >> > > A) [From all reports I've seen (*)] > >> > > Yes, it does. > >> > > >> > No it does not. If updatedb filled memory to the point of causing > >> > swapping (which noone is reproducing anyway) it HAS FILLED MEMORY and > >> > swap-prefetch hasn't any memory to prefetch into -- updatedb itself > >> > doesn't use any significant memory. > >> > >> however there are other programs which are known to take up significant > >> amounts of memory and will cause the issue being described (openoffice > >> for example) > >> > >> please don't get hung up on the text 'updatedb' and accept that there > >> are programs that do run intermittently and do use a significant amount > >> of ram and then free it. > > > > Different issue. One that's worth pursueing perhaps, but a different > > issue from the VFS caches issue that people have been trying to track > > down. > > people are trying to track down the problem of their machine being slow > until enough data is swapped back in to operate normally. > > in at some situations swap prefetch can help becouse something that used > memory freed it so there is free memory that could be filled with data > (which is something that Linux does agressivly in most other situations) > > in some other situations swap prefetch cannot help becouse useless data is > getting cached at the expense of useful data. > > nobody is arguing that swap prefetch helps in the second cast. Actually, I made a mistake when tracking the thread and reading the code for the patch and started to argue just that. But I have to admit I made a mistake - the patches author has stated (as Rene was kind enough to point out) that swap prefetch can't help when memory is filled. > what people are arguing is that there are situations where it helps for > the first case. on some machines and version of updatedb the nighly run of > updatedb can cause both sets of problems. but the nightly updatedb run is > not the only thing that can cause problems Solving the cache filling memory case is difficult. There have been a number of discussions about it. The simplest solution, IMHO, would be to place a (configurable) hard limit on the maximum size any of the kernels caches can grow to. (The only solution that was discussed, however, is a complex beast) > > but let's talk about the concept here for a little bit > > the design is to use CPU and I/O capacity that's otherwise idle to fill > free memory with data from swap. > > pro: >more ram has potentially useful data in it > > con: >it takes a little extra effort to give this memory to another app (the > page must be removed from the list and zeroed at the time it's needed, I > assume that the data is left in swap so that it doesn't have to be written > out again) > >it adds some complexity to the kernel (~500 lines IIRC from this thread) > >by undoing recent swapouts it can potentially mask problems with swapout > > it looks to me like unless the code was really bad (and after 23 months in > -mm it doesn't sound like it is) that the only significant con left is the > potential to mask other problems. I'll second this. But with the swap system itself having seen as heavy testing as it has I don't know if it would be masking other problems. That is why I've been asking "What is so wrong with it?" - while it definately doesn't help with programs that cause caches to balloon (that problem does need another solution) it does help to speed things up when a memory hog has exited. (And since its a pretty safe assumption that swap is going to be noticeably slower than RAM this patch seems to me to be a rather visible and obvious solution to that problem) > however there are many legitimate cases where it is definantly dong the > right thing (swapout was correct in pushing out the pages, but now the > cause of that preasure is gone). the amount of benifit from this will vary > from situation to situation, but it's not reasonable to claim that this > provides no benifit (you have benchmark numbers that show it in synthetic > benchmarks, and you have user reports that show it in the real-worlk) Exactly. Though I have seen posts which (to me at least) appear to claim exactly that. It was part of the reason why I got a bit incensed. (The other was that it looked like the kernel devs with the ultra-powerful machines were claiming 'I don't see the problem on my machine, so it doesn't exist'. That sort of attitude is fine, in some cases, but not, IMHO, where performance is concerned) > there are lots of things in the kernel who's job is to pre-fill the memroy > with data that may (or may not) be useful in
Re: [PATCH 0/3][try 1] init: enable system-on-initramfs
I had this unsent on my desktop, buried by other windows. Let me know if the conversation's moved on since, but if so I wasn't cc'd... On Thursday 19 July 2007 9:56:11 am Bodo Eggert wrote: > On Wed, 18 Jul 2007, Rob Landley wrote: > > On Friday 13 July 2007 2:56:00 pm Bodo Eggert wrote: > > > I toyed with setting up a diskless system in initramfs. In the process, > > > I came across some things: > > > > > > 1) There is no way to have the kernel not mount a filesystem, > > > unless you use /init or rdinit=. > > > > Er, yes. By design. > > > > The kernel has to run an init program in order to hand off control to > > userspace. In initramfs, this is defined as /init. It looks in exactly > > one documented place. > > > > The older root= mechanism fell back to a half-dozen places (eventually > > trying things like /bin/sh if it couldn't find anything else). This is > > because there wasn't a documented standard for what should be executed, > > like there is with initramfs. > > Ever since I started using linux in 1997, the first program to run from an > installed system was /sbin/init. (I might think about removing the other > paths.) So pass in rdinit=/sbin/init. (Back in 1997 you didn't have to specify "root=", you used rdev.) > The ramfs' /init was intended for system setup, which is a separate job. The ramfs /init was "intended" to be the first process to run, which inherits PID 1 and thus all responsibility for further system setup. You can't return back to the kernel from that, it panics if PID 1 exits. Whether you choose to do "system setup" or keep running with rootfs as your root filesystem (very popular with embedded devices) is not the kernel's problem. This has been documented and has worked fine for years. Note that the initrd mechanism (which used to run /linuxrc) was _not_ PID 1, and expected you to return to the kernel. That's one of the big improvements initramfs made over initrd. > It is not intended to be the program running the system. That's policy, and none of the kernel's business. > Mixing those two > up just does not feel right. You're mixing them in your head, and it sounds like you don't understand what it's doing. > Setting root= in order to change the root > directory is much more natural. Setting root= is not _used_ if initramfs triggers, because /init gets run before ever reaching that code. In initramfs, the root filesystem is rootfs, and no attempt to mount anything else is made by the kernel unless userspace explicitly asks for it. Userspace is welcome to mount anything it wants, and userspace can switch_root to it, but that's not the kernel's problem. > > > 1a) In the process of writing these patches, I found prepare_namespace > > > not to be called if /init is present. prepare_namespace will call > > > security_sb_post_mountroot after mounting the root fs. I did not > > > yet see a way to call this from /init, and grepping kinit for > > > "security" did not help, too. > > > > I don't use selinux. I'm neither a Fortune 500 company nor the NSA. > > That's no reason for keeping bugs in that part. *shrug* I was saying I can't really comment much on a subsystem I neither use nor see much point in. > > However, if you don't trust your own initramfs, where everything starts > > out running as root, you have bigger problems. > > Using that argument, you can deduce that nobody would need selinux at all. Yeah, pretty much. Then again I feel the same way about the Itanium, and try to stay out of the way of people who feel they do need it. > Obviously some people disagree, and maybe some of them are no fools, > therefore we should try to DTRT for them and do the callback when it's > supposed to happen. > > BTW: The problems start as soon as you have to do "reflections on trusting > trust". Which led to David Wheeler's "diverse double-compiling": http://www.dwheeler.com/trusting-trust/ Which led to rather a lot of patches being integrated into the tcc fork I maintain in my nonexistent free time, such as: http://www.landley.net/hg/tinycc?cs=e6ddaffce6a8 > > > Using tmpfs instead for the first root mount is as cheap as > > > using ramfs, as long as tmpfs is used anyway (and most likely it is). > > > > *shrug* I don't object to doing so, but I've heard nebulous technical > > objections from people who know more about the implementation details fo > > tmpfs than I do. > > Obviously these problems were solved. I'm all for a patch to make initramfs use tmpfs. I'm kind of dubious about one coming from somebody who thinks that the initramfs interface in use by thousands of developers for years now needs to be totally rewritten as a prerequisite of doing so. > > > 2a) I figured if you prepared the root fs to contain a running system, > > > you woud probably also set up a runnable system on it. > > > > *scratches head* > > > > That's a tautology, right? > > You may also use the same kernel with the same initramfs in order to
Reporting bugs (was Re: [ck] Re: Linus 2.6.23-rc1)
Martin Steigerwald wrote: > There are just about 9000 bugs in the kernel bugtracker and about 15 > bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of > applications, but still I think the number of bug reports in the kernel > bugtracker is ridicolously low. And I think thats because many users > don't bother to report bugs upstream for the Linux kernel, not because > that those bugs aren't there. > > I hope that the ck mailing list community will continue to be active and > possibly try to get swap prefetch and some other goodies of the ck > patchset into mainline. And I think it would also be a good idea for ck > mailing list community to report desktop related issues in the kernel > bugtracker. I think I will take the courage next time I find anything, > and report it straight there. A word of caution about bugzilla.kernel.org, to those who don't know already: By far not all maintainers and developers use bugzilla. I don't know for which subsystems it makes sense to file a report in bugzilla. I think your best bet is to report at the mailinglists listed in linux/MAINTAINERS. -- 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 2/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe
Hi Neil, Neil Horman [2007-07-28 9:46 -0400]: > > I just want to mention a potential problem with this: If you first > > expand the macros (from pattern to corename) and then split > > corename into an argv, then this breaks macro expansions > > containing spaces. This mostly affects the executable name, of > > course. > > > I never intended for this core_pattern argument passing to be able > to expand macros, other than the macros specified by the > core_pattern code. If you want it to do that, we can address that > with a later patch. No, I specifically mean the standard ones provided by format_corename(), such as %p (pid), %s (signal), or %e (executable name). I don't see a reason to provide additional functionality. > > In fact we considered this macro approach when doing the original > > patches in the Ubuntu kernel, but we eventually used environment > > variables because they are much easier and more robust to > > implement than doing a robust macro expansion (i. e. first split > > core_pattern into an argv and then call the macro expansion for > > each element). > > > I disagree. While it might be nice to be able to specify environment > variables as command line arguments, it would be much easier to just > let the core_pattern executable inherit the crashing processes > environment. we don't do that currently, but we easily could. That > way any information that the crashing process wants the dying > process to know can be inherited and vetted easily by apport (or > whatever the core_pattern points to). I'll do a patch later for > that if you don't like it. I don't think that this will be necessary. After all, the crash handler can read all the environment from /proc// (and that's indeed what apport does to figure out relevant parts from the environment like the locale). It seems we misunderstood each other, I don't expect or want any new functionality in core_pattern. AN example might make it more clear: The original problem that we are trying to solve is the current behaviour of core_pattern expansion with pipes: |/bin/crash --pid %p would try to execute the program '/bin/crash --pid 1234' instead of calling /bin/crash with ['--pid', '1234'] as argv, right? Your patch achieves the latter by splitting the formatted core dump string into an array (at spaces). I pointed out that this leads to problems when macro values contain spaces. This currently affects hostname (%h) (although this really should not happen in practice) and executable name (%e) (rare, but at least valid). I. e. for an executable name "foo bar" your patch would expand |/bin/crash %e to ['/bin/crash', 'foo', 'bar'] instead of ['/bin/crash', 'foo bar']. Of course this is a corner case, and personally I don't really care. I strive to keep the assumptions about the interface at a minimum, so right now Apport's only required input is the core dump itself (over stdin); signal and pid can be read from the environment, and if not present, they are read from the core dump. I did not defend Ubuntu's usage of environment variables, on the contrary. Using the standard macros is more explicit and elegant, and I welcome that change. I just pointed out the reason why we chose the environment variable approach initially. I just wanted to mention this little problem for the sake of correctness. Thank you, and have a nice weekend! Martin -- Martin Pitthttp://www.piware.de Ubuntu Developer http://www.ubuntu.com Debian Developer http://www.debian.org signature.asc Description: Digital signature
[PATCH] Try harder to probe some finicky mice
From: Alon Ziv <[EMAIL PROTECTED]> Some rodents appear to be extra-finicky, and require both a PSMOUSE_RESET_DIS and a PSMOUSE_RESET_BAT before they are unconfused enough to be probed. Signed-off-by: Alon Ziv <[EMAIL PROTECTED]> --- drivers/input/mouse/psmouse-base.c |1 + 1 files changed, 1 insertions(+), 0 deletions(-) diff --git a/drivers/input/mouse/psmouse-base.c b/drivers/input/mouse/psmouse-base.c index b9f0fb2..ca039a5 100644 --- a/drivers/input/mouse/psmouse-base.c +++ b/drivers/input/mouse/psmouse-base.c @@ -651,6 +651,7 @@ static int psmouse_extensions(struct psmouse *psmouse, * protocol probes. Note that we do full reset becuase some mice * put themselves to sleep when see PSMOUSE_RESET_DIS. */ + ps2_command(>ps2dev, NULL, PSMOUSE_CMD_RESET_DIS); psmouse_reset(psmouse); if (max_proto >= PSMOUSE_IMEX && im_explorer_detect(psmouse, set_properties) == 0) -- 1.5.2.146.gb75c6 - 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: Reporting bugs (was Re: [ck] Re: Linus 2.6.23-rc1)
Hi, On 28/07/07, Stefan Richter <[EMAIL PROTECTED]> wrote: > Martin Steigerwald wrote: > > There are just about 9000 bugs in the kernel bugtracker and about 15 > > bugs in the KDE bugtracker. Granted KDE bugtracker includes a lot of > > applications, but still I think the number of bug reports in the kernel > > bugtracker is ridicolously low. And I think thats because many users > > don't bother to report bugs upstream for the Linux kernel, not because > > that those bugs aren't there. > > > > I hope that the ck mailing list community will continue to be active and > > possibly try to get swap prefetch and some other goodies of the ck > > patchset into mainline. And I think it would also be a good idea for ck > > mailing list community to report desktop related issues in the kernel > > bugtracker. I think I will take the courage next time I find anything, > > and report it straight there. > > A word of caution about bugzilla.kernel.org, to those who don't know > already: By far not all maintainers and developers use bugzilla. > I don't know for which subsystems it makes sense to file a report in > bugzilla. I think your best bet is to report at the mailinglists > listed in linux/MAINTAINERS. Please CC all bug reports to LKML. I've got a large mailbox, but I don't want to subscribe all linux-* mailing lists :). Regards, Michal -- LOG http://www.stardust.webpages.pl/log/ - 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: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Len Brown wrote: > > That three-liner will crash ACPI+SMP-HOTPLUG_CPU kernels on resume. Explain that to me. There should *be* no resume. ACPI doesn't suspend/resume on its own, I hope. It is all done by the top-level suspend/resume code, not by ACPI. ACPI is a pure helper, and if you've changed that, then I think we need to revert more than a few lines. And it's the *top*level* code that selects HOTPLUG_CPU. Through SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. This is why it's so *totally* and *utterly* bogus for ACPI to select features that it has nothign what-so-ever to do with. In other words: ACPI isn't in the driving seat. Linus - 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: Problems with reading DVD using 2.6.21.5
Manuel Reimer wrote: Hello, I tried to reproduce this bug by mounting/unmounting the drive several times. It seems like this problem is caused, if the drive is at speed 0 after some time without access. In this situation, sometimes the drive seems to take a bit longer to speed up. Whenever it takes a bit longer, I get the error in dmesg and parts of the mounted disc are unreadable... Any chance to get this debugged? It's not entirely clear to me whether the kernel is doing any retries or not. It likely should be, but somebody more familiar with the block layer would likely have to answer whether it will be or not.. Certainly if we are already retrying and the drive keeps saying "no seek complete" there's not much the kernel can do about it.. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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/
Re: RFT: updatedb "morning after" problem [was: Re: -mm merge plans for 2.6.23]
On 7/28/07, Alan Cox <[EMAIL PROTECTED]> wrote: > Actual physical disk ops are precious resource and anything that mostly > reduces the number will be a win - not to stay swap prefetch is the right > answer but accidentally or otherwise there are good reasons it may happen > to help. > > Bigger more linear chunks of writeout/readin is much more important I > suspect than swap prefetching. . The larger the chunks are that we swap out, the less it actually hurts to swap, which might make all this a moot point. Not all I/O is created equal... Ray - 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: How can we make page replacement smarter (was: swap-prefetch)
Al Boldi wrote: Chris Snook wrote: Al Boldi wrote: Because it is hard to quantify the expected swap-in speed for random pages, let's first tackle the swap-in of consecutive pages, which should be at least as fast as swap-out. So again, why is swap-in so slow? If I'm writing 20 pages to swap, I can find a suitable chunk of swap and write them all in one place. If I'm reading 20 pages from swap, they could be anywhere. Also, writes get buffered at one or more layers of hardware. Ok, this explains swap-in of random pages. Makes sense, but it doesn't explain the awful tmpfs performance degradation of consecutive read-in runs from swap, which should have at least stayed constant At best, reads can be read-ahead and cached, which is why sequential swap-in sucks less. On-demand reads are as expensive as I/O can get. Which means that it should be at least as fast as swap-out, even faster because write to disk is usually slower than read on modern disks. But linux currently shows a distinct 2x slowdown for sequential swap-in wrt swap-out. And to prove this point, just try suspend to disk where you can see sequential swap-out being reported at about twice the speed of sequential swap-in on resume. Why is that? Depends if swap-in is doing any read-ahead. If it's reading one page at a time in from the disk then the performance will definitely suck because of all the overhead from the tiny I/O's. With random swap-in you then pay the horrible seek penalty for all the reads as well. -- Robert Hancock Saskatoon, SK, Canada To email, remove "nospam" from [EMAIL PROTECTED] Home Page: http://www.roberthancock.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/
[PATCH -mm] fix LSM kernel-doc
From: Randy Dunlap <[EMAIL PROTECTED]> I'd like mainline (Linus's git) to be kernel-doc clean (it's not, but all of the patches for it have been sent, just getting them merged is the challenge). One way to address this for future merges is to fix -mm kernel-doc. The security-convert-to-static patches need this docbook change. Warning(linux-2.6.23-rc1-mm1//security/security.c): no structured comments found Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/kernel-api.tmpl |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.23-rc1-mm1.orig/Documentation/DocBook/kernel-api.tmpl +++ linux-2.6.23-rc1-mm1/Documentation/DocBook/kernel-api.tmpl @@ -334,7 +334,7 @@ X!Earch/i386/kernel/mca.c Security Framework -!Esecurity/security.c +!Isecurity/security.c - 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 -mm] fix kgdb kernel-doc
From: Randy Dunlap <[EMAIL PROTECTED]> No kernel-doc comments in this file, although kgdb.tmpl implies that it needs some: Warning(linux-2.6.23-rc1-mm1//kernel/kgdb.c): no structured comments found Add kernel-doc notation in kgdb.h for: Warning(linux-2.6.23-rc1-mm1//include/linux/kgdb.h:225): No description found for parameter 'remove_all_hw_break' Warning(linux-2.6.23-rc1-mm1//include/linux/kgdb.h:225): No description found for parameter 'correct_hw_break' Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- Documentation/DocBook/kgdb.tmpl |4 +++- include/linux/kgdb.h|4 2 files changed, 7 insertions(+), 1 deletion(-) --- linux-2.6.23-rc1-mm1.orig/Documentation/DocBook/kgdb.tmpl +++ linux-2.6.23-rc1-mm1/Documentation/DocBook/kgdb.tmpl @@ -235,7 +235,9 @@ and are optionally implemented. Some functions (with _hw_ in the name) end up being required on arches which use hardware breakpoints. -!Ikernel/kgdb.c + Driver-Specific Functions --- linux-2.6.23-rc1-mm1.orig/include/linux/kgdb.h +++ linux-2.6.23-rc1-mm1/include/linux/kgdb.h @@ -207,6 +207,10 @@ extern int kgdb_arch_remove_breakpoint(u * breakpoint. * @remove_hw_breakpoint: Allow an architecture to specify how to remove a * hardware breakpoint. + * @remove_all_hw_break: Allow an architecture to specify how to remove all + * hardware breakpoints. + * @correct_hw_break: Allow an architecture to specify how to correct the + * hardware debug registers. * * The @shadowth flag is an option to shadow information not retrievable by * gdb otherwise. This is deprecated in favor of a binutils which supports - 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/
Removing the prism54 module
Dear All, I am trying to set up software suspend 2 (TuxOnIce now it seems). This has decided it wants to remove the prism54 module before starting the hibernate process. When it tries to do this, (or when I manually do: "ifconfig eth1 down"), I start getting these messages on all terminals, ad infinitum: kernel: unregister_netdevice: waiting for eth1 to become free. Usage count = 4 I asked a bit on #prism54 on freenode, and so I upgraded to linux 2.6.22.1 from kernel.org, always building prism54 as a module, but the problem continues. I have tried doing "ifconfig eth1 down" before rmmod, but this does not help. If you have any hints or answers as to what I should do, that would be great. I think I have subscribed successfully to this mailing list, but any CCs to this address are also welcome. Thanks in advance, Yours, Edward Ando - 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/
DCA=n , INTEL_IOATDMA=y compile error ( Re: 2.6.23-rc1-mm1 )
Hi, I got this error with a randconfig ( http://194.231.229.228/MM/randconfig-auto-86.ioat ) ... LD .tmp_vmlinux1 drivers/built-in.o: In function `ioat_shutdown_functionality': ioat.c:(.text+0x21ed32): undefined reference to `unregister_dca_provider' ioat.c:(.text+0x21ed3a): undefined reference to `free_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x2201f3): undefined reference to `alloc_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x22022e): undefined reference to `register_dca_provider' drivers/built-in.o: In function `ioat_dca_init': (.text+0x22023b): undefined reference to `free_dca_provider' make: *** [.tmp_vmlinux1] Error 1 ... Regards, Gabriel C - 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: serial flow control appears broken
On 7/27/07, Lee Howard <[EMAIL PROTECTED]> wrote: > Curiously, the session at 38400 bps that skipped 858 bytes... coincided, > not just in sequence but also in precice timing within the session, with > a small but noticeable disk load that I caused by grepping through a > hundred session logs. (I can't reproduce it easily, though, because of > disk caching.) `echo 1 > /proc/sys/vm/drop_caches` will clear out most (all?) of what the kernel has cached from the drive. It's there just for this kind of repeatability of tests... Ray - 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] audit m-l is members-only
From: Randy Dunlap <[EMAIL PROTECTED]> audit m-l is "members-only". Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]> --- MAINTAINERS |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) --- linux-2.6.23-rc1-mm1.orig/MAINTAINERS +++ linux-2.6.23-rc1-mm1/MAINTAINERS @@ -679,7 +679,7 @@ S: Maintained AUDIT SUBSYSTEM P: David Woodhouse M: [EMAIL PROTECTED] -L: [EMAIL PROTECTED] +L: [EMAIL PROTECTED] (subscribers-only) W: http://people.redhat.com/sgrubb/audit/ T: git kernel.org:/pub/scm/linux/kernel/git/dwmw2/audit-2.6.git S: Maintained - 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/
sound/pci/ac97/ac97_patch.h - declared 'static' but never defined warnings ( Re: 2.6.23-rc1-mm1 )
... sound/pci/ac97/ac97_patch.h:86: warning: 'snd_ac97_restore_status' declared 'static' but never defined sound/pci/ac97/ac97_patch.h:87: warning: 'snd_ac97_restore_iec958' declared 'static' but never defined ... Got that with a randconfig ( http://194.231.229.228/MM/randconfig-auto-86.ioat ) Regards, Gabriel C - 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: CONFIG_SUSPEND? (was: Re: [GIT PATCH] ACPI patches for 2.6.23-rc1)
On Sat, 28 Jul 2007, Linus Torvalds wrote: > > And it's the *top*level* code that selects HOTPLUG_CPU. Through > SUSPEND_SMP (which will select HOTPLUG_CPU) and SOFTWARE_SUSPEND. In other words, the problem seems to be that kernel/power/main.c: suspend_devices_and_enter() does the proper "disable/enable_nonboot_cpus()", but it does so without having enabled CPU hotplug. And you seem to think that it's ACPI that should enable the hotplug, even though the code that actually needs it is _outside_ ACPI. And I think that's wrong, and that this is a bug. So I think the real issue is that we allow that "suspend_devices_and_enter()" code to be compiled without HOTPLUG_CPU in the first place. It's not supposed to work that way. Of course, it may well be that other architectures can happily suspend even with multiple CPU's active, which may be the cause of this mess. But I really think it shouldn't be ACPI that has to select the CPU hotplug, since it's not ACPI that _uses_ it in the first place. Rafael: making a config option for STR (the same way we have a config option for hibernate), and just not allowing it on SMP without HOTPLUG_CPU seems to be the right thing. Len is right in that we do insane things right now (trying to STR with multiple CPU's still active), and I just don't think he's the one that should work around it! Linus - 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: alpha compile failure (srm_printk)
Retested this compile error with todays 2.6.23-rc1+git, still the same. > > LD arch/alpha/boot/bootloader > > arch/alpha/boot/bootloader.lds:25: undefined symbol `srm_printk' referenced > > in expression > > I was unable to repeoduce these errors on 2.6.22-rc4 with your config. Hmm. Just make works, make bootimage does not. I debugged this further today and I can not see how it can work. The link command in question is ld -static -uvsprintf -T arch/alpha/boot/bootloader.lds arch/alpha/boot/head.o arch/alpha/boot/main.o -o arch/alpha/boot/bootloader and it still tells arch/alpha/boot/bootloader.lds:25: undefined symbol `srm_printk' referenced in expression arch/alpha/boot/bootloader.lds contains a single related line referring to srm_printk: printk = srm_printk; This only seems to define an alias to srm_printk so not important (and unused)? nm arch/alpha/boot/head.o outputs T __start 0108 T halt 0110 T move_stack U start_kernel 0060 T switch_to_osf_pal 0100 T tbi 0020 T wrent 0040 T wrkg so no mention of srm_printk. nm arch/alpha/boot/main.o outputs U _end U callback_close U callback_getenv U callback_open U callback_read G hwrpb T pal_init b pcb_va U srm_printk 0130 T start_kernel U strcpy U switch_to_osf_pal and the U srm_printk is breaking things. main.c actually uses srm_printk inside so it really needs to link one in. I do not see where that srm_printk could come from? The only implementation seems to be in arch/alpha/lib/srm_printk.c that goes into arch/alpha/lib/lib.a.. maybe this is forgotten? arch/alpha/boot/Makefile contains different link rules for bootloader vs bootpheader and bootpzheader - the others also have $(LIBS_Y). However, as trial and error showed, adding $(LIBS_Y) to get lib/lib.a does not work - I got new unresolved symbols (__kmalloc or some other malloc variant). So, can anyone guide me further - where should srm_printk come from in bootloader image? -- Meelis Roos ([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/
mm/sparse.c compile error ( Re: 2.6.23-rc1-mm1 )
Hi, next randconfig error ( http://194.231.229.228/MM/randconfig-auto-87.mm_sparse.error ) ... mm/sparse.c: In function 'sparse_init': mm/sparse.c:482: error: implicit declaration of function 'sparse_early_usemap_alloc' mm/sparse.c:482: warning: assignment makes pointer from integer without a cast make[1]: *** [mm/sparse.o] Error 1 make: *** [mm] Error 2 make: *** Waiting for unfinished jobs ... guessing while this patch , but I am not really sure : fix-corruption-of-memmap-on-ia64-sparsemem-when-mem_section-is-not-a-power-of-2.patch Regards, Gabriel C - 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: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Jonathan Jessup wrote: > > Linus, there is a complaint about the Linux kernel, this complaint is that > the Linux kernel isn't giving priorities to desktop interactivity and > experience. The response on osnews.com etc have shown that there is public > demand for it too. No, the response on osnews.com only shows that there are a lot of armchair complainers around. People are suggesting that you'd have a separate "desktop kernel". That's insane. It also shows total ignorance of maintainership, and reality. And I bet most of the people there haven't tested _either_ scheduler, they just like making statements. The fact is, I've _always_ considered the desktop to be the most important part. And I suspect that that actually is true for most kernel developers, because quite frankly, that's what 99% of them ends up using. If a kernel developer uses Windows for his day-to-day work, I sure as hell wouldn't want to have him developing Linux. That has nothing to do with anything anti-windows: but the whole "eat your own dogfood" is a very fundamental thing, and somebody who doesn't do that shouldn't be allowed to be even _close_ to a compiler! So the whole argument about how kernel developers think that the desktop isn't important is totally made-up crap by Con, and then parrotted by osnews and other places. The fact is, most kernel developers realize that Linux is used in different places, on different machines, and with different loads. You cannot make _everybody_ happy, but you can try to do as good a job as possible. And doing "as good a job as possible" very much includes not focusing on any particular load. And btw, "the desktop" isn't actually one single load. It's in fact a lot of very different loads, and different people want different things. What makes the desktop so interesting is in fact that it shows more varied usage than any other niche - and no, 3D gaming isn't "it". > Maybe once or twice Con couldn't help or fix an issue but isn't that what > open source software is all about anyway? That's not the issue. Con wass fixated on one thing, and one thing only, and wasn't interested in anythign else - and attacked people who complained. Compare that to Ingo, who saw that what Con's scheduler did was good, and tried to solve the problems of people who complained. The ck mailing list is/was also apparently filled with people who all had the same issues, which is seriously the *wrong* thing to do. It means that any "consensus" coming out of that kind of private list is totally worthless, because the people you ask are already in agreement - you have a so-called "selection bias", and they just reinforce their own opinions. Which is why I don't trust mailing lists with a narrow topic. They are _useless_. If you cannot get many different people from _different_ areas to test your patches, and cannot see the big picture, the end result won't likely be very interesting to others, will it? The fact is, _any_ scheduler is going to have issues. I will bet you almost any amount of money that people are going to complain about Ingo's scheduler when 2.6.23 is released. That's not the issue: the issue is that the exact same thing would have happened with CK too. So if you are going to have issues with the scheduler, which one do you pick: the one where the maintainer has shown that he can maintain schedulers for years, can can address problems from _different_ areas of life? Or the one where the maintainer argues against people who report problems, and is fixated on one single load? That's really what it boils down to. I was actually planning to merge CK for a while. The _code_ didn't faze me. Linus - 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/3] core_pattern: allow passing of arguments to user mode helper when core_pattern is a pipe
On Sat, Jul 28, 2007 at 06:17:25PM +0200, Martin Pitt wrote:
> Hi Neil,
>
> Neil Horman [2007-07-28 9:46 -0400]:
> > > I just want to mention a potential problem with this: If you first
> > > expand the macros (from pattern to corename) and then split
> > > corename into an argv, then this breaks macro expansions
> > > containing spaces. This mostly affects the executable name, of
> > > course.
> > >
> > I never intended for this core_pattern argument passing to be able
> > to expand macros, other than the macros specified by the
> > core_pattern code. If you want it to do that, we can address that
> > with a later patch.
>
> No, I specifically mean the standard ones provided by
> format_corename(), such as %p (pid), %s (signal), or %e (executable
> name). I don't see a reason to provide additional functionality.
>
Ahh, well then you should have nothing to worry about, this patch expands them
just fine. And none of those macros will ever have spaces in them. I suppose
it would be possible for the executable name to have spaces in it, but honestly,
thats going rather out of your way to do something that you arguably shouldn't
do anyway.
> > > In fact we considered this macro approach when doing the original
> > > patches in the Ubuntu kernel, but we eventually used environment
> > > variables because they are much easier and more robust to
> > > implement than doing a robust macro expansion (i. e. first split
> > > core_pattern into an argv and then call the macro expansion for
> > > each element).
> > >
> > I disagree. While it might be nice to be able to specify environment
> > variables as command line arguments, it would be much easier to just
> > let the core_pattern executable inherit the crashing processes
> > environment. we don't do that currently, but we easily could. That
> > way any information that the crashing process wants the dying
> > process to know can be inherited and vetted easily by apport (or
> > whatever the core_pattern points to). I'll do a patch later for
> > that if you don't like it.
>
> I don't think that this will be necessary. After all, the crash
> handler can read all the environment from /proc// (and that's
> indeed what apport does to figure out relevant parts from the
> environment like the locale).
>
Agreed, /proc//* will be available while the helper app
runs.
> It seems we misunderstood each other, I don't expect or want any new
> functionality in core_pattern. AN example might make it more clear:
>
I think you're correct, I misundersood you previously. Apologies.
> The original problem that we are trying to solve is the current
> behaviour of core_pattern expansion with pipes:
>
> |/bin/crash --pid %p
>
> would try to execute the program '/bin/crash --pid 1234' instead of
> calling /bin/crash with ['--pid', '1234'] as argv, right? Your patch
> achieves the latter by splitting the formatted core dump string into
> an array (at spaces).
>
Yes, that is exactly correct.
> I pointed out that this leads to problems when macro values contain
> spaces. This currently affects hostname (%h) (although this really
> should not happen in practice) and executable name (%e) (rare, but at
> least valid). I. e. for an executable name "foo bar" your patch would
> expand
>
> |/bin/crash %e
>
> to ['/bin/crash', 'foo', 'bar'] instead of ['/bin/crash', 'foo bar'].
>
Also correct. Thats a pretty big corner case, and I personally don't think an
executable name with spaces is/should be valid anyway, but it can be done.
> Of course this is a corner case, and personally I don't really care.
> I strive to keep the assumptions about the interface at a minimum, so
> right now Apport's only required input is the core dump itself (over
> stdin); signal and pid can be read from the environment, and if not
> present, they are read from the core dump.
>
Jeremy asked that I make a patch next week to address split_argv's requirement
that the argc parameter be non-NULL. I'll be fixing that next week, and what I
can do is further enhance it such that it ignores spaces in quoted strings,
which should address the case that concerns you. I.E I can make split_argv
behave such that:
echo "|\"foo bar\" --pid %p" > /proc/sys/kernel/core_pattern
results in the following argv:
{{"foo bar"}, {"--pid"}, {"1234"}}
Which I think handles what you are looking for.
> I did not defend Ubuntu's usage of environment variables, on the
> contrary. Using the standard macros is more explicit and elegant, and
> I welcome that change. I just pointed out the reason why we chose the
> environment variable approach initially.
>
Ah, my bad. We're on the same page then, and I just misunderstood what you were
referring to when you said macro expansion. I thought you wanted to have
core_pattern translate things like $HOME and soforth, which can more esaily be
passed to things like apport via environment inheritence, which we can look at
at a later date.
> I just wanted to mention this little
[PATCH] fix alpha mkbb compilation warnings
In current 2.6.23-rc1+git, make bootimage gives the following warnings
while compiling mkbb.c. The patch below fixes these warnings by using
the proper include for exit() and using appropriate printf format.
HOSTCC arch/alpha/boot/tools/mkbb
arch/alpha/boot/tools/mkbb.c: In function 'main':
arch/alpha/boot/tools/mkbb.c:95: warning: implicit declaration of function
'exit'
arch/alpha/boot/tools/mkbb.c:95: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:102: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:110: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:117: warning: format '%d' expects type 'int', but
argument 3 has type 'long unsigned int'
arch/alpha/boot/tools/mkbb.c:118: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:125: warning: format '%d' expects type 'int', but
argument 3 has type 'long unsigned int'
arch/alpha/boot/tools/mkbb.c:126: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:143: warning: incompatible implicit declaration of
built-in function 'exit'
arch/alpha/boot/tools/mkbb.c:148: warning: incompatible implicit declaration of
built-in function 'exit'
Signed-off-by: Meelis Roos <[EMAIL PROTECTED]>
diff --git a/arch/alpha/boot/tools/mkbb.c b/arch/alpha/boot/tools/mkbb.c
index 632a7fd..1185778 100644
--- a/arch/alpha/boot/tools/mkbb.c
+++ b/arch/alpha/boot/tools/mkbb.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
/* Minimal definition of disklabel, so we don't have to include
@@ -114,7 +115,7 @@ int main(int argc, char ** argv)
nread = read(fd, _image, sizeof(bootblock));
if(nread != sizeof(bootblock)) {
perror("lxboot read");
- fprintf(stderr, "expected %d, got %d\n", sizeof(bootblock), nread);
+ fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
}
@@ -122,7 +123,7 @@ int main(int argc, char ** argv)
nread = read(dev, _from_disk, sizeof(bootblock));
if(nread != sizeof(bootblock)) {
perror("bootblock read");
- fprintf(stderr, "expected %d, got %d\n", sizeof(bootblock), nread);
+ fprintf(stderr, "expected %zd, got %d\n", sizeof(bootblock), nread);
exit(0);
}
--
Meelis Roos ([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: [ck] Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Michael Chang wrote: > > I do recall there is one issue on which Con wouldn't budge -- anything > that involved boosting certain kinds of processes in the kernel. I did that myself, so that's a non-issue. No. The complaints were about the CK scheduler not being as responsive under load as even the _old_ scheduler was. I don't know why people ignore this fact. It was a long thread back in March or April, and I'm pretty sure the CK mailing list was cc'd. Sure, most people don't actually have load-averages above ten etc, but it's important to do those well _too_. Linus - 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: NETPOLL=y , NETDEVICES=n compile error ( Re: 2.6.23-rc1-mm1 )
On Sat, 28 Jul 2007 17:44:45 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > Hi, > > I got this compile error with a randconfig ( > http://194.231.229.228/MM/randconfig-auto-82.broken.netpoll.c ). > > ... > > net/core/netpoll.c: In function 'netpoll_poll': > net/core/netpoll.c:155: error: 'struct net_device' has no member named > 'poll_controller' > net/core/netpoll.c:159: error: 'struct net_device' has no member named > 'poll_controller' > net/core/netpoll.c: In function 'netpoll_setup': > net/core/netpoll.c:670: error: 'struct net_device' has no member named > 'poll_controller' > make[2]: *** [net/core/netpoll.o] Error 1 > make[1]: *** [net/core] Error 2 > make: *** [net] Error 2 > make: *** Waiting for unfinished jobs > > ... > > > I think is because KGDBOE selects just NETPOLL. > Looks like it. Select went and selected NETPOLL and NETPOLL_TRAP but things like CONFIG_NETDEVICES and CONFIG_NET_POLL_CONTROLLER remain unset. `select' remains evil. Something like this.. --- a/lib/Kconfig.kgdb~kgdb-kconfig-fix +++ a/lib/Kconfig.kgdb @@ -175,8 +175,7 @@ endchoice config KGDBOE tristate "KGDB: On ethernet" if !KGDBOE_NOMODULE depends on m && KGDB - select NETPOLL - select NETPOLL_TRAP + depends on NETPOLL_TRAP && NET_POLL_CONTROLLER help Uses the NETPOLL API to communicate with the host GDB via UDP. In order for this to work, the ethernet interface specified must _ - 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 alpha objstrip.c compilation warnings
In current 2.6.23-rc1+git, make bootimage gives the following warnings
while compiling objstrip.c. The patch below fixes these warnings by
casting strncmp argument to char * - it does not seem feasible to change
its type in struct elfhdr.
HOSTCC arch/alpha/boot/tools/objstrip
arch/alpha/boot/tools/objstrip.c: In function 'main':
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of 'strlen' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of 'strlen' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of '__builtin_strcmp' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of 'strlen' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of '__builtin_strcmp' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of '__builtin_strcmp' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of '__builtin_strcmp' differ in signedness
arch/alpha/boot/tools/objstrip.c:147: warning: pointer targets in passing
argument 1 of 'strncmp' differ in signedness
Signed-off-by: Meelis Roos <[EMAIL PROTECTED]>
diff --git a/arch/alpha/boot/tools/objstrip.c b/arch/alpha/boot/tools/objstrip.c
index 96154e7..ef18382 100644
--- a/arch/alpha/boot/tools/objstrip.c
+++ b/arch/alpha/boot/tools/objstrip.c
@@ -144,7 +144,7 @@ main (int argc, char *argv[])
#ifdef __ELF__
elf = (struct elfhdr *) buf;
-if (elf->e_ident[0] == 0x7f && strncmp(elf->e_ident + 1, "ELF", 3) == 0) {
+if (elf->e_ident[0] == 0x7f && strncmp((char *)elf->e_ident + 1, "ELF", 3)
== 0) {
if (elf->e_type != ET_EXEC) {
fprintf(stderr, "%s: %s is not an ELF executable\n",
prog_name, inname);
--
Meelis Roos ([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: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Ronni Nielsen wrote: > > - Linus 2.6.23-rc1 > + Linux 2.6.23-rc1 > > Or are *you* now under versioning? > Or maybe a silent namechange of the kernel? Yeah, yeah, my fingers get confused. I type "Linux" and "Linus" interchangably, and _most_ of the time I notice, but then at other times I don't look closely enough at what I wrote, so something slips through. And sometimes when my right hand is off by a key, I'm Kubys. My fingers have minds all their own. Linus - 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: mm/sparse.c compile error ( Re: 2.6.23-rc1-mm1 )
On Sat, 28 Jul 2007 19:07:22 +0200 Gabriel C <[EMAIL PROTECTED]> wrote: > Hi, > > next randconfig error ( > http://194.231.229.228/MM/randconfig-auto-87.mm_sparse.error ) > > > ... > > mm/sparse.c: In function 'sparse_init': > mm/sparse.c:482: error: implicit declaration of function > 'sparse_early_usemap_alloc' > mm/sparse.c:482: warning: assignment makes pointer from integer without a cast > make[1]: *** [mm/sparse.o] Error 1 > make: *** [mm] Error 2 > make: *** Waiting for unfinished jobs > > ... > > > guessing while this patch , but I am not really sure : > > fix-corruption-of-memmap-on-ia64-sparsemem-when-mem_section-is-not-a-power-of-2.patch > That seems to have been fixed by one of the post-2.6.23-rc1-mm1 patches I merged, thanks. - 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: [ck] Re: Linus 2.6.23-rc1
On Jul 28 2007 10:12, Linus Torvalds wrote: > >The fact is, I've _always_ considered the desktop to be the most important >part. [...] >The fact is, most kernel developers realize that Linux is used in >different places, on different machines, and with different loads. You >cannot make _everybody_ happy, but you can try to do as good a job as >possible. And doing "as good a job as possible" very much includes not >focusing on any particular load. You cannot please everybody in the scheduler question, that is clear, then why not offer dedicated scheduling alternatives (plugsched comes to mind) and let them choose what pleases them most, and handles their workload best? 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/
[PATCH] fix alpha boot/main.c warning
In current 2.6.23-rc1+git, make bootimage gives the following warning
while compiling arch/alpha/boot/main.c. The patch below fixes the
warning by casting callback argument explicitly to void*. The original
value comes from START_ADDR macro and is clearly numeric so only cast it
for the callback.
CC arch/alpha/boot/main.o
arch/alpha/boot/main.c: In function 'load':
arch/alpha/boot/main.c:135: warning: passing argument 3 of 'callback_read'
makes pointer from integer without a cast
Signed-off-by: Meelis Roos <[EMAIL PROTECTED]>
diff --git a/arch/alpha/boot/main.c b/arch/alpha/boot/main.c
index 90ed55b..89f3be0 100644
--- a/arch/alpha/boot/main.c
+++ b/arch/alpha/boot/main.c
@@ -132,7 +132,7 @@ static inline long load(long dev, unsigned long addr,
unsigned long count)
if (result)
srm_printk("Boot file specification (%s) not implemented\n",
bootfile);
- return callback_read(dev, count, addr, boot_size/512 + 1);
+ return callback_read(dev, count, (void *)addr, boot_size/512 + 1);
}
/*
--
Meelis Roos ([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] optimize x86 page faults like all other achitectures and kill notifier cruft
x86(-64) are the last architectures still using the page fault notifier
cruft for the kprobes page fault hook. This patch converts them to the
proper direct calls, and removes the now unused pagefault notifier bits
aswell as the cruft in kprobes.c that was related to this mess.
I know Andi didn't really like this, but all other architecture
maintainers agreed the direct calls are much better and besides the
obvious cruft removal a common way of dealing with kprobes across
architectures is important aswell.
Signed-off-by: Christoph Hellwig <[EMAIL PROTECTED]>
Index: linux-2.6/arch/i386/kernel/kprobes.c
===
--- linux-2.6.orig/arch/i386/kernel/kprobes.c 2007-07-26 19:02:15.0
+0200
+++ linux-2.6/arch/i386/kernel/kprobes.c2007-07-27 20:20:45.0
+0200
@@ -579,7 +579,7 @@ out:
return 1;
}
-static int __kprobes kprobe_fault_handler(struct pt_regs *regs, int trapnr)
+int __kprobes kprobe_fault_handler(struct pt_regs *regs, int trapnr)
{
struct kprobe *cur = kprobe_running();
struct kprobe_ctlblk *kcb = get_kprobe_ctlblk();
@@ -661,7 +661,6 @@ int __kprobes kprobe_exceptions_notify(s
ret = NOTIFY_STOP;
break;
case DIE_GPF:
- case DIE_PAGE_FAULT:
/* kprobe_running() needs smp_processor_id() */
preempt_disable();
if (kprobe_running() &&
Index: linux-2.6/arch/i386/mm/fault.c
===
--- linux-2.6.orig/arch/i386/mm/fault.c 2007-07-26 19:02:15.0 +0200
+++ linux-2.6/arch/i386/mm/fault.c 2007-07-27 20:20:45.0 +0200
@@ -25,6 +25,7 @@
#include
#include
#include
+#include
#include
#include
@@ -32,33 +33,27 @@
extern void die(const char *,struct pt_regs *,long);
-static ATOMIC_NOTIFIER_HEAD(notify_page_fault_chain);
-
-int register_page_fault_notifier(struct notifier_block *nb)
+#ifdef CONFIG_KPROBES
+static inline int notify_page_fault(struct pt_regs *regs)
{
- vmalloc_sync_all();
- return atomic_notifier_chain_register(_page_fault_chain, nb);
-}
-EXPORT_SYMBOL_GPL(register_page_fault_notifier);
+ int ret = 0;
-int unregister_page_fault_notifier(struct notifier_block *nb)
-{
- return atomic_notifier_chain_unregister(_page_fault_chain, nb);
-}
-EXPORT_SYMBOL_GPL(unregister_page_fault_notifier);
+ /* kprobe_running() needs smp_processor_id() */
+ if (!user_mode_vm(regs)) {
+ preempt_disable();
+ if (kprobe_running() && kprobe_fault_handler(regs, 14))
+ ret = 1;
+ preempt_enable();
+ }
-static inline int notify_page_fault(struct pt_regs *regs, long err)
+ return ret;
+}
+#else
+static inline int notify_page_fault(struct pt_regs *regs)
{
- struct die_args args = {
- .regs = regs,
- .str = "page fault",
- .err = err,
- .trapnr = 14,
- .signr = SIGSEGV
- };
- return atomic_notifier_call_chain(_page_fault_chain,
- DIE_PAGE_FAULT, );
+ return 0;
}
+#endif
/*
* Return EIP plus the CS segment base. The segment limit is also
@@ -330,7 +325,7 @@ fastcall void __kprobes do_page_fault(st
if (unlikely(address >= TASK_SIZE)) {
if (!(error_code & 0x000d) && vmalloc_fault(address) >= 0)
return;
- if (notify_page_fault(regs, error_code) == NOTIFY_STOP)
+ if (notify_page_fault(regs))
return;
/*
* Don't take the mm semaphore here. If we fixup a prefetch
@@ -339,7 +334,7 @@ fastcall void __kprobes do_page_fault(st
goto bad_area_nosemaphore;
}
- if (notify_page_fault(regs, error_code) == NOTIFY_STOP)
+ if (notify_page_fault(regs))
return;
/* It's safe to allow irq's after cr2 has been saved and the vmalloc
Index: linux-2.6/arch/x86_64/kernel/kprobes.c
===
--- linux-2.6.orig/arch/x86_64/kernel/kprobes.c 2007-07-26 19:02:15.0
+0200
+++ linux-2.6/arch/x86_64/kernel/kprobes.c 2007-07-27 20:20:45.0
+0200
@@ -652,7 +652,6 @@ int __kprobes kprobe_exceptions_notify(s
ret = NOTIFY_STOP;
break;
case DIE_GPF:
- case DIE_PAGE_FAULT:
/* kprobe_running() needs smp_processor_id() */
preempt_disable();
if (kprobe_running() &&
Index: linux-2.6/arch/x86_64/mm/fault.c
===
--- linux-2.6.orig/arch/x86_64/mm/fault.c 2007-07-26 19:02:15.0
+0200
+++ linux-2.6/arch/x86_64/mm/fault.c2007-07-27 20:20:45.0 +0200
@@ -25,6 +25,7 @@
Re: Linus 2.6.23-rc1
On Sat, 28 Jul 2007, Kasper Sandberg wrote: > > First off, i've personally run tests on many more machines than my own, > i've had lots of people try on their machines, and i've seen totally > unrelated posts to lkml, plus i've seen the experiences people are > writing about on IRC. Frankly, im not just thinking of myself. Ok, good. Has anybody tried to figure out why 3D games seem to be such a special case? I know Ingo looked at it, and seemed to think that he found and fixed something. But it sounds like it's worth a lot more discussion. > Okay, i wasnt going to ask, but ill do it anyway, did you even read the > threads about SD? I don't _ever_ go on specialty mailing lists. I don't read -mm, and I don't read the -fs mailing lists. I don't think they are interesting. And I tried to explain why: people who concentrate on one thing tend to become this self-selecting group that never looks at anything else, and then rejects outside input from people who hadn't become part of the "mind meld". That's what I think I saw - I saw the reactions from where external people were talking and cc'ing me. And yes, it's quite possible that I also got a very one-sided picture of it. I'm not disputing that. Con was also ill for a rather critical period, which was certainly not helping it all. > Con was extremely polite to everyone, and he did work > with a multitude of people, you seem to be totally deadlocked into the > ONE incident with a person that was unhappy with SD, simply for being a > fair scheduler. Hey, maybe that one incident just ended up being a rather big portion of what I saw. Too bad. That said, the end result (Con's public gripes about other kernel developers) mostly reinforced my opinion that I did the right choice. But maybe you can show a better side of it all. I don't think _any_ scheduler is perfect, and almost all of the time, the RightAnswer(tm) ends up being not "one or the other", but "somewhere in between". It's not like we've come to the end of the road: the baseline has just improved. If you guys can show that SD actually is better at some loads, without penalizing others, we can (and will) revisit this issue. So what you should take away from this is that: from what I saw over the last couple of months, it really wasn't much of a decision. The difference in how Ingo and Con reacted to peoples reports was pretty stark. And no, I haven't followed the ck mailing list, and so yes, I obviously did get just a part of the picture, but the part I got was pretty damn unambiguous. But at the same time, no technical decision is ever written in stone. It's all a balancing act. I've replaced the scheduler before, I'm 100% sure we'll replace it again. Schedulers are actually not at all that important in the end: they are a very very small detail in the kernel. Linus - 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.23-rc1, KVM-AMD problem
Hi, I'm getting periodic oopses running KVM-33 on 2.6.23-rc1. Here is a digital photo of the oops. Alarmingly, a lot of the time it triple faults the machine and I don't get a chance to grab it. This time I was lucky, though. http://devzero.co.uk/~alistair/kvm-2.6.23-rc1.jpg Unfortunately, some of the oops text scrolled out of the screen. I will endeavour to reproduce the bug over serial console, but I can make no guarantees. The CPU is an AMD X2 BE-2350, chipset is AMD 690G. -- Cheers, Alistair. 137/1 Warrender Park Road, Edinburgh, UK. - 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/
