freebsd-sparc-digest V5 #204
owner-freebsd...@freebsd.org
freebsd-sparc-digest Saturday, December 28 2002 Volume 05 : Number 204
In this issue:
busdma on sparc
kldxref
sparc64 tinderbox failure
Re: busdma on sparc
Re: ntp problems on sparc
Re: kldxref
Re: ntp problems on sparc
Re: ntp problems on sparc
----------------------------------------------------------------------
Date: Fri, 27 Dec 2002 12:53:23 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: busdma on sparc
Hi,
I have a problem with porting my driver for the Marconi HE ATM card to
sparc:
The driver may (dependend on its cofiguration) need to give a lot of
mbufs and mbuf clusters to the card for its different receive queues. In
the biggest configuration I tried on i386 I have around 2000 clusters and
4000 mbufs. In iommu.c each dmamap eats up 32k of virtual address space
(16k because of the page size and 16k for alignment). This means, that
each mbuf of lesser than 200 bytes eats 32k of virtual DMA address space.
This makes it impossible to allocate enough buffers to the card for high
performance applications. I was under the impression, that mbufs are
already aligned to every possible alignment requirements, so wouldn't it
be possible to reduce the 32k to 16k on request from the driver (perhaps
via one of the BUS_DMA_BUS[1-4] flags?
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 27 Dec 2002 13:44:04 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: kldxref
Hi,
is there any chance of fixing the kldxref problem? It seems to prevent
loading of modules via dependencies which is needed to resolve
inter-module symbol dependencies.
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
Date: Fri, 27 Dec 2002 16:42:11 GMT
From: Mike Barcroft <mi...@sparc64.style9.org>
Subject: sparc64 tinderbox failure
- --------------------------------------------------------------
>>> Rebuilding the temporary build tree
- --------------------------------------------------------------
>>> stage 1: bootstrap tools
- --------------------------------------------------------------
>>> stage 2: cleaning up the object tree
- --------------------------------------------------------------
>>> stage 2: rebuilding the object tree
- --------------------------------------------------------------
>>> stage 2: build tools
- --------------------------------------------------------------
>>> stage 3: cross tools
- --------------------------------------------------------------
>>> stage 4: populating /tinderbox/sparc64/obj/tinderbox/sparc64/src/sparc64/usr/include
- --------------------------------------------------------------
>>> stage 4: building libraries
- --------------------------------------------------------------
>>> stage 4: make dependencies
- --------------------------------------------------------------
>>> stage 4: building everything..
- --------------------------------------------------------------
>>> Kernel build for GENERIC started on Fri Dec 27 16:12:52 GMT 2002
- --------------------------------------------------------------
===> ipfilter
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c: In function `ffs_load_inode':
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `mtype' doesn't match prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: argument `fs' doesn't match prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_subr.c:114: number of arguments doesn't match prototype
/tinderbox/sparc64/src/sys/ufs/ffs/ffs_extern.h:73: prototype declaration
*** Error code 1
Stop in /tinderbox/sparc64/obj/tinderbox/sparc64/src/sys/GENERIC.
*** Error code 1
Stop in /tinderbox/sparc64/src.
*** Error code 1
Stop in /tinderbox/sparc64/src.
------------------------------
Date: Fri, 27 Dec 2002 19:19:35 +0100
From: Thomas Moestl <tmo...@gmx.net>
Subject: Re: busdma on sparc
On Fri, 2002/12/27 at 12:53:23 +0100, Harti Brandt wrote:
> I have a problem with porting my driver for the Marconi HE ATM card to
> sparc:
>
> The driver may (dependend on its cofiguration) need to give a lot of
> mbufs and mbuf clusters to the card for its different receive queues. In
> the biggest configuration I tried on i386 I have around 2000 clusters and
> 4000 mbufs.
Hmmm, so the application is to handle a lot of small packets arriving
(or being sent) at high frequencies, right? What do you need the
clusters for in this case?
Such a high number of maps will also use up quite some kernel memory,
both for the maps themselves and for resource management. I would
suggest to hack up the mbuf allocator to make it possible to allocate
contiguous arrays of mbufs (e.g. one page at a time, which would
amount to 16 to 32 mbufs). This would cut the number of 4000 mbuf maps
to 125 on sparc64. Of course, this would also require some more
management on the driver's part, since mbufs that were handed up
cannot be replaced immediately (which should however not be a problem
from the latency point of view).
There might also be a fragmentation problem, which could be partly
worked around with another mh_flag to tell the allocator to put it
back into a contiguous pool if possible.
> In iommu.c each dmamap eats up 32k of virtual address space (16k
> because of the page size and 16k for alignment).
The page size is just 8kB. The alignment depends on your driver, the
IOMMU code just enforces alignment on a page boundary (i.e. no
additional alignment, since allocations are always on page
boundaries). This means that just 16kB are reserved for small DMA maps.
The additional 8kB are needed to handle cases where a buffer spans a
page boundary. This may not happen with mbufs, but can of course occur
in other situations.
> This means, that each mbuf of lesser than 200 bytes eats 32k of
> virtual DMA address space. This makes it impossible to allocate
> enough buffers to the card for high performance applications. I was
> under the impression, that mbufs are already aligned to every
> possible alignment requirements, so wouldn't it be possible to
> reduce the 32k to 16k on request from the driver (perhaps via one of
> the BUS_DMA_BUS[1-4] flags?
I do not think that using one of the flags would be a good idea, since
it requires drivers to do MD things to an MI API. In any event the
maximum number of pages with the current IOMMU TSB size is 4096, so
this would not help you for the largest configuration. Increasing the
TSB size to 64kB or 128kB might be another option for you.
I am working on a revision of the IOMMU code right now, I'll look into
a better way to get around this.
- Thomas
- --
Thomas Moestl <tmo...@gmx.net> http://www.tu-bs.de/~y0015675/
<t...@FreeBSD.org> http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
------------------------------
Date: Fri, 27 Dec 2002 10:35:03 -0800
From: "David O'Brien" <obr...@FreeBSD.ORG>
Subject: Re: ntp problems on sparc
On Fri, Dec 27, 2002 at 11:17:57AM +0100, Harti Brandt wrote:
> On Thu, 19 Dec 2002, Kris Kennaway wrote:
>
> It seems, that ntpd and friends have problems using hostnames. When I use
> IP numbers they seem to work.
I'm having no problems using ntpd on my blade100 using host names:
# cat /etc/ntpd.conf
server foo.nuxi.com
# ntpdc -c sysinfo
system peer: foo.nuxi.com
system peer mode: client
leap indicator: 00
stratum: 3
precision: -18
root distance: 0.04384 s
root dispersion: 0.02451 s
reference ID: [192.168.1.1]
reference time: c1b71b97.5619fea6 Fri, Dec 27 2002 10:33:59.336
system flags: auth monitor ntp kernel stats
jitter: 0.002502 s
stability: 0.006 ppm
broadcastdelay: 0.003998 s
authdelay: 0.000000 s
------------------------------
Date: Fri, 27 Dec 2002 14:29:06 -0500
From: Jake Burkholder <ja...@locore.ca>
Subject: Re: kldxref
Apparently, On Fri, Dec 27, 2002 at 01:44:04PM +0100,
Harti Brandt said words to the effect of;
>
> Hi,
>
> is there any chance of fixing the kldxref problem? It seems to prevent
> loading of modules via dependencies which is needed to resolve
> inter-module symbol dependencies.
>
What's breaking kldxref is that it reads in kld object files and tries
to read initialized variables from the data section before the files
have been relocated. This only happens to work on other platforms, its
not part of the elf spec and not guaranteed to work at all. The way to
fix it is that everywhere that reads in a kld and accesses the module
metadata data structures has to process the relocations first, so that
the variables get their values poked in. This is not especially hard
to fix, its just not high on my list of fun things to do.
Jake
------------------------------
Date: Fri, 27 Dec 2002 16:16:40 -0800 (PST)
From: Baby Peanut <baby_...@yahoo.com>
Subject: Re: ntp problems on sparc
Is you nsswitch.conf set up correctly?
# cat /etc/nsswitch.conf
hosts: files dns
>Has anyone else run into the following when trying to run ntpd on sparc?
>
>Dec 20 05:51:37 panther2 ntpd[416]: bind() fd 5, family 2, port 123, addr
216.136.204.96, in_classd=0 flags=1 fails: Can't assign requested address
>Dec 20 05:51:41 panther2 ntpd[416]: sendto(216.136.204.18): Bad file
descriptor
>Dec 20 05:51:42 panther2 ntpd[416]: sendto(216.136.204.118): Bad file
descriptor
>Dec 20 05:51:44 panther2 ntpd[416]: sendto(216.136.204.21): Bad file
descriptor
>Dec 20 05:51:53 panther2 ntpd[416]: sendto(216.136.204.27): Bad file
descriptor
>
>Kris
>
__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com
------------------------------
Date: Sat, 28 Dec 2002 17:51:38 +0100 (CET)
From: Harti Brandt <bra...@fokus.gmd.de>
Subject: Re: ntp problems on sparc
On Fri, 27 Dec 2002, David O'Brien wrote:
DO>On Fri, Dec 27, 2002 at 11:17:57AM +0100, Harti Brandt wrote:
DO>> On Thu, 19 Dec 2002, Kris Kennaway wrote:
DO>>
DO>> It seems, that ntpd and friends have problems using hostnames. When I use
DO>> IP numbers they seem to work.
DO>
DO>I'm having no problems using ntpd on my blade100 using host names:
DO>
DO># cat /etc/ntpd.conf
DO>server foo.nuxi.com
DO>
DO># ntpdc -c sysinfo
DO>system peer: foo.nuxi.com
DO>system peer mode: client
DO>leap indicator: 00
DO>stratum: 3
DO>precision: -18
DO>root distance: 0.04384 s
DO>root dispersion: 0.02451 s
DO>reference ID: [192.168.1.1]
DO>reference time: c1b71b97.5619fea6 Fri, Dec 27 2002 10:33:59.336
DO>system flags: auth monitor ntp kernel stats
DO>jitter: 0.002502 s
DO>stability: 0.006 ppm
DO>broadcastdelay: 0.003998 s
DO>authdelay: 0.000000 s
Well than something has changed. All IP addresses were 0.0.0.0 with
hostnames around a month ago and I got exactly the error in the previous
mail.
harti
- --
harti brandt, http://www.fokus.gmd.de/research/cc/cats/employees/hartmut.brandt/private
bra...@fokus.gmd.de, bra...@fokus.fhg.de
------------------------------
End of freebsd-sparc-digest V5 #204
***********************************
To Unsubscribe: send mail to majo...@FreeBSD.org
with unsubscribe freebsd-sparc-digest in the body of the message