Re: UBSAN report for main [so: 14] /usr/bin/whatis: non-zero (48) and zero offsets from null pointer in qsort.c

[Jan Kokemüller]

On 11.01.22 22:08, Stefan Esser wrote:
> diff --git a/lib/libc/stdlib/qsort.c b/lib/libc/stdlib/qsort.c
> index 5016fff7895f..51c41e802330 100644
> --- a/lib/libc/stdlib/qsort.c
> +++ b/lib/libc/stdlib/qsort.c
> @@ -108,6 +108,8 @@ local_qsort(void *a, size_t n, size_t es, cmp_t *cmp, void
> *thunk)
>   int cmp_result;
>   int swap_cnt;
> 
> + if (__predict_false(a == NULL))
> + return;
>  loop:
>   swap_cnt = 0;
>   if (n < 7) {
> 
> This would also work to prevent the NULL pointer arithmetik for
> ports that might also path a == NULL and n == 0 in certain cases.

The UB happens in this line, when "a == NULL" and "n == 0", right?

for (pm = (char *)a + es; pm < (char *)a + n * es; pm += es)

This is arithmetic on a pointer (the NULL pointer) which is not part of an
array, which is UB.

Then, wouldn't "if (__predict_false(n == 0))" be more appropriate than checking
for "a == NULL" here? Testing for "a == NULL" might suppress UBSAN warnings of
valid bugs, i.e. when "qsort" is called with "a == NULL" and "n != 0". In that
case UBSAN _should_ trigger.

UBSAN should not trigger when n == 0, though. At least, when "a" does point to
a valid array. But what about the case of "a == NULL && n == 0"? Is that deemed
UB? It looks like at least FreeBSD's "qsort_s" implementation says it's legal.

a != NULL (pointing to valid array), n != 0  ->  "normal" case, no UB
a != NULL (pointing to valid array), n == 0  ->  should not trigger UB, and
 doesn't in the current
 implementation
a == NULL, n == 0->  should not trigger UB?
 (debatable)

So if "a == NULL && n == 0" was deemed legal, then there would be no bug in
"mansearch.c", right?

-Jan

Re: atkbd_timeout() period?

[Jan Kokemüller]

On 05.01.22 06:41, Alexander Motin wrote:
> Or may be it can be avoided somehow 20 years later?

I'd be super happy if this was removed. On my old laptop I had to disable this
code for many years because it lead to hangs in my (non-standard) setup at the
time:



-Jan

Re: Livelock on recent current

[Jan Kokemüller]

On 09.09.20 06:18, Kevin Oberman wrote:
> I am seeing a problem since I moved to current on my laptop this week. It's
> odd as it is linked to the keyboard. As long as the keyboard is active,
> everything is fine, but if the keyboard is not used, after a few minutes,
> it locks up and gets very hot. The system may be busy or idle. The system
> seems completely locked. It does not respond in the network and the
> display, X or just vt is frozen. The only factor is use of the keyboard.

Reminds me of this bug:

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

I've been experiencing similar hangs when that timer in atkbd is
enabled. It doesn't seem to happen in the default keyboard
configuration, though.

-Jan
___
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: pkg OSVERSION problem

[Jan Kokemüller]

On 25.01.2018 21:19, Ronald Klop wrote:
> I know there should be multiple updates of packages.
> Even with -o OSVERSION it does not give any new pkgs anymore.
> What will help this?

I've just had the same issue and solved it by forcefully updating the
package database:

# pkg -o OSVERSION=1200056 update -f
# pkg -o OSVERSION=1200056 upgrade


-Jan
___
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: Intel CPU design flaw - FreeBSD affected? // disabling LDTSC

[Jan Kokemüller]

On 04.01.2018 19:23, Klaus P. Ohrhallinger wrote:
> All PoC code I have seen today relies on those instructions.
> Is there any other way to measure the memory/cache access times ?

It is possible to emulate a high resolution counter with a thread that
continuously increments a variable [1]. This is the reason why browser
vendors are currently disabling the SharedArrayBuffer feature [2].

[1]: 
https://gist.github.com/ErikAugust/724d4a969fb2c6ae1bbd7b2a9e3d4bb6#gistcomment-2311156
[2]: 
https://blog.mozilla.org/security/2018/01/03/mitigations-landing-new-class-timing-attack/
___
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: CFT: EVDEV support in psm(4) driver

[Jan Kokemüller]

Hi,

On 08.06.2017 01:32, Anthony Jenkins wrote:
> I'm seeing flakiness in X11 (KDE) with evdev enabled - a couple keys are
> reporting multiple (wrong) events and some aren't emitting any events
> (or they are, but they're NoSymbol):

It is true that the Evdev drivers emit other keycodes compared to the
'legacy' drivers.
I'm using this command to specify the correct mapping ("-rules evdev" is
the important part):

setxkbmap -rules evdev -layout us -variant altgr-intl -option 
ctrl:nocaps,compose:menu

I'm not sure if this is enough for KDE. I see 'Option "xkb_rules"
"evdev"' in your log, so the correct mapping should already be used?
Maybe KDE reverts this somehow. FWIW, when I press the arrow keys in xev
I see the following (correct) output:


KeyPress event, serial 33, synthetic NO, window 0x421,
root 0xc2, subw 0x0, time 820816, (158,533), root:(960,556),
state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x421,
root 0xc2, subw 0x0, time 820911, (158,533), root:(960,556),
state 0x0, keycode 113 (keysym 0xff51, Left), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False

KeyPress event, serial 33, synthetic NO, window 0x421,
root 0xc2, subw 0x0, time 821494, (158,533), root:(960,556),
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XmbLookupString gives 0 bytes:
XFilterEvent returns: False

KeyRelease event, serial 33, synthetic NO, window 0x421,
root 0xc2, subw 0x0, time 821565, (158,533), root:(960,556),
state 0x0, keycode 111 (keysym 0xff52, Up), same_screen YES,
XLookupString gives 0 bytes:
XFilterEvent returns: False


Cheers,
Jan
___
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: CFT: EVDEV support in psm(4) driver

[Jan Kokemüller]

Hi Vladimir,
this patch works great for me!
I'm testing this with a semi-mt Synaptics touchpad and a TrackPoint of a 
Lenovo T420. I'm running 12-CURRENT (amd64) and Xorg 1.19.3 from 
Matthew's CFT with the libudev-devd backend. The Evdev devices are 
picked up correctly by libudev-devd and xf86-input-libinput (even the 
TrackPoint). I haven't tested this with xf86-input-synaptics (which is 
in maintenance mode) or xf86-input-evdev. I am not

using xf86-input-mouse or xf86-input-keyboard.

What works (everything):
 - true smooth scrolling with Xinput2 (tested with GTK3 Firefox or 
gtk3-demo)

 - TrackPoint scrolling holding the middle button
 - both horizontal/vertical scrolling
 - two finger scrolling powered by libinput (this semi-mt touchpad 
doesn't really support more gestures than this)


The only thing that doesn't work out of the box is the mouse pointer on 
the VT console. It wouldn't be hard though to write a small tool that 
uses libinput to translate Evdev events into CONS_MOUSECTL ioctls needed 
for the VT pointer.


Some comments:
 - PS2_MOUSE_SYNAPTICS_PRODUCT should be 0x0007, not 0x0009 
(http://lxr.free-electrons.com/source/drivers/input/mouse/psmouse.h#L86)
 - The TrackPoint should be added with product id 0x000A as on Linux 
and with the INPUT_PROP_POINTING_STICK Evdev property set
 - I think it would be better if the same Evdev device names were 
exposed as on Linux (for example "SynPS/2 Synaptics TouchPad"). Many 
scripts using xinput to change device properties depend on the Linux 
device names.


I've added a patch and comments to https://reviews.freebsd.org/D10265 .

Even Linux 64-bit binaries work correctly with the created 
/dev/input/event* devices after applying those two patches here:

 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218625
 - https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218627

This will be very useful for Linux games using joysticks, game 
controllers etc.


Cheers,
Jan
___
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 11 RC1 - no wifi

[Jan Kokemüller]

On 23.08.16 21:18, Stefan Wendler wrote:

Hi,

I have upgraded from FreeBSD 10.3 to 11 RC1 on my Lenovo W450 with Intel
Centrino Ultimate-N 6300

After upgrade and a last reboot the iwn driver gets loaded but no iwn0
interface pops up. Doing a 'service netif restart' crashes the machine
and a core is written.


It's probably this bug:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=211689#c4

I've attached a patch there that fixes this issue for me.

-Jan
___
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: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 19:22, Lundberg, Johannes wrote:

​Where can I find xf86-input-libinput for FreeBSD? Will the original
source build?


Yes, the original source 
(https://cgit.freedesktop.org/xorg/driver/xf86-input-libinput/) will 
build unmodified.


I've copied libinput_drv.so to 
/usr/local/lib/xorg/modules/input/libinput_drv.so and installed 
"99-libinput.conf" into /usr/local/etc/X11/xorg.conf.d so that X will 
use libinput for the /dev/input/event* devices by default and not 
xf86-input-evdev or -synaptics.


Libinput has pretty advanced multitouch scrolling and gesture support 
that relies on evdev multitouch packets 
(https://www.kernel.org/doc/Documentation/input/multi-touch-protocol.txt). 
Are you already sending these packets, or are you sending relative 
(EV_REL) packets? Looking at the wmt driver in the wulf7/evdev branch 
sending EV_ABS packets does not seem too hard for USB based touchpads.


It is probably easiest to boot Linux, dump all evdev packets from the 
touchpad with the libevdev-events tool from libevdev, and then try to 
emulate that output with the wsp driver.


For testing smooth scrolling, gtk3-demo is pretty good; or recent 
versions of Firefox with the MOZ_USE_XINPUT2 environment variable set to 1.


-Jan
___
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: Wayland work status

[Jan Kokemüller]

Hi,

On 12.08.16 01:18, Lundberg, Johannes wrote:

x11/libinput (removed udev-stubs and linked to libudev-devd)


If you feel adventurous, you can try out the current state of the 
libinput port here (1.4.0):

https://github.com/jiixyj/libinput

I haven't yet tested the port with the evdev kernel work, though. I've 
been using my evdev implementation in userspace which uses cuse to 
create /dev/input/event* devices (https://github.com/jiixyj/evdevfbsd). 
I needed to adjust a few ioctl defines from the linux/input.h header to 
make some features work. The way Linux defines EVIOCGMTSLOTS and 
EVIOCGRAB didn't work with cuse. The kernel evdev implementation may 
work slightly differently, so that's something to look out for.


I've moved the udev-stubs.{c,h} out of the port into a separate library, 
but libudev-devd (https://github.com/wulf7/libudev-devd) certainly looks 
more mature!


The libinput code itself isn't that different from upstream anymore. 
I've removed the epoll->kqueue porting work and written a small epoll 
wrapper instead that implements everything libinput/libevdev and 
possibly wayland needs (https://github.com/jiixyj/epoll-shim). This 
isn't integrated yet into the build system of the libinput port, though. 
So you have to do something like 'CFLAGS="-I ~/git/epoll-shim/include -L 
~/git/epoll-shim -lepoll-shim -pthread" LDFLAGS="-pthread -lrt"' when 
configuring libinput.


All this can be used with the xf86-input-libinput driver to get smooth 
and horizontal scrolling in X, which is awesome!


--
Jan
___
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: Call For Testers: Synaptics touchpads

[Jan Kokemüller]

On 08.04.2015 09:19, Rui Paulo wrote:

The attached patch adds support for newer touchpad features and implements two
finger scrolling.


Hi,
thanks for bringing two finger scrolling to the psm driver!

I've attached a patch of some more improvements and fixes. I hope some 
of this stuff can make it into the driver:


- Two finger scrolling support for semi-MT touchpads. Those include 
many of the older Synaptics touchpads before true multitouch support 
(indicated by capMultiFinger). Semi-MT touchpads can report a second 
finger position, but the X or Y coordinate may be swapped with some 
coordinate of the first finger. This is a result of how the hardware 
works internally. Therefore, all that can be reliably extracted is the 
bounding box of the two finger positions. Semi-MT touchpads can be 
recognized by the capAdvancedGestures capability bit. After setting the 
mode byte, advanced gestures mode has to be enabled. Then, data packets 
compatible with the capMultiFinger format are sent, so the same two 
finger scrolling code can be leveraged. Enabling advanced gestures mode 
on true multitouch touchpads should be harmless. Linux seems to always 
enable advanced gestures mode. I don't have a real multitouch touchpad 
for testing though.


- Put mode setting logic into own functions synaptics_preferred_mode() 
and synaptics_set_mode() to have this in one place. 
synaptics_passthrough_on() and synaptics_passthrough_off() currently 
always use 0xc1 as the mode byte, which may be wrong for touchpads that 
don't have capExtended (sorry, my fault).


- Expose X and Y resolution of touchpad to userland. Also expose minimum 
and maximum X and Y coordinates. This is useful for programs in 
userspace that read raw PSM packets (with PSM_LEVEL_NATIVE enabled) and 
need to interpret the coordinates.


- Also send extended w mode packets (see section 3.2.9 of 
511-000275-01_RevB.pdf) to userspace if PSM_LEVEL_NATIVE is enabled. 
This is useful for userspace programs/drivers such as 
xf86-input-synaptics that can handle these packets.


- Fix parsing of nExtendedQueries, and request extended/continued 
capability bits depending on this value.


- capReportsMax, capClearPad, capAdvancedGestures and capCoveredPad must 
be extracted from status[0] and not status[2], I think.



Two finger scrolling works reasonably well with my semi-MT touchpad 
(Lenovo T420). However, it is very sensitive if I move my fingers very 
slowly. I wonder if this is because it's a semi-MT touchpad or if I have 
to tweak some setting. Also sometimes, if I move my fingers up, it 
scrolls down, and vice versa. Maybe this is a result of how dxp and dyp 
are calculated with the abs() function?


Cheers,
Jan
diff --git a/sys/dev/atkbdc/psm.c b/sys/dev/atkbdc/psm.c
index e8a2a93..4e41eef 100644
--- a/sys/dev/atkbdc/psm.c
+++ b/sys/dev/atkbdc/psm.c
@@ -483,6 +483,8 @@ static probefunc_t	enable_versapad;
 static void set_trackpoint_parameters(struct psm_softc *sc);
 static void synaptics_passthrough_on(struct psm_softc *sc);
 static void synaptics_passthrough_off(struct psm_softc *sc);
+static int synaptics_preferred_mode(struct psm_softc *sc);
+static void synaptics_set_mode(struct psm_softc *sc, int mode_byte);
 
 static struct {
 	int		model;
@@ -933,14 +935,8 @@ doopen(struct psm_softc *sc, int command_byte)
 		get_mouse_status(sc-kbdc, stat, 0, 3);
 		if ((SYNAPTICS_VERSION_GE(sc-synhw, 7, 5) ||
 		 stat[1] == 0x47) 
-		stat[2] == 0x40) {
-			/* Set the mode byte -- request wmode where
-			 * available */
-			if (sc-synhw.capExtended)
-mouse_ext_command(sc-kbdc, 0xc1);
-			else
-mouse_ext_command(sc-kbdc, 0xc0);
-			set_mouse_sampling_rate(sc-kbdc, 20);
+		 stat[2] == 0x40) {
+			synaptics_set_mode(sc, synaptics_preferred_mode(sc));
 			VLOG(5, (LOG_DEBUG, psm%d: Synaptis Absolute Mode 
 			hopefully restored\n,
 			sc-unit));
@@ -2176,6 +2172,20 @@ psmioctl(struct cdev *dev, u_long cmd, caddr_t addr, int flag,
 		(*(int *)addr  PSM_LEVEL_MAX))
 			return (EINVAL);
 		sc-mode.level = *(int *)addr;
+
+		if (sc-hw.model == MOUSE_MODEL_SYNAPTICS) {
+			/*
+			 * If we are entering PSM_LEVEL_NATIVE, we want to
+			 * enable sending of extended W mode packets to
+			 * userland. Reset the mode of the touchpad so that the
+			 * change in the level is picked up.
+			 */
+			error = block_mouse_data(sc, command_byte);
+			if (error)
+return (error);
+			synaptics_set_mode(sc, synaptics_preferred_mode(sc));
+			unblock_mouse_data(sc, command_byte);
+		}
 		break;
 
 	case MOUSE_GETSTATUS:
@@ -2864,7 +2874,8 @@ proc_synaptics(struct psm_softc *sc, packetbuf_t *pb, mousestatus_t *ms,
 
 		/* Palm detection. */
 		if (!(
-		(sc-synhw.capMultiFinger  (w == 0 || w == 1)) ||
+		((sc-synhw.capMultiFinger ||
+		  sc-synhw.capAdvancedGestures)  (w == 0 || w == 1)) ||
 		(sc-synhw.capPalmDetect  w = 4  w = max_width) ||
 		(!sc-synhw.capPalmDetect  *z = max_pressure) ||
 		(sc-synhw.capPen  w == 2))) {

Re: Synaptics Touchpad stops working in r281560

[Jan Kokemüller]

On 16.04.2015 06:16, Ranjan1018 . wrote:

Upgrade from r280855 to r281560 (amd64) on a Samsung Ativ Book 2 Laptop.
The Synaptics Touchpad stops working,  in Xorg.0.log  I have the error
message :

[  1047.413] (EE) synaptics: Mouse: Unable to query/initialize Synaptics
hardware.

[  1047.449] (EE) PreInit returned 11 for Mouse



Could you try to rebuild xf86-input-synaptics via ports? The kernel ABI 
has changed due to the additions to synapticshw_t in 
/usr/include/sys/mouse.h. The xorg driver calls the MOUSE_SYN_GETHWINFO 
ioctl which returns a synapticshw_t.

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

Re: Battery life with the latest drm

[Jan Kokemüller]

On 04.02.2015 21:27, Lars Engels wrote:

By the way on the X230 (IvyBridge i7) the loader.conf setting
drm.i915.enable_rc6=7 makes a huge difference.
For some other reason I removed it from loader.conf and
hw.acpi.battery.time showed 160 minutes. After re-adding it battery time
went up to 230 minutes.


I've been using the same setting for a while now and can confirm the 
increase of battery life. It also makes a huge difference in fan noise 
on my T420.


Can you suspend/resume with rc6 on? I had to patch around a deadlock in 
i915_irq.c: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=183859

I haven't checked yet if this still occurs after the recent drm import.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

r275326 (merge from projects/sendfile) broke Bluetooth for me

[Jan Kokemüller]

Hi,

after r275326 I can't get Bluetooth up anymore. Previously, running 
service bluetooth start ubt0 worked well. The first invocation 
returned an error, but the second always worked. Now, there are just 
errors (/etc/rc.d/bluetooth: ERROR: Unable to setup Bluetooth stack for 
device ubt0).


I've tracked the error down to the invocations of hccontrol in 
/etc/rc.d/bluetooth. hccontrol just prints an EMSGSIZE error message and 
fails. The setup of the netgraph nodes with ngctl works fine.


For now I've reverted the merges from projects/sendfile and Bluetooth 
works fine again. Should I open a bug report? This is from a Thinkpad T420.

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

Re: r275326 (merge from projects/sendfile) broke Bluetooth for me

[Jan Kokemüller]

On 21.12.2014 17:08, Adrian Chadd wrote:

Yes, please do!


I've filed a bug report:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196174

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

Re: x11/nvidia-driver (340.24/340.32/343.13): nvidia BLOB doesn't recognize any display socket on Lenovo E540/UEFI and FBSD CURRENT

[Jan Kokemüller]

On 28.09.2014 11:41, O. Hartmann wrote:

Without nouveau driver, FreeBSD people do not have the slightes chance to play 
with
OpenCL/libclc on nVidia's hardware.


Some time in the past it was possible to run CUDA/OpenCL Linux binaries 
with the Nvidia driver in Linux emulation mode on FreeBSD:


https://web.archive.org/web/20121015180221/http://blogs.freebsdish.org/jhb/2010/07/20/using-cuda-with-the-native-freebsdamd64-nvidia-driver

Not sure if that still works though.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: KQueue 0-length UDP packet

[Jan Kokemüller]

Hi,


What I wanted to ask is: why does FreeBSD kqueue implementation treat
`SO_RCVLOWAT` as a raw packet size watermark, and not using the actual
data size for filtering out events?


It looks like SO_RCVLOWAT refers to the number of bytes in the socket 
buffer, not raw packet bytes. In the case of an arriving UDP packet 
there is always a 'struct sockaddr' in the buffer that contains the 
source address/port of the message. For IPv4 this is 16 bytes and for 
IPv6 28 bytes. I think this is intended behavior, as this is data you 
can read with recvfrom or recvmsg.


POSIX says Receive calls may still return less than the low water mark 
if an error occurs, a signal is caught, or the type of data next in the 
receive queue is different from that returned (for example, out-of-band 
data). So in this case this data is address data.


On the other hand, NOTE_LOWAT from kevent refers to data/protocol bytes. 
The semantics were changed in 2002:

http://marc.info/?l=freebsd-archm=103587526507822w=2
The value you get in 'data' also refers to the number of protocol data 
bytes available.


I've had a look at how OpenBSD handles this. It returns the number of 
protocol data bytes with ioctl(s, FIONREAD, len) but the number of 
bytes in the socket buffer in the 'data' member of kevent, so exactly 
the other way around compared to FreeBSD. SO_RCVLOWAT works still the 
same, though.


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

Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction

[Jan Kokemüller]

Hi,


Maybe this is a problem caused by a misdetected clock source? I've had
this problem as well.


I've appended the patch I've been using to fix this problem on this 
Intel Core2Duo T6570 processor. There are some model IDs hardcoded in 
the TSC detection code that enable TSC even though it's not invariant 
here (no TSC_INVARIANT bit set on the CPU). There is some quirk code 
further down that disables TSC once again, but it only works for 
processors that have C3 power states (the T6570 doesn't). I don't think 
any of this model checking code is necessary, but maybe I'm wrong.


Cheers,
Jan
diff --git a/sys/x86/x86/tsc.c b/sys/x86/x86/tsc.c
index 2a6c81d..a30424e 100644
--- a/sys/x86/x86/tsc.c
+++ b/sys/x86/x86/tsc.c
@@ -57,7 +57,8 @@ int		tsc_perf_stat;
 static eventhandler_tag tsc_levels_tag, tsc_pre_tag, tsc_post_tag;
 
 SYSCTL_INT(_kern_timecounter, OID_AUTO, invariant_tsc, CTLFLAG_RDTUN,
-tsc_is_invariant, 0, Indicates whether the TSC is P-state invariant);
+tsc_is_invariant, 0,
+Indicates whether the TSC is ACPI P-, C- and T-state invariant);
 TUNABLE_INT(kern.timecounter.invariant_tsc, tsc_is_invariant);
 
 #ifdef SMP
@@ -272,9 +273,7 @@ probe_tsc_freq(void)
 
 	switch (cpu_vendor_id) {
 	case CPU_VENDOR_AMD:
-		if ((amd_pminfo  AMDPM_TSC_INVARIANT) != 0 ||
-		(vm_guest == VM_GUEST_NO 
-		CPUID_TO_FAMILY(cpu_id) = 0x10))
+		if ((amd_pminfo  AMDPM_TSC_INVARIANT) != 0)
 			tsc_is_invariant = 1;
 		if (cpu_feature  CPUID_SSE2) {
 			tsc_timecounter.tc_get_timecount =
@@ -282,12 +281,7 @@ probe_tsc_freq(void)
 		}
 		break;
 	case CPU_VENDOR_INTEL:
-		if ((amd_pminfo  AMDPM_TSC_INVARIANT) != 0 ||
-		(vm_guest == VM_GUEST_NO 
-		((CPUID_TO_FAMILY(cpu_id) == 0x6 
-		CPUID_TO_MODEL(cpu_id) = 0xe) ||
-		(CPUID_TO_FAMILY(cpu_id) == 0xf 
-		CPUID_TO_MODEL(cpu_id) = 0x3
+		if ((amd_pminfo  AMDPM_TSC_INVARIANT) != 0)
 			tsc_is_invariant = 1;
 		if (cpu_feature  CPUID_SSE2) {
 			tsc_timecounter.tc_get_timecount =
@@ -554,20 +548,6 @@ init_TSC_tc(void)
 	}
 
 	/*
-	 * We cannot use the TSC if it stops incrementing in deep sleep.
-	 * Currently only Intel CPUs are known for this problem unless
-	 * the invariant TSC bit is set.
-	 */
-	if (cpu_can_deep_sleep  cpu_vendor_id == CPU_VENDOR_INTEL 
-	(amd_pminfo  AMDPM_TSC_INVARIANT) == 0) {
-		tsc_timecounter.tc_quality = -1000;
-		tsc_timecounter.tc_flags |= TC_FLAGS_C3STOP;
-		if (bootverbose)
-			printf(TSC timecounter disabled: C3 enabled.\n);
-		goto init;
-	}
-
-	/*
 	 * We can not use the TSC in SMP mode unless the TSCs on all CPUs
 	 * are synchronized.  If the user is sure that the system has
 	 * synchronized TSCs, set kern.timecounter.smp_tsc tunable to a
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org

Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction

[Jan Kokemüller]

On 01.08.2014 20:59, Adrian Chadd wrote:

Can you file a pr with this patch?


Done:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=192316

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

Re: Fresh current (r269328) amd64: high load average while idle, slow keyboard reaction

[Jan Kokemüller]

Hi,

On 31.07.2014 16:21, Anton Berezin wrote:

At the console, depressing and holding a key does not lead to auto-repeat.

At the console, sometimes a key only appears on the terminal after another
key is pressed.


Maybe this is a problem caused by a misdetected clock source? I've had 
this problem as well.


Try to set kern.timecounter.hardware and/or kern.eventtimer.timer to 
other settings that are listed in kern.timecounter.choice and 
kern.eventtimer.choice, such as HPET which works great for me.


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

Re: 10-stable does not boot on Dell E1505 any more

[Jan Kokemüller]

 r255569 does not find /dev/ada0s2a and ? at the mountroot prompt
 shows no devices.

I've had the same problem after I updated my kernel today. I tracked it
down to the hyperv drivers that were added in r255524. Without the device
hyperv line in my kernconf the system boots fine again.
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org