Re: devel/stlport compile broken in -current
Thanks, that looks like that was the issue... On Sun, 9 Feb 2003, Lamont Granquist wrote: > On Sun, 9 Feb 2003, Craig Rodrigues wrote: > > On Sun, Feb 09, 2003 at 10:54:27AM -0800, Lamont Granquist wrote: > > > looks like nobody has fixed stlport since the last time gcc was > > > upgraded... > > > > I don't get these error messages on -current. > > > > > g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W > > > -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O > > > -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o > > > ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o > > > In file included from ../stlport/stl/_alloc.h:60, > > > from ../stlport/memory:28, > > > from dll_main.cpp:38: > > > ../stlport/new:36:49: ../g++/new: No such file or directory > > ^^^ > > > > This file should exist in /usr/include/g++/new. > > > > How did you install -current? > > its been updated frequently over the past 6 months - 1 year... i think > there's been at least two compiler changes since i started tracking > -current... > > > Did you read all the entries in /usr/src/UPDATING, especially > > the entry dated 20020831? > > mmm i don't think i did that because it was phrased as being > optional and only if you encountered problems... i'll try that, thanks > for pointing it out... > > > 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: devel/stlport compile broken in -current
On Sun, 9 Feb 2003, Craig Rodrigues wrote: > On Sun, Feb 09, 2003 at 10:54:27AM -0800, Lamont Granquist wrote: > > looks like nobody has fixed stlport since the last time gcc was > > upgraded... > > I don't get these error messages on -current. > > > g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W > > -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O > > -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o > > ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o > > In file included from ../stlport/stl/_alloc.h:60, > > from ../stlport/memory:28, > > from dll_main.cpp:38: > > ../stlport/new:36:49: ../g++/new: No such file or directory > ^^^ > > This file should exist in /usr/include/g++/new. > > How did you install -current? its been updated frequently over the past 6 months - 1 year... i think there's been at least two compiler changes since i started tracking -current... > Did you read all the entries in /usr/src/UPDATING, especially > the entry dated 20020831? mmm i don't think i did that because it was phrased as being optional and only if you encountered problems... i'll try that, thanks for pointing it out... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic with hp psc 2210xi usb printer
My USB PCI hub is: ohci0: mem 0xec00-0xec000fff irq 5 at device 5.0 on pci2 usb0: OHCI version 1.0 usb0: on ohci0 usb0: USB revision 1.0 uhub0: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 3 ports with 3 removable, self powered ohci1: mem 0xeb80-0xeb800fff irq 6 at device 5.1 on pci2 usb1: OHCI version 1.0 usb1: on ohci1 usb1: USB revision 1.0 uhub1: NEC OHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered pci2: at device 5.2 (no driver attached) Here's what happened when I plugged it the printer (all i did was plug it in): ulpt0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2, iclass 7/1 ulpt0: using bi-directional mode umass0: Hewlett-Packard PSC 2200 Series, rev 2.00/1.00, addr 2 umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 255, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 14, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT (da1:umass-sim0:0:0:0): got CAM status 0x4 (da1:umass-sim0:0:0:0): fatal error, failed to attach to device (da1:umass-sim0:0:0:0): lost device umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT umass0: Residue incorrect, was 8, should've been 0 umass0: BBB reset failed, TIMEOUT (da1:umass-sim0:0:0:0): removing device entry Opened disk da1 -> 5 Feb 9 13:08:45 coredump syslogd: kernel boot file is /boot/kernel/kernel Fatal trap 12: page fault while in kernel mode cpuid = 1; lapic.id = 0100 fault virtual address = 0x68 fault code = supervisor read, pawe not present instruction pointer= 0x8:0xc02f1d41 stack pointer ( < 0x10:0xd7a37c0c frame pointer = 0x10:0xd7a37c2c 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= 502 (tcsh) This is from -current as of around: 5.0-CURRENT #2: Thu Feb 6 18:59:11 PST 2003 And I've deleted my kernel.debug (and sources, and object tree), so debugging the panic I got out of it is unfortunately not going to be too useful... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
devel/stlport compile broken in -current
looks like nobody has fixed stlport since the last time gcc was upgraded... (i don't know C++ very well, so wasn't able to fix it myself...) > make ===> Extracting for stlport-gcc-4.5.3_1 >> Checksum OK for STLport-4.5.3.tar.gz. ===> stlport-gcc-4.5.3_1 depends on executable: gmake - found ===> Patching for stlport-gcc-4.5.3_1 ===> Applying FreeBSD patches for stlport-gcc-4.5.3_1 ===> Configuring for stlport-gcc-4.5.3_1 ===> Building for stlport-gcc-4.5.3_1 echo "Note : this makefile requires gmake on FreeBSD" Note : this makefile requires gmake on FreeBSD mkdir -p ../lib/obj/GCC-FREEBSD/ReleaseD g++ -D_THREAD_SAFE -D_REENTRANT -fexceptions -I../stlport -Wall -W -Wno-sign-compare -Wno-unused -Wno-uninitialized -ftemplate-depth-32 -O -pipe -march=athlon-mp -fPIC dll_main.cpp -c -o ../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:36:49: ../g++/new: No such file or directory In file included from ../stlport/stl/_alloc.h:60, from ../stlport/memory:28, from dll_main.cpp:38: ../stlport/new:45: `nothrow_t' not declared ../stlport/new:46: `nothrow' not declared ../stlport/new:52: `new_handler' not declared ../stlport/new:53: `set_new_handler' not declared ../stlport/stl/_pthread_alloc.c: In static member function `static _STL::_Pthread_alloc_per_thread_state<_Max_size>* _STL::_Pthread_alloc<_Max_size>::_S_get_per_thread_state() [with unsigned int _Max_size = 128]': dll_main.cpp:160: instantiated from here ../stlport/stl/_pthread_alloc.c:81: invalid use of undefined type `struct std::bad_alloc' :81: forward declaration of `struct std::bad_alloc' dll_main.cpp:160: instantiated from here ../stlport/stl/_pthread_alloc.c:90: invalid use of undefined type `struct std::bad_alloc' :90: forward declaration of `struct std::bad_alloc' ../stlport/stl/_alloc.c: In static member function `static void* _STL::__malloc_alloc<__inst>::_S_oom_malloc(unsigned int) [with int __inst = 0]': dll_main.cpp:163: instantiated from here ../stlport/stl/_alloc.c:75: invalid use of undefined type `struct std::bad_alloc' :75: forward declaration of `struct std::bad_alloc' : In function `void _STL::_Construct(_T1*, const _T2&) [with _T1 = void*, _T2 = void*]': ../stlport/stl/_alloc.h:365: instantiated from `void _STL::allocator<_Tp>::construct(_Tp*, const _Tp&) const [with _Tp = void*]' dll_main.cpp:169: instantiated from here :85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file : In function `void _STL::_Construct(_T1*, const _T2&) [with _T1 = char, _T2 = char]': ../stlport/stl/_alloc.h:365: instantiated from `void _STL::allocator<_Tp>::construct(_Tp*, const _Tp&) const [with _Tp = char]' dll_main.cpp:184: instantiated from here :85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file : In function `void _STL::_Construct(_T1*) [with _T1 = char]': ../stlport/stl/_string.h:326: instantiated from `void _STL::basic_string<_CharT, _Traits, _Alloc>::_M_construct_null_aux(_CharT*, const _STL::__false_type&) [with _CharT = char, _Traits = _STL::char_traits, _Alloc = _STL::allocator]' dll_main.cpp:192: instantiated from here :93: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:93: at this point in file gmake: *** [../lib/obj/GCC-FREEBSD/ReleaseD/dll_main.o] Error 1 *** Error code 2 Stop in /usr/ports/devel/stlport. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
(kgdb) frame 2
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
748 /usr/src/sys/cam/cam_periph.c: No such file or directory.
in /usr/src/sys/cam/cam_periph.c
(kgdb) print *periph
$11 = {pinfo = {priority = 1, generation = 6, index = 1},
periph_start = 0xc0157220 ,
periph_oninval = 0xc0156d70 ,
periph_dtor = 0xc0156e00 , periph_name = 0xc049b503 "pass",
path = 0xc406dcc0, softc = 0xc41e6000, unit_number = 1,
type = CAM_PERIPH_BIO, flags = 0, immediate_priority = 1, refcount = 1,
ccb_list = {slh_first = 0x0}, periph_links = {sle_next = 0x0},
unit_links = {
tqe_next = 0x0, tqe_prev = 0xc41cdb40}, deferred_callback = 0,
deferred_ac = 0}
(kgdb)
On Thu, 12 Dec 2002, Nate Lawson wrote:
> On Thu, 12 Dec 2002, Lamont Granquist wrote:
> > On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
> > > On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
> > > > On Tue, 10 Dec 2002, Lamont Granquist wrote:
> > > > > # ps xauww | egrep cda
> > > > > root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
> > > > > /usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
> > > > > # strace -p 36761
> > > > > ioctl(0, CAMGETPASSTHRU
> > > > >
> > > > > (...hangs forever and won't die with kill -9...)
> > > >
> > > > ps axl output for that proc, please.
> > >
> > > It's probably hanging waiting for a CCB, although ps axl output should tell
> > > us whether or not that's the case.
> > >
> > > If that is the case, it raises the "why" question, especially since nothing
> > > has changed in that area recently that I know of.
> >
> > i panic'd the system and got this for a bt on the process:
> >
> > (kgdb) bt
> > #0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
> > #1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
> > wmesg=0x0,
> > timo=0) at /usr/src/sys/kern/kern_synch.c:262
> > #2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
> > at /usr/src/sys/cam/cam_periph.c:748
> > #3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
> > error_routine=0xc01574f0 ) at
> > /usr/src/sys/cam/cam_periph.c:784
> > #4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 "", flag=3,
> > td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
> > #5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
> > at /usr/src/sys/fs/specfs/spec_vnops.c:352
> > #6 0xc02b3d18 in spec_vnoperate (ap=0x0)
> > at /usr/src/sys/fs/specfs/spec_vnops.c:126
> > #7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
> > data=0xc41f2800,
> > active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
> > #8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
> > #9 0xc046cc7e in syscall (frame=
> > {tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
> > 134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
> > tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
> > 672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
> > at /usr/src/sys/i386/i386/trap.c:1033
> > #10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
>
> This indicates the system is waiting for a CCB (blocked on tsleep in
> cam_periph_getccb). The call to xpt_schedule should make a CCB available
> and if it doesn't, it goes to sleep. A later schedule should hit the
> start entry for a driver that relinquishes its ccb and calls wakeup.
>
> Ken, I don't see any change that would cause this problem either. When
> did this problem start occurring? Also, it might be good to add a PCATCH
> to the tsleep since it's ok to interrupt here (I think).
>
> It would be great if you could do "frame 2" and then "print *periph"
>
> -Nate
>
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Wed, 11 Dec 2002, Kenneth D. Merry wrote:
> On Wed, Dec 11, 2002 at 11:37:42 -0800, Nate Lawson wrote:
> > On Tue, 10 Dec 2002, Lamont Granquist wrote:
> > > # ps xauww | egrep cda
> > > root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01
> > > /usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on
> > > # strace -p 36761
> > > ioctl(0, CAMGETPASSTHRU
> > >
> > > (...hangs forever and won't die with kill -9...)
> >
> > ps axl output for that proc, please.
>
> It's probably hanging waiting for a CCB, although ps axl output should tell
> us whether or not that's the case.
>
> If that is the case, it raises the "why" question, especially since nothing
> has changed in that area recently that I know of.
i panic'd the system and got this for a bt on the process:
(kgdb) bt
#0 mi_switch () at /usr/src/sys/kern/kern_synch.c:522
#1 0xc02f2027 in msleep (ident=0xc41fc0b8, mtx=0x0, priority=76,
wmesg=0x0,
timo=0) at /usr/src/sys/kern/kern_synch.c:262
#2 0xc0140ffc in cam_periph_getccb (periph=0xc41fc080, priority=1)
at /usr/src/sys/cam/cam_periph.c:748
#3 0xc01410a5 in cam_periph_ioctl (periph=0x0, cmd=-1033890813, addr=0x0,
error_routine=0xc01574f0 ) at
/usr/src/sys/cam/cam_periph.c:784
#4 0xc01573b8 in passioctl (dev=0x0, cmd=0, addr=0xc41f2800 "", flag=3,
td=0xc42fdc40) at /usr/src/sys/cam/scsi/scsi_pass.c:533
#5 0xc02b45ee in spec_ioctl (ap=0xc41f2800)
at /usr/src/sys/fs/specfs/spec_vnops.c:352
#6 0xc02b3d18 in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:126
#7 0xc034ae91 in vn_ioctl (fp=0xc4340f3c, com=3261076483,
data=0xc41f2800,
active_cred=0xc5eb9100, td=0xc42fdc40) at vnode_if.h:488
#8 0xc0310686 in ioctl (td=0xc42fdc40, uap=0xdacb0d10) at file.h:227
#9 0xc046cc7e in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077942432, tf_esi =
134979584, tf_ebp = -1077942408, tf_isp = -624226956, tf_ebx = 672215480,
tf_edx = 0, tf_ecx = 0, tf_eax = 54, tf_trapno = 12, tf_err = 2, tf_eip =
672506643, tf_cs = 31, tf_eflags = 582, tf_esp = -1077943092, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1033
#10 0xc045cd2d in Xint0x80_syscall () at {standard input}:140
Cannot access memory at address 0xbfbfe778
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ioctl(CAMGETPASSTHRU) hung X11/cda process
On Wed, 11 Dec 2002, Nate Lawson wrote: > On Tue, 10 Dec 2002, Lamont Granquist wrote: > > # ps xauww | egrep cda > > root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01 > > /usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on > > # strace -p 36761 > > ioctl(0, CAMGETPASSTHRU > > > > (...hangs forever and won't die with kill -9...) > > ps axl output for that proc, please. UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND 0 36761 1 6 -8 0 1884 1132 cgticb D p40:00.01 /usr/X11R6/l To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ioctl(CAMGETPASSTHRU) hung X11/cda process
# ps xauww | egrep cda root 36761 0.0 0.3 1884 1452 p4 D 7:25PM 0:00.01 /usr/X11R6/lib/X11/xmcd/bin-FreeBSD_5-i386/cda -batch -dev /dev/cd0 on # strace -p 36761 ioctl(0, CAMGETPASSTHRU (...hangs forever and won't die with kill -9...) This device is: cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: cd present [308392 x 2048 byte records] And i'm running a fairly current -current: # uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #18: Wed Dec 4 10:39:19 PST 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: mi_switch deadlock?
okay, any idea what i'm looking for then? something is locking the whole system up... On Thu, 24 Oct 2002, Julian Elischer wrote: > On Thu, 24 Oct 2002, Lamont Granquist wrote: > > my -current box keeps freezing about every 24h. i broke into the kernel > > and forced a panic and found lots of processes stuck in mi_switch(). > > Most processes are actually in mi_switch > that's the last think a process does before it is switched away from.. > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
mi_switch deadlock?
my -current box keeps freezing about every 24h. i broke into the kernel and forced a panic and found lots of processes stuck in mi_switch(). my uname is a build from tuesday running on an SMP machine: uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #16: Tue Oct 22 19:42:51 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386 i can get more information if anyone needs it... Script started on Thu Oct 24 18:58:57 2002 You have mail. coredump# gdb -k kernel.debug /var/crash/vmcore.4 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: bremfree: bp 0xce62a48c not locked panic messages: --- panic: lockmgr: pid 8272, not exclusive lock holder 7858 unlocking panic: from debugger Uptime: 4h30m13s pfs_vncache_unload(): 1 entries remaining Dumping 511 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #16: Tue Oct 22 19:42:51 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc06a5000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc06a50a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1400057705 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 536788992 (524208K bytes) avail memory = 513298432 (501268K bytes) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 9 entries at 0xc00f1370 acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: on pcib0 agp0: port 0xe800-0xe803 mem 0xfb80-0xfb800fff,0xfc00-0xfdff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.3 (no driver attached) ahc0: port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 16.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.OP2P - AE_NOT_FOUND pci2: on pcib2 fxp0: port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounter
sys/event.h EV_SET macro suggestion
I'd suggest this:
#define EV_SET(kevpin, a, b, c, d, e, f) do { \
struct kevent *kevp = kevpin; \
(kevp)->ident = (a);\
(kevp)->filter = (b); \
(kevp)->flags = (c);\
(kevp)->fflags = (d); \
(kevp)->data = (e); \
(kevp)->udata = (f);\
} while(0)
As opposed to what it is currently defined as:
#define EV_SET(kevp, a, b, c, d, e, f) do { \
(kevp)->ident = (a);\
(kevp)->filter = (b); \
(kevp)->flags = (c);\
(kevp)->fflags = (d); \
(kevp)->data = (e); \
(kevp)->udata = (f);\
} while(0)
The alternative I'm suggesting will work in the use case:
EV_SET(&kev_in[numchanges++], fd, EVFILT_READ, EV_DELETE, 0, 0, 0);
Which is probably a common way to try to use the macro, and the existing
behavior can certainly catch you off guard...
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: perl busted, spins, ignores SIGKILL
On Wed, 4 Sep 2002, Thomas Quinot wrote: > Le 2002-09-03, Lamont Granquist écrivait : > > i cvsup'd last night, and now i tried portupdate -a -f and debugging > > build problems with libtool i found that on my system i can make perl spin > > and consume 100% of a CPU just by: > > > > perl -pe s/foo/bar/g /tmp > > Any chance you have a /usr/local/bin/perl pointing back to > /usr/bin/perl? Cf. PR bin/42418. yes, in fact i appear to have that very problem... that's a really annoying bug... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
On Mon, 2 Sep 2002, David O'Brien wrote: > On Mon, Sep 02, 2002 at 02:17:25AM -0700, Lamont Granquist wrote: > > On Sun, 1 Sep 2002, David O'Brien wrote: > > > On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: > > > > It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy > > > > by the time that 5.2 and 5.3 come out. > > > > > > How would gcc-3.2 get more buggy over time than it is today?? > > > > I said it was buggy. Do you mean to imply that gcc-3.2 doesn't have a > > single bug in it? > > Labling software as "buggy" is a major put down. If GCC 3.2 is "buggy" > because it has at least one bug; then FreeBSD 4.7 will also be buggy as > hell. A year from now it probably will be seen as being buggy as hell and i think you're taking the description of "buggy" far too personally... Software has bugs, over time those bugs surface, some of them are due to design flaws which mean they don't get fixed in older versions and also developers tend to abandon support of older versions. The perception is that the software becomes buggy and it becomes frustrating to work with that software, even if you were perfectly happy with it a year ago. > > Admittedly I should have said "unmaintained" though -- point being that > > the bugs in it wouldn't be getting fixed by gcc developers who would > > rather fix them in 3.3... > > We don't maintain 3.x either -- much to the disappointment of some that > based products or major deployments on it. But I do think we support the > current release branch much better than the GCC people do. We have a > much more liberal MFC policy which lets us continue to fix invasive bugs > and add new features. Even more reason to try to get as current with gcc as possible with 5.0 -- if they're not liberally "MFC'ing" to 3.2 then it makes sense to launch 5.0 on a pre-3.3. Otherwise its up to the FreeBSD developers to try to duplicate the gcc developers efforts and patch gcc-3.2 in the 5.0 tree. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
perl busted, spins, ignores SIGKILL
i cvsup'd last night, and now i tried portupdate -a -f and debugging
build problems with libtool i found that on my system i can make perl spin
and consume 100% of a CPU just by:
perl -pe s/foo/bar/g /tmp
(turs out i can do this with any perl command, even perl --version...)
i also can't kill this process, or attach to it with gdb. i can get an
strace though which looks like:
execve("<8A>^D(H^E(<^D^E(^?^R
", [], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = 0
mmap(0, 2664, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x28061000
munmap(0x28061000, 2664)= 0
__sysctl([sysctl.debug], 2, "", [0], NULL, 0) = 0
mmap(0, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANON, -1, 0) =
0x28061000
geteuid(0x28049000) = 0
getuid()= 0 (euid 0)
getegid(0x28049000) = 0
getgid()= 0 (egid 0)
open("/var/run/ld-elf.so.hints", O_RDONLY) = 3
read(3, " object\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 128)
= 128
lseek(3, 549755813888, SEEK_SET)= 128
read(3, "/usr/lib:/usr/lib/compat:/usr/X1"..., 55) = 55
close(3)= 0
access("/usr/lib/libc.so.5", F_OK) = 0
open("/usr/lib/libc.so.5", O_RDONLY)= 3
fstat(3, {st_mode=0, st_size=0, ...}) = 0
read(3, "\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 4096)
= 409
6
mmap(0, 794624, PROT_READ|PROT_EXEC, MAP_PRIVATE, 3, 0) = 0x28069000
mmap(0x28113000, 20480, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED, 3,
0xa9
000) = 0x28113000
mmap(0x28118000, 77824, PROT_READ|PROT_WRITE,
MAP_PRIVATE|MAP_FIXED|MAP_ANON, -1
, 0) = 0x28118000
close(3)= 0
mmap(0, 216, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2812b000
munmap(0x2812b000, 216) = 0
mprotect(0x28069000, 696320, PROT_READ|PROT_WRITE|PROT_EXEC) = 0
mmap(0, 18824, PROT_READ|PROT_WRITE, MAP_ANON, -1, 0) = 0x2812b000
munmap(0x2812b000, 18824) = 0
mprotect(0x28069000, 696320, PROT_READ|PROT_EXEC) = 0
sigaction(SIGILL, {SIG_DFL}, {SIG_DFL}) = 0
sigprocmask(SIG_BLOCK, NULL, [])= 0
sigaction(SIGILL, {SIG_DFL}, NULL) = 0
sigprocmask(SIG_BLOCK, ~[ILL TRAP ABRT EMT FPE BUS SEGV SYS], []) = 0
sigprocmask(SIG_SETMASK, [], NULL) = 0
execve("<8A>^D(H^E(D^L^E(^?^R
", [], [/* 0 vars */]) = -1 ENOENT (No such file or directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = -1 ENOENT (No such file or
directory)
execve("", [], [/* 0 vars */]) = 0
(wash, rinse, repeat endlessly..)
strace sometimes fails with:
PIOCWSTOP: Input/output error
ahhh... the plot thickens, now its stopped consuming CPU, strace does
this:
coredump# strace -p 4432
--- SIGINT (Interrupt) ---
--- SIGINT (Interrupt) ---
coredump# strace -p 4432
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file
coredump# strace -p 4432
strace: open("/proc/...", ...): No such file or directory
trouble opening proc file
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
On Sun, 1 Sep 2002, David O'Brien wrote: > On Sun, Sep 01, 2002 at 12:37:14PM -0700, Lamont Granquist wrote: > > It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy > > by the time that 5.2 and 5.3 come out. > > How would gcc-3.2 get more buggy over time than it is today?? I said it was buggy. Do you mean to imply that gcc-3.2 doesn't have a single bug in it? Admittedly I should have said "unmaintained" though -- point being that the bugs in it wouldn't be getting fixed by gcc developers who would rather fix them in 3.3... > "archaic" does apply however. > > Why the fsck can't people come up to speed on an issue before spewing > FUD? I fail to see why assuming that a software project the size of the gcc compiler has a few bugs is "FUD"... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc 3.1 / streambuf.h broken with "using namespace std;"
On Sun, 1 Sep 2002, David O'Brien wrote: > 3.3.0 will be released before FreeBSD 5.1. It is my advice to > FreeBSD'ville that we go with a GCC 3.3 snapshot for FBSD 5.0 and a GCC > 3.3.0 release for FBSD 5.1. That way we can get the new features of 3.3 > into our 5.x branch. AND get bug fixes by importing 3.3.1 and 3.3.2 into > later FBSD 5.x releases. 5.0 will be a beta and will not be ready for production use right? If so, it seems perfectly acceptable to use a 3.3 snapshot and risk breaking binary compatibility between 5.0 and 5.1. If it happens, you mention the breakage in UPDATING and people who are using 5.0 should be expected to be paying attention. This way we get to where we want to be, which is 5.2 or 5.3 being a stable operating system with a stable and well-supported compiler. That seems to be the right long-term goal to shoot for. It sounds like gcc-3.1 or gcc-3.2 will be archaic and buggy by the time that 5.2 and 5.3 come out. I'm not sure exactly how FreeBSD would be "pulling a redhat" by putting in a development snapshot if the 5.0 release is clearly labelled for non-production use only... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
panic + scsi
i actually got a crash dump last night, panic + bt below...
also, scsi hasn't been working for me for at least a week or two now...
i'm using this:
pci0: at device 7.3 (no driver attached)
ahc_pci0: port 0xd400-0xd4ff mem
0xed8
0-0xed800fff irq 10 at device 9.0 on pci0
aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs
ahc_pci1: port 0xd000-0xd0ff mem
0xed0
0-0xed000fff irq 5 at device 9.1 on pci0
aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs
cd0 at ahc0 bus 0 target 4 lun 0
cd0: Removable CD-ROM SCSI-2 device
cd0: 20.000MB/s transfers (20.000MHz, offset 16)
cd0: Attempt to query device size failed: NOT READY, Medium not present -
tray closed
da0 at ahc0 bus 0 target 0 lun 0
da0: Fixed Direct Access SCSI-3 device
da0: 40.000MB/s transfers (20.000MHz, offset 63, 16bit), Tagged Queueing
Enabled
da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C)
but, for example, it doesn't find my CD/RW anymore:
coredump# cdrecord -scanbus
Cdrecord 1.11a28 (i386-unknown-freebsd5.0) Copyright (C) 1995-2002 Jrg
Schilling
cdrecord: No such file or directory. Cannot open SCSI driver.
cdrecord: For possible targets try 'cdrecord -scanbus'. Make sure you are
root.
=
panic: bremfree: bp 0xce6484bc not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
cpuid = 0; lapic.id =
fault virtual address = 0xed839a3c
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02e3670
stack pointer = 0x10:0xda07eb80
frame pointer = 0x10:0xda07eb88
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 = 3153 (perl)
trap number = 12
panic: page fault
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bremfree: bp 0xce6484bc not locked
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 11h58m20s
Dumping 511 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320
336 352 368 384 400 416 432 448 464 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc01cfa86 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:345
#2 0xc01cfd28 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#3 0xc0210dc7 in bremfree (bp=0xce6484bc) at
/usr/src/sys/kern/vfs_bio.c:633
#4 0xc02135b0 in getblk (vp=0xc41d, blkno=19915072, size=8192,
slpflag=0,
slptimeo=0) at /usr/src/sys/kern/vfs_bio.c:2318
#5 0xc0210efa in breadn (vp=0xc41d, blkno=0, size=0, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at
/usr/src/sys/kern/vfs_bio.c:691
#6 0xc0210eac in bread (vp=0x0, blkno=0, size=0, cred=0x0, bpp=0x0)
at /usr/src/sys/kern/vfs_bio.c:673
#7 0xc0278518 in ffs_update (vp=0xc42d2b90, waitfor=0)
at /usr/src/sys/ufs/ffs/ffs_inode.c:102
#8 0xc028b4df in ffs_fsync (ap=0xda07e9ac)
at /usr/src/sys/ufs/ffs/ffs_vnops.c:292
#9 0xc028a798 in ffs_sync (mp=0xc41c4800, waitfor=2, cred=0xc158be80,
td=0xc034b440) at vnode_if.h:597
#10 0xc02236e8 in sync (td=0xc034b440, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:129
#11 0xc01cf69b in boot (howto=256) at
/usr/src/sys/kern/kern_shutdown.c:254
#12 0xc01cfd28 in panic () at /usr/src/sys/kern/kern_shutdown.c:493
#13 0xc02e77e3 in trap_fatal (frame=0xda07eb40, eva=0)
at /usr/src/sys/i386/i386/trap.c:846
#14 0xc02e7492 in trap_pfault (frame=0xda07eb40, usermode=0,
eva=3984824892)
at /usr/src/sys/i386/i386/trap.c:760
#15 0xc02e6fbd in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1051056628, tf_esi =
-105732, tf_ebp = -637015160, tf_isp = -637015188, tf_ebx =
-1051056628, tf_edx = -1052943316, tf_ecx = 1, tf_eax = -1052962508,
tf_trapno = 12, tf_err = 2, tf_eip = -1070713232, tf_cs = 8, tf_eflags =
66194, tf_esp = 672165888, tf_ss = 0})
at /usr/src/sys/i386/i386/trap.c:446
#16 0xc02d1138 in calltrap () at {standard input}:99
#17 0xc02e3e31 in pmap_enter (pmap=0xc15a260c, va=3243910668,
m=0xc0fdc3a4,
prot=5 '\005', wired=0) at /usr/src/sys/i386/i386/pmap.c:2133
#18 0xc029c9f7 in vm_fault (map=0xc15a2594, vaddr=672165888,
fault_type=1 '\001', fault_flags=0) at /usr/src/sys/vm/vm_fault.c:880
#19 0xc02e73c2 in trap_pfault (frame=0xda07ed48, usermode=1,
eva=672169472)
at /usr/src/sys/i386/i386/trap.c:736
#20 0xc02e6e22 in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 671498288,
tf_ebp = -1077937068, tf_isp = -637014668, tf_ebx = 671478504, tf_edx =
671498304, tf_ecx = 671498304, tf_eax = 672229336, tf_trapno = 12, tf_err
= 4, tf_eip = 672169472, tf_cs = 31, tf_eflags = 66118, tf_esp =
-1077937100, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:332
#21 0xc02d1138 in calltrap () at {standard input}:99
---
UFS Snapshots kinda buggy?
So, I was playing around with snapshots and trying to come up with a cron
job which would do automatic snapshots of a system, kind of similar to
what you can get with a NetApp. I wrote the attatched (somewhat ugly)
proof of concept script to manage a /.snapshot directory for all the
mounted filesystems on a box. Running this in a tight loop caused some
pretty severe problems where the box would tend to panic if i tried to
remove some of the snapshot files. A whole lot of "rm, panic,
reboot, fsck, wash, rinse, repeat" later I seem to have cleared all
the snapshot files off my system and stabilized it.
My -current snapshot is:
> uname -a
FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #10: Sun
Jul 28 18:30:39 PDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP i386
My mounts are:
> mount
/dev/ad0s1a on / (ufs, local, soft-updates)
devfs on /dev (devfs, local)
procfs on /proc (procfs, local)
And my dmesg is attatched.
Incidentally, it might be good to have mount report that a filesystem is
a mounted snapshot. It would make it very easy to grep to select or
remove all the mounted snapshots from the output of mount.
I'm hoping that the rotatesnapshots script is enough to replicate and
identify the bugs. If not, feel free to contact me and I can try to
replicate them on my system to get more information on the specifics of
the panics...
#!/bin/sh
for fs in `mount -t ufs | egrep -v read-only | awk '{ print $3 }'`; do
echo "rotating snapshots on $fs"
# create .snapshot directory if it doesn't exist
if [ ! -e "$fs/.snapshot" ]; then
echo "creating .snapshot directory on $fs"
mkdir "$fs/.snapshot"
fi
# get number of snapshot files in .snapshot
num=`ls $fs/.snapshot | egrep "\.snap" | wc -l`
# unlink them if there are more than 20
if [ $num -ge 20 ]; then
nunlink=$(( $num - 19 ))
echo "unlinking $nunlink snapshot files"
for sf in `ls -t $fs/.snapshot | egrep ".snap" | tail -$nunlink`; do
snapfile="$fs/.snapshot/$sf"
sd=`echo $sf | sed -e s/\.snap/snap/`
snapdir="$fs/.snapshot/$sd"
md=`mount | egrep $sd | awk '{ print $1 }' | sed -e
s/.dev.md//'`
echo "unmounting $snapdir"
umount $snapdir
echo "removing $snapdir"
rmdir $snapdir
echo "removing /dev/md$md"
mdconfig -d -u $md
echo "deleting $snapfile"
rm -f $snapfile
done
fi
# do a snapshot
date=`date +%Y-%m-%d-%H:%M:%S`
snapfile="$fs/.snapshot/.snap-$date"
snapdir="$fs/.snapshot/snap-$date"
echo "mounting snapshot file"
mount -u -o snapshot $snapfile $fs
md=0
while [ -e "/dev/md$md" ]; do
md=$(($md + 1))
done
echo "creating /dev/md$md"
mdconfig -a -t vnode -f $snapfile -u $md
echo "creating $snapdir"
mkdir $snapdir
echo "mounting $snapdir"
mount -r /dev/md$md $snapdir
done
#/.snapshot/.snap-2002-05-04-20:02
#/.snapshot/snap-2002-05-04-20:02
Copyright (c) 1992-2002 The FreeBSD Project.
Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
FreeBSD 5.0-CURRENT #10: Sun Jul 28 18:30:39 PDT 2002
[EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP
Preloaded elf kernel "/boot/kernel/kernel" at 0xc047b000.
Preloaded elf module "/boot/kernel/acpi.ko" at 0xc047b0a8.
Timecounter "i8254" frequency 1193182 Hz
CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU)
Origin = "AuthenticAMD" Id = 0x662 Stepping = 2
Features=0x383fbff
AMD Features=0xc048
real memory = 536788992 (524208K bytes)
avail memory = 51598 (503852K bytes)
Programming 24 pins in IOAPIC #0
IOAPIC #0 intpin 2 -> irq 0
FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs
cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0
cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0
io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0
Pentium Pro MTRR support enabled
Using $PIR table, 9 entries at 0xc00f1370
npx0: on motherboard
npx0: INT 16 interface
acpi0: on motherboard
acpi0: power button is handled as a fixed feature programming model.
acpi0: sleep button is handled as a fixed feature programming model.
Timecounter "ACPI-fast" frequency 3579545 Hz
acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0
acpi_cpu0: on acpi0
acpi_cpu1: on acpi0
acpi_button0: on acpi0
acpi_pcib0: port 0xc
Re: Removing INET6 does stop the crashes.
Yeah, removing INET6 seems to make it much more stable for me as well. On Sun, 28 Jul 2002, walt wrote: > After reading Scott Long's recent post I tried removing INET6 > from my kernel config and the crashes due to mozilla are now > definitely gone. > > The question remains, I suppose, whether there are other programs > that will still trigger the same kernel bug in a different way, > or whether the bug truly is in the INET6 code. I do know I was > never trying to connect to any ipv6 site during the crashes, > which seems a bit suspicious. > > If Seigo Tanimura's recent swapping patch also fixes the crashing > (I haven't yet tried it) then perhaps the INET6 thing is just a > red herring--but for now it seems okay to me. > > > 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
-current now really bad
I cvsup'd and built last night around midnight and now I can reliably induce a freeze by firing up X and trying to load a page in mozilla (firing up mozilla doesn't do it, but the first page i try to load kills it). I get no crash dumps, and have to physically power the machine down. Attatched is a dmesg from my machine. I'm running: Mozilla 1.0 Release Candidate 2 XFree86 Version 4.2.0 / X Window System (protocol Version 11, revision 0, vendor release 6600) Release Date: 18 January 2002 sawfish version 1.0.1 I'm not sure how to find my gnome version... Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #9: Sun Jul 28 00:46:20 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc04ae000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc04ae0a8. Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 536788992 (524208K bytes) avail memory = 515735552 (503648K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2,version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1370 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.3 (no driver attached) ahc0: port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 16.0 on pci0 pci2: on pcib2 fxp0: port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 Timecounters tick every 10.000 msec APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 12949MB [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM at ata1-master PIO4 Mounting root from ufs:/dev/ad0s1a SMP: AP CPU #1 Launched! cd0 at ahc0 bus 0 target 4 lun 0 cd0: Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY, Medium not present - tray closed da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 40.000MB/s transfers (20.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C) WARNING: / was not properly dismounted /: mount pending error: blocks 2 files 0 /: reload pending error: blocks 2 files 0 Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #8: Wed Jul 17 23:03:58 PDT 2002
-current seems a little unstable tonight
I just cvsup'd and about 1.5h later got a crash+reboot with no dump. I think someone else mentioned problems with fsck and I saw something like that too -- it looked like the rc scripts errored out after the fsck and dropped me into single user... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE M-III status & junior hacker project.
On Sun, 7 Jul 2002, Josef Karthauser wrote: > On Sat, Jul 06, 2002 at 04:57:08PM -0700, Julian Elischer wrote: > > Well with various hints from here and there I have fixed > > the ^Z/fg problem (at least it seems fixed to me and others that > > have tested) This basically leaves only one outstanding > > problem that I know of which is a problem that Warner has with a > > particular progam. (This may also be fixed but I don't know) > > > > If anyone knows of something that was broken by the KSE commit, > > (i.e. it worked just before and not after) and is STILL > > broken please let me know because I think I can pretty much declare that > > chapter finished, and I'd like to get on with "extending" KSE > > functionality. This will be the start of Milestone IV, which would be > > add support for threads to run on multiple processors. > > Coincident with that some work should also proceed on gradually > > identifying and cleaning up places in the kernel where multithreading > > is just not ready.. e.g. which thread status do you get when you type ^T? > > I've absolutely no idea what's causing it, but I'm still having random reboots > of current after some uptime with no dumps. I'll install a new kernel > today and report back if it still happens. Maybe someone can help me to > track it down. I'm having problems like that every 1-3 days, but my build is pre-KSE-III (post-gcc-3.1 though). To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc internal compiler error with mozilla
On Mon, 27 May 2002, Sheldon Hearn wrote: > On Sun, 26 May 2002 15:28:44 MST, Lamont Granquist wrote: > > I got non-deterministic internal compiler errors when I was trying to > > compile mozilla. At the same time I was compiling gnome in another > > terminal window. It only happened with mozilla, it was non-deterministic > > in that I could do another 'make' and it would proceed past the point it > > failed. > > At the moment, the c++ compiler in the base system can't be used to > build Mozilla. > > Install the lang/gcc31 port and build Mozilla as follows: > > cd /usr/ports/www/mozilla > make CXX=/usr/local/bin/g++31 > > A few people have reported on this mailing list that the above works. > The archives are your friend. I'd seen this for gcc 3.1, but not for 2.9x. I thought I'd report it in case it turned out to be an OS issue rather than a gcc one... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Lock order reversal
I just got this in dmesg: lock order reversal 1st 0xdaa8ce2c process lock (process lock) @ /usr/src/sys/kern/kern_exec.c:316 2nd 0xc0424d60 filelist lock (filelist lock) @ /usr/src/sys/kern/kern_descrip.c:1112 What other information is needed to debug this? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Messages from WITNESS [Sun May 26 kernel]
from May 26 kernel:
% dmesg | egrep sleep | sort | uniq -c
3 /usr/src/sys/vm/uma_core.c:1324: could sleep with "UMA lock" locked
from /usr/src/sys/vm/uma_core.c:1157
2 /usr/src/sys/vm/uma_core.c:1324: could sleep with "eventhandler"
locked from /usr/src/sys/kern/subr_eventhandler.c:162
78 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0" locked from
/usr/src/sys/dev/sound/pcm/sound.c:134
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:fake" locked
from /usr/src/sys/dev/sound/pcm/channel.c:677
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:play:0"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
28 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:play:1"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:play:2"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:play:3"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:record:0"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
4 /usr/src/sys/vm/uma_core.c:1324: could sleep with "pcm0:record:1"
locked from /usr/src/sys/dev/sound/pcm/channel.c:677
2 /usr/src/sys/vm/uma_core.c:1324: could sleep with "process lock"
locked from /usr/src/sys/kern/kern_exec.c:316
5 /usr/src/sys/vm/uma_core.c:1324: could sleep with "process lock"
locked from /usr/src/sys/kern/kern_prot.c:511
7 /usr/src/sys/vm/uma_core.c:1324: could sleep with "process lock"
locked from /usr/src/sys/kern/kern_prot.c:613
1 /usr/src/sys/vm/uma_core.c:1324: could sleep with "rman" locked from
/usr/src/sys/kern/subr_rman.c:194
1 /usr/src/sys/vm/uma_core.c:1324: could sleep with "sf_bufs list lock"
locked from /usr/src/sys/kern/uipc_syscalls.c:1578
(i'll try enabling that sysctl and getting some tracebacks right after i'm
done with this ports compile...)
On Mon, 27 May 2002, Jun Kuriyama wrote:
> At Sun, 26 May 2002 22:19:58 + (UTC),
> Alfred Perlstein wrote:
> > Uh, why don't you guys enable 'debug.witness_ddb' and get us some
> > tracebacks? :)
>
> Could this help you?
>
> ../../../vm/uma_core.c:1324: could sleep with "process lock" locked from
>../../../kern/kern_prot.c:867
> ../../../vm/uma_core.c:1324: could sleep with "pcm0:play:0" locked from
>../../../dev/sound/pcm/sound.c:191
> Debugger("witness_sleep")
> Stopped at Debugger+0x46: xchgl %ebx,in_Debugger.0
> db> trace
> Debugger(c02d6fa0) at Debugger+0x46
> witness_sleep(1,0,c02ea491,52c) at witness_sleep+0xf8
> uma_zalloc_arg(c081d5a0,0,4) at uma_zalloc_arg+0x3e
> malloc(30,c031b020,4,e2fc3180,0) at malloc+0x78
> kobj_create(c031b0c0,c031b020,4,e2fc3180,e2f8cc00) at kobj_create+0x1a
> feeder_create(c031b0c0,0,e2fc3180,e7f96974,c017ebb5) at feeder_create+0x18
> chn_addfeeder(e2fc3180,c031b0c0,0) at chn_addfeeder+0x12
> chn_buildfeeder(e2fc3180) at chn_buildfeeder+0x5b
> chn_tryformat(e2fc3180,8,0,1f40,e2fc3180) at chn_tryformat+0x28
> chn_setformat(e2fc3180,8,e2fc3338,3,c035cad0) at chn_setformat+0x15
> chn_reset(e2fc3180,8) at chn_reset+0xc5
> dsp_open(c035cad0,6,2000,e33a2414,e837f980) at dsp_open+0x21c
> spec_open(e7f96a7c,e7f96b28,c01f5e69,e7f96a7c,6) at spec_open+0x12f
> spec_vnoperate(e7f96a7c) at spec_vnoperate+0x13
> vn_open_cred(e7f96c10,e7f96b64,0,e837f980,e7f96cec) at vn_open_cred+0x353
> vn_open(e7f96c10,e7f96b64,0,c01c7c54,e7f690f0) at vn_open+0x18
> open(e33a2414,e7f96d14,3,1,297) at open+0x155
> syscall(2f,2f,2f,804e6a4,2807343a) at syscall+0x205
> syscall_with_err_pushed() at syscall_with_err_pushed+0x1b
> --- syscall (5, FreeBSD ELF, open), eip = 0x280f4bcb, esp = 0xbfbffa08, ebp =
>0xbfbffa44 ---
>
>
> --
> Jun Kuriyama <[EMAIL PROTECTED]> // IMG SRC, Inc.
>
> 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
gcc internal compiler error with mozilla
Sorry in advance this bug report is probably not going to have enough information... On this box from an Apr 28th kernel that is pre-gcc-3.x: > uname -a FreeBSD coredump.scriptkiddie.org 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Sun Apr 28 14:54:52 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMPNOWIT i386 > gcc --version 2.95.4 I got non-deterministic internal compiler errors when I was trying to compile mozilla. At the same time I was compiling gnome in another terminal window. It only happened with mozilla, it was non-deterministic in that I could do another 'make' and it would proceed past the point it failed. Hardware is solid on this box in both Win2K and -stable. Its a A7M266D machine with dual K7 1800+. Probably not enough information and/or already fixed, but I thought I'd mention it... I didn't see any threads in -current on this behavior since Apr 28th... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: The future of perl on FreeBSD
On Mon, 13 May 2002, Jonathan Perkin wrote: > On Mon May 13, 2002 at 02:02:28PM -0600, Lyndon Nerenberg wrote: > > There is one problem with the /usr/bin/perl redirector: it can > > cause autoconfiguration scripts to mistakenly think perl is > > installed on the system (they find the /usr/bin/perl wrapper) when > > it isn't (there is no perl-from-ports backing the redirector). > > An auto-configuration script which merely checks for the existance > of a file rather than actually testing it's the file it needs is a > bit silly and probably deserves the breakage. There's two sides to this. One side is that you should always adhere to the FreeBSD filesystem standard. The other side is that if /usr/bin/perl exists it should always be a working perl program. I'd like to throw out a mention that I think that all filesystem standards imposed by the people writing the OS or the software packages and not imposed by the system administrators is the wrong way to go. A somewhat rambling stream-of-consciousness argument that I wrote about this is here: http://www.scriptkiddie.org/rants/registry.html I've been thinking that an interesting project would be to implement the "simple" part of this with the hooks into autoconf and /usr/bin/install and convert the FreeBSD base OS to use it. I'll be doing that after someone can roll the clock back to 1999 and have my stock options hit 200 though... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Hiten Pandya wrote: > --- Lamont Granquist <[EMAIL PROTECTED]> wrote: > > > I'm seeing this too, but I expect it's probably caused by out of sync > > > kernel and world. I haven't yet been able to test this hypothesis. > > > > I don't think so, I did: > > > > [...] > > Just cvsup again and rebuild your kernel, and that will fix the problem. Just finished, it did. Vmstat is fixed too. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Uptime of 8909 days on 5-CURRENT
On Sun, 28 Apr 2002, Kris Kennaway wrote: > On Sat, Apr 27, 2002 at 03:45:49PM -0700, Lamont Granquist wrote: > > > > I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime > > is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly > > buggy) 1004 BIOS. > > I'm seeing this too, but I expect it's probably caused by out of sync > kernel and world. I haven't yet been able to test this hypothesis. I don't think so, I did: 1. buildworld 2. buildkernel 3. installkernel 4. single user 5. installworld 6. mergemaster and then for good measure tried building the world again, and i've still got the problem. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Uptime of 8909 days on 5-CURRENT
I just did a cvsup today to -current on a GENERIC+SMP kernel and my uptime is showing 8909 days. Motherboard is an ASUS A7M266D with the (possibly buggy) 1004 BIOS. Here's my dmesg: == boot() called on cpu#1 Waiting (max 60 seconds) for system process `vnlru' to stop...stopped Waiting (max 60 seconds) for system process `bufdaemon' to stop...stopped Waiting (max 60 seconds) for system process `syncer' to stop...stopped syncing disks... 9 8 7 6 5 4 3 2 2 done Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Apr 27 15:17:05 PDT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/COREDUMP Preloaded elf kernel "/boot/kernel/kernel" at 0xc059d000. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc059d0a8. Timecounter "i8254" frequency 1193182 Hz CPU: AMD Athlon(TM) XP 1600+ (1400.06-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc048 real memory = 536788992 (524208K bytes) avail memory = 515842048 (503752K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 -> irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040010, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040010, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Pentium Pro MTRR support enabled Using $PIR table, 9 entries at 0xc00f1370 npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard acpi0: power button is handled as a fixed feature programming model. acpi0: sleep button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0xe408-0xe40b on acpi0 acpi_cpu0: on acpi0 acpi_cpu1: on acpi0 acpi_button0: on acpi0 acpi_pcib0: port 0xcf8-0xcff on acpi0 pci0: on acpi_pcib0 pcib1: at device 1.0 on pci0 pci1: on pcib1 pci1: at device 5.0 (no driver attached) isab0: at device 7.0 on pci0 isa0: on isab0 atapci0: port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: at device 7.3 (no driver attached) ahc0: port 0xd400-0xd4ff mem 0xed80-0xed800fff irq 10 at device 9.0 on pci0 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: port 0xd000-0xd0ff mem 0xed00-0xed000fff irq 5 at device 9.1 on pci0 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs pcib2: at device 16.0 on pci0 pci2: on pcib2 fxp0: port 0xb800-0xb83f mem 0xeb80-0xeb8f,0xec00-0xec000fff irq 10 at device 6.0 on pci2 fxp0: Ethernet address 00:90:27:bc:09:95 inphy0: on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: at device 8.0 (no driver attached) pci2: at device 8.1 (no driver attached) ppc0 port 0x778-0x77f,0x378-0x37f irq 7 drq 3 on acpi0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/9 bytes threshold plip0: on ppbus0 lpt0: on ppbus0 lpt0: Interrupt-driven port ppi0: on ppbus0 sio0 port 0x3f8-0x3ff irq 4 on acpi0 sio0: type 16550A sio1 port 0x2f8-0x2ff irq 3 on acpi0 sio1: type 16550A atkbdc0: port 0x64,0x60 irq 1 on acpi0 atkbd0: flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: at flags 0x100 on isa0 sc0: VGA <16 virtual consoles, flags=0x300> vga0: at port 0x3c0-0x3df iomem 0xa-0xb on isa0 APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 Timecounters tick every 10.000 msec acpi_cpu: CPU throttling enabled, 2 steps from 100% to 50.0% ad0: 12949MB [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM at ata1-master PIO4 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: Fixed Direct Access SCSI-3 device da0: 160.000MB/s transfers (80.000MHz, offset 63, 16bit), Tagged Queueing Enabled da0: 35003MB (71687369 512 byte sectors: 255H 63S/T 4462C) Mounting root from ufs:/dev/ad0s1a SMP: AP CPU #1 Launched! swi_net: unregistered isr number: 18. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kldxref problem
On Sat, 30 Mar 2002, Doug White wrote: > On Sat, 30 Mar 2002, A.Z. wrote: > > I am upgrading 4.5 to -current. > > > > buildworld went fine, > > make buildkernel also fine, > > but make installkernel is giving me an error > > > > kldxref/boot/kernel > > kldxref: No Such Fule or Directory > > > > ***Error code 1(ignored) > Did you miss this part? > > Man, this throws everyone off. > > The error was IGNORED. THERE IS NO PROBLEM. I'm telling you all, its very easy to miss that "(ignored)" Either work around this or suffer through posts about it every single week... To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP ffs_mountfs() broken?
Of course that should be an A7M266D... (its friday, my brain is fried and i think i need to take a sauna...) On Fri, 22 Mar 2002, Lamont Granquist wrote: > GENERIC works, so this looks like an SMP problem. > > Its happening right after the CPU initializes. This is probably the first > SMP code the machine runs? Is hardware incompatibility a good guess? I > would have expected that if someone broke ffs_mountfs() that someone else > would have noticed by now... > > Oh, I forgot to say in my previous message that my motherboard is a > Asus K7M266D. It runs 4.5-STABLE with SMP turned on fine, but only with > MP spec 1.1 and not 1.4. There's a BIOS upgrade which is supposed to fix > Linux + MP spec 1.4 issues which might fix 1.4 for FreeBSD as well. It > could fix this as well maybe? > > On Fri, 22 Mar 2002, Lamont Granquist wrote: > > I'll try to see if this was due to the cvsup or due to SMP. I've got a UP > > kernel from a few weeks ago that works fine. > > > > 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: SMP ffs_mountfs() broken?
GENERIC works, so this looks like an SMP problem. Its happening right after the CPU initializes. This is probably the first SMP code the machine runs? Is hardware incompatibility a good guess? I would have expected that if someone broke ffs_mountfs() that someone else would have noticed by now... Oh, I forgot to say in my previous message that my motherboard is a Asus K7M266D. It runs 4.5-STABLE with SMP turned on fine, but only with MP spec 1.1 and not 1.4. There's a BIOS upgrade which is supposed to fix Linux + MP spec 1.4 issues which might fix 1.4 for FreeBSD as well. It could fix this as well maybe? On Fri, 22 Mar 2002, Lamont Granquist wrote: > I'll try to see if this was due to the cvsup or due to SMP. I've got a UP > kernel from a few weeks ago that works fine. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP ffs_mountfs() broken?
I just cvsupped about an hour ago, built world and built a kernel that was
GENERIC with 486/586 turned off and SMP and IOAPIC turned on. It crashed
while trying to mount root. Apologies for mistakes in the following since
I don't have a serial console and had to write it down:
Mounting root from ufs:/dev/ad0s1a
SMP AP CPU #1 Launched!
kernel trap 12 with interrupts diabled
panic: blockable sleep lock (sleep mutex) Giant @ ../../../i386/i386/trap.c:706
cpuid = 1; lapic.id = 0100
Debugger("panic")
Stopped at Debugger+0x41: xorl %eax, %eax
trace showed the watchdog trap and then:
_mtx_lock_sleep
_mtx_lock_flags
vn_lock
spec_open
ffs_mountfs
ffs_mount
ufs_mountroot_try
ufs_mountroot
start_init
fork_exit
fork_trampoline
(sorry for eliminating all the args and such, but that's a lot of hex
numbers to write down by hand -- if anyone requests i'll see what i can do
about getting it off the serial port..)
I've never had this machine successfully running 5.0 with SMP, this was my
first attempt. My machine is:
2 x 1.4GHz K7 MP1600+
512MB crucial ECC
Adaptec 39160
Seagate 36GB drive (not used for my 5.0 box)
13GB IBM UDMA66 drive (5.0 is installed on this)
Geforce2/MX
Soundblaster
I'll try to see if this was due to the cvsup or due to SMP. I've got a UP
kernel from a few weeks ago that works fine.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: 4.5->5.0 kldxref:No such file or directory
On 15 Mar 2002, Dag-Erling Smorgrav wrote:
> Emiel Kollof <[EMAIL PROTECTED]> writes:
> > Why not test for it like this (or similar):
> >
> > [ -x /usr/sbin/kldxref ] && /usr/bin/kldxref (etcetera...)
>
> A better solution is
>
> @(kldxref ${DESTDIR}${KMODDIR} || \
> echo "Ignoring non-fatal kldxref failure")
I'd strongly suggest *something* like this.
I'm pretty familiar with make but at 3am the other night I missed the
"(ignored)" in the make output and figured that it had failed, and nearly
started a new thread on this myself. I expect you'll see a lot more
people making the same mistake and dragging down the SNR.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: -current lock warning...
I've seen this as well, -current from about 5 days ago, dual proc 1.4GHz K7 A7M266D with a 13GB IBM UDMA66 drive, GENERIC kernel + hints. On Sat, 16 Mar 2002, Hiten Pandya wrote: > --- Poul-Henning Kamp <[EMAIL PROTECTED]> wrote: > > >I haven't seen this. I built a kernel today, and I have a dual processor > > >machine. Are you using any special kernel options, such as VFS_BIO_DEBUG > > >or something, or am I talking nuts? :) > > > > Well, I have. On a single CPU net-booting -current. No. Yes :-) > > Although I am still getting the following lock problems when I shut > the system down: > > lock order reversal > 1st 0xc036afc0 allproc @ ../../../kern/vfs_syscalls.c:452 > 2nd 0xc7ecce34 filedesc structure @ ../../../kern/vfs_syscalls.c:457 > > I think I will have to check out lock problems you are getting today, > once I finish my breakfast. :-) > > __ > Do You Yahoo!? > Yahoo! Sports - live college hoops coverage > http://sports.yahoo.com/ > > 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
Upgrading to 5-CURRENT via sources
So, I've got a CVS checkout of 5-CURRENT on my 4.5-STABLE box and I'd like to upgrade to a spare partition that I have on the machine (making it dual boot). Can I just do: make world DESTDIR=/mnt/tmp And then build + drop the kernel into place + reboot? To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
