ccache during system build

[Rozhuk Ivan]

Hi!


Just few tips.


1. bsd.compiler.mk set COMPILERCHECK env var:

# Handle bootstrapped compiler changes properly by hashing their content
# rather than checking mtime.  For external compilers it should be safe
# to use the more optimal mtime check.
# XXX: CCACHE_COMPILERCHECK= string:
.if ${CC:N${CCACHE_BIN}:[1]:M/*} == ""
CCACHE_COMPILERCHECK?=  content
.else
CCACHE_COMPILERCHECK?=  mtime
.endif

this overrides ccache.conf setting and increase build time.
CCACHE_COMPILERCHECK='%compiler% -dumpversion'
makes first build and second system rebuild faster.


2. To allow ccache hit in case with different src and obj location
a) obj must be placed inside src
b) OBJTOP env var must be set to new obj location
without this obj path will contain src path and not hit to ccache.
c) CCACHE_BASEDIR must be set to src
d) CCACHE_NOHASHDIR=yes
e) CCACHE_COMPILERCHECK='%compiler% -dumpversion'
f) MAKEOBJDIRPREFIX=''
g) -o nocache must be used with mount_nullfs to avoid error during install:
exec(btxld) failed (No such file or directory) and obj via nullfs


As example, attached scripts build kernel and world using obj stored inside 
/tmp,
after build files from temp obj moved to /usr/obj dir.
Using simular technic for build FreeBSD inside other src and obj locations I got
ccache hit and reduce build time.

I got ccache miss only for kernel build in case different KERNCONF, because it 
is mapped
to obj dir path. Probably overwriting OBJROOT will fix it.




fbsd_build_kernel.sh
Description: application/shellscript


fbsd_build_world.sh
Description: application/shellscript

exec(btxld) failed (No such file or directory) and obj via nullfs

[Rozhuk Ivan]

Hi!


I found a way to fix error during install: exec(btxld) failed (No such file or 
directory)
in case obj is nullfs mounted.


Use option: -o nocache
mount_nullfs -o rw -o nocache -o noatime "${MAKEOBJDIRPREFIX_TMP}" 
"${MAKEOBJDIRPREFIX}"


This helps for me, hope it will be usfull for community.


PS: this works even without https://reviews.freebsd.org/D23411 patch.
I do not dig inside this and have no idea why this option undocumented.
Probably this some kernel/nullfs bug that must be investigated, or just
remove option and make it always enabled.

Too many warnings for world and kernel for 13 stable

[Rozhuk Ivan]

Hi!

There was a lot warning during build wold and kernel in past with clang 13,
but with clang 14 to many warnings.

Probably commiters will find some time to fix it?



I spent some time to fix/supress warnings for world, exept contrib and stand 
parts.
This patch is not to merge, it is to show that something goes wrong.
>From 616ca2b8b63b225be0305d34f36dd3d0050a6a4f Mon Sep 17 00:00:00 2001
From: Rozhuk Ivan 
Date: Fri, 10 Sep 2021 18:50:20 +0300
Subject: [PATCH] Fix build warnings

---
 lib/geom/eli/geom_eli.c   |  4 +-
 lib/libc/stdlib/rand.c|  4 +-
 lib/libfetch/http.c   |  7 +---
 lib/libkvm/kvm_minidump_powerpc64_hpt.c   |  3 --
 lib/libmd/rmd160c.c   |  1 +
 lib/libmd/sha1c.c |  2 +
 lib/libpfctl/libpfctl.c   | 16 +++
 lib/libpjdlog/pjdlog.c|  5 ++-
 lib/libprocstat/libprocstat.c |  1 +
 lib/libvgl/mouse.c|  5 +--
 lib/libvmmapi/vmmapi.c|  3 +-
 lib/ncurses/ncurses/termcap.c |  2 -
 sbin/bsdlabel/bsdlabel.c  |  8 +---
 sbin/camcontrol/zone.c|  7 +---
 sbin/ggate/ggated/ggated.c| 42 +++
 sbin/growfs/growfs.c  |  5 +--
 sbin/ipfw/ipfw2.c |  5 +--
 sbin/ipfw/nat.c   |  3 +-
 sbin/ipfw/nat64clat.c |  3 +-
 sbin/ipfw/nat64lsn.c  |  3 +-
 sbin/ipfw/nat64stl.c  |  3 +-
 sbin/ipfw/nptv6.c |  3 +-
 sbin/ipfw/tables.c|  6 +--
 sbin/nvmecontrol/modules/wdc/wdc.c|  3 +-
 sbin/pfctl/pfctl_optimize.c   |  3 --
 sbin/recoverdisk/recoverdisk.c| 14 +--
 sys/amd64/vmm/vmm_instruction_emul.c  | 18 ++--
 sys/netinet/libalias/alias.c  | 11 +++--
 usr.bin/backlight/backlight.c |  3 --
 usr.bin/ipcs/ipc.c|  3 +-
 usr.bin/mkuzip/mkuzip.c   |  8 ++--
 usr.bin/mt/mt.c   |  5 +--
 usr.bin/procstat/procstat.c   |  3 +-
 usr.bin/truss/syscalls.c  |  7 +---
 usr.bin/unifdef/unifdef.c |  5 +--
 usr.bin/units/units.c |  5 ---
 usr.bin/vmstat/vmstat.c   |  4 +-
 usr.bin/vtfontcvt/vtfontcvt.c |  8 
 usr.sbin/acpi/acpidump/acpi.c |  5 ---
 usr.sbin/bhyve/atkbdc.c   | 12 ++
 usr.sbin/bhyve/bhyverun.c | 12 ++
 usr.sbin/bhyve/gdb.c  | 14 ++-
 usr.sbin/bhyve/hda_codec.c| 22 +++---
 usr.sbin/bhyve/mem.c  | 26 
 usr.sbin/bhyve/mevent.c   |  4 +-
 usr.sbin/bhyve/pci_ahci.c | 20 -
 usr.sbin/bhyve/pci_e82545.c   |  8 +---
 usr.sbin/bhyve/pci_emul.c | 26 
 usr.sbin/bhyve/pci_hda.c  | 31 --
 usr.sbin/bhyve/pci_virtio_block.c | 10 ++---
 usr.sbin/bhyve/pci_virtio_console.c   |  8 +---
 usr.sbin/bhyve/pci_virtio_net.c   |  7 +---
 usr.sbin/bhyve/pci_virtio_rnd.c   |  5 +--
 usr.sbin/bhyve/pci_virtio_scsi.c  |  4 +-
 usr.sbin/bhyve/pm.c   | 10 +
 usr.sbin/bhyve/rtc.c  | 21 --
 usr.sbin/bhyve/spinup_ap.c| 22 --
 usr.sbin/bhyve/task_switch.c  | 22 +++---
 usr.sbin/bhyve/uart_emul.c| 13 ++
 usr.sbin/bhyve/vga.c  |  8 ++--
 usr.sbin/bsdinstall/partedit/scripted.c   |  7 ++--
 usr.sbin/camdd/camdd.c| 19 +
 usr.sbin/efibootmgr/efibootmgr.c  |  3 +-
 usr.sbin/efidp/efidp.c|  3 +-
 .../fifolog/fifolog_reader/fifolog_reader.c   |  4 +-
 usr.sbin/fifolog/lib/fifolog_int.c|  2 +-
 usr.sbin/fifolog/lib/fifolog_reader.c |  4 +-
 usr.sbin/fifolog/lib/fifolog_write_poll.c |  2 +-
 usr.sbin/fifolog/lib/getdate.y| 13 +-
 usr.sbin/fwcontrol/fwdv.c |  4 +-
 usr.sbin/makefs/msdos.c   |  2 -
 usr.sbin/makefs/msdos/msdosfs_vfsops.c|  2 -
 usr.sbin/mpsutil/mps_debug.c  |  2 -
 usr.sbin/mptable/mptable.c|  3 --
 usr.sbin/pmc/cmd_pmc_filter.cc|  3 +-
 usr.sbin/pw/pw_user.c |  4 +-
 usr.sbin/rpc.lockd/kern.c |  5 ---
 usr.sbin/rpc.tlsservd/rpc.tlsservd.c  |  3 +-
 usr.sbin/rrenumd/parse

Re: Problems with getting a crash dump

[Rozhuk Ivan]

On Mon, 08 Nov 2021 19:08:31 +
Alexander  wrote:

> Hello, I am currently using FreeBSD 14.0-CURRENT and I found a bug
> that triggers a kernel panic. I wanted to make a kernel crash dump to
> further investigate the issue, but after a few tries I still did not
> manage to do it. I started by following the instructions in the
> FreeBSD Handbook. I checked that /dev/nvd0p2.eli is an active swap
> device and I configured it to be used as a dump device like this:
> 
> # dumpon -v /dev/nvd0p2.eli
> # sysctl debug.kdb.panic=1
> 
> Then I booted into single user mode to extract the core dumb:
> 
> # savecore -vC /dev/nvd0p2
> checking for kernel dump on device /dev/nvd0p2
> mediasize = 2147483648 bytes
> sectorsize = 512 bytes
> magic mismatch on last dump header on /dev/nvd0p2
> No dump exists
> 
> A you can see the core dump was not written to the device. Later I
> also tried using /dev/nvd0p2 (with out the "eli" part), because
> /dev/nvd0p2.eli is only available after I enable it using swapon, but
> the handbook states the I should first extract the dump, before I use
> the device as swap again. But the result was the same. /dev/nvd0p2 is
> only 2gb in size and it's an encrypted swap device, so I thought that:
> 1) Maybe the size of the device is to small even for a minidump.
> 2) Perhaps using encrypted swap as a dump device is not supported.
> 
> Because of those complications I decided to use an external 8gb USB
> drive as my dump device.
> 
> # gpart create -s gpt /dev/da0
> # gpart add -t freebsd-swap /dev/da0
> # swapoff -a
> # swapon /dev/da0p1
> # dumpon -v /dev/da0p1
> kernel dumps on priority: device
> 0: da0p1
> 
> I have 8gb of RAM so a 8gb dump device should be big enough for a
> minidump. I used `sysctl debug.kdb.panic=1` to crash the kernel and
> rebooted the system. I also waited for 10 minutes to ensure the the
> kernel finished writing the core dump to the device.
> 
> # savecore -vC /dev/da0p1
> checking for kernel dump on device /dev/da0p1
> mediasize = 7744741376 bytes
> sectorsize = 512 bytes
> magic mismatch on last dump header on /dev/da0p1
> No dump exists
> 
> As you can see I still did not manage to get a kernel crash dump. Any
> ideas?
> 
> Here is a picture of the output I get after running `sysctl
> debug.kdb.panic=1`:
> https://forums.freebsd.org/attachments/img_20211108_163313-jpeg.11936/
> 
> PS yes kern.coredump is set to 1.
> 


https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238301
http://netlab.dhis.org/wiki/ru:software:freebsd:kernel_debug

It work for 12 and 13, may be 14 have bugs/changes.

pthread_mutex_lock(), EDEADLK and thread ID

[Rozhuk Ivan]

Hi!


We have some product based on FreeBSD 12.2 that running in different places and
environments, more than 5 years.

At one place we got EDEADLK some times then calling pthread_mutex_lock().
This happen to often: 1-4 times per 10 minutes.
Code designed to call abort() and generate coredump.
So we mostly sure that this was not happen in other places in past.

I know that we run as VmWare guest and can ask more details.


In lib/libthr/thread/thr_mutex.c
...
static int
mutex_lock_sleep(struct pthread *curthread, struct pthread_mutex *m,
const struct timespec *abstime)
{
uint32_t id, owner;
int count, ret;

id = TID(curthread);
if (PMUTEX_OWNER_ID(m) == id)
return (mutex_self_lock(m, abstime));



mutex_self_lock() may return EDEADLK for PTHREAD_MUTEX_ERRORCHECK mutex type, 
which is default.


Is it possible that "id = TID(_get_curthread());" some how changed to ID some 
other thread that lock mutex in past?

Re: Wi-Fi: HP ZBook 17 G2

[Rozhuk Ivan]

On Fri, 23 Jul 2021 19:26:02 +0100
Graham Perrin  wrote:

> According to ,
> iwm(4) should work.
> 

If your CPU can run byhive - do not waste time, install OpenWRT
and let it be your WiFi driver:
https://lists.freebsd.org/pipermail/freebsd-hackers/2020-June/056170.html

You will got: full AC speed, additional FW, nice GUI.

13 stable build fail

[Rozhuk Ivan]

...
In file included from /usr/src/lib/libc/gen/fstab.c:38:
In file included from 
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38:
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal 
error: 'bsm/audit.h' file not found
#include 
 ^
1 error generated.
--- fstab.o ---
*** [fstab.o] Error code 1

make[4]: stopped in /usr/src/lib/libc
In file included from /usr/src/lib/libc/gen/fts.c:40:
In file included from 
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38:
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal 
error: 'bsm/audit.h' file not found
#include 
 ^
In file included from /usr/src/lib/libc/gen/fts-compat.c:41:
In file included from 
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/mount.h:38:
/tmp/obj.world/usr/src/amd64.amd64/tmp/usr/include/sys/ucred.h:42:10: fatal 
error: 'bsm/audit.h' file not found
#include 
 ^
1 error generated.
--- fts.o ---
*** [fts.o] Error code 1

make[4]: stopped in /usr/src/lib/libc
...

Re: WSLg update on 1-5-2021 - BSD / WSL

[Rozhuk Ivan]

On Fri, 7 May 2021 14:31:39 +0100
David Chisnall  wrote:


> >> Whether Microsoft or the FreeBSD project should do the work really
> >> comes down to who has more to gain.  Windows 10 is installed on
> >> around a 1.3 billion devices and any of these users can run Ubuntu
> >> with a single click in the Microsoft Store, so it feels as if the
> >> FreeBSD project has a lot to gain from being able to reach them.  
> > 
> > Make job for free - make more money for MS.
> > Make win10 to support more features to increase windows value...  
> 
> How much money?  'Making money' doesn't just mean money coming in, it 
> means more money coming in than is going out.  Adding features to a 
> product costs money.  How many people will buy Windows 10 if it has a 
> good FreeBSD compatibility layer who wouldn't buy it without one?  I 
> very much doubt that this is a sufficient number to cover the cost of 
> the engineering work.

This is MS management problems.
Adding support WSL code will not make FBSD users happy, there is mush more
actual issues that require attention. IMHO.


> >> If you assume
> >> that 1% of people who want the feature commented, then this gives
> >> around 10,000 folks who really want a FreeBSD equivalent of WSL.  
> > 
> > They give money to MS, they ask MS to do job for money.  
> 
> They give money to MS, they get a Windows 10 license in return.  They 
> are happy to buy Windows without a FreeBSD compat layer.  They are 
> buying Windows on the basis of some subset of a large number of 
> features.  The lack of a FreeBSD compat layer is not preventing them 
> from buying Windows, they have not shown that this is the
> deal-breaker feature.

Because MS is monopoly on OS market.
For most peolpes there is no other way to buy PC/notebook without windows,
and no other way to use some software that was written for windows only.


> Microsoft, like any other POTS software vendor, will prioritise
> features that impact the most customers.  There are things on User
> Voice with tens or hundreds of thousands of votes and these tend to
> be prioritised. Something with under a hundred votes is so niche that
> it's only going to be a target of investment if it impacts another
> product or service.

>From mine experience MS listen only custommers from big b2b and b2gov.
Millions of users hate post win7 gui - see no reaction from ms.

 
> >> It's pretty hard to justify a feature in Windows that only 0.001%
> >> of Windows users will use. If you want to change that arithmetic,
> >> then next time your organisation is renewing M365 or Azure service
> >> subscriptions, tell your sales rep that FreeBSD support is
> >> important to your company.  
> > 
> > There is many other hosting services that have FBSD support.
> > So this is MS/azure problem.  
> 
> Azure already officially supports FreeBSD and we have contributed a
> load of code to improve that support over the years.  From the
> numbers I've seen, I strongly suspect that we've spent more on it
> than we've gained in revenue.

Ok, thanks!


> You are asking Microsoft to throw money at a thing that will
> definitely cost time and money (and comes with the associated
> opportunity cost, because developer time spent on this features is
> developer time not spent on other features) but with no clear
> indication that it will increase revenue.  Effectively, you are
> asking us to do work for free and you're also doing so quite rudely.

No, I do not ask MS for anything.
If MS want something - patches/pull requests/sponsoring are welcome!


> Personally, I'd love to have a FreeBSD compat layer.  The license
> would even make it possible to embed the FreeBSD kernel in Windows
> and so get the best aspects of WSL1 and WSL2.  From a business
> perspective; however, I can't argue that this would be a great use of
> engineer time. There are a load of features that would positively
> impact a lot more users that would be higher priority.

Same for FBSD.
FBSD have very limited peoples power and more prioritized tasks, at least
from my point of view.

May be you luck to find some one who can, have time and motivation to do this.


> If you want this to happen and you want Microsoft to do it, then you 
> need to help people inside the company provide this business case. 
> Things that don't help include:
> 
>   - I want it.
>   - You suck for not doing it.
>   - It would make you money in unspecified ways.
> 
> Things that do help include:
> 
>   - We are a FreeBSD shop with 1,000 workstations, we would switch to 
> Windows on the desktop with this feature.
>   - We are a large cloud customer with 10,000 VMs deployed, we would 
> switch to Azure with this feature.
>   - We are a Windows shop with a load of desktops but are planning to 
> switch to Macs because we want a BSD-style userland.

This is examples of negative motivation for this community. :)


___
freebsd-current@freebsd.org mailing list

Re: WSLg update on 1-5-2021 - BSD / WSL

[Rozhuk Ivan]

On Thu, 6 May 2021 10:57:16 +0100
David Chisnall  wrote:


> Whether Microsoft or the FreeBSD project should do the work really
> comes down to who has more to gain.  Windows 10 is installed on
> around a 1.3 billion devices and any of these users can run Ubuntu
> with a single click in the Microsoft Store, so it feels as if the
> FreeBSD project has a lot to gain from being able to reach them.

Make job for free - make more money for MS.
Make win10 to support more features to increase windows value...


> If you believe that FreeBSD provides a better experience (I certainly
> believe it provides a better developer experience) than Ubuntu, then
> making it easy to reach every Windows users is of huge value to the
> FreeBSD project and community.

Manipulation detected.


> Microsoft, in contrast, is driven by requests from customers who
> spend money on our products and services.
> Around a hundred people
> commented on the WSL issue to add FreeBSD support.

Ok, do you job and add FBSD support to WSL.


> If you assume
> that 1% of people who want the feature commented, then this gives
> around 10,000 folks who really want a FreeBSD equivalent of WSL.

They give money to MS, they ask MS to do job for money.


> It's pretty hard to justify a feature in Windows that only 0.001% of
> Windows users will use. If you want to change that arithmetic, then
> next time your organisation is renewing M365 or Azure service
> subscriptions, tell your sales rep that FreeBSD support is important
> to your company.

There is many other hosting services that have FBSD support.
So this is MS/azure problem.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: WSLg update on 1-5-2021 - BSD / WSL

[Rozhuk Ivan]

On Sat, 1 May 2021 21:42:38 +0200
Chargen  wrote:

> With FreeBSD subsystem and interops , windows should feel less
> monolithic
> 

Waste our resourses to increase MS money profit.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: stable/13, vm page counts do not add up

[Rozhuk Ivan]

On Tue, 13 Apr 2021 17:18:42 -0400
Mark Johnston  wrote:

> > P.S.
> > I have not been running any virtual machines.
> > I do use nvidia graphics driver.  
> 

In past I had report: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=238698

Now I switch to AMD and got only ~1Gb memory allocated by xorg.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 13:04:19 +0200
tue...@freebsd.org wrote:

> > As I understand, in some cases remote host does not reply with MSS
> > option, and host behind router continue use mss 8960, that dropped
> > by router.  
> If the peer does not provide an MSS option, your local FreeBSD based
> host should use an MSS of net.inet.tcp.mssdflt bytes. The default is
> 536. So I don't think this should be a problem.

Thats it!
Thanks, it was ~64k in mine config.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 17:23:39 +0700
Eugene Grosbein  wrote:

> > Is any other other options to work around this?  
> 
> Yes. Each entry in the routing table has "mtu" attribute limiting TCP
> MSS, too. You should use default route with -mtu 1500 attribute. For
> example, in /etc/rc.conf:
> 
> defaultroute="X.X.X.X -mtu 1500"
> 

This help only if I do this on all hosts in network, this is to many management.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP Connection hang - MSS again

[Rozhuk Ivan]

On Mon, 5 Apr 2021 12:44:50 +0300
Rozhuk Ivan  wrote:


> FreeBSD 13 desktop have no known problems with other websites.
> Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k.

Forgot.
FreeBSD 12 reply with MSS 8960, and I fix it in PF:
> scrub in on $ext_v4_if0 all max-mss 1400

so only https://online.sberbank.ru/CSAFront/index.do#/
time to time reply without mss option.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

TCP Connection hang - MSS again

[Rozhuk Ivan]

Hi!


TCP Connection hang then I try to open 
https://online.sberbank.ru/CSAFront/index.do#/

FreeBSD 13 desktop + FreeBSD 13 router (pf).
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/sysctl.conf
FreeBSD 13 desktop have no known problems with other websites.
Only with one remonte FreeBSD 12 with same sysctl.conf and mtu 9k.
If I set mtu to 1500 on desktop - issue is gone.

Router pf.conf contain:
scrub out on $ext_v4_if0 all random-id min-ttl 128 max-mss 1400
scrub in on $ext_v4_if0 all max-mss 1400


Android 9 and FreeBSD 12.2 have no this issue (both @WiFi).


As I understand, in some cases remote host does not reply with MSS option, and 
host behind
router continue use mss 8960, that dropped by router.

(pf scrub rules disabled for this log), tcpdump | grep mss:
176.99.179.102.60903 > 194.54.14.131.443: Flags [S], cksum 0xd0a2 
(correct), seq 3696980106, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 3763275954 ecr 0], length 0
176.99.179.102.60719 > 194.54.14.131.443: Flags [S], cksum 0xd796 
(correct), seq 232307963, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1963519951 ecr 0], length 0
176.99.179.102.50146 > 194.54.14.131.443: Flags [S], cksum 0x1aa9 
(correct), seq 3968469659, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 3417199378 ecr 0], length 0
176.99.179.102.50646 > 194.54.14.131.443: Flags [S], cksum 0xb3ba 
(correct), seq 3774081696, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1089629786 ecr 0], length 0
176.99.179.102.56843 > 194.54.14.131.443: Flags [S], cksum 0xc4dd 
(correct), seq 647662718, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 4054756545 ecr 0], length 0
194.54.14.131.443 > 176.99.179.102.56843: Flags [S.], cksum 0x35dd 
(correct), seq 186241788, ack 647662719, win 65535, options [mss 
1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541298941 ecr 4054756545], 
length 0
176.99.179.102.65364 > 194.54.14.131.443: Flags [S], cksum 0x17a0 
(correct), seq 1603248650, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1794142451 ecr 0], length 0
176.99.179.102.59862 > 194.54.14.131.443: Flags [S], cksum 0x2736 
(correct), seq 4000339086, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 4084903147 ecr 0], length 0
176.99.179.102.60915 > 194.54.14.131.443: Flags [S], cksum 0xd964 
(correct), seq 95236311, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1297197380 ecr 0], length 0
176.99.179.102.58717 > 194.54.14.131.443: Flags [S], cksum 0xf92e 
(correct), seq 1785704794, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1392944917 ecr 0], length 0
194.54.14.131.443 > 176.99.179.102.58717: Flags [S.], cksum 0xe020 
(correct), seq 2800465814, ack 1785704795, win 65535, options [mss 
1380,nop,wscale 3,nop,nop,sackOK,nop,nop,TS val 2541366941 ecr 1392944917], 
length 0
176.99.179.102.53377 > 194.54.14.131.443: Flags [S], cksum 0x8fdd 
(correct), seq 3235103847, win 65535, options [mss 8960,nop,wscale 10,sackOK,TS 
val 1359134165 ecr 0], length 0


Is it possible to force FreeBSD always ask with tcp mss option?
Is any other other options to work around this?






Full connections log:

12:06:44.205766 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 74: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), length 
60)
176.99.179.102.54064 > 194.54.14.131.443: Flags [S], cksum 0xca3f 
(correct), seq 980200339, win 65535, options [mss 1400,nop,wscale 10,sackOK,TS 
val 1268859625 ecr 0], length 0
12:06:44.206997 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 59, id 57535, offset 0, flags [none], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [S.], cksum 0x5d05 
(correct), seq 2754330417, ack 980200340, win 0, length 0
12:06:44.207126 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 54: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), length 
40)
176.99.179.102.54064 > 194.54.14.131.443: Flags [.], cksum 0x5d06 
(correct), seq 1, ack 1, win 65535, length 0
12:06:44.210824 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 59, id 45037, offset 0, flags [DF], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [.], cksum 0x5d06 
(correct), seq 1, ack 1, win 65535, length 0
12:06:44.211130 70:85:c2:43:67:5b > 78:da:6e:28:c9:c0, ethertype IPv4 (0x0800), 
length 571: (tos 0x0, ttl 128, id 0, offset 0, flags [DF], proto TCP (6), 
length 557)
176.99.179.102.54064 > 194.54.14.131.443: Flags [P.], cksum 0x7667 
(correct), seq 1:518, ack 1, win 65535, length 517
12:06:44.214366 78:da:6e:28:c9:c0 > 70:85:c2:43:67:5b, ethertype IPv4 (0x0800), 
length 60: (tos 0x0, ttl 53, id 45320, offset 0, flags [DF], proto TCP (6), 
length 40)
194.54.14.131.443 > 176.99.179.102.54064: Flags [.], cksum 0x5d06 
(correct), seq 1, 

Re: freebsd 13 ryzen micro stutter

[Rozhuk Ivan]

On Wed, 31 Mar 2021 02:35:25 -0700
Alastair Hogge  wrote:

> On 2021-03-28 16:09, Hans Petter Selasky wrote:
> > On 3/27/21 11:54 AM, Santiago Martinez wrote:  
> >> Hi, i have the same output as @Nils B. If i run with steal =2 and
> >> dtrace the micro stutter doesn't happen but as soon as i stop the
> >> dtrace script it the stutters come back again. 
> > 
> > Here is a patch which you can try. Not sure if it helps.
> > https://reviews.freebsd.org/D29467  
> 
> Thanks Hans, this reduces jitter somewhat, but it still noticeable in
> Quake2. I left kern.sched.steal_thresh at 1.
> 

I have no micro stutter with default kern.sched.steal_thresh=2, but I have set:
kern.sched.balance=0# Enables the long-term load balancer
kern.sched.balance_interval=1000# Average period in stathz ticks to run 
the long-term balancer
kern.sched.affinity=1   # Number of hz ticks to keep thread 
affinity for
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fsck strange output

[Rozhuk Ivan]

On Mon, 25 Jan 2021 15:40:12 -0800
Kirk McKusick  wrote:


> Please try this patch to fsck_ffs and see if it fixes your problem.
> 
>   Kirk McKusick
> 
> =-=-=
> 
> *** sbin/fsck_ffs/inode.c.orig2021-01-07 15:04:04.969086284
> -0800 --- sbin/fsck_ffs/inode.c   2021-01-25 15:29:06.404803358
> -0800 ***
> *** 611,618 
>   sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
>   partialcnt = inosused % fullcnt;
> ! partialsize = partialcnt * ((sblock.fs_magic ==
> FS_UFS1_MAGIC) ? !sizeof(struct ufs1_dinode) :
> sizeof(struct ufs2_dinode)); if (partialcnt != 0) {
>   readpercg++;
>   } else {
> --- 611,619 
>   sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
>   partialcnt = inosused % fullcnt;
> ! partialsize = fragroundup(,
> ! partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
> ! sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode))); if (partialcnt != 0) {
>   readpercg++;
>   } else {


https://github.com/rozhuk-im/freebsd/commit/5e8bfa01830e2b6ecb88e572064c6fffe5a2df2d
(if I apply correct :) )

With this patch - seems no errors, thanks!

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: fsck strange output

[Rozhuk Ivan]

On Mon, 25 Jan 2021 20:51:50 +
"Poul-Henning Kamp"  wrote:
> > Disk is 100% alive, got same on other HW.  
> 
> A disk can be alive and still have individually unreadable sectors,
> that is, IMO, the most common failure mode.
> 
> Try:
>   recoverdisk -v /dev/whatever
> 
> That will attempt to read all sectors on the disk.
> 

This happen on 4 different systems, that:
- based on Ryzen zen/zen+
- FreeBSD 13

2 systems have ECC that works and show no errors.

At least on 12 and prev on read error - kernel show
messages from drivers/geom.

recoverdisk -v - show no error.

I can reproduce this in VBox after disable "soft update journaling".
(I hope that you will not require from me to check VBox HW too :) ) 

VBOx - no "CANNOT READ BLK":
# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   enabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 2%
tunefs: space to hold for metadata blocks: (-k)1600
tunefs: optimization preference: (-o)  space
tunefs: volume label: (-L) 


VBOx - "CANNOT READ BLK" is present:
# tunefs -p /dev/ada0p2
tunefs: POSIX.1e ACLs: (-a)disabled
tunefs: NFSv4 ACLs: (-N)   disabled
tunefs: MAC multilabel: (-l)   disabled
tunefs: soft updates: (-n) enabled
tunefs: soft update journaling: (-j)   disabled
tunefs: gjournal: (-J) disabled
tunefs: trim: (-t) disabled
tunefs: maximum blocks per file in a cylinder group: (-e)  4096
tunefs: average file size: (-f)16384
tunefs: average number of files in a directory: (-s)   64
tunefs: minimum percentage of free space: (-m) 2%
tunefs: space to hold for metadata blocks: (-k)1600
tunefs: optimization preference: (-o)  space
tunefs: volume label: (-L) 


5cc52631b3b88dfc36d8049dc8bece8573c5f9af
[PATCH] Rewrite the disk I/O management system in fsck_ffs(8). Other
Since this commit this issue started.
I check: build system from prev commit - OK, build from this - "CANNOT READ 
BLK".

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

fsck strange output

[Rozhuk Ivan]

Hi!


I am on fresh 13 and on auto fsck got:

Jan 25 23:14:13 3des kernel: Starting file system checks:
Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
CANNOT READ BLK: 11072
Jan 25 23:14:13 3des kernel: /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6: 
UNEXPECTED SOFT UPDATE INCONSISTENCY; RUN fsck MANUALLY.
Jan 25 23:14:13 3des kernel: File system preen failed, trying fsck -y -T 
ffs:-R,-r -T ufs:-R,-r
Jan 25 23:14:13 3des kernel: ** /dev/gptid/81241708-8948-11e9-b1ae-049226c061d6
Jan 25 23:14:13 3des kernel: ** Last Mounted on /
Jan 25 23:14:13 3des kernel: ** Root file system
Jan 25 23:14:13 3des kernel: ** Phase 1 - Check Blocks and Sizes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 11072
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 5129280
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 6411520
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: THE FOLLOWING DISK SECTORS COULD NOT BE READ:
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CANNOT READ BLK: 7693888
Jan 25 23:14:13 3des kernel: UNEXPECTED SOFT UPDATE INCONSISTENCY
Jan 25 23:14:13 3des kernel: 
Jan 25 23:14:13 3des kernel: CONTINUE? yes


Disk is 100% alive, got same on other HW.
fsck -y - have no this strange problem with reading.

Is it OK "CANNOT READ BLK ..." ?


>From my rc.conf:
fsck_y_enable="YES" # Set to YES to do fsck -y if the initial preen 
fails.
fsck_y_flags="-T ffs:-R,-r -T ufs:-R,-r" # Additional flags for fsck -y
background_fsck="NO"# Attempt to run fsck in the background where 
possible.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

ld: error: undefined symbol: hid_locate

[Rozhuk Ivan]

Hi!

Trying to build 429c7d1ab4, got:


linking kernel.full
ld: error: undefined symbol: hid_locate
>>> referenced by uhid.c:727 (/usr/src/sys/dev/usb/input/uhid.c:727)
>>>   uhid.o:(uhid_probe)
>>> referenced by uhid.c:730 (/usr/src/sys/dev/usb/input/uhid.c:730)
>>>   uhid.o:(uhid_probe)
>>> referenced by ukbd.c:992 (/usr/src/sys/dev/usb/input/ukbd.c:992)
>>>   ukbd.o:(ukbd_parse_hid)
>>> referenced 16 more times

ld: error: undefined symbol: hid_report_size_max
>>> referenced by uhid.c:835 (/usr/src/sys/dev/usb/input/uhid.c:835)
>>>   uhid.o:(uhid_attach)
>>> referenced by uhid.c:838 (/usr/src/sys/dev/usb/input/uhid.c:838)
>>>   uhid.o:(uhid_attach)
>>> referenced by uhid.c:841 (/usr/src/sys/dev/usb/input/uhid.c:841)
>>>   uhid.o:(uhid_attach)
>>> referenced 3 more times

ld: error: undefined symbol: hid_is_keyboard
>>> referenced by ukbd.c:957 (/usr/src/sys/dev/usb/input/ukbd.c:957)
>>>   ukbd.o:(ukbd_probe)

ld: error: undefined symbol: hid_is_mouse
>>> referenced by ukbd.c:958 (/usr/src/sys/dev/usb/input/ukbd.c:958)
>>>   ukbd.o:(ukbd_probe)
>>> referenced by ums.c:451 (/usr/src/sys/dev/usb/input/ums.c:451)
>>>   ums.o:(ums_probe)

ld: error: undefined symbol: hid_get_data
>>> referenced by ukbd.c:695 (/usr/src/sys/dev/usb/input/ukbd.c:695)
>>>   ukbd.o:(ukbd_intr_callback)
>>> referenced by ukbd.c:700 (/usr/src/sys/dev/usb/input/ukbd.c:700)
>>>   ukbd.o:(ukbd_intr_callback)
>>> referenced by ukbd.c:734 (/usr/src/sys/dev/usb/input/ukbd.c:734)
>>>   ukbd.o:(ukbd_intr_callback)
>>> referenced 18 more times

ld: error: undefined symbol: hid_get_udata
>>> referenced by ukbd.c:722 (/usr/src/sys/dev/usb/input/ukbd.c:722)
>>>   ukbd.o:(ukbd_intr_callback)
>>> referenced by ukbd.c:722 (/usr/src/sys/dev/usb/input/ukbd.c:722)
>>>   ukbd.o:(ukbd_intr_callback)

ld: error: undefined symbol: hid_put_udata
>>> referenced by ukbd.c:830 (/usr/src/sys/dev/usb/input/ukbd.c:830)
>>>   ukbd.o:(ukbd_set_leds_callback)
>>> referenced by ukbd.c:821 (/usr/src/sys/dev/usb/input/ukbd.c:821)
>>>   ukbd.o:(ukbd_set_leds_callback)
>>> referenced by ukbd.c:839 (/usr/src/sys/dev/usb/input/ukbd.c:839)
>>>   ukbd.o:(ukbd_set_leds_callback)
--- kernel.full ---
*** [kernel.full] Error code 1

make[2]: stopped in /tmp/obj.kernel/usr/src/amd64.amd64/sys/RIM_WKS
--- all_subdir_mac_lomac ---
--- all_subdir_mac_biba ---
--- all_subdir_mac_bsdextended ---
--- modules-all ---
*** [modules-all] Error code 2
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

UEFI does not boot on real HW

[Rozhuk Ivan]

Hi!


I am trying to migrate from 12/stable to main@163f4f1573
and after system (world + kernel + bootloaders) update
UEFI does not work: it reads loader.conf, but a bit strange:
- logo is off - OK
- font colour does not change - not OK
then black screen, no connect via ssh, after h/w reset - no fsck run,
I assume that disk was not mounted.

UEFI loader shows console = serial, even if I disable serial - FAIL to boot.
Legacy loader console = Video - boot OK.


On VirtualBox UEFI uses console = Video, with all same configs - boot OK.
(graphics mode, never seen it before)
12/stable on same H/W and almost same configs boot using UEFI - boot OK
(console = Video, looks like text mode).


HW: APU A10-6700, 5600XT (display connected here).


I allready had try:

1. dd /dev/zero to efi part and run
/usr/src/tools/boot/install-boot.sh -b uefi -f ufs -s gpt ada0
to ensure that latest loader witout artifacts will be used;

2. Remove my loader.conf, loader.conf.local;

3. hw.vga.textmode=“0” - was set in my initial loader.conf;

4. If I copy userboot.so and userboot_lua.so from 12/stable
then UEFI boot OK, but show that console = serial and use
text mode.


My configs:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/boot/loader.conf
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/wks/boot/loader.conf.local
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/13/base/etc/src.conf
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Terminal colours in current

[Rozhuk Ivan]

On Sat, 2 Jan 2021 06:33:55 +0100
"Hartmann, O."  wrote:

> Colour settings seem to be broken since a couple of months. Out of
> the blue, coloured kernel messages vanished - this problem is on 12
> as well as CURRENT (we're running 12.2-RELENG, 12-STABLE and CURRENT).
> 

I do no see problem on stable 12.
Also current with loaders from 12 is OK.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Terminal colours in current

[Rozhuk Ivan]

Hi!

I am tring current and found that kernel options:
options TERMINAL_NORM_ATTR  = (FG_GREEN|BG_BLACK) # def to 
SC_NORM_ATTR / 2 | 0x00
options TERMINAL_KERN_ATTR  = (FG_YELLOW|BG_BLACK) # def to 
SC_KERNEL_CONS_ATTR / 14 / 0x00
does not work anymore.

Fast greping sources give me loader tunables:
teken.fg_color="2"  #
teken.bg_color="0"  #

but these optios does not allow set kernel messages colour.

https://www.freebsd.org/cgi/man.cgi?query=vt=0=4=FreeBSD+13.0-current=default=html
say that TERMINAL_NORM_ATTR and TERMINAL_KERN_ATTR should work.
Also it say that I should have:
 kern.vt.color..rgb=""
 kern.vt.fb.default_mode="x"
 kern.vt.fb.modes.="x"
but I only get:
kern.vty: vt
kern.vt.splash_cpu_duration: 10
kern.vt.splash_cpu_style: 2
kern.vt.splash_ncpu: 0
kern.vt.splash_cpu: 0
kern.vt.kbd_panic: 0
kern.vt.kbd_debug: 0
kern.vt.kbd_reboot: 0
kern.vt.kbd_poweroff: 0
kern.vt.kbd_halt: 0
kern.vt.suspendswitch: 0
kern.vt.deadtimer: 15
kern.vt.debug: 0
kern.vt.enable_bell: 0
kern.vt.enable_altgr: 1


Do I miss something?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: drm-current-kmod now installs sources

[Rozhuk Ivan]

On Fri, 16 Aug 2019 17:23:08 -0700
John Baldwin  wrote:

> > I use better way:
> > /etc/make.conf:
> > # Modules to build with kernel.
> > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod
> > graphics/gpu-firmware-kmod  
> 
> This doesn't work for folks who use pre-built packages.
> 

I update mine /usr/src via rsync from other mine server, so any
changes made by port or me or ... will lost.

Probably there is must be some solution like special folder where
ports can store some file with port name, that automaticly go to
PORTS_MODULES on build kernel.
And probably pkg can do with this something for "folks who use pre-built 
packages".

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: drm-current-kmod now installs sources

[Rozhuk Ivan]

On Fri, 16 Aug 2019 16:32:18 -0700 (PDT)
"Rodney W. Grimes"  wrote:

> > > >> > I've lost the original thread, but would the sources in
> > > >/usr/local/sys/modules get built regardless of what
> > > >MAKEOBJDIRPREFIX is?  And, now that sources may be installed by
> > > >a port, what is the method for _just_ updating the sources?  Why
> > > >do I even need to build and install the port?  Personally, I
> > > >would just rather have the drm-kmod sources just imported into
> > > >base and maintained there.  If I have 2 or more different
> > > >checked out base src trees, how do I get the correct drm-kmod to
> > > >go with them if there is only one /usr/local/sys/modules?  Do I
> > > >need multiple port trees just to pull in out of tree module
> > > >sources?
> > > >> 
> > > >> In some ways, installing sources for DRM is a compromise for
> > > >> the fact
> > > >that we
> > > >> can't have DRM in the base source anymore (for various
> > > >> reasons). 
> > > >However,
> > > >> virtualbox is also probably in that camp as well.
> > > >
> > > >I applaud this effort to provide a source compile mode for DRM,
> > > >but I think it has come up a bit short on execution with
> > > >numorious problems sited.
> > > >
> > > >I too am not real happy that /usr/local/src is going to get
> > > >automatically invoked from my some odd 10+ src trees that
> > > >are of various WIP's.  I need a way to easily disable this
> > > >both on a global scale, and on a per src tree way.
> > > >
> > > >Rather than a default to on with an opt out mechanism perhaps
> > > >while we gain experience change this to a default to off with
> > > >an opt in mechanism?
> > > >
> > > >Sadly I do not have proposed solution, but something better
> > > >than what is there now needs to be found.
> > > >
> > > 
> > > Could we have a .src.conf in the root of the tree to configure
> > > this on a tree by tree basis?
> > > 
> > >   
> > 
> > 
> > I use better way:
> > /etc/make.conf:  
> 
> That file is global to all src trees,
> so that does not achive the desired effect.

You can override this using
env __MAKE_CONF=PATH_TO_MAKE.CONF SRCCONF=PATH_TO_SRC.CONF


> > # Modules to build with kernel.
> > PORTS_MODULES+= graphics/drm-fbsd12.0-kmod
> > graphics/gpu-firmware-kmod  
> 
> Can we some how trigger that from either a kernel conf file,
> or at least on a per src tree basis?  Ala cy's .src.conf?

I dont know, never use it.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: HEADSUP: drm-current-kmod now installs sources

[Rozhuk Ivan]

On Fri, 16 Aug 2019 15:40:24 -0700
Cy Schubert  wrote:

> On August 16, 2019 2:51:22 PM PDT, "Rodney W. Grimes"
>  wrote:
> >> On 8/14/19 3:40 PM, Daniel Eischen wrote:  
> >> > I've lost the original thread, but would the sources in  
> >/usr/local/sys/modules get built regardless of what MAKEOBJDIRPREFIX
> >is?  And, now that sources may be installed by a port, what is the
> >method for _just_ updating the sources?  Why do I even need to build
> >and install the port?  Personally, I would just rather have the
> >drm-kmod sources just imported into base and maintained there.  If I
> >have 2 or more different checked out base src trees, how do I get the
> >correct drm-kmod to go with them if there is only one
> >/usr/local/sys/modules?  Do I need multiple port trees just to pull
> >in out of tree module sources?  
> >> 
> >> In some ways, installing sources for DRM is a compromise for the
> >> fact  
> >that we  
> >> can't have DRM in the base source anymore (for various reasons).   
> >However,  
> >> virtualbox is also probably in that camp as well.  
> >
> >I applaud this effort to provide a source compile mode for DRM,
> >but I think it has come up a bit short on execution with numorious
> >problems sited.
> >
> >I too am not real happy that /usr/local/src is going to get
> >automatically invoked from my some odd 10+ src trees that
> >are of various WIP's.  I need a way to easily disable this
> >both on a global scale, and on a per src tree way.
> >
> >Rather than a default to on with an opt out mechanism perhaps
> >while we gain experience change this to a default to off with
> >an opt in mechanism?
> >
> >Sadly I do not have proposed solution, but something better
> >than what is there now needs to be found.
> >
> >Regards,  
> 
> Could we have a .src.conf in the root of the tree to configure this
> on a tree by tree basis?
> 
> 


I use better way:
/etc/make.conf:
# Modules to build with kernel.
PORTS_MODULES+= graphics/drm-fbsd12.0-kmod graphics/gpu-firmware-kmod

+
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237290

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: acpi issues on FreeBSD-current_r350103 on Thinkpad A485

[Rozhuk Ivan]

On Sat, 20 Jul 2019 00:54:47 +0200
Evilham  wrote:


> Minor glitches:
> - xbacklight doesn't work, neither does intel-backlight because 
>   it's AMD
> - Speakers don't appear to work, audio input/output on 3.5 jack 
>   does.
> - SD card reader doesn't work (Bounty for 125 USD: 
>   https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=204521)

I have Asus 505 and backlight not work too (try via xfce4-power-manager).

I dig into it and found that problem somewhere in ACPI code.

1. It does not proper export some functions and FreeBSD
ACPI + xfce4-power-manager cant detect support this feature.
I hack kernel:
Index: /usr/src/sys/dev/acpica/acpi_video.c
===
--- /usr/src/sys/dev/acpica/acpi_video.c(revision 350398)
+++ /usr/src/sys/dev/acpica/acpi_video.c(working copy)
@@ -1053,8 +1053,12 @@
dcs = 0;
status = acpi_GetInteger(handle, "_DCS", );
if (ACPI_FAILURE(status))
-   printf("can't evaluate %s._DCS - %s\n",
-  acpi_name(handle), AcpiFormatException(status));
+   status = acpi_GetInteger(handle, "_STA", );
+   if (ACPI_FAILURE(status)) {
+   /* Assume that device OK by default. */
+   dcs = (DCS_EXISTS | DCS_ACTIVE | DCS_READY |
+   DCS_FUNCTIONAL | DCS_ATTACHED);
+   }
 
return (dcs);
 }
and now acpi/xfce4-power-manager show that feature supported but
it does not work.
(later I can move this hack into ACPI ASL code that load into bios, but it 
harder to maintain)

2. I dig more depper and decompile acpi code via isl.
There is a mess.
I found that function that set backlight level check some mem/register
value before write new backlight value.
I fail to found place where this value changed.
I try rewrite code to remove this check and recompile ACPI and load new
version witout this check on FreeBSD boot, it loaded but backlight still
not work.

Also I set in loader.conf:
hw.acpi.osname="Windows 2015"   # Some systems' ASL may have problems because 
they look for names of Microsoft operating systems.
because there is at least 4 different places in decompiled ACPI
where OS version and name checked - not help with blackligth, but as I see
this unblock some features/devices.


Also i2c touchpad dont work.
https://reviews.freebsd.org/D16698
not help.


For speakers probably wrong snddev set.
Try change hw.snd.default_unit.


> WARNING !drm_modeset_is_locked(>mutex) failed at 
> /wrkdirs/usr/ports/graphics/drm-fbsd12.0-kmod/work/kms-drm-6365030/drivers/gpu/drm/drm_atomic_helper.c:821
> [Multiple times...]
> kernel trap 22 with interrupts disabled
> kernel trap 22 with interrupts 
> disabled
> kernel trap 22 with interrupts disabled
> kernel trap 22 with interrupts disabled
> panic: spin lock held too long

I have another issue with amdgpu:
after lid closed and open again video freezes to few seconds every 10 seconds.
Switch to scfb xorg driver to fix it, but get small tearing on video playback.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Danish FreeBSD Developer hates jews collectively

[Rozhuk Ivan]

On Fri, 10 May 2019 20:22:31 +0200
Steffen Nurpmeso  wrote:

>  |> Background: Apparently a FreeBSD developer, a viking looking
> fellow, |> has been hiding a secret: just as many of his predecessors
> in the |> Danish cities during WWII (collaborators); He has a disdain
> for "the |> jews" collectively.
>  |>   
>  |
>  |Who cares!?
> 
> I want to point out one thing.  No, two.  One is that i concur
> with all left hand side arguments of PHKs blog post that was
> linked a 100 percent.  But that is my personal opinion.

I mean that this is "tech" resource about freebsd.
Who and what doing outside source tree is irrelivant.

ossobser...@redchan.it - idiot.
CoC - stupid thing.


PS: sorry for offtopic.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Danish FreeBSD Developer hates jews collectively

[Rozhuk Ivan]

On Thu, 09 May 2019 18:03:04 +
ossobser...@redchan.it wrote:

> Background: Apparently a FreeBSD developer, a viking looking fellow,  
> has been hiding a secret: just as many of his predecessors in the
> Danish cities during WWII (collaborators); He has a disdain for "the
> jews" collectively.
> 

Who cares!?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot hang on ryzen based notebook

[Rozhuk Ivan]

On Wed, 3 Apr 2019 09:05:22 +0200
Yamagi Burmeister  wrote:

> > > You wrote "apic.0.disabled", not "acpi.0.disabled". Are you sure
> > > you wrote the correct command? You do not want to disable the APIC
> > > (interrupt controller), but the ACPI (control and power
> > > interface).  
> > 
> > hint.acpi.0.disabled="1" - 11.13.1.
> > Then set:
> > panic: running without device atpic requires a local APIC  
> 
> Most modern hardware won't boot without ACPI. But I can get my Lenovo
> E485 to boot with Linux and FreeBSD if I disable IOMMU aupport in the
> BIOS / UEFI.
> 

With hw.pci.mcfg=0 - boot ok.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot hang on ryzen based notebook

[Rozhuk Ivan]

On Sat, 30 Mar 2019 19:49:06 +0200
Darius Mihai  wrote:

> > > I haven't actually tried with FreeBSD, but Linux also seems to
> > > have a similar problem that can be fixed by disabling ACPI.
> > > See 11.13.2.3 in
> > > https://www.freebsd.org/doc/handbook/acpi-overview.html and tell
> > > us how it works.
> > >  
> >
> > Panic with hint.apic.0.disabled="1":
> > https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203260=edit
> >
> > I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp().
> > - "No usable event timer found!"  
> 
> You wrote "apic.0.disabled", not "acpi.0.disabled". Are you sure you
> wrote the correct command? You do not want to disable the APIC
> (interrupt controller), but the ACPI (control and power interface).

hint.acpi.0.disabled="1" - 11.13.1.
Then set:
panic: running without device atpic requires a local APIC
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Boot hang on ryzen based notebook

[Rozhuk Ivan]

On Sat, 30 Mar 2019 16:37:06 +0200
Darius Mihai  wrote:


> I haven't actually tried with FreeBSD, but Linux also seems to have a
> similar problem that can be fixed by disabling ACPI.
> See 11.13.2.3 in
> https://www.freebsd.org/doc/handbook/acpi-overview.html and tell us
> how it works.
> 

Panic with hint.apic.0.disabled="1":
https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203260=edit

I try also hw.mca.enabled=0, but it panic on cpu_initclocks_bsp(). - "No usable 
event timer found!"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Boot hang on ryzen based notebook

[Rozhuk Ivan]

Hello!

Cant boot on ASUS VivoBook 15 X505ZA (AMD Ryzen 5 2500U)
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=236899
Sreenshot: https://bugs.freebsd.org/bugzilla/attachment.cgi?id=203257

Any ideas how to start?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 12 kernel broken

[Rozhuk Ivan]

On Mon, 25 Mar 2019 06:13:28 +1100
Peter Jeremy  wrote:

> On 2019-Mar-22 19:08:18 +0300, Rozhuk Ivan 
> wrote:
> >ld: error: undefined symbol: xz_dec_init  
> >>>> referenced by g_uzip_lzma.c:106
> >>>> (/usr/src/sys/geom/uzip/g_uzip_lzma.c:106)
> >>>> g_uzip_lzma.o:(g_uzip_lzma_ctor)  
> >
> >ld: error: undefined symbol: xz_dec_run  
> >>>> referenced by g_uzip_lzma.c:81
> >>>> (/usr/src/sys/geom/uzip/g_uzip_lzma.c:81)
> >>>> g_uzip_lzma.o:(g_uzip_lzma_decompress)  
> >
> >ld: error: undefined symbol: xz_dec_end  
> >>>> referenced by g_uzip_lzma.c:60
> >>>> (/usr/src/sys/geom/uzip/g_uzip_lzma.c:60)
> >>>> g_uzip_lzma.o:(g_uzip_lzma_free)  
> >--- kernel.full ---
> >*** [kernel.full] Error code 1  
> 
> Are you talking about FreeBSD 12 or FreeBSD 13?
> 

12
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD 12 kernel broken

[Rozhuk Ivan]

On Fri, 22 Mar 2019 12:12:44 -0700
Maxim Sobolev  wrote:

> src/UPDATING entry perhaps in order?
> 
> > Read the updated man page for geom_uzip.  Add
> > device xz
> > to your kernel config.


https://www.freebsd.org/cgi/man.cgi?query=geom_uzip=0=0=FreeBSD+13-current=default=html
https://www.freebsd.org/cgi/man.cgi?query=geom_uzip=0=0=FreeBSD+12.0-stable=default=html

I see nothing about xz.
src/UPDATING - nothing.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

FreeBSD 12 kernel broken

[Rozhuk Ivan]

ld: error: undefined symbol: xz_dec_init
>>> referenced by g_uzip_lzma.c:106 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:106)
>>>   g_uzip_lzma.o:(g_uzip_lzma_ctor)

ld: error: undefined symbol: xz_dec_run
>>> referenced by g_uzip_lzma.c:81 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:81)
>>>   g_uzip_lzma.o:(g_uzip_lzma_decompress)

ld: error: undefined symbol: xz_dec_end
>>> referenced by g_uzip_lzma.c:60 (/usr/src/sys/geom/uzip/g_uzip_lzma.c:60)
>>>   g_uzip_lzma.o:(g_uzip_lzma_free)
--- kernel.full ---
*** [kernel.full] Error code 1

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: sha256 speed

[Rozhuk Ivan]

On Mon, 7 Jan 2019 01:17:45 +0100
Stefan Ehmann  wrote:

> Hello,
> 
> On my Ryzen the sha256 command is much slower than openssl dgst
> -sha256. For large files, openssl is more than 7 times faster in
> practice.
> 
> You can also test it with the builtin benchmarks:
> sha256 -t
> openssl speed sha256
> 
> I think the reason is that openssl supports the SHA CPU extensions
> whereas libmd (used by sha256) does not.
> 
> Any chance we can make the base sha256 faster?
> I guess there is some reason why we use libmd instead of openssl.
> 
> https://reviews.freebsd.org/D2651 looks related but not sure it's
> still relevant.


Do not look into FreeBSD code )
You can take mine code: 
https://github.com/rozhuk-im/liblcb/blob/master/include/crypto/hash/sha2.h
there is Plain C and SHA versions.
I see SSE version in internet but do not implement it in mine sha2 code, only 
for sha1 now.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 19:41:47 -0500
Daniel Eischen  wrote:

> >> I'm trying to track down a couple of things.  amdtemp doesn't
> >> report any temperature sensors, and acpi seems to have some
> >> errors.  Not sure if they are related.  
> > 
> > It s a bit legacy )
> > Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
> > does not use amdsmn.  
> 
> Thanks, I think?!  I tried it and it panic'd as soon as it was
> kldload'd.  I don't have the trace back handy, but it was in a mtx
> lock after a pci_write.  I'm running 13-current, so it could be
> something different between that and -stable or whatever you're
> testing it on.


I do not test it on 13.
Make sure that you have not amdtemp and amdsmn built in kernel and that they 
not loaded.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 13:14:46 -0800
Conrad Meyer  wrote:

> You can adjust dev.amdtemp.N.sensor_offset as needed.  By default, the
> amdtemp sysctl gives you the unadjusted value.  On different Ryzen
> models the raw value is wrong by different amounts.  E.g. on my 1950X,
> I have sensor_offset set to "-27" to show correct temperature
> readings.
> 

Looks like new AGESA/BIOS change something, my fork of amdtemp now show (read) 
same value as on onboard led in "CurTmpTjSel"
...
dev.amdtemp.0.rtc.CurTmpTjSel: 47.7C
dev.amdtemp.0.rtc.CurTmp: 96.7C
...
49C diff, this was some sort of offset for older AMD CPU, used to calc 
CurTmpTjSel then it set to 3.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: No amdtemp sysctls, acpi errors, AMD Ryzen 5 2400G

[Rozhuk Ivan]

On Tue, 13 Nov 2018 12:59:59 -0500 (EST)
Daniel Eischen  wrote:

> I'm trying to track down a couple of things.  amdtemp doesn't
> report any temperature sensors, and acpi seems to have some
> errors.  Not sure if they are related.

It s a bit legacy )
Try mine: http://www.netlab.linkpc.net/download/tmp/amdtemp.c
does not use amdsmn.

On newer BIOS it swap CurTmpTjSel and CurTmp, and CurTmp show >90C.
I dont know why, @cem may know.

dev.amdtemp.0.htc.PslApicLoEn: 1
dev.amdtemp.0.htc.PslApicHiEn: 1
dev.amdtemp.0.htc.HtcActSts: 1
dev.amdtemp.0.htc.HtcAct: 1
dev.amdtemp.0.htc.HtcPstateLimit: 7
dev.amdtemp.0.htc.HtcSlewSel: 1
dev.amdtemp.0.htc.HtcLock: 1
dev.amdtemp.0.htc.HtcEn: 1
dev.amdtemp.0.htc.HtcHystLmt: 7.6C
dev.amdtemp.0.htc.HtcTmpLmt: 115.6C
dev.amdtemp.0.tts.core1.sensor1_offset: 0
dev.amdtemp.0.tts.core1.sensor0_offset: 0
dev.amdtemp.0.tts.core1.sensor1: -0.9C
dev.amdtemp.0.tts.core1.sensor0: -0.9C
dev.amdtemp.0.tts.core0.sensor1_offset: 0
dev.amdtemp.0.tts.core0.sensor0_offset: 0
dev.amdtemp.0.tts.core0.sensor1: -0.9C
dev.amdtemp.0.tts.core0.sensor0: -0.9C
dev.amdtemp.0.tts.thermtrip: 0
dev.amdtemp.0.tts.sense: 1
dev.amdtemp.0.tts.enable: 0
dev.amdtemp.0.tts.DiodeOffset: 13
dev.amdtemp.0.tts.TjOffset: 0
dev.amdtemp.0.rtc.sensor_offset: 0
dev.amdtemp.0.rtc.PerStepTimeUp: 15
dev.amdtemp.0.rtc.PerStepTimeDn: 15
dev.amdtemp.0.rtc.TmpMaxDiffUp: 3
dev.amdtemp.0.rtc.TmpSlewDnEn: 1
dev.amdtemp.0.rtc.CurTmpTjSel: 1.6C
dev.amdtemp.0.rtc.CurTmp: 50.6C
dev.amdtemp.0.%parent: hostb10
dev.amdtemp.0.%pnpinfo: 
dev.amdtemp.0.%location: 
dev.amdtemp.0.%driver: amdtemp
dev.amdtemp.0.%desc: AMD CPU On-Die Thermal Sensors
dev.amdtemp.%parent: 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Current status of Ryzen (non-)support

[Rozhuk Ivan]

On Sun, 21 Oct 2018 18:09:50 +0200
Hannes Hauswedell  wrote:

> I wanted to ask what the current status of Ryzen support is and/or
> whether any new changes are planned.
> 
> My situation:
> * second generation Ryzen: 2600X
> * running -CURRENT
> * I have done the things described here:
> https://lists.freebsd.org/pipermail/freebsd-current/2018-June/069799.html
> * no full system freezes, but under load, e.g. building with 12
> threads, programs start to segfault.
> * memtest86 ran through without issues
> * on a Linux dual boot I haven't had any issues
> 
>

1300X (25 week), 2200G, 2700X - OK on 11.2
I do not apply any fixes provided by @kib in "Ryzen public erratas".

Mine FreeBSD configs and tunings:
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/11.2/base/
http://www.netlab.linkpc.net/download/software/os_cfg/FBSD/11.2/wks/

Asrock Taichi x370 have strange proublems with PCI-e devices on BIOS ver > 4.60:
after load any smbus drivers pcie stop work or do it very strange.
Also with PinnaclePI-AM4_1.0.0.5 mine amdtemp driver read strange temperature, 
@cem should know more about this.
http://forum.asrock.com/forum_posts.asp?TID=9833=56770

Last time I have segfaults on bad mem modules contacts (fix: clean and 
reinstall) and mine coller do many pressure.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Mon, 1 Oct 2018 01:04:20 +0200
Wolfgang Zenker  wrote:

> > drm-next requires FreeBSD 12, I do not try it yet.  
> 
> that is no longer true; drm-next requires at least FreeBSD 11.2 now

Got kernel panic on amdgpu load.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Sun, 30 Sep 2018 23:38:02 +
Johannes Dieterich  wrote:

> > /usr/ports/graphics/drm-kmod
> > /usr/ports/graphics/drm-stable-kmod
> > /usr/ports/graphics/drm-legacy-kmod
> > /usr/ports/graphics/drm-next-kmod
> > /usr/ports/graphics/drm-devel-kmod
> > 
> > Too many drm...  
> Which is why there is graphics/drm-kmod which will install the most
> recent recommended DRM for your OS version. Could you try that?

It install graphics/drm-stable-kmod.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Sun, 30 Sep 2018 23:21:36 +
Johannes Dieterich  wrote:

 
> > drm-next requires FreeBSD 12, I do not try it yet.  
> It requires a FreeBSD version equal or higher than 1101511, could you
> provide sysctl kern.osrelease?

kern.osrelease: 11.2-STABLE

/usr/ports/graphics/drm-kmod
/usr/ports/graphics/drm-stable-kmod
/usr/ports/graphics/drm-legacy-kmod
/usr/ports/graphics/drm-next-kmod
/usr/ports/graphics/drm-devel-kmod

Too many drm...
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Sun, 30 Sep 2018 20:37:07 +
Johannes Dieterich  wrote:

> > finishing device. [TTM] Memory type 2 has not been initialized
> > device_attach: drmn0 attach returned 22  
> Just to make sure, the gpu-firmware port is installed
> and /boot/modules contains these files the load is looking for? Which
> drm port gets installed if you use the new graphics/drm-kmod
> metaport? If it is next, could you try with that?


# pkg version -v | grep gpu
gpu-firmware-kmod-g20180825=   up-to-date with index
xf86-video-amdgpu-1.3.0_3  =   up-to-date with index

# pkg version -v | grep kmod
drm-stable-kmod-g20180822  =   up-to-date with index
gpu-firmware-kmod-g20180825=   up-to-date with index

# ls /boot/modules/ | grep carrizo
-r-xr-xr-x   1 root  wheel13K Aug 26 21:20:06 2018 amdgpu_carrizo_ce_bin.ko*
-r-xr-xr-x   1 root  wheel21K Aug 26 21:20:06 2018 amdgpu_carrizo_me_bin.ko*
-r-xr-xr-x   1 root  wheel   261K Aug 26 21:20:06 2018 
amdgpu_carrizo_mec_bin.ko*
-r-xr-xr-x   1 root  wheel   261K Aug 26 21:20:06 2018 
amdgpu_carrizo_mec2_bin.ko*
-r-xr-xr-x   1 root  wheel21K Aug 26 21:20:06 2018 
amdgpu_carrizo_pfp_bin.ko*
-r-xr-xr-x   1 root  wheel23K Aug 26 21:20:06 2018 
amdgpu_carrizo_rlc_bin.ko*
-r-xr-xr-x   1 root  wheel15K Aug 26 21:20:06 2018 
amdgpu_carrizo_sdma_bin.ko*
-r-xr-xr-x   1 root  wheel15K Aug 26 21:20:06 2018 
amdgpu_carrizo_sdma1_bin.ko*
-r-xr-xr-x   1 root  wheel   270K Aug 26 21:20:06 2018 
amdgpu_carrizo_uvd_bin.ko*
-r-xr-xr-x   1 root  wheel   176K Aug 26 21:20:06 2018 
amdgpu_carrizo_vce_bin.ko*


drm-next requires FreeBSD 12, I do not try it yet.


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Sun, 30 Sep 2018 18:12:01 +
Johannes Dieterich  wrote:

> > I try drm-stable-kmod-g20180822 but it fail to load, as I
> > understand.  
> That should work, could you post the error messages? I assume you
> followed the instructions in the port? 


# kldload /boot/modules/amdgpu.ko

[drm] Initialized
[drm] amdgpu kernel modesetting enabled.
drmn0:  on vgapci0
vgapci0: child drmn0 requested pci_enable_io
vgapci0: child drmn0 requested pci_enable_io
[drm] initializing kernel modesetting (CARRIZO 0x1002:0x9874 0x1002:0x1E20 
0xE2).
[drm] register mmio base: 0xFE90
[drm] register mmio size: 262144
[drm] doorbell mmio base: 0xF000
[drm] doorbell mmio size: 8388608
[drm:amdgpu_device_init] 
Unable to find PCI I/O BAR
[drm] probing mlw for device 1002:9874 = 0
[drm] UVD is enabled in physical mode
[drm] VCE enabled in physical mode
[drm:amdgpu_atombios_init] Unable to find PCI I/O BAR; using MMIO for ATOM IIO
ATOM BIOS: BRISTOL
[drm] GPU post is not needed
Zone  kernel: Available graphics memory: 3104154 kiB
Zone   dma32: Available graphics memory: 2097152 kiB
[TTM] Initializing pool allocator
drmn0: VRAM: 2048M 0x - 0x7FFF (2048M used)
drmn0: GTT: 3031M 0x8000 - 0x00013D7667FF
[drm] Detected VRAM RAM=2048M, BAR=256M
[drm] RAM width 64bits UNKNOWN
[drm] amdgpu: 2048M of VRAM memory ready
[drm] amdgpu: 3031M of GTT memory ready.
[drm] GART: num cpu pages 776038, num gpu pages 776038
[drm] PCIE GART of 3031M enabled (table at 0x0004).
[drm] Supports vblank timestamp caching Rev 2 (21.10.2013).
[drm] Driver supports precise vblank timestamp query.
[drm] amdgpu: irq initialized.
amdgpu: powerplay initialized
[drm] Connector DP-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.DP-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-1: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-1
[drm]   - kern.vt.fb.default_mode
[drm] Connector HDMI-A-2: get mode from tunables:
[drm]   - kern.vt.fb.modes.HDMI-A-2
[drm]   - kern.vt.fb.default_mode
[drm] AMDGPU Display Connectors
[drm] Connector 0:
[drm]   DP-1
[drm]   HPD1
[drm]   DDC: 0x4868 0x4868 0x4869 0x4869 0x486a 0x486a 0x486b 0x486b
[drm]   Encoders:
[drm] DFP1: INTERNAL_UNIPHY
[drm] Connector 1:
[drm]   HDMI-A-1
[drm]   HPD2
[drm]   DDC: 0x486c 0x486c 0x486d 0x486d 0x486e 0x486e 0x486f 0x486f
[drm]   Encoders:
[drm] DFP2: INTERNAL_UNIPHY
[drm] Connector 2:
[drm]   HDMI-A-2
[drm]   HPD3
[drm]   DDC: 0x4870 0x4870 0x4871 0x4871 0x4872 0x4872 0x4873 0x4873
[drm]   Encoders:
[drm] DFP3: INTERNAL_UNIPHY1
amdgpu/carrizo_pfp.bin: could not load firmware image, error 2
amdgpu/carrizo_pfp.bin: could not load firmware image, error 2
amdgpu/carrizo_me.bin: could not load firmware image, error 2
amdgpu/carrizo_me.bin: could not load firmware image, error 2
amdgpu/carrizo_ce.bin: could not load firmware image, error 2
amdgpu/carrizo_ce.bin: could not load firmware image, error 2
amdgpu/carrizo_rlc.bin: could not load firmware image, error 2
amdgpu/carrizo_rlc.bin: could not load firmware image, error 2
amdgpu/carrizo_mec.bin: could not load firmware image, error 2
amdgpu/carrizo_mec.bin: could not load firmware image, error 2
amdgpu/carrizo_mec2.bin: could not load firmware image, error 2
amdgpu/carrizo_mec2.bin: could not load firmware image, error 2
drmn0: fence driver on ring 0 use gpu addr 0x8010, cpu addr 
0x0xf800444aa010
drmn0: fence driver on ring 1 use gpu addr 0x8020, cpu addr 
0x0xf800444aa020
drmn0: fence driver on ring 2 use gpu addr 0x8030, cpu addr 
0x0xf800444aa030
drmn0: fence driver on ring 3 use gpu addr 0x8040, cpu addr 
0x0xf800444aa040
drmn0: fence driver on ring 4 use gpu addr 0x8050, cpu addr 
0x0xf800444aa050
drmn0: fence driver on ring 5 use gpu addr 0x8060, cpu addr 
0x0xf800444aa060
drmn0: fence driver on ring 6 use gpu addr 0x8070, cpu addr 
0x0xf800444aa070
drmn0: fence driver on ring 7 use gpu addr 0x8080, cpu addr 
0x0xf800444aa080
drmn0: fence driver on ring 8 use gpu addr 0x8090, cpu addr 
0x0xf800444aa090
amdgpu/carrizo_sdma.bin: could not load firmware image, error 2
amdgpu/carrizo_sdma.bin: could not load firmware image, error 2
amdgpu/carrizo_sdma1.bin: could not load firmware image, error 2
amdgpu/carrizo_sdma1.bin: could not load firmware image, error 2
drmn0: fence driver on ring 9 use gpu addr 0x80a0, cpu addr 
0x0xf800444aa0a0
drmn0: fence driver on ring 10 use gpu addr 0x80b0, cpu addr 
0x0xf800444aa0b0
amdgpu/carrizo_uvd.bin: could not load firmware image, error 2
amdgpu/carrizo_uvd.bin: could not load firmware image, error 2
[drm] Found UVD firmware Version: 1.91 Family ID: 11
drmn0: fence driver on ring 11 use gpu addr 0x00681560, cpu addr 
0x0xf800e0681560
amdgpu/carrizo_vce.bin: could not load firmware image, error 2
amdgpu/carrizo_vce.bin: could not 

Re: APU Bristol Ridge graphics support

[Rozhuk Ivan]

On Sun, 30 Sep 2018 17:04:26 +
Johannes Dieterich  wrote:

> > A10-9700
> > Bristol Ridge Radeon R7
> > 
> > vgapci0@pci0:0:1:0: class=0x03 card=0x1e201002
> > chip=0x98741002 rev=0xe2 hdr=0x00 vendor = 'Advanced Micro
> > Devices, Inc. [AMD/ATI]' device = 'Wani [Radeon R5/R6/R7
> > Graphics]' class  = display
> > subclass   = VGA  

> Yes, I've had a Bristol Ridge as a daily driver until a few days ago.
> Use the LinuxKPI based DRM from ports, if you are on CURRENT
> graphics/drm-devel-kmod, and load amdgpu.ko.
> 

I am on 11.2.

I try drm-stable-kmod-g20180822 but it fail to load, as I understand.

Is xf86-video-amdgpu must be used with drm-*-kmod* ?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

APU Bristol Ridge graphics support

[Rozhuk Ivan]

Hello!

Is this graphics supported?

A10-9700
Bristol Ridge Radeon R7

vgapci0@pci0:0:1:0: class=0x03 card=0x1e201002 chip=0x98741002 rev=0xe2 
hdr=0x00
vendor = 'Advanced Micro Devices, Inc. [AMD/ATI]'
device = 'Wani [Radeon R5/R6/R7 Graphics]'
class  = display
subclass   = VGA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Good motherboard for Ryzen (first-gen)

[Rozhuk Ivan]

On Sat, 22 Sep 2018 20:28:22 +0200
Stefan Ehmann  wrote:

> Minor issues:
> - powerd/amdtemp don't work correctly, I'll probably retest when
> 12-BETA is out

Will not.
We does not have rep CPU temp offset table.

Not sure about thing in base, but mine AMDTemp: 
https://reviews.freebsd.org/D9759
have sysctl tune for temperature offset, you can use it.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Good motherboard for Ryzen (first-gen)

[Rozhuk Ivan]

On Fri, 21 Sep 2018 21:53:20 -0500
Eric van Gyzen  wrote:

> I would like to build a Ryzen desktop.  Can anyone recommend a good 
> motherboard?

https://www.hardwareluxx.de/community/f12/pga-am4-mainboard-vrm-liste-1155146.html
Any MoBo based on IR35201 or ASP1405I.

 
> I'm planning on a first-gen, because the second-gen has similar 
> stability problems as the first-gen had, and AMD hasn't released
> errata for the second-gen yet (as far as I know...I would love to be
> wrong).
> 

I dont see any issies with Ryzens: 1300x (25 week), 2200G, 2700x.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP server app performance

[Rozhuk Ivan]

On Sun, 12 Aug 2018 18:50:17 +0200
Honda Michio  wrote:

> I'm measuring TCP server app performance using my toy web server.
> It just accept TCP connections and responds back HTTP OK to the
> clients. It monitors sockets using kqueue, and processes each ready
> descriptor using a pair of read() and write(). (in more detail, it's
> https://github.com/micchie/netmap/tree/paste/apps/phttpd)
> 

PS:
2. SO_REUSEPORT_LB
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: TCP server app performance

[Rozhuk Ivan]

On Sun, 12 Aug 2018 18:50:17 +0200
Honda Michio  wrote:

> I'm measuring TCP server app performance using my toy web server.
> It just accept TCP connections and responds back HTTP OK to the
> clients. It monitors sockets using kqueue, and processes each ready
> descriptor using a pair of read() and write(). (in more detail, it's
> https://github.com/micchie/netmap/tree/paste/apps/phttpd)

1. Call accept() in loop until get error.
2. Use reuseport option for load balance.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Rozhuk Ivan]

On Mon, 21 May 2018 10:07:28 -0700
Steve Kargl  wrote:

> Why?  "If it isn't broken, why fix it?"
> 
> The conflict affects x86_64-*-freebsd aka amd64.  The
> conflict does not affect any other architecture.  The
> Makefile infrastructure can use MACHINE_ARCH to exclude
> drm2 from build of amd64.
> 
> I don't use netgraph or any of the if_*.ko modules.
> Can we put all of that into ports?  I don't use any
> scsi controllers, so those can go too.  Why make it
> insanely fun for users to configure a FreeBSD system.
> 

I just ask.
Or why not include drm-next to base svn repo and add some
option to make.conf to swith drm2/dem-next ?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Rozhuk Ivan]

On Sun, 20 May 2018 21:10:28 +0200
Oliver Pinter  wrote:

> > One of the reasons for the deprecation and removal of the drm2 bits
> > is that they prevent us from automatically loading the
> > drm-next/stable-kmod kernel modules, since the two collide.
> > Regards  
> 
> 
> Then it wold be better to resolve this problem, rather then removing a
> working solution. What's about module versioning what in other cases
> works?
> 

May be just move old drm2 to ports?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Rozhuk Ivan]

On Sun, 20 May 2018 16:32:50 +0100
Johannes Lundberg  wrote:

> Not in the current port.
> I think it should be usable in 4.15 but need some more tweaking and
> updated firmware modules before we can update the port.
> Active development going on here
> https://github.com/FreeBSDDesktop/kms-drm/issues


Thanks!
What futures will avaible in 4.15 - 4.16?
Video decoding acceleration?
3d acceleration?

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: [RFC] Deprecation and removal of the drm2 driver

[Rozhuk Ivan]

On Fri, 18 May 2018 21:12:26 +0100
Johannes Lundberg  wrote:

Is Ryzen 2200G integrated graphic supported?


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: SSP_CFLAGS for kernel

[Rozhuk Ivan]

On Sat, 5 May 2018 12:38:37 +0200
bryn1u85  wrote:

> Don't touch src.conf

I want to buils kernel and system with SSP too.

 
> Entry for make.conf should looks like below:
> 
> WITH_SSP_PORTS=YES
> 
> SSP_CFLAGS=-fstack-protector-all
> 
> SSP_CXXFLAGS=-fstack-protector-all
 
SSP_CXXFLAGS does not used in system and ports, at least on 11.2.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

SSP_CFLAGS for kernel

[Rozhuk Ivan]

Hi!

I set:

/etc/src.conf:
WITH_SSP=

/etc/make.conf:
SSP_CFLAGS=-fstack-protector-all
WITH_SSP_PORTS=yes


But in /usr/src/sys/conf/kern.mk:

...
#
# GCC SSP support
#
.if ${MK_SSP} != "no" && \
${MACHINE_CPUARCH} != "arm" && ${MACHINE_CPUARCH} != "mips"
CFLAGS+=-fstack-protector
.endif
...


Is there should be some thing like in /usr/src/share/mk/bsd.sys.mk:

SSP_CFLAGS?=-fstack-protector
CFLAGS+=${SSP_CFLAGS}

???


PS: /usr/ports/UPDATING
"The default SSP_CLFAGS is -fstack-protector, but -fstack-protector-all"
should be:
"The default SSP_CFLAGS is -fstack-protector, but -fstack-protector-all"
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: Speed up CD/DVD-based FreeBSD

[Rozhuk Ivan]

On Wed, 14 Mar 2018 17:13:27 +0100
"Hartmann, O."  wrote:

> The image itself is "custom made", since NanoBSD doesn't offer a
> proper CD9660 build script. But, it isn't hard to add some
> functionality to achive this task.

May be geom_cache can help increase random read speed?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: FreeBSD has a politics problem

[Rozhuk Ivan]

On Sat, 03 Mar 2018 17:30:14 -0500
John Darrah  wrote:

> FreeBSD recently introduced an updated Code of Conduct that
> developers and members must adhere to. There has been much backlash
> online about it and about introducing identity politics into a
> technical OS project in general. The Code of Conduct was adopted from
> the "Geek Feminism" wiki's version, which claims (among other things)
> that racism against whites doesn't exist, sexism against men doesn't
> exist, and that certain protected classes of people should not be
> criticised.
> 

+1
All people on the Internet are equal, there is nothing to discuss.
Any rules/CoC asserting the opposite are absurd.


The more you learn about the relationships and decisions in FreeBSD, the more 
doubts it is to continue to deal with this.

- Take the commit bit from an Iranian developer. (for me it's rumors, I can be 
wrong)

- History with John Marino a year ago:
https://lists.freebsd.org/pipermail/freebsd-ports/2017-February/107225.html

- Now this strange code of conduct, when quite neutral could be taken: 
https://www.kde.org/code-of-conduct/
and do not spend money.


As for me personally, I do not understand where the logic is in many technical 
solutions, from those that I see.
Perhaps these are differences of mentality and language.

1. The system does not still have the O_EVTONLY and O_NOATIME flags for open ().
CoreTeam believes that FreeBSD should only work on servers?

2. 3+ years in the glib broken GFileMonitor and it was completely off then the 
applications crashed and eerily braked.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=199872
While 1+ year there were two solutions to the problem:
a. go to libinotify and do not use the clumsy kqueue () code from glib
b. use my alternative kqueue () code: 
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214338

As a result, wait clumsy patches of glib with which everything is still slow.
I got the feeling that no one here at all does not care about FreeBSD users on 
workstations.

3. For 4 years there is still no support for modern LTE / 4g modems.
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192345
I rolled up the patch, checked it, then I also made a couple of significant, I 
think, improvements in logic, as a result, my first version of the patch, 
slightly modified in the design, is added to the system.

4. I do not understand why I had to add an extra driver to the system
"amdsmn - Family 17h System Management Network" which is only needed in amdtemp.
https://reviews.freebsd.org/D12217

5. Constant begging in the mailing list to pay attention to the patches in the 
bugzilla and added to the ports / system.
Otherwise, patches in bugzilla hang for months and years
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=223758

6. Imposing the use of poudriere port committers.

7. TCP stack which at considerable RTT and losses gives in times less speed 
than in Linux.
The minimum set of CC algorithms in the base.


In my experience CoreTeam (or whatever it is) is engaged in politics and code 
writing, and takes little care of both project and community management.
I see how people who do much go away, nobody takes their place, nobody does 
their work. This is bad for the project and for users.
Everything described above quite strongly demotivates me personally from any 
activity in the project.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: CURRENT: FreeBSD not reporting AES-NI on Intel(R) Xeon(R) CPU E5-1650 v3

[Rozhuk Ivan]

On Fri, 17 Mar 2017 17:53:24 +0100
"O. Hartmann"  wrote:

> > Other OS detect AES-NI on this server?  
> 
> I havn't ried so far, the box is in heavy use. I'd like to check with
> some live USB drive versions and report later.
> 

You can write or find some program that read and decode CPUID and check
AES-NI support without reboot.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Rozhuk Ivan]

On Wed, 8 Mar 2017 09:02:05 +0100
Olivier Cochard-Labbé <oliv...@freebsd.org> wrote:

> On Wed, Mar 8, 2017 at 7:29 AM, Rozhuk Ivan <rozhuk...@gmail.com>
> wrote:
> 
> >
> > Try now with last version of patch.
> >
> > ​Compile now and works on PC Engine APU1 and APU2:
> 

Thanks!

sysctl hw.model
please.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Rozhuk Ivan]

On Mon, 6 Mar 2017 13:23:40 +0100
Olivier Cochard-Labbé  wrote:

> > New amdtemp driver needs more testers!
> > https://reviews.freebsd.org/D9759
> ​
> This patch apply correctly (on 12-head r314770), but a "make
> buildkernel" failed with
> 
> ​--- all_subdir_amdtemp ---
> /usr/src/sys/modules/amdtemp/../../dev/amdtemp/amdtemp.c:1083:54:
> error: too few arguments to function call, expected 11, have 10
> regs[i].oid_handler, regs[i].fmt, regs[i].descr);
>^

Try now with last version of patch.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

Re: AMD CPU/APU temperature driver

[Rozhuk Ivan]

On Mon, 6 Mar 2017 10:04:06 +0100
Matthias Apitz  wrote:

> > rus/eng: http://netlab.dhis.org/wiki/ru:software:freebsd:amdtemp  
> 
> The English version of the Wiki gives only: This topic does not exist
> yet. Is there an English version?
> 

Sory, now avaible.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"

AMD CPU/APU temperature driver

[Rozhuk Ivan]

Hi!


New amdtemp driver needs more testers!


https://reviews.freebsd.org/D9759

Fast buld/install:
...download and apply patch...
kldunload amdtemp
cd /usr/src/sys/modules/amdtemp/
make
make install
make cleandir
kldload amdtemp


rus/eng: http://netlab.dhis.org/wiki/ru:software:freebsd:amdtemp


Read methods:
 - D18F3xE4 Thermtrip Status Register (TTS)
 - D18F3x64 Hardware Thermal Control (HTC) - tunables only, no temperature
 - D18F3xA4 Reported Temperature Control Register (RTC)
 - SB-TSI - Temperature Sensor Interface via CPU registers (TSI)
 - TSI via SMBus - not supported yet



Tunables:

D18F3xE4 Thermtrip Status Register
 - TjOffset (RD) - This field is the offset from CurTmp used to normalize to 
Tcontrol.
 - DiodeOffset (RD) - Thermal diode offset is used to correct the measurement 
made by an external temperature sensor.
 - ThermtpEn (RD) - The THERMTRIP state is supported by the processor.
 - Thermtrip (RD) - The processor has entered the THERMTRIP state.

D18F3x64 Hardware Thermal Control (HTC)
 - HtcTmpLmt (RD, Kelvin) - HTC temperature limit
 - HtcHystLmt (RW, Kelvin) - HTC hysteresis. The processor exits the HTC active 
state when the temperature selected by HtcSlewSel is less than the HTC 
temperature limit (HtcTmpLmt) minus the HTC hysteresis (HtcHystLmt).
 - HtcEn (RW) - HTC is enabled; the processor is capable of entering the 
HTC-active state.
 - HtcLock (RW) - HtcPstateLimit, HtcHystLmt, HtcTmpLmt, and HtcEn are 
read-only.
 - HtcSlewSel (RW) - HTC slew-controlled temperature select.
 - HtcPstateLimit (RW) - HTC P-state limit select.
 - HtcAct (RW) - The processor is currently in the HTC-active state.
 - HtcActSts (RW) - set-by-hardware; write-1-to-clear. Reset: 0. This bit is 
set by hardware when the processor enters the HTC-active state. It is cleared 
by writing a 1 to it.
 - PslApicHiEn (RW) - P-state limit higher value change APIC interrupt enable.
 - PslApicLoEn (RW) - P-state limit lower value change APIC interrupt enable.

D18F3xA4 Reported Temperature Control Register
 - CurTmp (RD, Kelvin) - Provides the current control temperature, Tctl, after 
the slew-rate controls have been applied.
 - CurTmpTjSel (RW, Kelvin) - Specifies a value used to create Tctl.
 - TmpSlewDnEn (RW) - Temperature slew downward enable.
 - TmpMaxDiffUp (RW) - Specifies the maximum difference, (Tctlm - Tctl), when 
Tctl immediatly updates to Tctlm.
 - PerStepTimeDn (RW) - Specifies the time that Tctlm must remain below Tctl 
before applying a 0.125 downward step.
 - PerStepTimeUp (RW) - Specifies the time that Tctlm must remain above Tctl 
before applying a 0.125 upward step.

SB-TSI registers
 - cpu_temperature (RD, Kelvin) - CPU Temperature
 - high_temperature_threshold (RD, Kelvin) - High Temperature Threshold
 - low_temperature_threshold (RD, Kelvin) - Low Temperature Threshold
 - cpu_temperature_offset_hi (RW) - CPU Temperature Offset High Byte
 - cpu_temperature_offset_lo (RW) - CPU Temperature Offset Low Byte
 - status (RW) - SB-TSI Status
 - cfg3 (RW) - SB-TSI Configuration Register 0x03
 - cfg9 (RW) - SB-TSI Configuration Register 0x09
 - upd_rate (RW) - Update Rate
 - timeout_cfg (RW) - Timeout Configuration
 - alert_threshold (RW) - Alert Threshold
 - alert_cfg (RW) - Alert Configuration
 - manufacture_id (RD) - Manufacture ID
 - revision (RD) - SB-TSI Revision



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"