Re: r269471 make unusable VT console
On 19.08.2014 18:28, Jean-Sébastien Pédron wrote: Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. -- Jean-Sébastien Pédron ___ 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: r269471 make unusable VT console
On 22 August 2014 01:47, Jean-Sébastien Pédron jean-sebastien.ped...@dumbbell.fr wrote: On 19.08.2014 18:28, Jean-Sébastien Pédron wrote: Here's a first version of the patch I was talking about: https://people.freebsd.org/~dumbbell/vt/vt-vga.5.patch This is now in HEAD, as of r270322. Again, this is unfinished work, but it already brings improvements. Woo! Thanks! -a ___ 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: [PATCH] Packet loss when 'control' messages are present with large data (sendmsg(2))
Bezüglich Yuri's Nachricht vom 02.09.2013 06:54 (localtime): Please check in this patch: http://www.freebsd.org/cgi/query-pr.cgi?pr=181741 Please MFC into 9.X Description of the problem is within PR. Thanks, Yuri Hello, I guess this fix should make it into 10.1. Can someone check please? Thanks, -Harry signature.asc Description: OpenPGP digital signature
Re: [CFT] SSP Package Repository available
On 21 Aug 2014, at 18:07, Bryan Drewery bdrew...@freebsd.org wrote: On 8/21/2014 10:53 AM, Bryan Drewery wrote: On 8/21/2014 5:34 AM, Mark Martinec wrote: Bryan Drewery wrote: Ports now support enabling Stack Protector [1] support on FreeBSD 10 i386 and amd64, and older releases on amd64 only currently. Support may be added for earlier i386 releases once all ports properly respect LDFLAGS. To enable, just add WITH_SSP=yes to your make.conf and rebuild all ports. The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all may optionally be set instead. That's probably SSP_CFLAGS, not SSP_CLFAGS. Nice find. Does clang (in 10-STABLE or CURRENT) support also the option -fstack-protector-strong ? Not sure if clang 3.4 has it, but I found a patch for it here: I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 in CURRENT. Indeed, support for -fstack-protector-strong was added after clang 3.4. Upstream is in the process of releasing clang 3.5; they're currently at -rc3, and unless something weird happens, the actual release should be soonish. That said, it might take a while to get this version into the base system, because there are some problems to overcome. The major one being, after 3.4 llvm and clang require a C++11-compatible compiler and standard library to build. :-) If there is a great demand for -fstack-protector-strong support, I can see if it can be backported to our 3.4 version. -Dimitry signature.asc Description: Message signed with OpenPGP using GPGMail
mkimg used to create gpt image, problem booting
Hi, I did the following: (1) Created a chroot from a src checkout/build with: make installworld DESTDIR=/opt2/branches/test1 make installkernel DESTDIR=/opt2/branches/test1 make distribution DESTDIR=/opt2/branches/test1 (2) Created a UFS image, /tmp/file.img using makefs based on the contents of /opt2/branches/test1 (3) Verified with bhyve that the UFS image booted properly. (4) Created an image with: cd /opt2/branches mkimg -v -s gpt -b test1/boot/pmbr -p freebsd-boot:=test1/boot/gptboot -p freebsd-ufs:=/tmp/file.img -o /tmp/foo1.img (5) Tried to boot the image with qemu: qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img SeaBIOS (version rel-1.7.4-0-g96917a8-20140203_153353-nilsson.home.kraxel.org) iPXE (http://ipxe.org) 00:03.0 C900 PCI2.10 PnP PMM+7FFC6110+7FF26110 C900 Booting from Hard Disk... BTX loader 1.00 BTX version is 1.02 Consoles: internal video/keyboard BIOS drive A: is disk0 BIOS drive C: is disk1 BIOS 639kB/2096120kB available memory FreeBSD/x86 bootstrap loader, Revision 1.1 (r...@dibbler.crodrigues.org, Wed Aug 20 21:58:27 PDT 2014) can't load 'kernel' Type '?' for a list of commands, 'help' for more detailed help. OK If I mdconfig the foo1.img disk image, and do a gpart show, I see: = 3 1784944 md0 GPT (872M) 3 321 freebsd-boot (16K) 35 17849122 freebsd-ufs (872M) Any idea what I am doing wrong? Thanks. -- Craig ___ 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] SSP Package Repository available
2014-08-22 18:07, Dimitry Andric wrote: On 21 Aug 2014, at 18:07, Bryan Drewery bdrew...@freebsd.org wrote: On 8/21/2014 10:53 AM, Bryan Drewery wrote: On 8/21/2014 5:34 AM, Mark Martinec wrote: Does clang (in 10-STABLE or CURRENT) support also the option -fstack-protector-strong ? Not sure if clang 3.4 has it, but I found a patch for it here: I'm told that clang 3.5 has support for it. We do not (yet) have 3.5 in CURRENT. Indeed, support for -fstack-protector-strong was added after clang 3.4. Upstream is in the process of releasing clang 3.5; they're currently at -rc3, and unless something weird happens, the actual release should be soonish. That said, it might take a while to get this version into the base system, because there are some problems to overcome. The major one being, after 3.4 llvm and clang require a C++11-compatible compiler and standard library to build. :-) If there is a great demand for -fstack-protector-strong support, I can see if it can be backported to our 3.4 version. Don't know how much demand there is. Just these days I was investigating what looks like a memory corruption in perl under FreeBSD 10, and realized the -fstack-protector-strong would be just the right thing to try first. (I ended up recompiling perl with gcc48). Just some random references I came across: https://en.wikipedia.org/wiki/Buffer_overflow_protection All Fedora packages are compiled with -fstack-protector since Fedora Core 5, and -fstack-protector-strong since Fedora 20. [...] All Arch Linux packages built since 4 May 2014 use -fstack-protector-strong. https://fedorahosted.org/fesco/ticket/1128 Benefit over the current default -fstack-protector = -fstack-protector is regarded as not secure enough (only protects 2% functions in Chromium project). -fstack-protector-strong hits the balance between the over-simplified -fstack-protector and over-killing -fstack-protector-all. [...] The stack-protector option is over-simplified, which ignores pointer cast, address computation, while the stack-protector-all is over-killing, using this option results in too much performance overhead. http://www.outflux.net/blog/archives/2014/01/27/fstack-protector-strong/ A normal x86_64 “defconfig” build, without stack protector had a kernel text size of 11430641 bytes with 36110 function bodies. Adding CONFIG_CC_STACKPROTECTOR_REGULAR increased the kernel text size to 11468490 (a +0.33% change), with 1015 of 36110 functions stack-protected (2.81%). Using CONFIG_CC_STACKPROTECTOR_STRONG increased the kernel text size to 11692790 (+2.24%), with 7401 of 36110 functions stack-protected (20.5%). And 20% is a far-cry from 100% if support for -fstack-protector-all was added back to the kernel. If there is a great demand for -fstack-protector-strong support, I can see if it can be backported to our 3.4 version. I guess the answer to that question is whether the goal/wish of a default WITH_SSP_PORTS / SSP_CFLAGS would be to switch to the -fstack-protector-strong before clang 3.5 comes into base. Mark ___ 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: r270287: crash
On Thu, Aug 21, 2014 at 09:26:19PM +0200, O. Hartmann wrote: FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I can not see at what point (on modern systems like Ivy Bridge). On older Core2Duo systems I get a trap 12 in APIC or similar. Are you using VirtualBox? I just fixed a crash that fits your description by recompiling virtualbox-ose-kmod. Marcus ___ 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
ktrace -c behavior
What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. ...I would expect the second command to clear the trace point for context switches. It doesn't. I have to specify -tw with the -c to get that behavior. This makes sense; it's just not what I was expecting. Assuming we want to keep this behavior, can we clarify the -c flag in man page? I would suggest: If the -t flag is not specified, clear the default set of trace points. Thanks, Eric ___ 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: ktrace -c behavior
Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. and/or just add specified: Clear the specified trace points ... ...I would expect the second command to clear the trace point for context switches. It doesn't. I have to specify -tw with the -c to get that behavior. This makes sense; it's just not what I was expecting. Assuming we want to keep this behavior, can we clarify the -c flag in man page? I would suggest: If the -t flag is not specified, clear the default set of trace points. Maybe we should add a new trace point string that is a (for all).. so you can do ktrace -ta -c? -- John-Mark Gurney Voice: +1 415 225 5579 All that I will do, has been done, All that I have, has not. ___ 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: ktrace -c behavior
On 08/22/2014 15:20, John-Mark Gurney wrote: Eric van Gyzen wrote this message on Fri, Aug 22, 2014 at 15:16 -0400: What behavior would you expect from this sequence of commands? ktrace -tw -p 1234 ktrace -c -p 1234 Based on this... -c Clear the trace points associated with the specified file or processes. and/or just add specified: Clear the specified trace points ... But what if I didn't specify them? ...I would expect the second command to clear the trace point for context switches. It doesn't. I have to specify -tw with the -c to get that behavior. This makes sense; it's just not what I was expecting. Assuming we want to keep this behavior, can we clarify the -c flag in man page? I would suggest: If the -t flag is not specified, clear the default set of trace points. Maybe we should add a new trace point string that is a (for all).. so you can do ktrace -ta -c? That would be handy. Eric ___ 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: mkimg used to create gpt image, problem booting
On Aug 22, 2014, at 9:49 AM, Craig Rodrigues rodr...@freebsd.org wrote: (5) Tried to boot the image with qemu: qemu-system-x86_64 -m 2048 -hda /tmp/foo1.img *snip* If I mdconfig the foo1.img disk image, and do a gpart show, I see: = 3 1784944 md0 GPT (872M) 3 321 freebsd-boot (16K) 35 17849122 freebsd-ufs (872M) Any idea what I am doing wrong? To the best of my knowledge, qemu is the thing you're doing wrong :-) I have so far not been able to boot an image created by mkimg with a FreeBSD-hosted qemu. o VMware and VirtualBox are fine. o A non-FreeBSD hosted qemu also works fine. If your host is running -current, make sure to set MALLOC_CONF=junk:false. It improves behaviour on FreeBSD for boot0/boo1. HTH (probably not), -- Marcel Moolenaar mar...@xcllnt.net signature.asc Description: Message signed with OpenPGP using GPGMail
Re: [patch] USB after second suspend/resume on ThinkPads.
Hello, Thanks for the patch. It works without any problems on my Thinkpad T400 with FreeBSD 10.0. Best regards Juergen -- Homepage: www.dankoweit.de ___ 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: mkimg used to create gpt image, problem booting
On 22 August 2014 16:45, Marcel Moolenaar mar...@xcllnt.net wrote: I have so far not been able to boot an image created by mkimg with a FreeBSD-hosted qemu. o VMware and VirtualBox are fine. o A non-FreeBSD hosted qemu also works fine. For what it's worth, I have no trouble booting a mkimg-created image with QEMU on FreeBSD, and have been using it regularly for vt(4) and UEFI development. Some particulars: * Host is amd64 stable/10 with some additional MFC candidates (uname reports FreeBSD 10.0-STABLE #1 r268946+94ba9c8(stable-10)) * My mkimg command was mkimg -s gpt -b $ROOTDIR/boot/pmbr -p efi:=$ROOTDIR/boot/boot1.efifat -p freebsd-boot:=$ROOTDIR/boot/gptboot -p freebsd-ufs:=ufs -p freebsd-swap::1M -o img * QEMU installed from the package, qemu-devel-2.0.0_2 * SeaBIOS version info printed at startup is the same as Craig's ___ 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: r270287: crash
On Fri, 22 Aug 2014 15:02:46 -0400 Marcus Reid mar...@blazingdot.com wrote: On Thu, Aug 21, 2014 at 09:26:19PM +0200, O. Hartmann wrote: FreeBSD r270287 crashes/reboots instantanously on loading the kernel. I can not see at what point (on modern systems like Ivy Bridge). On older Core2Duo systems I get a trap 12 in APIC or similar. Are you using VirtualBox? I just fixed a crash that fits your description by recompiling virtualbox-ose-kmod. Marcus I indeed use VirtualBox, but as of this moment, I have disabled the loading of the kernel module. The box still gets stuck and for unknown reason, ALL() CURRENT systems (different generatins of hardware, with or without integrated GPU) show question marks on the screen and no usefull screen when vt is enabled and in backward vga compatible mode. This also happens with nVidia dedicated PCIe GPUs as well as with Ivy Bridge integrated IGP 2500. The port virtualbox-ose-kmod is compiled everytime I compile a kernel/kernel mods via PORTS_MODULES=emulators/virtualbox-ose-kmod in /etc/src.conf. This unmature vt stuff starts to bother. signature.asc Description: PGP signature
[CURRENT]: r270386: unusable console (question marks filling scrren) in vt(), crash/freeze
On different platforms with different graphics hardware, recent CURRENT r 270386 shows a screen filled with question marks when booting, impossible to check the status or make enter commands. The systems don't boot into X11 graphical mode on systems were configured, they freeze. Those freezes/crashes happen on dedicated GPUs (all nVidia with nVidia BLOB). All systems use new vt in vga compat mode/textmode. The question marks occur on all systems, with Intel HD2500/HD2000 iGPU and on dedicated GPU hardware. Except of the nVidia BLOB, the freezing box doesn't load any suspicous kernel (foreign) kernel module (like vboxdrv.ko) at the time. I expect at least the vga textmode console in vt() working. Can the inventor of this mess plaese revert the code to a working version? signature.asc Description: PGP signature
[CURRENT]: r270386: PANIC: ncpus is 0 with non-zero map when vt() is used
Current r 270386 crashes/freezes with a panic: ncpus is 0 with non-zero map when used with vt() console (in text mode, on nVidia GTX560Ti device with nVidia BLOB 343.13). Disabling the nVidia BLOB results in the same crash. signature.asc Description: PGP signature
