Re: ACPI on Tyan Motherboard
On Tue, Aug 19, 2003 at 09:54:21AM -0700, David O'Brien wrote: Sorry but telling experiences with non-Tyan boards don't help one bit. (too bad I don't have Bill Paul's finesse in getting this point across) Actually, yes it does... well it's relevant in this case. ATX systems respond to holding the power button down for at least 4 seconds by doing a hard power down. I believe this is part of the applicable specifications. - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Anyone use WINE at all anywhere?
On Fri, Aug 01, 2003 at 05:38:33PM -0700, Julian Elischer wrote: Is the re ANYONE that uses wine on -current...? Sure, I use wine on current. However, the problems I seem to be getting are wine related and not due to problems with fbsd.. as far as I can tell. - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: gcc related -current upgrade problems
On Fri, Jul 25, 2003 at 05:45:10PM -0700, Scott M. Likens wrote: These issues have been addressed in KDE 3.1.3 if you're patient enough for Will to work out the kinks the ports will be updated in a week or less. The issue is not KDE related one, rather the base c++ headers trigger all sorts of warnings. Apparently on other operating systems libstdc++ does not trigger these warnings. - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Fixing gcc 3.3 compile failures
On Thu, Jul 17, 2003 at 07:52:00PM -0700, Kris Kennaway wrote: OK, now that the latest 5.x package build is well underway, we can start work on fixing the compile failures seen with gcc 3.3. What about stuff that breaks because the libstdc++ headers trip up gcc? - alex ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
What's up with www.freebsd.org?
http://www.freebsd.org/send-pr.html returns a 403. Oops. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: WIne freezes -current for half a year
On Sun, Nov 03, 2002 at 02:36:41PM -0800, Terry Lambert wrote: My understanding of his post was that, 6 months later, the machine unfreezes, and everything works normally... 8-) 8-). Actually, I think he's complaining that WINE isn't working in -current. Yup. That's about right. Last time I tried Wine (sometime within the past three or four months) I was trying to install either Free Agent or WinMX. The thing caused my 'puter to just reboot. I haven't felt like trying it since (especially now that current isn't hanging nearly as often otherwise). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 07:53:38PM -0700, Juli Mallett wrote: peter@ has been working busily in a Perforce branch to fix a lot of crap and it's by no means a small amount of work that he's done so far, especially taking into account the amount of testing and debugging he seems to be doing. It's the 'peter_sigfix' branch, I think. Great. Now where's the docu on this whole Perforce repository that everyone's so hot about? And what parts of what do I need? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.0-RUSH: -current install testers wanted!
On Tue, Oct 22, 2002 at 08:33:53AM +0200, Poul-Henning Kamp wrote: And I want them to do it RSN: 5.0-R is only 9 days away. If the release is only 9 days away, what will be done about the signal/FPU register stuff? As it stands, [x]emacs still hangs often enough, and KDE managed to destabilize my system significantly. Is there any quick hack or other such solution floating around that would resolve this? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: emacs problems?
On Fri, Oct 18, 2002 at 08:00:19AM -0700, walt wrote: Anyone else seeing this problem? The only issue I have with emacs (I'm using xemacs 21.1.14) is that it hangs quite often. Usually when I do a lot of mouse scrolling. This seems to be a recent thing. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
On Mon, Oct 14, 2002 at 05:00:45PM -0700, David O'Brien wrote: gcc's code optimizations are broken, and should be avoided. Not any more with GCC 3.2, unless you have a test case to prove it broken. Well you still can't buildworld with -O3 -march=pentiumpro -fno-strength-reduce. Looks like it dies somewhere while trying to make depend for groff. What was broken before the compiler upgrade was perl (this was indicated by automake being borked resulting in an inability to build kde). Thankfully this is now working. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
On Mon, Oct 14, 2002 at 10:37:53PM +0200, Daniel Rock wrote: If I compile it with optimization enabled make test fails at t/op/pat, test 640. Only with no optimization at all this test succeeded. I tried the following options So turn off the optimizations? gcc's code optimizations are broken, and should be avoided. If you want to break perl 5.6 you can do so with -O3 -march=pentiumpro (somehow I suspect -O2 would have the same effect). Besides, that just goes to show, it's not perl that's broken.. rather it's the compiler. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Perl 5.8 broken in current
On Tue, Oct 15, 2002 at 12:03:54AM +0200, Daniel Rock wrote: But why don't show the same optimization levels on another intel platform (Solaris x86, gcc-3.2 release) no problem? Because it's not the same compiler. -current is not using 3.2. $gcc -v Using built-in specs. Configured with: FreeBSD/i386 system compiler Thread model: posix gcc version 3.2.1 [FreeBSD] 20021009 (prerelease) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: Duplicate free of item 0xc2356000 from zone 0xc083a280(UMA Buckets)
(kgdb) bt ... #9 0xc035c1a8 in calltrap () at /var/tmp//ccqYOobH.s:98 #10 0xc02302fb in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:494 #11 0xc033603a in uma_dbg_free (zone=0xc083a280, slab=0xc2356fe0, item=0xc2356000) at ../../../vm/uma_dbg.c:273 #12 0xc03355a8 in uma_zfree_internal (zone=0xc083a280, item=0xc2356000, udata=0x0, skip=0) at ../../../vm/uma_core.c:1806 ---Type return to continue, or q return to quit--- #13 0xc0333d29 in cache_drain (zone=0xc083a780) at ../../../vm/uma_core.c:527 #14 0xc0333e2e in zone_drain (zone=0xc083a780) at ../../../vm/uma_core.c:579 #15 0xc0334a07 in zone_foreach (zfunc=0xc0333dd4 zone_drain) at ../../../vm/uma_core.c:1146 #16 0xc03358fe in uma_reclaim () at ../../../vm/uma_core.c:1955 #17 0xc0331840 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #18 0xc0332655 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #19 0xc0220d48 in fork_exit (callout=0xc0332428 vm_pageout, arg=0x0, frame=0xc8d67d48) at ../../../kern/kern_fork.c:853 Oops. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE 3.0 broken in current??
On Wed, Oct 09, 2002 at 04:13:45PM -0700, Terry Lambert wrote: Probably, this should be handled by sending a patch back to the KDE folks, whose servers were dead and being repaired yesterday. You could also make a port path that patched netdev.c, as an interim fix (include the header before including the sys/socket.h header). Unfortunately, It still has not been 72 hours for the download, so I still do not have the KDE sources available locally. Okay. I fixed that on the 3.0 branch. It's been fixed on the soon to be KDE 3.1 branch for a while now. Given how long it's been since it was touched.. oh well. Sometimes I wonder how this stuff even gets imported in the first place (ksysguard is a big pain in the ass that doesn't do much on fbsd even when it does feel like compiling). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: KDE 3.0 broken in current??
On Wed, Oct 09, 2002 at 10:17:01PM -0700, Terry Lambert wrote: FWIW: Thanks. It sometimes feels like people intentionally go out of their way to put Linux-isms (or whatever-isms) into code to make it not run on BSD platforms. I'm quite suprised how this managed to avoid detection for so long (webcvs.kde.org indicated that the last commit to this branch was 12 months ago). It's that whole feeling of fixing the same problems over and over again. Admittedly I run development versions of both FreeBSD and KDE, and the kde-freebsd team uses stable overwhelmingly so the combination doesn't receive the testing that others do. That said, I'm more than willing to review stuff and commit reasonable changes. Anything regarding port specific tweaks should go to the kde-freebsd team, I don't use the ports or packages of KDE or Qt. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Can't make depend or buildkernel for a custom kernel
Attached is my config file, here's the error I'm getting: make -V CFILES -V SYSTEM_CFILES -V GEN_CFILES -V GEN_M_CFILES | MKDEP_CPP=cc - E CC=cc xargs mkdep -a -f .newdep -O -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -ansi -g -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/d ev -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/ipfilter -D_KERNEL - include opt_global.h -fno-common -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding cc: Internal error: Segmentation fault (program cpp0) Please submit a full bug report. See URL:http://www.gnu.org/software/gcc/bugs.html for instructions. mkdep: compile failed *** Error code 1 If I use GENERIC, I can at least make depend. I'm also having problems with networking, seems like I can communicate with stuff listening on 127.0.0.1 just fine, but otherwise I can't connect to anything (traceroute works somewhat). Booting into an old (Sep 29) kernel works fine... actually I think this was broken within the past 7 days or so, I accidentally deleted my last working kernel. - alex machine i386 cpu I686_CPU ident ZIPPY_SMP maxusers0 makeoptions DEBUG=-g#Build kernel with gdb(1) debug symbols options INET#InterNETworking options INET6 #IPv6 communications protocols options FFS #Berkeley Fast Filesystem options SOFTUPDATES #Enable FFS soft updates support options UFS_DIRHASH options NFSCLIENT #Network Filesystem options NFSSERVER #Network Filesystem options MSDOSFS #MSDOS Filesystem options CD9660 #ISO 9660 Filesystem options PROCFS #Process filesystem options PSEUDOFS options COMPAT_43 #Compatible with BSD 4.3 [KEEP THIS!] options KTRACE #ktrace(1) support options SYSVSHM #SYSV-style shared memory options SYSVMSG #SYSV-style message queues options SYSVSEM #SYSV-style semaphores options P1003_1B#Posix P1003_1B real-time extensions options _KPOSIX_PRIORITY_SCHEDULING options KBD_INSTALL_CDEV# install a CDEV entry in /dev #options_KPOSIX_VERSION=199309L device random #entropy device #optionsSMP # Symmetric MultiProcessor Kernel #optionsAPIC_IO # Symmetric (APIC) I/O device isa device pci device fdc # Floppy drives # ATA and ATAPI devices device ata device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives device atapifd # ATAPI floppy drives device atapicam options ATA_STATIC_ID #Static device numbering #optionsATA_ENABLE_ATAPI_DMA#Enable DMA on ATAPI devices options DDB options WITNESS options WITNESS_SKIPSPIN options INVARIANTS options INVARIANT_SUPPORT # SCSI peripherals device scbus # SCSI bus (required) device pass device cd device atkbdc # atkbdc0 controls both the keyboard and the PS/2 mouse device atkbd device psm device vga device splash # splash screen/screen saver device sc # syscons is the default console driver, resembling an SCO console device npx # Floating point support - do not disable. device pmtimer # Add suspend/resume support for the i8254. #The orm device. This device gobbles up the Option ROMs in the ISA memory #I/O space. # Serial (COM) ports device sio # Parallel port device ppc device ppbus # Parallel port bus (required) device lpt # Printer # PCI Ethernet NICs. device miibus # MII bus support device fxp # Intel EtherExpress PRO/100B (82557, 82558) # Pseudo devices - the number indicates how many units to allocated. device loop# Network loopback device ether # Ethernet support device tun # Packet tunnel. device pty # Pseudo-ttys (telnet etc) device md # Memory disks # The `bpf' device enables the Berkeley Packet Filter. # Be aware of the administrative consequences of enabling this! device bpf # Berkeley packet filter # USB support device uhci# UHCI PCI-USB interface #device ohci# OHCI PCI-USB interface device usb
Re: Can't make depend or buildkernel for a custom kernel
On Mon, Oct 07, 2002 at 09:24:44PM -0600, M. Warner Losh wrote: : cc: Internal error: Segmentation fault (program cpp0) http://people.freebsd.org/~kan/gcc-cpp.diff Cool. make depend works now, let's see if the resulting kernel does. :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
On Mon, Oct 07, 2002 at 10:29:34PM -0600, M. Warner Losh wrote: I hit this same problem. Robert pointed me at this patch and I've booted 10 kernels built since then. Burried in my original post: I'm also having problems with networking, seems like I can communicate with stuff listening on 127.0.0.1 just fine, but otherwise I can't connect to anything (traceroute works somewhat). Booting into an old (Sep 29) kernel works fine... actually I think this was broken within the past 7 days or so, I accidentally deleted my last working kernel. But yeah, I expect it will boot just fine. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Can't make depend or buildkernel for a custom kernel
On Mon, Oct 07, 2002 at 09:57:49PM -0700, Terry Lambert wrote: I've noticed netmask problems in -current. If you set it to an larger boundary, it appears to be OK (e.g. I has to set 0x for 192.168.0.X to work). D'oh. That fixed it alright. Thanks. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Recent lock order reversal:
With a kernel from late 2 Oct 2002: lock order reversal 1st 0xc048db40 spechash (spechash) @ ../../../kern/vfs_subr.c:2743 2nd 0xc1efede0 vnode interlock (vnode interlock) @ ../../../kern/vfs_subr.c:2746 - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CURRENT's termcap broken
On Thu, Aug 29, 2002 at 01:46:05PM -0700, David O'Brien wrote: This is *totally* UNTRUE: /usr/local/bin//mutt: libslang.so = /usr/local/lib/libslang.so (0x280e5000) libm.so.2 = /usr/lib/libm.so.2 (0x28148000) libssl.so.2 = /usr/lib/libssl.so.2 (0x28167000) libcrypto.so.2 = /usr/lib/libcrypto.so.2 (0x28199000) libxpg4.so.3 = /usr/lib/libxpg4.so.3 (0x28263000) libintl.so.2 = /usr/local/lib/libintl.so.2 (0x28265000) libiconv.so.3 = /usr/local/lib/libiconv.so.3 (0x2826c000) libncurses.so.5 = /usr/lib/libncurses.so.5 (0x2834) libc.so.5 = /usr/lib/libc.so.5 (0x28382000) note the use of libslang. TERM=xterm and not having COLORTERM set, mutt will not use colors. TERM=xterm and COLORTERM=yes, mutt will use colors. TERM=xterm-color (COLORTERM set or not), mutt will use colors. Speaking of mutt. The end keys on my keyboard no longer work within mutt and xterm. The work just fine with some other programs and work fine still within a console. Just no longer within an xterm. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: compiling kdelibs3 fails with -current's gcc 3.2
On Tue, Sep 03, 2002 at 12:29:23AM +0200, Michael Reifenberger wrote: I tried CFLAGS with -O[1|2] and with or without -march=-pentium3. Always the same error. Anyone else? I'm seeing the exact same thing. I can't install linux_base either, nor can I build rpm. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: compiling kdelibs3 fails with -current's gcc 3.2
On Mon, Sep 02, 2002 at 08:10:42PM -0400, Alexander Kabaev wrote: Have no idea what is your problem with linux_base, but rpm build fine here after one gets past __size_t and machine/types.h. And how does one do that? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
sleeping with mntvnode locked...
So I'm trying to get the kernel to drop into ddb when it spews witness
stuff.. stuff like:
Aug 18 23:22:28 blarf kernel: ../../../vm/uma_core.c:1332: could sleep with process
lock locked from ../../../kern/kern_exec.c:360
Aug 18 23:22:28 blarf last message repeated 2 times
Aug 18 23:28:12 blarf kernel: ../../../vm/uma_core.c:1332: could sleep with process
lock locked from ../../../kern/kern_exec.c:360
Aug 18 23:28:12 blarf last message repeated 2 times
Aug 18 23:44:09 blarf kernel: ../../../vm/uma_core.c:1332: could sleep with process
lock locked from ../../../kern/kern_exec.c:360
Aug 18 23:44:09 blarf last message repeated 2 times
So I set debug.witness_ddb to 1. I see the above when I exit from X. No
ddb. Hmm. I go into the debugger manually and get a useless trace (duh).
Some more head scratching while world builds, then I get this:
../../../kern/kern_synch.c:454: sleeping with mntvnode locked from
../../../kern/vfs_subr.c:2789
panic: from debugger
cpuid = 0; lapic.id =
---
GNU gdb 5.2.0 (FreeBSD) 20020627
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc424acdc not locked
panic messages:
---
panic: from debugger
cpuid = 0; lapic.id =
syncing disks... panic: bremfree: bp 0xc424acdc not locked
cpuid = 0; lapic.id =
Uptime: 22h19m59s
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc02216b1 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0255f71 in bremfree (bp=0xc424acdc) at ../../../kern/vfs_bio.c:633
#4 0xc02576e6 in vfs_bio_awrite (bp=0xc424acdc)
at ../../../kern/vfs_bio.c:1627
#5 0xc01fafdc in spec_fsync (ap=0xc9c17814)
at ../../../fs/specfs/spec_vnops.c:406
#6 0xc01faba7 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:124
#7 0xc02e12a2 in ffs_sync (mp=0xc1b09a00, waitfor=2, cred=0xc0bace80,
td=0xc03eda40) at vnode_if.h:545
#8 0xc0265860 in sync (td=0xc03eda40, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
#9 0xc022131e in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#11 0xc016d1ed in db_panic () at ../../../ddb/db_command.c:449
#12 0xc016d18c in db_command (last_cmdp=0xc03c4440, cmd_table=0x0,
aux_cmd_tablep=0xc03bb4f0, aux_cmd_tablep_end=0xc03bb4f4)
at ../../../ddb/db_command.c:345
#13 0xc016d25b in db_command_loop () at ../../../ddb/db_command.c:471
#14 0xc016f692 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#15 0xc03257a8 in kdb_trap (type=3, code=0, regs=0xc9c17a28)
at ../../../i386/i386/db_interface.c:161
#16 0xc0339fcc in trap (frame=
{tf_fs = -1071448040, tf_es = -1070006256, tf_ds = 16, tf_edi = 1, tf_esi = 0,
tf_ebp = -910067092, tf_isp = -910067116, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_eax =
26, tf_trapno = 3, tf_err = 0, tf_eip = -1070441902, tf_cs = 8, tf_eflags = 642,
tf_esp = -1, tf_ss = -910067060}) at ../../../i386/i386/trap.c:605
#17 0xc0326bc8 in calltrap () at /var/tmp//ccTCRbXy.s:99
#18 0xc023bb23 in witness_sleep (check_only=0, lock=0xc042bbe0,
file=0xc038d8ee ../../../kern/kern_synch.c, line=454)
at ../../../kern/subr_witness.c:927
#19 0xc022653c in msleep (ident=0xc223a7b8, mtx=0xc042bbe0, priority=72,
wmesg=0x0, timo=0) at ../../../kern/kern_synch.c:454
#20 0xc0217497 in acquire (lkp=0xc223a7b8, extflags=16777280, wanted=1536)
at ../../../kern/kern_lock.c:168
#21 0xc02177d0 in lockmgr (lkp=0xc223a7b8, flags=16842754, interlkp=0x140,
td=0xc2667480) at ../../../kern/kern_lock.c:381
#22 0xc025c758 in vop_stdlock (ap=0x0) at ../../../kern/vfs_default.c:279
#23 0xc02ee573 in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2770
#24 0xc026c36a in vn_lock (vp=0xc223a6f0, flags=65538, td=0xc2667480)
at vnode_if.h:871
#25 0xc0263665 in vrele (vp=0xc223a6f0) at ../../../kern/vfs_subr.c:1963
#26 0xc0264a5a in sysctl_vnode (oidp=0xc03f9aa0, arg1=0x0, arg2=0,
req=0xc9c17c08) at ../../../kern/vfs_subr.c:2835
#27 0xc0228826 in sysctl_root (oidp=0x0, arg1=0xc9c17cb4, arg2=2,
req=0xc9c17c08) at ../../../kern/kern_sysctl.c:1147
#28 0xc02289e4 in userland_sysctl (td=0x0, name=0xc9c17cb4, namelen=2,
old=0xc9c17c60, oldlenp=0xa, inkernel=0, new=0xc9c17c30, newlen=0,
retval=0xc9c17cb0) at ../../../kern/kern_sysctl.c:1242
#29 0xc02288a9 in __sysctl (td=0xc2667480, uap=0xc9c17d14)
at ../../../kern/kern_sysctl.c:1181
#30 0xc033a7a4 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077939888, tf_esi = 2, tf_ebp =
-1079200088, tf_isp = -910066316, tf_ebx = -1079200048, tf_edx = -1077937728, tf_ecx =
-1077939912, tf_eax = 202, tf_trapno = 12, tf_err = 2, tf_eip = 134575943, tf_cs = 31,
tf_eflags = 658, tf_esp = -1079200132, tf_ss = 47})
at
Re: sleeping with mntvnode locked...
On Mon, Aug 19, 2002 at 01:56:38AM -0700, Don Lewis wrote: This is getting triggered by the kern.vnode sysctl. SMP or UP? SMP kernel, 1 processor until I find a lower profile heatsink. Offhand I have a hard time seeing how the sequence vref(vp) do cpu bound stuff vrele(vp) would do anything other than increment and decrement the vnode reference count on a UP box. Even on an SMP box, what are the chances that some other process would vrele() a vnode while the sysctl handler had a reference to it and was copying some data from it? Does sysctl kern.vnode trigger this panic while the machine is idle? I can only assume no, as I've run sysctl -a many times in a row before that crash and since that crash and it's yet to crash again with that crash (it did fall over with a most recently used by temp panic after about five hours tho). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: lock order reversal / could sleep with process lock:
On Sun, Aug 18, 2002 at 05:27:13PM -0700, Alex Zepeda wrote:
Should I set debug.witness_ddb to 1 and get a trace from it? Or has this
one already been seen?
It already fell over in exec, here's what it said:
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc42410a0 not locked
panic messages:
---
panic: Most recently used by temp
cpuid = 0; lapic.id =
syncing disks... panic: bremfree: bp 0xc42410a0 not locked
cpuid = 0; lapic.id =
Uptime: 4h13m25s
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc02216b1 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0255f71 in bremfree (bp=0xc42410a0) at ../../../kern/vfs_bio.c:633
#4 0xc02582ba in getblk (vp=0xc1b4c940, blkno=2883984, size=8192, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2318
#5 0xc025605f in breadn (vp=0xc1b4c940, blkno=2883984, size=8192,
rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0)
at ../../../kern/vfs_bio.c:691
#6 0xc025602c in bread (vp=0xc1b4c940, blkno=2883984, size=8192, cred=0x0,
bpp=0xc9b2b904) at ../../../kern/vfs_bio.c:673
#7 0xc02d16d9 in ffs_update (vp=0xc1bd8128, waitfor=0)
at ../../../ufs/ffs/ffs_inode.c:102
#8 0xc02e1bf9 in ffs_fsync (ap=0xc9b2b97c) at ../../../ufs/ffs/ffs_vnops.c:292
#9 0xc02e1122 in ffs_sync (mp=0xc1b93a00, waitfor=2, cred=0xc0bace80,
td=0xc03eda40) at vnode_if.h:545
#10 0xc0265860 in sync (td=0xc03eda40, uap=0x0)
at ../../../kern/vfs_syscalls.c:129
#11 0xc022131e in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#12 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#13 0xc03021ec in mtrash_ctor (mem=0xc2093400, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#14 0xc030113f in uma_zalloc_arg (zone=0xc0b859c0, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#15 0xc0218824 in malloc (size=6, type=0xc03f02c0, flags=0)
at ../../../kern/kern_malloc.c:171
#16 0xc0204324 in exec_elf32_imgact (imgp=0xc9b2bbc0) at imgact_elf.c:806
#17 0xc020e544 in execve (td=0xc1f1ed80, uap=0xc9b2bd14)
at ../../../kern/kern_exec.c:270
#18 0xc033a7a4 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 0, tf_esi = 136140320, tf_ebp =
-1077948136, tf_isp = -911032972, tf_ebx = 136156240, tf_edx = 136150624, tf_ecx = 5,
tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134908427, tf_cs = 31, tf_eflags =
642, tf_esp = -1077948356, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#19 0xc0326c1d in Xint0x80_syscall () at /var/tmp//ccTCRbXy.s:141
---Can't read userspace from dump, or kernel process---
(kgdb) quit
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: new.
On Mon, Aug 19, 2002 at 08:19:53PM -0500, [EMAIL PROTECTED] wrote: Looking forward to working with you all... What? Darwin wasn't good enough for you? Yuk, yuk, yuk. Good luck getting it running :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
panic: Most recently used by BIO buffer
This seems like a new one (previous kernels kept crashing with most
recently used by none).
FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Fri Aug 16 12:47:10 PDT
2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: from debugger
panic messages:
---
panic: Most recently used by BIO buffer
cpuid = 0; lapic.id =
panic: from debugger
cpuid = 0; lapic.id =
Uptime: 1d1h49m29s
pfs_vncache_unload(): 1 entries remaining
Dumping 127 MB
ata0: resetting devices ..
done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc02216b1 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc02218d3 in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc016d1ed in db_panic () at ../../../ddb/db_command.c:449
#4 0xc016d18c in db_command (last_cmdp=0xc03c4440, cmd_table=0x0,
aux_cmd_tablep=0xc03bb4f0, aux_cmd_tablep_end=0xc03bb4f4)
at ../../../ddb/db_command.c:345
#5 0xc016d25b in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc016f692 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc03257a8 in kdb_trap (type=3, code=0, regs=0xc9cf39c4)
at ../../../i386/i386/db_interface.c:161
#8 0xc0339fcc in trap (frame=
{tf_fs = 24, tf_es = -1026490352, tf_ds = 16, tf_edi = -1026470720, tf_esi =
256, tf_ebp = -909166072, tf_isp = -909166096, tf_ebx = 0, tf_edx = 0, tf_ecx = 0,
tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070441902, tf_cs = 8, tf_eflags =
658, tf_esp = -1069891672, tf_ss = -909166048})
at ../../../i386/i386/trap.c:605
#9 0xc0326bc8 in calltrap () at /var/tmp//ccTCRbXy.s:99
#10 0xc02218ba in panic (fmt=0x0) at ../../../kern/kern_shutdown.c:479
#11 0xc03021ec in mtrash_ctor (mem=0xc240c400, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc030113f in uma_zalloc_arg (zone=0xc0b859c0, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc0218824 in malloc (size=6, type=0xc03f02c0, flags=0)
at ../../../kern/kern_malloc.c:171
#14 0xc0204324 in exec_elf32_imgact (imgp=0xc9cf3bc0) at imgact_elf.c:806
#15 0xc020e544 in execve (td=0xc2d14cc0, uap=0xc9cf3d14)
at ../../../kern/kern_exec.c:270
#16 0xc033a7a4 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135209192, tf_esi = 135209068,
tf_ebp = -1077938328, tf_isp = -909165196, tf_ebx = 135209192, tf_edx = 135209208,
tf_ecx = 135209201, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134703887, tf_cs
= 31, tf_eflags = 642, tf_esp = -1077938372, tf_ss = 47})
at ../../../i386/i386/trap.c:1050
#17 0xc0326c1d in Xint0x80_syscall () at /var/tmp//ccTCRbXy.s:141
---Can't read userspace from dump, or kernel process---
(kgdb) quit
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
lock order reversal / could sleep with process lock:
../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:360 lock order reversal 1st 0xc25bb160 process lock (process lock) @ ../../../kern/kern_exec.c:360 2nd 0xc03eee00 filelist lock (filelist lock) @ ../../../kern/kern_descrip.c:1113 ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:360 ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:360 Should I set debug.witness_ddb to 1 and get a trace from it? Or has this one already been seen? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: CFLAGS=-O and WARN=5
On Thu, Aug 15, 2002 at 08:07:29AM +0900, Jun Kuriyama wrote: What I want to know is, our buildworld does not been supported without -O or not. AFAIK it world should compile with -O (I seem to remember parts breaking with -O0 for instance). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
oops: panic: bremfree: bp 0xc4206410 not locked
I got this while the system was swapping quite a bit (silly Gtk+ newsreader + supernews's huge retention == lots of memory used). FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #5: Wed Aug 14 00:39:15 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2.0 (FreeBSD) 20020627 Copyright 2002 Free Software Foundation, Inc. GDB is free software, covered by the GNU General Public License, and you are welcome to change it and/or distribute copies of it under certain conditions. Type show copying to see the conditions. There is absolutely no warranty for GDB. Type show warranty for details. This GDB was configured as i386-undermydesk-freebsd... panic: bremfree: bp 0xc4206410 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4206410 not locked cpuid = 0; lapic.id = Uptime: 1h20m25s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112[CTRL-C to abort] --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc022188d in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #3 0xc0255cf5 in bremfree (bp=0xc4206410) at ../../../kern/vfs_bio.c:633 #4 0xc025bc84 in cluster_wbuild (vp=0xc21beb90, size=8192, start_lbn=12, len=14) at ../../../kern/vfs_cluster.c:801 #5 0xc0257454 in vfs_bio_awrite (bp=0xc4206410) at ../../../kern/vfs_bio.c:1620 #6 0xc02e1a51 in ffs_fsync (ap=0xc8a6fb48) at ../../../ufs/ffs/ffs_vnops.c:231 #7 0xc02e104e in ffs_sync (mp=0xc1b1d600, waitfor=2, cred=0xc0bace80, td=0xc03ed9c0) at vnode_if.h:545 #8 0xc0265560 in sync (td=0xc03ed9c0, uap=0x0) at ../../../kern/vfs_syscalls.c:129 #9 0xc02214fa in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #10 0xc0221aaf in panic () at ../../../kern/kern_shutdown.c:493 #11 0xc030210c in mtrash_ctor (mem=0xc2599400, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #12 0xc0302178 in mtrash_fini (mem=0xc2599400, size=1024) at ../../../vm/uma_dbg.c:186 #13 0xc03003e5 in zone_drain (zone=0xc0b859c0) at ../../../vm/uma_core.c:646 #14 0xc0300d1b in zone_foreach (zfunc=0xc0300148 zone_drain) at ../../../vm/uma_core.c:1167 #15 0xc0301c5a in uma_reclaim () at ../../../vm/uma_core.c:1980 #16 0xc02fdb84 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:653 #17 0xc02fe9b1 in vm_pageout () at ../../../vm/vm_pageout.c:1439 #18 0xc0212330 in fork_exit (callout=0xc02fe784 vm_pageout, arg=0x0, frame=0xc8a6fd48) at ../../../kern/kern_fork.c:872 (kgdb) quit To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: oops: panic: bremfree: bp 0xc4206410 not locked
On Wed, Aug 14, 2002 at 05:35:32PM -0400, Jim Bloom wrote: I believe the more interesting panic to debug is the first one here in mtrash_ctor and not the problem with syncing the disk after a panic. I have seen a few other panics in this routine posted to current over the last few weeks. Yes, this is the one that interests me as well. In fact I've got another dump with a strikingly similar backtrace (differnet panic messages tho). Is there anything useful I can do with the dumps, or are the backtraces helpful enough? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
I think X is making this whole thing unstable..
I can buildworld no problem, play mp3s, read mail. But as soon as I play
around in X... boom the system falls over.
GNU gdb 5.2.0 (FreeBSD) 20020627
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is absolutely no warranty for GDB. Type show warranty for details.
This GDB was configured as i386-undermydesk-freebsd...
panic: bremfree: bp 0xc41dc89c not locked
panic messages:
---
panic: Most recently used by acl
cpuid = 0; lapic.id =
syncing disks... panic: bremfree: bp 0xc41dc89c not locked
cpuid = 0; lapic.id =
Uptime: 27m49s
Dumping 127 MB
ata0: resetting devices ..
done
16[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] 32[CTRL-C to abort] [CTRL-C to abort]
[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] 48[CTRL-C to abort] 64 80[CTRL-C to abort] [CTRL-C to
abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort]
96[CTRL-C to abort] 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc022436d in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc022458f in panic () at ../../../kern/kern_shutdown.c:493
#3 0xc0258071 in bremfree (bp=0xc41dc89c) at ../../../kern/vfs_bio.c:633
#4 0xc02597e2 in vfs_bio_awrite (bp=0xc41dc89c)
at ../../../kern/vfs_bio.c:1627
#5 0xc01fe184 in spec_fsync (ap=0xc9a29948)
at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01fdd73 in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:121
#7 0xc03049a1 in ffs_sync (mp=0xc1b15800, waitfor=2, cred=0xc0bace80,
td=0xc0414f60) at vnode_if.h:463
#8 0xc0266e04 in sync (td=0xc0414f60, uap=0x0)
at ../../../kern/vfs_syscalls.c:127
#9 0xc0223fda in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc022458f in panic () at ../../../kern/kern_shutdown.c:493
#11 0xc0325342 in mtrash_ctor (mem=0xc201f800, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc032429f in uma_zalloc_arg (zone=0xc0b85820, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc021b51c in malloc (size=5, type=0xc0415d80, flags=0)
at ../../../kern/kern_malloc.c:171
#14 0xc030e643 in ufs_access (ap=0xc9a29b00)
at ../../../ufs/ufs/ufs_vnops.c:368
#15 0xc0311aef in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2739
#16 0xc025c5a4 in vfs_cache_lookup (ap=0x0) at vnode_if.h:220
#17 0xc0311aef in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2739
#18 0xc0260058 in lookup (ndp=0xc9a29c30) at vnode_if.h:48
#19 0xc025faf8 in namei (ndp=0xc9a29c30) at ../../../kern/vfs_lookup.c:179
#20 0xc02691ea in lstat (td=0xc1bed840, uap=0xc9a29d14)
at ../../../kern/vfs_syscalls.c:1536
#21 0xc035d094 in syscall (frame=
{tf_fs = -1078001617, tf_es = -1078001617, tf_ds = -1078001617, tf_edi =
-1077941280, tf_esi = -1077941280, tf_ebp = -1077941384, tf_isp = -912089740, tf_ebx =
687791936, tf_edx = 134678288, tf_ecx = 6, tf_eax = 190, tf_trapno = 22, tf_err = 2,
tf_eip = 690031355, tf_cs = 31, tf_eflags = 642, tf_esp = -1077941460, tf_ss = 47}) at
../../../i386/i386/trap.c:1050
#22 0xc034972d in syscall_with_err_pushed () at /var/tmp//ccSIUcXd.s:129
---Can't read userspace from dump, or kernel process---
(kgdb)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Here's my most recent crash..
My system is down to one cpu (the first slot is appears to have eaten itself and using it results in interesting smells from the power supply), but I'm still running a SMP kernel. Anything else I should probe with gdb? FreeBSD blarf.homeip.net 5.0-CURRENT FreeBSD 5.0-CURRENT #3: Wed Jul 24 13:13:30 PDT 2002 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/ZIPPY_SMP_WITNESS i386 GNU gdb 5.2 (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-portbld-freebsd5.0... IdlePTD at phsyical address 0x0056e000 initial pcb at physical address 0x004564c0 panicstr: bremfree: bp 0xc4209bd4 not locked panic messages: --- panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4209bd4 not locked cpuid = 0; lapic.id = Uptime: 3h13m48s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 --- #0 doadump () at ../../../kern/kern_shutdown.c:213 213 dumping++; (kgdb) bt #0 doadump () at ../../../kern/kern_shutdown.c:213 #1 0xc02220bd in boot (howto=260) at ../../../kern/kern_shutdown.c:345 #2 0xc0ce in poweroff_wait (junk=0xc03b0785, howto=-1004495916) at ../../../kern/kern_shutdown.c:493 #3 0xc02551d7 in bremfree (bp=0xc03b0785) at ../../../kern/vfs_bio.c:633 #4 0xc025746e in getblk (vp=0xc1b1b000, blkno=196720, size=8192, slpflag=0, slptimeo=0) at ../../../kern/vfs_bio.c:2318 #5 0xc02552b7 in breadn (vp=0xc1b1b000, blkno=196720, size=8192, rablkno=0x0, rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:691 #6 0xc0255286 in bread (vp=0xc1b1b000, blkno=196720, size=8192, cred=0x0, bpp=0xc8a5cad0) at ../../../kern/vfs_bio.c:673 #7 0xc02f0894 in ffs_update (vp=0xc1df2a50, waitfor=0) at ../../../ufs/ffs/ffs_inode.c:102 #8 0xc0301f1a in ffs_fsync (ap=0xc8a5cb48) at ../../../ufs/ffs/ffs_vnops.c:272 #9 0xc02ffee8 in ffs_sync (mp=0xc1b15800, waitfor=2, cred=0xc0bace80, td=0xc040f260) at vnode_if.h:463 #10 0xc0263bbe in sync (td=0xc040f260, uap=0x0) at ../../../kern/vfs_syscalls.c:127 #11 0xc0221d2c in boot (howto=256) at ../../../kern/kern_shutdown.c:254 #12 0xc0ce in poweroff_wait (junk=0xc03cd8e8, howto=-1069754141) at ../../../kern/kern_shutdown.c:493 #13 0xc032022a in mtrash_ctor (mem=0x100, size=0, arg=0x0) at ../../../vm/uma_dbg.c:135 #14 0xc0320294 in mtrash_fini (mem=0xc215d000, size=8192) at ../../../vm/uma_dbg.c:186 #15 0xc031e576 in zone_drain (zone=0xc0bbfcc0) at ../../../vm/uma_core.c:646 #16 0xc031ee8c in zone_foreach (zfunc=0xc031e2e0 zone_drain) at ../../../vm/uma_core.c:1167 #17 0xc031fd90 in uma_reclaim () at ../../../vm/uma_core.c:1980 #18 0xc031be72 in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:654 #19 0xc031cbea in vm_pageout () at ../../../vm/vm_pageout.c:1434 #20 0xc021303e in fork_exit (callout=0xc031c9c0 vm_pageout, arg=0x0, frame=0xc8a5cd48) at ../../../kern/kern_fork.c:861 (kgdb) quit The most applicable dmesg output I could find was: Memory modified after free 0xc215d000(8188) panic: Most recently used by none cpuid = 0; lapic.id = syncing disks... panic: bremfree: bp 0xc4209bd4 not locked cpuid = 0; lapic.id = Uptime: 3h13m48s Dumping 127 MB ata0: resetting devices .. done 16 32 48 64 80 96 112 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:36:46PM -0700, Don Lewis wrote: It'll drop into ddb every time you get a witness error and you'll have to tell ddb to continue. This could be a might annoying if you are getting errors ever ten seconds ... I'm seeing this: ../../../vm/uma_core.c:1332: could sleep with kernel linker locked from ../../../kern/kern_linker.c:1797 very early on (before rc.sysctl is read -- okay I'm still using the old rc scripts). Is there any way to set debug.witness_ddb=1 from the loader? This is entirely repeatable (just boot up the machine), also seems to happen a few times at random while the system is running. I figure if I could get it to panic in the repeatable case... - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Here's a new(er) one
* $FreeBSD: src/sys/kern/vfs_bio.c,v 1.319 2002/07/10 17:02:28 dillon Exp $
* $FreeBSD: src/sys/kern/vfs_syscalls.c,v 1.267 2002/07/02 17:09:22 mux Exp $
GNU gdb 5.2 (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-portbld-freebsd5.0...
IdlePTD at phsyical address 0x00566000
initial pcb at physical address 0x0044ee80
panicstr: bremfree: bp 0xc422f8e8 not locked
panic messages:
---
panic: Most recently used by temp
cpuid = 0; lapic.id =
boot() called on cpu#0
syncing disks... panic: bremfree: bp 0xc422f8e8 not locked
cpuid = 0; lapic.id =
boot() called on cpu#0
Uptime: 2h21m27s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) t bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021e885 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021ea8a in poweroff_wait (junk=0xc03a9665, howto=-1004341016)
at ../../../kern/kern_shutdown.c:491
#3 0xc025107b in bremfree (bp=0xc03a9665) at ../../../kern/vfs_bio.c:633
#4 0xc025274e in vfs_bio_awrite (bp=0xc422f8e8)
at ../../../kern/vfs_bio.c:1626
#5 0xc01f9226 in spec_fsync (ap=0xc9b07678)
at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01f8e1b in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02fa484 in ffs_sync (mp=0xc1b15800, waitfor=2, cred=0xc0bace80,
td=0xc04079e0) at vnode_if.h:463
#8 0xc025f636 in sync (td=0xc04079e0, uap=0x0)
at ../../../kern/vfs_syscalls.c:127
#9 0xc021e4f4 in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc021ea8a in poweroff_wait (junk=0xc03c6448, howto=-1069940211)
at ../../../kern/kern_shutdown.c:491
#11 0xc031993a in mtrash_ctor (mem=0x100, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc03188d8 in uma_zalloc_arg (zone=0xc0b85200, udata=0x0, flags=0)
at ../../../vm/uma_core.c:1358
#13 0xc0215c58 in malloc (size=6, type=0xc0411c80, flags=0)
at ../../../kern/kern_malloc.c:171
#14 0xc0253764 in allocbuf (bp=0xc4202f98, size=1024)
at ../../../kern/vfs_bio.c:2584
#15 0xc025353f in getblk (vp=0xc1f3c420, blkno=0, size=1024, slpflag=0,
slptimeo=0) at ../../../kern/vfs_bio.c:2476
#16 0xc025115b in breadn (vp=0xc1f3c420, blkno=0, size=1024, rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at ../../../kern/vfs_bio.c:691
#17 0xc025112a in bread (vp=0xc1f3c420, blkno=0, size=1024, cred=0x0,
bpp=0xc9b078d8) at ../../../kern/vfs_bio.c:673
#18 0xc02f7f86 in ffs_blkatoff (vp=0xc1f3c420, offset=0, res=0x0,
bpp=0xc9b0794c) at ../../../ufs/ffs/ffs_subr.c:91
#19 0xc0300569 in ufs_lookup (ap=0xc9b07a74)
at ../../../ufs/ufs/ufs_lookup.c:266
#20 0xc030695d in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2724
#21 0xc0255545 in vfs_cache_lookup (ap=0x0) at vnode_if.h:73
#22 0xc030695d in ufs_vnoperate (ap=0x0) at ../../../ufs/ufs/ufs_vnops.c:2724
#23 0xc0258d68 in lookup (ndp=0xc9b07c40) at vnode_if.h:48
#24 0xc025881e in namei (ndp=0xc9b07c40) at ../../../kern/vfs_lookup.c:175
#25 0xc0262de8 in rename (td=0xc1d6b180, uap=0xc9b07d14)
at ../../../kern/vfs_syscalls.c:2497
#26 0xc0350ddc in syscall (frame=
{tf_fs = 134676527, tf_es = 134610991, tf_ds = -1078001617, tf_edi = 134647304,
tf_esi = 134652936, tf_ebp = -1077938248, tf_isp = -911180428, tf_ebx = 134653064,
tf_edx = 134652957, tf_ecx = 9, tf_eax = 128, tf_trapno = 47, tf_err = 2, tf_eip =
671960931, tf_cs = 31, tf_eflags = 646, tf_esp = -1077938404, tf_ss = 47}) at
../../../i386/i386/trap.c:1045
#27 0xc033d95d in syscall_with_err_pushed () at /var/tmp//ccPk7eLY.s:129
#28 0x0804f51e in ?? ()
#29 0x0804a129 in ?? ()
#30 0x08049cc1 in ?? ()
#31 0x0804d7aa in ?? ()
#32 0x08049eb9 in ?? ()
#33 0x08049a75 in ?? ()
(kgdb)
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Crash dumps on current
On Tue, Jul 09, 2002 at 10:37:20AM -0700, Matthew Dillon wrote:
Welcome to -current. I haven't been able to get crash dumps to
work for a while :-(
I usually set up a serial console between two machines and run
gdb live to debug the kernel.
Crash dumps have been working oh so well for me recently. Seems like the
occasional panic resulting in a reboot will not leave a proper dump, but
here's one I got today:
blarf:/home/crash#gdb52 -k kernel.3 vmcore.3
GNU gdb 5.2 (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-portbld-freebsd5.0...
IdlePTD at phsyical address 0x0054f000
initial pcb at physical address 0x0043f8a0
panicstr: from debugger
panic messages:
---
panic: Most recently used by none
panic: from debugger
Uptime: 58m32s
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021ba80 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021bc24 in poweroff_wait (junk=0xc0376288, howto=-928630028)
at ../../../kern/kern_shutdown.c:489
#3 0xc016babd in db_panic () at ../../../ddb/db_command.c:449
#4 0xc016ba5f in db_command (last_cmdp=0xc03d3680, cmd_table=0xc0376288,
aux_cmd_tablep=0xc03ca120, aux_cmd_tablep_end=0x104)
at ../../../ddb/db_command.c:345
#5 0xc016bb28 in db_command_loop () at ../../../ddb/db_command.c:471
#6 0xc016de51 in db_trap (type=3, code=0) at ../../../ddb/db_trap.c:72
#7 0xc0339291 in kdb_trap (type=3, code=0, regs=0xc8a63b94)
at ../../../i386/i386/db_interface.c:161
#8 0xc03465c9 in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = -1061660800, tf_esi = 256, t
f_ebp = -928629800, tf_isp = -928629824, tf_ebx = 0, tf_edx = 0, tf_ecx = 0, tf_
eax = 18, tf_trapno = 3, tf_err = 0, tf_eip = -1070361369, tf_cs = 8, tf_eflags
= 662, tf_esp = -1069828632, tf_ss = -928629780})
at ../../../i386/i386/trap.c:604
#9 0xc03394e7 in Debugger (msg=0xc039733c panic) at cpufunc.h:68
#10 0xc021bc0f in panic (fmt=0xc03bb5e8 Most recently used by %s\n)
at ../../../kern/kern_shutdown.c:476
#11 0xc0316702 in mtrash_ctor (mem=0xc1ebf000, size=0, arg=0x0)
at ../../../vm/uma_dbg.c:135
#12 0xc031676c in mtrash_fini (mem=0xc1ebf000, size=8192)
at ../../../vm/uma_dbg.c:186
#13 0xc0314a58 in zone_drain (zone=0xc0b85780) at ../../../vm/uma_core.c:646
#14 0xc031536e in zone_foreach (zfunc=0xc03147c2 zone_drain)
at ../../../vm/uma_core.c:1167
#15 0xc031626a in uma_reclaim () at ../../../vm/uma_core.c:1980
#16 0xc031242a in vm_pageout_scan (pass=0) at ../../../vm/vm_pageout.c:652
#17 0xc031310a in vm_pageout () at ../../../vm/vm_pageout.c:1429
#18 0xc020ca80 in fork_exit (callout=0xc0312ee0 vm_pageout, arg=0x0,
frame=0xc8a63d48) at ../../../kern/kern_fork.c:863
(kgdb)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
What to do with witness verbiage (is this new?)?
After the rude awakening that I was after all running current, I've finally turned on the WITNESS related options for my kernel (and boy is it wickedly unstable as of now). Anyways.. is there any sort of list of known warnings? I'm seeing a few consistantly relating to pcm0:play:0, pcm0, inp, tcp, and kernel linker. The pcm related ones are well known, right? The most recent one I'm seeing (that I'd never seen before) is this: ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 This is on a 2xP2-450 with a (for right now) UP kernel. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Here's another panic:
GNU gdb 5.2 (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-portbld-freebsd5.0...
IdlePTD at phsyical address 0x0054f000
initial pcb at physical address 0x0043f8a0
panicstr: bremfree: bp 0xc41c707c not locked
panic messages:
---
Fatal trap 12: page fault while in kernel mode
fault virtual address = 0xc26923f4
fault code = supervisor write, page not present
instruction pointer = 0x8:0xc02371a4
stack pointer = 0x10:0xc9b26aa8
frame pointer = 0x10:0xc9b26ab0
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 = 5431 (smtpd)
trap number = 12
panic: page fault
syncing disks... panic: bremfree: bp 0xc41c707c not locked
Uptime: 1h29m28s
pfs_vncache_unload(): 2 entries remaining
Dumping 127 MB
ata0: resetting devices .. done
16 32 48 64 80 96 112
---
#0 doadump () at ../../../kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at ../../../kern/kern_shutdown.c:213
#1 0xc021ba80 in boot (howto=260) at ../../../kern/kern_shutdown.c:345
#2 0xc021bc24 in poweroff_wait (junk=0xc039e8e5, howto=-1004769156)
at ../../../kern/kern_shutdown.c:489
#3 0xc024e12d in bremfree (bp=0xc039e8e5) at ../../../kern/vfs_bio.c:620
#4 0xc024f8a4 in vfs_bio_awrite (bp=0xc41c707c)
at ../../../kern/vfs_bio.c:1594
#5 0xc01f653a in spec_fsync (ap=0xc9b26924)
at ../../../fs/specfs/spec_vnops.c:403
#6 0xc01f612f in spec_vnoperate (ap=0x0)
at ../../../fs/specfs/spec_vnops.c:121
#7 0xc02f72a4 in ffs_sync (mp=0xc19ab200, waitfor=2, cred=0xc0babe80,
td=0xc03fc760) at vnode_if.h:458
#8 0xc025c4fa in sync (td=0xc03fc760, uap=0x0)
at ../../../kern/vfs_syscalls.c:127
#9 0xc021b6ef in boot (howto=256) at ../../../kern/kern_shutdown.c:254
#10 0xc021bc24 in poweroff_wait (junk=0xc03c40be, howto=-1069794545)
at ../../../kern/kern_shutdown.c:489
#11 0xc0346a9c in trap_fatal (frame=0x100, eva=3261670388)
at ../../../i386/i386/trap.c:841
#12 0xc03467eb in trap_pfault (frame=0xc9b26a68, usermode=0, eva=3261670388)
at ../../../i386/i386/trap.c:755
#13 0xc03463f6 in trap (frame=
{tf_fs = 24, tf_es = -911081456, tf_ds = -1071579120, tf_edi = -104120,
tf_esi = -1033296960, tf_ebp = -911054160, tf_isp = -911054188, tf_ebx = -1044534044,
tf_edx = -1041338176, tf_ecx = 1, tf_eax = -1033296912, tf_trapno = 12, tf_err = 2,
tf_eip = -1071418972, tf_cs = 8, tf_eflags = 66118, tf_esp = -1044534068, tf_ss =
-1044534144}) at ../../../i386/i386/trap.c:445
#14 0xc02371a4 in selwakeup (sip=0xc1bdace4)
at ../../../kern/sys_generic.c:1186
#15 0xc0248cbe in sowakeup (so=0xc1bdac80, sb=0xc1bdaccc)
at ../../../kern/uipc_socket2.c:300
#16 0xc0248946 in soisconnected (so=0xc2679898)
at ../../../kern/uipc_socket2.c:132
#17 0xc024ce6a in unp_connect2 (so=0xc1d0e258, so2=0xc2679898)
at ../../../kern/uipc_usrreq.c:765
#18 0xc024cdec in unp_connect (so=0xc1d0e258, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_usrreq.c:737
#19 0xc024c15d in uipc_connect (so=0x0, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_usrreq.c:161
#20 0xc0246c0d in soconnect (so=0xc1d0e258, nam=0xc1bc7680, td=0xc1ee70c0)
at ../../../kern/uipc_socket.c:429
#21 0xc0249fe9 in connect (td=0xc1ee70c0, uap=0xc9b26d14)
at ../../../kern/uipc_syscalls.c:440
#22 0xc0346d33 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 13, tf_esi = 0, tf_ebp =
-1077938264, tf_isp = -911053452, tf_ebx = 134731496, tf_edx = -1077938398, tf_ecx =
0, tf_eax = 98, tf_trapno = 22, tf_err = 2, tf_eip = 671994211, tf_cs = 31, tf_eflags
= 642, tf_esp = -1077938420, tf_ss = 47})
at ../../../i386/i386/trap.c:1045
#23 0xc033a62d in syscall_with_err_pushed () at /var/tmp//ccgOkQ7m.s:128
#24 0x080554d8 in ?? ()
#25 0x080555c1 in ?? ()
#26 0x080552d0 in ?? ()
#27 0x080553a4 in ?? ()
#28 0x080534cf in ?? ()
#29 0x0805363a in ?? ()
#30 0x080501d6 in ?? ()
#31 0x0804bcef in ?? ()
#32 0x08057aa5 in ?? ()
#33 0x0804c978 in ?? ()
#34 0x0804c909 in ?? ()
#35 0x0804e2ba in ?? ()
#36 0x0804e786 in ?? ()
#37 0x0804ab5d in ?? ()
#38 0x0804b5d2 in ?? ()
#39 0x0804b736 in ?? ()
#40 0x0804f6f5 in ?? ()
#41 0x0804f8fa in ?? ()
#42 0x0805ac31 in ?? ()
#43 0x0804ff74 in ?? ()
#44 0x0804b817 in ?? ()
#45 0x08049fc9 in ?? ()
(kgdb)
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 02:43:54AM -0700, Don Lewis wrote: I haven't had any instability problems in a while on my UP box. Seems like the UP kernels are more unstable for me. Go figure. ../../../vm/uma_core.c:1332: could sleep with process lock locked from ../../../kern/kern_exec.c:332 I haven't seen that one. If you can reproduce it, you might try setting the debug.witness_ddb sysctl to 1 and get a stack trace from ddb. This happened just before the box fell over (I'm now running a different kernel.. SMP.. so far so good). What's the downside to sticking debug.witness_ddb=1 in /etc/sysctl.conf? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: What to do with witness verbiage (is this new?)?
On Wed, Jul 10, 2002 at 01:34:50PM -0700, Don Lewis wrote: ../../../vm/uma_core.c:1332: could sleep with inp locked from ../../../netinet/tcp_subr.c:935 ../../../vm/uma_core.c:1332: could sleep with tcp locked from ../../../netinet/tcp_subr.c:928 I've never seen that one. I'll take a look at the code, though. I'm seeing the same (once at bootup tho). sm:blarf:~$uptime 8:48PM up 18:52, 4 users, load averages: 0.11, 0.06, 0.01 sm:blarf:~$ Sweet. Oddly the SMP kernels seem a tad more stable. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: ACPI woes again..
On Fri, Jul 05, 2002 at 06:46:05PM +0900, Takanori Watanabe wrote: Would you review this description? How about: --- acpi.4.orig Thu Jun 13 02:50:06 2002 +++ acpi.4 Fri Jul 5 21:16:59 2002 @@ -258,10 +258,35 @@ bus/children scan of the namespace. The ACPI CA code will still know about the avoided region. +.Sh OVERRIDING YOUR BIOS BYTECODE +ACPI interprets bytecode named AML, ACPI Machine Language, provided by BIOS +vendor as memory image at boot time. Sometimes, the AML code contains +incorrect bytecode that does not wreak havoc with the Microsoft implementations +of ACPI. Such bugs can often times prevent FreeBSD from booting. In case of +such issues, we provide a way to override buggy AML with your own AML +code. +.Pp +In order to load your AML code, +you must edit +.Pa /boot/loader.conf +and +include the follwing lines. +.Bd -literal -offset indent +acpi_dsdt_load=YES +acpi_dsdt_name=/boot/acpi_dsdt.aml #You may change the name. +.Ed +.Pp +In order to prepare your AML code, you will require +.Xr acpidump 8 , +.Xr iasl 1 +in devel/acpicatools port, and some ACPI knowledge. + .Sh COMPATIBILITY ACPI is only found/supported on Intel platforms (i386/IA32 and IA64). .Sh SEE ALSO .Xr config 8 , +.Xr loader.conf 5 , +.Xr acpidump 8 , .Xr acpi 9 .Sh AUTHORS .An -nosplit - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken world in rtld-elf...
On Fri, Jun 14, 2002 at 07:09:06PM +1000, Bruce Evans wrote: Not really. It is a transient bug that is almost as easy to fix as warn about. So when can I expect the fix to be committed? :-D - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: Broken world in rtld-elf...
On Thu, Jun 13, 2002 at 12:26:05PM +1000, Bruce Evans wrote: rtld still uses asms with the old, broken/fragile 0 constraint. This constraint is especially broken/fragile if things are pessimized by compiling without optimizations. D'oh! Is there any chance of sticking a warning in the makefile if -O0 (or whatever else would cause it to not compile) is present? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Broken world in rtld-elf...
So what's up with -current? I had to install gawk to get the kernel to build (and world too for that matter).. I haven't had the balls to put the one true awk back in place. But now whether in world mode or not I get: blarf:/usr/src/libexec/rtld-elf#make cc -O0 -Wall -DFREEBSD_ELF -I/usr/src/libexec/rtld-elf/i386 -I/usr/src/libexec/rtld-elf -elf -fpic -DPIC -Wformat=2 -Wno-format-extra-args -c /usr/src/libexec/rtld-elf/rtld.c /usr/src/libexec/rtld-elf/rtld.c: In function `atomic_decr_int': /usr/src/libexec/rtld-elf/i386/rtld_machdep.h:58: inconsistent operand constraints in an `asm' *** Error code 1 Stop in /usr/src/libexec/rtld-elf. blarf:/usr/src/libexec/rtld-elf# eek? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Cannot boot with ACPI enabled..
Attached are the dmesg from a kernel that worked (I was away from my
'puter for a few months so I wasn't able to try -current between mid Feb
and now) and my kernel config. However, now it'll hang after detecting:
acpi_tz0: thermal zone on acpi0
unless I disable the acpi thermal stuff with the debug.acpi.disable/avoid
kernel variables.
- alex
/*
RSD PTR: Checksum=156, OEMID=Award, RsdtAddress=0x07ff3000
*/
/*
RSDT: Length=44, Revision=1, Checksum=172,
OEMID=Award, OEM Table ID=AWRDACPI, OEM Revision=0x42302e31,
Creator ID=AWRD, Creator Revision=0x0
*/
/*
Entries={ 0x07ff3040, 0x07ff55c0 }
*/
/*
DSDT=0x7ff30c0
INT_MODEL=PIC
SCI_INT=9
SMI_CMD=0xb2, ACPI_ENABLE=0xa1, ACPI_DISABLE=0xa0, S4BIOS_REQ=0x0
PM1a_EVT_BLK=0x4000-0x4003
PM1a_CNT_BLK=0x4040-0x4041
PM2_TMR_BLK=0x4008-0x400b
PM2_GPE0_BLK=0x400c-0x400f
P_LVL2_LAT=90ms, P_LVL3_LAT=900ms
FLUSH_SIZE=0, FLUSH_STRIDE=0
DUTY_OFFSET=1, DUTY_WIDTH=1
DAY_ALRM=13, MON_ALRM=0, CENTURY=0
Flags={WBINVD,PROC_C1,SLP_BUTTON,RTC_S4}
*/
/*
DSDT: Length=9466, Revision=1, Checksum=18,
OEMID=AWARD, OEM Table ID=AWRDACPI, OEM Revision=0x1000,
Creator ID=MSFT, Creator Revision=0x10c
*/
DefinitionBlock (
acpi_dsdt.aml,//Output filename
DSDT, //Signature
0x1,//DSDT Revision
AWARD,//OEMID
AWRDACPI, //TABLE ID
0x1000 //OEM Revision
)
{
Scope(\_PR_) {
Processor(\_PR_.CPU_, 0, 0x0, 0x0) {
}
Processor(\_PR_.CPU1, 1, 0x0, 0x0) {
}
}
OperationRegion(CM70, SystemIO, 0x70, 0x2)
Field(CM70, ByteAcc, NoLock, Preserve) {
CI70, 8,
CO71, 8
}
IndexField(CI70, CO71, ByteAcc, NoLock, Preserve) {
Offset(0x5d),
SUSF, 8
}
Name(STAT, 0x0)
Name(\_S0_, Package(0x4) {
0x5,
0x5,
0x5,
0x5,
})
Name(\_S1_, Package(0x4) {
0x4,
0x4,
0x4,
0x4,
})
Name(\_S5_, Package(0x4) {
Zero,
Zero,
Zero,
Zero,
})
OperationRegion(\DEBG, SystemIO, 0x80, 0x1)
Field(\DEBG, ByteAcc, NoLock, Preserve) {
DBG1, 8
}
OperationRegion(EXTM, SystemMemory, 0x000ff830, 0x10)
Field(EXTM, WordAcc, NoLock, Preserve) {
ROM1, 16,
RMS1, 16,
ROM2, 16,
RMS2, 16,
ROM3, 16,
RMS3, 16,
AMEM, 32
}
OperationRegion(\SMIC, SystemIO, 0xb2, 0x1)
Field(\SMIC, ByteAcc, NoLock, Preserve) {
SCP_, 8
}
OperationRegion(\TRAP, SystemIO, 0x402f, 0x1)
Field(\TRAP, ByteAcc, NoLock, Preserve) {
, 1,
TR13, 1
}
OperationRegion(\GBLE, SystemIO, 0x4021, 0x1)
Field(\GBLE, ByteAcc, NoLock, Preserve) {
ESMI, 8
}
Name(CMDB, Buffer(0x8) { })
CreateByteField(CMDB, 0x0, BYT0)
CreateByteField(CMDB, 0x1, BYT1)
CreateByteField(CMDB, 0x2, BYT2)
CreateByteField(CMDB, 0x3, BYT3)
CreateByteField(CMDB, 0x4, BYT4)
CreateByteField(CMDB, 0x5, BYT5)
CreateByteField(CMDB, 0x6, BYT6)
CreateByteField(CMDB, 0x7, BYT7)
Name(IDEB, Buffer(0x38) { })
CreateField(IDEB, 0x0, 0x38, CMD0)
CreateField(IDEB, 0x38, 0x38, CMD1)
CreateField(IDEB, 0x70, 0x38, CMD2)
CreateField(IDEB, 0xa8, 0x38, CMD3)
CreateField(IDEB, 0xe0, 0x38, CMD4)
CreateField(IDEB, 0x0118, 0x38, CMD5)
CreateField(IDEB, 0x0150, 0x38, CMD6)
CreateField(IDEB, 0x0188, 0x38, CMD7)
OperationRegion(APMP, SystemIO, 0xb2, 0x2)
Field(APMP, ByteAcc, NoLock, Preserve) {
APMC, 8,
APMD, 8
}
OperationRegion(ELCR, SystemIO, 0x04d0, 0x2)
Field(ELCR, ByteAcc, NoLock, Preserve) {
ELC1, 8,
ELC2, 8
}
OperationRegion(GPOB, SystemIO, 0x4034, 0x4)
Field(GPOB, ByteAcc, NoLock, Preserve) {
GP00, 1,
GP01, 1,
GP02, 1,
GP03, 1,
GP04, 1,
GP05, 1,
GP06, 1,
GP07, 1,
GP08, 1,
GP09, 1,
GP0A, 1,
GP0B, 1,
GP0C, 1,
GP0D, 1,
GP0E, 1,
GP0F, 1,
GP10, 1,
GP11, 1,
GP12, 1,
GP13, 1,
GP14, 1,
GP15, 1,
GP16, 1,
GP17, 1,
GP18, 1,
GP19, 1,
GP1A, 1,
GP1B, 1,
GP1C, 1,
GP1D, 1,
GP1E, 1,
GP1F, 1
}
Name(OSFL, 0x1)
Method(STRC, 2) {
If(LNot(LEqual(SizeOf(Arg0), SizeOf(Arg1 {
Return(0x0)
}
Add(SizeOf(Arg0), 0x1, Local0)
Name(BUF0, Buffer(Local0) { })
Name(BUF1, Buffer(Local0) { })
Store(Arg0, BUF0)
Store(Arg1, BUF1)
While(Local0) {
Decrement(Local0)
If(LNot(LEqual(DerefOf(Index(BUF0, Local0, )), DerefOf(Index(BUF1, Local0,
) {
Return(Zero)
}
}
Return(One)
}
OperationRegion(RTCM, SystemIO, 0x70, 0x2)
Field(RTCM, ByteAcc, NoLock, Preserve) {
CMIN, 8,
CMDA, 8
}
IndexField(CMIN, CMDA, ByteAcc, NoLock, Preserve) {
Offset(0xf),
SHUT, 8
}
OperationRegion(\GRAM,
Re: 5.x packages and request for help.
On Thu, Mar 14, 2002 at 04:31:44PM -0800, Kris Kennaway wrote: I'm just uploading a new 5.x package set. This run was better than the previous (5364 packages vs. 5123 for the last run, but far fewer than the 5973 packages which are building in 4.x), but there were still a number of significant failures: qt2 is still failing so kde doesn't build, and some of the gnome components also failed. As far as Qt goes, rip out that objprelink crap. Without it Qt will build and work just fine. At least Qt 3.whatever works for me. I don't know why objprelink isn't working correctly for Qt, but I don't really care. For me disabling WITNESS does more than enough to make KDE useable on my -current box (2xP2-450). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
On Thu, Mar 14, 2002 at 06:40:37PM -0800, Kris Kennaway wrote: The compile problems seem to be related to recent compiler toolchain changes, which you might not see unless you recompiled everything qt23 depends on from scratch (which the package cluster does). Right, when I tried to compile Qt3 recently I had problems with moc dupming core. Getting rid of any objprelink references solved that. I suggest that something similar be done in the port (maybe make objprelink optional and then off by default). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: 5.x packages and request for help.
On Thu, Mar 14, 2002 at 09:01:47PM -0800, Terry Lambert wrote: I think it's idiotic to put spackle over the broken window, paint the wall, and then call it fixed. I know what objprelink is, and as far as I'm concerned it's there to work around the substandard support that C++ gets from the GNU binutils and compiler. I don't feel much sympathy for the breaking a silly hack that amounts to spackle in the first place by whatever happened to the binutils. FWIW I haven't built KDE or Qt from the ports tree in a while. It seems like it's been about six days since I've cvsup'd and built world. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: can't build kernel: config doesn't work
On Sun, Jul 01, 2001 at 08:09:14AM -0700, Mark Peek wrote:
Right, there is a new compile directory. Perhaps this needs to be
added to UPDATING. Anyway, did you run cvs update -dP on your cvs
tree? Or just do mkdir on the new path mentioned above.
It *IS* in UPDATING:
Updating Information for FreeBSD current users
This file is maintained and copyrighted by M. Warner Losh
[EMAIL PROTECTED]. Please send new entries directly to him. See end
of file for further details. For commonly done items, please see the
COMMON ITEMS: section later in the file.
20010628:
The kernel compile module has moved from src/sys/compile/FOO
to src/sys/${MACHINE}/compile/FOO.
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Now that crash dumps are working, here's a trace
The system just hung, and eventually rebooted. I was in X at the time..
anyways's here's the trace:
#0 dumpsys () at ../../kern/kern_shutdown.c:478
#1 0xc01dbdf3 in boot (howto=260) at ../../kern/kern_shutdown.c:321
#2 0xc01dc265 in panic (fmt=0xc03b6d05 softdep_lock: lock held by %d)
at ../../kern/kern_shutdown.c:600
#3 0xc03033bf in acquire_lock (lk=0xc040c358)
at ../../ufs/ffs/ffs_softdep.c:270
#4 0xc0307838 in softdep_update_inodeblock (ip=0xc1662000, bp=0xc38b887c,
waitfor=0) at ../../ufs/ffs/ffs_softdep.c:4004
#5 0xc02ffce5 in ffs_update (vp=0xc97bee60, waitfor=0)
at ../../ufs/ffs/ffs_inode.c:108
#6 0xc030e1f2 in ffs_fsync (ap=0xc8739d24) at ../../ufs/ffs/ffs_vnops.c:292
#7 0xc030b56a in ffs_sync (mp=0xc1122200, waitfor=2, cred=0xc0b32900,
p=0xc046c600) at vnode_if.h:441
#8 0xc022b647 in sync (p=0xc046c600, uap=0x0) at ../../kern/vfs_syscalls.c:620
#9 0xc01db873 in boot (howto=256) at ../../kern/kern_shutdown.c:231
#10 0xc01dc265 in panic (fmt=0xc03c628f page fault)
at ../../kern/kern_shutdown.c:600
#11 0xc035da8e in trap_fatal (frame=0xc8739e3c, eva=3735929064)
at ../../i386/i386/trap.c:976
#12 0xc035d7b9 in trap_pfault (frame=0xc8739e3c, usermode=0, eva=3735929064)
at ../../i386/i386/trap.c:890
#13 0xc035ce84 in trap (frame={tf_fs = -1069416424, tf_es = -1069416432,
tf_ds = 16, tf_edi = 4, tf_esi = -559038242, tf_ebp = -931946884,
tf_isp = -931946904, tf_ebx = -1053534208, tf_edx = -1052795076,
tf_ecx = -559038242, tf_eax = -559038242, tf_trapno = 12, tf_err = 0,
tf_eip = -1070582304, tf_cs = 8, tf_eflags = 66199, tf_esp = -931946856,
tf_ss = -1070571658}) at ../../i386/i386/trap.c:450
#14 0xc03035e0 in worklist_remove (item=0xdeadc0de)
at ../../ufs/ffs/ffs_softdep.c:431
#15 0xc0305f76 in free_diradd (dap=0xdeadc0de)
at ../../ufs/ffs/ffs_softdep.c:2600
#16 0xc03052da in free_newdirblk (newdirblk=0xc137edd0)
at ../../ufs/ffs/ffs_softdep.c:2033
#17 0xc030746a in handle_written_inodeblock (inodedep=0xc13f9f00,
bp=0xc38a9114) at ../../ufs/ffs/ffs_softdep.c:3768
#18 0xc0306db6 in softdep_disk_write_complete (bp=0xc38a9114)
at ../../ufs/ffs/ffs_softdep.c:3425
#19 0xc021dbdd in bufdone (bp=0xc38a9114) at ../../sys/buf.h:445
#20 0xc021dada in bufdonebio (bp=0xc38a9114) at ../../kern/vfs_bio.c:2693
#21 0xc0145e02 in ad_interrupt (request=0xc12d8bc0) at ../../sys/bio.h:103
#22 0xc013cd4a in ata_intr (data=0xc10a4180) at ../../dev/ata/ata-all.c:543
#23 0xc01cd24b in ithread_loop (arg=0xc10a4100) at ../../kern/kern_intr.c:521
#24 0xc01cba34 in fork_exit (callout=0xc01ccf88 ithread_loop,
arg=0xc10a4100, frame=0xc8739fa8) at ../../kern/kern_fork.c:727
This was with a pretty recent kernel (as of a few hours before it
crashed).
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: Now that crash dumps are working, here's a trace
On Sun, Jun 03, 2001 at 01:44:52PM -0700, Alex Zepeda wrote: The system just hung, and eventually rebooted. I was in X at the time.. anyways's here's the trace: And of course the system info (wc is enabled): Copyright (c) 1992-2001 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 #18: Sat Jun 2 18:33:49 PDT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY_SMP Timecounter i8254 frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (451.03-MHz 686-class CPU) Origin = GenuineIntel Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 125358080 (122420K 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: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel kernel at 0xc04ff000. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdcf0 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 17 - irq 9 IOAPIC #0 intpin 18 - irq 10 pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 IOAPIC #0 intpin 16 - irq 11 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 2 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 pci0: display, VGA at 9.0 (no driver attached) fxp0: Intel Pro/100 Ethernet port 0xe400-0xe43f mem 0xdb00-0xdb0f,0xdb10-0xdb100fff irq 10 at device 10.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a inphy0: i82555 10/100 media interface on miibus0 inphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto isa0: unexpected small tag 14 orm0: Option ROM at iomem 0xc-0xc87ff on isa0 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5 drive on fdc0 drive 0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: SB16 DSP 4.16 on sbc0 joy0: Generic PnP Joystick at port 0x200-0x207 on isa0 unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources sio0: 16550A-compatible COM port at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A unknown: PNP0700 can't assign resources ppc0: ECP parallel printer port at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio1: 16550A-compatible COM port at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IPv6 packet filtering initialized, logging disabled IP packet filtering initialized, divert enabled, rule-based forwarding disabled, default to deny, logging disabled IPsec: Initialized Security Association Processing. ad0: 29314MB IBM-DTLA-307030 [59560/16/63] at ata0-master tagged UDMA33 ad2: 12416MB WDC AC313000R [25228/16/63] at ata1-master UDMA33 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted SMP: AP CPU #1 Launched! lock order reversal 1st 0xc046d5c0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:478 2nd 0xc8b80b6c vnode interlock @ ../../kern/vfs_subr.c:1926 /var: mount pending error: blocks 10 files 2 /usr3: mount pending error: blocks 44 files 7 To Unsubscribe: send mail to [EMAIL
Re: panic: workitem_free: still on list
On Sat, May 19, 2001 at 02:53:57PM +0100, Bob Bishop wrote: On reboot, I got the manual fsck jive with the bad superblock: values disagree ,,with,, first alternate, and had to re-enable softupdates on / This hasn't bit me ever. Abridged backtrace: panic() workitem_free() free_newdirblk() handle_written_inodeblock() softdep_disk_write_complete() bufdone() bufdonebio() dadone() camisr() ithread_loop() fork_exit() fork_trampoline() However the above has, and I've got IDE disks: zippy:~#dmesg|egrep (^ad|^acd|^ata) atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 ata1: at 0x170 irq 15 on atapci0 ad0: 29314MB IBM-DTLA-307030 [59560/16/63] at ata0-master UDMA33 ad2: 12416MB WDC AC313000R [25228/16/63] at ata1-master UDMA33 acd0: CD-RW R/RW 4x4x24 at ata1-slave PIO4 Sadly I haven't been able to get a crash dump in a while. Usually it'll hang while trying to reset the disks, but this time it panic'd again. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: /ports/x11-toolkits/qt23 doesn't build
On Mon, Apr 16, 2001 at 06:09:08PM -0400, [EMAIL PROTECTED] wrote: The port qt23 as cvsup'd from current doesn't build, affects many related packets. Any clues ? Depending on what you need Qt for, you can always build Qt oob, and it should work pretty well. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: FW: Filesystem gets a huge performance boost
Yup, Kirk committed it. I really like the changes -- in the old days disk caches were tiny and directories were not well cached on top of that. It made sense to try to keep directories close to their files. So I'm all excited now at the progress that ufs/ffs are making recently. Yay Kirk. But this leaves one nagging question in my mind. What sort of intervention does one need to do to enable this newfangled wunderfs code? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: top output broked?
On Tue, Mar 27, 2001 at 03:18:10AM -0800, Alfred Perlstein wrote: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 824 root -80 1048K 596K biord 0 0:38 0.00% 0.00% find 385 root 40 32740K 31944K select 1 0:32 0.00% 0.00% XFree86 836 root -80 532K 276K biord 1 0:07 0.00% 0.00% nfsd 14848 root 960 26912K 26832K RUN1 0:04 0.00% 0.00% ld 424 bright 40 2120K 1340K select 0 0:04 0.00% 0.00% rxvt Hmm, I just rebuilt world recently (this morning), and I'm seeing this: PID USERNAME PRI NICE SIZERES STATE C TIME WCPUCPU COMMAND 311 root 1260 600K 264K CPU1 0 24:11 52.39% 52.39% nfsd 503 postfix40 1604K 904K select 0 0:02 0.15% 0.15% qmgr 8069 root 960 2088K 1240K CPU0 0 0:00 0.00% 0.00% top Eek. nfsd is sucking up CPU, even while it's idle (its only nfs client is down for a few quick repairs). I think it's been doing this since the TI-RPC stuff was imported. But, back to your problem, no 0.0% CPU time problem here. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: very strange problem with ps
On Fri, Mar 16, 2001 at 06:12:29PM -0800, Brooks Davis wrote: I'm seeing a very strange problem with ps. I was calling "ps -U From what I can tell (I've seen this for a while), calling ps -U username where username has no running processes (or none shown), will return such an error. ps -U where there are processes to be shown will work fine. *shrug* - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: random reboots...
On Wed, Mar 14, 2001 at 03:48:03PM +0600, Boris Popov wrote: You need options LIBMCHAIN as well. We don't have mechanism for specifying dependancies between options as of yet. (sorry, should put a note in the NOTES). OOps, okay. Thanks :) OTOH, it seems that suspending a program (hitting Ctrl-Z) seems to reboot my system with some regularity. I'm truely at a loss on how to explain this. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: midi causes panic on boot? + entropy gatherer works fine
On Mon, Mar 12, 2001 at 04:38:50PM +0100, Szilveszter Adam wrote: I wonder if this is known? If not, I can certainly provide more information. The offending sound hw is a Creative SB 64 AWE ISAPnP card. It works fine otherwise. (as it always has) Yup I'm seeing this too. SMP kernel, AWE64 PnP. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
random reboots...
I haven't been able to track this down since the kernel won't panic.. but with more recent kernels I've noticed: * options NCP prevents the kernel from linking * midi panics the system right after bootup But the biggest problem seems to be the spontaneous rebooting. At first I thought it might have been related to the recently re-installed HPT366, no such luck there. Then I thought something in make world was causing problems, nope. It seems mainly to happen when I suspend a program.. I'll just hit Ctrl-Z and the screen blanks, and I see the video card copyright info, etc, etc. The kernel that seems to work was built on Feb 18th, and the ones that aren't are from as recently as March 13th. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: random reboots...
On Wed, Mar 14, 2001 at 12:49:01AM -0800, Alex Zepeda wrote: The kernel that seems to work was built on Feb 18th, and the ones that aren't are from as recently as March 13th. D'oh. Forgot the kernel config file and dmesg output. The config file hasn't changed, but the dmesg output is (obviously) from the older kernel. - alex Copyright (c) 1992-2001 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 #2: Sun Feb 18 19:07:27 PST 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/ZIPPY_SMP Timecounter "i8254" frequency 1193182 Hz CPU: Pentium II/Pentium II Xeon/Celeron (451.03-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0x652 Stepping = 2 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 134152192 (131008K bytes) avail memory = 125919232 (122968K bytes) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor motherboard cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 Preloaded elf kernel "kernel" at 0xc048b000. WARNING: size of kinfo_proc (648) should be 644!!! seq0-15: Midi sequencers. Pentium Pro MTRR support enabled Using $PIR table, 7 entries at 0xc00fdcf0 apm0: APM BIOS on motherboard apm0: found APM BIOS v1.2, connected at v1.2 npx0: math processor on motherboard npx0: INT 16 interface pcib0: Intel 82443BX (440 BX) host to PCI bridge at pcibus 0 on motherboard IOAPIC #0 intpin 19 - irq 2 IOAPIC #0 intpin 17 - irq 9 IOAPIC #0 intpin 18 - irq 10 pci0: PCI bus on pcib0 pcib1: PCI-PCI bridge at device 1.0 on pci0 IOAPIC #0 intpin 16 - irq 11 pci1: PCI bus on pcib1 pci1: display, VGA at 0.0 (no driver attached) isab0: PCI-ISA bridge at device 7.0 on pci0 isa0: ISA bus on isab0 atapci0: Intel PIIX4 ATA33 controller port 0xf000-0xf00f at device 7.1 on pci0 ata0: at 0x1f0 irq 14 on atapci0 Warning, ithread (19, irq14: ata0) is an entropy source. ata1: at 0x170 irq 15 on atapci0 Warning, ithread (20, irq15: ata1) is an entropy source. uhci0: Intel 82371AB/EB (PIIX4) USB controller port 0xe000-0xe01f irq 2 at device 7.2 on pci0 usb0: Intel 82371AB/EB (PIIX4) USB controller on uhci0 usb0: USB revision 1.0 uhub0: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub0: 2 ports with 2 removable, self powered intpm0: Intel 82371AB Power management controller port 0x5000-0x500f irq 9 at device 7.3 on pci0 intpm0: I/O mapped 5000 intpm0: intr IRQ 9 enabled revision 0 smbus0: System Management Bus on intsmb0 smb0: SMBus general purpose I/O on smbus0 intpm0: PM I/O mapped 4000 pci0: display, VGA at 9.0 (no driver attached) fxp0: Intel InBusiness 10/100 Ethernet port 0xe400-0xe43f mem 0xdb00-0xdb0f,0xdb10-0xdb100fff irq 10 at device 10.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a isa0: unexpected small tag 14 atkbdc0: Keyboard controller (i8042) at port 0x60,0x64 on isa0 atkbd0: AT Keyboard irq 1 on atkbdc0 kbd0 at atkbd0 psm0: PS/2 Mouse irq 12 on atkbdc0 psm0: model MouseMan+, device ID 0 fdc0: NEC 72065B or clone at port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on isa0 fdc0: FIFO enabled, 8 bytes threshold fd0: 1440-KB 3.5" drive on fdc0 drive 0 sc0: System console on isa0 sc0: VGA 16 virtual consoles, flags=0x200 vga0: Generic ISA VGA at port 0x3c0-0x3df iomem 0xa-0xb on isa0 sbc0: Creative SB AWE64 at port 0x220-0x22f,0x330-0x331,0x388-0x38b irq 5 drq 1,5 on isa0 pcm0: SB16 DSP 4.16 on sbc0 midi0: SB Midi Interface on sbc0 midi1: SB OPL FM Synthesizer on sbc0 joy0: Generic PnP Joystick at port 0x200-0x207 on isa0 midi2: CTL0022 WaveTable Synthesizer at port 0x620-0x623,0xa20-0xa23,0xe20-0xe23 on isa0 emu2: DRAM size = 512KB unknown: PNP0303 can't assign resources unknown: PNP0f13 can't assign resources sio0: 16550A-compatible COM port at port 0x3f8-0x3ff irq 4 on isa0 sio0: type 16550A unknown: PNP0700 can't assign resources ppc0: ECP parallel printer port at port 0x378-0x37f,0x778-0x77a irq 7 drq 3 on isa0 ppc0: SMC-like chipset (ECP/EPP/PS2/NIBBLE) in COMPATIBLE mode ppc0: FIFO with 16/16/16 bytes threshold plip0: PLIP network interface on ppbus0 lpt0: Printer on ppbus0 lpt0: Interrupt-driven port ppi0: Parallel I/O on ppbus0 sio1: 16550A-compatible COM port at port 0x2f8-0x2ff irq 3 on isa0 sio1: type 16550A APIC_IO: Testing 8254 interrupt delivery APIC_IO: routing 8254 via IOAPIC #0 intpin 2 IPsec: Initialized Security Association Processing. ncp_load: [210-213] ad0: 29314MB IBM-DTLA-307030 [59560/16/63] at ata0-master UDMA33 Mounting root from ufs:/dev/ad0s3a WARNING: / was not properly dismounted SMP: AP CPU #1 Launched! lock order reversal 1st vnode interlock last acquired @ ../../ufs/ffs/ffs_vfsops.c:396 2nd 0xc03ff0a0 mntvnode @ ../../ufs/ffs/ffs_vfsops.c:
Re: Panic and filesystem corruption
On Wed, Mar 14, 2001 at 04:39:53PM -0800, Matt Dillon wrote: fsck all of your filesystems from single-user to remove the possibility of 'old' corruption (as in 'fsck', not 'fsck -p'). So if an fsck -f doesn't bomb out, the filesystem should be in an okay state? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: More on system hangs ... IRQ related?
On Sun, Mar 04, 2001 at 03:18:39PM -0400, The Hermit Hacker wrote:
My sound card overlaps with fxp0, and fxp1 overlaps with the
HighPoint controller ...
Grasping at straws here ...
Ditch the HPT366, it's crap and will cause system instabilities with
"fast" hard drives. I'm not sure what you have attached to it, but I've
had problems with {either,both} an IBM ATA100 HDD and a Western Digital
ATA66 drive attached. Apparently the ATA100 counterpart from HighPoint
isn't so bad.
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: More on system hangs ... IRQ related?
On Sun, Mar 04, 2001 at 06:47:09PM -0400, The Hermit Hacker wrote: Its alot harder to hang on a buildworld ... and not consistent, nor near as fast. startx will kill it each and every time based on a 'normal boot' ... the reason I was curious about the IRQs is that if I 'disabled' everything on the machine (ifconfig down the two ethernets), it appeared that X would actually keep running, where normally it would hang very quickly ... Have you tried your system without the highpoint? Or with no drives attached to it? There *are* known problems with this controller. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: How is -CURRENT?
On Fri, Feb 23, 2001 at 02:03:24PM +0700, John Indra wrote: Is it safe to make world right now? Do KDE2 apps work flawlessly on newest -CURRENT? If there are people that can say yes to that answer, than I am ready to blow away all my /usr/X11R6 and /usr/local and build everything from scratch, thank you... Define flawlessly? I haven't noticed any problems yet with KDE2, other than the usual mixing of threaded and non threaded (that glorious hack called mpeglib, and mpeglib_artsplug) bits breaking arts.. grr. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: startx/startkde hangs -CURRENT ...
Now, if I start X, the whole machine hangs solid ... Where? By all means, set KDE_DEBUG, and capture the startx output, and do something with the coredumps so that you encode the pid into the file name, since many kde crashes will be in kdeinit (since it's used to launch programs via shlibs).. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: got stuck in the current __sF foo...
On Sat, Feb 17, 2001 at 10:49:06PM -0400, The Hermit Hacker wrote: the thing that is confusing me is that I'm getting through most of the qt-copy compile before I get hit with it ... I'm doing a fresh 'make world' on the machine, just in case ... then I'm going to try David's idea, if that doesn't work ... Ehm. Where is this breaking in Qt? Are you perchance configuring Qt with -kde, which would link in some old libraries (it introduces a real chicken.. egg.. problem)? Maybe something else that Qt is depending on is linking to an odd version of libc. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: got stuck in the current __sF foo...
On Sat, Feb 17, 2001 at 11:00:05PM -0400, The Hermit Hacker wrote: I removed everything from /var/db/pkg (pkg_delete -f ) before I started this, and then did an rm -rf /usr/local ... basically, brought it to bare system, including an rm -rf /usr/X11R6 ... anything left should be system installed/upgraded :( So show us some output. Where's it breaking? Qt has proved easier to get working on NetBSD/mac68k than the rest of KDE, that's for sure. :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: got stuck in the current __sF foo...
On Sat, Feb 17, 2001 at 11:03:09PM -0400, The Hermit Hacker wrote: ls -lt libc.* -r--r--r-- 1 root wheel 599916 Feb 17 17:00 libc.so.5 lrwxr-xr-x 1 root wheel9 Feb 17 17:00 libc.so - libc.so.5 -r--r--r-- 1 root wheel 1240424 Feb 17 17:00 libc.a -r--r--r-- 1 root wheel 599116 Feb 15 21:10 libc.so.5.20010213 ^^ -r--r--r-- 1 root wheel 581944 Nov 9 01:45 libc.so.4 Hmm. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:19:36PM -0700, Warner Losh wrote: Changes of this magnitude require a bump of the major number, even though we've already done that in -current. It breaks nearly everything, including the upgrade path. Alternatively, the locking changes need to be backed out. Yup, I agree here. IMO so many things depend on the stdio bits, that a major number increase would have been desireable. So far, bzip2, pine/pico, GNU make, the GNU i18n stuff, fetchmail all needed to be rebuilt. Bumping the major number would at least allow these a stay of execution. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT is bad for me...
On Mon, Feb 12, 2001 at 02:20:30PM -0800, Mike Smith wrote: You can do better than this. Put the lock in FILE, and define a new structure FILE_old, which has the same size/layout as the old FILE structure. How is this more acceptable than bumping the major number? Are they really so precious that they can only be incremented once for a release cycle? Seems to me that a new major number is far cleaner than a gross hack. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Patch for FILE problems (was Re: -CURRENT is bad for me...)
On Mon, Feb 12, 2001 at 07:28:30PM -0500, Daniel Eischen wrote:
Attached is a patch that attempts to work around recent stdio
breakage in -current. I've verified it compiles, but won't be
able to test it until at least tomorrow. If someone wants to
review it and verify it works, I'll commit it.
How about this? :^)
--- lib/libc/Makefile.orig Mon Feb 12 16:30:48 2001
+++ lib/libc/Makefile Mon Feb 12 16:30:37 2001
@@ -7,7 +7,7 @@
# from CFLAGS below. To remove these strings from just the system call
# stubs, remove just -DSYSLIBC_RCS from CFLAGS.
LIB=c
-SHLIB_MAJOR= 5
+SHLIB_MAJOR= 6
SHLIB_MINOR= 0
CFLAGS+=-DLIBC_RCS -DSYSLIBC_RCS -I${.CURDIR}/include
AINC= -I${.CURDIR}/${MACHINE_ARCH}
- alex
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Fixed: LyX 1.1.5.2 dumping core
On Sun, Jan 28, 2001 at 01:28:03PM -0600, Patrick Hartling wrote: ldd was telling me that it had both libc.so.3 and libc.so.5 which seemed very bad to me. When I recomipled LyX to see if that would fix things, I noticed that ld was giving a warning about libc.so.3 and libc.so.5 potentially conflicting. It hadn't ever been a problem before, but it doesn't seem like the safest arrangment. With the symlink in place, ldd reports that only libc.so.5 is being used, and everything seems to be okay. Something that LyX is linking to is depending on libc v3. You should rebuild all of the dependencies, and then rebuild LyX. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: HEADS UP: Strange booting lockups
On Sun, Jan 21, 2001 at 02:32:38AM -0800, Jason Evans wrote: Several of us have started experiencing problems with kernels that won't boot. The symptom is hard to miss: the machine locks up at the spinner just before printing the copyright message at the beginning of the boot sequence. Hmm. I've recently tried to boot a kernel off of a CDRW, and it got through the loader, printed the copyright and blinked the keyboard leds, and froze. The lsdev command causes the loader to panic when booted from the CD. Could this possibly be related? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -current scheduler strangeness
On Mon, Nov 20, 2000 at 03:43:27PM +0100, Szilveszter Adam wrote: The messages did not start with SMPNG but got a *lot* more frequent in the last couple of weeks, making listening to mp3-s a real annoyance during any more serious system activity. (Earlier, ie in the early fall and in the summer) these messages were almost never seen while in console mode, but only with X and RealPlayer messing things up. I'm getting this too, in fact even pcmplay (about as minimalistic as you can get) skips a lot and often throws hwptr went backwards. Oh yeah, I'm using an AWE64 PnP as well. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: -CURRENT crashes under heavy disk activity
On Mon, Sep 25, 2000 at 09:36:13PM +0200, Soren Schmidt wrote: There is a known problem with fast disks (so far only the IBM DTLA series) and some old controllers fx the HPT366... Hrm... since when? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Tagged queuing for ATA drives, patches up for testing
On Thu, Aug 31, 2000 at 01:58:46PM +0200, Soren Schmidt wrote: Support for master/slave combinations, and ATA/ATAPI ditto is being worked on, but this requires a controller with support for the "auto nop" functionality. Which of the many different controllers supports this is unknown at this time, but HPT controllers has the needed functionality, and should be a safe bet. It seems that the DJNA series of IBM disks has some problems with tagged queueing, but at least the DPTA and DTLA series are known to work. The older DTTA series has not been tested yet. So does anyone know of any other combo that might work well? I've had nothing but trouble with my HighPoint 366 based board (have I mentioned I think Siig makes awful products?) in two different motherbords and with any OS I've tried it with (hell Win98 thought it was a SCSI adapter...). I've got a somewhat older 13gb WD Caviar (claims to support ATA66) and a 30gp Deskstar DTLA. I'm tempted to try out a Promise ATA 100 board... - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: panic: pmap_release
On Thu, Aug 31, 2000 at 06:50:22PM -0400, Evan Tsoukalas wrote: The following morning, I came in to find the panic I described in my previous post. I was hoping that, to some far more knowledgeable than I, that panic and trace would point the finger at a specific piece of hardware. FWIW, I'm thinking that the RAID controller is flaking, and I've just got to find some time to read the AMI docs to find out if I can swap controllers without causing myself too much pain. Thanks for your suggestion. What about heat? Heat can cause similar symptoms. What about bus speed? Some motherboards just can't handle a 100+mhz FSB well no matter what hardware you throw at it. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: SMP and softupdates?
On Mon, Aug 28, 2000 at 03:46:20PM +0200, Brad Knowles wrote: Personally, I'm astonished that an SMP kernel will actually boot and run on a uniprocessor machine. Grr, still getting used to mutt, and I didn't reply to the list. Yes, I'm using an SMP board, and waiting on the arrival of the 2nd processor. It boots up and runs fine. Before pointing any fingers at softupdates, etc... I think that the first thing I'd do on this machine is switch back to using a real uniprocessor kernel, and then see if I could replicate the problems. Yup, I've "fallen back to" a UP kernel, which hasn't crashed at all, and I've done the same thing (rm -rf, cvs update) many more times than were required to crash the SMP kernel. Before I try this again, I'll have a second processor in there.. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
SMP and softupdates?
In upgrading my system I've bought a shiny new SMP mobo to go with my new 30gb Deskstar... The nice thing about this new board is my HighPoint HPT366 based IDE controller works now (Buggy Phoenix BIOSes prevented it from working before). Perhaps in a rush to get started, I've compiled and been using a SMP kernel even before the second processor arrives. This has worked fine, however I've gotten some rather weird hangs and crashes resulting in a nice lost+found directory on the usr fs. In trying to track this down, I've tried a UP kernel which seems to not have crashed where the SMP one did before.. I'm sure it's not a cooling issue as the sole CPU is staying below 35C. However I'm curious: * Are there any known issues with SMP and softupdates as of late? * Is running one processor with an SMP kernel such a horrible idea (other than performance wise)? I'm glad I can run my harddrives (Caviar and Deskstar) at ATA66 speeds.. but having to tread lightly is sucking. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: strange freeze while starting kde2 :(
What version of XFree86 are you using? Make sure it's != 4.0.0. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: phkmalloc pam_ssh xdm
On Sun, 30 Jul 2000, Alexander Leidinger wrote: Hi, pam_ssh isn't able to start ssh-agent if you use ---snip--- xdm session sufficient pam_ssh.so ---snip--- in /etc/pam.conf. With "malloc.conf - aj" it seems to work. I've seen problems like this (try using Konqueror with malloc.conf set to AJ, *sigh*). What that indicates to me is that an application is expecting initialized memory, but it's too lazy to initialize the memory itself. Thus causing unexpected results. !#@$#!@ Anyone wanna debug kdelibs, Qt and Konqueror? *grin* - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: missing idea.h ... ?
On Fri, 21 Jul 2000, The Hermit Hacker wrote: If it helps any, I setup an anoncvs mirror for most of the stuff ... not sure if it helps any, since you are working off of snapshots, but its updated every 4hrs from the central repository, and the CVSROOT for it was announced on kde-devel ... What really needs to be done is fixing up of the kconsole grantpty code, the socket credentials code in kdesu(d) as well as some of the system info gathering for kcontrol as well as ksysguard. But that's just if you're looking for some code to hack on :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: cer/b7b/pfc - pem
On Tue, 18 Jul 2000, Leif Neland wrote: This works nicely in Windows (Outlook Express), but I'd like to try using the same key with openssl to generate crypted (to myself) or signed messages. I can export the key as a .cer, .p7b or .pfx, but openssl seems to want it in .pem format. You need to export your private key (too). Without OE5, this is an option when you attempt to save a cert as a file. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: 4.0-RELEASE boot.flp fails to boot on K6/2
On Tue, 21 Mar 2000, Jordan K. Hubbard wrote: Good idea, terrible name. Can't you guys some up with something better? :) reallybigbootthing.flp? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Linksys Revisted..
On Mon, 13 Mar 2000, Jay Oliver wrote: dc0: LC82C115 PNIC II 10/100BaseTX port 0xde00-0xdeff mem 0xdfffbf00-0xdfffbff dc0: Ethernet address: 00:a0:cc:32:a6:31 Different "revisions" of the Linksys NICs use different chips, so problems that afflict one "revision" quite possibly have nothing to do with the other card working. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Kde2pre: is it FreeBSD or Kde fault?
On Thu, 2 Mar 2000, Theo van Klaveren wrote: stereofftscope.cpp:~80: sorry, not implemented. (something about symbol to big for symbol table). Recompile all your sources with -fhuge-objects. I finished the build with make -k, but I have no arts :( I suspect this to be a FreeBSD problem, as the Linux guys don't seem to have this (or it would have been fixed in the previous two/three weeks). I noticed the same problem with libkhtml, b.t.w. Pfft. Last time I tried to compile arts, I only needed to make a few changes, and it worked fine. I haven't tried in a while. But if you're getting weird errors, then report them, as I haven't seen any such bug reports. If you don't report stuff, how do you expect it to be fixed? FWIW, I haven't seen the problems with eh_rtime_match being undefined either. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: kdelibs port broken?
On Fri, 25 Feb 2000, Will Andrews wrote: If you're gonna use a port, use ports for its dependencies too. You'd be stupid not to use the ports whenever you can. No one has ever provided me a convincing reason why this is not true. Well when you want to keep multiple versions of kde or qt around.. and want to be able to remove them in one fell swoop.. and the "packing lists" aren't for sure known.. yes it helps to have its own directory. For a normal desktop user you're perhaps right. But not using the ports for some things does not make one stupid, as quite possibly there's a good reason behind it. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: gcc, eh_rtime_match
On Tue, 15 Feb 2000, Ilmar S. Habibulin wrote: Who is porting gcc to freebsd? I have some problems with development vertion of kdes' new filemanager/browser. It can't find function eh_rtime_match, which i found in libgcc.a. What for is this function, should libgcc.a be linked with -lgcc flag? When i do so, konqueror dumps core. Where is this undefined symbol comming from? A quick grep in konqueror/ and libkonq/ revealed nothing (assuming here that you're seeing some sort of linker error). I've somewhat given up for the time being (due mainly to lack of time) on getting kde to build due to some rather bizare problems. I'm thinking a buildworld might solve things, but for now, the autoconf/libtool crap is still a rapidly moving target. Ah. - alex The average Slashdotter seems genuinely to think that the entire 'Net could be run on beige x86 boxes running Linux. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Mon, 31 Jan 2000, Gary Palmer wrote: /me looks at the stack of 386sx chips he has and wonders why no-one did 8 way SMP with these! You never heard of the Sequent boxes, did you? :) In fact I haven't. But I also don't have DXs either. :) - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INET6 and fxp
On Sat, 29 Jan 2000, Mattias Pantzare wrote: If I put INET6 in my kernelconfig my network stops working. Even IPv4. I have a Intel EtherExpress Pro 10/100B Ethernet (fxp) card. I found a fix for FreeBSD on an OpenBSD mailinglist :-) http://www.sigmasoft.com/~openbsd/archive/openbsd-tech/199912/msg00321.html Something better than that is probably needed in the long run. FWIW this doesn't happen with my card: fxp0: Intel InBusiness 10/100 Ethernet port 0x1000-0x103f mem 0xf400-0xf40 f,0xf410-0xf4100fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a fxp0: supplying EUI64: 00:90:27:ff:fe:d1:83:6a fxp0: starting DAD for fe80:0001::0290:27ff:fed1:836a fxp0: DAD complete for fe80:0001::0290:27ff:fed1:836a - no duplicates found 'course I don't actually use the card for internet access, just a local lan and the occasional IPv6 testing. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: PAIN
On Sun, 30 Jan 2000, kibbet wrote: /me looks at the bunch of 386 mobo's... lets not go there.. :) /me looks at the stack of 386sx chips he has and wonders why no-one did 8 way SMP with these! - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: INET6 and fxp
On Sun, 30 Jan 2000 [EMAIL PROTECTED] wrote: FWIW this doesn't happen with my card: fxp0: Intel InBusiness 10/100 Ethernet port 0x1000-0x103f mem 0xf400-0xf40 f,0xf410-0xf4100fff irq 10 at device 15.0 on pci0 fxp0: Ethernet address 00:90:27:d1:83:6a fxp0: supplying EUI64: 00:90:27:ff:fe:d1:83:6a fxp0: starting DAD for fe80:0001::0290:27ff:fed1:836a fxp0: DAD complete for fe80:0001::0290:27ff:fed1:836a - no duplicates found 'course I don't actually use the card for internet access, just a local lan and the occasional IPv6 testing. (from what I've heard) the symptom highly depends on chip revision so you are lucky. As it seems it's also probably quite timing dependant too. Right now I'm glad I've only got one PCI card that is giving me a hard time. - alex who hates SIIGnificantly crappy IDE controllers To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Loader.rc: unknown command
On Sun, 30 Jan 2000, Daniel C. Sobral wrote: Then, please send me the same information: how did you upgrade? what did you have before? what's the date of your present world? Make installworld, dunno but it was at least a few weeks old, and the present world was built last night. Anyway... nothing can actually explain the problem reported. :-( In theory, it's impossible for such a problem to happen unless someone introduced a bug in loader/FICL (or managed to disable FICL altogether). I would vote for FICL bug, as I tried updating my "scripts" too, and that didn't solve my problem. Perhaps there's a bug in reading the file off the disk. Needless to say it works, but give that strange error/warning at the beginning. - alex Experience something different With our new imported dolly She's lovely, warm, inflatable And we guarantee her joy - The Police To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Problems installing FreeBSD 4.0 20000125-CURRENT
On Thu, 27 Jan 2000, Bill Fenner wrote: Right. I've seen this when I hit Enter rapidly twice at the first loader prompt. Doesn't ever happen if I wait for the second prompt. That's my impression too -- I've seen it on my laptop when I do that (sometimes), and I may have hit enter twice rapidly on this reboot. Yup I've seen this too on my trusty Micron. I've found that hitting space, to get to the forth prompt, and then typing boot and then thwacking enter is a sure fire way to get it to boot correctly. Hitting enter twice in a row quickly occasionally screw up. Also sometimes I'll be able to catch the screwed up booter when I notice that it doesn't respond to me hitting enter (In 9 seconds... hit enter.. 8 seconds.. hit enter.. 7 seconds... hit reset). - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
On Wed, 26 Jan 2000, Soren Schmidt wrote: zippy:~#dd if=/dev/afd0c bs=1k count=16 of=afd0c.output dd: /dev/afd0c: Input/output error zippy:~#Jan 26 00:38:32 zippy /kernel: afd0: error reading primary partition table reading fsbn 0 Hmm. I know this disk works with Windows 98SE. Well, if it has problems with the partitions you should use /dev/afd0 and /dev/wfd0. Well the first read (even after the little blinky light went out) after inserting a disk with afd0 gives me an i/o error. The second read works. Swapped zip disks. Same with afd0c, except when it "works" zero records are transferred. It doesn't do much predictably, except for not work. I know I got an error reading the primary partition table the first time I tried to read (forget whether it was afd0 or afd0c). /me scratches his head - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Speaking of ATAisms...
I haven't been able to mount an msdos (FAT16) formattted zip disk (well any FAT16 formatted zip disk) for quite a while. Currently I'm trying to mount afd0s4, but no such luck (I think the latest error is something about reading the partition table). The wd driver used to grok the same disks. Any thoughts? P.S. Soren, thanks for the burncd program. So far I've had more luck with it than the Adaptec s/w that came with the drive. - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: Speaking of ATAisms...
On Wed, 26 Jan 2000, Soren Schmidt wrote: I still have that on my list, but I've not gotten down to it yet, sorry... Well as long as I've got the wd driver, I'm fine. Anything in perticular where I might be able to help in fixing this? P.S. Soren, thanks for the burncd program. So far I've had more luck with it than the Adaptec s/w that came with the drive. Glad to hear that _something_ works :) Well I haven't updated my kernel yet. *grin* - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree
On Mon, 24 Jan 2000, Ben Rosengart wrote: And the time and disk space required to make world. No thank you. Remember that the only win here is if bzip is used in an infrastructural capacity (e.g. for packages and other install stuff), and it has been pointed out that the savings on disk space are offset by the additional memory requirements. If it won't be used for infrastructure, then why can't it stay in ports? Again, lemmie get on my soap box, and ask have you looked at the man page, and compared the memory required when using -s to the memory required by gzip? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: bzip2 in src tree (Was Re: ports/16252: bsd.port.mk: Add bzip2support for distribution patches)
On Sun, 23 Jan 2000, Chuck Robey wrote: Ask me again in 18 months, maybe bzip2 will use less memory and be faster, and it's quite likely that it will be far more popular at ftp sites. Have you looked at the memory usage when you use the -s flag? - alex To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
