Re: Remember my ill-fated i386 smp pmap optimizations?
John Baldwin wrote: On 08-Jul-2002 Peter Wemm wrote: [snip] Excuse me while I go outside and shoot myself. Hahahaha! Glad to see you have fixed them. :) Unfortunately, there are still more problems. :-( I have found some of them. And what is really scary is that I have verified that some of what Terry has been FUD'ing(*) about for our TLB (mis)management is actually correct. :-( We have code that simply will not work (ie: vm86 will explode when doing VESA calls) if certain accidental conditions that mask the bugs no longer occur. Probably why my Pentium-III 866 locks up (with a continuous beep from the PC speaker) when I switch virtual consoles (no X running) when doing disk I/O and one console is running the standard 80x25 and the other is running 132x60. Seems to happen every time so far and has done so for several months. It doesn't happen on my Celeron 450 Slot-1 (actually a 300a running at 100Mhz FSB instead of 66MHz) with an Nvidia TNT2 16MB, Western digital something 20GB also using 80x25 and 132x60. (also GENERIC kernel and v.new -CURRENT). The P-III 866 has an Nvidia GeForce2 MX400 64MB, IBM 120GXP 40GB drive, very new -CURRENT and GENERIC kernel. extract of /boot/loader.conf has: hw.ata.wc=1 hw.ata.tags=1 --- This line not on the Celeron 450 box as vesa_load=YESthe WD drive cant do tagged command queing extract of /etc/rc.conf has: font8x16=cp437-8x16.fnt font8x14=cp437-8x14.fnt font8x8=cp437-8x8.fnt -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 EDINBURGH South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
NEWCARD
I am pretty new to FreeBSD, but I am trying to get current to run on my laptop with cardbus. With DP1 the kernel crashes everytime I insert a card. After diving in I realised that I must have made a mistake when compiling it. I then did cvsup to get the latest version but trying I just get this far : bash-2.05a# make -DNO_WERROR depend rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I../../.. -I../../../dev -I../../../contrib/dev/acpica -I../../../contrib/ipfilter -I../../../../include -D_KERNEL -include opt_global.h -mpreferred-stack-boundary=2 ../../../i386/i386/genassym.c In file included from ../../../sys/buf.h:263, from ../../../i386/i386/genassym.c:46: ../../../sys/proc.h:117: field `ar_args' has incomplete type *** Error code 1 Stop in /usr/src/sys/i386/compile/NEWCARD. *** Error code 1 Stop in /usr/src/sys/i386/compile/NEWCARD. I assume this is known or I am stupid? :) - kurtis - To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recent -CURRENT when trying to build ports/x11/XFree86-4
=== Registering installation for XFree86-documents-4.2.0 === Returning to build of XFree86-4.2.0_1,1 === XFree86-4.2.0_1,1 depends on file: /usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz - not found ===Verifying install for /usr/X11R6/lib/X11/fonts/100dpi/UTBI__10-ISO8859-1.pcf.gz in /usr/ports/x11-fonts/XFree86-4-font100dpi === Extracting for XFree86-font100dpi-4.2.0 Checksum OK for xc/X420src-2.tgz. === XFree86-font100dpi-4.2.0 depends on executable: mkfontdir - found === XFree86-font100dpi-4.2.0 depends on executable: imake - found === XFree86-font100dpi-4.2.0 depends on shared library: X11.6 - found === Patching for XFree86-font100dpi-4.2.0 === Configuring for XFree86-font100dpi-4.2.0 (cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/encodings imake -DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config -DTOPDIR=../../.. -DCURDIR=.; make Makefiles ; make includes ; make depend) making Makefiles in large... including in ./large... depending in ./large... (cd /usr/ports/x11-fonts/XFree86-4-font100dpi/work/xc/fonts/bdf/100dpi imake -DUseInstalled -DProjectRoot=/usr/X11R6 -I/usr/X11R6/lib/X11/config -DTOPDIR=../../.. -DCURDIR=.; make Makefiles ; make includes ; make depend) make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop *** Error code 2 -- Matthew Thyer Phone: +61 8 8259 7249 Science Corporate Information Systems Fax:+61 8 8259 5537 Defence Science and Technology Organisation, Edinburgh PO Box 1500 EDINBURGH South Australia 5111 IMPORTANT: This email remains the property of the Australian Defence Organisation and is subject to the jurisdiction of section 70 of the CRIMES ACT 1914. If you have received this email in error, you are requested to contact the sender and delete the email. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Crash dumps on current
On Tue, Jul 09, 2002 at 10:37:20AM -0700, Matthew Dillon wrote:
Welcome to -current. I haven't been able to get crash dumps to
work for a while :-(
I usually set up a serial console between two machines and run
gdb live to debug the kernel.
Crash dumps have been working oh so well for me recently. Seems like the
occasional panic resulting in a reboot will not leave a proper dump, but
here's one I got today:
blarf:/home/crash#gdb52 -k kernel.3 vmcore.3
GNU gdb 5.2 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you
are
welcome to change it and/or distribute copies of it under certain
conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-portbld-freebsd5.0...
IdlePTD at phsyical address 0x0054f000
initial pcb at physical address 0x0043f8a0
panicstr: from debugger
panic messages:
---
panic: Most recently used by none
panic: from debugger
Uptime: 58m32s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021ba80 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021bc24 in poweroff_wait (junk=0xc0376288, howto=-928630028)
at ../../../kern/kern_shutdown.c:489
#3 0xc016babd in db_panic () at ../../../ddb/db_command.c:449
#4 0xc016ba5f in db_command (last_cmdp=0xc03d3680, cmd_table=0xc0376288,
aux_cmd_tablep=0xc03ca120, aux_cmd_tablep_end=0x104)
at ../../../ddb/db_command.c:345
#5 0xc016bb28 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc016de51 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0339291 in kdb_trap (type=3, code=0, regs=0xc8a63b94)
at ../../../i386/i386/db_interface.c:161
#8 0xc03465c9 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061660800, tf_esi = 256, t
f_ebp = -928629800, tf_isp = -928629824, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_
eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070361369, tf_cs = 8, tf_eflags
= 662, tf_esp = -1069828632, tf_ss = -928629780})
at ../../../i386/i386/trap.c:604
#9 0xc03394e7 in Debugger (msg=0xc039733c panic) at cpufunc.h:68
#10 0xc021bc0f in panic (fmt=0xc03bb5e8 Most recently used by %s\n)
at ../../../kern/kern_shutdown.c:476
#11 0xc0316702 in mtrash_ctor (mem=0xc1ebf000, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc031676c in mtrash_fini (mem=0xc1ebf000, size=8192)
at ../../../vm/uma_dbg.c:186
#13 0xc0314a58 in zone_drain (zone=0xc0b85780) at ../../../vm/uma_core.c:646
#14 0xc031536e in zone_foreach (zfunc=0xc03147c2 zone_drain)
at ../../../vm/uma_core.c:1167
#15 0xc031626a in uma_reclaim () at ../../../vm/uma_core.c:1980
#16 0xc031242a in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:652
#17 0xc031310a in vm_pageout () at ../../../vm/vm_pageout.c:1429
#18 0xc020ca80 in fork_exit (callout=0xc0312ee0 vm_pageout, arg=0x0,
frame=0xc8a63d48) at ../../../kern/kern_fork.c:863
(kgdb)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: NEWCARD
the new code has been tweeked for gcc 3.1 in 3.1 you need foo[] in 2.95 you needed foo[0] you can follow the instructions in /usr/src/Makefile specifically the make buildkernel bit to make both the new compiler and build the kernel with it. On Mon, 8 Jul 2002, Kurt Erik Lindqvist wrote: [...] ../../../sys/proc.h:117: field `ar_args' has incomplete type *** Error code 1 Stop in /usr/src/sys/i386/compile/NEWCARD. *** Error code 1 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
What to do with witness verbiage (is this new?)?
After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 This is on a 2xP2-450 with a (for right now) UP kernel. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Here's another panic:
GNU gdb 5.2 (FreeBSD)
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-portbld-freebsd5.0...
IdlePTD at phsyical address 0x0054f000
initial pcb at physical address 0x0043f8a0
panicstr: bremfree: bp 0xc41c707c not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc26923f4
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02371a4
stack pointer = 0x10:0xc9b26aa8
frame pointer = 0x10:0xc9b26ab0
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 = 5431 (smtpd)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc41c707c not locked
Uptime: 1h29m28s
pfs_vncache_unload(): 2 entries remaining
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021ba80 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021bc24 in poweroff_wait (junk=0xc039e8e5, howto=-1004769156)
at ../../../kern/kern_shutdown.c:489
#3 0xc024e12d in bremfree (bp=0xc039e8e5) at ../../../kern/vfs_bio.c:620
#4 0xc024f8a4 in vfs_bio_awrite (bp=0xc41c707c)
at ../../../kern/vfs_bio.c:1594
#5 0xc01f653a in spec_fsync (ap=0xc9b26924)
at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01f612f in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02f72a4 in ffs_sync (mp=0xc19ab200, waitfor=2, cred=0xc0babe80,
td=0xc03fc760) at vnode_if.h:458
#8 0xc025c4fa in sync (td=0xc03fc760, uap=0x0)
at ../../../kern/vfs_syscalls.c:127
#9 0xc021b6ef in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc021bc24 in poweroff_wait (junk=0xc03c40be, howto=-1069794545)
at ../../../kern/kern_shutdown.c:489
#11 0xc0346a9c in trap_fatal (frame=0x100, eva=3261670388)
at ../../../i386/i386/trap.c:841
#12 0xc03467eb in trap_pfault (frame=0xc9b26a68, usermode=0, eva=3261670388)
at ../../../i386/i386/trap.c:755
#13 0xc03463f6 in trap (frame=
{tf_fs = 24, tf_es = -911081456, tf_ds = -1071579120, tf_edi = -104120,
tf_esi = -1033296960, tf_ebp = -911054160, tf_isp = -911054188, tf_ebx = -1044534044,
tf_edx = -1041338176, tf_ecx = 1, tf_eax = -1033296912, tf_trapno = 12, tf_err = 2,
tf_eip = -1071418972, tf_cs = 8, tf_eflags = 66118, tf_esp = -1044534068, tf_ss =
-1044534144}) at ../../../i386/i386/trap.c:445
#14 0xc02371a4 in selwakeup (sip=0xc1bdace4)
at ../../../kern/sys_generic.c:1186
#15 0xc0248cbe in sowakeup (so=0xc1bdac80, sb=0xc1bdaccc)
at ../../../kern/uipc_socket2.c:300
#16 0xc0248946 in soisconnected (so=0xc2679898)
at ../../../kern/uipc_socket2.c:132
#17 0xc024ce6a in unp_connect2 (so=0xc1d0e258, so2=0xc2679898)
at ../../../kern/uipc_usrreq.c:765
#18 0xc024cdec in unp_connect (so=0xc1d0e258, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_usrreq.c:737
#19 0xc024c15d in uipc_connect (so=0x0, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_usrreq.c:161
#20 0xc0246c0d in soconnect (so=0xc1d0e258, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_socket.c:429
#21 0xc0249fe9 in connect (td=0xc1ee70c0, uap=0xc9b26d14)
at ../../../kern/uipc_syscalls.c:440
#22 0xc0346d33 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 13, tf_esi = 0, tf_ebp =
-1077938264, tf_isp = -911053452, tf_ebx = 134731496, tf_edx = -1077938398, tf_ecx =
0, tf_eax = 98, tf_trapno = 22, tf_err = 2, tf_eip = 671994211, tf_cs = 31, tf_eflags
= 642, tf_esp = -1077938420, tf_ss = 47})
at ../../../i386/i386/trap.c:1045
#23 0xc033a62d in syscall_with_err_pushed () at /var/tmp//ccgOkQ7m.s:128
#24 0x080554d8 in ?? ()
#25 0x080555c1 in ?? ()
#26 0x080552d0 in ?? ()
#27 0x080553a4 in ?? ()
#28 0x080534cf in ?? ()
#29 0x0805363a in ?? ()
#30 0x080501d6 in ?? ()
#31 0x0804bcef in ?? ()
#32 0x08057aa5 in ?? ()
#33 0x0804c978 in ?? ()
#34 0x0804c909 in ?? ()
#35 0x0804e2ba in ?? ()
#36 0x0804e786 in ?? ()
#37 0x0804ab5d in ?? ()
#38 0x0804b5d2 in ?? ()
#39 0x0804b736 in ?? ()
#40 0x0804f6f5 in ?? ()
#41 0x0804f8fa in ?? ()
#42 0x0805ac31 in ?? ()
#43 0x0804ff74 in ?? ()
#44 0x0804b817 in ?? ()
#45 0x08049fc9 in ?? ()
(kgdb)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: bus_alloc_resrouce() fails in if_wi.c
On Tue, 9 Jul 2002, M. Warner Losh wrote: More of a dmesg would help debug this. Sure, full boot -v and pciconf -lv follows. -CURRENT is from right before KSE-III went in. To my untrained eye, the pcib1: device wi0 requested unsupported memory range 0x0-0xf41f looks suspect. How would that happen? -Paul. Copyright (c) 1992-2002 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.0-CURRENT #0: Sat Jun 29 23:52:40 PDT 2002 [EMAIL PROTECTED]:/u02/obj/u02/current-src/sys/mammoth Preloaded elf kernel /boot/kernel/kernel at 0xc05d2000. Preloaded elf module /boot/kernel/if_wi.ko at 0xc05d20b4. Preloaded elf module /boot/kernel/acpi.ko at 0xc05d2160. Calibrating clock(s) ... TSC clock: 1295988656 Hz, i8254 clock: 1193117 Hz CLK_USE_I8254_CALIBRATION not specified - using default frequency Timecounter i8254 frequency 1193182 Hz CLK_USE_TSC_CALIBRATION not specified - using old calibration method Timecounter TSC frequency 1296065907 Hz CPU: Pentium III/Pentium III Xeon/Celeron (1296.07-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE real memory = 132644864 (129536K bytes) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x005f9000 - 0x07ce, 124743680 bytes (30455 pages) 0x07d0 - 0x07e77fff, 1540096 bytes (376 pages) avail memory = 122417152 (119548K bytes) bios32: Found BIOS32 Service Directory header at 0xc00f6640 bios32: Entry = 0xfd7b0 (c00fd7b0) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xfd7b0+0x1f8 pnpbios: Found PnP BIOS data at 0xc00f66a0 pnpbios: Entry = f:915d Rev = 1.0 Other BIOS signatures found: random: entropy source mem: memory I/O Pentium Pro MTRR support enabled null: null device, zero device pci_open(1):mode 1 addr port (0x0cf8) is 0x8000f904 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71248086) Using $PIR table, 8 entries at 0xc00fdf40 npx0: math processor on motherboard npx0: INT 16 interface acpi0: PTLTDRSDT on motherboard acpi0: power button is handled as a fixed feature programming model. ACPI timer looks GOOD min = 3, max = 3, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 2 ACPI timer looks GOOD min = 3, max = 3, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 2 ACPI timer looks GOOD min = 3, max = 4, width = 2 ACPI timer looks GOOD min = 3, max = 3, width = 1 ACPI timer looks GOOD min = 3, max = 3, width = 1 ACPI timer looks GOOD min = 3, max = 4, width = 2 ACPI timer looks GOOD min = 3, max = 4, width = 2 ACPI timer looks GOOD min = 3, max = 4, width = 2 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_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: physical bus=0 found- vendor=0x8086, dev=0x7124, revid=0x03 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 map[10]: type 3, range 32, base f800, size 26, enabled map[14]: type 1, range 32, base f400, size 19, enabled found- vendor=0x8086, dev=0x7125, revid=0x03 bus=0, slot=1, func=0 class=03-00-00, hdrtype=0x00, mfdev=0 intpin=a, irq=10 powerspec 1 supports D0 D3 current D0 found- vendor=0x8086, dev=0x2418, revid=0x02 bus=0, slot=30, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 found- vendor=0x8086, dev=0x2410, revid=0x02 bus=0, slot=31, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 map[20]: type 4, range 32, base 10a0, size 4, enabled found- vendor=0x8086, dev=0x2411, revid=0x02 bus=0, slot=31, func=1 class=01-01-80, hdrtype=0x00, mfdev=0 map[20]: type 4, range 32, base 1080, size 5, enabled found- vendor=0x8086, dev=0x2412, revid=0x02 bus=0, slot=31, func=2 class=0c-03-00, hdrtype=0x00, mfdev=0 intpin=d, irq=11 map[20]: type 4, range 32, base 1100, size 4, enabled found- vendor=0x8086, dev=0x2413, revid=0x02 bus=0, slot=31, func=3 class=0c-05-00, hdrtype=0x00, mfdev=0 intpin=b, irq=9 map[10]: type 4, range 32, base 1200, size 8, enabled map[14]: type 4, range 32, base 1300, size 6, enabled found- vendor=0x8086, dev=0x2415, revid=0x02 bus=0, slot=31, func=5 class=04-01-00, hdrtype=0x00, mfdev=0 intpin=b, irq=9 pci0: PCI bus on acpi_pcib0 pci0: display, VGA at device 1.0 (no driver attached) pcib1: PCI-PCI bridge at device 30.0 on pci0 pcib1: secondary bus 1 pcib1: subordinate bus 1 pcib1: I/O decode0x2000-0x2fff pcib1: memory decode 0xf410-0xf41f pcib1: prefetched decode 0xf420-0xf42f pci1: physical bus=1 map[10]:
Re: Remember my ill-fated i386 smp pmap optimizations?
Peter Wemm wrote:
John Baldwin wrote:
On 08-Jul-2002 Peter Wemm wrote:
A few months ago, I had a bit of a disaster with some pmap optimizations.
After committing, all hell broke loose. It was backed out completely.
I finally found the problem (diff cleaned up to highlight the problem):
pmap_mapdev()
...
for (tmpva = va; size 0; ) {
pte = vtopte(tmpva);
*pte = pa | PG_RW | PG_V | pgeflag;
size -= PAGE_SIZE;
tmpva += PAGE_SIZE;
- pa += PAGE_SIZE;
}
invltlb();
Excuse me while I go outside and shoot myself.
Hahahaha!
Glad to see you have fixed them. :)
Unfortunately, there are still more problems. :-(
I've still got to find this one though:
TPTE at 0xbfca01f0 IS ZERO @ VA 2807c000
panic: bad peter
db trace
panic(c043087f,bfca01f0,2807c000,1,c040e9d7) at panic+0x84
pmap_remove_pages(c15d6ed0,0,bfc0,115,c028aee0) at pmap_remove_pages+0x9c
exit1(c15d5180,8b,c6,c24a0d04,0) at exit1+0x4f0
sigexit(c15d5180,b,c040fbb1,6e9,0) at sigexit+0x1b9
postsig(b,0,c0413100,e4,400) at postsig+0x11b
ast(d3aa5d48) at ast+0x328
doreti_ast() at doreti_ast+0x1a
ARGH! I think I found this one too. :-/
I think the fix [relative to the patch] is:
pmap_pte_quick()
...
/* are we current address space or kernel? */
if (pmap == kernel_pmap || frame == (PTDpde PG_FRAME))
return PTmap + index;
newpf = pde PG_FRAME;
if (((*PMAP1) PG_FRAME) != newpf) {
*PMAP1 = newpf | PG_RW | PG_V;
- pmap_invalidate_page(pmap, (vm_offset_t) PADDR1);
+ pmap_invalidate_page(kernel_pmap, (vm_offset_t) PADDR1);
}
return PADDR1 + (index (NPTEPG - 1));
*blush*. (read pmap_invalidate_page() in the diff to see why)
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Netgear MA401 pccard support?
- Original Message - From: M. Warner Losh [EMAIL PROTECTED] To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] Sent: Wednesday, July 10, 2002 7:05 AM Subject: Re: Netgear MA401 pccard support? In message: 046701c2279c$2878c4e0$0e81a8c0@gilgamesh Mauritz Sundell [EMAIL PROTECTED] writes: : I cant get my NETGEAR MA401 network pccard to work in CURRENT. Bummer. It works for other people. : I have a Compaq Evo N160 laptop. What kind of pccard/cardbus bridge do you have? TI1410 PCI-CardBus Bridge : Today I saw that the man-page for pcic(4) was updated (v.1.5) and stated : This does not work at all at the moment. That's just for older ISA devices. Most PCI devices work great. : It did work under 4.6-RELEASE ( I have not tried 4.6-STABLE). Maybe sending a dmesg from -stable would help. Alternatively, you should be able to run OLDCARD on -current. Warner I hope my dmesgs only come once, I have tried to send them twice:) Here they are inline (with some badly placed newlines): (I have not tried STABLE) Below are: ** 4.6-RELEASE: dmesg * *** 5.0-NEWCARD: dmesg 5.0-OLDCARD: dmesg (boot -v) *** 5.0-OLDCARD: dmesg 5.0-OLDCARD: pciconf -lv *** ** 4.6-RELEASE: dmesg * Copyright (c) 1992-2002 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 4.6-RELEASE #0: Tue Jun 11 06:14:12 GMT 2002 [EMAIL PROTECTED]:/usr/src/sys/compile/GENERIC Timecounter i8254 frequency 1193182 Hz CPU: Pentium III/Pentium III Xeon/Celeron (999.16-MHz 686-class CPU) Origin = GenuineIntel Id = 0x6b1 Stepping = 1 Features=0x383f9ffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,SEP,MTRR,PGE,MCA,C MOV,PAT,PSE36,MMX,FXSR,SSE real memory = 133562368 (130432K bytes) avail memory = 125050880 (122120K bytes) Preloaded elf kernel kernel at 0xc04d. Pentium Pro MTRR support enabled md0: Malloc disk Using $PIR table, 11 entries at 0xc00fdf10 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Host to PCI bridge on motherboard pci0: PCI bus on pcib0 pcib1: PCI to PCI bridge (vendor=8086 device=3576) at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: ATI model 4c59 graphics accelerator at 0.0 irq 11 uhci0: Intel 82801CA/CAM (ICH3) USB controller USB-A port 0x1840-0x185f irq 11 at device 29.0 on pci0 usb0: Intel 82801CA/CAM (ICH3) USB controller USB-A on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered uhci1: Intel 82801CA/CAM (ICH3) USB controller USB-B port 0x1860-0x187f irq 10 at device 29.1 on pci0 usb1: Intel 82801CA/CAM (ICH3) USB controller USB-B on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pcib2: PCI to PCI bridge (vendor=8086 device=2448) at device 30.0 on pci0 pci2: PCI bus on pcib2 pci2: unknown card (vendor=0x14f1, dev=0x2f00) at 4.0 pci2: unknown card (vendor=0x104c, dev=0x8023) at 5.0 pcic0: TI PCI-1410 PCI-CardBus Bridge irq 10 at device 6.0 on pci2 pcic0: PCI Memory allocated: 0x4400 pcic0: TI12XX PCI Config Reg: [ring enable][speaker enable][pwr save][CSC serial isa irq] pccard0: PC Card bus (classic) on pcic0 fxp0: Intel Pro/100 Ethernet port 0x3000-0x303f mem 0xd020-0xd0200fff irq 9 at device 8.0 on pci2 fxp0: Ethernet address 00:02:a5:9c:51:e3 inphy0: i82562ET 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isab0: PCI to ISA bridge (vendor=8086 device=248c) at device 31.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel ICH3 ATA100 controller port 0x1800-0x180f,0x374-0x377,0x170-0x177,0x3f4-0x3f7,0x1f0-0x1f7 at device 31.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: unknown card (vendor=0x8086, dev=0x2483) at 31.3 irq 5 pci0: unknown card (vendor=0x8086, dev=0x2485) at 31.5 irq 5 orm0: Option ROMs at iomem 0xc-0xcdfff,0xdb000-0xdbfff,0xdc000-0xd on isa0 fdc0: ready for input in output fdc0: cmd 3 failed at out byte 1 of 3 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model Generic PS/2 mouse, device ID 0 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 sio0 at port 0x3f8-0x3ff irq 4 flags 0x10 on isa0 sio0: type 16550A sio1: configured irq 3 not in bitmap of probed irqs 0 ppc0: Parallel port at port 0x378-0x37f irq 7 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/8 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 ata1-slave: ATA
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Alex Zepeda wrote After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). I haven't had any instability problems in a while on my UP box. Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? I don't have the pcm hardware. The only WITNESS message I consistently see is the kernel linker one. The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sparc64 tinderbox failure
-- Rebuilding the temporary build tree -- 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/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include -- stage 4: building libraries -- stage 4: make dependencies -- stage 4: building everything.. -- === lib/libxpg4 === lib/liby === lib/libz === bin === bin/cat === bin/chio === bin/chmod cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c: In function `main': /usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c:174: warning: null format string *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/bin/chmod. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/bin. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
_waitq_remove
While running (newly build) Xine I get following error: Fatal error '_waitq_remove: Not in queue' at line 350 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) Is this an outstanding KSE issue or a problem of the port itself? Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Marc To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 12:10:50PM +0200, Marc Recht wrote: While running (newly build) Xine I get following error: Fatal error '_waitq_remove: Not in queue' at line 350 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) Is this an outstanding KSE issue or a problem of the port itself? Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Marc I don't think this is KSE or even -CURRENT related. I get the same message with xine on -STABLE each time i use it. Xine is simply not very stable on FreeBSD, that's why I'm using mplayer now (which has it's own issues on -CURRENT) - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /usr/src/sys/vm/uma_core.c:1332: could sleep with kernel li
On 9 Jul, John Baldwin wrote: On 09-Jul-2002 Don Lewis wrote: I recently started seeing the warning message: /usr/src/sys/vm/uma_core.c:1332: could sleep with kernel linker locked from /usr/src/sys/kern/kern_linker.c:1797 at boot time on my -current box. It appears to be related to the changes in rev 1.90 of kern_linker.c. Turn on witness_ddb (set debug.witness_ddb to 1 in either the loader or via sysctl) and get a 'tr' from ddb to see the codepath in question. You can then 'c' continue to get back to running. You might want to do 'w witness_ddb 0' to keep from dropping back into ddb all the time before continuing. This problem is easily reproducable by just running sysctl -a. Here's the stack trace: witness_sleep() uma_zalloc_arg() vm_map_entry_create() vm_map_clip_start() vm_map_wire() vslock() sysctl_old_user() sysctl_kern_function_list_iterate() link_elf_each_function_name() sysctl_kern_function_list() ... The only fix I can think of is to do something like: grab the lock walk the list, counting the number of bytes the data occupies unlock retry: allocate a temporary buffer grab the lock walk the list, copying the data the data to the temporary buffer, halting the copy on overflow, but calculating the new size unlock if the buffer overflowed, free the buffer and goto retry copy the temporary buffer to user space free the buffer I suppose this could be simplified a bit by pretending to have a zero sized buffer and starting at the retry label, but in any case it sure is ugly. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
Alex Zepeda [EMAIL PROTECTED] writes: After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel Congratulations in turning your -CURRENT box into a doorstop! ;) DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
On Wed, Jul 10, 2002 at 12:12:56 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Consider following setup: OPIE is active and allow Unix plaintext passwords for local users only (i.e. common way of using OPIE). Then lets disable all sshd auth methods excepting PasswordAuthentication yes in sshd_config. Why? Why what? Sysadmin allows PasswordAuthentication only. 2nd bug is true: no OTP prompt in the scenario above. Because PasswordAuthentication is not OPIE. And I say so too. Why OPIE is in the middle (via PAM)? But you say, it is enhancement (apparently non-working due to missing OTP prompt). -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
VFS lock error in getnewvnode()
A box running this morning's -current compiled with DEBUG_VFS_LOCKS coughed up this error part way through a cvs update of the ports tree. VOP_GETVOBJECT: x is not locked but should be The stack trace is: getnewvnode() + 0x182 ffs_vget() + 0x73 ufs_lookup() + 0x10df vfs_vnoperate() + 0x13 ufs_cache_lookup() + 0x516 ufs_vnoperate() + 0x13 lookup() + 0x43b namei() + 0x1e4 lstat() I don't understand this error at all, because there is a call to vn_lock() immediately before the call to VOP_GETVOBJECT(). Once it hit this error, I turned off the vfs_badlock_panic switch, but the console continued to spew VFS lock errors for a variety of different vnode addresses. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
Andrey A. Chernov [EMAIL PROTECTED] writes: Why what? Sysadmin allows PasswordAuthentication only. Why? DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
On 10 Jul 2002, Marc Recht wrote: While running (newly build) Xine I get following error: Fatal error '_waitq_remove: Not in queue' at line 350 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) Is this an outstanding KSE issue or a problem of the port itself? Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Do you know when it broke? -- Dan Eischen To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
Kernel and world are of today. (cvusup'd 10:00 CEST). $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 2002/05/24 04:32:28 deischen Exp $ Do you know when it broke? Sorry, I've built today the first time. But, Christian (previous post) said he has the same problem with -STABLE. So, maybe it's a Xine problem. (Or libc_r is broken on both...) To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
I get the same message with xine on -STABLE each time i use it. Xine is simply not very stable on FreeBSD, that's why I'm using mplayer now Oh. :-) (which has it's own issues on -CURRENT) IIRC then MPlayer doesn't use threads. So, KSE shouldn't be an issue there. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
On Wed, Jul 10, 2002 at 14:17:51 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Why what? Sysadmin allows PasswordAuthentication only. Why? Because he choose to not trust hosts keys which can be stolen especially when not password-protected. Because it is documented way to configure sshd. This scenario is very equivalent to normal Unix login procedure excepting that passwords are not transferred as cleartext over the net. It is most easy way for admin to teach end-users to use ssh without (mis)dealing with hosts keys. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 02:38:51PM +0200, Marc Recht wrote: I get the same message with xine on -STABLE each time i use it. Xine is simply not very stable on FreeBSD, that's why I'm using mplayer now Oh. :-) (which has it's own issues on -CURRENT) IIRC then MPlayer doesn't use threads. So, KSE shouldn't be an issue there. The issue with mplayer is, that it crashes when i want to watch two consecutive files. The first one works fine, but when I want to play the second one, it crashes each time :) Very, very weird indeed... - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
Andrey A. Chernov [EMAIL PROTECTED] writes: On Wed, Jul 10, 2002 at 14:17:51 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Why what? Sysadmin allows PasswordAuthentication only. Why? Because he choose to not trust hosts keys which can be stolen especially when not password-protected. But why disable keyboard-interactive authentication? Really, Andrey, I get the feeling that you've shot yourself in the foot and are asking me why it hurts. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
On Wed, Jul 10, 2002 at 15:02:43 +0200, Dag-Erling Smorgrav wrote: But why disable keyboard-interactive authentication? There is nowhere documented that keyboard-interactive auth is required for PasswordAuthentication. It works without it for ages. Sysadmins tends to remove all unneded auth schemes to minimize compromise risk and left only few or even one auth scheme. Really, Andrey, I get the feeling that you've shot yourself in the foot and are asking me why it hurts. To shot yourself an additional action needed. But without any additional action I have untouched config files which works for ages and stop working now due to additional undocumented keyboard-interactive auth requirement or commenting out pam_opie* requirement. I think I am not only one with this setup type. Expect mass complaints when this goes to -stable, especially because of hidden nature of this bug. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
Andrey A. Chernov [EMAIL PROTECTED] writes: On Wed, Jul 10, 2002 at 15:02:43 +0200, Dag-Erling Smorgrav wrote: But why disable keyboard-interactive authentication? There is nowhere documented that keyboard-interactive auth is required for PasswordAuthentication. It works without it for ages. Sysadmins tends to remove all unneded auth schemes to minimize compromise risk and left only few or even one auth scheme. Andrey, I'd really suggest you back off and chill down. You're not making any sense at all. If your config file really disables all authentication methods except PasswordAuthentication, then OPIE *never* worked for you, because it *cannot* be implemented over the SSH PaswordAuthentication protocol. Expect mass complaints when this goes to -stable, especially because of hidden nature of this bug. It *is* in -STABLE. Nobody's complained. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
On Wed, Jul 10, 2002 at 15:37:11 +0200, Dag-Erling Smorgrav wrote: Andrey, I'd really suggest you back off and chill down. You're not making any sense at all. If your config file really disables all authentication methods except PasswordAuthentication, then OPIE *never* worked for you, because it *cannot* be implemented over the SSH PaswordAuthentication protocol. I say exact the same thing. 1) I not expect that OPIE will work at this place. 2) Moreover, I don't want OPIE here. 3) I don't need, don't want and not expect any OPIE, I want forget about it. But... 4) OPIE _automatically_ instered in the middle of auth against my will due to /etc/pam.d/sshd pam_opie* lines enabled by default. 5) OPIE is inserted inside the auth where it can't work in any case (inside PasswordAuthentication). 6) This bad OPIE insertion not documented anywhere in ssh manpages. Expect mass complaints when this goes to -stable, especially because of hidden nature of this bug. It *is* in -STABLE. Nobody's complained. Because of broken libopie (opieaccess). But someday -current fix will be merged. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
On Wed, Jul 10, 2002 at 15:37:11 +0200, Dag-Erling Smorgrav wrote: Andrey, I'd really suggest you back off and chill down. You're not making any sense at all. If your config file really disables all authentication methods except PasswordAuthentication, then OPIE *never* worked for you, because it *cannot* be implemented over the SSH PaswordAuthentication protocol. To make it short: you broke PaswordAuthentication auth by inserting OPIE there (via /etc/pam.d/sshd). Do you understand/confirm this statement? Could you please _remove_ OPIE from PaswordAuthentication, since according to your own words it *cannot* be implemented over the SSH PaswordAuthentication protocol ? -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On 10-Jul-2002 Archie Cobbs wrote: John Baldwin writes: code would be modified to fit this new behaviour, besides this, everywhere callout_stop() is used need to hold sched_lock and do a mi_switch() and modify td_flags is also unacceptable, this SMP race should be resolved in kern_timeout.c. How would you resolve it while still preserving the existing semantics? Saying this race should be resolved doesn't explain how you would go about resolving it. It's a lot harder than it looks. I don't know if this is the same problem or a different problem, but FWIW.. It is the same problem. What we do is change callout_stop() to let you know if it actually stopped the timeout or not. You then have to use your own locking and synchronization in the timeout function and yourself to close the rest of the race. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Patch for review (was Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd))
On Wed, Jul 10, 2002 at 15:37:11 +0200, Dag-Erling Smorgrav wrote: making any sense at all. If your config file really disables all authentication methods except PasswordAuthentication, then OPIE *never* worked for you, because it *cannot* be implemented over the SSH PaswordAuthentication protocol. OPIE should be not enabled by default since according to your own words it *cannot* be implemented over the SSH PaswordAuthentication protocol. PasswordAuthentication is very broken otherwise and not allows to log in. --- sshd.bakTue Jul 9 14:55:05 2002 +++ sshdWed Jul 10 19:16:54 2002 @@ -6,8 +6,8 @@ # auth auth requiredpam_nologin.so no_warn -auth sufficient pam_opie.so no_warn no_fake_prompts -auth requiredpam_opieaccess.so no_warn +#authsufficient pam_opie.so no_warn no_fake_prompts +#authrequiredpam_opieaccess.so no_warn auth requiredpam_unix.so no_warn try_first_pass # account -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: userret() , ast() and the end of syscalls
On 09-Jul-2002 Julian Elischer wrote: On Wed, 10 Jul 2002, Bruce Evans wrote: Can these flags be changed asynchronously? If so, then everything needs to be handled by ast() anyway. userret() should only check for work that needs doing in the usual case, and hopefully there is none (except for things like ktrace). That's an interestign way of thinking about it.. in that case, shouldn't ast() be called from within userret() instead of the other way around? userret() is called unconditionally from both trap() and syscall() (or just trap() on architectures where syscall() is called by trap()) if teh tast thing userret() did was to check if ast() should be called and to call it, it might simplify things.. also, should userret() then loop back to it's start if trap is called? It would need to, to simulate what it is doing now.. The test you refer to is done in MD code because ensuring atomicity involves doing MD things like disabling interrupts. It really works quite well the way it is atm. -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
John Baldwin writes: It is the same problem. What we do is change callout_stop() to let you know if it actually stopped the timeout or not. You then have to use your own locking and synchronization in the timeout function and yourself to close the rest of the race. OK, thanks. What do you think of the idea of letting the timer code (optionally) handle all the locking and race conditions? Even with callout_stop() returning 1 or 0, there still is *lots* of complexity required on the client side, especially when the object associated with the timer can be freed after stopping the timer, and you can have the same timer stopped and then restarted (which means that if you can't reliably stop the timer before starting another one, you can get an early timeout due to a previously not-stopped timer (which you have to check for (which is not trivial))). I beg you to look at netgraph/ng_pptpgre.c for an example of the gymnastics required. For example, you can't just use the object (in this case a netgraph node) as the void * argument to the timeout routine: you have to malloc() a separate structure containing just a pointer to the object, and then in the object itself have a pointer back to the malloc()'d structure. This is necessary so you can differentiate a real timer timeout from the previously stopped (but not really stopped) timer timeout if the timer was then restarted. In my experience, if the timer routines handle the locking life gets MUCH simpler for everyone else. -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for review (was Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd))
If I may suggest a fix that will probably make everyone happy... The problem seems to be the addition of opieaccess to the PAM configuration. With that addition, in -CURRENT, unless a user creates /etc/opieaccess and adds explicit permit lines, plain text passwords will not be accepted if OPIE is in use at the site. If that file does not exist, plain text passwords are explicitly denied. This breaks POLA. However, if /usr/src/contrib/opie/libopie/accessfile.c is changed to accept plain text passwords if the file does not exist (the normal case), then I believe people will be happy. Alternatively, we need to start distributing an /etc/opieaccess file that permit's every connection by default. So, to fix this: 1. Either this one line change to /usr/src/contrib/opie/libopie/accessfile.c From: if (!(fp = fopen(PATH_ACCESS_FILE, r))) return 0; To: if (!(fp = fopen(PATH_ACCESS_FILE, r))) return 1; Or add /etc/opieaccess with the line: permit 0.0.0.0 0.0.0.0 2. In -STABLE, merge src/lib/libopie/Makefile revs 1.14 and 1.15 to RELENG_4. Then merge which ever fix you do in #1 above, then it is safe to revert src/etc/pam.conf rev 1.6.2.16. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
gcc-3.1 Mozilla Build Fails
Maybe this would be more interesting to the mozilla guys but mozilla compiles on 2.95.3, so I think, the problem is related to gcc-3.1 (cd /usr/ports/www/mozilla/work/mozilla/dist/bin; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regxpcom; echo skin,install,select,classic/1.0 chrome/installed-chrome.txt; echo locale,install,select,en-US chrome/installed-chrome.txt; /usr/bin/env LD_LIBRARY_PATH=. MOZILLA_FIVE_HOME=. ./regchrome) Type Manifest File: /usr/ports/www/mozilla/work/mozilla/dist/bin/components/xpti.dat nsNativeComponentLoader: autoregistering begins. nsNativeComponentLoader: autoregistering succeeded ###!!! ASSERTION: never called: 'Error', file ../../../../dist/include/xpconnect/xpc_map_end.h, line 143 ###!!! Break: at file ../../../../dist/include/xpconnect/xpc_map_end.h, line 143 [1] 24584 Segmentation fault (core dumped) *** Error code 139 Stop in /usr/ports/www/mozilla. My gdb tells me, that: #0 0x284274c0 in nsXPCException::CanGetProperty(nsID const*, unsigned short const*, char**) (this=0x80bcdb8, iid=0xbfbfee40, propertyName=0x2815d70a, _retval=0x8) at xpcexception.cpp:506 506 *_retval = xpc_CheckAccessList(propertyName, allowed); (gdb) print _retval $1 = (char **) 0x8 (gdb) up #1 0x2815d751 in XPTC_InvokeByIndex (that=0x80b5940, methodIndex=12, paramCount=3217025902, params=0xbfbfee40) at xptcinvoke_unixish_x86.cpp:88 88 __asm__ __volatile__( (gdb) up #2 0x28441f8a in XPCWrappedNative::CallMethod(XPCCallContext, XPCWrappedNative::CallMode) (ccx=@0xbfbfef00, mode=CALL_METHOD) at xpcwrappednative.cpp:2025 2025invokeResult = XPTC_InvokeByIndex(callee, vtblIndex, paramCount, dispatchParams); (gdb) print paramCount $1 = 1 '\001' And this seems a bit strange, parameter 3 seems to be wrong. I am not a C++ Crack, so, anyone can help? #0 /usr/ports/www/mozilla/work/mozilla/js/src/xpconnect/src/xpcexception.cpp:506 #1 /usr/ports/www/mozilla/work/mozilla/xpcom/reflect/xptcall/src/md/unix/xptcinvoke_unixish_x86.cpp #2 /usr/ports/www/mozilla/work/mozilla/js/src/xpconnect/src/xpcwrappednative.cpp:2025 Regards, erdgeist - fnord! id 0x17B701E5 size 1024 | type rsa 11F8 8FF3 0508 09F9 DC6A 2AB3 AA67 C8CF To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t -CURRENT when trying to build ports/x11/XFree86-4
--- Thyer, Matthew [EMAIL PROTECTED] wrote: make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop *** Error code 2 -- Try: build ports/lang/perl and set env PERL to /usr/local/bin/perl __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 02:43:54AM -0700, Don Lewis wrote: I haven't had any instability problems in a while on my UP box. Seems like the UP kernels are more unstable for me. Go figure. ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. This happened just before the box fell over (I'm now running a different kernel.. SMP.. so far so good). What's the downside to sticking debug.witness_ddb=1 in /etc/sysctl.conf? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
In the last episode (Jul 10), Don Lewis said: On 10 Jul, Alex Zepeda wrote After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). I haven't had any instability problems in a while on my UP box. Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? I don't have the pcm hardware. The only WITNESS message I consistently see is the kernel linker one. The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. I see this one once every 10 seconds or so: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 -- Dan Nelson [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On 10-Jul-2002 Archie Cobbs wrote: John Baldwin writes: It is the same problem. What we do is change callout_stop() to let you know if it actually stopped the timeout or not. You then have to use your own locking and synchronization in the timeout function and yourself to close the rest of the race. OK, thanks. What do you think of the idea of letting the timer code (optionally) handle all the locking and race conditions? I'm not sure it can in a clean fashion since of the few cases I've known so far each client needs a customized solution. I am open to ideas though. I'm also open to some redesign of how callouts work to begin with (maybe using other threads than the one running softclock() to actually execute callout handlers, etc.). -- John Baldwin [EMAIL PROTECTED]http://www.FreeBSD.org/~jhb/ Power Users Use the Power to Serve! - http://www.FreeBSD.org/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for review (was Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd))
On Wed, Jul 10, 2002 at 09:37:24 -0700, Gregory Neil Shapiro wrote: The problem seems to be the addition of opieaccess to the PAM configuration. Not to PAM, but more strictly, to PAMified sshd. Addition of it to other PAMified programs works as expected. With that addition, in -CURRENT, unless a user creates /etc/opieaccess and adds explicit permit lines, plain text passwords will not be accepted if OPIE is in use at the site. If that file does not exist, plain text passwords are explicitly denied. This breaks POLA. Yes. However, if /usr/src/contrib/opie/libopie/accessfile.c is changed to accept plain text passwords if the file does not exist (the normal case), then I believe people will be happy. Alternatively, we need to start distributing an /etc/opieaccess file that permit's every connection by default. No. F.e. I have a rule in /etc/opieaccess which allow local plaintext passwords and disallow them for remote access. This is typical setup needed for most OPIE-aware programs. When pam_opie* added to sshd PasswordAuthenticate auth (by default), I can't login from remote, but still can from local. So, back to your proposal: 1) If /etc/opieaccess will not exists, other OPIE-aware programs will be broken (not tuned well for local/remote difference). 2) If /etc/opieaccess will have permit lines for all, other OPIE-aware programs will be broken (not tuned well for local/remote difference). BTW, changing documented OPIE way of things is not good from security reasons. 3) If /etc/opieaccess have correct permit line for local and not for remote, other OPIE-aware programs are happy, but sshd is broken (can't login from remote but can from local). So, your fix attempt really not fix things, only removing OPIE from PasswordAuthenticate fix them. OPIE not works with PasswordAuthenticate in any case, as DES himself confirms and what I say from the very beginning. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for review (was Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd))
Neither fix is correct. The correct solution is to remove the kludge in auth-passwd.c that tries to use PAM for password authentication. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
[ NOTE: I'm moving this discussion to [EMAIL PROTECTED] ]
John Baldwin writes:
What do you think of the idea of letting the timer code (optionally)
handle all the locking and race conditions?
I'm not sure it can in a clean fashion since of the few cases I've known
so far each client needs a customized solution. I am open to ideas though.
I'm also open to some redesign of how callouts work to begin with (maybe
using other threads than the one running softclock() to actually execute
callout handlers, etc.).
FWIW, here is an API I've used before. This handles all race
conditions and the 'other thread' question.
struct timer_event; /* opaque structure */
typedef struct timer_event *timer_handle_t; /* caller's timer handle */
typedef void timer_func_t(void *arg); /* timeout function type */
/* flags for timer_start() */
#define TIMER_RECURRING 0x0001 /* timer is recurring */
#define TIMER_OWN_THREAD0x0002 /* handle in separate thread */
extern int timer_start(timer_handle_t *handlep, mutex_t *mutexp,
timer_func_t tfunc, void *arg, u_int delay,
int flags);
extern void timer_cancel(timer_handle_t *handlep);
extern int timer_remaining(timer_handle_t handle, u_int *delayp);
static inline int
timer_isrunning(timer_handle_t handle)
{
return (handle != NULL);
}
Semantics:
1. The caller supplies a pointer to the 'handle', which must initially
be NULL. The handle != NULL if and only if the timer is running.
2. timer_cancel() guarantees that tfunc() will not be called subsequently
3. *handlep is set to NULL by timer_cancel() and by the timer expiring.
So when *handlep is NULL when tfunc() is invoked (unless TIMER_RECURRING).
4. Calling timer_start() or timer_stop() from within tfunc() is OK.
5. If TIMER_RECURRING, timer started again before calling tfunc()
6. If TIMER_OWN_THREAD, timer runs in a newly created thread (rather
than the timer service thread), which means that tfunc() may sleep
or be canceled. If tfunc() sleeps or the thread is canceled but
TIMER_OWN_THREAD was not set - panic.
7. If mutexp != NULL, *mutexp is acquired before calling tfunc() and
released after it returns.
Items 1, and 2 are guaranteed only if mutexp != NULL and the caller
acquires *mutexp before any calls to timer_start() or timer_cancel()
(you would normally be doing this anyway).
Errors:
- timer_start() returns EBUSY if *handlep != NULL
- timer_remaining() returns ESRCH if handle != NULL
The model is: you have some object that has an associated lock and
one or more associated timers. The object is to be locked whenever
you muck with it (including when you start, stop, or handle a timer):
struct foobar {
struct lock mutex;
timer_handle_t timer1;
timer_handle_t timer2;
...
};
Then all calls to the timer_* routines are well behaved and the
timeout thread caling tfunc() never races with any other thread
that may be stopping or starting the timer, or destroying the object.
E.g., to destroy the object, the following suffices:
void
foobar_destroy(struct foobar *f)
{
mutex_lock(f-mutex);
timer_cancel(f-timer1);
timer_cancel(f-timer2);
mutex_unlock(f-mutex);
free(f);
}
The only remaining complexity for the caller is that if you have
any TIMER_OWN_THREAD handlers which unlock the object (e.g., in order
to go to sleep), then you need to reference count the object and
have a FOOBAR_INVALID flag.
If you are working under a different model then this API may not
be appropriate, but at least in my multi-threading experience this
model is very typical.
-Archie
__
Archie Cobbs * Packet Design * http://www.packetdesign.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
RE: userret() , ast() and the end of syscalls
On Wed, 10 Jul 2002, John Baldwin wrote: On 09-Jul-2002 Julian Elischer wrote: On Wed, 10 Jul 2002, Bruce Evans wrote: Can these flags be changed asynchronously? If so, then everything needs to be handled by ast() anyway. userret() should only check for work that needs doing in the usual case, and hopefully there is none (except for things like ktrace). That's an interestign way of thinking about it.. I think of ast() as the real userret(). Splitting them is an implementation detail. The real userret() has to be very close to the return to user mode, since the return needs to be atomic with checking for things that need to be done before return, so you need fairly strong locking and don't want to hold the lock for very long. in that case, shouldn't ast() be called from within userret() instead of the other way around? No; that would pessimize userret() and break ast(). ast() is the real userret() so i needs to do more. userret() is called unconditionally from both trap() and syscall() (or just trap() on architectures where syscall() is called by trap()) if teh tast thing userret() did was to check if ast() should be called and to call it, it might simplify things.. also, should userret() then loop back to it's start if trap is called? It would need to, to simulate what it is doing now.. The test you refer to is done in MD code because ensuring atomicity involves doing MD things like disabling interrupts. It really works quite well the way it is atm. John moved the loop into ast() where it is easier to understand, but Matt made him move it back. There would be little point in userret() repeating the loop, since it has to open up a race window on return and then it would miss state changes. These should be seen later by ast(). Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Timeout and SMP race
On Wed, 10 Jul 2002, Archie Cobbs wrote: John Baldwin writes: It is the same problem. What we do is change callout_stop() to let you know if it actually stopped the timeout or not. You then have to use your own locking and synchronization in the timeout function and yourself to close the rest of the race. OK, thanks. What do you think of the idea of letting the timer code (optionally) handle all the locking and race conditions? Even with callout_stop() returning 1 or 0, there still is *lots* of complexity required on the client side, especially when the object associated with the timer can be freed after stopping the timer, and you can have the same timer stopped and then restarted (which means that if you can't reliably stop the timer before starting another one, you can get an early timeout due to a previously not-stopped timer (which you have to check for (which is not trivial))). I beg you to look at netgraph/ng_pptpgre.c for an example of the gymnastics required. For example, you can't just use the object (in this case a netgraph node) as the void * argument to the timeout routine: you have to malloc() a separate structure containing just a pointer to the object, and then in the object itself have a pointer back to the malloc()'d structure. This is necessary so you can differentiate a real timer timeout from the previously stopped (but not really stopped) timer timeout if the timer was then restarted. In my experience, if the timer routines handle the locking life gets MUCH simpler for everyone else. I certainly agree that mayb ewe should look at supplying support in teh timeout code for handling this race.. I've had my mind bent by it a few too many times, and I'm starting to think There's got to be a better way Archie.. can you pu tup a strawman proposal for the API chenge needed? -Archie __ Archie Cobbs * Packet Design * http://www.packetdesign.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
Christian Brueffer writes: The issue with mplayer is, that it crashes when i want to watch two consecutive files. The first one works fine, but when I want to play the second one, it crashes each time :) Have you tried using a playlist ? I've played maybe 20 files in a row doing that. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On 2002-07-10 09:58 +, Dag-Erling Smorgrav wrote:
=== bin/chmod
cc1: warnings being treated as errors
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c: In function `main':
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c:174: warning: null format
string
How does this look for fixing this warning?
%%%
Index: chmod.c
===
RCS file: /home/ncvs/src/bin/chmod/chmod.c,v
retrieving revision 1.25
diff -u -r1.25 chmod.c
--- chmod.c 30 Jun 2002 05:13:52 - 1.25
+++ chmod.c 10 Jul 2002 17:22:22 -
@@ -171,7 +171,7 @@
}
if ((ftsp = fts_open(++argv, fts_options, 0)) == NULL)
- err(1, NULL);
+ err(1, %s: %s, *argv, strerror(p-fts_errno));
for (rval = 0; (p = fts_read(ftsp)) != NULL;) {
switch (p-fts_info) {
case FTS_D: /* Change it at FTS_DP. */
%%%
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
wait for 5.0-RELEASE?
I'm building a new primary office workstation and thought I might try -current instead of 4.6-STABLE in order to make upgrading to 5.0-RELEASE easier. Will this make it easier to upgrade to 5.0-RELEASE when that happens, or does it not really matter? Regards, Graham __ Do You Yahoo!? Sign up for SBC Yahoo! Dial - First Month Free http://sbc.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: wait for 5.0-RELEASE?
+ Graham Guttocks wrote: | I'm building a new primary office workstation and | thought I might try -current instead of 4.6-STABLE | in order to make upgrading to 5.0-RELEASE easier. | | Will this make it easier to upgrade to 5.0-RELEASE | when that happens, or does it not really matter? Running -current is not a good idea. It is a development stream not intended for general usage. It is not guaranteed to work properly at any given time, and features are not necessarily complete. The upgrade path from 4.X to 5.0 will be well planned by the FreeBSD team, so it would be in your best interests to stick with the stable stream. -- Steve Tremblett To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Dan Nelson wrote: I see this one once every 10 seconds or so: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I've never seen that one. I'll take a look at the code, though. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On 10 Jul, Alex Zepeda wrote: On Wed, Jul 10, 2002 at 02:43:54AM -0700, Don Lewis wrote: I haven't had any instability problems in a while on my UP box. Seems like the UP kernels are more unstable for me. Go figure. ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. This happened just before the box fell over (I'm now running a different kernel.. SMP.. so far so good). What's the downside to sticking debug.witness_ddb=1 in /etc/sysctl.conf? It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 09:32:07PM +0200, Gary Jennejohn wrote: Christian Brueffer writes: The issue with mplayer is, that it crashes when i want to watch two consecutive files. The first one works fine, but when I want to play the second one, it crashes each time :) Have you tried using a playlist ? I've played maybe 20 files in a row doing that. --- Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] No, I've always been using 'open file'. Thanks for the hint, I'll try that out. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
Dag-Erling Smorgrav wrote: Alex Zepeda [EMAIL PROTECTED] writes: After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel Congratulations in turning your -CURRENT box into a doorstop! ;) Magician: For my fisrt trick, I shall install -current! Audience: Oooh! Magician: Now I will attempt to obtain a crash dump... this is a very dangerous trick... very few magicians alive today can perform this trick, although in the past, it was very common... Audience: Aaah! Magician: For my next trick, I will turn on WITNESS! Please be quiet! Many magicians have died doing this! Audience: Oooh! Magician: And for my final trick of the evening, I will throw this frisbee so that it lands under a car, just out of reach... Man (to wife): I think I'm beginning to see a pattern... -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd)
Andrey A. Chernov wrote: On Wed, Jul 10, 2002 at 14:17:51 +0200, Dag-Erling Smorgrav wrote: Andrey A. Chernov [EMAIL PROTECTED] writes: Why what? Sysadmin allows PasswordAuthentication only. Why? Because he choose to not trust hosts keys which can be stolen especially when not password-protected. Because it is documented way to configure sshd. This scenario is very equivalent to normal Unix login procedure excepting that passwords are not transferred as cleartext over the net. It is most easy way for admin to teach end-users to use ssh without (mis)dealing with hosts keys. I think he meant Why doesn't it respect the secure flag on pty's in /etc/ttys, like all other conforming UNIX programs do?. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Giorgos Keramidas [EMAIL PROTECTED] writes: How does this look for fixing this warning? No, gcc should accept a NULL format string for err(3). It looks like __printf0like is broken. DES -- Dag-Erling Smorgrav - [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Wed, 10 Jul 2002, Giorgos Keramidas wrote:
On 2002-07-10 09:58 +, Dag-Erling Smorgrav wrote:
=== bin/chmod
cc1: warnings being treated as errors
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c: In function `main':
/usr/home/des/tinderbox/sparc64/src/bin/chmod/chmod.c:174: warning: null format
string
How does this look for fixing this warning?
%%%
Index: chmod.c
===
RCS file: /home/ncvs/src/bin/chmod/chmod.c,v
retrieving revision 1.25
diff -u -r1.25 chmod.c
--- chmod.c 30 Jun 2002 05:13:52 - 1.25
+++ chmod.c 10 Jul 2002 17:22:22 -
@@ -171,7 +171,7 @@
}
if ((ftsp = fts_open(++argv, fts_options, 0)) == NULL)
- err(1, NULL);
+ err(1, %s: %s, *argv, strerror(p-fts_errno));
for (rval = 0; (p = fts_read(ftsp)) != NULL;) {
switch (p-fts_info) {
case FTS_D: /* Change it at FTS_DP. */
%%%
The main bug is that the warning is emitted. err(1, NULL) is perfectly
valid (see err(4)). Apparently the sparc64 compiler is missing support
for __printf0like.
Bruce
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On 2002-07-10 14:22 +, Matthew Dillon wrote: :Giorgos Keramidas [EMAIL PROTECTED] writes: : How does this look for fixing this warning? : :No, gcc should accept a NULL format string for err(3). It looks like :__printf0like is broken. Oops. I've already starting changing the calls to err(). I would really like buildworld to work and there aren't too many of them, and besides a little more verboseness for some of these failures is not a bad thing. The extra verboseness is fine, and I was almost finished posting a note that mentioned it. But I didn't thinking that the __printf0like bugs will never be fixed if we hide them by patching chmod. Nevertheless, I do agree that a more verbose error message is likely to be an improvement in this particular case. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
: :Giorgos Keramidas [EMAIL PROTECTED] writes: : How does this look for fixing this warning? : :No, gcc should accept a NULL format string for err(3). It looks like :__printf0like is broken. : :DES :-- :Dag-Erling Smorgrav - [EMAIL PROTECTED] Oops. I've already starting changing the calls to err(). I would really like buildworld to work and there aren't too many of them, and besides a little more verboseness for some of these failures is not a bad thing. I'm going to finish what I've been doing and if someone has a real huge chip on their shoulder and can't handle the strain then they can fix __printf0like and then back-out some or all of my changes with my permission. Personally speaking, as much as GCC annoys me it is sometimes better to modify the utility code then to add yet another hack to GCC that needs to be synchronized every time we update. -Matt Matthew Dillon [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Bruce Evans [EMAIL PROTECTED] writes:
The main bug is that the warning is emitted. err(1, NULL) is perfectly
valid (see err(4)). Apparently the sparc64 compiler is missing support
for __printf0like.
Strangely, my Alpha (July 3 -CURRENT) complains about this too, but my
i386 (June 24 -CURRENT) doesn't. Here's my test program:
#include stdio.h
int
main(void)
{
printf(NULL);
return 0;
}
on Alpha, I get
des@dsa ~% gcc -Wformat -c /tmp/format.c
/tmp/format.c: In function `main':
/tmp/format.c:6: warning: null format string
on i386, I don't get a warning.
DES
--
Dag-Erling Smorgrav - [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Thu, 11 Jul 2002, Giorgos Keramidas wrote: The extra verboseness is fine, and I was almost finished posting a note that mentioned it. But I didn't thinking that the __printf0like bugs will never be fixed if we hide them by patching chmod. It was fixed more than a month ago: % RCS file: /home/ncvs/src/contrib/gcc/c-format.c,v % Working file: c-format.c % head: 1.4 % ... % % revision 1.3 % date: 2002/05/22 16:37:09; author: obrien; state: Exp; lines: +83 -6 % 1/2assed reimplementation of c-common.c revs 1.2 (-fformat-extensions) % and 1.3 (printf0) for GCC 3.1. % The printf0 part always worked on i386's and doesn't seem to have any machine dependencies. Bruce To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: _waitq_remove
Fatal error '_waitq_remove: Not in queue' at line 350 in file /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) I get the same message with xine on -STABLE each time i use it. I've had this problem for months if not years, in all recent releases of FreeBSD. It's not consistent, sometimes (like right now) I can run xine dozens of times without getting an error, other times I have to run it six times before it works. I haven't been able to pin down a common factor (for example, running 4 xines at once doesn't seem to make it any more likely). -- Richard To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Update to the DRM
I've posted a diff to the DRM at http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.ta -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
On Wed, 2002-07-10 at 17:17, Eric Anholt wrote: I've posted a diff to the DRM at http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.ta Evolution's send button is way too big. http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.diff is the file. The patch brings the current DRM from DRI CVS into the system. It includes PCI Rage 128 support and support for transform, clipping, lighting (TCL) hardware on Radeons. Another user and I have been banging on it with DRI CVS X Servers on Radeon, and I've tested it with several other cards with DRI CVS. What is probably least tested is using 4.2.0 X Servers with the new DRM, I'll work on that soon. I'm looking for testers of this code in -current. Hopefully this will support 4.2.0 as well as the old code did, in which case I would like to commit this soon. -- Eric Anholt [EMAIL PROTECTED] http://people.freebsd.org/~anholt/dri/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
On Wednesday, July 10, 2002, at 05:22 PM, Matthew Dillon wrote: [snips] Personally speaking, as much as GCC annoys me it is sometimes better to modify the utility code then to add yet another hack to GCC that needs to be synchronized every time we update. -Matt Matthew Dillon [EMAIL PROTECTED] Amen! These hacks also place some things nearly out of reach (such as cross-compilability from Solaris). Just how _does_ one build a functional cross-toolchain for FreeBSD on a non-FreeBSD host? Cheers, Jerry Hicks [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Update to the DRM
Eric Anholt wrote: I've posted a diff to the DRM at http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.ta http://people.freebsd.org/~anholt/dri/files/currentdrm-20020709.diff -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Matthew Dillon wrote: : :Giorgos Keramidas [EMAIL PROTECTED] writes: : How does this look for fixing this warning? : :No, gcc should accept a NULL format string for err(3). It looks like :__printf0like is broken. : :DES :-- :Dag-Erling Smorgrav - [EMAIL PROTECTED] Oops. I've already starting changing the calls to err(). Please do not. gcc is just a tool. If it emits a warning on some arches because gcc doesn't understand how our libraries work, then we should disable the gcc checking for those arches on those functions. ie: remove the __printf0like completely for #ifdef sparc64 for err() etc. eg: --- cdefs.h 2002/07/08 16:43:35 1.56 +++ cdefs.h 2002/07/10 23:18:10 @@ -174,9 +174,9 @@ __attribute__((__format__ (__scanf__, fmtarg, firstvararg))) #endif /* Compiler-dependent macros that rely on FreeBSD-specific extensions. */ -#if __FreeBSD_cc_version = 31 +#if __FreeBSD_cc_version = 31 !defined(__sparc64__) #define__printf0like(fmtarg, firstvararg) \ __attribute__((__format__ (__printf0__, fmtarg, firstvararg))) #else #define__printf0like(fmtarg, firstvararg) This is much much less disruptive than slashing through userland and fixing something that is already perfectly correct and legal. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Dag-Erling Smorgrav wrote:
Bruce Evans [EMAIL PROTECTED] writes:
The main bug is that the warning is emitted. err(1, NULL) is perfectly
valid (see err(4)). Apparently the sparc64 compiler is missing support
for __printf0like.
Strangely, my Alpha (July 3 -CURRENT) complains about this too, but my
i386 (June 24 -CURRENT) doesn't. Here's my test program:
#include stdio.h
int
main(void)
{
printf(NULL);
return 0;
}
on Alpha, I get
des@dsa ~% gcc -Wformat -c /tmp/format.c
/tmp/format.c: In function `main':
/tmp/format.c:6: warning: null format string
on i386, I don't get a warning.
Stranger and stranger.. On sparc64 from:
peter@panther[4:21pm]~-104 uname -a
FreeBSD panther.freebsd.org FreeBSD 5.0-CURRENT #2: Sun Jul 7 20:52:14 PDT 2002er
peter@panther[4:21pm]~-105 cat foo.c
#include stdio.h
#include err.h
int
main(void)
{
printf(NULL);
err(1, NULL);
return 0;
}
peter@panther[4:22pm]~-106 cc -O -Wformat -c foo.c
peter@panther[4:22pm]~-107
ie: it looks like it is completely disabled. Maybe the sparc64 tinderbox
host is simply out of sync with -current?
Cheers,
-Peter
--
Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED]
All of this is for nothing if we don't go to the stars - JMS/B5
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Peter Wemm [EMAIL PROTECTED] writes: [...] peter@panther[4:22pm]~-106 cc -O -Wformat -c foo.c peter@panther[4:22pm]~-107 ie: it looks like it is completely disabled. Maybe the sparc64 tinderbox host is simply out of sync with -current? It has a kernel/world of June 27, which seems to be the problem. I'll update the system today, but we should probably disable fatal warnings during the build/cross tools phase of world. Best regards, Mike Barcroft To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Patch for review (was Re: OPIE auth broken too (was Re: PasswordAuthentication not works in sshd))
On Wed, Jul 10, 2002 at 19:55:19 +0200, Dag-Erling Smorgrav wrote: Neither fix is correct. The correct solution is to remove the kludge in auth-passwd.c that tries to use PAM for password authentication. I agree completely. My fix was quick dirty workaround only and not planned as a full solution. -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Thus spake Peter Wemm [EMAIL PROTECTED]: Please do not. gcc is just a tool. If it emits a warning on some arches because gcc doesn't understand how our libraries work, then we should disable the gcc checking for those arches on those functions. ie: remove the __printf0like completely for #ifdef sparc64 for err() etc. ... This is much much less disruptive than slashing through userland and fixing something that is already perfectly correct and legal. I agree that there's little sense in changing the code to work around a compiler bug, but it does not follow that the change is inherently a bad idea. I tend to think of adding descriptive error messages as something that should have been done long ago, and just happens to be slightly more useful now. The change buys us the time to figure out what's really wrong with gcc, rather than disabling and ignoring the offending warnings on sparc64. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Whoever fixes this, and however we agree to fix it, should also remember to close the bin/40382 PR. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t -CURRENT when trying to build ports/x11/XFree86-4
Doesn't seem to work for me with PERL defined in my environment and/or in
/etc/make.conf.
make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop
*** Error code 2
Stop in /usr/ports/x11-fonts/XFree86-4-font100dpi.
*** Error code 1
Stop in /usr/ports/x11/XFree86-4.
fuzz: {1025} env | grep PERL
PERL=/usr/local/bin/perl
fuzz: {1026} grep PERL /etc/make.conf
PERL=/usr/local/bin/perl
fuzz: {1027} pkg_info | grep perl
perl-5.6.1_6Practical Extraction and Report Language
-Original Message-
From: Shizuka Kudo [mailto:[EMAIL PROTECTED]]
Sent: Thursday, 11 July 2002 3:04 AM
To: Thyer, Matthew; '[EMAIL PROTECTED]'
Subject: Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on
v.recen t -CURRENT when trying to build ports/x11/XFree86-4
--- Thyer, Matthew [EMAIL PROTECTED] wrote:
make: don't know how to make /usr/X11R6/bin/ucs2any.pl. Stop
*** Error code 2
--
Try:
build ports/lang/perl and set env PERL to /usr/local/bin/perl
__
Do You Yahoo!?
Sign up for SBC Yahoo! Dial - First Month Free
http://sbc.yahoo.com
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Status of C++ in base system?
Hi All, I'm using current from just after the KSE libc_r fix. However it appears that XFree86-client c++ stuff is still broken. Is there a planned time when this will be fixed or am I missing something else? (XFree-libraries compiled and installed without a hitch ). rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs/glxinfo. *** Error code 1 Cheers, Benjamin -- 3D Research Associate+61 8 8302 3669 School of Computer and Information Science Room D1-07, Levels Campus University of South AustraliaMawson Lakes Blvd. [EMAIL PROTECTED] South Australia, 5095 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
RE: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t -CURRENT when trying to build ports/x11/XFree86-4
Thanks Dirk but I cant install ports/x11/XFree86-4-clients either! Errors below a gcc 3.1 ism maybe ? installing in programs/scripts... /usr/bin/install -c -m 0755 xon.sh /usr/X11R6/bin/xon install in programs/scripts done installing in programs/glxinfo... rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' collect2: ld returned 1 exit status *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs/glxinfo. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc. *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients. -Original Message- From: Dirk Engling [mailto:[EMAIL PROTECTED]] Sent: Thursday, 11 July 2002 3:13 AM To: [EMAIL PROTECTED] Subject: Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.recen t -CURRENT when trying to build ports/x11/XFree86-4 Just make /usr/ports/x11/XFree86-4-clients before XFree86-4, that worked fine with me Regards erdgeist - fnord! id 0x17B701E5 size 1024 | type rsa 11F8 8FF3 0508 09F9 DC6A 2AB3 AA67 C8CF To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of C++ in base system?
On Thu, Jul 11, 2002 at 11:01:04AM +0930, Benjamin Close wrote: Hi All, I'm using current from just after the KSE libc_r fix. However it appears that XFree86-client c++ stuff is still broken. Is there a planned time when this will be fixed or am I missing something else? (XFree-libraries compiled and installed without a hitch ). rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib /usr/X11R6/lib/libGLU.so: undefined reference to `operator new[](unsigned)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__si_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete(void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `__gxx_personality_v0' /usr/X11R6/lib/libGLU.so: undefined reference to `__cxa_pure_virtual' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator delete[](void*)' /usr/X11R6/lib/libGLU.so: undefined reference to `vtable for __cxxabiv1::__vmi_class_type_info' /usr/X11R6/lib/libGLU.so: undefined reference to `operator new(unsigned)' *** Error code 1 Stop in /usr/ports/x11/XFree86-4-clients/work/xc/programs/glxinfo. *** Error code 1 this was a pretty easy fix, I edited the makefile in work/xc/programs/glxinfo and changed the 'cc' program to be 'c++', then it compiled fine. This is an error in the makefile, not a bsd problem... maybe we should have a patch to fix this? Cheers, Benjamin -- 3D Research Associate+61 8 8302 3669 School of Computer and Information Science Room D1-07, Levels Campus University of South AustraliaMawson Lakes Blvd. [EMAIL PROTECTED] South Australia, 5095 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message -- -Erik [EMAIL PROTECTED] [http://math.smsu.edu/~erik] The opinions expressed by me are not necessarily opinions. In all probability, they are random rambling, and to be ignored. Failure to ignore may result in severe boredom or confusion. Shake well before opening. Keep Refrigerated. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.r ecen t -CURRENT when trying to build ports/x11/XFree86-4
Thyer, Matthew wrote: Thanks Dirk but I cant install ports/x11/XFree86-4-clients either! Errors below a gcc 3.1 ism maybe ? Almost certainly a compiler mixup. Did you install a binary package? Secondly.. you have: rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib Note that cc will not link in libstdc++.so. The new and delete primatives have been moved from libgcc.a to libstdc++.so.4, so if you compile and link a c++ executable, you MUST either use c++ instead of cc, or explicitly add -lstdc++ to the command line. The example above that you pasted does neither. Finally.. If you are really stuck here, may I suggest make -i all install on the port? ie: ignore errors. You might end up missing out on having /usr/X11R6/bin/glxinfo installed, but I would wager that you will not miss it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:34:50PM -0700, Don Lewis wrote: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I've never seen that one. I'll take a look at the code, though. I'm seeing the same (once at bootup tho). sm:blarf:~$uptime 8:48PM up 18:52, 4 users, load averages: 0.11, 0.06, 0.01 sm:blarf:~$ Sweet. Oddly the SMP kernels seem a tad more stable. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Status of C++ in base system?
I'm not sure what the deal with X is, but I have several non-X11 C++ programs that work just fine. Warner To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Giorgos Keramidas [EMAIL PROTECTED] writes:
Whoever fixes this, and however we agree to fix it,
should also remember to close the bin/40382 PR.
Comments on the attached, untested patch?
Best regards,
Mike Barcroft
Disable fatal warnings during bootstrap, build, and cross tools
phase of world.
Index: Makefile.inc1
===
RCS file: /work/repo/src/Makefile.inc1,v
retrieving revision 1.294
diff -u -r1.294 Makefile.inc1
--- Makefile.inc1 1 Jul 2002 17:51:43 - 1.294
+++ Makefile.inc1 11 Jul 2002 04:50:02 -
@@ -589,8 +589,8 @@
${_cxx_consumers} gnu/usr.bin/texinfo
cd ${.CURDIR}/${_tool}; \
${MAKE} DIRPRFX=${_tool}/ obj; \
- ${MAKE} DIRPRFX=${_tool}/ depend; \
- ${MAKE} DIRPRFX=${_tool}/ all; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true depend; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true all; \
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install
.endfor
@@ -624,7 +624,8 @@
.for _tool in bin/csh bin/sh ${_games} gnu/usr.bin/cc/cc_tools ${_fortran} \
${_libroken4} ${_libkrb5} lib/libncurses ${_share} \
usr.bin/awk usr.bin/file usr.sbin/sysinstall
- cd ${.CURDIR}/${_tool}; ${MAKE} DIRPRFX=${_tool}/ build-tools
+ cd ${.CURDIR}/${_tool}; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true build-tools
.endfor
#
@@ -650,8 +651,8 @@
gnu/usr.bin/cc ${_xlint}
cd ${.CURDIR}/${_tool}; \
${MAKE} DIRPRFX=${_tool}/ obj; \
- ${MAKE} DIRPRFX=${_tool}/ depend; \
- ${MAKE} DIRPRFX=${_tool}/ all; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true depend; \
+ ${MAKE} DIRPRFX=${_tool}/ NO_WERROR=true all; \
${MAKE} DIRPRFX=${_tool}/ DESTDIR=${MAKEOBJDIRPREFIX} install
.endfor
RE: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.r ecen t -CURRENT when trying to build ports/x11/XFree86-4
My entire machine is built from source. I started with no packages installed at all. The only think I can think of is old binaries/libraries/other files left behind from earlier -CURRENT. Is there a tool to clean these up yet? Maybe it should be part of mergemaster. I'll clean them up manually and see if that fixes it. I dont have an /etc/malloc.conf Significant part of my /etc/make.conf is: CFLAGS=-O -pipe COPTFLAGS=-O -pipe USA_RESIDENT=no XFREE86_VERSION=4 HAVE_MOTIF=yes WITH_MOTIF=yes WITH_PNG_MMX=yes WITH_GNOME=yes WITH_GTK=yes WITH_TK83=yes WITH_OGGVORBIS=yes WITH_SANE=yes A4=yes I'll experiment with a cut down make.conf too. -Original Message- From: Peter Wemm [mailto:[EMAIL PROTECTED]] Sent: Thursday, 11 July 2002 12:32 PM To: Thyer, Matthew Cc: 'Dirk Engling'; 'FreeBSD-CURRENT' Subject: Re: don't know how to make /usr/X11R6/bin/ucs2any.pl. on v.r ecen t -CURRENT when trying to build ports/x11/XFree86-4 Thyer, Matthew wrote: Thanks Dirk but I cant install ports/x11/XFree86-4-clients either! Errors below a gcc 3.1 ism maybe ? Almost certainly a compiler mixup. Did you install a binary package? Secondly.. you have: rm -f glxinfo LD_LIBRARY_PATH=../../exports/lib cc -o glxinfo -ansi -pedantic -Dasm=__asm -Wall -Wpointer-arith -L../../exports/lib glxinfo.o -lGLU -lGL -lXext -lX11 -L/usr/X11R6/lib -lc_r -lm -Wl,-rpath,/usr/X11R6/lib Note that cc will not link in libstdc++.so. The new and delete primatives have been moved from libgcc.a to libstdc++.so.4, so if you compile and link a c++ executable, you MUST either use c++ instead of cc, or explicitly add -lstdc++ to the command line. The example above that you pasted does neither. Finally.. If you are really stuck here, may I suggest make -i all install on the port? ie: ignore errors. You might end up missing out on having /usr/X11R6/bin/glxinfo installed, but I would wager that you will not miss it. Cheers, -Peter -- Peter Wemm - [EMAIL PROTECTED]; [EMAIL PROTECTED]; [EMAIL PROTECTED] All of this is for nothing if we don't go to the stars - JMS/B5 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: sparc64 tinderbox failure
Bruce, On Thu, Jul 11, 2002 at 08:23:06AM +1000, Bruce Evans wrote: The extra verboseness is fine, and I was almost finished posting a note that mentioned it. But I didn't thinking that the __printf0like bugs will never be fixed if we hide them by patching chmod. It was fixed more than a month ago: sorry, -current from July, 10: === roadstone# cd /usr/src/bin/chmod/ roadstone# ls CVS Makefilechmod.1 chmod.c roadstone# make clean rm -f chmod chmod.o chmod.1.gz chmod.1.cat.gz roadstone# make cc -O -pipe -mcpu=ev5 -Werror -Wall -Wno-format-y2k -Wno-uninitialized -Wformat=2 -Wno-format-extra-args -Werror -c /net/storage/FreeBSD/src/bin/chmod/chmod.c cc1: warnings being treated as errors /net/storage/FreeBSD/src/bin/chmod/chmod.c: In function `main': /net/storage/FreeBSD/src/bin/chmod/chmod.c:174: warning: null format string *** Error code 1 Stop in /net/storage/FreeBSD/src/bin/chmod. roadstone# === Road Stone is Alpha AXP EV6 DECChip 21264 machine. The printf0 part always worked on i386's and doesn't seem to have any machine dependencies. I hope you are right. :) Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
