> it works
> like a charm.
Thanks. Patch sdmmc-driver now submitted.
On Fri Oct 19 09:37:40 EDT 2012, 9f...@hamnavoe.com wrote:
> > it works
> > like a charm.
>
> Thanks. Patch sdmmc-driver now submitted.
could you explain the ccmalloc trick?
- erik
> could you explain the ccmalloc trick?
"cache coherent malloc" - not really a trick, just a way to
ensure SD buffers are cache-aligned and occupy an integral
number of cache lines, to avoid embarrassment when doing
dma on ARM (which bypasses the cache). It costs a bit of
space but saves copyin
Hello everyone,
I have sent an email from arsadogi at inf.uth.gr to iwp9papers at ericjul.dk
in order to submit our paper to the upcoming iwp9, but we have not received a
confirmation yet. The related details at iwp9.org are up to date? There is a
technical problem or the confirmation delay is
> /n/sources/contrib/miller/9/kw
in "plug":
I see you use /usr/miller/bin/arm/usbd, is there something special in
it?
Also, "paq" reappears, do we want it, or is it just leftover?
ripple# diff plug /n/sources/contrib/miller/9/kw/plug
59a60
> sdmmc sdio
On Fri Oct 19 10:01:11 EDT 2012, 9f...@hamnavoe.com wrote:
> > could you explain the ccmalloc trick?
>
> "cache coherent malloc" - not really a trick, just a way to
> ensure SD buffers are cache-aligned and occupy an integral
> number of cache lines, to avoid embarrassment when doing
> dma on AR
On Thu, Oct 18, 2012 at 1:17 PM, John Floren wrote:
> I too find Linux too mainstream: http://i.imgur.com/Wtm16.png
>
Bravo.
- Dan C.
>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?
Sorry, this was leakage from my own experiments. I've now
replaced that plug config with a standard
> easiest to just
> cacheline-align everything in malloc
Might be a good idea for ARM. Until someone produces a
chip with gigantic cache lines?
Another alternative might be to have a separate pool of
uncached memory.
comment it out and uncomment the line above.
On Fri, Oct 19, 2012 at 8:21 AM, wrote:
>> /n/sources/contrib/miller/9/kw
>
> in "plug":
>
> I see you use /usr/miller/bin/arm/usbd, is there something special in
> it?
>
> Also, "paq" reappears, do we want it, or is it just leftover?
>
> rip
> I forgot to say that I'm using the ext2srv version from Plan
> distribution, not the Iruata's from contrib/iru;
> compiling iru's ext2srv gives error:
> term% mk
> 8c -FTVw xfssrv.c
> 8c -FTVw xfile.c
> 8c -FTVw ext2fs.c
> 8c -FTVw ext2subs.c
> 8c -FTVw chat.c
> 8c -FTVw iobuf.c
> 8l -o 8.out xf
On Fri Oct 19 11:40:41 EDT 2012, 9f...@hamnavoe.com wrote:
> > easiest to just
> > cacheline-align everything in malloc
>
> Might be a good idea for ARM. Until someone produces a
> chip with gigantic cache lines?
>
> Another alternative might be to have a separate pool of
> uncached memory.
i'm
> Or you can look in /n/sources/patch/sdmmc-driver.
Thanks, will do. Time to dust off the Plug again. Thank you.
++L
> kw-style caches (16-byte lines)
mem.h says it's 32. But yeah, it's not much.
> i had to look twice to verify i understood the pointer orthodontics.
Correctness proof (or refutation) is left as an exercise for the reader...
Our building electrical people are shutting off power
to our part of the building from 07:00 EDT Saturday
through about 15:00 EDT, they say. Thus we are shutting
down our Plan 9 systems today, starting at 19:00 EDT.
I'll probably come in Saturday and bring them back up.
Now that the sheevaplug is running again, I thought I'd try compiling
Go on it, see how far I'd get.
It seems not very far at all and I'm sure I'm just not seeing the wood
for the trees. Compilation stops when int32 isn't defined:
bangle% ./make.rc
# Building C bootstrap tool.
cmd/dist
# Buildi
Try compiling under iostats.
On 19 October 2012 19:45, wrote:
>
> What I don't understand is where the 386 compilation finds the int32
> definition missing in arm. I lo
I think it's better to specify memory that must have special cache
properties, rather than assuming that everything is.
On Fri Oct 19 17:31:50 EDT 2012, charles.fors...@gmail.com wrote:
> I think it's better to specify memory that must have special cache
> properties, rather than assuming that everything is.
this depends on the ratio of memory that has special cache
properties to the memory that doesn't. if you h
Blocks are intended for IO.
On 19 October 2012 22:49, erik quanstrom wrote:
> Block*s (well at least the buffer)
> needs to be special because the ethernet on the marvell is not
> cache coherent.
>
> Try compiling under iostats.
Thanks for the suggestion, Charles. It does look even more baffling,
but I will look deeper for the relevant details. In the meantime,
these snippets may amuse:
...
12 214200
/usr/lucio/Project/go/include/ureg_x86.h
...
1
Is the main plan9 server down?
Thanks,
D
> Is the main plan9 server down?
Geoff warned us that he was shutting down all Plan 9 equipment at Bell
Labs. He threatened to bring them up later.
++L
Ah nice. Thanks, I completely missed that email.
D
On Oct 20, 2012, at 11:47 AM, lu...@proxima.alt.za wrote:
>> Is the main plan9 server down?
>
> Geoff warned us that he was shutting down all Plan 9 equipment at Bell
> Labs. He threatened to bring them up later.
>
> ++L
>
>
> Try compiling under iostats.
Thanks, Charles, that helped locate the absence of an
"include/plan9/arm/u.h" that seemingly just needs to add a few missing
definitions to the native /arm/include/u.h file.
I also tightened up a few spots in the Go release code and
successfully arrived to the point
25 matches
Mail list logo
