Re: close my resolved and obsolete PR
On 3/4/14 5:18 PM, Anton Shterenlikht wrote: > Please close this PR: > > http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/158542 > > I can no longer reproduce the problem. > Done, thanks for the follow-up! Chris signature.asc Description: OpenPGP digital signature
RFC: deprecation of nve(4) in 10-STABLE and removal from 11-CURRENT
Hi, for some time now we have had two drivers for NVIDIA NForce/MCP network chips, namely nve(4) and nfe(4). The former came first and is based on a binary blob. The latter was later ported from OpenBSD and is blob-free. nfe(4) supports all chips nve(4) supports, in addition to all the newer hardware. In essence, nfe(4) has been the de-facto standard driver for a long time. nve(4) has been commented out in GENERIC since 2007. For this reason I propose deprecating nve(4) in 10-STABLE and removing it from HEAD. Does anyone see a reason not to do this? Cheers, Christian (wearing my best asbestos suit) signature.asc Description: OpenPGP digital signature
Re: stat(1) - option doubled in manpage
On 4/22/12 20:00 , Rainer Hurling wrote: Just a small note. In stat(1) the description of option -l doubles: -l Display output in ls -lT format. Perhaps someone with a commit bit is interested in correcting this? ___ Fixed, thanks! Christian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: GrandCentralDispatch in FreeBSD?
On Thu, May 13, 2010 at 03:21:55PM +0100, Tom Evans wrote: > Hi Robert > > I saw today that you've written a proof of concept MPM for apache in > GCD [1] - are there any plans to port GCD to FreeBSD? > It's already there, see http://wiki.freebsd.org/GCD - Christian -- Christian Brueffer ch...@unixpages.org bruef...@freebsd.org GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgpSna1iEve0o.pgp Description: PGP signature
panic: softdep_deallocate_dependencies: dangling deps
Hi, got the following panic on an smp system tonight. Dump available for further debugging. FreeBSD haakonia.hitnet.rwth-aachen.de 5.1-CURRENT FreeBSD 5.1-CURRENT #22: Thu Nov 20 20:05:47 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORIEN i386 GNU gdb 5.3 (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.1"... panic: softdep_deallocate_dependencies: dangling deps panic messages: --- panic: softdep_deallocate_dependencies: dangling deps cpuid = 1; boot() called on cpu#1 syncing disks, buffers remaining... 3841 3841 3840 3839 3839 3838 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 3837 giving up on 3183 buffers Uptime: 6d8h13m1s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 464 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0534260 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc053465d in panic (fmt=0xc070c19a "softdep_deallocate_dependencies: dangling deps") at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc064ae85 in softdep_deallocate_dependencies (bp=0x0) at /usr/src/sys/ufs/ffs/ffs_softdep.c:5919 #4 0xc057e3fb in brelse (bp=0xcec64fd8) at /usr/src/sys/sys/buf.h:427 #5 0xc058e8fa in flushbuflist (blist=0xcec64fd8, flags=0, vp=0xc6388e38, slpflag=0, slptimeo=0, errorp=0x0) at /usr/src/sys/kern/vfs_subr.c:1269 #6 0xc058e508 in vinvalbuf (vp=0xc6388e38, flags=0, cred=0x0, td=0x0, slpflag=0, slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:1155 #7 0xc05913fd in vclean (vp=0xc6388e38, flags=8, td=0xc472aa00) at /usr/src/sys/kern/vfs_subr.c:2560 #8 0xc0591a41 in vgonel (vp=0xc6388e38, td=0x0) at /usr/src/sys/kern/vfs_subr.c:2756 #9 0xc058d558 in vlrureclaim (mp=0xc4c46800) at /usr/src/sys/kern/vfs_subr.c:725 #10 0xc058d78f in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:776 #11 0xc051da44 in fork_exit (callout=0xc058d5e0 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:793 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Random signals in {build,install}world recently?
On Mon, Oct 20, 2003 at 10:50:02AM -0400, Barney Wolff wrote: > On Mon, Oct 20, 2003 at 03:20:56PM +0200, Mark Santcroos wrote: > > On Mon, Oct 20, 2003 at 10:27:38AM +0200, Harti Brandt wrote: > > > On Mon, 20 Oct 2003, Vallo Kallaste wrote: > > > > > > VK>Hi > > > VK> > > > VK>It seems to be a recent problem. The hardware is OK, both Windows XP > > > VK>(which I use very seldom) and Gentoo Linux do not exhibit any > > > VK>problems. > > > VK>Basically one will get random signals as I have got in build- and > > > VK>installworld. It's impossible to complete make -j2 buildworld on my > > > VK>machine, but sometimes non-parallel buildworld will do, only to die > > > VK>later in installworld. > > > VK>This is on two-processor AMD 2400+ MP system, ASUS A7M-266D mobo and > > > VK>1GB ECC memory, ATA disks and CD/RW-DVD only. 4BSD scheduler if it > > > VK>matters. > > > > > > I have the same MB just with 1800+ processors. I had to reduce the CPU > > > frequency by about 10% in the BIOS setup to get the machine stable. I > > > assume the problem is actually the memory. > > > > Couldn't the following be of help here? > > > > options DISABLE_PSE > > options DISABLE_PG_G > > I don't think so. I tried that on my A7M266D with no effect. I believe > something in recent pmap code doesn't like this mobo, or maybe dual > athlons in general. I can run RELENG_5_1 rock solid, and -current from > 9/24/03 rock solid, but -current from 10/3 or later gets random sigs > and eventually panics. I have scsi disks so it's not ata. > I have the same experiences. Also AMD A7M-266D with two 1800+ Athlons here. Used to work fine, but got random signals with my latest builds. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: panic: The GEOM class BDE already loaded
On Fri, Oct 10, 2003 at 09:59:58AM +0200, mike wrote: > On Fri, 10 Oct 2003, Christian Brueffer wrote: > > > Date: Fri, 10 Oct 2003 02:08:26 +0200 > > From: Christian Brueffer <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > > Subject: panic: The GEOM class BDE already loaded > > > > Hi, > > > > just got the following panic on my server. The panic occured while trying > > to attach a gbde encrypted disk. geom_bde is compiled into the kernel. > > > > The problem seems to be that the kld name is 'geom_bde' but the module > name is 'g_bde' and gbde's main() we search for the kld which in your case > doesn't exist. > > Could you please try the attached patch for src/sbin/gbde? > Hi, The problem is already fixed in -current. Thanks anyway. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
panic: The GEOM class BDE already loaded
Hi, just got the following panic on my server. The panic occured while trying to attach a gbde encrypted disk. geom_bde is compiled into the kernel. Dump and debugging kernel are available for further debugging. Sources are from October 9th, around 2 PM CET. GNU gdb 5.3 (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.1"... panic: The GEOM class BDE already loaded panic messages: --- panic: The GEOM class BDE already loaded cpuid = 1; lapic.id = 0100 boot() called on cpu#1 syncing disks, buffers remaining... 1077 1077 1076 1076 1074 1074 1074 1073 1076 1073 1073 1073 1073 1073 107 3 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 1073 giving up on 911 buffers Uptime: 1m17s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368 384 400 416 432 448 46 4 480 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) where #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0512b90 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372 #2 0xc0512f96 in panic (fmt=0xc06ac0cf "The GEOM class %s already loaded") at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc04ca466 in g_load_class (arg=0xc49014d0, flag=0) at /usr/src/sys/geom/geom_subr.c:91 #4 0xc04c7f48 in one_event () at /usr/src/sys/geom/geom_event.c:180 #5 0xc04c8035 in g_run_events () at /usr/src/sys/geom/geom_event.c:200 #6 0xc04c9085 in g_event_procbody () at /usr/src/sys/geom/geom_kern.c:134 #7 0xc04e9d8f in fork_exit (callout=0xc04c9040 , arg=0x0, frame=0x0) at /usr/src/sys/kern/kern_fork.c:796 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
panic: pmap_enter: pte vanished, va: 0xbfbff000
Hi,
just got this panic on my smp box. Sources are from October 2nd, around
9pm CEST. A dump is available for further debugging.
GNU gdb 5.3 (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.1"...
panic: pmap_enter: pte vanished, va: 0xbfbff000
panic messages:
---
panic: pmap_enter: pte vanished, va: 0xbfbff000
cpuid = 1; lapic.id = 0100
boot() called on cpu#1
syncing disks, buffers remaining... 3842 3842 3842 3839 3839 3839 3839 3839 3842 3838
3838 3838 3838 3838 38
38 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838 3838
giving up on 3553 buffers
Uptime: 1d7h23m22s
Dumping 511 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 336 352 368
384 400 416 432 448 4
64 480 496
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
240 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240
#1 0xc0514fb0 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:372
#2 0xc05153b6 in panic (fmt=0xc06cb072 "pmap_enter: pte vanished, va: 0x%x")
at /usr/src/sys/kern/kern_shutdown.c:550
#3 0xc06723dd in pmap_enter (pmap=0xc515fc80, va=3217027072, m=0xc17ce6e0, prot=5
'\005', wired=0)
at /usr/src/sys/i386/i386/pmap.c:1962
#4 0xc062149c in vm_fault (map=0xc515fbd0, vaddr=3217027072, fault_type=1 '\001',
fault_flags=0)
at /usr/src/sys/vm/vm_fault.c:890
#5 0xc0675e39 in trap_pfault (frame=0xdbc8dd48, usermode=1, eva=3217029420)
at /usr/src/sys/i386/i386/trap.c:709
#6 0xc06759d4 in trap (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 76, tf_esi = 134629896, tf_ebp =
-1077937832, tf_isp = -
607593100, tf_ebx = 51, tf_edx = 1, tf_ecx = 19, tf_eax = 0, tf_trapno = 12, tf_err =
4, tf_eip = 673303409,
tf_cs = 31, tf_eflags = 66118, tf_esp = -1077937876, tf_ss = 47}) at
/usr/src/sys/i386/i386/trap.c:317
- Christian
--
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
pgp0.pgp
Description: PGP signature
Re: HFS+ driver kernel options?
On Thu, Sep 18, 2003 at 11:22:37PM -0500, David Leimbach wrote: > Hey... just looking to see what option I need to enable to get HFS+ > support... > All you need should be here: http://people.freebsd.org/~yar/hfs/ - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
panic: recursed on non-recursive lock (sleep mutex) vm page queue mutex @ kern/vfs_bio.c:1550
Hi, I just got this panic on an SMP machine running a kernel with sources from August 27th. I didn't get a dump and I just have the part of the stacktrace, which fit on the screen, maybe it is useful. backtrace(c03af9a8,c50ec5c8,c03c173d,c03c173d,c03b2673) at backtrace+0x17 witness_lock(c50ec5c8,8,c03b2673,60d,c043aac0) at witness_lock+0x672 _mtx_lock_flags(c50ec5c8,0,c03b266a,60d,ce5aa8c0) at _mtx_lock_flags+0xba vfs_vmio_release(ce5aa8c0,0,c03b266a,745,c41c9000) at vfs_vmio_release+0x5f getnewbuf(0,0,4000,4000,200) at getnewbuf+0x244 getblk(c41c9000,32120,0,4000,0) at getblk+0x37f breadn(c41c9000,32120,0,4000,0) at bread+0x52 bread(c41c9000,32120,0,4000,0) at bread+0x4c ffs_update(c52e15b4,0,1,54,c0238a8e) at ffs_update+0x206 ufs_inactive(d716fc30,d716fc4c,c026daf3,d716fc30,0) at ufs_inactive+0x1f5 ufs_vnoperate(d716fc30,0,c03b3e7d,8e3,c03fb420) at ufs_vnoperate+0x18 vput(c52e15b4,0,c03c243b,3b2,c52e15b4) at vput+0x143 vm_pageout_scan(0,0,c03c243b,5d9,1f4) at vm_pageout_scan+0x5b1 vm_pageout(0,d716fd48,c03aa010,314,dc328c3b) at vm_pageout+0x2db fork_exit(c032fd00,0,d716fd48) at fork_exit+0xcf fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd716fd7c, ebp = 0 --- recursed on non-recursive lock (sleep mutex) vm page queue mutex @ kern/vfs_bio.c:1550 first acquired @ vm/vm_pageout.c:405 panic: recurse cpuid = 0; lapic.id = boot() called on cpu#0 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
panic: softdep_lock: locking against myself
0, cred=3D0xc44c9e80, fdidx=3D0)
at vnode_if.h:118
#32 0xc0278040 in vn_open (ndp=3D0x0, flagp=3D0x0, cmode=3D0, fdidx=3D0) at=
/usr/src/sys/kern/vfs_vnops.c:93
#33 0xc0271060 in kern_open (td=3D0xc531a980, path=3D0x0, pathseg=3DUIO_USE=
RSPACE, flags=3D1539, mode=3D438)
at /usr/src/sys/kern/vfs_syscalls.c:688
#34 0xc0270f10 in open (td=3D0x0, uap=3D0x0) at /usr/src/sys/kern/vfs_sysca=
lls.c:654
#35 0xc0373763 in syscall (frame=3D
{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D -1077938472, tf_e=
si =3D 16, tf_ebp =3D -1077938744, tf_isp =3D
-612160140, tf_ebx =3D 135094816, tf_edx =3D 176, tf_ecx =3D 17, tf_eax=
=3D 5, tf_trapno =3D 12, tf_err =3D 2, tf_eip =3D
134911639, tf_cs =3D 31, tf_eflags =3D 514, tf_esp =3D -1077938788, tf_=
ss =3D 47})
at /usr/src/sys/i386/i386/trap.c:1005
=20
- Christian
=20
--=20
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
--9dgjiU4MmWPVapMU
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/U+v9bHYXjKDtmC0RAk3eAJ4mBt/NRl3AVqMmHmp5HdKdrCwR7gCglOpa
6xmQWbU3jd3ZkLLWd0/+QAw=
=n92I
-END PGP SIGNATURE-
--9dgjiU4MmWPVapMU--
panic: softdep_deallocate_dependencies: dangling deps
--D9sZ58tf58331Q5M Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, got a panic on my server tonight. Coredump available for further debuggung. FreeBSD haakonia.hitnet.rwth-aachen.de 5.1-CURRENT FreeBSD 5.1-CURRENT #6: = Thu Aug 28 00:16:19 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORIEN i386 GNU gdb 5.3 (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 condition= s. 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.1"... panic: softdep_deallocate_dependencies: dangling deps panic messages: --- panic: softdep_deallocate_dependencies: dangling deps cpuid =3D 1; lapic.id =3D 0100 boot() called on cpu#1 syncing disks, buffers remaining... panic: bremfree: removing a buffer not = on a queue cpuid =3D 1; lapic.id =3D 0100 boot() called on cpu#1 Uptime: 2d5h32m34s Dumping 511 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 256 272 288 304 320 = 336 352 368 384 400 416 432 448 464 4 80 496 --- #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 240 dumping++; (kgdb) bt #0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240 #1 0xc0212e20 in boot (howto=3D260) at /usr/src/sys/kern/kern_shutdown.c:3= 72 #2 0xc0213226 in panic (fmt=3D0xc03b2848 "bremfree: removing a buffer not = on a queue") at /usr/src/sys/kern/kern_shutdown.c:550 #3 0xc025a051 in bremfreel (bp=3D0xce6b6228) at /usr/src/sys/kern/vfs_bio.= c:644 #4 0xc0259f25 in bremfree (bp=3D0x0) at /usr/src/sys/kern/vfs_bio.c:626 #5 0xc025c658 in vfs_bio_awrite (bp=3D0x0) at /usr/src/sys/kern/vfs_bio.c:= 1699 #6 0xc030a54c in ffs_fsync (ap=3D0xd8361a70) at /usr/src/sys/ufs/ffs/ffs_v= nops.c:268 #7 0xc0309693 in ffs_sync (mp=3D0xc454d600, waitfor=3D2, cred=3D0xc150de80= , td=3D0xc040d7a0) at vnode_if.h:627 #8 0xc027040b in sync (td=3D0xc040d7a0, uap=3D0x0) at /usr/src/sys/kern/vf= s_syscalls.c:142 #9 0xc021296f in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:2= 81 #10 0xc0213226 in panic (fmt=3D0xc03bf702 "softdep_deallocate_dependencies:= dangling deps") at /usr/src/sys/kern/kern_shutdown.c:550 #11 0xc0306c35 in softdep_deallocate_dependencies (bp=3D0x0) at /usr/src/sy= s/ufs/ffs/ffs_softdep.c:5874 #12 0xc025b30a in brelse (bp=3D0xce6b6228) at /usr/src/sys/sys/buf.h:427 #13 0xc026b93a in flushbuflist (blist=3D0xce6b6228, flags=3D0, vp=3D0xc60fb= 490, slpflag=3D0, slptimeo=3D0, errorp=3D0x0) at /usr/src/sys/kern/vfs_subr.c:1277 #14 0xc026b548 in vinvalbuf (vp=3D0xc60fb490, flags=3D0, cred=3D0x0, td=3D0= x0, slpflag=3D0, slptimeo=3D0) at /usr/src/sys/kern/vfs_subr.c:1160 #15 0xc026e3cc in vclean (vp=3D0xc60fb490, flags=3D8, td=3D0xc4008000) at /= usr/src/sys/kern/vfs_subr.c:2577 #16 0xc026e959 in vgonel (vp=3D0xc60fb490, td=3D0x0) at /usr/src/sys/kern/v= fs_subr.c:2761 #17 0xc026a679 in vlrureclaim (mp=3D0xc454d600) at /usr/src/sys/kern/vfs_su= br.c:723 #18 0xc026a8bf in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:776 #19 0xc01ea01f in fork_exit (callout=3D0xc026a710 , arg=3D0x0, = frame=3D0x0) at /usr/src/sys/kern/kern_fork.c:796 (kgdb) Anyone interested? - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --D9sZ58tf58331Q5M Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/UaZJbHYXjKDtmC0RAlPDAJ9CGikHqB81AEzTPwjPU61jWDbWsgCdHWfX LE15qmeXdMWLQmEUwKXnKYI= =M4OU -END PGP SIGNATURE- --D9sZ58tf58331Q5M--
Re: panic: softdep_deallocate_dependencies: dangling deps
--LwbuP8dfxhLLLUfV Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sun, Aug 31, 2003 at 05:28:10AM -0400, Jeff Roberson wrote: > On Sun, 31 Aug 2003, Christian Brueffer wrote: >=20 > > Hi, > > > > got a panic on my server tonight. Coredump available for further debug= gung. > > > > FreeBSD haakonia.hitnet.rwth-aachen.de 5.1-CURRENT FreeBSD 5.1-CURRENT = #6: Thu Aug 28 00:16:19 CEST 2003 > > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/LORIEN i386 >=20 > When are your srouces from? Specifically, what version of vfs_bio.c do > you have? >=20 It should be rev 1.397 of vfs_bio.c, I updated the sources just before the kernel build. - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --LwbuP8dfxhLLLUfV Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/UcNjbHYXjKDtmC0RArWpAJ9RpBKghyAS/yUhxsuUnVguWMi8jwCgtFXy K1t1z2RdHzq+ZHoy4ujFkGw= =o1AU -END PGP SIGNATURE- --LwbuP8dfxhLLLUfV--
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
--Mh8CTEa8Ax54aLHp Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2003 at 05:57:28PM +1000, Tim Robbins wrote: > On Thu, Aug 21, 2003 at 08:14:45AM +0200, Christian Brueffer wrote: >=20 > > On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: > > > On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: > > >=20 > > > > Hi, > > > >=20 > > > > just got a panic on following 5.1-CURRENT machine: > > > >=20 > > > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu = Aug > > > > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr= /obj/usr/src/sys/GONDOR i386 > > > >=20 > > > > A dump is available if anyone needs specific information. > > > [...] > > > > panic: bundirty: buffer 0xc776e118 still on queue 2^M > > > [...] > > > > #2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p stil= l on queue %d")^M > > > > at /usr/src/sys/kern/kern_shutdown.c:550^M > > > > #3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/v= fs_bio.c:1121^M > > > > #4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs= _bio.c:1436^M > > > > #5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc= 2c17e40)^M > > > > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > > > > #6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/n= fs_bio.c:76^M > > > > #7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D1536= 0, slpflag=3D256, slptimeo=3D0, flags=3D0)^M > > > > at /usr/src/sys/kern/vfs_bio.c:2512^M > > > > #8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size= =3D15360, td=3D0xc2c17e40)^M > > > > at /usr/src/sys/nfsclient/nfs_bio.c:1037^M > > >=20 > > > I think I recognise this backtrace. Did you have a read-only NFS mount > > > active at the time of the crash? In any case, a copy of your NFS entr= ies from > > > /etc/fstab (with any private data removed) would be helpful in tracki= ng this > > > problem down. > > >=20 > >=20 > > No, all mounts were read-write. >=20 > Did one of the servers go down shortly before the panic, then? The last f= ew > lines of dmesg might be useful. >=20 No indication for that in the logs. I would have noticed anyway, as I was playing music from one of the shares. One of the shared file systems was full (besides the reserved space) at the time of the panic. Could that have to do something with it? - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Mh8CTEa8Ax54aLHp Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RIIgbHYXjKDtmC0RAqdEAKC4O3m7T3Gnl0WGDQ2LI8iyf2f2xQCfdeZ8 iOmwx948dfY0k1j9NSW65RM= =6VOi -END PGP SIGNATURE- --Mh8CTEa8Ax54aLHp--
Re: panic: bundirty: buffer 0xc776e118 still on queue 2
--qYrsQHciA3Wqs7Iv Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Thu, Aug 21, 2003 at 01:40:54PM +1000, Tim Robbins wrote: > On Thu, Aug 21, 2003 at 12:26:07AM +0200, Christian Brueffer wrote: >=20 > > Hi, > >=20 > > just got a panic on following 5.1-CURRENT machine: > >=20 > > FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug > > 7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj= /usr/src/sys/GONDOR i386 > >=20 > > A dump is available if anyone needs specific information. > [...] > > panic: bundirty: buffer 0xc776e118 still on queue 2^M > [...] > > #2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p still on= queue %d")^M > > at /usr/src/sys/kern/kern_shutdown.c:550^M > > #3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_b= io.c:1121^M > > #4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio= .c:1436^M > > #5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc2c17= e40)^M > > at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M > > #6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/nfs_b= io.c:76^M > > #7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D15360, s= lpflag=3D256, slptimeo=3D0, flags=3D0)^M > > at /usr/src/sys/kern/vfs_bio.c:2512^M > > #8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size=3D15= 360, td=3D0xc2c17e40)^M > > at /usr/src/sys/nfsclient/nfs_bio.c:1037^M >=20 > I think I recognise this backtrace. Did you have a read-only NFS mount > active at the time of the crash? In any case, a copy of your NFS entries = from > /etc/fstab (with any private data removed) would be helpful in tracking t= his > problem down. >=20 No, all mounts were read-write. # DeviceMountpoint FStype Options DumpPas= s# /dev/da0s1b noneswapsw 0 0 /dev/da0s1a / ufs rw 1 1 /dev/da0s1f /usrufs rw 2 2 /dev/da0s1e /varufs rw 2 2 /dev/cd0c /cdrom cd9660 ro,noauto 0 0 linproc /compat/linux/proc linprocfs rw 0 0 x.x.x.x:/usr/ports /usr/ports nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/src/usr/srcnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/obj/usr/objnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/doc/usr/docnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/www/usr/wwwnfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/home/chris /usr/home/chris nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten/ISOs /mnt/ISOs nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten/foo /mnt/foo nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/bigspace/bar /mnt/bar nfs rw,soft,bg,intr,nfsv3,rdirplus,-r=3D= 32768,-w=3D32768 0 0 x.x.x.x:/mnt/daten /mnt/daten nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/mnt/private /mnt/private nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/openbsd /usr/openbsd nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/netbsd /usr/netbsd nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 x.x.x.x:/usr/stable/src /usr/stable-src nfs rw,soft,bg,intr,nfsv3,rdirplus,= -r=3D32768,-w=3D32768 0 0 - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --qYrsQHciA3Wqs7Iv Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/RGNVbHYXjKDtmC0RAoYrAJwN82v27AzaXasul5yfiEFz4BVpQwCg/eYY n0EF+Wdkm/zwgb8/ahtbq40= =ERIm -END PGP SIGNATURE- --qYrsQHciA3Wqs7Iv--
panic: bundirty: buffer 0xc776e118 still on queue 2
--h31gzZEtNLTqOjlF
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
Hi,
just got a panic on following 5.1-CURRENT machine:
FreeBSD gondor.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Thu Aug
7 21:32:39 CEST 2003 [EMAIL PROTECTED] konia.hitnet.rwth-aachen.de:/usr/obj/usr=
/src/sys/GONDOR i386
A dump is available if anyone needs specific information.
GNU gdb 5.3 (FreeBSD)^M
Copyright 2002 Free Software Foundation, Inc.^M
GDB is free software, covered by the GNU General Public License, and you ar=
e^M
welcome to change it and/or distribute copies of it under certain condition=
s.^M
Type "show copying" to see the conditions.^M
There is absolutely no warranty for GDB. Type "show warranty" for details.=
^M
This GDB was configured as "i386-portbld-freebsd5.0"...^M
panic: bundirty: buffer 0xc776e118 still on queue 2^M
panic messages:^M
---^M
panic: bundirty: buffer 0xc776e118 still on queue 2^M
^M
syncing disks, buffers remaining... 2225 2225 2225 2225 2225 2225 2225 2225=
2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 2225 ^M
giving up on 80 buffers^M
Uptime: 8d3h14m30s^M
Dumping 255 MB^M
16 32 48 64[CTRL-C to abort] [CTRL-C to abort] [CTRL-C to abort] 80[CTRL-=
C to abort] [CTRL-C to abort] [CTRL-C to abort] 96 112 128 144 160 176 192=
208 224 240^M
---^M
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240^M
240 dumping++;^M
(kgdb) bt^M
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:240^M
#1 0xc0253c71 in boot (howto=3D256) at /usr/src/sys/kern/kern_shutdown.c:3=
72^M
#2 0xc0254007 in panic (fmt=3D0xc03cc0ef "bundirty: buffer %p still on que=
ue %d")^M
at /usr/src/sys/kern/kern_shutdown.c:550^M
#3 0xc029b291 in bundirty (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio.c=
:1121^M
#4 0xc029bde1 in brelse (bp=3D0xc776e118) at /usr/src/sys/kern/vfs_bio.c:1=
436^M
#5 0xc02efcb8 in nfs_writebp (bp=3D0xc776e118, force=3D1, td=3D0xc2c17e40)=
^M
at /usr/src/sys/nfsclient/nfs_vnops.c:2987^M
#6 0xc02e02c3 in nfs_bwrite (bp=3D0x0) at /usr/src/sys/nfsclient/nfs_bio.c=
:76^M
#7 0xc029dd41 in getblk (vp=3D0xc2c77b68, blkno=3D400, size=3D15360, slpfl=
ag=3D256, slptimeo=3D0, flags=3D0)^M
at /usr/src/sys/kern/vfs_bio.c:2512^M
#8 0xc02e21e5 in nfs_getcacheblk (vp=3D0xc2c77b68, bn=3D400, size=3D15360,=
td=3D0xc2c17e40)^M
at /usr/src/sys/nfsclient/nfs_bio.c:1037^M
#9 0xc02e1df0 in nfs_write (ap=3D0x0) at /usr/src/sys/nfsclient/nfs_bio.c:=
854^M
#10 0xc02b8a92 in vn_write (fp=3D0xc27a3880, uio=3D0xd5112c7c, active_cred=
=3D0xc2a5c980, flags=3D0, td=3D0xc2c17e40)^M
at vnode_if.h:432^M
#11 0xc027b5a8 in dofilewrite (td=3D0xc2c17e40, fp=3D0xc27a3880, fd=3D0, bu=
f=3D0x975b000, nbyte=3D0, offset=3D0, ^M
flags=3D0) at /usr/src/sys/sys/file.h:249^M
#12 0xc027b3de in write (td=3D0xc2c17e40, uap=3D0xd5112d10) at /usr/src/sys=
/kern/sys_generic.c:330^M
#13 0xc0383f13 in syscall (frame=3D^M
{tf_fs =3D 47, tf_es =3D 47, tf_ds =3D 47, tf_edi =3D 0, tf_esi
=3D=
677275520, tf_ebp =3D -1077939912, tf_isp =3D -720294540, tf_ebx =3D 67728=
7604, tf_edx =3D 22, tf_ecx =3D 677287604, tf_eax =3D 4, tf_trapno =3D 0, t=
f_err =3D 2, tf_eip =3D 677631647, tf_cs =3D 31, tf_eflags =3D 518, tf_esp =
=3D -1077939972, tf_ss =3D 47})^M
at /usr/src/sys/i386/i386/trap.c:1008
- Christian =20
=20
--=20
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
--h31gzZEtNLTqOjlF
Content-Type: application/pgp-signature
Content-Disposition: inline
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (FreeBSD)
iD8DBQE/Q/V/bHYXjKDtmC0RAuOfAKDdT0njACl5W2KRU73CY9lsN5aR6QCdHJ4p
5bckzKE/DAWesK1808FfeX0=
=q5XC
-END PGP SIGNATURE-
--h31gzZEtNLTqOjlF--
Re: sil3112 controller
--Dxnq1zWXvFF0Q93v Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 02, 2003 at 04:48:07PM +0300, Petri Helenius wrote: > Christian Brueffer wrote: >=20 > >On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote: > >=20 > > > >>I just wish there would either be more functionality in the twe driver= =20 > >>or somebody would come > >>out with 8-12 port SATA controller. Looking at the issues for example= =20 > >>the Adaptec SCSI RAIDs > >>have, it seems SATA will take them over quite quickly. > >> > >> =20 > >> > > > >FYI, 3ware sells 8 and 12 port SATA controllers. > > > >- Christian > > > >=20 > > > Sure, but the visibility for the array from the operating system is zero= =20 > with the twe > driver? Or am I missing an utility? >=20 Ah, no. I have talked to some 3ware guys at Linuxtag. They don't release their controller binaries for FreeBSD, because they have seen near zero demand for them yet. Asking them might work :-) - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --Dxnq1zWXvFF0Q93v Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.2 (FreeBSD) iD8DBQE/K8MCbHYXjKDtmC0RAggfAJ4m+yd7Mt+D6ZoKOd18sMc0/QMDOwCfWA20 2C+x1hbwsSDAKGdbwhvOt9s= =e1F0 -END PGP SIGNATURE- --Dxnq1zWXvFF0Q93v--
Re: sil3112 controller
--cHMo6Wbp1wrKhbfi Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Sat, Aug 02, 2003 at 11:19:48AM +0300, Petri Helenius wrote: >=20 > I just wish there would either be more functionality in the twe driver=20 > or somebody would come > out with 8-12 port SATA controller. Looking at the issues for example=20 > the Adaptec SCSI RAIDs > have, it seems SATA will take them over quite quickly. >=20 FYI, 3ware sells 8 and 12 port SATA controllers. - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --cHMo6Wbp1wrKhbfi Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/K7lPbHYXjKDtmC0RAhcmAKCZitcW4HFLTNDs1RjD5UGH1Plb5QCeLXx5 sk7PsU+dXAaJti1Fr8XnAL8= =Xd0P -END PGP SIGNATURE- --cHMo6Wbp1wrKhbfi--
world breakage in pam_echo
--iIq+KTIB+xWY0FJy Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Hi, my world is broken with the following error message for some days now: =3D=3D=3D> lib/libpam/modules/pam_echo cc -O2 -pipe -march=3Dpentium2 -I/usr/src/lib/libpam/modules/pam_echo/../..= /../../contrib/openpam/include -I/usr/src/lib/libpam/modules/pam_echo/../..= /libpam -Wsystem-headers -Werror -Wall -Wno-format-y2k -W -Wstrict-prototy= pes -Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-= strings -Wswitch -Wshadow -Wcast-align -Wno-uninitialized -c /usr/src/lib/= libpam/modules/pam_echo/pam_echo.c /usr/src/lib/libpam/modules/pam_echo/pam_echo.c: In function `_pam_echo': /usr/src/lib/libpam/modules/pam_echo/pam_echo.c:92: warning: dereferencing = type-punned pointer will break strict-aliasing rules *** Error code 1 Stop in /usr/src/lib/libpam/modules/pam_echo. *** Error code 1 Stop in /usr/src/lib/libpam/modules. *** Error code 1 Stop in /usr/src/lib/libpam. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. Does anyone have some insight into this? - Christian --=20 Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D --iIq+KTIB+xWY0FJy Content-Type: application/pgp-signature Content-Disposition: inline -BEGIN PGP SIGNATURE- Version: GnuPG v1.2.1 (FreeBSD) iD8DBQE/FWYzbHYXjKDtmC0RAmikAKCcf+97hb8MYVmFkcB98FFaBgZ2zQCg59oY zt3LZ+pRTuf0O8ndWBklElI= =cQku -END PGP SIGNATURE- --iIq+KTIB+xWY0FJy--
VM related LOR
Hi, I've been getting this LOR for some time now: FreeBSD fangorn.middleearth 5.1-CURRENT FreeBSD 5.1-CURRENT #4: Sun Jun 29 14:39:58 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FANGORN i386 lock order reversal 1st 0xc2a4eafc vm object (vm object) @ /usr/src/sys/vm/vm_object.c:432 2nd 0xc082f110 system map (system map) @ /usr/src/sys/vm/vm_kern.c:325 Stack backtrace: backtrace(c03c5dec,c082f110,c03d2dd4,c03d2dd4,c03d2c6f) at backtrace+0x17 witness_lock(c082f110,8,c03d2c6f,145,0) at witness_lock+0x697 _mtx_lock_flags(c082f110,0,c03d2c6f,145,3) at _mtx_lock_flags+0xb1 _vm_map_lock(c082f0b0,c03d2c6f,145,d2671a78,c0250074) at _vm_map_lock+0x36 kmem_malloc(c082f0b0,1000,101,d2671ae4,c034f60f) at kmem_malloc+0x3a page_alloc(c083a1c0,1000,d2671ad7,101,c040c84c) at page_alloc+0x27 slab_zalloc(c083a1c0,101,c03d4638,664,c083a714) at slab_zalloc+0x14f uma_zone_slab(c083a1c0,101,c03d4638,664,0) at uma_zone_slab+0xd8 uma_zalloc_internal(c083a1c0,0,101,6e8,0) at uma_zalloc_internal+0x55 uma_zfree_arg(c083a700,c2a73b40,0,d2671b90,c03368a8) at uma_zfree_arg+0x2e8 dev_pager_putfake(c2a73b40,0,c03d23ed,be,c2a4eafc) at dev_pager_putfake+0x3a dev_pager_dealloc(c2a4eafc,1,c03d453b,10c,0) at dev_pager_dealloc+0xc8 vm_pager_deallocate(c2a4eafc,0,c03d3711,25f,c03d4638) at vm_pager_deallocate+0x3 d vm_object_terminate(c2a4eafc,0,c03d3711,1b0,c0240820) at vm_object_terminate+0x1 f4 vm_object_deallocate(c2a4eafc,c2a25924,c2a4eafc,c2a25924,d2671c64) at vm_object_ deallocate+0x377 vm_map_entry_delete(c0ed3300,c2a25924,c03d2e42,867,c03c102d) at vm_map_entry_del ete+0x3b vm_map_delete(c0ed3300,0,bfc0,c0ed3300,c26dd400) at vm_map_delete+0x3e3 vm_map_remove(c0ed3300,0,bfc0,11d,c03c05de) at vm_map_remove+0x55 exit1(c2a22850,0,c03c05de,65,d2671d40) at exit1+0x696 sys_exit(c2a22850,d2671d10,c03d81fb,3fd,1) at sys_exit+0x41 syscall(885002f,88e002f,bfbf002f,0,) at syscall+0x26e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (1), eip = 0x2824ac5f, esp = 0xbfbffb50, ebp = 0xbfbffb6c --- This is reproducable here by starting the X server, starting gqview, loading an image with gqview and the shutting down the server with ctrl+alt+backspace. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:43:17PM +0200, Giorgos Keramidas wrote: > On 2003-03-24 19:14, Christian Brueffer <[EMAIL PROTECTED]> wrote: > > I'll write a small manpage this evening which says that MAKEDEV is > > gone now with a short summary of what devfs does. Does that resolve > > your worries? > > If you write a detailed description of devfs please add it to devfs(5) > and just replace the existing manpage of MAKEDEV with something like: > > The MAKEDEV script was deprecated by devfs(5) and geom(4) and > removed from FreeBSD after GEOM became mandatory. Please see > the devfs(5), devfs(8), geom(4) and mount_devfs(8) manpages for > more details. > > This should be enough IMHO to point the reader to the right place. > > - Giorgos > That was my original intent. I'm still uncertain if it would be better to write a small manpage or just create a MLINK to one of the devfs pages... - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 03:43:19PM -0500, Robert Watson wrote:
>
> On Mon, 24 Mar 2003, Christian Brueffer wrote:
>
> > > Well, not much to see here:
> > >
> > > malloc() of "128" with the following non-sleepablelocks held:
> > > exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n
> > > etisr.c:215
> > >
> > > which is repeated over and over again, when I copy a large file over
> > > NFS. There's no actual trace appearing.
> > >
> >
> > Sorry, these ones are appearing too:
> >
> > malloc() of "128" with the following non-sleepablelocks held:
> > exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u
> > srreq.c:1034
> > exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u
> > srreq.c:1027
>
> Looks like witness warnings don't automatically auto-trace. Could you set
> witness.ddb and generate a backtrace for each of the warnings and e-mail
> them to me? Thanks!
>
malloc() of "128" with the following non-sleepablelocks held:
exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @
/usr/src/sys/net/netisr.c:215
Debugger("witness_warn")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> tr
Debugger(c03a295c,cd21cb6c,1,c0441b80,c05232e0) at Debugger+0x54
witness_warn(5,0,c03d54ac,c03c2a26,3) at witness_warn+0x1a0
uma_zalloc_arg(c083ad80,0,102,c040df80,4) at uma_zalloc_arg+0x53
malloc(70,c05232e0,102,cd21cbd4,c051ff4b) at malloc+0xd4
biba_alloc(2,c05235c0,cd21cbf4,c02363df,c0ee993c) at biba_alloc+0x26
mac_biba_init_label(c0ee993c,0,c03c2846,2c1,0) at mac_biba_init_label+0x1b
mac_init_ipq(c0ee9918,b,0,c1367020,0) at mac_init_ipq+0x8f
ip_reass(c0ee9000,c04672c8,c0ee9918,cd21cc44,cd21cca0) at ip_reass+0x5e
ip_input(c0ee9000,0,c03ccd2d,e9,c0ebcb00) at ip_input+0x7ff
swi_net(0,0,c03c1abe,217,c0ec7a00) at swi_net+0x112
ithread_loop(c0ec6100,cd21cd48,c03c1921,363,aa90) at ithread_loop+0x182
fork_exit(c022e680,c0ec6100,cd21cd48) at fork_exit+0xc4
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xcd21cd7c, ebp = 0 ---
- Christian
--
Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED]
GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
pgp0.pgp
Description: PGP signature
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 11:03:52PM +0200, Ruslan Ermilov wrote: > On Mon, Mar 24, 2003 at 08:29:59PM +0200, Jarkko Santala wrote: > > On Mon, 24 Mar 2003, Christian Brueffer wrote: > > > > > On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: > > > > > Date: Mon, 24 Mar 2003 14:34:57 +0100 > > > > > From: Christian Brueffer <[EMAIL PROTECTED]> > > > > > Sender: [EMAIL PROTECTED] > > > > > > > > > > On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: > > > > > > On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: > > > > > > > > > > > > > In message <[EMAIL PROTECTED]>, Christian Brueffer w= > > > > > rites: > > > > > > > >now that MAKEDEV has been gone for a while, the manpages (alpha and i3= > > > > > 86) > > > > > > > >can be nuked as well, right? > > > > > > > > > > > > > > Right. > > > > > > > > > > > > Although it might be considered dragging old baggage around, would it > > > > > > make sense to instead of zapping the man page completely write a new one > > > > > > that would at least give a clue on how things are done these days? > > > > > > > > > > > > Otherwise unclued people might just think there's something wrong with > > > > > > their system because the man page is missing and get even more confused. > > > > > > > > > > Well, people are supposed to read UPDATING before updating the system. > > > > > UPDATING already has an entry about this, so has the handbook, the > > > > > release notes etc. > > > > > > > > > > I think we can't really help people that don't read the recommended > > > > > documentation. > > > > > > > > I think POLA should apply to things like this (even across major > > > > releases). MAKEDEV has been around for a long time and most folks are > > > > used to it being there. It's simply something that most people assume > > > > will be there on a Unix-like system. > > > > > > > > Yes, people should read UPDATING and, better still, the release > > > > notes. But taking the added step of having a simple man page with a > > > > pointer to the devfs paper and saying that MAKEDEV is no more there will > > > > avoid a lot of confusion. > > > > > > > > The goal of documentation should not be to make it possible for > > > > sophisticated users to use the system. It should make it as > > > > easy as possible for all levels of users, including those new to Unix > > > > and BSD to use the system. > > > > > > I'll write a small manpage this evening which says that MAKEDEV is gone now > > > with a short summary of what devfs does. > > > Does that resolve your worries? > > > > Exactly what I had in mind, so sounds good to me. ;) You probably want to > > make it as generic as possible, so that keeping it up-to-date doesn't > > become a burden in the future. I'd hate to create any extra maintenance > > work to anyone, no matter how small. > > > I'd rather just MLINK mount_devfs(8) to MAKEDEV(8) for the > time being, say until 5.2 is out, like is the case for > vnconfig(8). > Also good. devfs(5) would be a better choice then, mount_devfs(8) is just an MLINK to mount_std. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 08:59:29PM +0100, Christian Brueffer wrote: > On Mon, Mar 24, 2003 at 02:53:08PM -0500, Robert Watson wrote: > > > > > > It's on the console. > > > > Any chance you could copy/paste it using a serial console or the like? > > > > Well, not much to see here: > > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n > etisr.c:215 > > which is repeated over and over again, when I copy a large file over > NFS. There's no actual trace appearing. > Sorry, these ones are appearing too: malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a4608) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 exclusive sleep mutex udp r = 0 (0xc041a18c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1027 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 02:53:08PM -0500, Robert Watson wrote: > > > > It's on the console. > > Any chance you could copy/paste it using a serial console or the like? > Well, not much to see here: malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex netisr lock r = 0 (0xc0466d40) locked @ /usr/src/sys/net/n etisr.c:215 which is repeated over and over again, when I copy a large file over NFS. There's no actual trace appearing. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 02:45:57PM -0500, Robert Watson wrote: > On Mon, 24 Mar 2003, Christian Brueffer wrote: > > > FYI, debug.witness_trace is set (seems to default to 1). Any other ways > > to get more info out of this? > > Are you only looking at syslog, or also at the actual console? It could > be that the Witness traces only appear on the console itself, not in the > log (undesirable, but possible). > It's on the console. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 08:28:38PM +0100, Christian Brueffer wrote: > On Mon, Mar 24, 2003 at 01:08:37PM -0500, Robert Watson wrote: > > > > On Mon, 24 Mar 2003, Daniel C. Sobral wrote: > > > > > The messages below are from today's kernel + mac_mls and mac_biba > > > kld-loaded from loader(8). None of the warning appear if these modules > > > are not loaded (I haven't tried not loading one and then the other, but > > > I can do it on request) > > ... > > > malloc() of "128" with the following non-sleepablelocks held: > > > exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ > > > /usr/src/sys/netinet/udp_usrreq.c:1034 > > > exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ > > > /usr/src/sys/netinet/udp_usrreq.c:1027 > > > > Hmm. I think there's a witness flag to generate stack traces when giving > > out these sorts of warnings -- debug.witness_trace I think. Can you try > > turning that on in loader.conf and see if we get some additional > > information? The only MAC call in udp_output() is > > mac_create_mbuf_from_socket(), which isn't supposed to result in memory > > allocation. That should only happen when the mbuf itself is allocated. A > > stack trace might narrow down the source of the problem. > > > > I get this too with mac_biba in kernel or loaded as a module. > > Message at bootup: > > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex radix node head r = 1 (0xc268377c) locked @ /usr/src/sys/n > et/route.c:549 > > Messages on other network operations: > > malloc() of "128" with the following non-sleepablelocks held: > exclusive sleep mutex inp r = 0 (0xc27a435c) locked @ /usr/src/sys/netinet/udp_u > srreq.c:1034 > FYI, debug.witness_trace is set (seems to default to 1). Any other ways to get more info out of this? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: IP stack problem -- possibly mac-related
On Mon, Mar 24, 2003 at 01:08:37PM -0500, Robert Watson wrote: > > On Mon, 24 Mar 2003, Daniel C. Sobral wrote: > > > The messages below are from today's kernel + mac_mls and mac_biba > > kld-loaded from loader(8). None of the warning appear if these modules > > are not loaded (I haven't tried not loading one and then the other, but > > I can do it on request) > ... > > malloc() of "128" with the following non-sleepablelocks held: > > exclusive sleep mutex inp r = 0 (0xc280a6ec) locked @ > > /usr/src/sys/netinet/udp_usrreq.c:1034 > > exclusive sleep mutex udp r = 0 (0xc035eeec) locked @ > > /usr/src/sys/netinet/udp_usrreq.c:1027 > > Hmm. I think there's a witness flag to generate stack traces when giving > out these sorts of warnings -- debug.witness_trace I think. Can you try > turning that on in loader.conf and see if we get some additional > information? The only MAC call in udp_output() is > mac_create_mbuf_from_socket(), which isn't supposed to result in memory > allocation. That should only happen when the mbuf itself is allocated. A > stack trace might narrow down the source of the problem. > I get this too with mac_biba in kernel or loaded as a module. Message at bootup: malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex radix node head r = 1 (0xc268377c) locked @ /usr/src/sys/n et/route.c:549 Messages on other network operations: malloc() of "128" with the following non-sleepablelocks held: exclusive sleep mutex inp r = 0 (0xc27a435c) locked @ /usr/src/sys/netinet/udp_u srreq.c:1034 - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:12:15AM -0800, Kevin Oberman wrote: > > Date: Mon, 24 Mar 2003 14:34:57 +0100 > > From: Christian Brueffer <[EMAIL PROTECTED]> > > Sender: [EMAIL PROTECTED] > > > > On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: > > > On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: > > > > > > > In message <[EMAIL PROTECTED]>, Christian Brueffer w= > > rites: > > > > >now that MAKEDEV has been gone for a while, the manpages (alpha and i3= > > 86) > > > > >can be nuked as well, right? > > > > > > > > Right. > > > > > > Although it might be considered dragging old baggage around, would it > > > make sense to instead of zapping the man page completely write a new one > > > that would at least give a clue on how things are done these days? > > > > > > Otherwise unclued people might just think there's something wrong with > > > their system because the man page is missing and get even more confused. > > > > > > -jake > > > > > > > Well, people are supposed to read UPDATING before updating the system. > > UPDATING already has an entry about this, so has the handbook, the > > release notes etc. > > > > I think we can't really help people that don't read the recommended > > documentation. > > I think POLA should apply to things like this (even across major > releases). MAKEDEV has been around for a long time and most folks are > used to it being there. It's simply something that most people assume > will be there on a Unix-like system. > > Yes, people should read UPDATING and, better still, the release > notes. But taking the added step of having a simple man page with a > pointer to the devfs paper and saying that MAKEDEV is no more there will > avoid a lot of confusion. > > The goal of documentation should not be to make it possible for > sophisticated users to use the system. It should make it as > easy as possible for all levels of users, including those new to Unix > and BSD to use the system. > > R. Kevin Oberman, Network Engineer > Energy Sciences Network (ESnet) > Ernest O. Lawrence Berkeley National Laboratory (Berkeley Lab) > E-mail: [EMAIL PROTECTED] Phone: +1 510 486-8634 > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > I'll write a small manpage this evening which says that MAKEDEV is gone now with a short summary of what devfs does. Does that resolve your worries? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: MAKEDEV(8) manpage
On Mon, Mar 24, 2003 at 09:40:32AM +0200, Jarkko Santala wrote: > On Sun, 23 Mar 2003, Poul-Henning Kamp wrote: > > > In message <[EMAIL PROTECTED]>, Christian Brueffer writes: > > >now that MAKEDEV has been gone for a while, the manpages (alpha and i386) > > >can be nuked as well, right? > > > > Right. > > Although it might be considered dragging old baggage around, would it > make sense to instead of zapping the man page completely write a new one > that would at least give a clue on how things are done these days? > > Otherwise unclued people might just think there's something wrong with > their system because the man page is missing and get even more confused. > > -jake > Well, people are supposed to read UPDATING before updating the system. UPDATING already has an entry about this, so has the handbook, the release notes etc. I think we can't really help people that don't read the recommended documentation. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
MAKEDEV(8) manpage
Hi, now that MAKEDEV has been gone for a while, the manpages (alpha and i386) can be nuked as well, right? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Bluetooth stack for FreeBSD
On Thu, Mar 06, 2003 at 11:41:23AM -0800, Maksim Yevmenkin wrote: > Hello Christian, > > [...] > > >Are there any undertakings on the way to update the bluetooth code > >in -CURRENT to a newer snapshot? > > As soon as I get at least few positive feedbacks from the testers > Julian will commit it :) I do not feel comfortable to commit the > code that has only been tested on the limited set of devices I have. > > So I'll ask this again. Please try the new code and let me know if > it works for you. Pretty please with two sugar lumps on top :) > > thanks, > max > Great news :-) However, I can't test the code at the moment. My cell phone is bluetooth capable, but I don't have a bluetooth card yet. I was just interested because the -CURRENT sources haven't been updated for some time :-) - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Bluetooth stack for FreeBSD
On Wed, Mar 05, 2003 at 03:24:10PM -0800, Maksim Yevmenkin wrote: > > Dear Hackers, > > I'm very pleased to announce that another release is available for > download at > > http://www.geocities.com/m_evmenkin/ngbt-fbsd-20030305.tar.gz > > The Bluetooth sockets layer has been cleaned up. People should not > see any WITNESS complains with new code. Locking issues have been > revisited and code in much better shape now, although it probably > is not 100% SMP ready just yet. The code should work on SMP system > anyway because sockets layer is still under Giant. Minor bug in > OpenOBEX library has been fixed and OPEX Put-Empty command now works. > Also ng_ubt(4) now supports Wireless Transceiver for Bluetooth from > Microsoft. Thanks to Dustin Boontheekul <[EMAIL PROTECTED]> > for testing. > > IMPORTANT! > > Due to changes in API userland tools must be in sync with the kernel. > People should install new include files, recompile and reinstall all > userland tools as part of upgrade. I'm sorry about that. > > IMPORTANT! > > New taskqueue_swi_giant has been introduces recently in FreeBSD. > The socket code has been converted to use it. If you system is > not recent you will need > > 1) upgrade to recent -current > or > 2) change taskqueue_swi_giant to taskqueue_swi and compile code. > > People are advised to upgrade and try the new code. Please do ask > question and submit success stories/bug reports to me. Please also > CC to one the FreeBSD mailing lists (mobile, net or current) for > archive purposes. > > thanks, > max > Are there any undertakings on the way to update the bluetooth code in -CURRENT to a newer snapshot? - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Re: Wireless Networking
On Mon, Mar 03, 2003 at 01:07:28AM +, Suneel Jhangiani wrote: > I finally managed to get my hands on a couple of other Wireless network > cards (previously I had a DWL-650+ based on the unsupported TI chipset). > > I have tried both cards to no avail on FreeBSD v4.7 and was wondering if > anyone has either working under Current? > > The two cards are: > > 3Com OfficeConnect PC Card (3CRSHPW_96 Wireless LAN PC Card) > Intel PRO/Wireless 2011B LAN PC Card > > Regards, > > Suneel. > I think the 3com one has an Atmel chipset, which is unsupported. Don't about the other one. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
vm related panic
Hi, I occasionaly get this panic on my notebook, mostly at startup. I don't know for sure when it started, but it certainly didn't panic back in january/early february. FreeBSD fangorn.middleearth 5.0-CURRENT FreeBSD 5.0-CURRENT #6: Mon Feb 24 15:44:00 CET 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FANGORN i386 Fatal trap 12: page fault while in kernel mode fault virtual address = 0x72 fault code = supervisor read, page not present instruction pointer = 0x8:0xc02311c7 stack pointer = 0x10:0xcdc60958 frame pointer = 0x10:0xcdc60970 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 = 68 (sysctl) kernel: type 12 trap, code=0 Stopped at vm_object_pip_add+0x37: movzwl 0x72(%esi),%eax db> tr vm_object_pip_add(0,1,1,cdc60a28,cdc60a18) at vm_object_pip_add+0x37 vm_fault(c082f000,c0757000,1,0,c257f960) at vm_fault+0x2b0 trap_pfault(cdc60b14,0,c0757a1d,1,c0757a1d) at trap+0x3cd trap(c0450018,10,cdc60010,c0eb6000,cdc60c0c) at trap+0x3cd calltrap() at calltrap+0x5 --- trap 0xc, eip = 0xc02aec98, esp = 0xcdc60b54, ebp = 0xcdc60b54 --- strlen(c0757a1d,c04f36b1,12,c04a8068,20e9) at strlen+0x8 sysctl_kern_function_list_iterate(c0757a1d,cdc60c0c,c0e90048,c0eb6000,c0eb6000) at sysctl_kern_function_l ist_iterate+0x1a link_elf_each_function_name(c0eb6000,c02315f0,cdc60c0c,707,cdc60c0c) at link_elf_each_function_name+0x45 sysctl_kern_function_list(c0405a00,0,0,cdc60c0c,cdc60c0c) at sysctl_kern_function_list+0xec sysctl_root(0,cdc60ca8,2,cdc60c0c,bfbff40c) at sysctl_root+0x15b userland_sysctl(c257f960,cdc60ca8,2,0,bfbff40c) at userland_sysctl+0x1c2 __sysctl(c257f960,cdc60d10,c03d2d3e,407,6) at __sysctl+0xb0 syscall(2f,2f,2f,4,805befd) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (202, FreeBSD ELF32, __sysctl), eip = 0x805ae27, esp = 0xbfbff3bc, ebp = 0xbfbffc68 --- db> - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D pgp0.pgp Description: PGP signature
Fatal trap 18: integer divide while in kernel mode
Hi, got this panic with an up to date CURRENT: Fatal trap 18: integer divide while in kernel mode instruction pointer = 0x8:0xc025f3cc stack pointer = 0x10:0xd1d38aa8 frame pointer = 0x10:0xd1d38abc 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 = 446 (kldload) kernel: type 18 trap, code=0 Stopped at link_elf_lookup_symbol+0x1c:divl0x54(%esi),%eax db> tr link_elf_lookup_symbol(c282c200,c25a83e0,d1d38adc,c03b6bb1,c03b3e02) at link_elf_lookup_symbol+0x1c link_elf_lookup_set(c282c200,c03b3e02,d1d38b54,d1d38b58,d1d38b5c) at link_elf_lookup_set+0x7f linker_file_lookup_set(c282c200,c03b3e02,d1d38b54,d1d38b58,d1d38b5c) at linker_file_lookup_set+0x79 linker_load_dependencies(c282c200,0,c2852500,10c4,15500) at linker_load_dependencies+0x6a link_elf_load_file(c0409230,c25a8e20,d1d38c80,c25a8e20,0) at link_elf_load_file+0x464 linker_load_file(c25a8e20,d1d38ca4,0,d1d38cb4,0) at linker_load_file+0xbd linker_load_module(0,c264c400,0,0,d1d38cd0) at linker_load_module+0xd7 kldload(c2647000,d1d38d10,c03c9f4a,407,1) at kldload+0x114 syscall(2f,2f,2f,0,bfbffdcc) at syscall+0x28e Xint0x80_syscall() at Xint0x80_syscall+0x1d --- syscall (304, FreeBSD ELF32, kldload), eip = 0x8048d7b, esp = 0xbfbffd6c, ebp = 0xbfbffda0 --- db> - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D msg52270/pgp0.pgp Description: PGP signature
Re: /dev/dsp disappears while being used
On Thu, Jan 23, 2003 at 11:10:05PM +0100, Alexander Langer wrote: > > Folks. I heard on IRC others are seeing this as well: > > I'm using FreeBSD 5.0-CURRENT #2: Thu Jan 9 22:49:45 CET 2003 on i386, > but it used to happen since at least December, maybe even November (I'm > always using more or less recent -CURRENT's). > I didn't happen before, so I can be rather sure it's not the xmms binary > which causes the error, since I haven't changed anything in regard to > XMMS since August: > -r-xr-xr-x 1 root wheel 974196 Aug 23 12:24 xmms > and this error definitely didn't occur before November. > > This is my sndstat, if of interest: > FreeBSD Audio Driver (newpcm) > Installed devices: > pcm0: at io 0xd800 irq 10 (1p/1r/2v channels duplex default) > > hw.snd.targetirqrate: 32 > hw.snd.report_soft_formats: 1 > hw.snd.verbose: 1 > hw.snd.unit: 0 > hw.snd.maxautovchans: 5 > hw.snd.pcm0.buffersize: 16384 > hw.snd.pcm0.vchans: 2 > hw.snd.pcm0.spdif_enabled: 0 > > Anyways, here's the problem description: > > After several hours/days of uptime (2 days now) and approx. > 12 hours/day sound usage with XMMS and like hundrets of MP3 songs played, > /dev/dsp just disappears. > > It always happens after XMMS finnished an MP3 song and wants to play the > next one (also on songs it successfully played before). This fails, > because of these error messages: > > ** WARNING **: oss_open(): Failed to open audio device (/dev/dsp): > Operation not supported by device > ** WARNING **: oss_open(): Failed to open audio device (/dev/dsp): No > such file or directory > > I then mknod a dsp device with the major/minor of dsp in / and s-linked > /dev/dsp to /dsp. xmms then reports "Device busy". > > When I then symbolically link /dev/dsp to one of the dspX.X devices, > XMMS can play sound for some more time, but then these are disappearing > as well. > > Is this a devfs bug? I almost think so, but I'm not sure. > > Alex > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > I'm seeing this too, same sound chip, by the way. I'm running a recent current with the src/sys/dev/sound from early december, which works fine. The only commits to sys/dev/sound I can recall from that time frame were some locking changes in the pcm driver. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D msg50821/pgp0.pgp Description: PGP signature
Re: Which RELENG_5 for cvsup for RELEASE?
On Tue, Jan 21, 2003 at 03:25:09AM +0100, Harald Schmalzbauer wrote: > Simon L. Nielsen wrote: > > On 2003.01.21 03:13:41 +, Harald Schmalzbauer wrote: > > > >> I'd like to cvsup from RC1 to RELEASE. Is it still RELENG_5_0 or > >> something else? > > Yes it is still RELENG_5_0 - RELENG_5 will not be created untill after > > FreeBSD 5.1 or 5.2. > > OK., RELENG_5 will be the -stable branch; Like discovered before! But I > have little problems here in germany to find any up-to-date mirror. > cvsup.freebsd.org is the fastes, but obviously not the first choice from > here, on the other hand just ftp7.de.freebsd.org has 5-RELEASE (FTP!!!), > so I'm not sure if cvs is up to date. > > Which mirrors are up to date and have "spare" resources? > > Thanks, > > -Harry > I'm using cvsup2.de.freebsd.org, reasonably fast and up to date. - Christian -- Christian Brueffer [EMAIL PROTECTED] [EMAIL PROTECTED] GPG Key: http://people.freebsd.org/~brueffer/brueffer.key.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D msg50629/pgp0.pgp Description: PGP signature
Re: compile problem
On Sun, Jan 12, 2003 at 01:42:31PM -0800, Joe Laughlin wrote: > on Current cvsupped at 1:15 PST on 1/12/03, I get the following > > ===> lib/libkvm > rm -f .depend > mkdep -f .depend -a-DLIBC_SCCS -I/usr/src/lib/libkvm > /usr/src/lib/libkvm/kvm.c /usr/src/lib/libkvm/kvm_i386.c > /usr/src/lib/libkvm/kvm_file.c /usr/src/lib/libkvm/kvm_getloadavg.c > /usr/src/lib/libkvm/kvm_getswapinfo.c /usr/src/lib/libkvm/kvm_proc.c > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm.c -o kvm.o > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_i386.c -o kvm_i386.o > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_file.c -o kvm_file.o > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_getloadavg.c -o kvm_getloadavg.o > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_getswapinfo.c -o kvm_getswapinfo.o > cc -O2 -pipe -march=athlon -DLIBC_SCCS -I/usr/src/lib/libkvm -c > /usr/src/lib/libkvm/kvm_proc.c -o kvm_proc.o > /usr/src/lib/libkvm/kvm_proc.c: In function `kvm_proclist': > /usr/src/lib/libkvm/kvm_proc.c:376: structure has no member named > `ke_pctcpu' > *** Error code 1 > > Stop in /usr/src/lib/libkvm. > *** Error code 1 > > I'm seeing the same here. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg50049/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
On Sat, Jan 11, 2003 at 04:22:40PM +0100, [EMAIL PROTECTED] wrote: > In message <[EMAIL PROTECTED]>, Christian Brueffer writes: > > >It seems like you can encrypt swap with GBDE, at least that's what one > >item at http://www.freebsd.org/releases/5.0R/todo.html says. > >The manpage doesn't mention encrypting swap though. > > GBDE encrypts disk partitions, you can put swap, ufs, msdosfs or > even oracle inside the encrypted partitions, GBDE doesn't care. > Nice, thanks for the clarification. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49996/pgp0.pgp Description: PGP signature
Re: 5.0 without swap
On Sat, Jan 11, 2003 at 02:16:45AM -0800, Lucky Green wrote: > Miguel wrote: > > Having no swap will prevent you from getting crashdumps in > > case of panic which, if you run 5.0, is not that unusual. > > Besides these days harddrives cost $1/GB, so why not setup > > the swap partition anyway? > > I don't want cleartext cryptographic keys to ever touch magnetic media, > thus potentially opening the door to future forensic analysis. > > --Lucky, who thought that he once, many years ago, read that there was a > kernel option one should set if you have no swap partition. > > It seems like you can encrypt swap with GBDE, at least that's what one item at http://www.freebsd.org/releases/5.0R/todo.html says. The manpage doesn't mention encrypting swap though. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49995/pgp0.pgp Description: PGP signature
Re: pcm0:play:0: play interrupt timeout, channel dead
On Fri, Jan 03, 2003 at 04:22:28AM -0700, Scott Long wrote: > Christian Brueffer wrote: > > > > > > >Well, it's not only maestro hardware: > > > >pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at > >device 3 > >1.5 on pci0 > > > >The same with a CMI8738. > > > >I don't have any boards with these chips, but if it helps, I can give > >you full root access on one of the machines. > > > >- Christian > > > > My new laptop uses the ICH3 sound controller, and it works > fine with 5-current as of this morning. I can't comment on > the CMI8738 > > Scott > > > I admit, with the ICH3 it doesn't happen as much as with the CMI8738, but it still does. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49581/pgp0.pgp Description: PGP signature
Re: pcm0:play:0: play interrupt timeout, channel dead
On Thu, Jan 02, 2003 at 08:43:34PM -0700, Scott Long wrote: > [EMAIL PROTECTED] wrote: > > >Quoting Christian Brueffer : > > > > > > | > > | Hi, > > | > > | I'm seeing the same on two boxen here. The errors seem to have been > > | introduced during the latest pcm locking changes in mid-december. > > | > > | A src/dev/sound from the beginning of december works fine. > > > >Christian, > > > >Thanks. At least I'm not alone, Misery loves company, they say. I only > >have one older kernel and it works fine. [cvsup/world/kernel Dec. 20,2002 > >+- 4am pst] Now all we need is a fix :-) > > > >Thanks again, > > > >ed > > > > > > > >- > > > > > >To Unsubscribe: send mail to [EMAIL PROTECTED] > >with "unsubscribe freebsd-current" in the body of the message > > As the co-author of that driver, it pains me that it's broken. > Unfortunately, > my only maestro3 hardware was in a laptop that no longer works. If anyone > has the hardware as a PCI add-in board and is willing to loan it to me, I'd > be very grateful. > > Another thing to try would be to edit the driver source and reduce it's play > channels to 1 by changing M3_PCHANS. This wouldn't fix the problem, but > in the past the driver has been very fragile with multiple channels enabled. > > Scott > > > Well, it's not only maestro hardware: pcm0: port 0x18c0-0x18ff,0x1c00-0x1cff irq 11 at device 3 1.5 on pci0 The same with a CMI8738. I don't have any boards with these chips, but if it helps, I can give you full root access on one of the machines. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49577/pgp0.pgp Description: PGP signature
Re: pcm0:play:0: play interrupt timeout, channel dead
On Thu, Jan 02, 2003 at 07:47:33AM -0800, [EMAIL PROTECTED] wrote: > Since sometime around Christmas I noticed that sound no longer worked > wiith my new kernels from new worlds. I can go back to a pre-Christmas > kernel and it works fine. I thought I might have done something or that > it would work itself out. I haven't found what I might have done wrong > and it hasn't worked itself out so I wonder if there is anyone else having > issues with maestro3 or similar sound problems? Are there any ideas for > what I might do to get it working again? > > TIA for any help or suggestions, > > ed > > P.S. General Information. I don't know what else to send. > > My kernel configuration file is Generic with unused drivers commented out. > >From todays dmesg with a new world and kernel from yesterday I get: > > FreeBSD 5.0-CURRENT #34: Wed Jan 1 06:32:26 PST 2003 > [EMAIL PROTECTED]:/usr/obj/usr/src/sys/PIII850 > Preloaded elf kernel "/boot/kernel/kernel" at 0xc042b000. > Preloaded elf module "/boot/kernel/snd_maestro3.ko" at 0xc042b0bc. > Preloaded elf module "/boot/kernel/snd_pcm.ko" at 0xc042b170. > Preloaded elf module "/boot/kernel/acpi.ko" at 0xc042b21c. > > and > > pci0: at device 9.1 (no driver attached) > pcm0: port 0x1800-0x18ff irq 5 at device 10.0 on pci0 > > Then trying to play an mp3 I get > pcm0:play:0: play interrupt timeout, channel dead > > /root # kldstat > Id Refs AddressSize Name > 1 12 0xc010 2c42a8 kernel > 21 0xc03c5000 83cc snd_maestro3.ko > 32 0xc03ce000 19a88snd_pcm.ko > 41 0xc03e8000 41f3cacpi.ko > 51 0xc135a000 5000 linprocfs.ko > 61 0xc27d4000 15000linux.ko > > -- > > > - > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Hi, I'm seeing the same on two boxen here. The errors seem to have been introduced during the latest pcm locking changes in mid-december. A src/dev/sound from the beginning of december works fine. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49558/pgp0.pgp Description: PGP signature
Re: My wi(4) ate itself (or Fun with no memory).
On Mon, Dec 30, 2002 at 11:36:45AM -0800, Juli Mallett wrote: > Hey, > > I ran some stuff overnight which exhausted my system's memory fairly well, > and was also thrashing around on my network, and I woke up to find that my > wi(4) blew up more or less: > > wi0: watchdog timeout > wi0: timeout in wi_cmd 0x0002; event status 0x8000 > wi0: timeout in wi_cmd 0x; event status 0x8000 > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: init failed > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: mgmt. buffer allocation failed > Expensive timeout(9) function: 0xc02aefa0(0) 127.445894221 > wi0: timeout in wi_seek to 0/0; last status 4000 > wi0: timeout in wi_seek to 0/44; last status 4044 > wi0: wi_cmd: busy bit won't clear. > wi0: xmit failed > Expensive timeout(9) function: 0xc02cfde0(0xc1a08ccc) 7.384429976 > wi0: watchdog timeout > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: init failed > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: tx buffer allocation failed > wi0: wi_cmd: busy bit won't clear. > wi0: failed to allocate 1594 bytes on NIC > wi0: mgmt. buffer allocation failed > Expensive timeout(9) function: 0xc02aefa0(0) 135.098850348 > wi0: timeout in wi_seek to 0/0; last status 4000 > wi0: timeout in wi_seek to 0/44; last status 4044 > wi0: wi_cmd: busy bit won't clear. > wi0: xmit failed > > Was how it started, and then a lot more of the 'busy bit won't clear' > messages. I ejected the card after de-b0rking the rest of the system, and > was able to bring it back up fine, but thought maybe someone might have some > insight into how exactly my wi(4) blew up, and whether this is an acceptable > failure case :) > > Thanx, > juli. > -- > Juli Mallett <[EMAIL PROTECTED]> > AIM: BSDFlata IRC: juli@EFnet#flata > OpenDarwin, Mono, FreeBSD Developer. > ircd-hybrid Developer, EFnet addict. > FreeBSD on MIPS-Anything on FreeBSD. > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > I get those messages when running dstumbler and then trying to do other stuff with the device. The bad thing is, that the chip is integrated in my notebook so i can't simply take it out and back in again :-) Is there any other way to reinitialize the card? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49447/pgp0.pgp Description: PGP signature
Re: Sysinstall project?
On Mon, Dec 23, 2002 at 03:39:05PM -0500, Brian J. McGovern wrote: > I was just going through the list of projects at the FreeBSD website. I > didn't see one for the installer. I was curious if anyone was working on > an upgrade/replacement for sysinstall... I know of Jordan's paper on the > subject, et al, but curious if anyone was doing anything more than maintaining > our existing sysinstall. > -B > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-current" in the body of the message > > Hi, what you're looking for is the libh project (http://www.freebsd.org/projects/libh.html). There also exists are mailing list ([EMAIL PROTECTED]). - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg49254/pgp0.pgp Description: PGP signature
Re: 5.0-RC1: suspend trouble
On Sun, Dec 15, 2002 at 06:39:52PM -0800, Doug Barton wrote: > On Mon, 16 Dec 2002, Harald Hanche-Olsen wrote: > > > The main reason I decided to try 5.0-RC1 on my brand new Dell Inspiron > > 4150 is a minor problem with suspending the machine under 4.7: After > > wakeup, the fan runs full speed and will not settle until I reboot. > > > > However, with 5.0-RC1 the machine just freezes if I try suspending it. > > Theres is no reaction until I hit the power button, which shuts it > > down immediately. > > If it's any consolation, I have had the same problem on my ibm thinkpad > for a long time. > > -- >"We have known freedom's price. We have shown freedom's power. > And in this great conflict, ... we will see freedom's victory." > - George W. Bush, President of the United States > State of the Union, January 28, 2002 > > Do YOU Yahoo!? > > Suspend works ok on my Thinkpad R32. Which version do you have? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48831/pgp0.pgp Description: PGP signature
Re: swapoff code comitted.
On Sun, Dec 15, 2002 at 02:47:51PM -0800, Matthew Dillon wrote: > : > :How about renaming swapon(8) into swapctl(8) after this function enhancemen= > :t? > :This name reflects it's purpose much better and would be consistent with the > :other BSDs. > : > :- Christian > > I think that's an excellent idea. We would have to do some > rewriting to add the expected options but it would not be too > difficult to do. Mainly just grunt work. e.g. the NetBSD swapctl > command is this: > > swapctl -A [-p priority] [-t blk|noblk] > -D dumpdev > -U [-t blk|noblk] > -a [-p priority] path > -c -p priority path > -d path > -l | -s [-k] > -z > swapon -a | path > > And the OpenBSD swapctl command is this: > > swapctl -A [-p priority] [-t blk|noblk] > swapctl -a [-p priority] path > swapctl -c -p priority path > swapctl -d path > swapctl -l | -s [-k] > swapon -a | path > > We would simply ignore priority since we don't support it, nor would we > need a -t option since we do not have buffered block devices any more > or a -c option since, again, we do not have priorities. > > I would keep 'swapoff' in anycase. It's an obvious command and like > swapon could simply wind up being a hardlink to swapctl. > > I am not volunteering to do this, at least not right now. I have too > big a stack of things that still need to be committed, but if someone > else would like to tackle this I think it would be a nice little project > for a developer with some free time to waste and I would be happy to > review and test the work. > > -Matt > > I'll look into that when some of my current work is done. Maybe it's worth an entry in PHK's JKH TODO list for now. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48830/pgp0.pgp Description: PGP signature
Re: swapoff code comitted.
On Sun, Dec 15, 2002 at 11:46:55AM -0800, Matthew Dillon wrote: > David Schultz's swapoff code has been comitted. It should be regarded > as being highly experimental (and it still needs to be vetted for > VM locking changes and other recent changes in -current). A considerable > amount of testing has been done already but -current is a moving target. > > I am tentitively planning on MFCing the code in a few weeks (some time > after christmas) but it will depend on my schedule. If someone else > wants to take on that work I will would be happy to act as a reviewer. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > How about renaming swapon(8) into swapctl(8) after this function enhancement? This name reflects it's purpose much better and would be consistent with the other BSDs. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48813/pgp0.pgp Description: PGP signature
Re: Current issues
On Wed, Dec 11, 2002 at 01:25:22PM -0500, Chris Faulhaber wrote: > On Wed, Dec 11, 2002 at 08:59:04AM -0800, Marcus Reid wrote: > > Hi: > > > > I made the jump to CURRENT this morning (via a fresh -RC1 install) and > > made the following observations. > > > > 1. Thought I toggled newfs off on the partition where /home was mounted. > >It went ahead and zapped it anyway. Good thing for backups.. > > > > 2. USB doesn't work with my chipset. I have an Asus A7V with VIA chipset. > >Kernel messages follow. Please contact me if I can assist in debugging. > > > > I get the same errors on my Asus A7V333 yet my usb mouse works: > The same here (Asus A7M266). - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48541/pgp0.pgp Description: PGP signature
Re: The great perl script rewrite - big problem
On Sun, Dec 08, 2002 at 04:03:48PM +0100, Riccardo Torrini wrote: > I contributed to the great perl script rewrite but seems that > we forgot to rewrite some important perl script: > > # grep -lR perl /etc/periodic/ > /etc/periodic/daily/440.status-mailq > /etc/periodic/daily/460.status-mail-rejects > /etc/periodic/daily/470.status-named > /etc/periodic/security/550.ipfwlimit > /etc/periodic/security/650.ip6fwlimit > > I noticed this after installing postfix MTA into my 4.7 home server. > > BTW: postfix port disable periodic with this variables: > > # cat /etc/periodic.conf > daily_status_mail_rejects_enable="NO" > daily_status_include_submit_mailq="NO" > daily_submit_queuerun="NO" > > > Because FreeBSD.org use postfix I think it already resolved this > issue, can you distribute your special periodic scripts? > I tryed to convert 460* myself but the perl line is really too > complex for me :-( > > I think that an awk migration may be appropriate, and also a MFC. > Also a Cc: to stable people may be required. > Hi, this has already been taken care of: keramida2002/12/07 15:37:45 PST Modified files: etc/periodic/daily 440.status-mailq 460.status-mail-rejects 470.status-named etc/periodic/security 550.ipfwlimit 650.ip6fwlimit Log: Avoid using perl in the periodic & security scripts. This brings the base system one step closer to being totally perl-free. Approved by:re (jhb) Revision ChangesPath 1.9 +3 -3 src/etc/periodic/daily/440.status-mailq 1.15 +4 -3 src/etc/periodic/daily/460.status-mail-rejects 1.4 +23 -23src/etc/periodic/daily/470.status-named 1.5 +4 -2 src/etc/periodic/security/550.ipfwlimit 1.5 +4 -2 src/etc/periodic/security/650.ip6fwlimit - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48358/pgp0.pgp Description: PGP signature
Re: GEOM + GRUB = ??
On Wed, Dec 04, 2002 at 02:56:10PM -0500, Wesley Morgan wrote: > On Wed, 4 Dec 2002, Terry Lambert wrote: > > > The GRUB stuff does not use GEOM, because GEOM is an abstraction > > that lives in FreeBSD only. GRUB reads the data directly, itself. > > To do this, it has to have some knowledge of how to at least get > > at the code in the boot1/boot2 case (try booting one of the files > > in /boot instead of /kernel), and it needs to understand the FS > > layout for where the files are stored, and/or use a sector map. > > It will need to be updated for UFS2, when that becomes an issue. > > It's not the booting that is a problem. That was working fine until I > had to wipe out the MBR when my disklabel was chomped last week.. It's > the grub command-line "shell"/installer that won't work now (admittedly I > have not updated my grub boot blocks in a while either, so it may be a > pre-GEOM issue). Would not accessing /dev/adX with open() or so go through > GEOM? > Actually I was having problems with the installer in -STABLE also, so it may also be something with the port itself. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48098/pgp0.pgp Description: PGP signature
Re: VM related panic during suspend/resume
On Wed, Dec 04, 2002 at 01:52:33PM -0600, Alan L. Cox wrote: > I've just committed a fix for this assertion failure. > > Regards, > Alan > > Thanks! - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg48097/pgp0.pgp Description: PGP signature
VM related panic during suspend/resume
Hi,
I get this reproducable panic during suspend/resume on my notebook.
panic: mutex vm page queue mutex not owned at /usr/src/sys/vm/vm_page.c:460
Debugger("panic")
Stopped at Debugger+0x54: xchgl %eax,in_Debugger.0
db> tr
Debugger(c03e6d08,c04720e0,c03e641d,cd1f6b3c,1) at Debugger+0x54
panic(c03e641d,c03fb8ed,c03fb901,1cc,cd1f6b90) at panic+0xab
_mtx_assert(c0450860,1,c03fb901,1cc,c0b410d8) at _mtx_assert+0xbc
vm_page_sleep_if_busy(c0b410d8,0,c03ff930,c03fb901,c0e5f310) at
vm_page_sleep_if_busy+0x30
_pmap_unwire_pte_hold(c046c9dc,c0b410d8,1a7,c0ec4300,1) at _pmap_unwire_pte_hold+0x4c
pmap_unuse_pt(c046c9dc,21000,c0b410d8,0,21627) at pmap_unuse_pt+0xdb
pmap_remove_entry(c046c9dc,c083b900,21000,21000,c046c9dc) at pmap_remove_entry+0x7e
pmap_remove_pte(c046c9dc,bfc00084,21000,21000,22000) at pmap_remove_pte+0xbb
pmap_remove_page(c046c9dc,21000,c04569e0,0,c04006cd) at pmap_remove_page+0x46
pmap_remove(c046c9dc,21000,22000,7,1) at pmap_remove+0x47
acpi_sleep_machdep(c0ec5f00,3,c0408aac,c0260d55,3) at acpi_sleep_machdep+0x2a4
acpi_SetSleepState(c0ec5f00,3,cd1f6ce4,c05831c2,c0ec5f00) at acpi_SetSleepState+0x150
acpi_system_eventhandler_sleep(c0ec5f00,3,9a,c2547ca0,c05830e0) at
acpi_system_eventhandler_sleep+0x21
acpi_lid_notify_status_changed(c2547ca0,0,c058f416,7b,0) at
acpi_lid_notify_status_changed+0xe2
acpi_task_thread(0,cd1f6d48,c03e454f,35a,6f6b2e) at acpi_task_thread+0xad
fork_exit(c0588860,0,cd1f6d48) at fork_exit+0xa5
fork_trampoline() at fork_trampoline+0x1a
--- trap 0x1, eip = 0, esp = 0xcd1f6d7c, ebp = 0 ---
db>
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D
msg48042/pgp0.pgp
Description: PGP signature
Re: Cardbus panic with 3com Megahertz
On Thu, Nov 28, 2002 at 05:58:23PM -0700, Scott Long wrote: > On Thu, Nov 28, 2002 at 06:58:05PM -0500, Christian Brueffer wrote: > > > > Hi, > > > > got a reproducable panic while inserting a 3Com Megahertz 3CCFE575BT > > into an up to date -current system. > > The card used to work fine with DP1. > > This might be from my recent changes to the resource allocator in > cardbus. Unfortunately, I don't have one of these cards handy. > Could you enable the hw.cardbus.cis_debug and hw.cardbus.debug > sysctls and send me the full console output from inserting the > card? > > Scott > Hi, here's the output with the sysctls enabled. cis_debug doesn't seem to show anything. BTW, I don't know when you put your changes into the tree, but the card crashes a DP2 machine also. fangorn# found -> vendor=0x10b7, dev=0x, revid=0x01 class=02-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x, statreg=0x0210, cachelnsz=8 (dwords) lattimer=0xa8 (5040 ns), mingnt=0x0a (2500 ns), maxlat=0x05 (1250 ns) intpin=a, irq=255 Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdd79ad38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0173556 stack pointer = 0x10:0xcd2495e8 frame pointer = 0x10:0xcd2495f8 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 = 8 (cbb0) kernel: type 12 trap, code=0 Stopped at cardbus_read_tuple_mem+0x35:movzbl 0(%eax,%ecx,1),%eax db> - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47731/pgp0.pgp Description: PGP signature
Re: Cardbus panic with 3com Megahertz
On Thu, Nov 28, 2002 at 07:48:32PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Christian Brueffer <[EMAIL PROTECTED]> writes: > : got a reproducable panic while inserting a 3Com Megahertz 3CCFE575BT > : into an up to date -current system. > : The card used to work fine with DP1. > > How up to date? > > Warner > All recent kernel changes are in (just recompiled the kernel with new sources to be sure). - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47730/pgp0.pgp Description: PGP signature
Cardbus panic with 3com Megahertz
Hi, got a reproducable panic while inserting a 3Com Megahertz 3CCFE575BT into an up to date -current system. The card used to work fine with DP1. Fatal trap 12: page fault while in kernel mode fault virtual address = 0xdd79cd38 fault code = supervisor read, page not present instruction pointer = 0x8:0xc0173556 stack pointer = 0x10:0xcd24c5e8 frame pointer = 0x10:0xcd24c5f8 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 = 8 (cbb0) kernel: type 12 trap, code=0 Stopped at cardbus_read_tuple_mem+0x35:movzbl 0(%eax,%ecx,1),%eax db> tr cardbus_read_tuple_mem(c260cd80,c29a8880,b17ed38,cd24c65c,cd24c658) at cardbus_read_tuple_mem+0x35 cardbus_read_tuple(c260cd80,c2a82180,c29a8880,b17ed38,cd24c65c) at cardbus_read_tuple+0x75 cardbus_parse_cis(c260cd80,c2a82180,cd24ca88,0,c03d914b) at cardbus_parse_cis+0x1d9 cardbus_do_cis(c260cd80,c2a82180,,0,c2a82108) at cardbus_do_cis+0x41 cardbus_attach_card(c260cd80,c252a128,c03f62e4,393,c25aba00) at cardbus_attach_card+0x2ae cbb_insert(c25aba00,0,c03baefa,393,c25abb08) at cbb_insert+0x151 cbb_event_thread(c25aba00,cd24cd48,c03c8d67,35a,c0ec8e00) at cbb_event_thread+0x7a fork_exit(c019acb4,c25aba00,cd24cd48) at fork_exit+0xa7 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xcd24cd7c, ebp = 0 --- - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47716/pgp0.pgp Description: PGP signature
Re: Call for testers: acpica-unix-20021118.tar.gz
On Tue, Nov 26, 2002 at 09:48:27AM +0900, Mitsuru IWASAKI wrote:
> Hi,
>
> > the new snapshot boots fine here.
> >
> > However, I still get the message
> >
> > acpi0: AcpiGetSleepTypeData failed - AE_NOT_FOUND
>
> OK, never mind. This is normal because your DSDT doesn't have
> _S1_ object.
>
> Name(\_S0_, Package(0x4) {
> 0x0,
> 0x0,
> 0x0,
> 0x0,
> })
> Name(\_S3_, Package(0x4) {
> 0x5,
> 0x5,
> 0x0,
> 0x0,
> })
> Name(\_S4_, Package(0x4) {
> 0x6,
> 0x6,
> 0x0,
> 0x0,
> })
> Name(\_S5_, Package(0x4) {
> 0x7,
> 0x7,
> 0x0,
> 0x0,
> })
>
> > when I try to suspend the machine or anything with closing the lid,
> > or using the keyboard buttons, or when I try something like
> > acpiconf -s 1.
> >
> > The box in question is an IBM Thinkpad R32.
> >
> > Any ideas?
>
> Instead of _S1_, you can specify _S3_ (or _S4_ if you setup for
> hibernation properly) for ACPI configuration.
> Please try:
> # sysctl hw.acpi.sleep_button_state=S3
> # sysctl hw.acpi.lid_switch_state=S3
> # sysctl hw.acpi.standby_state=S3
>
> Thanks
>
>
Thanks, that did the trick.
/me should try a little more before sending out mail.
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D
msg47499/pgp0.pgp
Description: PGP signature
Re: Panic, possibly MAC related
Hi,
forget what i wrote about the acpi stuff, it's triggered by ntpd.
Removing the ntpd options from rc.conf let's me boot through
just fine.
Slab at 0xc282ffc8, freei 23 = 0
panic: Dublicate free of item 0xc282fb80 from zone 0xc0e8d00(128)
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> show pcpu
cpuid = 0
curthread = 0xc2557c40: pid 361 "ntpd"
curpcb = 0xcdc56da0
fpcurthread = 0xc2557c40: pid 361 "ntpd"
idlethread = 0xc0ec7a80: pid 11 "idle"
currentldt = 0x28
spin locks held:
db>
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D
msg47354/pgp0.pgp
Description: PGP signature
Re: Panic, possibly MAC related
On Sat, Nov 23, 2002 at 10:17:14AM -0500, Robert Watson wrote: > > On Sat, 23 Nov 2002, Christian Brueffer wrote: > > > just got this panic on my notebook. Had to manually shut it down after a > > acpiconf -s 4. At the next bootup, the panic occured. At the moment I'm > > trying to boot into my system again to reproduce it. > > In general, this panic occurs in the following situation: each mbuf packet > header has a label structure in it, and the Biba policy stores a per-label > allocated label blob using malloc'd memory. If the packet header is > copied using the copypacket abstractions, then the reference will be > duplicated as will the label data, so each resulting reference will be > separately handled and free'd. However, if the packet header data is > blindly copied without invoking the normal header replication code, then > the same pointer will sit in the new packet header as the old one. When > the two mbufs are free'd, the first one goes fine, but the second one is a > duplicate free. So somehow you managed to trigger a code path that > improperly copies packet headers. Do you have any information on what > process it was that was performing the recvfrom()? One of the code paths > that may present a problem in the base system implementation is a packet > copy for alignment purposes in the KAME code. Another possibility is that > we've seen a regression in existing handling of something like the > fragmentation code, broadcast/multicast, etc. Knowing what's in the > packet and what process it is would help a lot in debugging this. Also, > it would be useful to know what interface this mbuf originated from, if > possible. > > So if it's reproduceable, you want to show the pcpu data to find the pid, > then us ps to identify the process. If you have gdb set up (either live > or a dump), seeing the mbuf ifnet pointer value would be valuable, as well > as knowing the domain, type, etc of the socket in question. > > Thanks, > > Robert N M Watson FreeBSD Core Team, TrustedBSD Projects > [EMAIL PROTECTED] Network Associates Laboratories > Hi, seems like I'm finally able to reproduce the panic. It seems to happen when I play around with acpi stuff, especially the hw.acpi.cpu* settings. Unfortunately this has the side effect, that the panic occurs at every boot, so I haven't found a way to get back into the system yet (unset acpi_load at the loader prompt doesn't help). I'm not too familiar with kernel debugging too, so you would probably have to tell me what to type in. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47352/pgp0.pgp Description: PGP signature
Re: wlan device fails with latest CURRENT
On Fri, Nov 22, 2002 at 07:41:26PM -0700, M. Warner Losh wrote: > In message: <[EMAIL PROTECTED]> > Christian Brueffer <[EMAIL PROTECTED]> writes: > : Hi, > : > : just installed DP2 on my IBM Thinkpad R32 and updated to the latest > : -CURRENT. > : My wlan device (Prism 2.5, internal, no pccard) fails at bootup: > : > : wi0: mem 0xf800-0xf8000fff irq 11 at device 7.0 on pci2 > : wi0: No Mem space on prism2.5? > : device_probe_and_attach: wi0 attach returned 6 > : > : Used to work fine with 4.7-STABLE. > : > : Any ideas? > > Nope. More details? > > Warner > Here's the dmesg.boot and my kernel config. What else could be useful? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D Copyright (c) 1992-2002 The FreeBSD Project. Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994 The Regents of the University of California. All rights reserved. FreeBSD 5.0-CURRENT #0: Sat Nov 23 00:57:35 CET 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/FANGORN Preloaded elf kernel "/boot/kernel/kernel" at 0xc057. Preloaded elf module "/boot/kernel/acpi.ko" at 0xc05700a8. Timecounter "i8254" frequency 1193182 Hz Timecounter "TSC" frequency 1599827344 Hz CPU: Pentium 4 (1599.83-MHz 686-class CPU) Origin = "GenuineIntel" Id = 0xf24 Stepping = 4 Features=0x3febf9ff real memory = 267845632 (255 MB) avail memory = 254324736 (242 MB) Initializing GEOMetry subsystem Pentium Pro MTRR support enabled npx0: on motherboard npx0: INT 16 interface acpi0: on motherboard Using $PIR table, 10 entries at 0xc00fdef0 acpi0: power button is handled as a fixed feature programming model. Timecounter "ACPI-fast" frequency 3579545 Hz acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_cpu0: on acpi0 acpi_tz0: on acpi0 acpi_tz1: on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 0: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 before setting priority for links \\_SB_.LNKH: interrupts: 3 4 5 6 7 91011 penalty: 1110 1110 110 1110 1110 110 110 610 references: 1 priority: 0 before fixup boot-disabled links - \\_SB_.LNKH: interrupts: 3 4 5 6 7 91011 penalty: 1110 1110 110 1110 1110 110 110 610 references: 1 priority: 672 after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.0 \\_SB_.LNKD irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.1 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.2 \\_SB_.LNKH irq 10: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.29.3 \\_SB_.LNKC irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 0.31.1 pci0: on pcib0 agp0: mem 0xe000-0xe3ff at device 0.0 on pci0 pcib1: at device 1.0 on pci0 initial configuration \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - \\_SB_.LNKA irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.0 \\_SB_.LNKB irq 11: [ 3 4 5 6 7 9 10 11] low,level,sharable 1.0.1 pci1: on pcib1 pci1: at device 0.0 (no driver attached) uhci0: port 0x1800-0x181f irq 11 at device 29.0 on pci0 usb0: 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 uhci1: port 0x1820-0x183f irq 11 at device 29.1 on pci0 usb1: on uhci1 usb1: USB revision 1.0 uhub1: Intel UHCI root hub, class 9/0, rev 1.00/1.00, addr 1 uhub1: 2 ports with 2 removable, self powered uhci2: port 0x1840-0x185f irq 11 at device 29.2 on pci0 usb2: on uhci2 usb2: USB re
Panic, possibly MAC related
Hi,
just got this panic on my notebook. Had to manually shut it down
after a acpiconf -s 4. At the next bootup, the panic occured.
At the moment I'm trying to boot into my system again to reproduce
it.
Slab at 0xc26fffc8, freei 19 = 0.
panic: Dublicate free of item 0xc26ff980 from zone 0xc0e8d000(128)
Debugger("panic")
Stopped at Debugger+0x54: xchgl %ebx,in_Debugger.0
db> tr
Debugger(c03e24ca,c0475220,c03fb550,d1c9eae4,1) at Debugger+0x54
panic(c03fb550,c26ff980,c0e8d000,c03e0944,6a8) at panic+0xab
uma_dbg_free(c0e8d000,c26fffc8.c26ff980,6a8,0) at uma_dbg_free+0x122
uma_zfree_arg(c0e8d000,c26ff980,c26fffc8,c043b620,80) at uma_zfree_arg+0x124
free(c26ff980.c044ff60,d1c9eb80,c032a64d,c26ff980) at free+0xe1
biba_free(c26ff980,c0450260,d1c9eba4,c024244f,c0ee0e30) at biba_free+0x1d
mac_biba_destroy_label(c0ee0e30,0,c03e06f7,39a,c0ee0e00) at mac_biba_destroy_label+0x1d
mac_destroy_mbuf(c0ee0e00,0,c261b000,0,d1c9ebc0) at mac_destroy_mbuf+0x7f
m_free(c0ee0e00,0,d1c9ec6c,20e,0) at m_free+0x41
soreceive(c278ba00,d1c9ec44,d1c9ec6c,0,0) at soreceive+0x666
recvit(c261b000,6,d1c9ecb8,bfbff934,8090d10) at recvit+0x1ac
recvfrom(c261b000,d1c9ed10,c0402882.407,6) at recvfrom+0xa9
syscall(2f,2f,2f,8090c20,6) at syscall+0x28e
Xint0x80_syscall() at Xint0x80_syscall+0x1d
--- syscall (29, FreeBSD ELF32, recvfrom), eip = 0x280fdcc3, esp = 0xbfbff8dc, ebp =
0xbfbffbe8
db>
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D
GPG Key ID : 0xA0ED982D
msg47268/pgp0.pgp
Description: PGP signature
Re: DP2 sysinstall problems
On Fri, Nov 22, 2002 at 02:51:08PM -0700, Barkley Vowk wrote: > I worked around this by changing the partition ID number to a freebsd > partition. > > --- > Barkley C. Vowk -- Systems Analyst -- University of Alberta > Math Sciences Department - [EMAIL PROTECTED] > Office: CAB642A, 780-492-4064 > > Opinions expressed are the responsibility of the author and > may not reflect the opinions of others or reality. > > On Fri, 22 Nov 2002, Christian Brueffer wrote: > Thanks for the hint, I just left the OpenBSD partition in place. It was just 1gb anyway. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47266/pgp0.pgp Description: PGP signature
wlan device fails with latest CURRENT
Hi, just installed DP2 on my IBM Thinkpad R32 and updated to the latest -CURRENT. My wlan device (Prism 2.5, internal, no pccard) fails at bootup: wi0: mem 0xf800-0xf8000fff irq 11 at device 7.0 on pci2 wi0: No Mem space on prism2.5? device_probe_and_attach: wi0 attach returned 6 Used to work fine with 4.7-STABLE. Any ideas? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47265/pgp0.pgp Description: PGP signature
DP2 sysinstall problems
Hi, it was reported on this list that the DP2 sysinstall can't delete NTFS partitions. Seems like this can be extended to OpenBSD FFS. Just tried to delete a partition on my notebook and it failed miserably. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: A5C8 2099 19FF AACA F41B B29B 6C76 178C A0ED 982D GPG Key ID : 0xA0ED982D msg47252/pgp0.pgp Description: PGP signature
Here goes another one...
Hi,
got another panic in the line of panicstr: bremfree:
bp 0xc77cc8a0 not locked
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 0x0051
initial pcb at physical address 0x0040f600
panicstr: bremfree: bp 0xc77cc8a0 not locked
panic messages:
---
panic: Most recently used by temp
syncing disks... panic: bremfree: bp 0xc77cc8a0 not locked
Uptime: 2d8h37m59s
pfs_vncache_unload(): 1 entries remaining
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) bt
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc023908d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc0239241 in panic () at /usr/src/sys/kern/kern_shutdown.c:489
#3 0xc026c659 in bremfree (bp=0xc77cc8a0) at /usr/src/sys/kern/vfs_bio.c:633
#4 0xc026dd9e in vfs_bio_awrite (bp=0xc77cc8a0)
at /usr/src/sys/kern/vfs_bio.c:1626
#5 0xc021328c in spec_fsync (ap=0xd5ae98e0)
at /usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0212e7b in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc02dbe85 in ffs_sync (mp=0xc26ec400, waitfor=2, cred=0xc0ef5e80,
td=0xc03d8360) at vnode_if.h:463
#8 0xc027aff8 in sync (td=0xc03d8360, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:127
#9 0xc0238cf9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#10 0xc0239241 in panic () at /usr/src/sys/kern/kern_shutdown.c:489
#11 0xc02f987c in mtrash_ctor (mem=0xc2d07200, size=0, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:135
#12 0xc02f87d7 in uma_zalloc_arg (zone=0xc0ecf280, udata=0x0, flags=0)
at /usr/src/sys/vm/uma_core.c:1358
#13 0xc0230230 in malloc (size=5, type=0xc03dabe0, flags=0)
at /usr/src/sys/kern/kern_malloc.c:171
#14 0xc021b9f5 in elf_load_file (p=0xc287c558, file=0x0, addr=0xd5ae9acc,
entry=0x0) at /usr/src/sys/kern/imgact_elf.c:344
---Type to continue, or q to quit---
#15 0xc021c172 in exec_elf_imgact (imgp=0xd5ae9bc0)
at /usr/src/sys/kern/imgact_elf.c:662
#16 0xc0226200 in execve (td=0xc3020f00, uap=0xd5ae9d14)
at /usr/src/sys/kern/kern_exec.c:258
#17 0xc0329281 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135182808,
tf_esi = 135182836, tf_ebp = -1077937304, tf_isp = -709976716,
tf_ebx = 135208960, tf_edx = -1077936535, tf_ecx = 135182895,
tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134702995,
tf_cs = 31, tf_eflags = 642, tf_esp = -1077937348, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1045
#18 0xc031c8ad in syscall_with_err_pushed () at {standard input}:128
Cannot access memory at address 0xbfbffb68
(kgdb)
FreeBSD gondor.middleearth 5.0-CURRENT FreeBSD 5.0-CURRENT #12: Wed Jul 10
23:35:59 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GONDOR i386
Just tell me if you need more info, got two cores with the same panics
right here.
The panics usually happen after 2-3 days of uptime.
Alex Zepeda experiences similar panics as I've seen from the messages he has
sent to this list, but I don't know what the current state with him is.
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185
GPG Key ID : DAD2B05D5F3C3185
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: Here's a new(er) one
I got a similar one tonight:
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 0x0051
initial pcb at physical address 0x0040f600
panicstr: bremfree: bp 0xc77aa504 not locked
panic messages:
---
panic: Most recently used by temp
syncing disks... panic: bremfree: bp 0xc77aa504 not locked
Uptime: 1d4h52m47s
Dumping 255 MB
16 32 48 64 80 96 112 128 144 160 176 192 208 224 240
---
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
213 dumping++;
(kgdb) where
#0 doadump () at /usr/src/sys/kern/kern_shutdown.c:213
#1 0xc023908d in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:345
#2 0xc0239241 in panic () at /usr/src/sys/kern/kern_shutdown.c:489
#3 0xc026c659 in bremfree (bp=0xc77aa504) at /usr/src/sys/kern/vfs_bio.c:633
#4 0xc026dd9e in vfs_bio_awrite (bp=0xc77aa504)
at /usr/src/sys/kern/vfs_bio.c:1626
#5 0xc021328c in spec_fsync (ap=0xd5ad98e0)
at /usr/src/sys/fs/specfs/spec_vnops.c:403
#6 0xc0212e7b in spec_vnoperate (ap=0x0)
at /usr/src/sys/fs/specfs/spec_vnops.c:121
#7 0xc02dbe85 in ffs_sync (mp=0xc26ec400, waitfor=2, cred=0xc0ef5e80,
td=0xc03d8360) at vnode_if.h:463
#8 0xc027aff8 in sync (td=0xc03d8360, uap=0x0)
at /usr/src/sys/kern/vfs_syscalls.c:127
#9 0xc0238cf9 in boot (howto=256) at /usr/src/sys/kern/kern_shutdown.c:254
#10 0xc0239241 in panic () at /usr/src/sys/kern/kern_shutdown.c:489
#11 0xc02f987c in mtrash_ctor (mem=0xc29ec200, size=0, arg=0x0)
at /usr/src/sys/vm/uma_dbg.c:135
#12 0xc02f87d7 in uma_zalloc_arg (zone=0xc0ecf280, udata=0x0, flags=0)
at /usr/src/sys/vm/uma_core.c:1358
#13 0xc0230230 in malloc (size=5, type=0xc03dabe0, flags=0)
at /usr/src/sys/kern/kern_malloc.c:171
#14 0xc021b9f5 in elf_load_file (p=0xc2b1f804, file=0x0, addr=0xd5ad9acc,
entry=0x0) at /usr/src/sys/kern/imgact_elf.c:344
---Type to continue, or q to quit---
#15 0xc021c172 in exec_elf_imgact (imgp=0xd5ad9bc0)
at /usr/src/sys/kern/imgact_elf.c:662
#16 0xc0226200 in execve (td=0xc2f609c0, uap=0xd5ad9d14)
at /usr/src/sys/kern/kern_exec.c:258
#17 0xc0329281 in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = 135182808, tf_esi = 135182836,
tf_ebp = -1077937304, tf_isp = -710042252, tf_ebx = 135208960, tf_edx = -1077936535,
tf_ecx = 135182895, tf_eax = 59, tf_trapno = 12, tf_err = 2, tf_eip = 134702995,
tf_cs = 31, tf_eflags = 642, tf_esp = -1077937348, tf_ss = 47})
at /usr/src/sys/i386/i386/trap.c:1045
#18 0xc031c8ad in syscall_with_err_pushed () at {standard input}:128
Cannot access memory at address 0xbfbffb68
(kgdb)
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185
GPG Key ID : DAD2B05D5F3C3185
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 09:32:07PM +0200, Gary Jennejohn wrote: > Christian Brueffer writes: > > The issue with mplayer is, that it crashes when i want to watch two > > consecutive files. The first one works fine, but when I want to play > > the second one, it crashes each time :) > > > > Have you tried using a playlist ? I've played maybe 20 files in a > row doing that. > > --- > Gary Jennejohn / [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] > No, I've always been using 'open file'. Thanks for the hint, I'll try that out. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 02:38:51PM +0200, Marc Recht wrote: > > I get the same message with xine on -STABLE each time i use it. Xine > > is simply not very stable on FreeBSD, that's why I'm using mplayer now > Oh. :-) > > (which has it's own issues on -CURRENT) > IIRC then MPlayer doesn't use threads. So, KSE shouldn't be an issue > there. > The issue with mplayer is, that it crashes when i want to watch two consecutive files. The first one works fine, but when I want to play the second one, it crashes each time :) Very, very weird indeed... - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: _waitq_remove
On Wed, Jul 10, 2002 at 12:10:50PM +0200, Marc Recht wrote: > While running (newly build) Xine I get following error: > > Fatal error '_waitq_remove: Not in queue' at line 350 in file > /usr/src/lib/libc_r/uthread/uthread_priority_queue.c (errno = 0) > > Is this an outstanding KSE issue or a problem of the port itself? > > Kernel and world are of today. (cvusup'd 10:00 CEST). > > $FreeBSD: src/lib/libc_r/uthread/uthread_priority_queue.c,v 1.8 > 2002/05/24 04:32:28 deischen Exp $ > > Marc > I don't think this is KSE or even -CURRENT related. I get the same message with xine on -STABLE each time i use it. Xine is simply not very stable on FreeBSD, that's why I'm using mplayer now (which has it's own issues on -CURRENT) - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: KSE M-III status & junior hacker project.
On Mon, Jul 08, 2002 at 07:28:50PM -0400, Anthony Jenkins wrote: > > I finally shelled out Radio Shack's ridiculous amount for a null modem cable > and can do remote debugging now, but I can't remember the URL for that recent > series of articles on getting started with CURRENT debugging...anyone? > > TIA, > Anthony > > > Joe > I think you're looking for these: http://www.onlamp.com/pub/a/bsd/2002/03/21/Big_Scary_Daemons.html http://www.onlamp.com/pub/a/bsd/2002/04/04/Big_Scary_Daemons.html - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: [acpi-jp 1661] Re: ASUS CUSL2 panic on acpi
On Thu, Jul 04, 2002 at 10:09:52PM +0900, Mitsuru IWASAKI wrote:
> My analysis was finished. Please try this patch.
>
> --- exfield.c-Thu Jul 4 21:54:24 2002
> +++ exfield.c Thu Jul 4 21:55:02 2002
> @@ -200,7 +200,7 @@
> /* Handle both ACPI 1.0 and ACPI 2.0 Integer widths */
>
> IntegerSize = sizeof (ACPI_INTEGER);
> -if (WalkState->MethodNode->Flags & ANOBJ_DATA_WIDTH_32)
> +if (WalkState->MethodNode != NULL && WalkState->MethodNode->Flags &
>ANOBJ_DATA_WIDTH_32)
> {
> /*
> * We are running a method that exists in a 32-bit ACPI table.
>
The patch works fine, thanks.
- Christian
--
http://www.unixpages.org[EMAIL PROTECTED]
GPG Pub-Key: www.unixpages.org/cbrueffer.asc
GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185
GPG Key ID : DAD2B05D5F3C3185
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message
Re: ASUS CUSL2 panic on acpi
On Tue, Jul 02, 2002 at 11:55:18AM -0700, Shizuka Kudo wrote: > Dear all, > > I wonder if anyone experienced the same issue as mime. I have an ASUS CUSL2 running >-current and > starting about three days ago, it panic when acpi is autoloaded. If I unset >acpi_load at the boot > prompt, the machine works fine. > > Here's the panic message and a trace for those interested > > acpi0: on motherboard > > > Fatal trap 12: page fault while in kernel mode > fault virtual address = 0x16 > fault code = supervisor read, page not present > instruction pointer = 0x8:0xc04f9aca > stack pointer = 0x10:0xc054ea14 > frame pointer = 0x10:0xc054ea34 > 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 = 0 (swapper) > kernel: type 12 trap, code=0 > Stopped at AcpiExReadDataFromField+0x5a: movzbl 0x16(%eax),%eax > db> trace > AcpiExReadDataFromField(c0f00400,c25da200,c054ea50,c25e50c0,0) at >AcpiExReadDataFromField+0x5a > AcpiExResolveNodeToValue(c0f005b0,c0f00400,1,c0ed6d40,c054eab0) at >AcpiExResolveNodeToValue+0xd9 > AcpiExResolveToValue(c0f005b0,c0f00400,c0f00400,0,c054eab0) at >AcpiExResolveToValue+0x53 > AcpiExResolveOperands(5b80,c0f005b4,c0f00400,c0efbe00,c0f00400) at >AcpiExResolveOperands+0x1cf > AcpiDsEvalRegionOperands(c0f00400,c25d6480,c050411e,c25d6480,0) at >AcpiDsEvalRegionOperands+0x50 > AcpiDsExecEndOp(c0f00400,c054eb14,c0f00414,c0f0040c,cdd4f1b1) at >AcpiDsExecEndOp+0x258 > AcpiPsParseLoop(c0f00400,c257f900,c054eb74,0,0) at AcpiPsParseLoop+0x579 > AcpiPsParseAml(c0f00400,c25dcc40,0,cdd4f1a6,e) at AcpiPsParseAml+0x7c > AcpiDsExecuteArguments(c0efbe00,c051de10,e,cdd4f1a6,c257fdc0) at >AcpiDsExecuteArguments+0x182 > AcpiDsGetRegionArguments(c257fdc0,0,c0efbe00,1,c054ec10) at >AcpiDsGetRegionArguments+0x56 > AcpiNsInitOneObject(c0efbe00,1,c054ec60,0,0) at AcpiNsInitOneObject+0xd8 > AcpiNsWalkNamespace(0,,,1,c0500620) at AcpiNsWalkNamespace+0xad > AcpiWalkNamespace(0,,,c0500620,c054ec60) at AcpiWalkNamespace+0x77 > AcpiNsInitializeObjects(0,c054ecc8,c050b8ab,0,2) at AcpiNsInitializeObjects+0x4d > AcpiEnableSubsystem(0,2,c04fd110,0,0) at AcpiEnableSubsystem+0x8a > acpi_attach(c25d7580,c25b5090,c03d3590,c0ed4d00,c0f04c80) at acpi_attach+0x13b > device_probe_and_attach(c25d7580,c0f04c80,c054ed2c,c0368864,c0f04c80) at > device_probe_and_attach+0xaf > bus_generic_attach(c0f04c80,0,c0ed4d00,c0efda80,c0f04c80) at bus_generic_attach+0x28 > nexus_attach(c0f04c80,c2596090,c03d3590,c03c4480,0) at nexus_attach+0x14 > device_probe_and_attach(c0f04c80,c0ef9780,c054ed80,c035b5e5,c0f04f00) at > device_probe_and_attach+0xaf > root_bus_configure(c0f04f00,c03c4480,0,c054ed98,c020b175) at root_bus_configure+0x28 > configure(0,54b000,54bc00,54b000,0) at configure+0x35 > mi_startup() at mi_startup+0xb5 > begin() at begin+0x43 > db> > Hi, I'm getting a similar message with my Asus A7M266 (Yesterday's sources). What is the best way to record those messages at boot time? Writing them down by hand is pretty suboptimal and I don´t have a serial console installed. TIA, Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
Re: i386 tinderbox failure
On Thu, Jun 27, 2002 at 10:28:00AM -0700, Matthew Dillon wrote: > It would be great if you guys could re-test with the pmap fix > (/usr/src/sys/i386/i386/pmap.c r1.326). I believe that the pmap > bug was to blame for all of these issues but I need verification before > I have the comfort level necessary to do the MFC I intended to do. > > -Matt > Matthew Dillon > <[EMAIL PROTECTED]> > > Everything works great with the fix. - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
ld b0rked?
Hi, I build my system from the latest sources tonight and now I get errors from ld after starting e.g. a second ssh session, or X. It only happens after having started an instance of e.g. ssh or xdm before: chris@gondor:~ $ ssh 192.168.1.1 /usr/libexec/ld-elf.so.1: ssh: Shared object has no run-time symbol table FreeBSD gondor.middleearth 5.0-CURRENT FreeBSD 5.0-CURRENT #1: Thu Jun 27 01:45: 48 GMT 2002 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/GONDOR i386 Ideas? - Christian -- http://www.unixpages.org[EMAIL PROTECTED] GPG Pub-Key: www.unixpages.org/cbrueffer.asc GPG Fingerprint: 0DB5 8563 2473 C72A A8D1 56EA DAD2 B05D 5F3C 3185 GPG Key ID : DAD2B05D5F3C3185 To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-current" in the body of the message
