Re: New Xorg - different key-codes

[Greg 'groggy' Lehey]

On Wednesday, 11 March 2020 at  0:20:03 +, Poul-Henning Kamp wrote:
[originally sent to current@]
> I just updated my laptop from source, and somewhere along the way
> the key-codes Xorg sees changed.

Indeed.  This doesn't just affect -CURRENT: it happened to me on
-STABLE last week, so I'm copying that list too.  See
http://www.lemis.com/grog/diary-mar2020.php?topics=c&subtitle=Daily%20teevee%20update&article=D-20200306-002910#D-20200306-002910
, not the first entry on the subject.

> I have the right Alt key mapped to "Multi_key", which is now
> keycode 108 instead of 113, which is now arrow left instead.

Interesting.  Mine wandered from 117 to 147, with PageDown ("Next") as
collateral damage.  It seems that there are a lot of strange new key
bindings (partial output of xmodmap -pk):

117 0xff56 (Next)   0x (NoSymbol)   0xff56 (Next)
130 0xff31 (Hangul) 0x (NoSymbol)   0xff31 (Hangul)
131 0xff34 (Hangul_Hanja)   0x (NoSymbol)   0xff34 
(Hangul_Hanja)
135 0xff67 (Menu)   0x (NoSymbol)   0xff67 (Menu)
147 0x1008ff65 (XF86MenuKB) 0x (NoSymbol)   0x1008ff65 
(XF86MenuKB)

Some of these may reflect other remappings that I have done.

> I hope this email saves somebody else from the frustrating
> morning I had...

Sorry.  I should have thought of reporting it.  For me, with a number
of other issues, it was a frustrating week,some of which are still not
resolved.

Greg
--
Sent from my desktop computer.
Finger g...@freebsd.org for PGP public key.
See complete headers for address and phone numbers.
This message is digitally signed.  If your Microsoft mail program
reports problems, please read http://lemis.com/broken-MUA


signature.asc
Description: PGP signature

New Xorg - different key-codes

[Poul-Henning Kamp]

I just updated my laptop from source, and somewhere along the
way the key-codes Xorg sees changed.

I have the right Alt key mapped to "Multi_key", which is now
keycode 108 instead of 113, which is now arrow left instead.

I hope this email saves somebody else from the frustrating
morning I had...

-- 
Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
p...@freebsd.org | TCP/IP since RFC 956
FreeBSD committer   | BSD since 4.3-tahoe
Never attribute to malice what can adequately be explained by incompetence.
___
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: Emacs tramp mode doesn't work with CURRENT

[John Baldwin]

On 1/28/20 8:57 AM, John F Carr wrote:
> I use emacs tramp mode, which opens an ssh connection to a remote machine for 
> file access.  It works to Linux and FreeBSD 12.1, but not to CURRENT.  There 
> has been a change in the way characters are echoed by the shell, with 12.1 
> treating a consecutive run of backspace as an atomic unit and CURRENT 
> processing them one at a time.  This is not necessarily a bug, but it is a 
> nuisance and independently it is suboptimal.

I have the same breakage with an amd64 laptop running HEAD (and using
tramp-mode from emacs on a 12.x host)

Have you been able to bisect it at all?  I think libedit is probably a
good candidate as well.

What I see is that tramp-mode just hangs until I kill the ssh session it
is using, and then I see the same output you had below in the debug
window showing the extraneous newlines.

-- 
John Baldwin
___
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: System clock is slow

[Konstantin Belousov]

On Tue, Mar 10, 2020 at 12:24:24PM -0400, Theron wrote:
> On 2020-03-10 01:38, Peter Jeremy wrote:
> > Are you running NTP?  If so, is NTP maintaining lock and what is the
> > reported PLL frequency (ntpq -c kerni)?
> 
> Didn't show any useful difference, "kernel status: pll unsync" when I tested
> this.
> 
> > What does "sysctl kern.timecounter" report and have you tried using
> > any of the alternative timecounters listed in kern.timecounter.choice?
> 
> Indeed that reveals the problem:
>     kern.timecounter.hardware: TSC-low
> (before regression)
>     kern.timecounter.tc.TSC-low.frequency: 1296053807
> (after regression)
>     kern.timecounter.tc.TSC-low.frequency: 13
> 
> (why are these tsc_freq divided by two?)
Because it is TSC-low, not TSC timecounter.

> 
> Through some printf's in tsc.c I've determined that the 2.6e9 value is from
> 0x16 CPUID which Intel says is only a nominal value not to be used, whereas
> 2.592e9 value is from calibration.
> 
> /*
>  * Calculate TSC frequency using information from the CPUID leaf 0x15
>  * 'Time Stamp Counter and Nominal Core Crystal Clock'.  If leaf 0x15
>  * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
>  * Frequency Information'.  Leaf 0x16 is described in the SDM as
>  * informational only, but if 0x15 did not work, and TSC calibration
>  * is disabled, it is the best we can get at all.  It should still be
>  * an improvement over the parsing of the CPU model name in
>  * tsc_freq_intel(), when available.
>  */
> 
> The implementation logic for when to use tsc_freq_cpuid() looks wrong to me;
> it doesn't match what this comment implies.  Fallback to calibration when
> calibration is unspecified should proceed when 0x15 fails regardless of what
> 0x16 does.  (CC'd the authors).
Problem is that there are enough machines in wild that do not have ISA
clock in chipset, or BIOS did not bothered configuring the chipset to
make 8254 emulation operational.  Worse, the supposedly intended way for
BIOS to report the absense of the PC AT hardware through the FADT legacy
devices flag is broken on every machine I looked at.

The result of calibration on machine without ISA timer makes the machine
unusable at all.  The removal of 8254 emulation coincides with addition
of the 0x15/0x16 CPUID leafs, so our choice is to do the configuration
based on the widest possible compatibility.  I was told that fallback
to 0x16 is also used by Linux.

You can set machdep.disable_tsc_calibration tunable to 0 to force
calibration if it works for you.

> 
> Switching to HPET or ACPI-fast gives the expected results.  Would there be
> any reason to not use HPET provided I can cope with the performance
> implications?
> The name of the ACPI option varies haphazardly between "ACPI-fast" and
> "ACPI-safe" between reboots, I guess it is sensitive to some buggy vendor
> firmware.
Use HPET if you want, again by manual enable.

BTW, please install sysutils/x86info and provide the output of
x86info -r

> 
> > Are you overclocking your CPU (or doing anything else non-standard)?
> 
> I had previously used powerd to let the CPU underclock to 700MHz when idle. 
> Now, I've lost all control over CPU frequency (either by powerd or by
> sysctl) since there is some in-kernel cpufreq driver which I can't figure
> out how to disable.  It's very much an annoyance, but I think unrelated to
> the timecounter problem.
> 
> Theron
___
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: System clock is slow

[Bakul Shah]

On Mar 10, 2020, at 9:24 AM, Theron  wrote:
> 
> On 2020-03-10 01:38, Peter Jeremy wrote:
>> Are you running NTP?  If so, is NTP maintaining lock and what is the
>> reported PLL frequency (ntpq -c kerni)?
> 
> Didn't show any useful difference, "kernel status: pll unsync" when I tested 
> this.

May take a while. ntpq -c peer should show a line with a leading *.
Though likely unrelated to your problem.

>> What does "sysctl kern.timecounter" report and have you tried using
>> any of the alternative timecounters listed in kern.timecounter.choice?
> 
> Indeed that reveals the problem:
> kern.timecounter.hardware: TSC-low
> (before regression)
> kern.timecounter.tc.TSC-low.frequency: 1296053807
> (after regression)
> kern.timecounter.tc.TSC-low.frequency: 13

In an old (amd 8150) -12.1 machine I see
kern.timecounter.hardware: TSC-low
kern.timecounter.tc.TSC-low.frequency: 1806045908
machdep.tsc_freq: 3612091816

In a new ryzen -current machine:
kern.timecounter.hardware: TSC
kern.timecounter.tc.TSC.frequency: 2096123148
machdep.tsc_freq: 2096123148

> Through some printf's in tsc.c I've determined that the 2.6e9 value is from 
> 0x16 CPUID which Intel says is only a nominal value not to be used, whereas 
> 2.592e9 value is from calibration.
> 
> /*
>  * Calculate TSC frequency using information from the CPUID leaf 0x15
>  * 'Time Stamp Counter and Nominal Core Crystal Clock'.  If leaf 0x15
>  * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
>  * Frequency Information'.  Leaf 0x16 is described in the SDM as
>  * informational only, but if 0x15 did not work, and TSC calibration
>  * is disabled, it is the best we can get at all.  It should still be
>  * an improvement over the parsing of the CPU model name in
>  * tsc_freq_intel(), when available.
>  */
> 
> The implementation logic for when to use tsc_freq_cpuid() looks wrong to me; 
> it doesn't match what this comment implies.  Fallback to calibration when 
> calibration is unspecified should proceed when 0x15 fails regardless of what 
> 0x16 does.  (CC'd the authors).


As I understand it, if the user doesn't *explicitly* disable
frequency calibration, it must be calibrated. It may still be
skipped if there are no legacy devices. See around tsc.c:300.

What does sysctl machdep.disable_tsc_calibration return? Do you
see a line like the following in dmesg?

Skipping TSC calibration since no legacy devices reported by FADT and CPUID 
works

The Commit log says this:

x86: Fall back to leaf 0x16 if TSC frequency is obtained by CPUID and
leaf 0x15 is not functional.

This should improve automatic TSC frequency determination on
Skylake/Kabylake/... families, where 0x15 exists but does not provide
all necessary information.  SDM contains relatively strong wording
against such uses of 0x16, but Intel does not give us any other way to
obtain the frequency. Linux did the same in the commit
604dc9170f2435d27da5039a3efd757dceadc684.

Based on submission by: Neel Chauhan 
PR: 240475
Reviewed by:markj
Sponsored by:   The FreeBSD Foundation
MFC after:  1 week
Differential revision:  https://reviews.freebsd.org/D21777

> Switching to HPET or ACPI-fast gives the expected results.  Would there be 
> any reason to not use HPET provided I can cope with the performance 
> implications?

Have you looked at hpet(4), timecounters(4), clocks(7) manpages?
I don't know how up-to-date these manpages are
___
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: System clock is slow

[Conrad Meyer]

On Tue, Mar 10, 2020 at 9:24 AM Theron  wrote:
> I had previously used powerd to let the CPU underclock to 700MHz when
> idle.  Now, I've lost all control over CPU frequency (either by powerd
> or by sysctl) since there is some in-kernel cpufreq driver which I can't
> figure out how to disable.

It's hwpstate_intel(4).  You can add
'hint.hwpstate_intel.0.disabled="1"' in loader.conf or device.hints to
disable and use est(4), if you prefer.

The idea of the device is that hardware can do a better job managing
the frequency / power states rapidly than daemons like powerd.  But if
you like powerd/est, feel free to disable it.  Future models of Intel
CPU may not provide est(4).

If you leave it enabled, you can control the energy efficiency /
performance trade-off of hwpstate_intel on a per-core basis (or
per-package, if not disabled and hardware supports package-level
control) with 'dev.hwpstate_intel..epp=0-100' (sysctl or
tunable); the CPU uses this knob to control how biased it is towards
low frequency states.  100 is most efficient, 0 is most performant.
The default is 50.

Best,
Conrad
___
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: System clock is slow

[Theron]

On 2020-03-10 01:38, Peter Jeremy wrote:

Are you running NTP?  If so, is NTP maintaining lock and what is the
reported PLL frequency (ntpq -c kerni)?


Didn't show any useful difference, "kernel status: pll unsync" when I 
tested this.



What does "sysctl kern.timecounter" report and have you tried using
any of the alternative timecounters listed in kern.timecounter.choice?


Indeed that reveals the problem:
    kern.timecounter.hardware: TSC-low
(before regression)
    kern.timecounter.tc.TSC-low.frequency: 1296053807
(after regression)
    kern.timecounter.tc.TSC-low.frequency: 13

(why are these tsc_freq divided by two?)

Through some printf's in tsc.c I've determined that the 2.6e9 value is 
from 0x16 CPUID which Intel says is only a nominal value not to be used, 
whereas 2.592e9 value is from calibration.


/*
 * Calculate TSC frequency using information from the CPUID leaf 0x15
 * 'Time Stamp Counter and Nominal Core Crystal Clock'.  If leaf 0x15
 * is not functional, as it is on Skylake/Kabylake, try 0x16 'Processor
 * Frequency Information'.  Leaf 0x16 is described in the SDM as
 * informational only, but if 0x15 did not work, and TSC calibration
 * is disabled, it is the best we can get at all.  It should still be
 * an improvement over the parsing of the CPU model name in
 * tsc_freq_intel(), when available.
 */

The implementation logic for when to use tsc_freq_cpuid() looks wrong to 
me; it doesn't match what this comment implies.  Fallback to calibration 
when calibration is unspecified should proceed when 0x15 fails 
regardless of what 0x16 does.  (CC'd the authors).


Switching to HPET or ACPI-fast gives the expected results.  Would there 
be any reason to not use HPET provided I can cope with the performance 
implications?
The name of the ACPI option varies haphazardly between "ACPI-fast" and 
"ACPI-safe" between reboots, I guess it is sensitive to some buggy 
vendor firmware.



Are you overclocking your CPU (or doing anything else non-standard)?


I had previously used powerd to let the CPU underclock to 700MHz when 
idle.  Now, I've lost all control over CPU frequency (either by powerd 
or by sysctl) since there is some in-kernel cpufreq driver which I can't 
figure out how to disable.  It's very much an annoyance, but I think 
unrelated to the timecounter problem.


Theron
___
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: mouse is broken

[Diane Bruce]

On Tue, Mar 10, 2020 at 06:37:01AM -0600, The Doctor wrote:
> On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote:
> > 
> > After an update today to world, kernel, and ports my mouse no longer works.
> > Mouse works on console.  I use startx, mouse seems to break after startx is
> > issued.
> > 
> >  Is any one else seeing anything similar?  Any help is appreciated, thanks
> > in advance.
> 
> I have the same issue.

Check the UPDATING file in /usr/ports/UPDATING 

20200220:
read the entry on x11.

-- 
- d...@freebsd.org d...@db.net http://www.db.net/~db
___
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: mouse is broken

[Trond Endrestøl]

On Tue, 10 Mar 2020 06:37-0600, The Doctor wrote:

> On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote:
> > 
> > After an update today to world, kernel, and ports my mouse no longer works.
> > Mouse works on console.  I use startx, mouse seems to break after startx is
> > issued.
> > 
> >  Is any one else seeing anything similar?  Any help is appreciated, thanks
> > in advance.
> 
> I have the same issue.

You might be missing x11-drivers/xf86-input-evdev and/or 
x11-drivers/xf86-input-libinput.

-- 
Trond.
___
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: mouse is broken

[The Doctor]

On Mon, Mar 09, 2020 at 09:12:49PM -0400, AN wrote:
> 
> After an update today to world, kernel, and ports my mouse no longer works.
> Mouse works on console.  I use startx, mouse seems to break after startx is
> issued.
> 
>  Is any one else seeing anything similar?  Any help is appreciated, thanks
> in advance.

I have the same issue.

> ___
> 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"

-- 
Member - Liberal International This is doctor@@nl2k.ab.ca Ici doctor@@nl2k.ab.ca
Yahweh, Queen & country!Never Satan President Republic!Beware AntiChrist rising!
https://www.empire.kred/ROOTNK?t=94a1f39b  Look at Psalms 14 and 53 on Atheism
An enlightened soul would not demand of another to believe lies.  -unknown
___
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: Is amd automount still supported in 13.0 or not?

[Daniel Braniss]

> On 9 Mar 2020, at 19:26, Bob Willcox  wrote:
> 
> On Mon, Mar 09, 2020 at 08:35:58AM -0700, Cy Schubert wrote:
>> On March 9, 2020 7:49:34 AM PDT, Ed Maste  wrote:
>>> On Sun, 8 Mar 2020 at 13:23, Bob Willcox  wrote:
 
 Thanks for the tip! That worked for me. I guess from reading the
>>> documentation
 I didn't pick up on staying with the symlinks and simply changing
>>> host to net.
>>> 
>>> Glad it's working for you! Is there anything else that you found
>>> tricky or surprising in migrating? Perhaps we could produce a
>>> quick-reference transition guide.
>>> ___
>>> 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"
>> 
>> /net and indirect maps should be simple conversations. Direct maps may or 
>> may not be easy. Autofs doesn't support nested direct maps like amd does. 
>> You may need to mount elsewhere or use /net with symlinks.
>> 
>> We do have a port as well. The port will be retired after a reasonable 
>> amount of time to allow people to convert. Amd upstream has told me he no 
>> longer supports amd. His advice is to use autofs.
> 
> Yes, and I considered installing the amd port but that just seemed like I'd 
> be postponing
> the inevitable. Since I had a simple use case of just using symlinks to about 
> four of my
> remote filesystems, switching from using the /host symlink to the /net 
> symlink was pretty
> easy.
> 
> 
> -- 
> Bob Willcox| It's possible that the whole purpose of your life is to
> b...@immure.com  | serve as a warning to others.
> Austin, TX |
> ___
> 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 
> ”

short version:
 www.cs.huji.ac.il/~danny/autofs.py  
is a python script that converts old hesiod based am-utils maps to autofs
and has been in used for several years now.

long version:
we have been using amd (later am-utils) since sunos days, when we moved to BSD, 
there was no NIS support,
so we switched to hesiod (clever move then since we were all the time getting  
’NIS server not responding’)

with am-utils we had some issues, so when autofs finally made it to Linux, and 
then to FreeBSD, it has been
very solid indeed! 
BTW, autofs is heavily used here, for home directories, binaries etc.

my 2cents.

danny


___
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: users of drm-legacy-kmod or drm drivers from base

[M&S - Krasznai András]

Hi

I am experiencing the following: Firefox, Chrome, LibreOffice freezes my 
FreeBSD-CURRENT after a few seconds (the disk is used intensivey but nor 
keyboard nor mouse is working, I can move the mouse pointer but nothing happens 
when I click with any of the buttons), nothing is written on the screen. As the 
mouse seems to not work I am not able to start any other application after 
starting the above programs. before starting those programs xterm, clang, etc 
is running correctly.

Ctrl-Alt-Del kills the xorg server, and the laptop returns to the character 
based screen. I can start X again with startx, and  it behaves in the same 
manner. 

A week ago when the above first happened then (as it was recommended in 
pkg-message) recompiling xorg-server with the FIXDRM option corrected the 
problem, but as FIXDRM is now removed I am not able to use those applications.

I tried to force the usage of dri3 as recommended, but did not help.

The system is a Lenovo T510 laptop, Intel I5-M520 CPU, integrated Intel 
Graphics , FreeBSD-CURRENT #358833, ports installed from pkg repository. 




best regards

Andras Krasznai





-Eredeti üzenet-
Feladó: owner-freebsd-curr...@freebsd.org 
[mailto:owner-freebsd-curr...@freebsd.org] Meghatalmazó Niclas Zeising
Küldve: 2020. március 8. 20:34
Címzett: x...@freebsd.org; curr...@freebsd.org; sta...@freebsd.org; 
po...@freebsd.org
Tárgy: users of drm-legacy-kmod or drm drivers from base

[ This is cross-posted across several mailing lists for maximum 
visibility.  Please respect reply-to and keep replies to x...@freebsd.org 
. Thank you! ]

In order to improve support for the new lkpi based graphics drivers 
(drm-kmod) and to improve the graphics stack we have switched mesa to 
prefer DRI3 over DRI2.  This was done in r528071.  For those using 
drm-kmod, this should improve performance somewhat, and more importantly 
alleviate the use of the FIXDRM option (now removed) in xorg-server.

However, for those of you using graphics/drm-legacy-kmod or the drm 
drivers in base, this change can cause issues.  If you are experiencing 
problems when running OpenGL applications, you can force the use of the 
DRI2 backend.

To force mesa to use DRI2, set the environment variable 
LIBGL_DRI3_DISABLE to 1 before starting any OpenGL application.  The 
easiest way to accomplish this is by adding it to either your shell 
startup file or ~/.xinitrc.

As an example, for users of [t]csh, put
setenv LIBGL_DRI3_DISABLE 1
in ~/.cshrc.

For users of bourne type shells (sh, bash, ksh, zsh, ...) instead put
export LIBGL_DRI3_DISABLE=1
in ~/.profile

If you are using these legacy drivers, I'm also very interested in 
hearing what issues you are facing that prevents you from using the new 
lkpi based drivers.

Regards
-- 
Niclas Zeising
FreeBSD Graphics Team
___
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-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"