Menu
▾
▴
linuxsh-shmedia-dev — Linux kernel development for the SHmedia architecture
You can subscribe to this list here.
| 2002 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(3) |
Jun
(11) |
Jul
(5) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
|
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2003 |
Jan
|
Feb
|
Mar
(18) |
Apr
(7) |
May
(8) |
Jun
(19) |
Jul
(16) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
| 2004 |
Jan
|
Feb
|
Mar
|
Apr
|
May
(8) |
Jun
|
Jul
(2) |
Aug
(1) |
Sep
(7) |
Oct
|
Nov
|
Dec
(2) |
| 2005 |
Jan
(3) |
Feb
(2) |
Mar
|
Apr
|
May
(10) |
Jun
|
Jul
(1) |
Aug
(3) |
Sep
|
Oct
|
Nov
(4) |
Dec
(1) |
| 2006 |
Jan
(41) |
Feb
(41) |
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2007 |
Jan
(1) |
Feb
|
Mar
|
Apr
(1) |
May
|
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
(1) |
Nov
(1) |
Dec
|
|
From: Richard C. <Ric...@su...> - 2004-07-02 15:10:21
|
Hi Jamie * Jamie Lokier <ja...@sh...> [2004-07-02]: > > Richard Henderson wrote: > > > Richard raises an interesting point: exec-only pages are useless if > > > the code needs to read jump tables and constant pools. It seems very > > > likely Alpha and IA64 have these. > > > > Only if the processor is crippled enough that mixing jump tables and > > constant pools in the same pages as code is considered reasonable. > > That's a good point, if the i-cache and/or DTLB are separate from > d-cache and/or DTLB. Then it makes more sense to put tables in a > separate address block. > > However if the caches are unified then it makes sense to put them > together. Somehow I doubt if any of these 64-bit chips have unified > i- and d-caches though :) For the SH-4, and the SH-5 in SHcompact mode, the insertion of constant pools in amongst the code is essential. The SH-4 instruction set has specific "load word/longword from 2N/4N bytes forward of current PC" instructions (mov.[wl] @(disp,PC),Rm) for this. It seems a reasonable enough way of handling large immediates in a 16-bit encoding. For SH-5 in SHmedia mode, it probably isn't really necessary to put switch tables inside the .text section, but it's what the current toolchains do. > > Anyway, that's a strawman -- it's the toolchain's job to get the bits > > on the pt_load segments correct. > > > > If the pt_load segment or the mmap prot argument says execute-only, > > then you should honor it. > > In other words, PA-RISC and SH64 kernels _should_ create exec-only > pages if requested, as the hardware can do it, right? > > And the toolchain _should_ ask read permssion for code segments, if > (and only if) the compiler has generated code which needs that, right? As it turns out, it looks like the SH-5 toolchains already do that. The kernel was forcing readability onto mappings unnecessarily. I've done some local fixes to sh64/2.6 today, and the results of the program are now coming out: Requested PROT | --- R-- -W- RW- --X R-X -WX RWX ======================================================================== MAP_SHARED | --- r-- -w- rw- --x r-x -wx rwx MAP_PRIVATE | --- r-- -w- rw- --x r-x -wx rwx -- Richard \\\ SH-4/SH-5 Core & Debug Architect Curnow \\\ SuperH (UK) Ltd, Bristol |
|
From: Jamie L. <ja...@sh...> - 2004-07-01 22:42:40
|
Alpha and IA64 are the only Linux architecture where PROT_EXEC by
itself results in exec-only pages. Interestingly, the hardware of
some other architectures _could_ implement exec-only pages, but they
chose not to:
The PA-RISC pgtable.h says:
"We could have an execute only page using "gateway - promote
to priv level 3", but that is kind of silly. So, the way
things are defined now, we must always have read permission
for pages with execute permission. For the fun of it we'll go
ahead and support write only pages."
Richard Curnow working on the SH64 port says:
"Although the hardware is capable of distinguish R and X, the kernel
always allows R if X is specified to mmap(). This is for 2 reasons :
1. jump tables for switch() get embedded into the code in
32-bit (SHmedia) mode
2. constant pools embedded in the code in 16-bit
(SHcompact, i.e. SH-4 compatible) mode
so in practice an exec-only page is pretty useless to a
typical userland program."
Richard raises an interesting point: exec-only pages are useless if
the code needs to read jump tables and constant pools. It seems very
likely Alpha and IA64 have these.
The point is: should the automatic addition of read permission be
kernel policy (as on SH64 and PA-RISC), or should it be for userspace
policy to get right as real code probably needs it (as on Alpha and IA64)?
Does anyone think there's a "right" behaviour which current
or future Linux ports should try to conform to? Should any of the
current ones be changed?
I'm just making sure all 4 know about each others behaviour before I
wash my hands of this observation. :)
Cheers,
-- Jamie
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:43:03
|
Hi Marcelo,
Here's the final patch for the time being, still against 2.4.26:
[sh64] Modify the reserved effective addresses used by the cache
coherency functions to allow more choice in the the effective address at
which the kernel itself is executed.
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040504--patch-3/arch/sh64/mm/cache.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-4/arch/sh64/mm/cache.c 2004-05-04 14:11:16.000000000 +0100
@@ -474,7 +474,7 @@
/* Assumes this address (+ (2**n_synbits) pages up from it) aren't used for
anything else in the kernel */
-#define MAGIC_PAGE0_START 0xffffffffe0000000ULL
+#define MAGIC_PAGE0_START 0xffffffffec000000ULL
static void sh64_dcache_purge_coloured_phy_page(unsigned long paddr, unsigned long eaddr)
{
@@ -740,8 +740,8 @@
/****************************************************************************/
/* These *MUST* lie in an area of virtual address space that's otherwise unused. */
-#define UNIQUE_EADDR_START 0xc0000000UL
-#define UNIQUE_EADDR_END 0xd0000000UL
+#define UNIQUE_EADDR_START 0xe0000000UL
+#define UNIQUE_EADDR_END 0xe8000000UL
static unsigned long sh64_make_unique_eaddr(unsigned long user_eaddr, unsigned long paddr)
{
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:39:11
|
Hi Marcelo, Still against 2.4.26: [sh64] Allow base of RAM to be other than 512Mb-aligned. (Align the base address down when creating the kernel's superpage entries in the ITLB and DTLB). Please apply. Cheers Richard --- sh64--to-marcelo--040504--patch-2/arch/sh64/kernel/head.S 2004-04-30 12:53:29.000000000 +0100 +++ sh64--to-marcelo--040504--patch-3/arch/sh64/kernel/head.S 2004-05-04 14:10:18.000000000 +0100 @@ -37,18 +37,29 @@ #define MMUDR_END DTLB_LAST_VAR_UNRESTRICTED+TLB_STEP #define MMUDR_STEP TLB_STEP +/* Safety check : CONFIG_CACHED_MEMORY_OFFSET has to be a multiple of 512Mb */ +#if (CONFIG_CACHED_MEMORY_OFFSET & ((1UL<<29)-1)) +#error "CONFIG_CACHED_MEMORY_OFFSET must be a multiple of 512Mb" +#endif + /* * MMU defines: Fixed TLBs. */ -#define MMUIR_TEXT_H 0x0000000000000003 | (CONFIG_CACHED_MEMORY_OFFSET + CONFIG_MEMORY_START) +/* Deal safely with the case where the base of RAM is not 512Mb aligned */ + +#define ALIGN_512M_MASK (0xffffffffe0000000) +#define ALIGNED_EFFECTIVE ((CONFIG_CACHED_MEMORY_OFFSET + CONFIG_MEMORY_START) & ALIGN_512M_MASK) +#define ALIGNED_PHYSICAL (CONFIG_MEMORY_START & ALIGN_512M_MASK) + +#define MMUIR_TEXT_H (0x0000000000000003 | ALIGNED_EFFECTIVE) /* Enabled, Shared, ASID 0, Eff. Add. 0xA0000000 */ -#define MMUIR_TEXT_L 0x000000000000009a | (CONFIG_MEMORY_START) +#define MMUIR_TEXT_L (0x000000000000009a | ALIGNED_PHYSICAL) /* 512 Mb, Cacheable, Write-back, execute, Not User, Ph. Add. */ -#define MMUDR_CACHED_H 0x0000000000000003 | (CONFIG_CACHED_MEMORY_OFFSET + CONFIG_MEMORY_START) +#define MMUDR_CACHED_H 0x0000000000000003 | ALIGNED_EFFECTIVE /* Enabled, Shared, ASID 0, Eff. Add. 0xA0000000 */ -#define MMUDR_CACHED_L 0x000000000000015a | (CONFIG_MEMORY_START) +#define MMUDR_CACHED_L 0x000000000000015a | ALIGNED_PHYSICAL /* 512 Mb, Cacheable, Write-back, read/write, Not User, Ph. Add. */ #ifdef CONFIG_ICACHE_DISABLED @@ -209,15 +220,19 @@ /* Map one big (512Mb) page for ITLB */ movi MMUIR_FIRST, r21 movi MMUIR_TEXT_L, r22 /* PTEL first */ + add.l r22, r63, r22 /* Sign extend */ putcfg r21, 1, r22 /* Set MMUIR[0].PTEL */ movi MMUIR_TEXT_H, r22 /* PTEH last */ + add.l r22, r63, r22 /* Sign extend */ putcfg r21, 0, r22 /* Set MMUIR[0].PTEH */ /* Map one big CACHED (512Mb) page for DTLB */ movi MMUDR_FIRST, r21 movi MMUDR_CACHED_L, r22 /* PTEL first */ + add.l r22, r63, r22 /* Sign extend */ putcfg r21, 1, r22 /* Set MMUDR[0].PTEL */ movi MMUDR_CACHED_H, r22 /* PTEH last */ + add.l r22, r63, r22 /* Sign extend */ putcfg r21, 0, r22 /* Set MMUDR[0].PTEH */ /* -- Richard \\\ SH-4/SH-5 Core & Debug Architect Curnow \\\ SuperH (UK) Ltd, Bristol |
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:37:20
|
Hi Marcelo,
Also against 2.4.26:
[sh64] Decouple io_addr handling to allow building for Cayman without
supporting PCI. Tidy up naming + comments to emphasize when entities
relate to the Cayman SMSC SuperIO chip (as distinct from the SMSC LAN
controller chip.)
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040504--patch-1/arch/sh64/lib/io.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/arch/sh64/lib/io.c 2004-05-04 14:09:00.000000000 +0100
@@ -27,17 +27,23 @@
#define dprintk(x...)
-//#define io_addr(x) (((unsigned)(x) & 0x000fffff)| PCI_ST50_IO_ADDR )
-
+static int io_addr(int x) {
+ if (x < 0x400) {
#ifdef CONFIG_SH_CAYMAN
-extern unsigned long smsc_virt;
-extern unsigned long pciio_virt;
-#define io_addr(x) ( ((x)<0x400) ? \
- (((x) << 2)|smsc_virt) : \
- ((unsigned long)(x)+pciio_virt) )
+ return (x << 2) | smsc_superio_virt;
+#else
+ panic ("Illegal access to I/O port 0x%04x\n", x);
+ return 0;
+#endif
+ } else {
+#ifdef CONFIG_PCI
+ return (x + pciio_virt);
#else
-#define io_addr(x) ((unsigned long)(x)+pciio_virt)
+ panic ("Illegal access to I/O port 0x%04x\n", x);
+ return 0;
#endif
+ }
+}
unsigned long inb(unsigned long port)
{
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--patch-1/arch/sh64/mach-cayman/irq.c sh64--to-marcelo--040504--patch-2/arch/sh64/mach-cayman/irq.c
--- sh64--to-marcelo--040504--patch-1/arch/sh64/mach-cayman/irq.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/arch/sh64/mach-cayman/irq.c 2004-05-04 14:09:00.000000000 +0100
@@ -27,9 +27,12 @@
#define EPLD_STATUS_BASE (epld_virt + 0x10)
#define EPLD_MASK_BASE (epld_virt + 0x20)
+/* Note the SMSC SuperIO chip and SMSC LAN chip interrupts are all muxed onto
+ the same SH-5 interrupt */
+
static void cayman_interrupt_smsc(int irq, void *dev_id, struct pt_regs *regs)
{
- printk(KERN_INFO "CAYMAN: spurious interrupt\n");
+ printk(KERN_INFO "CAYMAN: spurious SMSC interrupt\n");
}
static void cayman_interrupt_pci2(int irq, void *dev_id, struct pt_regs *regs)
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--patch-1/arch/sh64/mach-cayman/setup.c sh64--to-marcelo--040504--patch-2/arch/sh64/mach-cayman/setup.c
--- sh64--to-marcelo--040504--patch-1/arch/sh64/mach-cayman/setup.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/arch/sh64/mach-cayman/setup.c 2004-05-04 14:09:00.000000000 +0100
@@ -74,7 +74,7 @@
#define ITI TOP_PRIORITY /* WDT Ints */
/* Setup for the SMSC FDC37C935 */
-#define SMSC_BASE 0x04000000
+#define SMSC_SUPERIO_BASE 0x04000000
#define SMSC_CONFIG_PORT_ADDR 0x3f0
#define SMSC_INDEX_PORT_ADDR SMSC_CONFIG_PORT_ADDR
#define SMSC_DATA_PORT_ADDR 0x3f1
@@ -91,14 +91,14 @@
#define SMSC_KEYBOARD_DEVICE 7
-#define SMSC_READ_INDEXED(index) ({ \
+#define SMSC_SUPERIO_READ_INDEXED(index) ({ \
outb((index), SMSC_INDEX_PORT_ADDR); \
inb(SMSC_DATA_PORT_ADDR); })
-#define SMSC_WRITE_INDEXED(val, index) ({ \
+#define SMSC_SUPERIO_WRITE_INDEXED(val, index) ({ \
outb((index), SMSC_INDEX_PORT_ADDR); \
outb((val), SMSC_DATA_PORT_ADDR); })
-unsigned long smsc_virt;
+unsigned long smsc_superio_virt;
/*
* Platform dependent structures: maps and parms block.
@@ -145,13 +145,13 @@
RES, RES, RES, RES, RES, RES, RES, ITI, /* IRQ 56-63 */
};
-static int __init smsc_setup(void)
+static int __init smsc_superio_setup(void)
{
unsigned char devid, devrev;
- smsc_virt = onchip_remap(SMSC_BASE, 1024, "SMSC");
- if (!smsc_virt) {
- panic("Unable to remap SMSC\n");
+ smsc_superio_virt = onchip_remap(SMSC_SUPERIO_BASE, 1024, "SMSC SuperIO");
+ if (!smsc_superio_virt) {
+ panic("Unable to remap SMSC SuperIO\n");
}
/* Initially the chip is in run state */
@@ -160,20 +160,20 @@
outb(SMSC_ENTER_CONFIG_KEY, SMSC_CONFIG_PORT_ADDR);
/* Read device ID info */
- devid = SMSC_READ_INDEXED(SMSC_DEVICE_ID_INDEX);
- devrev = SMSC_READ_INDEXED(SMSC_DEVICE_REV_INDEX);
- printk("SMSC devid %02x rev %02x\n", devid, devrev);
+ devid = SMSC_SUPERIO_READ_INDEXED(SMSC_DEVICE_ID_INDEX);
+ devrev = SMSC_SUPERIO_READ_INDEXED(SMSC_DEVICE_REV_INDEX);
+ printk("SMSC SuperIO devid %02x rev %02x\n", devid, devrev);
/* Select the keyboard device */
- SMSC_WRITE_INDEXED(SMSC_KEYBOARD_DEVICE, SMCS_LOGICAL_DEV_INDEX);
+ SMSC_SUPERIO_WRITE_INDEXED(SMSC_KEYBOARD_DEVICE, SMCS_LOGICAL_DEV_INDEX);
/* enable it */
- SMSC_WRITE_INDEXED(1, SMSC_ACTIVATE_INDEX);
+ SMSC_SUPERIO_WRITE_INDEXED(1, SMSC_ACTIVATE_INDEX);
/* Select the interrupts */
/* On a PC keyboard is IRQ1, mouse is IRQ12 */
- SMSC_WRITE_INDEXED(1, SMSC_PRIMARY_INT_INDEX);
- SMSC_WRITE_INDEXED(12, SMSC_SECONDARY_INT_INDEX);
+ SMSC_SUPERIO_WRITE_INDEXED(1, SMSC_PRIMARY_INT_INDEX);
+ SMSC_SUPERIO_WRITE_INDEXED(12, SMSC_SECONDARY_INT_INDEX);
/* Exit the configuraton state */
outb(SMSC_EXIT_CONFIG_KEY, SMSC_CONFIG_PORT_ADDR);
@@ -184,7 +184,7 @@
/* This is grotty, but, because kernel is always referenced on the link line
* before any devices, this is safe.
*/
-__initcall(smsc_setup);
+__initcall(smsc_superio_setup);
void __init platform_setup(void)
{
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--patch-1/include/asm-sh64/cayman.h sh64--to-marcelo--040504--patch-2/include/asm-sh64/cayman.h
--- sh64--to-marcelo--040504--patch-1/include/asm-sh64/cayman.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/include/asm-sh64/cayman.h 2004-05-04 14:09:00.000000000 +0100
@@ -13,7 +13,7 @@
*/
-/* Setup for the SMSC FDC37C935 */
+/* Setup for the SMSC FDC37C935 / LAN91C100FD */
#define SMSC_IRQ IRQ_IRL1
/* Setup for PCI Bus 2, which transmits interrupts via the EPLD */
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--patch-1/include/asm-sh64/io.h sh64--to-marcelo--040504--patch-2/include/asm-sh64/io.h
--- sh64--to-marcelo--040504--patch-1/include/asm-sh64/io.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/include/asm-sh64/io.h 2004-05-04 14:09:00.000000000 +0100
@@ -107,6 +107,13 @@
#ifdef __KERNEL__
+#ifdef CONFIG_SH_CAYMAN
+extern unsigned long smsc_superio_virt;
+#endif
+#ifdef CONFIG_PCI
+extern unsigned long pciio_virt;
+#endif
+
#define IO_SPACE_LIMIT 0xffffffff
/*
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--patch-1/include/asm-sh64/keyboard.h sh64--to-marcelo--040504--patch-2/include/asm-sh64/keyboard.h
--- sh64--to-marcelo--040504--patch-1/include/asm-sh64/keyboard.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-2/include/asm-sh64/keyboard.h 2004-05-04 14:09:00.000000000 +0100
@@ -19,7 +19,7 @@
#include <asm/io.h>
#ifdef CONFIG_SH_CAYMAN
-#define KEYBOARD_IRQ (START_EXT_IRQS + 2) /* SMSC IRQ 1 */
+#define KEYBOARD_IRQ (START_EXT_IRQS + 2) /* SMSC SuperIO IRQ 1 */
#endif
#define DISABLE_KBD_DURING_INTERRUPTS 0
@@ -61,7 +61,7 @@
*/
#ifdef CONFIG_SH_CAYMAN
-#define AUX_IRQ (START_EXT_IRQS + 6) /* SMSC IRQ12 */
+#define AUX_IRQ (START_EXT_IRQS + 6) /* SMSC SuperIO IRQ12 */
#endif
#define aux_request_irq(hand, dev_id) \
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:34:38
|
Hi Marcelo,
Also against 2.4.26:
[sh64] Remove refs to obsolete CONFIG_UNCACHED_MEMORY_OFFSET option
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040504--base-0/arch/sh64/config.in 2004-05-04 13:56:04.000000000 +0100
+++ sh64--to-marcelo--040504--patch-1/arch/sh64/config.in 2004-05-04 14:08:27.000000000 +0100
@@ -58,8 +58,7 @@
# Use 32-bit addressing for now.
# EMI based.
-# P2 (UNCACHED) required to use identity mapping
-# P1 (CACHED) assumes non-identity.
+# (CACHED) assumes non-identity.
#
# Memory options
@@ -68,7 +67,6 @@
int 'Memory size (in MB)' CONFIG_MEMORY_SIZE_IN_MB 64
hex 'Cached Area Offset' CONFIG_CACHED_MEMORY_OFFSET 20000000
-hex 'Uncached Area Offset' CONFIG_UNCACHED_MEMORY_OFFSET 00000000
hex 'Physical memory start address' CONFIG_MEMORY_START 80000000
#
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040504--base-0/arch/sh64/vmlinux.lds.S sh64--to-marcelo--040504--patch-1/arch/sh64/vmlinux.lds.S
--- sh64--to-marcelo--040504--base-0/arch/sh64/vmlinux.lds.S 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040504--patch-1/arch/sh64/vmlinux.lds.S 2004-05-04 14:08:27.000000000 +0100
@@ -38,7 +38,6 @@
OUTPUT_ARCH(sh:sh5)
#define C_PHYS(x) AT (ADDR(x) - CONFIG_CACHED_MEMORY_OFFSET)
-#define U_PHYS(x) AT (ADDR(x) - CONFIG_UNCACHED_MEMORY_OFFSET)
ENTRY(__start)
SECTIONS
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:32:05
|
Hi Marcelo,
Another patch against 2.4.26:
[sh64] Add a new config option to selectively enable the SR.WATCH bit
during boot. If enabled, the bit remains set in SR in both kernel and
user mode. It allows hardware watchpoints and tracing to be set up and
used across the debug link to help in diagnosing problems.
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040430--patch-3/arch/sh64/config.in 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-4/arch/sh64/config.in 2004-05-04 13:56:04.000000000 +0100
@@ -304,6 +304,7 @@
bool "Debug: audit page tables on return from syscall/exception/interrupt" CONFIG_SH64_PAGE_TABLE_AUDIT
dep_bool "Debug: report TLB fill/purge activity through /proc/tlb" CONFIG_SH64_PROC_TLB $CONFIG_PROC_FS
dep_bool "Debug: report ASIDS through /proc/asids" CONFIG_SH64_PROC_ASIDS $CONFIG_PROC_FS
+bool "Debug: set SR.WATCH to enable hardware watchpoints and trace" CONFIG_SH64_SR_WATCH
int 'Kernel messages buffer length shift (0 = default)' CONFIG_LOG_BUF_SHIFT 0
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040430--patch-3/arch/sh64/defconfig sh64--to-marcelo--040430--patch-4/arch/sh64/defconfig
--- sh64--to-marcelo--040430--patch-3/arch/sh64/defconfig 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-4/arch/sh64/defconfig 2004-05-04 13:56:04.000000000 +0100
@@ -490,6 +490,7 @@
# CONFIG_SH64_PAGE_TABLE_AUDIT is not set
# CONFIG_SH64_PROC_TLB is not set
# CONFIG_SH64_PROC_ASIDS is not set
+# CONFIG_SH64_SR_WATCH is not set
#
# Library routines
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040430--patch-3/arch/sh64/kernel/entry.S sh64--to-marcelo--040430--patch-4/arch/sh64/kernel/entry.S
--- sh64--to-marcelo--040430--patch-3/arch/sh64/kernel/entry.S 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-4/arch/sh64/kernel/entry.S 2004-05-04 13:56:04.000000000 +0100
@@ -1607,12 +1607,6 @@
shlli r36, 31, r36
andc r1, r36, r1 /* turn sr.mmu off in real mode section */
- /* Bodge : force sr.watch high on return. Can't understand why else this
- isn't happening. */
- movi 1, r38
- shlli r38, 26, r38
- or r38, r0, r0
-
putcon r1, ssr
_loada .poke0-CONFIG_CACHED_MEMORY_OFFSET, r36 /* real mode target address */
_loada 1f, r37 /* virtual mode return addr */
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040430--patch-3/include/asm-sh64/processor.h sh64--to-marcelo--040430--patch-4/include/asm-sh64/processor.h
--- sh64--to-marcelo--040430--patch-3/include/asm-sh64/processor.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-4/include/asm-sh64/processor.h 2004-05-04 13:56:04.000000000 +0100
@@ -101,7 +101,7 @@
*/
#define SR_FD 0x00008000
-#ifdef ST_DEBUG
+#if defined(CONFIG_SH64_SR_WATCH)
#define SR_MMU 0x84000000
#else
#define SR_MMU 0x80000000
diff -urN -x {arch} -x ',,*' -x .arch-ids sh64--to-marcelo--040430--patch-3/include/asm-sh64/registers.h sh64--to-marcelo--040430--patch-4/include/asm-sh64/registers.h
--- sh64--to-marcelo--040430--patch-3/include/asm-sh64/registers.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-4/include/asm-sh64/registers.h 2004-05-04 13:56:04.000000000 +0100
@@ -115,7 +115,7 @@
#define SR_HARMLESS 0x00000000500080f0 /* Write ignores for most */
#define SR_ENABLE_FPU 0xffffffffffff7fff /* AND with this */
-#ifdef ST_DEBUG
+#if defined (CONFIG_SH64_SR_WATCH)
#define SR_ENABLE_MMU 0x0000000084000000 /* OR with this */
#else
#define SR_ENABLE_MMU 0x0000000080000000 /* OR with this */
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:28:29
|
Hi Marcelo,
Another patch (still against 2.4.26), the subject line says it all.
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040430--patch-2/arch/sh64/kernel/time.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-3/arch/sh64/kernel/time.c 2004-04-30 16:07:11.000000000 +0100
@@ -404,13 +404,14 @@
{
unsigned int count;
unsigned long __dummy;
-
+ unsigned long ctc_val_init, ctc_val;
+
/*
** Regardless the toolchain, force the compiler to use the
** arbitrary register r3 as a clock tick counter.
** NOTE: r3 must be in accordance with rtc_interrupt()
*/
- register unsigned long long __clock_tick_count __asm__ ("r3");
+ register unsigned long long __rtc_irq_flag __asm__ ("r3");
sti();
do {} while (ctrl_inb(R64CNT) != 0);
@@ -419,13 +420,17 @@
/*
* r3 is arbitrary. CDC does not support "=z".
*/
+ ctc_val_init = 0xffffffff;
+ ctc_val = ctc_val_init;
+
asm volatile("gettr " __t0 ", %1\n\t"
+ "putcon %0, cr62\n\t"
"and %2, r63, %2\n\t"
"_pta 4, " __t0 "\n\t"
- "addi %0, 1, %0\n\t"
"beq/l %2, r63, " __t0 "\n\t"
"ptabs %1, " __t0 "\n\t"
- : "=r"(count), "=r" (__dummy), "=r" (__clock_tick_count)
+ "getcon cr62, %0\n\t"
+ : "=r"(ctc_val), "=r" (__dummy), "=r" (__rtc_irq_flag)
: "0" (0));
cli();
/*
@@ -445,11 +450,13 @@
* ....
*
* SH-5:
- * CPU clock = 2 stages * loop
- * ....
+ * Use CTC register to count. This approach returns the right value
+ * even if the I-cache is disabled (e.g. whilst debugging.)
*
*/
+ count = ctc_val_init - ctc_val; /* CTC counts down */
+
#if defined (CONFIG_SH_SIMULATOR)
/*
* Let's pretend we are a 5MHz SH-5 to avoid a too
@@ -457,18 +464,13 @@
* calibration within a reasonable time.
*/
return 5000000;
-#elif defined (CONFIG_ICACHE_DISABLED)
- /*
- * Let's pretend we are a 300MHz SH-5.
- */
- return 300000000;
#else
/*
* This really is count by the number of clock cycles
- * per loop (2) by the ratio between a complete R64CNT
+ * by the ratio between a complete R64CNT
* wrap-around (128) and CUI interrupt being raised (64).
*/
- return count*2*2;
+ return count*2;
#endif
}
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:25:52
|
Hi Marcelo,
This patch was created by Sean McGoogan <sea...@su...>:
[sh64] Bug fix: add clearer (more explicit) liveness dependency
constraints to _syscalln() assembler inline functions, to stop more
aggressive compiler optimisers passing the arguments pertaining to the
TRAPA in arbitrary registers. This is an essential bug fix for sh64, to
remove some dangerous congenital assumptions in the register
assignments.
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040430--patch-1/include/asm-sh64/unistd.h 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-2/include/asm-sh64/unistd.h 2004-04-30 16:05:35.000000000 +0100
@@ -287,20 +287,31 @@
type name(void) \
{ \
register unsigned long __sc0 __asm__ ("r9") = ((0x10 << 16) | __NR_##name); \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "()" \
: "=r" (__sc0) \
: "r" (__sc0) ); \
__syscall_return(type,__sc0); \
}
+ /*
+ * The apparent spurious "dummy" assembler comment is *needed*,
+ * as without it, the compiler treats the arg<n> variables
+ * as no longer live just before the asm. The compiler can
+ * then optimize the storage into any registers it wishes.
+ * The additional dummy statement forces the compiler to put
+ * the arguments into the correct registers before the TRAPA.
+ */
#define _syscall1(type,name,type1,arg1) \
type name(type1 arg1) \
{ \
register unsigned long __sc0 __asm__ ("r9") = ((0x11 << 16) | __NR_##name); \
register unsigned long __sc2 __asm__ ("r2") = (unsigned long) arg1; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2)" \
: "=r" (__sc0) \
: "r" (__sc0), "r" (__sc2)); \
+__asm__ __volatile__ ("!dummy %0 %1" \
+ : \
+ : "r" (__sc0), "r" (__sc2)); \
__syscall_return(type,__sc0); \
}
@@ -310,9 +321,12 @@
register unsigned long __sc0 __asm__ ("r9") = ((0x12 << 16) | __NR_##name); \
register unsigned long __sc2 __asm__ ("r2") = (unsigned long) arg1; \
register unsigned long __sc3 __asm__ ("r3") = (unsigned long) arg2; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2,%3)" \
: "=r" (__sc0) \
: "r" (__sc0), "r" (__sc2), "r" (__sc3) ); \
+__asm__ __volatile__ ("!dummy %0 %1 %2" \
+ : \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3) ); \
__syscall_return(type,__sc0); \
}
@@ -323,9 +337,12 @@
register unsigned long __sc2 __asm__ ("r2") = (unsigned long) arg1; \
register unsigned long __sc3 __asm__ ("r3") = (unsigned long) arg2; \
register unsigned long __sc4 __asm__ ("r4") = (unsigned long) arg3; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2,%3,%4)" \
: "=r" (__sc0) \
: "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4) ); \
+__asm__ __volatile__ ("!dummy %0 %1 %2 %3" \
+ : \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4) ); \
__syscall_return(type,__sc0); \
}
@@ -337,9 +354,12 @@
register unsigned long __sc3 __asm__ ("r3") = (unsigned long) arg2; \
register unsigned long __sc4 __asm__ ("r4") = (unsigned long) arg3; \
register unsigned long __sc5 __asm__ ("r5") = (unsigned long) arg4; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2,%3,%4,%5)" \
: "=r" (__sc0) \
: "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5) );\
+__asm__ __volatile__ ("!dummy %0 %1 %2 %3 %4" \
+ : \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5) );\
__syscall_return(type,__sc0); \
}
@@ -352,9 +372,13 @@
register unsigned long __sc4 __asm__ ("r4") = (unsigned long) arg3; \
register unsigned long __sc5 __asm__ ("r5") = (unsigned long) arg4; \
register unsigned long __sc6 __asm__ ("r6") = (unsigned long) arg5; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2,%3,%4,%5,%6)" \
: "=r" (__sc0) \
- : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
+ "r" (__sc6)); \
+__asm__ __volatile__ ("!dummy %0 %1 %2 %3 %4 %5" \
+ : \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
"r" (__sc6)); \
__syscall_return(type,__sc0); \
}
@@ -369,9 +393,13 @@
register unsigned long __sc5 __asm__ ("r5") = (unsigned long) arg4; \
register unsigned long __sc6 __asm__ ("r6") = (unsigned long) arg5; \
register unsigned long __sc7 __asm__ ("r7") = (unsigned long) arg6; \
-__asm__ __volatile__ ("trapa %1" \
+__asm__ __volatile__ ("trapa %1 !\t\t\t" #name "(%2,%3,%4,%5,%6,%7)" \
: "=r" (__sc0) \
- : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
+ "r" (__sc6), "r" (__sc7)); \
+__asm__ __volatile__ ("!dummy %0 %1 %2 %3 %4 %5 %6" \
+ : \
+ : "r" (__sc0), "r" (__sc2), "r" (__sc3), "r" (__sc4), "r" (__sc5), \
"r" (__sc6), "r" (__sc7)); \
__syscall_return(type,__sc0); \
}
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: Richard C. <Ric...@su...> - 2004-05-04 14:20:53
|
Hi Marcelo,
This patch is against 2.4.26 and fixes the handling of PCI interrupts on
the Cayman board when PCI cards containing PCI bridges are plugged in.
Please apply.
Cheers
Richard
--- sh64--to-marcelo--040430--base-0/arch/sh64/kernel/pci_sh5.c 2004-04-30 12:53:29.000000000 +0100
+++ sh64--to-marcelo--040430--patch-1/arch/sh64/kernel/pci_sh5.c 2004-04-30 15:21:25.000000000 +0100
@@ -320,43 +320,70 @@
{
int result = -1;
- if (dev->bus->number == 0) {
- switch ((slot + (pin-1)) & 3) {
- case 0:
- result = IRQ_INTA;
- break;
- case 1:
- result = IRQ_INTB;
- break;
- case 2:
- result = IRQ_INTC;
- break;
- case 3:
- result = IRQ_INTD;
- break;
- }
- }
-
- if (dev->bus->number == 2) {
- switch((slot + (pin-1)) & 3) {
- case 0:
- result = IRQ_P2INTA;
- break;
- case 1:
- result = IRQ_P2INTB;
- break;
- case 2:
- result = IRQ_P2INTC;
- break;
- case 3:
- result = IRQ_P2INTD;
- break;
- }
- }
-
- dprintk("map_cayman_irq for dev %d on bus %d slot %d, pin is %d : irq=%d\n",
- dev->devfn,dev->bus->number,slot,pin,result);
+ /* The complication here is that the PCI IRQ lines from the Cayman's 2
+ 5V slots get into the CPU via a different path from the IRQ lines
+ from the 3 3.3V slots. Thus, we have to detect whether the card's
+ interrupts go via the 5V or 3.3V path, i.e. the 'bridge swizzling'
+ at the point where we cross from 5V to 3.3V is not the normal case.
+
+ The added complication is that we don't know that the 5V slots are
+ always bus 2, because a card containing a PCI-PCI bridge may be
+ plugged into a 3.3V slot, and this changes the bus numbering.
+
+ Also, the Cayman has an intermediate PCI bus that goes a custom
+ expansion board header (and to the secondary bridge). This bus has
+ never been used in practice.
+
+ The 1ary onboard PCI-PCI bridge is device 3 on bus 0
+ The 2ary onboard PCI-PCI bridge is device 0 on the 2ary bus of the 1ary bridge.
+ */
+
+ struct slot_pin {
+ int slot;
+ int pin;
+ } path[4];
+ int i=0;
+ int base;
+
+ while (dev->bus->number > 0) {
+
+ slot = path[i].slot = PCI_SLOT(dev->devfn);
+ pin = path[i].pin = bridge_swizzle(pin, slot);
+ dev = dev->bus->self;
+ i++;
+ if (i > 3) panic("PCI path to root bus too long!\n");
+ }
+ slot = PCI_SLOT(dev->devfn);
+ /* This is the slot on bus 0 through which the device is eventually
+ reachable. */
+
+ /* Now work back up. */
+ if ((slot < 3) || (i == 0)) {
+ /* Bus 0 (incl. PCI-PCI bridge itself) : perform the final
+ swizzle now. */
+ result = IRQ_INTA + bridge_swizzle(pin, slot) - 1;
+ } else {
+ i--;
+ slot = path[i].slot;
+ pin = path[i].pin;
+ if (slot > 0) {
+ panic("PCI expansion bus device found - not handled!\n");
+ } else {
+ if (i > 0) {
+ /* 5V slots */
+ i--;
+ slot = path[i].slot;
+ pin = path[i].pin;
+ /* 'pin' was swizzled earlier wrt slot, don't do it again. */
+ result = IRQ_P2INTA + (pin - 1);
+ } else {
+ /* IRQ for 2ary PCI-PCI bridge : unused */
+ result = -1;
+ }
+ }
+ }
+
return result;
}
--
Richard \\\ SH-4/SH-5 Core & Debug Architect
Curnow \\\ SuperH (UK) Ltd, Bristol
|
|
From: HAJIA M. A. <mmr...@ca...> - 2003-07-30 09:55:33
|
DEAR SIR =2F MADAM I GREET YOU IN THE NAME OF ALAH=2E I AM HAJIA MARIAM ABACHA THE WIDOW OF THE LATE GEN=2ESANI ABACHA FORMER MILITARY HEAD OF STATE OF NIGERIA WHO DIED MYSTERIOUSLY AS A RESULT OF CARDIAC ARREST=2ESINCE AFTER THE DEATH OF MY HUSBAND MY FAMILY IS UNDER RESTRICTION OF MOVEMENT AND THAT NOT WITHSTANDING=2C WE ARE BEING MOLESTED=2C POLICED AND OUR BANK ACCOUNT BOTH HERE IN NIGERIA AND ABROAD ARE BEING FROZEN BY THE NIGERIA CIVILIAN GOVERNMENT=2C FOR MORE INTERROGATION ABOUT MY HUSBAND ASSEST AND SOME VITAL DOCUMENT=2EFOLLOWING THE RECENT DICOVERY OF MY HUSBAND BANK ACCOUNT BY THE GOVERNMENT=2CWITH SWISS BANK IN WHICH THE HUGE SUM OF US$700 MILLION AND DM450 MILLION WAS LODGE=2EI THEREFORE DECIDE TO CONTACT YOU IN CONFIDENCE THAT MY HUSBAND DEPOSITED THE SUM OF US$35 MILLION DOLLARS WITH A SECURITY COMPANY UNDER THE UNBRELLA OF A FOREIGN FIRM AND THE GOVERNMENT HAS NO KNOWLEDGE OF THIS FUND=2E I THEREFORE PERSONALLY APPEAL TO YOU SERIOUSLY AND RELIGIOUSLY AS A MUSLIM BROTHER FOR URGENT ASSISTANCE TO MOVE THIS FUND INTO YOUR COUNTRY WERE I BELIEVE IT WILL BE SAFE SINCE I CANNOT LIVE THE COUNTRY DUE TO THE RESTRICTION OF MOVEMENT IMPOSED ON THE MEMBERS OF MY FAMILY BY THE NIGERIAN GOVERNMENT=2E ALL RELIVANT DOCUMENTS AS REGARDS THIS FUND IS WITH ME INCLUDING CERTIFICATE OF DEPOSIT=2E AS SOON AS YOU INDICATE YOUR INTEREST YOU CAN CONTACT MY LAWYER =28BARRISTER MILTON JOE=29 ON HIS PRIVATE LINE FOR FURTHER DETAILS ON HIS PRIVATE NUMBER=3A 234-8037194273OR CONTACT HIM THROUGH HIS MAIL =28miltonjoe=40lawyer=2Ecom=29 PLEASE REPLY URGENTLY AND TREAT WITH ABSOLUTE CONFIDENCIALITY=2E SINCERITY=2E BEST REGARD HAJIA MARIAM ABACHA=2E =28MRS=2E=29 |
|
From: Jason <hea...@se...> - 2003-07-24 07:46:33
|
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html;charset=3Diso-8859-= 1"> <HTML> <HEAD> <TITLE>Get Cash Out!</TITLE> <META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859= -1"> </HEAD> <BODY BGCOLOR=3D"#FFFFFF"> <CENTER> <TABLE BORDER=3D"0" CELLPADDING=3D"0" CELLSPACING=3D"0"> <TR> <TD COLSPAN=3D"2"> <A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort= gage4321.com/debt/images/top1.gif" WIDTH=3D"550" HEIGHT=3D"76" BORDER=3D"0= "></A></TD> </TR> <TR> <TD> <A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort= gage4321.com/debt/images/photo.jpg" WIDTH=3D"238" HEIGHT=3D"188" BORDER=3D= "0"></A></TD> <TD> <A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort= gage4321.com/debt/images/copy.gif" WIDTH=3D"312" HEIGHT=3D"188" BORDER=3D"= 0"></A></TD> </TR> <TR> <TD COLSPAN=3D"2"> <A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort= gage4321.com/debt/images/nofees.gif" WIDTH=3D"550" HEIGHT=3D"45" BORDER=3D= "0"></A></TD> </TR> <TR> <TD COLSPAN=3D"2"> <A HREF=3D"http://www.mortgage4321.com/mortc/"><IMG SRC=3D"http://www.mort= gage4321.com/debt/images/rates.gif" WIDTH=3D"550" HEIGHT=3D"41" BORDER=3D"= 0"></A></TD> </TR> </TABLE> </CENTER> </BODY><BR> </HTML><br><br>vmmb qmsqc czk djaeo jclap pwm ijdn otsfpexzlhdo thl |
|
From: Dr. S. C. <co...@si...> - 2003-07-21 05:43:36
|
FROM=3ADR=2E SOLA COLE Dear friend=2C This letter may come to you as a surprise due to the fact that we have not yet met=2Cbut kindly consider the message=2C because=2C I am determined to live for posterity=2E I wish to plead with you to join me in not only serving humanity=2Cbut to also benefit in the process=2E This message could be strange but reality will definitely dawn on you=2C if you pay some attention to its contents=2E Please accept my sincere apologies=2E In bringing this message to you=2C I have no intention of causing you any personal pains or discomfort=2E I am Dr=2E Sola Cole=2C former Special Assistant to the late Liberian President=2C who was murdered by rebels=2E President Samuel Doe=2C in his bid to fend-off rebel insurgency=2Cand since he could no longer trust the army generals=2C confidentially put in my care=2Cthe sum of $18=2C000=2C000=2E00 =28eighteen million United States dollars=29=2C for the purpose of purchasing arms and ammunitions should the need arise=2E But unfortunately=2C the need did not arise and I could not purchase these arms before he was ambushed and killed by rebels=2E I deposited the US$18=2Cmillion in an offshore bank account=2Cand I alone and no one else=2Cknew about it=2C and I could not get in touch with any arms dealer before the then President was killed=2E I am presently in Africa=2C where I am trying to set-up a consultancy on inter-regional co-operation=2E I have borne the burden for too long=2EI do not want to keep the funds any longer=2C but I can never turn it over to the brutal and tyrannical rogue regime of Charles Taylor=28then rebel leader and now Liberian president=29=2C who is still committing all sorts of atrocities on the liberian people=2C to the extent that the United Nations has imposed various sanctions on the dictatorship=2E I am NOT solicitng your help to wage a war against the regime=2C but to act as a foreign partner=2C to allow me transfer the funds to you=2Cand YOU=2C in turn=2Cwould donate a portion of it as a humanitarian gesture to the Liberian people by purchasing such essential needs like blankets=2Cmilk and so on=2Cwater-pumping machines and agricultural equipment=2C from the money after deducting your expenses and the comission of 20%=2E Please note that I could have approached the Red Cross Society=2Cbut I changed my mind on that after calculating what they would deduct as comission=2C and also=2C after rationalising the scandal that followed their mismanagement of the donations meant for the victims of the september 11th attack on the United States=2E Also note that this offer will give you a double-edged advantage =3A 1=2E as the benefactor of the Liberian people and=3B 2=2E the comission you stand to earn=2E On getting a positive response from you=2C I will send to you the secret access codes of the offshore bank-account=2E Please note that confidentiality and honesty are fundamental rules in this transaction=2E Be assured that I am a reputable personality in this country and I am mindful of the legal implications of this transaction=2Cas I intend taking care of all the legal documentation for a successful and hitch-free transaction=2E I am therefore soliciting your assistance to have this money collected by you and=2For facilitate the transfer into your nominated account=28s=29=2E You may also contact me via any of the following email addresses=3A 1=2Esocole100=40netscape=2Ecom ***PLEASE NOTE THAT YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED=2E I will give you the details of this transaction on receipt of your response to this proposal=2EThank you very much for your time and understanding=2E Yours sincerely=2C Dr Sola Cole |
|
From: Dr. S. C. <co...@si...> - 2003-07-21 04:41:46
|
FROM=3ADR=2E SOLA COLE Dear friend=2C This letter may come to you as a surprise due to the fact that we have not yet met=2Cbut kindly consider the message=2C because=2C I am determined to live for posterity=2E I wish to plead with you to join me in not only serving humanity=2Cbut to also benefit in the process=2E This message could be strange but reality will definitely dawn on you=2C if you pay some attention to its contents=2E Please accept my sincere apologies=2E In bringing this message to you=2C I have no intention of causing you any personal pains or discomfort=2E I am Dr=2E Sola Cole=2C former Special Assistant to the late Liberian President=2C who was murdered by rebels=2E President Samuel Doe=2C in his bid to fend-off rebel insurgency=2Cand since he could no longer trust the army generals=2C confidentially put in my care=2Cthe sum of $18=2C000=2C000=2E00 =28eighteen million United States dollars=29=2C for the purpose of purchasing arms and ammunitions should the need arise=2E But unfortunately=2C the need did not arise and I could not purchase these arms before he was ambushed and killed by rebels=2E I deposited the US$18=2Cmillion in an offshore bank account=2Cand I alone and no one else=2Cknew about it=2C and I could not get in touch with any arms dealer before the then President was killed=2E I am presently in Africa=2C where I am trying to set-up a consultancy on inter-regional co-operation=2E I have borne the burden for too long=2EI do not want to keep the funds any longer=2C but I can never turn it over to the brutal and tyrannical rogue regime of Charles Taylor=28then rebel leader and now Liberian president=29=2C who is still committing all sorts of atrocities on the liberian people=2C to the extent that the United Nations has imposed various sanctions on the dictatorship=2E I am NOT solicitng your help to wage a war against the regime=2C but to act as a foreign partner=2C to allow me transfer the funds to you=2Cand YOU=2C in turn=2Cwould donate a portion of it as a humanitarian gesture to the Liberian people by purchasing such essential needs like blankets=2Cmilk and so on=2Cwater-pumping machines and agricultural equipment=2C from the money after deducting your expenses and the comission of 20%=2E Please note that I could have approached the Red Cross Society=2Cbut I changed my mind on that after calculating what they would deduct as comission=2C and also=2C after rationalising the scandal that followed their mismanagement of the donations meant for the victims of the september 11th attack on the United States=2E Also note that this offer will give you a double-edged advantage =3A 1=2E as the benefactor of the Liberian people and=3B 2=2E the comission you stand to earn=2E On getting a positive response from you=2C I will send to you the secret access codes of the offshore bank-account=2E Please note that confidentiality and honesty are fundamental rules in this transaction=2E Be assured that I am a reputable personality in this country and I am mindful of the legal implications of this transaction=2Cas I intend taking care of all the legal documentation for a successful and hitch-free transaction=2E I am therefore soliciting your assistance to have this money collected by you and=2For facilitate the transfer into your nominated account=28s=29=2E You may also contact me via any of the following email addresses=3A 1=2Esocole100=40netscape=2Ecom ***PLEASE NOTE THAT YOUR CONFIDENTIALITY IN THIS TRANSACTION IS HIGHLY REQUIRED=2E I will give you the details of this transaction on receipt of your response to this proposal=2EThank you very much for your time and understanding=2E Yours sincerely=2C Dr Sola Cole |
|
From: Dr. N. T. <tni...@in...> - 2003-07-20 05:41:31
|
From=3A Dr=2E Nicholas Ted Tel=3A 234-8033074806 fax=3A 234-1-7596714 Email=3Atnicholas5=40eudoramail=2Ecom Dear sir=2FMadam=2C In order to transfer out =28USD 12=2E6 M=29 Twelve million Six Hundred United States Dollars=29 from African Development Bank=2E I have the courage to ask you to look for a reliable and honest person who will be capable for this important business believing that you will never let me down either now or in future=2E I am Dr=2E Nicholas Ted=2C the Chief Auditor of African Development Bank=28ADB=29=2E There is an account opened in this bank in 1998 and since nobody has operated on this account again=2E After going through some old files in the records=2C I discovered that if I do not remit this money out urgently it would be forfeited for nothing=2E The owner of this account is Mr=2ESmith B=2EAndreas=2C a foreigner=2Cand a miner at kruger gold co=2E=2C a geologist by profession and he died since 1998=2E No other person knows about this account or any thing concerning it=2C the account has no other beneficiary and my investigation proved to me as well that this company does not know anything about this account and the amount involved is =28USD 12=2E6M=29 Twelve Million=2C six Hundred United States Dollars million dollars=2E I want to first transfer US$6=2C000=2C000=3A00 Six million United States Dollars from this money into a safe foreigners account abroad before the rest=2C but I don't know any foreigner=2E I am only contacting you as a foreigner because this money cannot be approved to a local bank here=2C but can only be approved to any foreign account because the money is in us dollars and the former owner of the account is Mr=2E Smith B=2EAndreas he is a foreigner too=2E I know that this message will come to you as a surprise as we don't know ourselves before=2E We will sign an agreement=2C but be sure that it is real and a genuine business=2E I only got your contact address from International Business Directory=2Cwith believe in God that you will never let me down in this business=2E You are the only person that I have contacted in this business=3B so please reply urgently so that I will inform you the next step to take immediately=2E Send also your private telephone and fax number including the full details of the account to be used for the deposit=2E I want us to meet face to face or sign a binding agreement to bind us together so that you can receive this money into a foreign account or any account of your choice where the fund will be safe=2E And I will fly to your country for withdrawal and sharing and other investments=2E I am contacting you because of the need to involve a foreigner with foreign account and foreign beneficiary=2E I need your full co-operation to make this work fine because the management is ready to approve this payment to any foreigner=2C who has correct information of this account=2C which I will give to you later immediately=2C if you are able and with capability to handle such amount in strict confidence and trust according to my instructions and advice for our mutual benefit because this opportunity will never come again in my life=2E I need truthful person in this business because I don't want to make mistake I need your strong assurance and trust=2E With my position now in the office I can transfer this money to any foreigner's reliable account=2C which you can provide with assurance that this money will be intact pending my physical arrival in your country for sharing=2E I will destroy all documents of transaction immediately we receive this money leaving no trace to any place=2E You can also come to discuss with me face to face after which I will make this remittance in your presence and two of us will fly to your country at least two days ahead of the money going into the account=2E I will apply for annual leave to get visa immediately I hear from you that you are ready to act and receive thi s fund in your account=2E I will use my position and influence to effect legal approvals and onward transfer of this money to your account with appropriate clearance forms of the ministries and foreign exchange departments=2E At the conclusion of this business=2C you will be given 35% of the total amount=2C 60% will be for me=2C while 5% will be for expenses both parties might have incurred during the process of transferring=2E I look forward to your earliest reply Dr=2E Nicholas Ted |
|
From: GERARD H. <ger...@ca...> - 2003-07-18 03:09:14
|
PORT-LOUIS MAURITIUS DIRECTOR TEL=3A874-762-970-480 DIRECT FAX=3A874-762-970-481 Attn The President=2FCEO I am Mr J=2E Gerard Hardy=2C vice president=2CMauritius Commercial Bank Ltd=2E I have urgent and very confidential business proposition for you=2E On June 6=2C 1998=2C an American Oil consultant contractor with Mauritius Mining Corporation=2C Mr Charles Andason made a numbered time Fixed Deposit for twelve calendar months valuedat US$25=2C000=2C000=2E00 Twenty- five Million Dollars in my branch=2E Upon maturity=2CI sent a routine notification to his forwarding address but got no reply=2E After a month=2C we sent a reminder and finally we discovered from his contract employers=2Cthe Island of Mauritius Mining Corporation=2C that Mr Charles Andason died from an automobile accident=2E On further investigation=2C I found out that he died without making a WILL and all attempts to trace his next of kin was fruitless=2E I therefore made further investigation and discovered that Mr Charles Andason did not declare any kin or relations in all his official documents including his Bank Deposit paperwork in my Bank=2E This sum of US$25=2C000=2C000=2E00 is still sitting in my Bank and the interest is being rolled over with the principal sum at the end of each year=2E No one will ever come forward to claim it=2E According to the Island of Mauritius Law=2C at the expiration of 5=28five=29 years=2C the money will revert to the ownership of the Island of Mauritius Government if nobody applies to claim the fund=2E Consequently=2C my proposal is that I will like you as a Foreigner to stand in as the next of kin to Mr Charles Andason so that the fruits of this old man's labor will not get into the hands of some corrupt government officials=2E This is simple=2E I will like you to provide immediately your full names and address so that the Attorney will prepare the necessary documents and affidavits which will put you in place as the next of kin=2E We shall employ the service of two Attorneys for drafting and notarization of the WILL and to obtain the necessary documents and letter of probate administration in your favor for the transfer=2E A bank account in any part of the world which you will provide will then facilitate the transfer of this money to you as the beneficiary=2Fnext of kin=2E The money will be paid into your account for us to share in the ratio of 60% for me and 40% for you=2E There is no risk at all as all the paperwork for this transaction will be done by the Attorney and my position guarantees the successful execution of this transaction=2E If you are interested=2Cplease reply immediately via the private email address below=2E Upon your response=2C I shall then provide you with more details and relevant documents that will help you understand the transaction=2EPlease observe utmost confidentiality and rest assured that this transaction would be most profitable for both of us because I shall require your assistance to invest my share in your country=2E Awaiting your urgent reply via my email=3A=28gerard669=40hknetmail=2Ecom=29 Thanks and regards=2C MR J=2E GERARD HARDY DIRECTOR TEL=3A874-762-970-480 DIRECT FAX=3A874-762-970-481 |
|
From: Paul M. <le...@li...> - 2003-07-13 19:56:31
|
On Mon, Jul 07, 2003 at 03:59:35PM +0100, Richard Curnow wrote: > what. So unless the app and all relevant libraries are compiled with > -g, the backtracing doesn't proceed very far (actually, back as far as > the first frame with no -g information.) >=20 Well, based off of this, the kernel backtrace should still be accurate for backtracing through the first stack frame, just not further. This is still useful for tracking an implicit crash location with the type of crash already determined ahead of time. In my initial tests of this, I've been unwinding the stack early on, and I hadn't noticed any oddities in the backtrace at that point -- though it wasn't tracing very far back either. Anyways, from the sounds of it, we'll need to have the symbol table availab= le in the kernel to actually make much additional use out of it (and trace back much further -- due to unlinked strack frames). I'm not sure how feasible this will be under 2.4, as it doesn't support a facility for this. Under 2.5 however, turning on CONFIG_KALLSYMS builds all of that in at link time, so we should be able to do something there (other architectures use this for things like print_symbol(), so that the symbol name can be decoded directly on the initial backtrace without relying on ksymoops traces). For 2.4, we're probably better off just not worrying about it, or simply adding a comment into the existing backtrace code outlining its limited usefulness. At this point, 2.6 isn't far off, so I'd much rather focus on getting this sort of stuff functional in 2.5 instead of spending more time on 2.4 (which at this point should mostly be limited to stability fixes, in my opinion). |
|
From: Steve W. <sc...@ne...> - 2003-07-07 19:14:53
|
On Mon, 7 Jul 2003, Richard Curnow wrote:
[in-kernel stack backtrace]
> However, as it stands, I'm not sure the output is useable. When gdb
> backtraces user-land stacks, it has to use the CFI information in the
> executable to walk back up the stack. Basically I believe this is
> because sh64 doesn't really have a fixed concept of stack frame layout
Right. The stack frames are not 'linked' together.
> Now I wouldn't expect the kernel's internal backtrace to deal with this,
> for a start, it doesn't know where the vmlinux executable is to look at
> the debug info, in fact it might not even be able to see its own vmlinux
> file. So I think we must go for an approach where the stack is streamed
> out to the console and a ksymoops-like tool used offline to mangle it.
Is there any way to embed the kernel's symbol table in the kernel itself?
I ask because that's really all you need in order to make stack tracing
work on SH5. For an example, see how NetBSD's sh5 backend for the kernel
debugger does it (the symbol table _is_ available on NetBSD):
http://cvsweb.netbsd.org/bsdweb.cgi/src/sys/arch/sh5/sh5/db_trace.c
By adding simple heuristics, you can also trace back through multiple
levels of exception frame (and print register contents while you're
there).
Cheers, Steve
|
|
From: Richard C. <Ric...@su...> - 2003-07-07 14:59:50
|
Hi Paul, Some time ago I noticed that you added a stack backtrace into traps.c, but it wasn't until today that I was 'fortunate' enough to get the benefit of its output. The potential of this for debugging, compared to just the register dump, is pretty exciting (after having seen what gurus on lkml can do with just a ksymoops output, anyway). However, as it stands, I'm not sure the output is useable. When gdb backtraces user-land stacks, it has to use the CFI information in the executable to walk back up the stack. Basically I believe this is because sh64 doesn't really have a fixed concept of stack frame layout (in terms of where the SP and PC of the caller are pushed relative to the current SP, for example). e.g. without the assistance of debug information, there's no way to know whether the return address is on the stack (and if so where), still in r18, moved to another register, or what. So unless the app and all relevant libraries are compiled with -g, the backtracing doesn't proceed very far (actually, back as far as the first frame with no -g information.) Now I wouldn't expect the kernel's internal backtrace to deal with this, for a start, it doesn't know where the vmlinux executable is to look at the debug info, in fact it might not even be able to see its own vmlinux file. So I think we must go for an approach where the stack is streamed out to the console and a ksymoops-like tool used offline to mangle it. At the moment, the dumping code looks to be dumping every word on the stack that looks like it lies within the kernel address space (vmlinux or modules). However, to walk the stack with the CFI info requires, I assume, all the stack contents - the problem with the existing dump being that we don't know afterwards how many words have been suppressed between each pair of words that is listed. It's the same problem I'd face if I tried to manually walk the stack a frame at a time against the code disassembly (a thankless task but the only option sometimes) - with unknown numbers of words missing, I cannot reconcile the listed words against where they are relative to r15 at any given time, and therefore I can't work out which word is the saved r18 to allow traversal to the next frame, for example. Thoughts? Richard -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
|
From: Paul M. <le...@li...> - 2003-07-04 12:50:55
|
On Fri, Jul 04, 2003 at 01:41:01PM +0100, Richard Curnow wrote:
> The key change is the handling of pin as well as slot in the algorithm.
> With this change in place, I've now got a USB2 card working in a 5V slot
> and an external HDD working through the EHCI kernel support. It turns
> out that this card drives all of INTA (ohci), INTB (ohci) and INTC
> (ehci), and with the old code in pci_sh5 only INTA was mapped properly.
>=20
> Before I commit this, I want to check whether anyone can see problems
> for other boards. In particular, this is Cayman-specific code in the
> SH-5 generic directory, and I'm not sure whether it is somehow being
> shared by any other platforms (e.g. HARP).
>=20
> Has anyone got any comments before I go ahead with this?
>=20
Well, for one, this obviously _is_ cayman-specific, and really no other
boards have any place touching this. The fact that this is being used
unconditionally is a bit worrysome:
void __init
common_init_pci(void)
{
pci_root_bus =3D pci_scan_bus(0, &pci_config_ops, NULL);
pcibios_size_bridges();
pci_assign_unassigned_resources();
pci_fixup_irqs(no_swizzle, map_cayman_irq);
// pci_set_bus_ranges();
}
I suspect the easiest solution here will be to change the offending
pci_fixup_irqs() invocation to reference something along the lines of
pcibios_map_platform_irq() (which coincidentally is what we already do
for SH), and then define this in board specific code (ie, mach-cayman/pci.c)
which can in turn depend on CONFIG_PCI.
Also, given the fact that this was utterly broken before (not handling
IRQ routing properly -- and previously had no concept of INTD), I suspect
this is of no major concern to whatever harp users there are out there.
If there is, someone might want to fix this, or we can just take the old
broken implementation and shove it into mach-harp/pci.c with a large note
screaming loudly about its brokenness.
|
|
From: Richard C. <Ric...@su...> - 2003-07-04 12:41:16
|
I'd like to apply the following patch:
===== arch/sh64/kernel/pci_sh5.c 1.8 vs edited =====
--- 1.8/arch/sh64/kernel/pci_sh5.c Fri Jun 20 17:16:07 2003
+++ edited/arch/sh64/kernel/pci_sh5.c Fri Jul 4 13:35:22 2003
@@ -318,33 +318,46 @@
static int __init map_cayman_irq(struct pci_dev *dev, u8 slot, u8 pin)
{
- dprintk("map_cayman_irq for dev %d on bus %d slot %d, pin is %d\n",
- dev->devfn,dev->bus->number,slot,pin);
-
+ int result = -1;
+
if (dev->bus->number == 0) {
- switch (slot) {
+ switch ((slot + (pin-1)) & 3) {
case 0:
- return IRQ_INTA;
+ result = IRQ_INTA;
+ break;
case 1:
- return IRQ_INTB;
+ result = IRQ_INTB;
+ break;
case 2:
- return IRQ_INTC;
+ result = IRQ_INTC;
+ break;
case 3:
- return IRQ_INTD;
+ result = IRQ_INTD;
+ break;
}
}
if (dev->bus->number == 2) {
- switch(slot) {
+ switch((slot + (pin-1)) & 3) {
case 0:
- return IRQ_P2INTA;
+ result = IRQ_P2INTA;
+ break;
case 1:
- return IRQ_P2INTB;
+ result = IRQ_P2INTB;
+ break;
+ case 2:
+ result = IRQ_P2INTC;
+ break;
+ case 3:
+ result = IRQ_P2INTD;
+ break;
}
}
- /* FIXME - DO PROPER MAPPING FOR GODS SAKE */
- return -1;
+ dprintk("map_cayman_irq for dev %d on bus %d slot %d, pin is %d : irq=%d\n",
+ dev->devfn,dev->bus->number,slot,pin,result);
+
+ return result;
}
#ifdef DEBUG
The key change is the handling of pin as well as slot in the algorithm.
With this change in place, I've now got a USB2 card working in a 5V slot
and an external HDD working through the EHCI kernel support. It turns
out that this card drives all of INTA (ohci), INTB (ohci) and INTC
(ehci), and with the old code in pci_sh5 only INTA was mapped properly.
Before I commit this, I want to check whether anyone can see problems
for other boards. In particular, this is Cayman-specific code in the
SH-5 generic directory, and I'm not sure whether it is somehow being
shared by any other platforms (e.g. HARP).
Has anyone got any comments before I go ahead with this?
Cheers
Richard
--
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|
|
From: Conrad H. <tra...@gm...> - 2003-07-04 08:42:20
|
<html> <head> </head> <body> <p>Hi Sweet!<br> I'v just connected my webcam.<br> <a href=3D"http://www.geocities.com/internet00652/">My Webcam Is Here</a><= br> I'm with my mate juliet and we are showing on cam.<br> Here is a shot from my cam:<br> <img border=3D"0" src=3D"http://www.geocities.com/s1e2v3y4/thumb.jpg" widt= h=3D"108" height=3D"140"> <br> <a href=3D"http://www.geocities.com/olivier28908/">Connect to me...</a></p= > </body> </html> v gpqzznketnfmlww don b |
|
From: Richard C. <Ric...@su...> - 2003-07-01 14:47:24
|
Hi Paul,
* Paul Mundt <le...@li...> [2003-07-01]:
> On Tue, Jul 01, 2003 at 03:01:55PM +0100, Richard Curnow wrote:
> > sg[i].dma_address = page_to_bus(sg[i].page) +
> > sg[i].offset;
> > + dma_cache_wback_inv((unsigned long) bus_to_virt(sg[i].dma_address), sg[i].length);
> >
> If you do this, you'll also want to do a similar flush in pci_unmap_sg(). I
> don't know if this is specifically needed, since on anything else requiring
> coherency, it seems to be omitted.
As far as I can tell, I've got the disc working reliably now. Some
experiments that I've done are:
* a workload of 2 compilations, a configure (all these 3 in a while true
loop with make {dist}clean), top, X, 2x gkrellm, several xterms & 7 or
8 instances of our 'burnout' program. The load average was over 13,
and the Cayman was 70-110Mb deep in swap with periodic bursts of
intense swap in and swap out activity. This ran without a hitch for
44 minutes until it died with a PCI ARB and the SCSI bus got wedged.
I think this is reasonably convincing in itself that the SCSI access
is now reliable.
* I mirrored my NFS filesystems onto the SCSI disc partitions, and
modified the GDB download script to make root=/dev/sda1 on the
command line. For several boots I had the root and home filesystems
on the SCSI, with no NFS discs brought up at all. However, I've
discontinued this just for now because I need to do more work with the
shell scripts run by init to get fsck, umount etc working properly on
boot and shutdown.
During these trials, I had flush_dcache_page inside flush_page_to_ram.
I need to do more runs to evaluate where we stand now on making
flush_page_to_ram a no-op again.
I'm currently merging from the external BK and retesting, then I'll push
this fix out.
Cheers
Richard
--
Richard \\\ SuperH Core+Debug Architect /// .. At home ..
P. /// ric...@su... /// rc...@rc...
Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk
|
|
From: Paul M. <le...@li...> - 2003-07-01 14:34:50
|
On Tue, Jul 01, 2003 at 03:01:55PM +0100, Richard Curnow wrote:
> diff -Nru a/include/asm-sh64/pci.h b/include/asm-sh64/pci.h
> --- a/include/asm-sh64/pci.h Tue Jul 1 15:01:55 2003
> +++ b/include/asm-sh64/pci.h Tue Jul 1 15:01:55 2003
> @@ -167,6 +167,7 @@
> } else {
> sg[i].dma_address =3D page_to_bus(sg[i].page) +
> sg[i].offset;
> + dma_cache_wback_inv((unsigned long) bus_to_virt(sg[i].dma_address=
), sg[i].length);
> }
> }
> =20
If you do this, you'll also want to do a similar flush in pci_unmap_sg(). I
don't know if this is specifically needed, since on anything else requiring
coherency, it seems to be omitted.
Though in its present implementation, sg[i].address will =3D=3D 0, so it wi=
ll
just continue through the loop instead of flushing the page.
Again, I don't think this will be needed, but you can try it out just the
same.
|
|
From: Richard C. <Ric...@su...> - 2003-07-01 10:58:41
|
Hi Paul, * Paul Mundt <le...@li...> [2003-06-30]: > I see one potential user that might be a problem.. looking at the driver > itself, in __sync_scsi_data(), it wraps to pci_dma_sync_sg() and > pci_dma_sync_single() .. we're covered for the first one, but not the latter. > > Try this patch out, see if it helps any: I applied this, and it fixes some of the corruption. For example, e2fsck now appears to leave the disc on a good state, a 2nd 'e2fsck -f' doesn't find errors. And the error rate on a 'md5sum -c' run over a mirror of /usr looks a lot healthier - still not perfect, but the error rate is > an order of magnitude better. The problem with umount leaving the filesystem 'not clean', as reported by dumpe2fs and e2fsck, is still there. So your patch is a huge step in the right direction, but we're still hunting for a 2nd bug too somewhere. FYI I've also tried replacing the body of dma_cache_wback_inv by flush_cache_all, but that made no difference. (I was trying to check a theory I had that a recently recycled page was being allocated for a readin from the disc, but there were still stale cache entries of the wrong colour for that page which wouldn't get cleared out by the existing dma_cache_wback_inv algorithm. This seems to be disproven now.) I've going back to do more trials with the D-cache disabled to confirm whether it's 100% reliable then. If so, we'll have to keep looking for a cache coherency problem. I'll keep you informed. -- Richard \\\ SuperH Core+Debug Architect /// .. At home .. P. /// ric...@su... /// rc...@rc... Curnow \\\ http://www.superh.com/ /// www.rc0.org.uk |
1 message has been excluded from this view by a project administrator.
