RE: 5-Stable (5.4) any ipnat changes?
I have the same problem: After I cvsuped my system from 5.3 to 5.4, ipfilter (compiled in the my custom kernel) & ipnat not start automatically. If I do "/etc/rc.d/ipfilter start && /etc/rc.d/ipnat start" manually - all works fine... Lines "ipfilner_enable=YES" and "ipnat_enable=YES" present in the /etc/rc.conf. ~>-Original Message- ~>From: [EMAIL PROTECTED] ~>[mailto:[EMAIL PROTECTED] On Behalf Of Billy Newsom ~>Sent: Thursday, May 26, 2005 1:54 AM ~>To: freebsd-stable@freebsd.org ~>Subject: 5-Stable (5.4) any ipnat changes? ~> ~> ~>Is there some reason why ipnat wouldn't automatically startup? ~> ~>I just upgraded from a 5-stable in February to a 5-stable in ~>May, so I ~>could essentially get 5.4 on this firewall machine. I simultaneously ~>was upgrading some ports, etc., but nothing too severe. When ~>I rebooted ~>the machine, everything looked fine. No problems whatsoever. ~> This was ~>the first time that I compiled multiple kernels (normally I ~>just compile ~>a custom and not the generic), but that is not related. ~> ~>What happened is that I had a strange problem receiving mail ~>on the mail ~>server. It took me quite a while to finally track down the ~>problem. I ~>ended up running a packet sniffer and still couldn't figure it out. ~>Well, it turned out that the filters in ipnat weren't ~>installed, and so ~>all of the NAT routing wasn't happening as normal. ~> ~>I have really never seen this server boot without NAT -- it's ~>basically ~>the same setup I've used for years and it never dawned on me ~>what would ~>happen if ipnat failed to run its filters. Meanwhile, ~>IPFilter was busy ~>running the firewall like normal. ~> ~>I have looked at the logs in detail and I can't find anything ~>that would ~>have turned off ipnat or caused it not to run its filter. ~>Nor, on the ~>otherhand, do I see where ipnat logs anything, anyway. ~> ~>Where would I look to track this down? Is it possible that ~>something in ~> stable messed this up? ~> ~> ~># ls -l /etc/ipnat.rules ~>-rw-r--r-- 1 root wheel 437 Mar 14 14:18 /etc/ipnat.rules ~> ~>Notice no changes since March in that file. ~> ~># cat /etc/rc.conf | grep ip ~>ipfilter_enable="YES" # Set to YES to enable ipfilter ~>functionality ~>ipfilter_program="/sbin/ipf"# where the ipfilter program lives ~>ipfilter_rules="/etc/ipf.rules" # rules definition file for ~>ipfilter, see ~> # ~>/usr/src/contrib/ipfilter/rules for ~>examples ~>ipfilter_flags="" # additional flags for ipfilter ~>ipnat_enable="YES" # Set to YES to enable ipnat ~>functionality ~>ipnat_program="/sbin/ipnat" # where the ipnat program lives ~>ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat ~>ipnat_flags="" # additional flags for ipnat ~>ipmon_enable="YES"# Set to YES for ipmon; ~>needs ipfilter ~>or ipnat ~>ipmon_program="/sbin/ipmon" # where the ipfilter ~>monitor program lives ~>ipmon_flags="-Ds" # typically "-Ds" or "-D ~>/var/log/ipflog" ~>ipfs_enable="YES" # Set to YES to enable saving ~>and restoring ~>ipfs_program="/sbin/ipfs" # where the ipfs program lives ~>ipfs_flags="" # additional flags for ipfs ~> ~>Thanks. ~>Billy ~>___ ~>freebsd-stable@freebsd.org mailing list ~>http://lists.freebsd.org/mailman/listinfo/freebsd-stable ~>To unsubscribe, send any mail to ~>"[EMAIL PROTECTED]" ~> ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
RE: SSHD timeout
Here are the ping results: ping statistics for 192.168.1.100: Packets : sent = 4, recieved = 4, lost = 0 <0% loss>, Approimant round trip time in mili-seconds: Min = 1ms, max = 2ms average= 1ms It's pingable at least Matt ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: problems with nfs+TCP - Resource temporarily unavailable
Oliver Lehmann wrote: Hi Mohan, Mohan Srinivasan wrote: Is this consistently reproducible ? it is - everytime I tried reproducing this with this morning's current, it also happens with STABLE How big was your file that you tried to dd ? I need to reproduce this here in order to track it down. dd if=/dev/urandom of=/usr/tmp.data bs=512k count=200 Also, can you try the test without using the soft mount option ? I don't see soft causing this, but just to eliminate those code paths. I removed soft and bb, but still the same results: [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/temp bs=32k dd: /mnt/files/temp: Resource temporarily unavailable 1797+0 records in 1796+0 records out 58851328 bytes transferred in 33.651500 secs (1748847 bytes/sec) ## I tried the same with an other nfs server (using dill as nfs server this time - system description is in my 1st mail, same mount options like / mnt/files). And guess what? dill rebooted immediate... dd came never back, gave no output Just for a data point here - I have a 5.3-STABLE (from about January 15th) that is serving up data via NFS (tcp and udp, FreeBSD, Linux, Solaris clients) to about 1000 clients. The server is constantly getting pounded. I haven't seen any issues like this on this machine. I'm about to bring up a 5.4R box that will be in the same environment. If I have any issues, I'll make sure to note them here. Eric -- Eric AndersonSr. Systems AdministratorCentaur Technology A lost ounce of gold may be found, a lost moment of time never. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? Before restoring my 5.4 dumps after testing -current, I installed fedora3 linux just to verify it isn't somehow the hardware itself. Ok, plain installation from CDs, kernel "2.6.9-1.667smp" (default installation kernel). There was absolutely zero noticable lag or any effect on response time on X11 while untarring the same firefox source. So there really seems to be something foul in FreeBSD in that regard. And now for the dumps.. *sigh*. mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make kernel error
On May 25, 2005, at 5:22 PM, Kris Kennaway wrote: On Wed, May 25, 2005 at 05:16:02PM -0400, steve Rieger wrote: usr/src/sys/dev/advansys/advansys.c: In function `adv_action': /usr/src/sys/dev/advansys/advansys.c:260: warning: cast from pointer to integer of different size *** Error code 1 Stop in /usr/obj/usr/src/sys/tbwa-custom-smp. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. can you give me some pointers What size? :) Kris these are the last lines prior to the error NOTE cvsup'd src, and built world prior to make kernel. have smp and PAE option in the custom config. and made sure that scbus is not commented out. Subject:error Date: May 25, 2005 5:38:22 PM EDT From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] 00 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/aac/aac.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/aac/aac_debug.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/aac/aac_disk.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/aac/aac_pci.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/aac/aac_cam.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -include opt_global.h -fno-common -finline-limit=8000 --param inline-unit-growth=100 --param large-function-growth=1000 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-mmx -mno-3dnow -mno-sse -mno-sse2 -ffreestanding -Werror /usr/src/sys/dev/advansys/adv_eisa.c cc -c -O -pipe -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -fformat-extensions -std=c99 -nostdinc -I- -I. -I/usr/src/sys -I/usr/src/sys/contrib/dev/acpica -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/ipfilter -I/usr/src/sys/contrib/pf -I/usr/src/sys/contrib/dev/ath -I/usr/src/sys/contrib/dev/ath/freebsd -I/usr/src/sys/contrib/ngatm -D_KERNEL -i
Re: problems with nfs+TCP - Resource temporarily unavailable
Oliver Lehmann wrote: > So.. using i386 as an tcp nfs-server - the only thing which happens is > that dd gets interruped, using alpha as an tcp nfs-server makes the alpha > panic. Ok, maybe the alpha has other problems... Disk worked for 7 years without problems but I just rebooted the system once more and now I'm getting several SCSI CAM messages (da0:sym0:0:0:0): Retrying Command (per Sense Data) (da0:sym0:0:0:0): READ(10). CDB: 28 0 0 57 72 80 0 0 20 0 (da0:sym0:0:0:0): CAM Status: SCSI Status Error (da0:sym0:0:0:0): SCSI Status: Check Condition (da0:sym0:0:0:0): MEDIUM ERROR info:577280 asc:11,0 (da0:sym0:0:0:0): Unrecovered read error field replaceable unit: e4 actual retry count: 257 So - it looks like I need a new disk... damn so drop that alpha problem for now -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Panic in 5.3 RELEASE
Hi, using the "user" keyword in pf rules the system panics. I found this in the errata page: (31 Oct 2004) When the user/group rule clauses in pf(4) and ipfw(4) are used, the loader tunable debug.mpsafenet must be set to 0 (this is 1 by default). I have mpsafenet disabled so i assume that this should work and this is an unknown issue. Here is the panic: Fatal trap 12: page fault while in kernel mode fault virtual address = 0x128 fault code = supervisor read, page not present instruction pointer = 0x8:0xc043f170 stack pointer = 0x10:0xd828caa4 frame pointer = 0x10:0xd828cad0 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 = 27 (swi1: net) [thread 100021] Stopped at 0xc043f170 = pf_socket_lookup+0x2a4:movl0x128(%eax),%eax db> where pf_socket_lookup(d828cb28,d828cb2c,1,d828cbe4,0) at 0xc043f170 = pf_socket_look4 pf_test_tcp(d828cb94,d828cb8c,1,c1932500,c192eb00) at 0xc043fa05 = pf_test_tcp+9 pf_test(1,c185f400,d828cc80,0,c1ac3000) at 0xc0446907 = pf_test+0x437 pf_check_in(0,d828cc80,c185f400,1,0) at 0xc044f9b1 = pf_check_in+0x35 pfil_run_hooks(c069e240,d828,c185f400,1,0) at 0xc053daef = pfil_run_hooks+03 ip_input(c192eb00) at 0xc05517a8 = ip_input+0x240 netisr_processqueue(c069bf18) at 0xc053d7bb = netisr_processqueue+0x9f swi_net(0) at 0xc053d96a = swi_net+0xa6 ithread_loop(c17a0580,d828cd48) at 0xc04bd1d9 = ithread_loop+0x155 fork_exit(c04bd084,c17a0580,d828cd48) at 0xc04bc359 = fork_exit+0x75 fork_trampoline() at 0xc060c8dc = fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xd828cd7c, ebp = 0 --- If you need something more feel free to ask. -- La prueba mas fehaciente de que existe vida inteligente en otros planetas, es que no han intentado contactar con nosotros. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 04:02:58PM -0700, Jon Dama wrote: > It's different, yes. But the trouble is that you need a controlled > interrupt source--i.e., you have to have some concept of when an "event" > might have been handled (were it not for such and such activity). > > I posit that without that counterfactual talking about PREEMPTION is > meaningless. > > The technique I mentioned--measuring and comparing the jitter was intended > to quash measuring the performance of the network stack itself. > > Do you have an idea how you can pose that counterfactual in a synthetic > arrangement more closely connected with the problem at hand? Nope..that's why I said it was a hard thing to study. Well-controlled benchmarking of FreeBSD is always welcome, so please feel free to proceed with your tests and let us know of anything interesting you identify. Kris pgpN9gRvgk7Mp.pgp Description: PGP signature
Re: jdk1.4.2 endless loop and kernel panic in thr_suspend()
On Wed, May 25, 2005 at 04:00:22PM -0700, Robert Faulds wrote: > Tomcat5.0.30 > libthr.so.1 via /etc/libmap.conf libthr is experimental and unmaintained..it was removed in 6.0 (well, replaced by David Xu's threading library). Try using the standard library instead. Kris pgpEJL2E0p45X.pgp Description: PGP signature
Re: problems with nfs+TCP - Resource temporarily unavailable
Hi Mohan, Mohan Srinivasan wrote: > Is this consistently reproducible ? it is - everytime > I tried reproducing this with this morning's > current, it also happens with STABLE > How big was your file that you tried to dd ? I need to reproduce this here > in order to track it down. dd if=/dev/urandom of=/usr/tmp.data bs=512k count=200 > Also, can you try the test without using the soft mount option ? I don't see > soft causing this, but just to eliminate those code paths. I removed soft and bb, but still the same results: [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/temp bs=32k dd: /mnt/files/temp: Resource temporarily unavailable 1797+0 records in 1796+0 records out 58851328 bytes transferred in 33.651500 secs (1748847 bytes/sec) ## I tried the same with an other nfs server (using dill as nfs server this time - system description is in my 1st mail, same mount options like / mnt/files). And guess what? dill rebooted immediate... dd came never back, gave no output dill's dmesg shows me: fatal kernel trap: trap entry = 0x4 (unaligned access fault) faulting va= 0xfc0006b6f44d opcode = 0x28 register = 0x5 pc = 0xfc541e08 ra = 0xfc541df4 sp = 0xfe000a0f9b70 usp= 0x11ffea80 curthread = 0xfc000f91ee10 pid = 343, comm = nfsd panic: trap Uptime: 3d14h15m51s Dumping 253 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete unfortunately... [EMAIL PROTECTED] tmp> kgdb vmcore.1 /usr/obj/alpha-5.4/usr/src/sys/DILL/ kernel.debug kgdb: bad namelist Exit 1 and damn! yes that panic is reproduceable! 2nd try writing on dill: [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/www/temp bs=32k dd: /mnt/www/temp: Resource temporarily unavailable 387+0 records in 386+0 records out 12648448 bytes transferred in 11.766768 secs (1074930 bytes/sec) So.. using i386 as an tcp nfs-server - the only thing which happens is that dd gets interruped, using alpha as an tcp nfs-server makes the alpha panic. And now it looks I should at first unmount the tcp mount, and then let my alpha system come back online ;) (which is of course not possible w/o the nfsd available of course) May 26 00:59:44 dill rpcbind: cannot create socket for udp6 Starting mountd. NFS on reserved port only=YES Starting nfsd. Starting local daemons: fatal kernel trap: trap entry = 0x4 (unaligned access fault) faulting va= 0xfc000f908929 opcode = 0x28 register = 0x5 pc = 0xfc532164 ra = 0xfc532138 sp = 0xfe000a1118c0 usp= 0x11ffea80 curthread = 0xfc000f91f950 pid = 409, comm = nfsd panic: trap Uptime: 8m17s Dumping 253 MB 16 32 48 64 80 96 112 128 144 160 176 192 208 224 240 Dump complete Automatic reboot in 15 seconds - press a key on the console to abort Rebooting... *** keyboard not plugged in... halted CPU 0 halt code = 5 HALT instruction executed PC = fc5bfac0 *** no timer interrupts on CPU 0 *** CPU 0 booting If someone want me to test sth.. let me know Systems available are 6.0/ i386, 6.0/amd64, 5.4-SMP/i386, 5.4/i386, 5.4/alpha, 4.11/i386 -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
It's different, yes. But the trouble is that you need a controlled interrupt source--i.e., you have to have some concept of when an "event" might have been handled (were it not for such and such activity). I posit that without that counterfactual talking about PREEMPTION is meaningless. The technique I mentioned--measuring and comparing the jitter was intended to quash measuring the performance of the network stack itself. Do you have an idea how you can pose that counterfactual in a synthetic arrangement more closely connected with the problem at hand? ... -Jon On Wed, 25 May 2005, Kris Kennaway wrote: > On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote: > > Could this be quantified by setting up a synthetic experiement: > > > > 1) one machine uses dummynet to generate a uniform packet/sec stream > > 2) another machine has a process receiving those packets and recording > >their arrival relative to the local TSC. afaik, the TSC is the only > >source of wall-time that doesn't involve a system call. Is that right? > >Are the TSCs synchronized on SMP systems? > > 3) Generate another source of activity on the receiving machine to > >estimate the effect of PREEMPTION relative to the (lack of) quiescence. > > 4) use the jitter in the TSC deltas to infer the effect of preemption > > That would be attempting to benchmark something entirely different. > > Kris > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 03:33:39PM -0700, Jon Dama wrote: > Could this be quantified by setting up a synthetic experiement: > > 1) one machine uses dummynet to generate a uniform packet/sec stream > 2) another machine has a process receiving those packets and recording >their arrival relative to the local TSC. afaik, the TSC is the only >source of wall-time that doesn't involve a system call. Is that right? >Are the TSCs synchronized on SMP systems? > 3) Generate another source of activity on the receiving machine to >estimate the effect of PREEMPTION relative to the (lack of) quiescence. > 4) use the jitter in the TSC deltas to infer the effect of preemption That would be attempting to benchmark something entirely different. Kris pgpJra1DkqzD7.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Could this be quantified by setting up a synthetic experiement: 1) one machine uses dummynet to generate a uniform packet/sec stream 2) another machine has a process receiving those packets and recording their arrival relative to the local TSC. afaik, the TSC is the only source of wall-time that doesn't involve a system call. Is that right? Are the TSCs synchronized on SMP systems? 3) Generate another source of activity on the receiving machine to estimate the effect of PREEMPTION relative to the (lack of) quiescence. 4) use the jitter in the TSC deltas to infer the effect of preemption -Jon On Thu, 26 May 2005, Bjarne Wichmann Petersen wrote: > On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > > using KDE) it would take 2-3 seconds before the file got highlighted. > > > After disabling PREEMTION again responsetime seems to have improved. > > Are you running 5.4-RELEASE or later? > > Later (5.4-STABLE). > > Hmm... did a little testing. Sometimes I *still* get "long" responsetimes with > PREEMPTION disabled in a seemingly random order. > > Bjarne > ___ > freebsd-stable@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-stable > To unsubscribe, send any mail to "[EMAIL PROTECTED]" > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make kernel error
On Wed, May 25, 2005 at 05:41:49PM -0400, steve Rieger wrote: > > On May 25, 2005, at 5:22 PM, Kris Kennaway wrote: > > >On Wed, May 25, 2005 at 05:16:02PM -0400, steve Rieger wrote: > >>usr/src/sys/dev/advansys/advansys.c: In function `adv_action': > >>/usr/src/sys/dev/advansys/advansys.c:260: warning: cast from pointer > >>to > >>integer of different size > >>*** Error code 1 > >> > >>Stop in /usr/obj/usr/src/sys/tbwa-custom-smp. > >>*** Error code 1 > >> > >>Stop in /usr/src. > >>*** Error code 1 > >> > >>Stop in /usr/src. > >> > >>can you give me some pointers > > > >What size? :) > > > >Kris > > > > these are the last lines prior to the error > NOTE cvsup'd src, and built world prior to make kernel. have smp and > PAE option in the custom config. and made sure that scbus is not > commented out. > /usr/src/sys/dev/advansys/advansys.c > /usr/src/sys/dev/advansys/advansys.c: In function `adv_action': > /usr/src/sys/dev/advansys/advansys.c:260: warning: cast from pointer to > integer of different size > *** Error code 1 This driver may not be compatible with PAE. Is it in the standard PAE config file? Kris pgplpkv7KS4eq.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Thu, May 26, 2005 at 12:14:35AM +0200, Bjarne Wichmann Petersen wrote: > On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > > using KDE) it would take 2-3 seconds before the file got highlighted. > > > After disabling PREEMTION again responsetime seems to have improved. > > Are you running 5.4-RELEASE or later? > > Later (5.4-STABLE). > > Hmm... did a little testing. Sometimes I *still* get "long" responsetimes > with > PREEMPTION disabled in a seemingly random order. This kind of thing is very difficult to diagnose..your system might be busy doing something else, KDE could be at fault, KDE could be swapped out, etc. Kris pgpad5ZTCUnoA.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wednesday 25 May 2005 23:45, Kris Kennaway wrote: > On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > > opposite experience. Eg. when clicking on a file in a fileselector (I'm > > using KDE) it would take 2-3 seconds before the file got highlighted. > > After disabling PREEMTION again responsetime seems to have improved. > Are you running 5.4-RELEASE or later? Later (5.4-STABLE). Hmm... did a little testing. Sometimes I *still* get "long" responsetimes with PREEMPTION disabled in a seemingly random order. Bjarne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
5-Stable (5.4) any ipnat changes?
Is there some reason why ipnat wouldn't automatically startup? I just upgraded from a 5-stable in February to a 5-stable in May, so I could essentially get 5.4 on this firewall machine. I simultaneously was upgrading some ports, etc., but nothing too severe. When I rebooted the machine, everything looked fine. No problems whatsoever. This was the first time that I compiled multiple kernels (normally I just compile a custom and not the generic), but that is not related. What happened is that I had a strange problem receiving mail on the mail server. It took me quite a while to finally track down the problem. I ended up running a packet sniffer and still couldn't figure it out. Well, it turned out that the filters in ipnat weren't installed, and so all of the NAT routing wasn't happening as normal. I have really never seen this server boot without NAT -- it's basically the same setup I've used for years and it never dawned on me what would happen if ipnat failed to run its filters. Meanwhile, IPFilter was busy running the firewall like normal. I have looked at the logs in detail and I can't find anything that would have turned off ipnat or caused it not to run its filter. Nor, on the otherhand, do I see where ipnat logs anything, anyway. Where would I look to track this down? Is it possible that something in stable messed this up? # ls -l /etc/ipnat.rules -rw-r--r-- 1 root wheel 437 Mar 14 14:18 /etc/ipnat.rules Notice no changes since March in that file. # cat /etc/rc.conf | grep ip ipfilter_enable="YES" # Set to YES to enable ipfilter functionality ipfilter_program="/sbin/ipf"# where the ipfilter program lives ipfilter_rules="/etc/ipf.rules" # rules definition file for ipfilter, see # /usr/src/contrib/ipfilter/rules for examples ipfilter_flags="" # additional flags for ipfilter ipnat_enable="YES" # Set to YES to enable ipnat functionality ipnat_program="/sbin/ipnat" # where the ipnat program lives ipnat_rules="/etc/ipnat.rules" # rules definition file for ipnat ipnat_flags="" # additional flags for ipnat ipmon_enable="YES"# Set to YES for ipmon; needs ipfilter or ipnat ipmon_program="/sbin/ipmon" # where the ipfilter monitor program lives ipmon_flags="-Ds" # typically "-Ds" or "-D /var/log/ipflog" ipfs_enable="YES" # Set to YES to enable saving and restoring ipfs_program="/sbin/ipfs" # where the ipfs program lives ipfs_flags="" # additional flags for ipfs Thanks. Billy ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 11:42:01PM +0200, Bjarne Wichmann Petersen wrote: > On Monday 23 May 2005 23:36, Kris Kennaway wrote: > > > Also try defining PREEMPTION in your kernel on 5.x and above (if you > > are running i386 or amd64). There have been very occasional reports > > of panics with this option enabled (although I use it everywhere and > > have not seen problems on my heavily loaded machines), but interactive > > response should be much better. > > I've had PREEMTION enabled in 5-STABLE for at couple of month and had the > opposite experience. Eg. when clicking on a file in a fileselector (I'm using > KDE) it would take 2-3 seconds before the file got highlighted. After > disabling PREEMTION again responsetime seems to have improved. Are you running 5.4-RELEASE or later? Kris pgpxUT9HdCRJe.pgp Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Monday 23 May 2005 23:36, Kris Kennaway wrote: > Also try defining PREEMPTION in your kernel on 5.x and above (if you > are running i386 or amd64). There have been very occasional reports > of panics with this option enabled (although I use it everywhere and > have not seen problems on my heavily loaded machines), but interactive > response should be much better. I've had PREEMTION enabled in 5-STABLE for at couple of month and had the opposite experience. Eg. when clicking on a file in a fileselector (I'm using KDE) it would take 2-3 seconds before the file got highlighted. After disabling PREEMTION again responsetime seems to have improved. Bjarne ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: make kernel error
On Wed, May 25, 2005 at 05:16:02PM -0400, steve Rieger wrote: > usr/src/sys/dev/advansys/advansys.c: In function `adv_action': > /usr/src/sys/dev/advansys/advansys.c:260: warning: cast from pointer to > integer of different size > *** Error code 1 > > Stop in /usr/obj/usr/src/sys/tbwa-custom-smp. > *** Error code 1 > > Stop in /usr/src. > *** Error code 1 > > Stop in /usr/src. > > can you give me some pointers What size? :) Kris pgpaxT1vMyfiI.pgp Description: PGP signature
make kernel error
usr/src/sys/dev/advansys/advansys.c: In function `adv_action': /usr/src/sys/dev/advansys/advansys.c:260: warning: cast from pointer to integer of different size *** Error code 1 Stop in /usr/obj/usr/src/sys/tbwa-custom-smp. *** Error code 1 Stop in /usr/src. *** Error code 1 Stop in /usr/src. can you give me some pointers -- Steve Rieger (212) 804-1131 (Work) (646) 335-8915 (Cell) chozrim (aim) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: releng 5 panic (again)
Mike Tancsa wrote: At 04:03 PM 25/05/2005, Stephen Montgomery-Smith wrote: I will try any reasonable test you guys have for me. Right now I am switching off HTT to see if that is the issue. This is a dual Xeon system. The SCHED_4BSD doesnt do anything with HTT and in fact might hurt performance. If you are using ULE, there are several known bugs and its not recommended that you use it. So in short, turn off HTT in your BIOS on RELENG_5. I am using the 4BSD scheduler, but I am really seeing some advantage with it. When it is switched off, multiply running programs really do seem to run a little slower. But I'll switch off HTT for now. Thanks, Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: releng 5 panic (again)
At 04:03 PM 25/05/2005, Stephen Montgomery-Smith wrote: I will try any reasonable test you guys have for me. Right now I am switching off HTT to see if that is the issue. This is a dual Xeon system. The SCHED_4BSD doesnt do anything with HTT and in fact might hurt performance. If you are using ULE, there are several known bugs and its not recommended that you use it. So in short, turn off HTT in your BIOS on RELENG_5. ---Mike ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
releng 5 panic (again)
Please help me! I know that I am getting few responses to my emails - I am guessing that my situation is difficult. If you could offer any ideas how to help with further diagnostics. I am regularly getting panics with instruction pointer equal to 0xc0611c69. I am not able to get any dumps - the dumpon directive is simply ignored. (I did get one dump (for some reason), but that was with a kernel that was not made with config -g, and new kernels made afterwards seem significantly different, despite having exactly the same size.) The code at this instruction pointer is (kgdb) list *0xc0611c69 0xc0611c69 is in fill_kinfo_thread (../../../kern/kern_proc.c:748). 743 } 744 745 kg = td->td_ksegrp; 746 747 /* things in the KSE GROUP */ 748 kp->ki_estcpu = kg->kg_estcpu; 749 kp->ki_slptime = kg->kg_slptime; 750 kp->ki_pri.pri_user = kg->kg_user_pri; 751 kp->ki_pri.pri_class = kg->kg_pri_class; 752 so I'm guessing that kp is not correct. Because of the consistency of the instruction pointer value from panic to panic, I really am thinking that this is not a hardware issue. I will try any reasonable test you guys have for me. Right now I am switching off HTT to see if that is the issue. This is a dual Xeon system. I am willing to provide a copy of the program that I'm guessing is causing the problem. It is a multithreaded program that is very CPU instensive, although most of the inners of the code are from the fftw3 port. One interesting thing about this program is that when I run it, top says that about 45% CPU is being used (which with 4 logical CPU's means that almost 2 CPU's are being used), but that actual program is registered at running with about 80% CPU time (which I am guessing means 0.8 of one CPU is being used). It seems to me that there is some disparity in the accounting. Maybe it is a problem with the math/fftw3 code. But is still shouldn't causes crashes. Please help me. I am sure that this is a difficult problem, but I just don't know how to provide you any further decent diagnostic information. Thanks, Stephen ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Perhaps it's something SATA-related? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
On Wed, May 25, 2005 at 06:44:37PM +0200, Matthias Buelow wrote: > Kris Kennaway wrote: > > >>interrupt total rate > >>irq1: atkbd0 586 0 > >>irq13: npx01 0 > >>irq14: ata0 94 0 > >>irq17: wi054 0 > >>irq20: fxp0 atapci162079 99 > >>irq21: uhci0 ehci0 1 0 > >>irq22: uhci11102 1 > >>lapic0: timer1246549 1994 > >>lapic1: timer1246427 1994 > >>Total2556893 4091 > >>The only relevant conflict I could see is irc 20; but I had already > >>tested that by removing fxp0 from the kernel. > > > >I wonder if USB is causing the problem all on its own..since that was > >the culprit in other situations when it was being triggered by virtue > >of interrupt sharing. Any chance you can try a non-USB mouse and > >remove USB from your kernel? > > Ok, now USB (both uhci and ehci) is gone. The problem is still the > same. vmstat -i: > > interrupt total rate > irq1: atkbd01324 3 > irq12: psm0 8562 21 > irq13: npx01 0 > irq14: ata0 94 0 > irq17: wi0 381 0 > irq20: fxp0 atapci161956154 > lapic0: timer 801433 1993 > lapic1: timer 801292 1993 > Total1675043 4166 > > To be frank, I do not believe it's got anything to do with locking or > interrupts. It somehow seems just like the scheduler is doing a bad job > of balancing interactive processes vs. disk i/o. I've seen the same > stuff for years on NetBSD (until they changed scheduling around 1.5 or > so) and Linux (until 2.4 kernels). During that time FreeBSD didn't > exhibit these symptoms and only in 5.x have I seen that kind of > behaviour creep back in. Has the classic scheduler been changed > somehow? Maybe I should try and see if the problem persists with the > ULE scheduler? Others don't see this though, and in other cases it was *definitively proven* to be caused by the issue I mentioned. I'll have to think more about what to try next..thanks for running the tests. Kris pgpWStVHX8C2v.pgp Description: PGP signature
problems with nfs+TCP - Resource temporarily unavailable
Hi, I'm getting the following error when dding a big file on an nfs mount which is mounted using TCP. [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Resource temporarily unavailable 639+0 records in 638+0 records out 20905984 bytes transferred in 15.066490 secs (1387582 bytes/sec) Exit 1 [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Resource temporarily unavailable 1035+0 records in 1034+0 records out 33882112 bytes transferred in 14.698220 secs (2305185 bytes/sec) Exit 1 dmesg gives me "nfs send error 35 for server file:/mnt/files" fstab entry on kartoffel and dill: file:/mnt/files /mnt/files nfs tcp,nfsv3,soft,bg,rw,noauto 0 0 - kartoffel is an amd64 system with an onboard re0 running CURRENT from May 24th evening. - dill is an alpha system with an xl0 running 5.4 STABLE from May 20th - file is an i386 SMP system with an xl0 running 5.4 STABLE from May 20th - dill and file are connected directly through an switch - kartoffel and file are connected through an router+switches. - kartoffel and nudel are running rpc.lockd and rpc.statd - dill doesn't run rpc.lockd neither rpc.statd Switching from nfsv3 to a nfsv2 mount is much slower and breaks sooner or later with an error too. It doesn't give me an "error 35" on client side, but an "nfsd send error 32" on server side and a slightly different error message: [EMAIL PROTECTED] olivleh1> dd if=/usr/tmp.data of=/mnt/files/tmp.data bs=32k dd: /mnt/files/tmp.data: Operation timed out 67+0 records in 66+0 records out 2162688 bytes transferred in 6.221855 secs (347595 bytes/sec) Exit 1 Switching from TCP to UDP makes this error gone. Any ideas how to fix this properly? (please CC me, I'm not subscribed to stable@) -- Oliver Lehmann http://www.pofo.de/ http://wishlist.ans-netz.de/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
somehow? Maybe I should try and see if the problem persists with the ULE scheduler? No difference with ULE, with the default parameters: kern.sched.name: ule kern.sched.slice_min: 10 kern.sched.slice_max: 142 kern.sched.preemption: 1 mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
stubborn RT2500 card with new NDIS
Hi,
I've tried the new NDIS interface with a Sweex LC500050 card, which uses
the RaLink RT2500 chipset on FreeBSD 5.4-STABLE #4: Mon May 23 05:35:51
CEST 2005.
I've got it almost running, except that when I run "dhclient ndis0", the
kernel seems to freeze (it won't even respond to closing/opening the lid,
normally it prints "acpi_lid0: Lid {closed|opened}"), no panic/dump/other
interesting stuff.
I've compiled the driver both with and without an additional file
"rt2500.cat", which seems to contain some binary data, but even winedump
can't make anything useful out of it. When converted into
"rt2500.cat.o", that file only contains a single start and end symbol.
Results without the file "rt2500.cat" follow.
dmesg snippet when plugging in the card:
---
[...]
wlan: <802.11 Link Layer>
[...]
ndis0: mem 0x8800-0x88001fff irq 11 at
device 0.0 on cardbus1
ndis0: [MPSAFE]
ndis0: NDIS API version: 5.1
ndis0: bpf attached
ndis0: Ethernet address: 00:50:fc:8c:40:78
ndis0: bpf attached
ndis0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps
ndis0: 11g rates: 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps 36Mbps 48Mbps 54Mbps
Interrupt storm detected on "irq11: cbb0 cbb1+"; throttling interrupt source
[...]
---
Output of "ifconfig ndis0" (SSID protected):
---
ndis0: flags=8843 mtu 1500
inet6 fe80::250:fcff:fe8c:4078%ndis0 prefixlen 64 scopeid 0x3
ether 00:50:fc:8c:40:78
media: IEEE 802.11 Wireless Ethernet autoselect
status: associated
ssid "" 1:""
channel 10 authmode OPEN powersavemode OFF powersavesleep 100
rtsthreshold 2312 protmode CTS
wepmode MIXED weptxkey 1
wepkey 1:104-bit
---
Output of "wicontrol ndis0" (SSID / WEP-key protected):
---
NIC serial number: [ ]
Station name: [ 82-168-79-254-bbxl.xdsl.tiscali.nl ]
SSID for IBSS creation: [ ]
Current netname (SSID): [ ]
Desired netname (SSID): [ ]
Current BSSID: [ 00:00:00:00:00:00 ]
Channel list: [
3fff ]
IBSS channel: [ 65535 ]
Current channel:[ 10 ]
Comms quality/signal/noise: [ 0 0 0 ]
Promiscuous mode: [ Off ]
Intersil-Prism2 based card: [ 1 ]
Port type (1=BSS, 3=ad-hoc):[ 1 ]
MAC address:[ 00:50:fc:8c:40:78 ]
TX rate (selection):[ 0 ]
TX rate (actual speed): [ 54 ]
RTS/CTS handshake threshold:[ 2312 ]
Create IBSS:[ Off ]
Access point density: [ 1 ]
Power Mgmt (1=on, 0=off): [ 0 ]
Max sleep time: [ 100 ]
WEP encryption: [ On ]
TX encryption key: [ 1 ]
Encryption keys:[ ][ ][ ][ ]
---
Did I miss something or is it just plain bad luck?
Kind regards,
Rene
--
"It won't fit on the line."
-- me, 2001
pgpvR1MdzYM9t.pgp
Description: PGP signature
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Kris Kennaway wrote: interrupt total rate irq1: atkbd0 586 0 irq13: npx01 0 irq14: ata0 94 0 irq17: wi054 0 irq20: fxp0 atapci162079 99 irq21: uhci0 ehci0 1 0 irq22: uhci11102 1 lapic0: timer1246549 1994 lapic1: timer1246427 1994 Total2556893 4091 The only relevant conflict I could see is irc 20; but I had already tested that by removing fxp0 from the kernel. I wonder if USB is causing the problem all on its own..since that was the culprit in other situations when it was being triggered by virtue of interrupt sharing. Any chance you can try a non-USB mouse and remove USB from your kernel? Ok, now USB (both uhci and ehci) is gone. The problem is still the same. vmstat -i: interrupt total rate irq1: atkbd01324 3 irq12: psm0 8562 21 irq13: npx01 0 irq14: ata0 94 0 irq17: wi0 381 0 irq20: fxp0 atapci161956154 lapic0: timer 801433 1993 lapic1: timer 801292 1993 Total1675043 4166 To be frank, I do not believe it's got anything to do with locking or interrupts. It somehow seems just like the scheduler is doing a bad job of balancing interactive processes vs. disk i/o. I've seen the same stuff for years on NetBSD (until they changed scheduling around 1.5 or so) and Linux (until 2.4 kernels). During that time FreeBSD didn't exhibit these symptoms and only in 5.x have I seen that kind of behaviour creep back in. Has the classic scheduler been changed somehow? Maybe I should try and see if the problem persists with the ULE scheduler? mkb. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
BKVASIZE for large block-size filesystems
FreeBSD5.4-Stable amd64 on a dual-opteron system with LSI-Megaraid 400G+ partion. The filesystem was created with: newfs -b 65536 -f 8192 -e 15835 /dev/amrd2s1d This is the data filesystem for a PostgreSQL database; as the default page size (files) is 8k, the above newfs scheme has 8k fragments which should fit nicely with the PostgreSQL page size. Now by default param.h defines BKVASIZE as 16384 (which has been pointed out in other posts as being *not* twice the default blocksize of 16k). I have modified it to be set at 32768 but still see a high and increasing value of vfs.bufdefragcnt which makes sense given the blocksize of the major filesystem in use. My question is are there any caveats about increasing BKVASIZE to 65536? The system has 8G of RAM and I understand that nbufs decreases with increasing BKVASIZE; how can I either determine if the resulting nbufs will be sufficient or calculate what is needed based on RAM and system usage? Also, will increasing BKVASIZE require a complete make buildworld or, if not, how can I remake the portions of system affected by BKVASIZE? Sven ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (nbench results)
On Tue, May 24, 2005 at 09:40:20PM +0200, Matthias Buelow wrote: > Bohdan Horst wrote: > > > I have 4 identical PC with FreeBSD (2x4.11R and 2x5.4R) > > Results (/usr/ports/net/benchmarks/nbench): > > What you're benchmarking here is gcc3 vs. gcc2. You could compile nbench on FreeBSD 4.11 with USE_GCC=3.4 of course... Or is gcc34 from ports that much different from FreeBSD 5 base gcc ? I don't think so, so it might be helpful. Marc pgpktjibwKdLL.pgp Description: PGP signature
Re: RELENG_5_4 panic
Filip Lenaerts wrote: > > hi all, > > tnx very much for reply, kris, stefan and thomas. i was also > thinking/fearing for a hardware error. the reason why i didn't > investigate sooner is that over the past two years i was running > 5.0-RC2 and after that followed current. i always assumed that that > could be the reason, but when i reverted a month ago to 5.4-RELEASE > and now RELENG_5_4 aka stable, the problem stayed ... plus my kernel > debugging skills are very limited - hence learned again :) > > so HW failure. now the only thing to do is convince our IT dep that > it is broken and ask a new one. the problem is that they only support > windows and they go frantic when they see linux, let alone BSD :) so > the probably want to put the blame on the OS iso the HW. wish me luck :) > > tnx again guys! > > filip > Get a copy of memtest86 (see http://www.memtest86.com/ for a bootable ISO) - it'sd a stand along memory diagnostic that ahppens to put a reasonable load on the cpu too - with some luck it will show up the problem and they won't be able to blame BSD (plus it's a good tool to have anyway). John ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
Jamie Heckford wrote:
Another one... looks completly different :-(
[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".
#0 doadump () at pcpu.h:160
160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt full
#0 doadump () at pcpu.h:160
No locals.
#1 0xc04fac8a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc04faf50 in panic (fmt=0xc06c06db
"softdep_deallocate_dependencies: dangling deps")
at /usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc357fd80
bootopt = 260
newpanic = 1
ap = 0xc357fd80 "\\\214\215ÃðjOÃ"
buf = "softdep_deallocate_dependencies: dangling deps", '\0'
#3 0xc061cbfe in softdep_deallocate_dependencies (bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:5961
No locals.
#4 0xc053c8f4 in brelse (bp=0xd77932d4) at buf.h:431
No locals.
#5 0xc054bd24 in flushbuflist (blist=0xd77932d4, flags=0,
vp=0xc4bf9630, slpflag=0,
slptimeo=0, errorp=0x0) at /usr/src/sys/kern/vfs_subr.c:1101
bp = (struct buf *) 0xd77932d4
nbp = (struct buf *) 0xd75948f0
found = 1
#6 0xc054b987 in vinvalbuf (vp=0xc4bf9630, flags=0, cred=0x0, td=0x0,
slpflag=0,
slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:987
blist = (struct buf *) 0x0
error = 0
object = 0xc04efc79
#7 0xc054e85c in vclean (vp=0xc4bf9630, flags=8, td=0xc357fd80)
at /usr/src/sys/kern/vfs_subr.c:2479
---Type to continue, or q to quit---
active = 0
#8 0xc054eeb5 in vgonel (vp=0xc4bf9630, td=0xc357fd80)
at /usr/src/sys/kern/vfs_subr.c:2697
No locals.
#9 0xc054a9f2 in vlrureclaim (mp=0xc35b3c00) at pcpu.h:157
vp = (struct vnode *) 0xc4bf9630
done = 0
trigger = 10
usevnodes = 0
count = 7
#10 0xc054ac66 in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:598
mp = (struct mount *) 0xc35b3c00
nmp = (struct mount *) 0xc35b3c00
done = 5887
p = (struct proc *) 0xc38d8c5c
td = (struct thread *) 0xc357fd80
#11 0xc04e67e8 in fork_exit (callout=0xc054aa98 , arg=0x0,
frame=0xe68aad38)
at /usr/src/sys/kern/kern_fork.c:791
p = (struct proc *) 0xc38d8c5c
td = (struct thread *) 0x0
#12 0xc066746c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
No locals.
(kgdb)
panic: softdep_deallocate_dependencies: dangling deps
Uptime: 10h26m14s
Dumping 2047 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 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136
1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360
1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584
1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808
1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032(kgdb)
Would be really grateful if anyone could suggest anything, again it
appears to happen around the time periodic runs (but has happened
randomly under load, not sure if this is a red herring tho)
If anyone needs anymore info, more than happy to oblige.
Cheers
Is there anyway this could be triggered by a filesystem becoming full.?
--
Jamie Heckford
Network Manager
Trident Microsystems Ltd.
t: +44(0)1737-780790
f: +44(0)1737-771908
w: http://www.trident-uk.co.uk/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 5.4-RC2 freezing - ATA related?
Jamie Heckford wrote:
On Wed, May 18, 2005 at 03:54:59PM -0700, Doug White wrote:
On Wed, 18 May 2005, Jamie Heckford wrote:
Hi Peter,
On Thu, May 19, 2005 at 05:53:12AM +1000, Peter Jeremy wrote:
On Wed, 2005-May-18 16:03:16 +0100, Jamie Heckford wrote:
Managed to get a dump on our system for a similar prob we are getting:
That traceback looks like a panic, not a deadlock. What was the panic
message?
Only have remote access to the box im afraid, is there anyway I can obtain
the panic message?
"print msgbuf" should do it
Another one... looks completly different :-(
[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".
#0 doadump () at pcpu.h:160
160 __asm __volatile("movl %%fs:0,%0" : "=r" (td));
(kgdb) bt full
#0 doadump () at pcpu.h:160
No locals.
#1 0xc04fac8a in boot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:410
first_buf_printf = 1
#2 0xc04faf50 in panic (fmt=0xc06c06db
"softdep_deallocate_dependencies: dangling deps")
at /usr/src/sys/kern/kern_shutdown.c:566
td = (struct thread *) 0xc357fd80
bootopt = 260
newpanic = 1
ap = 0xc357fd80 "\\\214\215ÃðjOÃ"
buf = "softdep_deallocate_dependencies: dangling deps", '\0'
#3 0xc061cbfe in softdep_deallocate_dependencies (bp=0x0)
at /usr/src/sys/ufs/ffs/ffs_softdep.c:5961
No locals.
#4 0xc053c8f4 in brelse (bp=0xd77932d4) at buf.h:431
No locals.
#5 0xc054bd24 in flushbuflist (blist=0xd77932d4, flags=0,
vp=0xc4bf9630, slpflag=0,
slptimeo=0, errorp=0x0) at /usr/src/sys/kern/vfs_subr.c:1101
bp = (struct buf *) 0xd77932d4
nbp = (struct buf *) 0xd75948f0
found = 1
#6 0xc054b987 in vinvalbuf (vp=0xc4bf9630, flags=0, cred=0x0, td=0x0,
slpflag=0,
slptimeo=0) at /usr/src/sys/kern/vfs_subr.c:987
blist = (struct buf *) 0x0
error = 0
object = 0xc04efc79
#7 0xc054e85c in vclean (vp=0xc4bf9630, flags=8, td=0xc357fd80)
at /usr/src/sys/kern/vfs_subr.c:2479
---Type to continue, or q to quit---
active = 0
#8 0xc054eeb5 in vgonel (vp=0xc4bf9630, td=0xc357fd80)
at /usr/src/sys/kern/vfs_subr.c:2697
No locals.
#9 0xc054a9f2 in vlrureclaim (mp=0xc35b3c00) at pcpu.h:157
vp = (struct vnode *) 0xc4bf9630
done = 0
trigger = 10
usevnodes = 0
count = 7
#10 0xc054ac66 in vnlru_proc () at /usr/src/sys/kern/vfs_subr.c:598
mp = (struct mount *) 0xc35b3c00
nmp = (struct mount *) 0xc35b3c00
done = 5887
p = (struct proc *) 0xc38d8c5c
td = (struct thread *) 0xc357fd80
#11 0xc04e67e8 in fork_exit (callout=0xc054aa98 , arg=0x0,
frame=0xe68aad38)
at /usr/src/sys/kern/kern_fork.c:791
p = (struct proc *) 0xc38d8c5c
td = (struct thread *) 0x0
#12 0xc066746c in fork_trampoline () at
/usr/src/sys/i386/i386/exception.s:209
No locals.
(kgdb)
panic: softdep_deallocate_dependencies: dangling deps
Uptime: 10h26m14s
Dumping 2047 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 512 528 544 560 576 592
608 624 640 656 672 688 704 720 736 752 768 784 800 816 832 848 864 880
896 912 928 944 960 976 992 1008 1024 1040 1056 1072 1088 1104 1120 1136
1152 1168 1184 1200 1216 1232 1248 1264 1280 1296 1312 1328 1344 1360
1376 1392 1408 1424 1440 1456 1472 1488 1504 1520 1536 1552 1568 1584
1600 1616 1632 1648 1664 1680 1696 1712 1728 1744 1760 1776 1792 1808
1824 1840 1856 1872 1888 1904 1920 1936 1952 1968 1984 2000 2016 2032(kgdb)
Would be really grateful if anyone could suggest anything, again it
appears to happen around the time periodic runs (but has happened
randomly under load, not sure if this is a red herring tho)
If anyone needs anymore info, more than happy to oblige.
Cheers
--
Jamie Heckford
Network Manager
Trident Microsystems Ltd.
t: +44(0)1737-780790
f: +44(0)1737-771908
w: http://www.trident-uk.co.uk/
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once > again. It will probably take an hour to get it up and running. Unfortunately, 6.0-CURRENT didn't help at all. FreeBSD 6.0-CURRENT #0: Wed May 25 13:24:30 CEST 2005 [...] Timecounter "i8254" frequency 1193182 Hz quality 0 CPU: AMD Athlon(TM) XP 2000+ (1668.71-MHz 686-class CPU) Origin = "AuthenticAMD" Id = 0x662 Stepping = 2 Features=0x383fbff AMD Features=0xc040 real memory = 1073725440 (1023 MB) avail memory = 1041891328 (993 MB) ACPI APIC Table: [...] pcm0: port 0xd800-0xd8ff at device 5.0 on pci0 [...] atkbd0: irq 1 on atkbdc0 kbd0 at atkbd0 atkbd0: [GIANT-LOCKED] psm0: irq 12 on atkbdc0 psm0: [GIANT-LOCKED] psm0: model IntelliMouse, device ID 3 [...] atapci0: port 0xd400-0xd407,0xd000-0xd003,0xb800-0xb807,0xb400-0xb403,0xb000-0xb00f mem 0xe580-0xe5803fff irq 19 at device 6.0 on pci0 ata2: on atapci0 ata3: on atapci0 atapci1: port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0x9800-0x980f at device 17.1 on pci0 ata0: on atapci1 ata1: on atapci1 [...] ad0: 38166MB at ata0-master UDMA100 [...] # vmstat -i interrupt total rate irq1: atkbd0 704 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq12: psm0 7143 24 irq13: npx01 0 irq14: ata046427160 irq15: ata1 67 0 irq16: fxp0 284 0 irq17: pcm0 4414 15 lapic0: timer 575578 1991 Total 634630 2195 # sysctl -a|grep mpsafe debug.mpsafevfs: 1 debug.mpsafenet: 1 debug.mpsafevm: 1 The issues still exist. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Syscons output freezes with 4.11-RELEASE
Hello all, got a very strange problem. This happened both, if the system was booted from a P2-400 Slot1 system and is happening again, although I've relocated the system to a K6-2 Sockel7 board. So, we have different hardware, except for 2x NIC and the HDDs, which I've transferred. The symptoms are, that some time during boot or shortly thereafter the output to the console would freeze completely. Absolutely no updates are happening. I can still log in via keyboard and do stuff (blindfolded) and all network services are running just fine. I didn't hit scroll lock or anything, it happens totally automatically, even with different keyboards. I tried changing various settings of ttyv0 through vidcontrol, but no success there. This is a 4.11 system, anything I could/should try to debug this? Ulrich Spörlein -- PGP Key ID: F0DB9F44 Encrypted mail welcome! Fingerprint: F1CE D062 0CA9 ADE3 349B 2FE8 980A C6B5 F0DB 9F44 Ok, which part of "Ph'nglui mglw'nafh Cthulhu R'lyeh wgah'nagl fhtagn." didn't you understand? pgpn6ODWIvfCI.pgp Description: PGP signature
Re: RELENG_5_4 panic
On Wed, 25 May 2005, Kris Kennaway wrote: i've been experiencing kernel panics for over a year, but the frequency of it seems like everytime there is a small high cpu usage peak, the system panics. im totally unsure what is going on, and hopefully someone can problem in the code or probably something else (hardware failure?). Sounds exactly like hardware failure to me. It's too bad you waited a year to investigate this :-) hi all, tnx very much for reply, kris, stefan and thomas. i was also thinking/fearing for a hardware error. the reason why i didn't investigate sooner is that over the past two years i was running 5.0-RC2 and after that followed current. i always assumed that that could be the reason, but when i reverted a month ago to 5.4-RELEASE and now RELENG_5_4 aka stable, the problem stayed ... plus my kernel debugging skills are very limited - hence learned again :) so HW failure. now the only thing to do is convince our IT dep that it is broken and ask a new one. the problem is that they only support windows and they go frantic when they see linux, let alone BSD :) so the probably want to put the blame on the OS iso the HW. wish me luck :) tnx again guys! filip Kris http://filip.freeshell.org mailto:[EMAIL PROTECTED] SDF Public Access UNIX System - http://sdf.lonestar.org ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: Performance of 4.x vs 5.x (Re: Lifetime of FreeBSD branches)
Krzysztof Kowalik [EMAIL PROTECTED] wrote: > [...] > I will try to put my hands on the mentioned AMD box once again, to run > some current 6.0 on it. OK, got the box. I ran a 5.4-RELEASE, identical (as I just restored dumps of my current workstation on it) as the one not giving problems on Intel-based system. Regardless of the state of USB, I can observe the mentioned issues (scattered sound, lagging mouse in X, etc while untarring firefox's sources). With USB, vmstat -i shows: interrupt total rate irq1: atkbd0 904 2 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 56478127 irq12: psm0 4912 11 irq13: npx01 0 irq14: ata0 8529 19 irq15: ata1 63 0 irq16: fxp0 uhci1 437384987 irq17: pcm0 1576 3 irq0: clk 441323996 Total 951182 2147 ... and without it: interrupt total rate irq1: atkbd0 164 1 irq3: sio1 1 0 irq4: sio0 1 0 irq6: fdc010 0 irq8: rtc 19340127 irq12: psm0 7005 46 irq13: npx01 0 irq14: ata018731123 irq15: ata1 61 0 irq16: fxp0 132 0 irq17: pcm0 2448 16 irq0: clk 151117994 Total 199011 1309 cvsup-ing current 6.0-CURRENT right now, to check the giantless VFS once again. It will probably take an hour to get it up and running. If you have any more ideas, while I still have the box, I'd be willing to try, time permitting. -- Krzysztof Kowalik | () ASCII Ribbon Campaign Computer Center, AGH UST| /\ Support plain text e-mail ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
panic: ffs_blkfree: freeing free block
Hi, I have seen this knid of panic on 5.3/i386 (-p15) and 4.x. Machine is an i386 machine with an external hardware RAID, shared with nfs. There are total 20+ nfs client. When one exported space gets full and some user's program keeping write (probability with remove) data to this space, sometimes after lots of /dev/x is full message, I got this panic. dev = da0s1d, block = 44652432, fs = /export/b1 panic: ffs_blkfree: freeing free block cpuid = 3 KDB: enter: panic [thread 100112] Stopped at kdb_enter+0x30: leave db> wh kdb_enter(c066992d,3,c0672f0b,e4ba6ae0,5) at kdb_enter+0x30 panic(c0672f0b,c22b58a8,2a95790,0,c23638d4) at panic+0x13e ffs_blkfree(c2363800,c23cb318,2a95790,0,4000) at ffs_blkfree+0x3d2 indir_trunc(c2690e00,aa55e20,0,1,80c) at indir_trunc+0x30d handle_workitem_freeblocks(c2690e00,0,2,6,0) at handle_workitem_freeblocks+0x20e process_worklist_item(0,0,42935dad,0,0) at process_worklist_item+0x1e1 softdep_process_worklist(0,1e,c1f1a320,0,0) at softdep_process_worklist+0xcc sched_sync(0,e4ba6d48,0,0,0) at sched_sync+0x5f2 fork_exit(c0541295,0,e4ba6d48) at fork_exit+0x80 fork_trampoline() at fork_trampoline+0x8 --- trap 0x1, eip = 0, esp = 0xe4ba6d7c, ebp = 0 --- The system disk is on ips(4) which does not support dump in 5.3 (supportted in 5.4). So, there is no dump available. I don't exactly know what kind of accessing pattern causes this. Therefore, no idea where to start at. Wonder if this can be fixed or so. Cheers, Rong-En Fan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5_4 panic
Guckux Filip Filip Lenaerts wrote: > i've been experiencing kernel panics for over a year, but the frequency > of them happening has increased dramatically. now i was finally able to > > it seems like everytime there is a small high cpu usage peak, the system > panics. im totally unsure what is going on, and hopefully someone can Sounds like a problem which I had a few years ago... hardware failure... The reason in my system was a hard-disk fan which won't work anymore. Under system load - the whole system wants more power and the result was kernel panic / resetting the system... Have a look to the other answers - dying of the CPU or s.th. else... (At the moment I expect a similiar problem, the ELKOs on my MotherBoard are white on the TOP - bad material and they are near the CPU/Cooler... :-( ) Bye Stefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: 4.10-RELEASE-p3 i386 problem with /dev/dsp
# [EMAIL PROTECTED] / 2005-05-24 21:27:19 +0200:
> On Mon, 23.05.2005 at 16:10:03 +0200, Roman Neuhauser wrote:
> > I have a machine with FreeBSD 4.10-RELEASE-p3 i386 (450MHz P3/Celeron)
> > that has been running just fine, but after ~ 120 days something
> > happened to /dev/dsp, and I can no longer play mp3s. A restart would
> > most probably fix it, but I'd like to know if it's possible to determine
> > (and fix) the issue on a running system. Yes, I'm fond of my uptime
> > ("up 133 days, 20:04", including an X session), but I'd also like to know if
> > this is recoverable or requires the windows-style bandaid.
>
> Back in the days, this used to happen from time to time. Somehow
> processes no longer could open /dev/dsp, but no other process had it
> open (verified with lsof and fstat).
But ktrace / kdump say the device has been open successfully, and
it's not before many writes (128 bytes each) return success that it
starts returning -1 with EINVAL.
> Looks like you need to reboot ...
Maybe this is a different problem, correctable without rebooting.
Of course, there isn't really any reason not to reboot it, but
I'd like to understand the problem first.
I understand that such a problem with 4.x won't draw much attention
these days. I just happen to enjoy 4.x so much I have it on all but
two boxes (a colleague of mine who runs 5.x had several panics
during the four months this 4.10 needed to build enough entropy to
give up sound).
--
How many Vietnam vets does it take to screw in a light bulb?
You don't know, man. You don't KNOW.
Cause you weren't THERE. http://bash.org/?255991
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5_4 panic
Hi, On Wed, 25. May 2005, at 6:49 +, Filip Lenaerts wrote according to [RELENG_5_4 panic]: > it seems like everytime there is a small high cpu usage peak, the system > panics. I've seen this very same symptom caused by a dying CPU some years ago. Riggs -- - "[...] I talked to the computer at great length and -- explained my view of the Universe to it" said Marvin. --- And what happened?" pressed Ford. "It committed suicide." said Marvin. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "[EMAIL PROTECTED]"
Re: RELENG_5_4 panic
On Wed, May 25, 2005 at 06:49:43AM +, Filip Lenaerts wrote: > hi all, > > i've been experiencing kernel panics for over a year, but the frequency of > them happening has increased dramatically. now i was finally able to > build a kernel with debug options, since even while trying to build this > kernel, i would get kernel panics. > > it seems like everytime there is a small high cpu usage peak, the system > panics. im totally unsure what is going on, and hopefully someone can > more understand this, looking at the kdbg output below, pinpointing a > problem in the code or probably something else (hardware failure?). > messages file can be found at http://filip.freeshell.org/messages Sounds exactly like hardware failure to me. It's too bad you waited a year to investigate this :-) Kris pgprfWUwo1xJs.pgp Description: PGP signature
