em interface slow down on 8.0R
Hi, I noticed that network connection of one of my boxes got significantly slow just after upgrading it to 8.0R. The box has an em0 (82547EI) and worked fine with 7.2R. The symptoms are: - A ping to a host on the same LAN takes 990ms RTT, it reduces gradually to around 1ms, and then it returns to around 1s. The rate was about 2ms/ping. - The response is quite slow, but no packet loss and network services on the box seem to work fine as far as I can check. There does not seem interrupt storm according to "vmstat -i". No error message such as "watchdog timeout" appears. Any ideas to narrow down the cause? It maybe a linkup problem with a specific model of hub like full-duplex/half-duplex mismatch, but the link is "1000baseT " and setting it manually did not solve it. I think it is certain that upgrading to 8.0R triggered it, at least. Another box with an em interface works fine after upgrading to 8.0R. It has a different chip (82573E). Details of the em interface and vmstat -i are the following: e...@pci0:1:1:0: class=0x02 card=0x302c8086 chip=0x10198086 rev=0x00 hdr=0x00 vendor = 'Intel Corporation' device = 'Gigabit Ethernet Controller (LOM) (82547EI)' class = network subclass = ethernet Adapter hardware address = 0xc42e1424 em0: CTRL = 0x183c0241 RCTL = 0x8002 em0: Packet buffer = Tx=10k Rx=30k em0: Flow control watermarks high = 28672 low = 27172 em0: tx_int_delay = 66, tx_abs_int_delay = 66 em0: rx_int_delay = 0, rx_abs_int_delay = 66 em0: fifo workaround = 0, fifo_reset_count = 0 em0: hw tdh = 49, hw tdt = 49 em0: hw rdh = 238, hw rdt = 187 em0: Num Tx descriptors avail = 250 em0: Tx Descriptors not avail1 = 0 em0: Tx Descriptors not avail2 = 0 em0: Std mbuf failed = 0 em0: Std mbuf cluster failed = 0 em0: Driver dropped packets = 0 em0: Driver tx dma failure in encap = 0 dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 dev.em.0.%driver: em dev.em.0.%location: slot=1 function=0 handle=\_SB_.PCI0.P0P2.TANA dev.em.0.%pnpinfo: vendor=0x8086 device=0x1019 subvendor=0x8086 subdevice=0x302c class=0x02 dev.em.0.%parent: pci1 dev.em.0.debug: -1 dev.em.0.stats: -1 dev.em.0.rx_int_delay: 0 dev.em.0.tx_int_delay: 66 dev.em.0.rx_abs_int_delay: 66 dev.em.0.tx_abs_int_delay: 66 dev.em.0.rx_processing_limit: 100 dev.em.0.wake: 0 % vmstat -i interrupt total rate irq4: uart0 3585 3 irq14: ata0 1811 1 irq15: ata1 112 0 irq16: uhci0 uhci315 0 irq18: em0 uhci2+ 92457 99 irq19: uhci1 1 0 irq23: ehci0 2 0 cpu0: timer 1849981 1997 cpu1: timer 1849961 1997 Total3797925 4101 -- Hiroki pgpKKA4N6gAaa.pgp Description: PGP signature
Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. oh ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: > I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the > Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows > in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.)___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE completed...
On Sun, 29 Nov 2009 11:30:18 -0800, Gary Kline wrote: >> * There have been a lot of changes in the kernel configuration. If >> you want a custom kernel, start anew from the 8.0 GENERIC kernel so >> you don't miss anything. > > Could somebody who's running a 32biter send a GENERIC from 8.0 so I > can diff? You can always grab the latest version of GENERIC for 8.X from: http://svn.freebsd.org/viewvc/base/stable/8/sys/i386/conf/GENERIC Just follow the "view" link of the latest revision. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, Nov 30, 2009 at 10:19:37AM +0100, Thomas Backman wrote: > > I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the > > Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O > > shows in contrast to all claims that have been to be improoved the opposite. > Corrected link: > http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 > > And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The > only reason I'm not switching from Linux. :( > > Regards, > Thomas > > (PS. See my thread about horrible console latency during disk IO in the > archives, very related. DS.)___ Given this is a discussion predominantly with disk I/O and/or filesystem "stuff", possibly the discussion should be on -fs instead? I do see the reasoning behind discussing it on -stable though. I haven't looked at the Phoronix Test Suite[1], which is what's being used for testing "threaded I/O". I don't understand what "threaded I/O" means in this context; I'm assuming it means making a separate LWP for each I/O transaction, e.g. multiple LWPs for I/O (within a single program). Some technical details of the implementation/test methodology would need to be provided for someone to assist in tracking down the problem. However, I will take the time to point out one key piece of info: The Phoronix Test Suite appears to be written entirely in PHP[2]. I've looked at the source and it does appear to be PHP-based (with reliance on numerous third-party C-based libraries, of course; this is normal). Given that, I'm not sure I can really take the results of some of those tests seriously. I'm not dissuading the evidence, I'm just saying, it's more of a "PHP benchmark on " than it is an OS benchmark. [1]: http://www.phoronix-test-suite.com/ [2]: http://www.phoronix-test-suite.com/?k=downloads -- | Jeremy Chadwick j...@parodius.com | | Parodius Networking http://www.parodius.com/ | | UNIX Systems Administrator Mountain View, CA, USA | | Making life hard for others since 1977. PGP: 4BD6C0CB | ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: how to get the UFSID of a mounted filesystem ?
Thanks for the advice guys - dumpfs works fine, and I didnt even know it existed until now which is king of embarassings given how old it is! cheers, -pete. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, 30 Nov 2009 01:43:15 -0800 Jeremy Chadwick wrote: > The Phoronix Test Suite appears to be written entirely in PHP[2]. > I've looked at the source and it does appear to be PHP-based (with > reliance on numerous third-party C-based libraries, of course; this > is normal). Given that, I'm not sure I can really take the results of > some of those tests seriously. I'm not dissuading the evidence, I'm > just saying, it's more of a "PHP benchmark on " than it is an OS > benchmark. > > [1]: http://www.phoronix-test-suite.com/ > [2]: http://www.phoronix-test-suite.com/?k=downloads The benchmarks are scheduled by PHP, but the benchmark tests aren't: if you look in pts\test-resources it seems it tests how long it takes to build programs like mplayer and apache, and interprets the timing results from programs like dbench, iozone, scimark2 and povray. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, 30 Nov 2009 01:43:15 -0800 Jeremy Chadwick wrote: > I haven't looked at the Phoronix Test Suite[1], which is what's being > used for testing "threaded I/O". I don't understand what "threaded > I/O" means in this context; I'm assuming it means making a separate > LWP for each I/O transaction, e.g. multiple LWPs for I/O (within a > single program). Some technical details of the implementation/test > methodology would need to be provided for someone to assist in > tracking down the problem. > I've found the benchmark it's using: it runs tiobench from http://sourceforge.net/projects/tiobench/ with the parameters -f 16, 64, 128, 256 -t 4, 8, 16, 32 It's another project that for some reason doesn't produce releases - the last version was back in 2002. If someone's re-running the benchmark it might be better to use the version from cvs. -- Bruce Cran ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( Regards, Thomas (PS. See my thread about horrible console latency during disk IO in the archives, very related. DS.) Hello Thomas. I recall myself having had similar problems during heavy disk I/O (UFS and ZFS) with stuck console, stuck clients and especially stuck X11-clients. The discussion was really 'hot', but in the end no clear statement was made whether this is disk-i/o related or a deeper problem in the scheduler. Sorry for the lack of the link, I thought Phoronix is well known ... Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Nov 30, 2009, at 12:38 PM, O. Hartmann wrote: > Thomas Backman wrote: >> On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: >>> I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the >>> Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O >>> shows in contrast to all claims that have been to be improoved the opposite. >> Corrected link: >> http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 >> And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The >> only reason I'm not switching from Linux. :( >> Regards, >> Thomas >> (PS. See my thread about horrible console latency during disk IO in the >> archives, very related. DS.) > > Hello Thomas. > I recall myself having had similar problems during heavy disk I/O (UFS and > ZFS) with stuck console, stuck clients and especially stuck X11-clients. The > discussion was really 'hot', but in the end no clear statement was made > whether this is disk-i/o related or a deeper problem in the scheduler. > > Sorry for the lack of the link, I thought Phoronix is well known ... > > Oliver That's too bad, re: the scheduling. It seems to be a quite universal problem, yet I haven't seen much effort spent on working on the problem. :/ Re: phoronix, I commented mostly because the site is .com and not .org, so I came to a parked domain when I clicked your link. :) Also, I figured linking directly to the article will help the archives. Regards, Thomas___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Bruce Cran wrote: On Mon, 30 Nov 2009 01:43:15 -0800 Jeremy Chadwick wrote: I haven't looked at the Phoronix Test Suite[1], which is what's being used for testing "threaded I/O". I don't understand what "threaded I/O" means in this context; I'm assuming it means making a separate LWP for each I/O transaction, e.g. multiple LWPs for I/O (within a single program). Some technical details of the implementation/test methodology would need to be provided for someone to assist in tracking down the problem. I've found the benchmark it's using: it runs tiobench from http://sourceforge.net/projects/tiobench/ with the parameters -f 16, 64, 128, 256 -t 4, 8, 16, 32 It's another project that for some reason doesn't produce releases - the last version was back in 2002. If someone's re-running the benchmark it might be better to use the version from cvs. All right, due to my English 9I'm not a native English speaker) and limited knowledge of designs and imlementations of OSs, I will be careful formulating the next statement. Many people are, as well as I, not very tight bound to the internals of an Operating System like Linux, OpenSolaris or even FreeBSD. If one has to decide to switch or use an OS, he will look for benchmarks or even benchmark suites - and probably run luckily into Phoronoix-testsuite. But this suite seems to tell us a very clear message: Linux or OpenSolaris, just from the point of view of 'performance'. As a scientist, I miss SPEC2006 benchmarks, since those benchmarks are more reliable to scientific purposes, but in most cases I saw those benchmarks, they were done with a Linux (even if SPEC does more highlighting the hardware performance since the OS's performance). Disk I/O is a very crucial part of the OS if one produces lots of data contained in small files or small chunks. Are there any recent benchmarks outside Phoronix? Last time I saw a serious benchmark was from Kris Kenneway, he measured the performance of databases on SMP boxes. Regards, Oliver ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
2009/11/30 O. Hartmann > I haven't looked at the Phoronix Test Suite[1], which is what's being >>> used for testing "threaded I/O". I don't understand what "threaded >>> I/O" means in this context; I'm assuming it means making a separate >>> LWP for each I/O transaction, e.g. multiple LWPs for I/O (within a >>> single program). Some technical details of the implementation/test >>> methodology would need to be provided for someone to assist in >>> tracking down the problem. >>> >>> >> I've found the benchmark it's using: it runs tiobench from >> http://sourceforge.net/projects/tiobench/ with the parameters >> -f 16, 64, 128, 256 >> -t 4, 8, 16, 32 >> >> It's another project that for some reason doesn't produce releases - >> the last version was back in 2002. If someone's re-running the >> benchmark it might be better to use the version from cvs. >> >> > All right, > due to my English 9I'm not a native English speaker) and limited knowledge > of designs and imlementations of OSs, I will be careful formulating the next > statement. > > Many people are, as well as I, not very tight bound to the internals of an > Operating System like Linux, OpenSolaris or even FreeBSD. If one has to > decide to switch or use an OS, he will look for benchmarks or even benchmark > suites - and probably run luckily into Phoronoix-testsuite. But this suite > seems to tell us a very clear message: Linux or OpenSolaris, just from the > point of view of 'performance'. > > As a scientist, I miss SPEC2006 benchmarks, since those benchmarks are more > reliable to scientific purposes, but in most cases I saw those benchmarks, > they were done with a Linux (even if SPEC does more highlighting the > hardware performance since the OS's performance). Disk I/O is a very crucial > part of the OS if one produces lots of data contained in small files or > small chunks. > > Are there any recent benchmarks outside Phoronix? Last time I saw a serious > benchmark was from Kris Kenneway, he measured the performance of databases > on SMP boxes. > > Regards, > Oliver I think it's fairly well known disk io isn't FreeBSD's strong suit, but it's not quite as bad as it looks. There is some low-hanging fruit here. If you where to actually tune ZFS as recommended you'd see stronger results and hopefully ahci will be enabled by default soon as it is a nice performance increase in concurre -- Adam Vande More ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Adam Vande More wrote: I think it's fairly well known disk io isn't FreeBSD's strong suit, but it's not quite as bad as it looks. There is some low-hanging fruit here. If you where to actually tune ZFS as recommended you'd see stronger results and hopefully ahci will be enabled by default soon as it is a nice performance increase in concurre Yes, ZFS+AHCI should give significantly better results on any such test. Though I doubt it would be enough to match Linux results. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Ivan Voras : > Thomas Backman wrote: > > On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: > > > >> I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the > >> Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O > >> shows in contrast to all claims that have been to be improoved the > >> opposite. > > Corrected link: > > http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 > > > > And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The > > only reason I'm not switching from Linux. :( "All operating systems were left with their default options during the installation process..." It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. While it would be nice if FreeBSD shipped with a more performant default setting, it would also be nice if mindless benchmark drones would quit assuming that every system ships pre-configured to perform optimally in their benchmarks. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Bill Moran wrote: In response to Ivan Voras : Thomas Backman wrote: On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O shows in contrast to all claims that have been to be improoved the opposite. Corrected link: http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... The only reason I'm not switching from Linux. :( "All operating systems were left with their default options during the installation process..." It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. On the other hand, random IO is negatively influenced by readahead :) ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
On Mon, Nov 30, 2009 at 02:49:17PM +0100, Ivan Voras wrote: > Bill Moran wrote: > >In response to Ivan Voras : > > > >>Thomas Backman wrote: > >>>On Nov 30, 2009, at 9:47 AM, O. Hartmann wrote: > >>> > I'm just wondering what's wrong with FreeBSD 8.0/amd64 when I read the > Benchmarks on Phoronix.org's website. Especially FreeBSD's threaded I/O > shows in contrast to all claims that have been to be improoved the > opposite. > >>>Corrected link: > >>>http://www.phoronix.com/scan.php?page=article&item=freebsd8_benchmarks&num=1 > >>> > >>>And yeah, quite honestly: disk scheduling in FreeBSD appears to suck... > >>>The only reason I'm not switching from Linux. :( > > > >"All operating systems were left with their default options during the > >installation process..." > > > >It's common knowledge that the default value for vfs.read_max is non- > >optimal for most hardware and that significant performance improvements > >can be made in most cases by raising it. > > On the other hand, random IO is negatively influenced by readahead :) Parallel Random I/O gives better results on Raid 5 than a single sequential read :-) I also found FreeBSD UFS with Softupdates handling directories with many small files much better than Linux and ReiserFS (same hardware) - at least a simple ls returned much quicker on FreeBSD (factor 5 to 10). So it is always a matter of what you intend to do with the filesystem - is it for logging, for mailserver-storage, for database usage, for fileserver, webserver etc. (with or without changing atime), with redundancy (raid 1, 5, 10) or using zfs, etc. With FreeBSD we have a system that works ok out of the box, but for real-world usage needs some tuning to be optimised for the specific task. Regards, Holger ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Bill Moran writes: > It's common knowledge that the default value for vfs.read_max is > non- optimal for most hardware and that significant performance > improvements can be made in most cases by raising it. Documentation/discussion where? Respectfully, Robert Huff ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
In response to Robert Huff : > > Bill Moran writes: > > > It's common knowledge that the default value for vfs.read_max is > > non- optimal for most hardware and that significant performance > > improvements can be made in most cases by raising it. > > Documentation/discussion where? http://www.google.com/search?q=freebsd+vfs.read_max ... although it doesn't seem to be "officially" documented anywhere. -- Bill Moran http://www.potentialtech.com http://people.collaborativefusion.com/~wmoran/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Robert Huff wrote: Bill Moran writes: It's common knowledge that the default value for vfs.read_max is non- optimal for most hardware and that significant performance improvements can be made in most cases by raising it. Documentation/discussion where? There is no documentation except for the sysctl documentation itself: "vfs.read_max: Cluster read-ahead max block count" but it depends on the load - it helps sequential reads, will probably do nothing for other kinds of loads. It is also UFS-only. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
UFS Panic on 7.1 -> ffs_valloc: dup alloc
Hi,
I had a panic today when someone created a symlink over NFS to a UFS
file system.
There seem to be 2 open PRs on this already:
kern/122380
kern/133980
Any ideas on a fix? I have not tried to repeat this crash but I have
saved a snapshot of the file system so I can test if needed. I also
have the core file preserved.
# uname -a
FreeBSD mongo.XXX 7.1-RELEASE-p4 FreeBSD 7.1-RELEASE-p4 #0 @718:817M:
Tue Nov 24 02:31:49 UTC 2009
t...@dev-tj-7-1-amd64.xxx:/usr/obj/usr/src/sys/XXXv5 amd64
# kgdb /boot/kernel/kernel vmcore.0
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 "amd64-marcel-freebsd"...
Unread portion of the kernel message buffer:
mode = 0100600, inum = 2355296, fs = /usr/home
panic: ffs_valloc: dup alloc
cpuid = 0
Uptime: 5d13h10m53s
Physical memory: 6122 MB
Dumping 510 MB: 495 479 463 447 431 415 399 383 367 351 335 319 303 287
271 255 239 223 207 191 175 159 143 127 111 95 79 63 47 31 15
#0 doadump () at pcpu.h:195
195 pcpu.h: No such file or directory.
in pcpu.h
(kgdb) bt
#0 doadump () at pcpu.h:195
#1 0x0004 in ?? ()
#2 0x8048e079 in boot (howto=260) at
/usr/src/sys/kern/kern_shutdown.c:418
#3 0x8048e482 in panic (fmt=0x104 bounds>) at /usr/src/sys/kern/kern_shutdown.c:574
#4 0x80607752 in ffs_valloc (pvp=Variable "pvp" is not available.
) at /usr/src/sys/ufs/ffs/ffs_alloc.c:968
#5 0x8063104e in ufs_makeinode (mode=41453,
dvp=0xff001d954dc8, vpp=0xb48e28a8, cnp=0xb48e28d0)
at /usr/src/sys/ufs/ufs/ufs_vnops.c:2254
#6 0x8063153f in ufs_symlink (ap=0xb48e29a0) at
/usr/src/sys/ufs/ufs/ufs_vnops.c:1831
#7 0x80737fe3 in VOP_SYMLINK_APV (vop=Variable "vop" is not
available.
) at vnode_if.c:1351
#8 0x805b8f38 in nfsrv_symlink (nfsd=0xff0065996100,
slp=0xff00035e6e00, td=0xff00041886e0, mrq=0xb48e2b00)
at vnode_if.h:712
#9 0x805b in nfssvc (td=Variable "td" is not available.
) at /usr/src/sys/nfsserver/nfs_syscalls.c:456
#10 0x806d7fa7 in syscall (frame=0xb48e2c80) at
/usr/src/sys/amd64/amd64/trap.c:907
#11 0x806be06b in Xfast_syscall () at
/usr/src/sys/amd64/amd64/exception.S:330
#12 0x000800687bfc in ?? ()
Previous frame inner to this frame (corrupt stack?)
(kgdb) frame 4
#4 0x80607752 in ffs_valloc (pvp=Variable "pvp" is not available.
) at /usr/src/sys/ufs/ffs/ffs_alloc.c:968
968 panic("ffs_valloc: dup alloc");
(kgdb) list
963 }
964 ip = VTOI(*vpp);
965 if (ip->i_mode) {
966 printf("mode = 0%o, inum = %lu, fs = %s\n",
967 ip->i_mode, (u_long)ip->i_number, fs->fs_fsmnt);
968 panic("ffs_valloc: dup alloc");
969 }
970 if (DIP(ip, i_blocks) && (fs->fs_flags & FS_UNCLEAN) == 0) {
/* XXX */
971 printf("free inode %s/%lu had %ld blocks\n",
972 fs->fs_fsmnt, (u_long)ino, (long)DIP(ip, i_blocks));
(kgdb)
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: Phoronix Benchmarks: Waht's wrong with FreeBSD 8.0?
Am 30.11.2009 15:46, schrieb Ivan Voras: > Robert Huff wrote: >> Bill Moran writes: >> >>> It's common knowledge that the default value for vfs.read_max is >>> non- optimal for most hardware and that significant performance >>> improvements can be made in most cases by raising it. >> >> Documentation/discussion where? > > There is no documentation except for the sysctl documentation itself: > "vfs.read_max: Cluster read-ahead max block count" but it depends on the > load - it helps sequential reads, will probably do nothing for other > kinds of loads. It is also UFS-only. I tested different values some time ago. vfs.read_max can be raised to about twice its default value and I set it to 15, when I had UFS+SU file systems (switched over to ZFS, long ago.) Tests included operations on large files (multi-GB) that were processed and written back to the same drive. But even in these tests, there was an upper limit beyond that system responsiveness declined massively (IIRC, at about 25). The best value (without impact on randoim I/O) seems to be in the range 12 to 16. (FreeBSD used to apply a heuristic on read-ahead, and only incremented the read amount to the limit set by the sysctl as long as the accesses were purely sequential.) Regards, STefan ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
I will look into this Hiroki, as time goes the older hardware does not always get test cycles like one might wish. Jack On Mon, Nov 30, 2009 at 12:04 AM, Hiroki Sato wrote: > Hi, > > I noticed that network connection of one of my boxes got > significantly slow just after upgrading it to 8.0R. The box has an > em0 (82547EI) and worked fine with 7.2R. > > The symptoms are: > > - A ping to a host on the same LAN takes 990ms RTT, it reduces > gradually to around 1ms, and then it returns to around 1s. The > rate was about 2ms/ping. > > - The response is quite slow, but no packet loss and network services > on the box seem to work fine as far as I can check. There does not > seem interrupt storm according to "vmstat -i". No error message > such as "watchdog timeout" appears. > > Any ideas to narrow down the cause? It maybe a linkup problem with a > specific model of hub like full-duplex/half-duplex mismatch, but the > link is "1000baseT " and setting it manually did not > solve it. I think it is certain that upgrading to 8.0R triggered it, > at least. > > Another box with an em interface works fine after upgrading to 8.0R. > It has a different chip (82573E). > > Details of the em interface and vmstat -i are the following: > > e...@pci0:1:1:0: class=0x02 card=0x302c8086 chip=0x10198086 rev=0x00 > hdr=0x00 >vendor = 'Intel Corporation' >device = 'Gigabit Ethernet Controller (LOM) (82547EI)' >class = network >subclass = ethernet > > Adapter hardware address = 0xc42e1424 > em0: CTRL = 0x183c0241 RCTL = 0x8002 > em0: Packet buffer = Tx=10k Rx=30k > em0: Flow control watermarks high = 28672 low = 27172 > em0: tx_int_delay = 66, tx_abs_int_delay = 66 > em0: rx_int_delay = 0, rx_abs_int_delay = 66 > em0: fifo workaround = 0, fifo_reset_count = 0 > em0: hw tdh = 49, hw tdt = 49 > em0: hw rdh = 238, hw rdt = 187 > em0: Num Tx descriptors avail = 250 > em0: Tx Descriptors not avail1 = 0 > em0: Tx Descriptors not avail2 = 0 > em0: Std mbuf failed = 0 > em0: Std mbuf cluster failed = 0 > em0: Driver dropped packets = 0 > em0: Driver tx dma failure in encap = 0 > > dev.em.0.%desc: Intel(R) PRO/1000 Network Connection 6.9.14 > dev.em.0.%driver: em > dev.em.0.%location: slot=1 function=0 handle=\_SB_.PCI0.P0P2.TANA > dev.em.0.%pnpinfo: vendor=0x8086 device=0x1019 subvendor=0x8086 > subdevice=0x302c class=0x02 > dev.em.0.%parent: pci1 > dev.em.0.debug: -1 > dev.em.0.stats: -1 > dev.em.0.rx_int_delay: 0 > dev.em.0.tx_int_delay: 66 > dev.em.0.rx_abs_int_delay: 66 > dev.em.0.tx_abs_int_delay: 66 > dev.em.0.rx_processing_limit: 100 > dev.em.0.wake: 0 > > % vmstat -i > interrupt total rate > irq4: uart0 3585 3 > irq14: ata0 1811 1 > irq15: ata1 112 0 > irq16: uhci0 uhci315 0 > irq18: em0 uhci2+ 92457 99 > irq19: uhci1 1 0 > irq23: ehci0 2 0 > cpu0: timer 1849981 1997 > cpu1: timer 1849961 1997 > Total3797925 4101 > > -- Hiroki > ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: [panic] 8.0-PRERELEASE
On Wednesday 25 November 2009 9:48:44 pm Glen Barber wrote: > Hello, > > This evening I experienced another panic on a Toshiba laptop on which I've > been having excessive hang-up issues. > > This time, I was able to get a crash report (attached, with fstat output > excluded because of the length). > > Any thoughts? Can you do this in kgdb: 'frame 7' 'p dev' 'p dl' -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0 kernel fails to build if some USB drivers are trimmed out; error in /sys/conf/files
On Thursday 26 November 2009 2:05:55 pm Scot Hetzel wrote: > On 11/26/09, Jeremy Chadwick wrote: > > I don't think parenthesis are the core of the problem, given that there > > are many other devices in /sys/conf/files which utilise said method. > > > There are only 2 places in the /sys/conf/files which use this method, > and both of them are for usb drivers: > > # USB ethernet drivers > # > dev/usb/net/if_aue.coptional aue > dev/usb/net/if_axe.coptional axe > dev/usb/net/if_cdce.c optional cdce > dev/usb/net/if_cue.coptional cue > dev/usb/net/if_kue.coptional kue > dev/usb/net/if_rue.coptional rue > dev/usb/net/if_udav.c optional udav > dev/usb/net/usb_ethernet.c \ > optional (aue | axe | cdce | cue | kue | rue | udav) > : > # USB serial and parallel port drivers > # > dev/usb/serial/u3g.coptional u3g > dev/usb/serial/uark.c optional uark > dev/usb/serial/ubsa.c optional ubsa > dev/usb/serial/ubser.c optional ubser > dev/usb/serial/uchcom.c optional uchcom > dev/usb/serial/ucycom.c optional ucycom > dev/usb/serial/ufoma.c optional ufoma > dev/usb/serial/uftdi.c optional uftdi > dev/usb/serial/ugensa.c optional ugensa > dev/usb/serial/uipaq.c optional uipaq > dev/usb/serial/ulpt.c optional ulpt > dev/usb/serial/umct.c optional umct > dev/usb/serial/umodem.c optional umodem > dev/usb/serial/umoscom.coptional umoscom > dev/usb/serial/uplcom.c optional uplcom > dev/usb/serial/uslcom.c optional uslcom > dev/usb/serial/uvisor.c optional uvisor > dev/usb/serial/uvscom.c optional uvscom > dev/usb/serial/usb_serial.c optional ucom | \ > (u3g | uark | ubsa | ubser | uchcom | ucycom | ufoma | uftdi | > ugensa | uipaq | ulpt | umct | umodem | umoscom | uplcom | uslcom | > uvisor | uvscom) > > It would be interesting if this also breaks for compiling 'USB serial > and parallel port drivers' into the kernel. config doesn't handle parentheses here at all. They should just be removed. config thinks the file is conditional on the '(aue', 'udav)', '(u3g', and 'uvscom)' drivers. -- John Baldwin ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: 8.0-RELEASE completed...
On Sun, Nov 29, 2009 at 07:47:28PM +, Bruce Cran wrote:
> On Sun, 29 Nov 2009 11:30:18 -0800
> Gary Kline wrote:
>
> > { One far, far OT question here: who can explain what dovecot
> > is/does? why it even exists? I'm familiar with MTA's, like
> > sendmail; likewise with MUA's, like evo, kmail, and mutt.
> > It's time to learn another level of complexity, evidently}
>
> Dovecot is an IMAP/POP3 server - sendmail lets you send mail, dovecot
> lets you fetch it from a remote server.
>
Well, I gotta fess up and admit that I've been living in the
past century for a long time! Weren't these IMAP/POP servers
originally for people to use their FreeBSD computers at home
from their university [or work] accounts? I had an IP from
work for several years, then set up sendmail to deliver mail
to my individual machines. i really have let things slide
since I went back to school; now it's time to get back on
track. For the past two years I've relied on one guy ... and
until I am back up to par, if he should get hit by a bus, I'm
up the creek. --Thus all these recent questions... .
> --
> Bruce Cran
--
Gary Kline kl...@thought.org http://www.thought.org Public Service Unix
http://jottings.thought.org http://transfinite.thought.org
The 7.31a release of Jottings: http://jottings.thought.org/index.php
___
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Teltonika ModemPCI/G10
Hi Guys! Is there anybody who uses Teltonika ModemPCI/G10 under 7-stable? I see that USB version of it (ModemUSB/G10) works for people via uftdi driver. Regards, Alex. ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
Re: em interface slow down on 8.0R
Jack Vogel wrote in <2a41acea0911301119j1449be58y183f2fe1d1112...@mail.gmail.com>: jf> I will look into this Hiroki, as time goes the older hardware does not jf> always jf> get test cycles like one might wish. Thanks! Please let me know if you need more information. -- Hiroki pgp3TYQPpOkMO.pgp Description: PGP signature
Re: interrupt storm on MSI IXP600 based motherboards
Pete French wrote: Oh FFS! This morning I sent the following email.. Six months is a long gap! I was hooinh the problem had gone away. I havent seen it on here since I started running 7.2-STABLE, and before that I made it go away by using a debug kernel. ...and within an hour of typing that I also started seeing these messages again for the first time in 6 months! That's one hell of a co-inicdence. Surely it cant be date related ? FYI, since upgrading to 8.0-PRERELEASE on Oct 30, there have been no interrupt storms. \o/ ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
