[current tinderbox] failure on amd64/amd64
TB --- 2003-07-27 05:21:59 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-27 05:21:59 - 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-27 05:24:06 - 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-27 06:24:01 - 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 Sun Jul 27 06:24:01 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 -Wst
Re: We have ath, now what about Broadcom?
On Saturday, 26 July 2003 at 11:00:40 -0600, M. Warner Losh wrote: > 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. Or *whether* you live in the US. There's a very good reason nobody's ever been sued for reverse engineering in Australia: it's not illegal (which may be a different statement from saying "it's legal"). That gets back to the original question: is it legal to use reverse engineered software in the USA? Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
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]"
[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 /vol/vol0/users/des/
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
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: 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]"
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: 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]"
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: 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: 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?
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
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?
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]"
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
[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/CU
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]"
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]"
[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/
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]"
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]"
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 to continue, or q 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'
#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\\¿hid¿lIFÃ\r\0\0\0‡Tc¿\r\0\0\0\001\0\0\0\214IFÃF£J¿‡:b¿\aK\0
`Uc¿‡]a¿†t\\¿x\0\0\0†t\\¿hid¿∞IFÃa[\026¿\222ZP¿PZ\026¿\0\0\0\0\020\0\0\0
hid¿†t\\¿∂S\026¿†t\\¿–l\\¿x\0\0\0\003\0\0"
addr = -1068808188
count = -1
have_addr = 0
---Type to continue, or q 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 to continue, or q to quit---
No locals.
#10 0xc032cf65 in panic (
f
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]"
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]"
[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/freeb
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 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 -Wst
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]"
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]"
[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 /vol/vol0/users/des/
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]"
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]> 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]"
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?
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]"
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: 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]"
[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: 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]"
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: 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]"
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]"
[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 -W
[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
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
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: 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]"
[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/cont
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]"
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
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]"
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: 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]"
