Re: Serial speed for boot device selection prompt
On Wed, Oct 24, 2007 at 10:50:21AM -0700, Sean Bruno wrote: > I have a drive that contains two seperate bootable partitions(ad0s1a and > ad0s2a). The boot device selection menu(boot0?) appears to only be able to > support 9600 8N1. I wanted to run the serial console at 115200, but I > currently have to switch to 9600 if I need to change the boot device. Is > there a way around this that I can't see? Could I get around this with a > BIOS that can do console redirection? Which "boot device selection menu" are you referring to? "boot0?" implies you don't know. Here's the difference: boot0 is this stage: F1 FreeBSD F5 Drive 1 Default: F1 boot2 is this stage: >> FreeBSD/i386 BOOT Default: 0:ad(0,a)/boot/loader boot: If you want serial capability in boot0, you should set BOOT_COMCONSOLE_SPEED=115200 in your make.conf. After you do that, you'll need to rebuild the boot blocks. The procedure for doing that is step 4 of Section 24.6.5.2 in the Handbook: http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/serialconsole-setup.html You'll also need to update the MBR boot code on-disk to use the new serial version (called boot0sio). boot0cfg -b /boot/boot0sio should do the trick. If you want serial capability in boot2, it's much easier. All you have to do is make a file called /boot.config and place -S115200 in it. You may also want to consider using -S115200 -Dh. See the boot(8) manpage for details on what -S, -D, and -h do. Make sure you don't have a CONSPEED setting in your kernel config as well. All that said, chances are the boot blocks you're using are likely configured to use data from ad0s1a (for booting). So that would be the place to put the /boot.config file. -- | Jeremy Chadwickjdc at parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting nonstandard serial baud rates w/FTDI
On Thu, Oct 25, 2007 at 10:11:36AM +1000, Antony Mawer wrote:
> On 25/10/2007 8:59 AM, Bernd Walter wrote:
> >On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote:
> >>Hi, everyone. I'm pulling my hair out in great chunks.
> >>
> >>I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to
> >>serial port at 25 baud. The FTDI chip definitely supports this rate.
> >>The port mounts at /dev/cuaU0.
> >>
> >>The problem is that
> >>/usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on
> >>this line:
> >>ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate))
> ...
> >>Any ideas on how to get this to work? It doesn't seem like it should be
> >>this difficult!
> >
> >You need to add support in the uftdi driver itself.
> >There is an enum containing ftdi_8u232am_* fields and a switch/case in
> >the driver.
> >
> >The hex value divides the 48MHz clock and leaves a factor 8.
> >So 0x0018 should be the right value for 25bps.
> >
> >There is an OpenBSD patch to calculate the rates dynamically:
> >http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975
> >Something similar (but in better style IMHO) is commited to OpenBSD,
> >which we should merge into our source.
>
>
> There looks to me to be an issue with an assignment operation (=) rather
> than equality test (==) in the following section of the patch:
>
>
> + /* Special cases for 2M and 3M. */
> + if ((speed >= UI(300 * 0.97)) && (speed = UI(200 * 0.97)) \
> && (speed <= UI(200 * 1.03))) { result = 1; goto done; }
>
>
> I would imagine the "(speed = UI(200 * 0.97))" should be == rather
> than = for this to make sense...?
Use the OpenBSD code instead - it is tested and generaly looks better.
You can easily get their diffs via cvs.
Rev 1.11 of uftdireg.h and 1.29 of uftdi.c
--
B.Walterhttp://www.bwct.de http://www.fizon.de
[EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED]
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting nonstandard serial baud rates w/FTDI
On 25/10/2007 8:59 AM, Bernd Walter wrote:
On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote:
Hi, everyone. I'm pulling my hair out in great chunks.
I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to
serial port at 25 baud. The FTDI chip definitely supports this rate. The
port mounts at /dev/cuaU0.
The problem is that
/usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line:
ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate))
...
Any ideas on how to get this to work? It doesn't seem like it should be this
difficult!
You need to add support in the uftdi driver itself.
There is an enum containing ftdi_8u232am_* fields and a switch/case in
the driver.
The hex value divides the 48MHz clock and leaves a factor 8.
So 0x0018 should be the right value for 25bps.
There is an OpenBSD patch to calculate the rates dynamically:
http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975
Something similar (but in better style IMHO) is commited to OpenBSD,
which we should merge into our source.
There looks to me to be an issue with an assignment operation (=) rather
than equality test (==) in the following section of the patch:
+ /* Special cases for 2M and 3M. */
+ if ((speed >= UI(300 * 0.97)) && (speed = UI(200 * 0.97)) \
&& (speed <= UI(200 * 1.03))) { result = 1; goto done; }
I would imagine the "(speed = UI(200 * 0.97))" should be == rather
than = for this to make sense...?
--Antony
___
freebsd-hackers@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Getting nonstandard serial baud rates w/FTDI
On Wed, Oct 24, 2007 at 09:53:06AM -0700, Brooks Talley wrote: > > Hi, everyone. I'm pulling my hair out in great chunks. > > I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to > serial port at 25 baud. The FTDI chip definitely supports this rate. > The port mounts at /dev/cuaU0. > > The problem is that > /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this > line: > ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) > > So far, I have applied these patches to uftdi.c and uftdireg.h: > http://tinyurl.com/2yye2l > > Approaching this with a machete, I have also updated > /usr/src/lib/libc/gen/termios.h to add B25, and rebuilt world and the > kernel, and confirmed that the updated termios.h made it to /usr/include and > /usr/include/sys. termios.h is not important - they are just constants, you should be able to use raw values in software. > Any ideas on how to get this to work? It doesn't seem like it should be this > difficult! You need to add support in the uftdi driver itself. There is an enum containing ftdi_8u232am_* fields and a switch/case in the driver. The hex value divides the 48MHz clock and leaves a factor 8. So 0x0018 should be the right value for 25bps. There is an OpenBSD patch to calculate the rates dynamically: http://archive.openbsd.nu/?ml=openbsd-tech&a=2006-06&m=2083975 Something similar (but in better style IMHO) is commited to OpenBSD, which we should merge into our source. -- B.Walterhttp://www.bwct.de http://www.fizon.de [EMAIL PROTECTED] [EMAIL PROTECTED][EMAIL PROTECTED] ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Floating point in interrupt handler
In message: <[EMAIL PROTECTED]> "Daan Vreeken [PA4DAN]" <[EMAIL PROTECTED]> writes: : But what I haven't found is a description of exactly what the kernel is : missing to allow floating point operations to be done there. FPU context is assumed to only change in user processes. You'd have to fix the FPU state saving code to cope with it changing everywhere, or you'd have to explicitly put the goo to save/restore it around the FP you want to do in the kernel. You had also make sure that the floating point exceptions never trap, since trapping inside the kernel has very limited support. You'll have to fix the problems that this would cause, or force the FPU into a state where it never traps. Sure, maybe you can make it happen. However, you are in for much pain and suffering. The kernel isn't a general purpose computing environment, and trying to pretend it is will lead to suffering. Especially inside of an interrupt handler. It is less bad if this is an ithread, but could be quite painful if you want to do this inside of a fast interrupt handler to reduce latency. I'd recommend strongly against trying this and revaluate your true need for FP in the kernel. From your other mail, you don't seem open to this answer. If you don't take it, you are setting yourself up for a lot of pain and suffering. It is your choice, however. If you do manage to pull it of, I'd be very interested in see what things I didn't know to warn you about... Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB vs PAE
In message: <[EMAIL PROTECTED]> Bob Bishop <[EMAIL PROTECTED]> writes: : Hi, : : On 23 Oct 2007, at 20:45, Ivan Voras wrote: : : > Bob Bishop wrote: : >> Hi, : >> : >> The whole USB kit and caboodle is nodevice'd out in the PAE : >> config. Can : >> anyone give a succinct summary of what needs fixing? (EVERYTHING! : >> is an : >> acceptable answer) Thanks : > : > I'm running USB keyboard and mouse under PAE without problems. Don't : > know about other USB devices. AFAIK everything that is 64-bit clean : > (i.e. works on AMD64 and other architectures) should work ok with PAE, : > so try compiling it in and see for yourself. : : : Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : 6.2R. Thanks! In 6.x the big problem is busdma support. USB doesn't use it quite right, which means that buffers that it uses must be in the lower 4GB. If not, then it won't work. Current does proper scatter/gather, so should work without issue. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB vs PAE
In message: <[EMAIL PROTECTED]> "Ivan Voras" <[EMAIL PROTECTED]> writes: : On 24/10/2007, Bob Bishop <[EMAIL PROTECTED]> wrote: : : > Yes. Keyboard and umass (CDROM and memory stick) seem to work here on : > 6.2R. Thanks! : : I just saw it is officially ok'ed for PAE in future versions (commit : by John Baldwin). 6.x doesn't have the scatter/gather code merged yet, so still is unsafe. Warner ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Look like IPFilter problem
Please file a PR. Darren ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Serial speed for boot device selection prompt
I have a drive that contains two seperate bootable partitions(ad0s1a and ad0s2a). The boot device selection menu(boot0?) appears to only be able to support 9600 8N1. I wanted to run the serial console at 115200, but I currently have to switch to 9600 if I need to change the boot device. Is there a way around this that I can't see? Could I get around this with a BIOS that can do console redirection? Sean ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getting nonstandard baud rates w/FTDI + python
Hi, everyone. I'm pulling my hair out in great chunks. I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 25 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) So far, I have applied these patches to uftdi.c and uftdireg.h: http://tinyurl.com/2yye2l Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B25, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. Any ideas on how to get this to work? It doesn't seem like it should be this difficult! Thanks -Brooks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB vs PAE
On 24/10/2007, Bob Bishop <[EMAIL PROTECTED]> wrote: > Yes. Keyboard and umass (CDROM and memory stick) seem to work here on > 6.2R. Thanks! I just saw it is officially ok'ed for PAE in future versions (commit by John Baldwin). ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Getting nonstandard serial baud rates w/FTDI
Hi, everyone. I'm pulling my hair out in great chunks. I need to get Python 2.5, using pyserial 2.2, to open a FTDI-based usb to serial port at 25 baud. The FTDI chip definitely supports this rate. The port mounts at /dev/cuaU0. The problem is that /usr/local/lib/python2.5/site-packages/serial/serialposix.py fails on this line: ispeed = ospeed = getattr(TERMIOS,'B%s' % (self._baudrate)) So far, I have applied these patches to uftdi.c and uftdireg.h: http://tinyurl.com/2yye2l Approaching this with a machete, I have also updated /usr/src/lib/libc/gen/termios.h to add B25, and rebuilt world and the kernel, and confirmed that the updated termios.h made it to /usr/include and /usr/include/sys. Any ideas on how to get this to work? It doesn't seem like it should be this difficult! Thanks -Brooks ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
kernel panic at shutdown with freebsd 7.0 current snapshot (oct-2007)
Hi I have ZFS (and snapshot) mounted. Then shutdown by `shutdown -p now`. There is the dump: # kgdb /boot/kernel/kernel.symbols vmcore.0 [GDB will not be able to debug user-mode threads: /usr/lib/libthread_db.so: Undefined symbol "ps_pglobal_lookup"] GNU gdb 6.1.1 [FreeBSD] Copyright 2004 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-marcel-freebsd". Unread portion of the kernel message buffer: panic: vrele: negative ref cnt cpuid = 0 KDB: enter: panic panic: from debugger cpuid = 0 Uptime: 8h44m12s Physical memory: 507 MB Dumping 120 MB: 105 89 73 57 41 25 9 #0 doadump () at pcpu.h:195 195 pcpu.h: No such file or directory. in pcpu.h (kgdb) where #0 doadump () at pcpu.h:195 #1 0xc074d98e in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:409 #2 0xc074dc4b in panic (fmt=Variable "fmt" is not available. ) at /usr/src/sys/kern/kern_shutdown.c:563 #3 0xc048cab7 in db_panic (addr=Could not find the frame base for "db_panic". ) at /usr/src/sys/ddb/db_command.c:433 #4 0xc048d4a5 in db_command_loop () at /usr/src/sys/ddb/db_command.c:401 #5 0xc048ec15 in db_trap (type=3, code=0) at /usr/src/sys/ddb/db_main.c:222 #6 0xc07748e6 in kdb_trap (type=3, code=0, tf=0xd53d7984) at /usr/src/sys/kern/subr_kdb.c:502 #7 0xc0a02dfb in trap (frame=0xd53d7984) at /usr/src/sys/i386/i386/trap.c:621 #8 0xc09e87eb in calltrap () at /usr/src/sys/i386/i386/exception.s:139 #9 0xc0774a62 in kdb_enter (msg=0xc0a996bc "panic") at cpufunc.h:60 #10 0xc074dc34 in panic (fmt=0xc0aa528a "vrele: negative ref cnt") at /usr/src/sys/kern/kern_shutdown.c:547 #11 0xc07cb0a1 in vrele (vp=0xc2fccaa0) at /usr/src/sys/kern/vfs_subr.c:2117 #12 0xc0725905 in fdfree (td=0xc2f29a50) at /usr/src/sys/kern/kern_descrip.c:1694 #13 0xc072ea53 in exit1 (td=0xc2f29a50, rv=1) at /usr/src/sys/kern/kern_exit.c:272 #14 0xc07508bf in sigexit (td=Variable "td" is not available. ) at /usr/src/sys/kern/kern_sig.c:2876 #15 0xc0750c99 in postsig (sig=1) at /usr/src/sys/kern/kern_sig.c:2748 #16 0xc077eb78 in ast (framep=0xd53d7d38) at /usr/src/sys/kern/subr_trap.c:250 #17 0xc09e910d in doreti_ast () at /usr/src/sys/i386/i386/exception.s:290 #18 0xd53d7d38 in ?? () #19 0x003b in ?? () #20 0x003b in ?? () #21 0x003b in ?? () #22 0x in ?? () #23 0x in ?? () #24 0xbfbfee58 in ?? () #25 0xd53d7d64 in ?? () #26 0x in ?? () #27 0x0804fb20 in ?? () #28 0x in ?? () #29 0x0004 in ?? () #30 0x000c in ?? () #31 0x0002 in ?? () #32 0x28167553 in ?? () #33 0x0033 in ?? () #34 0x0247 in ?? () #35 0xbfbfee1c in ?? () #36 0x003b in ?? () #37 0x in ?? () #38 0x in ?? () #39 0x in ?? () #40 0x in ?? () #41 0x0116c000 in ?? () #42 0xc2f5bd48 in ?? () ---Type to continue, or q to quit--- #43 0xc31e1000 in ?? () #44 0xd53d7878 in ?? () #45 0xd53d7854 in ?? () #46 0xc2f29a50 in ?? () #47 0xc076a756 in sched_switch (td=0x0, newtd=0x, flags=Cannot access memory at address 0xbfbfee68 ) at /usr/src/sys/kern/sched_4bsd.c:907 Previous frame inner to this frame (corrupt stack?) (kgdb) Regards Patrick __ Do You Yahoo!? Tired of spam? Yahoo! Mail has the best spam protection around http://mail.yahoo.com ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: USB vs PAE
Hi, On 23 Oct 2007, at 20:45, Ivan Voras wrote: Bob Bishop wrote: Hi, The whole USB kit and caboodle is nodevice'd out in the PAE config. Can anyone give a succinct summary of what needs fixing? (EVERYTHING! is an acceptable answer) Thanks I'm running USB keyboard and mouse under PAE without problems. Don't know about other USB devices. AFAIK everything that is 64-bit clean (i.e. works on AMD64 and other architectures) should work ok with PAE, so try compiling it in and see for yourself. Yes. Keyboard and umass (CDROM and memory stick) seem to work here on 6.2R. Thanks! -- Bob Bishop +44 (0)118 940 1243 [EMAIL PROTECTED] fax +44 (0)118 940 1295 ___ freebsd-hackers@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Look like IPFilter problem
IPNat and IPFilter are enabled.
IPFW rules are empty.
#uname -a
FreeBSD gw1.awax.corp 6.3-PRERELEASE FreeBSD 6.3-PRERELEASE #15: Wed Oct 24
10:05:34 MSD 2007 [EMAIL PROTECTED]:/usr/src/sys/i386/compile/GW i386
OPTIONS Part of kernel config file
makeoptions DEBUG=-g# Build kernel with gdb(1) debug
symbols
options KDB
options KDB_UNATTENDED
options SCHED_4BSD # 4BSD scheduler
options PREEMPTION # Enable kernel thread preemption
options INET# InterNETworking
#optionsINET6 # IPv6 communications protocols
options FFS # Berkeley Fast Filesystem
options SOFTUPDATES # Enable FFS soft updates support
options UFS_ACL # Support for access control lists
options UFS_DIRHASH # Improve performance on big
directories
options MD_ROOT # MD is a potential root device
options NFSCLIENT # Network Filesystem Client
options NFSSERVER # Network Filesystem Server
options NFS_ROOT# NFS usable as /, requires
NFSCLIENT
#optionsMSDOSFS # MSDOS Filesystem
options CD9660 # ISO 9660 Filesystem
options PROCFS # Process filesystem (requires
PSEUDOFS)
options PSEUDOFS# Pseudo-filesystem framework
options GEOM_GPT# GUID Partition Tables.
options COMPAT_43 # Compatible with BSD 4.3 [KEEP
THIS!]
options COMPAT_FREEBSD4 # Compatible with FreeBSD4
options COMPAT_FREEBSD5 # Compatible with FreeBSD5
#optionsSCSI_DELAY=5# Delay (in ms) before probing SCSI
options KTRACE # ktrace(1) support
options SYSVSHM # SYSV-style shared memory
options SYSVMSG # SYSV-style message queues
options SYSVSEM # SYSV-style semaphores
options _KPOSIX_PRIORITY_SCHEDULING # POSIX P1003_1B real-time
extensions
options KBD_INSTALL_CDEV# install a CDEV entry in /dev
options ADAPTIVE_GIANT # Giant mutex is adaptive.
##
options IPFIREWALL
options IPFIREWALL_VERBOSE
options IPFIREWALL_VERBOSE_LIMIT=100
options IPFILTER
options IPFILTER_LOG
#options SC_DISABLE_REBOOT
options MAXUSERS=1024
options TCP_DROP_SYNFIN
kgdb
(kgdb) where
#0 doadump () at pcpu.h:165
#1 0xc057ff0c in boot (howto=260) at ../../../kern/kern_shutdown.c:409
#2 0xc058028d in panic (fmt=0xc077e63f "sleeping thread") at
../../../kern/kern_shutdown.c:565
#3 0xc05a8a0c in propagate_priority (td=0xc55b9a80) at
../../../kern/subr_turnstile.c:209
#4 0xc05a93ef in turnstile_wait (lock=0xc07f58c0, owner=0x0, queue=0) at
../../../kern/subr_turnstile.c:715
#5 0xc05744ac in _mtx_lock_sleep (m=0xc07f58c0, tid=334112, opts=0,
file=0x0, line=0) at ../../../kern/kern_mutex.c:579
#6 0xc0443648 in fr_check (ip=0xc5e7d740, hlen=20, ifp=0x0, out=1,
mp=0xdd9a6b20) at ../../../contrib/ipfilter/netinet/fil.c:2320
#7 0xc0448f6c in fr_check_wrapper (arg=0x0, mp=0x0, ifp=0x0, dir=2) at
../../../contrib/ipfilter/netinet/ip_fil_freebsd.c:171
#8 0xc0618008 in pfil_run_hooks (ph=0xc0804fa0, mp=0xdd9a6b94,
ifp=0xc5735c00, dir=2, inp=0xc5db1924) at ../../../net/pfil.c:139
#9 0xc06349c0 in ip_output (m=0xc5e7d700, opt=0xc5735c00, ro=0xdd9a6b60,
flags=0, imo=0x0, inp=0xc5db1924) at ../../../netinet/ip_output.c:679
#10 0xc063ef11 in tcp_output (tp=0xc5de3000) at
../../../netinet/tcp_output.c:1080
#11 0xc0644e2a in tcp_timer_rexmt (xtp=0xc5de3000) at
../../../netinet/tcp_timer.c:537
#12 0xc058fa16 in softclock (dummy=0x0) at ../../../kern/kern_timeout.c:290
#13 0xc0564098 in ithread_execute_handlers (p=0xc55b8a78, ie=0xc5660280) at
../../../kern/kern_intr.c:682
#14 0xc0564216 in ithread_loop (arg=0xc55816b0) at
../../../kern/kern_intr.c:765
#15 0xc0562b0f in fork_exit (callout=0xc05641a0 , arg=0x0,
frame=0x0) at ../../../kern/kern_fork.c:830
#16 0xc072d86c in fork_trampoline () at ../../../i386/i386/exception.s:208
(kgdb) up 3
#3 0xc05a8a0c in propagate_priority (td=0xc55b9a80) at
../../../kern/subr_turnstile.c:209
209 panic("sleeping thread");
(kgdb) up 1
#4 0xc05a93ef in turnstile_wait (lock=0xc07f58c0, owner=0x0, queue=0) at
../../../kern/subr_turnstile.c:715
715 propagate_priority(td);
(kgdb) p td
$1 = (struct thread *) 0xc55b9780
(kgdb) up 1
#5 0xc05744ac in _mtx_lock_sleep (m=0xc07f58c0, tid=334112, opts=0,
file=0x0, line=0) at ../../../kern/kern_mutex.c:579
579 turnstile_wait(&m->mtx_object, mtx_owner(m),
(kgdb) p m->mtx_object
$2 = {lo_class = 0xc07d3404, lo_name = 0xc076a034 "ipf filter load/unload
mutex", lo_type = 0xc076a034 "ipf filter
