* Re: [PATCH] mm: fix page_mkclean_one
@ 2007-02-01 22:40 Mark Groves
2007-02-02 8:42 ` Nick Piggin
0 siblings, 1 reply; 45+ messages in thread
From: Mark Groves @ 2007-02-01 22:40 UTC (permalink / raw)
To: linux-kernel
Hi,
I have been been seeing a problem when using sendfile repeatedly on an
SMP server, which I believe is related to the problem that was
discovered recently with marking dirty pages. The bug, as well as a test
script, is listed at http://bugzilla.kernel.org/show_bug.cgi?id=7650.
Currently, we're experiencing errors where part of a previous packet is
being sent out rather than the current packet.
I have applied the patch Linus posted to a 2.6.19 kernel but am still
getting the problem. So I am wondering if there are any other places in
the kernel which mark pages as dirty which might require a similar
patch?
Regards,
Mark Groves
Researcher
University of Waterloo
Waterloo, Ontario, Canada
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2007-02-01 22:40 [PATCH] mm: fix page_mkclean_one Mark Groves
@ 2007-02-02 8:42 ` Nick Piggin
2007-02-02 13:08 ` Evgeniy Polyakov
0 siblings, 1 reply; 45+ messages in thread
From: Nick Piggin @ 2007-02-02 8:42 UTC (permalink / raw)
To: Mark Groves; +Cc: linux-kernel, netdev
Mark Groves wrote:
> Hi,
>
>
> I have been been seeing a problem when using sendfile repeatedly on an
> SMP server, which I believe is related to the problem that was
> discovered recently with marking dirty pages. The bug, as well as a test
> script, is listed at http://bugzilla.kernel.org/show_bug.cgi?id=7650.
> Currently, we're experiencing errors where part of a previous packet is
> being sent out rather than the current packet.
>
> I have applied the patch Linus posted to a 2.6.19 kernel but am still
> getting the problem. So I am wondering if there are any other places in
> the kernel which mark pages as dirty which might require a similar
> patch?
Your issue is not related, firstly because the page_mkclean bug did not
exist before 2.6.19 kernels.
Anyway, I had a look at your bugzilla test-case and managed to slim it
down to something that easily shows what the problem is (available on
request) -- the problem is that recipient of the sendfile is seeing
modifications that occur to the source file _after_ the sender has
completed the sendfile, because the file pages are not copied but
queued.
I think the usual approach to what you are trying to do is to set TCP_CORK,
then write(2) the header into the socket, then sendfile directly from the
file you want.
Another approach I guess is to implement an ack in your userland protocol
so you do not modify the sendfile source file until the client acks that
it has all the data.
I'm not sure if there are any other usual ways to do this (ie. a barrier
for sendfile, to ensure it will not pick up "future" modifications to the
file). netdev cc'ed, someone there might have additional comments.
Please close this bug if/when you are satisfied it is not a kernel problem.
Thanks,
Nick
--
SUSE Labs, Novell Inc.
Send instant messages to your online friends http://au.messenger.yahoo.com
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2007-02-02 8:42 ` Nick Piggin
@ 2007-02-02 13:08 ` Evgeniy Polyakov
0 siblings, 0 replies; 45+ messages in thread
From: Evgeniy Polyakov @ 2007-02-02 13:08 UTC (permalink / raw)
To: Nick Piggin; +Cc: Mark Groves, linux-kernel, netdev
On Fri, Feb 02, 2007 at 07:42:52PM +1100, Nick Piggin (nickpiggin@yahoo.com.au) wrote:
> Anyway, I had a look at your bugzilla test-case and managed to slim it
> down to something that easily shows what the problem is (available on
> request) -- the problem is that recipient of the sendfile is seeing
> modifications that occur to the source file _after_ the sender has
> completed the sendfile, because the file pages are not copied but
> queued.
>
> I think the usual approach to what you are trying to do is to set TCP_CORK,
> then write(2) the header into the socket, then sendfile directly from the
> file you want.
>
> Another approach I guess is to implement an ack in your userland protocol
> so you do not modify the sendfile source file until the client acks that
> it has all the data.
Mark, don't you use e1000 or other scatter-gather capable nic with
checksum offload? Likely yes.
Actual data sucking in that case happens when packet is supposed to be
transmitted by the NIC, not when sendfile() is returned. The same
applies to the case, when you have fancy egress filtering.
It is not allowed to modify pages until they are really transmitted, if
you want data integrity.
There are _no_ bugs in network or VFS cache in this test case.
> I'm not sure if there are any other usual ways to do this (ie. a barrier
> for sendfile, to ensure it will not pick up "future" modifications to the
> file). netdev cc'ed, someone there might have additional comments.
>
> Please close this bug if/when you are satisfied it is not a kernel problem.
>
> Thanks,
> Nick
>
> --
> SUSE Labs, Novell Inc.
> Send instant messages to your online friends http://au.messenger.yahoo.com
--
Evgeniy Polyakov
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
@ 2006-12-28 15:50 martin
0 siblings, 0 replies; 45+ messages in thread
From: martin @ 2006-12-28 15:50 UTC (permalink / raw)
To: Linus Torvalds, Guillaume Chazarain
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Thu Dec 28 15:09 , Guillaume Chazarain sent:
>I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/
>I have corruption with every Fedora release kernel except the first, that is
>2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit
>some corruption.
Confirm that I see corruption with Fedora kernel 2.6.18-1.2239.fc5:
...
Chunk 142969 corrupted (0-1459) (2580-4039)
Expected 121, got 0
Written as (89632)127652(124721)
Chunk 142976 corrupted (0-1459) (512-1971)
Expected 128, got 0
Written as (121734)128324(108589)
Checking chunk 143639/143640 (99%)
$ uname -a
Linux 2.6.18-1.2239.fc5 #1 Fri Nov 10 13:04:06 EST 2006 i686 athlon i386 GNU/Linux
/Martin
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
@ 2006-12-24 8:10 Gordon Farquharson
2006-12-24 8:43 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: Gordon Farquharson @ 2006-12-24 8:10 UTC (permalink / raw)
To: Martin Michlmayr
Cc: Peter Zijlstra, Andrei Popa, Andrew Morton, Linus Torvalds,
Hugh Dickins, Nick Piggin, Arjan van de Ven,
Linux Kernel Mailing List
On 12/22/06, Martin Michlmayr <tbm@cyrius.com> wrote:
> * Peter Zijlstra <a.p.zijlstra@chello.nl> [2006-12-22 14:25]:
> > > .... and it failed.
> > Since you are on ARM you might want to try with the page_mkclean_one
> > cleanup patch too.
>
> I've already tried it and it didn't work. I just tried it again
> together with Linus' patch and the two from Andrew and it still fails.
> (For reference, the patch is attached.)
I can confirm this behaviour with 2.6.19 and the patches mentioned
above (cumulative patch for 2.6.19 appended to the end of this email).
Is there any way to provide any debugging information that may help
solve the problem ? Would it help to know the nature of the corruption
e.g. an analysis of the corruption in the file ? I have previously
asked apt developers if they wanted to look at the corrupted cache
files, but there were no takers then.
BTW, I decided to try Linus's test program [1] on ARM (I don't think
that anybody had tried it on ARM before).
Since we see file corruption with 2.6.18 + [PATCH] mm: tracking shared
dirty pages [2], I ran Linus's program on machines with the following
setups:
2.6.18 + the following patches
mm: tracking shared dirty pages [2]
mm: balance dirty pages [3]
mm: optimize the new mprotect() code a bit [4]
mm: small cleanup of install_page() [5]
mm: fixup do_wp_page() [6]
mm: msync() cleanup [7]
$ ./mm-test | od -x
0000000 aaaa aaaa aaaa aaaa aaaa 0000 0000 0000
0000020 0000 0000 5555 5555 5555 5555 5555 5555
0000040 5555 5555 5555 5555
0000050
2.6.18 (no mm patches)
$ ./mm-test | od -x
0000000 aaaa aaaa aaaa aaaa aaaa aaaa aaaa aaaa
0000020 aaaa aaaa 5555 5555 5555 5555 5555 5555
0000040 5555 5555 5555 5555
0000050
I don't know if this helps at all.
Gordon
[1] http://lkml.org/lkml/2006/12/19/200
[2] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=d08b3851da41d0ee60851f2c75b118e1f7a5fc89
[3] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
[4] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=c1e6098b23bb46e2b488fe9a26f831f867157483
[5] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=e88dd6c11c5aef74d8b74a062767add53315533b
[6] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=ee6a6457886a80415db209e87033b63f2b06558c
[7] http://git.kernel.org/git/?p=linux/kernel/git/torvalds/linux-2.6.git;a=commitdiff;h=204ec841fbea3e5138168edbc3a76d46747cc987
diff -Naupr linux-2.6.19.orig/fs/buffer.c linux-2.6.19/fs/buffer.c
--- linux-2.6.19.orig/fs/buffer.c 2006-11-29 14:57:37.000000000 -0700
+++ linux-2.6.19/fs/buffer.c 2006-12-21 01:16:31.000000000 -0700
@@ -2832,7 +2832,7 @@ int try_to_free_buffers(struct page *pag
int ret = 0;
BUG_ON(!PageLocked(page));
- if (PageWriteback(page))
+ if (PageDirty(page) || PageWriteback(page))
return 0;
if (mapping == NULL) { /* can this still happen? */
@@ -2843,17 +2843,6 @@ int try_to_free_buffers(struct page *pag
spin_lock(&mapping->private_lock);
ret = drop_buffers(page, &buffers_to_free);
spin_unlock(&mapping->private_lock);
- if (ret) {
- /*
- * If the filesystem writes its buffers by hand (eg ext3)
- * then we can have clean buffers against a dirty page. We
- * clean the page here; otherwise later reattachment of buffers
- * could encounter a non-uptodate page, which is unresolvable.
- * This only applies in the rare case where try_to_free_buffers
- * succeeds but the page is not freed.
- */
- clear_page_dirty(page);
- }
out:
if (buffers_to_free) {
struct buffer_head *bh = buffers_to_free;
diff -Naupr linux-2.6.19.orig/fs/hugetlbfs/inode.c
linux-2.6.19/fs/hugetlbfs/inode.c
--- linux-2.6.19.orig/fs/hugetlbfs/inode.c 2006-11-29
14:57:37.000000000 -0700
+++ linux-2.6.19/fs/hugetlbfs/inode.c 2006-12-21 01:15:21.000000000 -0700
@@ -176,7 +176,7 @@ static int hugetlbfs_commit_write(struct
static void truncate_huge_page(struct page *page)
{
- clear_page_dirty(page);
+ cancel_dirty_page(page, /* No IO accounting for huge pages? */0);
ClearPageUptodate(page);
remove_from_page_cache(page);
put_page(page);
diff -Naupr linux-2.6.19.orig/include/linux/page-flags.h
linux-2.6.19/include/linux/page-flags.h
--- linux-2.6.19.orig/include/linux/page-flags.h 2006-11-29
14:57:37.000000000 -0700
+++ linux-2.6.19/include/linux/page-flags.h 2006-12-21
01:15:21.000000000 -0700
@@ -253,15 +253,11 @@ static inline void SetPageUptodate(struc
struct page; /* forward declaration */
-int test_clear_page_dirty(struct page *page);
+extern void cancel_dirty_page(struct page *page, unsigned int account_size);
+
int test_clear_page_writeback(struct page *page);
int test_set_page_writeback(struct page *page);
-static inline void clear_page_dirty(struct page *page)
-{
- test_clear_page_dirty(page);
-}
-
static inline void set_page_writeback(struct page *page)
{
test_set_page_writeback(page);
diff -Naupr linux-2.6.19.orig/mm/memory.c linux-2.6.19/mm/memory.c
--- linux-2.6.19.orig/mm/memory.c 2006-11-29 14:57:37.000000000 -0700
+++ linux-2.6.19/mm/memory.c 2006-12-21 01:15:21.000000000 -0700
@@ -1832,6 +1832,33 @@ void unmap_mapping_range(struct address_
}
EXPORT_SYMBOL(unmap_mapping_range);
+static void check_last_page(struct address_space *mapping, loff_t size)
+{
+ pgoff_t index;
+ unsigned int offset;
+ struct page *page;
+
+ if (!mapping)
+ return;
+ offset = size & ~PAGE_MASK;
+ if (!offset)
+ return;
+ index = size >> PAGE_SHIFT;
+ page = find_lock_page(mapping, index);
+ if (page) {
+ unsigned int check = 0;
+ unsigned char *kaddr = kmap_atomic(page, KM_USER0);
+ do {
+ check += kaddr[offset++];
+ } while (offset < PAGE_SIZE);
+ kunmap_atomic(kaddr,KM_USER0);
+ unlock_page(page);
+ page_cache_release(page);
+ if (check)
+ printk("%s: BADNESS: truncate check %u\n",
current->comm, check);
+ }
+}
+
/**
* vmtruncate - unmap mappings "freed" by truncate() syscall
* @inode: inode of the file used
@@ -1865,6 +1892,7 @@ do_expand:
goto out_sig;
if (offset > inode->i_sb->s_maxbytes)
goto out_big;
+ check_last_page(mapping, inode->i_size);
i_size_write(inode, offset);
out_truncate:
diff -Naupr linux-2.6.19.orig/mm/page-writeback.c
linux-2.6.19/mm/page-writeback.c
--- linux-2.6.19.orig/mm/page-writeback.c 2006-11-29
14:57:37.000000000 -0700
+++ linux-2.6.19/mm/page-writeback.c 2006-12-21 01:26:53.000000000 -0700
@@ -843,39 +843,6 @@ int set_page_dirty_lock(struct page *pag
EXPORT_SYMBOL(set_page_dirty_lock);
/*
- * Clear a page's dirty flag, while caring for dirty memory accounting.
- * Returns true if the page was previously dirty.
- */
-int test_clear_page_dirty(struct page *page)
-{
- struct address_space *mapping = page_mapping(page);
- unsigned long flags;
-
- if (mapping) {
- write_lock_irqsave(&mapping->tree_lock, flags);
- if (TestClearPageDirty(page)) {
- radix_tree_tag_clear(&mapping->page_tree,
- page_index(page),
- PAGECACHE_TAG_DIRTY);
- write_unlock_irqrestore(&mapping->tree_lock, flags);
- /*
- * We can continue to use `mapping' here because the
- * page is locked, which pins the address_space
- */
- if (mapping_cap_account_dirty(mapping)) {
- page_mkclean(page);
- dec_zone_page_state(page, NR_FILE_DIRTY);
- }
- return 1;
- }
- write_unlock_irqrestore(&mapping->tree_lock, flags);
- return 0;
- }
- return TestClearPageDirty(page);
-}
-EXPORT_SYMBOL(test_clear_page_dirty);
-
-/*
* Clear a page's dirty flag, while caring for dirty memory accounting.
* Returns true if the page was previously dirty.
*
diff -Naupr linux-2.6.19.orig/mm/rmap.c linux-2.6.19/mm/rmap.c
--- linux-2.6.19.orig/mm/rmap.c 2006-11-29 14:57:37.000000000 -0700
+++ linux-2.6.19/mm/rmap.c 2006-12-22 23:25:09.000000000 -0700
@@ -432,7 +432,7 @@ static int page_mkclean_one(struct page
{
struct mm_struct *mm = vma->vm_mm;
unsigned long address;
- pte_t *pte, entry;
+ pte_t *pte;
spinlock_t *ptl;
int ret = 0;
@@ -444,17 +444,18 @@ static int page_mkclean_one(struct page
if (!pte)
goto out;
- if (!pte_dirty(*pte) && !pte_write(*pte))
- goto unlock;
+ if (pte_dirty(*pte) || pte_write(*pte)) {
+ pte_t entry;
- entry = ptep_get_and_clear(mm, address, pte);
- entry = pte_mkclean(entry);
- entry = pte_wrprotect(entry);
- ptep_establish(vma, address, pte, entry);
- lazy_mmu_prot_update(entry);
- ret = 1;
+ flush_cache_page(vma, address, pte_pfn(*pte));
+ entry = ptep_clear_flush(vma, address, pte);
+ entry = pte_wrprotect(entry);
+ entry = pte_mkclean(entry);
+ set_pte_at(vma, address, pte, entry);
+ lazy_mmu_prot_update(entry);
+ ret = 1;
+ }
-unlock:
pte_unmap_unlock(pte, ptl);
out:
return ret;
@@ -489,6 +490,8 @@ int page_mkclean(struct page *page)
if (mapping)
ret = page_mkclean_file(mapping, page);
}
+ if (page_test_and_clear_dirty(page))
+ ret = 1;
return ret;
}
@@ -587,8 +590,6 @@ void page_remove_rmap(struct page *page)
* Leaving it set also helps swapoff to reinstate ptes
* faster for those pages still in swapcache.
*/
- if (page_test_and_clear_dirty(page))
- set_page_dirty(page);
__dec_zone_page_state(page,
PageAnon(page) ? NR_ANON_PAGES :
NR_FILE_MAPPED);
}
@@ -607,6 +608,7 @@ static int try_to_unmap_one(struct page
pte_t pteval;
spinlock_t *ptl;
int ret = SWAP_AGAIN;
+ struct page *dirty_page = NULL;
address = vma_address(page, vma);
if (address == -EFAULT)
@@ -633,7 +635,7 @@ static int try_to_unmap_one(struct page
/* Move the dirty bit to the physical page now the pte is gone. */
if (pte_dirty(pteval))
- set_page_dirty(page);
+ dirty_page = page;
/* Update high watermark before we lower rss */
update_hiwater_rss(mm);
@@ -684,6 +686,8 @@ static int try_to_unmap_one(struct page
out_unmap:
pte_unmap_unlock(pte, ptl);
+ if (dirty_page)
+ set_page_dirty(dirty_page);
out:
return ret;
}
@@ -915,6 +919,9 @@ int try_to_unmap(struct page *page, int
else
ret = try_to_unmap_file(page, migration);
+ if (page_test_and_clear_dirty(page))
+ set_page_dirty(page);
+
if (!page_mapped(page))
ret = SWAP_SUCCESS;
return ret;
diff -Naupr linux-2.6.19.orig/mm/truncate.c linux-2.6.19/mm/truncate.c
--- linux-2.6.19.orig/mm/truncate.c 2006-11-29 14:57:37.000000000 -0700
+++ linux-2.6.19/mm/truncate.c 2006-12-23 13:21:42.000000000 -0700
@@ -50,6 +50,21 @@ static inline void truncate_partial_page
do_invalidatepage(page, partial);
}
+void cancel_dirty_page(struct page *page, unsigned int account_size)
+{
+ /* If we're cancelling the page, it had better not be mapped
any more */+ if (page_mapped(page)) {
+ static unsigned int warncount;
+
+ WARN_ON(++warncount < 5);
+ }
+
+ if (TestClearPageDirty(page) && account_size &&
+ mapping_cap_account_dirty(page->mapping))
+ dec_zone_page_state(page, NR_FILE_DIRTY);
+}
+
+
/*
* If truncate cannot remove the fs-private metadata from the page, the page
* becomes anonymous. It will be left on the LRU and may even be mapped into
@@ -66,10 +81,11 @@ truncate_complete_page(struct address_sp
if (page->mapping != mapping)
return;
+ cancel_dirty_page(page, PAGE_CACHE_SIZE);
+
if (PagePrivate(page))
do_invalidatepage(page, 0);
- clear_page_dirty(page);
ClearPageUptodate(page);
ClearPageMappedToDisk(page);
remove_from_page_cache(page);
@@ -348,7 +364,6 @@ int invalidate_inode_pages2_range(struct
for (i = 0; !ret && i < pagevec_count(&pvec); i++) {
struct page *page = pvec.pages[i];
pgoff_t page_index;
- int was_dirty;
lock_page(page);
if (page->mapping != mapping) {
@@ -384,12 +399,8 @@ int invalidate_inode_pages2_range(struct
PAGE_CACHE_SIZE, 0);
}
}
- was_dirty = test_clear_page_dirty(page);
- if (!invalidate_complete_page2(mapping, page)) {
- if (was_dirty)
- set_page_dirty(page);
+ if (!invalidate_complete_page2(mapping, page))
ret = -EIO;
- }
unlock_page(page);
}
pagevec_release(&pvec);
--
Gordon Farquharson
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
2006-12-24 8:10 [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) Gordon Farquharson
@ 2006-12-24 8:43 ` Linus Torvalds
2006-12-26 16:17 ` Tobias Diedrich
0 siblings, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-24 8:43 UTC (permalink / raw)
To: Gordon Farquharson
Cc: Martin Michlmayr, Peter Zijlstra, Andrei Popa, Andrew Morton,
Hugh Dickins, Nick Piggin, Arjan van de Ven,
Linux Kernel Mailing List
On Sun, 24 Dec 2006, Gordon Farquharson wrote:
>
> Is there any way to provide any debugging information that may help
> solve the problem ?
I think we have people working on this. I know I'm trying to even come up
with an idea of what is going on. I don't think we know yet.
> Would it help to know the nature of the corruption e.g. an analysis
> of the corruption in the file ?
I actually think we know that, because Andrei already gave details. The
corruption seems to be basically a few pages that get zeroes at the end
rather than the expected contents. That's consistent with the page being
written out once, but then _not_ getting written out again despite being
dirtied some more.
But if you see ay other pattern, please holler, because that would be
interesting.
> BTW, I decided to try Linus's test program [1] on ARM (I don't think
> that anybody had tried it on ARM before).
You get the expected results, and in fact, I'd be very surprised if you
didn't. It's something subtler than that going on.
I now _suspect_ that we're talking about something like
- we started a writeout. The IO is still pending, and the page was
marked clean and is now in the "writeback" phase.
- a write happens to the page, and the page gets marked dirty again.
Marking the page dirty also marks all the _buffers_ in the page dirty,
but they were actually already dirty, because the IO hasn't completed
yet.
- the IO from the _previous_ write completes, and marks the buffers clean
again.
And no, thatr's not actually what is going on. The thing is, we actually
clear the buffer dirty bits when we start the IO, not when we end it, but
I think it is going to be this _kind_ of situation, where we missed
something, and marked it clean too late, and thus cleared a dirty bit.
I don't think it's a page table issue any more, it just doesn't look
likely with the ARM UP corruption. It's also not apparently even on a
cacheline boundary, so it probably is really a dirty bit that got cleared
wrogn due to some race with IO.
But right now we're all clueless. I personally suspect it's not even a new
bug: it's probably an old bug that simply didn't matter before.
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
2006-12-24 8:43 ` Linus Torvalds
@ 2006-12-26 16:17 ` Tobias Diedrich
2006-12-27 4:55 ` [PATCH] mm: fix page_mkclean_one David Miller
0 siblings, 1 reply; 45+ messages in thread
From: Tobias Diedrich @ 2006-12-26 16:17 UTC (permalink / raw)
To: Linus Torvalds
Cc: Gordon Farquharson, Martin Michlmayr, Peter Zijlstra,
Andrei Popa, Andrew Morton, Hugh Dickins, Nick Piggin,
Arjan van de Ven, Linux Kernel Mailing List
Linus Torvalds wrote:
> I don't think it's a page table issue any more, it just doesn't look
> likely with the ARM UP corruption. It's also not apparently even on a
> cacheline boundary, so it probably is really a dirty bit that got cleared
> wrogn due to some race with IO.
So, until now it's only been reported for SMP on i386?
I'm seeing the issue on my Pentium-M Notebook (Thinkpad R52) over
here, UP kernel, no preempt.
I've first seen it with 2.6.20-rc1, but am running 2.6.20-rc2 now.
The corruption pattern looks like the one already reported, rtorrent
hash check fails (for some files it succeeds at first, but
fails after "echo 1 > /proc/sys/vm/drop_caches"), the corruption is
zeroes at the end of page instead of data.
ii rtorrent 0.6.4-1 ncurses BitTorrent client based on LibTorren
ii libtorrent9 0.10.4-1 a C++ BitTorrent library
.config:
# Automatically generated make config: don't edit
# Linux kernel version: 2.6.20-rc2
# Mon Dec 25 14:00:03 2006
#
CONFIG_X86_32=y
CONFIG_GENERIC_TIME=y
CONFIG_LOCKDEP_SUPPORT=y
CONFIG_STACKTRACE_SUPPORT=y
CONFIG_SEMAPHORE_SLEEPERS=y
CONFIG_X86=y
CONFIG_MMU=y
CONFIG_GENERIC_ISA_DMA=y
CONFIG_GENERIC_IOMAP=y
CONFIG_GENERIC_BUG=y
CONFIG_GENERIC_HWEIGHT=y
CONFIG_ARCH_MAY_HAVE_PC_FDC=y
CONFIG_DMI=y
CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# Code maturity level options
#
CONFIG_EXPERIMENTAL=y
CONFIG_BROKEN_ON_SMP=y
CONFIG_INIT_ENV_ARG_LIMIT=32
#
# General setup
#
CONFIG_LOCALVERSION=""
CONFIG_LOCALVERSION_AUTO=y
CONFIG_SWAP=y
CONFIG_SYSVIPC=y
# CONFIG_IPC_NS is not set
CONFIG_POSIX_MQUEUE=y
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not set
# CONFIG_UTS_NS is not set
# CONFIG_AUDIT is not set
CONFIG_IKCONFIG=y
CONFIG_IKCONFIG_PROC=y
# CONFIG_SYSFS_DEPRECATED is not set
CONFIG_RELAY=y
CONFIG_INITRAMFS_SOURCE=""
CONFIG_CC_OPTIMIZE_FOR_SIZE=y
CONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not set
CONFIG_UID16=y
CONFIG_SYSCTL_SYSCALL=y
CONFIG_KALLSYMS=y
# CONFIG_KALLSYMS_ALL is not set
# CONFIG_KALLSYMS_EXTRA_PASS is not set
CONFIG_HOTPLUG=y
CONFIG_PRINTK=y
CONFIG_BUG=y
CONFIG_ELF_CORE=y
CONFIG_BASE_FULL=y
CONFIG_FUTEX=y
CONFIG_EPOLL=y
CONFIG_SHMEM=y
CONFIG_SLAB=y
CONFIG_VM_EVENT_COUNTERS=y
CONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not set
CONFIG_BASE_SMALL=0
# CONFIG_SLOB is not set
#
# Loadable module support
#
CONFIG_MODULES=y
CONFIG_MODULE_UNLOAD=y
CONFIG_MODULE_FORCE_UNLOAD=y
# CONFIG_MODVERSIONS is not set
# CONFIG_MODULE_SRCVERSION_ALL is not set
CONFIG_KMOD=y
#
# Block layer
#
CONFIG_BLOCK=y
CONFIG_LBD=y
CONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_LSF is not set
#
# IO Schedulers
#
CONFIG_IOSCHED_NOOP=y
CONFIG_IOSCHED_AS=y
CONFIG_IOSCHED_DEADLINE=y
CONFIG_IOSCHED_CFQ=y
CONFIG_DEFAULT_AS=y
# CONFIG_DEFAULT_DEADLINE is not set
# CONFIG_DEFAULT_CFQ is not set
# CONFIG_DEFAULT_NOOP is not set
CONFIG_DEFAULT_IOSCHED="anticipatory"
#
# Processor type and features
#
# CONFIG_SMP is not set
CONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_PARAVIRT is not set
# CONFIG_M386 is not set
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
CONFIG_MPENTIUMM=y
# CONFIG_MCORE2 is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_X86_GENERIC is not set
CONFIG_X86_CMPXCHG=y
CONFIG_X86_XADD=y
CONFIG_X86_L1_CACHE_SHIFT=6
CONFIG_RWSEM_XCHGADD_ALGORITHM=y
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set
CONFIG_GENERIC_CALIBRATE_DELAY=y
CONFIG_X86_WP_WORKS_OK=y
CONFIG_X86_INVLPG=y
CONFIG_X86_BSWAP=y
CONFIG_X86_POPAD_OK=y
CONFIG_X86_CMPXCHG64=y
CONFIG_X86_GOOD_APIC=y
CONFIG_X86_INTEL_USERCOPY=y
CONFIG_X86_USE_PPRO_CHECKSUM=y
CONFIG_X86_TSC=y
CONFIG_HPET_TIMER=y
CONFIG_HPET_EMULATE_RTC=y
CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set
CONFIG_X86_UP_APIC=y
CONFIG_X86_UP_IOAPIC=y
CONFIG_X86_LOCAL_APIC=y
CONFIG_X86_IO_APIC=y
CONFIG_X86_MCE=y
CONFIG_X86_MCE_NONFATAL=y
CONFIG_X86_MCE_P4THERMAL=y
CONFIG_VM86=y
# CONFIG_TOSHIBA is not set
# CONFIG_I8K is not set
# CONFIG_X86_REBOOTFIXUPS is not set
# CONFIG_MICROCODE is not set
# CONFIG_X86_MSR is not set
# CONFIG_X86_CPUID is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
CONFIG_DCDBAS=m
CONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set
CONFIG_PAGE_OFFSET=0xC0000000
CONFIG_ARCH_FLATMEM_ENABLE=y
CONFIG_ARCH_SPARSEMEM_ENABLE=y
CONFIG_ARCH_SELECT_MEMORY_MODEL=y
CONFIG_ARCH_POPULATES_NODE_MAP=y
CONFIG_SELECT_MEMORY_MODEL=y
CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set
CONFIG_FLATMEM=y
CONFIG_FLAT_NODE_MEM_MAP=y
CONFIG_SPARSEMEM_STATIC=y
CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set
# CONFIG_MATH_EMULATION is not set
CONFIG_MTRR=y
# CONFIG_EFI is not set
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not set
CONFIG_HZ_300=y
# CONFIG_HZ_1000 is not set
CONFIG_HZ=300
# CONFIG_KEXEC is not set
# CONFIG_RELOCATABLE is not set
CONFIG_PHYSICAL_ALIGN=0x100000
CONFIG_COMPAT_VDSO=y
#
# Power management options (ACPI, APM)
#
CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not set
# CONFIG_PM_SYSFS_DEPRECATED is not set
CONFIG_SOFTWARE_SUSPEND=y
CONFIG_PM_STD_PARTITION=""
#
# ACPI (Advanced Configuration and Power Interface) Support
#
CONFIG_ACPI=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_SLEEP_PROC_FS=y
# CONFIG_ACPI_SLEEP_PROC_SLEEP is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_HOTKEY=m
CONFIG_ACPI_FAN=y
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_THERMAL=y
# CONFIG_ACPI_ASUS is not set
CONFIG_ACPI_IBM=m
# CONFIG_ACPI_TOSHIBA is not set
# CONFIG_ACPI_CUSTOM_DSDT is not set
CONFIG_ACPI_BLACKLIST_YEAR=0
# CONFIG_ACPI_DEBUG is not set
CONFIG_ACPI_EC=y
CONFIG_ACPI_POWER=y
CONFIG_ACPI_SYSTEM=y
CONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not set
# CONFIG_ACPI_SBS is not set
#
# APM (Advanced Power Management) BIOS Support
#
# CONFIG_APM is not set
#
# CPU Frequency scaling
#
CONFIG_CPU_FREQ=y
CONFIG_CPU_FREQ_TABLE=y
# CONFIG_CPU_FREQ_DEBUG is not set
CONFIG_CPU_FREQ_STAT=y
# CONFIG_CPU_FREQ_STAT_DETAILS is not set
CONFIG_CPU_FREQ_DEFAULT_GOV_PERFORMANCE=y
# CONFIG_CPU_FREQ_DEFAULT_GOV_USERSPACE is not set
CONFIG_CPU_FREQ_GOV_PERFORMANCE=y
CONFIG_CPU_FREQ_GOV_POWERSAVE=y
CONFIG_CPU_FREQ_GOV_USERSPACE=y
CONFIG_CPU_FREQ_GOV_ONDEMAND=y
CONFIG_CPU_FREQ_GOV_CONSERVATIVE=y
#
# CPUFreq processor drivers
#
# CONFIG_X86_ACPI_CPUFREQ is not set
# CONFIG_X86_POWERNOW_K6 is not set
# CONFIG_X86_POWERNOW_K7 is not set
# CONFIG_X86_POWERNOW_K8 is not set
# CONFIG_X86_GX_SUSPMOD is not set
CONFIG_X86_SPEEDSTEP_CENTRINO=y
CONFIG_X86_SPEEDSTEP_CENTRINO_ACPI=y
CONFIG_X86_SPEEDSTEP_CENTRINO_TABLE=y
CONFIG_X86_SPEEDSTEP_ICH=y
CONFIG_X86_SPEEDSTEP_SMI=y
# CONFIG_X86_P4_CLOCKMOD is not set
# CONFIG_X86_CPUFREQ_NFORCE2 is not set
# CONFIG_X86_LONGRUN is not set
# CONFIG_X86_LONGHAUL is not set
#
# shared options
#
# CONFIG_X86_ACPI_CPUFREQ_PROC_INTF is not set
CONFIG_X86_SPEEDSTEP_LIB=y
# CONFIG_X86_SPEEDSTEP_RELAXED_CAP_CHECK is not set
#
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not set
CONFIG_PCI_GOANY=y
CONFIG_PCI_BIOS=y
CONFIG_PCI_DIRECT=y
CONFIG_PCI_MMCONFIG=y
CONFIG_PCIEPORTBUS=y
# CONFIG_HOTPLUG_PCI_PCIE is not set
CONFIG_PCIEAER=y
CONFIG_PCI_MSI=y
# CONFIG_PCI_MULTITHREAD_PROBE is not set
# CONFIG_PCI_DEBUG is not set
CONFIG_HT_IRQ=y
CONFIG_ISA_DMA_API=y
CONFIG_ISA=y
# CONFIG_EISA is not set
# CONFIG_MCA is not set
# CONFIG_SCx200 is not set
#
# PCCARD (PCMCIA/CardBus) support
#
CONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
CONFIG_PCMCIA=y
CONFIG_PCMCIA_LOAD_CIS=y
CONFIG_PCMCIA_IOCTL=y
CONFIG_CARDBUS=y
#
# PC-card bridges
#
CONFIG_YENTA=y
CONFIG_YENTA_O2=y
CONFIG_YENTA_RICOH=y
CONFIG_YENTA_TI=y
CONFIG_YENTA_ENE_TUNE=y
CONFIG_YENTA_TOSHIBA=y
# CONFIG_PD6729 is not set
# CONFIG_I82092 is not set
# CONFIG_I82365 is not set
# CONFIG_TCIC is not set
CONFIG_PCMCIA_PROBE=y
CONFIG_PCCARD_NONSTATIC=y
#
# PCI Hotplug Support
#
CONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not set
# CONFIG_HOTPLUG_PCI_COMPAQ is not set
CONFIG_HOTPLUG_PCI_IBM=y
CONFIG_HOTPLUG_PCI_ACPI=y
CONFIG_HOTPLUG_PCI_ACPI_IBM=y
# CONFIG_HOTPLUG_PCI_CPCI is not set
# CONFIG_HOTPLUG_PCI_SHPC is not set
#
# Executable file formats
#
CONFIG_BINFMT_ELF=y
CONFIG_BINFMT_AOUT=y
CONFIG_BINFMT_MISC=y
#
# Networking
#
CONFIG_NET=y
#
# Networking options
#
# CONFIG_NETDEBUG is not set
CONFIG_PACKET=y
CONFIG_PACKET_MMAP=y
CONFIG_UNIX=y
CONFIG_XFRM=y
# CONFIG_XFRM_USER is not set
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_NET_KEY is not set
CONFIG_INET=y
CONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not set
CONFIG_IP_FIB_HASH=y
# CONFIG_IP_PNP is not set
# CONFIG_NET_IPIP is not set
# CONFIG_NET_IPGRE is not set
# CONFIG_IP_MROUTE is not set
# CONFIG_ARPD is not set
CONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not set
CONFIG_INET_XFRM_MODE_TRANSPORT=y
CONFIG_INET_XFRM_MODE_TUNNEL=y
CONFIG_INET_XFRM_MODE_BEET=y
CONFIG_INET_DIAG=y
CONFIG_INET_TCP_DIAG=y
CONFIG_TCP_CONG_ADVANCED=y
CONFIG_TCP_CONG_BIC=y
CONFIG_TCP_CONG_CUBIC=y
CONFIG_TCP_CONG_WESTWOOD=y
# CONFIG_TCP_CONG_HTCP is not set
CONFIG_TCP_CONG_HSTCP=y
# CONFIG_TCP_CONG_HYBLA is not set
CONFIG_TCP_CONG_VEGAS=y
# CONFIG_TCP_CONG_SCALABLE is not set
# CONFIG_TCP_CONG_LP is not set
# CONFIG_TCP_CONG_VENO is not set
# CONFIG_DEFAULT_BIC is not set
CONFIG_DEFAULT_CUBIC=y
# CONFIG_DEFAULT_HTCP is not set
# CONFIG_DEFAULT_VEGAS is not set
# CONFIG_DEFAULT_WESTWOOD is not set
# CONFIG_DEFAULT_RENO is not set
CONFIG_DEFAULT_TCP_CONG="cubic"
# CONFIG_TCP_MD5SIG is not set
#
# IP: Virtual Server Configuration
#
# CONFIG_IP_VS is not set
CONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not set
CONFIG_IPV6_ROUTER_PREF=y
CONFIG_IPV6_ROUTE_INFO=y
# CONFIG_INET6_AH is not set
# CONFIG_INET6_ESP is not set
# CONFIG_INET6_IPCOMP is not set
# CONFIG_IPV6_MIP6 is not set
# CONFIG_INET6_XFRM_TUNNEL is not set
CONFIG_INET6_TUNNEL=y
CONFIG_INET6_XFRM_MODE_TRANSPORT=y
CONFIG_INET6_XFRM_MODE_TUNNEL=y
CONFIG_INET6_XFRM_MODE_BEET=y
# CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION is not set
CONFIG_IPV6_SIT=y
CONFIG_IPV6_TUNNEL=y
# CONFIG_IPV6_MULTIPLE_TABLES is not set
# CONFIG_NETWORK_SECMARK is not set
CONFIG_NETFILTER=y
# CONFIG_NETFILTER_DEBUG is not set
CONFIG_BRIDGE_NETFILTER=y
#
# Core Netfilter Configuration
#
CONFIG_NETFILTER_NETLINK=y
CONFIG_NETFILTER_NETLINK_QUEUE=y
CONFIG_NETFILTER_NETLINK_LOG=y
# CONFIG_NF_CONNTRACK_ENABLED is not set
CONFIG_NETFILTER_XTABLES=y
CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y
# CONFIG_NETFILTER_XT_TARGET_DSCP is not set
CONFIG_NETFILTER_XT_TARGET_MARK=y
CONFIG_NETFILTER_XT_TARGET_NFQUEUE=y
# CONFIG_NETFILTER_XT_TARGET_NFLOG is not set
CONFIG_NETFILTER_XT_MATCH_COMMENT=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not set
# CONFIG_NETFILTER_XT_MATCH_ESP is not set
# CONFIG_NETFILTER_XT_MATCH_LENGTH is not set
CONFIG_NETFILTER_XT_MATCH_LIMIT=y
CONFIG_NETFILTER_XT_MATCH_MAC=y
CONFIG_NETFILTER_XT_MATCH_MARK=y
# CONFIG_NETFILTER_XT_MATCH_POLICY is not set
CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
CONFIG_NETFILTER_XT_MATCH_PHYSDEV=y
CONFIG_NETFILTER_XT_MATCH_PKTTYPE=y
# CONFIG_NETFILTER_XT_MATCH_QUOTA is not set
CONFIG_NETFILTER_XT_MATCH_REALM=y
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set
# CONFIG_NETFILTER_XT_MATCH_STRING is not set
CONFIG_NETFILTER_XT_MATCH_TCPMSS=y
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
#
# IP: Netfilter Configuration
#
CONFIG_IP_NF_QUEUE=y
CONFIG_IP_NF_IPTABLES=y
CONFIG_IP_NF_MATCH_IPRANGE=y
CONFIG_IP_NF_MATCH_TOS=y
# CONFIG_IP_NF_MATCH_RECENT is not set
CONFIG_IP_NF_MATCH_ECN=y
CONFIG_IP_NF_MATCH_AH=y
# CONFIG_IP_NF_MATCH_TTL is not set
CONFIG_IP_NF_MATCH_OWNER=y
CONFIG_IP_NF_MATCH_ADDRTYPE=y
CONFIG_IP_NF_FILTER=y
CONFIG_IP_NF_TARGET_REJECT=y
CONFIG_IP_NF_TARGET_LOG=y
# CONFIG_IP_NF_TARGET_ULOG is not set
CONFIG_IP_NF_TARGET_TCPMSS=y
CONFIG_IP_NF_MANGLE=y
CONFIG_IP_NF_TARGET_TOS=y
CONFIG_IP_NF_TARGET_ECN=y
# CONFIG_IP_NF_TARGET_TTL is not set
# CONFIG_IP_NF_RAW is not set
# CONFIG_IP_NF_ARPTABLES is not set
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
CONFIG_IP6_NF_QUEUE=y
# CONFIG_IP6_NF_IPTABLES is not set
#
# Bridge: Netfilter Configuration
#
# CONFIG_BRIDGE_NF_EBTABLES is not set
#
# DCCP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_DCCP is not set
#
# SCTP Configuration (EXPERIMENTAL)
#
# CONFIG_IP_SCTP is not set
#
# TIPC Configuration (EXPERIMENTAL)
#
# CONFIG_TIPC is not set
# CONFIG_ATM is not set
CONFIG_BRIDGE=y
CONFIG_VLAN_8021Q=y
# CONFIG_DECNET is not set
CONFIG_LLC=y
# CONFIG_LLC2 is not set
# CONFIG_IPX is not set
# CONFIG_ATALK is not set
# CONFIG_X25 is not set
# CONFIG_LAPB is not set
# CONFIG_ECONET is not set
# CONFIG_WAN_ROUTER is not set
#
# QoS and/or fair queueing
#
CONFIG_NET_SCHED=y
CONFIG_NET_SCH_FIFO=y
# CONFIG_NET_SCH_CLK_JIFFIES is not set
# CONFIG_NET_SCH_CLK_GETTIMEOFDAY is not set
CONFIG_NET_SCH_CLK_CPU=y
#
# Queueing/Scheduling
#
CONFIG_NET_SCH_CBQ=y
CONFIG_NET_SCH_HTB=y
# CONFIG_NET_SCH_HFSC is not set
CONFIG_NET_SCH_PRIO=y
CONFIG_NET_SCH_RED=y
CONFIG_NET_SCH_SFQ=y
# CONFIG_NET_SCH_TEQL is not set
CONFIG_NET_SCH_TBF=y
CONFIG_NET_SCH_GRED=y
CONFIG_NET_SCH_DSMARK=y
CONFIG_NET_SCH_NETEM=y
CONFIG_NET_SCH_INGRESS=y
#
# Classification
#
CONFIG_NET_CLS=y
CONFIG_NET_CLS_BASIC=y
CONFIG_NET_CLS_TCINDEX=y
CONFIG_NET_CLS_ROUTE4=y
CONFIG_NET_CLS_ROUTE=y
# CONFIG_NET_CLS_FW is not set
CONFIG_NET_CLS_U32=y
# CONFIG_CLS_U32_PERF is not set
# CONFIG_CLS_U32_MARK is not set
# CONFIG_NET_CLS_RSVP is not set
# CONFIG_NET_CLS_RSVP6 is not set
# CONFIG_NET_EMATCH is not set
# CONFIG_NET_CLS_ACT is not set
# CONFIG_NET_CLS_POLICE is not set
# CONFIG_NET_CLS_IND is not set
# CONFIG_NET_ESTIMATOR is not set
#
# Network testing
#
# CONFIG_NET_PKTGEN is not set
# CONFIG_HAMRADIO is not set
# CONFIG_IRDA is not set
CONFIG_BT=y
CONFIG_BT_L2CAP=y
CONFIG_BT_SCO=y
CONFIG_BT_RFCOMM=y
CONFIG_BT_RFCOMM_TTY=y
CONFIG_BT_BNEP=y
CONFIG_BT_BNEP_MC_FILTER=y
CONFIG_BT_BNEP_PROTO_FILTER=y
CONFIG_BT_HIDP=y
#
# Bluetooth device drivers
#
CONFIG_BT_HCIUSB=m
CONFIG_BT_HCIUSB_SCO=y
# CONFIG_BT_HCIUART is not set
# CONFIG_BT_HCIBCM203X is not set
# CONFIG_BT_HCIBPA10X is not set
# CONFIG_BT_HCIBFUSB is not set
# CONFIG_BT_HCIDTL1 is not set
# CONFIG_BT_HCIBT3C is not set
# CONFIG_BT_HCIBLUECARD is not set
# CONFIG_BT_HCIBTUART is not set
# CONFIG_BT_HCIVHCI is not set
CONFIG_IEEE80211=y
# CONFIG_IEEE80211_DEBUG is not set
CONFIG_IEEE80211_CRYPT_WEP=y
CONFIG_IEEE80211_CRYPT_CCMP=y
CONFIG_IEEE80211_CRYPT_TKIP=y
CONFIG_IEEE80211_SOFTMAC=y
# CONFIG_IEEE80211_SOFTMAC_DEBUG is not set
CONFIG_WIRELESS_EXT=y
#
# Device Drivers
#
#
# Generic Driver Options
#
# CONFIG_STANDALONE is not set
# CONFIG_PREVENT_FIRMWARE_BUILD is not set
CONFIG_FW_LOADER=y
# CONFIG_DEBUG_DRIVER is not set
# CONFIG_SYS_HYPERVISOR is not set
#
# Connector - unified userspace <-> kernelspace linker
#
CONFIG_CONNECTOR=y
# CONFIG_PROC_EVENTS is not set
#
# Memory Technology Devices (MTD)
#
CONFIG_MTD=m
# CONFIG_MTD_DEBUG is not set
# CONFIG_MTD_CONCAT is not set
CONFIG_MTD_PARTITIONS=y
# CONFIG_MTD_REDBOOT_PARTS is not set
#
# User Modules And Translation Layers
#
CONFIG_MTD_CHAR=m
CONFIG_MTD_BLOCK=m
# CONFIG_MTD_BLOCK_RO is not set
CONFIG_FTL=m
CONFIG_NFTL=m
# CONFIG_NFTL_RW is not set
CONFIG_INFTL=m
CONFIG_RFD_FTL=m
# CONFIG_SSFDC is not set
#
# RAM/ROM/Flash chip drivers
#
CONFIG_MTD_CFI=m
CONFIG_MTD_JEDECPROBE=m
CONFIG_MTD_GEN_PROBE=m
# CONFIG_MTD_CFI_ADV_OPTIONS is not set
CONFIG_MTD_MAP_BANK_WIDTH_1=y
CONFIG_MTD_MAP_BANK_WIDTH_2=y
CONFIG_MTD_MAP_BANK_WIDTH_4=y
# CONFIG_MTD_MAP_BANK_WIDTH_8 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_16 is not set
# CONFIG_MTD_MAP_BANK_WIDTH_32 is not set
CONFIG_MTD_CFI_I1=y
CONFIG_MTD_CFI_I2=y
# CONFIG_MTD_CFI_I4 is not set
# CONFIG_MTD_CFI_I8 is not set
CONFIG_MTD_CFI_INTELEXT=m
CONFIG_MTD_CFI_AMDSTD=m
CONFIG_MTD_CFI_STAA=m
CONFIG_MTD_CFI_UTIL=m
CONFIG_MTD_RAM=m
CONFIG_MTD_ROM=m
# CONFIG_MTD_ABSENT is not set
# CONFIG_MTD_OBSOLETE_CHIPS is not set
#
# Mapping drivers for chip access
#
CONFIG_MTD_COMPLEX_MAPPINGS=y
# CONFIG_MTD_PHYSMAP is not set
# CONFIG_MTD_PNC2000 is not set
# CONFIG_MTD_NETSC520 is not set
# CONFIG_MTD_TS5500 is not set
# CONFIG_MTD_SBC_GXX is not set
# CONFIG_MTD_AMD76XROM is not set
# CONFIG_MTD_ICHXROM is not set
# CONFIG_MTD_SCB2_FLASH is not set
# CONFIG_MTD_NETtel is not set
# CONFIG_MTD_L440GX is not set
# CONFIG_MTD_PCI is not set
# CONFIG_MTD_PLATRAM is not set
#
# Self-contained MTD device drivers
#
# CONFIG_MTD_PMC551 is not set
# CONFIG_MTD_SLRAM is not set
# CONFIG_MTD_PHRAM is not set
# CONFIG_MTD_MTDRAM is not set
CONFIG_MTD_BLOCK2MTD=m
#
# Disk-On-Chip Device Drivers
#
# CONFIG_MTD_DOC2000 is not set
# CONFIG_MTD_DOC2001 is not set
# CONFIG_MTD_DOC2001PLUS is not set
#
# NAND Flash Device Drivers
#
CONFIG_MTD_NAND=m
# CONFIG_MTD_NAND_VERIFY_WRITE is not set
# CONFIG_MTD_NAND_ECC_SMC is not set
CONFIG_MTD_NAND_IDS=m
# CONFIG_MTD_NAND_DISKONCHIP is not set
# CONFIG_MTD_NAND_CS553X is not set
# CONFIG_MTD_NAND_NANDSIM is not set
#
# OneNAND Flash Device Drivers
#
# CONFIG_MTD_ONENAND is not set
#
# Parallel port support
#
CONFIG_PARPORT=y
CONFIG_PARPORT_PC=y
# CONFIG_PARPORT_SERIAL is not set
CONFIG_PARPORT_PC_FIFO=y
# CONFIG_PARPORT_PC_SUPERIO is not set
# CONFIG_PARPORT_PC_PCMCIA is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not set
# CONFIG_PARPORT_1284 is not set
#
# Plug and Play support
#
CONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#
# CONFIG_ISAPNP is not set
# CONFIG_PNPBIOS is not set
CONFIG_PNPACPI=y
#
# Block devices
#
# CONFIG_BLK_DEV_FD is not set
# CONFIG_BLK_DEV_XD is not set
# CONFIG_PARIDE is not set
# CONFIG_BLK_CPQ_DA is not set
# CONFIG_BLK_CPQ_CISS_DA is not set
# CONFIG_BLK_DEV_DAC960 is not set
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not set
CONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not set
CONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not set
# CONFIG_BLK_DEV_INITRD is not set
# CONFIG_CDROM_PKTCDVD is not set
# CONFIG_ATA_OVER_ETH is not set
#
# Misc devices
#
# CONFIG_IBM_ASM is not set
# CONFIG_SGI_IOC4 is not set
# CONFIG_TIFM_CORE is not set
# CONFIG_MSI_LAPTOP is not set
#
# ATA/ATAPI/MFM/RLL support
#
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not set
CONFIG_SCSI=y
# CONFIG_SCSI_TGT is not set
# CONFIG_SCSI_NETLINK is not set
CONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#
CONFIG_BLK_DEV_SD=y
# CONFIG_CHR_DEV_ST is not set
# CONFIG_CHR_DEV_OSST is not set
CONFIG_BLK_DEV_SR=y
# CONFIG_BLK_DEV_SR_VENDOR is not set
CONFIG_CHR_DEV_SG=y
# CONFIG_CHR_DEV_SCH is not set
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs
#
CONFIG_SCSI_MULTI_LUN=y
CONFIG_SCSI_CONSTANTS=y
# CONFIG_SCSI_LOGGING is not set
CONFIG_SCSI_SCAN_ASYNC=y
#
# SCSI Transports
#
# CONFIG_SCSI_SPI_ATTRS is not set
# CONFIG_SCSI_FC_ATTRS is not set
# CONFIG_SCSI_ISCSI_ATTRS is not set
# CONFIG_SCSI_SAS_ATTRS is not set
# CONFIG_SCSI_SAS_LIBSAS is not set
#
# SCSI low-level drivers
#
# CONFIG_ISCSI_TCP is not set
# CONFIG_BLK_DEV_3W_XXXX_RAID is not set
# CONFIG_SCSI_3W_9XXX is not set
# CONFIG_SCSI_7000FASST is not set
# CONFIG_SCSI_ACARD is not set
# CONFIG_SCSI_AHA152X is not set
# CONFIG_SCSI_AHA1542 is not set
# CONFIG_SCSI_AACRAID is not set
# CONFIG_SCSI_AIC7XXX is not set
# CONFIG_SCSI_AIC7XXX_OLD is not set
# CONFIG_SCSI_AIC79XX is not set
# CONFIG_SCSI_AIC94XX is not set
# CONFIG_SCSI_DPT_I2O is not set
# CONFIG_SCSI_ADVANSYS is not set
# CONFIG_SCSI_IN2000 is not set
# CONFIG_SCSI_ARCMSR is not set
# CONFIG_MEGARAID_NEWGEN is not set
# CONFIG_MEGARAID_LEGACY is not set
# CONFIG_MEGARAID_SAS is not set
# CONFIG_SCSI_HPTIOP is not set
# CONFIG_SCSI_BUSLOGIC is not set
# CONFIG_SCSI_DMX3191D is not set
# CONFIG_SCSI_DTC3280 is not set
# CONFIG_SCSI_EATA is not set
# CONFIG_SCSI_FUTURE_DOMAIN is not set
# CONFIG_SCSI_GDTH is not set
# CONFIG_SCSI_GENERIC_NCR5380 is not set
# CONFIG_SCSI_GENERIC_NCR5380_MMIO is not set
# CONFIG_SCSI_IPS is not set
# CONFIG_SCSI_INITIO is not set
# CONFIG_SCSI_INIA100 is not set
# CONFIG_SCSI_PPA is not set
# CONFIG_SCSI_IMM is not set
# CONFIG_SCSI_NCR53C406A is not set
# CONFIG_SCSI_STEX is not set
# CONFIG_SCSI_SYM53C8XX_2 is not set
# CONFIG_SCSI_IPR is not set
# CONFIG_SCSI_PAS16 is not set
# CONFIG_SCSI_PSI240I is not set
# CONFIG_SCSI_QLOGIC_FAS is not set
# CONFIG_SCSI_QLOGIC_1280 is not set
# CONFIG_SCSI_QLA_FC is not set
# CONFIG_SCSI_QLA_ISCSI is not set
# CONFIG_SCSI_LPFC is not set
# CONFIG_SCSI_SYM53C416 is not set
# CONFIG_SCSI_DC395x is not set
# CONFIG_SCSI_DC390T is not set
# CONFIG_SCSI_T128 is not set
# CONFIG_SCSI_U14_34F is not set
# CONFIG_SCSI_ULTRASTOR is not set
# CONFIG_SCSI_NSP32 is not set
# CONFIG_SCSI_DEBUG is not set
# CONFIG_SCSI_SRP is not set
#
# PCMCIA SCSI adapter support
#
# CONFIG_PCMCIA_AHA152X is not set
# CONFIG_PCMCIA_FDOMAIN is not set
# CONFIG_PCMCIA_NINJA_SCSI is not set
# CONFIG_PCMCIA_QLOGIC is not set
# CONFIG_PCMCIA_SYM53C500 is not set
#
# Serial ATA (prod) and Parallel ATA (experimental) drivers
#
CONFIG_ATA=y
CONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not set
CONFIG_ATA_PIIX=y
# CONFIG_SATA_MV is not set
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not set
# CONFIG_SATA_QSTOR is not set
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not set
# CONFIG_SATA_SIL is not set
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not set
# CONFIG_SATA_ULI is not set
# CONFIG_SATA_VIA is not set
# CONFIG_SATA_VITESSE is not set
# CONFIG_PATA_ALI is not set
# CONFIG_PATA_AMD is not set
# CONFIG_PATA_ARTOP is not set
# CONFIG_PATA_ATIIXP is not set
# CONFIG_PATA_CMD64X is not set
# CONFIG_PATA_CS5520 is not set
# CONFIG_PATA_CS5530 is not set
# CONFIG_PATA_CS5535 is not set
# CONFIG_PATA_CYPRESS is not set
# CONFIG_PATA_EFAR is not set
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not set
# CONFIG_PATA_HPT37X is not set
# CONFIG_PATA_HPT3X2N is not set
# CONFIG_PATA_HPT3X3 is not set
# CONFIG_PATA_IT821X is not set
# CONFIG_PATA_JMICRON is not set
# CONFIG_PATA_LEGACY is not set
# CONFIG_PATA_TRIFLEX is not set
# CONFIG_PATA_MARVELL is not set
# CONFIG_PATA_MPIIX is not set
# CONFIG_PATA_OLDPIIX is not set
# CONFIG_PATA_NETCELL is not set
# CONFIG_PATA_NS87410 is not set
# CONFIG_PATA_OPTI is not set
# CONFIG_PATA_OPTIDMA is not set
# CONFIG_PATA_PCMCIA is not set
# CONFIG_PATA_PDC_OLD is not set
# CONFIG_PATA_QDI is not set
# CONFIG_PATA_RADISYS is not set
# CONFIG_PATA_RZ1000 is not set
# CONFIG_PATA_SC1200 is not set
# CONFIG_PATA_SERVERWORKS is not set
# CONFIG_PATA_PDC2027X is not set
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not set
# CONFIG_PATA_VIA is not set
# CONFIG_PATA_WINBOND is not set
# CONFIG_PATA_WINBOND_VLB is not set
#
# Old CD-ROM drivers (not SCSI, not IDE)
#
# CONFIG_CD_NO_IDESCSI is not set
#
# Multi-device support (RAID and LVM)
#
CONFIG_MD=y
# CONFIG_BLK_DEV_MD is not set
CONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not set
CONFIG_DM_CRYPT=y
CONFIG_DM_SNAPSHOT=y
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not set
# CONFIG_DM_MULTIPATH is not set
#
# Fusion MPT device support
#
# CONFIG_FUSION is not set
# CONFIG_FUSION_SPI is not set
# CONFIG_FUSION_FC is not set
# CONFIG_FUSION_SAS is not set
#
# IEEE 1394 (FireWire) support
#
CONFIG_IEEE1394=y
#
# Subsystem Options
#
# CONFIG_IEEE1394_VERBOSEDEBUG is not set
# CONFIG_IEEE1394_OUI_DB is not set
CONFIG_IEEE1394_EXTRA_CONFIG_ROMS=y
CONFIG_IEEE1394_CONFIG_ROM_IP1394=y
# CONFIG_IEEE1394_EXPORT_FULL_API is not set
#
# Device Drivers
#
# CONFIG_IEEE1394_PCILYNX is not set
CONFIG_IEEE1394_OHCI1394=m
#
# Protocol Drivers
#
# CONFIG_IEEE1394_VIDEO1394 is not set
CONFIG_IEEE1394_SBP2=y
# CONFIG_IEEE1394_SBP2_PHYS_DMA is not set
CONFIG_IEEE1394_ETH1394=y
# CONFIG_IEEE1394_DV1394 is not set
CONFIG_IEEE1394_RAWIO=y
#
# I2O device support
#
# CONFIG_I2O is not set
#
# Network device support
#
CONFIG_NETDEVICES=y
# CONFIG_DUMMY is not set
CONFIG_BONDING=y
# CONFIG_EQUALIZER is not set
CONFIG_TUN=y
# CONFIG_NET_SB1000 is not set
#
# ARCnet devices
#
# CONFIG_ARCNET is not set
#
# PHY device support
#
# CONFIG_PHYLIB is not set
#
# Ethernet (10 or 100Mbit)
#
CONFIG_NET_ETHERNET=y
CONFIG_MII=y
# CONFIG_HAPPYMEAL is not set
# CONFIG_SUNGEM is not set
# CONFIG_CASSINI is not set
# CONFIG_NET_VENDOR_3COM is not set
# CONFIG_LANCE is not set
# CONFIG_NET_VENDOR_SMC is not set
# CONFIG_NET_VENDOR_RACAL is not set
#
# Tulip family network device support
#
# CONFIG_NET_TULIP is not set
# CONFIG_AT1700 is not set
# CONFIG_DEPCA is not set
# CONFIG_HP100 is not set
# CONFIG_NET_ISA is not set
CONFIG_NET_PCI=y
CONFIG_PCNET32=y
# CONFIG_PCNET32_NAPI is not set
CONFIG_AMD8111_ETH=y
CONFIG_AMD8111E_NAPI=y
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_AC3200 is not set
# CONFIG_APRICOT is not set
# CONFIG_B44 is not set
# CONFIG_FORCEDETH is not set
# CONFIG_CS89x0 is not set
# CONFIG_DGRS is not set
# CONFIG_EEPRO100 is not set
CONFIG_E100=y
# CONFIG_FEALNX is not set
# CONFIG_NATSEMI is not set
# CONFIG_NE2K_PCI is not set
# CONFIG_8139CP is not set
CONFIG_8139TOO=y
CONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not set
# CONFIG_8139TOO_8129 is not set
# CONFIG_8139_OLD_RX_RESET is not set
# CONFIG_SIS900 is not set
# CONFIG_EPIC100 is not set
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not set
# CONFIG_VIA_RHINE is not set
# CONFIG_NET_POCKET is not set
#
# Ethernet (1000 Mbit)
#
# CONFIG_ACENIC is not set
# CONFIG_DL2K is not set
# CONFIG_E1000 is not set
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not set
# CONFIG_R8169 is not set
# CONFIG_SIS190 is not set
# CONFIG_SKGE is not set
# CONFIG_SKY2 is not set
# CONFIG_SK98LIN is not set
# CONFIG_VIA_VELOCITY is not set
CONFIG_TIGON3=y
# CONFIG_BNX2 is not set
# CONFIG_QLA3XXX is not set
#
# Ethernet (10000 Mbit)
#
# CONFIG_CHELSIO_T1 is not set
# CONFIG_IXGB is not set
CONFIG_S2IO=m
# CONFIG_S2IO_NAPI is not set
# CONFIG_MYRI10GE is not set
# CONFIG_NETXEN_NIC is not set
#
# Token Ring devices
#
# CONFIG_TR is not set
#
# Wireless LAN (non-hamradio)
#
CONFIG_NET_RADIO=y
CONFIG_NET_WIRELESS_RTNETLINK=y
#
# Obsolete Wireless cards support (pre-802.11)
#
# CONFIG_STRIP is not set
# CONFIG_ARLAN is not set
# CONFIG_WAVELAN is not set
# CONFIG_PCMCIA_WAVELAN is not set
# CONFIG_PCMCIA_NETWAVE is not set
#
# Wireless 802.11 Frequency Hopping cards support
#
# CONFIG_PCMCIA_RAYCS is not set
#
# Wireless 802.11b ISA/PCI cards support
#
# CONFIG_IPW2100 is not set
CONFIG_IPW2200=m
CONFIG_IPW2200_MONITOR=y
CONFIG_IPW2200_RADIOTAP=y
CONFIG_IPW2200_PROMISCUOUS=y
CONFIG_IPW2200_QOS=y
# CONFIG_IPW2200_DEBUG is not set
# CONFIG_AIRO is not set
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not set
#
# Wireless 802.11b Pcmcia/Cardbus cards support
#
# CONFIG_AIRO_CS is not set
# CONFIG_PCMCIA_WL3501 is not set
#
# Prism GT/Duette 802.11(a/b/g) PCI/Cardbus support
#
# CONFIG_PRISM54 is not set
# CONFIG_USB_ZD1201 is not set
CONFIG_HOSTAP=m
CONFIG_HOSTAP_FIRMWARE=y
CONFIG_HOSTAP_FIRMWARE_NVRAM=y
# CONFIG_HOSTAP_PLX is not set
# CONFIG_HOSTAP_PCI is not set
CONFIG_HOSTAP_CS=m
# CONFIG_BCM43XX is not set
CONFIG_ZD1211RW=m
# CONFIG_ZD1211RW_DEBUG is not set
CONFIG_NET_WIRELESS=y
#
# PCMCIA network device support
#
# CONFIG_NET_PCMCIA is not set
#
# Wan interfaces
#
# CONFIG_WAN is not set
# CONFIG_FDDI is not set
# CONFIG_HIPPI is not set
# CONFIG_PLIP is not set
CONFIG_PPP=y
CONFIG_PPP_MULTILINK=y
CONFIG_PPP_FILTER=y
CONFIG_PPP_ASYNC=y
CONFIG_PPP_SYNC_TTY=y
CONFIG_PPP_DEFLATE=y
CONFIG_PPP_BSDCOMP=y
# CONFIG_PPP_MPPE is not set
CONFIG_PPPOE=y
# CONFIG_SLIP is not set
CONFIG_SLHC=y
# CONFIG_NET_FC is not set
# CONFIG_SHAPER is not set
CONFIG_NETCONSOLE=y
CONFIG_NETPOLL=y
# CONFIG_NETPOLL_RX is not set
# CONFIG_NETPOLL_TRAP is not set
CONFIG_NET_POLL_CONTROLLER=y
#
# ISDN subsystem
#
# CONFIG_ISDN is not set
#
# Telephony Support
#
# CONFIG_PHONE is not set
#
# Input device support
#
CONFIG_INPUT=y
# CONFIG_INPUT_FF_MEMLESS is not set
#
# Userland interfaces
#
CONFIG_INPUT_MOUSEDEV=y
CONFIG_INPUT_MOUSEDEV_PSAUX=y
CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024
CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not set
# CONFIG_INPUT_TSDEV is not set
# CONFIG_INPUT_EVDEV is not set
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#
CONFIG_INPUT_KEYBOARD=y
CONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not set
# CONFIG_KEYBOARD_XTKBD is not set
# CONFIG_KEYBOARD_NEWTON is not set
# CONFIG_KEYBOARD_STOWAWAY is not set
CONFIG_INPUT_MOUSE=y
CONFIG_MOUSE_PS2=y
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_INPORT is not set
# CONFIG_MOUSE_LOGIBM is not set
# CONFIG_MOUSE_PC110PAD is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not set
# CONFIG_INPUT_TOUCHSCREEN is not set
CONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not set
# CONFIG_INPUT_WISTRON_BTNS is not set
CONFIG_INPUT_UINPUT=m
#
# Hardware I/O ports
#
CONFIG_SERIO=y
CONFIG_SERIO_I8042=y
# CONFIG_SERIO_SERPORT is not set
# CONFIG_SERIO_CT82C710 is not set
# CONFIG_SERIO_PARKBD is not set
# CONFIG_SERIO_PCIPS2 is not set
CONFIG_SERIO_LIBPS2=y
# CONFIG_SERIO_RAW is not set
# CONFIG_GAMEPORT is not set
#
# Character devices
#
CONFIG_VT=y
CONFIG_VT_CONSOLE=y
CONFIG_HW_CONSOLE=y
# CONFIG_VT_HW_CONSOLE_BINDING is not set
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#
CONFIG_SERIAL_8250=y
# CONFIG_SERIAL_8250_CONSOLE is not set
CONFIG_SERIAL_8250_PCI=y
CONFIG_SERIAL_8250_PNP=y
# CONFIG_SERIAL_8250_CS is not set
CONFIG_SERIAL_8250_NR_UARTS=4
CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
#
# Non-8250 serial port support
#
CONFIG_SERIAL_CORE=y
# CONFIG_SERIAL_JSM is not set
CONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
CONFIG_PRINTER=m
# CONFIG_LP_CONSOLE is not set
CONFIG_PPDEV=m
# CONFIG_TIPAR is not set
#
# IPMI
#
# CONFIG_IPMI_HANDLER is not set
#
# Watchdog Cards
#
# CONFIG_WATCHDOG is not set
CONFIG_HW_RANDOM=y
CONFIG_HW_RANDOM_INTEL=y
CONFIG_HW_RANDOM_AMD=y
CONFIG_HW_RANDOM_GEODE=y
CONFIG_HW_RANDOM_VIA=y
# CONFIG_NVRAM is not set
CONFIG_RTC=y
# CONFIG_DTLK is not set
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not set
# CONFIG_SONYPI is not set
CONFIG_AGP=y
# CONFIG_AGP_ALI is not set
# CONFIG_AGP_ATI is not set
# CONFIG_AGP_AMD is not set
# CONFIG_AGP_AMD64 is not set
CONFIG_AGP_INTEL=y
# CONFIG_AGP_NVIDIA is not set
# CONFIG_AGP_SIS is not set
# CONFIG_AGP_SWORKS is not set
# CONFIG_AGP_VIA is not set
# CONFIG_AGP_EFFICEON is not set
CONFIG_DRM=y
# CONFIG_DRM_TDFX is not set
# CONFIG_DRM_R128 is not set
CONFIG_DRM_RADEON=m
# CONFIG_DRM_I810 is not set
# CONFIG_DRM_I830 is not set
# CONFIG_DRM_I915 is not set
# CONFIG_DRM_MGA is not set
# CONFIG_DRM_SIS is not set
# CONFIG_DRM_VIA is not set
# CONFIG_DRM_SAVAGE is not set
#
# PCMCIA character devices
#
# CONFIG_SYNCLINK_CS is not set
# CONFIG_CARDMAN_4000 is not set
# CONFIG_CARDMAN_4040 is not set
# CONFIG_MWAVE is not set
# CONFIG_PC8736x_GPIO is not set
# CONFIG_NSC_GPIO is not set
# CONFIG_CS5535_GPIO is not set
# CONFIG_RAW_DRIVER is not set
CONFIG_HPET=y
# CONFIG_HPET_RTC_IRQ is not set
CONFIG_HPET_MMAP=y
# CONFIG_HANGCHECK_TIMER is not set
#
# TPM devices
#
CONFIG_TCG_TPM=y
CONFIG_TCG_TIS=y
CONFIG_TCG_NSC=y
CONFIG_TCG_ATMEL=y
CONFIG_TCG_INFINEON=y
# CONFIG_TELCLOCK is not set
#
# I2C support
#
CONFIG_I2C=y
CONFIG_I2C_CHARDEV=y
#
# I2C Algorithms
#
CONFIG_I2C_ALGOBIT=y
# CONFIG_I2C_ALGOPCF is not set
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#
# CONFIG_I2C_ALI1535 is not set
# CONFIG_I2C_ALI1563 is not set
# CONFIG_I2C_ALI15X3 is not set
# CONFIG_I2C_AMD756 is not set
# CONFIG_I2C_AMD8111 is not set
# CONFIG_I2C_ELEKTOR is not set
CONFIG_I2C_I801=y
CONFIG_I2C_I810=y
# CONFIG_I2C_PIIX4 is not set
# CONFIG_I2C_NFORCE2 is not set
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not set
# CONFIG_I2C_PARPORT_LIGHT is not set
# CONFIG_I2C_PROSAVAGE is not set
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not set
# CONFIG_I2C_SIS96X is not set
# CONFIG_I2C_STUB is not set
# CONFIG_I2C_VIA is not set
# CONFIG_I2C_VIAPRO is not set
# CONFIG_I2C_VOODOO3 is not set
# CONFIG_I2C_PCA_ISA is not set
#
# Miscellaneous I2C Chip support
#
# CONFIG_SENSORS_DS1337 is not set
# CONFIG_SENSORS_DS1374 is not set
CONFIG_SENSORS_EEPROM=m
# CONFIG_SENSORS_PCF8574 is not set
# CONFIG_SENSORS_PCA9539 is not set
# CONFIG_SENSORS_PCF8591 is not set
# CONFIG_SENSORS_MAX6875 is not set
# CONFIG_I2C_DEBUG_CORE is not set
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not set
# CONFIG_I2C_DEBUG_CHIP is not set
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
#
# Dallas's 1-wire bus
#
# CONFIG_W1 is not set
#
# Hardware Monitoring support
#
CONFIG_HWMON=y
# CONFIG_HWMON_VID is not set
# CONFIG_SENSORS_ABITUGURU is not set
# CONFIG_SENSORS_ADM1021 is not set
# CONFIG_SENSORS_ADM1025 is not set
# CONFIG_SENSORS_ADM1026 is not set
# CONFIG_SENSORS_ADM1031 is not set
# CONFIG_SENSORS_ADM9240 is not set
# CONFIG_SENSORS_K8TEMP is not set
# CONFIG_SENSORS_ASB100 is not set
# CONFIG_SENSORS_ATXP1 is not set
# CONFIG_SENSORS_DS1621 is not set
# CONFIG_SENSORS_F71805F is not set
# CONFIG_SENSORS_FSCHER is not set
# CONFIG_SENSORS_FSCPOS is not set
# CONFIG_SENSORS_GL518SM is not set
# CONFIG_SENSORS_GL520SM is not set
# CONFIG_SENSORS_IT87 is not set
# CONFIG_SENSORS_LM63 is not set
# CONFIG_SENSORS_LM75 is not set
# CONFIG_SENSORS_LM77 is not set
# CONFIG_SENSORS_LM78 is not set
# CONFIG_SENSORS_LM80 is not set
# CONFIG_SENSORS_LM83 is not set
# CONFIG_SENSORS_LM85 is not set
# CONFIG_SENSORS_LM87 is not set
# CONFIG_SENSORS_LM90 is not set
# CONFIG_SENSORS_LM92 is not set
# CONFIG_SENSORS_MAX1619 is not set
# CONFIG_SENSORS_PC87360 is not set
# CONFIG_SENSORS_PC87427 is not set
# CONFIG_SENSORS_SIS5595 is not set
# CONFIG_SENSORS_SMSC47M1 is not set
# CONFIG_SENSORS_SMSC47M192 is not set
# CONFIG_SENSORS_SMSC47B397 is not set
# CONFIG_SENSORS_VIA686A is not set
# CONFIG_SENSORS_VT1211 is not set
# CONFIG_SENSORS_VT8231 is not set
# CONFIG_SENSORS_W83781D is not set
# CONFIG_SENSORS_W83791D is not set
# CONFIG_SENSORS_W83792D is not set
# CONFIG_SENSORS_W83793 is not set
# CONFIG_SENSORS_W83L785TS is not set
# CONFIG_SENSORS_W83627HF is not set
# CONFIG_SENSORS_W83627EHF is not set
CONFIG_SENSORS_HDAPS=m
# CONFIG_HWMON_DEBUG_CHIP is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
#
# Digital Video Broadcasting Devices
#
# CONFIG_DVB is not set
# CONFIG_USB_DABUSB is not set
#
# Graphics support
#
CONFIG_FIRMWARE_EDID=y
CONFIG_FB=m
CONFIG_FB_DDC=m
CONFIG_FB_CFB_FILLRECT=m
CONFIG_FB_CFB_COPYAREA=m
CONFIG_FB_CFB_IMAGEBLIT=m
# CONFIG_FB_MACMODES is not set
# CONFIG_FB_BACKLIGHT is not set
CONFIG_FB_MODE_HELPERS=y
# CONFIG_FB_TILEBLITTING is not set
# CONFIG_FB_CIRRUS is not set
# CONFIG_FB_PM2 is not set
# CONFIG_FB_CYBER2000 is not set
# CONFIG_FB_ARC is not set
# CONFIG_FB_VGA16 is not set
# CONFIG_FB_HGA is not set
# CONFIG_FB_S1D13XXX is not set
# CONFIG_FB_NVIDIA is not set
# CONFIG_FB_RIVA is not set
# CONFIG_FB_I810 is not set
# CONFIG_FB_INTEL is not set
# CONFIG_FB_MATROX is not set
CONFIG_FB_RADEON=m
CONFIG_FB_RADEON_I2C=y
CONFIG_FB_RADEON_DEBUG=y
# CONFIG_FB_ATY128 is not set
# CONFIG_FB_ATY is not set
# CONFIG_FB_SAVAGE is not set
# CONFIG_FB_SIS is not set
# CONFIG_FB_NEOMAGIC is not set
# CONFIG_FB_KYRO is not set
# CONFIG_FB_3DFX is not set
# CONFIG_FB_VOODOO1 is not set
# CONFIG_FB_CYBLA is not set
# CONFIG_FB_TRIDENT is not set
# CONFIG_FB_GEODE is not set
# CONFIG_FB_VIRTUAL is not set
#
# Console display driver support
#
CONFIG_VGA_CONSOLE=y
CONFIG_VGACON_SOFT_SCROLLBACK=y
CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64
CONFIG_VIDEO_SELECT=y
# CONFIG_MDA_CONSOLE is not set
CONFIG_DUMMY_CONSOLE=y
CONFIG_FRAMEBUFFER_CONSOLE=m
# CONFIG_FRAMEBUFFER_CONSOLE_ROTATION is not set
CONFIG_FONTS=y
# CONFIG_FONT_8x8 is not set
# CONFIG_FONT_8x16 is not set
# CONFIG_FONT_6x11 is not set
# CONFIG_FONT_7x14 is not set
# CONFIG_FONT_PEARL_8x8 is not set
# CONFIG_FONT_ACORN_8x8 is not set
# CONFIG_FONT_MINI_4x6 is not set
# CONFIG_FONT_SUN8x16 is not set
CONFIG_FONT_SUN12x22=y
# CONFIG_FONT_10x18 is not set
#
# Logo configuration
#
# CONFIG_LOGO is not set
CONFIG_BACKLIGHT_LCD_SUPPORT=y
CONFIG_BACKLIGHT_CLASS_DEVICE=m
CONFIG_BACKLIGHT_DEVICE=y
CONFIG_LCD_CLASS_DEVICE=m
CONFIG_LCD_DEVICE=y
#
# Sound
#
CONFIG_SOUND=y
#
# Advanced Linux Sound Architecture
#
CONFIG_SND=y
CONFIG_SND_TIMER=y
CONFIG_SND_PCM=y
# CONFIG_SND_SEQUENCER is not set
CONFIG_SND_OSSEMUL=y
CONFIG_SND_MIXER_OSS=y
CONFIG_SND_PCM_OSS=y
# CONFIG_SND_PCM_OSS_PLUGINS is not set
CONFIG_SND_RTCTIMER=y
# CONFIG_SND_DYNAMIC_MINORS is not set
# CONFIG_SND_SUPPORT_OLD_API is not set
CONFIG_SND_VERBOSE_PROCFS=y
# CONFIG_SND_VERBOSE_PRINTK is not set
# CONFIG_SND_DEBUG is not set
#
# Generic devices
#
CONFIG_SND_AC97_CODEC=y
# CONFIG_SND_DUMMY is not set
# CONFIG_SND_MTPAV is not set
# CONFIG_SND_MTS64 is not set
# CONFIG_SND_SERIAL_U16550 is not set
# CONFIG_SND_MPU401 is not set
#
# ISA devices
#
# CONFIG_SND_ADLIB is not set
# CONFIG_SND_AD1816A is not set
# CONFIG_SND_AD1848 is not set
# CONFIG_SND_ALS100 is not set
# CONFIG_SND_AZT2320 is not set
# CONFIG_SND_CMI8330 is not set
# CONFIG_SND_CS4231 is not set
# CONFIG_SND_CS4232 is not set
# CONFIG_SND_CS4236 is not set
# CONFIG_SND_DT019X is not set
# CONFIG_SND_ES968 is not set
# CONFIG_SND_ES1688 is not set
# CONFIG_SND_ES18XX is not set
# CONFIG_SND_GUSCLASSIC is not set
# CONFIG_SND_GUSEXTREME is not set
# CONFIG_SND_GUSMAX is not set
# CONFIG_SND_INTERWAVE is not set
# CONFIG_SND_INTERWAVE_STB is not set
# CONFIG_SND_OPL3SA2 is not set
# CONFIG_SND_OPTI92X_AD1848 is not set
# CONFIG_SND_OPTI92X_CS4231 is not set
# CONFIG_SND_OPTI93X is not set
# CONFIG_SND_MIRO is not set
# CONFIG_SND_SB8 is not set
# CONFIG_SND_SB16 is not set
# CONFIG_SND_SBAWE is not set
# CONFIG_SND_SGALAXY is not set
# CONFIG_SND_SSCAPE is not set
# CONFIG_SND_WAVEFRONT is not set
#
# PCI devices
#
# CONFIG_SND_AD1889 is not set
# CONFIG_SND_ALS300 is not set
# CONFIG_SND_ALS4000 is not set
# CONFIG_SND_ALI5451 is not set
# CONFIG_SND_ATIIXP is not set
# CONFIG_SND_ATIIXP_MODEM is not set
# CONFIG_SND_AU8810 is not set
# CONFIG_SND_AU8820 is not set
# CONFIG_SND_AU8830 is not set
# CONFIG_SND_AZT3328 is not set
# CONFIG_SND_BT87X is not set
# CONFIG_SND_CA0106 is not set
# CONFIG_SND_CMIPCI is not set
# CONFIG_SND_CS4281 is not set
# CONFIG_SND_CS46XX is not set
# CONFIG_SND_CS5535AUDIO is not set
# CONFIG_SND_DARLA20 is not set
# CONFIG_SND_GINA20 is not set
# CONFIG_SND_LAYLA20 is not set
# CONFIG_SND_DARLA24 is not set
# CONFIG_SND_GINA24 is not set
# CONFIG_SND_LAYLA24 is not set
# CONFIG_SND_MONA is not set
# CONFIG_SND_MIA is not set
# CONFIG_SND_ECHO3G is not set
# CONFIG_SND_INDIGO is not set
# CONFIG_SND_INDIGOIO is not set
# CONFIG_SND_INDIGODJ is not set
# CONFIG_SND_EMU10K1 is not set
# CONFIG_SND_EMU10K1X is not set
# CONFIG_SND_ENS1370 is not set
# CONFIG_SND_ENS1371 is not set
# CONFIG_SND_ES1938 is not set
# CONFIG_SND_ES1968 is not set
# CONFIG_SND_FM801 is not set
CONFIG_SND_HDA_INTEL=y
# CONFIG_SND_HDSP is not set
# CONFIG_SND_HDSPM is not set
# CONFIG_SND_ICE1712 is not set
# CONFIG_SND_ICE1724 is not set
CONFIG_SND_INTEL8X0=y
# CONFIG_SND_INTEL8X0M is not set
# CONFIG_SND_KORG1212 is not set
# CONFIG_SND_MAESTRO3 is not set
# CONFIG_SND_MIXART is not set
# CONFIG_SND_NM256 is not set
# CONFIG_SND_PCXHR is not set
# CONFIG_SND_RIPTIDE is not set
# CONFIG_SND_RME32 is not set
# CONFIG_SND_RME96 is not set
# CONFIG_SND_RME9652 is not set
# CONFIG_SND_SONICVIBES is not set
# CONFIG_SND_TRIDENT is not set
# CONFIG_SND_VIA82XX is not set
# CONFIG_SND_VIA82XX_MODEM is not set
# CONFIG_SND_VX222 is not set
# CONFIG_SND_YMFPCI is not set
CONFIG_SND_AC97_POWER_SAVE=y
#
# USB devices
#
# CONFIG_SND_USB_AUDIO is not set
# CONFIG_SND_USB_USX2Y is not set
#
# PCMCIA devices
#
# CONFIG_SND_VXPOCKET is not set
# CONFIG_SND_PDAUDIOCF is not set
#
# Open Sound System
#
# CONFIG_SOUND_PRIME is not set
CONFIG_AC97_BUS=y
#
# HID Devices
#
CONFIG_HID=y
#
# USB support
#
CONFIG_USB_ARCH_HAS_HCD=y
CONFIG_USB_ARCH_HAS_OHCI=y
CONFIG_USB_ARCH_HAS_EHCI=y
CONFIG_USB=y
# CONFIG_USB_DEBUG is not set
#
# Miscellaneous USB options
#
CONFIG_USB_DEVICEFS=y
# CONFIG_USB_BANDWIDTH is not set
# CONFIG_USB_DYNAMIC_MINORS is not set
# CONFIG_USB_SUSPEND is not set
CONFIG_USB_MULTITHREAD_PROBE=y
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#
CONFIG_USB_EHCI_HCD=m
# CONFIG_USB_EHCI_SPLIT_ISO is not set
# CONFIG_USB_EHCI_ROOT_HUB_TT is not set
# CONFIG_USB_EHCI_TT_NEWSCHED is not set
# CONFIG_USB_ISP116X_HCD is not set
# CONFIG_USB_OHCI_HCD is not set
CONFIG_USB_UHCI_HCD=m
# CONFIG_USB_SL811_HCD is not set
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not set
CONFIG_USB_PRINTER=y
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support'
#
#
# may also be needed; see USB_STORAGE Help for more information
#
CONFIG_USB_STORAGE=m
# CONFIG_USB_STORAGE_DEBUG is not set
# CONFIG_USB_STORAGE_DATAFAB is not set
# CONFIG_USB_STORAGE_FREECOM is not set
# CONFIG_USB_STORAGE_DPCM is not set
# CONFIG_USB_STORAGE_USBAT is not set
# CONFIG_USB_STORAGE_SDDR09 is not set
# CONFIG_USB_STORAGE_SDDR55 is not set
# CONFIG_USB_STORAGE_JUMPSHOT is not set
# CONFIG_USB_STORAGE_ALAUDA is not set
# CONFIG_USB_STORAGE_KARMA is not set
CONFIG_USB_LIBUSUAL=y
#
# USB Input Devices
#
CONFIG_USB_HID=y
# CONFIG_USB_HID_POWERBOOK is not set
# CONFIG_HID_FF is not set
# CONFIG_USB_HIDDEV is not set
# CONFIG_USB_AIPTEK is not set
# CONFIG_USB_WACOM is not set
# CONFIG_USB_ACECAD is not set
# CONFIG_USB_KBTAB is not set
# CONFIG_USB_POWERMATE is not set
# CONFIG_USB_TOUCHSCREEN is not set
# CONFIG_USB_YEALINK is not set
# CONFIG_USB_XPAD is not set
# CONFIG_USB_ATI_REMOTE is not set
# CONFIG_USB_ATI_REMOTE2 is not set
# CONFIG_USB_KEYSPAN_REMOTE is not set
# CONFIG_USB_APPLETOUCH is not set
#
# USB Imaging devices
#
# CONFIG_USB_MDC800 is not set
# CONFIG_USB_MICROTEK is not set
#
# USB Network Adapters
#
# CONFIG_USB_CATC is not set
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not set
# CONFIG_USB_RTL8150 is not set
CONFIG_USB_USBNET_MII=y
CONFIG_USB_USBNET=y
CONFIG_USB_NET_AX8817X=y
CONFIG_USB_NET_CDCETHER=m
# CONFIG_USB_NET_GL620A is not set
CONFIG_USB_NET_NET1080=m
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
CONFIG_USB_NET_RNDIS_HOST=m
CONFIG_USB_NET_CDC_SUBSET=m
# CONFIG_USB_ALI_M5632 is not set
# CONFIG_USB_AN2720 is not set
CONFIG_USB_BELKIN=y
CONFIG_USB_ARMLINUX=y
# CONFIG_USB_EPSON2888 is not set
CONFIG_USB_NET_ZAURUS=m
CONFIG_USB_MON=y
#
# USB port drivers
#
# CONFIG_USB_USS720 is not set
#
# USB Serial Converter support
#
CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
CONFIG_USB_SERIAL_GENERIC=y
# CONFIG_USB_SERIAL_AIRCABLE is not set
# CONFIG_USB_SERIAL_AIRPRIME is not set
# CONFIG_USB_SERIAL_ARK3116 is not set
# CONFIG_USB_SERIAL_BELKIN is not set
# CONFIG_USB_SERIAL_WHITEHEAT is not set
# CONFIG_USB_SERIAL_DIGI_ACCELEPORT is not set
# CONFIG_USB_SERIAL_CP2101 is not set
# CONFIG_USB_SERIAL_CYPRESS_M8 is not set
# CONFIG_USB_SERIAL_EMPEG is not set
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not set
# CONFIG_USB_SERIAL_EDGEPORT is not set
# CONFIG_USB_SERIAL_EDGEPORT_TI is not set
# CONFIG_USB_SERIAL_GARMIN is not set
# CONFIG_USB_SERIAL_IPW is not set
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not set
# CONFIG_USB_SERIAL_KEYSPAN is not set
# CONFIG_USB_SERIAL_KLSI is not set
# CONFIG_USB_SERIAL_KOBIL_SCT is not set
# CONFIG_USB_SERIAL_MCT_U232 is not set
# CONFIG_USB_SERIAL_MOS7720 is not set
# CONFIG_USB_SERIAL_MOS7840 is not set
# CONFIG_USB_SERIAL_NAVMAN is not set
CONFIG_USB_SERIAL_PL2303=y
CONFIG_USB_SERIAL_HP4X=y
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not set
# CONFIG_USB_SERIAL_TI is not set
# CONFIG_USB_SERIAL_CYBERJACK is not set
# CONFIG_USB_SERIAL_XIRCOM is not set
# CONFIG_USB_SERIAL_OPTION is not set
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not set
#
# USB Miscellaneous drivers
#
# CONFIG_USB_EMI62 is not set
# CONFIG_USB_EMI26 is not set
# CONFIG_USB_ADUTUX is not set
# CONFIG_USB_AUERSWALD is not set
# CONFIG_USB_RIO500 is not set
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_LED is not set
# CONFIG_USB_CYPRESS_CY7C63 is not set
# CONFIG_USB_CYTHERM is not set
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not set
# CONFIG_USB_FTDI_ELAN is not set
# CONFIG_USB_APPLEDISPLAY is not set
# CONFIG_USB_SISUSBVGA is not set
# CONFIG_USB_LD is not set
# CONFIG_USB_TRANCEVIBRATOR is not set
# CONFIG_USB_TEST is not set
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
#
# MMC/SD Card support
#
# CONFIG_MMC is not set
#
# LED devices
#
# CONFIG_NEW_LEDS is not set
#
# LED drivers
#
#
# LED Triggers
#
#
# InfiniBand support
#
# CONFIG_INFINIBAND is not set
#
# EDAC - error detection and reporting (RAS) (EXPERIMENTAL)
#
CONFIG_EDAC=y
#
# Reporting subsystems
#
# CONFIG_EDAC_DEBUG is not set
CONFIG_EDAC_MM_EDAC=y
# CONFIG_EDAC_AMD76X is not set
# CONFIG_EDAC_E7XXX is not set
# CONFIG_EDAC_E752X is not set
# CONFIG_EDAC_I82875P is not set
# CONFIG_EDAC_I82860 is not set
# CONFIG_EDAC_R82600 is not set
CONFIG_EDAC_POLL=y
#
# Real Time Clock
#
# CONFIG_RTC_CLASS is not set
#
# DMA Engine support
#
# CONFIG_DMA_ENGINE is not set
#
# DMA Clients
#
#
# DMA Devices
#
#
# Virtualization
#
# CONFIG_KVM is not set
#
# File systems
#
CONFIG_EXT2_FS=y
CONFIG_EXT2_FS_XATTR=y
CONFIG_EXT2_FS_POSIX_ACL=y
CONFIG_EXT2_FS_SECURITY=y
# CONFIG_EXT2_FS_XIP is not set
CONFIG_EXT3_FS=y
CONFIG_EXT3_FS_XATTR=y
CONFIG_EXT3_FS_POSIX_ACL=y
CONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not set
CONFIG_JBD=y
# CONFIG_JBD_DEBUG is not set
CONFIG_FS_MBCACHE=y
CONFIG_REISERFS_FS=y
# CONFIG_REISERFS_CHECK is not set
# CONFIG_REISERFS_PROC_INFO is not set
# CONFIG_REISERFS_FS_XATTR is not set
# CONFIG_JFS_FS is not set
CONFIG_FS_POSIX_ACL=y
# CONFIG_XFS_FS is not set
# CONFIG_GFS2_FS is not set
# CONFIG_OCFS2_FS is not set
CONFIG_MINIX_FS=y
# CONFIG_ROMFS_FS is not set
CONFIG_INOTIFY=y
CONFIG_INOTIFY_USER=y
# CONFIG_QUOTA is not set
CONFIG_DNOTIFY=y
# CONFIG_AUTOFS_FS is not set
CONFIG_AUTOFS4_FS=y
# CONFIG_FUSE_FS is not set
#
# CD-ROM/DVD Filesystems
#
CONFIG_ISO9660_FS=y
CONFIG_JOLIET=y
# CONFIG_ZISOFS is not set
CONFIG_UDF_FS=y
CONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#
CONFIG_FAT_FS=y
CONFIG_MSDOS_FS=y
CONFIG_VFAT_FS=y
CONFIG_FAT_DEFAULT_CODEPAGE=437
CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
CONFIG_NTFS_FS=y
# CONFIG_NTFS_DEBUG is not set
CONFIG_NTFS_RW=y
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_PROC_SYSCTL=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y
# CONFIG_TMPFS_POSIX_ACL is not set
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=y
CONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#
# CONFIG_ADFS_FS is not set
# CONFIG_AFFS_FS is not set
# CONFIG_HFS_FS is not set
# CONFIG_HFSPLUS_FS is not set
# CONFIG_BEFS_FS is not set
# CONFIG_BFS_FS is not set
# CONFIG_EFS_FS is not set
CONFIG_JFFS2_FS=m
CONFIG_JFFS2_FS_DEBUG=0
CONFIG_JFFS2_FS_WRITEBUFFER=y
# CONFIG_JFFS2_SUMMARY is not set
# CONFIG_JFFS2_FS_XATTR is not set
CONFIG_JFFS2_COMPRESSION_OPTIONS=y
CONFIG_JFFS2_ZLIB=y
CONFIG_JFFS2_RTIME=y
# CONFIG_JFFS2_RUBIN is not set
# CONFIG_JFFS2_CMODE_NONE is not set
CONFIG_JFFS2_CMODE_PRIORITY=y
# CONFIG_JFFS2_CMODE_SIZE is not set
CONFIG_CRAMFS=m
# CONFIG_VXFS_FS is not set
# CONFIG_HPFS_FS is not set
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not set
# CONFIG_UFS_FS is not set
#
# Network File Systems
#
CONFIG_NFS_FS=y
CONFIG_NFS_V3=y
CONFIG_NFS_V3_ACL=y
# CONFIG_NFS_V4 is not set
CONFIG_NFS_DIRECTIO=y
CONFIG_NFSD=y
CONFIG_NFSD_V2_ACL=y
CONFIG_NFSD_V3=y
CONFIG_NFSD_V3_ACL=y
# CONFIG_NFSD_V4 is not set
CONFIG_NFSD_TCP=y
CONFIG_LOCKD=y
CONFIG_LOCKD_V4=y
CONFIG_EXPORTFS=y
CONFIG_NFS_ACL_SUPPORT=y
CONFIG_NFS_COMMON=y
CONFIG_SUNRPC=y
# CONFIG_RPCSEC_GSS_KRB5 is not set
# CONFIG_RPCSEC_GSS_SPKM3 is not set
CONFIG_SMB_FS=y
# CONFIG_SMB_NLS_DEFAULT is not set
CONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not set
# CONFIG_CIFS_EXPERIMENTAL is not set
# CONFIG_NCP_FS is not set
# CONFIG_CODA_FS is not set
# CONFIG_AFS_FS is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#
# CONFIG_PARTITION_ADVANCED is not set
CONFIG_MSDOS_PARTITION=y
#
# Native Language Support
#
CONFIG_NLS=y
CONFIG_NLS_DEFAULT="iso8859-1"
CONFIG_NLS_CODEPAGE_437=y
# CONFIG_NLS_CODEPAGE_737 is not set
# CONFIG_NLS_CODEPAGE_775 is not set
CONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not set
# CONFIG_NLS_CODEPAGE_855 is not set
# CONFIG_NLS_CODEPAGE_857 is not set
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not set
# CONFIG_NLS_CODEPAGE_864 is not set
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not set
CONFIG_NLS_CODEPAGE_932=y
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not set
# CONFIG_NLS_ASCII is not set
CONFIG_NLS_ISO8859_1=y
# CONFIG_NLS_ISO8859_2 is not set
# CONFIG_NLS_ISO8859_3 is not set
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not set
# CONFIG_NLS_ISO8859_7 is not set
# CONFIG_NLS_ISO8859_9 is not set
# CONFIG_NLS_ISO8859_13 is not set
# CONFIG_NLS_ISO8859_14 is not set
CONFIG_NLS_ISO8859_15=y
# CONFIG_NLS_KOI8_R is not set
# CONFIG_NLS_KOI8_U is not set
CONFIG_NLS_UTF8=y
#
# Distributed Lock Manager
#
# CONFIG_DLM is not set
#
# Instrumentation Support
#
# CONFIG_PROFILING is not set
# CONFIG_KPROBES is not set
#
# Kernel hacking
#
CONFIG_TRACE_IRQFLAGS_SUPPORT=y
CONFIG_PRINTK_TIME=y
CONFIG_ENABLE_MUST_CHECK=y
CONFIG_MAGIC_SYSRQ=y
# CONFIG_UNUSED_SYMBOLS is not set
CONFIG_DEBUG_FS=y
# CONFIG_HEADERS_CHECK is not set
CONFIG_DEBUG_KERNEL=y
CONFIG_LOG_BUF_SHIFT=15
CONFIG_DETECT_SOFTLOCKUP=y
# CONFIG_SCHEDSTATS is not set
# CONFIG_DEBUG_SLAB is not set
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not set
# CONFIG_DEBUG_SPINLOCK is not set
# CONFIG_DEBUG_MUTEXES is not set
# CONFIG_DEBUG_RWSEMS is not set
# CONFIG_DEBUG_LOCK_ALLOC is not set
# CONFIG_PROVE_LOCKING is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not set
# CONFIG_DEBUG_LOCKING_API_SELFTESTS is not set
# CONFIG_DEBUG_KOBJECT is not set
CONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_FRAME_POINTER is not set
CONFIG_FORCED_INLINING=y
# CONFIG_RCU_TORTURE_TEST is not set
CONFIG_EARLY_PRINTK=y
# CONFIG_DEBUG_STACKOVERFLOW is not set
# CONFIG_DEBUG_STACK_USAGE is not set
#
# Page alloc debug is incompatible with Software Suspend on i386
#
# CONFIG_DEBUG_RODATA is not set
CONFIG_4KSTACKS=y
CONFIG_X86_FIND_SMP_CONFIG=y
CONFIG_X86_MPPARSE=y
CONFIG_DOUBLEFAULT=y
#
# Security options
#
# CONFIG_KEYS is not set
# CONFIG_SECURITY is not set
#
# Cryptographic options
#
CONFIG_CRYPTO=y
CONFIG_CRYPTO_ALGAPI=y
CONFIG_CRYPTO_BLKCIPHER=y
CONFIG_CRYPTO_MANAGER=y
# CONFIG_CRYPTO_HMAC is not set
# CONFIG_CRYPTO_XCBC is not set
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not set
# CONFIG_CRYPTO_MD5 is not set
# CONFIG_CRYPTO_SHA1 is not set
# CONFIG_CRYPTO_SHA256 is not set
# CONFIG_CRYPTO_SHA512 is not set
# CONFIG_CRYPTO_WP512 is not set
# CONFIG_CRYPTO_TGR192 is not set
# CONFIG_CRYPTO_GF128MUL is not set
CONFIG_CRYPTO_ECB=y
CONFIG_CRYPTO_CBC=y
# CONFIG_CRYPTO_LRW is not set
# CONFIG_CRYPTO_DES is not set
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not set
CONFIG_CRYPTO_AES=y
# CONFIG_CRYPTO_AES_586 is not set
# CONFIG_CRYPTO_CAST5 is not set
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not set
CONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not set
# CONFIG_CRYPTO_ANUBIS is not set
# CONFIG_CRYPTO_DEFLATE is not set
CONFIG_CRYPTO_MICHAEL_MIC=y
# CONFIG_CRYPTO_CRC32C is not set
# CONFIG_CRYPTO_TEST is not set
#
# Hardware crypto devices
#
# CONFIG_CRYPTO_DEV_PADLOCK is not set
CONFIG_CRYPTO_DEV_GEODE=m
#
# Library routines
#
CONFIG_BITREVERSE=y
CONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not set
CONFIG_CRC32=y
# CONFIG_LIBCRC32C is not set
CONFIG_ZLIB_INFLATE=y
CONFIG_ZLIB_DEFLATE=y
CONFIG_PLIST=y
CONFIG_IOMAP_COPY=y
CONFIG_GENERIC_HARDIRQS=y
CONFIG_GENERIC_IRQ_PROBE=y
CONFIG_X86_BIOS_REBOOT=y
CONFIG_KTIME_SCALAR=y
dmesg:
[ 0.000000] Linux version 2.6.20-rc2 (ranma@navi) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #26 Mon Dec 25 14:00:08 CET 2006
[ 0.000000] BIOS-provided physical RAM map:
[ 0.000000] sanitize start
[ 0.000000] sanitize end
[ 0.000000] copy_e820_map() start: 0000000000000000 size: 000000000009f000 end: 000000000009f000 type: 1
[ 0.000000] copy_e820_map() type is E820_RAM
[ 0.000000] copy_e820_map() start: 000000000009f000 size: 0000000000001000 end: 00000000000a0000 type: 2
[ 0.000000] copy_e820_map() start: 00000000000dc000 size: 0000000000024000 end: 0000000000100000 type: 2
[ 0.000000] copy_e820_map() start: 0000000000100000 size: 000000001fde0000 end: 000000001fee0000 type: 1
[ 0.000000] copy_e820_map() type is E820_RAM
[ 0.000000] copy_e820_map() start: 000000001fee0000 size: 0000000000015000 end: 000000001fef5000 type: 3
[ 0.000000] copy_e820_map() start: 000000001fef5000 size: 000000000000b000 end: 000000001ff00000 type: 4
[ 0.000000] copy_e820_map() start: 000000001ff00000 size: 0000000000100000 end: 0000000020000000 type: 2
[ 0.000000] copy_e820_map() start: 00000000e0000000 size: 0000000010000000 end: 00000000f0000000 type: 2
[ 0.000000] copy_e820_map() start: 00000000f0008000 size: 0000000000004000 end: 00000000f000c000 type: 2
[ 0.000000] copy_e820_map() start: 00000000fec00000 size: 0000000000010000 end: 00000000fec10000 type: 2
[ 0.000000] copy_e820_map() start: 00000000fed14000 size: 0000000000006000 end: 00000000fed1a000 type: 2
[ 0.000000] copy_e820_map() start: 00000000fed20000 size: 0000000000070000 end: 00000000fed90000 type: 2
[ 0.000000] copy_e820_map() start: 00000000fee00000 size: 0000000000001000 end: 00000000fee01000 type: 2
[ 0.000000] copy_e820_map() start: 00000000ff000000 size: 0000000001000000 end: 0000000100000000 type: 2
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f000 (usable)
[ 0.000000] BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved)
[ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved)
[ 0.000000] BIOS-e820: 0000000000100000 - 000000001fee0000 (usable)
[ 0.000000] BIOS-e820: 000000001fee0000 - 000000001fef5000 (ACPI data)
[ 0.000000] BIOS-e820: 000000001fef5000 - 000000001ff00000 (ACPI NVS)
[ 0.000000] BIOS-e820: 000000001ff00000 - 0000000020000000 (reserved)
[ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
[ 0.000000] BIOS-e820: 00000000f0008000 - 00000000f000c000 (reserved)
[ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved)
[ 0.000000] BIOS-e820: 00000000fed20000 - 00000000fed90000 (reserved)
[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved)
[ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved)
[ 0.000000] 510MB LOWMEM available.
[ 0.000000] Entering add_active_range(0, 0, 130784) 0 entries of 256 used
[ 0.000000] Zone PFN ranges:
[ 0.000000] DMA 0 -> 4096
[ 0.000000] Normal 4096 -> 130784
[ 0.000000] early_node_map[1] active PFN ranges
[ 0.000000] 0: 0 -> 130784
[ 0.000000] On node 0 totalpages: 130784
[ 0.000000] DMA zone: 32 pages used for memmap
[ 0.000000] DMA zone: 0 pages reserved
[ 0.000000] DMA zone: 4064 pages, LIFO batch:0
[ 0.000000] Normal zone: 989 pages used for memmap
[ 0.000000] Normal zone: 125699 pages, LIFO batch:31
[ 0.000000] DMI present.
[ 0.000000] ACPI: RSDP (v002 IBM ) @ 0x000f6bf0
[ 0.000000] ACPI: XSDT (v001 IBM TP-76 0x00001270 LTP 0x00000000) @ 0x1fee6f9b
[ 0.000000] ACPI: FADT (v003 IBM TP-76 0x00001270 IBM 0x00000001) @ 0x1fee7000
[ 0.000000] ACPI: SSDT (v001 IBM TP-76 0x00001270 MSFT 0x0100000e) @ 0x1fee71b4
[ 0.000000] ACPI: ECDT (v001 IBM TP-76 0x00001270 IBM 0x00000001) @ 0x1fef4d46
[ 0.000000] ACPI: TCPA (v001 IBM TP-76 0x00001270 PTL 0x00000001) @ 0x1fef4d98
[ 0.000000] ACPI: MADT (v001 IBM TP-76 0x00001270 IBM 0x00000001) @ 0x1fef4dca
[ 0.000000] ACPI: MCFG (v001 IBM TP-76 0x00001270 IBM 0x00000001) @ 0x1fef4e24
[ 0.000000] ACPI: BOOT (v001 IBM TP-76 0x00001270 LTP 0x00000001) @ 0x1fef4fd8
[ 0.000000] ACPI: DSDT (v001 IBM TP-76 0x00001270 MSFT 0x0100000e) @ 0x00000000
[ 0.000000] ACPI: PM-Timer IO Port: 0x1008
[ 0.000000] ACPI: Local APIC address 0xfee00000
[ 0.000000] ACPI: LAPIC (acpi_id[0x01] lapic_id[0x00] enabled)
[ 0.000000] Processor #0 6:13 APIC version 20
[ 0.000000] ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])
[ 0.000000] ACPI: IOAPIC (id[0x01] address[0xfec00000] gsi_base[0])
[ 0.000000] IOAPIC[0]: apic_id 1, version 32, address 0xfec00000, GSI 0-23
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
[ 0.000000] ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level)
[ 0.000000] ACPI: IRQ0 used by override.
[ 0.000000] ACPI: IRQ2 used by override.
[ 0.000000] ACPI: IRQ9 used by override.
[ 0.000000] Enabling APIC mode: Flat. Using 1 I/O APICs
[ 0.000000] Using ACPI (MADT) for SMP configuration information
[ 0.000000] Allocating PCI resources starting at 30000000 (gap: 20000000:c0000000)
[ 0.000000] Detected 1995.186 MHz processor.
[ 2.815181] Built 1 zonelists. Total pages: 129763
[ 2.815183] Kernel command line: root=/dev/sda6 resume=/dev/sda5 vga=ext parport=auto ide0=noprobe ide1=noprobe libata.atapi_enabled=1 ro
[ 2.815401] mapped APIC to ffff9000 (fee00000)
[ 2.815404] mapped IOAPIC to ffff8000 (fec00000)
[ 2.815406] Enabling fast FPU save and restore... done.
[ 2.815408] Enabling unmasked SIMD FPU exception support... done.
[ 2.815416] Initializing CPU#0
[ 2.815473] CPU 0 irqstacks, hard=c05f3000 soft=c05f2000
[ 2.815476] PID hash table entries: 2048 (order: 11, 8192 bytes)
[ 2.815491] is_hpet_capable()
[ 2.815493] trying to force-enable HPET
[ 2.815498] RCBA already mapped at f0008000
[ 2.815501] HPTC: RCBA Base is 0xf0008000, mapped at 0xffffc000 to 0xfffff000
[ 2.815505] HPTC: RCBA 0x3404 is 0x00000080n<3>Intel HPET force-enabled at 0xfed00000
[ 2.817499] Console: colour VGA+ 80x50
[ 2.821573] Dentry cache hash table entries: 65536 (order: 6, 262144 bytes)
[ 2.821816] Inode-cache hash table entries: 32768 (order: 5, 131072 bytes)
[ 2.831460] Memory: 512836k/523136k available (3392k kernel code, 9880k reserved, 1444k data, 200k init, 0k highmem)
[ 2.831572] virtual kernel memory layout:
[ 2.831573] fixmap : 0xfffb3000 - 0xfffff000 ( 304 kB)
[ 2.831574] vmalloc : 0xe0800000 - 0xfffb1000 ( 503 MB)
[ 2.831575] lowmem : 0xc0000000 - 0xdfee0000 ( 510 MB)
[ 2.831576] .init : 0xc05bb000 - 0xc05ed000 ( 200 kB)
[ 2.831577] .data : 0xc0450065 - 0xc05b90b8 (1444 kB)
[ 2.831579] .text : 0xc0100000 - 0xc0450065 (3392 kB)
[ 2.832061] Checking if this processor honours the WP bit even in supervisor mode... Ok.
[ 2.832297] hpet_enable
[ 2.832382] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0
[ 2.832602] hpet0: 3 64-bit timers, 14318180 Hz
[ 2.833675] Using HPET for base-timer
[ 2.915669] Calibrating delay using timer specific routine.. 3994.20 BogoMIPS (lpj=6654729)
[ 2.915836] Mount-cache hash table entries: 512
[ 2.915981] CPU: After generic identify, caps: afe9fbff 00100000 00000000 00000000 00000180 00000000 00000000
[ 2.915990] CPU: L1 I cache: 32K, L1 D cache: 32K
[ 2.916101] CPU: L2 cache: 2048K
[ 2.916171] CPU: After all inits, caps: afe9fbff 00100000 00000000 00002040 00000180 00000000 00000000
[ 2.916176] Intel machine check architecture supported.
[ 2.916248] Intel machine check reporting enabled on CPU#0.
[ 2.916320] Compat vDSO mapped to ffffa000.
[ 2.916396] CPU: Intel(R) Pentium(R) M processor 2.00GHz stepping 08
[ 2.916543] Checking 'hlt' instruction... OK.
[ 2.929131] ACPI: Core revision 20060707
[ 2.945497] ENABLING IO-APIC IRQs
[ 2.945753] ..TIMER: vector=0x31 apic1=0 pin1=2 apic2=-1 pin2=-1
[ 3.082402] NET: Registered protocol family 16
[ 3.082649] ACPI: ACPI Dock Station Driver
[ 3.082749] ACPI: bus type pci registered
[ 3.082824] PCI: Using MMCONFIG
[ 3.083561] Setting up standard PCI resources
[ 3.093993] ACPI: Interpreter enabled
[ 3.094065] ACPI: Using IOAPIC for interrupt routing
[ 3.094750] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.095684] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.096606] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.097521] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.098438] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.099369] ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.100284] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 *5 6 7 9 10 11)
[ 3.101201] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 6 7 9 10 *11)
[ 3.101926] ACPI: PCI Root Bridge [PCI0] (0000:00)
[ 3.102000] PCI: Probing PCI hardware (bus 00)
[ 3.103425] HPTC: RCBA Base is 0xf0008000
[ 3.103498] HPTC: RCBA 0x3404 is 0x80
[ 3.103566] HPTC: HPTC enabled
[ 3.103635] HPTC: HPET located at 0xfed00000
[ 3.103707] PCI quirk: region 1000-107f claimed by ICH6 ACPI/GPIO/TCO
[ 3.103779] PCI quirk: region 1180-11bf claimed by ICH6 GPIO
[ 3.103989] Boot video device is 0000:01:00.0
[ 3.104433] PCI: Transparent bridge - 0000:00:1e.0
[ 3.104583] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT]
[ 3.109110] ACPI: Power Resource [PUBS] (on)
[ 3.110023] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT]
[ 3.110275] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP0._PRT]
[ 3.110438] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.EXP2._PRT]
[ 3.110626] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.PCI1._PRT]
[ 3.112300] Linux Plug and Play Support v0.97 (c) Adam Belay
[ 3.112376] pnp: PnP ACPI init
[ 3.115896] pnp: PnP ACPI: found 13 devices
[ 3.115984] intel_rng: FWH not detected
[ 3.116140] SCSI subsystem initialized
[ 3.116225] libata version 2.00 loaded.
[ 3.116258] usbcore: registered new interface driver usbfs
[ 3.116349] usbcore: registered new interface driver hub
[ 3.116441] usbcore: registered new device driver usb
[ 3.116549] PCI: Using ACPI for IRQ routing
[ 3.116621] PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report
[ 3.215491] Bluetooth: Core ver 2.11
[ 3.215587] NET: Registered protocol family 31
[ 3.215657] Bluetooth: HCI device and connection manager initialized
[ 3.215728] Bluetooth: HCI socket layer initialized
[ 3.216289] ieee1394: Initialized config rom entry `ip1394'
[ 3.216345] PCI: Bridge: 0000:00:01.0
[ 3.216417] IO window: 3000-3fff
[ 3.216487] MEM window: b0100000-b01fffff
[ 3.216557] PREFETCH window: c0000000-c7ffffff
[ 3.216626] PCI: Bridge: 0000:00:1c.0
[ 3.216694] IO window: disabled.
[ 3.216766] MEM window: b0200000-b02fffff
[ 3.216835] PREFETCH window: disabled.
[ 3.216906] PCI: Bridge: 0000:00:1c.2
[ 3.216976] IO window: 4000-4fff
[ 3.217047] MEM window: b2000000-b3ffffff
[ 3.217117] PREFETCH window: c8000000-c80fffff
[ 3.217190] PCI: Bus 12, cardbus bridge: 0000:0b:00.0
[ 3.217260] IO window: 00005000-000050ff
[ 3.217331] IO window: 00005400-000054ff
[ 3.217403] PREFETCH window: d0000000-d3ffffff
[ 3.217474] MEM window: b8000000-bbffffff
[ 3.217545] PCI: Bridge: 0000:00:1e.0
[ 3.217615] IO window: 5000-8fff
[ 3.217686] MEM window: b4000000-bfffffff
[ 3.217757] PREFETCH window: d0000000-d7ffffff
[ 3.217834] ACPI: PCI Interrupt 0000:00:01.0[A] -> GSI 16 (level, low) -> IRQ 16
[ 3.217973] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 3.217986] ACPI: PCI Interrupt 0000:00:1c.0[A] -> GSI 20 (level, low) -> IRQ 17
[ 3.218125] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[ 3.218140] ACPI: PCI Interrupt 0000:00:1c.2[C] -> GSI 22 (level, low) -> IRQ 18
[ 3.218278] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[ 3.218287] PCI: Setting latency timer of device 0000:00:1e.0 to 64
[ 3.218298] ACPI: PCI Interrupt 0000:0b:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[ 3.218448] NET: Registered protocol family 2
[ 3.248830] IP route cache hash table entries: 4096 (order: 2, 16384 bytes)
[ 3.248952] TCP established hash table entries: 16384 (order: 4, 65536 bytes)
[ 3.249071] TCP bind hash table entries: 8192 (order: 3, 32768 bytes)
[ 3.249167] TCP: Hash tables configured (established 16384 bind 8192)
[ 3.249238] TCP reno registered
[ 3.258925] Simple Boot Flag at 0x35 set to 0x1
[ 3.259018] Machine check exception polling timer started.
[ 3.259287] Installing knfsd (copyright (C) 1996 okir@monad.swb.de).
[ 3.259478] NTFS driver 2.1.27 [Flags: R/W].
[ 3.259606] io scheduler noop registered
[ 3.259714] io scheduler anticipatory registered (default)
[ 3.259858] io scheduler deadline registered
[ 3.259969] io scheduler cfq registered
[ 3.261652] PCI: Setting latency timer of device 0000:00:01.0 to 64
[ 3.261667] assign_interrupt_mode Found MSI capability
[ 3.261754] Allocate Port Service[0000:00:01.0:pcie00]
[ 3.261774] Allocate Port Service[0000:00:01.0:pcie03]
[ 3.261816] PCI: Setting latency timer of device 0000:00:1c.0 to 64
[ 3.261852] assign_interrupt_mode Found MSI capability
[ 3.261949] Allocate Port Service[0000:00:1c.0:pcie00]
[ 3.261967] Allocate Port Service[0000:00:1c.0:pcie02]
[ 3.261987] Allocate Port Service[0000:00:1c.0:pcie03]
[ 3.262059] PCI: Setting latency timer of device 0000:00:1c.2 to 64
[ 3.262095] assign_interrupt_mode Found MSI capability
[ 3.262197] Allocate Port Service[0000:00:1c.2:pcie00]
[ 3.262215] Allocate Port Service[0000:00:1c.2:pcie02]
[ 3.262233] Allocate Port Service[0000:00:1c.2:pcie03]
[ 3.262314] pci_hotplug: PCI Hot Plug PCI Core version: 0.5
[ 3.262387] ibmphpd: IBM Hot Plug PCI Controller Driver version: 0.6
[ 3.262462] acpiphp: ACPI Hot Plug PCI Controller Driver version: 0.5
[ 3.265962] decode_hpp: Could not get hotplug parameters. Use defaults
[ 3.266059] acpiphp: Slot [1] registered
[ 3.267122] acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_find_acpi_device: Failed to get device information<3>acpiphp_ibm: ibm_acpiphp_init: acpi_walk_namespace failed
[ 3.269969] ACPI: AC Adapter [AC] (on-line)
[ 3.278158] ACPI: Battery Slot [BAT0] (battery present)
[ 3.278284] input: Power Button (FF) as /class/input/input0
[ 3.278358] ACPI: Power Button (FF) [PWRF]
[ 3.278459] input: Lid Switch as /class/input/input1
[ 3.278532] ACPI: Lid Switch [LID]
[ 3.278632] input: Sleep Button (CM) as /class/input/input2
[ 3.278706] ACPI: Sleep Button (CM) [SLPB]
[ 3.278995] ACPI: Video Device [VID] (multi-head: yes rom: no post: no)
[ 3.280635] ACPI: CPU0 (power states: C1[C1] C2[C2] C3[C3])
[ 3.280857] ACPI: Processor [CPU] (supports 8 throttling states)
[ 3.281966] ACPI: Thermal Zone [THM0] (63 C)
[ 3.283336] Real Time Clock Driver v1.12ac
[ 3.283432] Linux agpgart interface v0.101 (c) Dave Jones
[ 3.283522] agpgart: Detected an Intel 915GM Chipset.
[ 3.300594] agpgart: AGP aperture is 256M @ 0x0
[ 3.300695] [drm] Initialized drm 1.1.0 20060810
[ 3.300877] tpm_nsc tpm_nscl0: NSC TPM revision 2
[ 3.301002] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing disabled
[ 3.301249] serial8250: ttyS1 at I/O 0x2f8 (irq = 3) is a NS16550A
[ 3.302001] pnp: Device 00:09 activated.
[ 3.302186] 00:09: ttyS0 at I/O 0x3f8 (irq = 4) is a NS16550A
[ 3.302352] ACPI: PCI Interrupt 0000:00:1e.3[B] -> GSI 23 (level, low) -> IRQ 19
[ 3.302495] ACPI: PCI interrupt for device 0000:00:1e.3 disabled
[ 3.302599] parport: PnPBIOS parport detected.
[ 3.302704] parport0: PC-style at 0x3bc (0x7bc), irq 7 [PCSPP(,...)]
[ 3.303238] loop: loaded (max 8 devices)
[ 3.303352] nbd: registered device at major 43
[ 3.303761] Ethernet Channel Bonding Driver: v3.1.1 (September 26, 2006)
[ 3.303837] bonding: Warning: either miimon or arp_interval and arp_ip_target module parameters must be specified, otherwise bonding will not detect link failures! see bonding.txt for details.
[ 3.304025] pcnet32.c:v1.33 27.Jun.2006 tsbogend@alpha.franken.de
[ 3.304115] e100: Intel(R) PRO/100 Network Driver, 3.5.17-k2-NAPI
[ 3.304185] e100: Copyright(c) 1999-2006 Intel Corporation
[ 3.304292] tg3.c:v3.71 (December 15, 2006)
[ 3.304377] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 16 (level, low) -> IRQ 16
[ 3.304520] PCI: Setting latency timer of device 0000:02:00.0 to 64
[ 0.399999] eth0: Tigon3 [partno(BCM95751M) rev 4101 PHY(5750)] (PCI Express) 10/100/1000Base-T Ethernet 00:0a:e4:c1:27:01
[ 0.399999] eth0: RXcsums[1] LinkChgREG[0] MIirq[0] ASF[0] Split[0] WireSpeed[1] TSOcap[1]
[ 0.399999] eth0: dma_rwctrl[76180000] dma_mask[64-bit]
[ 0.399999] PPP generic driver version 2.4.2
[ 0.399999] PPP Deflate Compression module registered
[ 0.399999] PPP BSD Compression module registered
[ 0.403333] NET: Registered protocol family 24
[ 0.403333] tun: Universal TUN/TAP device driver, 1.6
[ 0.403333] tun: (C) 1999-2004 Max Krasnyansky <maxk@qualcomm.com>
[ 0.403333] netconsole: not configured, aborting
[ 0.403333] ahci 0000:00:1f.2: version 2.0
[ 0.403333] ahci: probe of 0000:00:1f.2 failed with error -12
[ 0.403333] ata_piix 0000:00:1f.2: version 2.00ac7
[ 0.403333] ata_piix 0000:00:1f.2: MAP [ P0 P2 IDE IDE ]
[ 0.403333] PCI: Setting latency timer of device 0000:00:1f.2 to 64
[ 0.403333] ata1: SATA max UDMA/133 cmd 0x1F0 ctl 0x3F6 bmdma 0x18C0 irq 14
[ 0.403333] ata2: PATA max UDMA/100 cmd 0x170 ctl 0x376 bmdma 0x18C8 irq 15
[ 0.403333] scsi0 : ata_piix
[ 0.563333] ata1.00: ATA-6, max UDMA/100, 195371568 sectors: LBA
[ 0.563333] ata1.00: ata1: dev 0 multi count 16
[ 0.563333] ata1.00: applying bridge limits
[ 0.573333] ata1.00: configured for UDMA/100
[ 0.573333] scsi1 : ata_piix
[ 0.886666] ata2.00: ATAPI, max UDMA/33
[ 1.046666] ata2.00: configured for UDMA/33
[ 1.046666] scsi 0:0:0:0: Direct-Access ATA FUJITSU MHV2100A 0084 PQ: 0 ANSI: 5
[ 1.046666] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[ 1.046666] sda: Write Protect is off
[ 1.046666] sda: Mode Sense: 00 3a 00 00
[ 1.046666] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.046666] SCSI device sda: 195371568 512-byte hdwr sectors (100030 MB)
[ 1.046666] sda: Write Protect is off
[ 1.046666] sda: Mode Sense: 00 3a 00 00
[ 1.046666] SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA
[ 1.046666] sda: sda1 sda2 sda3 < sda5 sda6 sda7 > sda4
[ 1.113333] sd 0:0:0:0: Attached scsi disk sda
[ 1.113333] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 1.116666] scsi 1:0:0:0: CD-ROM MATSHITA DVD-RAM UJ-830S 1.02 PQ: 0 ANSI: 5
[ 1.123333] sr0: scsi3-mmc drive: 24x/24x writer dvd-ram cd/rw xa/form2 cdda tray
[ 1.123333] Uniform CD-ROM driver Revision: 3.20
[ 1.123333] sr 1:0:0:0: Attached scsi CD-ROM sr0
[ 1.123333] sr 1:0:0:0: Attached scsi generic sg1 type 5
[ 1.123333] ieee1394: raw1394: /dev/raw1394 device initialized
[ 1.123333] Yenta: CardBus bridge found at 0000:0b:00.0 [1014:0532]
[ 1.249999] Yenta: ISA IRQ mask 0x0438, PCI irq 16
[ 1.249999] Socket status: 30000006
[ 1.249999] pcmcia: parent PCI bridge I/O window: 0x5000 - 0x8fff
[ 1.249999] cs: IO port probe 0x5000-0x8fff: clean.
[ 1.249999] pcmcia: parent PCI bridge Memory window: 0xb4000000 - 0xbfffffff
[ 1.249999] pcmcia: parent PCI bridge Memory window: 0xd0000000 - 0xd7ffffff
[ 1.503333] usbcore: registered new interface driver usblp
[ 1.503333] drivers/usb/class/usblp.c: v0.13: USB Printer Device Class driver
[ 1.503333] usbcore: registered new interface driver libusual
[ 1.503333] usbcore: registered new interface driver usbhid
[ 1.503333] drivers/usb/input/hid-core.c: v2.6:USB HID core driver
[ 1.503333] usbcore: registered new interface driver asix
[ 1.503333] usbcore: registered new interface driver usbserial
[ 1.503333] drivers/usb/serial/usb-serial.c: USB Serial support registered for generic
[ 1.503333] usbcore: registered new interface driver usbserial_generic
[ 1.503333] drivers/usb/serial/usb-serial.c: USB Serial Driver core
[ 1.503333] drivers/usb/serial/usb-serial.c: USB Serial support registered for hp4X
[ 1.503333] usbcore: registered new interface driver hp4X
[ 1.503333] drivers/usb/serial/hp4x.c: HP4x (48/49) Generic Serial driver v1.00
[ 1.503333] drivers/usb/serial/usb-serial.c: USB Serial support registered for pl2303
[ 1.503333] usbcore: registered new interface driver pl2303
[ 1.503333] drivers/usb/serial/pl2303.c: Prolific PL2303 USB to serial adaptor driver
[ 1.503333] PNP: PS/2 Controller [PNP0303:KBD,PNP0f13:MOU] at 0x60,0x64 irq 1,12
[ 1.509999] serio: i8042 KBD port at 0x60,0x64 irq 1
[ 1.509999] serio: i8042 AUX port at 0x60,0x64 irq 12
[ 1.509999] mice: PS/2 mouse device common for all mice
[ 1.513333] input: AT Translated Set 2 keyboard as /class/input/input3
[ 1.519999] i2c /dev entries driver
[ 1.519999] ACPI: PCI Interrupt 0000:00:1f.3[A] -> GSI 23 (level, low) -> IRQ 19
[ 1.519999] device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm-devel@redhat.com
[ 1.519999] EDAC MC: Ver: 2.0.1 Dec 25 2006
[ 1.549999] Advanced Linux Sound Architecture Driver Version 1.0.14rc1 (Wed Dec 20 08:11:48 2006 UTC).
[ 1.549999] ACPI: PCI Interrupt 0000:00:1e.2[A] -> GSI 22 (level, low) -> IRQ 18
[ 1.549999] PCI: Setting latency timer of device 0000:00:1e.2 to 64
[ 1.816666] ACPI: EC: evaluating _Q75
[ 2.133333] Synaptics Touchpad, model: 1, fw: 5.9, id: 0x2c6ab1, caps: 0x884793/0x0
[ 2.133333] serio: Synaptics pass-through port at isa0060/serio1/input0
[ 2.176666] input: SynPS/2 Synaptics TouchPad as /class/input/input4
[ 2.473333] intel8x0_measure_ac97_clock: measured 53330 usecs
[ 2.473333] intel8x0: clocking to 48000
[ 2.473333] ALSA device list:
[ 2.473333] #0: Intel ICH6 with AD1981B at 0xb0000800, irq 18
[ 2.473333] netem: version 1.2
[ 2.473333] u32 classifier
[ 2.473333] Netfilter messages via NETLINK v0.30.
[ 2.473333] ip_tables: (C) 2000-2006 Netfilter Core Team
[ 2.553333] TCP bic registered
[ 2.553333] TCP cubic registered
[ 2.553333] TCP westwood registered
[ 2.553333] TCP highspeed registered
[ 2.553333] TCP vegas registered
[ 2.553333] NET: Registered protocol family 1
[ 2.553333] NET: Registered protocol family 10
[ 2.553333] IPv6 over IPv4 tunneling driver
[ 2.553333] NET: Registered protocol family 17
[ 2.633333] Bridge firewalling registered
[ 2.633333] Bluetooth: L2CAP ver 2.8
[ 2.633333] Bluetooth: L2CAP socket layer initialized
[ 2.633333] Bluetooth: SCO (Voice Link) ver 0.5
[ 2.633333] Bluetooth: SCO socket layer initialized
[ 2.633333] Bluetooth: RFCOMM socket layer initialized
[ 2.633333] Bluetooth: RFCOMM TTY layer initialized
[ 2.633333] Bluetooth: RFCOMM ver 1.8
[ 2.633333] Bluetooth: BNEP (Ethernet Emulation) ver 1.2
[ 2.633333] Bluetooth: BNEP filters: protocol multicast
[ 2.633333] Bluetooth: HIDP (Human Interface Emulation) ver 1.1
[ 2.633333] 802.1Q VLAN Support v1.8 Ben Greear <greearb@candelatech.com>
[ 2.633333] All bugs added by David S. Miller <davem@redhat.com>
[ 2.633333] ieee80211: 802.11 data/management/control stack, git-1.1.13
[ 2.633333] ieee80211: Copyright (C) 2004-2005 Intel Corporation <jketreno@linux.intel.com>
[ 2.633333] ieee80211_crypt: registered algorithm 'NULL'
[ 2.633333] ieee80211_crypt: registered algorithm 'WEP'
[ 2.633333] ieee80211_crypt: registered algorithm 'CCMP'
[ 2.633333] ieee80211_crypt: registered algorithm 'TKIP'
[ 2.633333] speedstep-centrino with X86_SPEEDSTEP_CENTRINO_ACPIconfig is deprecated.
[ 2.633333] Use X86_ACPI_CPUFREQ (acpi-cpufreq instead.
[ 2.633333] Using IPI Shortcut mode
[ 2.633333] ACPI: (supports S0 S3 S4 S5)
[ 2.636666] Time: tsc clocksource has been installed.
[ 2.643333] Time: hpet clocksource has been installed.
[ 7.439999] IBM TrackPoint firmware: 0x0e, buttons: 3/3
[ 7.696665] input: TPPS/2 IBM TrackPoint as /class/input/input5
[ 7.703332] ACPI: EC: evaluating _Q75
[ 7.879999] kjournald starting. Commit interval 5 seconds
[ 7.879999] EXT3-fs: mounted filesystem with ordered data mode.
[ 7.879999] VFS: Mounted root (ext3 filesystem) readonly.
[ 7.879999] Freeing unused kernel memory: 200k freed
[ 11.453332] ACPI: PCI Interrupt 0000:0b:00.1[B] -> GSI 17 (level, low) -> IRQ 20
[ 11.506665] ohci1394: fw-host0: OHCI-1394 1.0 (PCI): IRQ=[20] MMIO=[b1000000-b10007ff] Max Packet=[2048] IR/IT contexts=[4/4]
[ 11.516665] eth1394: eth0: IEEE-1394 IPv4 over 1394 Ethernet (fw-host0)
[ 11.679998] cs: IO port probe 0x100-0x4ff: excluding 0x4d0-0x4d7
[ 11.683332] cs: IO port probe 0x800-0x8ff: clean.
[ 11.683332] cs: IO port probe 0xc00-0xcff: clean.
[ 11.683332] cs: IO port probe 0xa00-0xaff: clean.
[ 12.166665] Adding 1958000k swap on /dev/sda5. Priority:10 extents:1 across:1958000k
[ 12.319998] EXT3 FS on sda6, internal journal
[ 12.693332] ibm_acpi: ThinkPad EC firmware 76HT16WW-1.06
[ 12.693332] ibm_acpi: IBM ThinkPad ACPI Extras v0.13
[ 12.693332] ibm_acpi: http://ibm-acpi.sf.net/
[ 12.699998] ibm_acpi: fan_init: initial fan status is unknown, assuming it is in auto mode
[ 12.783332] ieee1394: Host added: ID:BUS[0-00:1023] GUID[000ae405314003e1]
[ 13.063332] kjournald starting. Commit interval 5 seconds
[ 13.063332] EXT3-fs: mounted filesystem with ordered data mode.
[ 13.066665] kjournald starting. Commit interval 5 seconds
[ 13.066665] EXT3 FS on sda7, internal journal
[ 13.066665] EXT3-fs: mounted filesystem with ordered data mode.
[ 13.493331] pcmcia: Detected deprecated PCMCIA ioctl usage from process: discover.
[ 13.493331] pcmcia: This interface will soon be removed from the kernel; please expect breakage unless you upgrade to new tools.
[ 13.493331] pcmcia: see http://www.kernel.org/pub/linux/utils/kernel/pcmcia/pcmcia.html for details.
[ 15.979998] ieee1394: Node removed: ID:BUS[0-00:1023] GUID[000ae405314003e1]
--
Tobias PGP: http://9ac7e0bc.uguu.de
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-26 16:17 ` Tobias Diedrich
@ 2006-12-27 4:55 ` David Miller
2006-12-27 7:00 ` Linus Torvalds
2006-12-28 0:16 ` Linus Torvalds
0 siblings, 2 replies; 45+ messages in thread
From: David Miller @ 2006-12-27 4:55 UTC (permalink / raw)
To: ranma
Cc: torvalds, gordonfarquharson, tbm, a.p.zijlstra, andrei.popa,
akpm, hugh, nickpiggin, arjan, linux-kernel
From: Tobias Diedrich <ranma@tdiedrich.de>
Date: Tue, 26 Dec 2006 17:17:00 +0100
> Linus Torvalds wrote:
> > I don't think it's a page table issue any more, it just doesn't look
> > likely with the ARM UP corruption. It's also not apparently even on a
> > cacheline boundary, so it probably is really a dirty bit that got cleared
> > wrogn due to some race with IO.
>
> So, until now it's only been reported for SMP on i386?
> I'm seeing the issue on my Pentium-M Notebook (Thinkpad R52) over
> here, UP kernel, no preempt.
I've seen it on sparc64, UP kernel, no preempt.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-27 4:55 ` [PATCH] mm: fix page_mkclean_one David Miller
@ 2006-12-27 7:00 ` Linus Torvalds
2006-12-27 8:39 ` Andrei Popa
2006-12-28 0:16 ` Linus Torvalds
1 sibling, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-27 7:00 UTC (permalink / raw)
To: David Miller
Cc: ranma, gordonfarquharson, tbm, a.p.zijlstra, andrei.popa, akpm,
hugh, nickpiggin, arjan, linux-kernel
On Tue, 26 Dec 2006, David Miller wrote:
>
> I've seen it on sparc64, UP kernel, no preempt.
Btw, having tried to debug the writeback code, there's one very special
case that just makes me go "hmm".
If we have a buffer that is "busy" when we try to write back a page, we
have this magic "wbc->sync_mode == WB_SYNC_NONE && wbc->nonblocking" mode,
where we won't wait for it, but instead we'll redirty the page and redo
the whole thing.
Looking at the code, that should all work, but at the same time, it
triggers some of my debug messages about having a dirty page during
writeback, and one way to trigger that debug message is to try to run
rtorrent on the machine..
I dunno. Witht he writeback being suspicious, and the normal
"block_write_full_page()" path being implicated in at least ext2, I just
wonder. This is one of those "let's see if behaviour changes" patches,
that I'm just throwing out there..
Linus
---
diff --git a/fs/buffer.c b/fs/buffer.c
index 263f88e..4652ef1 100644
--- a/fs/buffer.c
+++ b/fs/buffer.c
@@ -1653,19 +1653,7 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
do {
if (!buffer_mapped(bh))
continue;
- /*
- * If it's a fully non-blocking write attempt and we cannot
- * lock the buffer then redirty the page. Note that this can
- * potentially cause a busy-wait loop from pdflush and kswapd
- * activity, but those code paths have their own higher-level
- * throttling.
- */
- if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
- lock_buffer(bh);
- } else if (test_set_buffer_locked(bh)) {
- redirty_page_for_writepage(wbc, page);
- continue;
- }
+ lock_buffer(bh);
if (test_clear_buffer_dirty(bh)) {
mark_buffer_async_write(bh);
} else {
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-27 7:00 ` Linus Torvalds
@ 2006-12-27 8:39 ` Andrei Popa
0 siblings, 0 replies; 45+ messages in thread
From: Andrei Popa @ 2006-12-27 8:39 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, gordonfarquharson, tbm, a.p.zijlstra, akpm,
hugh, nickpiggin, arjan, linux-kernel
I have corrupted files...
> ---
> diff --git a/fs/buffer.c b/fs/buffer.c
> index 263f88e..4652ef1 100644
> --- a/fs/buffer.c
> +++ b/fs/buffer.c
> @@ -1653,19 +1653,7 @@ static int __block_write_full_page(struct inode *inode, struct page *page,
> do {
> if (!buffer_mapped(bh))
> continue;
> - /*
> - * If it's a fully non-blocking write attempt and we cannot
> - * lock the buffer then redirty the page. Note that this can
> - * potentially cause a busy-wait loop from pdflush and kswapd
> - * activity, but those code paths have their own higher-level
> - * throttling.
> - */
> - if (wbc->sync_mode != WB_SYNC_NONE || !wbc->nonblocking) {
> - lock_buffer(bh);
> - } else if (test_set_buffer_locked(bh)) {
> - redirty_page_for_writepage(wbc, page);
> - continue;
> - }
> + lock_buffer(bh);
> if (test_clear_buffer_dirty(bh)) {
> mark_buffer_async_write(bh);
> } else {
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-27 4:55 ` [PATCH] mm: fix page_mkclean_one David Miller
2006-12-27 7:00 ` Linus Torvalds
@ 2006-12-28 0:16 ` Linus Torvalds
2006-12-28 0:39 ` Linus Torvalds
1 sibling, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 0:16 UTC (permalink / raw)
To: David Miller
Cc: ranma, gordonfarquharson, tbm, a.p.zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Tue, 26 Dec 2006, David Miller wrote:
>
> I've seen it on sparc64, UP kernel, no preempt.
Ok, I still don't have a clue, but I think I at least have a new
test-case.
It can probably be improved upon, but this would _seem_ to trigger the
problem. Can people check?
You'd want to make sure you get page-put activity, by making TARGETSIZE be
big enough to cause memory pressure (and rather than making it bigger, you
might want to make your memory smaller instead, to make it run more
quickly. Either using "mem=128M" or big compiles or something...).
If it finds corruption, you'll see something like
Writing chunk 183858/183859 (99%)
Chunk ..
Chunk 120887 corrupted
Chunk 122372 corrupted
Chunk ...
Checking chunk 183858/183859 (99%)
otherwise it will just say
Writing chunk 183858/183859 (99%)
Checking chunk 183858/183859 (99%)
and exit.
I didn't spend a lot of time verifying this, but I _was_ able to cause
those "Chunk xxx corrupted" messages with this. There's probably a more
efficient better way to do it, but this is better than trying to use
rtorrent, and also makes any worries about what rtorrent does go away.
Of course, maybe it's this test-program that is buggy now, although it
looks trivial enough that I don't think it is.
I think my earlier stress-tester may not have triggered this, because it
just did all its writing in a linear order, so any LRU logic will happen
to write back old pages that we are no longer touching. The randomization
(and using a chunksize that isn't a multiple of a page-size) makes sure
that we're actually going to have lots of rewriting going on.
I think the test-case could probably be improved by having a munmap() and
page-cache flush in between the writing and the checking, to see whether
that shows the corruption easier (and possibly without having to start
paging in order to throw the pages out, which would simplify testing a
lot). But I haven't tested. I decided to post this asap, now that I've
recreated the corruption with something else, and something that is
possibly easier to analyze..
Linus
----
#include <sys/mman.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
#define TARGETSIZE (256 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
static void checkmem(void *start, int nr)
{
unsigned char c = nr, *p = start;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
if (*p++ != c) {
printf("Chunk %d corrupted \n", nr);
return;
}
}
}
int main(int argc, char **argv)
{
char *mapping;
int fd, i;
static int chunkorder[NRCHUNKS];
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
return 0;
}
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 0:16 ` Linus Torvalds
@ 2006-12-28 0:39 ` Linus Torvalds
2006-12-28 0:52 ` David Miller
0 siblings, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 0:39 UTC (permalink / raw)
To: David Miller
Cc: ranma, gordonfarquharson, tbm, a.p.zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, 27 Dec 2006, Linus Torvalds wrote:
>
> I think the test-case could probably be improved by having a munmap() and
> page-cache flush in between the writing and the checking, to see whether
> that shows the corruption easier (and possibly without having to start
> paging in order to throw the pages out, which would simplify testing a
> lot).
I think the page-writeout is implicated, because I do seem to need it, but
the page-cache flush does seem to make corruption _easier_ to see. I now
seem about to trigger it with a 100MB file on a 256MB machine in a minute
or so, with this slight modification.
I still don't see _why_, though. But maybe smarter people than me can see
it..
Linus
---
#include <sys/mman.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
#define TARGETSIZE (100 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
static void checkmem(void *start, int nr)
{
unsigned char c = nr, *p = start;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
if (*p++ != c) {
printf("Chunk %d corrupted \n", nr);
return;
}
}
}
static char *remap(int fd, char *mapping)
{
if (mapping) {
munmap(mapping, SIZE);
posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}
int main(int argc, char **argv)
{
char *mapping;
int fd, i;
static int chunkorder[NRCHUNKS];
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = remap(fd, NULL);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
/* Unmap, drop, and remap.. */
mapping = remap(fd, mapping);
/* .. and check */
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
return 0;
}
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 0:39 ` Linus Torvalds
@ 2006-12-28 0:52 ` David Miller
2006-12-28 3:04 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: David Miller @ 2006-12-28 0:52 UTC (permalink / raw)
To: torvalds
Cc: ranma, gordonfarquharson, tbm, a.p.zijlstra, andrei.popa, akpm,
hugh, nickpiggin, arjan, linux-kernel
From: Linus Torvalds <torvalds@osdl.org>
Date: Wed, 27 Dec 2006 16:39:43 -0800 (PST)
>
>
> On Wed, 27 Dec 2006, Linus Torvalds wrote:
> >
> > I think the test-case could probably be improved by having a munmap() and
> > page-cache flush in between the writing and the checking, to see whether
> > that shows the corruption easier (and possibly without having to start
> > paging in order to throw the pages out, which would simplify testing a
> > lot).
>
> I think the page-writeout is implicated, because I do seem to need it, but
> the page-cache flush does seem to make corruption _easier_ to see. I now
> seem about to trigger it with a 100MB file on a 256MB machine in a minute
> or so, with this slight modification.
>
> I still don't see _why_, though. But maybe smarter people than me can see
> it..
FWIW this program definitely triggers the bug for me.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 0:52 ` David Miller
@ 2006-12-28 3:04 ` Linus Torvalds
2006-12-28 4:32 ` Gordon Farquharson
` (4 more replies)
0 siblings, 5 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 3:04 UTC (permalink / raw)
To: David Miller
Cc: ranma, gordonfarquharson, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, 27 Dec 2006, David Miller wrote:
> >
> > I still don't see _why_, though. But maybe smarter people than me can see
> > it..
>
> FWIW this program definitely triggers the bug for me.
Ok, now that I have something simple to do repeatable stuff with, I can
say what the pattern is.. It's not all that surprising, but it's still
worth just stating for the record.
What happens is that when I do the "packetized writes" in random order,
the _last_ write to a page occasionally just goes missing. It's not always
at the end of a page, as shown by for example:
- A whole chunk got dropped:
Chunk 2094 corrupted (0-1459) (1624-3083)
Expected 46, got 0
Written as (30912)55414(10000)
That "Written as (x)y(z)" line means that the corrupted chunk was
written as chunk #y, and the preceding and following chunks (that were
_not_ corrupt) on the page was written as #x and #z respectively.
In other words, the missing chunk (which is still zero) was written
much later than the ones that were ok, and never hit the disk. It's a
contiguous chunk in the middle of the page (chunks are 1460 bytes in
size)
The first line means that all bytes of the chunk (0-1459) were
corrupted, and the values in parenthesis are the offsets within a page.
In other words, this was a chunk in the _middle_ of a page.
- The missing data can also be at the beginning or ends of pages:
Beginning of the chunk missing, it was at the end of a page (page
offsets 3288-4095) and the _next_ page got written out fine:
Chunk 2126 corrupted (0-807) (3288-4095)
Expected 78, got 0
Written as (32713)55573(14301)
End of a chunk missing, it was the beginning of a page (and the
_previous_ page that contained the beginning of the chunk was written
out fine)
Chunk 2179 corrupted (1252-1459) (0-207)
Expected 131, got 0
Written as (45189)55489(15515)
Now, the reason I say this isn't surprising is that this is entirely
consistent with the dirty bit being dropped on the floor somewhere, and
likely through some interaction with the previous changes being in the
process of being written out.
Something (incorrectly) ends up deciding that it doesn't need to write the
page, since it's already written, or alternatively clears the dirty bit
too late (clears it because an _earlier_ write finished, never mind that
the new dirty data didn't make it).
I also figured out that it's not the low-memory situation that does it, it
really must be the "page_mkclean()" triggering. Becuase I can do
echo 5 > /proc/sys/vm/dirty_ratio
echo 3 > /proc/sys/vm/dirty_background_ratio
to make it clean the pages much more aggressively than the default, and I
can see corruption on my 256MB machine with just a 40MB shared file, and
70MB of memory consistently free.
So this thing is definitely giving some answers. It's NOT about low
memory, and it very much seems to be about the whole "balance_dirty_ratio"
thing. I don't think I triggered the actual low-memory stuff once in that
situation..
So I have some more data on the behaviour, but I _still_ don't see the
reason behind it. It's probably something really obvious once it's pointed
out..
[ Modified test-program that tells you where the corruption happens (and
when the missing parts were supposed to be written out) appended, in
case people care. ]
Linus
---
#include <sys/mman.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
#define TARGETSIZE (100 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
#define page_offset(buf, off) (0xfff & ((unsigned)(unsigned long)(buf)+(off)))
static int chunkorder[NRCHUNKS];
static int order(int nr)
{
int i;
if (nr < 0 || nr >= NRCHUNKS)
return -1;
for (i = 0; i < NRCHUNKS; i++)
if (chunkorder[i] == nr)
return i;
return -2;
}
static void checkmem(void *buf, int nr)
{
unsigned int start = ~0u, end = 0;
unsigned char c = nr, *p = buf, differs = 0;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
unsigned char got = *p++;
if (got != c) {
if (i < start)
start = i;
if (i > end)
end = i;
differs = got;
}
}
if (start < end) {
printf("Chunk %d corrupted (%u-%u) (%u-%u) \n", nr, start, end,
page_offset(buf, start), page_offset(buf, end));
printf("Expected %u, got %u\n", c, differs);
printf("Written as (%d)%d(%d)\n", order(nr-1), order(nr), order(nr+1));
}
}
static char *remap(int fd, char *mapping)
{
if (mapping) {
munmap(mapping, SIZE);
posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}
int main(int argc, char **argv)
{
char *mapping;
int fd, i;
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = remap(fd, NULL);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
/* Unmap, drop, and remap.. */
mapping = remap(fd, mapping);
/* .. and check */
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
return 0;
}
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 3:04 ` Linus Torvalds
@ 2006-12-28 4:32 ` Gordon Farquharson
2006-12-28 4:53 ` Linus Torvalds
2006-12-28 5:55 ` Chen, Kenneth W
` (3 subsequent siblings)
4 siblings, 1 reply; 45+ messages in thread
From: Gordon Farquharson @ 2006-12-28 4:32 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On 12/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> [ Modified test-program that tells you where the corruption happens (and
> when the missing parts were supposed to be written out) appended, in
> case people care. ]
For the record, this is the output from a run on our ARM machine (32
MB RAM) with 2.6.18 + the following patches:
mm: tracking shared dirty pages
mm: balance dirty pages
mm: optimize the new mprotect() code a bit
mm: small cleanup of install_page()
mm: fixup do_wp_page()
mm: msync() cleanup
It is at all suprising that the second offset within a page can be
less than the first offset within a page ? e.g.
Chunk 260 corrupted (1-1455) (2769-127)
$ ./linus-test
Writing chunk 279/280 (99%)
Chunk 256 corrupted (1-1455) (1025-2479)
Expected 0, got 1
Written as (82)175(56)
Chunk 258 corrupted (1-1455) (3945-1303)
Expected 2, got 3
Written as (56)51(20)
Chunk 260 corrupted (1-1455) (2769-127)
Expected 4, got 5
Written as (20)30(18)
Chunk 262 corrupted (1-1455) (1593-3047)
Expected 6, got 7
Written as (18)196(158)
Chunk 264 corrupted (1-1455) (417-1871)
Expected 8, got 9
Written as (158)133(146)
Chunk 266 corrupted (1-1455) (3337-695)
Expected 10, got 11
Written as (146)43(77)
Chunk 268 corrupted (1-1455) (2161-3615)
Expected 12, got 13
Written as (77)251(211)
Chunk 270 corrupted (1-1455) (985-2439)
Expected 14, got 15
Written as (211)257(231)
Chunk 272 corrupted (1-1455) (3905-1263)
Expected 16, got 17
Written as (231)254(154)
Chunk 274 corrupted (1-1455) (2729-87)
Expected 18, got 19
Written as (154)11(85)
Chunk 276 corrupted (1-1455) (1553-3007)
Expected 20, got 21
Written as (85)230(134)
Chunk 278 corrupted (1-1455) (377-1831)
Expected 22, got 23
Written as (134)233(103)
Checking chunk 279/280 (99%)
Gordon
--
Gordon Farquharson
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 4:32 ` Gordon Farquharson
@ 2006-12-28 4:53 ` Linus Torvalds
2006-12-28 5:20 ` Gordon Farquharson
[not found] ` <97a0a9ac0612272115g4cce1f08n3c3c8498a6076bd5@mail.gmail.com>
0 siblings, 2 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 4:53 UTC (permalink / raw)
To: Gordon Farquharson
Cc: David Miller, ranma, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, 27 Dec 2006, Gordon Farquharson wrote:
>
> It is at all suprising that the second offset within a page can be
> less than the first offset within a page ? e.g.
>
> Chunk 260 corrupted (1-1455) (2769-127)
No, that just means that it went over to the next page (so you actually
had two consecutive pages that weren't written out).
That said, your output is very different from mine in another way. You
don't have zeroes in your pages, rather the thing seems to have data from
the next block (ie the chunk that should have 20 is reported as having 21
etc). You also have your offsets shifted up by one (ie offset 0 looks ok
for you, and then you have a strange pattern of corruption at bytes
1...1455 instead of 0..1459.
You also seem to have an example of the _earlier_ writes being corrupted,
rather than the later ones. For example (but it's also a page-crosser, so
maybe that's part of it):
Chunk 274 corrupted (1-1455) (2729-87)
Expected 18, got 19
Written as (154)11(85)
says that block chunk 274 is the corrupt one, but it was written fairly
early as #11, and the blocks around it (chunks 273 and 275) were actually
written later.
For all I know, my test-program is buggy wrt the ordering printouts,
though. Did you perhaps change the logic in any way?
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 4:53 ` Linus Torvalds
@ 2006-12-28 5:20 ` Gordon Farquharson
2006-12-28 5:41 ` David Miller
2006-12-28 10:13 ` Russell King
[not found] ` <97a0a9ac0612272115g4cce1f08n3c3c8498a6076bd5@mail.gmail.com>
1 sibling, 2 replies; 45+ messages in thread
From: Gordon Farquharson @ 2006-12-28 5:20 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
[Oops - forgot to hit "Reply to All" first time round.]
Hi Linus
On 12/27/06, Linus Torvalds <torvalds@osdl.org> wrote:
> For all I know, my test-program is buggy wrt the ordering printouts,
> though. Did you perhaps change the logic in any way?
I don't think so. I did reduce the target size
#define TARGETSIZE (100 << 12)
to make the program finish a little quicker, and for some reason I get
linus-test.c: In function 'remap':
linus-test.c:61: error: 'POSIX_FADV_DONTNEED' undeclared (first use in
this function)
when I compile the program, so I replaced POSIX_FADV_DONTNEED with 4
as defined in /usr/include/bits/fcntl.h.
Other than these two changes, the program is identical to the version
you posted.
I have run the program a few times, and the output is pretty
consistent. However, when I increase the target size, the difference
between the expected and actual values is larger.
Written as (749)935(738)
Chunk 1113 corrupted (1-1455) (2965-323)
Expected 89, got 93
Written as (935)738(538)
Chunk 1114 corrupted (1-1455) (329-1783)
Expected 90, got 94
Written as (738)538(678)
Chunk 1115 corrupted (1-1455) (1789-3243)
Expected 91, got 95
Written as (538)678(989)
Chunk 1120 corrupted (1-1455) (897-2351)
Expected 96, got 100
Written as (537)265(1005)
Chunk 1121 corrupted (1-1455) (2357-3811)
Expected 97, got 101
Written as (265)1005(-1)
--- linus-test.c.orig 2006-12-28 06:17:24.000000000 +0100
+++ linus-test.c 2006-12-28 06:18:24.000000000 +0100
@@ -6,7 +6,7 @@
#include <stdio.h>
#include <time.h>
-#define TARGETSIZE (100 << 20)
+#define TARGETSIZE (100 << 14)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
@@ -61,7 +61,7 @@
{
if (mapping) {
munmap(mapping, SIZE);
- posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
+ posix_fadvise(fd, 0, SIZE, 4);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
Gordon
--
Gordon Farquharson
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 5:20 ` Gordon Farquharson
@ 2006-12-28 5:41 ` David Miller
2006-12-28 5:47 ` Gordon Farquharson
2006-12-28 10:13 ` Russell King
1 sibling, 1 reply; 45+ messages in thread
From: David Miller @ 2006-12-28 5:41 UTC (permalink / raw)
To: gordonfarquharson
Cc: torvalds, ranma, tbm, a.p.zijlstra, andrei.popa, akpm, hugh,
nickpiggin, arjan, linux-kernel
From: "Gordon Farquharson" <gordonfarquharson@gmail.com>
Date: Wed, 27 Dec 2006 22:20:20 -0700
> and for some reason I get
>
> linus-test.c: In function 'remap':
> linus-test.c:61: error: 'POSIX_FADV_DONTNEED' undeclared (first use in
> this function)
>
> when I compile the program, so I replaced POSIX_FADV_DONTNEED with 4
> as defined in /usr/include/bits/fcntl.h.
Me too, I added "-D_POSIX_C_SOURCE=200112" to "fix" this.
Perhaps Linus's GCC sets that by default and our's doesn't.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 5:41 ` David Miller
@ 2006-12-28 5:47 ` Gordon Farquharson
0 siblings, 0 replies; 45+ messages in thread
From: Gordon Farquharson @ 2006-12-28 5:47 UTC (permalink / raw)
To: David Miller
Cc: torvalds, ranma, tbm, a.p.zijlstra, andrei.popa, akpm, hugh,
nickpiggin, arjan, linux-kernel
Hi David
On 12/27/06, David Miller <davem@davemloft.net> wrote:
> Me too, I added "-D_POSIX_C_SOURCE=200112" to "fix" this.
That works for me. Thanks for the tip.
Gordon
--
Gordon Farquharson
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 5:20 ` Gordon Farquharson
2006-12-28 5:41 ` David Miller
@ 2006-12-28 10:13 ` Russell King
2006-12-28 14:15 ` Gordon Farquharson
2006-12-28 17:27 ` Linus Torvalds
1 sibling, 2 replies; 45+ messages in thread
From: Russell King @ 2006-12-28 10:13 UTC (permalink / raw)
To: Gordon Farquharson
Cc: Linus Torvalds, David Miller, ranma, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, Dec 27, 2006 at 10:20:20PM -0700, Gordon Farquharson wrote:
> I have run the program a few times, and the output is pretty
> consistent. However, when I increase the target size, the difference
> between the expected and actual values is larger.
>
> Written as (749)935(738)
> Chunk 1113 corrupted (1-1455) (2965-323)
> Expected 89, got 93
This is not the corruption Linus is after. Note that the corruption starts
at offset '1'. Also note that:
89 = 1113 & 255
93 = 1113 & 255 | (1113 >> 8)
and if you look at glibc's memset() function, you'll notice that's exactly
what you expect if you pass a non-8bit value to it. Ergo, what you're
seeing is utterly expected given glibc's memset() implementation on ARM.
Fixing Linus' test program to pass nr & 255 to memset results in clean
passes on 2.6.9 on TheCus N2100 (IOP8032x) and 2.6.16.9 StrongARM
machines (as would be expected.)
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 10:13 ` Russell King
@ 2006-12-28 14:15 ` Gordon Farquharson
2006-12-28 15:53 ` Martin Michlmayr
2006-12-28 17:27 ` Linus Torvalds
1 sibling, 1 reply; 45+ messages in thread
From: Gordon Farquharson @ 2006-12-28 14:15 UTC (permalink / raw)
To: Gordon Farquharson, Linus Torvalds, David Miller, ranma, tbm,
Peter Zijlstra, andrei.popa, Andrew Morton, hugh, nickpiggin,
arjan, Linux Kernel Mailing List
On 12/28/06, Russell King <rmk+lkml@arm.linux.org.uk> wrote:
> Fixing Linus' test program to pass nr & 255 to memset results in clean
> passes on 2.6.9 on TheCus N2100 (IOP8032x) and 2.6.16.9 StrongARM
> machines (as would be expected.)
Thanks for the fix, Russell.
I can now trigger the (real) problem by using a 25 MB file (100 << 18)
and the Linksys NSLU2 (ARM, IXP420 processor, 32 MB RAM).
$ ./linus-test
Writing chunk 17954/17955 (99%)
Chunk 514 corrupted (0-1459) (872-2331)
Expected 2, got 0
Written as (8479)11160(10312)
Chunk 516 corrupted (0-303) (3792-4095)
Expected 4, got 0
Written as (10312)10569(4426)
Chunk 959 corrupted (0-691) (3404-4095)
Expected 191, got 0
Written as (687)4881(1522)
Chunk 1895 corrupted (0-1459) (1900-3359)
Expected 103, got 0
Written as (7746)8389(6231)
Chunk 2702 corrupted (0-1459) (472-1931)
Expected 142, got 0
Written as (4866)7103(2409)
Chunk 3314 corrupted (0-1459) (1064-2523)
Expected 242, got 0
Written as (4287)7064(1730)
Chunk 4043 corrupted (0-1459) (444-1903)
Expected 203, got 0
Written as (6495)8509(4464)
Chunk 5180 corrupted (0-1459) (1584-3043)
Expected 60, got 0
Written as (11056)12826(10797)
Chunk 5672 corrupted (0-991) (3104-4095)
Expected 40, got 0
Written as (9944)4872(41)
Chunk 5793 corrupted (460-1459) (0-999)
Expected 161, got 0
Written as (7059)5038(4377)
Chunk 6089 corrupted (0-1459) (1620-3079)
Expected 201, got 0
Written as (4672)5230(4403)
Chunk 6545 corrupted (268-1459) (0-1191)
Expected 145, got 0
Written as (3701)5969(4668)
Chunk 7578 corrupted (0-1459) (584-2043)
Expected 154, got 0
Written as (10015)5082(1648)
Chunk 7880 corrupted (864-1459) (0-595)
Expected 200, got 0
Written as (17869)5064(4745)
Chunk 8086 corrupted (0-1459) (888-2347)
Expected 150, got 0
Written as (10206)11050(10374)
Chunk 8749 corrupted (0-1459) (2212-3671)
Expected 45, got 0
Written as (15263)7132(4825)
Chunk 9068 corrupted (0-1459) (1008-2467)
Expected 108, got 0
Written as (5557)7571(6771)
Chunk 9193 corrupted (812-1459) (0-647)
Expected 233, got 0
Written as (9238)7277(4757)
Chunk 10032 corrupted (576-1459) (0-883)
Expected 48, got 0
Written as (15741)10012(1753)
Chunk 10056 corrupted (0-1459) (1696-3155)
Expected 72, got 0
Written as (5379)7431(262)
Chunk 10395 corrupted (0-1459) (1020-2479)
Expected 155, got 0
Written as (21)7442(5902)
Chunk 10791 corrupted (0-1459) (1644-3103)
Expected 39, got 0
Written as (4753)5925(5926)
Chunk 10792 corrupted (0-991) (3104-4095)
Expected 40, got 0
Written as (5925)5926(8555)
Chunk 11036 corrupted (0-1103) (2992-4095)
Expected 28, got 0
Written as (13755)14449(7458)
Chunk 11387 corrupted (644-1459) (0-815)
Expected 123, got 0
Written as (10853)11459(9445)
Chunk 11586 corrupted (920-1459) (0-539)
Expected 66, got 0
Written as (3769)11691(11123)
Chunk 11882 corrupted (0-1459) (1160-2619)
Expected 106, got 0
Written as (10736)11696(2788)
Chunk 12397 corrupted (0-603) (3492-4095)
Expected 109, got 0
Written as (2352)7515(2437)
Chunk 12669 corrupted (0-795) (3300-4095)
Expected 125, got 0
Written as (1191)7661(5266)
Chunk 13162 corrupted (0-1459) (2184-3643)
Expected 106, got 0
Written as (9383)13662(11544)
Chunk 14653 corrupted (0-27) (4068-4095)
Expected 61, got 0
Written as (8100)9456(1275)
Chunk 17332 corrupted (0-367) (3728-4095)
Expected 180, got 0
Written as (760)12247(1244)
Chunk 17445 corrupted (0-1459) (772-2231)
Expected 37, got 0
Written as (8007)16481(14439)
Chunk 17556 corrupted (0-1007) (3088-4095)
Expected 148, got 0
Written as (10113)10657(10477)
Chunk 17859 corrupted (0-995) (3100-4095)
Expected 195, got 0
Written as (14472)14767(11426)
Checking chunk 17954/17955 (99%)
Gordon
--
Gordon Farquharson
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 14:15 ` Gordon Farquharson
@ 2006-12-28 15:53 ` Martin Michlmayr
0 siblings, 0 replies; 45+ messages in thread
From: Martin Michlmayr @ 2006-12-28 15:53 UTC (permalink / raw)
To: Gordon Farquharson
Cc: Linus Torvalds, David Miller, ranma, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
* Gordon Farquharson <gordonfarquharson@gmail.com> [2006-12-28 07:15]:
> Thanks for the fix, Russell.
>
> I can now trigger the (real) problem by using a 25 MB file (100 << 18)
> and the Linksys NSLU2 (ARM, IXP420 processor, 32 MB RAM).
Me too (using 100 << 18). Interestingly, I don't seem to get any
corruption on a different ARM board, an IOP32x based machine with 128
MB RAM.
--
Martin Michlmayr
http://www.cyrius.com/
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 10:13 ` Russell King
2006-12-28 14:15 ` Gordon Farquharson
@ 2006-12-28 17:27 ` Linus Torvalds
2006-12-28 18:44 ` Russell King
1 sibling, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 17:27 UTC (permalink / raw)
To: Russell King
Cc: Gordon Farquharson, David Miller, ranma, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Thu, 28 Dec 2006, Russell King wrote:
>
> and if you look at glibc's memset() function, you'll notice that's exactly
> what you expect if you pass a non-8bit value to it. Ergo, what you're
> seeing is utterly expected given glibc's memset() implementation on ARM.
Guys, you _really_ should fix memset(). What you describe is a _bug_.
"memset()" takes an "int" as its argument (always has), and has to convert
it to a byte _itself_. It may not be common, but it's perfectly normal, to
pass it values outside 0-255 (negative values that still fit in a "signed
char" in particular are very normal, but my usage of "let the thing
truncate it itself" is also quite fine).
> Fixing Linus' test program to pass nr & 255 to memset
No. I'm almost certain that that is not a "fix", it's a workaround for a
serious bug in your glibc crap.
But it does explain all the unexpected strange behaviour (and the really
small writeback size - now it doesn't need any /proc/sys/vm/dirty_ratio
assumptions to be explicable.
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 17:27 ` Linus Torvalds
@ 2006-12-28 18:44 ` Russell King
2006-12-28 19:01 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: Russell King @ 2006-12-28 18:44 UTC (permalink / raw)
To: Linus Torvalds
Cc: Gordon Farquharson, David Miller, ranma, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Thu, Dec 28, 2006 at 09:27:12AM -0800, Linus Torvalds wrote:
> On Thu, 28 Dec 2006, Russell King wrote:
> > and if you look at glibc's memset() function, you'll notice that's exactly
> > what you expect if you pass a non-8bit value to it. Ergo, what you're
> > seeing is utterly expected given glibc's memset() implementation on ARM.
>
> Guys, you _really_ should fix memset(). What you describe is a _bug_.
Yup, but I have nothing to do with glibc because I refuse to do that
silly copyright assignment FSF thing. Hopefully someone else can
resolve it, but...
> > Fixing Linus' test program to pass nr & 255 to memset
>
> No. I'm almost certain that that is not a "fix", it's a workaround for a
> serious bug in your glibc crap.
_is_ a fix whether _you_ like it or not to work around the issue so
people can at least run your test program. I'm not saying it's a
proper fix though.
Of course, if you prefer to be mislead by incorrect bug reports...
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 18:44 ` Russell King
@ 2006-12-28 19:01 ` Linus Torvalds
0 siblings, 0 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 19:01 UTC (permalink / raw)
To: Russell King
Cc: Gordon Farquharson, David Miller, ranma, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Thu, 28 Dec 2006, Russell King wrote:
>
> Yup, but I have nothing to do with glibc because I refuse to do that
> silly copyright assignment FSF thing. Hopefully someone else can
> resolve it, but...
Yeah, me too.
> _is_ a fix whether _you_ like it or not to work around the issue so
> people can at least run your test program. I'm not saying it's a
> proper fix though.
My point was that it wasn't a "fix", it's a "workaround". The _fix_ would
be in glibc.
Nothing more..
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
[parent not found: <97a0a9ac0612272115g4cce1f08n3c3c8498a6076bd5@mail.gmail.com>]
* RE: [PATCH] mm: fix page_mkclean_one
2006-12-28 3:04 ` Linus Torvalds
2006-12-28 4:32 ` Gordon Farquharson
@ 2006-12-28 5:55 ` Chen, Kenneth W
2006-12-28 6:10 ` Chen, Kenneth W
2006-12-28 9:15 ` Zhang, Yanmin
` (2 subsequent siblings)
4 siblings, 1 reply; 45+ messages in thread
From: Chen, Kenneth W @ 2006-12-28 5:55 UTC (permalink / raw)
To: 'Linus Torvalds', David Miller
Cc: ranma, gordonfarquharson, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM
> On Wed, 27 Dec 2006, David Miller wrote:
> > >
> > > I still don't see _why_, though. But maybe smarter people than me can see
> > > it..
> >
> > FWIW this program definitely triggers the bug for me.
>
> Ok, now that I have something simple to do repeatable stuff with, I can
> say what the pattern is.. It's not all that surprising, but it's still
> worth just stating for the record.
Running the test code, git bisect points its finger at this commit. Reverting
this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code.
edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit
commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
Date: Mon Sep 25 23:30:58 2006 -0700
[PATCH] mm: balance dirty pages
Now that we can detect writers of shared mappings, throttle them. Avoids OOM
by surprise.
Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Hugh Dickins <hugh@veritas.com>
Signed-off-by: Andrew Morton <akpm@osdl.org>
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: [PATCH] mm: fix page_mkclean_one
2006-12-28 5:55 ` Chen, Kenneth W
@ 2006-12-28 6:10 ` Chen, Kenneth W
2006-12-28 6:27 ` David Miller
2006-12-28 17:10 ` Linus Torvalds
0 siblings, 2 replies; 45+ messages in thread
From: Chen, Kenneth W @ 2006-12-28 6:10 UTC (permalink / raw)
To: 'Linus Torvalds', David Miller
Cc: ranma, gordonfarquharson, tbm, Peter Zijlstra, andrei.popa,
Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
Chen, Kenneth wrote on Wednesday, December 27, 2006 9:55 PM
> Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM
> > On Wed, 27 Dec 2006, David Miller wrote:
> > > >
> > > > I still don't see _why_, though. But maybe smarter people than me can see
> > > > it..
> > >
> > > FWIW this program definitely triggers the bug for me.
> >
> > Ok, now that I have something simple to do repeatable stuff with, I can
> > say what the pattern is.. It's not all that surprising, but it's still
> > worth just stating for the record.
>
>
> Running the test code, git bisect points its finger at this commit. Reverting
> this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code.
>
> edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit
> commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
> Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> Date: Mon Sep 25 23:30:58 2006 -0700
>
> [PATCH] mm: balance dirty pages
>
> Now that we can detect writers of shared mappings, throttle them. Avoids OOM
> by surprise.
Oh, never mind :-( I just didn't create enough write out pressure when
test this. I just saw bug got triggered on a kernel I previously thought
was OK.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 6:10 ` Chen, Kenneth W
@ 2006-12-28 6:27 ` David Miller
2006-12-28 17:10 ` Linus Torvalds
1 sibling, 0 replies; 45+ messages in thread
From: David Miller @ 2006-12-28 6:27 UTC (permalink / raw)
To: kenneth.w.chen
Cc: torvalds, ranma, gordonfarquharson, tbm, a.p.zijlstra,
andrei.popa, akpm, hugh, nickpiggin, arjan, linux-kernel
From: "Chen, Kenneth W" <kenneth.w.chen@intel.com>
Date: Wed, 27 Dec 2006 22:10:52 -0800
> Chen, Kenneth wrote on Wednesday, December 27, 2006 9:55 PM
> > Linus Torvalds wrote on Wednesday, December 27, 2006 7:05 PM
> > > On Wed, 27 Dec 2006, David Miller wrote:
> > > > >
> > > > > I still don't see _why_, though. But maybe smarter people than me can see
> > > > > it..
> > > >
> > > > FWIW this program definitely triggers the bug for me.
> > >
> > > Ok, now that I have something simple to do repeatable stuff with, I can
> > > say what the pattern is.. It's not all that surprising, but it's still
> > > worth just stating for the record.
> >
> >
> > Running the test code, git bisect points its finger at this commit. Reverting
> > this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code.
> >
> > edc79b2a46ed854595e40edcf3f8b37f9f14aa3f is first bad commit
> > commit edc79b2a46ed854595e40edcf3f8b37f9f14aa3f
> > Author: Peter Zijlstra <a.p.zijlstra@chello.nl>
> > Date: Mon Sep 25 23:30:58 2006 -0700
> >
> > [PATCH] mm: balance dirty pages
> >
> > Now that we can detect writers of shared mappings, throttle them. Avoids OOM
> > by surprise.
>
>
> Oh, never mind :-( I just didn't create enough write out pressure when
> test this. I just saw bug got triggered on a kernel I previously thought
> was OK.
Besides, I'm pretty sure that from the Debian bug entry it's been
established that the dirty-page tracking changes from a few releases
ago introduced this problem.
^ permalink raw reply [flat|nested] 45+ messages in thread
* RE: [PATCH] mm: fix page_mkclean_one
2006-12-28 6:10 ` Chen, Kenneth W
2006-12-28 6:27 ` David Miller
@ 2006-12-28 17:10 ` Linus Torvalds
1 sibling, 0 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 17:10 UTC (permalink / raw)
To: Chen, Kenneth W
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, 27 Dec 2006, Chen, Kenneth W wrote:
> >
> > Running the test code, git bisect points its finger at this commit. Reverting
> > this commit on top of 2.6.20-rc2 doesn't trigger the bug from the test code.
> >
> > [PATCH] mm: balance dirty pages
> >
> > Now that we can detect writers of shared mappings, throttle them. Avoids OOM
> > by surprise.
>
> Oh, never mind :-( I just didn't create enough write out pressure when
> test this. I just saw bug got triggered on a kernel I previously thought
> was OK.
Btw, this is an important point - people have long felt that the new page
balancing in 2.6.19 was to blame, but you've just confirmed the long-held
suspicion (at least by me) that it's not actually a new bug at all, it's
just that the dirty page balancing causes writeback to happen _earlier_,
and thus is better able to _show_ a bug that we've likely had for a long
long time.
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 3:04 ` Linus Torvalds
2006-12-28 4:32 ` Gordon Farquharson
2006-12-28 5:55 ` Chen, Kenneth W
@ 2006-12-28 9:15 ` Zhang, Yanmin
2006-12-28 17:15 ` Linus Torvalds
2006-12-28 11:50 ` Petri Kaukasoina
2006-12-28 15:09 ` Guillaume Chazarain
4 siblings, 1 reply; 45+ messages in thread
From: Zhang, Yanmin @ 2006-12-28 9:15 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, 2006-12-27 at 19:04 -0800, Linus Torvalds wrote:
>
> On Wed, 27 Dec 2006, David Miller wrote:
> > >
> > > I still don't see _why_, though. But maybe smarter people than me can see
> > > it..
> >
> > FWIW this program definitely triggers the bug for me.
>
> Ok, now that I have something simple to do repeatable stuff with, I can
> say what the pattern is.. It's not all that surprising, but it's still
> worth just stating for the record.
>
> What happens is that when I do the "packetized writes" in random order,
> the _last_ write to a page occasionally just goes missing. It's not always
> at the end of a page, as shown by for example:
>
> - A whole chunk got dropped:
>
> Chunk 2094 corrupted (0-1459) (1624-3083)
> Expected 46, got 0
> Written as (30912)55414(10000)
>
> That "Written as (x)y(z)" line means that the corrupted chunk was
> written as chunk #y, and the preceding and following chunks (that were
> _not_ corrupt) on the page was written as #x and #z respectively.
>
> In other words, the missing chunk (which is still zero) was written
> much later than the ones that were ok, and never hit the disk. It's a
> contiguous chunk in the middle of the page (chunks are 1460 bytes in
> size)
>
> The first line means that all bytes of the chunk (0-1459) were
> corrupted, and the values in parenthesis are the offsets within a page.
> In other words, this was a chunk in the _middle_ of a page.
>
> - The missing data can also be at the beginning or ends of pages:
>
> Beginning of the chunk missing, it was at the end of a page (page
> offsets 3288-4095) and the _next_ page got written out fine:
>
> Chunk 2126 corrupted (0-807) (3288-4095)
> Expected 78, got 0
> Written as (32713)55573(14301)
>
> End of a chunk missing, it was the beginning of a page (and the
> _previous_ page that contained the beginning of the chunk was written
> out fine)
>
> Chunk 2179 corrupted (1252-1459) (0-207)
> Expected 131, got 0
> Written as (45189)55489(15515)
>
> Now, the reason I say this isn't surprising is that this is entirely
> consistent with the dirty bit being dropped on the floor somewhere, and
> likely through some interaction with the previous changes being in the
> process of being written out.
>
> Something (incorrectly) ends up deciding that it doesn't need to write the
> page, since it's already written, or alternatively clears the dirty bit
> too late (clears it because an _earlier_ write finished, never mind that
> the new dirty data didn't make it).
There might be a narrow race between set_page_dirty and clear_page_dirty.
The test program is a process to write/read data. pdflush might write data
to disk asynchronously. After pdflush writes a page to disk, it will call (either by
softirq) clear_page_dirty to clear the dirty bit after getting the interrupt
notification. But just after the page is written to disk and before the interrupt
reports the result, the test process might change the data and unmap the area. When
the area is unmapped, the page is marked as dirty again, but just after that, the
interrupt arrives and the dirty bit is cleared, so the late data will not be written
to disk.
Function zap_pte_range checks pte to set page dirty if needed, but it doesn't
hold page lock. If the page lock is held before set page dirty, the race might
be avoided.
Yanmin
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 9:15 ` Zhang, Yanmin
@ 2006-12-28 17:15 ` Linus Torvalds
0 siblings, 0 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 17:15 UTC (permalink / raw)
To: Zhang, Yanmin
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Thu, 28 Dec 2006, Zhang, Yanmin wrote:
>
> The test program is a process to write/read data. pdflush might write data
> to disk asynchronously. After pdflush writes a page to disk, it will call (either by
> softirq) clear_page_dirty to clear the dirty bit after getting the interrupt
> notification.
That would indeed be a horrible bug. However, we don't do
"clear_page_dirty()" _after_ the IO has completed, we do it _before_ the
IO starts.
If you can actually find a place that does clear_page_dirty _after_ IO,
then yes, you've just found the bug. But I haven't found it.
So the rule is _always_:
- call "clear_page_dirty_for_io()" with the page lock held, and _before_
the IO starts.
- do "set_page_writeback()" before unlocking the page again
- do a "end_page_writeback()" when the IO actually finishes.
and any code sequence that doesn't honor those rules would be buggy. A
beer for anybody that finds it..
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 3:04 ` Linus Torvalds
` (2 preceding siblings ...)
2006-12-28 9:15 ` Zhang, Yanmin
@ 2006-12-28 11:50 ` Petri Kaukasoina
2006-12-28 15:09 ` Guillaume Chazarain
4 siblings, 0 replies; 45+ messages in thread
From: Petri Kaukasoina @ 2006-12-28 11:50 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
On Wed, Dec 27, 2006 at 07:04:34PM -0800, Linus Torvalds wrote:
> [ Modified test-program that tells you where the corruption happens (and
> when the missing parts were supposed to be written out) appended, in
> case people care. ]
Hi
2.6.18 (and 2.6.18.6) is ok, 2.6.19-rc1 is broken. I tried some snapshots
between them but they hung before shell (2.6.18-git11, 2.6.18-git16,
2.6.18-git20, 2.6.18-git21). 2.6.18-git22 booted and was broken.
(UP, no preempt)
-Petri
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 3:04 ` Linus Torvalds
` (3 preceding siblings ...)
2006-12-28 11:50 ` Petri Kaukasoina
@ 2006-12-28 15:09 ` Guillaume Chazarain
2006-12-28 19:19 ` Guillaume Chazarain
4 siblings, 1 reply; 45+ messages in thread
From: Guillaume Chazarain @ 2006-12-28 15:09 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List
I set a qemu environment to test kernels: http://guichaz.free.fr/linux-bug/
I have corruption with every Fedora release kernel except the first, that is
2.4.22 works, but 2.6.5, 2.6.9, 2.6.11, 2.6.15 and 2.6.18-1.2798 exhibit
some
corruption.
Command line to test:
qemu root_fs -snapshot -kernel FC-kernels/FC2-vmlinuz-2.6.5-1.358 -append 'rw root=/dev/hda'
I get this kind of corruption:
http://guichaz.free.fr/linux-bug/corruption.png
--
Guillaume
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 15:09 ` Guillaume Chazarain
@ 2006-12-28 19:19 ` Guillaume Chazarain
2006-12-28 19:28 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: Guillaume Chazarain @ 2006-12-28 19:19 UTC (permalink / raw)
To: Linus Torvalds
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List, Chen Kenneth W
[-- Attachment #1: Type: text/plain, Size: 625 bytes --]
Guillaume Chazarain a écrit :
> I get this kind of corruption:
> http://guichaz.free.fr/linux-bug/corruption.png
Actually in qemu, I get three different behaviours:
- no corruption at all : with linux-2.4
- corruption only on the first chunks: before [PATCH] mm: balance dirty
pages as identified by Kenneth
- corruption of all chunks: after the balance dirty pages patch
Bisecting in linux-2.5 land I found
http://kernel.org/pub/linux/kernel/people/akpm/patches/2.5/2.5.66/2.5.66-mm3/broken-out/fadvise-flush-data.patch
to cause the corruption for me.
The attached patch fixes the corruption for me.
--
Guillaume
[-- Attachment #2: fadvise-dontneed.patch --]
[-- Type: text/x-patch, Size: 492 bytes --]
diff -r 3859b1144d3a mm/fadvise.c
--- a/mm/fadvise.c Sun Dec 24 05:00:03 2006 +0000
+++ b/mm/fadvise.c Thu Dec 28 19:53:40 2006 +0100
@@ -96,9 +96,6 @@ asmlinkage long sys_fadvise64_64(int fd,
case POSIX_FADV_NOREUSE:
break;
case POSIX_FADV_DONTNEED:
- if (!bdi_write_congested(mapping->backing_dev_info))
- filemap_flush(mapping);
-
/* First and last FULL page! */
start_index = (offset+(PAGE_CACHE_SIZE-1)) >> PAGE_CACHE_SHIFT;
end_index = (endbyte >> PAGE_CACHE_SHIFT);
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 19:19 ` Guillaume Chazarain
@ 2006-12-28 19:28 ` Linus Torvalds
2006-12-28 19:45 ` Andrew Morton
0 siblings, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 19:28 UTC (permalink / raw)
To: Guillaume Chazarain
Cc: David Miller, ranma, gordonfarquharson, tbm, Peter Zijlstra,
andrei.popa, Andrew Morton, hugh, nickpiggin, arjan,
Linux Kernel Mailing List, Chen Kenneth W
On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
>
> The attached patch fixes the corruption for me.
Well, that's a good hint, but it's really just a symptom. You effectively
just made the test-program not even try to flush the data to disk, so the
page cache would stay in memory, and you'd not see the corruption as well.
So you basically disabled the code that tried to trigger the bug more
easily.
But the reason I say it's interesting is that "WB_SYNC_NONE" is very much
implicated in mm/page-writeback.c, and if there is a bug triggered by
WB_SYNC_NONE writebacks, then that would explain why page-writeback.c also
fails..
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 19:28 ` Linus Torvalds
@ 2006-12-28 19:45 ` Andrew Morton
2006-12-28 20:14 ` Linus Torvalds
2006-12-28 22:35 ` Mike Galbraith
0 siblings, 2 replies; 45+ messages in thread
From: Andrew Morton @ 2006-12-28 19:45 UTC (permalink / raw)
To: Linus Torvalds
Cc: Guillaume Chazarain, David Miller, ranma, gordonfarquharson, tbm,
Peter Zijlstra, andrei.popa, hugh, nickpiggin, arjan,
Linux Kernel Mailing List, Chen Kenneth W
On Thu, 28 Dec 2006 11:28:52 -0800 (PST)
Linus Torvalds <torvalds@osdl.org> wrote:
>
>
> On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
> >
> > The attached patch fixes the corruption for me.
>
> Well, that's a good hint, but it's really just a symptom. You effectively
> just made the test-program not even try to flush the data to disk, so the
> page cache would stay in memory, and you'd not see the corruption as well.
>
> So you basically disabled the code that tried to trigger the bug more
> easily.
>
> But the reason I say it's interesting is that "WB_SYNC_NONE" is very much
> implicated in mm/page-writeback.c, and if there is a bug triggered by
> WB_SYNC_NONE writebacks, then that would explain why page-writeback.c also
> fails..
>
It would be interesting to convert your app to do fsync() before
FADV_DONTNEED. That would take WB_SYNC_NONE out of the picture as well
(apart from pdflush activity).
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 19:45 ` Andrew Morton
@ 2006-12-28 20:14 ` Linus Torvalds
2006-12-28 22:38 ` David Miller
2006-12-28 22:35 ` Mike Galbraith
1 sibling, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 20:14 UTC (permalink / raw)
To: Andrew Morton
Cc: Guillaume Chazarain, David Miller, ranma, gordonfarquharson, tbm,
Peter Zijlstra, andrei.popa, hugh, nickpiggin, arjan,
Linux Kernel Mailing List, Chen Kenneth W
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2468 bytes --]
On Thu, 28 Dec 2006, Andrew Morton wrote:
>
> It would be interesting to convert your app to do fsync() before
> FADV_DONTNEED. That would take WB_SYNC_NONE out of the picture as well
> (apart from pdflush activity).
I get corruption - but the whole point is that it's very much pdflush that
should be writing these pages out.
Andrew - give my test-program a try. It can run in about 1 minute if you
have a 256MB machine (I didn't, but "mem=256M" is my friend), and it seems
to very consistently cause corruption.
What I do is:
# Make sure we write back aggressively
echo 5 > /proc/sys/vm/dirty_ratio
as root, and then just run the thing. Tons of corruption. But the
corruption goes away if I just leave the default dirty ratio alone (but
then I can increse the file size to trigger it, of course - but that
also makes the test run a lot slower).
Now, with a pre-2.6.19 kernel, I bet you won't get the corruption as
easily (at least with the "fsync()"), but that's less to do with anything
new, and probably just because then you simply won't have any pdflushing
going on - since the kernel won't even notice that you have tons of dirty
pages ;)
It might also depend on the speed of your disk drive - the machine I test
this on has a slow 4200 rpm laptop drive in it, and that probably makes
things go south more easily. That's _especially_ true if this is related
to any "bdi_write_congested()" logic.
Now, it could also be related to various code snippets like
...
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page) ||
!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
...
where the WB_SYNC_NONE case will hit the "PageWriteback()" and just not do
the writeback at all (but it also won't clear the dirty bit, so it's
certainly not an *OBVIOUS* bug).
We also have code like this ("pageout()"):
if (clear_page_dirty_for_io(page)) {
int res;
struct writeback_control wbc = {
.sync_mode = WB_SYNC_NONE,
..
}
...
res = mapping->a_ops->writepage(page, &wbc);
and in this case, if the "WB_SYNC_NONE" means that the "writepage()" call
won't do anything at all because of congestion, then that would be a _bad_
thing, and would certainly explain how something didn't get written out.
But that particular path should only trigger for the "shrink_page_list()"
case, and it's not the case I seem to be testing with my "low dirty_ratio"
testing.
Linus
[-- Attachment #2: Type: TEXT/PLAIN, Size: 2872 bytes --]
#include <sys/mman.h>
#include <sys/fcntl.h>
#include <unistd.h>
#include <stdlib.h>
#include <string.h>
#include <stdio.h>
#include <time.h>
#define TARGETSIZE (22 << 20)
#define CHUNKSIZE (1460)
#define NRCHUNKS (TARGETSIZE / CHUNKSIZE)
#define SIZE (NRCHUNKS * CHUNKSIZE)
static void fillmem(void *start, int nr)
{
memset(start, nr, CHUNKSIZE);
}
#define page_offset(buf, off) (unsigned)((unsigned long)(buf)+(off)-(unsigned long)(mapping))
static int chunkorder[NRCHUNKS];
static char *mapping;
static int order(int nr)
{
int i;
if (nr < 0 || nr >= NRCHUNKS)
return -1;
for (i = 0; i < NRCHUNKS; i++)
if (chunkorder[i] == nr)
return i;
return -2;
}
static void checkmem(void *buf, int nr)
{
unsigned int start = ~0u, end = 0;
unsigned char c = nr, *p = buf, differs = 0;
int i;
for (i = 0; i < CHUNKSIZE; i++) {
unsigned char got = *p++;
if (got != c) {
if (i < start)
start = i;
if (i > end)
end = i;
differs = got;
}
}
if (start < end) {
printf("Chunk %d corrupted (%u-%u) (%x-%x) \n", nr, start, end,
page_offset(buf, start), page_offset(buf, end));
printf("Expected %u, got %u\n", c, differs);
printf("Written as (%d)%d(%d)\n", order(nr-1), order(nr), order(nr+1));
}
}
static char *remap(int fd, char *mapping)
{
if (mapping) {
munmap(mapping, SIZE);
// fsync(fd);
posix_fadvise(fd, 0, SIZE, POSIX_FADV_DONTNEED);
}
return mmap(NULL, SIZE, PROT_READ | PROT_WRITE, MAP_SHARED, fd, 0);
}
int main(int argc, char **argv)
{
int fd, i;
/*
* Make some random ordering of writing the chunks to the
* memory map..
*
* Start with fully ordered..
*/
for (i = 0; i < NRCHUNKS; i++)
chunkorder[i] = i;
/* ..and then mix it up randomly */
srandom(time(NULL));
for (i = 0; i < NRCHUNKS; i++) {
int index = (unsigned int) random() % NRCHUNKS;
int nr = chunkorder[index];
chunkorder[index] = chunkorder[i];
chunkorder[i] = nr;
}
fd = open("mapfile", O_RDWR | O_TRUNC | O_CREAT, 0666);
if (fd < 0)
return -1;
if (ftruncate(fd, SIZE) < 0)
return -1;
mapping = remap(fd, NULL);
if (-1 == (int)(long)mapping)
return -1;
for (i = 0; i < NRCHUNKS; i++) {
int chunk = chunkorder[i];
printf("Writing chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
fillmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
/* Unmap, drop, and remap.. */
mapping = remap(fd, mapping);
/* .. and check */
for (i = 0; i < NRCHUNKS; i++) {
int chunk = i;
printf("Checking chunk %d/%d (%d%%) \r", i, NRCHUNKS, 100*i/NRCHUNKS);
checkmem(mapping + chunk * CHUNKSIZE, chunk);
}
printf("\n");
/* Clean up for next time */
sleep(5);
sync();
sleep(5);
munmap(mapping, SIZE);
close(fd);
unlink("mapfile");
return 0;
}
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 20:14 ` Linus Torvalds
@ 2006-12-28 22:38 ` David Miller
2006-12-29 2:50 ` Segher Boessenkool
0 siblings, 1 reply; 45+ messages in thread
From: David Miller @ 2006-12-28 22:38 UTC (permalink / raw)
To: torvalds
Cc: akpm, guichaz, ranma, gordonfarquharson, tbm, a.p.zijlstra,
andrei.popa, hugh, nickpiggin, arjan, linux-kernel,
kenneth.w.chen
From: Linus Torvalds <torvalds@osdl.org>
Date: Thu, 28 Dec 2006 12:14:31 -0800 (PST)
> I get corruption - but the whole point is that it's very much pdflush that
> should be writing these pages out.
I think what might be happening is that pdflush writes them out fine,
however we don't trap writes by the application _during_ that writeout.
These corruptions look exactly as if:
1) pdflush begins writeback of page X
2) page goes to disk
3) application writes a chunk to the page
4) pdflush et al. think the page is clean, so it gets tossed, losing
the writes done in #3
So there's a missing PTE change in there, so that we never get proper
re-dirtying of the page if the application tries to write to the page
during the writeback.
It's something that will only occur with writeback and MAP_SHARED
writable access to the file pages. That's why we never see this
with normal filesystem writes, since those explicitly manage the
page dirty state.
I think the dirty balancing logic etc. isn't where the problems are,
to me it's a PTE state update issue for sure.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 22:38 ` David Miller
@ 2006-12-29 2:50 ` Segher Boessenkool
2006-12-29 6:48 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: Segher Boessenkool @ 2006-12-29 2:50 UTC (permalink / raw)
To: David Miller
Cc: nickpiggin, kenneth.w.chen, guichaz, hugh, linux-kernel, ranma,
torvalds, gordonfarquharson, akpm, a.p.zijlstra, tbm, arjan,
andrei.popa
> I think what might be happening is that pdflush writes them out fine,
> however we don't trap writes by the application _during_ that writeout.
Yeah. I believe that more exactly it happens if the very last
write to the page causes a writeback (due to dirty balancing)
while another writeback for the page is already happening.
As usual in these cases, I have zero proof.
> It's something that will only occur with writeback and MAP_SHARED
> writable access to the file pages.
It's the do_wp_page -> balance_dirty_pages -> generic_writepages
path for sure. Maybe it's enough to change
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page) ||
!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
to
if (wbc->sync_mode != WB_SYNC_NONE)
wait_on_page_writeback(page);
if (PageWriteback(page)) {
redirty_page_for_writepage(wbc, page);
unlock_page(page);
continue;
}
if (!clear_page_dirty_for_io(page)) {
unlock_page(page);
continue;
}
or something along those lines. Completely untested of course :-)
Segher
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-29 2:50 ` Segher Boessenkool
@ 2006-12-29 6:48 ` Linus Torvalds
0 siblings, 0 replies; 45+ messages in thread
From: Linus Torvalds @ 2006-12-29 6:48 UTC (permalink / raw)
To: Segher Boessenkool
Cc: David Miller, nickpiggin, kenneth.w.chen, guichaz, hugh,
linux-kernel, ranma, gordonfarquharson, akpm, a.p.zijlstra, tbm,
arjan, andrei.popa
On Fri, 29 Dec 2006, Segher Boessenkool wrote:
>
> > I think what might be happening is that pdflush writes them out fine,
> > however we don't trap writes by the application _during_ that writeout.
>
> Yeah. I believe that more exactly it happens if the very last
> write to the page causes a writeback (due to dirty balancing)
> while another writeback for the page is already happening.
>
> As usual in these cases, I have zero proof.
I actually have proof to the contrary, ie I have traces that say "the
write was started" after the last write.
And the VM layer in this area is actually fairly sane and civilized. It
has a bit that says "writeback in progress", and if that bit is set, it
simply _will_not_ start a new write. It even has various BUG_ON()'s to
that effect.
So everything I have ever seen says that the VM layer is actually doing
everything right.
> It's the do_wp_page -> balance_dirty_pages -> generic_writepages
> path for sure. Maybe it's enough to change
>
> if (wbc->sync_mode != WB_SYNC_NONE)
> wait_on_page_writeback(page);
>
> if (PageWriteback(page) ||
> !clear_page_dirty_for_io(page)) {
> unlock_page(page);
> continue;
> }
Notive how this one basically says:
- if it's under writeback, don't even clear the page dirty flag.
Your suggested change:
> if (wbc->sync_mode != WB_SYNC_NONE)
> wait_on_page_writeback(page);
>
> if (PageWriteback(page)) {
> redirty_page_for_writepage(wbc, page);
makes no sense, because we simply never _did_ the "clear_page_dirty()" if
the thing was under writeback in the first place. That's how C
conditionals work. So there's no reason to "redirty" it, because it
wasn't cleaned in the first place.
I've double- and triple-checked the dirty bits, including having traces
that actually say that the IO was started (from a VM perspective) _after_
the last write was done. The IO just didn't hit the disk.
I'm personally fairly convinced that it's not a VM issue, but a "IO
issue". Either in a low-level filesystem or in some of the fs/buffer.c
helper routines.
But I'd love to be proven wrong.
I do have a few interesting details from the trace I haven't really
analyzed yet. Here's the trace for events on one of the pages that was
corrupted. Note how the events are numbered (there were 171640 events
total), so the thing you see is just a small set of events from the whole
big trace, but it's the ones that talk about _that_ particular page.
I've grouped them so hat "consecutive" events group together. That just
means that no events on any other pages happened in between those events,
and it is usually a sign that it's really one single call-chain that
causes all the events.
For example, for the first group of three events (44366-44368), it's the
page fault that brings in the page, and since it's a write-fault, it will
not only map the page, it will mark the page itself dirty and then also
set the TAG_DIRTY on the mapping. So the "group" is just really a result
of one single event happening, which causes several things to happen to
that page. That's exactly what you'd expect.
Anyway, here is the list of events that page went through:
44366 PG 00000f6d: mm/memory.c:2254 mapping at b789fc54 (write)
44367 PG 00000f6d: mm/page-writeback.c:817 setting dirty
44368 PG 00000f6d: fs/buffer.c:738 setting TAG_DIRTY
64231 PG 00000f6d: mm/page-writeback.c:872 clean_for_io
64232 PG 00000f6d: mm/rmap.c:451 cleaning PTE b789f000
64233 PG 00000f6d: mm/page-writeback.c:914 set writeback
64234 PG 00000f6d: mm/page-writeback.c:916 setting TAG_WRITEBACK
64235 PG 00000f6d: mm/page-writeback.c:922 clearing TAG_DIRTY
67570 PG 00000f6d: mm/page-writeback.c:891 end writeback
67571 PG 00000f6d: mm/page-writeback.c:893 clearing TAG_WRITEBACK
76705 PG 00000f6d: mm/page-writeback.c:817 setting dirty
76706 PG 00000f6d: fs/buffer.c:725 dirtied buffers
76707 PG 00000f6d: fs/buffer.c:738 setting TAG_DIRTY
105267 PG 00000f6d: mm/page-writeback.c:872 clean_for_io
105268 PG 00000f6d: mm/rmap.c:451 cleaning PTE b789f000
105269 PG 00000f6d: mm/page-writeback.c:914 set writeback
105270 PG 00000f6d: mm/page-writeback.c:916 setting TAG_WRITEBACK
105271 PG 00000f6d: mm/page-writeback.c:922 clearing TAG_DIRTY
105272 PG 00000f6d: mm/page-writeback.c:891 end writeback
105273 PG 00000f6d: mm/page-writeback.c:893 clearing TAG_WRITEBACK
128032 PG 00000f6d: mm/memory.c:670 unmapped at b789f000
132662 PG 00000f6d: mm/filemap.c:119 Removing page cache
148278 PG 00000f6d: mm/memory.c:2254 mapping at b789f000 (read)
166326 PG 00000f6d: mm/memory.c:670 unmapped at b789f000
171958 PG 00000f6d: mm/filemap.c:119 Removing page cache
And notice that big grouping of seven events (105267-105273). The five
first events really _do_ make sense together: it's our page cleaning that
happens. But notice how the "end writeback" happens _immediately_.
Here's another page cleaning event for the page that preceded that page,
and did _not_ get corrupted:
105262 PG 00000f6c: mm/page-writeback.c:872 clean_for_io
105263 PG 00000f6c: mm/rmap.c:451 cleaning PTE b789e000
105264 PG 00000f6c: mm/page-writeback.c:914 set writeback
105265 PG 00000f6c: mm/page-writeback.c:916 setting TAG_WRITEBACK
105266 PG 00000f6c: mm/page-writeback.c:922 clearing TAG_DIRTY
108437 PG 00000f6c: mm/page-writeback.c:891 end writeback
108438 PG 00000f6c: mm/page-writeback.c:893 clearing TAG_WRITEBACK
and this looks a lot more like what you'd expect: other thngs happened in
between the "clear dirty, set writeback" stage and the "end writeback"
stage. That's what you'd expect to see if there was actually overlapping
IO and/or work.
(And notice that that _was_ what you saw even for the corrupted page for
the _first_ writeback: you saw the group-of-five that indicated a page
cleaning event had started, and then a group-of-two to indicate that the
writeback finished).
So I find this kind of pattern really suspicious. We have a missing
writeout, and my traces show (I didn't analyze this _particular_ one
closely, but I did the previous trace for another page that I posted) that
the writeback was actually started after the write that went missing was
done. AND I have this trace that seems to show that the writeback
basically completed immediately, with no other work in between.
That to me says: "somebody didn't actually write out out". The VM layer
asked the filesystem to do the write, but the filesystem just didn't do
it. I personally think it's because some buffer-head BH_dirty bit got
scrogged, but it could be some event that makes the filesystem simply not
do the IO because it thinks the "disk queues are too full", so it just
says "IO completed", without actually doing anything at all.
Now, the fact that it apparently happens for all of ext2, ext3
and reiserfs (but NOT apparently with "data=writeback"), makes me suspect
that there is some common interaction, and that it's somehow BH-related
(they all share much of the buffer head infrastructure). So it doesn't
look like it's just a bug in one random filesystem, I think it's a bug in
some buffer-head infrastructure/helper function.
So I don't think it's "core VM". I don't think it's the "page cache". I
think we handle the dirty state correctly at that level.
It looks more like "buffer cache" or "filesystem" to me by now.
(Btw, don't get me wrong - the above sequence numbers are in no way
*proof* of anything. You could get big groups for one page just because
something ended up being synchronous. I'll add some timestamps to my
traces to make it easier to see where there was real IO going on and where
there wasn't).
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 19:45 ` Andrew Morton
2006-12-28 20:14 ` Linus Torvalds
@ 2006-12-28 22:35 ` Mike Galbraith
1 sibling, 0 replies; 45+ messages in thread
From: Mike Galbraith @ 2006-12-28 22:35 UTC (permalink / raw)
To: Andrew Morton
Cc: Linus Torvalds, Guillaume Chazarain, David Miller, ranma,
gordonfarquharson, tbm, Peter Zijlstra, andrei.popa, hugh,
nickpiggin, arjan, Linux Kernel Mailing List, Chen Kenneth W
On Thu, 2006-12-28 at 11:45 -0800, Andrew Morton wrote:
> On Thu, 28 Dec 2006 11:28:52 -0800 (PST)
> Linus Torvalds <torvalds@osdl.org> wrote:
>
> >
> >
> > On Thu, 28 Dec 2006, Guillaume Chazarain wrote:
> > >
> > > The attached patch fixes the corruption for me.
> >
> > Well, that's a good hint, but it's really just a symptom. You effectively
> > just made the test-program not even try to flush the data to disk, so the
> > page cache would stay in memory, and you'd not see the corruption as well.
> >
> > So you basically disabled the code that tried to trigger the bug more
> > easily.
> >
> > But the reason I say it's interesting is that "WB_SYNC_NONE" is very much
> > implicated in mm/page-writeback.c, and if there is a bug triggered by
> > WB_SYNC_NONE writebacks, then that would explain why page-writeback.c also
> > fails..
> >
>
> It would be interesting to convert your app to do fsync() before
> FADV_DONTNEED. That would take WB_SYNC_NONE out of the picture as well
> (apart from pdflush activity).
I did fdatasync(), tried remapping before unmapping... nogo here.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
@ 2006-12-21 20:01 Linus Torvalds
2006-12-28 0:00 ` Martin Schwidefsky
0 siblings, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-21 20:01 UTC (permalink / raw)
To: Peter Zijlstra
Cc: schwidefsky, Martin Michlmayr, Hugh Dickins, Nick Piggin,
Arjan van de Ven, Andrei Popa, Andrew Morton,
Linux Kernel Mailing List, Florian Weimer, Marc Haber,
Heiko Carstens, Arnd Bergmann, gordonfarquharson
On Thu, 21 Dec 2006, Peter Zijlstra wrote:
>
> Also, I'm dubious about the while thing and stuck a WARN_ON(ret) thing
> at the beginning of the loop. flush_tlb_page() does IPI the other cpus
> to flush their tlb too, so there should not be a SMP race, Arjan?
Now, the reason I think the loop may be needed is:
CPU#0 CPU#1
----- -----
load old PTE entry
clear dirty and WP bits
write to page using old PTE
NOT CHECKING that the new one
is write-protected, and just
setting the dirty bit blindly
(but atomically)
flush_tlb_page()
TLB flushed, but we now have a
page that is marked dirty and
unwritable in the page tables,
and we will mark it clean in
"struct page *"
Now, the scary thing is, IF a CPU does this, then the way we do all this,
we may actually have the following sequence:
CPU#0 CPU#1
----- -----
load old PTE entry
ptep_clear_flush():
atomic "set dirty bit" sequence
PTEP now contains 0000040 !!!
flush_tlb_page();
TLB flushed, but PTEP is still
"dirty zero"
write the clear/readonly PTE
THE DIRTY BIT WAS LOST!
which might actually explain this bug.
I personally _thought_ that Intel CPU's don't actually do an "set dirty
bit atomically" sequence, but more of a "set dirty bit but trap if the TLB
is nonpresent" thing, but I have absolutely no proof for that.
Anyway, IF this is the case, then the following patch may or may not fix
things. It avoids things by never overwriting a PTE entry, not even the
"cleared" one. It always does an atomic "xchg()" with a valid new entry,
and looks at the old bits.
What do you guys think? Does something like this work out for S/390 too? I
tried to make that "ptep_flush_dirty()" concept work for architectures
that hide the dirty bit somewhere else too, but..
It actually simplifies the architecture-specific code (you just need to
implement a trivial "ptep_exchange()" and "ptep_flush_dirty()" macro), but
I only did x86-64 and i386, and while I've booted with this, I haven't
really given the thing a lot of really _deep_ thought.
But I think this might be safer, as per above.. And it _might_ actually
explain the problem. Exactly because the "ptep_clear() + blindly assign to
ptep" might lose a dirty bit that was written by another CPU.
But this really does depend on what a CPU does when it marks a page dirty.
Does it just blindly write the dirty bit? Or does it actually _validate_
that the old page table entry was still present and writable?
This patch makes no assumptions. It should work even if a CPU just writes
the dirty bit blindly, and the only expectation is that the page tables
can be accessed atomically (which had _better_ be true on any SMP
architecture)
Arjan, can you please check within Intel, and ask what the "proper"
sequence for doing something like this is?
Linus
----
commit 301d2d53ca0e5d2f61b1c1c259da410c7ee6d6a7
Author: Linus Torvalds <torvalds@woody.osdl.org>
Date: Thu Dec 21 11:11:05 2006 -0800
Rewrite the page table "clear dirty and writable" accesses
This is much simpler for most architectures, and allows us to do the
dirty and writable clear in a single operation without any races or any
double flushes.
It's also much more careful: we never overwrite the old dirty bits at
any time, and always make sure to do atomic memory ops to exchange and
see the old value.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 9d774d0..8879f1d 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -61,31 +61,6 @@ do { \
})
#endif
-#ifndef __HAVE_ARCH_PTEP_TEST_AND_CLEAR_DIRTY
-#define ptep_test_and_clear_dirty(__vma, __address, __ptep) \
-({ \
- pte_t __pte = *__ptep; \
- int r = 1; \
- if (!pte_dirty(__pte)) \
- r = 0; \
- else \
- set_pte_at((__vma)->vm_mm, (__address), (__ptep), \
- pte_mkclean(__pte)); \
- r; \
-})
-#endif
-
-#ifndef __HAVE_ARCH_PTEP_CLEAR_DIRTY_FLUSH
-#define ptep_clear_flush_dirty(__vma, __address, __ptep) \
-({ \
- int __dirty; \
- __dirty = ptep_test_and_clear_dirty(__vma, __address, __ptep); \
- if (__dirty) \
- flush_tlb_page(__vma, __address); \
- __dirty; \
-})
-#endif
-
#ifndef __HAVE_ARCH_PTEP_GET_AND_CLEAR
#define ptep_get_and_clear(__mm, __address, __ptep) \
({ \
diff --git a/include/asm-i386/pgtable.h b/include/asm-i386/pgtable.h
index e6a4723..b61d6f9 100644
--- a/include/asm-i386/pgtable.h
+++ b/include/asm-i386/pgtable.h
@@ -300,18 +300,20 @@ do { \
flush_tlb_page(vma, address); \
} while (0)
-#define __HAVE_ARCH_PTEP_CLEAR_DIRTY_FLUSH
-#define ptep_clear_flush_dirty(vma, address, ptep) \
-({ \
- int __dirty; \
- __dirty = pte_dirty(*(ptep)); \
- if (__dirty) { \
- clear_bit(_PAGE_BIT_DIRTY, &(ptep)->pte_low); \
- pte_update_defer((vma)->vm_mm, (address), (ptep)); \
- flush_tlb_page(vma, address); \
- } \
- __dirty; \
-})
+/*
+ * "ptep_exchange()" can be used to atomically change a set of
+ * page table protection bits, returning the old ones (the dirty
+ * and accessed bits in particular, since they are set by hw).
+ *
+ * "ptep_flush_dirty()" then returns the dirty status of the
+ * page (on x86-64, we just look at the dirty bit in the returned
+ * pte, but some other architectures have the dirty bits in
+ * other places than the page tables).
+ */
+#define ptep_exchange(vma, address, ptep, old, new) \
+ (old).pte_low = xchg(&(ptep)->pte_low, (new).pte_low);
+#define ptep_flush_dirty(vma, address, ptep, old) \
+ pte_dirty(old)
#define __HAVE_ARCH_PTEP_CLEAR_YOUNG_FLUSH
#define ptep_clear_flush_young(vma, address, ptep) \
diff --git a/include/asm-x86_64/pgtable.h b/include/asm-x86_64/pgtable.h
index 59901c6..07754b5 100644
--- a/include/asm-x86_64/pgtable.h
+++ b/include/asm-x86_64/pgtable.h
@@ -283,12 +283,20 @@ static inline pte_t pte_clrhuge(pte_t pte) { set_pte(&pte, __pte(pte_val(pte) &
struct vm_area_struct;
-static inline int ptep_test_and_clear_dirty(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
-{
- if (!pte_dirty(*ptep))
- return 0;
- return test_and_clear_bit(_PAGE_BIT_DIRTY, &ptep->pte);
-}
+/*
+ * "ptep_exchange()" can be used to atomically change a set of
+ * page table protection bits, returning the old ones (the dirty
+ * and accessed bits in particular, since they are set by hw).
+ *
+ * "ptep_flush_dirty()" then returns the dirty status of the
+ * page (on x86-64, we just look at the dirty bit in the returned
+ * pte, but some other architectures have the dirty bits in
+ * other places than the page tables).
+ */
+#define ptep_exchange(vma, address, ptep, old, new) \
+ (old).pte = xchg(&(ptep)->pte, (new).pte);
+#define ptep_flush_dirty(vma, address, ptep, old) \
+ pte_dirty(old)
static inline int ptep_test_and_clear_young(struct vm_area_struct *vma, unsigned long addr, pte_t *ptep)
{
diff --git a/mm/rmap.c b/mm/rmap.c
index d8a842a..a028803 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -432,7 +432,7 @@ static int page_mkclean_one(struct page *page, struct vm_area_struct *vma)
{
struct mm_struct *mm = vma->vm_mm;
unsigned long address;
- pte_t *pte, entry;
+ pte_t *ptep;
spinlock_t *ptl;
int ret = 0;
@@ -440,22 +440,24 @@ static int page_mkclean_one(struct page *page, struct vm_area_struct *vma)
if (address == -EFAULT)
goto out;
- pte = page_check_address(page, mm, address, &ptl);
- if (!pte)
- goto out;
-
- if (!pte_dirty(*pte) && !pte_write(*pte))
- goto unlock;
-
- entry = ptep_get_and_clear(mm, address, pte);
- entry = pte_mkclean(entry);
- entry = pte_wrprotect(entry);
- ptep_establish(vma, address, pte, entry);
- lazy_mmu_prot_update(entry);
- ret = 1;
-
-unlock:
- pte_unmap_unlock(pte, ptl);
+ ptep = page_check_address(page, mm, address, &ptl);
+ if (ptep) {
+ pte_t old, new;
+
+ old = *ptep;
+ new = pte_wrprotect(pte_mkclean(old));
+ if (!pte_same(old, new)) {
+ for (;;) {
+ flush_cache_page(vma, address, page_to_pfn(page));
+ ptep_exchange(vma, address, ptep, old, new);
+ if (pte_same(old, new))
+ break;
+ ret |= ptep_flush_dirty(vma, address, ptep, old);
+ flush_tlb_page(vma, address);
+ }
+ }
+ pte_unmap_unlock(pte, ptl);
+ }
out:
return ret;
}
^ permalink raw reply related [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
2006-12-21 20:01 [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) Linus Torvalds
@ 2006-12-28 0:00 ` Martin Schwidefsky
2006-12-28 0:42 ` Linus Torvalds
0 siblings, 1 reply; 45+ messages in thread
From: Martin Schwidefsky @ 2006-12-28 0:00 UTC (permalink / raw)
To: Linus Torvalds
Cc: Peter Zijlstra, Martin Michlmayr, Hugh Dickins, Nick Piggin,
Arjan van de Ven, Andrei Popa, Andrew Morton,
Linux Kernel Mailing List, Florian Weimer, Marc Haber,
Heiko Carstens, Arnd Bergmann, gordonfarquharson
On Thu, 2006-12-21 at 12:01 -0800, Linus Torvalds wrote:
> What do you guys think? Does something like this work out for S/390 too? I
> tried to make that "ptep_flush_dirty()" concept work for architectures
> that hide the dirty bit somewhere else too, but..
For s390 there are two aspects to consider:
1) the pte values are 100% software controlled. They only change because
a cpu stored a value to it or issued one of the specialized instructions
(csp, ipte and idte). The ptep_flush_dirty would be a nop for s390.
2) ptep_exchange is a bit dangerous. For s390 we need a lock that
protects the software controlled updates of the ptes. The reason is the
ipte instruction. It is implemented by the machine microcode in a
non-atomic way in regard to the memory. It reads the byte of the pte
that contains the invalid bit, flushes the tlb entries for it and then
writes back the byte with the invalid bit set. The microcode makes sure
that this pte cannot be used for form a new tlb on any cpu while the
ipte is in progress.
That means a compare-and-swap semantics on ptes won't work together with
the ipte optimization. As long as there is the pte lock that protects
all software accesses to the pte we are fine. But if any code expects
that ptep_exchange does something like an xchg things break.
--
blue skies,
Martin.
Martin Schwidefsky
Linux for zSeries Development & Services
IBM Deutschland Entwicklung GmbH
"Reality continues to ruin my life." - Calvin.
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3)
2006-12-28 0:00 ` Martin Schwidefsky
@ 2006-12-28 0:42 ` Linus Torvalds
2006-12-28 0:52 ` [PATCH] mm: fix page_mkclean_one David Miller
0 siblings, 1 reply; 45+ messages in thread
From: Linus Torvalds @ 2006-12-28 0:42 UTC (permalink / raw)
To: Martin Schwidefsky
Cc: Peter Zijlstra, Martin Michlmayr, Hugh Dickins, Nick Piggin,
Arjan van de Ven, Andrei Popa, Andrew Morton,
Linux Kernel Mailing List, Florian Weimer, Marc Haber,
Heiko Carstens, Arnd Bergmann, gordonfarquharson
On Thu, 28 Dec 2006, Martin Schwidefsky wrote:
>
> For s390 there are two aspects to consider:
> 1) the pte values are 100% software controlled.
That's fine. In that situation, you shouldn't need any atomic ops at all,
I think all our sw page-table operations are already done under the pte
lock.
The reason x86 needs to be careful is exactly the fact that the hardware
will obviously do a lot on its own, and the hardware is _not_ going to
honor our page table locking ;)
In an all-sw situation, a lot of this should be easier. S390 has _other_
things that are inconvenient (the strange "dirty bit is not in the page
tables" thing that makes it look different from everybody else), but hey,
it's a balance..
So for s390, ptep_exchange() in my example should be able to be a simple
"load old value and store new one", assuming everybody honors the pte lock
(and they _should_).
Linus
^ permalink raw reply [flat|nested] 45+ messages in thread
* Re: [PATCH] mm: fix page_mkclean_one
2006-12-28 0:42 ` Linus Torvalds
@ 2006-12-28 0:52 ` David Miller
0 siblings, 0 replies; 45+ messages in thread
From: David Miller @ 2006-12-28 0:52 UTC (permalink / raw)
To: torvalds
Cc: schwidefsky, a.p.zijlstra, tbm, hugh, nickpiggin, arjan,
andrei.popa, akpm, linux-kernel, fw, mh+linux-kernel,
heiko.carstens, arnd.bergmann, gordonfarquharson
From: Linus Torvalds <torvalds@osdl.org>
Date: Wed, 27 Dec 2006 16:42:40 -0800 (PST)
> That's fine. In that situation, you shouldn't need any atomic ops at all,
> I think all our sw page-table operations are already done under the pte
> lock.
This is true, but there is one subtlety to this I want to
point out in passing.
That lock can possibly only protect a page of PTEs.
When NR_CPUS >= CONFIG_SPLIT_PTLOCK_CPUS, the locking is done per page
of PTEs, not for all of the page tables of an address space at once.
What this means is that it's really difficult to forcefully block out
all page table operations for a given mm, and I actually needed to do
something like this on sparc64 (when growing the TLB lookup hash
table, you can't let any PTEs change state while the table is
changing). For my case, I added a spinlock to mm->context since
actually what I need is to block modifications to the hash table
itself during PTE changes.
^ permalink raw reply [flat|nested] 45+ messages in thread
end of thread, other threads:[~2007-02-02 13:09 UTC | newest]
Thread overview: 45+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2007-02-01 22:40 [PATCH] mm: fix page_mkclean_one Mark Groves
2007-02-02 8:42 ` Nick Piggin
2007-02-02 13:08 ` Evgeniy Polyakov
-- strict thread matches above, loose matches on Subject: below --
2006-12-28 15:50 martin
2006-12-24 8:10 [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) Gordon Farquharson
2006-12-24 8:43 ` Linus Torvalds
2006-12-26 16:17 ` Tobias Diedrich
2006-12-27 4:55 ` [PATCH] mm: fix page_mkclean_one David Miller
2006-12-27 7:00 ` Linus Torvalds
2006-12-27 8:39 ` Andrei Popa
2006-12-28 0:16 ` Linus Torvalds
2006-12-28 0:39 ` Linus Torvalds
2006-12-28 0:52 ` David Miller
2006-12-28 3:04 ` Linus Torvalds
2006-12-28 4:32 ` Gordon Farquharson
2006-12-28 4:53 ` Linus Torvalds
2006-12-28 5:20 ` Gordon Farquharson
2006-12-28 5:41 ` David Miller
2006-12-28 5:47 ` Gordon Farquharson
2006-12-28 10:13 ` Russell King
2006-12-28 14:15 ` Gordon Farquharson
2006-12-28 15:53 ` Martin Michlmayr
2006-12-28 17:27 ` Linus Torvalds
2006-12-28 18:44 ` Russell King
2006-12-28 19:01 ` Linus Torvalds
[not found] ` <97a0a9ac0612272115g4cce1f08n3c3c8498a6076bd5@mail.gmail.com>
[not found] ` <Pine.LNX.4.64.0612272120180.4473@woody.osdl.org>
2006-12-28 5:38 ` Gordon Farquharson
2006-12-28 9:30 ` Martin Michlmayr
2006-12-28 10:16 ` Martin Michlmayr
2006-12-28 10:49 ` Russell King
2006-12-28 14:56 ` Martin Michlmayr
2006-12-28 5:58 ` Gordon Farquharson
2006-12-28 17:08 ` Linus Torvalds
2006-12-28 5:55 ` Chen, Kenneth W
2006-12-28 6:10 ` Chen, Kenneth W
2006-12-28 6:27 ` David Miller
2006-12-28 17:10 ` Linus Torvalds
2006-12-28 9:15 ` Zhang, Yanmin
2006-12-28 17:15 ` Linus Torvalds
2006-12-28 11:50 ` Petri Kaukasoina
2006-12-28 15:09 ` Guillaume Chazarain
2006-12-28 19:19 ` Guillaume Chazarain
2006-12-28 19:28 ` Linus Torvalds
2006-12-28 19:45 ` Andrew Morton
2006-12-28 20:14 ` Linus Torvalds
2006-12-28 22:38 ` David Miller
2006-12-29 2:50 ` Segher Boessenkool
2006-12-29 6:48 ` Linus Torvalds
2006-12-28 22:35 ` Mike Galbraith
2006-12-21 20:01 [PATCH] mm: fix page_mkclean_one (was: 2.6.19 file content corruption on ext3) Linus Torvalds
2006-12-28 0:00 ` Martin Schwidefsky
2006-12-28 0:42 ` Linus Torvalds
2006-12-28 0:52 ` [PATCH] mm: fix page_mkclean_one David Miller
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).