[Bug 212011] loader.efi crashes sometimes before loading kernel and causes machine to reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212011 Bug ID: 212011 Summary: loader.efi crashes sometimes before loading kernel and causes machine to reboot Product: Base System Version: 10.3-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: dannvas...@gmail.com CC: freebsd-am...@freebsd.org CC: freebsd-am...@freebsd.org The bootloader component loader.efi sometimes crashes and crashes and forces the computer to reboot, other times it just feezes and does nothing and other times it loads the kernel normally. The issue only appeared after upgrading from 10.2 to 10.3. It worked perfectly under version 10.2 and 10.1. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212011] loader.efi crashes sometimes before loading kernel and causes machine to reboot
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212011 --- Comment #1 from dannvas...@gmail.com --- Created attachment 173894 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173894&action=edit Dmesg output -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
Look! Travelling Provence-Alpes-Côte d'Azur!
Magnificent, fascinating journeys and bright unforgettable impressions experienced during these travels are luxury nowadays. Guide to Provence Provence – the Alpes – Cote d’Azur Alpes-Maritimes Vaucluse Alpes-de-Haute-Provence TOP 10 largest yachts at the Côte d'Azur Bouches-du-Rhone Hautes-Alpes Var The guide to Provence with unique proposals that represent a terrific mix of art, fashion, architecture, gastronomy, with an abundance of things and attention to detail that characterize an exceptional journey. On the pages of our guide to Provence you will find a guidebook consisting of short inspirational stories that offer you to discover the abundant life of the Provence region. Cote d'Azur is one of the most prestigious tourist destinations in the world. Provence as before is a favorite place for recreation and residence. Old cities with monuments of architecture and art, exclusive beach resorts, golf courses, picturesque villages of Provence, high class day spa, majestic and grand Alps. All this luxury and comfort
[Bug 212013] 11.0-RC1: vimage jail with pf not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013 Bug ID: 212013 Summary: 11.0-RC1: vimage jail with pf not working Product: Base System Version: 11.0-RC1 Hardware: Any OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: qja...@a1poweruser.com Tested on 11.0-RC1 with only vimage compiled into the kernel. Tested pf in vnet jail and no firewall on host. Tested pf in vnet jail and on the host. Vnet jail used this /etc/devfs.rules rule [devfsrules_vjail_pf=70] add include $devfsrules_jail add path pf unhide add path pfsync unhide add path pflog unhide Testing no pf firewall running on host, just in vnet jail. When starting vnet jail with pf, I check if pf kernel modules are loaded, if not them load them. Auto loading of modules does not happen. Issuing "ps ax" command on the host show this for pf, 925 - DL0:00.35 [pf purge] Issuing "ifconfig -a" command from the started vnet jail console shows pflog0: flags=0<> metric 0 mtu 33184 groups: pflog The pf log file is allocated but not enabled in the vnet jail. Issuing the pf command "pfctl -sr -vv" from the started vnet jail console show this No ALTQ support in kernel ALTQ related functions disabled @0 block drop in quick on epair23b inet proto tcp from any to any port = nicname [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1301 State Creations: 0 ] @1 pass log (all) quick on epair23b all flags S/SA keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1301 State Creations: 0 ] This at lease seems to indicate pf is running in the vnet jail. Issuing the "ping" command from the started vnet jail console works. Issuing the "whois" command from the started vnet jail console works also, but should not work because of the above block rule on port 43. This indicates that the pf rules in a vnet jail are not functioning. No pf log messages are posted in the vnet jail and no log messages are posted in the hosts pf log. Testing pf firewall running on host and vnet jail. After booting host, Issuing "ps ax" command on the host show this for pf, 393 - DL 0:00.07 [pf purge] 406 - Is 0:00.01 pflogd: [priv] (pflogd) 409 - S0:00.00 pflogd: [running] -s 116 -i pflog0 -f /var/log/pflog (pflo Issuing "ifconfig -a" command from the started vnet jail console shows pflog0: flags=0<> metric 0 mtu 33184 groups: pflog The pf log file is allocated but not enabled in the vnet jail. Issuing the pf command "pfctl -sr -vv" from the started vnet jail console shows this No ALTQ support in kernel ALTQ related functions disabled @0 block drop in quick on epair23b inet proto tcp from any to any port = nicname [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1165 State Creations: 0 ] @1 pass log (all) quick on epair23b all flags S/SA keep state [ Evaluations: 0 Packets: 0 Bytes: 0 States: 0 ] [ Inserted: uid 0 pid 1165 State Creations: 0 ] Issuing the pf command "pfctl -sr -vv" from the host console shows this No ALTQ support in kernel ALTQ related functions disabled @0 pass log (all) quick on fxp0 all flags S/SA keep state [ Evaluations: 24Packets: 9 Bytes: 740 States: 0 ] [ Inserted: uid 0 pid 411 State Creations: 3 ] The vnet jail results are the same as above. But the hosts pf log, logs this on vnet jail startup. pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report v2[|icmp6] pass out on epair23a: :: > ff02::16: HBH ICMP6, multicast listener report v2[|ic pass out on fxp0: :: > ff02::1:ff00:60b: ICMP6, neighbor solicitation[|icmp6] pass out on bridge0: :: > ff02::16: HBH ICMP6, multicast listener report v2[|icm pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report v2[|icmp6] pass out on epair23a: :: > ff02::16: HBH ICMP6, multicast listener report v2[|ic pass out on bridge0: :: > ff02::16: HBH ICMP6, multicast listener report v2[|icm pass out on fxp0: :: > ff02::16: HBH ICMP6, multicast listener report v2[|icmp6] pass out on fxp0: fe80::c1:ff:fe00:60b > ff02::16: HBH ICMP6, multicast listener Issuing the "ping" command from the started vnet jail console works and the hosts pf log shows this pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo reply pass in on bridge0: 8.8.8.8 > 10.23.0.2: ICMP echo reply pass out on fxp0: 10.23.0.2 > 8.8.8.8: ICMP echo request pass in on fxp0: 8.8.8.8 > 10.23.0.2: ICMP echo
[Bug 211958] Boot overflows when reading loader.conf
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211958 --- Comment #1 from commit-h...@freebsd.org --- A commit references this bug: Author: tsoome Date: Sat Aug 20 16:23:20 UTC 2016 New revision: 304532 URL: https://svnweb.freebsd.org/changeset/base/304532 Log: loader is filling fixed length command_errbuf with sprintf() and is trusting strings provided by user/config files. This update is replacing sprintf with snprintf for cases the command_errbuf is built from dynamic content. PR: 211958 Reported by: ect...@gmail.com Reviewed by: imp, allanjude Approved by: imp (mentor), allanjude (mentor) Differential Revision:https://reviews.freebsd.org/D7563 Changes: head/sys/boot/common/boot.c head/sys/boot/common/bootstrap.h head/sys/boot/common/commands.c head/sys/boot/common/interp.c head/sys/boot/common/ls.c head/sys/boot/common/module.c head/sys/boot/efi/loader/arch/amd64/framebuffer.c head/sys/boot/fdt/fdt_loader_cmd.c -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 211990] iscsi fails to reconnect and does not release devices
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211990 --- Comment #5 from Ben RUBSON --- I made further troubleshooting. Regarding the number of iscsid processes which increases, I've found timeout settings which permit to always have only one process per target : sysctl kern.iscsi.login_timeout=85 sysctl kern.iscsi.iscsid_timeout=5 sysctl kern.iscsi.ping_timeout=5 These are based on net.inet.tcp.keepinit which is 75000 by default (75 seconds). Regarding the "30" processes limit, it can be tuned with the "-d" option to iscsid (through /etc/rc.d/iscsid for example). And the most important, regarding the bug : when devices do not want to correctly reconnect, I found that it is because iscsi is stuck in the following : cam_sim_free(is->is_sim, TRUE /*free_devq*/); However I don't know why. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212014] Unable to build non-SMP kernel since r303776
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212014
Bug ID: 212014
Summary: Unable to build non-SMP kernel since r303776
Product: Base System
Version: 10.3-STABLE
Hardware: Any
OS: Any
Status: New
Severity: Affects Only Me
Priority: ---
Component: kern
Assignee: freebsd-bugs@FreeBSD.org
Reporter: g...@grinstead.org
Since r303776 I'm unable to build a custom kernel with "nooptions SMP"
specified. The kernel conf I'm using consists of:
include GENERIC
nooptions SMP
make.conf is empty.
The last excerpt from the compilation is:
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 -f
format-extensions -Wmissing-include-dirs -fdiagnostics-show-option
-Wno-error-tautological-compare
-Wno-error-empty-body -Wno-error-parentheses-equality
-Wno-error-unused-function -nostdinc -I.
-I/usr/src/sys -I/usr/src/sys/contrib/altq -I/usr/src/sys/contrib/libfdt
-D_KERNEL -DHAVE_KERNEL_OPT
ION_HEADERS -include opt_global.h -fno-omit-frame-pointer
-mno-omit-leaf-frame-pointer -mno-aes -mn
o-avx -mcmodel=kernel -mno-red-zone -mno-mmx -mno-sse -msoft-float
-fno-asynchronous-unwind-tables
-ffreestanding -fstack-protector -gdwarf-2 -Werror /usr/src/sys/x86/xen/hvm.c
/usr/src/sys/x86/xen/hvm.c:398:7: error: use of undeclared identifier
'msix_disable_migration'
msix_disable_migration == -1) {
^
/usr/src/sys/x86/xen/hvm.c:409:4: error: use of undeclared identifier
'msix_disable_migration'
msix_disable_migration = 1;
^
2 errors generated.
*** Error code 1
Stop.
The build above is from a system running 10.3-STABLE #0 r303775 amd64, but it
appears to affect i386 with a similar configuration as well.
The same or very similar error appears to be produced when building against
both r303776 and r304519 (the last I've tested against).
I believe all relevant local changes have been rolled back, but unfortunately
I'm not in a position to test a build on a completely fresh install at present.
While I think I have eliminated all likely sources of user meddling, my
apologies in advance if this isn't the case.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212014] Unable to build non-SMP kernel since r303776
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212014 Mark Linimon changed: What|Removed |Added Assignee|freebsd-bugs@FreeBSD.org|j...@freebsd.org --- Comment #1 from Mark Linimon --- Assign to committer of r303776. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212018] [ipsec] Enable IPSEC_NAT_T in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 Bug ID: 212018 Summary: [ipsec] Enable IPSEC_NAT_T in GENERIC kernel configuration Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: geezabiscu...@hotmail.com Since IPSEC has been enabled in the GENERIC kernel I'd also like IPSEC_NAT_T to be enabled. Mobile IPSEC clients often have to deal with connecting to endpoints via NATed IPs. Currently I need to run a custom kernel on my laptop just to add IPSEC_NAT_T support and it makes keeping my system up to date somewhat cumbersome. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212018] [ipsec] Enable IPSEC_NAT_T in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 Darryn Nicol changed: What|Removed |Added Component|kern|conf -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 208529] Error setting up SSL_CTX client key and cert and control-enable: no
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=208529 Stefan changed: What|Removed |Added CC||blach...@b-tu.de --- Comment #5 from Stefan --- Bug still present in 11-RC1. Would be great if the patch could be applied, as this false error spam is just annoying and distracting. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212013] 11.0-RC1: vimage jail with pf not working
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212013 Bjoern A. Zeeb changed: What|Removed |Added CC||b...@freebsd.org --- Comment #1 from Bjoern A. Zeeb --- Just in reply to #3 as you say yourself in your description, it's outgoing packets, but your rule inside the jail specifies "in": 0 block drop in quick on epair23b inet proto tcp from any to any port = nicname Can you change that to "out" and see if it starts working? Currently on your "in" directions whois packets would originate from src port 43 and thus don't match the dest port 43. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212020] Add powerd(8) support for newer AMD CPUs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212020 Bug ID: 212020 Summary: Add powerd(8) support for newer AMD CPUs Product: Base System Version: CURRENT Hardware: amd64 OS: Any Status: New Severity: Affects Many People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: scoobi_...@yahoo.com CC: freebsd-am...@freebsd.org CC: freebsd-am...@freebsd.org Created attachment 173900 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=173900&action=edit Patch to add powerd/cpufreq support for newer AMD CPUs. sys/x86/cpufreq/hwpstate.c provides support for AMD CPUs, but only supports families up to 0x11. The latest AMD CPU family is 0x16. This patch adds support for newer AMD CPUs. (The patch to sys/x86/cpufreq/powernow.c is cosmetic/superfluous.) -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212020] Add powerd(8) support for newer AMD CPUs
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212020 Mark Linimon changed: What|Removed |Added Keywords||patch -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 212018] [ipsec] [request] Enable IPSEC_NAT_T in GENERIC kernel configuration
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=212018 Mark Linimon changed: What|Removed |Added Summary|[ipsec] Enable IPSEC_NAT_T |[ipsec] [request] Enable |in GENERIC kernel |IPSEC_NAT_T in GENERIC |configuration |kernel configuration Assignee|freebsd-bugs@FreeBSD.org|freebsd-...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
