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 -- ===> usr.bin/top In file included from /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:30: /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:75:27: sys/syslimits.h: No such file or directory /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:105:27: machine/param.h: No such file or directory /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sparc64/usr/include/sys/param.h:107:28: machine/limits.h: No such file or directory In file included from /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:32: /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:22:20: stdio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:24:21: string.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:25:21: memory.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/contrib/top/os.h:26:21: stdlib.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:33:19: stdio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:34:19: nlist.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:35:18: math.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:36:17: kvm.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:37:17: pwd.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:38:23: sys/errno.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:39:24: sys/sysctl.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:40:24: sys/dkstat.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:41:22: sys/file.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:43:22: sys/proc.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:44:22: sys/user.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:45:25: sys/vmmeter.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:46:26: sys/resource.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:47:24: sys/rtprio.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:50:20: stdlib.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:52:20: unistd.h: No such file or directory /usr/home/des/tinderbox/sparc64/src/usr.bin/top/machine.c:53:62: osreldate.h: No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory cc: installation problem, cannot exec `cpp0': No such file or directory mkdep: compile failed *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.bin/top. *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/src/usr.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
Re: Page faults from bento cluster (Re: Problems reading vmcores)
On 31 Aug, Kris Kennaway wrote: > panic: page fault > panic messages: > --- > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x4 Looks like a NULL structure pointer dereference. It looks like the access is four bytes into the structure. > #7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607 > #8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10) > at /usr/src/sys/kern/kern_exec.c:280 > #9 0xc03a8a31 in syscall (frame= > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp = >-1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx = >135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31, >tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47}) > at /usr/src/sys/i386/i386/trap.c:1050 > #10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140 > ---Can't read userspace from dump, or kernel process--- I've seen other reports of similar crashes on the list. What version of imgact_elf.c is this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Aug 31 22:28:29 PDT 2002 -- ===> aic7xxx/ahc (null): Unable to malloc scope object *** Error code 70 Stop in /local0/scratch/des/src/sys/modules/aic7xxx/ahc. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules/aic7xxx. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
why pay $35.00 when you can get better service for $14.95
LATEST NEWS: The new domain names are finally available to the general public at discount prices. Now you can register one of the exciting new .BIZ or .INFO domain names, as well as the original .COM and .NET names for just $14.95. These brand new domain extensions were recently approved by ICANN and have the same rights as the original .COM and .NET domain names. The biggest benefit is of-course that the .BIZ and .INFO domain names are currently more available. i.e. it will be much easier to register an attractive and easy-to-remember domain name for the same price. Visit: http://www.affordable-domains.com today for more info. Register your domain name today for just $14.95 at: http://www.affordable-domains.com/ Registration fees include full access to an easy-to-use control panel to manage your domain name in the future. Sincerely, Domain Administrator Affordable Domains To remove your email address from further promotional mailings from this company, click here: http://www.centralremovalservice.com/cgi-bin/domain-remove.cgi (e3)2546mEwQ5-744iAuM8195fXrJ4-346bVnF0707zRjD3-856vNfA9207sKbV8-757nFzR3106jDvN7-@73 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another one. I have the cores if anyone needs to look at them..otherwise I'll stop posting these for now. Kris panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x4 fault code = supervisor read, page not present instruction pointer = 0x8:0xc021cd13 stack pointer = 0x10:0xda326a50 frame pointer = 0x10:0xda326a58 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 = 9298 (sh) trap number = 12 panic: page fault Uptime: 4h36m51s Dumping 510 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345 #2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #4 0xc03a83d2 in trap_pfault (frame=0xda326a10, usermode=0, eva=4) at /usr/src/sys/i386/i386/trap.c:760 #5 0xc03a7efd in trap (frame= {tf_fs = 24, tf_es = -634257392, tf_ds = -1069219824, tf_edi = -634229836, tf_esi = -1069110816, tf_ebp = -634230184, tf_isp = -634230212, tf_ebx = 40, tf_edx = 3, tf_ecx = -725475328, tf_eax = 0, tf_trapno = 12, tf_err = 0, tf_eip = -1071526637, tf_cs = 8, tf_eflags = 66199, tf_esp = -725475328, tf_ss = 1}) at /usr/src/sys/i386/i386/trap.c:446 #6 0xc0399a48 in calltrap () at {standard input}:98 #7 0xc021d91f in exec_elf32_imgact (imgp=0xda326bb4) at imgact_elf.c:607 #8 0xc022a9a2 in execve (td=0xc484c240, uap=0xda326d10) at /usr/src/sys/kern/kern_exec.c:280 #9 0xc03a8a31 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135022716, tf_esi = 0, tf_ebp = -1077940704, tf_isp = -634229388, tf_ebx = 135022736, tf_edx = 135022736, tf_ecx = 135022895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134697908, tf_cs = 31, tf_eflags = 659, tf_esp = -1077940748, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050 #10 0xc0399a9d in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- msg42364/pgp0.pgp Description: PGP signature
Re: Page faults from bento cluster (Re: Problems reading vmcores)
Another page fault in umount panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02012ed stack pointer = 0x10:0xda021b1c frame pointer = 0x10:0xda021b30 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 = 40889 (umount) trap number = 12 panic: page fault Uptime: 1h54m17s Dumping 510 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345 #2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #4 0xc03a83d2 in trap_pfault (frame=0xda021adc, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:760 #5 0xc03a7efd in trap (frame= {tf_fs = -637403112, tf_es = -1071120368, tf_ds = -989069296, tf_edi = 0, tf_esi = -989006984, tf_ebp = -637396176, tf_isp = -637396216, tf_ebx = -637396056, tf_edx = -1006065664, tf_ecx = 0, tf_eax = -637396056, tf_trapno = 12, tf_err = 0, tf_eip = -1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -637396056, tf_ss = 104}) at /usr/src/sys/i386/i386/trap.c:446 #6 0xc0399a48 in calltrap () at {standard input}:98 #7 0xc029198d in vflush (mp=0xc5e6, rootrefs=0, flags=2) at vnode_if.h:309 #8 0xc0200eaa in devfs_unmount (mp=0xc5e6, mntflags=524288, td=0xc5855000) at /usr/src/sys/fs/devfs/devfs_vfsops.c:130 #9 0xc028d9b4 in dounmount (mp=0xc5e6, flags=-974782464, td=0xc5855000) at /usr/src/sys/kern/vfs_mount.c:1296 #10 0xc028d79c in unmount (td=0xc5855000, uap=0xda021d10) at /usr/src/sys/kern/vfs_mount.c:1239 #11 0xc03a8a31 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134950973, tf_ebp = -1077938936, tf_isp = -637395596, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514, tf_esp = -1077939060, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050 #12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- msg42363/pgp0.pgp Description: PGP signature
Page faults from bento cluster (Re: Problems reading vmcores)
I worked out what was wrong: some of them were very old vmcores that had never been saved. There's another problem though, because those machines have all panicked in the past 24 hours, so I don't know where the remaining dumps went. Kris panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02012ed stack pointer = 0x10:0xd7b24b1c frame pointer = 0x10:0xd7b24b30 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 = 88342 (umount) trap number = 12 panic: page fault Uptime: 10h9m31s Dumping 510 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345 #2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #4 0xc03a83d2 in trap_pfault (frame=0xd7b24adc, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:760 #5 0xc03a7efd in trap (frame= {tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977731568, tf_edi = 0, tf_esi = -977701728, tf_ebp = -676181200, tf_isp = -676181240, tf_ebx = -676181080, tf_edx = -1006065664, tf_ecx = 0, tf_eax = -676181080, tf_trapno = 12, tf_err = 0, tf_eip = -1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676181080, tf_ss = 104}) at /usr/src/sys/i386/i386/trap.c:446 #6 0xc0399a48 in calltrap () at {standard input}:98 #7 0xc029198d in vflush (mp=0xc4a75400, rootrefs=0, flags=2) at vnode_if.h:309 #8 0xc0200eaa in devfs_unmount (mp=0xc4a75400, mntflags=524288, td=0xc41b29c0) at /usr/src/sys/fs/devfs/devfs_vfsops.c:130 #9 0xc028d9b4 in dounmount (mp=0xc4a75400, flags=-995666944, td=0xc41b29c0) at /usr/src/sys/kern/vfs_mount.c:1296 #10 0xc028d79c in unmount (td=0xc41b29c0, uap=0xd7b24d10) at /usr/src/sys/kern/vfs_mount.c:1239 #11 0xc03a8a31 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 134845070, tf_esi = 134951997, tf_ebp = -1077938952, tf_isp = -676180620, tf_ebx = 0, tf_edx = 1, tf_ecx = 3, tf_eax = 22, tf_trapno = 12, tf_err = 2, tf_eip = 134524579, tf_cs = 31, tf_eflags = 514, tf_esp = -1077939076, tf_ss = 47}) at /usr/src/sys/i386/i386/trap.c:1050 #12 0xc0399a9d in Xint0x80_syscall () at {standard input}:140 ---Can't read userspace from dump, or kernel process--- panic: page fault panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x28 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02012ed stack pointer = 0x10:0xd7b27b1c frame pointer = 0x10:0xd7b27b30 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 = 50685 (umount) trap number = 12 panic: page fault Uptime: 10h24m57s Dumping 510 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 213 /usr/src/sys/kern/kern_shutdown.c: No such file or directory. in /usr/src/sys/kern/kern_shutdown.c (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213 #1 0xc0242ed4 in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345 #2 0xc024310b in panic () at /usr/src/sys/kern/kern_shutdown.c:493 #3 0xc03a86f3 in trap_fatal (frame=0x104, eva=0) at /usr/src/sys/i386/i386/trap.c:846 #4 0xc03a83d2 in trap_pfault (frame=0xd7b27adc, usermode=0, eva=40) at /usr/src/sys/i386/i386/trap.c:760 #5 0xc03a7efd in trap (frame= {tf_fs = -676200424, tf_es = -1071120368, tf_ds = -977862640, tf_edi = 0, tf_esi = -977815232, tf_ebp = -676168912, tf_isp = -676168952, tf_ebx = -676168792, tf_edx = -1005847040, tf_ecx = 0, tf_eax = -676168792, tf_trapno = 12, tf_err = 0, tf_eip = -1071639827, tf_cs = 8, tf_eflags = 66118, tf_esp = -676168792, tf_ss = 104}) at /usr/src/sys/i386/i386/trap.c:446 #6 0xc0399a48 in calltrap () at {standard input}:98 #7 0xc029198d in vflush (mp=0xc58d6c00, rootrefs=0, flags=2) at vnode_if.h:309 #8 0xc0200eaa in devfs_unmount (mp=0xc58d6c00, mntflags=524288, td=0xc41b2a80) at /usr/src/sys/fs/devfs/devfs_vfsops.c:130 #9 0xc028d9b4 in dounmount (mp=0xc58
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
David O'Brien wrote: > > Because rather than leaving it alone for a while, they are already > > planning a 3.3. 8-). > > > > And comments on this list to that effect. > > I don't follow. The GCC group branches previous to a release and makes > an initial + point releases from it. I thought it was the general consensus that the 3.1 version of the compiler was broken, and generated bad code, and that the 3.2 compiler had a lot of these problems corrected, but destroyed binary compatability with 3.1. I guess the fear is that, if they are willing to destroy binary compatability between point releases, with another point release in the wings, it would be risky to pick the point release one behind to standardise upon. It was my understanding that FreeBSD 5.0 release was not going to be GCC 3.3 (because GCC 3.3 would not be released in time for FreeBSD to not be "pulling a RedHat" if they shipped a beta and called it 3.3) , might be GCC 3.2, and was currently down-rev from there. > How is this different from FreeBSD? > (other than they branch much before the .0 release and we don't). FreeBSD has been been branched for 18 months before the 5.0 release; what are you talking about?!? There's not much more "much" than that, in the entire history of GCC. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: > On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: > > On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > > > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > > > > > I'm having difficulty reading vmcore images with gdb (either the > > > > system version or the port). > > > > > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > > > > > >But you need to specify the -k flag to gdb to use it against kernel > > >dumps, I'm sure it will give much better results :) > > > > Oops, pasted the wrong thing: > > > > gohan10# gdb -k kernel.debug vmcore.0 > > GNU gdb 5.2.0 (FreeBSD) 20020627 > > 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-undermydesk-freebsd"... > > /a/vmcore.0: Undefined error: 0. > > Also > > gohan10# bin/gdb52 -k kernel.debug vmcore.0 > 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"... > /a/vmcore.0: Bad file descriptor. Sorry, I can't help you: I never uncountered this behavior, and certainly not on the recent kernel dumps I have under the hood. PS: I must admit I was a bit surprised by your initial post, I have classified it in the 'he must be aspleep / under caffeined ' category :) - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
On Sat, Aug 31, 2002 at 03:06:08PM -0700, Terry Lambert wrote: > David O'Brien wrote: > > On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: > > > In general, though, the answer is that "3.1 sucks and 2.9x > > > does not". 8-). > > > > Feh. 3.1's optimizer is less buggy in my experience. > > > > > Use at least GCC 3.2, if you feel compelled to use a buggy > > > non-maintenance release level GCC; alternately, wait for 3.3. > > > > What in the world are you trying to say?? > > "non-maintenance release"??? Why do you think 3.2 is buggy?? > > Because rather than leaving it alone for a while, they are already > planning a 3.3. 8-). > > And comments on this list to that effect. I don't follow. The GCC group branches previous to a release and makes an initial + point releases from it. How is this different from FreeBSD? (other than they branch much before the .0 release and we don't). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
David O'Brien wrote: > On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: > > In general, though, the answer is that "3.1 sucks and 2.9x > > does not". 8-). > > Feh. 3.1's optimizer is less buggy in my experience. > > > Use at least GCC 3.2, if you feel compelled to use a buggy > > non-maintenance release level GCC; alternately, wait for 3.3. > > What in the world are you trying to say?? > "non-maintenance release"??? Why do you think 3.2 is buggy?? Because rather than leaving it alone for a while, they are already planning a 3.3. 8-). And comments on this list to that effect. -- Terry To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 03:00:43PM -0700, Kris Kennaway wrote: > On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > > > I'm having difficulty reading vmcore images with gdb (either the > > > system version or the port). > > > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > > > >But you need to specify the -k flag to gdb to use it against kernel > >dumps, I'm sure it will give much better results :) > > Oops, pasted the wrong thing: > > gohan10# gdb -k kernel.debug vmcore.0 > GNU gdb 5.2.0 (FreeBSD) 20020627 > 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-undermydesk-freebsd"... > /a/vmcore.0: Undefined error: 0. Also gohan10# bin/gdb52 -k kernel.debug vmcore.0 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"... /a/vmcore.0: Bad file descriptor. Kris msg42357/pgp0.pgp Description: PGP signature
Re: Problems reading vmcores
On Sat, Aug 31, 2002 at 11:42:01PM +0200, Yann Berthier wrote: > On Sat, 31 Aug 2002, Kris Kennaway wrote: > > > I'm having difficulty reading vmcore images with gdb (either the > > system version or the port). > > > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 > >But you need to specify the -k flag to gdb to use it against kernel >dumps, I'm sure it will give much better results :) Oops, pasted the wrong thing: gohan10# gdb -k kernel.debug vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 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-undermydesk-freebsd"... /a/vmcore.0: Undefined error: 0. Kris msg42356/pgp0.pgp Description: PGP signature
emu10k1 maintainer
Is there still someone maintaining the emu10k1 driver, or the pcm driver in general? -mg To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems reading vmcores
On Sat, 31 Aug 2002, Kris Kennaway wrote: > I'm having difficulty reading vmcore images with gdb (either the > system version or the port). > > (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 But you need to specify the -k flag to gdb to use it against kernel dumps, I'm sure it will give much better results :) regards, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Problems reading vmcores
I'm having difficulty reading vmcore images with gdb (either the system version or the port). (gdb) gohan10# gdb /a/kernel.debug /a/vmcore.0 GNU gdb 5.2.0 (FreeBSD) 20020627 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-undermydesk-freebsd"... "/a/vmcore.0" is not a core dump: File format not recognized I have a lovely collection of panics from the bento cluster over the last 12 hours, but no way to get tracebacks. savecore: reboot after panic: ufs_dirbad: bad dir savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: sleeping thread owns a mutex savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: page fault savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: pipe buffer gone savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 savecore: reboot after panic: Most recently used by AD driver savecore: unable to open bounds file, using 0 savecore: writing core to vmcore.0 Kris msg42353/pgp0.pgp Description: PGP signature
Re: bin/42255: Truss segfaults when tracing sshd
On Sat, Aug 31, 2002 at 05:45:26PM +0200, Anders Nordby wrote: > # truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'` > > Log into the system with sshd, and truss will segfault: There is an even easier way to reproduce this: gonzo 9% sleep 10 & [2] 35245 gonzo 10% truss -p 35245 *segfaults* It is actually just strcmping a NULL syscall name, which can happen if you truss a process which is waiting for a syscall to return when you first attach to the process. The patch below seems to fix the problem, but I Matthew would like a more complex fix. David. ndex: syscalls.c === RCS file: /cvs/FreeBSD-CVS/src/usr.bin/truss/syscalls.c,v retrieving revision 1.25 diff -u -r1.25 syscalls.c --- syscalls.c 7 Aug 2002 11:35:18 - 1.25 +++ syscalls.c 31 Aug 2002 21:10:51 - @@ -411,7 +411,7 @@ if (trussinfo->flags & FOLLOWFORKS) len += fprintf(trussinfo->outfile, "%5d: ", trussinfo->pid); - if (!strcmp(name, "execve") || !strcmp(name, "exit")) { + if (name != NULL && (!strcmp(name, "execve") || !strcmp(name, "exit"))) { clock_gettime(CLOCK_REALTIME, &trussinfo->after); } To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
On Tue, Aug 27, 2002 at 05:55:18PM -0700, Terry Lambert wrote: > In general, though, the answer is that "3.1 sucks and 2.9x > does not". 8-). Feh. 3.1's optimizer is less buggy in my experience. > Use at least GCC 3.2, if you feel compelled to use a buggy > non-maintenance release level GCC; alternately, wait for 3.3. What in the world are you trying to say?? "non-maintenance release"??? Why do you think 3.2 is buggy?? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 02:06:54PM -0500, Dan Nelson wrote: > In the last episode (Aug 28), Jens Schweikhardt said: > > On Wed, Aug 28, 2002 at 07:35:32PM +0200, Sheldon Hearn wrote: > > # On (2002/08/28 19:04), Jens Schweikhardt wrote: > > # > Yes, use plain TERM=xterm. It's got color now as it should. I'm > > # > thinking of removing xterm-color if I can't resolve the > > # > enter_alt_charset_mode stuff. Let me know if TERM=xterm does not > > # > work as expected in mutt et al. I'll post a minor HEADS UP to > > # > current@. > > # > > # Doesn't work for centericq or mutt. > > > > Are you sure? I use mutt too (in an rxvt), and TERM=xterm works > > wonderfully with colors. Hang on, will test mutt in plain xterm... > > yes, works there too. > > Older versions of the mutt port used the slang terminal library, which > had (has?) a bug that assumed that all xterms supported color. It > didn't matter what your termcap says. This is *totally* UNTRUE: /usr/local/bin//mutt: libslang.so => /usr/local/lib/libslang.so (0x280e5000) libm.so.2 => /usr/lib/libm.so.2 (0x28148000) libssl.so.2 => /usr/lib/libssl.so.2 (0x28167000) libcrypto.so.2 => /usr/lib/libcrypto.so.2 (0x28199000) libxpg4.so.3 => /usr/lib/libxpg4.so.3 (0x28263000) libintl.so.2 => /usr/local/lib/libintl.so.2 (0x28265000) libiconv.so.3 => /usr/local/lib/libiconv.so.3 (0x2826c000) libncurses.so.5 => /usr/lib/libncurses.so.5 (0x2834) libc.so.5 => /usr/lib/libc.so.5 (0x28382000) note the use of libslang. TERM=xterm and not having COLORTERM set, mutt will not use colors. TERM=xterm and COLORTERM=yes, mutt will use colors. TERM=xterm-color (COLORTERM set or not), mutt will use colors. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 07:06:40PM +0200, Jens Schweikhardt wrote: > # Mutt shows this when I start vi as my editor or run fetchmail: > # > # "TERMCAP", line 0, terminal 'xterm-color': enter_alt_charset_mode but no acs_chars > # > # My centericq window ends up using pipe signs (|), minus signs (-) and > # plus signs (+) to draw boxes. . > Please use plain TERM=xterm which now has color support. If any problems > remain, please let me know. Are you saying to try TERM=xterm as a test, or that TERM=xterm-color is not longer supported? If the second, that is unacceptable. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: CURRENT's termcap broken
On Wed, Aug 28, 2002 at 09:41:05PM +0200, Jens Schweikhardt wrote: > 20020827: >Our /etc/termcap now has all the entries from the XFree86 xterm >almost unchanged. This means xterm now supports color by default. >If you used TERM=xterm-color in the past you now should use >TERM=xterm. (xterm-color will lead to benign warnings). This is unacceptable -- you are breaking cross-platform (even -stable to -current) logins. TERM=xterm-color should work just as well and w/o warnings it did before your commit. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 5.0 release schedule?
On Wed, Aug 28, 2002 at 09:28:20AM -0400, Bosko Milekic wrote: > > I think we're on our way to stabilizing -CURRENT enough for a DP2 > soon. I would sit and wait it out just a tad longer. :-) A 5.0 DP2 branch was created just yesterday. So how ever good yesterday's -current was will affect DP2. I rather expected the release engineers to at least querry the lists to ask what the known issues are before picking which code to base DP2 on. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 10:52:09 -0700, George V. Neville-Neil wrote: > I think this is in -STABLE not -CURRENT, I'm having this problem there. The problem is in -current too, see my following optional ahc ahd bug explanation, aicasm target inserted only when _both_ of them are enabled. -- 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: New SCSI: can't 'make depend'
I think this is in -STABLE not -CURRENT, I'm having this problem there. Later, George -- George V. Neville-Neil [EMAIL PROTECTED] Neville-Neil Consulting www.neville-neil.com "I learn only to be contented." inscription at Ryoan-ji in Kyoto, Japan To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 21:39:40 +0400, Andrey A. Chernov wrote: > > I wonder about > optional ahc ahd > line here. Is it assumes that _both_ must be on? Yes, it was the bug place. Here is the workaround which fix it for me: --- files.bak Sat Aug 31 20:46:30 2002 +++ files Sat Aug 31 21:40:55 2002 @@ -4,7 +4,7 @@ # limitations in config: backslash-newline doesn't work in strings, and # dependency lines other than the first are silently ignored. # -aicasm optional ahc ahd \ +aicasm optional ahc \ dependency "$S/dev/aic7xxx/aicasm/*.[chyl]" \ compile-with"${MAKE} -f $S/dev/aic7xxx/aicasm/Makefile MAKESRCPATH=$S/dev/aic7xxx/aicasm" \ no-obj no-implicit-rule\ -- Andrey A. Chernov http://ache.pp.ru/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Sat Aug 31 10:40:36 PDT 2002 -- ===> aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /local0/scratch/des/src/sys/modules/aic7xxx. *** Error code 1 Stop in /local0/scratch/des/src/sys/modules. *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** Error code 1 Stop in /local0/scratch/des/src. *** Error code 1 Stop in /local0/scratch/des/src. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 11:15:55 -0600, Justin T. Gibbs wrote: > > Apparently Makefile not have aicasm target (newly created clean > > building directory): > > I can't reproduce this here. My kernel Makefile includes an aicasm target. I have only this lines included, but not aicasm target itself. I have 'device ahc'. Maybe tabs/spaces/continuation lines or 'config' issue with /sys/conf/files? I wonder about optional ahc ahd line here. Is it assumes that _both_ must be on? aic7xxx_{seq.h,reg.h,reg_print.c}: $S/dev/aic7xxx/aic7xxx.{reg,seq} $S/cam/scsi/scsi_message.h aicasm ./aicasm ${INCLUDES} -I$S/cam/scsi -I$S/dev/aic7xxx -o aic7xxx_seq.h -r aic7xxx_reg.h -p aic7xxx_reg_print.c -i $S/dev/aic7xxx/aic7xxx_osm.h $S/dev/aic7xxx/aic7xxx.seq -- 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: CURRENT's termcap broken
... # > # and midnight commander shows all with -, +, | instead of # > # pesudo-graphics. # > # > It seems this is the price we pay for alignment with what XFree86 ships. # # I see Wait, maybe I was too fast and there is a solution. Looking at the xterm FAQ, http://dickey.his.com/xterm/xterm.faq.html My terminal doesn't show box characters Xterm displays the 7-bit ASCII and VT100 graphic characters (including box corners) using specially arranged fixed-pitch fonts. The first 32 glyph positions (which would correspond to nonprinting control characters) are used to hold the VT100 graphic characters. Some fonts that otherwise look fine (such as courier) do not have glyphs defined for these positions. So they display as blanks. Use xfd to display the font. XFree86 xterm can form its own line-drawing characters (see patch 90, for example). It does not draw all of the graphic characters, only those that may be done with straight lines. But those are the most used, making most of the fixed-pitch fonts useful for xterm. You may also have a problem with the terminfo description. As distributed, the X11R6 terminfo for xterm does not have the acsc string defined, so most implementations of curses do not try to use the alternate character set. Finally, some people confuse the VT100 graphic characters with the VT220 support for DEC technical character set. These are distinct (7-bit) character sets. Xterm currently does not support this. I found that it is really dependent on the font. I use some IBM font from an AIX system (Rom14) by default, which has no box characters and thus displays blanks instead. If I use e.g. $ xterm -fn fixed -e midc I have all the box characters and midc looks good. Use $ xfd -fn whateverfont and look at the first 32 characters. Regards, Jens -- Jens Schweikhardt http://www.schweikhardt.net/ SIGSIG -- signature too long (core dumped) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: New SCSI: can't 'make depend'
On Sat, Aug 31, 2002 at 11:15:55 -0600, Justin T. Gibbs wrote: > > Apparently Makefile not have aicasm target (newly created clean > > building directory): > > I can't reproduce this here. My kernel Makefile includes an aicasm target. >From where aicasm target must come in? As I see, src/sys/conf/Makefile.i386 v1.257 not have it. -- 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: New SCSI: can't 'make depend'
> Apparently Makefile not have aicasm target (newly created clean > building directory): I can't reproduce this here. My kernel Makefile includes an aicasm target. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New SCSI: can't 'make depend'
Apparently Makefile not have aicasm target (newly created clean building directory): rm -f .olddep if [ -f .depend ]; then mv .depend .olddep; fi make _kernel-depend cc -c -O -pipe -march=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -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 -ffreestanding ../../../i386/i386/genassym.c NM=nm OBJFORMAT=elf sh ../../../kern/genassym.sh genassym.o > assym.s awk -f ../../../tools/vnode_if.awk ../../../kern/vnode_if.src -h make: don't know how to make aicasm. Stop *** Error code 2 Stop in /usr/src/sys/i386/compile/POBRECITA. -- 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: Kernel compile at aic7xxx/aicasm today's current.
[I tried to send this unicast to [EMAIL PROTECTED], but the attempt was rejected with an "reason: 550 5.7.1 Access denied" as the only excuse given for the behavior. dhw] Adding a "cleandepend" stanza similar to the just-added "cleandir" stanza seems to get beyond that. Cheers, david -- David H. Wolfskill [EMAIL PROTECTED] To paraphrase David Hilbert, there can be no conflicts between the discipline of systems administration and Microsoft, since they have nothing in common. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Truss segfaults when tracing sshd
>Submitter-Id: current-users >Originator:Anders Nordby <[EMAIL PROTECTED]> >Organization: >Confidential: no >Synopsis: Truss segfaults when tracing sshd >Severity: serious >Priority: medium >Category: bin >Class: sw-bug >Release: FreeBSD 5.0-CURRENT i386 >Environment: FreeBSD current 5.0-CURRENT FreeBSD 5.0-CURRENT #0: Sat Aug 31 09:31:05 GMT 2002 root@current:/usr/obj/usr/src/sys/MYGENERIC i386 Filesystems mounted: /dev/ad0s1a on / (ufs, local) devfs on /dev (devfs, local) /dev/ad0s1f on /tmp (ufs, local, soft-updates) /dev/ad0s1g on /usr (ufs, local, soft-updates) /dev/ad0s1e on /var (ufs, local, soft-updates) eggsilo:/space/distfiles on /usr/ports/distfiles (nfs) procfs on /proc (procfs, local) The processor on the system is a 466 MHz Intel Celeron. >Description: Find your sshd process: # sockstat -l | grep sshd root sshd 175 3 tcp6 *:22 *:* root sshd 175 4 tcp4 *:22 *:* Truss it through gdb: # gdb truss GNU gdb 5.2.0 (FreeBSD) 20020627 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-undermydesk-freebsd"... (no debugging symbols found)... (gdb) run -p 175 Starting program: /usr/bin/truss -p 175 Now log in to the machine (I'm logging in as root), and return to gdb: (no debugging symbols found)...(no debugging symbols found)... Program received signal SIGSEGV, Segmentation fault. 0x08049c77 in free () (gdb) bt #0 0x08049c77 in free () #1 0x2806d000 in ?? () #2 0x08049e3e in free () #3 0x0804eb6d in free () #4 0x08049182 in free () #5 0x08048d31 in free () (gdb) >How-To-Repeat: On a vanilla -current system from today: # truss -p `sockstat -l | egrep 'sshd.*tcp4' | awk '{print $3}'` Log into the system with sshd, and truss will segfault: Segmentation fault (core dumped) This also seems to happen if you truss sshd while logging out another ssh session. >Fix: N/A To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
I now get a bit further: ===> aic7xxx ===> aic7xxx/aicasm make -f /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm cleandir make -f /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm/Makefile MAKESRCPATH=/.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm/../../../dev/aic7xxx/aicasm clean rm -f aicasm_gram.h aicasm_macro_gram.h aicasm_gram.output aicasm_macro_gram.output aicasm aicasm.o aicasm_symbol.o aicasm_gram.o aicasm_macro_gram.o aicasm_scan.o aicasm_macro_scan.o aicasm_scan.c aicasm_macro_scan.c aicasm_gram.c aicasm_gram.h aicasm_macro_gram.c aicasm_macro_gram.h make: don't know how to make cleandepend. Stop *** Error code 2 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx/aicasm. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules/aic7xxx. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src/sys/modules. *** Error code 1 Stop in /.amd_mnt/han/host/usr/obj/.amd_mnt/han/host/usr/src/sys/GREEDO. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src. *** Error code 1 Stop in /.amd_mnt/han/host/usr/src. On Sat, Aug 31, 2002 at 08:50:33AM -0600, Justin T. Gibbs wrote: > > Today's current gave me the following error while building a new kernel > > after a successful make world. > > > > cd /usr/src/sys/modules ; > > MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules > > KMODDIR=/boot/kernel MACHINE=i386 make cleandir > > ===> 3dfx > > ===> accf_data > > ===> accf_http > > ===> agp > > ===> aha > > ===> aic7xxx > > ===> aic7xxx/aicasm > > make: don't know how to make cleandir. Stop > > *** Error code 2 > > > > Stop in /usr/src/sys/modules/aic7xxx. > > *** Error code 1 > > Ooops. I never use the buildkernel target. Try re-cvsup'ing and see > if the change I just checked in fixes this for you. > > -- > Justin > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message -- Bob WillcoxWe seem to have forgotten the simple truth that [EMAIL PROTECTED] reason is never perfect. Only non-sense attains Austin, TX perfection. -- Poul Henningsen [1894-1967] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ACPI no longer disabled when APM enabled?
On Thu, 29 Aug 2002, Gavin Atkinson wrote: > Since the recent ACPI import (i believe), it seems that ACPI is no longer > disabled when APM is enabled. I do not explicitely disable API anywhere. > In the past, I have seen upon bootup a message "apm: Other PM system > enabled." and the kernel would carry on booting as if ACPI had not been > loaded. As a follow-up to this... adding the hint hint.acpi.0.disable="1" fixes the suspend problems, but produces the following error messages on boot-up: unknown: can't assign resources (port) unknown: can't assign resources (irq) unknown: can't assign resources (port) unknown: can't assign resources (port) unknown: can't assign resources (port) These only exist with the acpi hint above. Removing the hint and reverting to a previous kernel (where ACPI is disabled because APM is enabled) shows them with the hint in place too, but obviously acpi is not enabled then. I have confirmed that this is new with the latest acpi import. The recent heads-up about hw.acpi.0.disable="1" has not fixed the problem I am seeing. Those ISA PNP IDs correspond to, /usr/src/sys/isa/atkbdc_isa.c: { 0x0303d041, "Keyboard controller (i8042)" },/* PNP0303 */ /usr/src/sys/boot/common/pnpdata:ident=PNP0700 module=fd # PC standard floppy disk controller /usr/src/sys/boot/common/pnpdata:ident=PNP0501 module=sio# 16550A-compatible COM port /usr/src/sys/boot/common/pnpdata:ident=PNP0401 module=lpt# ECP printer port /usr/src/sys/isa/psm.c: { 0x130fd041, "PS/2 mouse port" }, /* PNP0F13 */ These devices seem to work fine however. Gavin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
Quoting "Justin T. Gibbs" <[EMAIL PROTECTED]>: | > Today's current gave me the following error while building a new kernel | > after a successful make world. | > | > cd /usr/src/sys/modules ; | > MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules | > KMODDIR=/boot/kernel MACHINE=i386 make cleandir | > ===> 3dfx | > ===> accf_data | > ===> accf_http | > ===> agp | > ===> aha | > ===> aic7xxx | > ===> aic7xxx/aicasm | > make: don't know how to make cleandir. Stop | > *** Error code 2 | > | > Stop in /usr/src/sys/modules/aic7xxx. | > *** Error code 1 | | Ooops. I never use the buildkernel target. Try re-cvsup'ing and see | if the change I just checked in fixes this for you. I'll do it right now. Thanks, ed To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kernel compile at aic7xxx/aicasm today's current.
> Today's current gave me the following error while building a new kernel > after a successful make world. > > cd /usr/src/sys/modules ; > MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules > KMODDIR=/boot/kernel MACHINE=i386 make cleandir > ===> 3dfx > ===> accf_data > ===> accf_http > ===> agp > ===> aha > ===> aic7xxx > ===> aic7xxx/aicasm > make: don't know how to make cleandir. Stop > *** Error code 2 > > Stop in /usr/src/sys/modules/aic7xxx. > *** Error code 1 Ooops. I never use the buildkernel target. Try re-cvsup'ing and see if the change I just checked in fixes this for you. -- Justin To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
[광고] freebsd-current님 재미있는 사은품을 드립니다.
Title: ½Åû¼¸ÞÀÏÆû ¼º¸í Áֹεî·Ï ¹øÈ£ ("-"ÀÔ·Â) Á÷Àå ÀüÈ ÈÞ´ëÆù ½Å±Ô ȸ¿ø ¿¬È¸ºñ ¸éÁ¦ Çö´ë ÀÚµ¿Â÷ ±¸ÀԽà Æ÷ÀÎÆ® ÇÒÀÎ ±¹³»ÃÖÃÊ ÁÖÀ¯ º¸Ç蹫·á °¡ÀÔ Á¤ºñ ÀÚµ¿Â÷ ¿ëÇ° ÇÒÀÎ Çö´ë M Ä«µå ½Å±Ô ȸ¿ø ¿¬È¸ºñ ¸éÁ¦ ±â¾Æ ÀÚµ¿Â÷ ±¸ÀԽà Æ÷ÀÎÆ® ÇÒÀÎ ±¹³»ÃÖÃÊ ÁÖÀ¯ º¸Ç蹫·á °¡ÀÔ Á¤ºñ ÀÚµ¿Â÷ ¿ëÇ° ÇÒÀÎ ±â¾Æ ³ëºí·¹½º Æò»ý ¿¬È¸ºñ ¸éÁ¦ Æ÷ÀÎÆ®³³ºÎ,°ø°ú±Ý Ä«µå°áÁ¦ ¼ºñ½º Çö´ëÁ¤À¯ §¤ ´ç 40¿ø ¿µÈ ¿¹¸Å Àå´ç 2,000¿ø ÇÒÀÎ KT ºôÇöóÀÚ »ç¿ëÇÑ 0.5%¸¦ ºÒ¿ìÀÌ¿ôµ½±â Æò»ý ¿¬È¸ºñ ¸éÁ¦ ±ÝÀ¶¼ºñ½º 5¾ï ¹«·á º¸Çè »ç¶ûÀÇ ¼Õ°áÆì±â ±ÍÇÏÀÇ ¸ÞÀÏÁÖ¼Ò´Â À¥¼ÇÎÀ» ÅëÇØ ¼öÁýÇÑ °ÍÀ̸ç, ±×¿Ü¿¡ ¾î¶°ÇÑ Á¤º¸µµ °®°í ÀÖÁö ¾ÊÀ½À» ¹àÈü´Ï´Ù. ÀÌ E-mailÀº ¹ß½ÅÀü¿ëÀ̸ç, ¿øÄ¡ ¾ÊÀ¸½Ç °æ¿ì ¾Æ·¡ â¿¡ ¸ÞÀÏÁÖ¼Ò¸¦ ÀÔ·ÂÇÏ¿© ÁÖ½Ã¸é µÎ ¹ø ´Ù½Ã ¸ÞÀÏÀÌ °¡Áö ¾Êµµ·Ï ÇÏ°Ú½À´Ï´Ù. º» ¸ÞÀÏÀº Á¤º¸Åë½ÅºÎ ±Ç°í »çÇ׿¡ ÀÇ°Å Á¦¸ñ¿¡ [±¤°í]¶ó°í Ç¥½ÃµÈ ±¤°í ¸ÞÀÏÀÔ´Ï´Ù. ¹öÆ°À» Ŭ¸¯ÇÏ½Ã¸é ¼ö½Å°ÅºÎ󸮰¡ ÀÌ·ç¾î Áý´Ï´Ù. If you won't receive any more mail about this site, press button and fill your e-mail address. And then we will not send any mail to you [EMAIL PROTECTED]
Kernel compile at aic7xxx/aicasm today's current.
Today's current gave me the following error while building a new kernel after a successful make world. cd /usr/src/sys/modules ; MAKEOBJDIRPREFIX=/usr/obj/usr/src/sys/PIII850N/modules KMODDIR=/boot/kernel MACHINE=i386 make cleandir ===> 3dfx ===> accf_data ===> accf_http ===> agp ===> aha ===> aic7xxx ===> aic7xxx/aicasm make: don't know how to make cleandir. Stop *** Error code 2 Stop in /usr/src/sys/modules/aic7xxx. *** Error code 1 Thanks, ed -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
openssh and lastlog
I've been seeing these messages for months.. Aug 31 20:19:29 cinq sshd[2342]: /var/log/lastlog: Permission denied .. because sshd has dropped root privileges by the time pam_lastlog tries to log the message. I realise this was discussed on this list about 2 months ago, but it hasn't been fixed yet. Why not just go back to using openssh's built-in lastlog code until pam_lastlog can be made to work from within openssh? Tim To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
i386 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/i386/obj/local0/scratch/des/src/i386/usr/include -- >>> stage 4: building libraries -- >>> stage 4: make dependencies -- >>> stage 4: building everything.. -- >>> Kernel build for GENERIC started on Fri Aug 30 22:34:55 PDT 2002 -- >>> Kernel build for GENERIC completed on Fri Aug 30 23:38:55 PDT 2002 -- >>> Kernel build for LINT started on Fri Aug 30 23:38:55 PDT 2002 -- ===> xe /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:480: warning: no previous prototype for `AcpiDbDecodeNode' /local0/scratch/des/src/sys/contrib/dev/acpica/dbdisply.c:131: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbexec.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbhistry.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbinput.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbstats.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/dbxface.c:127: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwgpe.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c: In function `AcpiGetSleepTypeData': /local0/scratch/des/src/sys/contrib/dev/acpica/hwregs.c:242: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfname.c:125: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/nsxfobj.c:126: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/rsdump.c:124: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utclib.c:129: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utdebug.c:122: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetRegionName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:492: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetEventName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:530: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c: In function `AcpiUtGetTypeName': /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:607: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/contrib/dev/acpica/utglobal.c:610: warning: cast discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/acpica/acpi_acad.c:50: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_cmbat.c:56: warning: `_THIS_MODULE' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:274: warning: `acpi_pwr_deregister_consumer' defined but not used /local0/scratch/des/src/sys/dev/acpica/acpi_powerres.c:212: warning: `acpi_pwr_deregister_resource' defined but not used /local0/scratch/des/src/sys/dev/hea/eni_buffer.c: In function `eni_test_memory': /local0/scratch/des/src/sys/dev/hea/eni_buffer.c:127: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/hea/eni_vcm.c: In function `eni_closevcc': /local0/scratch/des/src/sys/dev/hea/eni_vcm.c:289: warning: passing arg 1 of pointer to function makes pointer from integer without a cast /local0/scratch/des/src/sys/dev/ie/if_ie.c: In function `ieattach': /local0/scratch/des/src/sys/dev/ie/if_ie.c:779: warning: assignment discards qualifiers from pointer target type /local0/scratch/des/src/sys/dev/ie/if_ie