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
[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 -Wstrict-prototypes -Wmissing-prototypes
[current tinderbox] failure on i386/i386
TB --- 2003-07-27 06:25:00 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-07-27 06:25:00 - 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-27 06:28:41 - 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-27 07:34:15 - 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 Sun Jul 27 07:34:15 GMT 2003 Kernel build for GENERIC completed on Sun Jul 27 07:48:41 GMT 2003 TB --- 2003-07-27 07:48:41 - 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-27 07:48:41 - 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 Sun Jul 27 07:48:42 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/i386/isa/pcvt/pcvt_drv.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/i386/isa/pcvt/pcvt_ext.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/i386/isa/pcvt/pcvt_kbd.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
Re: device driver memory leak in 5.1-20030726?
On Saturday, July 26, 2003, at 10:02 PM, Gary Jennejohn wrote: 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 Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. Mark Blackman Exonetric Consulting ___ [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?
On Sun, 27 Jul 2003, Mark Blackman wrote: Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: FreeBSD 5.1-R kernel panic
On Sat, Jul 26, 2003 at 10:48:21PM -0600, Stephane Raimbault wrote: 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. Are you using USB? Approximately 2 weeks ago, some changes were introduced into the USB code which could in some scenarios mean a depletion of kmem_map. I've glanced at usb_mem.c and it appears that the USB code 'caches' everything that it allocates into a couple of lists it maintains locally. This prevents UMA from seeing the freed memory and, from the point of view of the VM, the memory is never reclaimed. I am unsure as to whether or not the memory allocated by the USB stuff needs to be type stable so I can't really fix this. I urge the USB authors to glance there. If you are using USB, try turning it off to see if the panic persists. If not, then we'll have to look elsewhere. Regards, -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: device driver memory leak in 5.1-20030726?
On Sun, Jul 27, 2003 at 04:43:32PM +0200, Lukas Ertl wrote: On Sun, 27 Jul 2003, Mark Blackman wrote: Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. regards, le There are two problems. 1) The USB code never frees the stuff it allocates; 2) The USB code places the stuff it allocates into a couple of lists unprotected by any mutexes. It should at a minimum assert that Giant is held coming in, at all times. -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ -- 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 alpha/alpha
TB --- 2003-07-27 16:00:01 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-27 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-27 16:01:57 - 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 17:07:06 - 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 17:07:06 GMT 2003 Kernel build for GENERIC completed on Sun Jul 27 17:18:54 GMT 2003 TB --- 2003-07-27 17:18:54 - 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 17:18:54 - 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 17: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
[current tinderbox] failure on amd64/amd64
TB --- 2003-07-27 17:21:58 - starting CURRENT tinderbox run for amd64/amd64 TB --- 2003-07-27 17:21:58 - 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 17:23:54 - 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 18:23:48 - 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 18:23:48 GMT 2003 [...] cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_ch.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_da.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_pass.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-omit-frame-pointer -mcmodel=kernel -mno-red-zone -mfpmath=387 -mno-sse -mno-sse2 -mno-mmx -mno-3dnow -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/amd64/amd64/src/sys/cam/scsi/scsi_sa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: FreeBSD 5.1-R kernel panic
Hi Bosko, Thanks for your response. I do not use USB on the system... I'll try removing those devices from the kernel and see if the problem continues. I will let you know. Thanks, Stephane Raimbault. - Original Message - From: Bosko Milekic [EMAIL PROTECTED] Newsgroups: mailing.freebsd.current Sent: Sunday, July 27, 2003 8:56 Subject: Re: FreeBSD 5.1-R kernel panic On Sat, Jul 26, 2003 at 10:48:21PM -0600, Stephane Raimbault wrote: 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. Are you using USB? Approximately 2 weeks ago, some changes were introduced into the USB code which could in some scenarios mean a depletion of kmem_map. I've glanced at usb_mem.c and it appears that the USB code 'caches' everything that it allocates into a couple of lists it maintains locally. This prevents UMA from seeing the freed memory and, from the point of view of the VM, the memory is never reclaimed. I am unsure as to whether or not the memory allocated by the USB stuff needs to be type stable so I can't really fix this. I urge the USB authors to glance there. If you are using USB, try turning it off to see if the panic persists. If not, then we'll have to look elsewhere. Regards, -- 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] ___ [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?
Lukas Ertl writes: On Sun, 27 Jul 2003, Mark Blackman wrote: Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. I did some playing around today with various kernels. A kernel from July 12 at 12:01 works just fine. A kernel from July 15 at 23:30 hangs (with the IRQ9 thread and g_down each using 50% of the CPU). Killing the mount with ^C leaves the (in my case) mount_msdos hung in the background and it's un-killable. It's probably stuck waiting for USB. A kernel from July 16 at 12:01 exhibits similar symptoms to the kernel from July 15. July 15 is about the time that a massive update of the USB code from NetBSD was made. I didn't try kernels from July 13 or July 14. I've observed other problems with -current: 1) mount_msdos results in a kernel panic (NULL pointer deref) 2) mounting linuxprocfs also results in a panic At the moment I'm running a world from July 15 and a kernel from July 12. --- 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?
Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200: On Sun, 27 Jul 2003, Mark Blackman wrote: Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I must note that the USB changes only allocates memory in the M_USB area which is described by: usb.c:MALLOC_DEFINE(M_USB, USB, USB); So, that means it wouldn't be in the devbuf area. (This is the one of the points of malloc areas is to help track down stray allocations and memory leaks). I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. It may be leaking, but it won't be leaking devbuf memory. The only thing that is in usb (in dev/usb) that uses M_DEVBUF is ukbd. -- 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: device driver memory leak in 5.1-20030726?
Gary Jennejohn writes: I've observed other problems with -current: 1) mount_msdos results in a kernel panic (NULL pointer deref) 2) mounting linuxprocfs also results in a panic Replying to myself. (2) is wrong. It doesn't panic, it just fails with a message that linuxprocfs doesn't support the new mount. --- 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]
SSH from host to jail
I'm trying to set up some jails in a 5.1R system. I've pretty much copied a setup that was working fine in 4.8; but on 5.1 I can't seem to SSH from the host system into one of its jails. It acts like the packets just aren't getting through. I would really appreciate it if somebody would send me rc.conf fragments that are known to work for setting up a jail's IP alias and routing on 5.1. Thanks, -Pat ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Feasibility/Practicality of using GBDE to facilitate encryptedswap, md, /tmp, filesystems
In message [EMAIL PROTECTED], John Stockdale writes: 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 have a number of operations I plan to add to the gbde tool, but some of them has be a bit worried about their foot-shooting potential so I'm still thinking about them, and rather than go over the program twice, I'm holding on to the easy ones until I'm ready to do them all. The one operation which is a no-brainer so to speak is the one time attach where the gbde device is init'ed and attached but the master key and lock sector is never written to the device. This is the mode you want to use for paging devices. -- 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]
[PATCH] Add support for the Intel 852 chipset
Here is a bad that adds i852 support to the AGP system. This seems to work fine on my Dell 5150. Others may want to double-check this first since this isn't my area of expertise. Joe -- PGP Key : http://www.marcuscom.com/pgp.asc --- src/sys/pci/agp_intel.c.origSat Jul 26 00:28:34 2003 +++ src/sys/pci/agp_intel.c Sat Jul 26 00:28:39 2003 @@ -99,6 +99,9 @@ case 0x25308086: return (Intel 82850 host to AGP bridge); + + case 0x35808086: + return (Intel 82852 host to AGP bridge); case 0x33408086: return (Intel 82855 host to AGP bridge); @@ -209,6 +212,7 @@ break; case 0x1a308086: /* i845 */ + case 0x35808086: /* i852 */ case 0x33408086: /* i855 */ case 0x25708086: /* i865 */ case 0x25788086: /* i875P */ @@ -232,6 +236,7 @@ case 0x25018086: /* i820 */ case 0x1a308086: /* i845 */ case 0x25308086: /* i850 */ + case 0x35808086: /* i852 */ case 0x33408086: /* i855 */ case 0x25318086: /* i860 */ case 0x25708086: /* i865 */ @@ -278,6 +283,7 @@ ~(1 1)), 1); case 0x1a308086: /* i845 */ + case 0x35808086: /* i852 */ case 0x33408086: /* i855 */ case 0x25708086: /* i865 */ case 0x25788086: /* i875P */ signature.asc Description: This is a digitally signed message part
Re: SSH from host to jail
Pat Lashley wrote:
I'm trying to set up some jails in a 5.1R system. I've pretty much
copied a setup that was working fine in 4.8; but on 5.1 I can't seem
to SSH from the host system into one of its jails. It acts like the
packets just aren't getting through.
I would really appreciate it if somebody would send me rc.conf fragments
that are known to work for setting up a jail's IP alias and routing on
5.1.
sure, but this isn't going to fix your problem:
ifconfig_wi0=inet 192.168.0.140 netmask 255.255.255.0
ifconfig_wi0_alias0=inet 192.168.0.131 netmask 255.255.255.255
jail_enable=YES
jail_list=shiba
jail_shiba_hostname=shiba
jail_shiba_ip=192.168.0.131
jail_shiba_rootdir=/usr/prison/192_168_0_130/
jail_shiba_exec=/bin/sh /etc/rc
To fix your problem you should try to mount a devfs for the jail so the
tty device is available for sshd to open when you login. I simply added
one line to my /etc/rc.d/jail script to test for the dev mount-point
in jail. Like so:
[ -d ${jail_rootdir}/dev ] mount -t devfs ${jail_rootdir}\dev
I suppose we could avoid this little fau pax in the future by adding a
new jail specific rc.conf var like this example:
jail_shiba_devfs=/usr/prison/192_168_0_130/dev
It could be easy to have it simply exist, or be non-null, to imply a
desire for devfs, and further checked for the existence of the
mount-point as I wrote above.
I could have a pr+patch made in 5 minutes if anybody thinks this is not
a bad idea?
-Jon
___
[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?
On Sun, 27 Jul 2003, John-Mark Gurney wrote: Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200: I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I must note that the USB changes only allocates memory in the M_USB area which is described by: usb.c:MALLOC_DEFINE(M_USB, USB, USB); So, that means it wouldn't be in the devbuf area. (This is the one of the points of malloc areas is to help track down stray allocations and memory leaks). Then I have no explanation. I'm running the box with a WiFi card, generating lots of network traffic, and the box is running fine, no panics, and low devbuf allocation. I'm running the box with the USB Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM link), and the box panics within half an hour in kmem_malloc, with devbuf allocation up to 74MB. It must be either in the Bluetooth code or in the USB code. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR with filedesc structure and Giant
After upgrading last night, one of the package machines found this: lock order reversal 1st 0xc6c1c334 filedesc structure (filedesc structure) @ /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902 2nd 0xc04aa120 Giant (Giant) @ /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372 Stack backtrace: backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17 witness_lock(c04aa120,8,c0434e3d,174,1bc) at witness_lock+0x672 _mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba spec_poll(d8dddaf8,d8dddb18,c02d119c,d8dddaf8,c04939a0) at spec_poll+0x134 spec_vnoperate(d8dddaf8,c04939a0,c520b124,40,c675e300) at spec_vnoperate+0x18 vn_poll(c44c5e14,40,c675e300,c6222d10,c675e300) at vn_poll+0x3c selscan(c6222d10,d8dddb98,d8dddb88,6,4) at selscan+0x13e kern_select(c6222d10,6,bfbff5c0,0,0) at kern_select+0x36f select(c6222d10,d810,c0455899,3ee,5) at select+0x66 syscall(2f,2f,2f,8055050,bfbff5b8) at syscall+0x273 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (93), eip = 0x280ccacc, esp = 0x2832eb68, ebp = 0x2832ebc0 --- Debugger(witness_lock) Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0 Kris pgp0.pgp Description: PGP signature
dereferencing type-punned pointer will break strict-aliasing rules
Is this caused by -oS option? - in making BOOTMFS in make release cc -c -Os -pipe -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/geom/geom_dev.c /usr/src/sys/geom/geom_dev.c: In function `g_dev_open': /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:205: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:205: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c: In function `g_dev_close': /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:232: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:253: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:253: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c: In function `g_dev_ioctl': /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:281: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules /usr/src/sys/geom/geom_dev.c:340: warning: dereferencing type-punned pointer will break strict-aliasing rules *** Error code 1 1 error -- Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc. [EMAIL PROTECTED] // FreeBSD Project ___ [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?
Lukas Ertl wrote this message on Mon, Jul 28, 2003 at 01:11 +0200:
On Sun, 27 Jul 2003, John-Mark Gurney wrote:
Then I have no explanation. I'm running the box with a WiFi card,
generating lots of network traffic, and the box is running fine, no
panics, and low devbuf allocation. I'm running the box with the USB
Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM
link), and the box panics within half an hour in kmem_malloc, with devbuf
allocation up to 74MB. It must be either in the Bluetooth code or in the
USB code.
Hmm. this is wierd, it appears to be a bug in the Netgraph code. There
is a bit of code that allocates memory for the data, and then promptly
overwrites the malloc w/ data from the mbuf.
Try the attached patch. This could VERY well crash your machine as I
don't know mbuf code very well.
Thanks.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Index: ng_device.c
===
RCS file: /home/ncvs/src/sys/netgraph/ng_device.c,v
retrieving revision 1.3
diff -u -u -r1.3 ng_device.c
--- ng_device.c 3 Mar 2003 12:15:52 - 1.3
+++ ng_device.c 28 Jul 2003 00:47:30 -
@@ -360,12 +360,6 @@
return(-1);
}
- buffer = malloc(sizeof(char)*m-m_len, M_DEVBUF, M_NOWAIT | M_ZERO);
- if(buffer == NULL) {
- printf(%s(): ERROR: buffer malloc failed\n,__func__);
- return(-1);
- }
-
buffer = mtod(m,char *);
if( (connection-loc+m-m_len) NGD_QUEUE_SIZE) {
@@ -374,7 +368,8 @@
} else
printf(%s(): queue full, first read out a bit\n,__func__);
- free(buffer,M_DEVBUF);
+ /* XXX - free chain? */
+ m_free(m);
return(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
On Sun, Jul 27, 2003 at 04:33:51PM -0700, Kris Kennaway wrote:
After upgrading last night, one of the package machines found this:
lock order reversal
1st 0xc6c1c334 filedesc structure (filedesc structure) @
/a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:902
2nd 0xc04aa120 Giant (Giant) @
/a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
Stack backtrace:
backtrace(c043d4af,c04aa120,c0439aa4,c0439aa4,c0434e3d) at backtrace+0x17
witness_lock(c04aa120,8,c0434e3d,174,1bc) at witness_lock+0x672
_mtx_lock_flags(c04aa120,0,c0434e3d,174,c043daba) at _mtx_lock_flags+0xba
spec_poll(d8dddaf8,d8dddb18,c02d119c,d8dddaf8,c04939a0) at spec_poll+0x134
spec_vnoperate(d8dddaf8,c04939a0,c520b124,40,c675e300) at spec_vnoperate+0x18
vn_poll(c44c5e14,40,c675e300,c6222d10,c675e300) at vn_poll+0x3c
selscan(c6222d10,d8dddb98,d8dddb88,6,4) at selscan+0x13e
kern_select(c6222d10,6,bfbff5c0,0,0) at kern_select+0x36f
select(c6222d10,d810,c0455899,3ee,5) at select+0x66
syscall(2f,2f,2f,8055050,bfbff5b8) at syscall+0x273
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (93), eip = 0x280ccacc, esp = 0x2832eb68, ebp = 0x2832ebc0 ---
Debugger(witness_lock)
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
#8 0xc0290ed7 in witness_lock (lock=0xc04aa120, flags=8,
file=0xc0434e3d /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c,
line=372)
at /a/asami/portbuild/i386/src-client/sys/kern/subr_witness.c:838
#9 0xc0261f4a in _mtx_lock_flags (m=0x0, opts=0, file=0xc04d17a8 , line=-1068850912)
at /a/asami/portbuild/i386/src-client/sys/kern/kern_mutex.c:334
#10 0xc0231154 in spec_poll (ap=0xd8dddaf8)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:372
#11 0xc0230648 in spec_vnoperate (ap=0x0)
at /a/asami/portbuild/i386/src-client/sys/fs/specfs/spec_vnops.c:122
#12 0xc02d119c in vn_poll (fp=0x0, events=0, active_cred=0xc675e300, td=0x0) at
vnode_if.h:537
#13 0xc02945ae in selscan (td=0xc6222d10, ibits=0xd8dddb98, obits=0xd8dddb88, nfd=6)
at /a/asami/portbuild/i386/src-client/sys/sys/file.h:272
#14 0xc029412f in kern_select (td=0xc6222d10, nd=6, fd_in=0xbfbff5c0, fd_ou=0x0,
fd_ex=0x0, tvp=0xd8dddcd4)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:822
#15 0xc0293da6 in select (td=0x0, uap=0xd810)
at /a/asami/portbuild/i386/src-client/sys/kern/sys_generic.c:726
#16 0xc03ef9b3 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134565968, tf_esi = -1077938760,
tf_ebp = 674425792, tf_isp = -656548492, tf_ebx = 0, tf_edx = -1077938752, tf_ecx = 0,
tf_eax = 93, tf_trapno = 12, tf_err = 2, tf_eip = 671926988, tf_cs = 31, tf_eflags =
534, tf_esp = 674425704, tf_ss = 47})
at /a/asami/portbuild/i386/src-client/sys/i386/i386/trap.c:1008
#17 0xc03dfbed in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---
(kgdb)
pgp0.pgp
Description: PGP signature
Re: device driver memory leak in 5.1-20030726?
Lukas Ertl wrote this message on Mon, Jul 28, 2003 at 01:11 +0200:
Then I have no explanation. I'm running the box with a WiFi card,
generating lots of network traffic, and the box is running fine, no
panics, and low devbuf allocation. I'm running the box with the USB
Bluetooth dongle, generating much less traffic (it's just a 9.6kbit GSM
link), and the box panics within half an hour in kmem_malloc, with devbuf
allocation up to 74MB. It must be either in the Bluetooth code or in the
USB code.
Upon futher looking at the code, I have a better fix for this. Let me
know how things go for you.
--
John-Mark Gurney Voice: +1 415 225 5579
All that I will do, has been done, All that I have, has not.
Index: ng_device.c
===
RCS file: /home/ncvs/src/sys/netgraph/ng_device.c,v
retrieving revision 1.3
diff -u -u -r1.3 ng_device.c
--- ng_device.c 3 Mar 2003 12:15:52 - 1.3
+++ ng_device.c 28 Jul 2003 01:04:31 -
@@ -354,27 +354,13 @@
NGI_GET_M(item, m);
NG_FREE_ITEM(item);
- m = m_pullup(m,m-m_len);
- if(m == NULL) {
- printf(%s(): ERROR: m_pullup failed\n,__func__);
- return(-1);
- }
-
- buffer = malloc(sizeof(char)*m-m_len, M_DEVBUF, M_NOWAIT | M_ZERO);
- if(buffer == NULL) {
- printf(%s(): ERROR: buffer malloc failed\n,__func__);
- return(-1);
- }
-
- buffer = mtod(m,char *);
-
- if( (connection-loc+m-m_len) NGD_QUEUE_SIZE) {
- memcpy(connection-readq+connection-loc, buffer, m-m_len);
- connection-loc += m-m_len;
- } else
+ if( (connection-loc+m-m_len) NGD_QUEUE_SIZE)
+ m_copydata(m, 0, m-m_len, connection-readq+connection-loc);
+ else
+ /* XXX - we really should handle this failure case better */
printf(%s(): queue full, first read out a bit\n,__func__);
- free(buffer,M_DEVBUF);
+ m_freem(m);
return(0);
}
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LiveCD FBSD Current
On Sat, 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 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dereferencing type-punned pointer will break strict-aliasingrules
At Mon, 28 Jul 2003 00:30:35 + (UTC),
kuriyama wrote:
Is this caused by -oS option?
Grrr, of course this should be s/-oS/-Os/.
These warnings are caused from DROP_GIANT() macro. By tracking this
down, actual source is __PCPU_GET() macro (line: 115) in
sys/i386/include/pcpu.h.
__result = *(__pcpu_type(name) *)__i;
To test this with simplified code:
-
% cat test.c
struct T {
int a;
};
void
test()
{
struct T* c;
int __i = 0;
c = *(struct T* *)__i;
}
% cc -c -Os -Wall test.c
test.c: In function `test':
test.c:11: warning: dereferencing type-punned pointer will break strict-aliasing rules
-
__PCPU_GET() macro seems to be harmless if -Os is not used or
__pcpu_type() returns actual type rather than pointer.
What should we do?
--
Jun Kuriyama [EMAIL PROTECTED] // IMG SRC, Inc.
[EMAIL PROTECTED] // FreeBSD Project
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dereferencing type-punned pointer will break strict-aliasingrules
On Mon, Jul 28, 2003 at 10:35:22AM +0900, Jun Kuriyama wrote: At Mon, 28 Jul 2003 00:30:35 + (UTC), kuriyama wrote: Is this caused by -oS option? Grrr, of course this should be s/-oS/-Os/. These warnings are caused from DROP_GIANT() macro. By tracking this down, actual source is __PCPU_GET() macro (line: 115) in sys/i386/include/pcpu.h. __result = *(__pcpu_type(name) *)__i; snip What should we do? I presume you read share/example/make.conf, which states # To compile just the kernel with special optimizations, you should use # this instead of CFLAGS (which is not applicable to kernel builds anyway). # There is very little to gain by using higher optimization levels, and doing # so can cause problems. # #COPTFLAGS= -O -pipe Notice the last 6 words. -- Steve ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dereferencing type-punned pointer will break strict-aliasingrules
On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
Is this caused by -oS option?
- in making BOOTMFS in make release
cc -c -Os -pipe -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/geom/geom_dev.c
/usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
/usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
break strict-aliasing rules
[...]
Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
implementation:
#define __PCPU_GET(name) ({ \
__pcpu_type(name) __result; \
\
[...]
} else if (sizeof(__result) == 4) { \
u_int __i; \
__asm __volatile(movl %%fs:%1,%0 \
: =r (__i)\
: m (*(u_int *)(__pcpu_offset(name; \
__result = *(__pcpu_type(name) *)__i; \
[...]
In this case, the PCPU_GET is used to retrieve curthread, causing
sizeof(__result) to be 4, so the cast at the end of the code snippet
is from a u_int * to struct thread *, and __i is accessed through the
casted pointer, which violates the C99 aliasing rules.
An alternative is to type-pun via a union, which is also a bit ugly,
but explicitly allowed by C99. Patch attached (but only superficially
tested).
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
Index: pcpu.h
===
RCS file: /vol/ncvs/src/sys/i386/include/pcpu.h,v
retrieving revision 1.36
diff -u -r1.36 pcpu.h
--- pcpu.h 27 Jun 2003 21:50:52 - 1.36
+++ pcpu.h 28 Jul 2003 01:37:57 -
@@ -96,23 +96,32 @@
__pcpu_type(name) __result; \
\
if (sizeof(__result) == 1) {\
- u_char __b; \
+ union { \
+ u_char __b; \
+ __pcpu_type(name) __r; \
+ } __u; \
__asm __volatile(movb %%fs:%1,%0 \
- : =r (__b)\
+ : =r (__u.__b)\
: m (*(u_char *)(__pcpu_offset(name; \
- __result = *(__pcpu_type(name) *)__b; \
+ __result = __u.__r; \
} else if (sizeof(__result) == 2) { \
- u_short __w;\
+ union { \
+ u_short __w;\
+ __pcpu_type(name) __r; \
+ } __u; \
__asm __volatile(movw %%fs:%1,%0 \
- : =r (__w)\
+ : =r (__u.__w)\
: m (*(u_short *)(__pcpu_offset(name; \
- __result = *(__pcpu_type(name) *)__w; \
+ __result = __u.__r; \
} else if (sizeof(__result) == 4) { \
- u_int __i; \
+ union { \
+ u_int __i; \
+ __pcpu_type(name) __r; \
+
Re: dereferencing type-punned pointer will break strict-aliasingrules
On Mon, 2003/07/28 at 03:59:00 +0200, Thomas Moestl wrote:
Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
implementation:
#define __PCPU_GET(name) ({ \
__pcpu_type(name) __result; \
\
[...]
} else if (sizeof(__result) == 4) { \
u_int __i; \
__asm __volatile(movl %%fs:%1,%0 \
: =r (__i)\
: m (*(u_int *)(__pcpu_offset(name; \
__result = *(__pcpu_type(name) *)__i; \
[...]
In this case, the PCPU_GET is used to retrieve curthread, causing
sizeof(__result) to be 4, so the cast at the end of the code snippet
is from a u_int * to struct thread *, and __i is accessed through the
^^^ struct thread **, of course.
casted pointer, which violates the C99 aliasing rules.
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
___
[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 22:18:59 -0600, M. Warner Losh wrote: 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. They look related. I've now found the orm output: orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 The last one is the video BIOS. It's interesting to note that it doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this point the 16 kB area is already unmapped. I've worked around the problem by compiling the video BIOS into the X server and not trying to access the BIOS in the machine. Obviously not a solution, but it works for the moment. I'd really like to track down the problem. Does anybody have an idea? 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 22:18:59 -0600, M. Warner Losh wrote: : 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. : : They look related. I've now found the orm output: : : orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 : : The last one is the video BIOS. It's interesting to note that it : doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this : point the 16 kB area is already unmapped. H, The list comes from scanning the ISA HOLE for certain memory signatures. These signatures have a length in them that say I'm a rom that's X long. I don't think that it suggests that things are 'unmapped'... : I've worked around the problem by compiling the video BIOS into the X : server and not trying to access the BIOS in the machine. Obviously : not a solution, but it works for the moment. I'd really like to track : down the problem. Does anybody have an idea? I don't, I'm sorry. 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 Sunday, 27 July 2003 at 21:42:35 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: On Saturday, 26 July 2003 at 22:18:59 -0600, M. Warner Losh wrote: 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. They look related. I've now found the orm output: orm0: Option ROMs at iomem 0xe-0xe3fff,0xdf800-0xd,0xd-0xd17ff,0xc-0xcefff on isa0 The last one is the video BIOS. It's interesting to note that it doesn't report the 4 kB BIOS at 0xcf000, which suggests that at this point the 16 kB area is already unmapped. H, The list comes from scanning the ISA HOLE for certain memory signatures. These signatures have a length in them that say I'm a rom that's X long. Sure. The data at offset 0xc are: C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is the length byte (120 sectors, or 60 kB). That's how orm0 knows the end address. I don't think that it suggests that things are 'unmapped'... If the area between 0xcc000 and 0xc had been mapped, orm0 would have found this too: C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... I've worked around the problem by compiling the video BIOS into the X server and not trying to access the BIOS in the machine. Obviously not a solution, but it works for the moment. I'd really like to track down the problem. Does anybody have an idea? I don't, I'm sorry. Understood. I was hoping that somebody else might have some ideas. 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: : Sure. The data at offset 0xc are: : : C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... : : The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is : the length byte (120 sectors, or 60 kB). That's how orm0 knows the : end address. : : I don't think that it suggests that things are 'unmapped'... : : If the area between 0xcc000 and 0xc had been mapped, orm0 would : have found this too: : : C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... 08 - 4k It could also be that there's a bug in orm that's missing it... 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 Sunday, 27 July 2003 at 22:03:57 -0600, M. Warner Losh wrote: In message: [EMAIL PROTECTED] Greg 'groggy' Lehey [EMAIL PROTECTED] writes: Sure. The data at offset 0xc are: C000: 55 AA 78 E9 44 06 00 00-00 00 00 00 00 00 00 00 U.x.D... The 0xaa55 is the BIOS signature (Here be a BIOS), and the 0x78 is the length byte (120 sectors, or 60 kB). That's how orm0 knows the end address. I don't think that it suggests that things are 'unmapped'... If the area between 0xcc000 and 0xc had been mapped, orm0 would have found this too: C000:F000 55 AA 08 E8 6D 0B CB 11-FE 02 00 00 00 00 00 00 U...m... 08 - 4k Correct. It should have shown a BIOS from 0xcf000 to 0xc It could also be that there's a bug in orm that's missing it... Sure, but given the other indications, that's not so likely. Greg -- See complete headers for address and phone numbers pgp0.pgp Description: PGP signature
Re: Mapping Video BIOS?
Where are you getting the data? A windows tool? 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 Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: Where are you getting the data? A windows tool? If you're talking about the BIOS contents I'm printing, yes, I'm using a Microsoft tool called DEBUG (which has been around since before Microsoft bought DOS :-). 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 Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). I don't suppose that you could use FreeBSD's /dev/mem + od? Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: dereferencing type-punned pointer will break strict-aliasingrules
Hmm, it seems this macro is John's baby. John?
At Mon, 28 Jul 2003 02:00:50 + (UTC),
Thomas Moestl wrote:
[1 text/plain; us-ascii (7bit)]
On Mon, 2003/07/28 at 09:30:08 +0900, Jun Kuriyama wrote:
Is this caused by -oS option?
- in making BOOTMFS in make release
cc -c -Os -pipe -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/geom/geom_dev.c
/usr/src/sys/geom/geom_dev.c: In function `g_dev_open':
/usr/src/sys/geom/geom_dev.c:198: warning: dereferencing type-punned pointer will
break strict-aliasing rules
[...]
Yes, by implying -fstrict-aliasing, so using -fno-strict-aliasing is a
workaround. The problem is caused by the i386 PCPU_GET/PCPU_SET
implementation:
#define __PCPU_GET(name) ({ \
__pcpu_type(name) __result; \
\
[...]
} else if (sizeof(__result) == 4) { \
u_int __i; \
__asm __volatile(movl %%fs:%1,%0 \
: =r (__i)\
: m (*(u_int *)(__pcpu_offset(name; \
__result = *(__pcpu_type(name) *)__i; \
[...]
In this case, the PCPU_GET is used to retrieve curthread, causing
sizeof(__result) to be 4, so the cast at the end of the code snippet
is from a u_int * to struct thread *, and __i is accessed through the
casted pointer, which violates the C99 aliasing rules.
An alternative is to type-pun via a union, which is also a bit ugly,
but explicitly allowed by C99. Patch attached (but only superficially
tested).
- Thomas
--
Thomas Moestl [EMAIL PROTECTED] http://www.tu-bs.de/~y0015675/
[EMAIL PROTECTED] http://people.FreeBSD.org/~tmm/
PGP fingerprint: 1C97 A604 2BD0 E492 51D0 9C0F 1FE6 4F1D 419C 776C
[2 pcpu.diff text/plain; us-ascii (7bit)]
Index: pcpu.h
===
RCS file: /vol/ncvs/src/sys/i386/include/pcpu.h,v
retrieving revision 1.36
diff -u -r1.36 pcpu.h
--- pcpu.h27 Jun 2003 21:50:52 - 1.36
+++ pcpu.h28 Jul 2003 01:37:57 -
@@ -96,23 +96,32 @@
__pcpu_type(name) __result; \
\
if (sizeof(__result) == 1) {\
- u_char __b; \
+ union { \
+ u_char __b; \
+ __pcpu_type(name) __r; \
+ } __u; \
__asm __volatile(movb %%fs:%1,%0 \
- : =r (__b)\
+ : =r (__u.__b)\
: m (*(u_char *)(__pcpu_offset(name; \
- __result = *(__pcpu_type(name) *)__b; \
+ __result = __u.__r; \
} else if (sizeof(__result) == 2) { \
- u_short __w;\
+ union { \
+ u_short __w;\
+ __pcpu_type(name) __r; \
+ } __u; \
__asm __volatile(movw %%fs:%1,%0 \
- : =r (__w)\
+ : =r (__u.__w)\
: m (*(u_short *)(__pcpu_offset(name; \
- __result = *(__pcpu_type(name) *)__w; \
+ __result = __u.__r; \
} else if (sizeof(__result) == 4) { \
- u_int __i; \
+ union {
Re: Mapping Video BIOS?
On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote:
Where are you getting the data? A windows tool?
If you're talking about the BIOS contents I'm printing, yes, I'm using
a Microsoft tool called DEBUG (which has been around since before
Microsoft bought DOS :-).
I don't suppose that you could use FreeBSD's /dev/mem + od?
Yup, can do.
# dd if=/dev/mem bs=64k skip=12 count=1 | hd | less
55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...|
0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB|
...
bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@|
c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ||
*
0001
That's pretty much what I expected. Up to offset bff0, it's identical
with the Microsoft dump.
Greg
--
Finger [EMAIL PROTECTED] for PGP public key
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 Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). : : I don't suppose that you could use FreeBSD's /dev/mem + od? : : Yup, can do. : : # dd if=/dev/mem bs=64k skip=12 count=1 | hd | less : : 55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...| : 0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB| : ... : bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@| : c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || : * : 0001 : : That's pretty much what I expected. Up to offset bff0, it's identical : with the Microsoft dump. Shouldn't you be looking at 0x000c instead of 0xc000? 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 Sunday, 27 July 2003 at 22:32:42 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote:
In message: [EMAIL PROTECTED]
Greg 'groggy' Lehey [EMAIL PROTECTED] writes:
On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote:
Where are you getting the data? A windows tool?
If you're talking about the BIOS contents I'm printing, yes, I'm using
a Microsoft tool called DEBUG (which has been around since before
Microsoft bought DOS :-).
I don't suppose that you could use FreeBSD's /dev/mem + od?
Yup, can do.
dd if=/dev/mem bs=64k skip=12 count=1 | hd | less
55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...|
0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB|
...
bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@|
c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ||
*
0001
That's pretty much what I expected. Up to offset bff0, it's identical
with the Microsoft dump.
Shouldn't you be looking at 0x000c instead of 0xc000?
Yes, I am. Look at the calculations in the dd above: skip 12 blocks
of 64 kB, or 0xc. If you mean the output of Microsoft's DEBUG,
that's in 8086 real mode, segment:offset. The segment registers are
logically shifted 4 bits to the left, so C000: is 0xc.
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 Sunday, 27 July 2003 at 22:32:42 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:17:32 -0600, M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Greg 'groggy' Lehey [EMAIL PROTECTED] writes: : On Sunday, 27 July 2003 at 22:11:29 -0600, M. Warner Losh wrote: : Where are you getting the data? A windows tool? : : If you're talking about the BIOS contents I'm printing, yes, I'm using : a Microsoft tool called DEBUG (which has been around since before : Microsoft bought DOS :-). : : I don't suppose that you could use FreeBSD's /dev/mem + od? : : Yup, can do. : : dd if=/dev/mem bs=64k skip=12 count=1 | hd | less : : 55 aa 78 e9 44 06 00 00 00 00 00 00 00 00 00 00 |U.x.D...| :0010 00 00 00 00 00 00 00 00 68 01 00 00 00 00 49 42 |h.IB| :... :bff0 04 03 80 00 0c 00 00 00 20 00 10 0b 3e 00 02 40 | .@| :c000 ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff ff || :* :0001 : : That's pretty much what I expected. Up to offset bff0, it's identical : with the Microsoft dump. : : Shouldn't you be looking at 0x000c instead of 0xc000? : : Yes, I am. Look at the calculations in the dd above: skip 12 blocks : of 64 kB, or 0xc. If you mean the output of Microsoft's DEBUG, : that's in 8086 real mode, segment:offset. The segment registers are : logically shifted 4 bits to the left, so C000: is 0xc. No, didn't see the skip. Looks like weird things are going on :-( 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-28 04:00:03 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-07-28 04:00:03 - 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-28 04:02:25 - 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-28 05:07:36 - 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 Mon Jul 28 05:07:36 GMT 2003 Kernel build for GENERIC completed on Mon Jul 28 05:19:21 GMT 2003 TB --- 2003-07-28 05:19:21 - 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-28 05:19:21 - 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 Mon Jul 28 05:19:21 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
Recommended kernel config for a dell 8450, 8 cpu, 8GB of ram.
Hi Guys, Just seeking some general information. I've got a couple of dell 8 cpu boxes here running FreeBSD 5.1-RELEASE and am interested in peoples thoughts on the best kernel configs for this type of machine. I'm interested in the best way of making use of 8 cpu's and also seeing the whole 8GB of RAM. Cheers, -- Mark Sergeant [EMAIL PROTECTED] SNSOnline Technical Services ___ [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?
John-Mark Gurney wrote: Lukas Ertl wrote this message on Sun, Jul 27, 2003 at 16:43 +0200: On Sun, 27 Jul 2003, Mark Blackman wrote: Perhaps it's a USB bug. There seems to be some correspondence between the use of the USB Speedtouch ADSL modem and the out-of-control devbuf allocations. I'm too seeing these annoying kmem_malloc panics on recent -current kernels. The laptop I'm using is way off of being overloaded at all, the only thing I do is going online using a Bluetooth USB dongle. As soon as I generate some network traffic, devbuf allocations go up, until at some point the machine panics randomly in kmem_malloc. I must note that the USB changes only allocates memory in the M_USB area which is described by: usb.c:MALLOC_DEFINE(M_USB, USB, USB); So, that means it wouldn't be in the devbuf area. (This is the one of the points of malloc areas is to help track down stray allocations and memory leaks). I have different core dumps and backtraces available, but they don't seem to be of much use in this case. I really suspect the USB stuff to be leaking. It may be leaking, but it won't be leaking devbuf memory. The only thing that is in usb (in dev/usb) that uses M_DEVBUF is ukbd. bus_dma_tag_create() allocates out of M_DEVBUF. Could it be that tags are being created and never destroyed? Scott ___ [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?
Scott Long wrote this message on Sun, Jul 27, 2003 at 23:33 -0600: John-Mark Gurney wrote: It may be leaking, but it won't be leaking devbuf memory. The only thing that is in usb (in dev/usb) that uses M_DEVBUF is ukbd. bus_dma_tag_create() allocates out of M_DEVBUF. Could it be that tags are being created and never destroyed? Ugh, yes, it does. :( What is the point of having malloc areas if everything uses them? I just checked and about every driver allocates memory under DEVBUF. Is there some reason why we don't allocate more malloc types to make this type of thing more easy to debug? -- 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]
