Advice regarding sync_file implementation
Hi I'm working on getting drm-next graphics parts up to Linux 4.11. After current drm-next version drm start using sync_file to synchronize access to shared dma buffers between userland and kernel. sync_file is using anon_inode, both which currently are missing from linuxkpi. http://elixir.free-electrons.com/linux/v4.11/source/drivers/dma-buf/sync_file.c#L31 https://elixir.free-electrons.com/linux/v4.11/source/fs/anon_inodes.c#L70 This will be used by both kernel (drm and graphics drivers) and userland (libdrm). What would be the best solution to implement this on FreeBSD? Do we have anything equivalent that we can use or is it best to make a similar implementation as done in Linux? We want to reduce the need of patching upstream and Linux code as much as possible and implement things in linuxkpi to make further updates more smooth. Cheers! /Johannes ___ 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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard
Am Sat, 9 Dec 2017 19:10:03 -0700 Warner Losh schrieb: > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann wrote: > > > Am Sat, 9 Dec 2017 14:30:38 -0700 > > Warner Losh schrieb: > > > > > On Sat, Dec 9, 2017 at 1:47 PM, O. Hartmann > > wrote: > > > > > > > Am Sat, 9 Dec 2017 13:00:12 -0700 > > > > Warner Losh schrieb: > > > > > > > > > On Sat, Dec 9, 2017 at 12:13 PM, Michael Tuexen > > > > wrote: > > > > > > > > > > > > On 9. Dec 2017, at 19:41, O. Hartmann > > > > wrote: > > > > > > > > > > > > > > Running a PCengines APU2C4 with FreeBSD Current, r326734, fails > > to > > > > boot, > > > > > > it gets stuck at > > > > > > > the very first messages on the serial console prompting > > > > > > > > > > > > > > Consoles: internal video/keyboard > > > > > > > > > > > > > > and then nothing more. > > > > > > I don't think it is a general problem with r326734. I'm running on > > the > > > > > > same hardware > > > > > > that revision (with some modifications to the TCP I'm testing): > > > > > > > uname -a > > > > > > FreeBSD nf3.testbed 12.0-CURRENT FreeBSD 12.0-CURRENT #31 > > r326734M: Sat > > > > > > Dec 9 20:03:59 CET 2017 tuexen@nf3.testbed:/usr/home/ > > > > > > tuexen/head/sys/amd64/compile/TCP amd64 > > > > > > > > > > > > > > > > Hi Michael, > > > > > > > > > > What's your boot setup? BIOS vs UEFI? UFS vs ZFS? GELI? GPT vs MBR? > > > > Plants > > > > > vs Zombies? And did you update your boot blocks or not? > > > > > > > > > > Warner > > > > > > > > All right, I got your point here, my bad, my apaologies. > > > > > > > > I boot from a NanoBSD-prepared image residing on a SD card. The > > partiton > > > > scheme is GPT, > > > > non UEFI (the SeaBIOS, latest version available for the APU2C2 > > available) > > > > doesn't support > > > > UEFI. NanoBSD scripts (legacy.sh) has been modified to fit our > > requests. > > > > > > > > The modifications target at most the creation of a GPT partition scheme > > > > layout, > > > > installing boot/pmbr as bootcode and boot/gptboot on a freebsd-boot > > > > partition as well as > > > > boot/boot1.efifat onto a dedicated efi-type partition. The UEFI > > partition > > > > is usually > > > > created before(!) the freebsd-boot partition, but in this specific > > > > version, there is NO > > > > EFI partition, only the gptboot containing partition. The binaries of > > the > > > > above mentioned > > > > bootcode/efi code images are taken from the newly build world. I do not > > > > use boot0sio, the > > > > portion where it is installed is excluded by some "if GPT; then" > > clause. > > > > > > > > The last known-good version I reported in working is the image I > > backuped > > > > last time. I > > > > lost the USB 2.0 flash device today containing the last version, that > > was > > > > not far from > > > > r326218, the version that corrupted FreeBSD, I guess it was r326184, > > but I > > > > really do not > > > > know and I havn't a backup of that image. > > > > > > > > The buildworld process is maintained by a bunch of WITHOUT_ statements > > in > > > > a file driving > > > > NanoBSD. This just for the record just in case FreeBSD build system > > changed > > > > something significantly. > > > > > > > > > > Should, but if you could share what those all are, I can tell you if any > > > might cause an issue that would help us root cause. > > > > > > > > > > Building a world takes 90 minutes or more, so bi-secting the problem > > would > > > > be a pain in > > > > the arse (that said, I imply that world and kernel need to be in sync). > > > > > > > > I would appreciate hints or tipps where to look after or how to > > increase > > > > verbosity > > > > especially at the first boot stage. > > > > > > > > > > OK. So you are booting with gptboot off an SD card on the PC Engines > > system > > > via legacy methods for a UFS root partition. GELI is not involved, > > correct? > > > > I do not use GELI. GEOM_GELI is in ther kernel compiled in. No modules are > > allowed to be > > loaded. > > > > The disk image created and mounted via md0 (mdconfig -a -t vndo -f > > filename.img) looks > > like: > > > > => 40 5175704 md0 GPT (2.5G) > >40 10242 boot0 (512K) > > 1064 20594643 dsks1a (1.0G) > > 2060528 20636434 dsks2a (1.0G) > > 4124171 10485765 dsks3 (512M) > > 5172747 2997 - free - (1.5M) > > > > This is the image type without UEFI partition, legacy boot only via > > gptboot. > > > > > > > > Sadly, there's no easy way to increase the verbosity of the early boot > > > since the boot blocks have to live in such a constrained environment > > > there's a strong bias against including debug code. > > > > > > But what we know is encouraging. We know that gptboot properly loaded, > > and > > > that it found /boot/loader, loaded it, and then we had the issue. This > > > helps us constrain
Re: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard
Am Sun, 10 Dec 2017 11:14:51 +0100 "O. Hartmann" schrieb: > Am Sat, 9 Dec 2017 19:10:03 -0700 > Warner Losh schrieb: > > > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann wrote: [schnipp] > > > > > > I'm with you on this. I'm just trying to figure out what, exactly, I need > > to try to setup since this isn't quite my env. > > I have to wait until my box has built r326550 ... I just built r326550, installed the usual way without changes the NanoBSD image and it worked! > > > > > So you don't load GELI since you have it in your kernel. Does this mean > > that gptboot loading from a GELI partition? > > I have a static kernel. Some regulations say, that the kernel is not allowede > to > dynamically load modules at any time, so I just built GEOM_ELI into the > kernel - I > wanted to make that clear for the record. > > The rest is simple and vanilla, I guess. > > > > > Warner > > > > > > > > > Kind regards, > > > > > > Oliver > > > > > > > > > > > Since this is very early in /boot/loader's purview, I don't think > > > > kernel/world matter at all (apart from the fact that loader is built as > > > > part of world). > > > > > > > > The PCengines APU with the most recent SeaBIOS isn't capable of booting > > > > > > > > > FreeBSD from USB > > > > > 3.0 devices. Even from USB 2.0 flashdrives working images fail at the > > > > > > > > boot > > > > > loader with > > > > > "failed with error 19". > > > > > > > > > > > > OK. I assume this is a different issue. :) > > > > > > > > Warner > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Best regards > > > > > > > Michael > > > > > > > > > > > > > > > > FreeBSD CURRENT FreeBSD 12.0-CURRENT #52 r324234: Tue Oct 3 > > > 11:00:53 > > > > > > > CEST 2017 amd64 > > > > > > > > works fine. > > > > > > > > > > > > > > > > What the heck has changed? > > > > > > > > > > > > > > > > Kind regards, > > > > > > > > > > > > > > > > oh > > > > > > > > > > > > > > > > -- > > > > > > > > O. Hartmann > > > > > > > > > > > > > > > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > > > > > > > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 > > > Abs. 4 > > > > > > > BDSG). > > > > > > > > > > > > > > ___ > > > > > > > freebsd-current@freebsd.org mailing list > > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > > > > freebsd.org" > > > > > > > > > > > > > ___ > > > > > > freebsd-current@freebsd.org mailing list > > > > > > https://lists.freebsd.org/mailman/listinfo/freebsd-current > > > > > > To unsubscribe, send any mail to "freebsd-current-unsubscribe@ > > > > > freebsd.org" > > > > > > > > > > > > > > > > > > > > -- > > > > > O. Hartmann > > > > > > > > > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > > > > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 > > > > > > > > BDSG). > > > > > > > > > > > > > > > > > -- > > > O. Hartmann > > > > > > Ich widerspreche der Nutzung oder Übermittlung meiner Daten für > > > Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). > > > > > > -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpLnkgx1UzK0.pgp Description: OpenPGP digital signature
Re: Makefile show all flags
blubee blubeeme wrote: > When porting software FreeBSD has a lot of internal makefiles that gets > pulled in that setup the build environment: /usr/ports/Mk/* > > Is there a way to print out the env during the make process so that I can > see what knobs, switches and flags were set before the build is run? Is this any use? make -dA It's pretty verbose. I'd suggest running it through "script" or redirecting stderr to a file! cheers, jamie ___ 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: [PATCH] Document powl and tgammal kludges
On 9 Dec 2017, at 02:02, Steve Kargl wrote: > > The following patch documents the remaining kludges that > theraven@ committed in r255294 on 2013-09-06. I have > cleaned up all of the others, but powl and tgammal remain. > ngie@ seems to have documented the existence of powl with > r290605, but did not document the rather poor numerical > accuracy of the result. tgammal remains undocumented. As it > is unlikely that theraven@ will document the nature of his > kludge nor the existence of tgammal, I have have prepared > a patch that documents the expected numerical accuracy in BUGS > sections, and have also documented tgammal. Thanks, committed in r326748. -Dimitry signature.asc Description: Message signed with OpenPGP
Re: [PATCH] Document powl and tgammal kludges
On Sun, Dec 10, 2017 at 05:44:33PM +0100, Dimitry Andric wrote: > On 9 Dec 2017, at 02:02, Steve Kargl > wrote: > > > > The following patch documents the remaining kludges that > > theraven@ committed in r255294 on 2013-09-06. I have > > cleaned up all of the others, but powl and tgammal remain. > > ngie@ seems to have documented the existence of powl with > > r290605, but did not document the rather poor numerical > > accuracy of the result. tgammal remains undocumented. As it > > is unlikely that theraven@ will document the nature of his > > kludge nor the existence of tgammal, I have have prepared > > a patch that documents the expected numerical accuracy in BUGS > > sections, and have also documented tgammal. > > Thanks, committed in r326748. > Thanks for the quick commit. -- Steve ___ 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: r326734: serial console fails: boot stuck at: Consoles: internal video/keyboard
Am Sun, 10 Dec 2017 13:54:06 +0100 "O. Hartmann" schrieb: > Am Sun, 10 Dec 2017 11:14:51 +0100 > "O. Hartmann" schrieb: > > > Am Sat, 9 Dec 2017 19:10:03 -0700 > > Warner Losh schrieb: > > > > > On Sat, Dec 9, 2017 at 6:35 PM, O. Hartmann > > > wrote: > > [schnipp] > > > > > > > > > > I'm with you on this. I'm just trying to figure out what, exactly, I need > > > to try to setup since this isn't quite my env. > > > > I have to wait until my box has built r326550 ... > > I just built r326550, installed the usual way without changes the NanoBSD > image and it > worked! > [...] r326583 works, too, r32684 has a compilation failure due to sys/geom/eli/g_eli_hmac.c -- O. Hartmann Ich widerspreche der Nutzung oder Übermittlung meiner Daten für Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG). pgpgvZiexZ2Ny.pgp Description: OpenPGP digital signature
