Re: clock works slowly when I change CPU speed
Thorsten Greiner wrote: * Bob Fleck [EMAIL PROTECTED] [2003-08-15 22:46]: So, what should be done to restore the proper behavior of the timekeeping on these systems? $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz Timecounter ACPI-fast frequency 3579545 Hz Timecounter TSC frequency 1595302164 Hz $ sysctl -w kern.timecounter.hardware=i8254 Fixes the problem for me. I suspect you should set this in /etc/sysctl.conf to enable it permanently. I suspect that systems where ACPI indicates that the clock speed may change as a result of power management events should set this automatically so people don't have to hack up their system with sysctl's just to get things to work, when it's well known that the system selecting TSC by default on systems with a variable processor speed will experience problems otherwise. I'm guessing what changes in the patches is that the default for preferred clock changed to the wrong thing. -- Terry ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
In message [EMAIL PROTECTED], Robe rt Watson writes: On Fri, 15 Aug 2003, Kris Kennaway wrote: The problem seems to be due to select() being called on the /dev/null device, and it is holding the filedesc lock when it reaches PICKUP_GIANT() in spec_poll. Yeah, this is pretty much the same issue you've been bumping into for a bit -- we hold filedesc lock over select(), which means every object we poll can't grab a lock that either comes before the file descriptor lockin the lock order, or that might sleep. Doesn't this effectively doom any attempt at getting rid af Giant from below ? -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
On Sat, Aug 16, 2003 at 09:12:27AM +0200, Poul-Henning Kamp wrote: In message [EMAIL PROTECTED], Robe rt Watson writes: On Fri, 15 Aug 2003, Kris Kennaway wrote: The problem seems to be due to select() being called on the /dev/null device, and it is holding the filedesc lock when it reaches PICKUP_GIANT() in spec_poll. Yeah, this is pretty much the same issue you've been bumping into for a bit -- we hold filedesc lock over select(), which means every object we poll can't grab a lock that either comes before the file descriptor lockin the lock order, or that might sleep. Doesn't this effectively doom any attempt at getting rid af Giant from below ? It seems like the locking strategy is wrong (see other LORs in select() and poll()). Alfred said he had fixed it, but it was backed out: http://www.freebsd.org/cgi/cvsweb.cgi/src/sys/kern/kern_descrip.c?rev=1.191content-type=text/x-cvsweb-markup As I seem to recall, his strategy of fixing the problem itself caused other problems, though (which was why it was backed out). Kris pgp0.pgp Description: PGP signature
Re: clock works slowly when I change CPU speed
In message [EMAIL PROTECTED], MATOBA Hirozumi wri tes: On Fri, 15 Aug 2003 22:50:47 +0200 Thorsten Greiner wrote: | $ dmesg | grep counter | Timecounter i8254 frequency 1193182 Hz | Timecounter ACPI-fast frequency 3579545 Hz | Timecounter TSC frequency 1595302164 Hz | $ sysctl -w kern.timecounter.hardware=i8254 | Fixes the problem for me. I suspect you should set this in | /etc/sysctl.conf to enable it permanently. Thank you for your advice. I've given timecounters qualities which should solve this problem. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
[current tinderbox] failure on i386/pc98
TB --- 2003-08-16 08:19:51 - starting CURRENT tinderbox run for i386/pc98 TB --- 2003-08-16 08:19:51 - checking out the source tree TB --- cd /home/des/tinderbox/CURRENT/i386/pc98 TB --- /usr/bin/cvs -f -R -q -d/home/ncvs update -Pd -A src TB --- 2003-08-16 08:25:18 - building world TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make -B buildworld Rebuilding the temporary build tree stage 1: legacy release compatibility shims stage 1: bootstrap tools stage 2: cleaning up the object tree stage 2: rebuilding the object tree stage 2: build tools stage 3: cross tools stage 4: populating /home/des/tinderbox/CURRENT/i386/pc98/obj/pc98/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/i386/usr/include stage 4: building libraries stage 4: make dependencies stage 4: building everything.. TB --- 2003-08-16 09:24:12 - building generic kernel TB --- cd /home/des/tinderbox/CURRENT/i386/pc98/src TB --- /usr/bin/make buildkernel KERNCONF=GENERIC Kernel build for GENERIC started on Sat Aug 16 09:24:12 GMT 2003 [...] cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/libkern/udivdi3.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/libkern/umoddi3.c cc -c -x assembler-with-cpp -DLOCORE -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/i386/busio.s cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/acpica -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/ipfilter -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/contrib/dev/ath/freebsd -D_KERNEL -include opt_global.h -fno-common -finline-limit=15000 -fno-strict-aliasing -mno-align-long-strings -mpreferred-stack-boundary=2 -ffreestanding -Werror /vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/pc98/i386/busiosubr.c cc -c -O -pipe -mcpu=pentiumpro -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -g -nostdinc -I- -I. -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys -I/vol/vol0/users/des/tinderbox/CURRENT/i386/pc98/src/sys/dev
Bluetooth on -current
Greetings -current Does anyone know the status of Max Yevmenkin's bluetooth stack for -current? There appears to be bluetooth support with netgraph, is this working? Any expriences with bluetooth on -current are very greatly appreciated. regards -kim -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
On Sat, 16 Aug 2003, Poul-Henning Kamp wrote: The problem seems to be due to select() being called on the /dev/null device, and it is holding the filedesc lock when it reaches PICKUP_GIANT() in spec_poll. Yeah, this is pretty much the same issue you've been bumping into for a bit -- we hold filedesc lock over select(), which means every object we poll can't grab a lock that either comes before the file descriptor lockin the lock order, or that might sleep. Doesn't this effectively doom any attempt at getting rid af Giant from below ? I have mixed feelings about our current strategy. On the one hand, it's a very simple strategy to understand and implement -- it's also a reasonable argument that poll operations for status might return quickly -- i.e., be safe while holding a mutex to prevent the filedesc array from changing. On the other hand, the lock order and sleep implications are pretty alarming, and have already caused a substantial number of problems. It would be interesting to know what consistency guarantees are provided for the user app on other platforms with fine-grained kernel locking. Approaches that come to mind include making a copy of the filedesc array to prevent it from changing (sounds expensive for a select() call) to avoid holding the mutex for long; we could move to an sx lock which would fix the sleep issue at a slightly increased locking cost (but not solve the lock order problem); if we push Giant past the file descriptor code in one big throw that would resolve the lock order issue (but not the sleep problem). In a recent pass, I identified some of the locks with order relationships with the file descriptor lock, and many of those will be non-trivial to resolve. For example, we grab file descriptor locks during execve() to clean up the file descriptor array, and kevent interacts with file descriptor locks. Pushing Giant off further off execve() might have a fair number of interactions with VFS and VM we'd want to watch out for (on the other hand, we are probably close..) Most of the changes to push Giant behind the filedesc lock are not too bad, though. I think it would be worth a concerted effort by an interested and competent party to push Giant behind the file descriptor lock. Robert N M Watson FreeBSD Core Team, TrustedBSD Projects [EMAIL PROTECTED] Network Associates Laboratories ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
LOR tcp_input.c vs. tcp_usrreq.c (was: Re: 2 LORs on my NFS server.)
* Tilman Linneweh [Fr, 15 Aug 2003 at 16:17 GMT]: My CURRENT is already a bit old: # uname -a FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Jul 20 01:00:14 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/CURRENT/sys/POLLY i386 I updated my CURRENT to polly# uname -a FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sat Aug 16 10:11:52 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/source/CURRENT/sys/POLLY i386 and this LOR is reproducable. This happend while the machine was NFS-serving around 3 clients with normal udp NFS and a fourth. client tried to mount something via mount_nfs -T -a 2 The problem is the client with TCP mounts. I tried this time with a single NetBSD client that does a TCP mount and cd'd to the mounted directory. lock order reversal 1st 0xc1a17278 inp (inp) @ /usr/source/CURRENT/sys/netinet/tcp_input.c:654 2nd 0xc046bd6c tcp (tcp) @ /usr/source/CURRENT/sys/netinet/tcp_usrreq.c:621 Stack backtrace: backtrace(1,0,,c0445068,c04451d0) at backtrace+0x12 witness_lock(c046bd6c,8,c03c334c,26d,0) at witness_lock+0x55e _mtx_lock_flags(c046bd6c,0,c03c334c,26d) at _mtx_lock_flags+0x7d tcp_usr_rcvd(c1ce8800,80) at tcp_usr_rcvd+0x1b soreceive(c1ce8800,c891ab1c,c891ab28,c891ab20,0) at soreceive+0x815 nfsrv_rcv(c1ce8800,c1a70780,4) at nfsrv_rcv+0x75 sowakeup(c1ce8800,c1ce884c) at sowakeup+0x7f tcp_input(c0b9ac00,14) at tcp_input+0x11f6 ip_input(c0b9ac00) at ip_input+0x7c8 swi_net(0) at swi_net+0xe6 ithread_loop(c0b87180,c891ad48,c0b87180,c0221660,0) at ithread_loop+0x11c fork_exit(c0221660,c0b87180,c891ad48) at fork_exit+0xab fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc891ad7c, ebp = 0 --- Debugger(witness_lock) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 #8 0xc0251271 in witness_lock (lock=0xc046bd6c, flags=8, file=0xc03c334c /usr/source/CURRENT/sys/netinet/tcp_usrreq.c, line=621) at /usr/source/CURRENT/sys/kern/subr_witness.c:838 #9 0xc0229a7d in _mtx_lock_flags (m=0xc046bd6c, opts=0, ---Type return to continue, or q return to quit--- file=0xc03c334c /usr/source/CURRENT/sys/netinet/tcp_usrreq.c, line=621) at /usr/source/CURRENT/sys/kern/kern_mutex.c:336 #10 0xc02b951b in tcp_usr_rcvd (so=0x0, flags=128) at /usr/source/CURRENT/sys/netinet/tcp_usrreq.c:621 #11 0xc0266155 in soreceive (so=0xc1ce8800, psa=0xc891ab1c, uio=0xc891ab28, mp0=0xc891ab20, controlp=0x0, flagsp=0xc891ab24) at /usr/source/CURRENT/sys/kern/uipc_socket.c:1087 #12 0xc1a3efb5 in nfsrv_rcv (so=0xc1ce8800, arg=0xc1a70780, waitflag=4) at /usr/source/CURRENT/sys/nfsserver/nfs_srvsock.c:445 #13 0xc026783f in sowakeup (so=0xc1ce8800, sb=0xc1ce884c) at /usr/source/CURRENT/sys/kern/uipc_socket2.c:320 #14 0xc02b1336 in tcp_input (m=0xc0b9ac00, off0=20) at /usr/source/CURRENT/sys/netinet/tcp_input.c:1129 #15 0xc02abe08 in ip_input (m=0xc0b9ac00) at /usr/source/CURRENT/sys/netinet/ip_input.c:950 #16 0xc0293b06 in swi_net (dummy=0x0) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: clock works slowly when I change CPU speed
On Sat, 16 Aug 2003 10:25:33 +0200 Poul-Henning Kamp wrote: | In message [EMAIL PROTECTED], MATOBA Hirozumi wri | tes: | On Fri, 15 Aug 2003 22:50:47 +0200 Thorsten Greiner wrote: | | $ dmesg | grep counter | | Timecounter i8254 frequency 1193182 Hz | | Timecounter ACPI-fast frequency 3579545 Hz | | Timecounter TSC frequency 1595302164 Hz | | $ sysctl -w kern.timecounter.hardware=i8254 | | Fixes the problem for me. I suspect you should set this in | | /etc/sysctl.conf to enable it permanently. | Thank you for your advice. | I've given timecounters qualities which should solve this problem. Thank you. I searched in cvs-all mailing-list archive about it, and found at: Message-Id: [EMAIL PROTECTED] From: Poul-Henning Kamp [EMAIL PROTECTED] Date: Sat, 16 Aug 2003 01:23:53 -0700 (PDT) Subject: cvs commit: src/sys/sys timetc.h src/sys/kern kern_tc.c src/sys/dev/acpica acpi_timer.c src/sys/i386/i386 tsc.c src/sys/i386/isa clock.c Then I did cvsup on Date: 16 Aug 2003 17:55 +900 (JST) on my ThinkPad A22e, and checked : the value of kern.timecounter.hardware is ACPI-fast (without changing by sysctl -w) the clock works normally at any CPU settings (hw.acpi.cpu) $ dmesg | grep counter Timecounter i8254 frequency 1193182 Hz quality 0 Timecounter ACPI-fast frequency 3579545 Hz quality 1000 Timecounter TSC frequency 797050143 Hz quality 800 Timecounters tick every 10.000 msec $ sysctl kern.timecounter kern.timecounter.nbinuptime: 105755 kern.timecounter.nnanouptime: 3 kern.timecounter.nmicrouptime: 635 kern.timecounter.nbintime: 38493 kern.timecounter.nnanotime: 5 kern.timecounter.nmicrotime: 38488 kern.timecounter.ngetbinuptime: 0 kern.timecounter.ngetnanouptime: 4 kern.timecounter.ngetmicrouptime: 4186 kern.timecounter.ngetbintime: 0 kern.timecounter.ngetnanotime: 18 kern.timecounter.ngetmicrotime: 30494 kern.timecounter.nsetclock: 3 kern.timecounter.hardware: ACPI-fast kern.timecounter.choice: TSC(800) ACPI-fast(1000) i8254(0) dummy(-100) kern.timecounter.tick: 1 files: /boot/loader.conf.local: hint.acpi.0.disabled=0 hint.apm.0.disabled=1 hw.acpi.verbose=1 hw.ata.atapi_dma=1 if_fxp_load=YES snd_ich_load=YES /etc/sysctl.conf: hw.acpi.lid_switch_state=NONE hw.acpi.suspend_state=NONE hw.acpi.sleep_delay=5 hw.acpi.cpu.performance_speed=4 kernel config file: alomost the same as GENERIC, except for commented out Ethernet drivers (all the lines from device de to device wi, and two lines device aue,device axe) -- [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_xl borked in current!!
In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : On Wed, Aug 13, 2003 at 02:34:38PM +0200, Soeren Schmidt wrote: : : Upgraded laptop from 5.1 to -current was as usual a bad idea, this : time the xl driver broke (and wi is still useless BTW) leaving me : with no networks working :( : : Well, you lucky one, when I insert a Xircom PCMCIA card : -current panics ;-) You have your choice: panic or Xircom no work. I'll add the limiters I've had in my tree. Problem is that the card doesn't like the memory address we choose to read the CIS in at... Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth on -current
On Sat, 16 Aug 2003, Kim Culhan wrote: Does anyone know the status of Max Yevmenkin's bluetooth stack for -current? There appears to be bluetooth support with netgraph, is this working? Any expriences with bluetooth on -current are very greatly appreciated. I've successfully used Bluetooth to connect to my mobile phone and use it as a modem to connect to the internet. So far, I'd say that Bluetooth support is fine in -CURRENT. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Panic on my NFS server: Consumer with zero access count ing_dev_strategy
Hi,
Today I did something stupid. I umount'ed a filesystem of my NFS Server,
while an NFS client was writing to it.
My NFS Server is:
polly# uname -a
FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sat Aug 16
10:11:52 CEST 2003
[EMAIL PROTECTED]:/usr/obj/usr/source/CURRENT/sys/POLLY i386
To my surprise I didn't got a Device busy error or something like
that, but the following panic. I rebooted, and tried again, and this
panic is reproducable.
panic(c03b359c,c1973b00,c403a600,c1948ab0,c1ce35b4) at panic+0xb7
g_dev_strategy(c403a600) at g_dev_strategy+0x118
spec_xstrategy(c1ce35b4,c403a600,0,cd001960,c0201253) at
spec_xstrategy+0x20f
spec_specstrategy(cd001988,cd0019a4,c026d8f4,cd001988,0) at
spec_specstrategy+0x4e
spec_vnoperate(cd001988) at spec_vnoperate+0x13
breadn(c1ce35b4,b7c4e0,0,4000,0) at breadn+0xf4
bread(c1ce35b4,b7c4e0,0,4000,0) at bread+0x20
ffs_update(c1dc0b68,1,ba,0,0) at ffs_update+0x1eb
ffs_fsync(cd001ae0,c02ade94,c0473d20,0,c0229c8d) at ffs_fsync+0x397
nfsrv_commit(c1b0d700,c1a24b00,c1948ab0,cd001c78,0) at
nfsrv_commit+0x3b6
nfssvc_nfsd(c1948ab0,c19479e0,1,c03b7606,167) at nfssvc_nfsd+0x372
nfssvc(c1948ab0,cd001d14,2,0,292) at nfssvc+0x12c
syscall(2f,2f,2f,bfbffdc4,4) at syscall+0x1ed
Xint0x80_syscall() at Xint0x80_syscall+0x1d
(kgdb) bt
#0 doadump () at /usr/source/CURRENT/sys/kern/kern_shutdown.c:240
#1 0xc014ea78 in db_fncall (dummy1=0, dummy2=0, dummy3=-1069042912,
dummy4=0xc8967750 lw\226Èh\234\À ³GÀ\001)
at /usr/source/CURRENT/sys/ddb/db_command.c:548
#2 0xc014e85e in db_command (last_cmdp=0xc03e3210, cmd_table=0x0,
aux_cmd_tablep=0xc03db3e8, aux_cmd_tablep_end=0xc03db3ec)
at /usr/source/CURRENT/sys/ddb/db_command.c:346
#3 0xc014e94b in db_command_loop () at
/usr/source/CURRENT/sys/ddb/db_command.c:472
#4 0xc01512ea in db_trap (type=3, code=0)
at /usr/source/CURRENT/sys/ddb/db_trap.c:73
#5 0xc0363910 in kdb_trap (type=3, code=0, regs=0xc896787c)
at /usr/source/CURRENT/sys/i386/i386/db_interface.c:172
#6 0xc03731cf in trap (frame=
{tf_fs = 24, tf_es = 16, tf_ds = 16, tf_edi = 1, tf_esi =
-1069861476, tf_ebp = -929662784, tf_isp = -929662808, tf_ebx = 0,
tf_edx = 0, tf_ecx = 1, tf_eax = 18, tf_trapno = 3, tf_err = 0, tf_eip =
-1070187611, tf_cs = 8, tf_eflags = 642, tf_esp = -929662740, tf_ss =
-929662752}) at /usr/source/CURRENT/sys/i386/i386/trap.c:580
#7 0xc0364f58 in calltrap () at {standard input}:96
#8 0xc0231c97 in panic (
fmt=0xc03b359c Consumer with zero access count in g_dev_strategy)
at /usr/source/CURRENT/sys/kern/kern_shutdown.c:534
#9 0xc0203ad8 in g_dev_strategy (bp=0xc4017920)
at /usr/source/CURRENT/sys/geom/geom_dev.c:422
#10 0xc0201eaf in spec_xstrategy (vp=0xc1ce5db0, bp=0xc4017920)
at /usr/source/CURRENT/sys/fs/specfs/spec_vnops.c:512
#11 0xc0201f0e in spec_specstrategy (ap=0xc896795c)
at /usr/source/CURRENT/sys/fs/specfs/spec_vnops.c:529
#12 0xc0201253 in spec_vnoperate (ap=0x0)
at /usr/source/CURRENT/sys/fs/specfs/spec_vnops.c:122
#13 0xc026d8f4 in breadn (vp=0xc1ce5db0, blkno=5269152, size=16384,
rablkno=0x0,
rabsize=0x0, cnt=0, cred=0x0, bpp=0x0) at vnode_if.h:1116
#14 0xc026d7e0 in bread (vp=0xc1ce5db0, blkno=5269152, size=16384,
cred=0x0,
bpp=0xc89679fc) at /usr/source/CURRENT/sys/kern/vfs_bio.c:679
#15 0xc030ddcb in ffs_update (vp=0xc1a05a44, waitfor=0)
at /usr/source/CURRENT/sys/ufs/ffs/ffs_inode.c:104
#16 0xc0325907 in ufs_inactive (ap=0x0)
at /usr/source/CURRENT/sys/ufs/ufs/ufs_inode.c:125
#17 0xc032c993 in ufs_vnoperate (ap=0x0)
at /usr/source/CURRENT/sys/ufs/ufs/ufs_vnops.c:2792
#18 0xc027e32e in vput (vp=0xc1a05a44) at vnode_if.h:953
#19 0xc1a34c19 in nfsrv_write (nfsd=0xc1dab900, slp=0xc19de580,
td=0xc0b90390,
mrq=0xc8967c78) at /usr/source/CURRENT/sys/nfsserver/nfs_serv.c:1018
#20 0xc1a40752 in nfssvc_nfsd (td=0x0)
at /usr/source/CURRENT/sys/nfsserver/nfs_syscalls.c:445
#21 0xc1a401cc in nfssvc (td=0xc0b90390, uap=0xc8967d14)
at /usr/source/CURRENT/sys/nfsserver/nfs_syscalls.c:180
#22 0xc037394d in syscall (frame=
{tf_fs = 47, tf_es = 47, tf_ds = 47, tf_edi = -1077936700, tf_esi
= 4, tf_ebp =
---Type return to continue, or q return to quit---
-1077937592, tf_isp = -929661580, tf_ebx = 0, tf_edx = 672335864, tf_ecx
= 25, tf_eax = 155, tf_trapno = 12, tf_err = 2, tf_eip = 671851775,
tf_cs = 31, tf_eflags = 658, tf_esp = -1077937620, tf_ss = 47}) at
/usr/source/CURRENT/sys/i386/i386/trap.c:1008
#23 0xc0364fad in Xint0x80_syscall () at {standard input}:138
---Can't read userspace from dump, or kernel process---
(kgdb) fr 9
#9 0xc0203ad8 in g_dev_strategy (bp=0xc4017920)
at /usr/source/CURRENT/sys/geom/geom_dev.c:422
422 (g_dev_strategy raced with g_dev_close and lost));
(kgdb) list
417 g_dev_strategy(%p/%p) offset %jd length %jd data %p
cmd %d,
418 bp, bp2, (intmax_t)bp-bio_offset,
(intmax_t)bp2-bio_length,
419 bp2-bio_data, bp2-bio_cmd);
420
Re: if_xl borked in current!!
M. Warner Losh wrote: In message: [EMAIL PROTECTED] Andreas Klemm [EMAIL PROTECTED] writes: : On Wed, Aug 13, 2003 at 02:34:38PM +0200, Soeren Schmidt wrote: : : Upgraded laptop from 5.1 to -current was as usual a bad idea, this : time the xl driver broke (and wi is still useless BTW) leaving me : with no networks working :( : : Well, you lucky one, when I insert a Xircom PCMCIA card : -current panics ;-) You have your choice: panic or Xircom no work. I'll add the limiters I've had in my tree. Problem is that the card doesn't like the memory address we choose to read the CIS in at... Warner The Xircom cards worked this past spring. What has changed in the CIS code since then? Scott ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: if_xl borked in current!!
In message: [EMAIL PROTECTED] Scott Long [EMAIL PROTECTED] writes: : M. Warner Losh wrote: : In message: [EMAIL PROTECTED] : Andreas Klemm [EMAIL PROTECTED] writes: : : On Wed, Aug 13, 2003 at 02:34:38PM +0200, Soeren Schmidt wrote: : : : : Upgraded laptop from 5.1 to -current was as usual a bad idea, this : : time the xl driver broke (and wi is still useless BTW) leaving me : : with no networks working :( : : : : Well, you lucky one, when I insert a Xircom PCMCIA card : : -current panics ;-) : : You have your choice: panic or Xircom no work. I'll add the limiters : I've had in my tree. Problem is that the card doesn't like the memory : address we choose to read the CIS in at... : : Warner : : The Xircom cards worked this past spring. What has changed in the CIS : code since then? nothing. The 16-bit cards have always had issues on some machines or with some cards. rather than mapping the cis in, 0's are read back. Warner ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth on -current
On Sat, 16 Aug 2003, Lukas Ertl wrote: On Sat, 16 Aug 2003, Kim Culhan wrote: Does anyone know the status of Max Yevmenkin's bluetooth stack for -current? I've successfully used Bluetooth to connect to my mobile phone and use it as a modem to connect to the internet. So far, I'd say that Bluetooth support is fine in -CURRENT. Would you describe the procedure you used to make this work? -kim ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Bluetooth on -current
On Sat, 16 Aug 2003, Kim Culhan wrote: Does anyone know the status of Max Yevmenkin's bluetooth stack for -current? I've successfully used Bluetooth to connect to my mobile phone and use it as a modem to connect to the internet. So far, I'd say that Bluetooth support is fine in -CURRENT. Would you describe the procedure you used to make this work? I mostly followed the info on http://www.oook.cz/bsd/handbook/bluetooth.html. regards, le -- Lukas Ertl eMail: [EMAIL PROTECTED] UNIX Systemadministrator Tel.: (+43 1) 4277-14073 Vienna University Computer Center Fax.: (+43 1) 4277-9140 University of Vienna http://mailbox.univie.ac.at/~le/ ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
TESTERS WANTED for ATAng preview 2
The story continues with Preview 2 - from the README: Now the functionality is almost equal to that of stock ATA, I'm getting close to being ready to expose this on the -current users, so please give this a go to shake out the last nasties. I've fixed alot of minor issue that testers have reported back (thanks!!), plus a few chipset issued found over the last days. Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files to your src tree, remove the contents of sys/dev/ata and extract the ATAng-*tgz file there, then do the usual drill to get a new kernel... As usual it might kill your dog, abduct your kids and whatnot :) Let me know how this works out for you! Enjoy!! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Panic on my NFS server: Consumer with zero access count ing_dev_strategy
In message [EMAIL PROTECTED], Tilman Linneweh writes: Hi, Today I did something stupid. I umount'ed a filesystem of my NFS Server, while an NFS client was writing to it. This is a pretty evil bug, the panic correctly stops UFS/FFS from writing to the disk device after it has been closed. I am not sure how this is possible, the mountpoint should be long gone etc. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR with filedesc structure and Giant
In message [EMAIL PROTECTED], Robe rt Watson writes: On Sat, 16 Aug 2003, Poul-Henning Kamp wrote: The problem seems to be due to select() being called on the /dev/null device, and it is holding the filedesc lock when it reaches PICKUP_GIANT() in spec_poll. Yeah, this is pretty much the same issue you've been bumping into for a bit -- we hold filedesc lock over select(), which means every object we poll can't grab a lock that either comes before the file descriptor lockin the lock order, or that might sleep. Doesn't this effectively doom any attempt at getting rid af Giant from below ? I have mixed feelings about our current strategy. [...] Well, I was thinking more of the work I have been doing trying to put drivers and GEOM outside Giant (starting from the bottom). At one point we have to say Well, the locks we have above are solid, but we need to drop Giant below here but if Witness sees a PICKUP_GIANT() as an acquisition of Giant, rather than as a resumption of Giant, this clearly does not work. -- Poul-Henning Kamp | UNIX since Zilog Zeus 3.20 [EMAIL PROTECTED] | TCP/IP since RFC 956 FreeBSD committer | BSD since 4.3-tahoe Never attribute to malice what can adequately be explained by incompetence. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Fxtv DGA mode doesn't work anymore
Something has changed during last week because my Fxtv stopped working in DGA mode. I'm back running old kernel so any clues what might cause this? Tomppa FreeBSD 5.1-CURRENT #3: Sun Aug 10 00:57:18 EEST 2003 FreeBSD 5.1-CURRENT #4: Sat Aug 16 21:17:19 EEST 2003 ***clip clip*** Copyright (c) 1992-2003 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.1-CURRENT #3: Sun Aug 10 00:57:18 EEST 2003 [EMAIL PROTECTED]:/u/F/local/sup/5.0/sys/i386/compile/CAT acpi_alloc_wakeup_handler: unable to allocate wake memory Preloaded elf kernel /boot/kernel.old/kernel at 0xc053a000. Calibrating clock(s) ... i8254 clock: 1193190 Hz Timecounter i8254 frequency 1193190 Hz Calibrating TSC clock ... TSC clock: 400913881 Hz CPU: Pentium II/Pentium II Xeon/Celeron (400.91-MHz 686-class CPU) Origin = GenuineIntel Id = 0x653 Stepping = 3 Features=0x183fbffFPU,VME,DE,PSE,TSC,MSR,PAE,MCE,CX8,APIC,SEP,MTRR,PGE,MCA,CMOV,PAT,PSE36,MMX,FXSR real memory = 536805376 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00564000 - 0x1f6b1fff, 521461760 bytes (127310 pages) avail memory = 514416640 (490 MB) Programming 24 pins in IOAPIC #0 IOAPIC #0 intpin 2 - irq 0 FreeBSD/SMP: Multiprocessor System Detected: 2 CPUs cpu0 (BSP): apic id: 0, version: 0x00040011, at 0xfee0 cpu1 (AP): apic id: 1, version: 0x00040011, at 0xfee0 io0 (APIC): apic id: 2, version: 0x00170011, at 0xfec0 bios32: Found BIOS32 Service Directory header at 0xc00fdb60 bios32: Entry = 0xfdb70 (c00fdb70) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xdb91 pnpbios: Found PnP BIOS data at 0xc00f7a30 pnpbios: Entry = f:74be Rev = 1.0 Other BIOS signatures found: null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled SMP: CPU0 bsp_apic_configure(): lint0: 0x00010700 lint1: 0x0400 TPR: 0x SVR: 0x01ff acpi0: AMIINT on motherboard ACPI-1287: *** Error: Method execution failed [\\_SB_.NRTH.SBRG.PS2M._STA] (Node 0xc1bbb9a0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.NRTH.SBRG.PS2M._STA] (Node 0xc1bbb9a0), AE_AML_REGION_LIMIT pci_open(1):mode 1 addr port (0x0cf8) is 0x8058 pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=71908086) pcibios: BIOS version 2.10 AcpiOsDerivePciId: bus 0 dev 7 func 0 acpi0: power button is handled as a fixed feature programming model. ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 6, width = 4 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 ACPI timer looks BAD min = 2, max = 5, width = 3 Timecounter ACPI-safe frequency 3579545 Hz AcpiOsDerivePciId: bus 0 dev 0 func 0 ACPI-1287: *** Error: Method execution failed [\\_SB_.NRTH.SBRG.PS2M._STA] (Node 0xc1bbb9a0), AE_AML_REGION_LIMIT ACPI-0175: *** Error: Method execution failed [\\_SB_.NRTH.SBRG.PS2M._STA] (Node 0xc1bbb9a0), AE_AML_REGION_LIMIT acpi_timer0: 24-bit timer at 3.579545MHz port 0x408-0x40b on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu0: CPU port 0x530-0x537 on acpi0 mss_probe: no address given, try 0x530 mss_detect, busy still set (0xff) acpi_cpu1: CPU port 0x530-0x537 on acpi0 pcib0: ACPI Host-PCI bridge port 0x440-0x44f,0x400-0x43f,0xcf8-0xcff on acpi0 initial configuration before setting priority for links before fixup boot-disabled links - after fixup boot-disabled links -- arbitrated configuration - pci0: ACPI PCI bus on pcib0 pci0: physical bus=0 map[10]: type 3, range 32, base e800, size 26, enabled found- vendor=0x8086, dev=0x7190, revid=0x02 bus=0, slot=0, func=0 class=06-00-00, hdrtype=0x00, mfdev=0 cmdreg=0x0106, statreg=0x2210, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) found- vendor=0x8086, dev=0x7191, revid=0x02 bus=0, slot=1, func=0 class=06-04-00, hdrtype=0x01, mfdev=0 cmdreg=0x011f, statreg=0x0220, cachelnsz=0 (dwords) lattimer=0x40 (1920 ns), mingnt=0x88 (34000 ns), maxlat=0x00 (0 ns) found- vendor=0x8086, dev=0x7110, revid=0x02 bus=0, slot=7, func=0 class=06-01-00, hdrtype=0x00, mfdev=1 cmdreg=0x010f, statreg=0x0280, cachelnsz=0 (dwords) lattimer=0x00 (0 ns), mingnt=0x00 (0 ns), maxlat=0x00 (0 ns) map[20]: type 4, range 32, base
Re: TESTERS WANTED for ATAng preview 2
+---[ Soeren Schmidt ]-- | | The story continues with Preview 2 - from the README: | | Now the functionality is almost equal to that of stock ATA, I'm getting | close to being ready to expose this on the -current users, so please | give this a go to shake out the last nasties. | I've fixed alot of minor issue that testers have reported back (thanks!!), | plus a few chipset issued found over the last days. | | Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files | to your src tree, remove the contents of sys/dev/ata and extract the | ATAng-*tgz file there, then do the usual drill to get a new kernel... | | As usual it might kill your dog, abduct your kids and whatnot :) | | Let me know how this works out for you! linking kernel ata-all.o: In function `ata_identify_devices': ata-all.o(.text+0x107e): undefined reference to `ad_attach' ata-all.o(.text+0x1116): undefined reference to `ad_attach' I'm guessing this is because I have; device ata #device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives I guess it wants atadisk enabled in the kernel config (trying now). This config works with ata-old-gen though. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 2
It seems Andrew Kenneth Milton wrote: linking kernel ata-all.o: In function `ata_identify_devices': ata-all.o(.text+0x107e): undefined reference to `ad_attach' ata-all.o(.text+0x1116): undefined reference to `ad_attach' I'm guessing this is because I have; device ata #device atadisk # ATA disk drives device atapicd # ATAPI CDROM drives #device atapifd # ATAPI floppy drives #device atapist # ATAPI tape drives I guess it wants atadisk enabled in the kernel config (trying now). This config works with ata-old-gen though. I've fixed this locally, thanks for pointing it out! -Søren ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: TESTERS WANTED for ATAng preview 2
+---[ Andrew Kenneth Milton ]-- | +---[ Soeren Schmidt ]-- | | | | The story continues with Preview 2 - from the README: | | | | Now the functionality is almost equal to that of stock ATA, I'm getting | | close to being ready to expose this on the -current users, so please | | give this a go to shake out the last nasties. | | I've fixed alot of minor issue that testers have reported back (thanks!!), | | plus a few chipset issued found over the last days. | | | | Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files | | to your src tree, remove the contents of sys/dev/ata and extract the | | ATAng-*tgz file there, then do the usual drill to get a new kernel... | | | | As usual it might kill your dog, abduct your kids and whatnot :) | | | | Let me know how this works out for you! Adding atadisk fixed the linking problem. I'm now getting millions of these; ata1: spurious interrupt - status=0xff error=0xff reason=0xff ata1 is disabled in the BIOS. -- Totally Holistic Enterprises Internet| | Andrew Milton The Internet (Aust) Pty Ltd | M:+61 416 022 411 | ACN: 082 081 472 ABN: 83 082 081 472 |[EMAIL PROTECTED]| Carpe Daemon ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: LOR tcp_input.c vs. tcp_usrreq.c (was: Re: 2 LORs on my NFSserver.)
On 16 Aug, Tilman Linneweh wrote: * Tilman Linneweh [Fr, 15 Aug 2003 at 16:17 GMT]: My CURRENT is already a bit old: # uname -a FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sun Jul 20 01:00:14 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/CURRENT/sys/POLLY i386 I updated my CURRENT to polly# uname -a FreeBSD polly.arved.de 5.1-CURRENT FreeBSD 5.1-CURRENT #1: Sat Aug 16 10:11:52 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/source/CURRENT/sys/POLLY i386 and this LOR is reproducable. This happend while the machine was NFS-serving around 3 clients with normal udp NFS and a fourth. client tried to mount something via mount_nfs -T -a 2 The problem is the client with TCP mounts. I tried this time with a single NetBSD client that does a TCP mount and cd'd to the mounted directory. lock order reversal 1st 0xc1a17278 inp (inp) @ /usr/source/CURRENT/sys/netinet/tcp_input.c:654 2nd 0xc046bd6c tcp (tcp) @ /usr/source/CURRENT/sys/netinet/tcp_usrreq.c:621 Stack backtrace: backtrace(1,0,,c0445068,c04451d0) at backtrace+0x12 witness_lock(c046bd6c,8,c03c334c,26d,0) at witness_lock+0x55e _mtx_lock_flags(c046bd6c,0,c03c334c,26d) at _mtx_lock_flags+0x7d tcp_usr_rcvd(c1ce8800,80) at tcp_usr_rcvd+0x1b soreceive(c1ce8800,c891ab1c,c891ab28,c891ab20,0) at soreceive+0x815 nfsrv_rcv(c1ce8800,c1a70780,4) at nfsrv_rcv+0x75 sowakeup(c1ce8800,c1ce884c) at sowakeup+0x7f tcp_input(c0b9ac00,14) at tcp_input+0x11f6 ip_input(c0b9ac00) at ip_input+0x7c8 swi_net(0) at swi_net+0xe6 ithread_loop(c0b87180,c891ad48,c0b87180,c0221660,0) at ithread_loop+0x11c fork_exit(c0221660,c0b87180,c891ad48) at fork_exit+0xab fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xc891ad7c, ebp = 0 --- Debugger(witness_lock) Stopped at Debugger+0x45: xchgl %ebx,in_Debugger.0 This is a known issue. -- Forwarded message -- From: Don Lewis [EMAIL PROTECTED] Subject: Re: LOR in NFS server Date: Thu, 24 Apr 2003 21:20:56 -0700 (PDT) To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] On 24 Apr, Gordon Tetlow wrote: I generated it while running nessus against my local machine. lock order reversal 1st 0xc9384c44 inp (inp) @ /local/usr.src/sys/netinet/tcp_input.c:649 2nd 0xc05aa84c tcp (tcp) @ /local/usr.src/sys/netinet/tcp_usrreq.c:621 Stack backtrace: backtrace(c04e9f03,c05aa84c,c04f0770,c04f0770,c04f1ae4) at backtrace+0x17 witness_lock(c05aa84c,8,c04f1ae4,26d,0) at witness_lock+0x692 _mtx_lock_flags(c05aa84c,0,c04f1ae4,26d,0) at _mtx_lock_flags+0xb2 tcp_usr_rcvd(c8a63800,80,c04ea514,df0e9a9c,3b9aca00) at tcp_usr_rcvd+0x30 soreceive(c8a63800,df0e9ad8,df0e9ae4,df0e9adc,0) at soreceive+0x86a nfsrv_rcv(c8a63800,c6d4fb00,4,34,10430) at nfsrv_rcv+0x8a sowakeup(c8a63800,c8a6384c,c04f11d5,434,108) at sowakeup+0x97 tcp_input(c21f5400,14,c0304f91,df0e9c5c,c02f60ba) at tcp_input+0x1341 ip_input(c21f5400,0,c04efede,e9,c21bd280) at ip_input+0x7b0 swi_net(0,0,c04e4eed,217,c21c73c0) at swi_net+0x111 ithread_loop(c21c6100,df0e9d48,c04e4d5d,314,c21c8d10) at ithread_loop+0x16c fork_exit(c02ec2d0,c21c6100,df0e9d48) at fork_exit+0xc0 fork_trampoline() at fork_trampoline+0x1a --- trap 0x1, eip = 0, esp = 0xdf0e9d7c, ebp = 0 --- Hmn ... does NFS over TCP even work with a -current box as the server? It looks like tcp_input() has grabbed the locks in tcbinfo and inp, and then tcp_usr_rcvd() attempts to grab the same locks. I can think of three possible ways of fixing this problem. 1) Drop the locks in tcp_input() before calling sorwakeup() and grab them again if necessary. One has to be careful not to break anything by doing this. This also adds overhead for non-NFS traffic. 2) Never call soreceive() from nfsrv_rcv(), always wake nfsd instead. This has the advantage of minimizing the amount of time that the locks are held, but increases overhead under lightly loaded conditions. 3) Somehow tell tcp_usr_rcvd() not to attempt to grab the locks in this specific case. -- End forwarded message -- -- Forwarded message -- From: Jeffrey Hsu [EMAIL PROTECTED] Subject: Re: LOR in NFS server Date: Fri, 25 Apr 2003 01:02:56 -0700 To: [EMAIL PROTECTED] Cc: [EMAIL PROTECTED] 1st 0xc9384c44 inp (inp) @ /local/usr.src/sys/netinet/tcp_input.c:649 2nd 0xc05aa84c tcp (tcp) @ /local/usr.src/sys/netinet/tcp_usrreq.c:621 This old nag warning has been there since last year and was first reported by Lars Eggert [EMAIL PROTECTED]. I made up a fix for him at the time which you can find at http://www.freebsd.org/~hsu/hammer.diff. Lars has verified that this eliminates the nag warnings. But, I'm hoping to have a more unified solution to the general sowakeup problem, so have not committed this patch. Jeffrey -- End forwarded message --
an driver / Cisco Aironet 340 stopped working
I've used my Cisco WLAN with Toshiba Portege 3440 couple years but now it's broken. I just upgraded to new Toshiba Tecra M1 and reinstalled FreeBSD there and now I get an0: record length mismatch -- expected 430, got 440 for Rid ff68 errors. I already tried with old laptop with latest kernel and old kernel from Jun 26th but it's also broken there so I cannot say who long this has been broken. Tomppa fwe0: flags=8943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::39ff:fe34:7ff2%fwe0 prefixlen 64 scopeid 0x1 ether 02:00:39:34:7f:f2 ch 1 dma 0 em0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 options=3RXCSUM,TXCSUM inet6 fe80::208:dff:feda:ec61%em0 prefixlen 64 scopeid 0x2 inet 212.226.167.247 netmask 0xfff0 broadcast 212.226.167.255 inet6 2001:670:82:babe:208:dff:feda:ec61 prefixlen 64 tentative autoconf ether 00:08:0d:da:ec:61 media: Ethernet autoselect (100baseTX full-duplex) status: active lo0: flags=8049UP,LOOPBACK,RUNNING,MULTICAST mtu 16384 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x3 inet 127.0.0.1 netmask 0xff00 an0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST mtu 1500 inet6 fe80::240:96ff:fe38:56e7%an0 prefixlen 64 scopeid 0x4 ether 00:40:96:38:56:e7 media: IEEE 802.11 Wireless Ethernet autoselect (DS/11Mbps) status: associated ssid AsOlA 1:AsOlA stationname phb channel 6 authmode OPEN powersavemode CAM powersavesleep 200 wepmode ON weptxkey 1 wepkey 1:128-bit Copyright (c) 1992-2003 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.1-CURRENT #3: Sat Aug 16 20:28:39 EEST 2003 [EMAIL PROTECTED]:/u/F/local/sup/5.0/sys/i386/compile/PHB acpi_alloc_wakeup_handler: unable to allocate wake memory Preloaded elf kernel /boot/kernel/kernel at 0xc065. Preloaded elf module /boot/kernel/splash_bmp.ko at 0xc06502e4. Preloaded elf module /boot/kernel/vesa.ko at 0xc0650394. Preloaded splash_image_data /boot/splash.bmp at 0xc0650440. Preloaded elf module /boot/kernel/usb.ko at 0xc0650490. Preloaded elf module /boot/kernel/ukbd.ko at 0xc0650538. Preloaded elf module /boot/kernel/ums.ko at 0xc06505e4. Preloaded elf module /boot/kernel/umass.ko at 0xc065068c. Preloaded elf module /boot/kernel/random.ko at 0xc0650738. Calibrating clock(s) ... i8254 clock: 1193183 Hz Timecounter i8254 frequency 1193183 Hz quality 0 Calibrating TSC clock ... TSC clock: 1396507980 Hz CPU: Intel(R) Pentium(R) M processor 1400MHz (1396.51-MHz 686-class CPU) Origin = GenuineIntel Id = 0x695 Stepping = 5 Features=0xa7e9f9bfFPU,VME,DE,PSE,TSC,MSR,MCE,CX8,SEP,MTRR,PGE,MCA,CMOV,PAT,CLFLUSH,DTS,ACPI,MMX,FXSR,SSE,SSE2,TM,PBE real memory = 536674304 (511 MB) Physical memory chunk(s): 0x1000 - 0x0009efff, 647168 bytes (158 pages) 0x00677000 - 0x1f692fff, 520208384 bytes (127004 pages) avail memory = 513142784 (489 MB) bios32: Found BIOS32 Service Directory header at 0xc00f0240 bios32: Entry = 0xfc0e3 (c00fc0e3) Rev = 0 Len = 1 pcibios: PCI BIOS entry at 0xf+0xd641 pnpbios: Found PnP BIOS data at 0xc00f0450 pnpbios: Entry = f:9138 Rev = 1.0 pnpbios: Event flag at 510 pnpbios: OEM ID 8938f351 Other BIOS signatures found: wlan: 802.11 Link Layer null: null device, zero device mem: memory I/O Pentium Pro MTRR support enabled VESA: information block 56 45 53 41 00 02 00 01 00 01 01 00 00 00 40 00 00 01 00 02 00 02 13 01 00 01 2d 01 00 01 38 01 00 01 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 VESA: 31 mode(s) found VESA: v2.0, 32768k memory, flags:0x1, mode table:0xc053aca0 (140) VESA: Trident CYBER 2100 VESA: TRIDENT MICROSYSTEMS INC. CYBER 2100 RXT 7.3 (16.28) random: entropy source splash: [EMAIL PROTECTED], size:787506 splash_bmp: beyond screen capacity (1024x768, 255 colors) splash_bmp: beyond screen capacity (1024x768, 255 colors) bmp_start(): splash_mode:261 splash: image decoder found: splash_bmp acpi0: TOSHIB 750 on motherboard pci_open(1):mode 1 addr port (0x0cf8) is 0x pci_open(1a): mode1res=0x8000 (0x8000) pci_cfgcheck: device 0 [class=06] [hdr=00] is there (id=33408086) pcibios: BIOS version 2.10 Using $PIR table, 8 entries at 0xc00f01a0 PCI-Only Interrupts: none Location Bus Device Pin Link IRQs embedded0 31A 0x62 11 embedded0 31B 0x61 11 embedded0 29A 0x60 11 embedded0 29B 0x63 11 embedded0 29C 0x62 11 embedded0 29D 0x6b 11 embedded2 11A 0x60 11 embedded2 11B 0x63 11 embedded10A 0x6a 11 embedded2 10A 0x63 11 embedded2 10B 0x60 11 embedded2 13A 0x60 11
Sleeping on objtrm with the following non-sleepable locks held:
I got this overnight on one of the alpha machines: Sleeping on objtrm with the following non-sleepable locks held: exclusive sleep mutex system map r = 0 (0xfc0007dd2098) locked @ /a/asami/portbuild/alpha/src-client/sys/vm/vm_map.c:2228 witness_warn Stopped at Debugger+0x38: zapnot v0,#0xf,v0 v0=0x0 db trace Debugger() at Debugger+0x38 witness_warn() at witness_warn+0x284 msleep() at msleep+0xa8 vm_object_pip_wait() at vm_object_pip_wait+0x88 vm_object_terminate() at vm_object_terminate+0x54 vm_object_deallocate() at vm_object_deallocate+0x408 vm_map_entry_delete() at vm_map_entry_delete+0x54 vm_map_delete() at vm_map_delete+0x3dc vm_map_remove() at vm_map_remove+0x64 kmem_free() at kmem_free+0x34 pipe_free_kmem() at pipe_free_kmem+0xdc pipeclose() at pipeclose+0x278 pipe_close() at pipe_close+0x40 fdrop_locked() at fdrop_locked+0x184 fdrop() at fdrop+0x50 closef() at closef+0x260 close() at close+0x1e0 syscall() at syscall+0x33c XentSys() at XentSys+0x64 --- syscall (6, FreeBSD ELF64, close) --- --- user mode --- db Is this already fixed? Kris pgp0.pgp Description: PGP signature
when should 5.x be stable enough for web servers
On i386 hardware and two processors amd mp. should I wait for 5.2. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
when should 5.2 be released
just asking :) ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: when should 5.x be stable enough for web servers
On Saturday 16 August 2003 18:10, Eriq Lamar wrote: On i386 hardware and two processors amd mp. should I wait for 5.2. You should probably wait until a release is tagged RELENG_5, indicating that it's considered stable. -- brandon s. allbery [linux,solaris,freebsd,perl] [EMAIL PROTECTED] system administrator [WAY too many hats][EMAIL PROTECTED] electrical and computer engineering, carnegie mellon univ. KF8NH URGENT! E-xpedient nuked APK subdomains; kf8nh.apk.net is DEAD. Sorry. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Sleeping on objtrm with the following non-sleepable locksheld:
On Sat, Aug 16, 2003 at 05:14:41PM -0500, Alan L. Cox wrote: Yes. In the following commit, ... Great, I'll update the kernels. Kris pgp0.pgp Description: PGP signature
Re: TESTERS WANTED for ATAng preview 2
On Sat, Aug 16, 2003 at 10:06:02PM +0200, Soeren Schmidt wrote: The story continues with Preview 2 - from the README: Now the functionality is almost equal to that of stock ATA, I'm getting close to being ready to expose this on the -current users, so please give this a go to shake out the last nasties. I've fixed alot of minor issue that testers have reported back (thanks!!), plus a few chipset issued found over the last days. Grap the latest from ftp.deepcore.dk/pub/ATAng and apply the diff files to your src tree, remove the contents of sys/dev/ata and extract the ATAng-*tgz file there, then do the usual drill to get a new kernel... As usual it might kill your dog, abduct your kids and whatnot :) Let me know how this works out for you! My Sun Ultra5 won't panic's with this patched in. ... Timecounters tick every 10.000 msec ata3: spurious interrupt - status=0x00 error=0x04 reason=0x01 ata3: spurious interrupt - status=0x00 error=0x04 reason=0x01 ata3: spurious interrupt - status=0x00 error=0x04 reason=0x01 ata3: spurious interrupt - status=0x00 error=0x04 reason=0x01 ata3: spurious interrupt - status=0x00 error=0x04 reason=0x01 panic: trap: division by zero cpuid = 0; Debugger(panic) Stopped at Debugger+0x1c: ta %xcc, 1 db where panic() at panic+0x174 trap() at trap+0x340 -- division by zero %o7=0xc00874f8 ad_print at ad_print+0x164 ad_attach() at ad_attach+0x370 ata_boot_attach() at ata_boot_attach+0x34 run_interrupt_driven_config_hooks() at run_interrupt_driven_config_hooks+0x20 mi_startup() at mi_startup+0x12c btext() at btext+0x34 Attached is the dmesg from a unpatched kernel. Copyright (c) 1992-2003 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.1-CURRENT #6: Sat Aug 16 21:51:06 CEST 2003 [EMAIL PROTECTED]:/usr/obj/usr/src/sys/SPARC64 Preloaded elf kernel /boot/kernel.ok/kernel at 0xc0352000. Timecounter tick frequency 4 Hz quality 0 real memory = 536870912 (512 MB) avail memory = 514727936 (490 MB) cpu0: Sun Microsystems UltraSparc-IIi Processor (400.00 MHz CPU) nexus0: OpenFirmware Nexus device pcib0: U2P UPA-PCI bridge on nexus0 pcib0: Sabre, impl 0, version 0, ign 0x7c0, bus A DVMA map: 0xc000 to 0xc3ff pci0: OFW PCI bus on pcib0 pcib1: APB PCI-PCI bridge at device 1.1 on pci0 pci1: OFW PCI bus on pcib1 ebus0: revision 0x01 ebus0: PCI-EBus2 bridge mem 0xf100-0xf17f,0xf000-0xf0ff at device 1.0 on pci1 ebus0: auxio addr 0x140072f000-0x140072f003,0x140072c000-0x140072c003,0x140072a000-0x140072a003,0x1400728000-0x1400728003,0x1400726000-0x1400726003 (no driver attached) ebus0: power addr 0x1400724000-0x1400724003 irq 37 (no driver attached) ebus0: SUNW,pll addr 0x1400504000-0x1400504002 (no driver attached) ebus0: se addr 0x140040-0x140040007f irq 43 (no driver attached) ebus0: su addr 0x14003083f8-0x14003083ff irq 41 (no driver attached) ebus0: su addr 0x14003062f8-0x14003062ff irq 42 (no driver attached) ebus0: ecpp addr 0x140070-0x14007f,0x140030015c-0x140030015d,0x14003043bc-0x14003043cb irq 34 (no driver attached) ebus0: fdthree addr 0x140072-0x1400720003,0x1400706000-0x140070600f,0x14003023f0-0x14003023f7 irq 39 (no driver attached) eeprom0: EBus EEPROM/clock addr 0x14-0x141fff on ebus0 eeprom0: model mk48t59 eeprom0: hostid 80f92d5a ebus0: flashprom addr 0x10-0x1f (no driver attached) ebus0: SUNW,CS4231 addr 0x1400722000-0x1400722003,0x1400704000-0x140070400f,0x1400702000-0x140070200f,0x140020-0x14002000ff irq 36,35 (no driver attached) hme0: Sun HME 10/100 Ethernet mem 0xe000-0xe0007fff at device 1.1 on pci1 hme0: Ethernet address: 08:00:20:f9:2d:5a miibus0: MII bus on hme0 nsphy0: DP83840 10/100 media interface on miibus0 nsphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto pci1: display, VGA at device 2.0 (no driver attached) atapci0: CMD 646 WDMA2 controller port 0xc00020-0xc0002f,0xc00018-0xc0001b,0xc00010-0xc00017,0xc8-0xcb,0xc0-0xc7 at device 3.0 on pci1 ata2: at 0xc0 on atapci0 ata3: at 0xc00010 on atapci0 pcib2: APB PCI-PCI bridge at device 1.0 on pci0 pci2: OFW PCI bus on pcib2 ahc0: Adaptec 3960D Ultra160 SCSI adapter port 0x400-0x4ff mem 0x2000-0x2fff at device 1.0 on pci2 aic7899: Ultra160 Wide Channel A, SCSI Id=7, 32/253 SCBs ahc1: Adaptec 3960D Ultra160 SCSI adapter port 0x800-0x8ff mem 0x4000-0x4fff at device 1.1 on pci2 aic7899: Ultra160 Wide Channel B, SCSI Id=7, 32/253 SCBs Timecounters tick every 10.000 msec ad0: 8693MB ST39111A [17662/16/63] at ata2-master WDMA2 acd0: CDROM CRD-8322B at ata3-master PIO4 Waiting 15 seconds for SCSI devices to settle Mounting root from ufs:/dev/ad0a ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: when should 5.x be stable enough for web servers
On Sat, Aug 16, 2003 at 06:10:38PM -0400, Eriq Lamar wrote: On i386 hardware and two processors amd mp. should I wait for 5.2. (*shrug*) some people are already using it. It is very stable for most people now, but if you run into a bug, it is probably a show-stopper type. If you have multiple web servers, it would be nice to try 5.1-CURRENT and report how you find it compairs to 4.x. ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: when should 5.2 be released
On Sat, Aug 16, 2003 at 06:15:26PM -0400, Eriq Lamar wrote: just asking :) See the website. Kris pgp0.pgp Description: PGP signature
Re: an driver / Cisco Aironet 340 stopped working
Tomi Vainio - Sun Finland [EMAIL PROTECTED] probably said: I've used my Cisco WLAN with Toshiba Portege 3440 couple years but now it's broken. I just upgraded to new Toshiba Tecra M1 and reinstalled FreeBSD there and now I get an0: record length mismatch -- expected 430, got 440 for Rid ff68 errors. I already tried with old laptop with latest kernel and old kernel from Jun 26th but it's also broken there so I cannot say who long this has been broken. Have you got recent firmware on the cisco card ? The newer windows driver will helpfully upgrade it for you silently. If it has upgraded, downgrade it. The freebsd driver doesn't yet work with the new firmware. Cisco have changed the operation of the card with newer firmware and havn't released docs on working with the newer firmware. P. -- pir[EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to [EMAIL PROTECTED]
