Serial GDB hangs
Hi, I am trying to debug a KLD using serial GDB but it keeps hanging.. ie I will enter the debugger OK, and generally everything will work OK for a while, but then I'll want to do another command and it will just sit there in the ttyin state :-/ It is sometimes recoverable but that requires breaking to the debugger manually after restarting GDB which isn't exactly desirable :( It seems more reliable at 9600 but I would have thought a K7 1Ghz could go a bit faster :-/ (Gdb is running on a PIII-700 laptop) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
PCI read config functions
Hi, I'm trying to write a driver for a serial card - it is fairly simple, but I'm having trouble with some conversions from the Linux driver :) In the Linux driver there is stuff like - if ((rc = pcibios_read_config_byte(bus, dev_fn, PCI_DC_SIO_PORT, nport)) != PCIBIOS_SUCCESSFUL) break; And I think the equiv would be - tmp = pci_read_config(dev, PCI_DC_SIO_PORT, /*bytes*/1); printf(pccom: number of ports - %d\n, tmp); However this just ends up printing 0. (PCI_DC_SIO_PORT is 0x2f) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recv() to a mmap'ed file?
Hi,
WRT to Terry's email, I initialized the file by writing N nul ('\0')
bytes to it.
Alfred Perlstein wrote:
Have you tried the mapping with PROT_READ as well? I don't think
most arches allow for access without PROT_READ along with PROT_WRITE.
Oops.. and I even read the thread a little while ago about PROT_WRITE
alone not working on x86, but working on alpha because write-only
pages are supported on that architecture.. silly me
anyhow, I changed it to use O_RDWR instead of O_WRONLY to open(2) and
then I used both PROT_READ and PROT_WRITE as the protection argument,
and then the file transfer worked like a charm.
Which brings us to the question, on x86 arch why do we even allow a
PROT_WRITE only map to be created? It is useless and a program which
gets a write-only map will think it actually has such a mmap'ed
region, but it will get a SIGBUS if it tries to write to it. It would
be better to return -1 and set errno to EFAULT than to have this brain
damage imho.
--
Farooq
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
Hi, Here are my test news. The -O bug doesn't happen with gcc295 from ports ! I tried all these FLAGS, but noone of them was creating the problems we see with -O : Optimization Options -fcaller-saves -fcse-follow-jumps -fcse-skip-blocks -fdelayed-branch -felide-constructors -fexpensive-optimizations -ffast-math -ffloat-store -fforce-addr -fforce-mem -finline-functions -fkeep-inline-functions -fmemoize-lookups -fno-default-inline -fno-defer-pop -fno-function-cse -fno-inline -fno-peephole -fomit-frame-pointer -frerun-cse-after-loop -fschedule-insns -fschedule-insns2 -fstrength-reduce -fthread-jumps -funroll-all-loops So what does -O exactly ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
STABLE is broken too, but in a different manner. I just added -O and
then this happened.
[algo] :testing inplace_merge #1() (weak) ... eh_test in free(): warning: junk
pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: junk pointer, too high to make sense
eh_test in free(): warning: modified (chunk-) pointer
# gdb eh_test eh_test.core
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
58{
(gdb) bt
#0 0x806630b in void _STL::inplace_mergeSortClass * (__first=0xbfbff0ac,
__middle=0xbfbff23c, __last=0xbfbff3cc) at test_algo.cpp:58
#1 0x8066e8a in void WeakCheckSortBuffer, test_inplace_merge_1
(v=@0xbfbff83c, op=@0xbfbff434, max_iters=200) at test_algo.cpp:216
#2 0x804b41e in test_algo () at test_algo.cpp:248
#3 0x8049e37 in main (argc=3, argv=0xbfbffbe0) at main.cpp:275
#4 0x8049759 in _start ()
Martin
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
subscribe
Mit freundlichen Grüßen / Best Regards Joerg Wagner _ Fa. Arxes NCC AG IM-CAS-CCC-PCH Tel.: +49 214/30-31000 Fax: E-Mail: [EMAIL PROTECTED] Internet : http://www.bayer-ag.de To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded. All cpp* files are the same in the port and our system compilers. And ideas and pointers which subsystems I could test for this breakage ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
On Tue, Mar 12, 2002 at 11:32:25PM -0800, Terry Lambert wrote: The POSIX specification itself is a better reference for POSIX. The copy I have is old, and the Single Unix Specifications I have (the Go Solo 2, and the earlier Draft of the Spec. 1770 from the UNIX International FTP site before it dies in the mid 1990's) aren't exactly the same thing as POSIX (they are X/Open documents, not IEEE). Unfortunately, the real thing is expensive, but necessary, if you are going to use the features it defines in as portable a way as possible. The Single UNIX Specification, Version 3 was released recently, incorporating POSIX 1003.1-2001. I think the standard is available for free (unlike the older POSIX standards) on the web: http://www.unix-systems.org/version3/ The RT stuff is the one listed; the AIO stuff, I'd have to look up; have you found it yet? Or do I need to go diving? The AIO stuff looks to be there in FreeBSD for the most part. Unfortunately in ACE, there is a interdependency between the AIO code and RT signals, so you either have to have all the features implemented, or you can't use any of them. Is there a maintainer or set of maintainers who looks at POSIX stuff for FreeBSD? I notice that in /usr/src/sys/posix4/, there is some code for things like POSIX message queues. Is that code maintained, or has it been deprecated in favor of kqueue? I don't want to get into a debate about the technical merits of POSIX, but I have worked on some projects where adhering to POSIX api's was actually a project requirement due to customer demand. Thanks again. -- Craig RodriguesDistributed Systems and Logistics, Office 6/304 [EMAIL PROTECTED] BBN Technologies, a Verizon company (617) 873-4725 Cambridge, MA To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: firewall and ports
- Original Message - From: Martin Vana [EMAIL PROTECTED] To: [EMAIL PROTECTED] Sent: Tuesday, March 12, 2002 3:55 PM Subject: firewall and ports hi, I sit behind a tough firewall, and none of the ports in port collection is able to fetch files need for install. How could I overcome the firewall? This belongs more on -questions than it does on -hackers. Also, you don't give any specifics on what your firewall does and does not allow you to do. You may be able to fetch through your firewall by enabling passive mode. To do so, set the environment variable FTP_PASSIVE_MODE to anything but no. fetch(1) also has a -p flag that does the same thing. See the manpages for fetch(1) and fetch(3) for other options, including using an ftp and/or an http proxy. JN To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: unionfs and getcwd problem.
On Mon, 2002-03-11 at 00:47, BOUWSMA Beery wrote: Thanks! I'm pleased to report that I applied your patch to my -stable source, and now I'm able to `make buildworld' with my rw unionfs mount of my local hacks, atop a ro nullfs mount with unaltered source, which I'm doing right now. The only obvious `problem' is when a non-r00t user attempts to access the union-mounted fs when the shadow directories have not yet been created, and `permission denied' is returned for all directories that exist below, but not in the unionfs fs. E.g.: Yes, it is because of feature of unionfs to create shadow directories with credentionals of proceses doing rise operation. And if process have no permissions to write into parent directory operation fail. One of possible workarounds do as root find /union/mount/point to create all shadow directories. Another solution is to change behaviour of unionfs to use root-cred while make shadows, and then put attributes/ownership from lower layer to shadows. (but this will take a bit of kernel hacking) thanks, barry bouwsma -- TSB Russian Express, Moscow Vladimir B. Grebenschikov, [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Running different startup scripts on behalf of loaded kernel and kernel modules
In article [EMAIL PROTECTED] you wrote: On Tue, Mar 12, 2002 at 04:38:42PM +0200, Vladimir Terziev wrote: I have to configure a box, which has to run different startup scrips on behalf of loaded kernel and kernel modules at startup. [...] How can I understand, when the startup scripts are going to be runned, which menu item is choosed ? I think that your scripts should set some variables in the loader's environment that can later be passed on to the kernel and read by userland utilities (including startup scripts) - see kenv(1). Yes, you can set a variable in bootforth with : foo s value s my_var setenv ; OK foo OK and, in a startup script, read it with kenv | grep my_var . (There's a bug in setenv when used interactively; it uses the variable's name as its value, too. But it works correctly when used in the definition of a word.) Another (too fancy) way would be to use a file (bootforth has fopen, fread, fwrite, fclose). See libstand(3) and src/sys/boot/ficl/loader.c for more details. Bye, Philipp -- http://www.uni-karlsruhe.de/~un1i/ (,.) \\\@@ ) \= ) cc_|\_,^ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: How to correctly detect POSIX 1003.1b features on FreeBSD?
Craig Rodrigues wrote: The Single UNIX Specification, Version 3 was released recently, incorporating POSIX 1003.1-2001. I think the standard is available for free (unlike the older POSIX standards) on the web: http://www.unix-systems.org/version3/ Thanks for the pointer. The RT stuff is the one listed; the AIO stuff, I'd have to look up; have you found it yet? Or do I need to go diving? The AIO stuff looks to be there in FreeBSD for the most part. Unfortunately in ACE, there is a interdependency between the AIO code and RT signals, so you either have to have all the features implemented, or you can't use any of them. I rather suspected this was the case. THere was a thread on one of the lists recently that talked about hacking up some of the AIO context to simulate a queued signal, as it would normally have appeared had it come back through the AIO. Is there a maintainer or set of maintainers who looks at POSIX stuff for FreeBSD? There are police. Daniel Eischen handles threads, Garret Wollman handles much of everything else, and there are other people who will dip their oars in, if it comes to it (like me; getting involved in this discussion was related to the test macros not working, which is about the extent to which I care about it). I notice that in /usr/src/sys/posix4/, there is some code for things like POSIX message queues. Is that code maintained, or has it been deprecated in favor of kqueue? The easiest answer to this is to look at when it was last changed: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/posix4/ You'll also not that this outs Peter as one of the POSIX mavens who does code in that area... ;^). I don't want to get into a debate about the technical merits of POSIX, but I have worked on some projects where adhering to POSIX api's was actually a project requirement due to customer demand. I have, too. Ususally, they mandated older versions of POSIX, so that they knew they were well supports, and relatively platform independent. E.g. RT signals would not even be considered as part of an implementation for another 2-4 years. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Recv() to a mmap'ed file?
* Farooq Mela [EMAIL PROTECTED] [020313 11:38] wrote: Farooq Mela wrote: region, but it will get a SIGBUS if it tries to write to it. It would be better to return -1 and set errno to EFAULT than to have this brain damage imho. eep... that should be EINVAL... maybe i can be forgiven, though, given the time at which i wrote the message :-) Why should we hide the fact that you are on a brain dead archetecture? :) -- -Alfred Perlstein [[EMAIL PROTECTED]] 'Instead of asking why a piece of software is using 1970s technology, start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
Exception-handling is broken with -O in -stable, and has been for years.
FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds
to implement exceptions, so when the GCC folks broke that path, it was
never fixed. There are supposedly patches floating around that fix the
problem, but they either didn't work as advertised or the ball got dropped.
This problem should exist in -current since I think FreeBSD finally drops
setjmp/longjmp stack unwinds and goes to dwarf 2 unwinds, which do work
(and which are used by the GCC 2.95 port, which also works but which
isn't compatible with /usr/lib/libstdc++.{a,so}).
This issue is why Yahoo! has to use its own build of GCC, and I doubt
we're the only ones...
-Ed
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Ç¿ÁÒµØÕð
»¶ÓÄú·¢±íÄúµÄ¹Ûµã [EMAIL PROTECTED] Changchun-mh2.gif Description: Binary data
Ç¿ÁÒµØÕð
»¶ÓÄú·¢±íÄúµÄ¹Ûµã [EMAIL PROTECTED] Changchun-mh2.gif Description: Binary data
Re: DMA memory allocation/deallocation
I am having some memory allocation woes in my FreeBSD kernel device driver. I allocate DMAable memory with something like: retval = bus_dma_tag_create ... (1 20), 1, (1 20), ... which seems to succeed/work. But when I attempt to release the allocated memory like this: bus_dmamap_unload(memtag, memmap); bus_dmamem_free(memtag, (void *) vaddr, memmap); bus_dmamap_destroy(memtag, memmap); bus_dma_tag_destroy(memtag); there was a contig_free bug that was squashed between 4.4 and 4.5, by Matt Dillon. If I remember correctly there is a slight leak if the contig_malloc failed, but that would not be your problem. it is possible that something else on the system is allocating at least single block in that now freed, but perfect sized chunk. as a result, the new allocation can no longer use that memory and has to search higher in RAM. try a few back to back bus_dmamem_alloc() and bus_dmamem_free() without any other operations and if that is sliding up in RAM there is a(nother) problem in the contiguous free...my guess it will operate normally and the problem is related to someone allocating a block and breaking up that nice contiguous chunk. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 12:15:34PM -0800, Ed Hall wrote: Exception-handling is broken with -O in -stable, and has been for years. FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds to implement exceptions, so when the GCC folks broke that path, it was never fixed. There are supposedly patches floating around that fix the problem, but they either didn't work as advertised or the ball got dropped. We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA memory allocation/deallocation
Thanks for the reply Mark, I tracked my problem down. In 'bus_dmamem_alloc', 'contigmalloc' is used if the size is greater than PAGE_SIZE. However, in 'bus_dmamem_free' the same PAGE_SIZE check is performed, but nothing is done for the case where the size is greater than PAGE_SIZE. So I then called contigfree explicitly in my code, and the memory is released. Another problem though, I am allocating a large DMAable buffer ~300MB. I get to allocate this and free this twice on our system (512MB memory). However, when I try a third time to load my device driver and allocate the memory, it fails. Subsequent attempts also fail. It seems that something is allocating in the middle of my nice big free buffer. Does 'contigalloc' do anything sensible like shuffling arround of pages in physical memory to make room for the requested amount of space? Regards Greg. Quoth mark tinguely: there was a contig_free bug that was squashed between 4.4 and 4.5, by Matt Dillon. If I remember correctly there is a slight leak if the contig_malloc failed, but that would not be your problem. it is possible that something else on the system is allocating at least single block in that now freed, but perfect sized chunk. as a result, the new allocation can no longer use that memory and has to search higher in RAM. try a few back to back bus_dmamem_alloc() and bus_dmamem_free() without any other operations and if that is sliding up in RAM there is a(nother) problem in the contiguous free...my guess it will operate normally and the problem is related to someone allocating a block and breaking up that nice contiguous chunk. -- +--+ | Do you want to know more? www.geocities.com/worfsom/ | | ..ooOO Greg Johnson OOoo.. | | HW/SW Engineer[EMAIL PROTECTED] | | Canon Information Systems Research Australia (CISRA) | | 1 Thomas Holt Dr., North Ryde, NSW, 2113, Australia | | I FLEXed my BISON and it went YACC! - me. | +--+ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
We are using a set of patches that were part of gcc 2.95.3_test3. Do you have a sample program in which exceptions are still broken on FreeBSD 4.5? cd /usr/ports/devel/stlport make install cd work/STL*/test/eh add -O to gcc-freebsd.mk gmake -f gcc-freebsd.mk clean gmake -f gcc-freebsd.mk and see what happens ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
problem : crypto
Hi everybody, I am making my own set of administrative tools and i have one little questions : whitch tool i should use to encrypt data ? are the story about the security of pgp (seems to be a whole, I don't beleive it ) thrue ? is there somethings better ( i wish just encrypt some text-file ) ? To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA memory allocation/deallocation
Thanks for the reply Mark, I tracked my problem down. In 'bus_dmamem_alloc', 'contigmalloc' is used if the size is greater than PAGE_SIZE. However, in 'bus_dmamem_free' the same PAGE_SIZE check is performed, but nothing is done for the case where the size is greater than PAGE_SIZE. So I then called contigfree explicitly in my code, and the memory is released. you may want a bugreport. Another problem though, I am allocating a large DMAable buffer ~300MB. I get to allocate this and free this twice on our system (512MB memory). However, when I try a third time to load my device driver and allocate the memory, it fails. Subsequent attempts also fail. It seems that something is allocating in the middle of my nice big free buffer. Does 'contigalloc' do anything sensible like shuffling arround of pages in physical memory to make room for the requested amount of space? It tries to squeeze out pageable memory, but it is not always successful. no other re-arranging is done because we don't know all the pointers and devices that are using that memory. but since most allocations are done by grabbing the first available chunk that works, you can try the trick of allocating the big things towards the end of the memory range and work your way backwards, unfortunately that would mean bypassing the politically correct way of allocating the buffer by using bus_dmamem_alloc(). Evenually that trick will fail too. You can make that memory static, by not really releasing it. Of course no one else can use it either. the contig allocation leak I alluded to was if you have lots of physical memory, but did not expand the kernel virtual map. then we don't put back the contiguous memory back into the available array. since you should have a kernel virtual of at least 1GB and only physical of 512MB, you are not hitting this situation. --mark tinguely. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 02:08:55PM +0100, Martin Blapp wrote: I removed now #undef DEFAULT_VTABLE_THUNKS and set again #define DWARF2_UNWIND_INFO 1 in the port. The -O tests still succeeded. All cpp* files are the same in the port and our system compilers. And ideas and pointers which subsystems I could test for this breakage ? Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Kris msg32798/pgp0.pgp Description: PGP signature
Re: gcc -O broken in CURRENT
Hi Kris, Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Easy to say, hard to do. STABLE is broken as current is, and it seems that 4.4 and 4.3 are also broken for the STLport test. This is a very difficult thing to do for someone that does not know gcc internals. Impossible for me. I don't have the resources (time) and knowledge (compiler coding) to do this. I can only state that: - plain gcc without patches works - gcc295 from ports works - gcc is STABLE and CURRENT is broken - It's not the dewarf unwinding. Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 11:42:46PM +0100, Martin Blapp wrote: Hi Kris, Did you pursue my suggestion of comparing recent patches in the port and in the source tree? Easy to say, hard to do. STABLE is broken as current is, and it seems that 4.4 and 4.3 are also broken for the STLport test. That gives you MORE information: look for patches to the gcc directory which have been MFCed. This is a very difficult thing to do for someone that does not know gcc internals. You don't have to understand the changes, just look at the cvs logs for the past few months, and try backing out revisions to see if it fixes things, or at least identify a list of possible changes which others can test. Kris msg32800/pgp0.pgp Description: PGP signature
Re: gcc -O broken in CURRENT
Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
[LONG] Re: Performance of FreeBSD vs NetBSD (was: Re: Performance of -current vs -stable)
(sorry for the delay in following-up to this thread; when the Big Blue Room is cloudless and approaching 25 degrees at this time of year, I feel an uncontrollable craving to lock myself in that room most of the day) I wrote: Hmmm, a few weeks ago I did some totally unscientific testing, noting that -current was much slower than -stable, by playing an mp3 with an And then a lot of people responded. So let me attempt to restate things, and possibly clear things up thereby. Or, you can just skip straight to the end, where I reveal just what I did to restore similar performance with FreeBSD that I saw under NetBSD, which shall terminate this thread. One can hope. My observations were as follows: o) I had problems doing ``work'' and listening to mp3s with a native mpg123 binary under both FreeBSD-CURRENT and 4.5-STABLE. o) I had no problems with a comparable native binary and NetBSD-current. o) Both FreeBSD-CURRENT and FreeBSD-stable performed roughly identically, both with and without the kernel WITNESS option, so I wasn't seeing the killer performance there that others have noted, just as a side note. I then asked if any of the config options I posted from part of my kernel configuration for -STABLE were known show-stoppers to be avoided. By the time I had updated my archive of the mailing lists a day or two later, nobody had pointed an accusing finger, so I've decided to do somewhat more extensive testing. Seat-of-the-pants observation with `top' showed an apparent improvement by a factor of two in CPU usage when running the native NetBSD binary under NetBSD. Other observations I've made, that I'll be using as datapoints later, are that a normal `buildworld' for both -current and -stable on this 75MHz hardware take somewhere arount 1000 to 1100 minutes or so; also, a `nice'd `installworld' (out of necessity niced in order to get relatively real-time audio playback with only a few pauses each minute) took two or three hours when running mpg123. Then I took one of the FreeBSD binaries and re-linked it statically, in order to run it under NetBSD as well as both FreeBSDen. With this, the FreeBSD performance was unchanged, whilst that of NetBSD actually improved by `top' to a ratio of ~3:1 CPU usage by FreeBSD. Now I'll be doing other tests, to guess whether this is a real system- like issue, or if it only affects mpg123, or my audio setup, or what. Ideas include timing a comparable build process under NetBSD (which does rather differ from that of FreeBSD, so perhaps only for amusement value), and attempting to run the same build process with both Net- and FreeBSD. Other tests limited to a `buildkernel' may be tried, so I can get more results than a build per day and a half. Hey, oboyoboy, one -STABLE FreeBSD test gave these results: bash-2.05a$ time /usr/obj/ports/5.0/usr/ports/audio/mpg123/work/mpg123-0.59r/mp g123-static-O3-current -t -v /usr/home/mp3/hr-XXL-chillout-11.aug.mp3 [...] Playing MPEG stream from hr-XXL-chillout-11.aug.mp3 ... Junk at the beginning MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 522 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 160 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 308633 [0], Time: 134:22.24 [00:00.00], [120:20] Decoding of hr-XXL-chillout-11.aug.mp3 finished. real35m43.727s user33m41.078s sys 0m19.797s bash-2.05a$ This seems to imply that at 35 realtime minutes for a 120 minute file, FreeBSD-STABLE can play back at about 3 1/2 times realtime on a lightly loaded system. Much closer to the NetBSD `top' CPU ratio. This points to the actual sound k0deZ as being responsible for the slowdown that I experience. Now I'll try to respond to points others have made and further muddy the waters, or something. Martin Ankerl noted: One real test is to measure how long your machine needs to decode a stream without threads with 100% CPU. Using mpg123 you can do this with time mpg123 -t mp3stream.mp3 Good idea. Here's NetBSD-current compared with FreeBSD-current (same static binary on all three OSen): (time /usr/obj/ports/5.0/usr/ports/audio/mpg123/work/mpg123-0.59r/mpg123-static- O3-current -t -v /usr/home/mp3/hr-XXL-chillout-21.okt.mp3 ) NetBSD: [...] Playing MPEG stream from hr-XXL-chillout-21.okt.mp3 ... Junk at the beginning MPEG 1.0, Layer: III, Freq: 44100, mode: Joint-Stereo, modext: 2, BPF : 417 Channels: 2, copyright: No, original: Yes, CRC: No, emphasis: 0. Bitrate: 128 Kbits/s, Extension value: 0 Audio: 1:1 conversion, rate: 44100, encoding: signed 16 bit, channels: 2 Frame# 382927 [0], Time: 166:42.99 [00:00.00], [174:13] Decoding of hr-XXL-chillout-21.okt.mp3 finished. real49m56.748s user48m10.644s sys 0m18.401s FreeBSD-CURRENT: [...] Frame# 382927 [0], Time: 166:42.99 [00:00.00], [174:13] Decoding of hr-XXL-chillout-21.okt.mp3 finished. real
question for recent sysinstall hacker(s)
i see that in 4.5 ipaddr/netmask/defaultrouter are necessary parameters for scripted install.cfg installations (in my case, pxe). how does one go about using dhcp instead? if i'm using pxeboot to install multiple system simultaneously over nfs, i can't have them all using the same ip. in 4.4-release, "tryDHCP=YES" was valid (with no ipaddr/netmask/defaultrouter declarations) please reply via email, and thanks
Re: gcc -O broken in CURRENT
cd /usr/src/gnu/usr.bin/cc make make install On Wed, 13 Mar 2002, Martin Blapp wrote: Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? Martin To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Interesting sysctl variables in Mac OS X with hw info
hw.busfrequency = 133326902 hw.cpufrequency = 66700 hw.cachelinesize = 32 hw.l1icachesize = 32768 hw.l1dcachesize = 32768 hw.l2settings = -2147483648 hw.l2cachesize = 262144 Assuming that some or all of this information can be derived on x86 / alpha / sparc, how useful do folks think it would be to have this information be available from sysctl space? I personally would love to see CPU and bus speed info. - Jordan To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
* Jordan Hubbard [EMAIL PROTECTED] [020313 15:56] wrote: hw.busfrequency = 133326902 hw.cpufrequency = 66700 hw.cachelinesize = 32 hw.l1icachesize = 32768 hw.l1dcachesize = 32768 hw.l2settings = -2147483648 hw.l2cachesize = 262144 Assuming that some or all of this information can be derived on x86 / alpha / sparc, how useful do folks think it would be to have this information be available from sysctl space? I personally would love to see CPU and bus speed info. Those look pretty good. Having the cacheline size available would also help quite a bit for avoiding false sharing for allocation of data structures in smp. -- -Alfred Perlstein [[EMAIL PROTECTED]] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: DMA memory allocation/deallocation
Greg Johnson wrote: Thanks for the reply Mark, I tracked my problem down. In 'bus_dmamem_alloc', 'contigmalloc' is used if the size is greater than PAGE_SIZE. However, in 'bus_dmamem_free' the same PAGE_SIZE check is performed, but nothing is done for the case where the size is greater than PAGE_SIZE. So I then called contigfree explicitly in my code, and the memory is released. Another problem though, I am allocating a large DMAable buffer ~300MB. I get to allocate this and free this twice on our system (512MB memory). However, when I try a third time to load my device driver and allocate the memory, it fails. Subsequent attempts also fail. Yes. This will happen because the memory becomes fragmented. If you allocated a huge block early, then the allocation can always be satisfied. If you deallocate it, then the system is free to use it up. So it can break up the previous space to use for smaller spaces. A subsequent attempt at allocation can therefore not be satisfied using the same memory, and the allocation may succeed, but it will do so at another location, after the allocations. At the very least, I can allocate the memory, make several small allocations, free the memory, and then make several small allocations, which then leaves me with needing to do the alocation after the set of small allocations after the first allcoation. If you are goung to be loading and unloading a driver during developement, and you need a huge gob of memory like this, then the correct approach is to do the allocation at or as soon after boot time as possible, and then reference the allcoated area from your load/unload/load/unload'ed driver. It seems that something is allocating in the middle of my nice big free buffer. Sure. You freed it. Anything that wants memory can alloc that area. Most likely, the allocation is proceeding at the start of the region as new allocations take place after the free. Does 'contigalloc' do anything sensible like shuffling arround of pages in physical memory to make room for the requested amount of space? You mean will it defrag physical memory so that you can do another contiguous allocation, and will it evict clean pages from physical memory to leave a large contiguous space that can subsequently be used by an allocation. The answer is no. What you are trying to do sould occur rarely, and the memory should be committed eary, so that this is never an issue in real life. If you want to fix this problem, you can write a physical memory defragmentation routine. It will probably stall most of the operations on your system, unless you seperate the reserve/commit phases of the malloc, so that you can incrementally reserve the memory as you defragthe map, so that it won't refrag behind you. Another approach for some systems is to seperate the memory, and do small allocations at the bottom and large ones at the top, such that when you need to do a large one, there is still space at the top for the allocation, without causing fragmentation when you fre and reallocate it several times. This approach, expectation zoning for size, is in conflict with another, generally more useful approach, called expectation zoning for persistance. In the second approach, you seperate memory into allocation pools by expectation of how lon an allocation will be held. By doing this, you get a relatively homogeneous lifetime for the memory in each zone. In practice, this will reduce overall fragmentation of the memory map up to 85% (or better, depending on your zone granularity). But it means that large allocations in any given zone are less likely to be successful. If you want to work on defragging physical memory, it's possbile to do, but will be difficult. The first thing that you will need to ensure is that the defragging code is not subject to its own operations. The second is that the space reclaiming code, which can only evict clean pages, or evict to swap dirty pages, doesn't touch any code or data in the paging path at all, or it won't work. In general, the ability to do this was expected to come into FreeBSD with the ELF switchover, but so far the only benefit is that there is an on average saving of 1/2 a page of disk at an increased cost of one page for the code/data duplication split for the combined code/data page. Actually, this was probably the wong way to do the trade, considering disk sizes are still growing faster than RAM, and RAM is limited to 32 bit for a while still). If you want to work on the code, to do this, I'm sure there are people who would be willing to help you out, after you take the lead on some code in that area. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
Alfred Perlstein wrote: * Jordan Hubbard [EMAIL PROTECTED] [020313 15:56] wrote: [ ... ] Assuming that some or all of this information can be derived on x86 / alpha / sparc, how useful do folks think it would be to have this information be available from sysctl space? I personally would love to see CPU and bus speed info. Those look pretty good. Having the cacheline size available would also help quite a bit for avoiding false sharing for allocation of data structures in smp. This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, Mar 13, 2002 at 04:25:00PM -0800, Terry Lambert wrote: This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? My suspicion is that everything that currently runs FreeBSD reliably would be just fine with this setup, but when I brought this up before I recalled seeing a systems with different speeds on each CPU so I mentioned it. I think many of these settings should probalby go in hw.cpu#.xxx syctls since they are cpu attributes not system ones. It seems that the various HA systems with hot swapable CPUs are likely to get into situations where the CPUs don't quite match so it would be nice if we reported things that way. If we went down the path of having per-cpu sysctls then it would also be logical to export CPU versioning info as well as CPU features. That would be port specific of course, but I'm sure we could manage to be more consistant then Linux's /proc/cpuinfo. -- Brooks -- Any statement of the form X is the one, true Y is FALSE. PGP fingerprint 655D 519C 26A7 82E7 2529 9BF0 5D8E 8BE9 F238 1AD4 msg32809/pgp0.pgp Description: PGP signature
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, 13 Mar 2002, Brooks Davis wrote: On Wed, Mar 13, 2002 at 04:25:00PM -0800, Terry Lambert wrote: This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? certainly no reason to not have: hw.cpu.0.clock etc. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
Wouldn't it make the most sense to just have the hw.cpu# stuff you mentioned in email? That's the easiest way to understand the data as a user at least. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com We should not be ashamed to acknowledge truth from whatever source it comes to us, even if it is brought to us by former generations and foreign peoples. For him who seeks the truth there is nothing of higher value than truth itself. al-Kindi (c 801-66) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
On Wed, Mar 13, 2002 at 11:49:52PM +0100, Martin Blapp wrote: Kris, fixes things, or at least identify a list of possible changes which others can test. How can I compile gcc without doing a make world ? cd /usr/src/gnu/usr.bin/cc make all Kris msg32812/pgp0.pgp Description: PGP signature
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, 13 Mar 2002, Jordan Hubbard wrote:
hw.busfrequency = 133326902
hw.cpufrequency = 66700
hw.freq.{bus,cpu}
hw.cachelinesize = 32
hw.l1icachesize = 32768
hw.l1dcachesize = 32768
hw.l2settings = -2147483648
hw.l2cachesize = 262144
hw.cache.size.line
hw.cache.size.l1.i
hw.cache.size.l1.d
hw.cache.l2.settings
hw.cache.size.l2
Right?
--
| Matthew N. Dodd | '78 Datsun 280Z | '75 Volvo 164E | FreeBSD/NetBSD |
| [EMAIL PROTECTED] | 2 x '84 Volvo 245DL| ix86,sparc,pmax |
| http://www.jurai.net/~winter | For Great Justice! | ISO8802.5 4ever |
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
On Wed, 13 Mar 2002, Brooks Davis wrote: On Wed, Mar 13, 2002 at 04:25:00PM -0800, Terry Lambert wrote: This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? I thought it was a real bad thing to run CPUs in SMP systems at different clock rates. In fact, I never thought it was possible. I know I can't on my old 2-way P166 box, but things have changed a lot since '91. -- Matt Emmerton To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
hw.busfrequency = 133326902 hw.cpufrequency = 66700 hw.cachelinesize = 32 hw.l1icachesize = 32768 hw.l1dcachesize = 32768 hw.l2settings = -2147483648 hw.l2cachesize = 262144 Assuming that some or all of this information can be derived on x86 / alpha / sparc, how useful do folks think it would be to have this information be available from sysctl space? I personally would love to see CPU and bus speed info. Note, CPU speed on x86 laptops is variable depending on power control. I'm not sure this is the case on the Apple hardware. Nate To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Interesting sysctl variables in Mac OS X with hw info
Matthew Emmerton wrote: This was actually discussed a while back (a month or two ago). It got really bogged down when someone pointed out that they were running CPUs with different clock rates in their SMP box, just to see what the net effect would be. THe problem was, of course, which one do you report, when the numbers don't match exactly, and/or how do you report both (or N)? I thought it was a real bad thing to run CPUs in SMP systems at different clock rates. In fact, I never thought it was possible. I know I can't on my old 2-way P166 box, but things have changed a lot since '91. It depends on the stepping, and that the external interfaces are all the same (voltage, clock speed for memory and I/O, etc.). PIII's can run this way, for sure. If you want to find out who's doing it, you only need to search the SMP list archives; it wasn't important enough for me to commit the message to memory, I only remember the fact that someone was doing it successfully. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
I wrote: : This problem should exist in -current since I think FreeBSD finally drops ^^ That should be shouldn't. I shouldn't post in a hurry (like I'm doing now). -Ed To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: panic: pmap_enter (closed, thanks!)
In message: [EMAIL PROTECTED] Mike Silbersack [EMAIL PROTECTED] writes: : : On Tue, 12 Mar 2002, Terry Lambert wrote: : : I'm glad the non-8:1 ratio works. I thought that it should; : the only suspicious code, from my point of vies, was the frag : mask calculation. And I had a real hard time believing it to : be wrong, except for Mike's claim that it was broken, since I : haven't personally had problems with it. 8-(. : : -- Terry : : It's not my claim, it's Luigi Rizzo and Warner Losh's claim. I haven't : had any personal experience with such ratios, but I trust that if those : two are pointing the finger, there is a problem. I have strong circumstantial evidence that weird things happen when you don't have 8:1, but not when you have it. I haven't been able to pin things down enough to get a good bug report, however. Maybe it is a red herring, but making only that change to a mfs mount creation (eg 4:1 - 8:1) turns a system from a hang bait on boot (1 in 4 boots hang) to rock solid ( 1000 boots w/o a hang). Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCI read config functions
In message: [EMAIL PROTECTED] Daniel O'Connor [EMAIL PROTECTED] writes: : In the Linux driver there is stuff like - : if ((rc = pcibios_read_config_byte(bus, dev_fn, PCI_DC_SIO_PORT, : nport)) != PCIBIOS_SUCCESSFUL) break; : : And I think the equiv would be - : tmp = pci_read_config(dev, PCI_DC_SIO_PORT, /*bytes*/1); : printf(pccom: number of ports - %d\n, tmp); : : : However this just ends up printing 0. : : (PCI_DC_SIO_PORT is 0x2f) Do you have the right dev? bcr = pci_read_config(sp-sc-dev, CB_PCI_BRIDGE_CTRL, 2); is what I use in the pccard bridge pci driver and it works. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
In message: [EMAIL PROTECTED] Ed Hall [EMAIL PROTECTED] writes: : Exception-handling is broken with -O in -stable, and has been for years. : FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds : to implement exceptions, so when the GCC folks broke that path, it was : never fixed. There are supposedly patches floating around that fix the : problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Porting a userland NFS server
Hi, I am trying to port a program called Katie - http://www.netcraft.com.au/geoffrey/katie/ from Linux. It comprises of a bunch of Perl scripts and some embedded C which talk to a Postgres server and provide a transparent repository file system.. (Please, no vomiting) I have got it to build and run (needs Perl 5.6.x unfortunately), and just recently I got FreeBSD to NFS mount a view, but I can't read the special server info file :( I end up with EFBIG when trying to read the .katie-server-info file, but if I create a file inside the view (eg echo abc foo) then it can be read with no problem, _but_ the dump of NFS traffic doesn't show a read for that file. I have ethereal dumps of a working FreeBSD NFS loopback mount and broken file requests etc if anyone's interested. It would be nice to get this working as the project looks quite useful :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc -O broken in CURRENT
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Ed Hall [EMAIL PROTECTED] writes: : Exception-handling is broken with -O in -stable, and has been for years. : FreeBSD is one of the few systems that use setjmp/longjmp stack unwinds : to implement exceptions, so when the GCC folks broke that path, it was : never fixed. There are supposedly patches floating around that fix the : problem, but they either didn't work as advertised or the ball got dropped. H, C++ exceptions work in -stable with -O and have for at least a year. At least they are working for us in our environment. What's busted? Per thread exception stacks? THat's where I'd look... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: PCI read config functions
On Thu, 2002-03-14 at 18:11, M. Warner Losh wrote: : However this just ends up printing 0. : : (PCI_DC_SIO_PORT is 0x2f) Do you have the right dev? bcr = pci_read_config(sp-sc-dev, CB_PCI_BRIDGE_CTRL, 2); is what I use in the pccard bridge pci driver and it works. I believe so.. The code I pasted is in the probe routine of the device just after a check that the vendor and device ID are correct. Perhaps not all of it is mapped? (or isn't during probe?) Or some other straw grabbing statement :) --- Daniel O'Connor software and network engineer for Genesis Software - http://www.gsoft.com.au The nice thing about standards is that there are so many of them to choose from. -- Andrew Tanenbaum To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM: file swapping (this time in libc): patch
Ok, there are two rather serious problems with this patch: (1) When you use a MAP_PRIVATE mapping, modifications to the mapped memory are backed by swap, not by the file. That is what MAP_PRIVATE does by definition. (2) You can't safely use MAP_SHARED unless you also deal with fork() or you will share what is supposed to be process-private memory across the fork(). -Matt Matthew Dillon [EMAIL PROTECTED] :ehlo. : : I was told that diff format I used is unappropriate for most cases, : so I redo it in unified (-u) format. : : Purpose: to allow developers of large applications to use system : memory allocation routines for allocating in mmap()ed file : instead of writing own ones. Also, allow to run applications that : may use huge amount of memory (like Gimp) without reconfiguring : swap. : : Patch description: the patch implements file-backed memory : allocation for regular malloc() routine. If 'F' flag is set : in malloc options, instead of doing mmap(MAP_ANON), malloc() : maps regions from temporal file. File is growed as neccessary, : and new regions are mapped from the same file. : : Details: to avoid using two methods of allocation (brk() and mmap()) in : the same file, regular allocation altered to use mmap(). This : is done by writing emulators (brk_emulator() and sbrk_emulator()). : File allocator uses single descriptor (usually fd==512). File is : created in directory specified by $SWAPDIR, $TMPDIR or /tmp : (in this order). $SWAPDIR is introduced since often people use : memory file system for /tmp. Temporal file is unlinked after : creation, so it will be deleted automatically at exit. : : Informal testing shows no performance hit comparing with old-style : brk() allocation, and small hit when using file-backed allocation. : : Here the patch (made on 4.3-RELEASE-p20) :=== :--- malloc.c.old Tue Oct 2 12:52:25 2001 :+++ malloc.c Thu Oct 4 20:05:52 2001 :@@ -97,7 +97,7 @@ :... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: VM: file swapping (this time in libc): patch
Oops. I'm sorry! This was an email all the from last october! I didn't mean to resurrect the thread :-) -Matt :ehlo. : : I was told that diff format I used is unappropriate for most cases, : so I redo it in unified (-u) format. : : Purpose: to allow developers of large applications to use system :... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
