[Bug 190785] New: cpu affinity not work in FreeBSD 10-STABLE
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190785 Bug ID: 190785 Summary: cpu affinity not work in FreeBSD 10-STABLE Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Many People Priority: --- Component: bin Assignee: freebsd-bugs@FreeBSD.org Reporter: gon...@bsdinfo.com.br Hi, Recently noticed the following: # devinfo -rv em0 pnpinfo vendor=0x8086 device=0x105e subvendor=0x8086 subdevice=0x135e class=0x02 at slot=0 function=0 Interrupt request lines: 264 pcib1 I/O port window: 0x4020-0x403f pcib1 memory window: 0xc124-0xc125 0xc126-0xc127 After discovering the irq 264 in interface em0, I did this: # cpuset -l 3 -x 264 Even doing this, the em0 continues migrating to other CPU after a short period of time. You see it happen with: top -PSH. Tested on more than one system with FreeBSD 10-STABLE. FreeBSD .x.xxx.xx 10.0-STABLE FreeBSD 10.0-STABLE #9 r267034: Wed Jun 4 02:22:38 BRT 2014 r...@.x.xxx.xx:/usr/obj/usr/src/sys/GONDIM amd64 -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190786] New: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190786 Bug ID: 190786 Summary: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block Product: Base System Version: 10.0-RELEASE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: kern Assignee: freebsd-bugs@FreeBSD.org Reporter: p5b2e9...@t-online.de While booting these bug warnings are generated: ACPI APIC Table: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x102C/0x0 (20130823/tbfadt-630) ACPI related output of dmesg: > dmesg | grep -i acpi Features=0xafe9fbff ACPI APIC Table: ACPI BIOS Warning (bug): 32/64X length mismatch in FADT/Gpe1Block: 0/32 (20130823/tbfadt-601) ACPI BIOS Warning (bug): Optional FADT field Gpe1Block has zero address or length: 0x102C/0x0 (20130823/tbfadt-630) acpi0: on motherboard acpi_ec0: port 0x62,0x66 on acpi0 acpi0: Power Button (fixed) acpi0: reservation of 0, a (3) failed acpi0: reservation of 10, 3ff0 (3) failed cpu0: on acpi0 attimer0: port 0x40-0x43 irq 0 on acpi0 atrtc0: port 0x70-0x71 irq 8 on acpi0 Timecounter "ACPI-fast" frequency 3579545 Hz quality 900 acpi_timer0: <24-bit timer at 3.579545MHz> port 0x1008-0x100b on acpi0 acpi_lid0: on acpi0 acpi_button0: on acpi0 pcib0: port 0xcf8-0xcff on acpi0 pci0: on pcib0 pcib1: irq 20 at device 28.0 on pci0 pci2: on pcib1 pcib2: at device 30.0 on pci0 pci4: on pcib2 acpi_tz0: on acpi0 atkbdc0: port 0x60,0x64 irq 1 on acpi0 battery0: on acpi0 acpi_acad0: on acpi0 I do not know if the lines with "failed" are related to this bug. But it is worth hinting to this. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190787] OCZ-AGILITY3 SSD Not Detected
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190787 David Chisnall changed: What|Removed |Added CC||thera...@freebsd.org Component|standards |kern Assignee|freebsd-standards@FreeBSD.o |freebsd-bugs@FreeBSD.org |rg | --- Comment #3 from David Chisnall --- Reassign. This is a kernel bug, not a standards issue. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 174905] [patch] make cron(8) honor rfc821, rfc5321, rfc2076, rfc3834
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=174905 Olli Hauer changed: What|Removed |Added Version|1.0-CURRENT |unspecified Severity|Affects Only Me |Affects Many People -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190793] New: Some rc scripts return non zero status on success
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190793
Bug ID: 190793
Summary: Some rc scripts return non zero status on success
Product: Base System
Version: 10.0-STABLE
Hardware: Any
OS: Any
Status: Needs Triage
Severity: Affects Some People
Priority: ---
Component: conf
Assignee: freebsd-bugs@FreeBSD.org
Reporter: belzeb...@gmail.com
Created attachment 143528
--> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=143528&action=edit
remove "[ foo ] && bar" hack
Rc scripts (/etc/rc.d/*) is written to return status returned by the last
executed command. This is correct behavior, but it cause problems with
construction like this:
[ -n "${foo}" ] && echo '.'
This construction may return 1 and if it is the last command, whole script
return 1. This behavior was certainly not intended, I guess. So construction
above should be changed into correcrt form:
if [ -n "${foo}" ]; then
echo '.'
fi
I find this bug in /etc/rc.d/routing, but more scripts are affected. Situation
when bug appear depends on configuration of services. Patch removing this hack
from all scripts is attached.
--
You are receiving this mail because:
You are the assignee for the bug.
___
freebsd-bugs@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-bugs
To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 184507] [patch] [libfetch] allow hiding User-Agent with empty string
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=184507 Baptiste Daroussin changed: What|Removed |Added Status|Commit Ready|Needs MFC CC||b...@freebsd.org -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190718] Error during installing collectd5 on amd64 FreeBSD8.4 via port
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190718 Baptiste Daroussin changed: What|Removed |Added CC||b...@freebsd.org Component|bin |Individual Port(s) Version|8.4-RELEASE |Latest Assignee|freebsd-bugs@FreeBSD.org|freebsd-ports-bugs@FreeBSD. ||org Product|Base System |Ports Tree --- Comment #1 from Baptiste Daroussin --- This is a ports bug -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 121073] [kernel] [patch] run chroot as an unprivileged user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 Nathan Whitehorn changed: What|Removed |Added Attachment #84994|0 |1 is obsolete|| CC||nwhiteh...@freebsd.org --- Comment #6 from Nathan Whitehorn --- Created attachment 143547 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=143547&action=edit Prevents escape from unprivileged chroot This fixes the issue of using this feature to escape from a chroot established with privileges after dropping them by the simple expedient of unconditionally preventing unprivileged chroot while already in a chroot. The second issue raised (MAC transitions) I know nothing about and cannot address. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 121073] [kernel] [patch] run chroot as an unprivileged user
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=121073 --- Comment #7 from ji...@quis.cx --- I remember someone saying this could be exploited using rfork. I don't know why it's not listed in this bug. IIRC the problem was that fd_rdir (root of the processes) was stored in proc->p_fd (struct filedesc) and the P_NOSUGID-flag in struct proc itself. One could use rfork to create a new process with the same descriptor table and call chroot in the child which would flag the child with P_NOSUGID but change to root for the parent as well. The parent doesn't get P_NOSUGID however and will be able to execve a setuid executable with a fake libc. -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
[Bug 190818] New: /etc/rc.d/netif enters an endless cycle when ipv6 aliases are configured
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=190818 Bug ID: 190818 Summary: /etc/rc.d/netif enters an endless cycle when ipv6 aliases are configured Product: Base System Version: 10.0-STABLE Hardware: Any OS: Any Status: Needs Triage Severity: Affects Some People Priority: --- Component: misc Assignee: freebsd-bugs@FreeBSD.org Reporter: e...@norma.perm.ru In a setup like this ifconfig_vlan1="192.168.3.22/24 vlan 1 vlandev bce0" ifconfig_vlan1_alias0="inet 192.168.3.13/32 vhid 5 advskew 50 pass XX" ifconfig_vlan1_alias1="inet 192.168.3.1/32 vhid 5 advskew 50 pass XX" ifconfig_vlan1_alias2="inet6 fd00::301 prefixlen 120 vhid 5 advskew 50 pass XX -accept_rtadv" ifconfig_vlan15="192.168.7.7/24 vlan 15 vlandev bce0" ifconfig_vlan15_alias0="inet 192.168.7.2/24" ifconfig_vlan15_alias1="inet 192.168.7.6/24 vhid 7 advskew 50 pass XX" ifconfig_vlan15_alias2="inet6 fd00::701 prefixlen 120 vhid 7 advskew 50 pass XX" rtadvd_interfaces="vlan1 vlan15" ifconfig_vlan1_ipv6="inet6 fd00::0316 prefixlen 120 -accept_rtadv" ifconfig_vlan15_ipv6="inet6 fd00::0702 prefixlen 120 -accept_rtadv" FreeBSD can never enter a multiuser because the startup process is stuck in an endless cycle. For some reason ifalias_expand_addr() is called with ipv6 arguments instead of ifalias_expand_addr_inet6. May be carp has something to do with it. In the video provided the server tried to boot with the config above, it enters the first endless cycle on first interface, after a while I hit Ctrl-C repeatedly, the booting process immediately enters the endless cycle in the second interface, after a bunch of Ctrl-C it finally boots up. Link: http://unix.zhegan.in/files/output.mkv (about 8 megs, x264-encoded video from server's ipkvm). -- You are receiving this mail because: You are the assignee for the bug. ___ freebsd-bugs@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-bugs To unsubscribe, send any mail to "freebsd-bugs-unsubscr...@freebsd.org"
