* Re: [bug] block subsystem related crash on Legacy iSeries viodasd.c
From: Will Schmidt @ 2007-10-22 13:56 UTC (permalink / raw)
To: Jens Axboe; +Cc: Stephen Rothwell, linux-kernel, linuxppc-dev
In-Reply-To: <20071021124426.GS10674@kernel.dk>
On Sun, 2007-10-21 at 14:44 +0200, Jens Axboe wrote:
> On Fri, Oct 19 2007, Will Schmidt wrote:
> > Hi Jens, Stephen, and Everyone else.
...
> You need this, will remember to fix that up for the new branch as well.
>
> diff --git a/drivers/block/viodasd.c b/drivers/block/viodasd.c
> index e824b67..2ce3622 100644
> --- a/drivers/block/viodasd.c
> +++ b/drivers/block/viodasd.c
> @@ -270,6 +270,7 @@ static int send_request(struct request *req)
> d = req->rq_disk->private_data;
>
> /* Now build the scatter-gather list */
> + memset(sg, 0, sizeof(sg));
> nsg = blk_rq_map_sg(req->q, req, sg);
> nsg = dma_map_sg(d->dev, sg, nsg, direction);
>
That appears to do the trick. Thanks!
Tested-By: Will Schmidt <will_schmidt@vnet.ibm.com>
^ permalink raw reply
* Re: SystemACE driver problem
From: aauer1 @ 2007-10-22 13:50 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710191120w209b62a0l4f71e528e5f1a1b3@mail.gmail.com>
Hello,
I have partly solved my problem with the System ACE controller. And I think
it may be interesting for. I don't know the real cause of the problem,
because it is very difficult to reproduce it. But I think the problem is
anywhere in the initialization of the System ACE controller.
So, I started a new design with the Xilinx platform studio and wrote my own
code to read the first sector of the CF card. This code is not very
beautiful, but it works. So, I configured the FPGA and downloaded my
program. And wow... I get the first sector of the card.
Afterwards, I reseted the System ACE controller and downloaded the
zImage.elf from my kernel. Now, the kernel can initialize the CF card and
mount the root filesystem. Wonderful!
If the problem occurs again, I will have a closer look.
For the sake of completeness, my init code:
================================
XStatus status;
XSysAce SysAce;
int i=0;
volatile short *ptr = (short *)0x41800000; // BASE Address of SYSACE
volatile char *cptr = (char *) 0x41800000; // BASE Address of SYSACE
print("\r\nTesting SysAce for SysACE_CompactFlash...\r\n");
status = XSysAce_Initialize(&SysAce, XPAR_SYSACE_COMPACTFLASH_DEVICE_ID);
if(status != XST_SUCCESS)
{
print("Init... FAILED\r\n");
}
else
{
print("Init... PASSED\r\n");
printf("Base Address: %x\r\n",SysAce.BaseAddress);
printf("Is Ready: %x\r\n",SysAce.IsReady);
printf("sizeof(short): %d\r\n", sizeof(short));
printf("Status0 value: %x\r\n",ptr[2]);
printf("Status1 value: %x\r\n",ptr[3]);
printf("Error0 value: %x\r\n",ptr[4]);
printf("Error1 value: %x\r\n",ptr[5]);
printf("Version value: %x\r\n",ptr[0xb]);
printf("Ctrl0 value: %x\r\n",cptr[0x18]);
printf("Ctrl0 value: %x\r\n",cptr[0x18]);
ptr[0xc] = 0x0300;
printf("Status0 value: %x\r\n",ptr[2]);
while(!(ptr[2] & 0x0200));
print("Lock granted\r\n");
while(!(ptr[2] & 0x0001));
print("Ready for command\r\n");
ptr[8] = 0x0000; // LBA
ptr[9] = 0x0000; // LBA
ptr[10] = 0x0103;
ptr[0xc] = 0x8000;
while(!(ptr[3] & 0x0200));
print("Busy cleared\r\n");
printf("Status0 value: %x\r\n",ptr[2]);
while(!(ptr[2] & 0x2000));
print("Data Buffer is ready\r\n");
for(i=0;i<256;i++)
{
printf("0x%04x\r\n", ptr[0x20]&0xffff);
}
ptr[0xc] = 0x0100;
printf("Status0 value: %x\r\n",ptr[2]);
printf("Ctrl0 value: %x\r\n",ptr[0xc]);
printf("Ctrl1 value: %x\r\n",ptr[0xd]);
Cheers,
Andreas
Grant Likely-2 wrote:
>
> On 10/19/07, aauer1 <aauer1@gmx.at> wrote:
>>
>>
>>
>> Grant Likely-2 wrote:
>> >
>> > On 10/19/07, aauer1 <aauer1@gmx.at> wrote:
>> >>
>> >> Hello
>> >>
>> >> I'm trying to boot a Linux Kernel 2.6.23-rc2 from Grant Likely (thanks
>> >> for
>> >> the great work) on a Xilinx ML403 board. I want to use the second
>> >> partition
>> >> of the Compact Flash Card as root filesystem. But the boot process
>> hangs
>> >> at
>> >> the initialization of the SystemACE module. A strange effect is that
>> the
>> >> DONE LED (configuration of the FPGA is done) turns off. So, this means
>> >> that
>> >> the FPGA loses his configuration.
>> >> Has anybody recognized a similar problem with the SystemACE module??
>> >>
>> >> The boot log:
>> >> ========
>> > [snipped]
>> >> [ 0.268807] uartlite.0: ttyUL0 at MMIO 0x40600000 (irq = 2) is a
>> >> uartlite
>> >> [ 0.270399] console [ttyUL0] enabled
>> >> [ 1.762725] RAMDISK driver initialized: 8 RAM disks of 8192K size
>> 1024
>> >> blocke
>> >> [ 1.852062] Registering Xilinx SystemACE driver, major=254
>> >> [ 1.919734] xsysace xsysace.0: ace_probe(c01638e0)
>> >
>> > Yes, I've seen that. It means something went wrong with the setup and
>> > caused the sysace to reload the FPGA. Is the systemace base address
>> > and bus width set correctly?
>> >
>> >
>>
>> The base address is the same as in the system.mhs file of my hardware
>> design. So, I think it should be correct. The bus width is set to 16 bits
>> (hardware design). So far as I can see, the sysace driver defines a 16
>> bit
>> data bus (hard coded), too.
>
> Hmmm; that's all very odd. I don't know what could be causing that.
>
>> A paper of BlueCat Linux says that there is a problem with the System ACE
>> hardware module:
>> "Due to a known problem of the opb_sysace IP Core programmed into the
>> FPGA
>> (incorrect operation in the interrupt mode) the SystemACE Compact Flash
>> device is supported in the polling mode."
>>
>> Does anyone know something about the bug in the SystemACE IP core??
>
> I don't know about the old xilinx supplied sysace driver, but the new
> xsysace.c driver is robust enough to work around missed interrupts. I
> don't know of any other problems with the opb_sysace IP core.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
>
>
--
View this message in context: http://www.nabble.com/SystemACE-driver-problem-tf4651846.html#a13342284
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* RE: [PATCH] [POWERPC] ucc_geth: Eliminate compile warnings
From: Medve Emilian-EMMEDVE1 @ 2007-10-22 13:47 UTC (permalink / raw)
To: David Miller; +Cc: netdev, jgarzik, linuxppc-dev
In-Reply-To: <20071019.164143.75786621.davem@davemloft.net>
Hello David,
> No piece of code in the kernel should live in a vacuum.
>=20
> In order to improve overall code quality, every piece of
> driver code should avoid assuming things about pointer
> sizes and things of this nature.
I'm afraid we might be talking about orthogonal issues here. I actively
agree that all code (not only kernel) should be written up to the
coding/quality standards you mention above, but I see a difference
between fixing a warning and making a driver portable (to 64-bit
PowerPCs, to other platforms, etc.). If there is a kernel todo list
somewhere lets add to it the task to make the ucc_geth more portable.
> Then the driver can get enabled into the build on every
> platform, and therefore nobody will break the build of
> this driver again since it will get hit by "allmodconfig"
> et al. builds even on platforms other than the one it is
> meant for.
>=20
> This hack fix is not acceptable, really.
Are you suggesting we leave those warnings there until somebody decides
to fix all the portability issues of this driver? My patch is a small
and insignificant improvement and not the revolution you're asking for,
but is an small improvement today (I dislike warnings) vs. an improbable
big one in the future.
Leo, as author and maintainer of this driver, what's your take on this?
Cheers,
Emil.
^ permalink raw reply
* Re: Device trees and audio codecs
From: Timur Tabi @ 2007-10-22 13:07 UTC (permalink / raw)
To: Jon Smirl; +Cc: PowerPC dev list
In-Reply-To: <9e4733910710210701x67b2e99frd0784ac2c8bd27fd@mail.gmail.com>
Jon Smirl wrote:
> Doing it that way will make the kernel specific to the target device.
> Currently I can load the same mpc5200 kernel on several different
> target devices since the platform specific code is triggered in the
> probe machine phase.
Maybe I need to take a look at your code, but the fabric driver is, in
effect, a platform-specific driver. Its job is to figure out what
hardware is on the board, how it's connected, and then initialize and
connect the other drivers as appropriate.
> I tried making the fabric driver into a platform driver instead of an
> openfirmware driver, but the mpc5200 code is not initializing platform
> drivers correctly.
Yeah, that wouldn't work. Platform drivers are initialized way too early.
> I could insert calls into arch/powerpc/platforms/52xx/whatever to load
> the specific asoc fabric, but doing that is a mess. There must be a
> way to trigger loading of machine specific drivers
Either you do it at driver __init time, or via a probe. The probe
actually occurs at __init time, anyway, so they're kinda the same thing.
The only thing the probe gets you is that you're called multiple times
for each instance of a node in the tree.
>> Since the Apple audio drivers are not ASoC drivers, I suggest we don't pay
>> attention to what they do.
>
> Those Apple drivers are very similar to asoc drivers. They could
> easily be folded into the asoc code.
Perhaps, but that's a job for another day (and another developer).
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: Jon Loeliger @ 2007-10-22 12:36 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev
In-Reply-To: <20d6133a9294d4f06a7e78ca627ec4f3@kernel.crashing.org>
So, like, the other day Segher Boessenkool mumbled:
> > Property names have been limited to start with
> > characters from the set [a-zA-Z,._#?]. That is, the
> > digits and the expression symbols have been removed.
>
> This cannot work; many property names start with a digit,
> for example.
Are any of those property names in use in any
of our DTS files or b-w-o.txt? Not really, no.
In fact, with this lexical change, all of our
DTS files still produce byte-identical results.
I really think this is one of those areas where
we may need to stray from the other guideline.
Is there a compelling reason somewhere? Really?
jdl
^ permalink raw reply
* Re: Difference between ioremap() and phy_to_virt() Kernel function
From: Arnd Bergmann @ 2007-10-22 11:04 UTC (permalink / raw)
To: linuxppc-embedded; +Cc: Misbah khan
In-Reply-To: <13339930.post@talk.nabble.com>
On Monday 22 October 2007, Misbah khan wrote:
> Could you Please let me know what is the difference between ioremap() and
> phy_to_virt() function being provided by the Kernel.
ioremap gives you a new mapping for I/O addresses that you can access
with functions like in_be32 and the like.
phy_to_virt() is rarely used at all, it only serves to convert a physical
address for main memory (RAM) into the address used inside of the kernel.
Arnd <><
^ permalink raw reply
* Difference between ioremap() and phy_to_virt() Kernel function
From: Misbah khan @ 2007-10-22 10:03 UTC (permalink / raw)
To: linuxppc-embedded
Hi all
Could you Please let me know what is the difference between ioremap() and
phy_to_virt() function being provided by the Kernel.
--Misbah
--
View this message in context: http://www.nabble.com/Difference-between-ioremap%28%29-and-phy_to_virt%28%29-Kernel-function-tf4669833.html#a13339930
Sent from the linuxppc-embedded mailing list archive at Nabble.com.
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 8:04 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <200710221542.10592.wangbj@lzu.edu.cn>
> Yup, I've found how does the kernel handle tlbs, I think the most important
> thing is I forgot read/write the SPRN_SPRG3 register as _switch does.
SPRG3 is for use by the operating system for whatever you want... if you
are copying linux code, then you probably indeed want to get that right
but you don't have to use SPRG3.
> I've add the _PAGE_PRESENT flag to the related PTE
Hrm.. that has nothing ot do with the PTE. Bolting is more a property of
your replacement algorithm in the TLB miss handler.
Ben.
^ permalink raw reply
* Re: [Rtlinuxgpl] ppc manual paging question
From: Nicholas Mc Guire @ 2007-10-22 7:53 UTC (permalink / raw)
To: Wang, Baojun; +Cc: rtlinuxgpl, Miguel Masmano, linuxppc-dev
In-Reply-To: <393096168.21831@eyou.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
> OK, Shall I look for the DataTLBError code in head.S? I realized that I've got
> DataTLBError sometimes via BDI2000/kgdb (the fault address is within
> DataTLBError), Shall I should also look for arch/ppc/mm/fault.c?
>
if you end up in fault.c (via call to handle_page_fault) then I think you
allready had an invalid access - you should not have ended there if the
tlb entries would have been loaded properly from where ever XM put them
(not in any pgd that linux knows of) - no COW or lazy mechanism available
as the pgd of the domains are not handled in fault.c .
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHHFcZnU7rXZKfY2oRAtKLAJ4pdGYGSrv/WFEraJiiHdeGndVupwCgiz56
Le5QyhS1dpfdgb0pbe5hLRk=
=PutX
-----END PGP SIGNATURE-----
^ permalink raw reply
* Re: ppc manual paging question
From: Wang, Baojun @ 2007-10-22 7:42 UTC (permalink / raw)
To: benh, linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <393039004.29574@lzu.edu.cn>
[-- Attachment #1: Type: text/plain, Size: 1775 bytes --]
On Monday 22 October 2007 15:34:24, Benjamin Herrenschmidt wrote：
> > Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's
> > almost nothing like in ppc 4xx/44x.
>
> You'll have to get yourself a 44x manual :-)
>
> > > It's a software loaded TLB, you'll have to put translations in the TLB
> > > yourself. You'll need to design your own data structures for that, tho
> > > you can use a page table for tracking, like we do in linux, and then
> > > have your own TLB miss handler to fill the TLB from that.
> >
> > OK, Shall I look for the DataTLBError code in head.S? I realized that
> > I've got DataTLBError sometimes via BDI2000/kgdb (the fault address is
> > within DataTLBError), Shall I should also look for arch/ppc/mm/fault.c?
>
> head_44x.S is where you'll find some guidance
Yup, I've found how does the kernel handle tlbs, I think the most important
thing is I forgot read/write the SPRN_SPRG3 register as _switch does.
> > > Your initial code probably need to bolt a TLB entry for the kernel
> > > itself.
> >
> > I don't understand this clearly, how can I do this?
>
> Well, you insert a TLB entry manually and avoid replacing it later on
I've add the _PAGE_PRESENT flag to the related PTE
> Ben.
Thanks very much I'm now getting much clearer about my question:)
Regards,
Wang
--
Wang, Baojun Lanzhou University
Distributed & Embedded System Lab http://dslab.lzu.edu.cn
School of Information Science and Engeneering wangbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 .P.R.China
Tel:+86-931-8912025 Fax:+86-931-8912022
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 7:34 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <200710221417.43544.wangbj@lzu.edu.cn>
> Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's
> almost nothing like in ppc 4xx/44x.
You'll have to get yourself a 44x manual :-)
> > It's a software loaded TLB, you'll have to put translations in the TLB
> > yourself. You'll need to design your own data structures for that, tho
> > you can use a page table for tracking, like we do in linux, and then
> > have your own TLB miss handler to fill the TLB from that.
> OK, Shall I look for the DataTLBError code in head.S? I realized that I've got
> DataTLBError sometimes via BDI2000/kgdb (the fault address is within
> DataTLBError), Shall I should also look for arch/ppc/mm/fault.c?
head_44x.S is where you'll find some guidance
> > Your initial code probably need to bolt a TLB entry for the kernel
> > itself.
> I don't understand this clearly, how can I do this?
Well, you insert a TLB entry manually and avoid replacing it later on
Ben.
^ permalink raw reply
* Re: ppc manual paging question
From: Wang, Baojun @ 2007-10-22 6:17 UTC (permalink / raw)
To: benh, linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <393033430.04221@lzu.edu.cn>
On Monday 22 October 2007 14:01:33, Benjamin Herrenschmidt wrote=EF=BC=9A
> > I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org)
> > from x86 to ppc, I think I'm near the ending except the above problem.
> > xtratum is doing things like xen but it's much simpler (it's aimed for
> > realtime), it need provides memory space sperations for it's domains, so
> > I need manually paging. Each domain is loaded by a userspace program
> > (instead of the root domain as a kernel module), the loader will load t=
he
> > domain's (ELF staticly excutable) PT_LOAD section into memory, and then
> > raise a properly system call (passing the structurized loaded data as
> > arguments) to load the domain via load_domain_sys(), and at the last st=
ep
> > of loading the domain, xtratum will jump to the entry code of the new
> > domain(asm wrappered start() routine) and then everything should be fin=
e.
> > The problem now is as follow:
> >
> > under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, b=
ut
> > I guess there is something wrong with my mm code so after the domain is
> > loaded, the virt addres 0x100000a0 just point to garbage instead of the
> > right start() routine. So how can I setup paging properly so that the
> > virtual memory could be translated to proper data?
>
> Are you aware that the 440 MMU doesn't actually know what a page table
> is and doesn't load PTEs from memory ?
Sorry I didn't realized that. I've finished looking pem64b.pdf, but it's=20
almost nothing like in ppc 4xx/44x.
> It's a software loaded TLB, you'll have to put translations in the TLB
> yourself. You'll need to design your own data structures for that, tho
> you can use a page table for tracking, like we do in linux, and then
> have your own TLB miss handler to fill the TLB from that.
OK, Shall I look for the DataTLBError code in head.S? I realized that I've =
got=20
DataTLBError sometimes via BDI2000/kgdb (the fault address is within=20
DataTLBError), Shall I should also look for arch/ppc/mm/fault.c?
> Your initial code probably need to bolt a TLB entry for the kernel
> itself.
I don't understand this clearly, how can I do this?
> Ben.
Regards,
Wang
=2D-=20
Wang, Baojun =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Lanzhou University
Distributed & Embedded System Lab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0http://dslab.lzu.edu.cn
School of Information Science and Engeneering =C2=A0 =C2=A0 =C2=A0 =C2=A0wa=
ngbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .P.R.China
Tel:+86-931-8912025 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fax:+86-931-8912022
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 6:01 UTC (permalink / raw)
To: Wang, Baojun; +Cc: linuxppc-dev, rtlinuxgpl, Miguel Masmano
In-Reply-To: <200710221350.31688.wangbj@lzu.edu.cn>
> I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) from
> x86 to ppc, I think I'm near the ending except the above problem. xtratum is
> doing things like xen but it's much simpler (it's aimed for realtime), it
> need provides memory space sperations for it's domains, so I need manually
> paging. Each domain is loaded by a userspace program (instead of the root
> domain as a kernel module), the loader will load the domain's (ELF staticly
> excutable) PT_LOAD section into memory, and then raise a properly system call
> (passing the structurized loaded data as arguments) to load the domain via
> load_domain_sys(), and at the last step of loading the domain, xtratum will
> jump to the entry code of the new domain(asm wrappered start() routine) and
> then everything should be fine. The problem now is as follow:
>
> under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, but I
> guess there is something wrong with my mm code so after the domain is loaded,
> the virt addres 0x100000a0 just point to garbage instead of the right start()
> routine. So how can I setup paging properly so that the virtual memory could
> be translated to proper data?
Are you aware that the 440 MMU doesn't actually know what a page table
is and doesn't load PTEs from memory ?
It's a software loaded TLB, you'll have to put translations in the TLB
yourself. You'll need to design your own data structures for that, tho
you can use a page table for tracking, like we do in linux, and then
have your own TLB miss handler to fill the TLB from that.
Your initial code probably need to bolt a TLB entry for the kernel
itself.
Ben.
^ permalink raw reply
* Re: ppc manual paging question
From: Wang, Baojun @ 2007-10-22 5:50 UTC (permalink / raw)
To: benh, linuxppc-dev, Miguel Masmano, rtlinuxgpl
In-Reply-To: <393029235.18964@lzu.edu.cn>
On Monday 22 October 2007 12:50:52, Benjamin Herrenschmidt wrote=EF=BC=9A
> On Mon, 2007-10-22 at 12:03 +0800, Wang, Baojun wrote:
> > hi,
> >
> > I've got some qeustion about ppc(ppc44x) paging:
> >
> > how can I manually map a virtual address to a physical address through a
> > specific pgd? How does ppc translate virt address to physical one? I
> > think besides from tlb, the CPU will search the page table entries via
> > the pgd, can I alter the pgd value to change the memory translation?
> > under i386, it's very simple, we can just rewrite %%cr3, it even could
> > invalidate all tlb entries automatically, how can I do this under ppc?
> > I've tried rewrite
> > current->mm->pgd and current->thread.pgdir, but sounds like it still not
> > insufficiant, am I missing something vital?
>
> What the heck are you trying to do ? Please explain and I'll tell you
> how to do it properly :-)
I'm porting an adeos nano kernel named xtratum (http://www.xtratum.org) fro=
m=20
x86 to ppc, I think I'm near the ending except the above problem. xtratum i=
s=20
doing things like xen but it's much simpler (it's aimed for realtime), it=20
need provides memory space sperations for it's domains, so I need manually=
=20
paging. Each domain is loaded by a userspace program (instead of the root=20
domain as a kernel module), the loader will load the domain's (ELF staticly=
=20
excutable) PT_LOAD section into memory, and then raise a properly system ca=
ll=20
(passing the structurized loaded data as arguments) to load the domain via=
=20
load_domain_sys(), and at the last step of loading the domain, xtratum will=
=20
jump to the entry code of the new domain(asm wrappered start() routine) and=
=20
then everything should be fine. The problem now is as follow:
under my ppc (440GR/440EP) platform, start() is always at 0x100000a0, but I=
=20
guess there is something wrong with my mm code so after the domain is loade=
d,=20
the virt addres 0x100000a0 just point to garbage instead of the right start=
()=20
routine. So how can I setup paging properly so that the virtual memory coul=
d=20
be translated to proper data?
I can describe in more detail if neccessary.
Thanks very much for take care.
Regards,
Wang
P.S:
The orignal xtratum (x86) code:
#define load_pd(pd) {\
__asm__ __volatile__ ("movl %0,%%cr3": :"r" (__pa(pd))); \
}
#define save_pd(pd) {\
__asm__ __volatile__ ("movl %%cr3, %0\n\t": "=3Dr" (pd) :); \
pd =3D (unsigned long) __va (pd); \
}
=2E..
// Virtual address to page directory entry
#define va2pd(vaddress) ((vaddress) >> PGDIR_SHIFT)
// Virtual address to page table entry
#define va2pt(vaddress) (((vaddress) & 0x3FF000) >> PAGE_SHIFT)
// Page directory and page table to virtual address
#define pdpt2va(pd, pt) (((pd) << PGDIR_SHIFT) | ((pt) << PAGE_SHIFT))
// Next macro allows to obtain a pt address through the page directory
#define get_pd_addr(pd, pd_entry) \
((unsigned long) __va (((unsigned long *)(pd)) [(pd_entry)] & PAGE_MASK))
// And the following one allows to obtain a page address via the page
// table
#define get_pt_addr(pt, pt_entry) \
((unsigned long)__va (((unsigned long *)*(pt)) [(pt_entry)] & PAGE_MASK))
=2E..
static inline void fill_pd_entry (unsigned long pd,
unsigned long pd_entry,
unsigned long pt,
unsigned long flags) {
((unsigned long *)pd) [pd_entry] =3D
((__pa (pt) & PAGE_MASK) | (flags & 0xFFF));
}
static inline void fill_pt_entry (unsigned long pt,
unsigned long pt_entry,
unsigned long page,
unsigned long flags) {
((unsigned long *)pt) [pt_entry] =3D
((__pa (page) & PAGE_MASK) | (flags & 0xFFF));
}
=2E..
static inline unsigned long create_page_directory (unsigned long
(*alloc_page) (void)) {
unsigned long pd =3D (*alloc_page) (), c_pd;
if (!pd) return pd;
save_pd(c_pd);
memset ((unsigned char *) &((unsigned long *) pd)[0],
0, 1024 * sizeof (unsigned long));
memcpy ((unsigned char *) &((unsigned long *) pd)[va2pd(PAGE_OFFSET)],
(unsigned char *) &((unsigned long *) c_pd)[va2pd(PAGE_OFFSET)],
(1024 - va2pd(PAGE_OFFSET)) * sizeof (unsigned long));
return pd;
}
static inline unsigned long allocate_user_page (unsigned long pd,
unsigned long vaddress,
unsigned long (*alloc_page)
(void)) {
unsigned long pt_entry =3D va2pt(vaddress),
pd_entry =3D va2pd(vaddress), pt, page =3D 0;
if (vaddress >=3D PAGE_OFFSET) return 0;
// Check if there is already an allocated pt in the pd table
if (!(((unsigned long *)pd) [pd_entry] & _PAGE_PRESENT)) {
if (!(pt =3D (unsigned long) (*alloc_page) ())) return 0;
fill_pd_entry (pd, pd_entry,
pt, _PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
} else
pt =3D get_pd_addr(pd, pd_entry);
// Check whether there is already an allocated page in the pt table
if (!(((unsigned long *)pt)[pt_entry] & _PAGE_PRESENT)) {
if (!(page =3D (unsigned long) (*alloc_page) ())) return 0;
fill_pt_entry (pt, pt_entry, page,
_PAGE_PRESENT | _PAGE_RW | _PAGE_USER);
}
return page;
}
> Cheers,
> Ben.
=2D-=20
Wang, Baojun =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=
=A0Lanzhou University
Distributed & Embedded System Lab =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0http://dslab.lzu.edu.cn
School of Information Science and Engeneering =C2=A0 =C2=A0 =C2=A0 =C2=A0wa=
ngbj@lzu.edu.cn
Tianshui South Road 222. Lanzhou 730000 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 .P.R.China
Tel:+86-931-8912025 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0=
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0Fax:+86-931-8912022
^ permalink raw reply
* Re: ppc manual paging question
From: Benjamin Herrenschmidt @ 2007-10-22 4:50 UTC (permalink / raw)
To: Wang, Baojun
Cc: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, Miguel Masmano,
linux-embedded
In-Reply-To: <200710221203.24157.wangbj@lzu.edu.cn>
On Mon, 2007-10-22 at 12:03 +0800, Wang, Baojun wrote:
> hi,
>
> I've got some qeustion about ppc(ppc44x) paging:
>
> how can I manually map a virtual address to a physical address through a
> specific pgd? How does ppc translate virt address to physical one? I think
> besides from tlb, the CPU will search the page table entries via the pgd, can
> I alter the pgd value to change the memory translation? under i386, it's very
> simple, we can just rewrite %%cr3, it even could invalidate all tlb entries
> automatically, how can I do this under ppc? I've tried rewrite
> current->mm->pgd and current->thread.pgdir, but sounds like it still not
> insufficiant, am I missing something vital?
What the heck are you trying to do ? Please explain and I'll tell you
how to do it properly :-)
Cheers,
Ben.
^ permalink raw reply
* Re: ppc manual paging question
From: Nicholas Mc Guire @ 2007-10-22 4:40 UTC (permalink / raw)
To: Wang, Baojun
Cc: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, Miguel Masmano,
linux-embedded
In-Reply-To: <393088111.08518@eyou.net>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
>
> I've got some qeustion about ppc(ppc44x) paging:
>
> how can I manually map a virtual address to a physical address through a
> specific pgd? How does ppc translate virt address to physical one? I think
> besides from tlb, the CPU will search the page table entries via the pgd, can
> I alter the pgd value to change the memory translation? under i386, it's very
> simple, we can just rewrite %%cr3, it even could invalidate all tlb entries
> automatically, how can I do this under ppc? I've tried rewrite
> current->mm->pgd and current->thread.pgdir, but sounds like it still not
> insufficiant, am I missing something vital?
>
sur ! same thing flush the tlb
or you will be totally inconsistant - actually the box should not
have survived this treatment in a stable manner. You might want to
look at kernel/ppc-stub.c as a good reference - its a similar problem
gdb also writes into memory without the kernel knowing about it - that
is comparable to what XM is doing - the solution flush the cache/tlb
all over the place - now flushing the cache is evil - but I would do
it for now and we can check alternatives and optimizations later - for
now brute force is the way to go.
for 4xx dont forget to isync after fidling with pgd/pte (see set_context
in entry_4xx.S . As far as I understand 4xx all you would really need to
do is clear the TLB entry and then you get an exception and that is
handled via 0x1100/0x1200 D/I respectively (head_4xx.S) - admitedly Im
not up to this task - need to give the manuals a lock my self to
understand whats going on there ;)
hofrat
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)
iD8DBQFHHCmpnU7rXZKfY2oRAjLmAJ90QwCBHLaglOfJ5QAnJyCCIZDmGwCgh/fD
E76Ki1FdfofUSuVBXL1tG0M=
=/1C5
-----END PGP SIGNATURE-----
^ permalink raw reply
* dtc: data.c doesn't need to include dtc-parser.tab.h
From: David Gibson @ 2007-10-22 4:09 UTC (permalink / raw)
To: Jon Loeliger; +Cc: linuxppc-dev
Presumably we used this #include once, but it's certainly not
necessary now.
Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
Index: dtc/data.c
===================================================================
--- dtc.orig/data.c 2007-10-22 14:03:09.000000000 +1000
+++ dtc/data.c 2007-10-22 14:03:44.000000000 +1000
@@ -19,7 +19,6 @@
*/
#include "dtc.h"
-#include "dtc-parser.tab.h"
void fixup_free(struct fixup *f)
{
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* ppc manual paging question
From: Wang, Baojun @ 2007-10-22 4:03 UTC (permalink / raw)
To: linuxppc-dev, rtlinuxgpl, Nicholas Mc Guire, linux-embedded,
Miguel Masmano
hi,
I've got some qeustion about ppc(ppc44x) paging:=20
how can I manually map a virtual address to a physical address through a=20
specific pgd? How does ppc translate virt address to physical one? I think=
=20
besides from tlb, the CPU will search the page table entries via the pgd, c=
an=20
I alter the pgd value to change the memory translation? under i386, it's ve=
ry=20
simple, we can just rewrite %%cr3, it even could invalidate all tlb entries=
=20
automatically, how can I do this under ppc? I've tried rewrite=20
current->mm->pgd and current->thread.pgdir, but sounds like it still not=20
insufficiant, am I missing something vital?=20
Any hint will be greatly approciated.
Regards,
Wang
P.S:
here is the code:
#define save_pd(pd) ((pd) =3D (unsigned long)(current->mm->pgd))
#define load_pd(pd) (current->mm->pgd =3D (pd))
=2E..
static inline pgd_t* __pgd_offset(unsigned long pgd_base, unsigned long va)
{
return (pgd_t*)((pgd_t*)pgd_base + pgd_index(va));
}
static inline pte_t* pte_offset(pmd_t* pte_base, unsigned long va)
{
return (pte_t*)((pte_t*)pte_base + pte_index(va));
}
static inline unsigned long get_free_pages_atomic(int order)
{
return __get_free_pages(GFP_ATOMIC, order);
}
=2E..
unsigned long create_page_directory (unsigned long (*alloc_page) (void)) {
unsigned long pd, c_pd;
unsigned long idx;
save_pd(c_pd);
pd =3D get_free_pages_atomic(PGD_ORDER);
if(!pd) return 0;
memset((void*)pd, 0, PGD_ORDER << PAGE_SHIFT);
/*
* copy kernel page directies
*/
idx =3D pgd_index(PAGE_OFFSET);
memcpy((pgd_t*)pd + idx, (pgd_t*)c_pd + idx, (PTRS_PER_PGD - idx) *=20
sizeof(pgd_t));
printk(KERN_EMERG"create_page_directory return: 0x%lx, c_pd: 0x%lx\n", pd=
,=20
c_pd);
return pd;
}
/*
* allocate a user page at @vaddress if possible
* TODO: add tlb/slb/bat for fast page/block address translation
*/
unsigned long allocate_user_page (unsigned long pd,
unsigned long vaddress,
unsigned long (*alloc_page) (void)) {
pgd_t* pgd;
pud_t* pud;
pmd_t* pmd;
pte_t* pte;
unsigned long page =3D 0;
#define mm_debug printk
mm_debug("allocate_user_page(0x%lx, 0x%lx, 0x%lx)\n", pd, vaddress,=
=20
alloc_page);
pgd =3D __pgd_offset(pd, vaddress);
if(!pgd_present(*pgd) || !(*pgd)){
pud_t* pud_entry =3D (pud_t*)get_free_pages_atomic(PUD_ORDE=
R);
if(!pud_entry) return 0;
*pgd =3D __pa(pud_entry) & PAGE_MASK;
mm_debug("!pgd_present, pgd: 0x%lx, *pgd: 0x%lx\n", pgd,=20
*pgd);
}
pud =3D pud_offset(pgd, vaddress);
if(!pud_present(*pud) || !(*pud)){
pmd_t* pmd_entry =3D (pmd_t*)get_free_pages_atomic(PMD_ORDE=
R);
if(!pmd_entry) return 0;
*pud =3D __pa(pmd_entry) & PAGE_MASK;
mm_debug("!pud_present, pud: 0x%lx, *pud: 0x%lx\n", pud,=20
*pud);
}
pmd =3D pmd_offset(pud, vaddress);
if(!pmd_present(*pmd) || !(*pmd)){
pte_t* pte_entry =3D (pte_t*)get_free_pages_atomic(PTE_ORDE=
R);
if(!pte_entry) return 0;
*pmd =3D __pa(pte_entry) & PAGE_MASK;
*pmd |=3D _PMD_PRESENT;
mm_debug("!pmd_present, pmd: 0x%lx, *pmd: 0x%lx\n", pmd,=20
*pmd);
}
pte =3D pte_offset(pmd, vaddress);
if(!pte_present(*pte) || !(*pte) || pte_none(*pte)){
unsigned long pfn;
page =3D get_free_pages_atomic(PAGE_ORDER);
mm_debug("page: 0x%lx\n", page);
pfn =3D __pa(page) & PAGE_MASK;
mm_debug("pfn: 0x%lx\n", pfn);
set_pte_at(current->mm, page, pte, pfn_pte(pfn >> PAGE_SHIF=
T,=20
__pgprot(PAGE_SHARED_X)));
mm_debug("pte_present now?: %lld\n", pte_present(*pte));
mm_debug("!pte_present, pte: 0x%lx\n", pte);
}
mm_debug("allocate_user_page: return 0x%lx\n", page);
#undef mm_debug
return page;
}
=2D-=20
Wang, Baojun =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =
=A0 =A0 =A0 =A0 =A0Lanzhou University
Distributed & Embedded System Lab =A0 =A0 =A0 =A0 =A0 =A0 =A0http://dslab.l=
zu.edu.cn
School of Information Science and Engeneering =A0 =A0 =A0 =A0wangbj@lzu.edu=
=2Ecn
Tianshui South Road 222. Lanzhou 730000 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 .P.R.China
Tel:+86-931-8912025 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0=
=A0 =A0Fax:+86-931-8912022
^ permalink raw reply
* Re: SystemACE driver problem
From: Grant Likely @ 2007-10-22 3:24 UTC (permalink / raw)
To: John Hahn; +Cc: linuxppc-embedded
In-Reply-To: <001a01c81456$985b6a90$c9123fb0$@com>
On 10/21/07, John Hahn <jhahn@bcfsemi.com> wrote:
> Grant
>
> Regarding your comment about the new xsysace.c driver vs. the old Xilinx
> one, is that chosen at the kernel config time ?
>
> i.e.
> cp arch/ppc/configs/ml403_defconfig
> make ARCH=ppc CROSS_COMPILE=/opt/eldk4.1/usr/bin/ppc_4xx- oldconfig
>
> ...
> Xilinx SystemACE support (XILINX_SYSACE) [N/m/y/?] (NEW) y
> Xilinx SystemACE support (old driver) (XILINX_SYSACE_OLD) [N/m/y/?] (NEW) N
>
> I am also about build and test with the 2.6.23-rc2 same source. Just wanted
> to be sure I am choosing the right driver for the ml403 reference design
> bits from Xilinx.
Both drivers work. The new driver is faster, but the old driver is
more featurefull. If one isn't working for you, try the other and
report your experiences with both here to the list.
Cheers,
g.
--
Grant Likely, B.Sc., P.Eng.
Secret Lab Technologies Ltd.
grant.likely@secretlab.ca
(403) 399-0195
^ permalink raw reply
* RE: SystemACE driver problem
From: John Hahn @ 2007-10-22 2:52 UTC (permalink / raw)
To: linuxppc-embedded
In-Reply-To: <fa686aa40710191120w209b62a0l4f71e528e5f1a1b3@mail.gmail.com>
Grant
Regarding your comment about the new xsysace.c driver vs. the old Xilinx
one, is that chosen at the kernel config time ?
i.e.
cp arch/ppc/configs/ml403_defconfig
make ARCH=ppc CROSS_COMPILE=/opt/eldk4.1/usr/bin/ppc_4xx- oldconfig
...
Xilinx SystemACE support (XILINX_SYSACE) [N/m/y/?] (NEW) y
Xilinx SystemACE support (old driver) (XILINX_SYSACE_OLD) [N/m/y/?] (NEW) N
I am also about build and test with the 2.6.23-rc2 same source. Just wanted
to be sure I am choosing the right driver for the ml403 reference design
bits from Xilinx.
Thanks
John Hahn
BCF Semiconductor
---
P.S. Sorry for taking the thread off on a slight tangent ...
> From: Grant Likely
> Sent: Friday, October 19, 2007 11:21 AM
>
... <snip>
>
> I don't know about the old xilinx supplied sysace driver, but the new
> xsysace.c driver is robust enough to work around missed interrupts. I
> don't know of any other problems with the opb_sysace IP core.
>
> Cheers,
> g.
>
> --
> Grant Likely, B.Sc., P.Eng.
> Secret Lab Technologies Ltd.
> grant.likely@secretlab.ca
> (403) 399-0195
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
^ permalink raw reply
* Re: [PATCH 5/7] pci: Export the pci_restore_msi_state() function
From: Michael Ellerman @ 2007-10-22 1:49 UTC (permalink / raw)
To: David Miller; +Cc: netdev, mcarlson, linuxppc-dev list, mchan, linux-pci
In-Reply-To: <20071021.162131.43417026.davem@davemloft.net>
[-- Attachment #1: Type: text/plain, Size: 1345 bytes --]
On Sun, 2007-10-21 at 16:21 -0700, David Miller wrote:
> From: "Matt Carlson" <mcarlson@broadcom.com>
> Date: Fri, 19 Oct 2007 14:36:56 -0700
>
> > This patch exports the pci_restore_msi_state() function. This function
> > is needed to restore the MSI state during PCI error recovery.
> >
> > Signed-off-by: Linas Vepstas <linas@austin.ibm.com>
> > Signed-off-by: Matt Carlson <mcarlson@broadcom.com>
> > Signed-off-by: Michael Chan <mchan@broadcom.com>
>
> I'm not so sure about this.
On pseries there's a chance it will work for PCI error recovery, but if
so it's just lucky that firmware has left everything configured the same
way. For actual suspend/resume it will never work, we need to ask
firmware to configure things.
> Perhaps, instead, you should do a pci_msi_disable() and
> pci_msi_enable() in the error detection and recovery sequence.
Yes I think so. That way we can properly reconfigure via the firmware
interface. The other option would be to design some new arch hook to do
resume, but just doing a disable/enable seems simpler to me.
cheers
--
Michael Ellerman
OzLabs, IBM Australia Development Lab
wwweb: http://michael.ellerman.id.au
phone: +61 2 6212 1183 (tie line 70 21183)
We do not inherit the earth from our ancestors,
we borrow it from our children. - S.M.A.R.T Person
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: David Gibson @ 2007-10-22 1:17 UTC (permalink / raw)
To: Olof Johansson; +Cc: linuxppc-dev, scott.wood
In-Reply-To: <20071022011740.GA25222@lixom.net>
On Sun, Oct 21, 2007 at 08:17:40PM -0500, Olof Johansson wrote:
> On Mon, Oct 22, 2007 at 10:36:25AM +1000, David Gibson wrote:
> > On Fri, Oct 19, 2007 at 09:43:55PM -0500, Olof Johansson wrote:
> > > Hi,
> > >
> > > Did it ever?! I get this with current mainline when building default target:
> >
> > I think you must have an old dtc; I'm pretty sure I removed the check
> > for /chosen some time ago. But then I also thought we added a force
> > to the dtc commant line in wrapper ages ago, so now I'm a bit confused.
>
> Hrm, seems like I had an old version. It's a little annoying that it's a
> moving target and it's impossible to find out form a built binary which
> version it is, besides trying to guess based on file time stamps.
>
> A nice enhancement could be to have a "dtc -v" and have the makefile
> verify it before using it.
Current dtc has a -v option. Trying to verify it in Makefile (or more
to the point in the wrapper script) would be a bit.. messy (since the
necessary version kind of depends on the dts file anyway).
Avoiding this sort of hassle is why I'd like to put a copy of dtc in
the kernel tree.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: Olof Johansson @ 2007-10-22 1:23 UTC (permalink / raw)
To: scott.wood, linuxppc-dev
In-Reply-To: <20071022011740.GA25222@lixom.net>
On Sun, Oct 21, 2007 at 08:17:40PM -0500, Olof Johansson wrote:
> A nice enhancement could be to have a "dtc -v" and have the makefile
> verify it before using it.
Looks like current versions do have "-v", my old one didn't. Apologies.
-Olof
^ permalink raw reply
* Re: ep88xc_defconfig doesn't build
From: Olof Johansson @ 2007-10-22 1:17 UTC (permalink / raw)
To: scott.wood, linuxppc-dev
In-Reply-To: <20071022003625.GC17164@localhost.localdomain>
On Mon, Oct 22, 2007 at 10:36:25AM +1000, David Gibson wrote:
> On Fri, Oct 19, 2007 at 09:43:55PM -0500, Olof Johansson wrote:
> > Hi,
> >
> > Did it ever?! I get this with current mainline when building default target:
>
> I think you must have an old dtc; I'm pretty sure I removed the check
> for /chosen some time ago. But then I also thought we added a force
> to the dtc commant line in wrapper ages ago, so now I'm a bit confused.
Hrm, seems like I had an old version. It's a little annoying that it's a
moving target and it's impossible to find out form a built binary which
version it is, besides trying to guess based on file time stamps.
A nice enhancement could be to have a "dtc -v" and have the makefile
verify it before using it.
-Olof
^ permalink raw reply
* Re: [PATCH 4/4] DTC: Begin the path to sane literals and expressions.
From: David Gibson @ 2007-10-22 0:51 UTC (permalink / raw)
To: Segher Boessenkool; +Cc: linuxppc-dev, Jon Loeliger
In-Reply-To: <20d6133a9294d4f06a7e78ca627ec4f3@kernel.crashing.org>
On Sun, Oct 21, 2007 at 07:30:45AM +0200, Segher Boessenkool wrote:
> > Property names have been limited to start with
> > characters from the set [a-zA-Z,._#?]. That is, the
> > digits and the expression symbols have been removed.
>
> This cannot work; many property names start with a digit,
> for example.
Yes, crap. Ok, I guess we just have to put the literal lexer rule
before the property name lexer rule, so literals will be recognized in
preference. Disallowing just those property names which look like
literals is a little warty, but not likely to cause trouble in
practice, I think.
--
David Gibson | I'll have my music baroque, and my code
david AT gibson.dropbear.id.au | minimalist, thank you. NOT _the_ _other_
| _way_ _around_!
http://www.ozlabs.org/~dgibson
^ 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