Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
I wrote:
git diff 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3
6f37ac793d6ba7b35d338f791974166f67fdd9ba
produced a relatively short patch (18,437 bytes). The list of involved
files:
(omitted)
Current state of the source tree is the 6f37ac... version, so I'll start
backing out the above diffs in related groups and continue until I've got
a working kernel. For lack of an obvious target, I'll start with the
seemingly innocuous change to sysctl_check.c. I'll report back when I've
got something.
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Here's uname -a, just to confirm (maybe) I'm running on what I say
works:
Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007 alpha
Here's the diff I backed out (patch -R). It's short...
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, rose, trans_net_rose_table },
{ NET_IPV6, ipv6, trans_net_ipv6_table },
{ NET_X25, x25, trans_net_x25_table },
- { NET_TR, tr, trans_net_tr_table },
+ { NET_TR, token-ring, trans_net_tr_table },
{ NET_DECNET, decnet, trans_net_decnet_table },
/* NET_ECONET not used */
{ NET_SCTP, sctp, trans_net_sctp_table },
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm 3/6] powerpc: remove DMA 4GB boundary protection
Previously, during initialization of the IOMMU tables, the last entry
at each 4GB boundary is marked as used since there are many adapters
which cannot handle DMAing across any 4GB boundary.
The IOMMU doesn't allocate a memory area spanning LLD's segment
boundary anymore. The segment boundary of devices are set to 4GB by
default. So we can remove 4GB boundary protection now.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/powerpc/kernel/iommu.c | 21 +
1 files changed, 1 insertions(+), 20 deletions(-)
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 6abf4c3..bdb194c 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -448,9 +448,6 @@ void iommu_unmap_sg(struct iommu_table *tbl, struct
scatterlist *sglist,
struct iommu_table *iommu_init_table(struct iommu_table *tbl, int nid)
{
unsigned long sz;
- unsigned long start_index, end_index;
- unsigned long entries_per_4g;
- unsigned long index;
static int welcomed = 0;
struct page *page;
@@ -472,6 +469,7 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
#ifdef CONFIG_CRASH_DUMP
if (ppc_md.tce_get) {
+ unsigned long index;
unsigned long tceval;
unsigned long tcecount = 0;
@@ -502,23 +500,6 @@ struct iommu_table *iommu_init_table(struct iommu_table
*tbl, int nid)
ppc_md.tce_free(tbl, tbl-it_offset, tbl-it_size);
#endif
- /*
-* DMA cannot cross 4 GB boundary. Mark last entry of each 4
-* GB chunk as reserved.
-*/
- if (protect4gb) {
- entries_per_4g = 0x1l IOMMU_PAGE_SHIFT;
-
- /* Mark the last bit before a 4GB boundary as used */
- start_index = tbl-it_offset | (entries_per_4g - 1);
- start_index -= tbl-it_offset;
-
- end_index = tbl-it_size;
-
- for (index = start_index; index end_index - 1; index +=
entries_per_4g)
- __set_bit(index, tbl-it_map);
- }
-
if (!welcomed) {
printk(KERN_INFO IOMMU table initialized, virtual merging
%s\n,
novmerge ? disabled : enabled);
--
1.5.3.4
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm 2/6] powerpc: convert iommu to use the IOMMU helper
This patch converts PPC's IOMMU to use the IOMMU helper functions. The
IOMMU doesn't allocate a memory area spanning LLD's segment boundary
anymore.
iseries_hv_alloc and iseries_hv_map don't have proper device
struct. 4GB boundary is used for them.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/powerpc/Kconfig |3 +
arch/powerpc/kernel/dma_64.c |6 +-
arch/powerpc/kernel/iommu.c| 65
arch/powerpc/platforms/iseries/iommu.c |4 +-
include/asm-powerpc/iommu.h| 10 ++--
5 files changed, 45 insertions(+), 43 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index 98aef7f..1a6cf07 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -227,6 +227,9 @@ config IOMMU_VMERGE
Most drivers don't have this problem; it is safe to say Y here.
+config IOMMU_HELPER
+ def_bool PPC64
+
config HOTPLUG_CPU
bool Support for enabling/disabling CPUs
depends on SMP HOTPLUG EXPERIMENTAL (PPC_PSERIES || PPC_PMAC)
diff --git a/arch/powerpc/kernel/dma_64.c b/arch/powerpc/kernel/dma_64.c
index 1806d96..6fcb7cb 100644
--- a/arch/powerpc/kernel/dma_64.c
+++ b/arch/powerpc/kernel/dma_64.c
@@ -31,8 +31,8 @@ static inline unsigned long device_to_mask(struct device *dev)
static void *dma_iommu_alloc_coherent(struct device *dev, size_t size,
dma_addr_t *dma_handle, gfp_t flag)
{
- return iommu_alloc_coherent(dev-archdata.dma_data, size, dma_handle,
- device_to_mask(dev), flag,
+ return iommu_alloc_coherent(dev, dev-archdata.dma_data, size,
+ dma_handle, device_to_mask(dev), flag,
dev-archdata.numa_node);
}
@@ -52,7 +52,7 @@ static dma_addr_t dma_iommu_map_single(struct device *dev,
void *vaddr,
size_t size,
enum dma_data_direction direction)
{
- return iommu_map_single(dev-archdata.dma_data, vaddr, size,
+ return iommu_map_single(dev, dev-archdata.dma_data, vaddr, size,
device_to_mask(dev), direction);
}
diff --git a/arch/powerpc/kernel/iommu.c b/arch/powerpc/kernel/iommu.c
index 7a5d247..6abf4c3 100644
--- a/arch/powerpc/kernel/iommu.c
+++ b/arch/powerpc/kernel/iommu.c
@@ -31,6 +31,7 @@
#include linux/string.h
#include linux/dma-mapping.h
#include linux/bitops.h
+#include linux/iommu-helper.h
#include asm/io.h
#include asm/prom.h
#include asm/iommu.h
@@ -81,17 +82,19 @@ static int __init setup_iommu(char *str)
__setup(protect4gb=, setup_protect4gb);
__setup(iommu=, setup_iommu);
-static unsigned long iommu_range_alloc(struct iommu_table *tbl,
+static unsigned long iommu_range_alloc(struct device *dev,
+ struct iommu_table *tbl,
unsigned long npages,
unsigned long *handle,
unsigned long mask,
unsigned int align_order)
{
- unsigned long n, end, i, start;
+ unsigned long n, end, start;
unsigned long limit;
int largealloc = npages 15;
int pass = 0;
unsigned long align_mask;
+ unsigned long boundary_size;
align_mask = 0xl (64 - align_order);
@@ -136,14 +139,17 @@ static unsigned long iommu_range_alloc(struct iommu_table
*tbl,
start = mask;
}
- n = find_next_zero_bit(tbl-it_map, limit, start);
-
- /* Align allocation */
- n = (n + align_mask) ~align_mask;
-
- end = n + npages;
+ if (dev)
+ boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+ 1 IOMMU_PAGE_SHIFT);
+ else
+ boundary_size = ALIGN(1UL 32, 1 IOMMU_PAGE_SHIFT);
+ /* 4GB boundary for iseries_hv_alloc and iseries_hv_map */
- if (unlikely(end = limit)) {
+ n = iommu_area_alloc(tbl-it_map, limit, start, npages,
+tbl-it_offset, boundary_size IOMMU_PAGE_SHIFT,
+align_mask);
+ if (n == -1) {
if (likely(pass 2)) {
/* First failure, just rescan the half of the table.
* Second failure, rescan the other half of the table.
@@ -158,14 +164,7 @@ static unsigned long iommu_range_alloc(struct iommu_table
*tbl,
}
}
- for (i = n; i end; i++)
- if (test_bit(i, tbl-it_map)) {
- start = i+1;
- goto again;
- }
-
- for (i = n; i end; i++)
- __set_bit(i, tbl-it_map);
+ end = n + npages;
/* Bump the hint to a new block for small allocs. */
[PATCH -mm 5/6] x86: convert gart IOMMU to use the IOMMU helper
This patch converts gart IOMMU to use the IOMMU helper functions. The
IOMMU doesn't allocate a memory area spanning LLD's segment boundary
anymore.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/x86/Kconfig |2 +-
arch/x86/kernel/pci-gart_64.c | 41 +
2 files changed, 26 insertions(+), 17 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index df22fe7..34519c2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -434,7 +434,7 @@ config CALGARY_IOMMU_ENABLED_BY_DEFAULT
If unsure, say Y.
config IOMMU_HELPER
- def_bool CALGARY_IOMMU
+ def_bool (CALGARY_IOMMU || GART_IOMMU)
# need this always selected by IOMMU for the VIA workaround
config SWIOTLB
diff --git a/arch/x86/kernel/pci-gart_64.c b/arch/x86/kernel/pci-gart_64.c
index b8595d6..d0b9033 100644
--- a/arch/x86/kernel/pci-gart_64.c
+++ b/arch/x86/kernel/pci-gart_64.c
@@ -25,6 +25,7 @@
#include linux/bitops.h
#include linux/kdebug.h
#include linux/scatterlist.h
+#include linux/iommu-helper.h
#include asm/atomic.h
#include asm/io.h
#include asm/mtrr.h
@@ -82,17 +83,24 @@ AGPEXTERN __u32 *agp_gatt_table;
static unsigned long next_bit; /* protected by iommu_bitmap_lock */
static int need_flush; /* global flush state. set for each gart wrap */
-static unsigned long alloc_iommu(int size)
+static unsigned long alloc_iommu(struct device *dev, int size)
{
unsigned long offset, flags;
+ unsigned long boundary_size;
+ unsigned long base_index;
+
+ base_index = ALIGN(iommu_bus_base dma_get_seg_boundary(dev),
+ PAGE_SIZE) PAGE_SHIFT;
+ boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+ PAGE_SIZE) PAGE_SHIFT;
spin_lock_irqsave(iommu_bitmap_lock, flags);
- offset = find_next_zero_string(iommu_gart_bitmap, next_bit,
- iommu_pages, size);
+ offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, next_bit,
+ size, base_index, boundary_size, 0);
if (offset == -1) {
need_flush = 1;
- offset = find_next_zero_string(iommu_gart_bitmap, 0,
- iommu_pages, size);
+ offset = iommu_area_alloc(iommu_gart_bitmap, iommu_pages, 0,
+ size, base_index, boundary_size, 0);
}
if (offset != -1) {
set_bit_string(iommu_gart_bitmap, offset, size);
@@ -114,7 +122,7 @@ static void free_iommu(unsigned long offset, int size)
unsigned long flags;
spin_lock_irqsave(iommu_bitmap_lock, flags);
- __clear_bit_string(iommu_gart_bitmap, offset, size);
+ iommu_area_free(iommu_gart_bitmap, offset, size);
spin_unlock_irqrestore(iommu_bitmap_lock, flags);
}
@@ -235,7 +243,7 @@ static dma_addr_t dma_map_area(struct device *dev,
dma_addr_t phys_mem,
size_t size, int dir)
{
unsigned long npages = to_pages(phys_mem, size);
- unsigned long iommu_page = alloc_iommu(npages);
+ unsigned long iommu_page = alloc_iommu(dev, npages);
int i;
if (iommu_page == -1) {
@@ -355,10 +363,11 @@ static int dma_map_sg_nonforce(struct device *dev, struct
scatterlist *sg,
}
/* Map multiple scatterlist entries continuous into the first. */
-static int __dma_map_cont(struct scatterlist *start, int nelems,
- struct scatterlist *sout, unsigned long pages)
+static int __dma_map_cont(struct device *dev, struct scatterlist *start,
+ int nelems, struct scatterlist *sout,
+ unsigned long pages)
{
- unsigned long iommu_start = alloc_iommu(pages);
+ unsigned long iommu_start = alloc_iommu(dev, pages);
unsigned long iommu_page = iommu_start;
struct scatterlist *s;
int i;
@@ -394,8 +403,8 @@ static int __dma_map_cont(struct scatterlist *start, int
nelems,
}
static inline int
-dma_map_cont(struct scatterlist *start, int nelems, struct scatterlist *sout,
-unsigned long pages, int need)
+dma_map_cont(struct device *dev, struct scatterlist *start, int nelems,
+struct scatterlist *sout, unsigned long pages, int need)
{
if (!need) {
BUG_ON(nelems != 1);
@@ -403,7 +412,7 @@ dma_map_cont(struct scatterlist *start, int nelems, struct
scatterlist *sout,
sout-dma_length = start-length;
return 0;
}
- return __dma_map_cont(start, nelems, sout, pages);
+ return __dma_map_cont(dev, start, nelems, sout, pages);
}
/*
@@ -452,8 +461,8 @@ static int gart_map_sg(struct device *dev, struct
scatterlist *sg, int nents,
if (!iommu_merge || !nextneed || !need || s-offset ||
(s-length +
[PATCH -mm 1/6] add IOMMU helper functions for the free area management
This adds IOMMU helper functions for the free area management. These
functions take care of LLD's segment boundary limit for IOMMUs. They
would be useful for IOMMUs that use bitmap for the free area
management.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
include/linux/iommu-helper.h |7
lib/Makefile |1 +
lib/iommu-helper.c | 76 ++
3 files changed, 84 insertions(+), 0 deletions(-)
create mode 100644 include/linux/iommu-helper.h
create mode 100644 lib/iommu-helper.c
diff --git a/include/linux/iommu-helper.h b/include/linux/iommu-helper.h
new file mode 100644
index 000..4dd4c04
--- /dev/null
+++ b/include/linux/iommu-helper.h
@@ -0,0 +1,7 @@
+extern unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size,
+ unsigned long align_mask);
+extern void iommu_area_free(unsigned long *map, unsigned long start,
+ unsigned int nr);
diff --git a/lib/Makefile b/lib/Makefile
index b862b90..17fb758 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -65,6 +65,7 @@ obj-$(CONFIG_SMP) += pcounter.o
obj-$(CONFIG_AUDIT_GENERIC) += audit.o
obj-$(CONFIG_SWIOTLB) += swiotlb.o
+obj-$(CONFIG_IOMMU_HELPER) += iommu-helper.o
obj-$(CONFIG_FAULT_INJECTION) += fault-inject.o
lib-$(CONFIG_GENERIC_BUG) += bug.o
diff --git a/lib/iommu-helper.c b/lib/iommu-helper.c
new file mode 100644
index 000..e7d8544
--- /dev/null
+++ b/lib/iommu-helper.c
@@ -0,0 +1,76 @@
+/*
+ * IOMMU helper functions for the free area management
+ */
+
+#include linux/module.h
+#include linux/bitops.h
+
+static unsigned long find_next_zero_area(unsigned long *map,
+unsigned long size,
+unsigned long start,
+unsigned int nr)
+{
+ unsigned long index, end, i;
+again:
+ index = find_next_zero_bit(map, size, start);
+ end = index + nr;
+ if (end size)
+ return -1;
+ for (i = index + 1; i end; i++) {
+ if (test_bit(i, map)) {
+ start = i+1;
+ goto again;
+ }
+ }
+ return index;
+}
+
+static inline void set_bit_area(unsigned long *map, unsigned long i,
+ int len)
+{
+ unsigned long end = i + len;
+ while (i end) {
+ __set_bit(i, map);
+ i++;
+ }
+}
+
+static inline int is_span_boundary(unsigned int index, unsigned int nr,
+ unsigned long shift,
+ unsigned long boundary_size)
+{
+ shift = (shift + index) (boundary_size - 1);
+ return shift + nr boundary_size;
+}
+
+unsigned long iommu_area_alloc(unsigned long *map, unsigned long size,
+ unsigned long start, unsigned int nr,
+ unsigned long shift, unsigned long boundary_size,
+ unsigned long align_mask)
+{
+ unsigned long index;
+again:
+ index = find_next_zero_area(map, size, start, nr);
+ if (index != -1) {
+ index = (index + align_mask) ~align_mask;
+ if (is_span_boundary(index, nr, shift, boundary_size)) {
+ /* we could do more effectively */
+ start = index + 1;
+ goto again;
+ }
+ set_bit_area(map, index, nr);
+ }
+ return index;
+}
+EXPORT_SYMBOL(iommu_area_alloc);
+
+void iommu_area_free(unsigned long *map, unsigned long start, unsigned int nr)
+{
+ unsigned long end = start + nr;
+
+ while (start end) {
+ __clear_bit(start, map);
+ start++;
+ }
+}
+EXPORT_SYMBOL(iommu_area_free);
--
1.5.3.4
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm 0/6] fix iommu segment boundary problems (powerpc and x86)
This patchset is a sequel to my patchset to fix iommu segment boundary problems: http://www.mail-archive.com/linux-scsi@vger.kernel.org/msg11919.html This adds new IOMMU helper functions for the free area management. These functions take care of LLD's segment boundary limit for IOMMUs. They are useful for IOMMUs that use bitmap for the free area management. The helper functions are very low level. They just find a free area in bitmap appropriate for low level drivers. The IOMMUs continue to use their hardware specific techniques easily with the low level helper functions. This patchset converts three IOMMUs: POWERPC, X86 calgary, and X86 gart but I tested POWERPC patch. The rest are only compile tested since I don't have hardware. This is against 2.6.24-rc4-mm1. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm 6/6] kill __clear_bit_string and find_next_zero_string
This kills unused __clear_bit_string and find_next_zero_string (they
were used by only gart and calgary IOMMUs).
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/x86/lib/Makefile_64|2 +-
arch/x86/lib/bitstr_64.c| 28
include/asm-x86/bitops_64.h | 16
3 files changed, 1 insertions(+), 45 deletions(-)
delete mode 100644 arch/x86/lib/bitstr_64.c
diff --git a/arch/x86/lib/Makefile_64 b/arch/x86/lib/Makefile_64
index bbabad3..1b72bda 100644
--- a/arch/x86/lib/Makefile_64
+++ b/arch/x86/lib/Makefile_64
@@ -9,5 +9,5 @@ obj-$(CONFIG_SMP) += msr-on-cpu.o
lib-y := csum-partial_64.o csum-copy_64.o csum-wrappers_64.o delay_64.o \
usercopy_64.o getuser_64.o putuser_64.o \
- thunk_64.o clear_page_64.o copy_page_64.o bitstr_64.o bitops_64.o
+ thunk_64.o clear_page_64.o copy_page_64.o bitops_64.o
lib-y += memcpy_64.o memmove_64.o memset_64.o copy_user_64.o rwlock_64.o
copy_user_nocache_64.o
diff --git a/arch/x86/lib/bitstr_64.c b/arch/x86/lib/bitstr_64.c
deleted file mode 100644
index 7445caf..000
--- a/arch/x86/lib/bitstr_64.c
+++ /dev/null
@@ -1,28 +0,0 @@
-#include linux/module.h
-#include linux/bitops.h
-
-/* Find string of zero bits in a bitmap */
-unsigned long
-find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len)
-{
- unsigned long n, end, i;
-
- again:
- n = find_next_zero_bit(bitmap, nbits, start);
- if (n == -1)
- return -1;
-
- /* could test bitsliced, but it's hardly worth it */
- end = n+len;
- if (end nbits)
- return -1;
- for (i = n+1; i end; i++) {
- if (test_bit(i, bitmap)) {
- start = i+1;
- goto again;
- }
- }
- return n;
-}
-
-EXPORT_SYMBOL(find_next_zero_string);
diff --git a/include/asm-x86/bitops_64.h b/include/asm-x86/bitops_64.h
index 48adbf5..aaf1519 100644
--- a/include/asm-x86/bitops_64.h
+++ b/include/asm-x86/bitops_64.h
@@ -37,12 +37,6 @@ static inline long __scanbit(unsigned long val, unsigned
long max)
((off)+(__scanbit(~(((*(unsigned long *)addr)) (off)),(size)-(off : \
find_next_zero_bit(addr,size,off)))
-/*
- * Find string of zero bits in a bitmap. -1 when not found.
- */
-extern unsigned long
-find_next_zero_string(unsigned long *bitmap, long start, long nbits, int len);
-
static inline void set_bit_string(unsigned long *bitmap, unsigned long i,
int len)
{
@@ -53,16 +47,6 @@ static inline void set_bit_string(unsigned long *bitmap,
unsigned long i,
}
}
-static inline void __clear_bit_string(unsigned long *bitmap, unsigned long i,
- int len)
-{
- unsigned long end = i + len;
- while (i end) {
- __clear_bit(i, bitmap);
- i++;
- }
-}
-
/**
* ffz - find first zero in word.
* @word: The word to search
--
1.5.3.4
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH -mm 4/6] x86: convert calgary IOMMU to use the IOMMU helper
This patch converts calgary IOMMU to use the IOMMU helper
functions. The IOMMU doesn't allocate a memory area spanning LLD's
segment boundary anymore.
Signed-off-by: FUJITA Tomonori [EMAIL PROTECTED]
---
arch/x86/Kconfig |3 +++
arch/x86/kernel/pci-calgary_64.c | 34 --
2 files changed, 23 insertions(+), 14 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 48d09cb..df22fe7 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -433,6 +433,9 @@ config CALGARY_IOMMU_ENABLED_BY_DEFAULT
Calgary anyway, pass 'iommu=calgary' on the kernel command line.
If unsure, say Y.
+config IOMMU_HELPER
+ def_bool CALGARY_IOMMU
+
# need this always selected by IOMMU for the VIA workaround
config SWIOTLB
bool
diff --git a/arch/x86/kernel/pci-calgary_64.c b/arch/x86/kernel/pci-calgary_64.c
index 21f34db..f5b47ba 100644
--- a/arch/x86/kernel/pci-calgary_64.c
+++ b/arch/x86/kernel/pci-calgary_64.c
@@ -35,6 +35,7 @@
#include linux/pci.h
#include linux/delay.h
#include linux/scatterlist.h
+#include linux/iommu-helper.h
#include asm/gart.h
#include asm/calgary.h
#include asm/tce.h
@@ -260,22 +261,28 @@ static void iommu_range_reserve(struct iommu_table *tbl,
spin_unlock_irqrestore(tbl-it_lock, flags);
}
-static unsigned long iommu_range_alloc(struct iommu_table *tbl,
- unsigned int npages)
+static unsigned long iommu_range_alloc(struct device *dev,
+ struct iommu_table *tbl,
+ unsigned int npages)
{
unsigned long flags;
unsigned long offset;
+ unsigned long boundary_size;
+
+ boundary_size = ALIGN(dma_get_seg_boundary(dev) + 1,
+ PAGE_SIZE) PAGE_SHIFT;
BUG_ON(npages == 0);
spin_lock_irqsave(tbl-it_lock, flags);
- offset = find_next_zero_string(tbl-it_map, tbl-it_hint,
- tbl-it_size, npages);
+ offset = iommu_area_alloc(tbl-it_map, tbl-it_size, tbl-it_hint,
+ npages, 0, boundary_size, 0);
if (offset == ~0UL) {
tbl-chip_ops-tce_cache_blast(tbl);
- offset = find_next_zero_string(tbl-it_map, 0,
- tbl-it_size, npages);
+
+ offset = iommu_area_alloc(tbl-it_map, tbl-it_size, 0,
+ npages, 0, boundary_size, 0);
if (offset == ~0UL) {
printk(KERN_WARNING Calgary: IOMMU full.\n);
spin_unlock_irqrestore(tbl-it_lock, flags);
@@ -286,7 +293,6 @@ static unsigned long iommu_range_alloc(struct iommu_table
*tbl,
}
}
- set_bit_string(tbl-it_map, offset, npages);
tbl-it_hint = offset + npages;
BUG_ON(tbl-it_hint tbl-it_size);
@@ -295,13 +301,13 @@ static unsigned long iommu_range_alloc(struct iommu_table
*tbl,
return offset;
}
-static dma_addr_t iommu_alloc(struct iommu_table *tbl, void *vaddr,
- unsigned int npages, int direction)
+static dma_addr_t iommu_alloc(struct device *dev, struct iommu_table *tbl,
+ void *vaddr, unsigned int npages, int direction)
{
unsigned long entry;
dma_addr_t ret = bad_dma_address;
- entry = iommu_range_alloc(tbl, npages);
+ entry = iommu_range_alloc(dev, tbl, npages);
if (unlikely(entry == bad_dma_address))
goto error;
@@ -354,7 +360,7 @@ static void iommu_free(struct iommu_table *tbl, dma_addr_t
dma_addr,
badbit, tbl, dma_addr, entry, npages);
}
- __clear_bit_string(tbl-it_map, entry, npages);
+ iommu_area_free(tbl-it_map, entry, npages);
spin_unlock_irqrestore(tbl-it_lock, flags);
}
@@ -438,7 +444,7 @@ static int calgary_map_sg(struct device *dev, struct
scatterlist *sg,
vaddr = (unsigned long) sg_virt(s);
npages = num_dma_pages(vaddr, s-length);
- entry = iommu_range_alloc(tbl, npages);
+ entry = iommu_range_alloc(dev, tbl, npages);
if (entry == bad_dma_address) {
/* makes sure unmap knows to stop */
s-dma_length = 0;
@@ -476,7 +482,7 @@ static dma_addr_t calgary_map_single(struct device *dev,
void *vaddr,
npages = num_dma_pages(uaddr, size);
if (translation_enabled(tbl))
- dma_handle = iommu_alloc(tbl, vaddr, npages, direction);
+ dma_handle = iommu_alloc(dev, tbl, vaddr, npages, direction);
else
dma_handle = virt_to_bus(vaddr);
@@ -516,7 +522,7 @@ static void* calgary_alloc_coherent(struct device *dev,
size_t size,
if (translation_enabled(tbl)) {
/* set up tces to cover the allocated range */
-
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the seemingly innocuous change to sysctl_check.c.
I'll report back when I've got something.
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Here's uname -a, just to confirm (maybe) I'm running on what I say
works:
Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007 alpha
Here's the diff I backed out (patch -R). It's short...
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, rose, trans_net_rose_table },
{ NET_IPV6, ipv6, trans_net_ipv6_table },
{ NET_X25, x25, trans_net_x25_table },
- { NET_TR, tr, trans_net_tr_table },
+ { NET_TR, token-ring, trans_net_tr_table },
{ NET_DECNET, decnet, trans_net_decnet_table },
/* NET_ECONET not used */
{ NET_SCTP, sctp, trans_net_sctp_table },
reverting this makes the kernel image shorter by 8 bytes - so perhaps
some alignment issue somewhere? Or something gets overflown? Does any of
this get actually used by your bootup?
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: everything in wait_for_completion, what is my system doing?
Hello Andrew, thanks for your help! On Friday 07 December 2007 02:09:11 Andrew Morton wrote: On Wed, 5 Dec 2007 21:44:54 +0100 Bernd Schubert [EMAIL PROTECTED] wrote: after scsi-recovery a system here went into some kind lock-up, everything seems to be in wait_for_completion(). Please see the attached blocked_states.txt and all_states.txt files. This is 2.6.22.12, I can easily find out the line numbers if required. Any help is highly appreciated. Please cc linux-scsi on scsi-related reports. Sorry, I these traces confused me a bit. I had absolutely no idea about a possible reason. [blocked_states.txt text/plain (20.5KB)] [generate break] [ 1818.566436] SysRq : Show Blocked State [ 1818.570260] [ 1818.570261] free sibling [ 1818.579253] task PCstack pid father child younger older [ 1818.586987] events/7 D 0155dd642280 026 2 (L-TLB) [ 1818.593747] 81012b529ac0 0046 810128280d18 [ 1818.601321] 8100ba2376f8 81012b689630 81012aff76b0 00078023e215 [ 1818.608870] 00010003ca14 810001065400 000780430c13 [ 1818.616222] Call Trace: [ 1818.618925] [804ececb] io_schedule+0x28/0x36 [ 1818.624207] [8036e517] get_request_wait+0x104/0x158 [ 1818.630112] [8036e5a1] blk_get_request+0x36/0x6b [ 1818.635755] [8042f5cb] scsi_execute+0x51/0x129 [ 1818.641240] [880cc11b] :scsi_transport_spi:spi_execute+0x87/0xf8 [ 1818.648271] [880cd5ae] :scsi_transport_spi:spi_dv_device_echo_buffer+0x181/0x27d [ 1818.656739] [880cd801] :scsi_transport_spi:spi_dv_retrain+0x4e/0x240 [ 1818.664139] [880ce008] :scsi_transport_spi:spi_dv_device+0x615/0x69c [ 1818.671542] [880f16d1] :mptspi:mptspi_dv_device+0xb3/0x14b [ 1818.678042] [880f27d3] :mptspi:mptspi_dv_renegotiate_work+0xcb/0xef [ 1818.685348] [80245bb8] run_workqueue+0x8e/0x120 [ 1818.690905] [80245d50] worker_thread+0x106/0x117 [ 1818.696540] [80249672] kthread+0x4b/0x82 [ 1818.701474] [8020ab28] child_rip+0xa/0x12 [ 1818.706495] [ 1818.708022] unionfs-fuse- D 01a76ef63463 0 1119 1 (NOTLB) [ 1818.714764] 810129765988 0082 80337e22 [ 1818.722329] 8101297658c8 81012b652f20 810129eec810 0006 [ 1818.729895] 00010005204e 81000105c400 000680337c3e [ 1818.737249] Call Trace: [ 1818.739953] [804ecfba] schedule_timeout+0x8a/0xb6 [ 1818.745673] [804ecf01] io_schedule_timeout+0x28/0x36 [ 1818.751664] [8026fba7] congestion_wait+0x9d/0xc2 [ 1818.757300] [80269b24] balance_dirty_pages_ratelimited_nr+0x196/0x22f [ 1818.764781] [80265a3f] generic_file_buffered_write+0x52a/0x60d [ 1818.771641] [80266210] __generic_file_aio_write_nolock+0x45a/0x491 [ 1818.778852] [802662a8] generic_file_aio_write+0x61/0xc1 [ 1818.785101] [8032eb94] nfs_file_write+0x138/0x1b7 [ 1818.790822] [8028d222] do_sync_write+0xcc/0x112 [ 1818.796372] [8028d32b] vfs_write+0xc3/0x165 [ 1818.801575] [8028d5df] sys_pwrite64+0x68/0x96 [ 1818.806959] [80209d0e] system_call+0x7e/0x83 [ 1818.812250] [2b4eeec3ea73] [snippage] Possibly your device driver had conniptions and stopped generating completion interrupts. Which driver is in use? This is this time easily visible from the traces (mptspi_dv_device) ;) So its the mpt driver, we are using LSI22320 cards (I CC'ed Eric). I don't suppose it is repeatable. Thats a clear yes and no. Exactly this state we have got two or three times during an exhausting hardware stress test over the last weeks (with real and with simulated errors), but its not easily reproducible. Furthermore, the hardware will go into production soon and I don't have the chance to simulate further errors. However, we can easily get a similar state just on a raid6-rebuild (with high end hardware though. (You probably never won't run into into it with normal disks, we are doing software-raid over a bunch of several hardware raid systems). In the raid6-rebuild case the system is not completely locked up, just mostly. Somehow raid6-rebuild is still working, we can see this by the io usage status of the hardware-raids, but the system is completely blocked otherwise. Only pings and sysrq's are working. Thanks, Bernd -- Bernd Schubert Q-Leap Networks GmbH - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
* Bob Tracy [EMAIL PROTECTED] wrote: I'm struggling to see how any of those could have broken block device mounting on alpha. Are you sure you bisected right? Based on what's in that commit, it *does* appear something went wrong with bisection. If the implicated commit is the next one in time sequence relative to # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and I'll report back. Worst case, I'll have to start over and write off the past four days... generally it's easier to just go back in time and re-try the last known good and last-known bad commit IDs to establish that they are indeed correctly identified. if they are not then step back one more in the bisection log. No need to spend another 4 days on this, if most of the bisection is OK. You can replay a corrected git bisection log quickly, by doing: git-bisect reset git-bisect bisect.log Ingo - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Andrew Morton wrote: On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote: Andrew Morton wrote: commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba Merge: 2f1f53b... d90bf5a... Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Nov 14 18:51:48 2007 -0800 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/n * 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: (omitted for brevity) I'm struggling to see how any of those could have broken block device mounting on alpha. Are you sure you bisected right? Based on what's in that commit, it *does* appear something went wrong with bisection. If the implicated commit is the next one in time sequence relative to # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and I'll report back. Worst case, I'll have to start over and write off the past four days... Gad. I trust the second time will be faster. git-bisect _is_ very error prone. I find one of the problems is that each step is so far apart in time that you forget what you were doing. Did I remember to test that iteration? Did I install the right kernel? etc. Sorry about this... Not appropriate ;) Thanks for helping out. Thanks for the kind words... The above-mentioned test verified that the bisection was/is correct: 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 works, and 6f37ac793d6ba7b35d338f791974166f67fdd9ba doesn't. Now I've got to figure out why. git diff 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 6f37ac793d6ba7b35d338f791974166f67fdd9ba produced a relatively short patch (18,437 bytes). The list of involved files: diff --git a/drivers/char/random.c b/drivers/char/random.c diff --git a/drivers/isdn/sc/card.h b/drivers/isdn/sc/card.h diff --git a/drivers/isdn/sc/packet.c b/drivers/isdn/sc/packet.c diff --git a/drivers/isdn/sc/shmem.c b/drivers/isdn/sc/shmem.c diff --git a/drivers/net/arm/ep93xx_eth.c b/drivers/net/arm/ep93xx_eth.c diff --git a/drivers/net/bonding/bond_main.c b/drivers/net/bonding/bond_main.c diff --git a/drivers/net/e1000/e1000_main.c b/drivers/net/e1000/e1000_main.c diff --git a/drivers/net/fs_enet/Kconfig b/drivers/net/fs_enet/Kconfig diff --git a/drivers/net/fs_enet/Makefile b/drivers/net/fs_enet/Makefile diff --git a/drivers/net/netx-eth.c b/drivers/net/netx-eth.c diff --git a/drivers/net/s2io.c b/drivers/net/s2io.c diff --git a/drivers/net/wireless/iwlwifi/iwl3945-base.c b/drivers/net/wireless/iwlwifi/iwl3945-base.c diff --git a/include/net/sock.h b/include/net/sock.h diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c diff --git a/net/core/dev.c b/net/core/dev.c diff --git a/net/ipv4/route.c b/net/ipv4/route.c diff --git a/net/ipv4/tcp_input.c b/net/ipv4/tcp_input.c diff --git a/net/sched/sch_generic.c b/net/sched/sch_generic.c Current state of the source tree is the 6f37ac... version, so I'll start backing out the above diffs in related groups and continue until I've got a working kernel. For lack of an obvious target, I'll start with the seemingly innocuous change to sysctl_check.c. I'll report back when I've got something. -- Bob Tracy | They couldn't hit an elephant at this dist- [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH] SCSI: make pcmcia directory use obj-y|m instead of subdir-y|m
subdir-y|m isn't supposed to contain modules or built-in components. Change subdir-$(CONFIG_PCMCIA) to obj-$(CONFIG_PCMCIA). Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] --- drivers/scsi/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 2e6129f..72c8d2e 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -18,7 +18,7 @@ CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o= # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM -subdir-$(CONFIG_PCMCIA)+= pcmcia +obj-$(CONFIG_PCMCIA) += pcmcia/ obj-$(CONFIG_SCSI) += scsi_mod.o obj-$(CONFIG_SCSI_TGT) += scsi_tgt.o - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [patch] SCSI: early detection of medium not present, updated
On Wed, 5 Dec 2007, James Bottomley wrote: For one thing, you've using retries to control both an outer loop and an inner loop -- meaning the total number of attempts could be on the order of retries**2. Sort of; however, there should only really be one cc/ua before the TUR goes through. Also, TUR produces almost no conditions that would be retryable in scsi_decide_disposition() and the scsi_execute sends it down with REQ_FAILFAST anyway, so it's really not used much. For another, why do you want to swallow a UNIT_ATTENTION? Shouldn't that be up to the code calling scsi_test_unit_ready()? No, that's a bug in the old code. UA doesn't necessarily mean there's a media change. It could be asserted for a whole host of reasons. Until we get proper UA signalling, we need to resend the TUR so we get the correct media status and discard the UA (Even if the device is asserting UA for media change reasons, it will still give the correct sense code response to the following TUR). Well then, the patch appears good. I haven't been able to test it because it's based against a source tree I haven't got. Can you provide an equivalent patch against 2.6.24-rc4? Alan Stern - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Thu, 6 Dec 2007 23:07:08 -0600 (CST) [EMAIL PROTECTED] (Bob Tracy) wrote: Andrew Morton wrote: commit 6f37ac793d6ba7b35d338f791974166f67fdd9ba Merge: 2f1f53b... d90bf5a... Author: Linus Torvalds [EMAIL PROTECTED] Date: Wed Nov 14 18:51:48 2007 -0800 Merge branch 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/n * 'master' of master.kernel.org:/pub/scm/linux/kernel/git/davem/net-2.6: [NET]: rt_check_expire() can take a long time, add a cond_resched() [ISDN] sc: Really, really fix warning [ISDN] sc: Fix sndpkt to have the correct number of arguments [TCP] FRTO: Clear frto_highmark only after process_frto that uses it [NET]: Remove notifier block from chain when register_netdevice_notifier f [FS_ENET]: Fix module build. [TCP]: Make sure write_queue_from does not begin with NULL ptr [TCP]: Fix size calculation in sk_stream_alloc_pskb [S2IO]: Fixed memory leak when MSI-X vector allocation fails [BONDING]: Fix resource use after free [SYSCTL]: Fix warning for token-ring from sysctl checker [NET] random : secure_tcp_sequence_number should not assume CONFIG_KTIME_S [IWLWIFI]: Not correctly dealing with hotunplug. [TCP] FRTO: Plug potential LOST-bit leak [TCP] FRTO: Limit snd_cwnd if TCP was application limited [E1000]: Fix schedule while atomic when called from mii-tool. [NETX]: Fix build failure added by 2.6.24 statistics cleanup. [EP93xx_ETH]: Build fix after 2.6.24 NAPI changes. [PKT_SCHED]: Check subqueue status before calling hard_start_xmit I'm struggling to see how any of those could have broken block device mounting on alpha. Are you sure you bisected right? Based on what's in that commit, it *does* appear something went wrong with bisection. If the implicated commit is the next one in time sequence relative to # good: [2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3] CRISv10 fasttimer: Scrap INLINE and name timeval_cmp better then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and I'll report back. Worst case, I'll have to start over and write off the past four days... Gad. I trust the second time will be faster. git-bisect _is_ very error prone. I find one of the problems is that each step is so far apart in time that you forget what you were doing. Did I remember to test that iteration? Did I install the right kernel? etc. Sorry about this... Not appropriate ;) Thanks for helping out. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SCSI: make pcmcia directory use obj-y|m instead of subdir-y|m
On Fri, Dec 07, 2007 at 10:36:23PM +0900, Tejun Heo wrote: subdir-y|m isn't supposed to contain modules or built-in components. Change subdir-$(CONFIG_PCMCIA) to obj-$(CONFIG_PCMCIA). Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] Ack-by: Sam Ravnborg [EMAIL PROTECTED] --- drivers/scsi/Makefile |2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/drivers/scsi/Makefile b/drivers/scsi/Makefile index 2e6129f..72c8d2e 100644 --- a/drivers/scsi/Makefile +++ b/drivers/scsi/Makefile @@ -18,7 +18,7 @@ CFLAGS_aha152x.o = -DAHA152X_STAT -DAUTOCONF CFLAGS_gdth.o= # -DDEBUG_GDTH=2 -D__SERIAL__ -D__COM2__ -DGDTH_STATISTICS CFLAGS_seagate.o = -DARBITRATE -DPARITY -DSEAGATE_USE_ASM -subdir-$(CONFIG_PCMCIA) += pcmcia +obj-$(CONFIG_PCMCIA) += pcmcia/ obj-$(CONFIG_SCSI) += scsi_mod.o obj-$(CONFIG_SCSI_TGT) += scsi_tgt.o - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the seemingly innocuous change to sysctl_check.c.
I'll report back when I've got something.
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Here's uname -a, just to confirm (maybe) I'm running on what I say
works:
Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007
alpha
Here's the diff I backed out (patch -R). It's short...
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, rose, trans_net_rose_table },
{ NET_IPV6, ipv6, trans_net_ipv6_table },
{ NET_X25, x25, trans_net_x25_table },
- { NET_TR, tr, trans_net_tr_table },
+ { NET_TR, token-ring, trans_net_tr_table },
{ NET_DECNET, decnet, trans_net_decnet_table
},
/* NET_ECONET not used */
{ NET_SCTP, sctp, trans_net_sctp_table },
reverting this makes the kernel image shorter by 8 bytes - so
perhaps some alignment issue somewhere? Or something gets overflown?
Does any of this get actually used by your bootup?
Dunno... The dmesg output is not terribly useful here, because most
of the interesting stuff concerning udev startup that appears on the
console never makes it into a log. Note that, for the bad cases, I
don't see the same console output that Michael reported, although the
net effect is the same: the partitions don't get found, so I'm offered
the chance to enter my root password and do some poking around, and
when I do, none of the block devices are present under /dev.
I'm open to suggestions on how to take this analysis further. Michael
indicated he's running a conference this week, so I don't know when
he'll be able to come up for air.
i'm not sure how to do direct debugging on udev, so i can only guess
about what effect on the kernel side could have caused this. One bad
hack would be to probe udevd's behavior by changing the NET_TR entry
in various ways:
tr - token-ring # breaks
tr - tr # works
tr - token-rin0 # ?(1)
tr - TR # ?(2)
the question is, does tweak (1) and tweak (2) work or break?
but it would be a lot more effective i guess to get some udevd expert's
attention on this ...
Could we get the output of:
ls -l /sys/block/sda/
and:
grep . /sys/block/sda/*/dev
?
Kay
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
* Bob Tracy [EMAIL PROTECTED] wrote:
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the seemingly innocuous change to sysctl_check.c.
I'll report back when I've got something.
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Here's uname -a, just to confirm (maybe) I'm running on what I say
works:
Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007
alpha
Here's the diff I backed out (patch -R). It's short...
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, rose, trans_net_rose_table },
{ NET_IPV6, ipv6, trans_net_ipv6_table },
{ NET_X25, x25, trans_net_x25_table },
- { NET_TR, tr, trans_net_tr_table },
+ { NET_TR, token-ring, trans_net_tr_table },
{ NET_DECNET, decnet, trans_net_decnet_table },
/* NET_ECONET not used */
{ NET_SCTP, sctp, trans_net_sctp_table },
reverting this makes the kernel image shorter by 8 bytes - so
perhaps some alignment issue somewhere? Or something gets overflown?
Does any of this get actually used by your bootup?
Dunno... The dmesg output is not terribly useful here, because most
of the interesting stuff concerning udev startup that appears on the
console never makes it into a log. Note that, for the bad cases, I
don't see the same console output that Michael reported, although the
net effect is the same: the partitions don't get found, so I'm offered
the chance to enter my root password and do some poking around, and
when I do, none of the block devices are present under /dev.
I'm open to suggestions on how to take this analysis further. Michael
indicated he's running a conference this week, so I don't know when
he'll be able to come up for air.
i'm not sure how to do direct debugging on udev, so i can only guess
about what effect on the kernel side could have caused this. One bad
hack would be to probe udevd's behavior by changing the NET_TR entry
in various ways:
tr - token-ring # breaks
tr - tr # works
tr - token-rin0 # ?(1)
tr - TR # ?(2)
the question is, does tweak (1) and tweak (2) work or break?
but it would be a lot more effective i guess to get some udevd expert's
attention on this ...
Ingo
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [OpenFCoE PATCH] [PATCH] Performance improvement, combine received data copy with CRC.
Rob Love wrote: Joe Eykholt wrote: [PATCH] Performance improvement, combine received data copy with CRC. Shouldn't we remove openfc_cp_to_user() if we're moving that functionality into openfc_scsi_recv_data()? Yes. That was an oversight. I did intend to remove it. Do you want a new patch for that or will you take care of it? I can take care of it. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
* Andrew Morton [EMAIL PROTECTED] wrote: then the test of whether I bisected correctly is as simple as applying the commit and seeing if things break, because I'm running on the kernel corresponding to 2f1f53bdc6531696934f6ee7bbdfa2ab4f4f62a3 right now. Let me give that a try and I'll report back. Worst case, I'll have to start over and write off the past four days... Gad. I trust the second time will be faster. git-bisect _is_ very error prone. I find one of the problems is that each step is so far apart in time that you forget what you were doing. Did I remember to test that iteration? Did I install the right kernel? etc. i have a fully automated bootup-hang bisection script. It is based on git-bisect run. I run the script, it builds and boots kernels fully automatically, and when the bootup fails (the script notices that via the serial log, which it continuously watches - or via a timeout, if the system does not come up within 10 minutes it's a bad kernel), the script raises my attention via a beep and i power cycle the test box. (yeah, i should make use of a managed power outlet to 100% automate it) So i dont have to a single manual decision anytime during the bisection. But the scripts are very much tied to my ad-hoc test environment so it would not be of much general use. Ingo - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: Is the udev daemon (still) running while it fails? Yes, and there's something else I forgot to mention that may be significant... For the bad case, in addition to udevd, ps -ef shows a sh -e /lib/udev/net.agent running with a PPID of 1. This process doesn't exit until I reboot. If this is normal under the circumstances, please disregard. -- Bob Tracy | They couldn't hit an elephant at this dist- [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Recent sym53c8xx patches
On Tue, 2007-11-27 at 09:51 -0500, Tony Battersby wrote: Hello, I am sending this message to check up on the merge status of my recent sym53c8xx patches to make sure they aren't forgotten. Matthew Wilcox, could you give an ack/nak for these merge requests? Also, please let me know if I need to do anything else (such as resending later) to make sure these patches get merged. [PATCH] [SCSI] sym53c8xx: fix free_irq() regression in 2.6.24 http://marc.info/?t=11943826337r=1w=4 Regression fix. Should be merged in 2.6.24. OK'ed by Christoph Hellwig. [PATCH] [SCSI] sym53c8xx: fix resid calculation http://marc.info/?l=linux-scsim=119438360705773w=4 Bug fix. I would like it to be merged in 2.6.24. No replies to initial message. These two I have flagged for inclusion. [PATCH] [SCSI] sym53c8xx: don't flood syslog with negotiation messages http://marc.info/?l=linux-scsim=119446914818689w=4 More an annoyance fix than a bug fix. Probably safe to merge for 2.6.24, but could wait for 2.6.25 if someone objects. No replies to initial message. This one I'd like to wait on maintainer feedback [PATCH] [SCSI] sym53c8xx: fix setflag user command to control disconnects http://marc.info/?l=linux-scsim=119446790116497w=4 Fix for long-broken not-widely-used feature. Can be dropped if the disconnect attribute will be added to the SPI transport class in the near future. Is anyone working on this BTW? This one, I was sort of expecting, since you want the feature that you'd add it to the transport class ... [PATCH] [SCSI] sym53c8xx: increase sg_tablesize for larger data transfers http://marc.info/?l=linux-scsim=119513922112712w=4 Enhancement. On hold for the moment due to speculation that it may break some 875 chips. I'd like more feedback, but sometimes the best way of testing things like this is to stick it in the field and see if it breaks something. James - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-mm1 and excessive block IO errors
On Fri, 07 Dec 2007 20:44:45 + Zan Lynx [EMAIL PROTECTED] wrote: I am not sure if this problem has been addressed already. I read some about the fast-fail issues and this may be related? On nearly all my USB block devices, I have been getting zillions of I/O errors. But they aren't real, they don't appear with 2.6.23 kernels. I can often read and write data to the device, but these IO errors cause error aborts in user space applications in many cases, making it a chancy thing to run backup software, for example. Here is a bit of dmesg from plugging in a perfectly good USB-2 flash drive. hub 3-0:1.0: state 7 ports 6 chg evt 0004 ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: new high speed USB device using ehci_hcd and address 9 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: default language 0x0409 usb 3-2: uevent usb 3-2: usb_probe_device usb 3-2: configuration #1 chosen from 1 choice usb 3-2: adding 3-2:1.0 (config #1, interface 0) usb 3-2:1.0: uevent libusual 3-2:1.0: usb_probe_interface libusual 3-2:1.0: usb_probe_interface - got id usb-storage 3-2:1.0: usb_probe_interface usb-storage 3-2:1.0: usb_probe_interface - got id scsi4 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '009' usb 3-2: New USB device found, idVendor=05dc, idProduct=a400 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: JUMPDRIVE usb 3-2: Manufacturer: LEXAR MEDIA usb 3-2: SerialNumber: 0A4EEC05201219080904 usb-storage: device found at 9 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 0 CCS sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 4:0:0:0: [sdg] Attached SCSI removable disk sd 4:0:0:0: Attached scsi generic sg7 type 0 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 3984 Yes, this is breakage in the scsi tree. I believe that the offending patch has been found and I have a nasty fix somewhere in my inbox - it involves reverting a patch which doesn't revert properly. I haven't got onto looking at it yet, sorry. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 2.6.23] 3w-xxxx: Fix bad unaligned accesses on alpha SMP
On Dec 6, 2007 6:07 PM, Gabriele Gorla [EMAIL PROTECTED] wrote:
disable packing of the TAG_TW_Device_Extension
structure to prevent kernel unaligned accesses when
accessing the spinlock inside the ioctl_wqueue structure.
Fixes smartmontools kernel panic on alpha SMP
Signed-off-by: Gabriele Gorla [EMAIL PROTECTED]
---
--- linux-2.6.23/drivers/scsi/3w-.h 2007-10-09 13:31:38.0 -0700
+++ linux-2.6.23a/drivers/scsi/3w-.h 2007-12-06 17:46:05.0 -0800
@@ -392,6 +392,8 @@
unsigned char padding[12];
} TW_Passthru;
+#pragma pack()
+
typedef struct TAG_TW_Device_Extension {
u32 base_addr;
unsigned long *alignment_virtual_address[TW_Q_LENGTH];
@@ -430,6 +432,4 @@
wait_queue_head_t ioctl_wqueue;
} TW_Device_Extension;
-#pragma pack()
-
#endif /* _3W__H */
ACK James, please apply.
-Adam
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: Yeah, that looks all fine. What distro is that, and what's the udev version? Mine is Debian Etch, normally with the latest released or -rcX kernel from kernel.org. Updates current as of about 18 hours ago. Udev package version is 0.105-4. The RELEASE-NOTES file in /usr/share/doc/udev says udev 105. You are booting your kernel with an initramfs? Not in my case: everything I need at boot time is built-in. Is the udev daemon (still) running while it fails? If you run /sbin/udevtrigger, do the nodes appear? I can answer the above later when I'm back in front of the machine, but even in the not good case, I still see the following messages from the /etc/rcS.d/S03udev file: Starting the hotplug events dispatcher udevd. Synthesizing the initial hotplug events. This is where udevtrigger gets called, followed by the load_input_modules and create_dev_makedev functions, then... Waiting for /dev to be fully populated. which is where udevsettle gets called. None of the above appear to be exiting abnormally for the bad case, but I'll definitely take a closer look at what MAKEDEV (/dev/MAKEDEV -- /sbin/MAKEDEV) is doing. In particular, Debian MAKEDEV is looking at /proc/devices to decide what to do, so maybe cat /proc/devices would be useful to look at for the broken case. -- Bob Tracy | They couldn't hit an elephant at this dist- [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Bob Tracy wrote: That was quick :-). Backing out the sysctl_check.c diff gives me a working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though. Michael Cree: could you try backing out the diff below from your 2.6.24-rc3 tree and see if things are now working for you? Yes (conference is now over). I backed out the sysctl_check patch from 2.6.24-rc3 and, indeed, got a working kernel. The working kernel (was probably 2.6.24-rc3 less sysctl_check patch, but might have been a 2.6.23 variant) has the following in /sys/block alpha:~# ls -l /sys/block/ total 0 drwxr-xr-x 5 root root 0 2007-12-08 08:55 fd0 drwxr-xr-x 6 root root 0 2007-12-08 08:55 hde drwxr-xr-x 5 root root 0 2007-12-08 08:55 hdf drwxr-xr-x 10 root root 0 2007-12-08 08:55 sda drwxr-xr-x 9 root root 0 2007-12-08 08:55 sdb alpha:~# ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 8192 2007-12-08 08:55 capability -r--r--r-- 1 root root 8192 2007-12-08 08:55 dev lrwxrwxrwx 1 root root0 2007-12-08 08:55 device - ../../devices/pci0001:01/0001:01:06.0/host0/target0:0:1/0:0:1:0 drwxr-xr-x 2 root root0 2007-12-08 08:55 holders drwxr-xr-x 3 root root0 2007-12-08 08:55 queue -r--r--r-- 1 root root 8192 2007-12-08 08:55 range -r--r--r-- 1 root root 8192 2007-12-08 08:55 removable drwxr-xr-x 3 root root0 2007-12-08 08:55 sda1 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda2 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda3 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda4 drwxr-xr-x 3 root root0 2007-12-08 08:55 sda5 -r--r--r-- 1 root root 8192 2007-12-08 08:55 size drwxr-xr-x 2 root root0 2007-12-08 08:55 slaves -r--r--r-- 1 root root 8192 2007-12-08 08:55 stat lrwxrwxrwx 1 root root0 2007-12-08 08:55 subsystem - ../../block --w--- 1 root root 8192 2007-12-08 08:55 uevent alpha:~# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 The broken kernel (2.6.24-rc3) has the following in /sys/block alpha:~# ls -l /sys/block/ total 0 drwxr-xr-x 5 root root 0 Dec 8 09:22 fd0 drwxr-xr-x 6 root root 0 Dec 8 09:22 hde drwxr-xr-x 5 root root 0 Dec 8 09:23 hdf drwxr-xr-x 10 root root 0 Dec 8 09:22 sda drwxr-xr-x 9 root root 0 Dec 8 09:23 sdb alpha:~# ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 8192 Dec 8 09:22 capability -r--r--r-- 1 root root 8192 Dec 8 09:22 dev lrwxrwxrwx 1 root root0 Dec 8 09:23 device - ../../devices/pci0001:01/0001:01:06.0/host0/target0:0:1/0:0:1:0 drwxr-xr-x 2 root root0 Dec 8 09:22 holders drwxr-xr-x 3 root root0 Dec 8 09:22 queue -r--r--r-- 1 root root 8192 Dec 8 09:22 range -r--r--r-- 1 root root 8192 Dec 8 09:22 removable drwxr-xr-x 3 root root0 Dec 8 09:22 sda1 drwxr-xr-x 3 root root0 Dec 8 09:22 sda2 drwxr-xr-x 3 root root0 Dec 8 09:22 sda3 drwxr-xr-x 3 root root0 Dec 8 09:22 sda4 drwxr-xr-x 3 root root0 Dec 8 09:22 sda5 -r--r--r-- 1 root root 8192 Dec 8 09:22 size drwxr-xr-x 2 root root0 Dec 8 09:22 slaves -r--r--r-- 1 root root 8192 Dec 8 09:22 stat lrwxrwxrwx 1 root root0 Dec 8 09:22 subsystem - ../../block --w--- 1 root root 8192 Dec 8 09:22 uevent alpha:~# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 I failed to spot any difference (other than the formatting of the dates) between the two! Cheers Michael. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Fw: scsi_wait_scan Kconfig option
Hi all, Please see below. Nick Begin forwarded message: Date: Fri, 7 Dec 2007 19:12:42 + From: Nick Warne [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: scsi_wait_scan Kconfig option Hi all, I am bringing this up again - primarily as I forgot about it after patching my build tree ages ago: http://lkml.org/lkml/2007/10/27/68 Today I built and installed git for the first time and cloned Linus' tree (very trick!). I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... .config # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y # CONFIG_SCSI_TGT is not set # CONFIG_SCSI_NETLINK is not set # CONFIG_SCSI_PROC_FS is not set # # 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 is not set # CONFIG_CHR_DEV_SG is not set # CONFIG_CHR_DEV_SCH is not set # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set CONFIG_SCSI_WAIT_SCAN=m I have attached my patch again :-) Nick -- Free Software Foundation Associate Member 5508 -- Free Software Foundation Associate Member 5508--- linux-current/drivers/scsi/Kconfig_old 2007-10-20 12:44:50.0 +0100 +++ linux-current/drivers/scsi/Kconfig 2007-10-20 12:57:13.0 +0100 @@ -248,10 +248,17 @@ or async on the kernel's command line. config SCSI_WAIT_SCAN - tristate + tristate Wait for SCSI scan completion default m depends on SCSI depends on MODULES + help + The SCSI subsystem can probe for devices while the rest of the + system continues booting, and even probe devices on different + busses in parallel, leading to a significant speed-up. + + You can load the scsi_wait_scan module to ensure that all scans + have completed. menu SCSI Transports depends on SCSI
Re: BUG 2.6.24-rc4-mm1 -- Boot still hangs w/ async scsi scan
On Thu, 2007-12-06 at 10:35 -0800, Andrew Morton wrote:
On Thu, 06 Dec 2007 13:14:22 -0500 Lee Schermerhorn [EMAIL PROTECTED] wrote:
On Wed, 2007-12-05 at 13:20 -0800, Andrew Morton wrote:
On Wed, 05 Dec 2007 11:36:39 -0500
Lee Schermerhorn [EMAIL PROTECTED] wrote:
As reported here:
http://marc.info/?l=linux-scsim=119645761124683w=4
against 24-rc3-mm2, I'm still seeing the hang on my HP ia64 NUMA
platform under 24-rc4-mm1 with async scsi scan enabled. I'm still
seeing the message mptspi: ioc#: mpt_config failed when it hangs.
I can boot by disabling async scan. However, I've also noticed some
disks attached via one of the mpt adapters [scsi8 in console long in
message linked above] going off-line during stress tests. This was
under 24-rc3-mm2. Haven't got that far yet with 24-rc4-mm1.
Is ther any way of tricking you into
http://www.zip.com.au/~akpm/linux/patches/stuff/bisecting-mm-trees.txt?
Obvious culprits to start with would be git-scsi-misc and maybe
scsi-early-detection-of-medium-not-present-updated.patch. But there are
only 20-odd scsi patches in there.
The reported hang occurs after pushing the git-scsi-misc patch.
OK, thanks.
More info on the hang.
I thought I'd enable the debug prints in just mpt_config() to see if I
could see why it failed when the hang occurs. [Hacky patch below.].
However, when I enable the printk's the system boots fine with
git-scsi-misc applied, even with async scan enabled. An extract of the
console log of the messages is included below, in case that provides a
clue to anyone who might care.
One other thing: If I leave the system in the hung state long enough, I
start seeing stack dumps and messages about tasks blocked for more than
120 seconds [swapper and scsi_scan_[89]]. Section of the log included
below.
I'll keep investigating in the background...
Lee
---
temp mpt debug patch
drivers/message/fusion/mptbase.c |5 +
1 file changed, 5 insertions(+)
Index: Linux/drivers/message/fusion/mptbase.c
===
--- Linux.orig/drivers/message/fusion/mptbase.c 2007-12-07 12:12:00.0
-0500
+++ Linux/drivers/message/fusion/mptbase.c 2007-12-07 12:16:29.0
-0500
@@ -5633,6 +5633,9 @@ SendEventAck(MPT_ADAPTER *ioc, EventNoti
* -EAGAIN if no msg frames currently available
* -EFAULT for non-successful reply or no reply (timeout)
*/
+// brute force enable dcprintk for just this function
+#undef dcprintk
+#define dcprintk(IOC, CMD) CMD
int
mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS *pCfg)
{
@@ -5746,6 +5749,8 @@ mpt_config(MPT_ADAPTER *ioc, CONFIGPARMS
return rc;
}
+#undef dcprintk
+#define dcprintk(IOC, CMD)
/*=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=*/
/**
---
console log extract of messages from patch above:
Fusion MPT base driver 3.04.06
Copyright (c) 1999-2007 LSI Corporation
Fusion MPT SPI Host driver 3.04.06
GSI 43 (level, low) - CPU 2 (0x0800) vector 74
ACPI: PCI Interrupt :38:01.0[A] - GSI 43 (level, low) - IRQ 74
mptbase: ioc0: Initiating bringup
ioc0: LSI53C1030 C0: Capabilities={Initiator,Target}
mptbase: ioc0: Sending Config request type 3, page 0 and action 0
mptbase: ioc0: Sending Config request type 3, page 0 and action 1
mptbase: ioc0: Sending Config request type 3, page 2 and action 0
mptbase: ioc0: Sending Config request type 3, page 2 and action 6
mptbase: ioc0: Sending Config request type 4, page 1 and action 0
mptbase: ioc0: Sending Config request type 4, page 0 and action 0
mptbase: ioc0: Sending Config request type 1, page 1 and action 0
mptbase: ioc0: Sending Config request type 1, page 1 and action 1
mptbase: ioc0: Sending Config request type 1, page 4 and action 0
mptbase: ioc0: Sending Config request type 1, page 4 and action 1
mptbase: ioc0: Sending Config request type 0, page 2 and action 0
mptbase: ioc0: Sending Config request type 0, page 2 and action 1
mptbase: ioc0: Sending Config request type 9, page 0 and action 0
mptbase: ioc0: Sending Config request type 9, page 0 and action 1
scsi8 : ioc0: LSI53C1030 C0, FwRev=01032341h, Ports=1, MaxQ=255, IRQ=74
mptbase: ioc0: Sending Config request type 4, page 1 and action 2
GSI 44 (level, low) - CPU 3 (0x0c00) vector 75
ACPI: PCI Interrupt :38:01.1[B] - GSI 44 (level, low) - IRQ 75
mptbase: ioc1: Initiating bringup
ioc1: LSI53C1030 C0: Capabilities={Initiator,Target}
mptbase: ioc1: Sending Config request type 3, page 0 and action 0
scsi 8:0:0:0: Direct-Access COMPAQ BF036863B9 HPB4 PQ: 0 ANSI: 3
target8:0:0: Beginning Domain Validation
mptbase: ioc0: Sending Config request type 4, page 1 and action 2
mptbase: ioc0: Sending Config request type 4, page 1 and action 2
mptbase: ioc1: Sending Config request type 3, page 0 and action 1
mptbase:
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: On Fri, 2007-12-07 at 19:06 +0100, Ingo Molnar wrote: i'm not sure how to do direct debugging on udev, so i can only guess about what effect on the kernel side could have caused this. One bad hack would be to probe udevd's behavior by changing the NET_TR entry in various ways: tr - token-ring # breaks tr - tr # works tr - token-rin0 # ?(1) tr - TR # ?(2) the question is, does tweak (1) and tweak (2) work or break? but it would be a lot more effective i guess to get some udevd expert's attention on this ... Could we get the output of: ls -l /sys/block/sda/ and: grep . /sys/block/sda/*/dev ? Here are the requested items for the 2.6.24-rc2-g6f37ac79-dirty kernel (the working one with the sysctl_check.c patch reverted): smirkin:/# ls -l /sys/block/sda total 0 -r--r--r-- 1 root root 8192 Dec 7 08:36 capability -r--r--r-- 1 root root 8192 Dec 7 08:36 dev lrwxrwxrwx 1 root root0 Dec 7 08:36 device - ../../devices/pci:00/:00:14.0/:01:09.0/host0/target0:0:0/0:0:0:0 drwxr-xr-x 2 root root0 Dec 7 08:36 holders drwxr-xr-x 3 root root0 Dec 7 08:36 queue -r--r--r-- 1 root root 8192 Dec 7 08:36 range -r--r--r-- 1 root root 8192 Dec 7 08:36 removable drwxr-xr-x 3 root root0 Dec 7 08:36 sda1 drwxr-xr-x 3 root root0 Dec 7 08:36 sda2 drwxr-xr-x 3 root root0 Dec 7 08:36 sda3 drwxr-xr-x 3 root root0 Dec 7 08:36 sda4 drwxr-xr-x 3 root root0 Dec 7 08:36 sda5 drwxr-xr-x 3 root root0 Dec 7 08:36 sda6 drwxr-xr-x 3 root root0 Dec 7 08:36 sda7 -r--r--r-- 1 root root 8192 Dec 7 08:36 size drwxr-xr-x 2 root root0 Dec 7 08:36 slaves -r--r--r-- 1 root root 8192 Dec 7 08:36 stat lrwxrwxrwx 1 root root0 Dec 7 08:36 subsystem - ../../block --w--- 1 root root 8192 Dec 7 08:36 uevent smirkin:/# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 /sys/block/sda/sda6/dev:8:6 /sys/block/sda/sda7/dev:8:7 Assuming /sys/block even exists for the non-working case, I'll forward that info in a few hours when I can get home to reboot the machine. -- Bob Tracy | They couldn't hit an elephant at this dist- [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Kay Sievers wrote: Is the udev daemon (still) running while it fails? Yes. If you run /sbin/udevtrigger, do the nodes appear? No. Exit status is 0, and there are no errors. Everything looks fine under /sys/block, and there doesn't seem to be a problem with /proc/devices either. -- Bob Tracy | They couldn't hit an elephant at this dist- [EMAIL PROTECTED] | - Last words of Union General John Sedgwick, | Battle of Spotsylvania Court House, U.S. Civil War - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: 2.6.24-rc4-mm1 and excessive block IO errors
On Fri, Dec 07, 2007 at 03:05:37PM -0800, Andrew Morton wrote: On Fri, 07 Dec 2007 20:44:45 + Zan Lynx [EMAIL PROTECTED] wrote: I am not sure if this problem has been addressed already. I read some about the fast-fail issues and this may be related? On nearly all my USB block devices, I have been getting zillions of I/O errors. But they aren't real, they don't appear with 2.6.23 kernels. I can often read and write data to the device, but these IO errors cause error aborts in user space applications in many cases, making it a chancy thing to run backup software, for example. Here is a bit of dmesg from plugging in a perfectly good USB-2 flash drive. hub 3-0:1.0: state 7 ports 6 chg evt 0004 ehci_hcd :00:02.2: GetStatus port 2 status 001803 POWER sig=j CSC CONNECT hub 3-0:1.0: port 2, status 0501, change 0001, 480 Mb/s hub 3-0:1.0: debounce: port 2: total 100ms stable 100ms status 0x501 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: new high speed USB device using ehci_hcd and address 9 ehci_hcd :00:02.2: port 2 high speed ehci_hcd :00:02.2: GetStatus port 2 status 001005 POWER sig=se0 PE CONNECT usb 3-2: default language 0x0409 usb 3-2: uevent usb 3-2: usb_probe_device usb 3-2: configuration #1 chosen from 1 choice usb 3-2: adding 3-2:1.0 (config #1, interface 0) usb 3-2:1.0: uevent libusual 3-2:1.0: usb_probe_interface libusual 3-2:1.0: usb_probe_interface - got id usb-storage 3-2:1.0: usb_probe_interface usb-storage 3-2:1.0: usb_probe_interface - got id scsi4 : SCSI emulation for USB Mass Storage devices drivers/usb/core/inode.c: creating file '009' usb 3-2: New USB device found, idVendor=05dc, idProduct=a400 usb 3-2: New USB device strings: Mfr=1, Product=2, SerialNumber=3 usb 3-2: Product: JUMPDRIVE usb 3-2: Manufacturer: LEXAR MEDIA usb 3-2: SerialNumber: 0A4EEC05201219080904 usb-storage: device found at 9 usb-storage: waiting for device to settle before scanning usb-storage: device scan complete scsi 4:0:0:0: Direct-Access LEXARJUMPDRIVE1000 PQ: 0 ANSI: 0 CCS sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sd 4:0:0:0: [sdg] 2026592 512-byte hardware sectors (1038 MB) sd 4:0:0:0: [sdg] Write Protect is off sd 4:0:0:0: [sdg] Mode Sense: 43 00 00 00 sd 4:0:0:0: [sdg] Assuming drive cache: write through sdg: sdg1 sd 4:0:0:0: [sdg] Attached SCSI removable disk sd 4:0:0:0: Attached scsi generic sg7 type 0 sd 4:0:0:0: [sdg] Result: hostbyte=0x01 driverbyte=0x00 end_request: I/O error, dev sdg, sector 3984 Yes, this is breakage in the scsi tree. I believe that the offending patch has been found and I have a nasty fix somewhere in my inbox - it involves reverting a patch which doesn't revert properly. I haven't got onto looking at it yet, sorry. Zan, check this thread http://marc.info/?t=11968982411r=1w=2 for unholy details. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH] SCSI: make pcmcia directory use obj-y|m instead of subdir-y|m
Sam Ravnborg wrote: On Fri, Dec 07, 2007 at 10:36:23PM +0900, Tejun Heo wrote: subdir-y|m isn't supposed to contain modules or built-in components. Change subdir-$(CONFIG_PCMCIA) to obj-$(CONFIG_PCMCIA). Signed-off-by: Tejun Heo [EMAIL PROTECTED] Cc: Sam Ravnborg [EMAIL PROTECTED] Cc: James Bottomley [EMAIL PROTECTED] Ack-by: Sam Ravnborg [EMAIL PROTECTED] Thanks. I guess this should go through SCSI tree. James, can you please forward this upstream? -- tejun - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: scsi_wait_scan Kconfig option
Hi Matthew, On Fri, 7 Dec 2007 12:47:56 -0700 Matthew Wilcox [EMAIL PROTECTED] wrote: On Fri, Dec 07, 2007 at 07:39:53PM +, Nick Warne wrote: I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... You have modules on ... which means you might decide to load a scsi driver as a module. Maybe one that isn't part of the source tree. The scsi_wait_scan module is only 1500 bytes. Apart from a sense of ideological purity (odd in someone who chooses to use nVidia rather than, say, nv or nouveau), this really isn't a problem. Alas the card I have isn't supported, but that debate isn't for here. OK, I only have SCSI set for USB storage etc. I find it strange that this one and only option in the whole of Kconfig builds a module, and yet, even though I know I will never need it, I can't stop it. Surely if people build their own kernels, they should know (and) be allowed to configure such options? Nick -- Free Software Foundation Associate Member 5508 - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
On Sat, 2007-12-08 at 09:43 +1300, Michael Cree wrote: Bob Tracy wrote: That was quick :-). Backing out the sysctl_check.c diff gives me a working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though. Michael Cree: could you try backing out the diff below from your 2.6.24-rc3 tree and see if things are now working for you? Yes (conference is now over). I backed out the sysctl_check patch from 2.6.24-rc3 and, indeed, got a working kernel. The working kernel (was probably 2.6.24-rc3 less sysctl_check patch, but might have been a 2.6.23 variant) has the following in /sys/block alpha:~# grep . /sys/block/sda/*/dev /sys/block/sda/sda1/dev:8:1 /sys/block/sda/sda2/dev:8:2 /sys/block/sda/sda3/dev:8:3 /sys/block/sda/sda4/dev:8:4 /sys/block/sda/sda5/dev:8:5 I failed to spot any difference (other than the formatting of the dates) between the two! Yeah, that looks all fine. What distro is that, and what's the udev version? You are booting your kernel with an initramfs? Is the udev daemon (still) running while it fails? If you run /sbin/udevtrigger, do the nodes appear? Kay - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [BUG] 2.6.23-rc3 can't see sd partitions on Alpha
Ingo Molnar wrote:
* Bob Tracy [EMAIL PROTECTED] wrote:
Current state of the source tree is the 6f37ac... version, so I'll
start backing out the above diffs in related groups and continue
until I've got a working kernel. For lack of an obvious target,
I'll start with the seemingly innocuous change to sysctl_check.c.
I'll report back when I've got something.
That was quick :-). Backing out the sysctl_check.c diff gives me a
working kernel. Beats the [EMAIL PROTECTED] out of me how/why, though.
Michael Cree: could you try backing out the diff below from your
2.6.24-rc3 tree and see if things are now working for you?
Here's uname -a, just to confirm (maybe) I'm running on what I say
works:
Linux smirkin 2.6.24-rc2-g6f37ac79-dirty #2 Fri Dec 7 08:03:12 CST 2007
alpha
Here's the diff I backed out (patch -R). It's short...
diff --git a/kernel/sysctl_check.c b/kernel/sysctl_check.c
index 5a2f2b2..4abc6d2 100644
--- a/kernel/sysctl_check.c
+++ b/kernel/sysctl_check.c
@@ -738,7 +738,7 @@ static struct trans_ctl_table trans_net_table[] = {
{ NET_ROSE, rose, trans_net_rose_table },
{ NET_IPV6, ipv6, trans_net_ipv6_table },
{ NET_X25, x25, trans_net_x25_table },
- { NET_TR, tr, trans_net_tr_table },
+ { NET_TR, token-ring, trans_net_tr_table },
{ NET_DECNET, decnet, trans_net_decnet_table },
/* NET_ECONET not used */
{ NET_SCTP, sctp, trans_net_sctp_table },
reverting this makes the kernel image shorter by 8 bytes - so perhaps
some alignment issue somewhere? Or something gets overflown? Does any of
this get actually used by your bootup?
Dunno... The dmesg output is not terribly useful here, because most of
the interesting stuff concerning udev startup that appears on the
console never makes it into a log. Note that, for the bad cases, I
don't see the same console output that Michael reported, although the
net effect is the same: the partitions don't get found, so I'm offered
the chance to enter my root password and do some poking around, and
when I do, none of the block devices are present under /dev.
I'm open to suggestions on how to take this analysis further. Michael
indicated he's running a conference this week, so I don't know when he'll
be able to come up for air.
--
Bob Tracy | They couldn't hit an elephant at this dist-
[EMAIL PROTECTED] | - Last words of Union General John Sedgwick,
| Battle of Spotsylvania Court House, U.S. Civil War
-
To unsubscribe from this list: send the line unsubscribe linux-scsi in
the body of a message to [EMAIL PROTECTED]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Fw: scsi_wait_scan Kconfig option
On Fri, Dec 07, 2007 at 07:39:53PM +, Nick Warne wrote: I try not to build a modular kernel, but only have modules ON due to nVidia (sigh). So I was semi-surprised when I saw the scsi_wait_scan module being built again, yet NO WHERE in menuconfig is it present to turn OFF. Even if I hand edit .config, make puts it back again... You have modules on ... which means you might decide to load a scsi driver as a module. Maybe one that isn't part of the source tree. The scsi_wait_scan module is only 1500 bytes. Apart from a sense of ideological purity (odd in someone who chooses to use nVidia rather than, say, nv or nouveau), this really isn't a problem. -- Intel are signing my paycheques ... these opinions are still mine Bill, look, we understand that you're interested in selling us this operating system, but compare it to ours. We can't possibly take such a retrograde step. - To unsubscribe from this list: send the line unsubscribe linux-scsi in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
