Re: problem with bus_dmamap_load_uio
On Monday 03 November 2008 03:50:21 pm Patrick Lamaizière wrote: > Hello, > > (8-Current/i386) > > I've got a problem with bus_dmamap_load_uio(9). I want to use it to > map an uio for DMA with the Geode security block (glxsb(4)). > > It works, i can make milions of crypto operations with cryptotest. > > But when (i guess, i'm not sure) the free memory becomes low, > bus_dmamap_load_uio() fails with errno == EFBIG. > > I can reproduce the problem by running "periodic daily", "dd > if=/dev/zero of=foo", ... > > By sample i run into problems with Mem: 33M Active, 310M Inact, 82M > Wired, 60M Buf, 69M Free. > > When it fails the uio is : > uio_segflg = UIO_SYSSPACE > uio_iovcnt = 1, > totlen = 16384 (the total length for iov) > uio_resid = 16384 > > (i've got some failure with size between 4000 and 16384) > > I don't understand why bus_dmamap_load_uio() cannot load the uio. Also > when it fails, i copy the uio into a buffer and then a > bus_dmamap_load() of the buffer always works. > > The dma tag is allocated with: > > bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev),/* parent */ > 16, 0, /* alignments, bounds */ > BUS_SPACE_MAXADDR_32BIT, /* lowaddr */ > BUS_SPACE_MAXADDR, /* highaddr */ > NULL, NULL, /* filter, filterarg */ > 16384, /* maxsize */ > 1, /* nsegments */ > 16384, /* maxsegsize */ > BUS_DMA_ALLOCNOW,/* flags */ > NULL, NULL, /* lockfunc, lockarg */ > &sc->sc_dmat); > > The dma map is created just before the bus_dmamap_load_uio() and > destroyed later. > > (source : http://user.lamaiziere.net/patrick/glxsb.c , see > glxsb_crypto_encdec() ). > > I'm trying to understand and fix this problem for several days, so any > idea will be very cool... Your dma tag only allows a single scatter/gather entry (nsegments). What is happening is that under memory pressure, the virtual buffer in userland is not built from physically contiguous pages, so you would need multiple s/g entries to describe the buffer. Hence EFBIG. If your hardware can handle multiple s/g entries, then just increase 'nsegments' and handle the multiple segments in your callback routine. -- John Baldwin ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: includes, configure, /usr/lib vs. /usr/local/lib, and linux coders
That's alot of good info. It should go in the porter's handbook, maybe... So, if I'm looking to make a port, which one of those people should I be acting as? Maintainer? That's FreeBSD-port-terminology you are using, correct? Steve On Sat, Nov 1, 2008 at 8:55 AM, Giorgos Keramidas <[EMAIL PROTECTED]> wrote: > On Fri, 31 Oct 2008 12:30:46 -0700, "Steve Franks" <[EMAIL PROTECTED]> wrote: >> Let's backup. What's the 'right' way to get a bloody linux program >> that expects all it's headers in /usr/include to compile on freebsd >> where all the headers are in /usr/local/include? That's all I'm >> really asking. Specifically, it's looking for libusb & libftdi. If I >> just type gmake, it can't find it, but if I manually edit the >> Makefiles to add -I/usr/local/include, it can. Obviously, manually >> editing the makefiles is *not* the right way to fix it (plus it's >> driving me crazy). > > Then you run `configure' with the `right' environment: > >env CPPFLAGS='-I/usr/local/include' \ > LDFLAGS='-L/usr/local/lib' ./configure > > The `--includedir' and `--libdir' options are *not* meant to be useful > to the developer that uses the GNU build tools, but to the person who > compiles something for the target host. > > There are several types of people involved in the `release' of a full > program: > >* The maintainer, who uses `automake', `libtool' and `autoconf' to > write portable Makefiles and build tools. > >* The builder, who compiles the program with specific options. > >* The packager, who runs `make install' in the build tree, creates a > set of installed files, and then packages *some* of these files in > a packaging-specific format. > > These types of people commonly have different constraints in the way > they can tweak and twist the GNU build tools, to match their needs. > > 1. The _maintainer_ of the program is free to set up his environment to > include any `CPPFLAGS', `CFLAGS' or `LDFLAGS' they find useful. For > example, if they have an experimental third-party library installed > in a custom location they can use: > > export CPPFLAGS='-I/opt/foolib/include' LDFLAGS='-L/opt/foolib/lib' > ./configure --prefix='/var/tmp/myprog' > > This way `configure' will emit Makefiles that try to use the > third-party library from `/opt/foolib' instead of the system-default > location for header files and libraries. > > This may often be a lot easier than waiting until the necessary bits > are installed in the ``official'' places at development systems. > Developers who want to experiment with a new version of `libfoo', > i.e. to integrate it with the rest of a program, can use custom > `CPPFLAGS' and `LDFLAGS' while everyone else is merrily going along > with the ``standard'' version of the `libfoo' library. > > 2. The _builder_ may be constrained in the sets of options he can pass > to the `CFLAGS'. He is, after all, testing how a pristine, clean > version of the program can build in what is defined as the ``official > release'' environment. > > He may be allowed to tinker with include paths and library paths, but > it is often safer to wrap the build process in scripts and tools that > yield a repeatable, verifiable build process. This may preclude the > use of options like `-I/custom/hdr/path' and `-L/custom/lib/path'. > > The builder of a program may not be an actual person, but a cron job > or another automated process, i.e. a `nightly build' script that runs > a clean build in a pristine environment, verifies that it can all > complete without errors, and then emails one or more reports. > > When the builder _is_ a real person, he may be sharing roles with the > third type of person involved in the build life of a program that > uses the GNU build tools: the packaging person. > > 3. The _packager_ is someone who runs `make install', to produce the > final program distribution and then bundles parts of or even all the > files that are produced by the usual `install' target of GNU tools. > The installation of all the files may be done in the default > installation `prefix', but it may also be redirected to a staging > area by setting `DESTDIR' in the environment: > > mkdir /var/tmp/proto > env DESTDIR=/var/tmp/proto make install > > Depending on the type of the target system, and on particular needs > of the packaging person, there may be cases where certain files have > to be installed in a `non-standard' location, or in a location that > was not foreseen by the original maintainer. In that case, the > packager can use the `--libdir' and `--includedir' options to change > the final, installed location of the relevant bits. > > A typical example is the case of Solaris systems, where libraries may > be installed in `/usr/lib/64' for 64-bit architectures. When a > packager prepares installation images for these architectures, he can > build the program with: > >
problem with bus_dmamap_load_uio
Hello, (8-Current/i386) I've got a problem with bus_dmamap_load_uio(9). I want to use it to map an uio for DMA with the Geode security block (glxsb(4)). It works, i can make milions of crypto operations with cryptotest. But when (i guess, i'm not sure) the free memory becomes low, bus_dmamap_load_uio() fails with errno == EFBIG. I can reproduce the problem by running "periodic daily", "dd if=/dev/zero of=foo", ... By sample i run into problems with Mem: 33M Active, 310M Inact, 82M Wired, 60M Buf, 69M Free. When it fails the uio is : uio_segflg = UIO_SYSSPACE uio_iovcnt = 1, totlen = 16384 (the total length for iov) uio_resid = 16384 (i've got some failure with size between 4000 and 16384) I don't understand why bus_dmamap_load_uio() cannot load the uio. Also when it fails, i copy the uio into a buffer and then a bus_dmamap_load() of the buffer always works. The dma tag is allocated with: bus_dma_tag_create(bus_get_dma_tag(sc->sc_dev),/* parent */ 16, 0, /* alignments, bounds */ BUS_SPACE_MAXADDR_32BIT, /* lowaddr */ BUS_SPACE_MAXADDR, /* highaddr */ NULL, NULL, /* filter, filterarg */ 16384, /* maxsize */ 1, /* nsegments */ 16384, /* maxsegsize */ BUS_DMA_ALLOCNOW,/* flags */ NULL, NULL, /* lockfunc, lockarg */ &sc->sc_dmat); The dma map is created just before the bus_dmamap_load_uio() and destroyed later. (source : http://user.lamaiziere.net/patrick/glxsb.c , see glxsb_crypto_encdec() ). I'm trying to understand and fix this problem for several days, so any idea will be very cool... thanks, regards. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: How to troubleshoot wireless problem?
On 11/3/08, Yuri <[EMAIL PROTECTED]> wrote: > My FreeBSD is able to connect to WiFi WEP network 95% of time. > But 5% of time either ifconfig shown "not associated" status or dhclient > fails to get IP address or name resolution isn't functioning > after DHCP exchange is complete. Signal strength is -80:-95. > After a while I am able to connect again. > This happens with both ath0 and ral0 devices. > > In the meantime Linux box sitting next to FreeBSD box has > no problem connecting to the same WiFi network at all times. > > This makes me think that something in FreeBSD isn't working right. > > How can I troubleshoot this problem? > How stable is support for wireless networking in FreeBSD? > > I use this command line: > ifconfig wepmode on ssid my-ssid weptxkey 1 wepkey 0xMYKEY dhcp > on 7.1-PRERELEASE In wlan(4) it is explained in detail how to enable debuging. Also every driver have its own ways to toggle debug options. Note that wlan and driver modules must be compiled with debug enabled(at least it works in that way on CURRENT). Look in NOTES for explanation. ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
How to troubleshoot wireless problem?
My FreeBSD is able to connect to WiFi WEP network 95% of time. But 5% of time either ifconfig shown "not associated" status or dhclient fails to get IP address or name resolution isn't functioning after DHCP exchange is complete. Signal strength is -80:-95. After a while I am able to connect again. This happens with both ath0 and ral0 devices. In the meantime Linux box sitting next to FreeBSD box has no problem connecting to the same WiFi network at all times. This makes me think that something in FreeBSD isn't working right. How can I troubleshoot this problem? How stable is support for wireless networking in FreeBSD? I use this command line: ifconfig wepmode on ssid my-ssid weptxkey 1 wepkey 0xMYKEY dhcp on 7.1-PRERELEASE Yuri ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
