@bcr Do you have any objections on behalf of core@? As I am removing some stale members I was also looking forward for core's approval.

patch ready and tested at PR 265632

In D30333#825537, @arrowd wrote:

In D30333#825523, @eduardo wrote:

How can I find device id for this legion like

#define	LENOVO_L5AMD_SUBVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)

Thanks

In my case I ran pciconf -lv and found a device with multimedia class:

hdac0@pci0:0:31:3:      class=0x040380 rev=0x31 hdr=0x00 vendor=0x8086 device=0xa171 subvendor=0x1043 subdevice=0x15e0
    vendor     = 'Intel Corporation'
    device     = 'CM238 HD Audio Controller'
    class      = multimedia
    subclass   = HDA

The subdevice=0x15e0 part turned out to be the correct value for that switch.

In D30333#825523, @eduardo wrote:

How can I find device id for this legion like

#define	LENOVO_L5AMD_SUBVENDOR	HDA_MODEL_CONSTRUCT(LENOVO, 0x381b)

Thanks

it works same way for a legion 5 intel version:

I'm trying to get sound from my speakers on a Lenovo 5 (intel i7), headphones works ok.

FWIW, splice: https://reviews.freebsd.org/D30597

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

we have so many such unfinished things

In D30378#684094, @trasz wrote:

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono

Why do we need it? All the BSD's seem to exist without splice() just fine?

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

It's literally the second item on that list, for example pulseaudio hard crashes because it's not there. I have started but it's pretty hard, I wonder if anyone can help?

FWIW, splice(2) can be a wrapper around copy_file_range(2). We should also have a fallback from sendfile(2) to splice(2), for when it fails with ENOTSOCK. This is one of the things that break Mono.

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

In D30378#684088, @dchagin wrote:

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

some time ago I wrote splice emulation via dofileread/dofilewrite ) but I abandoned it because I think we need a native splice() and tee() implementation. feel free to as arch@ about it:)

The most pressing issue is the incomplete pthread support notably with FUTEX_LOCK_PI and FUTEX_UNLOCK_PI and friends.

https://wiki.freebsd.org/Linuxulator#Roadmap, pi is not the key, we have so many important holes

I don't think they are even usable, since the core file is in FreeBSD format that linux gdb can't parse, and confuse the freebsd gdb because it's a linux process/elf.

we have so many such unfinished things, like arm linuxulator, splice sys call....

Yes, about splice, I was thinking we could just use a regular copy and be done with it. It wouldn't be that hard to implement, I can possibly look at it.

In D30378#684071, @dchagin wrote:

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

we have so many such unfinished things, like arm linuxulator, splice sys call....

In D30333#683079, @arrowd wrote:

lots of output

In D30378#684069, @pitwuu_gmail.com wrote:

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

In D30378#684068, @emaste wrote:

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

IMO this sort of thing is sufficient reason to have this linprocfs entry. What do you think about extending it slightly, at least translating FreeBSD's default %N.core to the Linux equivalent (%e.core I guess?)

Encountered in the crash handler of 'kodi'. Kodi still crashes, but at least the crash handler doesn't seem to crash anymore.

In D30378#684066, @emaste wrote:

Is there a way to config git to do that by default? It's annoying to do every time.

I'm not sure, although I also suspect you don't want it when generating a patch for your own review, not for upload to Phabricator. There is a tool in the tree, tools/tools/git/git-arc, which can take care of submitting phab reviews for you.

Is there a way to config git to do that by default? It's annoying to do every time.

In D30378#683157, @emaste wrote:

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details

hi, what is the purpose for this? it will be used read only. so what is the program depend on it?

For future uploads please include full context by using e.g. git show -U99999 <hash> - see https://wiki.freebsd.org/Phabricator for details