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 Jul 26 22:27:32 PDT 2002 -- >>> Kernel build for GENERIC completed on Fri Jul 26 23:27:37 PDT 2002 -- >>> Kernel build for LINT started on Fri Jul 26 23:27:37 PDT 2002 -- ===> LINT /local0/scratch/des/src/sys/i386/conf/LINT: unknown option "PCI_ENABLE_IO_MODES" *** 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: About the recent kernel crashes.
Hi I ran a gdb session again and I hope the following is more helpful: 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"... panic: bremfree: bp 0xc685fe48 not locked panic messages: --- panic: Assertion (m->mtx_lock & (MTX_RECURSED|MTX_CONTESTED)) == 0 failed at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_mutex.c:915 syncing disks... panic: bremfree: bp 0xc685fe48 not locked Uptime: 2m49s pfs_vncache_unload(): 1 entries remaining Dumping 255 MB ata1: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:213 213 dumping++; (kgdb) where #0 doadump () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:213 #1 0xc028b176 in boot (howto=260) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:345 #2 0xc028b335 in panic () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493 #3 0xc02bd0a5 in bremfree (bp=0xc685fe48) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:633 #4 0xc02be816 in vfs_bio_awrite (bp=0xc685fe48) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:1627 #5 0xc02651b8 in spec_fsync (ap=0xcfffda94) at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:403 #6 0xc0264da7 in spec_vnoperate (ap=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:121 #7 0xc037a385 in ffs_sync (mp=0xc17fae00, waitfor=2, cred=0xc0ef5e00, td=0xc0491540) at vnode_if.h:463 #8 0xc02cbe8c in sync (td=0xc0491540, uap=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_syscalls.c:127 #9 0xc028ae1d in boot (howto=256) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:254 #10 0xc028b335 in panic () at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493 #11 0xc0283fef in mtx_destroy (m=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_mutex.c:915 #12 0xc03037f9 in in6_pcbdetach (inp=0xc1953248) at /mnt/aux3/cvs/freebsd/usr/src/sys/netinet6/in6_pcb.c:625 #13 0xc02f4046 in tcp_close (tp=0xc1953348) at /mnt/aux3/cvs/freebsd/usr/src/sys/netinet/tcp_subr.c:729 #14 0xc02f871a in tcp_disconnect (tp=0xc1953348) at /mnt/aux3/cvs/freebsd/usr/src/sys/netinet/tcp_usrreq.c:1192 #15 0xc02f6fe8 in tcp_usr_detach (so=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/netinet/tcp_usrreq.c:178 #16 0xc02b57c0 in soclose (so=0xc192c4e0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/uipc_socket.c:360 #17 0xc02a919a in soo_close (fp=0x0, td=0xc17fea80) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/sys_socket.c:215 #18 0xc02758a2 in fdrop_locked (fp=0xc19f3a8c, td=0xc17fea80) at file.h:228 #19 0xc02754f8 in fdrop (fp=0xc19f3a8c, td=0xc17fea80) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_descrip.c:1622 #20 0xc02754cb in closef (fp=0xc19f3a8c, td=0xc17fea80) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_descrip.c:1608 #21 0xc027417b in close (td=0xc17fea80, uap=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_descrip.c:800 #22 0xc03c0ec4 in syscall (frame= {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 21, tf_ebp = -1078989288, tf_isp = -805315212, tf_ebx = 677687508, tf_edx = 699043868, tf_ecx = 9, tf_eax = 6, tf_trapno = 22, tf_err = 2, tf_eip = 677955607, tf_cs = 31, tf_eflags = 514, tf_esp = -1078989412, tf_ss = 47}) at /mnt/aux3/cvs/freebsd/usr/src/sys/i386/i386/trap.c:1050 #23 0xc03b435d in syscall_with_err_pushed () at {standard input}:128 (kgdb) up 11 #11 0xc0283fef in mtx_destroy (m=0x0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_mutex.c:915 915 MPASS((m->mtx_lock & (MTX_RECURSED|MTX_CONTESTED)) == 0); (kgdb) list 910 LOCK_LOG_DESTROY(&m->mtx_object, 0); 911 912 if (!mtx_owned(m)) 913 MPASS(mtx_unowned(m)); 914 else { 915 MPASS((m->mtx_lock & (MTX_RECURSED|MTX_CONTESTED)) == 0); 916 917 /* Tell witness this isn't locked to make it happy. */ 918 WITNESS_UNLOCK(&m->mtx_object, LOP_EXCLUSIVE, __FILE__, 919 __LINE__); (kgdb) p m $1 = (struct mtx *) 0x0 (kgdb) q Peter Kostouros wrote: > Hi > > I got something similar after cvsup'ing and generating a system > earlier today (4hrs > ago) and running mozilla. Unlike other times, I have a coredump. > I hope the following helps: -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
kernel crash when rebooting old kernel
Ok, I tried rebooting to my old orig kernel (5.0-DP1) to see if it helped my printing issue. well, this happened when I rebooted: Panic: Malloc type lacks magic Debugger ("panic") stopped at Debugger+0x40 xorl%eax, %eax ? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: About the recent kernel crashes.
Hi I got something similar after cvsup'ing and generating a system earlier today (4hrs ago) and running mozilla. Unlike other times, I have a coredump. I hope the following helps: 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)... panic: bremfree: bp 0xc69041dc not locked panic messages: --- panic: Assertion (m->mtx_lock & (MTX_RECURSED|MTX_CONTESTED)) == 0 failed at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_mutex.c:915 syncing disks... panic: bremfree: bp 0xc69041dc not locked Uptime: 2h39m25s pfs_vncache_unload(): 98 entries remaining Dumping 255 MB ata1: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 0xc028ad40 in doadump () (kgdb) bt #0 0xc028ad40 in doadump () #1 0xc028b176 in boot () #2 0xc028b335 in panic () #3 0xc02bd0a5 in bremfree () #4 0xc02be816 in vfs_bio_awrite () #5 0xc02651b8 in spec_fsync () #6 0xc0264da7 in spec_vnoperate () #7 0xc037a385 in ffs_sync () #8 0xc02cbe8c in sync () #9 0xc028ae1d in boot () #10 0xc028b335 in panic () #11 0xc0283fef in mtx_destroy () #12 0xc03037f9 in in6_pcbdetach () #13 0xc02f4046 in tcp_close () #14 0xc02f871a in tcp_disconnect () #15 0xc02f6fe8 in tcp_usr_detach () #16 0xc02b57c0 in soclose () #17 0xc02a919a in soo_close () #18 0xc02758a2 in fdrop_locked () #19 0xc02754f8 in fdrop () #20 0xc02754cb in closef () #21 0xc027417b in close () #22 0xc03c0ec4 in syscall () #23 0xc03b435d in syscall_with_err_pushed () (kgdb) q walt <[EMAIL PROTECTED]> wrote A small observation which I hope will be useful: I started getting unexpected lockups during mozilla sessions after remaking world & kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. Seems to implicate kernel code committed on July 25, sometime after about 1430 GMT. -- Regards Peter As always the organisation disavows knowledge of this email To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system crashes; reboots when printing
On Fri, 2002-07-26 at 18:43, karl agee wrote: > ok, what's going on here??? > > system: 5.0-current. > > trying to print to a post script laser printer which works fine in the > past. setup using apsfilter. > > When I attempt to print any file from any program the desktop locks up > then the system reboots. why? > > I havent found any log messages when this happens. > > I also run setiathome. I've noticed that when this happens the seti > workunit progress is lost and it starts where it left off at the last > session. > > --karl well...I tried testing communications with the printer via the method in the handbook # lptest > /dev/lpt0 you guess it...it crashed and rebooted as before. what could be going on? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system crashes; reboots when printing
On Fri, 2002-07-26 at 19:24, Garance A Drosihn wrote: > At 6:43 PM -0700 7/26/02, karl agee wrote: > >system: 5.0-current. > > > >trying to print to a post script laser printer which works fine > >in the past. setup using apsfilter. > > > >When I attempt to print any file from any program the desktop > >locks up then the system reboots. why? > > Try copying a postscript file directly to the printer (skip > apsfilter and all of lpr), and see if you still get a system > crash. That will help to point to where the problem might be. > > If this is a networked printer, then you'll probably want to > use lpr but skip apsfilter. Excuse my newbie ignorance, but, how to do print a file bypassing lpr and apsfilter --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
About the recent kernel crashes.
A small observation which I hope will be useful: I started getting unexpected lockups during mozilla sessions after remaking world & kernel on the evening of July 25. The screen would freeze completely, followed a few seconds later by a spontaneous reboot. After this happened twice I deleted the new kernel and went back to using the kernel I compiled on the morning of the same day, July 25, and the crashes disappeared. I've cvsup'd and remade the world twice since then (but not the kernel) and I remain crash-free. Seems to implicate kernel code committed on July 25, sometime after about 1430 GMT. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: system crashes; reboots when printing
At 6:43 PM -0700 7/26/02, karl agee wrote: >system: 5.0-current. > >trying to print to a post script laser printer which works fine >in the past. setup using apsfilter. > >When I attempt to print any file from any program the desktop >locks up then the system reboots. why? Try copying a postscript file directly to the printer (skip apsfilter and all of lpr), and see if you still get a system crash. That will help to point to where the problem might be. If this is a networked printer, then you'll probably want to use lpr but skip apsfilter. -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
system crashes; reboots when printing
ok, what's going on here??? system: 5.0-current. trying to print to a post script laser printer which works fine in the past. setup using apsfilter. When I attempt to print any file from any program the desktop locks up then the system reboots. why? I havent found any log messages when this happens. I also run setiathome. I've noticed that when this happens the seti workunit progress is lost and it starts where it left off at the last session. --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where's perl???
On Fri, Jul 26, 2002 at 03:41:59PM -0400, Garance A Drosihn wrote: > At 12:01 PM +0200 7/26/02, Michael Nottebrock wrote: > > That said though, it would be good to have something a little > smarter than a blind find|rm which did find old files, and move > them out of the way. [move, not remove -- just in case it picks > the wrong files!] > rm(1) does take a -i option. -- Steve To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
is linux compatibility broken???
is linux compatibility broken??? I need to upgrade my linux-base from 6.1.1 to 7.1 so I can install realplayeram I in for a rude awakening if I do?? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA 800x600 console not working
David Xu wrote: > > Yes, this is a known problem. I have a patch for this, you may > download it from here: > http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz > > David Xu > Thanks!! Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
On 26-Jul-2002 andrew bliznak wrote: > John Baldwin wrote: >> On 26-Jul-2002 andrew bliznak wrote: >> >>>#14 0xc03179d8 in calltrap () at {standard input}:98 >>>#15 0xc01e4db5 in _mtx_lock_sleep (m=0x28, opts=0, file=0x0, line=0) >>> at /usr/home/andrew/C/src/sys/kern/kern_mutex.c:598 >> >> >> This is the bug, it's like it is dereferencing a null pointer to get >> a mutex or something. >> >> >>>#16 0xc026f71d in tcp_input (m=0xc0f10100, off0=20) >>> at /usr/home/andrew/C/src/sys/netinet/tcp_input.c:520 >> >> >> /* >> * Locate pcb for segment. >> */ >> INP_INFO_WLOCK(&tcbinfo); >> headlocked = 1; >> >> #define INP_INFO_WLOCK(ipi) mtx_lock(&(ipi)->ipi_mtx) >> >> I don't see why it should be a problem though, tcbinfo is a global >> var. > > Hm, little more debuging, m in sys/kern/kern_mutex.c:595 is wrong! It's wrong on the stack. Look at the _mtx_lock_sleep() line above. I would say print the value of m in gdb, but gdb doesn't always get local variables right (maybe the new gcc and dwarf stuff isn't subject to that). Actually, I think gdb has screwed up your backtrace some anyway. Back to the original fault messages: fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01e4b02 Can you do 'l *0xc01e4b02' in gdb and show the output? -- 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
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.. -- >>> Kernel build for GENERIC started on Fri Jul 26 11:44:02 GMT 2002 -- ===> GENERIC FYI: static unit limits for ppp are set: NPPP=1 Kernel build directory is /home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC Don't forget to do a ``make depend'' ./aicasm: 873 instructions used cc1: warnings being treated as errors /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket2.c: In function `sbflush': /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket2.c:732: warning: long int format, different type arg (arg 2) /usr/home/des/tinderbox/sparc64/src/sys/kern/uipc_socket2.c:732: warning: long int format, different type arg (arg 4) *** Error code 1 Stop in /usr/home/des/tinderbox/sparc64/obj/usr/home/des/tinderbox/sparc64/src/sys/GENERIC. *** 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
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 Jul 26 09:36:17 PDT 2002 -- ===> stg ===> streams ===> vesa ===> vinum ===> wi ===> xe ./aicasm: 873 instructions used ./aicasm: 674 instructions used /local0/scratch/des/src/sys/dev/pccbb/pccbb.c:621:2: #endif without #if mkdep: compile failed *** Error code 1 Stop in /local0/scratch/des/obj/local0/scratch/des/src/sys/GENERIC. *** 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
TCP broken on IPv6 enabled kernels?
All, I just cvsuped and built a new kernel and world last night, updating from a 2 week old -current that was working fine. Now, TCP seems broken. After I open and close a single TCP session, any further TCP opens result in either a failure (connection refused) or a system deadlock. ICMP seems to not be affected by this, and I haven't tried UDP. Taking INET6 out of my kernel seemed to fix this. And, if it makes a difference, I'm connected via an Orinoco WiFi card. Scott To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
Peter Schultz wrote: > On Thu, 2002-07-25 at 16:30, Alex Zepeda wrote: > >>I can buildworld no problem, play mp3s, read mail. But as soon as I play >>around in X... boom the system falls over. >> > > > As of this morning's new world I cannot open galeon/mozilla without a > complete lockup. I've also been locking up the system under X when disk > i/o gets heavy. That may be why galeon/mozilla won't run because I'll > hear the disk loading the program and right at the peak of it the system > freezes. > > Pete... > Same here - mozilla openning large mailbox: Script started on Fri Jul 26 18:25:22 2002 pyvo# gdb -k /boot/kernel/kernel.debug -c ./vmcore.2 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"... panic: bwrite: buffer is not busy??? panic messages: --- Fatal trap 12: page fault while in kernel mode fault virtual address = 0x24 fault code = supervisor read, page not present instruction pointer = 0x8:0xc01e4b02 stack pointer = 0x10:0xcc3c4a8c frame pointer = 0x10:0xcc3c4a9c 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 = 12 (swi1: net) trap number = 12 panic: page fault syncing disks... panic: bwrite: buffer is not busy??? Uptime: 3m55s Dumping 255 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 --- #0 doadump () at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:213 213 dumping++; (kgdb) where #0 doadump () at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:213 #1 0xc01ef338 in boot (howto=260) at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:345 #2 0xc01ef56b in panic () at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:493 #3 0xc022ec02 in bwrite (bp=0x104) at /usr/home/andrew/C/src/sys/kern/vfs_bio.c:797 #4 0xc023012e in vfs_bio_awrite (bp=0xc6dcc954) at /usr/home/andrew/C/src/sys/kern/vfs_bio.c:1637 #5 0xc01c1335 in spec_fsync (ap=0xcc3c4890) at /usr/home/andrew/C/src/sys/fs/specfs/spec_vnops.c:403 #6 0xc01c0e58 in spec_vnoperate (ap=0x0) at /usr/home/andrew/C/src/sys/fs/specfs/spec_vnops.c:121 #7 0xc02d1d43 in ffs_sync (mp=0xc1cd0600, waitfor=2, cred=0xc0ef6e80, td=0xc03b2ba0) at vnode_if.h:463 #8 0xc0240c38 in sync (td=0xc03b2ba0, uap=0x0) at /usr/home/andrew/C/src/sys/kern/vfs_syscalls.c:127 #9 0xc01eefbc in boot (howto=256) at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:254 #10 0xc01ef56b in panic () at /usr/home/andrew/C/src/sys/kern/kern_shutdown.c:493 #11 0xc03265f3 in trap_fatal (frame=0x100, eva=0) at /usr/home/andrew/C/src/sys/i386/i386/trap.c:846 #12 0xc03262d2 in trap_pfault (frame=0xcc3c4a4c, usermode=0, eva=36) ---Type to continue, or q to quit--- at /usr/home/andrew/C/src/sys/i386/i386/trap.c:760 #13 0xc0325d2d in trap (frame= {tf_fs = -1071775720, tf_es = 16, tf_ds = 16, tf_edi = -1057947392, tf_esi = 40, tf_ebp = -868463972, tf_isp = -868464008, tf_ebx = -1057962496, tf_edx = -1070177560, tf_ecx = 0, tf_eax = 40, tf_trapno = 12, tf_err = 0, tf_eip = -1071756542, tf_cs = 8, tf_eflags = 66195, tf_esp = -868463944, tf_ss = -1057964672}) at /usr/home/andrew/C/src/sys/i386/i386/trap.c:446 #14 0xc03179d8 in calltrap () at {standard input}:98 #15 0xc01e4db5 in _mtx_lock_sleep (m=0x28, opts=0, file=0x0, line=0) at /usr/home/andrew/C/src/sys/kern/kern_mutex.c:598 #16 0xc026f71d in tcp_input (m=0xc0f10100, off0=20) at /usr/home/andrew/C/src/sys/netinet/tcp_input.c:520 #17 0xc026a7a3 in ip_input (m=0xc0f10100) at /usr/home/andrew/C/src/sys/netinet/ip_input.c:839 #18 0xc026a892 in ipintr () at /usr/home/andrew/C/src/sys/netinet/ip_input.c:857 #19 0xc01db773 in swi_net (dummy=0x0) at /usr/home/andrew/C/src/sys/kern/kern_intr.c:646 #20 0xc01db471 in ithread_loop (arg=0xc0ef8800) at /usr/home/andrew/C/src/sys/kern/kern_intr.c:535 #21 0xc01da6f6 in fork_exit (callout=0xc01db2a0 , arg=0x0, frame=0x0) at /usr/home/andrew/C/src/sys/kern/kern_fork.c:861 (kgdb) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
John Baldwin wrote: > On 26-Jul-2002 andrew bliznak wrote: > >>#14 0xc03179d8 in calltrap () at {standard input}:98 >>#15 0xc01e4db5 in _mtx_lock_sleep (m=0x28, opts=0, file=0x0, line=0) >> at /usr/home/andrew/C/src/sys/kern/kern_mutex.c:598 > > > This is the bug, it's like it is dereferencing a null pointer to get > a mutex or something. > > >>#16 0xc026f71d in tcp_input (m=0xc0f10100, off0=20) >> at /usr/home/andrew/C/src/sys/netinet/tcp_input.c:520 > > > /* > * Locate pcb for segment. > */ > INP_INFO_WLOCK(&tcbinfo); > headlocked = 1; > > #define INP_INFO_WLOCK(ipi) mtx_lock(&(ipi)->ipi_mtx) > > I don't see why it should be a problem though, tcbinfo is a global > var. Hm, little more debuging, m in sys/kern/kern_mutex.c:595 is wrong! (kgdb) up 16 #16 0xc026f71d in tcp_input (m=0xc0f10100, off0=20) at /usr/home/andrew/C/src/sys/netinet/tcp_input.c:520 520 INP_INFO_WLOCK(&tcbinfo); (kgdb) print tcinfo $1 = {hashbase = 0xc1c6a000, hashmask = 511, porthashbase = 0xc0efe800, porthashmask = 511, listhead = 0xc03c1bf0, lastport = 49172, lastlow = 0, lasthi = 0, ipi_zone = 0xc0f05dc0, ipi_count = 29, ipi_gencnt = 74, ipi_mtx = {mtx_object = {lo_class = 0xc03b6f00, lo_name = 0xc03662e8 "tcp", lo_type = 0xc03662e8 "tcp", lo_flags = 720896, lo_list = { tqe_next = 0x0, tqe_prev = 0x0}, lo_witness = 0x0}, mtx_lock = 3237004802, mtx_recurse = 0, mtx_blocked = { tqh_first = 0xc0f0bd80, tqh_last = 0xc0f0bda0}, mtx_contested = { le_next = 0x0, le_prev = 0xc0f0c664}, mtx_acqtime = 0, mtx_filename = 0x0, mtx_lineno = 0}} (kgdb) down #15 0xc01e4db5 in _mtx_lock_sleep (m=0x28, opts=0, file=0x0, line=0) at /usr/home/andrew/C/src/sys/kern/kern_mutex.c:598 598 propagate_priority(td); (kgdb) list 593 * Save who we're blocked on. 594 */ 595 td->td_blocked = m; 596 td->td_mtxname = m->mtx_object.lo_name; 597 td->td_state = TDS_MTX; 598 propagate_priority(td); 599 600 if (LOCK_LOG_TEST(&m->mtx_object, opts)) 601 CTR3(KTR_LOCK, 602 "_mtx_lock_sleep: p %p blocked on [%p] %s", td, m, (kgdb) print td $2 = (struct thread *) 0xc0f0c600 (kgdb) print *td $3 = {td_proc = 0xc207f560, td_ksegrp = 0xc207f598, td_plist = { tqe_next = 0x0, tqe_prev = 0xc207f570}, td_kglist = {tqe_next = 0x0, tqe_prev = 0xc207f5b4}, td_slpq = {tqe_next = 0x0, tqe_prev = 0xc0f0c0d8}, td_blkq = {tqe_next = 0x0, tqe_prev = 0x0}, td_runq = {tqe_next = 0x0, tqe_prev = 0x0}, td_selq = {tqh_first = 0xc1cef270, tqh_last = 0xc20c711c}, td_flags = 200, td_last_kse = 0x0, td_kse = 0xc207f5f4, td_dupfd = 0, td_wchan = 0xc03ba2c4, td_wmesg = 0xc035eb89 "select", td_lastcpu = 0 '\0', td_inktr = 0 '\0', td_inktrace = 0 '\0', td_locks = -416, td_blocked = 0x0, td_ithd = 0x0, td_mtxname = 0x0, td_contested = {lh_first = 0xc03c1c2c}, td_sleeplocks = 0x0, td_intr_nesting_level = 0, td_mailbox = 0x0, td_ucred = 0xc209f100, td_switchin = 0, td_md = , td_retval = {0, 189}, td_base_pri = 187 'ยป', td_priority = 40 '(', td_pcb = 0xcc3e5da0, td_state = TDS_SLP, td_slpcallout = {c_links = {sle = { sle_next = 0x0}, tqe = {tqe_next = 0x0, tqe_prev = 0xc0f0c510}}, c_time = 23481, c_arg = 0xc0f0c600, c_func = 0xc01cc450 , c_flags = 14}, td_frame = 0xcc3e5d48, td_kstack_obj = 0xc083312c, td_kstack = 3426631680, td_critnest = 1} (kgdb) print m $4 = (struct mtx *) 0x28 (kgdb) > > Hmm, one thing to note is that the tcbinfo_mtx pointer isn't ever > used or assigned. > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs -T breakage
* Bakul Shah <[EMAIL PROTECTED]> [020725 23:14] wrote: > > Yes, that code is very broken indeed. It probably was supposed to > > call __rpc_setconf("udp") and not getnetconfigent("udp"), but that > > seems to pick up an ipv6 address. I think the best plan is to go > > back to the way that part of the code was before revision 1.10. > > > > Could you try the following patch? > > Thank you for the patch! Yes, it works. Right after I sent > out my message I tried an almost identical patch which also > worked but, as I said I don't understand this code, didn't > have time to understand it and my patch seemed a bit hacky so > I kept quiet. Actually this whole routine seems hacky -- why > look up "udp" when you are told explicitly to use tcp? Oh > well, I should keep quiet until I really understand it:-) Ian, can you commit this fix? -Alfred To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: VESA 800x600 console not working
Yes, this is a known problem. I have a patch for this, you may download it from here: http://opensource.zjonline.com.cn/freebsd/vm86patch.tgz David Xu - Original Message - From: "Rob" <[EMAIL PROTECTED]> To: "Current" <[EMAIL PROTECTED]> Sent: Saturday, July 27, 2002 6:46 AM Subject: VESA 800x600 console not working > Having a laptop here, I wanted to get the same 800x600 console that I > have in -stable. I built my kernel with OPTIONS VESA and OPTIONS > SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080 > in the device.hints file for SC. That gave me a blank screen upon > startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol > command "vidcontrol -g 100x37 VESA_800x600. That gave me a blank screen > at the end of the bootup. Is this functionality broken in -current, or > am I doing something wrong? > > Thanks, Rob. > > > -- > - > The Numeric Python EM Project > > www.pythonemproject.com > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message __ Do You Yahoo!? Yahoo! Health - Feel better, live better http://health.yahoo.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where's perl???
At 12:01 PM +0200 7/26/02, Michael Nottebrock wrote: >Erik Greenwald wrote: >>speaking of, is there any good way to automatically eliminate old >>unnecessary parts of the base? > >>should there be one? :) > >An increasing number of people seem to believe that and there has >been some discussion lately, which showed that there are also a >large number of people opposing that (for reasons that remain >unclear to me). The specific methods that have been proposed (namely, a blind 'rm -f' hanging off a 'find' command) are too dangerous, IMO. We need to come up with something which isn't so destructive, if we're going to do this, and which recognizes that people might have very legitimate reasons to have their very own "old file" sitting at some point in some directory. the FreeBSD project does not own my hardware or my time, and is not appropriate for installworlds started deleting files based on no other criteria than the timestamp on the file. That said though, it would be good to have something a little smarter than a blind find|rm which did find old files, and move them out of the way. [move, not remove -- just in case it picks the wrong files!] -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
On Thu, 2002-07-25 at 16:30, Alex Zepeda wrote: > I can buildworld no problem, play mp3s, read mail. But as soon as I play > around in X... boom the system falls over. > As of this morning's new world I cannot open galeon/mozilla without a complete lockup. I've also been locking up the system under X when disk i/o gets heavy. That may be why galeon/mozilla won't run because I'll hear the disk loading the program and right at the peak of it the system freezes. Pete... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
Peter Schultz wrote: > > On Thu, 2002-07-25 at 16:30, Alex Zepeda wrote: > > I can buildworld no problem, play mp3s, read mail. But as soon as I play > > around in X... boom the system falls over. > > > > As of this morning's new world I cannot open galeon/mozilla without a > complete lockup. I've also been locking up the system under X when disk > i/o gets heavy. That may be why galeon/mozilla won't run because I'll > hear the disk loading the program and right at the peak of it the system > freezes. > > Pete... > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message I hate to write these "it works for me" mails, but I did cvsup yesterday, and I haven't had any X11 problems with any programs. However, I built X11 quite a long time ago. Maybe it is a gcc problem in recent X11 builds. Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: where's perl???
Karl, On Thu, Jul 25, 2002 at 11:09:05PM -0700, karl agee wrote: > on my box perl is located > su-2.05a# whereis perl > perl: /usr/bin/perl /usr/share/man/man1/perl.1.gz /usr/src/usr.bin/perl it is a wrapper. Perl now isn't in a base system. > I checked various files to see if I could edit anything but there was > nothing obvious. Should I make a link to /usr/bin/perl? Say as root "use.perl port" after installing /usr/ports/lang/perl. Andrew. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: I think X is making this whole thing unstable..
John Baldwin wrote: > On 26-Jul-2002 andrew bliznak wrote: > >>John Baldwin wrote: >> >>>On 26-Jul-2002 andrew bliznak wrote: >>> [ ... ] > Actually, I think gdb has screwed up your backtrace some anyway. Back > to the original fault messages: > > fault virtual address = 0x24 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc01e4b02 > > Can you do 'l *0xc01e4b02' in gdb and show the output? > (kgdb) l *0xc01e4b02 0xc01e4b02 is in propagate_priority (/usr/home/andrew/C/src/sys/kern/kern_mutex.c:183). 178 179 /* 180 * Check if the thread needs to be moved up on 181 * the blocked chain 182 */ 183 if (td == TAILQ_FIRST(&m->mtx_blocked)) { 184 continue; 185 } 186 187 td1 = TAILQ_PREV(td, threadqueue, td_blkq); (kgdb) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mount_nfs -T breakage
> Yes, that code is very broken indeed. It probably was supposed to > call __rpc_setconf("udp") and not getnetconfigent("udp"), but that > seems to pick up an ipv6 address. I think the best plan is to go > back to the way that part of the code was before revision 1.10. > > Could you try the following patch? Thank you for the patch! Yes, it works. Right after I sent out my message I tried an almost identical patch which also worked but, as I said I don't understand this code, didn't have time to understand it and my patch seemed a bit hacky so I kept quiet. Actually this whole routine seems hacky -- why look up "udp" when you are told explicitly to use tcp? Oh well, I should keep quiet until I really understand it:-) Thanks again! -- bakul To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
where's perl???
I am trying to install imwheel in my -current setup...ran make install in the port (updated yesterday) and it ran the compliation but bombed at perl. It sed: su-2.05a# make install; make clean >> imwheel-0.9.9.tar.gz doesn't seem to exist in /usr/ports/distfiles/. >> Attempting to fetch from http://jonatkins.org/imwheel/files/. Receiving imwheel-0.9.9.tar.gz (411882 bytes): 100% 411882 bytes transferred in 102.9 seconds (3.91 kBps) ===> Extracting for imwheel-0.9.9 >> Checksum OK for imwheel-0.9.9.tar.gz. ===> imwheel-0.9.9 depends on executable: gmake - found ===> imwheel-0.9.9 depends on shared library: X11.6 - found ===> Patching for imwheel-0.9.9 ===> Applying FreeBSD patches for imwheel-0.9.9 /usr/local/bin/perl: not found *** Error code 127 on my box perl is located su-2.05a# whereis perl perl: /usr/bin/perl /usr/share/man/man1/perl.1.gz /usr/src/usr.bin/perl I checked various files to see if I could edit anything but there was nothing obvious. Should I make a link to /usr/bin/perl? --karl To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
VESA 800x600 console not working
Having a laptop here, I wanted to get the same 800x600 console that I have in -stable. I built my kernel with OPTIONS VESA and OPTIONS SC_PIXEL_MODE. I have tried two methods. The first was to put 0x0080 in the device.hints file for SC. That gave me a blank screen upon startup. I also tried putting into /usr/local/etc/rc.d the vidcontrol command "vidcontrol -g 100x37 VESA_800x600. That gave me a blank screen at the end of the bootup. Is this functionality broken in -current, or am I doing something wrong? Thanks, Rob. -- - The Numeric Python EM Project www.pythonemproject.com To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
New suspend/resume panic on new current?
Hi, I just got this panic on current source supped midnight GMT 26th July (today...). I haven't seen anyone else mention this, it happened when i ran 'fg' in a tcsh root shell. System dropped to debugger, i typed 'panic' but it couldn't dump to disk, it printed the _sx_xlock panic below many times then rebooted. panic: blockable sleep lock (sleep mutex) Giant @ /usr/src/sys/vm/vm_fault.c:206 panic: from debugger Uptime: 2h40m47s Dumping 127 MB ata0: resetting devices .. panic: msleep Uptime: 2h40m47s panic: witness_destroy: lock (sleep mutex) pseudofs_vncache is not initialized Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 Uptime: 2h40m47s panic: _sx_xlock (shutdown_post_sync): xlock already held @ /usr/src/sys/kern/kern_shutdown.c:341 U