* Re: [PATCH] fix warning when using PHYS_TO_XKSEG_xx()
From: Andrew Sharp @ 2007-11-26 23:06 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, ralf
In-Reply-To: <20071126223948.C7CB3C2B26@solo.franken.de>
This is the basically the patch I submitted 10/31 and I believe is
queued for 2.6.25 ...
On Sun, 25 Nov 2007 11:28:03 +0100 Thomas Bogendoerfer
<tsbogend@alpha.franken.de> wrote:
> use CONST64 cast in PHYS_TO_XPHYS macro to avoid warning about shifts
> longer than the target type.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
> arch/mips/lib/uncached.c | 8 ++++----
> include/asm-mips/addrspace.h | 2 +-
> 2 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/arch/mips/lib/uncached.c b/arch/mips/lib/uncached.c
> index 58d14f4..b59b770 100644
> --- a/arch/mips/lib/uncached.c
> +++ b/arch/mips/lib/uncached.c
> @@ -46,8 +46,8 @@ unsigned long __init run_uncached(void *func)
> if (sp >= (long)CKSEG0 && sp < (long)CKSEG2)
> usp = CKSEG1ADDR(sp);
> #ifdef CONFIG_64BIT
> - else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0LL, 0)
> &&
> - (long long)sp < (long long)PHYS_TO_XKPHYS(8LL, 0))
> + else if ((long long)sp >= (long long)PHYS_TO_XKPHYS(0, 0) &&
> + (long long)sp < (long long)PHYS_TO_XKPHYS(8, 0))
> usp = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> XKPHYS_TO_PHYS((long long)sp));
> #endif
> @@ -58,8 +58,8 @@ unsigned long __init run_uncached(void *func)
> if (lfunc >= (long)CKSEG0 && lfunc < (long)CKSEG2)
> ufunc = CKSEG1ADDR(lfunc);
> #ifdef CONFIG_64BIT
> - else if ((long long)lfunc >= (long long)PHYS_TO_XKPHYS(0LL,
> 0) &&
> - (long long)lfunc < (long long)PHYS_TO_XKPHYS(8LL,
> 0))
> + else if ((long long)lfunc >= (long long)PHYS_TO_XKPHYS(0, 0)
> &&
> + (long long)lfunc < (long long)PHYS_TO_XKPHYS(8, 0))
> ufunc = PHYS_TO_XKPHYS((long long)K_CALG_UNCACHED,
> XKPHYS_TO_PHYS((long
> long)lfunc)); #endif
> diff --git a/include/asm-mips/addrspace.h
> b/include/asm-mips/addrspace.h index 0bb7a93..9002d66 100644
> --- a/include/asm-mips/addrspace.h
> +++ b/include/asm-mips/addrspace.h
> @@ -127,7 +127,7 @@
> #define PHYS_TO_XKSEG_CACHED(p)
> PHYS_TO_XKPHYS(K_CALG_COH_SHAREABLE, (p)) #define
> XKPHYS_TO_PHYS(p) ((p) & TO_PHYS_MASK) #define
> PHYS_TO_XKPHYS(cm, a) (_CONST64_(0x8000000000000000) |
> \
> - ((cm)<<59) | (a))
> + (_CONST64_(cm)<<59) | (a))
>
> /*
> * The ultimate limited of the 64-bit MIPS architecture: 2 bits for
> selecting
^ permalink raw reply
* Re: SGI IP28 support
From: post @ 2007-11-27 2:30 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126230127.GA21970@alpha.franken.de>
Hi!
On Tue, 27 Nov 2007, Thomas Bogendoerfer wrote:
> Date: Tue, 27 Nov 2007 00:01:27 +0100
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> To: linux-mips@linux-mips.org
> Subject: Re: SGI IP28 support
>
> On Mon, Nov 26, 2007 at 11:38:14PM +0100, Thomas Bogendoerfer wrote:
> > [..]
>
> There is one thing I forgot: You need a special gcc, which will generate
> cache barriers to avoid speculative stores done by the R10k. Peter
> had some patches submitted to the gcc maintainers, which I used to
> build my own gcc 4.2.1 cross compiler. Does anybody know, if Peter's
> paches are already intergrated in newer gcc versions ?
They hardly are. At least i didn't undertake a second attempt yet. Nor
did i hear of the Gentoo-folks or someone else taking this unpleasant
job.
>
> Thomas.
>
> --
> Crap can work. Given enough thrust pigs will fly, but it's not necessary a
> good idea. [ RFC1925, 2.3 ]
>
>
>
kind regards
peter
^ permalink raw reply
* Re: [PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: Geert Uytterhoeven @ 2007-11-27 8:28 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-scsi, linux-mips, ralf, James.Bottomley
In-Reply-To: <20071126223921.A566CC2B26@solo.franken.de>
On Mon, 26 Nov 2007, Thomas Bogendoerfer wrote:
> --- a/drivers/scsi/sgiwd93.c
> +++ b/drivers/scsi/sgiwd93.c
> @@ -33,19 +33,27 @@
>
> struct ip22_hostdata {
> struct WD33C93_hostdata wh;
> - struct hpc_data {
> - dma_addr_t dma;
> - void *cpu;
> - } hd;
> + dma_addr_t dma;
> + void *cpu;
> + void *dev;
> };
>
> #define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata))
>
> struct hpc_chunk {
> struct hpc_dma_desc desc;
> - u32 _padding; /* align to quadword boundary */
> + u32 _padding[128/4 - 3]; /* align to biggest cache line size */
^^^^^^^^^
(128 - sizeof(struct hpc_dma_desc))/4?
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fix warning when using PHYS_TO_XKSEG_xx()
From: Thomas Bogendoerfer @ 2007-11-27 8:59 UTC (permalink / raw)
To: Andrew Sharp; +Cc: linux-mips, ralf
In-Reply-To: <20071126150601.2cd8efc0@ripper.onstor.net>
On Mon, Nov 26, 2007 at 03:06:01PM -0800, Andrew Sharp wrote:
> This is the basically the patch I submitted 10/31 and I believe is
> queued for 2.6.25 ...
oops, I didn't notice that. If it's in, I could check off that patch
from my list.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: Thomas Bogendoerfer @ 2007-11-27 9:01 UTC (permalink / raw)
To: Geert Uytterhoeven; +Cc: linux-scsi, linux-mips, ralf, James.Bottomley
In-Reply-To: <Pine.LNX.4.64.0711270927370.22167@anakin>
On Tue, Nov 27, 2007 at 09:28:14AM +0100, Geert Uytterhoeven wrote:
> > struct hpc_chunk {
> > struct hpc_dma_desc desc;
> > - u32 _padding; /* align to quadword boundary */
> > + u32 _padding[128/4 - 3]; /* align to biggest cache line size */
> ^^^^^^^^^
> (128 - sizeof(struct hpc_dma_desc))/4?
yes, that's safer. Thank you.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: SGI IP28 support
From: Ralf Baechle @ 2007-11-27 14:13 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126223814.GA21339@alpha.franken.de>
On Mon, Nov 26, 2007 at 11:38:14PM +0100, Thomas Bogendoerfer wrote:
> I finally cleaned up Peter Fuerst's IP28 patches and solved some of
> the IP28 issues in an IMHO more eye-friendly way (no ip26ucmem).
> My IP28 boots with these patches from an Debian sarge NFS root and
> is able to dd data from the harddrive. I'm going to send this patches
> to this list and the subsystem maintainers.
>
> There is one change missing to get a working SCSI driver, because
> a proper fix will be done in 2.6.25. The quick&dirty workaround is
> below. The workaround makes sure that the sense_buffer lives in
> its own cache line by aligning and extendin it.
>
> The patch "Use real cache invalidate" still contains one problem.
> It will not flush the cache correctly, if the given size is bigger
> than the second level cache. The problem is, that there is no index
> invalidate cache operation available. I have two ideas to solve that.
> One is to always do a range invalidate (maybe just by using this only
> for R10k machines, which usually have quite big caches) or scan through
> the cache and use the tag informations to do hit invalidate. If anybody
> has a better idea please speak up :-)
A while ago I instrumented the cacheflushing functions to get a histogram
of cacheflush sizes. I was surprised to find no flushes larger than 64K
even though I did that experiment on an Origin with a large RAID array
copying huge amounts of data with reads and writes of several MB. So as
long as that finding holds your code will work.
Ralf
^ permalink raw reply
* Re: [PATCH] Use real cache invalidate
From: Ralf Baechle @ 2007-11-27 14:16 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126224001.48CF6C2B26@solo.franken.de>
On Mon, Nov 26, 2007 at 11:40:01PM +0100, Thomas Bogendoerfer wrote:
> R10k non coherent machines need a real dma cache invalidate to get
> rid of speculative stores in cache.
Wonderful. This should also deliver a slight performance benefit for
other systems.
Ralf
^ permalink raw reply
* Re: [PATCH] IP22/IP28: fix extracting board/chip rev
From: Ralf Baechle @ 2007-11-27 14:52 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126223944.16FBEC2B26@solo.franken.de>
On Sun, Nov 25, 2007 at 11:27:06AM +0100, Thomas Bogendoerfer wrote:
Queued for 2.6.25,
Ralf
^ permalink raw reply
* Re: [PATCH] qemu: do not enable IP7 blindly
From: Ralf Baechle @ 2007-11-27 16:16 UTC (permalink / raw)
To: Atsushi Nemoto; +Cc: linux-mips
In-Reply-To: <20071123.004406.108119126.anemo@mba.ocn.ne.jp>
On Fri, Nov 23, 2007 at 12:44:06AM +0900, Atsushi Nemoto wrote:
> IP7 will be enabled automatically in mips_clockevent_init(), if it was
> available.
Applied.
Ralf
^ permalink raw reply
* BUG: using smp_processor_id() in preemptible code
From: Pavel Kiryukhin @ 2007-11-27 16:20 UTC (permalink / raw)
To: linux-mips; +Cc: vksavl
I get the following bug running 2.6.18 on malta34Kc .
Freeing prom memory: 956kb freed
Freeing firmware memory: 978944k freed
Freeing unused kernel memory: 180k freed
BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
caller is r4k_dma_cache_wback_inv+0x144/0x2a0
Call Trace:
[<80117af8>] r4k_dma_cache_wback_inv+0x144/0x2a0
[<802e4b84>] debug_smp_processor_id+0xd4/0xf0
[<802e4b7c>] debug_smp_processor_id+0xcc/0xf0
...
CONFIG_DEBUG_PREEMPT is enabled.
--
Bug cause is blast_dcache_range() in preemptible code [in
r4k_dma_cache_wback_inv()].
blast_dcache_range() is constructed via __BUILD_BLAST_CACHE_RANGE that
uses cpu_dcache_line_size(). It uses current_cpu_data that use
smp_processor_id() in turn. In case of CONFIG_DEBUG_PREEMPT
smp_processor_id emits BUG if we are executing with preemption
enabled.
Cpu options of cpu0 are assumed to be the superset of all processors.
Can I make the same assumptions for cache line size and fix this
issue the following way:
Index: linux-2.6.18/include/asm-mips/cpu-features.h
===================================================================
--- linux-2.6.18.orig/include/asm-mips/cpu-features.h
+++ linux-2.6.18/include/asm-mips/cpu-features.h
@@ -200,10 +200,10 @@
#endif
#ifndef cpu_dcache_line_size
-#define cpu_dcache_line_size() current_cpu_data.dcache.linesz
+#define cpu_dcache_line_size() cpu_data[0].dcache.linesz
#endif
#ifndef cpu_icache_line_size
-#define cpu_icache_line_size() current_cpu_data.icache.linesz
+#define cpu_icache_line_size() cpu_data[0].icache.linesz
#endif
#ifndef cpu_scache_line_size
#define cpu_scache_line_size() current_cpu_data.scache.linesz
Any suggestions would be greatly appreciated.
---
Thanks,
Pavel
^ permalink raw reply
* Re: [PATCH] SGISEEQ: use cached memory access to make driver work on IP28
From: Ralf Baechle @ 2007-11-27 16:32 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: netdev, linux-mips, jgarzik
In-Reply-To: <20071126223934.84BE7C2B26@solo.franken.de>
On Sat, Nov 24, 2007 at 01:29:19PM +0100, Thomas Bogendoerfer wrote:
> Following patch is clearly 2.6.25 material and is needed to get SGI IP28
> machines supported.
>
> Thomas.
>
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncached. To avoid this pain I changed
> the driver to use only cached access to memory.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
IP28 is clearly a maximum weirdo beast. Technically the patch looks fine
it's just a few stilistic issues such as there no reason for
DMA_SYNC_DESC_CPU and DMA_SYNC_DESC_DEV being macros so why not using
inlines.
Acked-by: Ralf Baechle <ralf@linux-mips.org>
Ralf
^ permalink raw reply
* prism54 - MIPS do_be() trap caught
From: Luis R. Rodriguez @ 2007-11-27 17:17 UTC (permalink / raw)
To: loswillios; +Cc: kyle, linux-wireless, developers, linux-mips
Changing subject, CC'ing linux-mips, perhaps they can help.
On Nov 26, 2007 7:54 PM, loswillios <loswillios@gmail.com> wrote:
> Jan Willies wrote:
> > Luis R. Rodriguez wrote:
> >> Actually I've been informed this is not unaligned access problem but
> >> instead it occurs on do_be() or ip22_be_interrupt() on MIPS. I'll have
> >> to check how that works, I do not yet understand how this is reached.
> >
> > I will try a new build with prism54 in the next days and let you know if
> > that issue is still present.
>
> Still the same problem with 2.6.23.1:
>
> root@OpenWrt:/# ifconfig eth1 up
> eth1: resetting device...
> eth1: uploading firmware...
> eth1: firmware version: 1.0.4.3
> eth1: firmware upload complete
> eth1: interface reset complete
>
> root@OpenWrt:/# iwlist eth1 scanning
> Data bus error, epc == c011518c, ra == c01146cc
> Oops[#1]:
> Cpu 0
> $ 0 : 00000000 1000b800 abad0000 00000032
> $ 4 : 00000001 c00c8000 00000013 00000001
> $ 8 : 0000003c 80102bd4 ffffffff 81e2101c
> $12 : ffffffff 00000580 2ab8af24 00000498
> $16 : 81e21680 000000fa 81339380 0000004a
> $20 : 81339380 00000000 a1e80000 81339000
> $24 : 00000000 2abd55e0
> $28 : 813b4000 813b5cc8 00000019 c01146cc
> Hi : 00000000
> Lo : 00000580
> epc : c011518c Not tainted
> ra : c01146cc Status: 1000b803 KERNEL EXL IE
> Cause : 0000001c
> PrId : 00029007
I can see that this comes from arch/mips/kernel/traps.c do_be() but I
fail to see when this is triggered. Perhaps someone from linux-mips
might be able to help shed some light here. I tried looking into the
stack trace before but I couldn't find any code that made me suspect
of a possible big endian problem (it seems that may be the problem?).
The stack trace used to look like this:
Call Trace:
[<c007e16c>] isl38xx_trigger_device+0xc/0x60 [prism54]
[<c007d6c0>] islpci_mgt_transaction+0x380/0x614 [prism54]
[<c0086cd0>] mgt_get_request+0x100/0x2ec [prism54]
[<c0081628>] prism54_set_mac_address+0x1a0/0xfd8 [prism54]
> Modules linked in: prism54 ehci_hcd ohci_hcd nf_nat_tftp
> nf_conntrack_tftp nf_nat_irc nf_conntrack_irc nf_nat_ftp
> nf_conntrack_ftp ppp_async ppp_generic slhc crc_ccitt usbcore arc4 aes
> deflate ecb cbc blkcipher crypto_hash cryptomgr crypto_algapi
> switch_robo switch_core diag
> Process iwlist (pid: 680, threadinfo=813b4000, task=810a10c8)
> Stack : ffffff9c 2ab3549b 80074a50 7fd23300 00000000 810a10c8 8003cac4
> 81339710
> 81339710 8008c054 0000003e 00000000 00000000 813b5e60 00000060
> 17000012
> 81339380 813b5d78 00000498 c011dce0 81052920 00000000 17000012
> 00000009
> 0000003e 813b5d30 00000000 81052920 813b5e70 802a6000 802a6000
> 813b5e60
> 813b5e70 00000000 81339380 00008b0b c01187ec 00008b0b 81047360
> 000080d0
> ...
> Call
> Trace:[<80074a50>][<8003cac4>][<8008c054>][<c011dce0>][<c01187ec>][<c01186a4>][<801ec8ec>][<8005ecc4>][<8005ecc4>][<800cbc34>][<80118d8c>][<c01186a4>][<801ecb10>][<80060f6c>][<80164b28>][<8008d4a8>][<8008630c>][<8008661c>][<8008669c>][<8000c12c>][<80003a00>]
>
> Code: 10800014 24020002 3c02abad <8ca30010> 3442face 1462000f
> 24020008 08045470 00000000
> Segmentation fault
Can you enable KALLSYMS again?
> Sometimes I even get this weird stuff:
>
> root@OpenWrt:/# ifconfig eth1 up
> eth1: resetting device...
> eth1: uploading firmware...
> eth1: firmware version: 1.0.4.3
> eth1: firmware upload complete
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: no 'reset complete' IRQ seen - retrying
> eth1: interface reset failure
> prism54: Your card/socket may be faulty, or IRQ line too busy :(
> ifconfig: SIOCSIFFLAGS: Timer expired
Hm, seems schedule_timeout_uninterruptible() and the time remaining
was misused. This just is a stupid way to wait, not sure why the
check on islpci_reset_if() is used that way. I'll also test something
later with actual hardware. If anyone has some spare fullmac cards
please send one, all of mine except one which I've put on Orbit for
anyone to use have died. Pasting a quick patch for this, sorry, you
may need to edit manually. I need to get an inline append plugin for
firefox...
diff --git a/drivers/net/wireless/prism54/islpci_dev.c
b/drivers/net/wireless/prism54/islpci_dev.c
index 0847953..62d1797 100644
--- a/drivers/net/wireless/prism54/islpci_dev.c
+++ b/drivers/net/wireless/prism54/islpci_dev.c
@@ -491,7 +491,7 @@ islpci_reset_if(islpci_private *priv)
remaining = schedule_timeout_uninterruptible(HZ);
- if(remaining > 0) {
+ if(remaining >= 0) {
result = 0;
break;
}
^ permalink raw reply related
* Re: prism54 - MIPS do_be() trap caught
From: Geert Uytterhoeven @ 2007-11-27 17:25 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: loswillios, kyle, linux-wireless, developers, linux-mips
In-Reply-To: <43e72e890711270917o309441a0g99ac435a629b6d5e@mail.gmail.com>
On Tue, 27 Nov 2007, Luis R. Rodriguez wrote:
> Changing subject, CC'ing linux-mips, perhaps they can help.
>
> On Nov 26, 2007 7:54 PM, loswillios <loswillios@gmail.com> wrote:
> > Jan Willies wrote:
> > > Luis R. Rodriguez wrote:
> > >> Actually I've been informed this is not unaligned access problem but
> > >> instead it occurs on do_be() or ip22_be_interrupt() on MIPS. I'll have
> > >> to check how that works, I do not yet understand how this is reached.
> > >
> > > I will try a new build with prism54 in the next days and let you know if
> > > that issue is still present.
> >
> > Still the same problem with 2.6.23.1:
> >
> > root@OpenWrt:/# ifconfig eth1 up
> > eth1: resetting device...
> > eth1: uploading firmware...
> > eth1: firmware version: 1.0.4.3
> > eth1: firmware upload complete
> > eth1: interface reset complete
> >
> > root@OpenWrt:/# iwlist eth1 scanning
> > Data bus error, epc == c011518c, ra == c01146cc
> > Oops[#1]:
> > Cpu 0
> > $ 0 : 00000000 1000b800 abad0000 00000032
> > $ 4 : 00000001 c00c8000 00000013 00000001
> > $ 8 : 0000003c 80102bd4 ffffffff 81e2101c
> > $12 : ffffffff 00000580 2ab8af24 00000498
> > $16 : 81e21680 000000fa 81339380 0000004a
> > $20 : 81339380 00000000 a1e80000 81339000
> > $24 : 00000000 2abd55e0
> > $28 : 813b4000 813b5cc8 00000019 c01146cc
> > Hi : 00000000
> > Lo : 00000580
> > epc : c011518c Not tainted
> > ra : c01146cc Status: 1000b803 KERNEL EXL IE
> > Cause : 0000001c
> > PrId : 00029007
>
> I can see that this comes from arch/mips/kernel/traps.c do_be() but I
> fail to see when this is triggered. Perhaps someone from linux-mips
> might be able to help shed some light here. I tried looking into the
> stack trace before but I couldn't find any code that made me suspect
> of a possible big endian problem (it seems that may be the problem?).
> The stack trace used to look like this:
BE = bus error, not big endian here.
Gr{oetje,eeting}s,
Geert
--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org
In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
-- Linus Torvalds
^ permalink raw reply
* Re: [PATCH] fix warning when using PHYS_TO_XKSEG_xx()
From: Andrew Sharp @ 2007-11-27 17:31 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, ralf
In-Reply-To: <20071127085900.GB6733@alpha.franken.de>
On Tue, 27 Nov 2007 09:59:00 +0100 tsbogend@alpha.franken.de (Thomas
Bogendoerfer) wrote:
> On Mon, Nov 26, 2007 at 03:06:01PM -0800, Andrew Sharp wrote:
> > This is the basically the patch I submitted 10/31 and I believe is
> > queued for 2.6.25 ...
>
> oops, I didn't notice that. If it's in, I could check off that patch
> from my list.
I tried to check, but apparently I don't pull the queue branch
anymore. I don't remember why.
Cheers,
a
^ permalink raw reply
* Re: [PATCH] fix warning when using PHYS_TO_XKSEG_xx()
From: Andrew Sharp @ 2007-11-27 17:31 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips, ralf
In-Reply-To: <20071127085900.GB6733@alpha.franken.de>
On Tue, 27 Nov 2007 09:59:00 +0100 tsbogend@alpha.franken.de (Thomas
Bogendoerfer) wrote:
> On Mon, Nov 26, 2007 at 03:06:01PM -0800, Andrew Sharp wrote:
> > This is the basically the patch I submitted 10/31 and I believe is
> > queued for 2.6.25 ...
>
> oops, I didn't notice that. If it's in, I could check off that patch
> from my list.
I tried to check, but apparently I don't pull the queue branch
anymore. I don't remember why.
Cheers,
a
^ permalink raw reply
* Re: prism54 - MIPS do_be() trap caught
From: Maciej W. Rozycki @ 2007-11-27 18:08 UTC (permalink / raw)
To: Luis R. Rodriguez
Cc: loswillios, kyle, linux-wireless, developers, linux-mips
In-Reply-To: <43e72e890711270917o309441a0g99ac435a629b6d5e@mail.gmail.com>
On Tue, 27 Nov 2007, Luis R. Rodriguez wrote:
> > root@OpenWrt:/# iwlist eth1 scanning
> > Data bus error, epc == c011518c, ra == c01146cc
> > Oops[#1]:
> > Cpu 0
> > $ 0 : 00000000 1000b800 abad0000 00000032
> > $ 4 : 00000001 c00c8000 00000013 00000001
> > $ 8 : 0000003c 80102bd4 ffffffff 81e2101c
> > $12 : ffffffff 00000580 2ab8af24 00000498
> > $16 : 81e21680 000000fa 81339380 0000004a
> > $20 : 81339380 00000000 a1e80000 81339000
> > $24 : 00000000 2abd55e0
> > $28 : 813b4000 813b5cc8 00000019 c01146cc
> > Hi : 00000000
> > Lo : 00000580
> > epc : c011518c Not tainted
> > ra : c01146cc Status: 1000b803 KERNEL EXL IE
> > Cause : 0000001c
> > PrId : 00029007
>
> I can see that this comes from arch/mips/kernel/traps.c do_be() but I
> fail to see when this is triggered. Perhaps someone from linux-mips
> might be able to help shed some light here. I tried looking into the
> stack trace before but I couldn't find any code that made me suspect
> of a possible big endian problem (it seems that may be the problem?).
> The stack trace used to look like this:
[...]
> > Code: 10800014 24020002 3c02abad <8ca30010> 3442face 1462000f
> > 24020008 08045470 00000000
> > Segmentation fault
Well, a data bus error is caused by external hardware signalling a
transaction error on a data read operation (there is an instruction bus
error counterpart). A possible reason is a data parity or irrecoverable
ECC error or a bus timeout when accessing an unpopulated location. In
this case the faulting instruction is 8ca30010, which is
lw v1,16(a1)
and a1 is 0xc00c8000 above. I guess you need to find out where the
mapping for this virtual address is established and what physical address
and thus device (if any at all) it corresponds to.
Maciej
^ permalink raw reply
* [PATCH] Use correct dma flushing in dma_cache_sync()
From: Thomas Bogendoerfer @ 2007-11-27 18:31 UTC (permalink / raw)
To: linux-mips; +Cc: ralf
Not cache coherent R10k systems (like IP28) need to do real cache
invalidates in dma_cache_sync().
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
diff --git a/arch/mips/mm/dma-default.c b/arch/mips/mm/dma-default.c
index 33519ce..5cd94a8 100644
--- a/arch/mips/mm/dma-default.c
+++ b/arch/mips/mm/dma-default.c
@@ -364,7 +364,7 @@ void dma_cache_sync(struct device *dev, void *vaddr, size_t size,
BUG_ON(direction == DMA_NONE);
if (!plat_device_is_coherent(dev))
- dma_cache_wback_inv((unsigned long)vaddr, size);
+ __dma_sync((unsigned long)vaddr, size, direction);
}
EXPORT_SYMBOL(dma_cache_sync);
^ permalink raw reply related
* Re: [PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: peter fuerst @ 2007-11-27 23:00 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-scsi, linux-mips, ralf, James.Bottomley
In-Reply-To: <20071126223921.A566CC2B26@solo.franken.de>
Hello Thomas,
unlike with sgiseeq.c, in sgiwd93.c there's no need to bloat the hpc_chunk
and only a single dma_cache_sync-call is necessary in fill_hpc_entries and
init_hpc_chain respectively.
kind regards
peter
On Mon, 26 Nov 2007, Thomas Bogendoerfer wrote:
> Date: Mon, 26 Nov 2007 18:41:15 +0100
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> To: linux-scsi@vger.kernel.org, linux-mips@linux-mips.org
> Cc: ralf@linux-mips.org, James.Bottomley@HansenPartnership.com
> Subject: [PATCH] SGIWD93: use cached memory access to make driver work on
> IP28
>
> Following patch is 2.6.25 material needed to get SGI IP28 machines
> supported.
>
> Thomas.
>
> SGI IP28 machines would need special treatment (enable adding addtional
> wait states) when accessing memory uncached. To avoid this pain I
> changed the driver to use only cached access to memory.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
> drivers/scsi/sgiwd93.c | 68 ++++++++++++++++++++++++++++++-----------------
> 1 files changed, 43 insertions(+), 25 deletions(-)
>
> ...
Signed-off-by: peter fuerst <post@pfrst.de>
---
diff -up a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -42,15 +42,13 @@ struct ip22_hostdata {
struct hpc_chunk {
struct hpc_dma_desc desc;
- u32 _padding[128/4 - 3]; /* align to biggest cache line size */
+ u32 _padding;
};
/* space for hpc dma descriptors */
-#define HPC_DMA_SIZE (4 * PAGE_SIZE)
+#define HPC_DMA_SIZE PAGE_SIZE
/* we only need to sync the dma descriptor */
-#define DMA_HPC_SYNC(dev, hcp, dir) \
- dma_cache_sync(dev, hcp, sizeof(struct hpc_dma_desc), dir)
#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
@@ -73,6 +71,7 @@ void fill_hpc_entries(void *dev, struct
void *addr = cmd->SCp.ptr;
dma_addr_t physaddr;
unsigned long count;
+ struct hpc_chunk *hcpstart = hcp;
physaddr = dma_map_single(dev, addr, len, DMA_DIR(datainp));
cmd->SCp.dma_handle = physaddr;
@@ -85,7 +84,6 @@ void fill_hpc_entries(void *dev, struct
count = len > 8192 ? 8192 : len;
hcp->desc.pbuf = physaddr;
hcp->desc.cntinfo = count;
- DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE);
hcp++;
len -= count;
physaddr += count;
@@ -98,7 +96,7 @@ void fill_hpc_entries(void *dev, struct
*/
hcp->desc.pbuf = 0;
hcp->desc.cntinfo = HPCDMA_EOX;
- DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE);
+ dma_cache_sync(dev, hcpstart, sizeof(*hcp)*(1+hcp-hcpstart), DMA_TO_DEVICE);
}
static int dma_setup(struct scsi_cmnd *cmd, int datainp)
@@ -181,18 +179,17 @@ static inline void init_hpc_chain(void *
unsigned long start, end;
start = (unsigned long) hcp;
- end = start + (4 * PAGE_SIZE);
+ end = start + HPC_DMA_SIZE;
while (start < end) {
hcp->desc.pnext = (u32) (dma + sizeof(struct hpc_chunk));
hcp->desc.cntinfo = HPCDMA_EOX;
- DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE);
hcp++;
dma += sizeof(struct hpc_chunk);
start += sizeof(struct hpc_chunk);
};
hcp--;
hcp->desc.pnext = hdata->dma;
- DMA_HPC_SYNC(dev, hcp, DMA_TO_DEVICE);
+ dma_cache_sync(dev, hdata->cpu, HPC_DMA_SIZE, DMA_TO_DEVICE);
}
static int sgiwd93_bus_reset(struct scsi_cmnd *cmd)
^ permalink raw reply
* Re: [PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: Thomas Bogendoerfer @ 2007-11-27 23:36 UTC (permalink / raw)
To: peter fuerst; +Cc: linux-scsi, linux-mips, ralf, James.Bottomley
In-Reply-To: <Pine.LNX.4.58.0711272348360.407@Indigo2.Peter>
On Wed, Nov 28, 2007 at 12:00:39AM +0100, peter fuerst wrote:
> unlike with sgiseeq.c, in sgiwd93.c there's no need to bloat the hpc_chunk
> and only a single dma_cache_sync-call is necessary in fill_hpc_entries and
> init_hpc_chain respectively.
funny I realized that a couple of minutes ago. A kernel with this
changes booted ok. I'll post an updated driver tomorrow.
Thomas.
--
Crap can work. Given enough thrust pigs will fly, but it's not necessary a
good idea. [ RFC1925, 2.3 ]
^ permalink raw reply
* Re: [PATCH] IP28 support
From: peter fuerst @ 2007-11-28 1:33 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126224004.D885AC2B26@solo.franken.de>
Hello Thomas,
unfortunately a little change to ip28_be_interrupt is needed (sorry, that
it was not yet applied):
---
diff -u -p a/arch/mips/sgi-ip22/ip28-berr.c b/arch/mips/sgi-ip22/ip28-berr.c
--- a/arch/mips/sgi-ip22/ip28-berr.c
+++ b/arch/mips/sgi-ip22/ip28-berr.c
@@ -597,7 +597,7 @@ static int ip28_be_interrupt(const struc
goto mips_be_fatal;
/* Any state other than "GIO transaction bus timed out" is fatal. */
- if (gio_err_stat & GIO_ERRMASK & ~SGIMC_GSTAT_TIME)
+ if (gio_err_stat & GIO_ERRMASK /* & ~SGIMC_GSTAT_TIME */)
goto mips_be_fatal;
/* Finding `cpu_err_addr' in the insn at EPC is fatal. */
---
Since identification of HPC3-dma-addresses in ip28_be_interrupt does not
work as intended, currently any GIO-bus-error must be taken as fatal, or
a "real" bus-error might slip through undetected as "speculative":
When the bus-error occurs CBP is already advanced, so it won't match the
offending address. Examining the current dma-descriptor for a pbuf-address-
range, that might contain this address, isn't possible either, since NDP
is already advanced to the next descriptor.
GIO error 0x401:<TIME > @ 0x7e390000
HPC3 (scsi1) @ 1fb92000: ctl 00000014, ndp 2043c010, cbp 7e390180
Dumping sgiwd93_host1 dma-descriptors: 900000002043c000:
pnext pbuf cntinfo
[ 0] 2043c010 7e390000 00002000 8192 cbp == [0].pbuf+0x180
ndp -> [ 1] 2043c020 7e392000 00002000 8192
[ 2] 2043c030 7e394000 00002000 8192
...
[255] 2043c000 00000000 80000000 0
So, for reliable detection of HPC3-dma-addresses the bus-error-handler would
need access to the descriptor-chain of each HPC3-driver, which would require
any such driver to register its descriptor chain with the bus-error-handler...
Experience suggests, that the possibility of false positives, caused by the
workaround, should be comparatively neglibible.
kind regards
peter
On Mon, 26 Nov 2007, Thomas Bogendoerfer wrote:
> Date: Mon, 26 Nov 2007 23:40:04 +0100 (CET)
> From: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> To: linux-mips@linux-mips.org
> Cc: ralf@linux-mips.org
> Subject: [PATCH] IP28 support
>
> Add support for SGI IP28 machines (Indigo 2 with R10k CPUs)
> This work is mainly based on Peter Fuersts work.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
> ---
>
> ...
> diff --git a/arch/mips/sgi-ip22/ip28-berr.c b/arch/mips/sgi-ip22/ip28-berr.c
> new file mode 100644
> index 0000000..e61e8f3
> --- /dev/null
> +++ b/arch/mips/sgi-ip22/ip28-berr.c
> ...
^ permalink raw reply
* mips build breakage in current mainline
From: Andrew Morton @ 2007-11-28 6:16 UTC (permalink / raw)
To: Ralf Baechle; +Cc: linux-mips
allmodconfig...
arch/mips/kernel/csrc-r4k.c:9: error: syntax error before "c0_hpt_read"
arch/mips/kernel/csrc-r4k.c:10: warning: return type defaults to `int'
arch/mips/kernel/csrc-r4k.c: In function `c0_hpt_read':
arch/mips/kernel/csrc-r4k.c:11: error: implicit declaration of function `read_c0_count'
arch/mips/kernel/csrc-r4k.c: At top level:
arch/mips/kernel/csrc-r4k.c:14: error: variable `clocksource_mips' has initializer but incomplete type
arch/mips/kernel/csrc-r4k.c:15: error: unknown field `name' specified in initializer
arch/mips/kernel/csrc-r4k.c:15: warning: excess elements in struct initializer
arch/mips/kernel/csrc-r4k.c:15: warning: (near initialization for `clocksource_mips')
arch/mips/kernel/csrc-r4k.c:16: error: unknown field `read' specified in initializer
arch/mips/kernel/csrc-r4k.c:16: warning: excess elements in struct initializer
arch/mips/kernel/csrc-r4k.c:16: warning: (near initialization for `clocksource_mips')
arch/mips/kernel/csrc-r4k.c:17: error: unknown field `mask' specified in initializer
arch/mips/kernel/csrc-r4k.c:17: error: implicit declaration of function `CLOCKSOURCE_MASK'
arch/mips/kernel/csrc-r4k.c:17: warning: excess elements in struct initializer
arch/mips/kernel/csrc-r4k.c:17: warning: (near initialization for `clocksource_mips')
arch/mips/kernel/csrc-r4k.c:18: error: unknown field `flags' specified in initializer
arch/mips/kernel/csrc-r4k.c:18: error: `CLOCK_SOURCE_IS_CONTINUOUS' undeclared here (not in a function)
arch/mips/kernel/csrc-r4k.c:18: warning: excess elements in struct initializer
arch/mips/kernel/csrc-r4k.c:18: warning: (near initialization for `clocksource_mips')
arch/mips/kernel/csrc-r4k.c:21: error: syntax error before "init_mips_clocksource"
arch/mips/kernel/csrc-r4k.c:22: warning: return type defaults to `int'
arch/mips/kernel/csrc-r4k.c: In function `init_mips_clocksource':
arch/mips/kernel/csrc-r4k.c:24: error: invalid use of undefined type `struct clocksource'
arch/mips/kernel/csrc-r4k.c:24: error: `mips_hpt_frequency' undeclared (first use in this function)
arch/mips/kernel/csrc-r4k.c:24: error: (Each undeclared identifier is reported only once
arch/mips/kernel/csrc-r4k.c:24: error: for each function it appears in.)
arch/mips/kernel/csrc-r4k.c:26: error: implicit declaration of function `clocksource_set_clock'
arch/mips/kernel/csrc-r4k.c:28: error: implicit declaration of function `clocksource_register'
arch/mips/kernel/csrc-r4k.c: At top level:
arch/mips/kernel/csrc-r4k.c:14: error: storage size of `clocksource_mips' isn't known
make[1]: *** [arch/mips/kernel/csrc-r4k.o] Error 1
make: *** [arch/mips/kernel/csrc-r4k.o] Error 2
^ permalink raw reply
* [UPDATED PATCH] SGIWD93: use cached memory access to make driver work on IP28
From: Thomas Bogendoerfer @ 2007-11-26 17:41 UTC (permalink / raw)
To: linux-scsi, linux-mips; +Cc: ralf, James.Bottomley
Changes to last version:
- no additional padding of hpc descriptor
- one dma_cache_sync after hpc descriptors are setup is enough
Thomas.
SGI IP28 machines would need special treatment (enable adding addtional
wait states) when accessing memory uncached. To avoid this pain I
changed the driver to use only cached access to memory.
Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
---
drivers/scsi/sgiwd93.c | 64 +++++++++++++++++++++++++++++------------------
1 files changed, 39 insertions(+), 25 deletions(-)
diff --git a/drivers/scsi/sgiwd93.c b/drivers/scsi/sgiwd93.c
index eef8275..e64ddee 100644
--- a/drivers/scsi/sgiwd93.c
+++ b/drivers/scsi/sgiwd93.c
@@ -33,10 +33,9 @@
struct ip22_hostdata {
struct WD33C93_hostdata wh;
- struct hpc_data {
- dma_addr_t dma;
- void *cpu;
- } hd;
+ dma_addr_t dma;
+ void *cpu;
+ void *dev;
};
#define host_to_hostdata(host) ((struct ip22_hostdata *)((host)->hostdata))
@@ -46,6 +45,11 @@ struct hpc_chunk {
u32 _padding; /* align to quadword boundary */
};
+/* space for hpc dma descriptors */
+#define HPC_DMA_SIZE PAGE_SIZE
+
+#define DMA_DIR(d) ((d == DATA_OUT_DIR) ? DMA_TO_DEVICE : DMA_FROM_DEVICE)
+
static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
{
struct Scsi_Host * host = dev_id;
@@ -59,15 +63,17 @@ static irqreturn_t sgiwd93_intr(int irq, void *dev_id)
}
static inline
-void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp)
+void fill_hpc_entries(struct ip22_hostdata *hd, struct scsi_cmnd *cmd, int din)
{
unsigned long len = cmd->SCp.this_residual;
void *addr = cmd->SCp.ptr;
dma_addr_t physaddr;
unsigned long count;
+ struct hpc_chunk *hcp;
- physaddr = dma_map_single(NULL, addr, len, cmd->sc_data_direction);
+ physaddr = dma_map_single(hd->dev, addr, len, DMA_DIR(din));
cmd->SCp.dma_handle = physaddr;
+ hcp = hd->cpu;
while (len) {
/*
@@ -89,6 +95,9 @@ void fill_hpc_entries(struct hpc_chunk *hcp, struct scsi_cmnd *cmd, int datainp)
*/
hcp->desc.pbuf = 0;
hcp->desc.cntinfo = HPCDMA_EOX;
+ dma_cache_sync(hd->dev, hd->cpu,
+ (unsigned long)(hcp + 1) - (unsigned long)hd->cpu,
+ DMA_TO_DEVICE);
}
static int dma_setup(struct scsi_cmnd *cmd, int datainp)
@@ -96,9 +105,8 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
struct ip22_hostdata *hdata = host_to_hostdata(cmd->device->host);
struct hpc3_scsiregs *hregs =
(struct hpc3_scsiregs *) cmd->device->host->base;
- struct hpc_chunk *hcp = (struct hpc_chunk *) hdata->hd.cpu;
- pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hcp);
+ pr_debug("dma_setup: datainp<%d> hcp<%p> ", datainp, hdata->cpu);
hdata->wh.dma_dir = datainp;
@@ -111,12 +119,12 @@ static int dma_setup(struct scsi_cmnd *cmd, int datainp)
if (cmd->SCp.ptr == NULL || cmd->SCp.this_residual == 0)
return 1;
- fill_hpc_entries(hcp, cmd, datainp);
+ fill_hpc_entries(hdata, cmd, datainp);
pr_debug(" HPCGO\n");
/* Start up the HPC. */
- hregs->ndptr = hdata->hd.dma;
+ hregs->ndptr = hdata->dma;
if (datainp)
hregs->ctrl = HPC3_SCTRL_ACTIVE;
else
@@ -134,6 +142,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt,
if (!SCpnt)
return;
+ if (SCpnt->SCp.ptr == NULL || SCpnt->SCp.this_residual == 0)
+ return;
+
hregs = (struct hpc3_scsiregs *) SCpnt->device->host->base;
pr_debug("dma_stop: status<%d> ", status);
@@ -145,8 +156,9 @@ static void dma_stop(struct Scsi_Host *instance, struct scsi_cmnd *SCpnt,
barrier();
}
hregs->ctrl = 0;
- dma_unmap_single(NULL, SCpnt->SCp.dma_handle, SCpnt->SCp.this_residual,
- SCpnt->sc_data_direction);
+ dma_unmap_single(hdata->dev, SCpnt->SCp.dma_handle,
+ SCpnt->SCp.this_residual,
+ DMA_DIR(hdata->wh.dma_dir));
pr_debug("\n");
}
@@ -160,22 +172,23 @@ void sgiwd93_reset(unsigned long base)
hregs->ctrl = 0;
}
-static inline void init_hpc_chain(struct hpc_data *hd)
+static inline void init_hpc_chain(void *dev, struct ip22_hostdata *hdata)
{
- struct hpc_chunk *hcp = (struct hpc_chunk *) hd->cpu;
- struct hpc_chunk *dma = (struct hpc_chunk *) hd->dma;
+ struct hpc_chunk *hcp = (struct hpc_chunk *)hdata->cpu;
+ dma_addr_t dma = hdata->dma;
unsigned long start, end;
start = (unsigned long) hcp;
- end = start + PAGE_SIZE;
+ end = start + HPC_DMA_SIZE;
while (start < end) {
- hcp->desc.pnext = (u32) (dma + 1);
+ hcp->desc.pnext = (u32) (dma + sizeof(struct hpc_chunk));
hcp->desc.cntinfo = HPCDMA_EOX;
- hcp++; dma++;
+ hcp++;
+ dma += sizeof(struct hpc_chunk);
start += sizeof(struct hpc_chunk);
};
hcp--;
- hcp->desc.pnext = hd->dma;
+ hcp->desc.pnext = hdata->dma;
}
static int sgiwd93_bus_reset(struct scsi_cmnd *cmd)
@@ -234,16 +247,17 @@ static int __init sgiwd93_probe(struct platform_device *pdev)
host->irq = irq;
hdata = host_to_hostdata(host);
- hdata->hd.cpu = dma_alloc_coherent(&pdev->dev, PAGE_SIZE,
- &hdata->hd.dma, GFP_KERNEL);
- if (!hdata->hd.cpu) {
+ hdata->dev = &pdev->dev;
+ hdata->cpu = dma_alloc_noncoherent(&pdev->dev, HPC_DMA_SIZE,
+ &hdata->dma, GFP_KERNEL);
+ if (!hdata->cpu) {
printk(KERN_WARNING "sgiwd93: Could not allocate memory for "
"host %d buffer.\n", unit);
err = -ENOMEM;
goto out_put;
}
- init_hpc_chain(&hdata->hd);
+ init_hpc_chain(&pdev->dev, hdata);
regs.SASR = wdregs + 3;
regs.SCMD = wdregs + 7;
@@ -273,7 +287,7 @@ static int __init sgiwd93_probe(struct platform_device *pdev)
out_irq:
free_irq(irq, host);
out_free:
- dma_free_coherent(NULL, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma);
+ dma_free_noncoherent(NULL, HPC_DMA_SIZE, hdata->cpu, hdata->dma);
out_put:
scsi_host_put(host);
out:
@@ -289,7 +303,7 @@ static void __exit sgiwd93_remove(struct platform_device *pdev)
scsi_remove_host(host);
free_irq(pd->irq, host);
- dma_free_coherent(&pdev->dev, PAGE_SIZE, hdata->hd.cpu, hdata->hd.dma);
+ dma_free_noncoherent(&pdev->dev, HPC_DMA_SIZE, hdata->cpu, hdata->dma);
scsi_host_put(host);
}
^ permalink raw reply related
* Re: BUG: using smp_processor_id() in preemptible code
From: Ralf Baechle @ 2007-11-28 11:23 UTC (permalink / raw)
To: Pavel Kiryukhin; +Cc: linux-mips
In-Reply-To: <73cd086a0711270820r92dc164heaa453e94cf1a8c6@mail.gmail.com>
On Tue, Nov 27, 2007 at 07:20:47PM +0300, Pavel Kiryukhin wrote:
> I get the following bug running 2.6.18 on malta34Kc .
>
> Freeing prom memory: 956kb freed
> Freeing firmware memory: 978944k freed
> Freeing unused kernel memory: 180k freed
> BUG: using smp_processor_id() in preemptible [00000000] code: swapper/1
> caller is r4k_dma_cache_wback_inv+0x144/0x2a0
> Call Trace:
> [<80117af8>] r4k_dma_cache_wback_inv+0x144/0x2a0
> [<802e4b84>] debug_smp_processor_id+0xd4/0xf0
> [<802e4b7c>] debug_smp_processor_id+0xcc/0xf0
> ...
> CONFIG_DEBUG_PREEMPT is enabled.
> --
> Bug cause is blast_dcache_range() in preemptible code [in
> r4k_dma_cache_wback_inv()].
> blast_dcache_range() is constructed via __BUILD_BLAST_CACHE_RANGE that
> uses cpu_dcache_line_size(). It uses current_cpu_data that use
> smp_processor_id() in turn. In case of CONFIG_DEBUG_PREEMPT
> smp_processor_id emits BUG if we are executing with preemption
> enabled.
>
> Cpu options of cpu0 are assumed to be the superset of all processors.
>
> Can I make the same assumptions for cache line size and fix this
> issue the following way:
That's safe and probably saner than littlering preempt_disable /
preempt_enable calls over the code.
Ralf
^ permalink raw reply
* Re: [PATCH] Use correct dma flushing in dma_cache_sync()
From: Ralf Baechle @ 2007-11-28 9:43 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071127183133.CB8DDC2B2D@solo.franken.de>
On Tue, Nov 27, 2007 at 07:31:33PM +0100, Thomas Bogendoerfer wrote:
> Not cache coherent R10k systems (like IP28) need to do real cache
> invalidates in dma_cache_sync().
Queued for 2.6.25,
Ralf
^ permalink raw reply
* Re: [PATCH] IP28: added cache barrier to assembly routines
From: Ralf Baechle @ 2007-11-28 9:53 UTC (permalink / raw)
To: Thomas Bogendoerfer; +Cc: linux-mips
In-Reply-To: <20071126223955.9BAAAC2B26@solo.franken.de>
On Sun, Nov 25, 2007 at 11:47:56AM +0100, Thomas Bogendoerfer wrote:
> IP28 needs special treatment to avoid speculative accesses. gcc
> takes care for .c code, but for assembly code we need to do it
> manually.
>
> This is taken from Peter Fuersts IP28 patches.
>
> Signed-off-by: Thomas Bogendoerfer <tsbogend@alpha.franken.de>
Queued for 2.6.25 as well.
Thanks,
Ralf
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox