Re: Memory Mangement Problem in 5.1-RELEASE
Shawn wrote: On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: You probably can't get away with the old gcc, since the binary format changed For No Good Reason(tm). Didn't the GNU people say they had to change it to be more ABI compliant with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. It's like the ELF standard instead of a.out; I was very much in favor of the change-over because it was supposed to let us have section attribution and multiple text and data segements that got loaded in the same executable. Is your FreeBSD kernel capable of defragging kernel memory to permit large contiguaous allocations for a device driver like the BT848 to happen well after boot time? Mine isn't. Is your FreeBSD kernel capable of dicarding the code and data for the probe routines that are not currently being executed and are not used in the common operational case? Mine isn't. Is your FreeBSD kernel capable of paging out any kernel page that's not in the paging path, so that if you, for example, have sound hardware and aren't using your sound driver, you have the ability to use the physical memory to instead open more sockets? Mine isn't. Is your FreeBSD kernel capable of loading *only* the probe code for a device, and, if it doesn't probe as being there, never loading the rest of the device driver and cotributing to KVA fragmentation? Mine isn't. Does your system have a libc.so linked against a libresolv.so that's totally seperate so that you can pull in new libraries from ISC whenever you need to do that the name lookups aren't serialized and make your Netscape slow? Mine doesn't. Is your entire system linked shared? Well, mine is. 8-). But it was under a.out, too. ELF promised a lot of things that never ended up having any practical value beyond what we already had with a.out, which was one BSS, one TEXT, and one DATA: just like before ELF. So what exactly is being promised by being more standards compliant in this particular instance? I can tell you what isn't: binaries are larger and compilation is slower than in previous releases; keeping up with GCC feels like running further and deeper into a swamp filled with molasses. Yeah, it's nice that we support 64 bit architectures (sorta) now, but that particular feature didn't need the binary format changed. Does anyone else ever suspect that some standards are written to cripple your competition, if they are stupid enough to fully comply with them? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Shawn wrote: On Fri, 2003-07-25 at 01:42, Terry Lambert wrote: I do know that even if they remove the bridge, they are unlikely to provide enough documentation to boot and run natively on the hardware without having IBM code setting up the bus arbitration and other bits that are currently undocumented. Why would IBM try to hide this? Wouldn't they *want* people to take full advantage of the processor for the best performance to help give their product a good image? Adaptec didn't document their hardware to prevent people from cloning its interface in order to leverage the driver developement effort and advocacy it took to get their drivers into Windows. Diamond Multimedia didn't document their video cards because they had a hardware guy instead of a Real Software Engineer design their BIOS interface, and there was no non-Diamond-BIOS-accessible table of the PAL imputs vs. the video mode self-docmented in their BIOS, and they wanted to be able to change PAL and BIOS in tandem to add updated features to their cards, without changing their overall card design. There are a lot of comapnies who don't document their hardware for reasons of liability, when their documentation is incorrect and thus causes their hardware to fail, sometimes by cooking. Intel doesn't docuyment their full errata on their processors because then people wouldn't buy stock-on-hand, if they knew a stepping without a particular errata existed that didn't have the problem in question. How much of an excuse do they need? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: It is simply swapping when it shouldn't. Opening Mozilla, Opera, Netscape, DrJava, jEdit, Emacs, PrBoom, XBubbles, and Nautilus at the same time on a 233Mhz machine should fill up the memory (160Mb) but instead it has decided to use the swap disk for a measly 50Mb which I do have in RAM!! Please google for the phrase write through cache. GG. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-26 05:34:55 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-26 05:34:55 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 05:36:55 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 06:36:49 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 06:36:49 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_ch.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_da.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_pass.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_sa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: fuword(), suword(), etc.
geeze terry would you mind unhijacking this topic? The topic is Should we have an suptr() and fuptr() to match suword() and fuword()? On Fri, 25 Jul 2003, Terry Lambert wrote: [tonnes of absolutly irrelevant stuff] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
Ahmed Al-Hindawi wrote: dude, I have a third of my memory free!! Dude, there's a difference between free and available. Dude, what makes you think that the swap in use doesn't refer to pages that are also in main memory, but marked clean because they've already been written to a backing store, but can be instantly reactivated in main memory without reading from swap? Dude, why do you thing FreeBSD is ever reading from swap at all when you are in this situation, and is not just writing it, in case you have a demand spike for memory so it can satisfy it immediately, instead of having to futz around with delaying your request until it can write the dirty things in main memory to swap? Dude, have you ever been through a drive through or even in line inside at a fast food place like Wendy's, where they send order takers into the line to proactively take your orders, so that all you have to do when you get to the front of the line is hand them your order ticket, instead of stating your order and delaying the whole line behind you by however long they were already delayed plus the time it takes you to give them your order? Dude, have you ever heard of queueing theory or have you ever google'd for pool retention time and latency in the same query? Dude, stop saying dude. 8-) 8-). There are good reasons that FreeBSD acts the way it does, and why it is more responsive under a high load than certain other OS's written by people who are at best undergraduates and at worst High school students, and never cracked open a copy of Knuth's Algorithms in their lives, let alone owned one and put it up on their bookshelf. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
make libstdc++ error
after cvsup'd from 5.0R to 5.1R and get error at installworld thx any info. c++ -O -pipe -mcpu=pentiumpro -DIN_GLIBCPP_V3 -DHAVE_CONFIG_H -I/usr/src/gnu/lib/libstdc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/libstdc++/libsupc++ -I/usr/src/gnu/lib/libstdc++/../../../contrib/gcc -fno-implicit-templates -ffunction-sections -fdata-sections -Wno-deprecated -c /usr/src/contrib/libstdc++/src/locale.cc -o locale.o /usr/src/contrib/libstdc++/src/locale.cc:454: `char std::locale::facet::_S_c_name[2]' is not a static member of `class std::locale::facet' *** Error code 1 Stop in /usr/src/gnu/lib/libstdc++. *** Error code 1 Stop in /usr/src/gnu/lib. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: fuword(), suword(), etc.
Julian Elischer wrote: geeze terry would you mind unhijacking this topic? The topic is Should we have an suptr() and fuptr() to match suword() and fuword()? I'm not the one who posted the question without changing the subject line; please read the thread history. In answer to your question, my answer is still: How do you intend to deal with 32 and 64 bit address spaces on the same machine, if all you have is one function for the copyin and one for the copyout?. Or is there no intent to allow IA32 binaries to run on IA64, never ever ever? -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: We have ath, now what about Broadcom?
On Fri, 25 Jul 2003, M. Warner Losh wrote: : Can they now take they took relevant steps as a defence in a law court? That's a very interesting question. Which might get answered since some industrious folks aligned with a certain other open source operating system are in the process of reverse engineering said devices. -- Doug White| FreeBSD: The Power to Serve [EMAIL PROTECTED] | www.FreeBSD.org ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
If your system is spending a lot of time moving data to and from swap when it is not memory-starved, or if it is stalling memory allocations that it should be able to fulfill from free RAM, that's a concern. That is exactly it. I emphaises th words when it is not memory-starved . It isn't memory starved. Also I get 150Mb frequently of swap disk space, whilst still having a complete third of my memory free!! I can understand everyones view on this, that the swap algorithim is swaping pre-emtively. But 150MB?? Is that what is called a low level of swaping?? _ MSN 8 helps eliminate e-mail viruses. Get 2 months FREE*. http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Mapping Video BIOS?
I've spent the last couple of days tracking down a problem starting X on a Dell Inspiron 5100. I've got as far as discovering that the video BIOS is not being completely mapped: it's 60 kB long, but only 48 kB are being mapped into memory. To make matters worse, the machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Memory Mangement Problem in 5.1-RELEASE
In message [EMAIL PROTECTED], Ahmed Al-Hindawi writes : If your system is spending a lot of time moving data to and from swap when it is not memory-starved, or if it is stalling memory allocations that it should be able to fulfill from free RAM, that's a concern. That is exactly it. I emphaises th words when it is not memory-starved . It isn't memory starved. Also I get 150Mb frequently of swap disk space, whilst still having a complete third of my memory free!! I can understand everyones view on this, that the swap algorithim is swaping pre-emtively. But 150MB?? Is that what is called a low level of swaping?? Programs like cp(1) uses mmap(2) to copy things, so if you cp(1) a big file, it is not uncommon for some programs to end up on swap. Until they are used again, they will not get paged in. I often see the getty's for the vty's and similar junk on my swap space. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- 2003-07-26 06:37:48 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-26 06:37:48 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 06:39:54 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 07:43:54 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 07:43:54 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 07:58:20 GMT 2003 TB --- 2003-07-26 07:58:20 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 07:58:20 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 07:58:20 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/uipc_jumbo.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/uipc_mbuf.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/uipc_mbuf2.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include
Re: fuword(), suword(), etc.
On Sat, Jul 26, 2003 at 12:08:29AM -0700, Terry Lambert wrote: In answer to your question, my answer is still: How do you intend to deal with 32 and 64 bit address spaces on the same machine, if all you have is one function for the copyin and one for the copyout?. Or is there no intent to allow IA32 binaries to run on IA64, never ever ever? What does that have to do with anything? Adding fuptr()/suptr() has no consequences for supporting or not supporting different memory models with different pointer sizes. The functions are defined to operate on native (kernel PoV) pointers. Any non- native (kernel PoV) ABI has a non-native ABI handler that does all the mapping, converting and copying bits from userland to kernel and vice versa. And I can't believe I actually wasted my time telling you this when you only have to use your head instead of your keyboard. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Sat, Jul 26, 2003 at 05:32:17PM +0930, Greg 'groggy' Lehey wrote: Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? The video BIOS is usually mapped by system BIOS into real memory to begin with, so it should be just sitting there. There are usually northbridge chipset registers for dealing with this sort of thing. The SMM mode might reuse that window, though, but generally this is hidden from non-SMM mode applications. You're in luck - been rebuilding X, so have xc tarballs handy. The XFree86 code responsible is: xc/programs/Xserver/hw/xfree86/int10 Some drivers like to call VBE via int10h, so this module acts as a bridge. It just memcpy()'s the ROM and uses various methods, depending on the compilation target, to call int10h. Is the onboard video AGP/PCI? It is possible that the device isn't reporting its memory window in the ROM BAR correctly. I've seen this happen with some low-end network cards before. Try my tools at this URL to check this: http://www.incunabulum.com/code/projects/pci/freebsd/ BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 9:41:14 +0100, Bruce M Simpson wrote: On Sat, Jul 26, 2003 at 05:32:17PM +0930, Greg 'groggy' Lehey wrote: Can anybody point me in the right direction? Where should I be looking for this? Is this memory mapped permanently, or is it only during X startup? The video BIOS is usually mapped by system BIOS into real memory to begin with, so it should be just sitting there. There are usually northbridge chipset registers for dealing with this sort of thing. The SMM mode might reuse that window, though, but generally this is hidden from non-SMM mode applications. You're in luck - been rebuilding X, so have xc tarballs handy. The XFree86 code responsible is: xc/programs/Xserver/hw/xfree86/int10 Yup, I've been playing around with it. I currently have my arms in xf86ExtendedInitInt10, which does the mapping. It tries to map 256 kB of memory, and I suppose it does, for some definition: (II) RADEON(0): mapped system memory at 0xc, len 0x4, video BIOS offset 0xc, to 0x28368000 But at 0xcc00, I get: (gdb) x/20x 0x28373ff0 0x28373ff0: 0x00800304 0x000c 0x0b100020 0x4002003e 0x28374000: 0x 0x 0x 0x 0x28374010: 0x 0x 0x 0x I've looked in the same space with Microsoft, which says: C000:BFF0 04 03 80 00 0C 00 00 00-20 00 10 0B 3E 00 02 40 .@ C000:C000 00 2E 05 01 06 10 40 01-90 01 02 97 01 45 01 0D [EMAIL PROTECTED] Some drivers like to call VBE via int10h, so this module acts as a bridge. It just memcpy()'s the ROM and uses various methods, depending on the compilation target, to call int10h. Is the onboard video AGP/PCI? Intel 82845, if that's the correct answer. I've put the dmesg up at http://www.lemis.com/grog/Inspiron/dmesg.boot. It is possible that the device isn't reporting its memory window in the ROM BAR correctly. I've seen this happen with some low-end network cards before. I could believe that, but I think we have a different problem here: since it's mapping up to the end of low memory. My guess is that something else shares this space, and that it has been turned off. I'm going to carry on investigating, but if anybody else recognizes the problem, I'd be interested to hear from you. Try my tools at this URL to check this: http://www.incunabulum.com/code/projects/pci/freebsd/ Thanks, I'll try that anyway. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
[current tinderbox] failure on i386/pc98
TB --- 2003-07-26 08:07:23 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-26 08:07:23 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 08:12:23 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 09:16:13 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 09:16:13 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 09:28:08 GMT 2003 TB --- 2003-07-26 09:28:08 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 09:28:08 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 09:28:08 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/uipc_jumbo.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/uipc_mbuf.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/uipc_mbuf2.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include
[current tinderbox] failure on ia64/ia64
TB --- 2003-07-26 09:35:30 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-07-26 09:35:30 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 09:38:05 - building world TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/ia64/ia64/obj/ia64/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 10:44:28 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/ia64/ia64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 10:44:28 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/ia64/elf_machdep.c cc -c -x assembler-with-cpp -Wa,-x -DLOCORE -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/ia64/exception.S cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/ia64/in_cksum.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/dev/ath/freebsd -I/vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/contrib/ia64/libuwx/src -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/ia64/ia64/interrupt.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual
gcc ABI compliance (was: Re: Memory Mangement Problem in5.1-RELEASE)
On Fri, 25 Jul 2003 23:22:00 -0700 Terry Lambert [EMAIL PROTECTED] wrote: Didn't the GNU people say they had to change it to be more ABI compliant with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. Some standards are not worth complying with; I still have yet to see anyone tell me exactly what the practical benefit of doing this is. When X (X 1) compilers comply to the same ABI standard, I can mix the results of those compilers (if I see a benefit to do so). As we have icc in the ports collection and the base system is compiled with gcc and I want to be able to link to gcc compiled libs with icc, I appreciate the effort of the involved parties to try to comply to a common ABI standard. Bye, Alexander. -- I believe the technical term is Oops! http://www.Leidinger.net Alexander @ Leidinger.net GPG fingerprint = C518 BC70 E67F 143F BE91 3365 79E2 9C60 B006 3FE7 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc related -current upgrade problems
Le Saturday 26 July 2003 00:46, John a écrit : . /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:62:25: attempt to use poisoned malloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:63:25: attempt to use poisoned calloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:64:25: attempt to use poisoned realloc /usr/src/gnu/usr.bin/cc/cc_tools/freebsd-native.h:65:25: attempt to use poisoned strdup mkdep: compile failed Hello, I've seen yesterday the exact same error : (maybe some bad wave coming to us from the outer space ?) one one machine (A). What was surprising in my case was that this error was systematic : I've tried three compilations in a succession to be sure it was not an error due to bad hardware. Then I've transferred the hard disk to another machine (B), and relaunched the make buildworld to check that the compiler and the sources on the disk were good (and indeed the make buildworld an make buildkernel succeeded on machine B) then I've re-transferred back the disk to the first machine, and I could then make buildworld - big surprise ? the first machine uses a Pentium-4 mobile (a real P-IV, not a Banias) and the second machine uses a Pentium-III TfH ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LiveCD FBSD Current
On Fri, Jul 25, 2003 at 09:57:04PM -0700, Kris Kennaway wrote: On Sat, Jul 26, 2003 at 06:31:03AM +0200, Sebastian Yepes [ESN] wrote: Hi all I have made a liveCD of FreeBSD Current and it boot's and looks like it run ok.. The only problem i am haveing is with the md system.. it dus not let me do the newfs on the md dev, i have runing devfs and mounted the procfs.. mdcondig -a -t malloc -s 2m -u 0 - work's ok newfs /dev/md0 -- 'pid xxx (newfs), uid 0: exited on signal 4 IIIegal instruction -- And with mdmfs -M -s 2m md1 -tmp i get the same error Can any one plz informe me on how to fix this or what am i duing bad... This typically means you compiled the binary with CPU optimizations that are incorrect for the target system. Kris Thanx for the tip.. I was compiling the kernel for other box.. It work 100% now thanX -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LiveCD FBSD Current
On Sat, Jul 26, 2003 at 09:32:40PM +1000, Mark Sergeant wrote: On Sat, 2003-07-26 at 21:09, Sebastian Yepes [ESN] wrote: On Fri, Jul 25, 2003 at 09:57:04PM -0700, Kris Kennaway wrote: On Sat, Jul 26, 2003 at 06:31:03AM +0200, Sebastian Yepes [ESN] wrote: Hi all I have made a liveCD of FreeBSD Current and it boot's and looks like it run ok.. The only problem i am haveing is with the md system.. it dus not let me do the newfs on the md dev, i have runing devfs and mounted the procfs.. mdcondig -a -t malloc -s 2m -u 0 - work's ok newfs /dev/md0 -- 'pid xxx (newfs), uid 0: exited on signal 4 IIIegal instruction -- And with mdmfs -M -s 2m md1 -tmp i get the same error Can any one plz informe me on how to fix this or what am i duing bad... This typically means you compiled the binary with CPU optimizations that are incorrect for the target system. Kris Thanx for the tip.. I was compiling the kernel for other box.. It work 100% now thanx Any chance of a website with a howto for others looking at doing the same thing ? Cheers, -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services Yes ones i have every the init rc's working, and the mdfs i well post a mini HowTo.. becouse there is really not much to do, this have been working almost out of the box.. -- /* FingerPrint: 5BF1 58B1 DE75 CBE3 6044 7098 1246 1EF6 9E78 041C @@@ @@ @@@ @@! @@@ !@@ @@! @@@ @[EMAIL PROTECTED]@!@ !@@!! @!@ [EMAIL PROTECTED] !!: !!! !:! !!: !!! :: : :: ::.: : :: : : The Power To Kill LinuX */ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-07-26 10:52:27 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-26 10:52:27 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 10:54:34 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 11:51:44 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 11:51:44 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 12:00:53 GMT 2003 TB --- 2003-07-26 12:00:53 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 12:00:53 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 12:00:53 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netatalk/at_rmx.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netatalk/ddp_input.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/netatalk/ddp_output.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror
Re: Memory Mangement Problem in 5.1-RELEASE
thanks for all the help guys, I appreciate it. And sorry for using the word dude; I got a little agitated because people always expact them selves to be superior than youself because you are the one asking the question and they are answering!! Thanks anyway _ MSN 8 with e-mail virus protection service: 2 months FREE* http://join.msn.com/?page=features/virus ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Disabling ISAPNP in -CURRENT
Hi, Is there any way to disable ISAPNP from probing in -CURRENT short of writing a patch to do so? It is causing some delay when booting Bochs. Thanks BMS ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: We have ath, now what about Broadcom?
On Sat, 26 Jul 2003, Doug White wrote: On Fri, 25 Jul 2003, M. Warner Losh wrote: : Can they now take they took relevant steps as a defence in a law court? That's a very interesting question. Which might get answered since some industrious folks aligned with a certain other open source operating system are in the process of reverse engineering said devices. Would not said software be illegal to distribute in the US? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
buildworld fails on FreeBSD5.0/i386
Hi, I'm trying to upgrade my FreeBSD5.0 server to FreeBSD current. My make buildworld fails with the current CVS checkout during stage 3: cross tools. I use a GENERIC kernel on i386 and I followed the procedure as described in the FreeBSD handbook. Can anybody give me a clue how to fix this? Is this related to the recent gcc-upgrade? If so, can anybody tell me what CVS checkout of FreeBSD I should use if I'm not (yet) interested in gcc3.3? PieterB 8 [...] cc -O -pipe -DIN_GCC -DHAVE_CONFIG_H -DPREFIX=\/usr/obj/ad3/freebsd5current/src/i386/usr\ -I/usr/obj/ad3/freebsd5current/src/i386/ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus/../cc_tools -I/ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc -I/ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/config -I/ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus/../../../../contrib/gcc/cp -I. -I/usr/obj/ad3/freebsd5current/src/i386/legacy/usr/include -c /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c In file included from /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:168: /ad3/freebsd5current/src/contrib/gcc/cp/tree.def:35: excess elements in char array initializer /ad3/freebsd5current/src/contrib/gcc/cp/tree.def:35: (near initialization for `tree_code_type') [...] /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:169: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:169: (near initialization for `tree_code_type') In file included from /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:170: /ad3/freebsd5current/src/contrib/gcc/c-common.def:29: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/c-common.def:29: (near initialization for `tree_code_type') [...] /ad3/freebsd5current/src/contrib/gcc/c-common.def:119: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/c-common.def:119: (near initialization for `tree_code_type') /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:171: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:171: (near initialization for `tree_code_type') In file included from /ad3/freebsd5current/src/contrib/gcc/cp/cp-lang.c:172: /ad3/freebsd5current/src/contrib/gcc/cp/cp-tree.def:45: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/cp/cp-tree.def:45: (near initialization for `tree_code_type') [...] /ad3/freebsd5current/src/contrib/gcc/cp/cp-tree.def:283: excess elements in struct initializer /ad3/freebsd5current/src/contrib/gcc/cp/cp-tree.def:283: (near initialization for `tree_code_type') *** Error code 1 Stop in /ad3/freebsd5current/src/gnu/usr.bin/cc/cc1plus. *** Error code 1 Stop in /ad3/freebsd5current/src/gnu/usr.bin/cc. *** Error code 1 Stop in /ad3/freebsd5current/src. *** Error code 1 Stop in /ad3/freebsd5current/src. *** Error code 1 Stop in /ad3/freebsd5current/src. -- http://zwiki.org/PieterB ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: We have ath, now what about Broadcom?
In message: [EMAIL PROTECTED] Wesley Morgan [EMAIL PROTECTED] writes: : On Sat, 26 Jul 2003, Doug White wrote: : : On Fri, 25 Jul 2003, M. Warner Losh wrote: : : : Can they now take they took relevant steps as a defence in a law court? : : That's a very interesting question. : : Which might get answered since some industrious folks aligned with a : certain other open source operating system are in the process of reverse : engineering said devices. : : Would not said software be illegal to distribute in the US? That's a very interesting question. The reason I keep saying that is that nobody knows for sure. Nobody has reverse engineered anything, got sued and won (or lost). Just like the GPL has never been tested in a court of law, reverse engineering a driver has never been tested. There have been a few test cases in other areas, and those may or may not apply to drivers. Anybody who gives you a definitive answer is full of s*** and is only speculating based on their legal theories. However, lots of people have reverse engineered devices in the past, and those driver are widely available and those people typically haven't been sued. Some have, however, and desided to settle rather than fight. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
On Fri, Jul 25, 2003 at 11:22:00PM -0700, Terry Lambert wrote: Shawn wrote: On Fri, 2003-07-25 at 02:21, Terry Lambert wrote: You probably can't get away with the old gcc, since the binary format changed For No Good Reason(tm). Didn't the GNU people say they had to change it to be more ABI compliant with the 'standard'? I will believe that when they upgrade their FORTRAN compiler to be more compliant with 'the standard'. The gcc-g95 developers have begun the merge of the Fortran 95 front end and runtime library into the tree-ssa branch of GCC. The target is to have a Fortran compiler that complies with ISO/IEC 1539-1:1997 include in gcc-3.5.0. BTW, the official name of the language is Fortran not FORTRAN. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: We have ath, now what about Broadcom?
In message: [EMAIL PROTECTED] M. Warner Losh [EMAIL PROTECTED] writes: : The reason I keep saying that is that nobody knows for sure. Nobody : has reverse engineered anything, got sued and won (or lost). Just However, there are one or two cases that are close to relevant working their ways through the courts. Since they are in different districts, the answer is different depending on where you live in the US. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-26 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-26 16:00:01 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 16:02:27 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 17:07:34 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 17:07:35 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 17:19:25 GMT 2003 TB --- 2003-07-26 17:19:25 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 17:19:25 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 17:19:25 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. Does it have a firewire port? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1-RELEASE can't find SIL 0680 IDE controller
hello my name is David a i read your message with interest because i have a mandrake linux distribution who don't want to be installed with my sil 0680 PCI card and i don't know if it exists a driver for this one can you say me how you can make boot your system under linux with your card, please thank you very much ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-26 17:22:27 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-26 17:22:27 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 17:24:28 - building world TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/amd64/amd64/obj/amd64/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 18:23:59 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/amd64/amd64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 18:23:59 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_ch.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_da.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_pass.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_sa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: Vim: Caught deadly signal BUS (after -current update with newgcc)
Now, it has been fixed today with the new 6.2.040 patch. Cheers, Mezz On Fri, 18 Jul 2003 13:24:30 -0500, Jeremy Messenger [EMAIL PROTECTED] wrote: On Fri, 18 Jul 2003 19:36:50 +0200, Matthias Schuendehuette [EMAIL PROTECTED] wrote: On Thursday 17 July 2003 08:14, David O'Brien wrote: I'm willing to commit it as such, but I'd like to hear more people's opinion. What I found so far: - gvim 6.2.21 works under 'twm' - gvim 6.2.21 works under 'kde 3.1' with SESSION_MANAGER unset - gvim 6.2.21 works under 'kde 3.1' if running on a remote machine tunneled through ssh's X11-redirection as reported by others: - gvim 6.2.21 works without patch 015 I looked at patch 015 but I'm not familiar with X11 SessionManagerProtocol - perhaps some others are able to analyze the correctness of that patch... I have sent to the vim-dev mailing list yesterday, because I got the same problem. I gave them with info of vim ran under gdb and explained about that 6.2.015 patch cause the crash. The author of VIM uses FreeBSD as well, so hope he will look into this problem. Cheers, Mezz -- bsdforums.org 's moderator, mezz. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/i386
TB --- 2003-07-26 18:24:57 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-26 18:24:57 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/i386 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 18:26:55 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 19:30:04 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 19:30:04 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 19:45:54 GMT 2003 TB --- 2003-07-26 19:45:54 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 19:45:54 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 19:45:54 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/pci/if_wb.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/pci/if_xl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/pci/intpm.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
device driver memory leak in 5.1-20030726?
Hi all, I'm seeing the same 'kmem_malloc(4096): kmem_map too small: X total allocated' messages that a few other have reported. Now, I understand that setting kern.vm.kmem.size larger is supposed to help, but I'm using a 128M Celeron-650 i386 system with no unusual devices (expect perhaps a Speedtouch ADSL modem) and I've progressively set the kern.vm.kmem.size to larger and larger values, starting at 64MB, then 96MB and finally 128MB. As I approached the physical memory size of the machine (128MB), the panic problem failed to reappear, but I got another problem whereby the kernel appeared to take over all of memory (i.e. processes were gradually all getting swapped out, but no other process seemed to be taking the memory) within about 30 minutes of boot-up. I noticed in the final minutes of the case where kmem.size=128MB (i.e. all of physical RAM), that kern.malloc was reporting 100M of 'devbuf' memory allocations and that it was gradually increasing at about 25k per second. I can't believe this is normal behaviour, but I'm no expert. I believe the devbuf allocations are specifically for device drivers. From these symptoms, I'm speculating that one or more device drivers are producing kernel memory leaks and either triggering the 'kmem_map too small' messages or pushing all of the userland processes out of the way. Is this a reasonable interpretation? Does anyone else see symptoms that might lead to this conclusion? As a side note, I also briefly witnessed scrolling errors like 'ad0: out of memory in start'. I have no idea if this implies the 'ad' driver is an issue. Regards, Mark Blackman Exonetric Consulting ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
5.1 and Pervasive SQL in Linux Emu (7) - tty stopped output
the following script starts psql without problems on 4.8 with linux base
6. with 5.1 and linux base 7 it looks like su hangs. scripts doenst
complete and ends with tty output stopped.
there is also something very strange: when starting pervasive in
forground mode i get a listener and it works. when starting into
background (manually without the following script) i dont get a listener
opened. persavice thinks it is open, at least there is no entry in any
log but netstat -rn doesnt show a listener.
#!/compat/linux/bin/sh
#
# description: Starts and stops the Pervasive mkded and sqlmgr daemons
# chkconfig: 2345 92 92
start_psql(){
echo Starting Pervasive services:
SQLID=`/bin/ps ax | grep -v grep | grep sqlmgr | awk '{print $1}'`
BTRID=`/bin/ps ax | grep -v grep | grep mkded | awk '{print $1}'`
if [ X$BTRID != X -o X$SQLID != X ] ; then
echo Warning: the following service is running
if [ X$BTRID != X ] ; then
echo mkded
fi
if [ X$SQLID != X ] ; then
echo sqlmgr
fi
echo
fi
echo mkded
echo cd $PVSW_ROOT/bin; . $PVSW_ROOT/bin/.bash_profile ; ./mkded
-start | /usr/bin/su - psql || exit 1
echo sqlmgr
echo cd $PVSW_ROOT/bin; . $PVSW_ROOT/bin/.bash_profile ; ./sqlmgr
-start | /usr/bin/su - psql || exit 1
touch /var/lock/subsys/psql
echo
}
stop_psql(){
echo Shutting down Pervasive services:
SQLID=`/bin/ps ax | grep -v grep | grep sqlmgr | awk '{print $1}'`
if [ X$SQLID != X ] ; then
echo sqlmgr
if [ -x /usr/local/psql/bin/sqlmgr ] ; then
echo cd $PVSW_ROOT/bin; . $PVSW_ROOT/bin/.bash_profile ; ./sqlmgr
-stop | /usr/bin/su - psql
else
kill -9 $SQLID
fi
fi
BTRID=`/bin/ps ax | grep -v grep | grep mkded | awk '{print $1}'`
if [ X$BTRID != X ] ; then
echo mkded
if [ -x /usr/local/psql/bin/mkded ] ; then
echo cd $PVSW_ROOT/bin; . $PVSW_ROOT/bin/.bash_profile ; ./mkded
-stop | /usr/bin/su - psql
else
kill -9 $BTRID
fi
fi
echo
rm -f /var/lock/subsys/psql
}
force_psql(){
if [ -x $PVSW_ROOT/bin/mkded ] ; then
echo Clearing Pervasive shared memory:
echo cd $PVSW_ROOT/bin; . $PVSW_ROOT/bin/.bash_profile ; ./mkded
-force | /bin/su - psql
fi
# jme 27791
MEMORY=`ipcs -m | grep psql | awk '{print $2}' | tr -d psql `
if [ X$MEMORY != X ] ; then
for i in $MEMORY ; do
ipcrm shm $i
done
fi
echo Clearing semaphores:
SEMAFORES=`ipcs -s | grep psql | awk '{print $2}' | tr -d psql `
if [ X$SEMAFORES != X ] ; then
for i in $SEMAFORES ; do
ipcrm sem $i
done
fi
# ayahin: defect 33091
SQLID=`/bin/ps ax | grep -v grep | grep sqlmgr | awk '{print $1}'`
BTRID=`/bin/ps ax | grep -v grep | grep mkded | awk '{print $1}'`
if [ X$SQLID != X ] ; then
echo sqlmgr
kill -9 $SQLID
fi
if [ X$BTRID != X ] ; then
echo mkded
kill -9 $BTRID
fi
echo
}
# Setting up environment
PVSW_ROOT=/usr/local/psql
PATH=$PVSW_ROOT/bin:$PATH
LD_LIBRARY_PATH=$PVSW_ROOT/lib
cd $PVSW_ROOT/bin
case $1 in
start)
start_psql
;;
stop)
stop_psql
;;
force)
stop_psql
force_psql
;;
restart)
echo Restarting Pervasive services:
stop_psql
start_psql
echo done.
;;
*)
echo Usage: psql {start|stop|force|restart}
exit 1
esac
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
A backtrace: (where and where full) for those who can decipher them
uma_core.c seems to have been the trigger.
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc032cc4c in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
#2 0xc032cfd7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc0163e22 in db_panic () at /usr/src/sys/ddb/db_command.c:449
#4 0xc0163da2 in db_command (last_cmdp=0xc05c6b40, cmd_table=0x0,
aux_cmd_tablep=0xc054de7c, aux_cmd_tablep_end=0xc054de94)
at /usr/src/sys/ddb/db_command.c:346
#5 0xc0163ec5 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:471
#6 0xc0166dc5 in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:73
#7 0xc04b454c in kdb_trap (type=3, code=0, regs=0xcc464aa4)
at /usr/src/sys/i386/i386/db_interface.c:172
#8 0xc04c5e1d in trap (frame=
{tf_fs = -1047855080, tf_es = -867827696, tf_ds = 16, tf_edi = 1,
tf_esi = -1068224493, tf_ebp = -867808528, tf_isp = -867808560, tf_ebx
= 0, tf_edx = 0, tf_ecx = -1067232032, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1068808188, tf_cs = 8, tf_eflags = 646, tf_esp =
-1068208597, tf_ss = -1068312245})
at /usr/src/sys/i386/i386/trap.c:580
#9 0xc04b5f38 in calltrap () at {standard input}:102
#10 0xc032cf65 in panic (
fmt=0xc0543013 kmem_malloc(%ld): kmem_map too small: %ld total
allocated)
at /usr/src/sys/kern/kern_shutdown.c:534
#11 0xc047dee0 in kmem_malloc (map=0xc082f0b0, size=4096, flags=2)
at /usr/src/sys/vm/vm_kern.c:339
#12 0xc048ee87 in page_alloc (zone=0xc083aee0, bytes=0, pflag=0x0,
wait=0)
---Type return to continue, or q return to quit---
at /usr/src/sys/vm/uma_core.c:806
#13 0xc048ebbf in slab_zalloc (zone=0xc083aee0, wait=2)
at /usr/src/sys/vm/uma_core.c:711
#14 0xc048fd58 in uma_zone_slab (zone=0xc083aee0, flags=258)
at /usr/src/sys/vm/uma_core.c:1503
#15 0xc048ff96 in uma_zalloc_bucket (zone=0xc083aee0, flags=258)
at /usr/src/sys/vm/uma_core.c:1606
#16 0xc048fbf9 in uma_zalloc_arg (zone=0xc083aee0, udata=0x0, flags=258)
at /usr/src/sys/vm/uma_core.c:1434
#17 0xc0321543 in malloc (size=3229855456, type=0xc0583a80, flags=258)
at /usr/src/sys/vm/uma.h:229
#18 0xc03325f5 in sigacts_alloc () at /usr/src/sys/kern/kern_sig.c:2719
#19 0xc03173ce in fork1 (td=0xc18bce40, flags=20, pages=0,
procp=0xcc464cd8)
at /usr/src/sys/kern/kern_fork.c:414
#20 0xc0316c2b in fork (td=0xc18bce40, uap=0xcc464d10)
at /usr/src/sys/kern/kern_fork.c:102
#21 0xc04c6753 in syscall (frame=
{tf_fs = 134938671, tf_es = 134873135, tf_ds = -1078001617,
tf_edi = 6, tf_esi = 135030952, tf_ebp = -1077937480, tf_isp =
-867807884, tf_ebx = 135016448, tf_edx = 3, tf_ecx = -1077937680,
tf_eax = 2, tf_trapno = 12, tf_err = 2, tf_eip = 673679423, tf_cs = 31,
tf_eflags = 531, tf_esp = -1077937732, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1008
#22 0xc04b5f8d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb) where full
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
No locals.
#1 0xc032cc4c in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:372
No locals.
#2 0xc032cfd7 in panic () at /usr/src/sys/kern/kern_shutdown.c:550
td = (struct thread *) 0xc18bce40
bootopt = 260
newpanic = 0
ap = 0xcc464924 IF=\026\004HK
buf = kmem_malloc(4096): kmem_map too small: 112951296 total
allocated, '\0' repeats 191 times
#3 0xc0163e22 in db_panic () at /usr/src/sys/ddb/db_command.c:449
No locals.
#4 0xc0163da2 in db_command (last_cmdp=0xc05c6b40, cmd_table=0x0,
aux_cmd_tablep=0xc054de7c, aux_cmd_tablep_end=0xc054de94)
at /usr/src/sys/ddb/db_command.c:346
cmd = (struct command *) 0xc04dedfc
t = 0
modif =
\0t\\hidlIF\r\0\0\0Tc\r\0\0\0\001\0\0\0\214IFFJ:b\aK\0
`Uc]at\\x\0\0\0t\\hidIFa[\026\222ZPPZ\026\0\0\0\0\020\0\0\0
hidt\\S\026t\\l\\x\0\0\0\003\0\0
addr = -1068808188
count = -1
have_addr = 0
---Type return to continue, or q return to quit---
result = 0
#5 0xc0163ec5 in db_command_loop () at
/usr/src/sys/ddb/db_command.c:471
No locals.
#6 0xc0166dc5 in db_trap (type=3, code=0) at
/usr/src/sys/ddb/db_trap.c:73
bkpt = 0
#7 0xc04b454c in kdb_trap (type=3, code=0, regs=0xcc464aa4)
at /usr/src/sys/i386/i386/db_interface.c:172
ef = 70
ddb_mode = 1
#8 0xc04c5e1d in trap (frame=
{tf_fs = -1047855080, tf_es = -867827696, tf_ds = 16, tf_edi = 1,
tf_esi = -1068224493, tf_ebp = -867808528, tf_isp = -867808560, tf_ebx
= 0, tf_edx = 0, tf_ecx = -1067232032, tf_eax = 18, tf_trapno = 3,
tf_err = 0, tf_eip = -1068808188, tf_cs = 8, tf_eflags = 646, tf_esp =
-1068208597, tf_ss = -1068312245})
at /usr/src/sys/i386/i386/trap.c:580
td = (struct thread *) 0xc18bce40
p = (struct proc *) 0xc19c7d3c
sticks = 3224514865
i = 0
ucode = 0
type = 3
code = 0
eva = 0
#9 0xc04b5f38 in calltrap () at {standard input}:102
---Type return to continue, or q return to quit---
No locals.
#10 0xc032cf65 in
Re: device driver memory leak in 5.1-20030726?
Mark Blackman writes: I'm seeing the same 'kmem_malloc(4096): kmem_map too small: X total allocated' messages that a few other have reported. [snip] From these symptoms, I'm speculating that one or more device drivers are producing kernel memory leaks and either triggering the 'kmem_map too small' messages or pushing all of the userland processes out of the way. Is this a reasonable interpretation? Does anyone else see symptoms that might lead to this conclusion? I'm seeing exactly the same thing when I try to access my Archos Jukebox (a USB 2.0 device). This didn't happen with a kernel made before July 20, although I can't say when exactly the leak (if there is one) was introduced, since I only make a new kernel every few weeks. Eventually usb_allocmem fails and shortly thereafter I get the ``kmem_map too small'' panic. Unfortunately, panicing in ddb results in a hang - no crashdump. --- Gary Jennejohn / garyj[at]jennejohn.org gj[at]freebsd.org gj[at]denx.de ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Loading 5.x onto a laptop
Hi Has anyone manage to load ver 5.x into the Compaq Presario 1370 notebook. I get kernel panic all the time Regards ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-07-26 19:57:59 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-07-26 19:57:59 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 20:01:00 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-26 21:06:26 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Jul 26 21:06:26 GMT 2003 Kernel build for GENERIC completed on Sat Jul 26 21:20:56 GMT 2003 TB --- 2003-07-26 21:20:56 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-26 21:20:56 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sat Jul 26 21:20:56 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pci/if_vr.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pci/if_wb.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -DGPROF -falign-functions=16 -DGPROF4 -DGUPROF -finline-limit=15000 -fno-builtin -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror -finstrument-functions -Wno-inline /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pci/if_xl.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h
Re: Loading 5.x onto a laptop
On Sat, Jul 26, 2003 at 09:18:01PM +, Dave Johnson wrote: Hi Has anyone manage to load ver 5.x into the Compaq Presario 1370 notebook. I get kernel panic all the time Regards Yes. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Memory Mangement Problem in 5.1-RELEASE
Poul-Henning Kamp wrote this message on Sat, Jul 26, 2003 at 10:04 +0200:
In message [EMAIL PROTECTED], Ahmed Al-Hindawi writes
Programs like cp(1) uses mmap(2) to copy things, so if you cp(1) a big
file, it is not uncommon for some programs to end up on swap. Until they
Only for files up to 8megs in size. I was meaning to ask if we should
incrase this limit.
line 136 of src/bin/cp/utils.c:
if (S_ISREG(fs-st_mode) fs-st_size = 8 * 1048576) {
are used again, they will not get paged in. I often see the getty's for
the vty's and similar junk on my swap space.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on sparc64/sparc64
TB --- 2003-07-26 22:56:58 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-07-26 22:56:58 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-26 22:58:54 - building world TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/sparc64/sparc64/obj/sparc64/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-27 00:01:07 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jul 27 00:01:07 GMT 2003 Kernel build for GENERIC completed on Sun Jul 27 00:10:14 GMT 2003 TB --- 2003-07-27 00:10:14 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-27 00:10:14 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jul 27 00:10:14 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_wb.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/if_xl.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/intpm.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/pci/meteor.c
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Does it have a firewire port? Yes. How can I use that? I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. : : Does it have a firewire port? : : Yes. How can I use that? If you have a second machine with firewire, then you can use the firewire port as your console. Look at /usr/ports/devel/dcons. It is one of the under-publicized cool features from Japan (Thanks Shimokawa-san!). : I had also expected that you could shed some light on the BIOS mapping : issue. Since my last message I've become pretty sure that it must be : something to do with the chip set setup. Is it possible that we're : not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. It may be the case that we aren't setting things up so that XFree86 can call the BIOS, but given that we used PCIBIOS before ACPI, it seems unlikely. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
MD5 signatures of 5.1-RELEASE
I'm getting a wrong MD5 signature when downloading the miniinst image from ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/5.1 Also, and this is really weird, the file sizes I see on a web browser are different than what I get with a FTP client. Yes, I realize this is a FTP URL but still, the file list view in Mozilla (both Firbird 0.6 on FreeBSD and 1.2.1 on Linux) indicates files 7-8 megabytes smaller than a ls done in a command-line ftp. In any case, I don't care much about Mozilla's quirks - I just want the miniinst ISO to match its MD5. -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: machine doesn't have a serial port, so I can't apply a kernel debugger to find out what's going on. Does it have a firewire port? Yes. How can I use that? If you have a second machine with firewire, then you can use the firewire port as your console. Look at /usr/ports/devel/dcons. It is one of the under-publicized cool features from Japan (Thanks Shimokawa-san!). Ah, good stuff. I'll have to check if it also works with gdb. Unfortunately, this is my only machine with firewire. I was wondering if there were USB/conventional serial converters that I could use. I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. I'm not sure at what level. I suspect that something in the chipset is turning off that area of memory, or mapping something else to it. The dump from Microsoft shows that there's another BIOS at 0xcf000, but what I have mapped in memory shows only 0xff up to address 0xd, where I find another BIOS signature: 0x28377fe0: 0x 0x 0x 0x 0x28377ff0: 0x 0x 0x 0x 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 It may be the case that we aren't setting things up so that XFree86 can call the BIOS, but given that we used PCIBIOS before ACPI, it seems unlikely. Well, this is a new laptop, so it's possible that something *is* getting set up incorrectly. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: MD5 signatures of 5.1-RELEASE
Dan Pelleg [EMAIL PROTECTED] writes: I'm getting a wrong MD5 signature when downloading the miniinst image from ftp://ftp.freebsd.org/pub/FreeBSD/ISO-IMAGES-i386/5.1 Sorry, false alarm. This is just the plain-ol' ASCII transfer nonsense. I did not expect fetch to trip me like this. Sorry for wasting people's time. -- Dan Pelleg ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Saturday, 26 July 2003 at 11:27:06 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : machine doesn't have a serial port, so I can't apply a kernel debugger : to find out what's going on. : : Does it have a firewire port? : : Yes. How can I use that? : : If you have a second machine with firewire, then you can use the : firewire port as your console. Look at /usr/ports/devel/dcons. It is : one of the under-publicized cool features from Japan (Thanks : Shimokawa-san!). : : Ah, good stuff. I'll have to check if it also works with gdb. : Unfortunately, this is my only machine with firewire. I was wondering : if there were USB/conventional serial converters that I could use. None of them support console access, as far as I know. : I had also expected that you could shed some light on the BIOS mapping : issue. Since my last message I've become pretty sure that it must be : something to do with the chip set setup. Is it possible that we're : not mapping the entire area 0xc to 0xf? : : I'm not sure what you mean by this question. Since OLDCARD works, and : requires read/write access to that physical memory range, I doubt that : it is unmapped. : : I'm not sure at what level. I suspect that something in the chipset : is turning off that area of memory, or mapping something else to it. : The dump from Microsoft shows that there's another BIOS at 0xcf000, : but what I have mapped in memory shows only 0xff up to address : 0xd, where I find another BIOS signature: : : 0x28377fe0: 0x 0x 0x 0x : 0x28377ff0: 0x 0x 0x 0x : 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x : 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e : 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 Typically, there are a number of different ROM sections. The orm driver searches for these things out. Does it report anything : It may be the case that we aren't setting things up so that XFree86 : can call the BIOS, but given that we used PCIBIOS before ACPI, it : seems unlikely. : : Well, this is a new laptop, so it's possible that something *is* : getting set up incorrectly. True. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Mapping Video BIOS?
On Saturday, 26 July 2003 at 19:47:50 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 18:44:43 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: I had also expected that you could shed some light on the BIOS mapping issue. Since my last message I've become pretty sure that it must be something to do with the chip set setup. Is it possible that we're not mapping the entire area 0xc to 0xf? I'm not sure what you mean by this question. Since OLDCARD works, and requires read/write access to that physical memory range, I doubt that it is unmapped. I'm not sure at what level. I suspect that something in the chipset is turning off that area of memory, or mapping something else to it. The dump from Microsoft shows that there's another BIOS at 0xcf000, but what I have mapped in memory shows only 0xff up to address 0xd, where I find another BIOS signature: 0x28377fe0: 0x 0x 0x 0x 0x28377ff0: 0x 0x 0x 0x 0x28378000: 0xe80caa55 0x4ecb14c8 0x033b 0x 0x28378010: 0x 0x0020 0x00600040 0x90c08b2e 0x28378020: 0x49444e55 0xea16 0x0c9d0201 0xad100800 Typically, there are a number of different ROM sections. The orm driver searches for these things out. Does it report anything Presuming that it's the ROM driver, I get this in the dmesg I posted: pnpbios: Bad PnP BIOS data checksum That's pretty much the same problem reported by the X server. Where would I go from there? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: gcc related -current upgrade problems
On Fri, Jul 25, 2003 at 05:45:10PM -0700, Scott M. Likens wrote: These issues have been addressed in KDE 3.1.3 if you're patient enough for Will to work out the kinks the ports will be updated in a week or less. The issue is not KDE related one, rather the base c++ headers trigger all sorts of warnings. Apparently on other operating systems libstdc++ does not trigger these warnings. - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
kernel build failure: mga_state.c
cc -c -O -pipe -march=pentium3 -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/dev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /usr/src/sys/dev/drm/mga_state.c /usr/src/sys/dev/drm/mga_state.c: In function `mga_g400_emit_state': /usr/src/sys/dev/drm/mga_state.c:278: warning: inlining failed in call to `mga_g400_emit_pipe' /usr/src/sys/dev/drm/mga_state.c:387: warning: called from here /usr/src/sys/dev/drm/mga_state.c:163: warning: inlining failed in call to `mga_g400_emit_tex0' /usr/src/sys/dev/drm/mga_state.c:397: warning: called from here *** Error code 1 Stop in /usr/obj/usr/src/sys/DAEMON. *** Error code 1 -- Optimized, readable, on time; Pick any two. FreeBSD 5.1-CURRENT i386 11:23AM up 1 day, 2:15, 1 user, load averages: 0.65, 0.56, 0.39 signature.asc Description: This is a digitally signed message part
Re: Mapping Video BIOS?
In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : Presuming that it's the ROM driver, I get this in the dmesg I posted: : pnpbios: Bad PnP BIOS data checksum That's likely the problem. However, PnP BIOS information isn't the same thing that the orm[sic] driver probes for. : Where would I go from there? Not sure. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel build failure: mga_state.c
Have you not been reading the mailing list? Right now you are supposed to WERROR if you run into these. Kris pgp0.pgp Description: PGP signature
Re: FreeBSD 5.1-R kernel panic
Well, I had compiled options DDB into the kernel and today the kernel panic'd... here is what I got. I ran the following in the db prompt. trace, show reg, ps. Let me know if this is the kind of information you need, and if there is anything else I need to provide... can I re-compile the kernel without the options DDB now, or should I provide the same info next time in panic's to confirm it's the same problem? Thanks, Stephane. I've attached the file debug.txt which contains the panic info. Let me know if you need it in a different format. Thanks again, Stephane Raimbault. - Original Message - From: Bosko Milekic [EMAIL PROTECTED] Newsgroups: mailing.freebsd.current Sent: Wednesday, July 23, 2003 10:14 Subject: Re: FreeBSD 5.1-R kernel panic On Wed, Jul 23, 2003 at 09:56:32AM -0600, Stephane Raimbault wrote: Hi Bosko, Looking at netstat -m, the value I'd probably be interested in is the following: 3% of cluster map consumed knowing that the Maximum possible is 25600 I can deduce that ~768 are being used? Is that correct. I'm not much of a programmer, but I did recognize the printf(); statements from a C class I didn't do well in half a decade ago... as you can tell, I'm not much of a programmer :). If it's not the 3% I should be paying attention too... then let me know :) Look at the in pool values for all the pcpu and GEN caches and add them up. Do this for clusters (since there are fewer). Compare to the Maximum Possible value. With a machine that goes into spike-load periods, you may want to have the Maximum Possible stay about 4-6 times what you have as your average in pool value (remember to sum the in pool values for the pcpu and GEN caches). The 3% is not what you think it is. It's the percentage of the allocated wired-down memory that is NOT in any of the caches but is allocated and circulating in the system. If you have a high number of cached items but the percentage is relatively low for most of the time, it's a sign that you were probably in a heavy-usage scenario some time ago, but that your current usage is relatively low. As for using the option DDB in my kernel, I do have one question. I do have remote console access that I use to go into single user mode on the box remotely. I'm suspecting I could use the debugger mode over the comconsole... I just want to make sure there is some kind of reboot command from the debugger so that I can tell the box to reboot once I've captured the stack trace? If so, I'll enable the DDB tonight and get you the info as soon as I can. Yes, you can do DDB over serial console. Take a look at the handbook for more information on using DDB. If you have the space in /var and enough swap, you may want to try getting a crashdump so that you can reboot and use GDB to debug. Again, take a look at the handbook. thanks again, Stephane. -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED] --- Outgoing mail is certified Virus Free. Checked by AVG anti-virus system (http://www.grisoft.com). Version: 6.0.502 / Virus Database: 300 - Release Date: 7/18/2003 panic: kmem_malloc(4096): kmem_map too small: 275251200 total allocated cpuid = 0; lapic.id = Debugger(panic) Stopped at Debugger+0x55: xchgl %ebx,in_Debugger.0 db trace Debugger(c04f954d,0,c050b17e,e959eb04,1) at Debugger+0x55 panic(c050b17e,1000,1068,e959eb30,e959eb3c) at panic+0x11f kmem_malloc(c082f0b0,1000,2,e959eb84,c0457486) at kmem_malloc+0xf7 page_alloc(c082ab40,1000,e959eb77,2,d47486d8) at page_alloc+0x27 slab_zalloc(c082ab40,102,d47486d8,e959ebcc,c036644d) at slab_zalloc+0x106 uma_zone_slab(c082ab40,102,0,d5069960,c082ac18) at uma_zone_slab+0xd8 uma_zalloc_bucket(c082ab40,102,c050c3d9,586,c02f0651) at uma_zalloc_bucket+0x15d uma_zalloc_arg(c082ab40,0,102,2,c082ab40) at uma_zalloc_arg+0x230 malloc(80,c054bf40,102,d7080680,e959ec50) at malloc+0x58 crget(c06f1140,e959ec50,d7080680,e959ecc8,c0361457) at crget+0x25 crdup(d7080680,8e1ad280,af77e,dd313180,d5069960) at crdup+0xe kern_access(d17b85f0,84536cc,0,0,e959ed40) at kern_access+0x17 access(d17b85f0,e959ed10,c05108b8,3fb,2) at access+0x29 syscall(bfbf002f,bfbf002f,bfbf002f,bfbfc6a4,284f15d4) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (33, FreeBSD ELF32, access), eip = 0x282cc463, esp = 0xbfbfc5fc, ebp = 0xbfbfc6c8 --- db show reg cs 0x8 ds0x10 es 0xd2e00010 fs 0xcada0018 ss0x10 eax 0x12 ecx0x4 edx 0 ebx 0 esp 0xe959eabc ebp 0xe959eac8 esi 0x100 edi
[current tinderbox] failure on alpha/alpha
TB --- 2003-07-27 04:00:02 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-27 04:00:02 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-07-27 04:01:59 - building world TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/alpha/alpha/obj/alpha/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-07-27 05:07:07 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sun Jul 27 05:07:07 GMT 2003 Kernel build for GENERIC completed on Sun Jul 27 05:18:53 GMT 2003 TB --- 2003-07-27 05:18:53 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src/sys/alpha/conf TB --- /usr/bin/make -B LINT TB --- 2003-07-27 05:18:53 - building LINT kernel TB --- cd /home/des/tinderbox/CURRENT/alpha/alpha/src TB --- /usr/bin/make buildkernel KERNCONF=LINT Kernel build for LINT started on Sun Jul 27 05:18:54 GMT 2003 [...] cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwlib.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/advansys/adwmcode.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/aha/aha.c cc -c -O -pipe -mcpu=ev4 -mtune=ev5 -mieee -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-builtin -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror
Feasibility/Practicality of using GBDE to facilitate encryptedswap, md, /tmp, filesystems
Hopefully PHK has a chance to look this one over, but if anyone else has any thoughts I'll take any opinions I can get. ;) I was looking over the 5.2 TODO and got curious as to the changes intended for GBDE to allow integration into the fstab / boot-time mount procedure. Unfortunately I have a rather poor background in how the various FreeBSD subsystems interact, but was wondering if such boot-time mount ability could be used such that GBDE encrypted devices could be used to back the swap, /tmp, and other portions of the file system. It seems that initializing a GBDE device at boot with a random lock file key (or no lock file?) such that as soon as the GBDE dev is detached or the machine is rebooted all information on that partition is not recoverable. Not only would this give us encrypted swap that OpenBSD minions always laude over me ;) but also it seems like (specifically /tmp encryption) would combat the chances that copies of plain text files get left around. On a slightly related note, I currently have a script that allows the creation of a post boot encrypted md device, and am just using the -p option on initialization to feed GBDE a passphrase piped from /dev/random into md5. Is there any way to do such an initialization more securely? (such as not having to rely on the security of the shell or md5 along the way?) Thanks -John ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
