Re: Problem building kernel
On 24.12.2023 15:47, tue...@freebsd.org wrote: On Dec 24, 2023, at 12:27, Vladimir Kondratyev wrote: On 24.12.2023 14:18, tue...@freebsd.org wrote: Dear all, I just tried to build world and kernel on a 64-bit PPC system. make -j 32 buildworld ran without problems. However make kernel KERNCONF=GENERIC breaks with .. --- all_subdir_accf_data --- --- accf_data.kld --- ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize -r -o accf_data.kld accf_data.o --- all_subdir_acl_nfs4 --- --- offset.inc --- sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o > offset.inc --- all_subdir_accf_data --- ld: error: accf_data.o is incompatible with elf32ppc_fbsd *** [accf_data.kld] Error code 1 make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data 5.79 real22.37 user15.35 sys make[1]: stopped in /usr/home/tuexen/freebsd-src make: stopped in /usr/home/tuexen/freebsd-src tuexen@blackbird: Any idea what is going wrong? Best regards Michael Latest LKPI changes broke 32 bit archs and powerpc. I am going to fix them. Sorry for breakage. No problem. If you want me to test a fix, drop me an e-mail. Best regards Michael Hopefully it is fixed now. -- WBR Vladimir Kondratyev
Re: Problem building kernel
On 24.12.2023 14:18, tue...@freebsd.org wrote: Dear all, I just tried to build world and kernel on a 64-bit PPC system. make -j 32 buildworld ran without problems. However make kernel KERNCONF=GENERIC breaks with .. --- all_subdir_accf_data --- --- accf_data.kld --- ld -m elf32ppc_fbsd -warn-common --build-id=sha1 --no-toc-optimize -r -o accf_data.kld accf_data.o --- all_subdir_acl_nfs4 --- --- offset.inc --- sh /usr/home/tuexen/freebsd-src/sys/kern/genoffset.sh genoffset.o > offset.inc --- all_subdir_accf_data --- ld: error: accf_data.o is incompatible with elf32ppc_fbsd *** [accf_data.kld] Error code 1 make[4]: stopped in /usr/home/tuexen/freebsd-src/sys/modules/accf_data 5.79 real22.37 user15.35 sys make[1]: stopped in /usr/home/tuexen/freebsd-src make: stopped in /usr/home/tuexen/freebsd-src tuexen@blackbird: Any idea what is going wrong? Best regards Michael Latest LKPI changes broke 32 bit archs and powerpc. I am going to fix them. Sorry for breakage. -- WBR Vladimir Kondratyev
Re: RES: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
On 28.06.2022 09:59, Ivan Quitschal wrote:
Hi Vladimir / All,
Just a question in case you guys know how.
Problem is fixed , nothing about that, but after the keyboard is detached and
reattached , I
always have to do another "kbdcontrol -r fast" myself for it to get back to the
speed I use.
I've tried to call this command from within devd.conf alongside moused, but no
success.
Any ideas ?
May be DE overrides repeat rate for you?
Anyway, it is possible to change repeat rate through evdev interface.
Following snippet of code illustrates a way to do that:
#include
#include
#include
#include
#include
#include
void
usage(void)
{
printf("usage: eviocresp /dev/input/event0\n");
}
int
main(int argc, char** argv)
{
int fd = 0;
int rep[2] = {0, 0};
if (argc < 2) {
usage();
exit(0);
}
if ((fd = open(argv[1], O_RDWR)) < 0) {
perror("unable to access file, exiting");
exit(1);
}
/* get current auto-repeat args. */
if (ioctl(fd, EVIOCGREP, rep)) {
perror("unable to set delay and repeat rate for input devices");
exit(1);
}
/* set auto-repeat rate as 0. */
rep[1] = 0;
if (ioctl(fd, EVIOCSREP, rep)) {
perror("unable to set delay and repeat rate for input devices");
exit(1);
}
printf("rep[0]:%d;rep[1]:%d\n", rep[0], rep[1]);
close(fd);
}
--
WBR
Vladimir Kondratyev
Re: iichid/hms keyboard/mouse wrongly reattached to uhid/ums
On 27.06.2022 18:19, Ivan Quitschal wrote: Hi all Not sure if I found a problem here but here we go. Since I have a KVM usb switch here for keyboard/mouse sometimes I toggle it between my windows and freebsd. I am using iichid here to have my multimedia keys working on keyboard and all hw.usb.usbhid.enable="1" Im also using Wulf’s moused https://github.com/wulf7/moused <https://github.com/wulf7/moused> so far so good. Problem is: when I switch to windows , everything is detached correctly (hms, hkbd etc), but when I switch back, sometimes the keyboard and mouse are wrongly attached to “ums” device , not hms. (sometimes it goes to the correct one). Shouldn’t ums/uhid modules be deactivated once hw.usb.usbhid.enable is set to 1 ? The workaround I did here was to manually kldunload both uhid.ko and ums.ko within rc.local during boot. This way I can detache attach the kbd/mouse back as much as I want and it always end up in hms/hkbd devices Is this how its supposed to function? Randomly choosing between ums or hms? Thanks --tzk It seems that usbhid's bus probe priority must be increased from BUS_PROBE_GENERIC + 1 to BUS_PROBE_DEFAULT + 1 Test this patch: diff --git a/sys/dev/usb/input/usbhid.c b/sys/dev/usb/input/usbhid.c index fe53f11b8f4..174e1c28ae9 100644 --- a/sys/dev/usb/input/usbhid.c +++ b/sys/dev/usb/input/usbhid.c @@ -802,7 +802,7 @@ usbhid_probe(device_t dev) if (hid_test_quirk(>sc_hw, HQ_HID_IGNORE)) return (ENXIO); - return (BUS_PROBE_GENERIC + 1); + return (BUS_PROBE_DEFAULT + 1); } static int -- WBR Vladimir Kondratyev
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On 30.01.2022 22:43, Stefan Esser wrote: Am 30.01.22 um 19:23 schrieb Vladimir Kondratyev: On 30.01.2022 00:25, Stefan Esser wrote: After rebooting with freshly built world, kernel and the amdgpu driver my console stopped working. It goes blank and the display goes into a power save mode, as soon as the amdgpu driver is loaded. The GPU (a Radeon R7 250E) is correctly detected as before, but there is an error message "drmn0: [drm] Cannot find any crtc or sizes". [...] [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] DVI-I-1 [drm] HPD2 [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 A successful driver attach from a reboot a few days ago had ended in: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xE0503000 [drm] vram apper at 0xE000 [drm] size 33177600 [drm] fb depth is 24 [drm] pitch is 15360 [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 Regards, STefan drm-kmod commit 534aa199c10d forced it to use i2c from base. Hi Vladimir, thank you for the information! I'm using drm-devel-kmod, and in fact found that 5.5.19.g20211230 works, while 5.7.19.g20220126 (committed as 0c38674b389ad on 2022-01-26) causes the failure. You may try to checkout previous revision (444dc58f0247) to find out if in-base i2c is guilty or not. Assuming that the same change to use the system i2c code has been in the latest commit to the drm-devel-kmod port, this should be proven, now. ;-) These is the list of in-kernel i2c modules on my system (a Ryzen 9 5950 on an ASUS mainboard with B550 chip-set): $ kldstat -v | grep iic 68 iicsmb/smbus 67 iicbus/iicsmb 66 iichb/iicbus 65 iicbb/iicbus 64 iicbus/iic 63 iicbus/ic 213 lkpi_iicbb/iicbb 212 lkpi_iic/lkpi_iicbb 211 lkpi_iic/iicbus 210 drmn/lkpi_iic 56 iichid/hidbus Can I help debug this issue? I could re-install the latest version and boot with hw.dri.drm_debug or dev.drm.drm_debug set? Or are there other settings to get a debug log from the i2c side? Regards, STefan PS: I'm keeping the CC to current@, since this might be an issue in the i2c kernel code ... There are no successful lkpi_iic attachments in your output. They look like: lkpi_iic0: on drmn0 Please share your `devinfo -v` output. Kldload output with verbose boot enabled can be helpful too. -- WBR Vladimir Kondratyev
Re: Kernel changes causing AMDGPU / DRM to fail? i2c related?
On 30.01.2022 00:25, Stefan Esser wrote: After rebooting with freshly built world, kernel and the amdgpu driver my console stopped working. It goes blank and the display goes into a power save mode, as soon as the amdgpu driver is loaded. The GPU (a Radeon R7 250E) is correctly detected as before, but there is an error message "drmn0: [drm] Cannot find any crtc or sizes". I'm asking here and not on the ports list, since the AMDGPU driver has not been updated for half a year. But to be sure that there is no mismatch between kernel and user land, I have rebuilt all X11 server and library ports. There have been changes affecting the i2c driver, IIRC, and the error message seems to point at an issue obtaining information from the LCD display. The output of "grep drm /var/run/dmesg.boot" follows: [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 (VERDE 0x1002:0x683F 0x174B:0xA001 0x00). [drm] register mmio base: 0xFCE0 [drm] register mmio size: 262144 [drm] add ip block number 0 [drm] add ip block number 1 [drm] add ip block number 2 [drm] add ip block number 3 [drm] add ip block number 4 [drm] add ip block number 5 [drm] add ip block number 6 [drm] BIOS signature incorrect 0 0 [drm] vm size is 512 GB, 2 levels, block size is 10-bit, fragment size is 9-bit drmn0: successfully loaded firmware image 'amdgpu/verde_mc.bin' drmn0: VRAM: 1024M 0x00F4 - 0x00F43FFF (1024M used) drmn0: GART: 1024M 0x00FF - 0x00FF3FFF [drm] Detected VRAM RAM=1024M, BAR=256M [drm] RAM width 128bits GDDR5 [drm] amdgpu: 1024M of VRAM memory ready [drm] amdgpu: 3072M of GTT memory ready. [drm] GART: num cpu pages 262144, num gpu pages 262144 drmn0: PCIE GART of 1024M enabled (table at 0x00F40050). [drm] Supports vblank timestamp caching Rev 2 (21.10.2013). drmn0: successfully loaded firmware image 'amdgpu/verde_pfp.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_me.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_ce.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_rlc.bin' drmn0: successfully loaded firmware image 'amdgpu/verde_smc.bin' [drm] Internal thermal controller without fan control [drm] amdgpu: dpm 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 DVI-I-1: get mode from tunables: [drm] - kern.vt.fb.modes.DVI-I-1 [drm] - kern.vt.fb.default_mode [drm] AMDGPU Display Connectors [drm] Connector 0: [drm] DP-1 [drm] HPD4 [drm] DDC: 0x1950 0x1950 0x1951 0x1951 0x1952 0x1952 0x1953 0x1953 [drm] Encoders: [drm] DFP1: INTERNAL_UNIPHY2 [drm] Connector 1: [drm] HDMI-A-1 [drm] HPD1 [drm] DDC: 0x195c 0x195c 0x195d 0x195d 0x195e 0x195e 0x195f 0x195f [drm] Encoders: [drm] DFP2: INTERNAL_UNIPHY2 [drm] Connector 2: [drm] DVI-I-1 [drm] HPD2 [drm] DDC: 0x1958 0x1958 0x1959 0x1959 0x195a 0x195a 0x195b 0x195b [drm] Encoders: [drm] DFP3: INTERNAL_UNIPHY [drm] CRT1: INTERNAL_KLDSCP_DAC1 drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes drmn0: [drm] Cannot find any crtc or sizes [drm] Initialized amdgpu 3.37.0 20150101 for drmn0 on minor 0 A successful driver attach from a reboot a few days ago had ended in: [drm] CRT1: INTERNAL_KLDSCP_DAC1 [drm] fb mappable at 0xE0503000 [drm] vram apper at 0xE000 [drm] size 33177600 [drm] fb depth is 24 [drm]pitch is 15360 [drm] Initialized amdgpu 3.36.0 20150101 for drmn0 on minor 0 Regards, STefan drm-kmod commit 534aa199c10d forced it to use i2c from base. You may try to checkout previous revision (444dc58f0247) to find out if in-base i2c is guilty or not. -- WBR Vladimir Kondratyev
Re: sound on FreeBSD 14.0-CURRENT
On 17.11.2021 13:03, Ludovit Koren wrote: Hans Petter Selasky writes: > Hi, >> Still the same result... >> > Please show all commands you try! > Can you explain, which if these devices you want to receive audio > from, and which you want to transmit audio to: > pcm0: (play/rec) default > pcm1: (play) > pcm2: (play) > It might also be the mixer has the volume or recording level set to zero. It is my new notebook... I want to use applications like mplayer, firefox, chrome. On my old notebook, I can listen from speakers, after plugging in the headphones, from them. I would like to have the same functionality. It does not work automatically on the new notebook. I suppose pcm1, is the output for the jack headphones. You don't need virtual_oss to do that. Just configure pins on your soundchip properly. See EXAMPLES section of man snd_hda. -- WBR Vladimir Kondratyev
Re: panic: device_unbusy: called for non-busy device iichid0
On 27.05.2021 14:41, David Wolfskill wrote: > This was on the new(er) laptop with which I have been experimenting; it > uses iichid to controll/access the built-in mouse/touchpad. > > The machine was running: > > FreeBSD g1-48.catwhisker.org 14.0-CURRENT FreeBSD 14.0-CURRENT #252 > main-n246951-38e7025a60b2: Wed May 26 04:56:25 PDT 2021 > r...@g1-48.catwhisker.org:/common/S4/obj/usr/src/amd64.amd64/sys/CANARY > amd64 1400017 1400017 > > at the time. Note that the reboot after building the above (yesterday) > was without issue, and the reboot after the panic was also without issue > -- so this would seem to have elements of timing/racing involved. (And > it's likely to be distinctly unpleasant to debug, as it seems that > reproduction may be rather "iffy.") > > I took a photo of the displayed backtrace; it's at > https://www.catwhisker.org/~david/FreeBSD/head/n246951/device_unbusy.jpg > > Here's a slightly-abbreviated hand-transcribed version: > > panic: device_unbusy: called for non-busy device iichid0 > cpuid = 8 > time = 1622113818 > KDB: stack backtrace: > db_trace_self_wrapper() > vpanic() > panic() > device_unbusy() > iicbus_release_bus() > iichid_intr() > ithread-loop() > fork_exit() > fork_trampoline() > --- trap 0, rip = 0, rsp = 0, rbp = 0 --- > KDB: enter: panic > [ thread pid 12 tid 100170 ] > Stopped at 0x80c36867 = kdb_enter+ 0x37:$0,0x12a0b9e(%rip) > db> > It looks like iicbus issue. It was very easy reproducible with iichid when latter had a bug triggering interrupt storm on device_attach: https://github.com/wulf7/iichid/issues/22 It was caused by unlocked calls to device_busy() and device_unbusy() in iicbus_request_bus() routine. These unlocked calls resulted in races with parallel device attachment process. CC-ed ian@ -- WBR Vladimir Kondratyev
Re: iichid touchpad stopped working
On 13.01.2021 23:29, Jakob Alvermark wrote: > On 1/13/21 5:56 PM, Vladimir Kondratyev wrote: >> On 13.01.2021 18:54, Jakob Alvermark wrote: >>> Hi, >>> >>> >>> After updating -current on my Acer laptop the touchpad stopped working. >>> >>> The device is detected fine: >>> >>> iichid0: at addr 0x2c irq 67 on >>> iicbus0 >>> >>> But there are no events from it. >>> >>> Might it have something to do with this: >>> >>> commit b1f1b07f6d412cb3ec8588a634836e26396eec70 >>> Author: Vladimir Kondratyev >>> Date: Wed Oct 7 00:50:16 2020 +0300 >>> >>> hid: Import iichid - I2C transport backend for HID subsystem >>> >> It is quite possible. You should remove sysutils/iichid after this >> commit. > > I did. Still no luck. > > Anything I can do to debug? > Add following options to kernel config and rebuild kernel: options IICHID_DEBUG options IICHID_SAMPLING Than add hw.iichid.debug=5 to /boot/loader.conf, than reboot and send me a boot log. ___ 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: iichid touchpad stopped working
On 13.01.2021 18:54, Jakob Alvermark wrote: > Hi, > > > After updating -current on my Acer laptop the touchpad stopped working. > > The device is detected fine: > > iichid0: at addr 0x2c irq 67 on > iicbus0 > > But there are no events from it. > > Might it have something to do with this: > > commit b1f1b07f6d412cb3ec8588a634836e26396eec70 > Author: Vladimir Kondratyev > Date: Wed Oct 7 00:50:16 2020 +0300 > > hid: Import iichid - I2C transport backend for HID subsystem > It is quite possible. You should remove sysutils/iichid after this commit. ___ 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: ld: error: undefined symbol: hid_locate
On 08.01.2021 12:43, Rozhuk Ivan wrote: > 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 > Add "device hid" to your kernel config file. It is mentioned in 20210107 UPDATING entry. ___ 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_wmi noisy without EC
On 17.12.2020 11:24, Yuri Pankov wrote:
> Yuri Pankov wrote:
>> On Tue, Nov 17, 2020, at 4:00 PM, Vladimir Kondratyev wrote:
>>> On 2020-11-17 15:29, Yuri Pankov wrote:
>>>> On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
>>>>> On 2020-11-17 10:57, Vladimir Kondratyev wrote:
>>>>>> On 2020-11-17 03:00, Yuri Pankov wrote:
>>>>>>> I have started seeing the following on boot since some time:
>>>>>>>
>>>>>>> acpi_wmi0: on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>> acpi_wmi0: on acpi0
>>>>>>> acpi_wmi0: cannot find EC device
>>>>>>> device_attach: acpi_wmi0 attach returned 6
>>>>>>>
>>>>>>> Likely following this commit:
>>>>>>>
>>>>>>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>>>>>>> Author: Vladimir Kondratyev
>>>>>>> Date: Sat Oct 31 22:19:39 2020 +
>>>>>>>
>>>>>>> acpi_wmi(4): Add ACPI_PNP_INFO
>>>>>>>
>>>>>>> While the reason is obvious -- there's no EC in this system
>>>>>>> (Gigabyte
>>>>>>> X299X AORUS MASTER desktop motherboard), at least searching the
>>>>>>> `acpidump -dt` output doesn't show any PNP0C09 entries -- it
>>>>>>> certainly
>>>>>>> looks like "something is broken" when first noticed. I wonder if we
>>>>>>> could/should handle this gracefully -- no EC, do nothing, simply
>>>>>>> exit?
>>>>>>
>>>>>> Following patch should ignore missing EC like Linux does. Could you
>>>>>> test it?
>>>>>>
>>>>>> diff --git a/sys/dev/acpi_support/acpi_wmi.c
>>>>>> b/sys/dev/acpi_support/acpi_wmi.c
>>>>>> index 379cfd1705f1..efae96cdcc9a 100644
>>>>>> --- a/sys/dev/acpi_support/acpi_wmi.c
>>>>>> +++ b/sys/dev/acpi_support/acpi_wmi.c
>>>>>> @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
>>>>>> if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
>>>>>> == NULL)
>>>>>> device_printf(dev, "cannot find EC device\n");
>>>>>> - else if (ACPI_FAILURE((status =
>>>>>> AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>>> + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
>>>>>> ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
>>>>>> device_printf(sc->wmi_dev, "couldn't install notify handler -
>>>>>> %s\n",
>>>>>> AcpiFormatException(status));
>>>>>> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
>>>>>> ACPI_PHYSICAL_ADDRESS address,
>>>>>> return (AE_BAD_PARAMETER);
>>>>>> if (address + (width / 8) - 1 > 0xFF)
>>>>>> return (AE_BAD_ADDRESS);
>>>>>> + if (sc->ec_dev == NULL)
>>>>>> + return (AE_NOT_FOUND);
>>>>>> if (function == ACPI_READ)
>>>>>> *value = 0;
>>>>>> ec_addr = address;
>>>>>
>>>>> @#@##! Web client ate all the tabs.
>>>>>
>>>>> Patch is in attachment.
>>>>
>>>> Output changed, though it's still somewhat noisy -- I guess there
>>>> isn't a way to NOT report the device that we are not going to attach
>>>> to, or do that e.g. only for verbose boot?
>>>>
>>>> acpi_wmi0: on acpi0
>>>> acpi_wmi0: cannot find EC device
>>>> acpi_wmi0: Embedded MOF found
>>>> ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
>>>> object (Buffer) (20201113/nsarguments-361)
>>>> acpi_wmi1: on acpi0
>>>> acpi_wmi1: cannot find EC device
>>>> acpi_wmi2: on acpi0
>>>> acpi_wmi2: cannot find EC device
>>>> acpi_wmi3: on acpi0
>>>> acpi_wmi3: cannot find EC device
>>>
>>> acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
>>> in OpRegion handler.
>>> WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
>>> successfully attached to 4 nodes.
>>
>> Oh great, I misunderstood then. And indeed, sysctl -b
>> dev.acpi_wmi.0.bmof | bmf2mof provides some interesting information.
>> All other 3 instances do not though. In any case, it seems to work now.
>>
>>> Verbosity can be reduced with attached patch if current level is too
>>> high for you.
>>
>> Works for me both ways, I simply had the wrong impression that if we
>> don't have EC, we can't attach at all.
>
> Could you commit this, or is it incomplete fix?
I did some tests with ACER ACPI extras which left functional after
OPregion handler had been disabled, so I think, fix is complete.
I have created a phabricator review: https://reviews.freebsd.org/D27653
___
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_wmi noisy without EC
On 2020-11-17 15:29, Yuri Pankov wrote:
On Tue, Nov 17, 2020, at 11:07 AM, Vladimir Kondratyev wrote:
On 2020-11-17 10:57, Vladimir Kondratyev wrote:
> On 2020-11-17 03:00, Yuri Pankov wrote:
>> I have started seeing the following on boot since some time:
>>
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>> acpi_wmi0: on acpi0
>> acpi_wmi0: cannot find EC device
>> device_attach: acpi_wmi0 attach returned 6
>>
>> Likely following this commit:
>>
>> commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
>> Author: Vladimir Kondratyev
>> Date: Sat Oct 31 22:19:39 2020 +
>>
>> acpi_wmi(4): Add ACPI_PNP_INFO
>>
>> While the reason is obvious -- there's no EC in this system (Gigabyte
>> X299X AORUS MASTER desktop motherboard), at least searching the
>> `acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
>> looks like "something is broken" when first noticed. I wonder if we
>> could/should handle this gracefully -- no EC, do nothing, simply exit?
>
> Following patch should ignore missing EC like Linux does. Could you
> test it?
>
> diff --git a/sys/dev/acpi_support/acpi_wmi.c
> b/sys/dev/acpi_support/acpi_wmi.c
> index 379cfd1705f1..efae96cdcc9a 100644
> --- a/sys/dev/acpi_support/acpi_wmi.c
> +++ b/sys/dev/acpi_support/acpi_wmi.c
> @@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
> if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
> == NULL)
> device_printf(dev, "cannot find EC device\n");
> - else if (ACPI_FAILURE((status =
> AcpiInstallNotifyHandler(sc->wmi_handle,
> + if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
> ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
> device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
> AcpiFormatException(status));
> @@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
> ACPI_PHYSICAL_ADDRESS address,
> return (AE_BAD_PARAMETER);
> if (address + (width / 8) - 1 > 0xFF)
> return (AE_BAD_ADDRESS);
> + if (sc->ec_dev == NULL)
> + return (AE_NOT_FOUND);
> if (function == ACPI_READ)
> *value = 0;
> ec_addr = address;
@#@##! Web client ate all the tabs.
Patch is in attachment.
Output changed, though it's still somewhat noisy -- I guess there
isn't a way to NOT report the device that we are not going to attach
to, or do that e.g. only for verbose boot?
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
acpi_wmi0: Embedded MOF found
ACPI: \134GSA1.WQCC: 1 arguments were passed to a non-method ACPI
object (Buffer) (20201113/nsarguments-361)
acpi_wmi1: on acpi0
acpi_wmi1: cannot find EC device
acpi_wmi2: on acpi0
acpi_wmi2: cannot find EC device
acpi_wmi3: on acpi0
acpi_wmi3: cannot find EC device
acpi_wmi does not try to attach to EC node (PNP0C09). It only queries it
in OpRegion handler.
WMI's _HID/_CID is PNP0C14. According to your output, acpi_wmi has
successfully attached to 4 nodes.
Verbosity can be reduced with attached patch if current level is too
high for you.
--
WBR
Vladimir Kondratyevdiff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..1fddcd4f3637 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -245,8 +245,9 @@ acpi_wmi_attach(device_t dev)
/* XXX Only works with one EC, but nearly all systems only have one. */
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
- device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
+ ACPI_VPRINT(dev, acpi_device_get_parent_softc(dev),
+ "cannot find EC device\n");
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
AcpiFormatException(status));
@@ -701,6 +702,8 @@ acpi_wmi_ec_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
___
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_wmi noisy without EC
On 2020-11-17 10:57, Vladimir Kondratyev wrote:
On 2020-11-17 03:00, Yuri Pankov wrote:
I have started seeing the following on boot since some time:
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
acpi_wmi(4): Add ACPI_PNP_INFO
While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed. I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?
Following patch should ignore missing EC like Linux does. Could you
test it?
diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler -
%s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
@#@##! Web client ate all the tabs.
Patch is in attachment.
--
WBR
Vladimir Kondratyevdiff --git a/sys/dev/acpi_support/acpi_wmi.c b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler - %s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function, ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
___
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_wmi noisy without EC
On 2020-11-17 03:00, Yuri Pankov wrote:
I have started seeing the following on boot since some time:
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
acpi_wmi0: on acpi0
acpi_wmi0: cannot find EC device
device_attach: acpi_wmi0 attach returned 6
Likely following this commit:
commit 708d048ccfdacf6199cc08a56aa05a9c899441fd
Author: Vladimir Kondratyev
Date: Sat Oct 31 22:19:39 2020 +
acpi_wmi(4): Add ACPI_PNP_INFO
While the reason is obvious -- there's no EC in this system (Gigabyte
X299X AORUS MASTER desktop motherboard), at least searching the
`acpidump -dt` output doesn't show any PNP0C09 entries -- it certainly
looks like "something is broken" when first noticed. I wonder if we
could/should handle this gracefully -- no EC, do nothing, simply exit?
Following patch should ignore missing EC like Linux does. Could you test
it?
diff --git a/sys/dev/acpi_support/acpi_wmi.c
b/sys/dev/acpi_support/acpi_wmi.c
index 379cfd1705f1..efae96cdcc9a 100644
--- a/sys/dev/acpi_support/acpi_wmi.c
+++ b/sys/dev/acpi_support/acpi_wmi.c
@@ -246,7 +246,7 @@ acpi_wmi_attach(device_t dev)
if ((sc->ec_dev = devclass_get_device(devclass_find("acpi_ec"), 0))
== NULL)
device_printf(dev, "cannot find EC device\n");
- else if (ACPI_FAILURE((status =
AcpiInstallNotifyHandler(sc->wmi_handle,
+ if (ACPI_FAILURE((status = AcpiInstallNotifyHandler(sc->wmi_handle,
ACPI_DEVICE_NOTIFY, acpi_wmi_notify_handler, sc
device_printf(sc->wmi_dev, "couldn't install notify handler -
%s\n",
AcpiFormatException(status));
@@ -701,6 +701,8 @@ acpi_wmi_ec_handler(UINT32 function,
ACPI_PHYSICAL_ADDRESS address,
return (AE_BAD_PARAMETER);
if (address + (width / 8) - 1 > 0xFF)
return (AE_BAD_ADDRESS);
+ if (sc->ec_dev == NULL)
+ return (AE_NOT_FOUND);
if (function == ACPI_READ)
*value = 0;
ec_addr = address;
--
WBR
Vladimir Kondratyev
___
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"
13-current 'devinfo -v' does not show PnP and location strings
'devinfo -v' on latest 13-CURRENT does not show PnP and location strings for devices with no drivers attached. Is it intentional? ___ 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: r343567 aka PAE vs non-PAE merge breaks i386 freebsd
On 2019-02-22 09:04, Steve Kargl wrote: Ideas? Place hw.above4g_allow=0 into /boot/loader.conf? -- WBR Vladimir Kondratyev ___ 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: What is evdev and autoloading?
On 2019-02-17 21:03, Steve Kargl wrote: Anyone have insight into what evdev is? There appears to be no manual page. When I reboot a system with custom kernel, the system is autoloading evdev.ko, uhid.ko, and wmt.ko. I do not need nor what these modules loaded. How does one prevent this autoloading? Anyone have insight into what evdev is? evdev.ko is a small in-kernel library that makes all your input events like keyboard presses libinput-compatible. I do not need nor what these modules loaded. I think removing "option EVDEV_SUPPORT" from your kernel config should disable most of evdev.ko dependencies -- WBR Vladimir Kondratyev ___ 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"
r340343 triggers kernel assertion if file is opened with O_BENEATH flag set through symlink
Following test case triggers assertion after r340343:
#include
int
main(int argc, char **argv)
{
openat(open("/etc", O_RDONLY), "termcap", O_RDONLY | O_BENEATH);
}
It results in:
panic: Assertion (ndp->ni_lcf & NI_LCF_LATCH) != 0 failed at
/usr/src/sys/kern/vfs_lookup.c:182
___
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: Vbox causing host crash/reboot on 12-current
Hi
I am sure that crashes was caused by SMAP as I am faced with them too.
I have made following patch to fix panic (attached)
Apply it to portstree and rebuild emulators/virtualbox-ose-kmod
P.S. It is POC so no arch/SMAP autodetection
On 8/7/18 6:14 PM, AN wrote:
> Update:
>
> I found the revision:
> https://svnweb.freebsd.org/base?view=revision=336876
>
> Use SMAP on amd64.
>
> Could this possibly cause VBox to crash and reboot the system? Is
> there a sysctl to disable?
>
> Thanks
>
> On Tue, Aug 7, 2018 at 10:46 AM, AN wrote:
>> I recently started having severe instability on a workstation with
>> VirtualBox. I'm not sure if it was caused by the recent large ports
>> update, or a recent commit that affected SMAP. I can't seem to find
>> that revision, would someone please post it and also the workaround to
>> disable it, I would like to try it after work and see if disabling it
>> allows VBox to work. Is anyone else seeing this effect with Vbox?
>>
>> What I'm seeing is that as soon as a VM is started it reboots the
>> host, totally reproducible every time. I tried to rebuild VBox and
>> kmod, and also some qt5 ports but still not working. Any help is
>> appreciated, thanks for reading.
>>
>> Regards
> ___
> 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"
Index: emulators/virtualbox-ose/files/patch-smap
===
--- emulators/virtualbox-ose/files/patch-smap (nonexistent)
+++ emulators/virtualbox-ose/files/patch-smap (working copy)
@@ -0,0 +1,36 @@
+--- src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c.orig 2018-08-08 22:32:59.741196000 +0300
src/VBox/HostDrivers/Support/freebsd/SUPDrv-freebsd.c 2018-08-08 22:52:49.842726000 +0300
+@@ -44,6 +44,7 @@
+ #include
+ #include
+ #include
++#include
+
+ #include "../SUPDrvInternal.h"
+ #include
+@@ -310,6 +311,9 @@ static int VBoxDrvFreeBSDIOCtl(struct cd
+ {
+ PSUPDRVSESSION pSession;
+ devfs_get_cdevpriv((void **));
++int rc;
++
++stac();
+
+ /*
+ * Deal with the fast ioctl path first.
+@@ -318,9 +322,13 @@ static int VBoxDrvFreeBSDIOCtl(struct cd
+ || ulCmd == SUP_IOCTL_FAST_DO_HM_RUN
+ || ulCmd == SUP_IOCTL_FAST_DO_NOP)
+ && pSession->fUnrestricted == true)
+-return supdrvIOCtlFast(ulCmd, *(uint32_t *)pvData, _VBoxDrvFreeBSDDevExt, pSession);
++rc = supdrvIOCtlFast(ulCmd, *(uint32_t *)pvData, _VBoxDrvFreeBSDDevExt, pSession);
++else
++rc = VBoxDrvFreeBSDIOCtlSlow(pSession, ulCmd, pvData, pTd);
+
+-return VBoxDrvFreeBSDIOCtlSlow(pSession, ulCmd, pvData, pTd);
++clac();
++
++return rc;
+ }
+
+
Property changes on: emulators/virtualbox-ose/files/patch-smap
___
Added: fbsd:nokeywords
## -0,0 +1 ##
+yes
\ No newline at end of property
Added: svn:eol-style
## -0,0 +1 ##
+native
\ No newline at end of property
Added: svn:mime-type
## -0,0 +1 ##
+text/plain
\ No newline at end of property
___
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: Linux process causes kernel panic
On 8/6/18 11:41 PM, Konstantin Belousov wrote: >>> linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401) >>> -- here it stops -- >> Can you fix your mail client ? Unfortunately, it did all that dumb wraps at send time not at edit. Sorry. >>> ddb also shows that process is looping somewhere inside linux_sys_futex() >> There are two bugs. One is that ifuncs handling for relocations against >> local symbols in elf obj modules was missed. Patch below fixed it for me. >> >> Second bug is that futexes seems to not handle accesses to the CoW >> mappings which are not yet copied. I think that the second bug is >> irrelevant for your case, since it worked before. >> >> Try this patch in addition to the linux/ patches I sent before. It fixed skype for me too! Thank you! ___ 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"
Linux process causes kernel panic
I've got similar panic right after skype start
Disabling of SMAP via loader tunable workarounded the panic for me.
Applying of the patch make skype eating 100%CPU in unkillable state.
tail of ktrace dump
1238 skype CALL linux_gettid
1238 skype RET linux_gettid 101123/0x18b03
1238 skype CALL
linux_sys_futex(0x3301edc,0x84,0x1,0x7fff,0x3301ec0,0x2)
1238 skype RET linux_sys_futex 0
1238 skype CALL linux_sys_futex(0x33b0fac,0x80,0x1,0,0x33b0f90,0x1)
1238 skype CALL linux_sys_futex(0x3301edc,0x80,0x1,0,0x3301ec0,0x1)
1238 skype RET linux_sys_futex -1 errno -11 Resource temporarily
unavailable
1238 skype CALL
linux_sys_futex(0x3301ec0,0x81,0x1,0x3301ec0,0x33b02c8,0xc168)
1238 skype RET linux_sys_futex 0
1238 skype CALL
linux_sys_futex(0x33b0fac,0x85,0x1,0x1,0x33b0fa8,0x401)
-- here it stops --
ddb also shows that process is looping somewhere inside linux_sys_futex()
KDB: enter: manual escape to
debugger
[ thread pid 11 tid 100014
]
Stopped at kdb_enter+0x3b: movq
$0,kdb_why
db> bt
1238
Tracing pid 1238 tid 101049 td
0xf80157a64000
cpustop_handler() at cpustop_handler+0x28/frame
0xfe9d6df0
ipi_nmi_handler() at ipi_nmi_handler+0x44/frame
0xfe9d6e10
trap() at trap+0x49/frame
0xfe9d6f20
nmi_calltrap() at nmi_calltrap+0x8/frame
0xfe9d6f20
--- trap 0x13, rip = 0x80709219, rsp = 0xfe00a8c906d0, rbp =
0xfe00a8c90750
---
witness_unlock() at witness_unlock+0x139/frame 0xfe00a8c90750
__mtx_unlock_flags() at __mtx_unlock_flags+0x5d/frame
0xfe00a8c90790
futex_put() at futex_put+0x134/frame
0xfe00a8c907c0
linux_sys_futex() at linux_sys_futex+0x609/frame
0xfe00a8c90880
ia32_syscall() at ia32_syscall+0x282/frame
0xfe00a8c909b0
int0x80_syscall_common() at int0x80_syscall_common+0x9c/frame 0x401
On 06.08.2018 15:03, Johannes Lundberg wrote:
> On Sat, Aug 4, 2018 at 3:22 PM Konstantin Belousov
> wrote:
>
>> On Sat, Aug 04, 2018 at 01:12:17PM +0100, Johannes Lundberg wrote:
>>> No panic over night with that tunable so it seems you're on the right
>>> track.
>> Please try this, on top of r337316.
>>
> Been running boinc client now with 4 linux processes at 100% cpu load with
> this patch for a while. So far so good.
>
>
>> diff --git a/sys/amd64/linux/linux_machdep.c
>> b/sys/amd64/linux/linux_machdep.c
>> index 6c5b014853f..434ea0eac07 100644
>> --- a/sys/amd64/linux/linux_machdep.c
>> +++ b/sys/amd64/linux/linux_machdep.c
>> @@ -78,6 +78,9 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>>
>> +#include
>> +#include
>> +
>> #include
>> #include
>> #include
>> @@ -88,8 +91,6 @@ __FBSDID("$FreeBSD$");
>> #include
>> #include
>>
>> -#include
>> -
>> int
>> linux_execve(struct thread *td, struct linux_execve_args *args)
>> {
>> @@ -276,3 +277,48 @@ linux_set_cloned_tls(struct thread *td, void *desc)
>>
>> return (0);
>> }
>> +
>> +int futex_xchgl_nosmap(int oparg, uint32_t *uaddr, int *oldval);
>> +int futex_xchgl_smap(int oparg, uint32_t *uaddr, int *oldval);
>> +DEFINE_IFUNC(, int, futex_xchgl, (int, uint32_t *, int *), static)
>> +{
>> +
>> + return ((cpu_stdext_feature & CPUID_STDEXT_SMAP) != 0 ?
>> + futex_xchgl_smap : futex_xchgl_nosmap);
>> +}
>> +
>> +int
Re: Proper way to remove never used ioctls
On 2018-06-02 20:36, Allan Jude wrote: On 2018-06-02 11:03, Warner Losh wrote: On Sat, Jun 2, 2018 at 7:33 AM, Vladimir Kondratyev wrote: Hi, Our sys/mouse.h header has a definition of MOUSE_GETVARS and MOUSE_SETVARS ioctls which are not documented and only stubbed in a few drivers: mse(4), psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS implemented in psm(4) Given the fact that they were introduced 20 years ago, implementation was never completed and googling on them shows no traces of usage in indexed universe, is it acceptable to just drop both defines and implementation w.o. leaving any COMPAT_FREEBSD shims? I'd prepare a patch just removing them. I'd then send that patch to the ports mgr team and request a exp-run. Details for that can be found in https://www.freebsd.org/doc/en_US.ISO8859-1/articles/committers-guide/ports.html Once that's done, submit a Phabricator review and send me email. I'll make sure it gets pushed in if there's no objections. Warner This indeed seems to be the correct approach. The exp-run will compile the entire ports tree against the patched base system, and identify any 3rd party software that fails to compile because of the change. Thank you, Allan and Warner! I'll follow yours advice. -- WBR Vladimir Kondratyev ___ 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"
Proper way to remove never used ioctls
Hi, Our sys/mouse.h header has a definition of MOUSE_GETVARS and MOUSE_SETVARS ioctls which are not documented and only stubbed in a few drivers: mse(4), psm(4) and syscon's sysmouse(4). The only exception is MOUSE_GETVARS implemented in psm(4) Given the fact that they were introduced 20 years ago, implementation was never completed and googling on them shows no traces of usage in indexed universe, is it acceptable to just drop both defines and implementation w.o. leaving any COMPAT_FREEBSD shims? -- WBR Vladimir Kondratyev ___ 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"
CFT: Driver for generic MS Windows 7/8/10 - compatible USB HID multi-touch touchscreens
Hi, all Following patch [1] adds support for generic MS Windows 7/8/10 - compatible USB HID multi-touch touchscreens via evdev protocol. It is intended to be a native replacement of hid-miltitouch.c driver found in Linux distributions and multimedia/webcamd port. Patch is made for 12-CURRENT and most probably can be applied to recent 11-STABLE and 11.1-RELEASE (not tested) How to test. 1. Apply patch [1] 2. To compile this driver into the kernel, place the following lines into your kernel configuration file: device wmt device usb device evdev Alternatively, to load the driver as a module at boot time, place the following line in loader.conf(5): wmt_load="YES" 3. Install x11-drivers/xf86-input-evdev or x11-drivers/xf86-input-libinput port 4. Tell XOrg to use evdev or libinput driver for the device: Section "ServerLayout" InputDevice"TouchScreen0" "SendCoreEvents" EndSection Section "InputDevice" Identifier "TouchScreen0" Driver "evdev" # Driver "libinput" Option "Device" "/dev/input/eventXXX" EndSection Exact value of "/dev/input/eventXXX" can be obtained with evemu-record utility from devel/evemu. Note1: Currently, driver does not support pens or touchpads. Note2: wmt.ko should be kld-loaded before uhid driver to take precedence over it! Otherwise uhid can be kld-unloaded after loading of wmt. [1] wmt review: https://reviews.freebsd.org/D12017 Raw diff: https://reviews.freebsd.org/file/data/ruebvnmyzymnhc7ho37f/PHID-FILE-nue7bjzefxyvwjkcfepd/D12017.diff -- WBR Vladimir Kondratyev ___ 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
On 09.06.2017 15:57, Jonathan Anderson wrote: > Hi Vladimir, > > Thanks very much... I've been using your patch for awhile with my > Synaptics touchpad and it's lovely to have two-finger scrolling that > works properly! I did need to massage the patch to make it apply on > drm-next: > https://github.com/trombonehero/freebsd/commit/3d74a33a1bc709d289216cb946744afecb70f6b5 > > The patch is commited to CURRENT already so you don`t need apply extra patches anymore. Part of initial patch that I can find under your link has not been committed as it can trigger deadlock on KDB entering. > Sometimes I experience dropped touchpad events, particularly when the > system is busy and my wi-fi is being reconfigured. Is there anything I > can do to help debug this? Are you observing SYN_DROPPED events in evemu-record output? If so run it under "nice -n -20" If SYN_DROPPED still persists, add debug.psm.loglevel=5 to /boot/loader.conf, reboot and send me content of /var/log/messages. Only "dropped touch" part of log is needed. Event dropping occurs when kernel writes events faster than user can read, so usually it is a user-land 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: CFT: EVDEV support in psm(4) driver
On 08.06.2017 02: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): You can test evdev directly w/o Xserver started by running of evemu-record utility from https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218383 PR to see if events are matching keys or not. Note: depending on kern.evdev.rcpt_mask sysctl value only one of kdbmux or AT keyboard devices should emit events. Not bother! > Section "InputDevice" > Identifier "Keyboard0" > Driver "evdev" > Option "Device" "/dev/input/event1" > EndSection This lines are not required usually if you are using devd or udev autoconfiguration backends. Moreover they can do a harm. Could you compare input device lists from xinput command output with evemu-record output? They should be the same except "Virtual core XTEST" entries. If they are not, that could be the culprit. It is possinle that Xorg receives one key event several times. In that case try to uninstall xf86-input-keyboard and restart Xserver than. > 2. My Synaptics clickpad (and the pointer in general) freeze for several > seconds, although it hasn't done it lately. When a freeze occurs (in X > windows), other GUI processes don't seem to be affected. If I have > another pointer device attached (e.g. USB mouse), it also doesn't move > the pointer during the freeze. Try run evemu-record on synaptics device node to see if you are receiving events from touchpad during freezes or not ___ 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
On 2017-04-17 13:59, Jan Kokemüller wrote: Hi Vladimir, this patch works great for me! Great! I am not using xf86-input-mouse or xf86-input-keyboard. You stepped on minefield. xf86-input-keyboard does things that should be done by xorg-server like terminal blanking, disabling keybuffering and so on. I had seen (and heard) some funny effects before copied required ~20 lines of code from xf86-input-keyboard to xorg-server. - TrackPoint scrolling holding the middle button Thanks for report. I was not able to test trackpoint due to lack of hardware. 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. Just run moused on /dev/psm0. Unlike usermode drivers like xf86-input-synaptics in psm mode, in-kernel driver keeps psm0 device unbusied in sysmouse mode. 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 . Patch looks good to me. I will merge it after small refactoring. Thank you! -- WBR Vladimir Kondratyev ___ 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"
CFT: EVDEV support in psm(4) driver
Hi, FreeBSD laptop users Following patch [1] bring in multitouch EVDEV support for Synaptics and Elan PS/2 touchpads found in many laptops. (And for generic relative PS/2 mices as well). This allows to replace our limited in-kernel gesture processor with full-blown one from xf86-input-synaptics or xf86-input-libinput driver and makes Synaptics and Elan PS/2 touchpad support to be mostly on par with Linux Other mostly evdev-unrelated fixes and improvements are: 1. Fix rare but quite annoying issue in Elan hw v.4 touchpads support. Triple-finger taps are reported as double-finger taps under several circumstances. 2. Adjust tap min queue size on Elans to make multifinger tap detection more reliable. 3. Adjust Elantech palm width threshold to nearly match synaptics defaults 4. Discard pointer movements rather then mouse packets on palm detection to reduce cursor jumping. 5. Enable palm detection on two finger touches for multitouch trackpads. 6. Reduce synaptics touch sensitivity Increase hw.psm.synaptics.min_pressure default value from 16 to 32 to nearly match Linux driver (30-35 hysteresis loop). This makes libinput tap detection more reliable. 7. Serialize atkbdc ports and psm softc access with mutexes and mark psm interrupt and cdev handlers MPSAFE Patch is made for 12-CURRENT and most probably can be applied to recent 11-STABLE (not tested) How to test. 1. Apply patch [1] 2. Add `device evdev` and `options EVDEV_SUPPORT` to kernel config file and rebuild kernel 3. Add hw.psm.elantech_support=1 or hw.psm.synaptics_support=1 to /boot/loader.conf 4. Add kern.evdev.rcpt_mask=12 to /etc/sysctl.conf to enable psm source and disable sysmouse 5. Install x11-drivers/xf86-input-synaptics port compiled with EVDEV support enabled or x11-drivers/xf86-input-libinput 6. Tell XOrg to use synaptics or libinput driver as primary mouse driver: Section "InputDevice" Identifier "Mouse0" Driver "synaptics" # Driver "libinput" Option "Device" "/dev/input/eventXXX" EndSection Exact value of "/dev/input/eventXXX" can be obtained with evemu-record utiliy [2]. In most cases I have seen psm event device is located at /dev/input/event2. Lenovo trackpoint should appear as separate relative event device and is handled with xf86-input-evdev driver (not tested yet) Note: Neither HAL nor DEVD Xorg configuration backends support evdev at present time so x11-servers/xorg-server should be recompiled w/o autoconfiguration support. Alternatively DEVD or UDEV backends from coming Xorg update [3] can be used 7. Reboot and test touchpad with XOrg or evemu-record [1] psm(4) evdev support: https://reviews.freebsd.org/D10207 Raw diff: https://reviews.freebsd.org/file/data/pqjvpuhwfgsu5nnamibg/PHID-FILE-uuyjx66blb344hre3nc2/D10207.vson.id27478.whitespaceignore-most.diff [2] evemu port: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218383 Not commited yet. [3] Xorg 1.19.3 update: https://lists.freebsd.org/pipermail/freebsd-x11/2017-March/019100.html (Patch content is slightly garbled) -- WBR Vladimir Kondratyev ___ 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: basic evdev setup
Hi, Andriy I can add my 2 cents to Oleksander`s 1. If xf86-input-keyboard is not used as primary keyboard driver, patch [1] should be applied to xorg-server to prevent ttyv8<->xorg frame buffers interference 2. It`s also worth trying one of PR/196678 patches to xorg devd configuration backend [2] 3. To see events going through evdev interface, evemu-record utility from evemu package [3] can be used. [1] https://reviews.freebsd.org/differential/changeset/?ref=218662 [2] https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=196678 [3] https://www.freedesktop.org/software/evemu/ 1, 2 and 3 was collected together at https://reviews.freebsd.org/D7588 but this review is somewhat outdated now. On 2017-02-16 00:57, Oleksandr Tymoshenko wrote: Andriy Gapon (a...@freebsd.org) wrote: Oleksandr, at the moment the documentation for evdev on FreeBSD is very scarce, even if we talk about wiki pages, informal howto-s or blog posts. So, I would like to ask your help for a very basic evdev test setup. All input devices I have are standard keyboard and a mouse with some extra keys. I would like to be able to use the keyboard and the mouse as usual when in the console. And I would like to be able to use the extra mouse keys in X. What steps should I take to achieve that? I already evdev + EVDEV_SUPPORT on the kernel side in addition to the regular keyboard and mouse drivers (atkbdc + ums). I have also installed xf86-input-evdev. Do I need any additional kernel evedev configuration via sysctl? What should I add to xorg configuration to enable evdev for X? * Adding Vladimir Kondratyev to Cc since he's contributed evdev patch Hi Andriy, evdev works in parallel with standard input system, so you don't have to worry about console input support. Current evdev implementation uses following devices as a source of input events: ukbd(4), ums(4), atkbd(4), kbdmux(4), sysmouse(4) As you see three of them are actual hardware and two of them are virtual aggregating devices. You can enable/disable particular sources using kern.evdev.rcpt_mask sysctl. There are four controlling bits to enable/disable driver as a source of events: bit 0: is set enables sysmouse bit 1: is set enables kbdmux bit 2: is set enables ums bit 3: is set enables atkbd, ukbd By default sysmouse and kbdmux are enabled. Sysmouse requires moused to work, so make sure that moused is running on your system. In your Xorg config you'll need something like this: Section "InputDevice" Identifier "Mouse0" Driver "evdev" Option "Device" "/dev/input/event0" EndSection Section "InputDevice" Identifier "Keyboard0" Driver "evdev" Option "Device" "/dev/input/event1" EndSection I didn't test Xorg thoroughly so there might be some undiscovered bugs. My target use case was Qt in EGLFS mode. If you have any questions or bugreports - I'll be glad to answer them ___ 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"
