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
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
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: 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: 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..
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: 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: 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 = incomplete type,
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 cv_timedwait_end, 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: 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 return to continue, or q return 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 ithread_loop, 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
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
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
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
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
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
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: 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
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: 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
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
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
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: 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
