http://permalink.gmane.org/gmane.os.freebsd.current hourly 1 1901-01-01T00:00+00:00 http://gmane.org/img/gmane-25t.png http://gmane.org http://permalink.gmane.org/gmane.os.freebsd.current/142281 <pre>Good day. I had created patches for OpenSSH to resurrect handling of VersionAddendum and, additionally, enable/disable advertisements for HPN feature in sshd version banner. des&lt; at &gt;, bz&lt; at &gt; and brooks&lt; at &gt; are aware of this patch, Bjoern even reviewed the first version of the patch, but the second one isn't yet reviewed. Can anyone who uses SSH test this patch and report their findings to the respective PR. Also, code reviews are welcome too. Thanks! PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=163843 Patches: * 8-STABLE, http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling-8-STABLE.diff * 9-STABLE, http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling-9-STABLE.diff * 10-CURRENT, http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling.diff Instructions: {{{ cd /usr/src fetch -o ssh-addendum.diff http://codelabs.ru/fbsd/patches/openssh/OpenSSH-fix-VersionAddendum-handling.diff patch -p1 &lt; ssh-addendum.diff cd secure/lib/libssh ma</pre> Eygene Ryabinkin 2012-05-26T10:34:20 http://permalink.gmane.org/gmane.os.freebsd.current/142280 <pre>Hi, I'm glad to hear this :) I'll try to fix suspend/resume related problems when I have spare time. Thanks! _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Mitsuru IWASAKI 2012-05-26T08:37:27 http://permalink.gmane.org/gmane.os.freebsd.current/142278 <pre> Yes, I do. This very moment, I got rid of those messages. I think it is not very clear to me (and maybe others) anymore, what goes into /etc/src.conf and what is to be remaining in /etc/make.conf. Since I wrecked all my FreeBSD 10-0-CURRENT boxes around the 15th of May by simply building a "world" (on a daily baisis, so they got affected all), but was luckily able to repair, I guess I need to figure out what's really necessary to go in /etc/src.conf and in /etc/make.conf. There are some mails in this list claiming that setting CC=, CXX= and CPP= needs also to be done in /etc/src.conf. I have those already set in /etc/make.conf using a "knob" for checking to build with CLANG or not. Well, am I right that first /etc/make.conf gets read and then /etc/src.conf? By mistake I set "CFLAGS=" instead of "CFLAGS+=" in /etc/src.conf, so all settings performed prior to the "sucking in" of /etc/src.conf got banned from the options - and ended up in not finding even includes anymore (due to missing -Ifoo/bar options).</pre> O. Hartmann 2012-05-26T06:48:09 http://permalink.gmane.org/gmane.os.freebsd.current/142276 <pre> On May 25, 2012, at 11:55 AM, Bjoern A. Zeeb wrote: Thank you!!! It was a bit of a surprise (and a little time to diagnose) to find that LRO was breaking forwarding. Guy -------- This message has been scanned by ComplianceSafe, powered by Palisade's PacketSure. _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Guy Helmer 2012-05-25T17:05:17 http://permalink.gmane.org/gmane.os.freebsd.current/142275 <pre>Hey, last night I pushed in the essential offloading support changes for IPv6 along with quite a bit of other "noise" into HEAD. There is more locking improvements etc. to come once I have looped things back to my working tree and Michael Tuexen will improve SCTP/v6 on loopback as well soonish. This is a call for testing. The in-tree cxgb(4) and ixgbe(4) drivers have been updated to make use of the new features (TSO6/LRO6), and more drivers will follow (I already have cxgbe done, talking about mxge, ..) but others should also see improvements for at least upper layer protocol checksum calculations and I'd love people to test with as many drivers as possible, as I plan to merge it for the upcoming 9.1-RELEASE cycle and wouldn't want to ship broken IPv6 in a few months;-) Here's the patch that should just apply to stable/9 matching what I put into HEAD (+ an earlier cxgb change) (untested): http://people.freebsd.org/~bz/20120525-01-ipv6-offload-mfc9.diff If you need a patch for a specific release pleas</pre> Bjoern A. Zeeb 2012-05-25T16:55:28 http://permalink.gmane.org/gmane.os.freebsd.current/142274 <pre>To respond to my own mail again: * should the cardbus slot peripherals be detached and reattached upon resume? Or should it be just suspend/resumed? * here's what I see during suspend: wlan1: link state changed to DOWN [100741]: ieee80211_reset_bss: iv_bss=0xc969e000, new iv_bss=0xc96a5000 [100480] cbb0: Opening memory: [100480] ath1: detached pci0:21:0:0: Transition from D0 to D2 [100480] pci21: failed to set ACPI power state D2 on \\_SB_.PCI0.PCI1.CDBS: AE_BAD_PARAMETER [100480] vga0: saving 4612 bytes of video state [100480] vga0: saving color palette [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP0: AE_BAD_PARAMETER [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP1: AE_BAD_PARAMETER [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP2: AE_BAD_PARAMETER [100480] pci0: failed to set ACPI power state D2 on \\_SB_.PCI0.EXP3: AE_BAD_PARAMETER .. would someone with some ACPI clue please help me figure out how broken the ACPI code in my T60 BIOS is? :) </pre> Adrian Chadd 2012-05-25T16:52:15 http://permalink.gmane.org/gmane.os.freebsd.current/142272 <pre> This is very true for reads, not for writes because it is a COW filesystem so writes are usually sequencial disk-wise. </pre> Jeremie Le Hen 2012-05-25T12:58:57 http://permalink.gmane.org/gmane.os.freebsd.current/142271 <pre>Hi, On Fri, 25 May 2012, Niclas Zeising wrote: NZ&gt;Sometime quite recent a change to FreeBSD CURRENT makes it almost impossible NZ&gt;to run it as a virtualbox guest, at least under Windows. If I roll back the NZ&gt;vbox machine to a (unfortunately quite old, from January) CURRENT everything NZ&gt;seems to be working. NZ&gt;The issue is that the virtual machine runs very very slow, and makes the host NZ&gt;almost impossible to work with, especially during compiles and other NZ&gt;activities involving the CPU and the disk. I have also experienced that the NZ&gt;host machine crashes, but that might be unrelated. NZ&gt;Is anyone else experiencing this, or am I doing something very wrong? I'm running current compiled with CLANG on the latest stable virtualbox under Win7. It works good, the only issue I had a couple of days ago when compiling world with -j4 (I've a 2-core with HTT) was that the CPUs were not raising their speed. They were just running on 780MHz and the compilation took half a day. A reboot of windows 'fixed' thi</pre> Harti Brandt 2012-05-25T11:53:45 http://permalink.gmane.org/gmane.os.freebsd.current/142270 <pre>Hi! Sometime quite recent a change to FreeBSD CURRENT makes it almost impossible to run it as a virtualbox guest, at least under Windows. If I roll back the vbox machine to a (unfortunately quite old, from January) CURRENT everything seems to be working. The issue is that the virtual machine runs very very slow, and makes the host almost impossible to work with, especially during compiles and other activities involving the CPU and the disk. I have also experienced that the host machine crashes, but that might be unrelated. Is anyone else experiencing this, or am I doing something very wrong? Let me know if I need to provide more information or if I can help in some other way. Best Regards! _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Niclas Zeising 2012-05-25T11:30:57 http://permalink.gmane.org/gmane.os.freebsd.current/142269 <pre>To respond to my own email: * if I unload cbb/pccard/cardbus and reload them, suddenly the slot works. * I've been toying with S3 suspend to RAM, so I wondered if it were that. Yes, it seems to be suspend related. I'll do some more thorough testing tomorrow, but once I suspend, the ath(4) NIC gets detached from the cardbus slot, then upon resume the NIC isn't found (bus timeout) and won't be until I unload/reload the modules. Should pccard/cbb/cardbus 'properly' handle S3 suspend/resume? Does it work for anyone else? Adrian _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Adrian Chadd 2012-05-25T07:53:33 http://permalink.gmane.org/gmane.os.freebsd.current/142268 <pre>Hi all, I've just upgraded to 9-stable and I'm seeing the following error on my Lenovo Thinkpad T60. 'cbb0: Warning: Bus reset timeout' This is a very recent bug. I was running 9-stable from about 3 weeks ago (before BSDCan 2012) and cardbus was working fine. Would anyone have any culprit commits for me to try reverting? Having cardbus work on these lenovo thinkpads is very important to me and ath(4) development. :) Thanks, adrian _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Adrian Chadd 2012-05-25T07:38:26 http://permalink.gmane.org/gmane.os.freebsd.current/142267 <pre> If your disk dies then you need a redundant copy of your data - either via backups or via RAID. Normally, you'd run ZFS with some level of redundancy so that disk failures did not result in data loss. That said, ZFS is touchier about data - if it can't verify the checksums in your data, it will refuse to give it to you - whereas UFS will hand you back a pile of bytes that may or may the same as what you gave it to store. And you can't necessarily get _any_ data off a failed disk. 4TB disks are available but not really economical at present. 2TB disks still seem to be the happy medium. If your data will compress down to 2TB then save it to a disk, otherwise split your backups across a pair of disks. A 2TB disk with enclosure is &lt;&lt;USD150. If you don't trust that, buy a second set. (And if you value your data, get a trusted friend to store one copy at their house in case anything happens at your house). I have had lots of problems at $work with Solaris UFS quietly corrupting data following crashes.</pre> Peter Jeremy 2012-05-24T21:01:28 http://permalink.gmane.org/gmane.os.freebsd.current/142266 <pre> Updated to r235926 &amp; kernel build completed successfully. Sevan _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Sevan / Venture37 2012-05-24T20:50:02 http://permalink.gmane.org/gmane.os.freebsd.current/142265 <pre> We actually use it in very random high IOP's applications with small requests, so high standard disk's aren't even an option so SDD's all the way and we see nice performance. I can't say we've compared it to say FFS as that simply doesn't provide the management tools we needed so wasn't even considered, but its far from shabby in our environment :) Regards Steve ================================================ This e.mail is private and confidential between Multiplay (UK) Ltd. and the person or entity to whom it is addressed. In the event of misdirection, the recipient is prohibited from using, copying, printing or otherwise disseminating it or any information contained in it. In the event of misdirection, illegible or incomplete transmission please telephone +44 845 868 1337 or return the E.mail to postmaster&lt; at &gt;multiplay.co.uk. _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send </pre> Steven Hartland 2012-05-24T20:30:17 http://permalink.gmane.org/gmane.os.freebsd.current/142264 <pre>2012/5/7 Steve Wills &lt;swills&lt; at &gt;freebsd.org&gt; hm.. looks like problem is still here. I'm trying update my r234992 to r235887 http://pastebin.com/stm7b8hQ _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Sergey Dyatko 2012-05-24T20:10:59 http://permalink.gmane.org/gmane.os.freebsd.current/142263 <pre> - ZFS is not optimal for situations where there are a lot of small, randomly dispersed IOs around the disk space. Like in any sort of RDBMS. Even so, ZFS is certainly my personal default nowadays. On a machine of any size, the question is not "should I use ZFS?" but "are there any good reasons why I shouldn't use ZFS? (And if so, what could I do to make it possible to use ZFS anyhow...)" With Andriy's recent patches to zfsboot to extend support for Boot Environments, it's all starting to look particularly sexy. Cheers, Matthew </pre> Matthew Seaman 2012-05-24T19:58:52 http://permalink.gmane.org/gmane.os.freebsd.current/142262 <pre> - ZFS is not optimal for situations where there are a lot of small, randomly dispersed IOs around the disk space. Like in any sort of RDBMS. Even so, ZFS is certainly my personal default nowadays. On a machine of any size, the question is not "should I use ZFS?" but "are there any good reasons why I shouldn't use ZFS? (And if so, what could I do to make it possible to use ZFS anyhow...)" With Andriy's recent patches to zfboot to extend support for Boot Environments, it's all starting to look particularly sexy. Cheers, Matthew </pre> Matthew Seaman 2012-05-24T19:58:38 http://permalink.gmane.org/gmane.os.freebsd.current/142261 <pre> Something is going wrong with your include paths; most likely your CFLAGS gets mangled. The actual mkdep command line should have been similar to (wrapped for clarity): CC='clang' \ mkdep \ -f .depend \ -a \ -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/include \ -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/tools/clang/include \ -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen \ -I. \ -I/usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/../../lib/clang/include \ -DLLVM_ON_UNIX \ -DLLVM_ON_FREEBSD \ -D__STDC_LIMIT_MACROS \ -D__STDC_CONSTANT_MACROS \ -DLLVM_DEFAULT_TARGET_TRIPLE=\"i386-unknown-freebsd10.0\" \ -DDEFAULT_SYSROOT=\"\" \ -I/usr/obj/usr/src/tmp/legacy/usr/include \ /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Error.cpp \ /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Main.cpp \ /usr/src/lib/clang/libllvmtablegen/../../../contrib/llvm/lib/TableGen/Record.cp</pre> Dimitry Andric 2012-05-24T19:29:52 http://permalink.gmane.org/gmane.os.freebsd.current/142260 <pre> I've seen these too, and it seems clang produces debug info which ctfconvert can't handle, for some reason. However, in my case, the kernel build doesn't abort at all, it continues and all the object files seem to work just fine. I don't know much much about the dtrace/ctfconvert stuff though, so I will have to ask somebody else to step up to investigate, and hopefully fix it. :) ... Ah, I think that it works for me, because I don't define STRIP to empty. Just as an experiment, can you try commenting that setting, and do a clean build of your kernel? _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Dimitry Andric 2012-05-24T19:21:49 http://permalink.gmane.org/gmane.os.freebsd.current/142259 <pre> Hence I dropped it in current. I have not exhausted all options, because I keep discovering things. And given the long time with FreeBSD, I tend to reexamine man pages to see what people have added and/or documented. So before I start hammering at the scripts, I'll need to go through wat is already there.. Thanx, --WjW _______________________________________________ freebsd-current&lt; at &gt;freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscribe&lt; at &gt;freebsd.org" </pre> Willem Jan Withagen 2012-05-24T18:01:28 http://permalink.gmane.org/gmane.os.freebsd.current/142258 <pre>Hi I'm unable to build the generic kernel, seeing lots of "failed to retrieve array bounds" errors (129 to be exact) starting with ERROR: scsi_all.c: die 43574: failed to retrieve array bounds &amp; stoping at cc -c -O2 -pipe -fno-strict-aliasing -std=c99 -g -Wall -Wredundant-decls -Wnested-externs -Wstrict-prototypes -Wmissing-prototypes -Wpointer-arith -Winline -Wcast-qual -Wundef -Wno-pointer-sign -fformat-extensions -Wmissing-include-dirs -fdiagnostics-show-option -Wno-error-tautological-compare -Wno-error-empty-body -Wno-error-parentheses-equality -nostdinc -I. -I/usr/src/sys -I/usr/src/sys/contrib/altq -D_KERNEL -DHAVE_KERNEL_OPTION_HEADERS -include opt_global.h -fno-omit-frame-pointer -mno-aes -mno-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float -fno-asynchronous-unwind-tables -ffreestanding -fstack-protector -Werror /usr/src/sys/dev/ata/ata-card.c ctfconvert -L VERSION -g aic_pccard.o ctfconvert -L VERSION -g ata-card.o ctfconvert -L VERSION -g intel_dp.o ERROR: intel</pre> Sevan / Venture37 2012-05-24T17:13:06 Search the mailing list at Gmane query http://search.gmane.org/?group=$group=gmane.os.freebsd.current