Re: [HEADSUP] Upcoming GNU sort removal
On Thu, 2012-10-04 at 18:16 +0200, Gabor Kovesdan wrote: > Em 04-10-2012 16:50, Dennis Glatting escreveu: > > On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: > >> > Hi, > >> > > >> > it has been more than 3 months ago that BSD sort became default in HEAD > >> > and no serious complaints have been raised against it since then so I > >> > plan to permanently remove GNU sort from head in the next days. If you > >> > have any objection, please raise it now. > >> > > > Initially I had problems with multi TB files (--unique, five to ten > > files) but I haven't had to do that in two(?) months. I will be getting > > back to that project in a month or so. > > > > It challanges a system's resources. :) > > And did it go much better with base GNU sort? It's quite an extreme > case... :) Multi GB is also rare not speaking about multi TB... > Yes. However my problem now is ZFS stability -- typically locking up, case example today: last pid: 67998; load averages: 0.00, 0.00, 0.00up 1+19:50:51 19:02:10 80 processes: 1 running, 79 sleeping CPU: 0.0% user, 0.0% nice, 0.0% system, 0.0% interrupt, 100% idle Mem: 146M Active, 2765M Inact, 35G Wired, 371M Buf, 86G Free ARC: 32G Total, 4141M MRU, 27G MFU, 55M Anon, 485M Header, 614M Other Swap: 233G Total, 233G Free PID USERNAMETHR PRI NICE SIZERES STATE C TIME WCPU COMMAND 17517 root 17 424 217M 128M tx->tx 21 25.3H 0.00% pbzip2 17568 root 17 524 201M 116M tx->tx 24 25.2H 0.00% pbzip2 17508 root 17 464 201M 116M tx->tx 33 24.6H 0.00% pbzip2 17544 root 17 524 205M 120M tx->tx 37 24.6H 0.00% pbzip2 17532 root 17 524 209M 123M tx->tx 35 24.5H 0.00% pbzip2 etc. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [CFT]hwpmc update for sandybridge-e
On Thu, Oct 4, 2012 at 3:46 PM, Sean Bruno wrote: > So, I did the bear minimum and kind of hacked things together without > understanding precisely what I was doing, and I was able to massage the > sandybridge-e CPUs into giving me some basic functions. > > Comments or concerns before I commit this? fabient@ already added some Ivy Bridge support to hwpmc. You may want to rebase based on his changes. I'd suggest SANDYBRIDGE_XEON, rather than SANDYBRIDGE_E only because I think it will make it more clear/correct. I'd also suggest putting something in uncore_pcpu_fini to not clear the EVSEL MSRs for SNB Xeon. By adding the new CPU type like you did, it has the effect of using the WSM EVSEL MSRs here (see the SELECTSEL macro in hwpmc_uncore.c). This is likely harmless, but isn't correct, and would be safer to just not clear the EVSEL MSRs at all, since there are no uncore events defined for your new CPU type anyways. Regards, -Jim > http://people.freebsd.org/~sbruno/pmc_sandybridge.txt > > Sean > > p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. > > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysctl kern.ipc.somaxconn limit 65535 why?
On 4 October 2012 15:21, Peter Jeremy wrote: > On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: >>In addition we had to migrate all our mysql servers from freebsd to debian >>because they were hitting some arbitary OS limit but I could never figure >>out what, sys% usage went through the roof when this limit was hit, issue >>didnt occur on debian. > > Did you report this issue on any of the FreeBSD mailing lists? > Reporting a problem doesn't guarantee that it will be fixed > (unfortunately) but not reporting a problem makes it extremely > unlikely that it will be fixed. Right, if you don't report that issue then the likelihood of it being fixed is low. It wouldn't be the first time that I've seen FreeBSD expose some bug in some not-quite-right multi-threaded code because it doesn't behave "like linux", regardless of what the specification says. :-) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[CFT]hwpmc update for sandybridge-e
So, I did the bear minimum and kind of hacked things together without understanding precisely what I was doing, and I was able to massage the sandybridge-e CPUs into giving me some basic functions. Comments or concerns before I commit this? http://people.freebsd.org/~sbruno/pmc_sandybridge.txt Sean p.s. I'm trying to hunt down some IvyBridge boxes to finish this off. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: sysctl kern.ipc.somaxconn limit 65535 why?
On 2012-Oct-03 19:45:01 +0100, free...@chrysalisnet.org wrote: >In addition we had to migrate all our mysql servers from freebsd to debian >because they were hitting some arbitary OS limit but I could never figure >out what, sys% usage went through the roof when this limit was hit, issue >didnt occur on debian. Did you report this issue on any of the FreeBSD mailing lists? Reporting a problem doesn't guarantee that it will be fixed (unfortunately) but not reporting a problem makes it extremely unlikely that it will be fixed. > I feel recently freebsd is more focused on desktop's >and as such developer's never develop for a heavy server usage scenario, This isn't intentionally true but it's true that few developers run large servers so they may not run into some issues that only impact large systems. Again, it's up to people who do run such systems to provide feedback about bottlenecks & issues they hit so that they can be fixed. >I keep coming across hardcoded low limits. As rightly pointed out default There are lots of defaults that were set some time (potentially decades) ago and may no longer be optimal. It's unrealistic to expect that all the defaults are correct in all circumstances and this is one area where end users can help by flagging defaults that they find need tuning. >values now days are useless 128 for somaxconn? maybe ok for a desktop. But, as others have pointed out, this isn't one of them. Can you please provide more details on a use scenario where a listen(2) backlog exceeding 128 is reasonable. > I cant tell app developers to >fix their apps to work on FreeBSD, they dont care, if it works fine on >windows and linux then the app isnt broken as far as they are concerned. FreeBSD is not Windows or Linux and never will be. There are lots of grey areas in the various standards that *BSD, Linux, Solaris, Windows etc comply with and some OSs interpret these grey areas differently to others (in some areas, it seems Linux has deliberately done things differently to other Unices for no obvious reason, and the GNU embrace-and-extend philosophy doesn't help). Writing portable code takes more than adding some .ac/.am files to an arbitrary blob of code and just because a developer thinks their app isn't broken doesn't make them right. BTW, I note that this was sent to -current? Are you running HEAD on production servers? If so, your feedback on issues you encounter would be appreciated so that they can be corrected before they make it into a RELEASE. -- Peter Jeremy ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn MFC to stable/8
John Baldwin wrote: > On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: > > Hi, > > > > Hopefully someone familiar with svn can help. When I try to MFC > > a kernel change to stable/8, it works, but I end up with tons of > > mergeinfo. (It looks like every directory under sys.) > > > > Does this matter or is there a trick to avoid this? > > > > Thanks in advance for any help, rick > > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > > Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 > not working well with newer merges from 1.7. The simplest solution > is to just update your client to svn 1.7. Otherwise, you can commit > what you have now with 1.6. > Thanks yet again John. I used svn1.7 and it didn't have all the dirs. It only listed directory properties for sys and sys/fs, which I hope was ok, since I committed it. rick > -- > John Baldwin > ___ > freebsd-current@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-current > To unsubscribe, send any mail to > "freebsd-current-unsubscr...@freebsd.org" ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
On Thu, 2012-10-04 at 22:24 +0200, Marek Salwerowicz wrote: > W dniu 2012-10-04 20:51, Lev Serebryakov pisze: > > Hello, Marek. > > You wrote 3 октября 2012 г., 23:17:35: > > > >>> atrtc0: port 0x70-0x71 on acpi0 > > MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host > > MS> Do you have any solution? > > In my case it was local patch for exotic embedded chipset... > Can you send me the patch so I can have a look if I don't use the same > chipset ? > > Regards, It is the patch attached to this PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=170705 The patch fixes a problem with old AMD Geode chipsets, but causes a hang at atrtc attach when run under virtualbox, and I haven't had time yet to install and learn to use vbox enough to debug it. -- Ian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [SPAM]Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
W dniu 2012-10-04 20:51, Lev Serebryakov pisze: Hello, Marek. You wrote 3 октября 2012 г., 23:17:35: atrtc0: port 0x70-0x71 on acpi0 MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS> Do you have any solution? In my case it was local patch for exotic embedded chipset... Can you send me the patch so I can have a look if I don't use the same chipset ? Regards, -- Marek Salwerowicz ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: memory warnings r240891 | dmesgg
On 4 October 2012 20:18, Darrel wrote: > Hello, > > Swap was created twice on this 9.0 release candidate install- once as > part of zfs and also as encrypted hard drive space. > > (30) @ 12:01:50> swapinfo > Device 1K-blocks UsedAvail Capacity > /dev/zvol/bigD/swap 41943040 4194304 0% > /dev/gpt/swap0.eli 31457280 3145728 0% > /dev/gpt/swap1.eli 31457280 3145728 0% > Total104857600 10485760 0% [...] > * > FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 > [...] > real memory = 1073741824 (1024 MB) > avail memory = 937144320 (893 MB [...] > > warning: total configured swap (2621440 pages) exceeds maximum > recommended amount (1852656 pages). > > warning: increase kern.maxswzone or reduce amount of swap. > > * > > Apparently kern.maxswzone is currently equal to 0. How might I tweak it > just enough to fix this? So, reduce amount of swap :) This is because kernel needs some memory to manage swap too. Currently for amd64 this roughly reduces to the following rule (My apologies in advance for the extra simplification): 100MB RAM per 800MB swap space. So, with your current amount of RAM (893MB) it is recommended to setup no more than 7144 MB of swap. [1] [1] Let's look at vm/swap_pager.c:swapon_check_swzone(npages). Here npages is the total swap pages you want to setup. The warning will trigger if (npages > maxpages / 2) becomes true. maxpages is the maximum pages the system can use for swap management. It is calculated as: maxpages = uma_zone_get_max(swap_zone) * SWAP_META_PAGES; By default SWAP_META_PAGES is 32 on amd64, and swap_zone limit calculates as available memory pages in system divided by two (assuming that maxswzone is zero (by default on amd64) and cannot further affect the limit). So that with X total pages in system, the maximum Y swap pages you are advised to have is: Y = X * SWAP_META_PAGES / 2 / 2, or X * 8 (on amd64). -- wbr, pluknet ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn MFC to stable/8
On Thursday, October 04, 2012 2:10:11 pm Rick Macklem wrote: > Hi, > > Hopefully someone familiar with svn can help. When I try to MFC > a kernel change to stable/8, it works, but I end up with tons of > mergeinfo. (It looks like every directory under sys.) > > Does this matter or is there a trick to avoid this? > > Thanks in advance for any help, rick > ps: I seem to MFC fine to stable/9. I only see this for stable/8. Someone screwed up the mergeinfo on stable/8/sys/dev due to svn 1.6 not working well with newer merges from 1.7. The simplest solution is to just update your client to svn 1.7. Otherwise, you can commit what you have now with 1.6. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: Latest -CURRENT/i386 could not start under VirutalBox 4.1.18 and 4.2 (Windows host): hangs up after atrtc0 detection
Hello, Marek. You wrote 3 октября 2012 г., 23:17:35: >> atrtc0: port 0x70-0x71 on acpi0 MS> still the same in my environment, running FreeBSD 9.1 under ESXi5.1 host MS> Do you have any solution? In my case it was local patch for exotic embedded chipset... -- // Black Lion AKA Lev Serebryakov ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn MFC to stable/8
On 4 October 2012 14:35, Rick Macklem wrote: > Sean Bruno wrote: >> On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: >> > Hi, >> > >> > Hopefully someone familiar with svn can help. When I try to MFC >> > a kernel change to stable/8, it works, but I end up with tons of >> > mergeinfo. (It looks like every directory under sys.) >> > >> > Does this matter or is there a trick to avoid this? >> > >> > Thanks in advance for any help, rick >> > ps: I seem to MFC fine to stable/9. I only see this for stable/8. >> > ___ >> >> Can you post your attempted svn merge command? >> >> Sean > Same as I've always used. When at the top of an updated stable/8 > checkout tree... > # svn merge -c240720 svn+ssh://rmack...@svn.freebsd.org/base/head/sys sys > > Also, after I reverse merge via: > # svn merge -c-240720 svn+ssh://rmack...@svn.freebsd.org/base/head/sys sys > # svn status . > M sys > M sys/dev/sound > - so I end up doing an "rm -r" of the tree, followed by a fresh checkout. > (Before, the status wouldn't see anything modified after I would reverse >the merge out.) FYI you could just do svn revert -R, no need for rm -r svn merge -c240720 svn+ssh://svn.freebsd.org/base/head/sys stable8/sys worked for me. Note that lack of a '-' after the 'c' from 'svn help merge': If ARG is negative this is like -r ARG:ARG-1 -- Eitan Adler ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn MFC to stable/8
Sean Bruno wrote: > On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: > > Hi, > > > > Hopefully someone familiar with svn can help. When I try to MFC > > a kernel change to stable/8, it works, but I end up with tons of > > mergeinfo. (It looks like every directory under sys.) > > > > Does this matter or is there a trick to avoid this? > > > > Thanks in advance for any help, rick > > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > > ___ > > Can you post your attempted svn merge command? > > Sean Same as I've always used. When at the top of an updated stable/8 checkout tree... # svn merge -c240720 svn+ssh://rmack...@svn.freebsd.org/base/head/sys sys Also, after I reverse merge via: # svn merge -c-240720 svn+ssh://rmack...@svn.freebsd.org/base/head/sys sys # svn status . M sys M sys/dev/sound - so I end up doing an "rm -r" of the tree, followed by a fresh checkout. (Before, the status wouldn't see anything modified after I would reverse the merge out.) rick ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: svn MFC to stable/8
On Thu, 2012-10-04 at 11:10 -0700, Rick Macklem wrote: > Hi, > > Hopefully someone familiar with svn can help. When I try to MFC > a kernel change to stable/8, it works, but I end up with tons of > mergeinfo. (It looks like every directory under sys.) > > Does this matter or is there a trick to avoid this? > > Thanks in advance for any help, rick > ps: I seem to MFC fine to stable/9. I only see this for stable/8. > ___ Can you post your attempted svn merge command? Sean ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
memory warnings r240891 | dmesgg
Hello, Swap was created twice on this 9.0 release candidate install- once as part of zfs and also as encrypted hard drive space. (30) @ 12:01:50> swapinfo Device 1K-blocks UsedAvail Capacity /dev/zvol/bigD/swap 41943040 4194304 0% /dev/gpt/swap0.eli 31457280 3145728 0% /dev/gpt/swap1.eli 31457280 3145728 0% Total104857600 10485760 0% Since then, all references to OpenBSD Packet Filter have been removed and the system is now r240891 * FreeBSD 10.0-CURRENT #1 r240891: Tue Sep 25 00:51:03 EDT 2012 WARNING: WITNESS option enabled, expect reduced performance. CPU: AMD Sempron(tm) Processor 2800+ (1599.86-MHz K8-class CPU) Origin = "AuthenticAMD" Id = 0x20fc2 Family = 0xf Model = 0x2c Stepping = 2 Features=0x78bfbff Features2=0x1 AMD Features=0xe2500800 AMD Features2=0x1 real memory = 1073741824 (1024 MB) avail memory = 937144320 (893 MB ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) ipfw2 (+ipv6) initialized, divert loadable, nat loadable, rule-based forwarding disabled, default to deny, logging disabled DUMMYNET 0 with IPv6 initialized (100409) load_dn_sched dn_sched FIFO loaded load_dn_sched dn_sched PRIO loaded load_dn_sched dn_sched QFQ loaded load_dn_sched dn_sched RR loaded load_dn_sched dn_sched WF2Q+ loaded hpt27xx: no controller detected. GEOM_ELI: Device gpt/swap0.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software GEOM_ELI: Device gpt/swap1.eli created. GEOM_ELI: Encryption: AES-XTS 128 GEOM_ELI: Crypto: software warning: total configured swap (2621440 pages) exceeds maximum recommended amount (1852656 pages). warning: increase kern.maxswzone or reduce amount of swap. * Apparently kern.maxswzone is currently equal to 0. How might I tweak it just enough to fix this? Also, I have been disregarding the prefetch notice about zfs. I have not seen any adverse results. Darrel ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
svn MFC to stable/8
Hi, Hopefully someone familiar with svn can help. When I try to MFC a kernel change to stable/8, it works, but I end up with tons of mergeinfo. (It looks like every directory under sys.) Does this matter or is there a trick to avoid this? Thanks in advance for any help, rick ps: I seem to MFC fine to stable/9. I only see this for stable/8. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] Upcoming GNU sort removal
On 10/4/2012 11:26 AM, C. P. Ghost wrote: BTW, its good to see BSD-licensed tools gradually replacing GNU tools in base. Though I'd have really preferred to see resources directed towards getting XEN/Dom0 support to FreeBSD/amd64. This really needs some love, IMHO. ;-) Gabor Thanks, -cpghost. Then give it some love yourself! No one is stopping you! :) -- Chuck Burns ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] Upcoming GNU sort removal
On Thu, Oct 4, 2012 at 6:16 PM, Gabor Kovesdan wrote: > Em 04-10-2012 16:50, Dennis Glatting escreveu: >> On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: >>> > Hi, >>> > >>> > it has been more than 3 months ago that BSD sort became default in HEAD >>> > and no serious complaints have been raised against it since then so I >>> > plan to permanently remove GNU sort from head in the next days. If you >>> > have any objection, please raise it now. >>> > >> Initially I had problems with multi TB files (--unique, five to ten >> files) but I haven't had to do that in two(?) months. I will be getting >> back to that project in a month or so. >> >> It challanges a system's resources. :) > > And did it go much better with base GNU sort? It's quite an extreme > case... :) Multi GB is also rare not speaking about multi TB... Yup. Plus nothing prevents us from using GNU sort from ports for those extremely rare cases. AFAICS, BSD sort is great for most of the workloads and is a perfect replacement for GNU sort. Good work! BTW, its good to see BSD-licensed tools gradually replacing GNU tools in base. Though I'd have really preferred to see resources directed towards getting XEN/Dom0 support to FreeBSD/amd64. This really needs some love, IMHO. ;-) > Gabor Thanks, -cpghost. -- Cordula's Web. http://www.cordula.ws/ ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] Upcoming GNU sort removal
Em 04-10-2012 16:50, Dennis Glatting escreveu: > On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: >> > Hi, >> > >> > it has been more than 3 months ago that BSD sort became default in HEAD >> > and no serious complaints have been raised against it since then so I >> > plan to permanently remove GNU sort from head in the next days. If you >> > have any objection, please raise it now. >> > > Initially I had problems with multi TB files (--unique, five to ten > files) but I haven't had to do that in two(?) months. I will be getting > back to that project in a month or so. > > It challanges a system's resources. :) And did it go much better with base GNU sort? It's quite an extreme case... :) Multi GB is also rare not speaking about multi TB... Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: [HEADSUP] Upcoming GNU sort removal
On Thu, 2012-10-04 at 12:53 +0200, Gabor Kovesdan wrote: > Hi, > > it has been more than 3 months ago that BSD sort became default in HEAD > and no serious complaints have been raised against it since then so I > plan to permanently remove GNU sort from head in the next days. If you > have any objection, please raise it now. > Initially I had problems with multi TB files (--unique, five to ten files) but I haven't had to do that in two(?) months. I will be getting back to that project in a month or so. It challanges a system's resources. :) ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
[HEADSUP] Upcoming GNU sort removal
Hi, it has been more than 3 months ago that BSD sort became default in HEAD and no serious complaints have been raised against it since then so I plan to permanently remove GNU sort from head in the next days. If you have any objection, please raise it now. Gabor ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
fusefs-sshfs crash
root@hummingbird:boris# uname -a FreeBSD hummingbird.dev 10.0-CURRENT FreeBSD 10.0-CURRENT #41 r241078: Mon Oct 1 21:18:05 YEKT 2012 r...@hummingbird.dev:/usr/obj/usr/src/sys/HUMMINGBIRD i386 root@hummingbird:boris# tail /var/log/messages ... Oct 4 11:29:04 hummingbird su: boris to root on /dev/pts/1 root@hummingbird:boris# sshfs boris@elephant:/home/boris/ /mnt/ boris@elephant.localnetwork's password: root@hummingbird:boris# ls /mnt ls: /mnt: Bad file descriptor root@hummingbird:boris# tail /var/log/messages ... Oct 4 11:29:04 hummingbird su: boris to root on /dev/pts/1 Oct 4 11:29:46 hummingbird kernel: pid 593 (sshfs), uid 0: exited on signal 11 (core dumped) root@hummingbird:boris# mount -lv ... /dev/fuse0 on /mnt (fusefs.sshfs, local, synchronous, fsid 04ff00eded00) root@hummingbird:boris# umount -f /mnt root@hummingbird:boris# gdb -e /usr/local/bin/sshfs -c /sshfs.core 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". Core was generated by `sshfs'. Program terminated with signal 11, Segmentation fault. Reading symbols from /usr/local/lib/libfuse.so.2...done. Loaded symbols for /usr/local/lib/libfuse.so.2 Reading symbols from /usr/local/lib/libgthread-2.0.so.0...done. Loaded symbols for /usr/local/lib/libgthread-2.0.so.0 Reading symbols from /usr/local/lib/libglib-2.0.so.0...done. Loaded symbols for /usr/local/lib/libglib-2.0.so.0 Reading symbols from /lib/libthr.so.3...done. Loaded symbols for /lib/libthr.so.3 Reading symbols from /lib/libc.so.7...done. Loaded symbols for /lib/libc.so.7 Reading symbols from /usr/local/lib/libiconv.so.3...done. Loaded symbols for /usr/local/lib/libiconv.so.3 Reading symbols from /usr/local/lib/libintl.so.9...done. Loaded symbols for /usr/local/lib/libintl.so.9 Reading symbols from /usr/local/lib/libpcre.so.1...done. Loaded symbols for /usr/local/lib/libpcre.so.1 Reading symbols from /libexec/ld-elf.so.1...done. Loaded symbols for /libexec/ld-elf.so.1 #0 0x0804ecd5 in ?? () [New Thread 2902a300 (LWP 100808/sshfs)] [New Thread 2902a080 (LWP 100807/sshfs)] [New Thread 28c03580 (LWP 100806/sshfs)] [New Thread 28c03080 (LWP 100344/sshfs)] (gdb) bt #0 0x0804ecd5 in ?? () #1 0x08056b78 in ?? () #2 0x in ?? () #3 0x28c31a30 in ?? () #4 0x281a5dde in __pthread_mutex_lock (mutex=0xa5a5a5a5) at /usr/src/lib/libthr/thread/thr_mutex.c:436 #5 0x0805001f in ?? () #6 0xa5a5a5a5 in ?? () #7 0x000189c7 in ?? () #8 0x in ?? () #9 0x2809aa40 in .got () from /usr/local/lib/libfuse.so.2 #10 0x29008000 in ?? () #11 0xbf8fce90 in ?? () #12 0xbf8fcc98 in ?? () #13 0x0805267f in ?? () #14 0x08056cf8 in ?? () #15 0xbf8fce90 in ?? () #16 0xbf8fccb8 in ?? () #17 0x in ?? () #18 0x in ?? () #19 0xa5a5a5a5 in ?? () #20 0xbf8fccc8 in ?? () #21 0x08052ecd in ?? () #22 0x2982a100 in ?? () #23 0xbf8fcd28 in ?? () #24 0xbf8fcdbc in ?? () #25 0x2807127f in ?? () #26 0x29808020 in ?? () #27 0x2809aa40 in .got () from /usr/local/lib/libfuse.so.2 #28 0xbf8fccc8 in ?? () #29 0xffdd in ?? () #30 0x in ?? () #31 0x in ?? () #32 0xbf8fccf8 in ?? () #33 0x2807f451 in fuse_fs_fgetattr (fs=0x2982a100, path=0xbf8fcd28 "", buf=0xbf8fcdbc, fi=0x2807127f) at fuse.c:1555 Sorry bad speak English. ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
