Xorg port problem?
I seem to have problems building xorg-server port on freebsd HEAD with a snapshot of source that is about 5 days old. I'm running AMD64 build everything i've installed is fine except when building xorg-server gcc 4.2starts to use all the memory i have and then exits saying not enough memory (Over 2GBs of RAM + Swap being used). It does this consistently when it tries to compile xf86PciScan.c (hope thats the right file). Sometime the system locks up from this load but i think that ZFS 's fault. I was wondering maybe I just had bad luck with this build? I haven't seen this in previous builds I'm wondering if its GCC 4.2? Note this was done on a completely clean new system. With a ZFS root :-) -- Ali Mashtizadeh علی مشتی زاده ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: Mike Meyer wrote: In [EMAIL PROTECTED], Hartmut Brandt [EMAIL PROTECTED] typed: 1. make and its sub-makes for a) reading the file; b) parsing the file (note that .if and .for processing is done while parsing); c) processing targets. Make and submakes have been gone over already. See URL: http://miller.emu.id.au/pmiller/books/rmch/ . I'm not sure it can be applied to the ports tree, though. I haven't looked into it, but recalled this paper when you mentioned measuring makes and sub-makes. Unfortunately you deleted the sentence before, so I rephrase it: before looking into optimizations find out where the time is actually spend - how many seconds of the hours the process takes, are actually spent in make and sub-makes. If the entire process takes 2 hours of which the makes take 20 seconds then by enhancing performance of make by 50% you win 10 seconds. This is probably not worth a single line of additional code. The paper you point to talks about something entirely different. It think we're talking about two different things. You're talking about the efficiency of make, whereas he's talking about the efficiency of make. Um, wait. You're talking about what I'll call the *internal* efficiency of make, defined as how fast it does the things it does. He's talking about what I'll call the *external* efficiency of make, which is how well it does at doing the minimum amount of work it needs to do. I hope you can see where the confusion comes from. Yeah, from that you deleted the other two of my points in your response where I talked about shells and external commands executed by make. You cited the point where I asked for numbers on *internal* efficiency and the point to a paper about *external* efficiency. I've seen no numbers WHAT actually makes the ports stuff so slow. To make my point a last time: until there are numbers, there is no guess around what to do. harti ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Ali Mashtizadeh wrote: I seem to have problems building xorg-server port on freebsd HEAD with a snapshot of source that is about 5 days old. I'm running AMD64 build everything i've installed is fine except when building xorg-server gcc 4.2starts to use all the memory i have and then exits saying not enough memory (Over 2GBs of RAM + Swap being used). It does this consistently when it tries to compile xf86PciScan.c (hope thats the right file). Sometime the system locks up from this load but i think that ZFS 's fault. I was wondering maybe I just had bad luck with this build? I haven't seen this in previous builds I'm wondering if its GCC 4.2? Note this was done on a completely clean new system. With a ZFS root :-) May not be the answer you want to hear, but I built all the xorg stuff multiple times on -current systems both pre and post the gcc + symver + version bump eras, and didn't have the problems you're seeing. What I don't have though is zfs, so that may be a place to look. One way to check is if you're not doing it already, use an mfs /tmp and see if that helps. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Doug Barton wrote: (Over 2GBs of RAM + Swap being used). It does this consistently when it tries to compile xf86PciScan.c (hope thats the right file). May not be the answer you want to hear, but I built all the xorg stuff multiple times on -current systems both pre and post the gcc + symver + version bump eras, and didn't have the problems you're seeing. It's the well-known problem of new gcc 4.2 optimizations (bug). Simply compile with -O0 instead of -O2. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Alex Dupre wrote: Doug Barton wrote: (Over 2GBs of RAM + Swap being used). It does this consistently when it tries to compile xf86PciScan.c (hope thats the right file). May not be the answer you want to hear, but I built all the xorg stuff multiple times on -current systems both pre and post the gcc + symver + version bump eras, and didn't have the problems you're seeing. It's the well-known problem of new gcc 4.2 optimizations (bug). Simply compile with -O0 instead of -O2. Not disputing your answer, but I'm curious. Why would it cause problems on some systems but not others? I haven't done anything with my cflags ... Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Doug Barton [EMAIL PROTECTED] writes: Hello, Not disputing your answer, but I'm curious. Why would it cause problems on some systems but not others? I haven't done anything with my cflags ... Can't give any response, but I was hit by the bug Alex talks about during upgrade. My box ran out of swap while compiling xf86scanpci.c with -O2 (inspiron 4150, 512MB ram, 512MB swap, 07-05-27 -current) Éric Masson -- Même à 15 minutes par livre à 250°, un con reste un con, et celui là restera pour encore un bon moment un con majuscule. On devrait le mettre à Sèvre, sous cloche, le con étalon. (c)(r)(tm) -+- RM in http://neuneu.ctw.cc - Comment servir le neuneu -+- ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Doug Barton ha scritto: Not disputing your answer, but I'm curious. Why would it cause problems on some systems but not others? I haven't done anything with my cflags ... It depends on how much RAM + Swap do you have. I know people with 1.5Gb that have such problem and others with 2.5Gb that haven't it (if I remember correctly the amounts). The bug is the un-optimized optimization :-) There is already a patch that will be included in 4.2.1 release, but I hope will be backported before in FreeBSD gcc. -- Alex Dupre ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
On 2007-May-27 16:12:54 -0700, Bakul Shah [EMAIL PROTECTED] wrote: Given the size and complexity of the port system I have long felt that rather than do everything via more and more complex Mk/*.mk what is is needed is a ports server and a thin CLI frontend to it. I don't believe this is practical. Both package names and port dependencies depend on the options that are selected as well as what other ports are already installed. A centralised ports server is not going to have access to this information. -- Peter Jeremy pgpfPtzrTbSlc.pgp Description: PGP signature
Re: Looking for speed increases in make index
On 2007-May-28 00:15:28 +0200, Michel Talon [EMAIL PROTECTED] wrote: Of course a lot of people have thinked about it, and quickly realized that it was not going to work. In the bsd.ports.mk, evaluation of one variable may be dependent on some conditional, which may itself be dependant on some other variable, appearing as some target. This constantly happens in bsd.ports.mk. ... To gain some performance, a first idea would be to simplify bsd.ports.mk. I am convinced that a substantial part of the 4000 lines are historical crap which serve no useful purpose. There are tons of variables who have probably purely anecdotical interest. There are targets which could be happily suppressed. These two paragraphs are contradictory. If bsd.ports.mk really is 4000 lines of historical crap and full full of unused variables than an evaluate on demand approach would be a big win. A second idea would be to multithread make, since modern machines will have a lot of cores. Not yet. Dual-core machines are still relatively new. Of the seven hosts that I regularly use, only one is dual core. Threading adds significant overheads and it's not clear how it would help in this specific instance. Anyways, one of the things which cannot be a big factor is reading bsd.ports.mk from hard disk. Reading 210KB from a modern disk is quite fast. It is certainly cached in memory when you run make index. Which is the specific case being discussed in this thread. On the other hand it is so big that it probably doesn't fit in cache, or probably only fits in caches of machines generously endowed. It may not stay in L1 cache but unless your system is extremely memory stressed, it should stay in RAM. I'd suggest that if bsd.ports.mk is not cached then you have more serious problems to address before you worry about the performance of make(1). (i am thinking Pentium 4 versus Core 2 Duo) is striking. It is less than 10 minutes on the big cache machine versus 30 minutes on the small cache one. If the cache effect is indeed dominant, then reducing the size of bsd.ports.mk by all possible means would be very beneficial. This is likely to be more a combination of the crippled pentium 4 core and a largish memory footprint for make than anything to do with bsd.ports.mk itself. By the way an alternative system would be to use something other than make to do the job. This is a possibility but it needs to be something that can be part of the base system. This means you are limited to C/C++, awk, sh and make. In particular, python, ruby, perl and similar scripting languages are out. Whilst make seems the obvious choice for the ports infrastructure, in reality, the infrastructure does not really need or use the sort of implicit dependency tracking and target transformations that make excels at. Of course, any alternative to make needs to provide a language for defining dependencies that is equally powerful and easy to use. -- Peter Jeremy pgpPFzz4p1Mss.pgp Description: PGP signature
Re: Looking for speed increases in make index and pkg_version for ports
On 2007-May-27 15:52:16 -0500, Stephen Montgomery-Smith [EMAIL PROTECTED] wrote: I have been thinking a lot about looking for speed increases for make index and pkg_version and things like that. So for example, in pkg_version, it calls make -V PKGNAME for every installed package. Now make -V PKGNAME should be a speedy operation, but the make has to load in and analyze bsd.port.mk, a quite complicated file with about 200,000 characters in it, when all it is needing to do is to figure out the value of the variable PKGNAME. This would be trivial if some packages didn't change names depending on options and what was installed. I agree that parsing a 210KB file 17,000 times is not going to be fast. Especially since some ports include bsd.ports.mk multiple times... I suggest rewriting make so that variables are only evaluated on a need to know basis. This sounds like a good idea but I suspect it's not going to be feasible. The biggest problem I see is that the make language allows variables to be expanded either when they are assigned or when they are referenced. If a variable expansion is delayed from the assignment to the first use then the expansion must be performed using the state of make as it was when the variable was assigned. The cost of keeping this state probably exceeds the cost of actually evaluating the variable. So, for example, if all we need to know is PKGNAME, there is no need to evaluate, for example, _RUN_LIB_DEPENDS, unless the writer of that particular port has done something like having PORTNAME depend on the value of _RUN_LIB_DEPENDS. Rather than trying to develop a tool that can quickly expand PKGNAME irrespective of what convoluted code the author has used, how about a partial solution? For most ports, PKGNAME depends solely on 3 or 4 variables that are statically defined in the port Makefile. The obvious solution would seem to be to develop a script that can handle the easy cases itself and punt the difficult cases back to make. The definition of 'easy' can be adjusted over time to increase performance. This approach would seem to have a relatively low bar to entry whilst offering good effort/performance tradeoff at the low end. The various depends lists would seem amenable to the same approach - though the entry level tool will have far lower coverage due to the extensive use of USE_GNOME=... and similar 'macro'-style constructs. -- Peter Jeremy pgpCyJ5Uh8Myq.pgp Description: PGP signature
Re: Looking for speed increases in make index and pkg_version for ports
On 2007-May-27 15:30:48 -0700, Jeremy Chadwick [EMAIL PROTECTED] wrote: This sounds like a good solution. In fact, I'm lead to believe that heavy reliance on /bin/sh is part of why the ports collection is slow. Someone needs to enable accounting on a recent -current (with the high-resolution accounting records) and look at where the time is actually going. (My -current box needs upgrading before I could do this). That said, /bin/sh is dynamically linked and a fork/exec is not cheap. Some quick-and-not-necessarily-reliable tests on 6.2-STABLE/amd64 show that /bin/sh takes about 2.5 times as long to start as /rescue/sh (though it's only 2:1 on i386). (These are different boxes so the absolute times aren't comparable). amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.20s user 0.08s system 98% cpu 0.283 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.22s user 0.06s system 97% cpu 0.287 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.19s user 0.10s system 98% cpu 0.288 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /rescue/sh -c echo foo; done' /dev/null sh -c /dev/null 0.84s user 6.12s system 97% cpu 7.162 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /rescue/sh -c echo foo; done' /dev/null sh -c /dev/null 1.12s user 6.05s system 97% cpu 7.366 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /bin/sh -c echo foo; done' /dev/null sh -c /dev/null 5.72s user 13.40s system 96% cpu 19.734 total amd64% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /bin/sh -c echo foo; done' /dev/null sh -c /dev/null 5.97s user 12.89s system 97% cpu 19.407 total amd64% i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.17s user 0.03s system 95% cpu 0.208 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.17s user 0.03s system 99% cpu 0.199 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done' /dev/null sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); echo foo; done'0.16s user 0.04s system 99% cpu 0.200 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /rescue/sh -c echo foo; done' /dev/null sh -c /dev/null 3.68s user 18.19s system 98% cpu 22.212 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /rescue/sh -c echo foo; done' /dev/null sh -c /dev/null 3.34s user 18.54s system 98% cpu 22.110 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /bin/sh -c echo foo; done' /dev/null sh -c /dev/null 12.03s user 29.42s system 98% cpu 41.965 total i386% time sh -c 'i=0; while [ $i -lt 1 ]; do i=$(($i+1)); /bin/sh -c echo foo; done' /dev/null sh -c /dev/null 12.20s user 29.25s system 98% cpu 41.975 total -- Peter Jeremy pgpUpeOoZw3YV.pgp Description: PGP signature
Re: Looking for speed increases in make index and pkg_version for ports
Ivan Voras [EMAIL PROTECTED] wrote: Because the information is not a constant. For example, the mpg123 port changes its PKGNAME as soon as esound is installed. Maybe the time has come to give up on some of the flexibility the ports tree has (and this particular one is confusing to the users) [...] maybe more confusing to portupgrade -- one day I'll get tired of running 'pkgdb -F' almose every time before portupgrade to fix old dependencies (packages with old config or things like ru-xmms instead of xmms). This is portupgrade's problem really, but doing away from such flexibility would make life slightly easier... [SorAlx] ridin' VN1500-B2 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Using get_system_info() - Obtaining the CPU states...
Hi there, I have an application running on FreeBSD which needs to display the CPU states as like the top command shows in the 3rd line as below: - CPU states: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle - I learnt that the top command uses the get_system_info() function for printing the CPU state detail. But I could not locate the source code of this function. Could anybody help me in locating the header/source file in which the get_system_info() function is located?. Any other ideas are also welcome. Note: I do not want to display the CPU load average... -- Thanks, Suresh Kumar J ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
* Hartmut Brandt [EMAIL PROTECTED] [20070529 08:21]: I've seen no numbers WHAT actually makes the ports stuff so slow. To make my point a last time: until there are numbers, there is no guess around what to do. It just occured to me that DTrace could be a big help with this task. I suggest someone convinces jb@ to take a look. qvb -- pica ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Using get_system_info() - Obtaining the CPU states...
On Tue, May 29, 2007 at 04:24:27PM +0530, Suresh Kumar J wrote: I learnt that the top command uses the get_system_info() function for printing the CPU state detail. But I could not locate the source code of this function. Could anybody help me in locating the header/source file in which the get_system_info() function is located? /usr/src/usr.bin/top/machine.c (which can be found on the web at http://cvsweb.freebsd.org/src/usr.bin/top/machine.c) -- Shenanigans! Shenanigans!Best of 3! -- Flash ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Looking for speed increases in make index and pkg_version for ports
On Tue, May 29, 2007 at 08:34:29PM +1000, Peter Jeremy wrote: On 2007-May-27 15:30:48 -0700, Jeremy Chadwick [EMAIL PROTECTED] wrote: This sounds like a good solution. In fact, I'm lead to believe that heavy reliance on /bin/sh is part of why the ports collection is slow. Someone needs to enable accounting on a recent -current (with the high-resolution accounting records) and look at where the time is actually going. (My -current box needs upgrading before I could do this). The best I was able to do: I have a 6.2-RELEASE box which contains profiled libraries, and managed to make a profiled /bin/sh. This didn't take much work (just some modification of src/bin/sh/Makefile), but one thing which did stump me was the .gmon file never getting written. Turns out trap.c calls _exit(2) not exit(3). Change that and voila. Admittedly I'm not that familiar with gprof, and I'm also left wondering if profiling /bin/sh is going to help us, since we don't have a direct way of determining which shell commands take the most time -- just which C functions are most heavily used. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Kernel panicking in 6.2 and 7-CURRENT -- interrupt issues
Hello, I'm trying to install 7-CURRENT on my desktop, locally instead of on a virtual machine, and I'm running into an issue where the kernel almost always panics on boot with my motherboard (ASUS P5N-SLI E), due to some sort of interrupt assignment / probing issues. Observations: 1. 7-CURRENT (built) never properly detects the interrupts on the system. 2. 7-CURRENT (May ISO snapshot) doesn't properly detect my USB keyboard, but boots and runs sysinstall. 3. 6.2 RELEASE panics if I don't boot FreeBSD up into safe mode, due to an issue with the ohci driver (I think the error message had something to deal with device adding / enumeration and not being able to find a memory / interrupt address). First off, if I could get some of the command line arguments to pass to the kernel to emulate safe-mode, that would be much appreciated. Second off, if anybody has any ideas on how to debug this issue, I'll go off and try to determine what the cause is. If it's anything like it was before (clean out /usr/obj, rebuild), I'll be ok. Otherwise, I'll have to purchase more parts and build another dedicated FreeBSD system :(.. Thanks, -Garrett ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
direct I/O access
hi all, Sorry for cross posting, but perhaps hackers is a better list than multimedia for this topic. i am trying to port my old assembler soft for Dos to FreeBSD. i need to write and read directly to the midi and scsi device. when i try something like this i receive a sigbus error SORRY, i am NOT nor a C nor a FreeBSD expert!!! all i know is Assembly language! i made some search in the devel handbook and did not found the solution. What is wrong here? Can you enlight me please? Many thanks in advance and bests regards Raoul [EMAIL PROTECTED] ---cut--- .data .align 4 params: .word 0x330,2,1 # midi port = enabling IO ??? .text .align 4 .global _start _start: nop pushl params pushl $0x3 movl$0Xa5,%eax int $0x80 addl$0x08,%esp movw$0x331,%dx # status register inb %dx,%al # ... pushl $0 # exit movl$0x1,%eax int $0x80 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
On Tue, May 29, 2007 at 12:07:44AM -0700, Doug Barton wrote:
Alex Dupre wrote:
Doug Barton wrote:
(Over 2GBs of RAM + Swap being used). It does this consistently when it
tries to compile xf86PciScan.c (hope thats the right file).
May not be the answer you want to hear, but I built all the xorg stuff
multiple times on -current systems both pre and post the gcc + symver
+ version bump eras, and didn't have the problems you're seeing.
It's the well-known problem of new gcc 4.2 optimizations (bug). Simply
compile with -O0 instead of -O2.
Not disputing your answer, but I'm curious. Why would it cause
problems on some systems but not others? I haven't done anything with
my cflags ...
It wants to use ${BIGNUM} amount of memory to optimize a huge C file,
so that might be fatal (or just terminally irritating) on smaller
systems.
Kris
pgpYA6AWk5tYl.pgp
Description: PGP signature
Freebsd 6.2 panic
I have some machines running php/mysql/postfix from time to time the computers running FreeBSD 6,2 crashes with the following messages fatal trap 12:page fault while in kernel mode cpuid=0; apic id=00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer= 0x20:0xc066c731 stack pointer=0x28:0xe74fec90 frame pointer=0x28:0xe74fec9c code segment=base 0x0,limit 0xf,type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflag=resume,IOPL=0 current process=5 (thread taskq) trap number=12 panic page fault cpuid=0 uptime:16h7m48s cannot dump. no dump device defined Automatic rebbot in 15 second - press a key on the console to abort Rebooting cpu_reset:stopping other CPU does anyone has an idea on what I can do to solve this problem ? thanks for your help -- didier ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Setting up development environment
Hello, Is there any official way to setup a development environment for FreeBSD. I mean, I want to contribute with FreeBSD development. All I know that there is a Developer's Handbook, but what about setting a development environment for FreeBSD-CURRENT and -STABLE including from official c-mode-hooks and c++-mode-hooks for emacs to environment variables for cross-compiling the FreeBSD source. Can anyone guide me, or send me tips to get an optimal chance to contribute with FreeBSD?. Best regards, -- .O. | Daniel Molina Wegener | C/C++ Developer ..O | dmw [at] unete [dot] cl | FOSS Coding Adict OOO | BSD Linux User| Standards Rocks! ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Xorg port problem?
Alex Dupre wrote: Doug Barton ha scritto: Not disputing your answer, but I'm curious. Why would it cause problems on some systems but not others? I haven't done anything with my cflags ... It depends on how much RAM + Swap do you have. I know people with 1.5Gb that have such problem and others with 2.5Gb that haven't it (if I remember correctly the amounts). The bug is the un-optimized optimization :-) There is already a patch that will be included in 4.2.1 release, but I hope will be backported before in FreeBSD gcc. Ok, this makes sense. I was interested in the original post because I also have 2G of ram, and very little swap configured, so it looked to me like the only variable was that he had ZFS and I didn't. Doug -- This .signature sanitized for your protection ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Freebsd 6.2 panic
On Tue, May 29, 2007 at 10:56:40PM +0200, didier derny wrote: I have some machines running php/mysql/postfix from time to time the computers running FreeBSD 6,2 crashes with the following messages fatal trap 12:page fault while in kernel mode cpuid=0; apic id=00 fault virtual address = 0x104 fault code = supervisor read, page not present instruction pointer= 0x20:0xc066c731 stack pointer=0x28:0xe74fec90 frame pointer=0x28:0xe74fec9c code segment=base 0x0,limit 0xf,type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflag=resume,IOPL=0 Is it always the exact same panic or is it random? A box here had a few random trap 12 page fault panics recently, especially while booting up cold but also at run time, and the problem turned out to be bad capacitors on the motherboard. If you have physical access look at the capacitors on the board to see if they are bulged of even leak. cannot dump. no dump device defined You might want to configure dumping, see dumpon(8). Look at the traces you get from the dumps: kgdb /boot/kernel/kernel dumpfile bt It helps to run a kernel compiled with DEBUG=-g. I think this is default in GENERIC on 6.2. If the crashes are at seemingly random points in the kernel code you probably have a hardware problem. If it's always the same trace then post it. -- stefan http://stsp.name PGP Key: 0xF59D25F0 pgpIIlOG5NjCt.pgp Description: PGP signature
Re: direct I/O access
Raoul, good day. Tue, May 29, 2007 at 08:10:26PM +0200, [EMAIL PROTECTED] wrote: i am trying to port my old assembler soft for Dos to FreeBSD. i need to write and read directly to the midi and scsi device. when i try something like this i receive a sigbus error Seems like that the following fragment params: .word 0x330,2,1 # midi port = enabling IO ??? [...] pushl params pushl $0x3 movl$0Xa5,%eax int $0x80 addl$0x08,%esp translates to the call i386_get_ioperm(0x330, 2, 1). But you should use the i386_set_ioperm(0x330, 2, 1), aren't you? You're trying to grant the IO permissions for your process? Then use i386_set_ioperm that will be equivalent to the first parameter to the 'int 0x80' to 0x04 instead 0x03. With 0x03 you're just trying to make the system to write the _current_ IO permissions starting with port 0x330 to the _addresses_ 0x02 and 0x01. And this is obviously wrong, but it should provoke the segfault error instead of sigbus. I am not sure about the 'pushl params' statement: will it push all three arguments to the stack? My GNU assembler knowledge is rather rusty and incomplete, sorry. But maybe it is the reason why you're getting the sigbus instead of 'correct' sigsegv. -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: direct I/O access
Me again. Wed, May 30, 2007 at 08:46:14AM +0400, Eygene Ryabinkin wrote: Then use i386_set_ioperm that will be equivalent to the first parameter to the 'int 0x80' to 0x04 instead 0x03. Hmm, that should read set the first parameter for the 'int 0x80' to 0x04 instead of 0x03 -- it is much more understandable ;)) -- Eygene ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
