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: 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: usb lpt borked?
On Sat, 6 Apr 2002, Josef Karthauser wrote: After this patch my usb mouse work again in console and X !!! > On Sat, Apr 06, 2002 at 09:28:26AM +0200, Alexander Leidinger wrote: > > On 5 Apr, Julian Elischer wrote: > > > > > > ok guys we seem to be going backwards on this one.. > > > > > > 3 months ago this worked perfectly > > > 2 months ago it crashed after each document (on close()) > > > now it crashes on open().. at least in the old kernel > > > I could get my printouts :-) > > > > A Mar 12 kernel should work ok. > > > > > ps shows the lpd daemon sleeping 'usbsyn' just before the crash.. > > > no crashdumps yet.. will try, though I don't know if > > > the new crashdump code produces usable dumps yet.. > > > (I guess I'm going to find out :-) > > > > I've seen no ulpt related panics, it just doesn't print (VIA KT133A). > > Only my USB mice does something bad, it hangs the system hard on > > shutdown. > > Try this which Scott Long submitted a few days ago: > > Index: uhci.c > === > RCS file: /usr/home/ncvs/src/sys/dev/usb/uhci.c,v > retrieving revision 1.104 > diff -u -r1.104 uhci.c > --- uhci.c 1 Apr 2002 22:03:37 - 1.104 > +++ uhci.c 5 Apr 2002 08:17:03 - > @@ -2051,6 +2051,7 @@ > xfer->pipe->intrxfer = 0; > } > > uhci_abort_xfer(xfer, USBD_CANCELLED); > + usb_transfer_complete(xfer); > } > > > /* Close a device interrupt pipe. */ > > > > Joe > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: XFree86 and -CURRENT crashing
On Wed, 3 Apr 2002, Coleman Kane wrote: Its usb. Someone with working serial console need look at this. > I have been having major issues with XFree86 recently. It seems to just > completely halt the machine hard whenever I try starting it. If I run > it from a remote terminal with -verbose all the way up, it seems to halt > at the section just after it says it's loading the RENDER module. I was > wondering if anyone else knew of or has the same problem. Basically, > it is a typical Athlon system running a Radeon DDR 32MB card, but the > server even crashes if I force the vga driver instead. If I run Xvfb, it > seems to work fine. Thew only real odd thing about my system is that I am > using a USB keyboard and mouse instead of their AT,PS/2 counterparts. > > -- > coleman > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: USB mouse problem
On Sat, 30 Mar 2002, Masahide -mac- NODA wrote: Same here, solid lock, debug key not work. If I setup X to use /dev/ums0 computer hang just after startx. All worked with kernel/world from Mar 12. -- Mar 26 17:32:08 pyvo kernel: FreeBSD 5.0-CURRENT #10: Tue Mar 26 16:29:37 EET 2002 ... Mar 26 17:32:08 pyvo kernel: uhci0: port 0xb400-0xb41f irq 11 at device 4.2 on pci0 Mar 26 17:32:08 pyvo kernel: usb0: on uhci0 Mar 26 17:32:08 pyvo kernel: usb0: USB revision 1.0 Mar 26 17:32:08 pyvo kernel: uhub0: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 26 17:32:08 pyvo kernel: uhub0: 2 ports with 2 removable, self powered Mar 26 17:32:08 pyvo kernel: ums0: Microsoft Microsoft IntelliMouse. Explorer, rev 1.10/1.14, addr 2, iclass 3/1 Mar 26 17:32:08 pyvo kernel: ums0: 5 buttons and Z dir. Mar 26 17:32:08 pyvo kernel: uhci1: port 0xb000-0xb01f irq 11 at device 4.3 on pci0 Mar 26 17:32:08 pyvo kernel: usb1: on uhci1 Mar 26 17:32:08 pyvo kernel: usb1: USB revision 1.0 Mar 26 17:32:08 pyvo kernel: uhub1: VIA UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 Mar 26 17:32:08 pyvo kernel: uhub1: 2 ports with 2 removable, self powered > Hi, -current users. > > I found 'hung up situtation' with USB mouse on current. > > - Insert USB mouse to FreeBSD-CURRENT machine. > - search moused pid for USB mouse > - kill pid to hungup > > This problem cause 'unable to shutdown FreeBSD'. > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
diskcheckd.conf
After CURRENT update I see this in /var/log/messages: >Jun 12 18:50:48 pyvo diskcheckd[204]: open /etc/diskcheckd.conf failure: >No such file or directory I saw this commit message: > revision 1.267 > date: 2001/06/03 20:15:10; author: phk; state: Exp; lines: +9 -1 > Add diskcheckd to /etc/rc with a knob in rc.conf. > > Make the default setting YES for now to get some experience with it. > > Note: If people starts seeing disk errors because of this then it > should not be backed. > But where diskcheckd.conf ? * * 1 * -- To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
