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' internal: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' internal: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' internal:75: forward declaration of `struct std::bad_alloc' internal: 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 internal:85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file internal: 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 internal:85: too many arguments to function `void* operator new(unsigned int) ' ../stlport/stl/_construct.h:85: at this point in file internal: 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_traitschar, _Alloc = _STL::allocatorchar]' dll_main.cpp:192: instantiated from here internal: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
panic with hp psc 2210xi usb printer
My USB PCI hub is: ohci0: NEC uPD 9210 USB controller mem 0xec00-0xec000fff irq 5 at device 5.0 on pci2 usb0: OHCI version 1.0 usb0: NEC uPD 9210 USB controller 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: NEC uPD 9210 USB controller mem 0xeb80-0xeb800fff irq 6 at device 5.1 on pci2 usb1: OHCI version 1.0 usb1: NEC uPD 9210 USB controller 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: serial bus, USB 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
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
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: 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 passerror) 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
(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 passstart,
periph_oninval = 0xc0156d70 passoninvalidate,
periph_dtor = 0xc0156e00 passcleanup, 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 passerror) 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, 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: PLEXTOR CD-R PX-W1210S 1.01 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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! real memory = 536788992 (524208K bytes) avail memory = 513298432 (501268K bytes) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D 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: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 pcib0: ACPI Host-PCI bridge 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: ACPI PCI bus on pcib0 agp0: AMD 762 host to AGP bridge port 0xe800-0xe803 mem 0xfb80-0xfb800fff,0xfc00-0xfdff at device 0.0 on pci0 pcib1: ACPI PCI-PCI bridge 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: ACPI PCI bus on pcib1 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 3960D Ultra160 SCSI adapter 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: Adaptec 3960D Ultra160 SCSI adapter 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: ACPI PCI-PCI bridge at device 16.0 on pci0 pcib2: could not get PCI interrupt routing table for \\_SB_.PCI0.OP2P - AE_NOT_FOUND pci2: ACPI PCI bus on pcib2 fxp0: Intel Pro 10/100B/100+ Ethernet 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: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: multimedia, audio at device 8.0 (no driver attached) pci2: input device 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: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio0
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 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
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(8AF3^D(HF3^E(B0F3BFBFF4BFBF^DF4BFBFE1^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(8AF3^D(HF3^E(B8F3BFBFDF4BFBF^LF4BFBFE1^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 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
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
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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE
AMD Features=0xc048MP,AMIE,DSP,3DNow!
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: math processor on motherboard
npx0: INT 16 interface
acpi0: ASUS A7M266-D 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: CPU
-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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! 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: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D 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: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 3960D Ultra160 SCSI adapter 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: Adaptec 3960D Ultra160 SCSI adapter 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: PCI-PCI bridge at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel Pro 10/100B/100+ Ethernet 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: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: multimedia, audio at device 8.0 (no driver attached) pci2: input device 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: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O 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: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse Explorer, device ID 4 orm0: Option ROMs at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA 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 IBM-DJNA-371350 [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM CREATIVEDVD8400E 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: PLEXTOR CD-R PX-W1210S 1.01 Removable CD-ROM SCSI-2 device cd0: 20.000MB/s transfers (20.000MHz, offset 16) cd0: Attempt to query device size failed: NOT READY,
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 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: 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
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: 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
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, 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
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
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=0x383fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR,SSE AMD Features=0xc048MP,AMIE,DSP,3DNow! 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: math processor on motherboard npx0: INT 16 interface acpi0: ASUS A7M266-D 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: CPU on acpi0 acpi_cpu1: CPU on acpi0 acpi_button0: Power Button on acpi0 acpi_pcib0: Host-PCI bridge port 0xcf8-0xcff on acpi0 pci0: PCI bus on acpi_pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 pci1: PCI bus on pcib1 pci1: display, VGA at device 5.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: AMD 768 ATA100 controller port 0xd800-0xd80f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 pci0: bridge, PCI-unknown at device 7.3 (no driver attached) ahc0: Adaptec 3960D Ultra160 SCSI adapter 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: Adaptec 3960D Ultra160 SCSI adapter 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: PCI-PCI bridge at device 16.0 on pci0 pci2: PCI bus on pcib2 fxp0: Intel Pro 10/100B/100+ Ethernet 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: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci2: multimedia, audio at device 8.0 (no driver attached) pci2: input device 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: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O 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: Keyboard controller (i8042) port 0x64,0x60 irq 1 on acpi0 atkbd0: AT Keyboard flags 0x1 irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model IntelliMouse, device ID 3 orm0: Option ROMs at iomem 0xd8000-0xd8fff,0xc-0xcc7ff on isa0 fdc0: cannot reserve I/O port range (6 ports) pmtimer0 on isa0 sc0: System console at flags 0x100 on isa0 sc0: VGA 16 virtual consoles, flags=0x300 vga0: Generic ISA VGA 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 IBM-DJNA-371350 [26310/16/63] at ata0-master UDMA66 acd0: DVD-ROM CREATIVEDVD8400E at ata1-master PIO4 Waiting 15 seconds for SCSI devices to settle da0 at ahc0 bus 0 target 0 lun 0 da0: SEAGATE ST336704LW 0004 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:
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
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: normal da0 SCSI adaptor dmesg output 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: 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
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
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
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
