[Bug 233764] [amdtemp] does not know correct offset for AMD Family 15h (A8-7600, FX-8300, etc) Tctl
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=233764 Alexey Dokuchaev changed: What|Removed |Added CC||da...@freebsd.org --- Comment #23 from Alexey Dokuchaev --- Unfortunately, our amdtemp(4) driver is doing the best it can according to the spec. Starting with the Phenoms, AMD's digital sensor no longer reports an absolute temperature value anymore, but a reading with a certain offset, which isn't really known; it might not even be constant per CPU type. I believe that some proprietary tools employ certain tricks or use undocumented pieces of knowledge to make up for this, but e.g. Open Hardware Monitor uses the same formula as FreeBSD plus allows to specify configurable "offset" which is zero by default: ((Tctl >> 21) & 0x7FF) / 8.0f. That is, Tctl is a non-physical temperature on an arbitrary scale (confusingly) measured in degrees Celsius with a resolution of 1/8th degree. AMD designed this equation to accurately read load temperatures (45°C+). It has an equational offset to determine them which equalizes at 45́°C. Since it's designed for peak values and is a non-physical temperature it cannot read idle temperatures or account for ambient temperature correctly. That's why popular tools like HWinfo64, MWmonitor, or Aida64 usually report two values: one for the socket and another for the core temperature. The socket value is what you should look at if you want an idea of idle temperature and the core one for the CPU temperature under load. I understand that it's somewhat frustrating to see BIOS and AMD Overdrive reporting seemingly sane temperatures across the entire spectrum, but it is most likely a cumulative reading from a number of different sensors, most of which are out of scope of amdtemp(4) or even undocumented at all. -- 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 234985] epair: Kernel panic when destroying epair interface of vnet jail after using ifconfig inside the jail
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=234985 Kubilay Kocak changed: What|Removed |Added Status|New |Open Summary|kernel panic when |epair: Kernel panic when |destroying epair interface |destroying epair interface |of vnet jail after using|of vnet jail after using |ifconfig inside the jail|ifconfig inside the jail See Also||https://bugs.freebsd.org/bu ||gzilla/show_bug.cgi?id=2388 ||70 Keywords|panic |crash, needs-patch, ||needs-qa Assignee|b...@freebsd.org|n...@freebsd.org Flags||mfc-stable12- CC||n...@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"
[Bug 242008] Installation on BananaPi fails: mmc0: Failed to set VCCQ for card at relative address 1
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242008 --- Comment #2 from Helmut --- I booted FreeBSD-12.1 verbosely and with kern.smp.disabled=1 and got the following output in the serial console: usbus0: 480Mbps High Speed USB v2.0 usbus1: 12Mbps Full Speed USB v1.0 usbus2: 480Mbps High Speed USB v2.0 usbus3: 12Mbps Full Speed USB v1.0 axp2xx_pmu0: Powered by AC aw_mmc0: Powering up sd/mmc mmc0: Probing bus ugen0.1: at usbus0 uhub0: on usbus0 ugen1.1: at usbus1 uhub1: on usbus1 ugen2.1: at usbus2 uhub2: on usbus2 ugen3.1: at usbus3 uhub3: on usbus3 mmc0: SD 2.0 interface conditions: OK mmc0: SD probe: OK (OCR: 0x00ff8000) mmc0: Current OCR: 0x00ff8000 mmc0: Probing cards mmc0: New card detected (CID 2842454e4434474221562a275e0107e7) mmc0: New card detected (CSD 400e00325b591ddd7f800a4000e9) mmc0: Card at relative address 0x59b4 added: mmc0: card: SDHC ND4GB 2.1 SN 562A275E MFG 07/2016 by 40 BE mmc0: quirks: 0 mmc0: bus: 4bit, 50MHz (high speed timing) mmc0: memory: 7829504 blocks, erase sector 8192 blocks mmc0: setting transfer rate to 50.000MHz (high speed timing) mmcsd0: 4GB at mmc0 50.0MHz/4bit/32768-block regulator: shutting down vcc3v0 regulator: shutting down vcc3v3 regulator: shutting down vcc5v0 regulator: shutting down ldo3 Trying to mount root from ufs:/dev/ufs/rootfs [rw]... GEOM: new disk mmcsd0 mmc0: setting bus width to 4 bits high speed timing mmc0: Failed to set VCCQ for card at relative address 22964 GEOM_PART: partition 1 on (mmcsd0, MBR) is not aligned on 4194304 bytes GEOM_PART: partition 2 on (mmcsd0, MBR) is not aligned on 4194304 bytes aw_mmc0: error rint: -- 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 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 Bug ID: 242744 Summary: IPSec in transport mode between FreeBSD hosts blackholes TCP traffic Product: Base System Version: 12.1-RELEASE Hardware: Any OS: Any Status: New Severity: Affects Some People Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: v...@sibptus.ru When you configure transport mode IPSec between two FreeBSD hosts (no tunnels or if_ipsec), TCP connectivity between those hosts breaks. It happens because a) ESP packets are always generated with the DF flag set, b) PMTUD does not work in IPSec transport mode because there is no interface (?) c) when TCP segments of standard size are encapsulated into ESP packets, the resulting oversized ESP packets cannot pass through any interface with MTU=1500, nor can they be fragmented because of the DF flag, so they are just blackholed and never leave the host. How to reproduce. Configure a simple transport mode IPSec between two FreeBSD hosts and try to scp files from one host to another. The file transfer will inevitably stall, until you clear all IPSec policies. Watch with tcpdump: all ESP packets have the DF flag set, but large ESP packets will be missing. A workaround. A host route to the peer with "-mtu 1400" can be configured as described in https://lists.freebsd.org/pipermail/freebsd-net/2019-December/054952.html but it is not scalable. What is to be done. ESP packets should not have the DF flags set by default for things to "just work." I've checked that the net.inet.ipsec.dfbit does not affect transport mode. Regardless of its value, the DF flag is always on. -- 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 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 --- Comment #1 from Victor Sudakov --- All the above seems to be valid for IPv6 too. -- 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 242727] MII device leaks memory on detach
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242727 Mark Johnston changed: What|Removed |Added Assignee|b...@freebsd.org|ma...@freebsd.org Status|New |In Progress CC||ma...@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"
[Bug 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 dewa...@heuristicsystems.com.au changed: What|Removed |Added CC||dewa...@heuristicsystems.co ||m.au --- Comment #2 from dewa...@heuristicsystems.com.au --- Victor - are you using asymmetric keys between hosts during this phase of testing, or are you using pre-shared keys? If asymmetric, can you try with insecure keys (so the key can be transmitted within a packet)? -- 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 242746] Deleting (or re-setting) an IP address with ifconfig holds (leaks?) memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746 Bug ID: 242746 Summary: Deleting (or re-setting) an IP address with ifconfig holds (leaks?) memory Product: Base System Version: CURRENT Hardware: Any OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: ghuckri...@blackberry.com Overview: Setting an IP address consumes 'ifaddr' typed memory. When destroying the IP address the memory is not freed. This memory does not appear to be collected later, as running the below script shows no recovery after continuously re-setting the ip address for 16 hours. The leaked memory was tracked down to the ifa_alloc() function, see line 845 of https://svnweb.freebsd.org/base/head/sys/net/if.c?revision=355070&view=markup Instrumenting the code revealed that there are more ifa_ref() calls than ifa_free() calls. This results in the memory being held, as the system believes there is still a reference to this memory. Steps to Reproduce: 'ifconfig inet' an address and then 'ifconfig inet delete' it. Actual Results: # vmstat -m | grep ifaddr ifaddr 14136K - 235 16,32,64,128,256,512,2048,4096 # # ifconfig em1 inet 192.168.200.44 # vmstat -m | grep ifaddr ifaddr 14236K - 236 16,32,64,128,256,512,2048,4096 # ifconfig em1 inet delete 192.168.200.44 # vmstat -m | grep ifaddr ifaddr 14236K - 236 16,32,64,128,256,512,2048,4096 # cat /tmp/loop while true do ifconfig em1 192.168.200.33 sleep 1 vmstat -m | grep ifaddr done # /tmp/loop ifaddr 13537K - 294 16,32,64,128,256,512,2048,4096 ifaddr 13638K - 295 16,32,64,128,256,512,2048,4096 ifaddr 13738K - 296 16,32,64,128,256,512,2048,4096 ifaddr 13839K - 297 16,32,64,128,256,512,2048,4096 snip (16 hours worth of logs)... ifaddr 1834875 917406K - 1835088 16,32,64,128,256,512,2048,4096 ifaddr 1834876 917407K - 1835089 16,32,64,128,256,512,2048,4096 ifaddr 1834877 917407K - 1835090 16,32,64,128,256,512,2048,4096 ifaddr 1834878 917408K - 1835091 16,32,64,128,256,512,2048,4096 ifaddr 1834879 917408K - 1835092 16,32,64,128,256,512,2048,4096 ^C # Expected Results: Not to leak/hold onto memory. Build Date & Hardware: HEADr355854 on amd64 target with any networking interface -- 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 242747] AMD Epyc+GELI not using Hardware AES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242747 Bug ID: 242747 Summary: AMD Epyc+GELI not using Hardware AES Product: Base System Version: 12.1-RELEASE Hardware: amd64 OS: Any Status: New Severity: Affects Only Me Priority: --- Component: kern Assignee: b...@freebsd.org Reporter: nev...@talkpoint.com Created attachment 210085 --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=210085&action=edit Xeon/Epyc Server Information I have two similar systems I'm testing as database hardware. Both consist of 8x Samsung 860 Pro SSD's attached to LSI9003-8i, 256GB ram, equal chassis/backplane. The only variance is one server is an Epyc 7371, and the other a Xeon Gold 6130. I've attached some command snippets to show configuration info There are 8 configured SSD's in each all the same setup as the ones I listed in a ZFS raid 10 setup with 4 mirrored vdevs. I'm aware that GELI is setup with 4k aligned sectors vs the drives reported 512 bytes, it should be a non-factor for the behavior I'm seeing. Long and short is, despite the Epyc box reporting that it supports AES like the Xeon as well as GELI showing Crypto: hardware, when I extract a tar of my 100GB test database to each server the load of the Epyc box is significantly higher with top showing tons of CPU time on g_eli threads that the Xeon does not have when in hardware mode. When I disable the aesni and cryptodev modules on the Xeon I get the same behavior with high g_eli thread load which leads me to believe that depsite Epyc/GELI reporting they're using hardware AES it's actually still running in software mode. I've tried with both AES-XTS and AES-CBC modes for GELI with the same behavior. Both servers are fully research at the moment so I can try any necessary tests/fixes to drill down on this. -- 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 242747] geli: AMD Epyc+GELI not using Hardware AES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242747 Kubilay Kocak changed: What|Removed |Added Summary|AMD Epyc+GELI not using |geli: AMD Epyc+GELI not |Hardware AES|using Hardware AES Severity|Affects Only Me |Affects Some People Status|New |Open Flags||mfc-stable12?, ||mfc-stable11? Keywords||needs-qa, performance -- 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 242746] ifconfig: Deleting (or re-setting) an IP address holds (leaks?) memory
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242746 Kubilay Kocak changed: What|Removed |Added Summary|Deleting (or re-setting) an |ifconfig: Deleting (or |IP address with ifconfig|re-setting) an IP address |holds (leaks?) memory |holds (leaks?) memory CC||n...@freebsd.org Severity|Affects Only Me |Affects Many People Flags||mfc-stable12?, ||mfc-stable11? Status|New |Open Keywords||needs-patch, needs-qa Assignee|b...@freebsd.org|n...@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"
[Bug 242747] geli: AMD Epyc+GELI not using Hardware AES
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242747 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|g...@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"
[Bug 242744] IPSec in transport mode between FreeBSD hosts blackholes TCP traffic
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242744 Mark Linimon changed: What|Removed |Added Assignee|b...@freebsd.org|n...@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"
[Bug 241710] please increase ARG_MAX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710 --- Comment #27 from commit-h...@freebsd.org --- A commit references this bug: Author: pfg Date: Sat Dec 21 02:40:41 UTC 2019 New revision: 355968 URL: https://svnweb.freebsd.org/changeset/base/355968 Log: MFC r355828: Double the size of ARG_MAX on LP64 platforms. As modern software keeps growing in size, we get requests to update the value of ARG_MAX in order to link the resulting object files. Other OSs have much higher values but increasiong ARG_MAX has a multiplied effect on KVA, so just bumping this value is dangerous in some archs like ARM32 that can exhaust KVA rather easily. While it would be better to have a unique value for all archs, other OSs (Illumos in particular) can have different ARG_MAX limits depending on the platform, For now we want to be really conservative so we are avoidng the change on ILP32 and in the alternative case we only double it since that seems to work well enough for recent Code Aster. Bump the _FreeBSD_version for this change. PR: 241710 Changes: _U stable/12/ stable/12/sys/sys/param.h stable/12/sys/sys/syslimits.h -- 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 241710] please increase ARG_MAX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710 --- Comment #28 from commit-h...@freebsd.org --- A commit references this bug: Author: pfg Date: Sat Dec 21 03:01:06 UTC 2019 New revision: 53702 URL: https://svnweb.freebsd.org/changeset/doc/53702 Log: Double the size of ARG_MAX on LP64 platforms. Document the _FreeBSD_version updates corresponding to this change. PR: 241710 Changes: head/en_US.ISO8859-1/books/porters-handbook/versions/chapter.xml -- 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 241710] please increase ARG_MAX
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241710 Pedro F. Giffuni changed: What|Removed |Added Status|In Progress |Closed Resolution|--- |FIXED --- Comment #29 from Pedro F. Giffuni --- OK, the new limit should hold ... - i386 is being unfairly penalized, - Still pending for someone with ARM32 to determine if we can re-unify the ARG_MAX value, but that should probably be handled in another PR. -- 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"