In D20720#448402, @trasz wrote:

In D20720#448101, @greg_unrelenting.technology wrote:

Many many many Linux binaries are ELFOSABI_NONE.

The Elf64_Brandinfo definitions directly above the added lines allow executables with ELFOSABI_NONE to run when interp_path matches. You can see one was added for musl libc, before that one was added, Alpine Linux did not work.
But that's for normal executables.

But the musl entry still says ELFOSABI_LINUX, doesn't it?

Many many many Linux binaries are ELFOSABI_NONE.

Well, someone could chroot into a *FreeBSD* installation with the compat/linux packages installed in it..

Works fine on aarch64, please add it to the list

Rebased for rS348195 (D20357)

I wonder if this is what we need on aarch64 for the Ampere eMAG server to not panic in ACPI: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=237055#c40

update: what's hanging is the WRITE4 for putting the PLL into normal mode!

Kernel with this patch boots fine on Amazon EC2 (which btw you can use too, freebsd-snapshots posts have aarch64 AMIs)

new emmc patch is D20156

In D19335#433606, @manu wrote:

In D19335#433397, @manu wrote:

In D19335#433249, @greg_unrelenting.technology wrote:

rebased, depends on D19986

not tested yet — for some reason my rockpro64 can't boot: clknode_register hangs when registering the first PLL on rk3399_cru0 :(

Could you test reverting r344626 ? ganbold@ have problem with this revision on the NanoPi T4. I personally don't have problems booting it (tried yesterday).

Mhm no, I've unplugged my eMMC module from my RockPro64 for a long time now so it's not that.
Could you try with the latest dtb ? It's installed now but on the wrong path until @kevans commit his fix. (so it's in /boot/dtb/ directly right now)

rebased, depends on D19986

Added fdt detach corresponding to the current attach code (usb-phy)

I don't think anyone really worked on the tests. I never tried to run them.

Done. btw, the original version was confirmed working on the Ampere system.

In D19986#430964, @emaste wrote:

In D19986#430466, @manu wrote:

Something like D19389 would be better.

Ah, yes. GregV would you rework it using that approach?

Done. Checked that mlx5ib loads.

In D19983#429595, @hselasky wrote:

Can you verify that the LINT kernel passes with this change on aarch64?

Sure, split to D19987

Update: the GPU hangs are *not* caused by IOMMU remapping. Possibly a bug in drm-v5.0… I'll try the updated version of this patch with stable drm later

In D19845#428854, @tychon wrote:

Looks like a symptom of non-translatable physical address. I've encountered drivers which need additional work outside of the scope of this effort. Perhaps this is the case there as I can't any more cases in the Linux KPI where a physical address is substituted for a DMA one.

Also, I assume this is in remap mode. Does it work in identify map mode hw.busdma.default="bounce"? Unless there is an API which escaped, if it works in hw.dmar.enable="0" it's not a regression from before :-/

Some more i915 GPU testing (w/o the latest update here): after using Firefox (opengl layers, xwayland) for some time, GPU resets start happening

works very well, will this be committed soon?

Also tested on an AMD Ryzen + Vega system, no regressions. (No IOMMU there because no one wrote a dmar equivalent for AMD IOMMU…)

Tested on my Haswell laptop with drm-v5.0, everything works (both with DMAR on and off), this line is new in dmesg:

okay, PCI is now https://reviews.freebsd.org/D19896

done

The quirk is a much more elegant way, thanks for the suggestion!

Landed as r345407.

In D19507#423995, @imp wrote:

I wouldn't be opposed to that either. I dislike special cases, but this may be a good case for an exception.

In D19507#423825, @imp wrote:

IIRC, this violates the ACPI definition for these fields.

Dammit. The Ampere eMAG (which uses the pl011 SBSR UART) represents *shiftp = 2; as

In D19438#416304, @ae wrote:

I have no objection. AFAIR, the main goal of this change was the adding ability to extend number of entries for some tables, that have very little number of partition entries, e.g. 1 or 2.
I think if you revert this change, then you will not able to add new partitions for these tables, even if there are enough space to keep them.

I can confirm that mtu changes on ena work fine with this patch, nice

Merged into D19507

btw, would it be better to integrate all my uart patches into this, or post them separately?

In D19507#417521, @andrew wrote:

Could you use spcr->SerialPort.AccessWidth to find this? It's set to 1 in the copy of the spcr table I have indicating byte access.

In D19330#414453, @markj wrote:

I still think that the change should apply only to shm descriptors

In D19354#414690, @jbeich wrote:

Greg, can you help fix stdsimd on aarch64?

I've noticed a generic-ehci driver in sys/mips/mediatek/mtk_ehci.c already (and tried on my RK3399, it does attach). That should probably be replaced by this. Does anyone test mediatek MIPS these days? :)

In D19336#413879, @manu wrote:

I haven't looked at the arasan controller yet but I'm sure that if there is a different compatible it's because we need to do more work than just matching on the compatible.

In D19330#414136, @markj wrote:

I don't really follow. For regular files, O_NONBLOCK means "don't block on open." vn_read() will translate O_NONBLOCK to IO_NDELAY, but most filesystems don't do anything with that. In the snippet you referenced, the code has a comment, "refuse to block when reading," but with this patch shm_read() will block anyway because uiomove_object_page() provides no mechanism for the caller to ask for non-blocking semantics. So either Linux ignores the O_NONBLOCK flag when reading from a shm object and the referenced comment is bogus, or Linux actually honours the flag, in which case this patch isn't sufficient. In the former case, the code should simply be eliminated rather than changing the kernel.

In D19330#414021, @markj wrote:

What are the semantics on Linux? I can imagine O_NONBLOCK meaning "return EAGAIN if the page is swapped out," in which case this patch is not sufficient.

In D18694#410790, @wulf wrote:

I hope you won't mind if I change sysctl name from "input_id" to "id" and disable exposure of optional properties like "uniq" and "phys" if they are not set. Just to be consistent with ioctl interface.

ping @brooks

Works fine for me. x11-im/fractal update to 4.0.0 is waiting on this.

added missing EVDEV_UNLOCK

In D18694#403804, @wulf wrote:

To handle native device creation one should listen for EVDEV devd events while to handle cuse devices CDEV devd events should be processed.
You can not just listen for CDEV devd events as there is a race window between cdev and sysctl creation.

Looks like powerpc64 is also here (but not the new aarch64 bootstraps)…

In D18754#400281, @tcberner wrote:

@greg_unrelenting.technology : https://phabricator.kde.org/D18009

Updated with suggestions

In D18754#400221, @tcberner wrote:

Tryign to ck-launch-session /usr/local/bin/startplasmacompositor leads to a segfault ck.

oh, it also didn't enable termios raw mode. That was causing Weston to crash when pressing Enter :D Fixed.

+ fix re-plugging devices by checking if the found device is still alive