Inappropriate ioctl for device (CDIOCREADAUDIO)

[Peter Kostouros]

Hi

I am using cd2mp3 (which uses dagrab) to copy an audio file. 
Unfortunately I receive the following message:

dagrab: read raw ioctl failed at lba 33 length 12: Inappropriate ioctl 
for device

I hope the following snippet of code from dagrab might be useful:

void cd_read_audio(int lba,int num,char *buf)
{
   struct ioc_read_audio ra;
   ra.address.lba=lba
   ra.address_format=CD_LBA_FORMAT;
   ra.nframes=num;
   ra.buffer=buf;
   if(ioctl(cdrom_fd,CDIOCREADAUDIO,&ra)) {
  fprintf(...);
  ...
   }
}
cd2mp3 works if I use last week's kernel. Note, I re-built cd2mp3 and 
its dependencies.

--

Regards

Peter

As always the organisation disavows knowledge of this email



___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

libthr: Blocked signal nesting level must be 1!

[Peter Kostouros]

Hi

I received the following message while running mplayer:

Blocked signal nesting level must be 1!
Abnormal termination, file: 
/mnt/cvs/FreeBSD/usr/src/libthr/thread/thr_kern.c, line: 88

I am running with SCHED_ULE, and have mapped libc_r to libthr in 
libmap.conf. The program runs fine when libc_r is not mapped to libthr.

Note, kernel and world cvsup'ed and built about 24 hours ago.

--

Regards

Peter

As always the organisation disavows knowledge of this email

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: IDE DVD playback on 5.1-CURRENT

[Peter Kostouros]

Hi

I had a similar problem when running mplayer with recent kernels. My 
problem was that although I was executing mplayer with -dvd-device 
/dev/acd0, the program was trying to open /dev/racd0. I modified 
main/libmpdvdkit2/dvd_reader.c and sure enough everything is OK. I hope 
the following helps:

#if defined(SYS_BSD)
/* FreeBSD /dev/(r)(a)cd0c (a is for atapi), recomended to _not_ use r
  OpenBSD /dev/rcd0c, it needs to be the raw device
  NetBSD  /dev/rcd0[d|c|..] d for x86, c (for non x86), perhaps others
  Darwin  /dev/rdisk0,  it needs to be the raw device
  BSD/OS  /dev/sr0c (if not mounted) or /dev/rsr0c ('c' any letter will 
do) */
static char *bsd_block2char( const char *path )
{
   char *new_path;

#if 0
   /* If it doesn't start with "/dev/" or does start with "/dev/r" exit */
   if( strncmp( path, "/dev/",  5 ) || !strncmp( path, "/dev/r", 6 ) )
 return (char *) strdup( path );
   /* Replace "/dev/" with "/dev/r" */
   new_path = malloc( strlen(path) + 2 );
   strcpy( new_path, "/dev/r" );
   strcat( new_path, path + strlen( "/dev/" ) );
#endif
  
   new_path = strdup(path);
  
   return new_path;
}
#endif

Adam K Kirchhoff wrote:

Again, no luck.  From vlc:

[0141] main input: playlist item `dvdold:///dev/[EMAIL PROTECTED],1'
[0141] dvd input error: dvdcss cannot open device
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0 with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
[0141] dvdread input error: libdvdcss cannot open source
[0141] vcd input error: no movie tracks found
[0141] main input error: no suitable access module for `/://dvdold:///dev/[EMAIL 
PROTECTED],1
From mplayer:
Playing DVD title 1
libdvdread: Could not open device with libdvdcss.
libdvdread: Can't open /dev/acd0 for reading
Couldn't open DVD device: /dev/acd0
From ogle:
libdvdread: Using libdvdcss version 1.2.5 for DVD access
libdvdread: Could not open /dev/acd0c with libdvdcss.
libdvdread: Can't open /dev/acd0c for reading
ERROR[ogle_nav]: faild to open/read the DVD
Yet the same DVD in the firewire drive works just fine.

I can certainly try recompiling the applications but, frankly, I'm really
doubtful that will solve the problem :-(
Adam

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"


 



--

Regards

Peter

As always the organisation disavows knowledge of this email

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

panic: improper umtx access

[Peter Kostouros]

Hi

I received a panic: improper umtx access from a system cvsup'ed about 8 
hours ago. It occurred when executing mcs (mono C# compiler). Note 
/etc/libmap.conf had libc_r.so* pointing to libthr.so* for mono/mcs. I 
am also running the SCHED_ULE scheduler.

I hope the attached backtrace is useful.

--

Regards

Peter

As always the organisation disavows knowledge of this email

Script started on Sat Jul 19 19:53:59 2003
eva# gdb -k -f kernel.debun g -f /var/crash/vmcore.18

GNU gdb 5.2.1 (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-undermydesk-freebsd"...
panic: improper umtx access
panic messages:
---
panic: improper umtx access

syncing disks, buffers remaining... 4819 4819 4817 4816 4816 4816 4815 4815 4815 4815 
4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 4815 
giving up on 2893 buffers
Uptime: 27m10s
acd0: timeout waiting for cmd=e7 s=01 e=04
acd0: flushing device failed
Dumping 1023 MB
ata0: resetting devices ..
done
 16 32[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C 
to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to 
abort] [CTRL-C to abort]  48[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to 
abort] [CTRL-C to abort] [CTRL-C to abort]  64[CTRL-C to abort] [CTRL-C to abort] 
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to 
abort] [CTRL-C to abort]  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 512 528 544 560 576 592 608 624 640 
656 672 688 704 720 736 752 768 784 800 816 832 848 864 880 896 912 928 944 960 976 
992 1008
---
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
#0  doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240:6807:beg:0xc023a65b
(kgdb) bt
#0  doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:240
#1  0xc023ac91 in boot (howto=256) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:372
#2  0xc023b027 in panic () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:550
#3  0xc024bcd1 in _umtx_unlock (td=0xc32ae390, uap=0x0)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306
#4  0xc03911e3 in syscall (frame=
  {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135333020, tf_esi = 135332992, 
tf_ebp = -1081159924, tf_isp = -530489996, tf_ebx = 674411260, tf_edx = 0, tf_ecx = 
134524928, tf_eax = 435, tf_trapno = 12, tf_err = 2, tf_eip = 674719375, tf_cs = 31, 
tf_eflags = 2097734, tf_esp = -1081159968, tf_ss = 47}) at 
/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c:1023
#5  0xc038157d in Xint0x80_syscall () at {standard input}:144
---Can't read userspace from dump, or kernel process---

(kgdb) up 3
#3  0xc024bcd1 in _umtx_unlock (td=0xc32ae390, uap=0x0)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_umtx.c:306:7814:beg:0xc024bcd1
(kgdb) l
301 }
302 } else {
303 UMTX_UNLOCK();
304 old = casuptr((intptr_t *)&umtx->u_owner,
305 owner, UMTX_CONTESTED);
306 KASSERT(old != -1 && old != owner, ("improper umtx access"));
307 }
308 
309 if (old == -1)
310 return (EFAULT);
(kgdb) p old
$1 = -1020599407
(kgdb) p owner
$2 = -1020599407
(kgdb) p td
$3 = (struct thread *) 0xc32ae390
(kgdb) p uq
$4 = (struct umtx_q *) 0x0
(kgdb) l q
eva# exit

exit

Script done on Sat Jul 19 19:57:24 2003
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: world build fails since yesterday

[Peter Kostouros]

FYI

I was able to build world by reverting to a kernel cvsup'ed and built on 
30/05/2003; I could not do so with a kernel cvsup'ed and built on 
06/06/2003.



Christoph P. Kukulies wrote:

On Thu, Jun 26, 2003 at 01:10:09PM +0200, Tobias Roth wrote:
 

Overheating/powermanagement - maybe. I have an ASUS 4SX8 with a 1.3 GHz P4.
I would exclude memory problems. I had built world a couple of times
during the last 8 weeks of cvsuping.
 

i just got two continuous crashes on stable as well. so at least for me
it is definitely a hardware issue. what's left for me is try again with
the latest bios (reinstall win, duh), and then send my laptop back to
IBM.
   

But then you don't have a point claiming a hardware problem :-)

 

the buildworld tests I asked you guys to do are no longer necessary to
clarify my issues, thanks for considering them.
   



There were indeed times when I made a clean FreeBSD world build a criterium
for a functioning hardware (cheap dimms, simms, exotic motherboards).
--
Chris Christoph P. U. Kukulies kukulies (at) rwth-aachen.de
 



--

Regards

Peter

As always the organisation disavows knowledge of this email

___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

KSE test code (src/tools/KDE/ksetest) panic

[Peter Kostouros]

Hi

I receive panics when running this test program. The system was cvsup'ed 
and built on Mar 21. I hope the attached trace is helpful.

--

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

Script started on Sat Mar 22 22:56:08 2003
GNU gdb 5.2.1 (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-undermydesk-freebsd"...
panic: mi_switch: switch in a critical section
panic messages:
---
panic: blockable sleep lock (sleep mutex) process lock @ 
/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c:728

syncing disks, buffers remaining... panic: mi_switch: switch in a critical section
Uptime: 2h5m17s
Dumping 511 MB
ata0: resetting devices ..
done
 16 32 48 64[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]  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
---
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linux/linux.ko.debug
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/acpi/acpi.ko.debug
Reading symbols from 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug...done.
Loaded symbols for 
/usr/obj/mnt/cvs/FreeBSD/usr/src/sys/EVA/modules/mnt/cvs/FreeBSD/usr/src/sys/modules/linprocfs/linprocfs.ko.debug
#0  doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:239
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:239:6799:beg:0xc02397eb
(kgdb) bt
#0  doadump () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:239
#1  0xc0239e13 in boot (howto=260) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:371
#2  0xc023a113 in panic () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:542
#3  0xc0240731 in mi_switch () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_synch.c:466
#4  0xc0240075 in msleep (ident=0xc0478c14, mtx=0xc0478c20, priority=68, 
wmesg=0xc03cf9a1 "wdrain", 
timo=0) at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_synch.c:248
#5  0xc027d542 in bwrite (bp=0xcc26bdf0) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_bio.c:357
#6  0xc027dcec in bawrite (bp=0x0) at /mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_bio.c:1143
#7  0xc02858da in cluster_wbuild (vp=0xc40f0b68, size=16384, start_lbn=48, len=8)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_cluster.c:965
#8  0xc027f099 in vfs_bio_awrite (bp=0xcc2a3d68) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_bio.c:1681
#9  0xc032cc72 in ffs_fsync (ap=0xd32029f8) at 
/mnt/cvs/FreeBSD/usr/src/sys/ufs/ffs/ffs_vnops.c:255
#10 0xc032be1e in ffs_sync (mp=0xc204fa00, waitfor=2, cred=0xc150ae00, td=0xc0417540) 
at vnode_if.h:612
#11 0xc029242b in sync (td=0xc0417540, uap=0x0) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/vfs_syscalls.c:138
#12 0xc0239973 in boot (howto=256) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:280
#13 0xc023a113 in panic () at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_shutdown.c:542
#14 0xc025bb2f in witness_lock (lock=0xc151ea68, flags=8, 
file=0xc03e12df "/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c", line=728)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/subr_witness.c:574
#15 0xc02304a1 in _mtx_lock_flags (m=0xc151fa00, opts=0, 
file=0xc03e12df "/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c", line=-1051596184)
at /mnt/cvs/FreeBSD/usr/src/sys/kern/kern_mutex.c:336
#16 0xc03868ed in trap_pfault (frame=0xd3202bc0, usermode=0, eva=404)
at /mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c:728
#17 0xc038658d in trap (frame=
  {tf_fs = 24, tf_es = -752877552, tf_ds = -1037565936, tf_edi = 0, tf_esi = 400, 
tf_ebp = -752866288, tf_isp = -752866324, tf_ebx = 49, tf_edx = -1051592192, tf_ecx = 
-1040472000, tf_eax = -1069424904, tf_trapno = 12, tf_err = 2, tf_eip = -1071385900, 
tf_cs = 8, tf_eflags = 66118, tf_esp = -1069765046, tf_ss = -1040472000}) at 
/mnt/cvs/FreeBSD/usr/src/sys/i386/i386/trap.c:444
#18 0xc0376e48 in calltrap () at {standard input}:96
#19 0xc024be4f in sched_rem (ke=0x31) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/sched_ule.c:252
#20 0xc023efe0 in setrunqueue (td=0x31) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/kern_switch.c:345
#21 0xc024b95c in sched_wakeup (td=0xc3c99400) at 
/mnt/cvs/FreeBSD/usr/src/sys/kern/sched_ule.c:604
#22 0xc02409d0 in setrunnable (td=0xc3c99400) at 
/mnt/cvs/FreeBSD/u

Re: gcc3.2.2 import might have trashed ld-elf.so.1

[Peter Kostouros]

Hi

The problem I have is with designer, Qt's IDE. It was working well until 
a cvsup a few days ago. I hope the attached can help.

Alexander Kabaev wrote:

On Sun, 16 Feb 2003 02:09:24 +0800
leafy <[EMAIL PROTECTED]> wrote:

 

I rebuilt and installed  world on Friday and reinstalled ALL my ports
with 'portupgrade -ra'. I have found the exact line that will trigger
the ld "undefined symbol" error.

/usr/X11R6/bin/uic -nounload -tr tr2i18n -i htmlpageinfo.h
./htmlpageinfo.ui > htmlpageinfo.cc.temp ; ret=$?;  sed -e "s,tr2i18n(
\"\" ),QString::null,g" htmlpageinfo.cc.temp | sed -e "s,tr2i18n(
\"\"\, \"\" ),QString::null,g" | sed -e
"s,image\([0-9][0-9]*\)_data,img\1_htmlpageinfo,g" >> htmlpageinfo.cc
; rm -f htmlpageinfo.cc.temp ; if test "$ret" = 0; then echo '#include
"htmlpageinfo.moc"' >>htmlpageinfo.cc; else rm -f htmlpageinfo.cc ;
exit $ret ; fi
   


QT's uic binary does not use libwizards.so. Please take time to dig a
little deeper and figure what binary exactly is failing. It is doubtful
someone will be able to help you otherwise. 

 



--

Regards

Peter

As always the organisation disavows knowledge of this email


Script started on Sun Feb 16 17:21:26 2003
bash-2.05b$ exitrm .*~*~jed .cvsrccdless 
cv*scd cvsup//usr/share/ex*              
   gdb -f /opt/de  qt/bin/designer/q        signer
GNU gdb 5.2.1 (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-undermydesk-freebsd"...
(no debugging symbols found)...
(gdb) r
Starting program: /opt/qt-x11-free-3.1.1/bin/designer 
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
Xlib:  extension "GLX" missing on display ":0.0".
Xlib:  extension "GLX" missing on display ":0.0".
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...(no debugging symbols found)...
(no debugging symbols found)...
Program received signal SIGSEGV, Segmentation fault.
0x in ?? ()
(gdb) bt
#0  0x in ?? ()
#1  0x28f8204c in __static_initialization_and_destruction_0(int, int) ()
   from /opt/kde-3.1/lib/libkio.so.5
#2  0x28f8209a in _GLOBAL__D__ZNK13KOpenSSLProxy9hasLibSSLEv ()
   from /opt/kde-3.1/lib/libkio.so.5
#3  0x28f6a6d9 in __do_global_dtors_aux () from /opt/kde-3.1/lib/libkio.so.5
#4  0x29101c91 in _fini () from /opt/kde-3.1/lib/libkio.so.5
#5  0x2827716c in dlclose () from /usr/libexec/ld-elf.so.1
#6  0x28749c89 in QLibraryPrivate::freeLibrary() ()
   from /opt/qt/lib/libqt-mt.so.3
#7  0x2876a6bd in QLibrary::unload() () from /opt/qt/lib/libqt-mt.so.3
#8  0x2874ddc0 in QComLibrary::unload() () from /opt/qt/lib/libqt-mt.so.3
#9  0x2874dce9 in QComLibrary::~QComLibrary() () from /opt/qt/lib/libqt-mt.so.3
#10 0x28768147 in QGPluginManager::addLibrary(QLibrary*) ()
   from /opt/qt/lib/libqt-mt.so.3
#11 0x28767495 in QGPluginManager::featureList() const ()
   from /opt/qt/lib/libqt-mt.so.3
#12 0x08092fca in MainWindow::setupPluginManagers() ()
#13 0x0807cfcd in MainWindow::MainWindow(bool, bool, QString const&) ()
#14 0x0807b4db in main ()
#15 0x0807a995 in _start ()
(gdb) q up  q
The program is running.  Exit anyway? (y or n) y
bash-2.05b$ exit
exit

Script done on Sun Feb 16 17:22:34 2003

Question regarding LOR in vfs_mount.c

[Peter Kostouros]

Hi

The LOR detected in /usr/src/sys/kern/vfs_mount.c (process lock on line 
1144, and filedesc structure on line 1151) has been previously reported: 
I have noticed it upon shutdown. An LOR fix was presented recently for a 
similar LOR arising in kern_descrip.c , see 
http://www.freebsd.org/cgi/getmsg.cgi?fetch=571049+573330+/usr/local/www/db/text/2003/freebsd-current/20030202.freebsd-current, 
and replies. Following upon this, would a similar solution resolve the 
LOR in vfs_mount.c, or should something more involved be taking place?

--

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: Fatal trap 12: page fault while in kernel mode

[Peter Kostouros]

Hi

I recompiled the official nv driver with debugging symbols: X works as 
expected. My apologies if I alarmed anyone.

John Baldwin wrote:

On 22-Jan-2003 Peter Kostouros wrote:
 

Hi

I am having a similar problem to what has been reported previously
regarding X. Basically I get a fatal trap 12. (cvsup'ed about one hour
ago.) I have attached a backtrace I hope is useful.

When I started X within gdb, I received the following:

Program received signal SIGUSR1. User defined signal 1
0x2818b1a3 in sigsuspend() from /usr/lib/libc.so.5.
   


Unfortunately the bug is in a kernel module (the ?? lines
in your backtrace).  Could you possibly compile a custom
kernel that has everything you use in it and then reproduce
this bug and get a trace?

 

Peter
   


 



--

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

Fatal trap 12: page fault while in kernel mode

[Peter Kostouros]

Hi

I am having a similar problem to what has been reported previously
regarding X. Basically I get a fatal trap 12. (cvsup'ed about one hour
ago.) I have attached a backtrace I hope is useful.

When I started X within gdb, I received the following:

Program received signal SIGUSR1. User defined signal 1
0x2818b1a3 in sigsuspend() from /usr/lib/libc.so.5.

Peter

Script started on Wed Jan 22 19:55:34 2003
GNU gdb 5.2.1 (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-undermydesk-freebsd"...
panic: bwrite: buffer is not busy???
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address   = 0x308
fault code  = supervisor read, page not present
instruction pointer = 0x8:0xc03a9ce2
stack pointer   = 0x10:0xe09cb66c
frame pointer   = 0x10:0xe09cb678
code segment= base 0x0, limit 0xf, type 0x1b
= DPL 0, pres 1, def32 1, gran 1
processor eflags= interrupt enabled, resume, IOPL = 3
current process = 679 (XFree86)
trap number = 12
panic: page fault

syncing disks, buffers remaining... panic: bwrite: buffer is not busy???
Uptime: 8m37s
Dumping 511 MB
ata0: resetting devices ..
ad0: DMA limited to UDMA33, non-ATA66 cable or device
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 /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232
/mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232:6775:beg:0xc025687b
(kgdb) bt
#0  doadump () at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:232
#1  0xc0256d99 in boot (howto=260)
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:364
#2  0xc0256ff3 in panic ()
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:531
#3  0xc0299e82 in bwrite (bp=0xcc314d28)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:798
#4  0xc029b605 in vfs_bio_awrite (bp=0xcc314d28)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:1650
#5  0xc035390a in ffs_fsync (ap=0xe09cb474)
at /mnt/cvs/freebsd/usr/src/sys/ufs/ffs/ffs_vnops.c:258
#6  0xc0352a37 in ffs_sync (mp=0xc1f8d800, waitfor=2, cred=0xc150ae00, 
td=0xc0436000) at vnode_if.h:612
#7  0xc02afc9b in sync (td=0xc0436000, uap=0x0)
at /mnt/cvs/freebsd/usr/src/sys/kern/vfs_syscalls.c:138
#8  0xc025697c in boot (howto=256)
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:273
#9  0xc0256ff3 in panic ()
at /mnt/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:531
#10 0xc03af692 in trap_fatal (frame=0xe09cb62c, eva=0)
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:844
#11 0xc03af372 in trap_pfault (frame=0xe09cb62c, usermode=0, eva=776)
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:758
#12 0xc03aee60 in trap (frame=
---Type  to continue, or q  to quit---
  {tf_fs = 24, tf_es = 33554448, tf_ds = 16, tf_edi = -1067102624, tf_esi = 
812924928, tf_ebp = -526600584, tf_isp = -526600616, tf_ebx = -1037925756, tf_edx = 
193, tf_ecx = -526598752, tf_eax = 4, tf_trapno = 12, tf_err = 0, tf_eip = 
-1069900574, tf_cs = 8, tf_eflags = 78339, tf_esp = 812924928, tf_ss = 812924928}) at 
/mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:445
#13 0xc039f548 in calltrap () at {standard input}:98
#14 0xc06327d6 in ?? ()
#15 0xc0567b8e in ?? ()
#16 0xc05681d1 in ?? ()
#17 0xc055ca70 in ?? ()
#18 0xc056a1d9 in ?? ()
#19 0xc0569e1b in ?? ()
#20 0xc0631b9d in ?? ()
#21 0xc062fec1 in ?? ()
#22 0xc021bc09 in spec_ioctl (ap=0xc0654e60)
at /mnt/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:349
#23 0xc021b3a8 in spec_vnoperate (ap=0x0)
at /mnt/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:123
#24 0xc02b8591 in vn_ioctl (fp=0xc1fe02d0, com=3223602724, data=0xe09cbc48, 
active_cred=0xc23b3b00, td=0xc1ef4d20) at vnode_if.h:488
#25 0xc02798f3 in ioctl (td=0xc1ef4d20, uap=0xe09cbd10) at file.h:247
#26 0xc03af9ba in syscall (frame=
  {tf_fs = 47, tf_es = 140574767, tf_ds = -1078001617, tf_edi = 33554946, tf_esi = 
-104118, tf_ebp = -1077938072, tf_isp = -526598796, tf_ebx = -1077938---Type 
 to continue, or q  to quit---
020, tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip = 
673858499, tf_cs = 31, tf_eflags = 12934, tf_esp = -1077938100, tf_ss = 47})
at /mnt/cvs/freebsd/usr/src/sys/i386/i386/trap.c:1033
#27 0xc039f59d in Xint0x80_syscall () at {standard input}:140
---Can't read userspace from dump, or kernel process---

(kgdb) q

Script done on Wed Jan 22 19:55:39 2003

Re: VOP_STRATEGY on VCHR?

[Peter Kostouros]

Hi

I received a similar problem during booting into single user mode upon 
startup. I hope the following helps:

mounting root from ufs:/dev/ad2s1a
start_init: trying /sbin/init

VOP_STRATEGY on VCHR
:0xc189a00: tag none, type VCHR, usecount 5, write count 0, refcount  6, 
flags (VV_OBJBUF)

backtrace
spec_strategy
spec_getpages
ffs_getpages
vnode_pager_getpages
exec_map_first_page
kern_execve
execve
start_init
fork_exit
fork_trampoline

--- trap 0x1, eip = 0, esp = 0xcbaaed7c, ebp = 0 ---

[EMAIL PROTECTED] wrote:

In message <[EMAIL PROTECTED]>, walt writes:
 

After updating world and kernel this evening I saw this message fly by
during the reboot:

Mounting root from ufs:/dev/ad0s3a

VOP_STRATEGY on VCHR
: 0xc25fd000: tag none, type VCHR, usecount 5, writecount 0, refcount 6, flags (VV_OBJBUF),
Sorry, need DDB option to print backtrace

That feels like an error message (sort of) but everything seems to be
working normally.  Is this a real problem or just noise?
   


Well, to you it's just noise, to me it's a real problem :-)

It is probably the same problem as the one I just commited a fix for.

If you get this again after upgrading, please put the DDB option in
your kernel and see if you can reproduce it so I get a traceback.
The vnode information alone seems not quite as useful as I had hoped.

 



--

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: Trouble building X on fresh 5.0-RC2 install?

[Peter Kostouros]

Hi

It has been mentioned a few times, though not specifically for RC2. 
Check the archives for
subjects "X server - undefined symbols" and "XFree 4.2.1 doesn't work 
with last CURRENT".


walt wrote:

I've installed RC2 on my new ASUS A7V8X/AthlonXP and the
whole thing went very well except for building XFree.

X does compile with no complaints but when I attempt to
run it I get unresolved symbol errors and then a coredump.

I'm not asking for a fix here, really, so I won't bother
you with debugging details.  I'm just curious if
anyone else has had problems building X recently.

I'm a bit reluctant to try re-compiling it on my old
"stable" -CURRENT box because it's working so well ;)


To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message





--

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: XFree 4.2.1 doesn't work with last CURRENT

[Peter Kostouros]

Hi Aurelien

I was able to get X running once I recompiled (the server) with 
-fno-merge-constants. Unfortunately, I do not know if it has anything to 
do with the GCC ABI issue.

Aurelien Nephtali wrote:

Hi,

I've upgraded from 4.2.0 to 4.2.1 and now X11 doesn't want to start :/
I've attached the error log.

Any help would be appreciated :)

-- Aurelien
 



--

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

X server problem - undefined symbols

[Peter Kostouros]

Hi

After building a system from yesterday's sources (14/12/02), I rebuild 
my X server from ports. Upon invoking startx the X server terminated 
with the following messages:

Symbol  from module /usr/X11R6/lib/modules/fonts/libbitmap.a is unresolved.
...
...


/var/log/XFress86.0.log has something like:

(II) LoadModule: "bitmap"
(II) Loading /usr/X11R6/lib/modules/fonts/libbitmap.a
Not loading .rodata.str1.32
Not loading .rodata.str1.1
Not loading .rodata.cst8

and so on.

After an Internet search, I recompiled the server with 
-fno-merge-constants and the X server is now running.

--

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

nVidia drivers revisited

[Peter Kostouros]

Hi

My system was dumping core when I tried to invoke X with the recently 
released nVidia drivers installed (similar to Kris's problem?). Upon 
creating a kernel without INVARIANTS and INVARIANT_SUPPORT options, X 
runs well. My question is, of the X/nVidia success stories, were kernels 
built with or without INVARIANTS and INVARIANT_SUPPORT options?

For those interested, the panics I received were:

mutex vm page queue mutex not owned at .../usr/src/sys/vm/vm_page.c:1215.

The source was from about 23/11.

--

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

panic: Most recently used by kqueue

[Peter Kostouros]

Hi

System was generated Sunday evening (without INET6 option in kernel 
config). At the time of the panic
I was running mozilla, xmms, and gkrellm. I hope the attachment is of 
some use.

-- 

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






Script started on Tue Jul 30 20:14:40 2002
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 0xc686fe48 not locked
panic messages:
---
panic: Most recently used by kqueue


syncing disks... panic: bremfree: bp 0xc686fe48 not locked
Uptime: 42m24s
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  0xc028895a in boot (howto=260)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:345
#2  0xc0288b19 in panic ()
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493
#3  0xc02ba889 in bremfree (bp=0xc686fe48)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:633
#4  0xc02bbffa in vfs_bio_awrite (bp=0xc686fe48)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_bio.c:1627
#5  0xc0262950 in spec_fsync (ap=0xd00279dc)
at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:406
#6  0xc026253f in spec_vnoperate (ap=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/fs/specfs/spec_vnops.c:124
#7  0xc03584ed in ffs_sync (mp=0xc185c800, waitfor=2, cred=0xc0ef5e00, td=0xc046b6a0)
at vnode_if.h:463
#8  0xc02c9670 in sync (td=0xc046b6a0, uap=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/vfs_syscalls.c:127
#9  0xc0288601 in boot (howto=256)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:254
#10 0xc0288b19 in panic ()
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_shutdown.c:493
#11 0xc0376bfc in mtrash_ctor (mem=0xc1cff700, size=0, arg=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_dbg.c:135
#12 0xc0375b57 in uma_zalloc_arg (zone=0xc0ecf140, udata=0x0, flags=1)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_core.c:1358
#13 0xc027fbd4 in malloc (size=4, type=0xc04783c0, flags=0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_malloc.c:171
#14 0xc02debac in rt_msg2 (type=14, rtinfo=0xd0027b44, cp=0x0, w=0xd0027b94)
at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:690
#15 0xc02df0f0 in sysctl_iflist (af=0, w=0xd0027b94)
at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:954
#16 0xc02df309 in sysctl_rtsock (oidp=0xc04784e0, arg1=0xd0027cbc, arg2=4, 
req=0xd0027c08) at /mnt/aux3/cvs/freebsd/usr/src/sys/net/rtsock.c:1032
#17 0xc028f7b1 in sysctl_root (oidp=0x0, arg1=0xd0027cb4, arg2=6, req=0xd0027c08)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1104
#18 0xc028f980 in userland_sysctl (td=0x0, name=0xd0027cb4, namelen=6, 
old=0xd0027c60, oldlenp=0xa, inkernel=0, new=0xd0027c30, newlen=0, 
retval=0xd0027cb0) at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1202
#19 0xc028f845 in __sysctl (td=0xc17fef00, uap=0xd0027d14)
at /mnt/aux3/cvs/freebsd/usr/src/sys/kern/kern_sysctl.c:1141
#20 0xc039f134 in syscall (frame=
  {tf_fs = 47, tf_es = 135331887, tf_ds = -1078001617, tf_edi = 6, tf_esi = 
135884800, tf_ebp = -1077938100, tf_isp = -805143180, tf_ebx = 676064028, tf_edx = 
135005808, tf_ecx = -1077938024, tf_eax = 202, tf_trapno = 22, tf_err = 2, tf_eip = 
675666455, tf_cs = 31, tf_eflags = 658, tf_esp = -1077938160, tf_ss = 47})
at /mnt/aux3/cvs/freebsd/usr/src/sys/i386/i386/trap.c:1050
#21 0xc03925cd in syscall_with_err_pushed () at {standard input}:128
---Can't read userspace from dump, or kernel process---

(kgdb) up 11
#11 0xc0376bfc in mtrash_ctor (mem=0xc1cff700, size=0, arg=0x0)
at /mnt/aux3/cvs/freebsd/usr/src/sys/vm/uma_dbg.c:135
135 panic("Most recently used by %s\n", (*ksp == NULL)?
(kgdb) l
130 
131 for (p = mem; cnt > 0; cnt--, p++)
132 if (*p != uma_junk) {
133 printf("Memory modified after free %p(%d)\n",
134 mem, size);
135 panic("Most recently used by %s\n", (*ksp == NULL)?
136 "none" : (*ksp)->ks_shortdesc);
137 }
138 }
139 
(kgdb) p uma_junk
$1 = 3735929054
(kgdb) p *(u_int32_t *)mem
$2 = 3735929054
(kgdb) p *(u_int32_t *)mem[1@(mem + 4)

Re: About the recent kernel crashes.

[Peter Kostouros]

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

Re: About the recent kernel crashes.

[Peter Kostouros]

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