Re: Scheduling 2.6.17-1
On Mon, 19 Jun 2006, Frederik Schueler wrote:
Hello,
I would like to reschedule the uploads:
Unless someone objects, we will upload both linux-2.6.16 and linux-2.6
to unstable tomorrow, 20th of June.
- linux-2.6 2.6.17-1 is what we have in dists/trunk/linux-2.6 now.
- linux-2.6.16 2.6.16-15 is what we have in dists/sid/linux-2.6 now,
Bastian will apply the needed changes to the build system later today
and rename the source package accordingly.
If someone needs more time for the one or the other kernel version,
please raise your voice so we can reschedule again.
On sparc 2.6.17 SMP kernel is broken, and at the moment I don't have a
clue how to fix it. I can try git-bisecting it, but it will probably take
at least few more days before it even becomes clear what causes the breakage.
There are a couple of patches for 2.6.16 which I would love to see
included. There is a D-cache memory corruption fix included in 2.6.17
(attached as sparc64-dcache.patch), which did not appear in a 2.6.16
point release as I hoped. As it also affect the mips arch, perhaps mips
maintainer should also have a look at it. The other patch
(sparc32-iotlb.patch, posted today) addresses current sparc32 breakage,
so it would be great to include that as well.
I'm currently building the kernel with these patches, and should be able
to test it tomorrow (at least on sparc64), so please don't upload before
that. If tests work out, I hope to be able to commit them to svn tomorrow
morning, as tonight my network access is extremely flaky :-(
Best regards,
Jurij Smakov jurij@wooyd.org
Key: http://www.wooyd.org/pgpkey/ KeyID: C99E03CC
From davem@davemloft.net Thu Jun 1 21:51:17 2006
Date: Thu, 01 Jun 2006 17:52:58 -0700 (PDT)
From: David Miller <davem@davemloft.net>
To: marvin@mydatex.cz
Cc: jurij@wooyd.org, mroos@linux.ee, sparclinux@vger.kernel.org
Subject: [PATCH]: Fix D-cache corruption in mremap() (was Re: 2.6.17-rc3+git seems to corrupt dpkg databases)
Thanks to some excellent corrupted status and available files
Daniel sent to me, I was able to track down the bug. This
bug has been around basically forever, just minor data layout
changes due to arbitrary unrelated kernel and userland library
modifications make the bug go away for some time and then
reappear. It was always there.
Anyways, give this patch below a test, it should fix things.
It is against the current 2.6.17 tree.
I'll also post a little reproducer program that can be used to
accurately see if the patch really fixes the problem on your
machine or not, which should help with the variability of the
dpkg corruption case.
Please test this, I need to know if this works for everyone
or not.
Thanks.
diff-tree 0b0968a3e691771bf87e1ce747b2c7d23b5526c8 (from 951bc82c53f30ec6b4c2d04a051e74ea9a89b669)
Author: David S. Miller <davem@sunset.sfo1.dsl.speakeasy.net>
Date: Thu Jun 1 17:47:25 2006 -0700
[SPARC64]: Fix D-cache corruption in mremap
If we move a mapping from one virtual address to another,
and this changes the virtual color of the mapping to those
pages, we can see corrupt data due to D-cache aliasing.
Check for and deal with this by overriding the move_pte()
macro. Set things up so that other platforms can cleanly
override the move_pte() macro too.
Signed-off-by: David S. Miller <davem@davemloft.net>
diff --git a/include/asm-generic/pgtable.h b/include/asm-generic/pgtable.h
index 358e4d3..c2059a3 100644
--- a/include/asm-generic/pgtable.h
+++ b/include/asm-generic/pgtable.h
@@ -159,17 +159,8 @@ static inline void ptep_set_wrprotect(st
#define lazy_mmu_prot_update(pte) do { } while (0)
#endif
-#ifndef __HAVE_ARCH_MULTIPLE_ZERO_PAGE
+#ifndef __HAVE_ARCH_MOVE_PTE
#define move_pte(pte, prot, old_addr, new_addr) (pte)
-#else
-#define move_pte(pte, prot, old_addr, new_addr) \
-({ \
- pte_t newpte = (pte); \
- if (pte_present(pte) && pfn_valid(pte_pfn(pte)) && \
- pte_page(pte) == ZERO_PAGE(old_addr)) \
- newpte = mk_pte(ZERO_PAGE(new_addr), (prot)); \
- newpte; \
-})
#endif
/*
diff --git a/include/asm-mips/pgtable.h b/include/asm-mips/pgtable.h
index 702a28f..69cebbd 100644
--- a/include/asm-mips/pgtable.h
+++ b/include/asm-mips/pgtable.h
@@ -70,7 +70,15 @@ extern unsigned long zero_page_mask;
#define ZERO_PAGE(vaddr) \
(virt_to_page(empty_zero_page + (((unsigned long)(vaddr)) & zero_page_mask)))
-#define __HAVE_ARCH_MULTIPLE_ZERO_PAGE
+#define __HAVE_ARCH_MOVE_PTE
+#define move_pte(pte, prot, old_addr, new_addr) \
+({ \
+ pte_t newpte = (pte); \
+ if (pte_present(pte) && pfn_valid(pte_pfn(pte)) && \
+ pte_page(pte) == ZERO_PAGE(old_addr)) \
+ newpte = mk_pte(ZERO_PAGE(new_addr), (prot)); \
+ newpte; \
+})
extern void paging_init(void);
diff --git a/include/asm-sparc64/pgtable.h b/include/asm-sparc64/pgtable.h
index c44e746..cd464f4 100644
--- a/include/asm-sparc64/pgtable.h
+++ b/include/asm-sparc64/pgtable.h
@@ -689,6 +689,23 @@ static inline void set_pte_at(struct mm_
#define pte_clear(mm,addr,ptep) \
set_pte_at((mm), (addr), (ptep), __pte(0UL))
+#ifdef DCACHE_ALIASING_POSSIBLE
+#define __HAVE_ARCH_MOVE_PTE
+#define move_pte(pte, prot, old_addr, new_addr) \
+({ \
+ pte_t newpte = (pte); \
+ if (tlb_type != hypervisor && pte_present(pte)) { \
+ unsigned long this_pfn = pte_pfn(pte); \
+ \
+ if (pfn_valid(this_pfn) && \
+ (((old_addr) ^ (new_addr)) & (1 << 13))) \
+ flush_dcache_page_all(current->mm, \
+ pfn_to_page(this_pfn)); \
+ } \
+ newpte; \
+})
+#endif
+
extern pgd_t swapper_pg_dir[2048];
extern pmd_t swapper_low_pmd_dir[2048];
-
To unsubscribe from this list: send the line "unsubscribe sparclinux" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
From breuerr@mc.net Mon Jun 19 21:10:41 2006
Date: Mon, 19 Jun 2006 23:08:59 -0500
From: Bob Breuer <breuerr@mc.net>
To: sparclinux@vger.kernel.org
Subject: [PATCH] sparc32: fix iommu_flush_iotlb end address
[ The following text is in the "ISO-8859-1" character set. ]
[ Your display is set for the "UTF-8" character set. ]
[ Some characters may be displayed incorrectly. ]
Fix the calculation of the end address when flushing iotlb entries to
ram. This bug has been a cause of esp dma errors, and it affects
HyperSPARC systems much worse than SuperSPARC systems.
Signed-off-by: Bob Breuer <breuerr@mc.net>
---
Just in case it's not obvious from the patch as to how the dma was
broken: Each dma mapping sets up iopte entries for the iommu, and the
iommu only looks in main memory for the iopte entries. If there is a
group of iopte entries that are smaller than a page in size, but
straddle a page boundary, the broken code would fail to flush the last
page to ram.
Bob
[ Part 2: "Attached Text" ]
diff --git a/arch/sparc/mm/iommu.c b/arch/sparc/mm/iommu.c
index 77840c8..7215849 100644
--- a/arch/sparc/mm/iommu.c
+++ b/arch/sparc/mm/iommu.c
@@ -144,8 +144,9 @@ static void iommu_flush_iotlb(iopte_t *i
unsigned long start;
unsigned long end;
- start = (unsigned long)iopte & PAGE_MASK;
+ start = (unsigned long)iopte;
end = PAGE_ALIGN(start + niopte*sizeof(iopte_t));
+ start &= PAGE_MASK;
if (viking_mxcc_present) {
while(start < end) {
viking_mxcc_flush_page(start);
Reply to: