Re: Lucent IBSS mode doesn't work in -CURRENT?
Hi, Are you sure? I believe the Win2k driver is still at the same level as the XP driver - you probably just need to download a newer one.. Correct me if I'm wrong. But I have a Sony Vaio thingie here with Win2k, and I've used that one to upgrade all my cards (Lucent, Orinoco and Avaya labelled - same card, different sticker). Can't recall which firmware version, though. Can I see that from fbsd? /Eirik Oh and btw.. Get the *latest* firmware onto all your cards. That is essential for anything to work right at all.. I'm stuck upgrading because my Windows 2K Lucent driver is too out of date for any of the newer firmware revs. I believe I need at least rev 6.1 of the Win2K driver to run any of the firmware update tools. How did you upgrade your firmware? If anyone has the bits+pieces to rev firmware I'd like it so I can test the wi driver w/ different firmware revs. Sam pgp0.pgp Description: PGP signature
[current tinderbox] failure on i386/i386
TB --- 2003-08-01 06:19:20 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-08-01 06:19:20 - 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-08-01 06:21:23 - 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-08-01 07:26:09 - 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 Fri Aug 1 07:26:10 GMT 2003 [...] awk -f /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/usb/usb_if.m -h awk -f /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/isa/isa_if.m -h awk -f /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/tools/makeobjops.awk /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/pci/agp_if.m -h if [ -f .olddep ]; then mv .olddep .depend; fi rm -f .newdep /home/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/make.i386/make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc -E CC=cc xargs mkdep -a -f .newdep -O -pipe -mcpu=pentiumpro -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/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 -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ff! reestanding /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/dev/ppc/ppc.c:53:28: dev/ppc/ppcvar.h: No such file or directory mkdep: compile failed *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/obj/vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/GENERIC. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src. TB --- 2003-08-01 07:27:22 - /usr/bin/make returned exit code 1 TB --- 2003-08-01 07:27:22 - ERROR: failed to build generic kernel TB --- 2003-08-01 07:27:22 - tinderbox aborted ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [Fwd: cvs commit: src/sys/kern sys_pipe.c]
Alan L. Cox wrote: Kris Kennaway wrote: On Wed, Jul 30, 2003 at 11:15:09PM -0500, Alan L. Cox wrote: I believe that the attached commit addresses the panic: sleeping thread owns a mutex problem reported by Kris and another related problem reported a few days earlier. The earlier problem report included the following stack trace: Great, thanks! Be warned ... I believe that there is still another way for this error to come up in the pipe code. Let me know if it reoccurs. FWIW: Me too. I'd look at it more, but it'd pollute my /tmp with FreeBSD code too similar to the code that I'm currently interested in fixing. 8-). In general, I would encourage people to start filing problem reports for these sorts of things. Always file a PR, if you can, and if the mail server lets you. The amount of work it takes to verify something as a duplicate is nothing, when compared to trying to regain the goodwill of someone shot in the foot by something that was known about but not reported. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Serious 'tr' bug, patch for review included
On Fri, Aug 01, 2003 at 06:12:13AM +0400, Andrey Chernov wrote: On Fri, Aug 01, 2003 at 12:02:04 +1000, Tim Robbins wrote: 8 bits by casting to char. Using charcoll() to sort char arrays may work on little endian machines, but may not on big endian machines. s-set is array of ints, not array of chars. In any case thanx for looking. Sorry, I must be going blind. Tim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fatal trap 12 under RELENG_5_1, anyone who can help?
Hello. My FreeBSD RELENG_5_1 server (cvsupped 4 days ago) seems to have problems - it crashes from time to time (approx. once a day). I've rebuilt the kernel with debug-symbols and enabled the debugger and caught a crash tonight: Here's what I had on screen (I also ran show reg and trace): Fatal trap 12: page fault while in kernel mode fault virtual address = 0x14 fault code = supervisor write, page not present instruction pointer = 0x8:0xc02e8139 stack pointer = 0x10:0xcfbf684c frame pointer = 0x10:0xcfbf6880 code segment= base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, gran 1 processor eflags= interrupt enabled, resume, IOPL = 0 current process = 46373 (ctl_cyrusdb) kernel: type 12 trap, code=0 Stopped at g_dev_strategy+0x29:movl%eax,0x14(%ebx) db show reg cs 0x8 ds0x10 es0x10 fs0x18 ss0x10 eax 0xf7255200 ecx 0 edx 0 ebx 0 esp 0xcfbf684c ebp 0xcfbf6880 esi 0xc201e824 edi 0xc2044900 eip 0xc02e8139 g_dev_strategy+0x29 efl0x10286 dr0 0 dr1 0 dr2 0 dr3 0 dr4 0x0ff0 dr5 0x400 dr6 0x0ff0 dr7 0x400 g_dev_strategy+0x29:movl%eax,0x14(%ebx) db trace g_dev_strategy(c201e824,c2152800,0,cfbf68d0,c2098eca) at g_dev_strategy+0x29 launch_requests(c2e16e80,0,1,,43) at launch_requests+0x448 vinumstart(c5ad9da8,0,c243aab0,cfbf694c,c02e5bc6) at vinumstart+0x2b2 vinumstrategy(c5ad9da8,0,c0b79490,40,0) at vinumstrategy+0xa6 spec_xstrategy(c215b7fc,c5ad9da8,cfbf6968,c02e4f18,cfbf6994) at spec_xstrategy+0x306 spec_specstrategy(cfbf6994,cfbf69b0,c044f7ad,cfbf6994,0) at spec_specstrategy+0x1b spec_vnoperate(cfbf6994,0,c0b79490,f,c5ad9da8) at spec_vnoperate+0x18 ufs_strategy(cfbf69d8,cfbf6a0c,c0359a87,cfbf69d8,1) at ufs_strategy+0xdd ufs_vnoperate(cfbf69d8,1,c0504f45,35e,cfbf69f8) at ufs_vnoperate+0x18 bwrite(c5ad9da8,cfbf6a5c,c0361aca,c5ad9da8,c5ad9ed8) at bwrite+0x3a7 bawrite(c5ad9da8,c5ad9ed8,10,3c6,20020080) at bawrite+0x1c cluster_wbuild(c302c000,4000,4c,0,4) at cluster_wbuild+0x6ba cluster_write(c5afaf08,84cf9c,0,51,c2f82300) at cluster_write+0x571 ffs_write(cfbf6be0,c1fb97f8,c243aab0,227,c2158600) at ffs_wrie+0x5ff vn_write(c1fb97f8,cfbf6c7c,c2f82300,0,c243aab0) at vn_write+0x192 write(c243aab0,cfbf6d10,c0518514,3fb,3) at write+0x69 syscall(2f,2f,2f,0,807e000) at syscall+0x24e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (4, FreeBSD ELF32, write), eip = 0x282e08b3, esp = 0xbfbfec1c, ebp = 0xbfbfec38 --- db I _think_ I've managed to type it all in correctly. No crash dump was made (I have dumpdev=/dev/ad0s1b in /etc/rc.conf) - are there anything else I need to do to get it to crashdump to that device? Should I have given any other commands to the internal debugger to find more information? The kernel I'm running is really GENERIC with a few small changes: vimes# diff VIMES /usr/src/sys/i386/conf/GENERIC 25c25 ident trisha --- ident GENERIC 30c30 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols --- #makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols 62c62 options DDB #Enable the kernel debugger --- #options DDB #Enable the kernel debugger 266,269d265 # This option is a subset of the IPFILTER option. options IPFILTER#ipfilter support options IPFILTER_LOG#ipfilter logging options IPFILTER_DEFAULT_BLOCK #block all packets by default vimes# So, can anyone help me out here? Are there anything else I should have done to find more information? Any other commands to give to the kernel debugger? Any way of making the crashdump happen next time I see a kernel trap like this? -- Eivind Olsen [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/pc98
TB --- 2003-08-01 07:27:23 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-08-01 07:27: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-08-01 07:32:47 - 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-08-01 08:32:45 - 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 Fri Aug 1 08:32:46 GMT 2003 Kernel build for GENERIC completed on Fri Aug 1 08:44:50 GMT 2003 TB --- 2003-08-01 08:44:50 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-01 08:44:50 - 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 Fri Aug 1 08:44:50 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-strict-aliasing -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/kern_thr.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-strict-aliasing -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/kern_kthread.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-strict-aliasing -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/kern_ktr.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c: In function `db_ktr_all': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: `lines' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:270: warning: unused variable
Dummy: PCM causes freezes
Hi!
I got a problem with the pcm driver - on the startup of whatever sound
application by whatever user - root, me, etc it freezes my machine.
I experienced this both on 5.1RElease and 5.1-STABLE(24.07.2003CVSUP). The card
is ESS 1938(SOLO-1) The thing happens over and over again. Here is what I do:
add pcm to the kernel file, make buildinstall{kernel}. Reboot,
build+installworld and on the next reboot start KDE,mpg123,etc and face the music.
I googled and found some info that the needed driver must be loaded in
loader.conf like: `snd_es_1938_load=YES`.
However, even without this, I see my ESS Card attached at pcm0. Can anyone give
hints and help me out bypass this system freeze caused by the pcm?
Attached is my dmesg.boot of my new kernel.
TIA,
Dimitar
dmesg.boot
Description: Binary data
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
bge vlan stranges
Hello! I have Compaq DL360G2 with Broadcom BCM5701 Gigabit Ethernet and FreeBSD 5.1R installed. There are no problems if I use bge as usual network card, but when I try to use 802.1Q vlans, I can't receive (only receive, sending is ok) packets more then 1456 bytes! What is the problem? BGE driver, VLAN driver or my network configuration? Best wishes, Boris ___ [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-08-01 08:51:51 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-01 08:51:51 - 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-08-01 08:55:17 - 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-08-01 10:02:09 - 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 Fri Aug 1 10:02:10 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 -fno-strict-aliasing -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwdev.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 -fno-strict-aliasing -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwdma.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 -fno-strict-aliasing -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwmem.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 -fno-strict-aliasing -mconstant-gp -ffixed-r13 -mfixed-range=f32-f127 -mno-sdata -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/sys/dev/firewire/fwohci.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes
Re: make buildworld: Signal 11; Illegal instruction
On Thu, Jul 31, 2003 at 09:52:08PM +0100, Bruce Cran wrote: On Thu, Jul 31, 2003 at 03:03:01PM -0400, Chris Shenton wrote: Chris Shenton [EMAIL PROTECTED] writes: *** Signal 11 ... Illegal instruction (core dumped) *** Error code 132 Also seeing *** Signal 4 if it matters. This sounds way too flakey to be SW. I'm seeing the same symptoms. I got a signal 4 when running 'clean' in the pam authentication directory, and I've just had a signal 11 running 'rm -f libradius.so'. This is an install from a snapshot I built today - during the install I had panics in _mtx_init_ and a backtrace traced through vfs and ffs functions, and I only managed to install successfully when I had the CPU throttled to 30%. This is the same computer which ran memtest86 for 8 hours without a single fault last night, so I doubt the hardware's faulty, at least not the memory or the CPU. memtest86 does not always catch memory errors. sig11 and sig4 at varying locations during buildworld are a sure indicator for a hardware problem. most likely a memory or overheating issue, though other hardware related causes are possible. if you still are not convinced that this is a hardware issue, run build- world on a -stable system. more and more latest generation laptops from different manufacturers show these symptoms during hot days. my guess is that mobile pentium 4 systems are just not as stable as they should. let's hope things get better with the pentium m chips. are the manufaturers deploy better quality control to catch the numerous faulty systems. ___ [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-08-01 10:06:10 - starting CURRENT tinderbox run for sparc64/sparc64 TB --- 2003-08-01 10:06:10 - 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-08-01 10:08:23 - 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-08-01 11:06:06 - 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 Fri Aug 1 11:06:06 GMT 2003 Kernel build for GENERIC completed on Fri Aug 1 11:15:19 GMT 2003 TB --- 2003-08-01 11:15:19 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/sparc64/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-01 11:15:19 - 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 Fri Aug 1 11:15:19 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-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_thr.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-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_kthread.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-strict-aliasing -fno-builtin -mcmodel=medlow -msoft-float -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c: In function `db_ktr_all': /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: error: `lines' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:273: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/sparc64/sparc64/src/sys/kern/kern_ktr.c:270: warning: unused variable `c' *** Error code 1 Stop in
Re: make buildworld: Signal 11; Illegal instruction
On Fri, Aug 01, 2003 at 01:04:16PM +0200, Tobias Roth wrote: On Thu, Jul 31, 2003 at 09:52:08PM +0100, Bruce Cran wrote: On Thu, Jul 31, 2003 at 03:03:01PM -0400, Chris Shenton wrote: Chris Shenton [EMAIL PROTECTED] writes: *** Signal 11 ... Illegal instruction (core dumped) *** Error code 132 Also seeing *** Signal 4 if it matters. This sounds way too flakey to be SW. I'm seeing the same symptoms. I got a signal 4 when running 'clean' in the pam authentication directory, and I've just had a signal 11 running 'rm -f libradius.so'. This is an install from a snapshot I built today - during the install I had panics in _mtx_init_ and a backtrace traced through vfs and ffs functions, and I only managed to install successfully when I had the CPU throttled to 30%. This is the same computer which ran memtest86 for 8 hours without a single fault last night, so I doubt the hardware's faulty, at least not the memory or the CPU. memtest86 does not always catch memory errors. sig11 and sig4 at varying locations during buildworld are a sure indicator for a hardware problem. most likely a memory or overheating issue, though other hardware related causes are possible. if you still are not convinced that this is a hardware issue, run build- world on a -stable system. more and more latest generation laptops from different manufacturers show these symptoms during hot days. my guess is that mobile pentium 4 systems are just not as stable as they should. let's hope things get better with the pentium m chips. are the manufaturers deploy better quality control to catch the numerous faulty systems. My stock Dell Optiplex GX260, P4 based with 256 MB RAM, running -current, would spit signal 4,10 and 11 (and also 6, don't remember) all over the place during buildworld when not having these kernel options: options DISABLE_PSE options DISABLE_PG_G Search the -current archive, it's due to a processor bug but there is no detailed public information about it and hence no 'official' fix. You might try and see if it helps for you. memtest86 and other hardware testers won't notice anything because it's in the CPU and officially unknown. But yes, also keep in mind that there might be overheating issues if the wheather is hot; yesterday my -stable machine at home rebooted during a port build: turned out to be a flatcable being too close to the CPU fan... Karel. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
Hm. A bit of a stab in the dark, but from sys/dev/bge/if_bge.c, line 3185 (on 5.1 release, 2399) /* Specify MTU. */ CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN); Wonder if this should be /* Specify MTU. */ CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN); Given that bge advertises IFCAP_VLAN_MTU?? ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: make buildworld: Signal 11; Illegal instruction
On Fri, Aug 01, 2003 at 02:41:16PM +0200, Karel J. Bosschaart wrote: On Fri, Aug 01, 2003 at 01:04:16PM +0200, Tobias Roth wrote: On Thu, Jul 31, 2003 at 09:52:08PM +0100, Bruce Cran wrote: On Thu, Jul 31, 2003 at 03:03:01PM -0400, Chris Shenton wrote: Chris Shenton [EMAIL PROTECTED] writes: *** Signal 11 ... Illegal instruction (core dumped) *** Error code 132 Also seeing *** Signal 4 if it matters. This sounds way too flakey to be SW. I'm seeing the same symptoms. I got a signal 4 when running 'clean' in the pam authentication directory, and I've just had a signal 11 running 'rm -f libradius.so'. This is an install from a snapshot I built today - during the install I had panics in _mtx_init_ and a backtrace traced through vfs and ffs functions, and I only managed to install successfully when I had the CPU throttled to 30%. This is the same computer which ran memtest86 for 8 hours without a single fault last night, so I doubt the hardware's faulty, at least not the memory or the CPU. memtest86 does not always catch memory errors. sig11 and sig4 at varying locations during buildworld are a sure indicator for a hardware problem. most likely a memory or overheating issue, though other hardware related causes are possible. if you still are not convinced that this is a hardware issue, run build- world on a -stable system. more and more latest generation laptops from different manufacturers show these symptoms during hot days. my guess is that mobile pentium 4 systems are just not as stable as they should. let's hope things get better with the pentium m chips. are the manufaturers deploy better quality control to catch the numerous faulty systems. My stock Dell Optiplex GX260, P4 based with 256 MB RAM, running -current, would spit signal 4,10 and 11 (and also 6, don't remember) all over the place during buildworld when not having these kernel options: options DISABLE_PSE options DISABLE_PG_G Search the -current archive, it's due to a processor bug but there is no detailed public information about it and hence no 'official' fix. You might try and see if it helps for you. memtest86 and other hardware testers won't notice anything because it's in the CPU and officially unknown. But yes, also keep in mind that there might be overheating issues if the wheather is hot; yesterday my -stable machine at home rebooted during a port build: turned out to be a flatcable being too close to the CPU fan... Karel. Thanks, I'd come to the conclusion it must have been the P4 bug. The system gets hot, sometimes 65 deg C during builds, but it very rarely aborts on a signal 11. I don't quite understand what happened yesterday to break it so badly, maybe it was because I was newly installing a -CURRENT snapshot I'd built with pentium2 optimisations, but I don't know. -- Bruce Cran ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000
Kris Kennaway writes: On Thu, Jul 31, 2003 at 01:48:59AM -0700, Kris Kennaway wrote: I upgraded the alpha package machines tonight, and one of them fell over shortly after taking load, with the following: .. Two more panics on alpha: panic: vm_fault: fault on nofault entry, addr: fe0007fde000 Debugger() at Debugger+0x38 panic() at panic+0x168 vm_fault() at vm_fault+0x1360 trap() at trap+0x5c8 XentMM() at XentMM+0x2c --- memory management fault (from ipl 0) --- bcopy_samealign_lp() at bcopy_samealign_lp+0x8 copyout() at copyout+0x38 uiomove() at uiomove+0x19c pipe_read() at pipe_read+0x290 dofileread() at dofileread+0x100 read() at read+0x64 syscall() at syscall+0x33c XentSys() at XentSys+0x64 --- syscall (3, FreeBSD ELF64, read) --- --- user mode --- The crashdump might actually be useful here. You'd have only the trap() and vm_fault() frames, but at least you'd have information about the state of the vm system. I updated a UP alpha here at roughly the same time. I was able to do a buildworld with the new kernel from sources dated July 30, around noon PDT. Is this GENERIC or an otherwise SMP kernel? Just for the heck of it, edit GENERIC and get rid of the SMP option if its a UP box. That's what I always run and I'm curious if that might be your stability problem. Drew ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000
On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote: The crashdump might actually be useful here. You'd have only the trap() and vm_fault() frames, but at least you'd have information about the state of the vm system. Two crashdumps coming up! I'll move them onto beast:/j/kris/crash together with the kernel.debug. I updated a UP alpha here at roughly the same time. I was able to do a buildworld with the new kernel from sources dated July 30, around noon PDT. The problems I'm seeing are only intermittent (about a dozen spurious port build failures over 27 hours of package building on 9 machines, plus 3 VM panics), but they're definitely ongoing. Is this GENERIC or an otherwise SMP kernel? Just for the heck of it, edit GENERIC and get rid of the SMP option if its a UP box. That's what I always run and I'm curious if that might be your stability problem. It's a UP kernel. Kris pgp0.pgp Description: PGP signature
5.2-RELEASE TODO
This is an automated bi-weekly mailing of the FreeBSD 5.2 open issues list. The live version of this list is available at: http://www.FreeBSD.org/releases/5.2R/todo.html Automated mailing of this list will continue through the release of FreeBSD 5.2. FreeBSD 5.2 Open Issues Open Issues This is a list of open issues that need to be resolved for FreeBSD 5.2. If you have any updates for this list, please e-mail [EMAIL PROTECTED] Must Resolve Issues for 5.2-RELEASE ++ |Issue| Status | Responsible | Description | |-+--+-+-| | | | | KSE M:N threading | | | | | support is reaching | | | | | experimental yet| | | | Julian | usable status on| | Production-quality | In | Elischer, David | i386 for| | M:N threading | progress | Xu, Daniel | 5.1-RELEASE. M:N| | | | Eischen | threading should be | | | | | productionable and | | | | | usable on all | | | | | platforms by| | | | | 5.2-RELEASE.| |-+--+-+-| | | | | Currently, the MD | | | | | elements of KSE are | | | | | present only for| | | | | the i386 platform, | | | | | limiting use of KSE | | | | | to the i386 | | | | | platform. It is | | | | | highly desirable to | | KSE support for | | Jake| make KSE available | | sparc64, alpha, | -- | Burkholder, --, | on non-i386 | | ia64| | -- | platforms for | | | | | 5.2-RELEASE so that | | | | | KSE can see more| | | | | broad exposure, and | | | | | the performance | | | | | benefits of KSE can | | | | | be visible to users | | | | | of the 64-bit | | | | | FreeBSD | | | | | architectures. | |-+--+-+-| | | | | Kris Kennaway | | | | | reports high| | | | | instability of | | | | | 5-CURRENT on ia64 | | | In | Marcel | machines, such as | | ia64 stability | Progress | Moolenaar | the pluto* | | | | | machines. These | | | | | problems need to be | | | | | fixed in order to | | | | | get a successful| | | | | package build. | |-+--+-+-| | | | | ia64 serial console | | | | | support is reported | | | | | to not be | | | | | functional on HP| | | In | Marcel | Itanium2 platforms. | | ia64 sio support| progress | Moolenaar, | A reworking of the | | | | Warner Losh | sio driver to | | | | | improve platform| | | | | independence and| | | | | bus handling is | | | |
SOLVED (Was: Problem with AHC driver.)
On Friday 25 July 2003 10:33, Adam Kranzel wrote: On Friday 25 July 2003 10:08, Scott Long wrote: snip lots Okay, I've got a new kernel working now. It seems it was a combination of a messed-up /boot/device.hints file (I'd not updated it in a long time), and the BIOS assigning IRQ 15 to the AHC card, which it didn't seem to like. I copied over GENERIC.hints (and added a couple things), and messed around to give the card a different IRQ, and all seems to be working fine now. Thanks to all the developers for making such a great OS. -Adam ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000
Kris Kennaway writes:
On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
The crashdump might actually be useful here. You'd have only the
trap() and vm_fault() frames, but at least you'd have information
about the state of the vm system.
Two crashdumps coming up! I'll move them onto beast:/j/kris/crash
together with the kernel.debug.
I may have wasted your time. The first one is unusable (lots of ddb
cruft). Damned gdb -k. Grrr.
I don't have read perms on vmcore.{1,2}, so I don't know if they are
helpful.
If you're willing to get your traces via ddb's debug.trace_on_panic
and to set debug.debugger_on_panic=0, then we might get at least a
partial trace. FWIW, I have to do this to get any sort of crashdump
at all on SMP x86. I'm amazed you were able to call doadump from ddb.
When I try that on x86, I just get a continuous stream of panics or
fatal traps.
Drew
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
spin lock sched lock held for 5 seconds
Hi, got the following panic overnight running with all debugging options on (WITNESS, MUTEX_DEBUG, DIAGNOSTIC, INVARIANTS; WITNESS_SKIPSPIN off): panic: spin lock sched lock held by 0xc658e130 for 5 seconds cpuid = 0; lapic.id = Stack backtrace: backtrace(c031d030,0,c031c4c5,df0dab8c,100) at backtrace+0x17 panic(c031c4c5,c031c62e,c658e130,c036f160,18b) at panic+0x13d _mtx_lock_spin(c036f160,2,c031a229,18b,c21b2ab0) at _mtx_lock_spin+0x83 _mtx_lock_spin_flags(c036f160,2,c031a229,18b,df0dac0c) at _mtx_lock_spin_flags+0xb9 statclock(df0dac00,df0dac44,c02d8a9c,0,c2198d00) at statclock+0x39 rtcintr(0) at rtcintr+0x4f Xfastunpend8(df0dacb8,c02d1f05,8,608,c0372e60) at Xfastunpend8+0x1c call_fast_unpend(8,608,c0372e60,ffc00034,0) at call_fast_unpend+0xd i386_unpend(c036f160,c21b0790,df0dacd0,c01b1ae0,df0dacec) at i386_unpend+0x8d cpu_unpend(df0dacec,c01a2534,c036f160,1,c031c2e2) at cpu_unpend+0x2d critical_exit(c036f160,1,c031c2e2,1bc,1) at critical_exit+0x2d _mtx_unlock_spin_flags(c036f160,0,c031ac9f,7c,c21b2ab0) at _mtx_unlock_spin_flags+0xbb idle_proc(0,df0dad48,c031ab89,312,c21b2ab0) at idle_proc+0xb0 fork_exit(c0199972,0,df0dad48) at fork_exit+0xc3 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0dad7c, ebp = 0 --- Debugger(panic) timeout stopping cpus Stopped at Debugger+0x4f: xchgl %ebx,in_Debugger.0 db The machine is still in ddb, let me know if I can provide additional info. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: vm/map LOR
fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock needs to be dropped before allocating or freeing to that zone. What does Alan think? (cc'd) -Bosko On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote: Hi, with yesterday's -current: 1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323 Stack backtrace: backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at vm_object_terminate+0x1e5 vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at vm_object_deallocate+0x35e vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at vm_map_entry_delete+0x3c vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at vm_map_delete+0x3c3 vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e syscall(2f,2f,2f,f8000,1000) at syscall+0x260 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute -- 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: vm/map LOR
Try the attached patch. On Fri, Aug 01, 2003 at 11:02:49AM +, Bosko Milekic wrote: fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock needs to be dropped before allocating or freeing to that zone. What does Alan think? (cc'd) -Bosko On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote: Hi, with yesterday's -current: 1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323 Stack backtrace: backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at vm_object_terminate+0x1e5 vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at vm_object_deallocate+0x35e vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at vm_map_entry_delete+0x3c vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at vm_map_delete+0x3c3 vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e syscall(2f,2f,2f,f8000,1000) at syscall+0x260 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute -- 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] -- Bosko Milekic * [EMAIL PROTECTED] * [EMAIL PROTECTED] TECHNOkRATIS Consulting Services * http://www.technokratis.com/ diff -ru vm.old/device_pager.c vm/device_pager.c --- vm.old/device_pager.c Fri Aug 1 11:20:26 2003 +++ vm/device_pager.c Fri Aug 1 11:36:03 2003 @@ -96,7 +96,7 @@ sx_init(dev_pager_sx, dev_pager create); mtx_init(dev_pager_mtx, dev_pager list, NULL, MTX_DEF); fakepg_zone = uma_zcreate(DP fakepg, sizeof(struct vm_page), - NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_NOFREE); + NULL, NULL, NULL, NULL, UMA_ALIGN_PTR, UMA_ZONE_VM|UMA_ZONE_NOFREE); } /* ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
ports/news/newscache gives sig11 on recent -CURRENT
ports/news/newscache now gives me a sig11. It didn't a few weeks ago but I really can't pin it down any closer than that. I thought it may have been related to the new gcc import but I'm not able to check that. After it gave me the sig11 I recompiled it and its dependancies and that didn't fix anything. I'm running -CURRENT as of 7/31/03. I have the following in /etc/syslog.conf: news.* /var/log/news.log I see this in /var/log/news.log: Aug 1 10:36:06 energistic NewsCache[75426]: NewsCache Server Start Aug 1 10:36:38 energistic NewsCache[97305]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] connect Aug 1 10:36:38 energistic NewsCache[97305]: NServer::NServer() hostname set to: energistic.com Aug 1 10:36:38 energistic NewsCache[97305]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] MODE READER Aug 1 10:36:38 energistic NewsCache[97305]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] NEWGROUPS 030519 214720 Aug 1 10:36:38 energistic NewsCache[97305]: active database timed out Aug 1 10:36:38 energistic NewsCache[97305]: RServer::issue: issue list active * Aug 1 10:36:38 energistic NewsCache[75426]: 97305 caught signal 11 Aug 1 10:36:41 energistic NewsCache[68550]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] connect Aug 1 10:36:41 energistic NewsCache[68550]: NServer::NServer() hostname set to: energistic.com Aug 1 10:36:41 energistic NewsCache[68550]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] MODE READER Aug 1 10:36:41 energistic NewsCache[68550]: bdsl.66.12.217.43.gte.net [66.12.21 7.43] GROUP alt.martial-arts.tae-kwon-do Aug 1 10:36:41 energistic NewsCache[68550]: RServer::issue: issue group alt.mar tial-arts.tae-kwon-do Aug 1 10:36:41 energistic NewsCache[75426]: 68550 caught signal 11 I couldn't find a debug option to force 'newscache' to deliver more interesting information... -Steve ___ [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-08-01 16:00:06 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-08-01 16:00:06 - 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-08-01 16:02:33 - 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-08-01 17:08:28 - 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 Fri Aug 1 17:08:28 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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdev.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdma.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwmem.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwohci.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 -g -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
Re: bge vlan stranges
In article [EMAIL PROTECTED], Peter Edwards [EMAIL PROTECTED] wrote: Hm. A bit of a stab in the dark, but from sys/dev/bge/if_bge.c, line 3185 (on 5.1 release, 2399) /* Specify MTU. */ CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN); Wonder if this should be /* Specify MTU. */ CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN); Given that bge advertises IFCAP_VLAN_MTU?? Good guess, but the approved way of doing it is to add this code near the point where IFCAP_VLAN_MTU is set: ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); See sys/dev/fxp/if_fxp.c for an example that works. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
John Polstra [EMAIL PROTECTED] wrote: Peter Edwards [EMAIL PROTECTED] wrote: CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN); Good guess, but the approved way of doing it is to add this code near the point where IFCAP_VLAN_MTU is set: ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); See sys/dev/fxp/if_fxp.c for an example that works. Sorry for being obtuse, but just to clarify: fxp just seems to have an allow long frames flag, rather than a max frame size register in the hardware, so you never seem to have to tell the hardware the max size of a frame it needs to accept. I assume you mean, that after setting if_hdrlen, you still need to write to the PCI register, like this: CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ifp-if_hdrlen + ETHER_CRC_LEN); I don't have a bge device, so I can't muck about with it to try. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
In article [EMAIL PROTECTED], Peter Edwards [EMAIL PROTECTED] wrote: John Polstra [EMAIL PROTECTED] wrote: Peter Edwards [EMAIL PROTECTED] wrote: CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ETHER_HDR_LEN + ETHER_CRC_LEN + ETHER_VLAN_ENCAP_LEN); Good guess, but the approved way of doing it is to add this code near the point where IFCAP_VLAN_MTU is set: ifp-if_data.ifi_hdrlen = sizeof(struct ether_vlan_header); See sys/dev/fxp/if_fxp.c for an example that works. Sorry for being obtuse, but just to clarify: No, you are right. I didn't read the posting carefully enough. Sorry! fxp just seems to have an allow long frames flag, rather than a max frame size register in the hardware, so you never seem to have to tell the hardware the max size of a frame it needs to accept. I assume you mean, that after setting if_hdrlen, you still need to write to the PCI register, like this: CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ifp-if_hdrlen + ETHER_CRC_LEN); Yes, you probably do have to do that. I think you also have to set if_data.ifi_hdrlen as I said, or the MTU as understood by the rest of the system will come out 4 bytes too short. But I'm just speaking from memory without any actual experiments to back up what I'm saying. :-} Thanks for the correction! John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
John Polstra [EMAIL PROTECTED] wrote: No, you are right. I didn't read the posting carefully enough. Sorry! No problem. [snip] I assume you mean, that after setting if_hdrlen, [snip] I think you also have to set if_data.ifi_hdrlen as I said [snip] My fault: I jumped from one term for the same thing to the other without explanation. if_hdrlen is a macro for if_data.ifi_hdrlen. I'm not a big fan of hiding those kind of details with macros, but I assume they're defined by smarter people than me in order that they be used :-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge vlan stranges
In article [EMAIL PROTECTED], Peter Edwards [EMAIL PROTECTED] wrote: John Polstra [EMAIL PROTECTED] wrote: [snip] I assume you mean, that after setting if_hdrlen, [snip] I think you also have to set if_data.ifi_hdrlen as I said [snip] My fault: I jumped from one term for the same thing to the other without explanation. if_hdrlen is a macro for if_data.ifi_hdrlen. Understood. I was just trying to make the point that you have to set that in addition to setting the MTU register in the hardware. I'm not a big fan of hiding those kind of details with macros, but I assume they're defined by smarter people than me in order that they be used :-) I don't know why the fxp driver doesn't use the macro. Maybe the macro didn't exist yet when that code was added. John -- John Polstra John D. Polstra Co., Inc.Seattle, Washington USA Two buttocks cannot avoid friction. -- Malawi saying ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: vm/map LOR
Bosko Milekic wrote: fakepg_zone should probably be UMA_ZONE_VM. Or the vm_object lock needs to be dropped before allocating or freeing to that zone. What does Alan think? (cc'd) Perhaps. Regardless, in this case, the lock-order reversal is a false positive. What it shows is the locking of a user-level vm map, followed by vm_object #1, followed by the kmem_map. If this had proceeded to conclusion, you would have seen the locking of vm_object #2, the kmem_object. So, to witness this appears as a lock-order reversal. Unless vm_object #1 and vm_object #2 are the same, there is no possibility of deadlock. Witness is simply unable to distinguish the two vm objects because they have the same label. If they were given unique labels, witness would be overwhelmed because there are simply too many vm objects. Regards, Alan On Thu, Jul 31, 2003 at 04:46:06PM -0700, Lars Eggert wrote: Hi, with yesterday's -current: 1st 0xc6dfd094 vm object (vm object) @ /usr/src/sys/vm/vm_object.c:434 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:323 Stack backtrace: backtrace(c032000b,c082f110,c033362f,c033362f,c03334c6) at backtrace+0x17 witness_lock(c082f110,8,c03334c6,143,c082f0b0) at witness_lock+0x686 _mtx_lock_flags(c082f110,0,c03334c6,143,101) at _mtx_lock_flags+0xb5 _vm_map_lock(c082f0b0,c03334c6,143,c0374778,c03747a0) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,eb44db14,c02b0433) at kmem_malloc+0x3a page_alloc(c083a240,1000,eb44db07,101,0) at page_alloc+0x27 slab_zalloc(c083a240,101,c083a254,8,c0334e1e) at slab_zalloc+0xc2 uma_zone_slab(c083a240,101,c0334e1e,663,165) at uma_zone_slab+0xd9 uma_zalloc_internal(c083a240,0,101,6e7,0) at uma_zalloc_internal+0x4f uma_zfree_arg(c083a900,c6e31000,0,eb44dbc4,c029884d) at uma_zfree_arg+0x2a6 dev_pager_putfake(c6e31000,0,c0332b9e,be,c6dfd094) at dev_pager_putfake+0x35 dev_pager_dealloc(c6dfd094,1,c0334dcf,10c,0) at dev_pager_dealloc+0xb9 vm_pager_deallocate(c6dfd094,0,c0333f6c,261,1b2) at vm_pager_deallocate+0x3d vm_object_terminate(c6dfd094,0,c0333f6c,1b2,c6b894ec) at vm_object_terminate+0x1e5 vm_object_deallocate(c6dfd094,c082bd20,c6dfd094,c082bd20,eb44dca0) at vm_object_deallocate+0x35e vm_map_entry_delete(c6593e00,c082bd20,c033369d,897,c019f843) at vm_map_entry_delete+0x3c vm_map_delete(c6593e00,282e2000,282e3000,1000,282e2000) at vm_map_delete+0x3c3 vm_map_remove(c6593e00,282e2000,282e3000,0,c6b8a618) at vm_map_remove+0x55 munmap(c6ae24c0,eb44dd14,c0339293,3ee,2) at munmap+0x9e syscall(2f,2f,2f,f8000,1000) at syscall+0x260 Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (73), eip = 0x28257aa7, esp = 0xbfbffc1c, ebp = 0xbfbffc48 --- Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute -- 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: bge vlan stranges
Ok. After all that, and given I've gone this far... Boris, does the patch included fix your problem? -- Peter Edwards. Index: sys/dev/bge/if_bge.c === RCS file: /pub/FreeBSD/development/FreeBSD-CVS/src/sys/dev/bge/if_bge.c,v retrieving revision 1.46 diff -u -r1.46 if_bge.c --- sys/dev/bge/if_bge.c25 Jul 2003 20:33:43 - 1.46 +++ sys/dev/bge/if_bge.c1 Aug 2003 18:33:56 - @@ -2356,6 +2356,7 @@ ifp-if_watchdog = bge_watchdog; ifp-if_init = bge_init; ifp-if_mtu = ETHERMTU; + ifp-if_hdrlen = sizeof(struct ether_vlan_header); ifp-if_snd.ifq_maxlen = BGE_TX_RING_CNT - 1; ifp-if_hwassist = BGE_CSUM_FEATURES; ifp-if_capabilities = IFCAP_HWCSUM | IFCAP_VLAN_HWTAGGING | @@ -3181,8 +3182,8 @@ ifp = sc-arpcom.ac_if; /* Specify MTU. */ - CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + - ETHER_HDR_LEN + ETHER_CRC_LEN); + CSR_WRITE_4(sc, BGE_RX_MTU, ifp-if_mtu + ifp-if_hdrlen + + ETHER_CRC_LEN); /* Load our MAC address. */ m = (u_int16_t *)sc-arpcom.ac_enaddr[0];___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Crash during login on CURRENT system
CURRENT system on an IBM T30 crashed in login Since it was on my laptop, I need to hand-type this, so I hope to not make any errors. I doubt that I can repeat it. Fatal trap 12: page fault while in kernel mode Fault virtual address = 0x304 fault code= supervisor read, page not present instruction pointer = 0x8:0xc033a1f0 stack pointer = 0x10:0xdbb519cc frame pointer = 0x10:0xdbb51a14 code segment = base 0x0, limit 0xf, type 0x1b = DPL 0, pres 1, def32 1, rean 1 processor eflags = interrupt enabled, resume, IOPL = 0 current process = 612 (login) kernel: type 12 trap, code=0 Stopped at ufsdirhash_lookup+0x2e0: movl 0(%eax,%edx,4),%ebx db tr ufsdirhash_lookup(c4858360,c41cc81a,e,c48583b0,ddb51a7c) at ufsdirhash_lookup+0x2e0 ufs_lookup(ddb51b3c,dbb51c78,c029bb81,ddb51b3c,ddb51c74) at ufs_lookup+0x1fb ufs_vnoperate(ddb51b3c,ddb51c74,ddb51c88,c4844db0,c41a9390) at ufs_vnoperate+0x18 vfs_cache_lookup(dbb51bbc,dbb51bd8,c02a0e83,dbb51bbc,c41a9390) at vfs_cache_lookup+0x301 ufs_vnoperate(dbb51bbc,c41a9390,0,c41a9390,c41a9390) at ufs_vnoperate+0x18 lookup(dbb516c0,c41cc800,400,dbb51c7c,c41a9390) at lookup+0x302 namei(dbb51c60,c483e5d8,c41a9390,60,c41a9390) at namei+0x20b kern_access(c41a9390,28072000,0,0,dbb51d40) at kern_access+0x56 access(c41a9390,dbb51d10,8,c,2) at access+0x29 syscall(2f,2f,bfbf002f,bfbff5e0,28072000) at syscall_0x2b0 Xint0x80_syscall() at Xint0x80_syscall+0x1d ---syscall (33, FreeBSD ELF32, access), eip = 0x28055647, esp = 0xbfbff57c, ebp = 0xbfbff5898 --- -- R. Kevin Oberman, Network Engineer Energy Sciences Network (ESnet) Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
crash when bringing up fddi interface
I added a DEC DEFPA PCI FDDI card to my Alpha.
When ifconfig fpa0 foo I am greeted by the following
panic:
fatal kernel trap:
trap entry = 0x2 (memory management fault)
cpuid = 2
faulting va= 0x53c443f891b8
type = access violation
cause = load instructon
pc = 0xfc4addc8
ra = 0xfc4ad3ac
sp = 0xfe0039dfd970
usp= 0x11fffa70
curthread = 0xfc0006acba20
pid = 571, comm = ifconfig
Stopped at rt_maskedcopy+0x18: ldq_u t0,0(a2)
0x53c443f891b8
t0=0x0,a2=0x53c443f891b8
db tb
No such command
db bt
No such command
db tsa^H ^H^H ^Hrace
rt_maskedcopy() at rt_maskedcopy+0x18
rtrequest1() at rtrequest1+0x39c
rtinit() at rtinit+0x250
in_ifinit() at in_ifinit+0x6d4
in_control() at in_control+0x918
ifioctl() at ifioctl+0x2b4
soo_ioctl() at soo_ioctl+0x290
ioctl() at ioctl+0x750
syscall() at syscall+0x3b8
XentSys() at XentSys+0x64
--- syscall (54, FreeBSD ELF64, ioctl) ---
--- user mode ---
db
So, something appears to go wrong in:
static void
rt_maskedcopy(src, dst, netmask)
struct sockaddr *src, *dst, *netmask;
{
register u_char *cp1 = (u_char *)src;
register u_char *cp2 = (u_char *)dst;
register u_char *cp3 = (u_char *)netmask;
u_char *cplim = cp2 + *cp3;
u_char *cplim2 = cp2 + *cp1;
*cp2++ = *cp1++; *cp2++ = *cp1++; /* copies sa_len sa_family */
cp3 += 2;
if (cplim cplim2)
cplim = cplim2;
while (cp2 cplim)
*cp2++ = *cp1++ *cp3++;
if (cp2 cplim2)
bzero((caddr_t)cp2, (unsigned)(cplim2 - cp2));
}
My other DEFPA lives in a BP6 x86 box and is not panicing.
Suggestions?
W/
--
| / o / /_ _ [EMAIL PROTECTED]
|/|/ / / /( (_) Bulte
___
[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-08-01 18:20:30 - starting CURRENT tinderbox run for i386/i386 TB --- 2003-08-01 18:20:30 - 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-08-01 18:22:46 - 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-08-01 19:22:39 - 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 Fri Aug 1 19:22:39 GMT 2003 Kernel build for GENERIC completed on Fri Aug 1 19:37:04 GMT 2003 TB --- 2003-08-01 19:37:04 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/i386/src/sys/i386/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-01 19:37:04 - 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 Fri Aug 1 19:37:04 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-strict-aliasing -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/kern_thr.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-strict-aliasing -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/kern_kthread.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-strict-aliasing -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/kern_ktr.c /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c: In function `db_ktr_all': /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: `lines' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:273: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/i386/i386/src/sys/kern/kern_ktr.c:270: warning: unused variable `c' ***
sil3112 controller
Just saw the support for the controller go in. Does the driver support any RAID1 style mirroring? Pete ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
Hi, after upgrading the Kernel I found that the glx-related programs of the NVidia graphics driver die in calls to sysarch. Here is a truss fragment of a 'glxinfo' run: sysarch(0x1,0xbfbffb14) ERR#22 'Invalid argument' SIGNAL 10 SIGNAL 10 Process stopped because of: 16 process exit, rval = 138 In the sysarch call the first argument indicats - according to machine/sysarch.h - a call of I386_SET_LDT. For 4.X it was necessary to enable USER_LDT in the kernel config. This option is no longer present in the kernel config (the NVidia driver worked without before my cvs update...). Best regards -Thorsten -- For every complex problem, there is a solution that is simple, neat, and wrong. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge driver not recognising BCM 5705M
I'm somewhat confused.
So am I: where were you when I asked sent e-mail to this list asking
for people to test the 5705 changes before I committed them?
On a recent 5.1-CURRENT, boot -v gives me:
Actually, boot -v gives you much more, like the date when the kernel
image was compiled. Too bad you decided not to show everything to us.
found- vendor=0x14e4, dev=0x165d, revid=0x01
bus=2, slot=0, func=0
class=02-00-00, hdrtype=0x00, mfdev=0
cmdreg=0x0116, statreg=0x02b0, cachelnsz=8 (dwords)
lattimer=0x20 (960 ns), mingnt=0x40 (16000 ns), maxlat=0x00 (0 ns)
intpin=a, irq=11
powerspec 2 supports D0 D3 current D0
followed by:
pci2: network, ethernet at device 0.0 (no driver attached)
This is the internal Gigabit ethernet on my Dell D800 laptop... but
it's not recognised, even though...
static struct bge_type bge_devs[] = {
...
{ BCOM_VENDORID, BCOM_DEVICEID_BCM5705,
Broadcom BCM5705 Gigabit Ethernet },
...
};
and ...
#define BCOM_VENDORID 0x14E4
#define BCOM_DEVICEID_BCM5705M 0x165D
... so why doesn't the bge driver kick in?
You'll need to investigate this one for yourself. Make *SURE* you booted
from the right kernel image (strings -a /boot/kernel/kernel | grep 5705).
A good way to experiment is compile your kernel _WITHOUT_ bge support,
and then build if_bge.ko as a module:
# cd /sys/modules/bge
# make; make load
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
If stupidity were a handicap, you'd have the best parking spot.
=
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: sil3112 controller
It seems Petri Helenius wrote: Just saw the support for the controller go in. Does the driver support any RAID1 style mirroring? Only our own ATA RAID (see atacontrol).. I do have an Adaptec 1210 that has RAID capabilities and I have deciphered their RAID config info, but support is not finished yet. -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: bge driver not recognising BCM 5705M
Bill == Bill Paul [EMAIL PROTECTED] writes: I'm somewhat confused. Bill So am I: where were you when I asked sent e-mail to this list Bill asking for people to test the 5705 changes before I committed Bill them? I very well might not have had this machine. When did you commit them? On a recent 5.1-CURRENT, boot -v gives me: Bill Actually, boot -v gives you much more, like the date when the Bill kernel image was compiled. Too bad you decided not to show Bill everything to us. I didn't want to spam, but my recent current is: FreeBSD canoe.velocet.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Jul 15 17:54:29 EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CANOE i386 Bill You'll need to investigate this one for yourself. Make *SURE* Bill you booted from the right kernel image (strings -a Bill /boot/kernel/kernel | grep 5705). A good way to experiment is Bill compile your kernel _WITHOUT_ bge support, and then build Bill if_bge.ko as a module: Bill # cd /sys/modules/bge # make; make load I will do that presently. Dave. -- |David Gilbert, Independent Contractor. | Two things can only be | |Mail: [EMAIL PROTECTED]| equal if and only if they | |http://daveg.ca | are precisely opposite. | =GLO ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Thorsten Greiner wrote: Hi, after upgrading the Kernel I found that the glx-related programs of the NVidia graphics driver die in calls to sysarch. Here is a truss fragment of a 'glxinfo' run: sysarch(0x1,0xbfbffb14)ERR#22 'Invalid argument' SIGNAL 10 SIGNAL 10 Process stopped because of: 16 process exit, rval = 138 In the sysarch call the first argument indicats - according to machine/sysarch.h - a call of I386_SET_LDT. For 4.X it was necessary to enable USER_LDT in the kernel config. This option is no longer present in the kernel config (the NVidia driver worked without before my cvs update...). Hmmm, well I know we changed the semantics of the I386_SET_LDT call a bit but as far as I could see it was a backwards compatible change.. can you compile your sys_machdep.c with the option -DDEBUG? I noticed there is a debug printf that is enabled byu this and may show what request the NVIDIA people are making. Best regards -Thorsten -- For every complex problem, there is a solution that is simple, neat, and wrong. ___ [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: bge driver not recognising BCM 5705M
Bill == Bill Paul [EMAIL PROTECTED] writes:
I'm somewhat confused.
Bill So am I: where were you when I asked sent e-mail to this list
Bill asking for people to test the 5705 changes before I committed
Bill them?
I very well might not have had this machine. When did you commit
them?
On a recent 5.1-CURRENT, boot -v gives me:
Bill Actually, boot -v gives you much more, like the date when the
Bill kernel image was compiled. Too bad you decided not to show
Bill everything to us.
I didn't want to spam,
*sigh* No. Spam is when you try to sell me viagra or bestiality porn.
Providing detailed problem reports is not spam. It saves me from having
to _ask_ you for more information, thereby prolonging what might otherwise
be a simple one shot exchange. It also can save time and wear and tear
on developers, since, in the process of collecting detailed information,
you might stumble upon possible solutions to your problem on your own,
to wit:
...but my recent current is:
FreeBSD canoe.velocet.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue Jul 15 17:54:29
EDT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/CANOE i386
[/u/wpaul/xl/src/sys/dev/bge]:zim.wrs.com{58}% cvs log if_bge.c
[...]
revision 1.44
date: 2003/07/16 00:09:56; author: wpaul; state: Exp; lines: +226 -103
^^
Add support for the BCM5705 and its ilk. Changes:
- 5705 doesn't support jumbo frames
- Statistics must be read from registers
- RX return ring must be capped at 512 entries
- Omit initialization of certain device blocks
- Acknowledge link change interrupts by setting the 'link changed'
bit in the status register (used to have no effect)
- Remember to toggle the MI completion bit too
- Set the mbuf low watermark differently (on-chip memory buffers,
not BSD mbufs)
- Don't enable [EMAIL PROTECTED] feature for certain 5705 chip revs
- Add additional PCI IDs for 5705 and 5782 parts
- Add a forgotten 5704 PCI ID
Most changes ripped kicking and screaming from the Broadcom linux driver.
Thanks to Paul Saab for sanity testing. (My lack of sanity has been
confirmed.)
Your kernel image on July 15th. The changes were committed on July 16th.
You missed by one day.
-Bill
--
=
-Bill Paul(510) 749-2329 | Senior Engineer, Master of Unix-Fu
[EMAIL PROTECTED] | Wind River Systems
=
If stupidity were a handicap, you'd have the best parking spot.
=
___
[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-08-01 19:45:47 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-08-01 19:45:47 - 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-08-01 19:48:16 - 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-08-01 20:48:19 - 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 Fri Aug 1 20:48:20 GMT 2003 Kernel build for GENERIC completed on Fri Aug 1 21:00:19 GMT 2003 TB --- 2003-08-01 21:00:19 - generating LINT kernel config TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/conf TB --- /usr/bin/make -B LINT TB --- 2003-08-01 21:00:19 - 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 Fri Aug 1 21:00:19 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-strict-aliasing -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/kern_thr.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-strict-aliasing -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/kern_kthread.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-strict-aliasing -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/kern_ktr.c /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c: In function `db_ktr_all': /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: `lines' undeclared (first use in this function) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: (Each undeclared identifier is reported only once /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:273: error: for each function it appears in.) /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/kern/kern_ktr.c:270: warning: unused variable
Re: bge driver not recognising BCM 5705M
Bill == Bill Paul [EMAIL PROTECTED] writes:
Bill Actually, boot -v gives you much more, like the date when the
Bill kernel image was compiled. Too bad you decided not to show
Bill everything to us.
I didn't want to spam,
Bill *sigh* No. Spam is when you try to sell me viagra or bestiality
Bill porn. Providing detailed problem reports is not spam. It saves
Bill me from having to _ask_ you for more information, thereby
Bill prolonging what might otherwise be a simple one shot
Bill exchange. It also can save time and wear and tear on developers,
Bill since, in the process of collecting detailed information, you
Bill might stumble upon possible solutions to your problem on your
Bill own, to wit:
...but my recent current is:
FreeBSD canoe.velocet.net 5.1-CURRENT FreeBSD 5.1-CURRENT #0: Tue
Jul 15 17:54:29 EDT 2003
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/CANOE i386
Bill [/u/wpaul/xl/src/sys/dev/bge]:zim.wrs.com{58}% cvs log if_bge.c
Bill [...] revision 1.44 date:
Bill 2003/07/16 00:09:56; author: wpaul; state: Exp; lines: +226 -103
Bill ^^ Add support for the BCM5705 and its ilk. Changes:
Ah... well ... must apologise. I normally follow -current and
associated lists, but that was the week I was screwed out of my
company, fired, and tossed out on the street.
I'm feeling much better now.
Dave.
--
|David Gilbert, Independent Contractor. | Two things can only be |
|Mail: [EMAIL PROTECTED]| equal if and only if they |
|http://daveg.ca | are precisely opposite. |
=GLO
___
[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-08-01 21:07:19 - starting CURRENT tinderbox run for ia64/ia64 TB --- 2003-08-01 21:07:19 - 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-08-01 21:09:57 - 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 [...] nm: init_sec_context.So: File format not recognized nm: inquire_context.So: File format not recognized nm: inquire_cred.So: File format not recognized nm: release_buffer.So: File format not recognized nm: release_cred.So: File format not recognized nm: release_name.So: File format not recognized nm: release_oid_set.So: File format not recognized release_oid_set.So: file not recognized: File format not recognized *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src/kerberos5/lib/libgssapi. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. *** Error code 1 Stop in /vol/vol0/users/des/tinderbox/CURRENT/ia64/ia64/src. TB --- 2003-08-01 21:19:16 - /usr/bin/make returned exit code 1 TB --- 2003-08-01 21:19:16 - ERROR: failed to build world TB --- 2003-08-01 21:19:16 - tinderbox aborted ___ [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 --- mkdir /home/des/tinderbox TB --- mkdir /home/des/tinderbox/CURRENT TB --- mkdir /home/des/tinderbox/CURRENT/sparc64 TB --- mkdir /home/des/tinderbox/CURRENT/sparc64/sparc64 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: panic: vm_fault: fault on nofault entry, addr: fffffe0007e8e000
On Fri, Aug 01, 2003 at 10:59:06AM -0400, Andrew Gallatin wrote:
Kris Kennaway writes:
On Fri, Aug 01, 2003 at 09:00:44AM -0400, Andrew Gallatin wrote:
The crashdump might actually be useful here. You'd have only the
trap() and vm_fault() frames, but at least you'd have information
about the state of the vm system.
Two crashdumps coming up! I'll move them onto beast:/j/kris/crash
together with the kernel.debug.
I may have wasted your time. The first one is unusable (lots of ddb
cruft). Damned gdb -k. Grrr.
That one was the third panic I posted, which was the:
trap entry = 0x2 (memory management fault)
I don't have read perms on vmcore.{1,2}, so I don't know if they are
helpful.
Oops, sorry.
If you're willing to get your traces via ddb's debug.trace_on_panic
and to set debug.debugger_on_panic=0, then we might get at least a
partial trace. FWIW, I have to do this to get any sort of crashdump
at all on SMP x86. I'm amazed you were able to call doadump from ddb.
When I try that on x86, I just get a continuous stream of panics or
fatal traps.
Hmm, I don't see this on the UP i386 machines. Bento hasn't panicked
in a while (time to upgrade!), although I do seem to recall problems
the last time it did.
kris
pgp0.pgp
Description: PGP signature
Re: ports/news/newscache gives sig11 on recent -CURRENT
On Fri, Aug 01, 2003 at 11:08:05AM -0500, Steve Ames wrote: ports/news/newscache now gives me a sig11. It didn't a few weeks ago but I really can't pin it down any closer than that. I thought it may have been related to the new gcc import but I'm not able to check that. After it gave me the sig11 I recompiled it and its dependancies and that didn't fix anything. Can you try to get a gdb backtrace and track down the cause of the problem? Kris pgp0.pgp Description: PGP signature
Re: [current tinderbox] failure on sparc64/sparc64
Tinderbox [EMAIL PROTECTED] writes: TB --- mkdir /home/des/tinderbox TB --- mkdir /home/des/tinderbox/CURRENT TB --- mkdir /home/des/tinderbox/CURRENT/sparc64 TB --- mkdir /home/des/tinderbox/CURRENT/sparc64/sparc64 Sorry about that, I was a bit too hasty moving some directories around. DES -- Dag-Erling Smørgrav - [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Julian Elischer [EMAIL PROTECTED] [2003-08-01 23:44]: can you compile your sys_machdep.c with the option -DDEBUG? I noticed there is a debug printf that is enabled byu this and may show what request the NVIDIA people are making. This is what gets logged: Aug 1 23:42:43 tybalt kernel: i386_set_ldt: start=6 num=1 descs=0xbfbff724 I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Regards -Thorsten -- Those who in quarrels interpose, must often wipe a bloody nose. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. Regards -Thorsten -- Adding manpower to a late software project makes it later ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
* Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten -- There are 10 kinds of people in the world, those who understand binary and those who don't. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. -- Munish Chopra ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: I might add that this si slightly bogus as you an't have aproces being a BSDI binary and a SOLARIS binary and a BCS binary all at the same time, and we don't set any values on most (any?) of these segments for FreeBSD binaries.. if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? -- Dan Eischen ___ [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: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Thorsten Greiner wrote: * Thorsten Greiner [EMAIL PROTECTED] [2003-08-01 23:47]: I will test wether the problem still occurs with version 1.84 of sys_machdep.c and let you know. Yup, reverting to 1.84 unbreaks this for me. Looking at the changes made it appears to me that the check if (uap-start NLDT || uap-num = 0) return (EINVAL);i causes this, because NLDT is 6 and the NVidia stuff passes uap-start == 6 to this call. It can't use 6. FreeBSD reserves 0-16 for its own use. I think the bug was in the old code allowing this to happen... Looking at segments.h. /* * Entries in the Local Descriptor Table (LDT) */ #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) it looks like NLDT should be save between from 6 to 15 (though I wish they'd chosen a different value) so we could add: if ((uap-start == LBSDICALLS_SEL) || (uap-start = LUDATA_SEL)) || (uap-num = 0)) ... What do you think? I think it could work, but do we want it to work? If we are really reserving the first 17 (16 really, since 0 is invalid), then what are we to do if we want to use another one? Do we add NVidia's LDTs to segments.h so that we, or anyone else, will not use them? We could make a new syscall and use the old one for compat behavior, or make it a compile time option... If they ever recompile, they really want to be using the new interface, so I think breaking it by default would be good. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. I think that they are safe.. looking at it further, it appears that NLDT is not really a 'reservation' as much as a description of how much space we may need to allocate initially. I think that it wouldn't matter (for example) if you used one of the existing defined numbers as long as you are not running a program that used them.. i.e you could use as you are not a BSDI binary that needs it. Given this.. it would appear that maybe the whole idea needs to be looked at again. Also it's interesting to note that '0' is defined.. this is intersting as a value of a segment register of '0' is not allowed from my memory. I guess that only applies to GDTEs. -- Munish Chopra ___ [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: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. David Xu ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Sat, 2 Aug 2003, David Xu wrote: On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. Why not allow setting a specific entry when it's currently unused and not reserved by us? We can simply fail if the process is trying to set a LDT entry that's currently being used or is reserved by us. The only case that causes problems is when an existing LDT entry is overwritten by another consumer. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Sat, 2 Aug 2003, David Xu wrote: On Saturday 02 August 2003 06:24, Munish Chopra wrote: On 2003-08-02 00:20 +0200, Thorsten Greiner wrote: * Daniel Eischen [EMAIL PROTECTED] [2003-08-02 00:06]: I think the bug was in the old code allowing this to happen... Well, than someone should tell that to NVidia. Their driver is closed source and comes without user servicable parts. Regards -Thorsten That's going to be a lot easier to get through if someone can confirm whether 0-16 are reserved, or whether (like julian says), 6-15 are actually safe and something else is being clobbered. #define LSYS5CALLS_SEL 0 /* forced by intel BCS */ #define LSYS5SIGR_SEL 1 #define L43BSDCALLS_SEL 2 /* notyet */ #define LUCODE_SEL 3 #define LSOL26CALLS_SEL 4 /* Solaris = 2.6 system call gate */ #define LUDATA_SEL 5 /* separate stack, es,fs,gs sels ? */ /* #define LPOSIXCALLS_SEL 5*/ /* notyet */ #define LBSDICALLS_SEL 16 /* BSDI system call gate */ #define NLDT(LBSDICALLS_SEL + 1) LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Of course, but there are pre-exisiting binaries that use a selector of 6. David Xu ___ [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]
Waiting on allproc w/ with non-sleepable locks held
Hi, yet another funky console message with today's -current: Waiting on allproc with the following non-sleepablelocks held: exclusive sleep mutex callout_dont_sleep r = 0 (0xc0371fa0) locked @ /usr/src/sys/kern/kern_timeout.c:223 Got this twice in a row; system didn't enter ddb so I got no trace. Lars -- Lars Eggert [EMAIL PROTECTED] USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. I think that for now we can allow anything over 6 because we are not a BSDI binary. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. Why not allow setting a specific entry when it's currently unused and not reserved by us? We can simply fail if the process is trying to set a LDT entry that's currently being used or is reserved by us. The only case that causes problems is when an existing LDT entry is overwritten by another consumer. That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). I can see the need to keep the old behavoir for compatibility's sake. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. I think that for now we can allow anything over 6 because we are not a BSDI binary. make that over 5 ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Marcel Moolenaar wrote: On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. Why not allow setting a specific entry when it's currently unused and not reserved by us? We can simply fail if the process is trying to set a LDT entry that's currently being used or is reserved by us. The only case that causes problems is when an existing LDT entry is overwritten by another consumer. That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). I can see the need to keep the old behavoir for compatibility's sake. How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) -- Dan Eischen ___ [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: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. I think that for now we can allow anything over 6 because we are not a BSDI binary. That's a quick fix, yes. But I still think we should put things in place to disallow this and favor the dynamic ldt creation. I can only see it rearing its ugly head at some point in the future when our thread libraries get more widespread use. -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: On Fri, 1 Aug 2003, Daniel Eischen wrote: That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). I can see the need to keep the old behavoir for compatibility's sake. How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) And make a new interface, changing the prototype in the header file, so old uses of it fail to compile??? -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote:
I can see the need to keep the old behavoir for compatibility's
sake.
How about we complain loudly on the console when it's done..
(for the first few times)
(with info on how to do it right)
static int complained = 6;
if (complained-- ) {
printf (process (PID %d) Use static LDT allocation.\n,
td-td_proc-p_pid);
printf (man i386_set_ldt for more information\n);
}
and fix the man paget to indicate that static alloacation
is frowned upon.
We should however allow it to succeed if it doesn't collide
with LUDATA or LUCODE I think.
(if they are set)
julian
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: [PATCH] jail NG schript patch for mounting devfs and procfsautomatically
On Tue, Jul 29, 2003 at 08:27:07PM +0200, Jens Rehsack wrote:
On 29.07.2003 19:21, Mike Makonnen wrote:
On Tue, Jul 29, 2003 at 07:08:38PM +0200, Jens Rehsack wrote:
Yeah, I'll take care of this. I had asked scott to mail me his final
patch so I could commit it, but I never heard back from him. I'll
dig out the revisions from my mail archives and combine the
two.
You can mail me the patch first, so that I can test it before you
commit it, if you want.
Hi Jens,
Can you apply the attached patches and let me know how it goes?
Cheers.
--
Mike Makonnen | GPG-KEY: http://www.identd.net/~mtm/mtm.asc
[EMAIL PROTECTED] | D228 1A6F C64E 120A A1C9 A3AA DAE1 E2AF DBCC 68B9
[EMAIL PROTECTED]| FreeBSD - Unleash the Daemon!
Index: etc/rc.subr
===
RCS file: /home/ncvs/src/etc/rc.subr,v
retrieving revision 1.13
diff -u -r1.13 rc.subr
--- etc/rc.subr 9 Jun 2003 17:31:06 - 1.13
+++ etc/rc.subr 1 Aug 2003 23:05:21 -
@@ -1033,3 +1033,160 @@
esac
fi
}
+
+# devfs_init_rulesets
+# Initialize default system supplied rulesets.
+#
+devfs_init_rulesets()
+{
+ local rsHide rsBasic rsLogin rsJail _me
+ rsHide=$devfs_ruleset_hide
+ rsBasic=$devfs_ruleset_basic
+ rsLogin=$devfs_ruleset_login
+ rsJail=$devfs_ruleset_jail
+ _me=devfs_init_rulesets
+
+ # Go through this only once
+ if [ -n $devfs_rulesets_init ]; then
+ debug $_me: devfs rulesets already initialized
+ return
+ fi
+
+ # Hide: Hide all devices
+ #
+ /sbin/devfs rule -s $rsHide delset
+ /sbin/devfs rule -s $rsHide add hide
+
+ # Basic: Basic devices typically necessary
+ #
+ /sbin/devfs rule -s $rsBasic delset
+ /sbin/devfs rule -s $rsBasic add path null unhide
+ /sbin/devfs rule -s $rsBasic add path zero unhide
+ /sbin/devfs rule -s $rsBasic add path random unhide
+ /sbin/devfs rule -s $rsBasic add path urandom unhide
+
+ # Login: Devices typically needed to support loged-in users
+ #
+ /sbin/devfs rule -s $rsLogin delset
+ /sbin/devfs rule -s $rsLogin add path 'ptyp*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyq*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyr*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptys*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyP*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyQ*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyR*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ptyS*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyp*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyq*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyr*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttys*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyP*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyQ*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyR*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'ttyS*' unhide
+ /sbin/devfs rule -s $rsLogin add path 'fd/*' unhide
+ /sbin/devfs rule -s $rsLogin add path stdin unhide
+ /sbin/devfs rule -s $rsLogin add path stdout unhide
+ /sbin/devfs rule -s $rsLogin add path stderr unhide
+
+ # Jail: Devices typically usefull in a jail
+ #
+ /sbin/devfs rule -s $rsJail add path '*' include $rsHide
+ /sbin/devfs rule -s $rsJail add path '*' include $rsBasic
+ /sbin/devfs rule -s $rsJail add path '*' include $rsLogin
+
+ devfs_rulesets_init=1
+ debug $_me: devfs rulesets initialized
+}
+
+# devfs_set_ruleset ruleset [dir]
+# Sets the default ruleset of dir to ruleset.
+# Returns non-zero if it could not set it successfully.
+#
+devfs_set_ruleset()
+{
+ local devdir rs _me
+ rs=$1
+ [ -n $2 ] devdir=-m $2 || devdir=
+ _me=devfs_set_ruleset
+
+ if [ -z $rs ]; then
+ warn $_me: you must specify a ruleset number
+ return 1
+ fi
+ debug $_me: setting ruleset ($rs) on mount-point (${devdir#-m })
+ if ! /sbin/devfs $devdir ruleset $rs ; then
+ warn $_me: unable to set ruleset $rs to ${devdir#-m }
+ return 1
+ fi
+ return 0
+}
+
+# devfs_apply_ruleset ruleset [dir]
+# Apply ruleset number $ruleset to the devfs mountpoint $dir.
+# Returns 0 on success or non-zero if it could not apply
+# the ruleset.
+#
+devfs_apply_ruleset()
+{
+ local devdir rs _me
+ rs=$1
+ [ -n $2 ] devdir=-m $2 || devdir=
+ _me=devfs_apply_ruleset
+
+ if [ -z $rs ]; then
+ warn $_me: you must specify a ruleset
+ return 1
+ fi
+ debug $_me: applying ruleset ($rs) to mount-point (${devdir#-m })
+ if ! /sbin/devfs $devdir rule -s $rs applyset ; then
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote: On Fri, 1 Aug 2003, Marcel Moolenaar wrote: On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: LUCODE_SEL is used by kernel to load _ucodesel to user %cs LUDATA_SEL is used by kernel to load _udatasel to user %ds, %es, %fs, %gs. I didn't check other ABIs, but setting to a fixed location of LDT in userland is also a bad idea, I think it will conflict with thread library soon, it is better to use dynamic allocating facility newly added in i386_set_ldt. Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. Why not allow setting a specific entry when it's currently unused and not reserved by us? We can simply fail if the process is trying to set a LDT entry that's currently being used or is reserved by us. The only case that causes problems is when an existing LDT entry is overwritten by another consumer. That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). But if we only use the dynamic allocation then it can only fail for a combination of 3rd party code. It should always work when there's just one 3rd party piece of code involved. This makes it work for anything we should care about. The moment a process is constructed with various 3rd party pieces compatibility is out of our hands anyway (compatibility between the various 3rd party pieces that is). Having a way to disallow using the static allocation should be easy if we use compiler magic to test that the LDT entry is constant and 0. If it is, all is ok (assuming that I'm not mistaken that we use a 0 entry to indicate dynamic allocation -- I haven't actually paid that close attention to it). If the LDT entry is non-constant, it can still be 0 of course but I expect that to be a weird border case. -- Marcel Moolenaar USPA: A-39004 [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: Having a way to disallow using the static allocation should be easy if we use compiler magic to test that the LDT entry is constant and 0. If it is, all is ok (assuming that I'm not mistaken that we use a 0 entry to indicate dynamic allocation -- I haven't actually paid that close attention to it). If the LDT entry is non-constant, it can still be 0 of course but I expect that to be a weird border case. note that a 0 value turns out to be valid.. we had thougth it was invalid when we did the dynamic code ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote: On Fri, 1 Aug 2003, Julian Elischer wrote: How about we complain loudly on the console when it's done.. (for the first few times) (with info on how to do it right) And make a new interface, changing the prototype in the header file, so old uses of it fail to compile??? This could be a royal pain for someone in a hurry.. I think just the message would be enough to annoy them to fix it.. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Marcel Moolenaar wrote: On Fri, Aug 01, 2003 at 07:18:11PM -0400, Daniel Eischen wrote: On Fri, 1 Aug 2003, Marcel Moolenaar wrote: On Fri, Aug 01, 2003 at 06:51:33PM -0400, Daniel Eischen wrote: Perhaps we need to rethink the interface and disallow specification of any ldt; only allow dynamic. We would need a different method of setting an array of them, though. Why not allow setting a specific entry when it's currently unused and not reserved by us? We can simply fail if the process is trying to set a LDT entry that's currently being used or is reserved by us. The only case that causes problems is when an existing LDT entry is overwritten by another consumer. That's what I was worried about. Once an application or library is written to use specific LDTs, you never know how it will be affected by the use of threading libraries (or other libraries using threads). But if we only use the dynamic allocation then it can only fail for a combination of 3rd party code. It should always work when there's just one 3rd party piece of code involved. This makes it work for anything we should care about. The moment a process is constructed with various 3rd party pieces compatibility is out of our hands anyway (compatibility between the various 3rd party pieces that is). If your 3rd party code is a library, and other application code is built to be threaded (or use other libraries that are threaded) _and_ use this 3rd party library, then you have a problem. You don't know what ldt allocation is going to come first. If our dynamic allocations are made first and the 3rd party static allocations are made next, then you can have something whacky ensue. It may not even be the same all the time; it could depend on which button a user clicks first. OpenGL is the example that I was thinking about. Having a way to disallow using the static allocation should be easy if we use compiler magic to test that the LDT entry is constant and 0. If it is, all is ok (assuming that I'm not mistaken that we use a 0 entry to indicate dynamic allocation -- I haven't actually paid that close attention to it). If the LDT entry is non-constant, it can still be 0 of course but I expect that to be a weird border case. This is all good :-) -- Dan Eischen ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote:
On Fri, 1 Aug 2003, Marcel Moolenaar wrote:
OpenGL is the example that I was thinking about.
Having a way to disallow using the static allocation should be easy
if we use compiler magic to test that the LDT entry is constant and
0. If it is, all is ok (assuming that I'm not mistaken that we use a
0 entry to indicate dynamic allocation -- I haven't actually paid
that close attention to it). If the LDT entry is non-constant, it
can still be 0 of course but I expect that to be a weird border case.
This is all good :-)
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
if (dp-sd.sd_type == SDT_SYSNULL)
break;
dp++;
(beware white space munging.. (copypaste))
I'd follow this with actual breakage oafer say 3 months.
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
newsyslog problems with -C
I have created a private newsyslog.conf with this contents:
-8-
/var/tmp/foofoo:mail600 7 * @T00ZBCN
/var/tmp/barbar:mail600 7 * @T00ZBCN
-8-
Without creating by hand /var/tmp/{foo,bar} this command fail leaving the
temporary mkstemp /var/tmp/{foo,bar}.zXX (with XX variable):
# cd /var/tmp
# newsyslog -v -F -C -f /usr/local/etc/rotatemailbackup.conf
-- [creating entry for /var/tmp/foo]
-- [creating entry for /var/tmp/bar]
/var/tmp/foo 7Z: does not exist - will create.
newsyslog: can't fchmod temp file '/var/tmp/foo.z8FjDcW': Bad file descriptor
# newsyslog -v -F -CC -f /silos/usr/local/etc/rotatemailbackup.conf
-- [creating entry for /var/tmp/foo]
-- [creating entry for /var/tmp/bar]
/var/tmp/foo 7Z: does not exist - will create.
newsyslog: can't fchmod temp file '/var/tmp/foo.zyXVe1U': Bad file descriptor
But it works if I manually 'touch' both {foo,bar}
# touch foo bar
# newsyslog -v -F -C -f /silos/usr/local/etc/rotatemailbackup.conf
-- [creating entry for /var/tmp/foo]
-- [creating entry for /var/tmp/bar]
/var/tmp/foo 7Z: -- trimming log
-- [freeing entry for /var/tmp/foo]
/var/tmp/bar 7Z: -- trimming log
-- [freeing entry for /var/tmp/bar]
# newsyslog -v -F -CC -f /silos/usr/local/etc/rotatemailbackup.conf
-- [creating entry for /var/tmp/foo]
-- [creating entry for /var/tmp/bar]
/var/tmp/foo 7Z: -- trimming log
-- [freeing entry for /var/tmp/foo]
/var/tmp/bar 7Z: -- trimming log
-- [freeing entry for /var/tmp/bar]
It also fails if I remove the mandatory C flag from config file.
So, how the -C and C parameters are supposed to works?
NB: this happens on both 4.8 and recent -CURRENT and only when user:group
are specified...
--
Riccardo. ( http://www.GUFI.org/~vic/ )
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote:
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
Looks OK, but if we are doing a dynamic allocation, it might be
better to start at NLDT just to avoid the known problem of someone
using 6... Just a thought.
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Daniel Eischen wrote:
On Fri, 1 Aug 2003, Julian Elischer wrote:
Here's my first patch..
I'd suggest this (along with man page change) to go in first
for a while before we break people's code.
cvs server: Diffing .
Index: sys_machdep.c
===
RCS file: /home/ncvs/src/sys/i386/i386/sys_machdep.c,v
retrieving revision 1.86
diff -u -r1.86 sys_machdep.c
--- sys_machdep.c 31 Jul 2003 08:20:24 - 1.86
+++ sys_machdep.c 1 Aug 2003 23:58:29 -
@@ -410,6 +410,9 @@
return(error);
}
+static int ldt_warnings;
+#define NUM_LDT_WARNINGS 10
+
static int
i386_set_ldt(td, args)
struct thread *td;
@@ -441,7 +444,7 @@
uap-start = NLDT;
uap-num = MAX_LD - NLDT;
}
- if (uap-start NLDT || uap-num = 0)
+ if (uap-start = LUDATA_SEL || uap-num = 0)
return (EINVAL);
mtx_lock_spin(sched_lock);
pldt = mdp-md_ldt;
@@ -460,10 +463,16 @@
}
if (!(uap-start == 0 uap-num == 1)) {
+ /* complain a for a while if using old methods */
+ if (ldt_warnings++ NUM_LDT_WARNINGS) {
+ printf(Warning: pid %d used static ldt
allocation.\n,
+ td-td_proc-p_pid);
+ printf(See the i386_set_ldt man page for more
info\n);
+ }
/* verify range of descriptors to modify */
largest_ld = uap-start + uap-num;
- if (uap-start NLDT || uap-start = MAX_LD ||
uap-num 0 ||
- largest_ld MAX_LD) {
+ if (uap-start = LUDATA_SEL || uap-start = MAX_LD ||
+ uap-num 0 || largest_ld MAX_LD) {
return (EINVAL);
}
}
@@ -562,7 +571,7 @@
again:
mtx_lock_spin(sched_lock);
dp = ((union descriptor *)(pldt-ldt_base))[NLDT];
- for (i = NLDT; i pldt-ldt_len; ++i) {
+ for (i = LUDATA_SEL + 1; i pldt-ldt_len; ++i) {
Looks OK, but if we are doing a dynamic allocation, it might be
better to start at NLDT just to avoid the known problem of someone
using 6... Just a thought.
sure.. (though we don't know how many they use we just saw the first
one fail).
of course they only link with linux threads.
when they link with us they's use our %gs..
I also noticed that if we disable the 'splat' mode, we'd break sysVR4
binary code as they do that.. (though it's #if 0'd out at the moment)
--
Dan Eischen
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: NVidia glx stuff dies in sysarch(I386_SET_LDT, ...)
On Fri, 1 Aug 2003, Julian Elischer wrote: Looks OK, but if we are doing a dynamic allocation, it might be better to start at NLDT just to avoid the known problem of someone using 6... Just a thought. sure.. (though we don't know how many they use we just saw the first one fail). of course they only link with linux threads. when they link with us they's use our %gs.. I also noticed that if we disable the 'splat' mode, we'd break sysVR4 binary code as they do that.. (though it's #if 0'd out at the moment) not to mention linux (more important..) though I might add that that code could do with rewriting to get rid of a lot of stackgap stuff. (i386/linux/linux_machdep.c around line 630) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Compaq N610c and external keyboard
Hello fellow Compaq N610c users, when booting my N610c with an external keyboard, I'd see keyboard lights flash and keyboards worked at boot prompt but after booting finished neither the integratd kbd or the external kbd would work, At boot up would see: atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 device_probe_and_attach: atkbd0 attach returned 6 This can be fixed by changing /boot/device.hints hint.atkbd.0.flags=0x1 to hint.atkbd.0.flags=0x3 Now both keyboards work fine. Slowly getting there! -- tonym ps still waiting for that unexpected email explaining how to get syspension/resumption to work correctly and to eliminate loss of sync when switching from text to graphics mode. ;-) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Anyone use WINE at all anywhere?
Is the re ANYONE that uses wine on -current...? for that matter, a -current user that uses wine on 4.x? julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: newsyslog problems with -C
On Sat, Aug 02, 2003 at 02:03:32AM +0200, Riccardo Torrini wrote:
Without creating by hand /var/tmp/{foo,bar} this command fail
# newsyslog -v -F -C -f /usr/local/etc/rotatemailbackup.conf
-- [creating entry for /var/tmp/foo]
-- [creating entry for /var/tmp/bar]
/var/tmp/foo 7Z: does not exist - will create.
newsyslog: can't fchmod temp file '/var/tmp/foo.z8FjDcW': \
Bad file descriptor
Found (I think :-)
# truss newsyslog -v -CC -F -f \
/usr/local/etc/rotatemailbackup.conf /var/tmp/foo
[...]
lstat(/var/tmp,0xbfbffad0) = 0 (0x0)
gettimeofday(0xbfbff500,0x0) = 0 (0x0)
getpid() = 84801 (0x14b41)
open(/dev/urandom,0x0,00) = 3 (0x3)
read(0x3,0xbfbff50c,0x74)= 116 (0x74)
close(3) = 0 (0x0)
stat(/var/tmp,0xbfbff610) = 0 (0x0)
open(/var/tmp/foo.zM4kxLE,0xa02,0600) = 3 (0x3)
fchown(0x3,0x3e9,0x6)= 0 (0x0)
close(3) = 0 (0x0)
fchmod(0x3,0x180)ERR#9 'Bad file descriptor'
[...]
It seems that last two lines are reversed (close before fchmod).
Looking into sources I found two close(fd). Here is the patch:
-8-[ patch ]-8-
# diff -u newsyslog.c.orig newsyslog.c
--- newsyslog.c.origSun May 25 18:46:13 2003
+++ newsyslog.c Sat Aug 2 02:28:50 2003
@@ -1764,7 +1764,6 @@
failed = fchown(fd, ent-uid, ent-gid);
if (failed)
err(1, can't fchown temp file %s, tempfile);
- (void) close(fd);
}
}
-8-[ patch ]-8-
Now it works, here is the correct flow:
[...]
open(/dev/urandom,0x0,00) = 3 (0x3)
read(0x3,0xbfbff4bc,0x74)= 116 (0x74)
close(3) = 0 (0x0)
stat(/var/tmp,0xbfbff5c0) = 0 (0x0)
open(/var/tmp/foo.zKXXcYJ,0xa02,0600) = 3 (0x3)
fchown(0x3,0x3e9,0x6)= 0 (0x0)
fchmod(0x3,0x180)= 0 (0x0)
rename(0xbfbff680,0x8058060) = 0 (0x0)
close(3) = 0 (0x0)
-- [freeing entry for /var/tmp/foo]
[...]
Please commit on both 4.8 and -CURRENT because newsyslog.c 1.25.2.21 (4.8)
and newsyslog.c 1.70 (-CURRENT) are equal but the headers. Thanks.
--
Riccardo. ( http://www.GUFI.org/~vic/ )
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone use WINE at all anywhere?
Julian Elischer wrote: Is the re ANYONE that uses wine on -current...? for that matter, a -current user that uses wine on 4.x? I don't _use_ wine on -current, but I can tell you the brief experience that caused me to give up on it. I wanted to install wine to run Crimson Editor, which is a fairly nice text editor for windows. There's no Linux or BSD version. The wine website claims that Crimson works under wine. I spent about 4 or 5 hours trying to get Crimson to install and/or run. While I was at it, I tried a number of other wine apps to see if I was doing things correctly. I tried Getting America's Army to work, even Windows explorer or IE. The only thing I ever got to run under wine was puTTY ... which is one Windows app I have absolutely zero use for. Eventually, I gave up on wine and cleaned all traces of it from my HDD. YMMV, but I thought I'd throw my $.02 in. -- Bill Moran Potential Technologies http://www.potentialtech.com ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Problem making a gateway from 5.1-RELEASE
Hey, This isn't quite -CURRENT, but it's 5.1-RELEASE. I'm trying to put together a typical nat/gateway box. But I can't seem to get both network cards to work at the same time. I've tried a 3com card, a realtek card, as well as the onboard sis chipset card. One card always works, the other seems to work (it gets a DHCP addy) but I can't ping or otherwise communicate via it. Although it seems to be communicating somehow, as the output of netstat show that it sees the other machines chattering on its subnet. Sometimes it's the 3com that works, other times it's the realtek, depending on which devices are installed/enabled. I don't see any interrupt conflicts. Below is the dmesg from when the 3com and realtek were installed with the onboard sis disabled. Does anyone have any ideas as to what's going on? Is this a case of the hardware just being too cheap? Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #2: Sat Aug 2 07:46:12 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PROXY Preloaded elf kernel /boot/kernel/kernel at 0xc03f9000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03f9244. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1693130944 Hz CPU: Intel(R) Celeron(R) CPU 1.70GHz (1693.13-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 100597760 (95 MB) avail memory = 93331456 (89 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AWARD AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fdc90 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: SIS Generic host to PCI bridge mem 0xe800-0xebff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 atapci0: SiS 96X UDMA133 controller port 0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: multimedia, audio at device 2.7 (no driver attached) pci0: serial bus, USB at device 3.0 (no driver attached) pci0: serial bus, USB at device 3.1 (no driver attached) pci0: serial bus, USB at device 3.3 (no driver attached) dc0: 3Com OfficeConnect 10/100B port 0xe000-0xe0ff mem 0xed102000-0xed1023ff irq 5 at device 6.0 on pci0 dc0: Ethernet address: 00:04:75:b5:27:2c miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem 0xed104000-0xed1040ff irq 11 at device 8.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:c0:ca:14:03:eb miibus1: MII bus on rl0 rlphy0: RealTek internal media interface on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled, default to deny, logging unlimited ad0: 38166MB WDC WD400BB-00DEA0 [77545/16/63] at ata0-master UDMA100 acd0: CDROM ATAPI CD-ROM 52XMax at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s1a ___ [EMAIL
Re: Problem making a gateway from 5.1-RELEASE
Nevermind. I think I've been working too many hours. The problem was a stupid nat misconfiguration that I have now fixed. The strange behaviour this was causing misled me to believe one of the NICs wasn't working correctly. Bill Moran wrote: Hey, This isn't quite -CURRENT, but it's 5.1-RELEASE. I'm trying to put together a typical nat/gateway box. But I can't seem to get both network cards to work at the same time. I've tried a 3com card, a realtek card, as well as the onboard sis chipset card. One card always works, the other seems to work (it gets a DHCP addy) but I can't ping or otherwise communicate via it. Although it seems to be communicating somehow, as the output of netstat show that it sees the other machines chattering on its subnet. Sometimes it's the 3com that works, other times it's the realtek, depending on which devices are installed/enabled. I don't see any interrupt conflicts. Below is the dmesg from when the 3com and realtek were installed with the onboard sis disabled. Does anyone have any ideas as to what's going on? Is this a case of the hardware just being too cheap? Copyright (c) 1992-2003 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.1-RELEASE #2: Sat Aug 2 07:46:12 GMT 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PROXY Preloaded elf kernel /boot/kernel/kernel at 0xc03f9000. Preloaded elf module /boot/kernel/acpi.ko at 0xc03f9244. Timecounter i8254 frequency 1193182 Hz Timecounter TSC frequency 1693130944 Hz CPU: Intel(R) Celeron(R) CPU 1.70GHz (1693.13-MHz 686-class CPU) Origin = GenuineIntel Id = 0xf13 Stepping = 3 Features=0x3febfbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,SS,HTT,TM real memory = 100597760 (95 MB) avail memory = 93331456 (89 MB) Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: AWARD AWRDACPI on motherboard pcibios: BIOS version 2.10 Using $PIR table, 6 entries at 0xc00fdc90 acpi0: power button is handled as a fixed feature programming model. Timecounter ACPI-fast frequency 3579545 Hz acpi_timer0: 24-bit timer at 3.579545MHz port 0x1008-0x100b on acpi0 acpi_cpu0: CPU on acpi0 acpi_tz0: thermal zone on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge port 0x10c0-0x10ff,0x1000-0x10bf,0x480-0x48f,0xcf8-0xcff on acpi0 pci0: ACPI PCI bus on pcib0 agp0: SIS Generic host to PCI bridge mem 0xe800-0xebff at device 0.0 on pci0 pcib1: PCIBIOS PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 0.0 (no driver attached) isab0: PCI-ISA bridge at device 2.0 on pci0 isa0: ISA bus on isab0 atapci0: SiS 96X UDMA133 controller port 0x4000-0x400f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 2.5 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: multimedia, audio at device 2.7 (no driver attached) pci0: serial bus, USB at device 3.0 (no driver attached) pci0: serial bus, USB at device 3.1 (no driver attached) pci0: serial bus, USB at device 3.3 (no driver attached) dc0: 3Com OfficeConnect 10/100B port 0xe000-0xe0ff mem 0xed102000-0xed1023ff irq 5 at device 6.0 on pci0 dc0: Ethernet address: 00:04:75:b5:27:2c miibus0: MII bus on dc0 ukphy0: Generic IEEE 802.3u media interface on miibus0 ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto rl0: RealTek 8139 10/100BaseTX port 0xe400-0xe4ff mem 0xed104000-0xed1040ff irq 11 at device 8.0 on pci0 rl0: Realtek 8139B detected. Warning, this may be unstable in autoselect mode rl0: Ethernet address: 00:c0:ca:14:03:eb miibus1: MII bus on rl0 rlphy0: RealTek internal media interface on miibus1 rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto fdc0: Enhanced floppy controller (i82077, NE72065 or clone) port 0x3f7,0x3f2-0x3f5 irq 6 drq 2 on acpi0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A ppc0 port 0x778-0x77b,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold ppbus0: Parallel port bus on ppc0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 atkbdc0: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROM at iomem 0xc-0xc7fff on isa0 pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio1: configured irq 3 not in bitmap of probed irqs 0 sio1: port may not be enabled vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec ipfw2 initialized, divert disabled, rule-based forwarding enabled,
groff and mkdep?
I've just started to try and sync up to -CURRENT, and my first time asking on the lists, and everything seems to be going fine, except groff's build dies with rm -f .depend mkdep -f .depend -a /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/input.cpp /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/printer.cpp /usr/src/contrib/groff/src/libs/libdriver/input.cpp:244:20: driver.h: No such file or directory /usr/src/contrib/groff/src/libs/libdriver/input.cpp:245:20: device.h: No such file or directory /usr/src/contrib/groff/src/libs/libdriver/printer.cpp:29:20: driver.h: No such file or directory mkdep: compile failed *** Error code 1 I've tried everything I can think of, including changing the Makefile to explicitly include the groff directories via CFLAGS, CXXFLAGS, and such (and it adds the directive), but that doesn't seem to help in the slightest. Does anyone have any idea what's wrong with this? Is there any way to bypass this particular program in the build, and is it safe to do so? ___ [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-08-02 04:00:07 - starting CURRENT tinderbox run for alpha/alpha TB --- 2003-08-02 04:00:07 - 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-08-02 04:02:37 - 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-08-02 05:09:00 - 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 Aug 2 05:09:00 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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdev.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwdma.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwmem.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 -g -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-strict-aliasing -mno-fp-regs -ffixed-8 -Wa,-mev6 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/alpha/alpha/src/sys/dev/firewire/fwohci.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 -g -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
Re: Anyone use WINE at all anywhere?
I used wine on 5.1-RELEASE in order to convert some binary cdrom format other than .iso (all those nice .ccd, .nrg, ...). I tried playing on my own copy of Starcraft but didn't successed yet however I didn't take much time to work on it. Except old games or mirc32 (for my gf), I'm not so much interested in wine but rather in vmware. If you have any patch to try, you're welcome. Is the re ANYONE that uses wine on -current...? for that matter, a -current user that uses wine on 4.x? julian ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: groff and mkdep?
On Fri, Aug 01, 2003 at 08:48:07PM -0700, Peorth wrote: I've just started to try and sync up to -CURRENT, and my first time asking on the lists, and everything seems to be going fine, except groff's build dies with rm -f .depend mkdep -f .depend -a /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/input.cpp /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/printer.cpp /usr/src/contrib/groff/src/libs/libdriver/input.cpp:244:20: driver.h: No such file or directory /usr/src/contrib/groff/src/libs/libdriver/input.cpp:245:20: device.h: No such file or directory /usr/src/contrib/groff/src/libs/libdriver/printer.cpp:29:20: driver.h: No such file or directory mkdep: compile failed *** Error code 1 I've tried everything I can think of, including changing the Makefile to explicitly include the groff directories via CFLAGS, CXXFLAGS, and such (and it adds the directive), but that doesn't seem to help in the slightest. Does anyone have any idea what's wrong with this? Is there any way to bypass this particular program in the build, and is it safe to do so? I can only reproduce this with make depend CFLAGS=. Something somewhere overrides the normal CFLAGS value; the command line above is incorrect, the correct one should look like this: mkdep -f .depend -a-DHAVE_CONFIG_H -I/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/include -I/usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../src/include /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/input.cpp /usr/src/gnu/usr.bin/groff/src/libs/libdriver/../../../../../../contrib/groff/src/libs/libdriver/printer.cpp So in short, something is wrong with your build environment. Cheers, -- Ruslan Ermilov Sysadmin and DBA, [EMAIL PROTECTED] Sunbay Software Ltd, [EMAIL PROTECTED] FreeBSD committer pgp0.pgp Description: PGP signature
[BUG REPORT] Off by one error in initializing unit number forPCCARD NICs in both recent 4.8-STABLE and 5.1-RELEASE
Because of the nature of this bug, I have no network access on my FreeBSD machine and so I'm filing this off my wife's laptop. I can't send-pr in any other manner. Would someone please post this SYSTEM IBM 380XD Thinkpad Laptop running either a recent (post-May) 4.8-STABLE or 5.1-RELEASE (off the ISO images off ftp.freebsd.org). The 5.1 kernel was recompiled with OLDCARD support since NEWCARD fails in other ways. Using Compaq Netelligent 10/100 PCCARD Nic or NetGear Wireless (xe and wi respectively) SYMPTOMS Boot and detect occur normally. However, as the PCCARD device is being brought up, the PCCARD subsystem is starting with a unit number of -1 instead of 0. Hence, I get messages indicating attempts to start xe-1 which always fail. Prior to May, STABLE was fine. When I recompiled STABLE and found myself without network access. I decided to install a clean install of 5.1-RELEASE. To my chagrin, the same problem exists on 5.1-RELEASE too. WORKAROUND None known. jmc ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone use WINE at all anywhere?
On Saturday, 02 August 2003 10:38, Julian Elischer wrote: Is the re ANYONE that uses wine on -current...? for that matter, a -current user that uses wine on 4.x? Well I used to use wine to play Quake2 and load flash programs but ever since moving from Windows 98 to XP wine doesn't really seem to work at all. Not there is much reason left to use it as I don't use Windows XP much anymore. julian ___ [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]
