[Bug 233764] [amdtemp] does not know correct offset for AMD Family 15h (A8-7600, FX-8300, etc) Tctl

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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

2019-12-20 Thread bugzilla-noreply
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"