linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* map iomem in linux_2_4_dev
@ 2002-05-27  5:59 shaowei dai
  2002-05-27  6:34 ` David Gibson
  0 siblings, 1 reply; 15+ messages in thread
From: shaowei dai @ 2002-05-27  5:59 UTC (permalink / raw)
  To: linuxppc-embedded


Hello, every one:

I've searched through the achieve, but failed to find stuff about mapping
io-memmory in this linux_2_4_dev version.
After check the source code, it seems from 2_4_dev onwards, no need to use
ioremap to map io memory. We
should use io_block_mapping() instead.

What confused me is that after i add the following statement in
m8xx_setup.c. My pcmcia_cs package still can't get access to this address.
The mesage from pcmcia is : GetNextTuple: No more items.

What i add in m8xx_setup.c is:

#ifdef CONFIG_FADS

io_block_mapping(PCMCIA_MEM_ADDR,PCMCIA_MEM_ADDR,PCMCIA_MEM_SIZE,_PAGE_IO);
#endif

But after i insert my PCMCIA card to my FADS board, i check the
/var/log/debug information. I found that:
...
m8xx_pcmcia: SetMemMap(0,0,0x21,300 ns, 0xff020000-0xff020000, 0x0000)
----
Does anyone know why this SetMemMap size is 0 instead of PCMCIA_MEM_SIZE? Is
this the reason of pcmcia module fail?

Appreciate your help!


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-27  5:59 map iomem in linux_2_4_dev shaowei dai
@ 2002-05-27  6:34 ` David Gibson
  2002-05-27  6:51   ` shaowei dai
  0 siblings, 1 reply; 15+ messages in thread
From: David Gibson @ 2002-05-27  6:34 UTC (permalink / raw)
  To: linuxppc-embedded


On Mon, May 27, 2002 at 01:59:54PM +0800, shaowei dai wrote:
>
> Hello, every one:
>
> I've searched through the achieve, but failed to find stuff about mapping
> io-memmory in this linux_2_4_dev version.
> After check the source code, it seems from 2_4_dev onwards, no need to use
> ioremap to map io memory. We
> should use io_block_mapping() instead.

No, you should use ioremap() wherever possible.  Only use
io_block_mapping() if for some strange reason you need to specify the
virtual address.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-27  6:34 ` David Gibson
@ 2002-05-27  6:51   ` shaowei dai
  2002-05-27  8:13     ` Sangmoon Kim
  0 siblings, 1 reply; 15+ messages in thread
From: shaowei dai @ 2002-05-27  6:51 UTC (permalink / raw)
  To: linuxppc-embedded


Hello, David:

Thanks for your reply.  When use ioremap,  it seems you can only know the
virtual address of this mapped address
at runing time. Then for PCMICA package, how can you pass this virtual
address when you compile
that package?  Am i wrong in understanding pcmcia package io memory
requirement? If i'm wrong, could you give me
some reference site to learn more?

regards
shaowei

----- Original Message -----
From: "David Gibson" <david@gibson.dropbear.id.au>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Monday, May 27, 2002 2:34 PM
Subject: Re: map iomem in linux_2_4_dev


>
> On Mon, May 27, 2002 at 01:59:54PM +0800, shaowei dai wrote:
> >
> > Hello, every one:
> >
> > I've searched through the achieve, but failed to find stuff about
mapping
> > io-memmory in this linux_2_4_dev version.
> > After check the source code, it seems from 2_4_dev onwards, no need to
use
> > ioremap to map io memory. We
> > should use io_block_mapping() instead.
>
> No, you should use ioremap() wherever possible.  Only use
> io_block_mapping() if for some strange reason you need to specify the
> virtual address.
>
> --
> David Gibson | For every complex problem there is a
> david@gibson.dropbear.id.au | solution which is simple, neat and
> | wrong.  -- H.L. Mencken
> http://www.ozlabs.org/people/dgibson
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-27  8:13     ` Sangmoon Kim
@ 2002-05-27  8:13       ` shaowei dai
  2002-05-28  0:36         ` David Gibson
  0 siblings, 1 reply; 15+ messages in thread
From: shaowei dai @ 2002-05-27  8:13 UTC (permalink / raw)
  To: Sangmoon Kim, linuxppc-embedded


Hi, Sangmoon:

Thanks. I got it. We've to use io_block_mapping() followed by ioremap() to
map the physical address.

regards.

----- Original Message -----
From: "Sangmoon Kim" <dogoil@etinsys.com>
To: "shaowei dai" <dshaowei@rfnetech.com>;
<linuxppc-embedded@lists.linuxppc.org>
Sent: Monday, May 27, 2002 4:13 PM
Subject: Re: map iomem in linux_2_4_dev


> Hi, Shaowei:
>
> The parameter addr of ioremap is not a virtual address
> but a kind of physical address.
>
> Let us have a device at 0x78000000.
> We can change the address to 0xf0000000 by...
>  io_block_mapping(0xf0000000, 0x78000000, 0x08000000, _PAGE_IO);
> Than what is the return value of ioremap(0x78000000, 0x08000000)?
> That is 0xf0000000.
>
> The system changes the addresses of devices for various reason.
> We only know the original address.
> Than we can use the ioremap to get the changed address.
>
> -Sangmoon Kim-
>
>


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-27  6:51   ` shaowei dai
@ 2002-05-27  8:13     ` Sangmoon Kim
  2002-05-27  8:13       ` shaowei dai
  0 siblings, 1 reply; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-27  8:13 UTC (permalink / raw)
  To: shaowei dai, linuxppc-embedded


Hi, Shaowei:

The parameter addr of ioremap is not a virtual address
but a kind of physical address.

Let us have a device at 0x78000000.
We can change the address to 0xf0000000 by...
 io_block_mapping(0xf0000000, 0x78000000, 0x08000000, _PAGE_IO);
Than what is the return value of ioremap(0x78000000, 0x08000000)?
That is 0xf0000000.

The system changes the addresses of devices for various reason.
We only know the original address.
Than we can use the ioremap to get the changed address.

-Sangmoon Kim-

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-27  8:13       ` shaowei dai
@ 2002-05-28  0:36         ` David Gibson
  2002-05-28  4:42           ` Sangmoon Kim
  0 siblings, 1 reply; 15+ messages in thread
From: David Gibson @ 2002-05-28  0:36 UTC (permalink / raw)
  To: shaowei dai; +Cc: Sangmoon Kim, linuxppc-embedded


On Mon, May 27, 2002 at 04:13:05PM +0800, shaowei dai wrote:
>
> Hi, Sangmoon:
>
> Thanks. I got it. We've to use io_block_mapping() followed by ioremap() to
> map the physical address.

No, that's rubbish.  Use one or the other. ioremap() takes a physical
address and returns the virtual address at which it mapped it.

> From: "Sangmoon Kim" <dogoil@etinsys.com>
> To: "shaowei dai" <dshaowei@rfnetech.com>;
> <linuxppc-embedded@lists.linuxppc.org>
> Sent: Monday, May 27, 2002 4:13 PM
> Subject: Re: map iomem in linux_2_4_dev
>
>
> > Hi, Shaowei:
> >
> > The parameter addr of ioremap is not a virtual address
> > but a kind of physical address.
> >
> > Let us have a device at 0x78000000.
> > We can change the address to 0xf0000000 by...
> >  io_block_mapping(0xf0000000, 0x78000000, 0x08000000, _PAGE_IO);
> > Than what is the return value of ioremap(0x78000000, 0x08000000)?
> > That is 0xf0000000.
> >
> > The system changes the addresses of devices for various reason.
> > We only know the original address.
> > Than we can use the ioremap to get the changed address.
> >
> > -Sangmoon Kim-

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-28  0:36         ` David Gibson
@ 2002-05-28  4:42           ` Sangmoon Kim
  0 siblings, 0 replies; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-28  4:42 UTC (permalink / raw)
  To: linuxppc-embedded


Hi,

>
> No, that's rubbish.  Use one or the other. ioremap() takes a physical
> address and returns the virtual address at which it mapped it.
>

Sometimes it is needed to use  io_block_mapping and ioremap.
io_block_mapping maps a phiscal address to a virtual address.
And ioremap returns the virtual address.
When I ported linux on an MPC755 based custom board.
My hardware didn't running because it had a serial port at 0x78000000.
Linux uses 0 to 0x7fffffff as a virtual memory for applications.
And the address of 0x78000000 overlaped the serial port.
I had to use io_block_mapping to map it at different location on system initialization,
and ioremap to get the mapped address on serial port driver.
I'm sorry, if it's another rubbish.
-Sangmoon Kim-

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
@ 2002-05-28 10:38 Sangmoon Kim
  2002-05-28 13:23 ` Matt Porter
  0 siblings, 1 reply; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-28 10:38 UTC (permalink / raw)
  To: linuxppc-embedded


Hi,
>
> No, that's rubbish.  Use one or the other. ioremap() takes a physical
> address and returns the virtual address at which it mapped it.
>
Sometimes it is needed to use  io_block_mapping and ioremap.
io_block_mapping maps a phiscal address to a virtual address.
And ioremap returns the virtual address.
When I ported linux on an MPC755 based custom board.
My hardware didn't running because it had a serial port at 0x78000000.
Linux uses 0 to 0x7fffffff as a virtual memory for applications.
And the address of 0x78000000 overlaped the serial port.
I had to use io_block_mapping to map it at different location on system initialization,
and ioremap to get the mapped address on serial port driver.
I'm sorry, if it's another rubbish.
-Sangmoon Kim-


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-28 10:38 Sangmoon Kim
@ 2002-05-28 13:23 ` Matt Porter
  2002-05-29  4:57   ` Sangmoon Kim
  0 siblings, 1 reply; 15+ messages in thread
From: Matt Porter @ 2002-05-28 13:23 UTC (permalink / raw)
  To: Sangmoon Kim; +Cc: linuxppc-embedded


On Tue, May 28, 2002 at 07:38:19PM +0900, Sangmoon Kim wrote:
>
> Hi,
> >
> > No, that's rubbish.  Use one or the other. ioremap() takes a physical
> > address and returns the virtual address at which it mapped it.
> >
> Sometimes it is needed to use  io_block_mapping and ioremap.
> io_block_mapping maps a phiscal address to a virtual address.
> And ioremap returns the virtual address.
> When I ported linux on an MPC755 based custom board.
> My hardware didn't running because it had a serial port at 0x78000000.
> Linux uses 0 to 0x7fffffff as a virtual memory for applications.
> And the address of 0x78000000 overlaped the serial port.
> I had to use io_block_mapping to map it at different location on system initialization,
> and ioremap to get the mapped address on serial port driver.
> I'm sorry, if it's another rubbish.

You don't need io_block_mapping.  Follow one of the many examples to
use early_serial_init with an ioremap call for your UART.

The only reason your method works is that the io_block_mapping is
actually using a BAT on our classic PPC platform.  ioremap will
look for an existent BAT mapping and just return the translated
virtual address in this case.  Relying on this is bad practice
since it will not work on other PPC systems.

As David correctly pointed out, only use io_block_mapping when
you absolutely must control the placement of the virtual address.
There are cases when this is necessary since the hardware engineers
always send us garbage to support.  Mapping a UART at init time is
not one of these.

BTW, your UART at physical 0x78000000 has zero bearing on the default
PPC Linux task size virtual addresses from 0-0x7fffffff.

Regards,
--
Matt Porter
porter@cox.net
This is Linux Country. On a quiet night, you can hear Windows reboot.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-28 13:23 ` Matt Porter
@ 2002-05-29  4:57   ` Sangmoon Kim
  2002-05-29  5:47     ` Roland Dreier
  2002-05-29  5:47     ` David Gibson
  0 siblings, 2 replies; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-29  4:57 UTC (permalink / raw)
  To: Matt Porter; +Cc: linuxppc-embedded


Hi,
>
> You don't need io_block_mapping.  Follow one of the many examples to
> use early_serial_init with an ioremap call for your UART.
>
> The only reason your method works is that the io_block_mapping is
> actually using a BAT on our classic PPC platform.  ioremap will
> look for an existent BAT mapping and just return the translated
> virtual address in this case.  Relying on this is bad practice
> since it will not work on other PPC systems.
>
Right, I exactly wanted to do that.
I called io_block_mapping() on initialization code.
More precisly on <board name>_map_io(),
which is in arch/ppc/platforms/<board_name>_setup().
It has nothing to do with competibility.
And... Is there any ppc without BAT?
I didn't know that.

> As David correctly pointed out, only use io_block_mapping when
> you absolutely must control the placement of the virtual address.
Than, if the system initialization code is changed,
the driver code should be changed too.

> There are cases when this is necessary since the hardware engineers
> always send us garbage to support.  Mapping a UART at init time is
> not one of these.
>
Actually, I'm a hardware guy.
In most cases, mapping UART is not needed,
but on the hardware I designed, it is needed.
Because its physical addres is 0x78000000.
Don't blame us too much.
It takes much money to change hardware.

- Sangmoon Kim -

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-29  4:57   ` Sangmoon Kim
@ 2002-05-29  5:47     ` Roland Dreier
  2002-05-29  6:01       ` Sangmoon Kim
  2002-05-29  5:47     ` David Gibson
  1 sibling, 1 reply; 15+ messages in thread
From: Roland Dreier @ 2002-05-29  5:47 UTC (permalink / raw)
  To: Sangmoon Kim; +Cc: linuxppc-embedded


>>>>> "Sangmoon" == Sangmoon Kim <dogoil@etinsys.com> writes:

    Sangmoon> Actually, I'm a hardware guy.  In most cases, mapping
    Sangmoon> UART is not needed, but on the hardware I designed, it
    Sangmoon> is needed.  Because its physical addres is 0x78000000.

You do not need to remap the UART.  It doesn't matter that 0x78000000
is its address.  Linux will not get confused between physical address
of the UART and any virtual address space it may be using.  Just call
ioremap() and give it the address 0x78000000.  It will give you a
virtual address you can use to access the UART.

Best,
Roland

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-29  4:57   ` Sangmoon Kim
  2002-05-29  5:47     ` Roland Dreier
@ 2002-05-29  5:47     ` David Gibson
  2002-05-29  6:14       ` Sangmoon Kim
  2002-05-29 12:48       ` shaowei dai
  1 sibling, 2 replies; 15+ messages in thread
From: David Gibson @ 2002-05-29  5:47 UTC (permalink / raw)
  To: linuxppc-embedded


On Wed, May 29, 2002 at 01:57:34PM +0900, Sangmoon Kim wrote:
>
> Hi,
> >
> > You don't need io_block_mapping.  Follow one of the many examples to
> > use early_serial_init with an ioremap call for your UART.
> >
> > The only reason your method works is that the io_block_mapping is
> > actually using a BAT on our classic PPC platform.  ioremap will
> > look for an existent BAT mapping and just return the translated
> > virtual address in this case.  Relying on this is bad practice
> > since it will not work on other PPC systems.
> >
> Right, I exactly wanted to do that.
> I called io_block_mapping() on initialization code.
> More precisly on <board name>_map_io(),
> which is in arch/ppc/platforms/<board_name>_setup().
> It has nothing to do with competibility.
> And... Is there any ppc without BAT?
> I didn't know that.

Yes there are PPCs without BATs.  e.g. 4xx.

> > As David correctly pointed out, only use io_block_mapping when
> > you absolutely must control the placement of the virtual address.
> Than, if the system initialization code is changed,
> the driver code should be changed too.

That's exactly why ioremap() is preferred - then the initialization
code doesn't need to touch it at all.

> > There are cases when this is necessary since the hardware engineers
> > always send us garbage to support.  Mapping a UART at init time is
> > not one of these.
> >
> Actually, I'm a hardware guy.
> In most cases, mapping UART is not needed,
> but on the hardware I designed, it is needed.
> Because its physical addres is 0x78000000.
> Don't blame us too much.
> It takes much money to change hardware.

Rubbish.  Having a *physical* address of 0x78000000 is no problem at
all, ioremap() will map that (like any other physical address) into a
sensible virtual address.

--
David Gibson			| For every complex problem there is a
david@gibson.dropbear.id.au	| solution which is simple, neat and
				| wrong.  -- H.L. Mencken
http://www.ozlabs.org/people/dgibson

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-29  5:47     ` Roland Dreier
@ 2002-05-29  6:01       ` Sangmoon Kim
  0 siblings, 0 replies; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-29  6:01 UTC (permalink / raw)
  To: Roland Dreier; +Cc: linuxppc-embedded


Thank you.
I'll try that.

> >>>>> "Sangmoon" == Sangmoon Kim <dogoil@etinsys.com> writes:
>
>     Sangmoon> Actually, I'm a hardware guy.  In most cases, mapping
>     Sangmoon> UART is not needed, but on the hardware I designed, it
>     Sangmoon> is needed.  Because its physical addres is 0x78000000.
>
> You do not need to remap the UART.  It doesn't matter that 0x78000000
> is its address.  Linux will not get confused between physical address
> of the UART and any virtual address space it may be using.  Just call
> ioremap() and give it the address 0x78000000.  It will give you a
> virtual address you can use to access the UART.
>
> Best,
> Roland
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-29  5:47     ` David Gibson
@ 2002-05-29  6:14       ` Sangmoon Kim
  2002-05-29 12:48       ` shaowei dai
  1 sibling, 0 replies; 15+ messages in thread
From: Sangmoon Kim @ 2002-05-29  6:14 UTC (permalink / raw)
  To: David Gibson, linuxppc-embedded


OK,
I understand.
Thank you.

----- Original Message -----
From: "David Gibson" <david@gibson.dropbear.id.au>
To: <linuxppc-embedded@lists.linuxppc.org>
Sent: Wednesday, May 29, 2002 2:47 PM
Subject: Re: map iomem in linux_2_4_dev


>
> On Wed, May 29, 2002 at 01:57:34PM +0900, Sangmoon Kim wrote:
> >
> > Hi,
> > >
> > > You don't need io_block_mapping.  Follow one of the many examples to
> > > use early_serial_init with an ioremap call for your UART.
> > >
> > > The only reason your method works is that the io_block_mapping is
> > > actually using a BAT on our classic PPC platform.  ioremap will
> > > look for an existent BAT mapping and just return the translated
> > > virtual address in this case.  Relying on this is bad practice
> > > since it will not work on other PPC systems.
> > >
> > Right, I exactly wanted to do that.
> > I called io_block_mapping() on initialization code.
> > More precisly on <board name>_map_io(),
> > which is in arch/ppc/platforms/<board_name>_setup().
> > It has nothing to do with competibility.
> > And... Is there any ppc without BAT?
> > I didn't know that.
>
> Yes there are PPCs without BATs.  e.g. 4xx.
>
> > > As David correctly pointed out, only use io_block_mapping when
> > > you absolutely must control the placement of the virtual address.
> > Than, if the system initialization code is changed,
> > the driver code should be changed too.
>
> That's exactly why ioremap() is preferred - then the initialization
> code doesn't need to touch it at all.
>
> > > There are cases when this is necessary since the hardware engineers
> > > always send us garbage to support.  Mapping a UART at init time is
> > > not one of these.
> > >
> > Actually, I'm a hardware guy.
> > In most cases, mapping UART is not needed,
> > but on the hardware I designed, it is needed.
> > Because its physical addres is 0x78000000.
> > Don't blame us too much.
> > It takes much money to change hardware.
>
> Rubbish.  Having a *physical* address of 0x78000000 is no problem at
> all, ioremap() will map that (like any other physical address) into a
> sensible virtual address.
>
> --
> David Gibson | For every complex problem there is a
> david@gibson.dropbear.id.au | solution which is simple, neat and
> | wrong.  -- H.L. Mencken
> http://www.ozlabs.org/people/dgibson
>
>
>

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

* Re: map iomem in linux_2_4_dev
  2002-05-29  5:47     ` David Gibson
  2002-05-29  6:14       ` Sangmoon Kim
@ 2002-05-29 12:48       ` shaowei dai
  1 sibling, 0 replies; 15+ messages in thread
From: shaowei dai @ 2002-05-29 12:48 UTC (permalink / raw)
  To: David Gibson, linuxppc-embedded


Hi, David,  Sangmoon and all:

Thanks for all the input.

Now i understand why m8xx_pcmcia.c needs to use io_block_mapping. If we can
use ioremap in the driver, then
we don't need to map the io mem in kernel init. Maybe we can do some
improvement later on this driver.

regards


** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

^ permalink raw reply	[flat|nested] 15+ messages in thread

end of thread, other threads:[~2002-05-29 12:48 UTC | newest]

Thread overview: 15+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2002-05-27  5:59 map iomem in linux_2_4_dev shaowei dai
2002-05-27  6:34 ` David Gibson
2002-05-27  6:51   ` shaowei dai
2002-05-27  8:13     ` Sangmoon Kim
2002-05-27  8:13       ` shaowei dai
2002-05-28  0:36         ` David Gibson
2002-05-28  4:42           ` Sangmoon Kim
  -- strict thread matches above, loose matches on Subject: below --
2002-05-28 10:38 Sangmoon Kim
2002-05-28 13:23 ` Matt Porter
2002-05-29  4:57   ` Sangmoon Kim
2002-05-29  5:47     ` Roland Dreier
2002-05-29  6:01       ` Sangmoon Kim
2002-05-29  5:47     ` David Gibson
2002-05-29  6:14       ` Sangmoon Kim
2002-05-29 12:48       ` shaowei dai

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).