Re: Problem (re)building graphics/drm-61-kmod via PORTS_MODULES+=
Or maybe the port just insists on building linuxkpi_video: --- video_kmod.o
---
cc: error: no such include directory:
'/usr/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.92_1/linuxkpi/dummy/include'
[-Werror,-Wmissing-include-dirs]
--- aperture.o ---
cc: error: no such include directory:
'/usr/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.92_1/linuxkpi/dummy/include'
[-Werror,-Wmissing-include-dirs]
--- hdmi.o ---
cc: error: no such include directory:
'/usr/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.92_1/linuxkpi/dummy/include'
[-Werror,-Wmissing-include-dirs]
--- aperture.o ---
*** [aperture.o] Error code 1
make[1]: stopped making "all" in
/usr/ports/graphics/drm-61-kmod/work/drm-kmod-drm_v6.1.92_1/linuxkpi_video
. As I said, this happens even after this problem was supposedly fixed.
With the master branch of drm-kmod, I can just skip building linuxkpi_video
and everything will be fine.
On Fri, Oct 25, 2024 at 6:20 PM Oleg Lelchuk wrote:
> Building either linuxkpi or linuxkpi_video from
> https://github.com/freebsd/drm-kmod.git is not necessary if I want
> functioning intel graphics, but the port version insists on building those
> unnecessary things.
>
> On Fri, Oct 25, 2024 at 6:10 PM Oleg Lelchuk
> wrote:
>
>> With clang 19, I can build i1915kms from
>> https://github.com/freebsd/drm-kmod.git and I won't encounter any
>> issues. However, with the port version of drm-61-kmod, I would still
>> encounter an error. I think this happens because the port wants to build
>> stuff in the linuxkpi_video directory, but with the master branch of
>> github.com/freebsd/drm-kmod.git, I can just skip building linuxkpi_video
>> and everything will be fine. This situation was observed after
>> https://github.com/freebsd/drm-kmod/commit/5b2279ae2a59b653a3a553a8a8399e5e89bb2b90
>> commit was added and after
>> https://cgit.freebsd.org/ports/commit/?id=a247eb9392542aeb11dc6d13778b59bb4bce2d19
>> commit was added.
>>
>> On Fri, Oct 25, 2024 at 6:23 AM David Wolfskill
>> wrote:
>>
>>> On Fri, Oct 25, 2024 at 09:20:16AM +0200, Robert Clausecker wrote:
>>> > Hi David,
>>> > ...
>>> > The same issue was reported in another thread. Try this workaround:
>>>
>>> Aye; saw that, tried it, and it works for me (modulo MUA-mangling of
>>> whitespace).
>>>
>>> Here's a representation of what I used:
>>>
>>> diff --git a/graphics/drm-61-kmod/Makefile
>>> b/graphics/drm-61-kmod/Makefile
>>> index 6db2f255..596cdb20d13b 100644
>>> --- a/graphics/drm-61-kmod/Makefile
>>> +++ b/graphics/drm-61-kmod/Makefile
>>> @@ -49,6 +49,8 @@ PLIST_SUB+= I915="@comment "
>>>
>>> MAKE_ENV+= MAKEOBJDIRPREFIX=${WRKSRC}/obj
>>>
>>> +post-patch:
>>> + ${MKDIR} ${WRKSRC}/linuxkpi/dummy/include
>>> pre-build:
>>> ${MKDIR} ${WRKSRC}/obj
>>> (cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE_CMD} obj)
>>>
>>>
>>>
>>> Thanks!
>>>
>>> Peace,
>>> david
>>> --
>>> David H. Wolfskill da...@catwhisker.org
>>> It has been said that history repeats itself. This is perhaps not quite
>>> correct; it merely rhymes. -- Theodor Reik
>>>
>>> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>>>
>>
Re: Problem (re)building graphics/drm-61-kmod via PORTS_MODULES+=
Building either linuxkpi or linuxkpi_video from
https://github.com/freebsd/drm-kmod.git is not necessary if I want
functioning intel graphics, but the port version insists on building those
unnecessary things.
On Fri, Oct 25, 2024 at 6:10 PM Oleg Lelchuk wrote:
> With clang 19, I can build i1915kms from
> https://github.com/freebsd/drm-kmod.git and I won't encounter any issues.
> However, with the port version of drm-61-kmod, I would still encounter an
> error. I think this happens because the port wants to build stuff in the
> linuxkpi_video directory, but with the master branch of
> github.com/freebsd/drm-kmod.git, I can just skip building linuxkpi_video
> and everything will be fine. This situation was observed after
> https://github.com/freebsd/drm-kmod/commit/5b2279ae2a59b653a3a553a8a8399e5e89bb2b90
> commit was added and after
> https://cgit.freebsd.org/ports/commit/?id=a247eb9392542aeb11dc6d13778b59bb4bce2d19
> commit was added.
>
> On Fri, Oct 25, 2024 at 6:23 AM David Wolfskill
> wrote:
>
>> On Fri, Oct 25, 2024 at 09:20:16AM +0200, Robert Clausecker wrote:
>> > Hi David,
>> > ...
>> > The same issue was reported in another thread. Try this workaround:
>>
>> Aye; saw that, tried it, and it works for me (modulo MUA-mangling of
>> whitespace).
>>
>> Here's a representation of what I used:
>>
>> diff --git a/graphics/drm-61-kmod/Makefile b/graphics/drm-61-kmod/Makefile
>> index 6db2f255..596cdb20d13b 100644
>> --- a/graphics/drm-61-kmod/Makefile
>> +++ b/graphics/drm-61-kmod/Makefile
>> @@ -49,6 +49,8 @@ PLIST_SUB+= I915="@comment "
>>
>> MAKE_ENV+= MAKEOBJDIRPREFIX=${WRKSRC}/obj
>>
>> +post-patch:
>> + ${MKDIR} ${WRKSRC}/linuxkpi/dummy/include
>> pre-build:
>> ${MKDIR} ${WRKSRC}/obj
>> (cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE_CMD} obj)
>>
>>
>>
>> Thanks!
>>
>> Peace,
>> david
>> --
>> David H. Wolfskill da...@catwhisker.org
>> It has been said that history repeats itself. This is perhaps not quite
>> correct; it merely rhymes. -- Theodor Reik
>>
>> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>>
>
Re: Problem (re)building graphics/drm-61-kmod via PORTS_MODULES+=
With clang 19, I can build i1915kms from
https://github.com/freebsd/drm-kmod.git and I won't encounter any issues.
However, with the port version of drm-61-kmod, I would still encounter an
error. I think this happens because the port wants to build stuff in the
linuxkpi_video directory, but with the master branch of
github.com/freebsd/drm-kmod.git, I can just skip building linuxkpi_video
and everything will be fine. This situation was observed after
https://github.com/freebsd/drm-kmod/commit/5b2279ae2a59b653a3a553a8a8399e5e89bb2b90
commit was added and after
https://cgit.freebsd.org/ports/commit/?id=a247eb9392542aeb11dc6d13778b59bb4bce2d19
commit was added.
On Fri, Oct 25, 2024 at 6:23 AM David Wolfskill
wrote:
> On Fri, Oct 25, 2024 at 09:20:16AM +0200, Robert Clausecker wrote:
> > Hi David,
> > ...
> > The same issue was reported in another thread. Try this workaround:
>
> Aye; saw that, tried it, and it works for me (modulo MUA-mangling of
> whitespace).
>
> Here's a representation of what I used:
>
> diff --git a/graphics/drm-61-kmod/Makefile b/graphics/drm-61-kmod/Makefile
> index 6db2f255..596cdb20d13b 100644
> --- a/graphics/drm-61-kmod/Makefile
> +++ b/graphics/drm-61-kmod/Makefile
> @@ -49,6 +49,8 @@ PLIST_SUB+= I915="@comment "
>
> MAKE_ENV+= MAKEOBJDIRPREFIX=${WRKSRC}/obj
>
> +post-patch:
> + ${MKDIR} ${WRKSRC}/linuxkpi/dummy/include
> pre-build:
> ${MKDIR} ${WRKSRC}/obj
> (cd ${WRKSRC} ; ${SETENV} ${MAKE_ENV} ${MAKE_CMD} obj)
>
>
>
> Thanks!
>
> Peace,
> david
> --
> David H. Wolfskill da...@catwhisker.org
> It has been said that history repeats itself. This is perhaps not quite
> correct; it merely rhymes. -- Theodor Reik
>
> See https://www.catwhisker.org/~david/publickey.gpg for my public key.
>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I am still using the same workaround: instead of rv =
efi_global_getenv("ConOut", buf, &sz); I have rv =
efi_global_getenv("ConIn", buf, &sz);
Happy New Year!
On Mon, May 15, 2023 at 8:41 AM Oleg Lelchuk wrote:
> I got it.
>
> On Mon, May 15, 2023, 8:32 AM Toomas Soome wrote:
>
>>
>>
>> On 15. May 2023, at 15:22, Oleg Lelchuk wrote:
>>
>> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
>> in the previous email message... I find it a bit surprising that I only had
>> to make one tiny change to the source code of stand to make the graphical
>> logo appear, to start playing with the EFI resolution, and etc.
>>
>>
>> The font size/resolution is difficult topic. The implementation itself
>> can choose “good enough” variant and then some people are happy and some
>> people are unhappy.
>>
>> The current loader UI is built on terminal dimensions (which depend on
>> glyph size and resolution), and there the traditional assumption is that we
>> have 80x24 terminal. With different fonts and depending on how much screen
>> space we want to leave unused, we can get different dimensions for terminal.
>>
>> And since there is quite a variation of displays, the challenge is to get
>> decent enough visual on most commonly used displays - so there can be
>> pressure to use fixed resolution etc. And this is also the reason, why you
>> see very simple boot screens with something like spinning wheel on some
>> other systems.
>>
>> rgds,
>> toomas
>>
>>
>> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk wrote:
>>
>>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced
>>> ConOut with ConIn in this line: rv = efi_global_getenv("ConIn", buf, &sz);
>>> . Now I am able to see the beautiful graphical logo in the efi boot menu!
>>> But why are the boot menu and the logo shown in the top left corner of my
>>> computer screen? My monitor is 1080p and the setting
>>> efi_max_resolution=1080p in loader.conf only affects what happens after the
>>> kernel starts booting up, but it doesn't affect what happens before it: the
>>> boot menu and the logo remain in the top left corner of the screen. Why is
>>> this the case? You can see the photo in the provided attachment... And
>>> thank you, guys, for your work!
>>>
>>> On Sat, May 13, 2023 at 9:35 AM Warner Losh wrote:
>>>
>>>>
>>>>
>>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk
>>>> wrote:
>>>>
>>>>> I've been reading the documentation for loader.efi and it says this:
>>>>> "If there is no ConOut variable, both serial and video are attempted.
>>>>> loader.efi uses the "efi" console for the video (which may or may
>>>>> not
>>>>> work) and "comconsole" for the serial on COM1 at the default baud
>>>>> rate.
>>>>> The kernel will use a dual console, with the video console
>>>>> primary if a
>>>>> UEFI graphics device is detected, or the serial console as
>>>>> primary if
>>>>> not."
>>>>> I find this language confusing because I don't know what is meant by
>>>>> "a UEFI graphics device". In my situation, is my Intel Integrated Graphics
>>>>> card an UEFI graphics device? Does it mean that once i915kms is loaded, I
>>>>> no longer deal with UEFI graphics? I think lots of people whose native
>>>>> language is English will find the documentation describing loader.efi
>>>>> confusing. The documentation page also mentions this: "BUGS
>>>>> Systems that do not have a ConOut variable set are not conformant
>>>>> with
>>>>> the standard, and likely have unexpected results." But I think
>>>>> you guys already implied that the UEFI specification doesn't mandate
>>>>> having
>>>>> such a variable.
>>>>>
>>>>
>>>> That's unclear. The standard refers to it many times. Earlier versions
>>>> especially. It doesn't say it's optional, unlike some other variables. Yet
>>>> later versions don't say it's mandatory. I've yet to own or use a system
>>>> without it... such systems exist but they are quite new...
>>>>
>>>> Warner
>>>>
>>>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk
>>>>> wrote:
>>>>>
>>>>>> I got it. Thanks.
>>>>>>
>>>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote:
>>>>>>
>>>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk
>>>>>>> wrote:
>>>>>>> >
>>>>>>> > I don't want to go through the hassle of filling a bug with my
>>>>>>> vendor. I will just wait for you, guys, to update the stand
>>>>>>> implementation.
>>>>>>> Thank you for explaining to me what causes this issue.
>>>>>>>
>>>>>>> This issue is tracked in PR 265980 if you want to follow it.
>>>>>>> https://bugs.freebsd.org/265980
>>>>>>>
>>>>>>
>>
Re: 'teken_utf8_bytes_to_codepoint' [-Wunused-function]
I typed "stty iutf8" after updating to the latest world and kernel and the
backspace key still seems to erase only one byte when erasing Russian
letters. For example, I compile this program:
#include
#include
int main()
{
std::cout << "Enter something: ";
std::string sentence;
std::getline(std::cin,sentence);
std::cout << sentence << std::endl;
}
And when running the program, I type something using Russian letters,
use the backspace key to erase some letters, hit enter, and what I see
on the screen is some garbage. My LANG variable is set to C.UTF-8.
On Sun, Oct 8, 2023 at 10:00 AM Gary Jennejohn wrote:
> I just updated my current sources and did a buildworld and buildkernel.
>
> This warning was spit out, although it didn't result in buildkernel
> failing:
>
> In file included from /usr/src/sys/teken/teken.c:70:
> /usr/src/sys/teken/teken_wcwidth.h:128:1: warning: unused function
> 'teken_utf8_bytes_to_codepoint' [-Wunused-function]
> teken_utf8_bytes_to_codepoint(uint8_t bytes[4], int nbytes)
> ^
> 1 warning generated.
>
> Just FYI.
>
> --
> Gary Jennejohn
>
>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I got it.
On Mon, May 15, 2023, 8:32 AM Toomas Soome wrote:
>
>
> On 15. May 2023, at 15:22, Oleg Lelchuk wrote:
>
> Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
> in the previous email message... I find it a bit surprising that I only had
> to make one tiny change to the source code of stand to make the graphical
> logo appear, to start playing with the EFI resolution, and etc.
>
>
> The font size/resolution is difficult topic. The implementation itself can
> choose “good enough” variant and then some people are happy and some people
> are unhappy.
>
> The current loader UI is built on terminal dimensions (which depend on
> glyph size and resolution), and there the traditional assumption is that we
> have 80x24 terminal. With different fonts and depending on how much screen
> space we want to leave unused, we can get different dimensions for terminal.
>
> And since there is quite a variation of displays, the challenge is to get
> decent enough visual on most commonly used displays - so there can be
> pressure to use fixed resolution etc. And this is also the reason, why you
> see very simple boot screens with something like spinning wheel on some
> other systems.
>
> rgds,
> toomas
>
>
> On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk wrote:
>
>> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced
>> ConOut with ConIn in this line: rv = efi_global_getenv("ConIn", buf, &sz);
>> . Now I am able to see the beautiful graphical logo in the efi boot menu!
>> But why are the boot menu and the logo shown in the top left corner of my
>> computer screen? My monitor is 1080p and the setting
>> efi_max_resolution=1080p in loader.conf only affects what happens after the
>> kernel starts booting up, but it doesn't affect what happens before it: the
>> boot menu and the logo remain in the top left corner of the screen. Why is
>> this the case? You can see the photo in the provided attachment... And
>> thank you, guys, for your work!
>>
>> On Sat, May 13, 2023 at 9:35 AM Warner Losh wrote:
>>
>>>
>>>
>>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk
>>> wrote:
>>>
>>>> I've been reading the documentation for loader.efi and it says this:
>>>> "If there is no ConOut variable, both serial and video are attempted.
>>>> loader.efi uses the "efi" console for the video (which may or may
>>>> not
>>>> work) and "comconsole" for the serial on COM1 at the default baud
>>>> rate.
>>>> The kernel will use a dual console, with the video console primary
>>>> if a
>>>> UEFI graphics device is detected, or the serial console as primary
>>>> if
>>>> not."
>>>> I find this language confusing because I don't know what is meant by "a
>>>> UEFI graphics device". In my situation, is my Intel Integrated Graphics
>>>> card an UEFI graphics device? Does it mean that once i915kms is loaded, I
>>>> no longer deal with UEFI graphics? I think lots of people whose native
>>>> language is English will find the documentation describing loader.efi
>>>> confusing. The documentation page also mentions this: "BUGS
>>>> Systems that do not have a ConOut variable set are not conformant
>>>> with
>>>> the standard, and likely have unexpected results." But I think you
>>>> guys already implied that the UEFI specification doesn't mandate having
>>>> such a variable.
>>>>
>>>
>>> That's unclear. The standard refers to it many times. Earlier versions
>>> especially. It doesn't say it's optional, unlike some other variables. Yet
>>> later versions don't say it's mandatory. I've yet to own or use a system
>>> without it... such systems exist but they are quite new...
>>>
>>> Warner
>>>
>>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk
>>>> wrote:
>>>>
>>>>> I got it. Thanks.
>>>>>
>>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote:
>>>>>
>>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk
>>>>>> wrote:
>>>>>> >
>>>>>> > I don't want to go through the hassle of filling a bug with my
>>>>>> vendor. I will just wait for you, guys, to update the stand
>>>>>> implementation.
>>>>>> Thank you for explaining to me what causes this issue.
>>>>>>
>>>>>> This issue is tracked in PR 265980 if you want to follow it.
>>>>>> https://bugs.freebsd.org/265980
>>>>>>
>>>>>
>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
Adding screen.font="16×32" to loader.conf fixed that tiny issue mentioned
in the previous email message... I find it a bit surprising that I only had
to make one tiny change to the source code of stand to make the graphical
logo appear, to start playing with the EFI resolution, and etc.
On Sun, May 14, 2023, 8:58 AM Oleg Lelchuk wrote:
> Okay, so I edited /usr/src/stand/efi/loader/main.c , and I replaced ConOut
> with ConIn in this line: rv = efi_global_getenv("ConIn", buf, &sz); . Now I
> am able to see the beautiful graphical logo in the efi boot menu! But why
> are the boot menu and the logo shown in the top left corner of my computer
> screen? My monitor is 1080p and the setting efi_max_resolution=1080p in
> loader.conf only affects what happens after the kernel starts booting up,
> but it doesn't affect what happens before it: the boot menu and the logo
> remain in the top left corner of the screen. Why is this the case? You can
> see the photo in the provided attachment... And thank you, guys, for your
> work!
>
> On Sat, May 13, 2023 at 9:35 AM Warner Losh wrote:
>
>>
>>
>> On Sat, May 13, 2023, 6:26 AM Oleg Lelchuk wrote:
>>
>>> I've been reading the documentation for loader.efi and it says this: "If
>>> there is no ConOut variable, both serial and video are attempted.
>>> loader.efi uses the "efi" console for the video (which may or may
>>> not
>>> work) and "comconsole" for the serial on COM1 at the default baud
>>> rate.
>>> The kernel will use a dual console, with the video console primary
>>> if a
>>> UEFI graphics device is detected, or the serial console as primary
>>> if
>>> not."
>>> I find this language confusing because I don't know what is meant by "a
>>> UEFI graphics device". In my situation, is my Intel Integrated Graphics
>>> card an UEFI graphics device? Does it mean that once i915kms is loaded, I
>>> no longer deal with UEFI graphics? I think lots of people whose native
>>> language is English will find the documentation describing loader.efi
>>> confusing. The documentation page also mentions this: "BUGS
>>> Systems that do not have a ConOut variable set are not conformant
>>> with
>>> the standard, and likely have unexpected results." But I think you
>>> guys already implied that the UEFI specification doesn't mandate having
>>> such a variable.
>>>
>>
>> That's unclear. The standard refers to it many times. Earlier versions
>> especially. It doesn't say it's optional, unlike some other variables. Yet
>> later versions don't say it's mandatory. I've yet to own or use a system
>> without it... such systems exist but they are quite new...
>>
>> Warner
>>
>> On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk
>>> wrote:
>>>
>>>> I got it. Thanks.
>>>>
>>>> On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote:
>>>>
>>>>> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk
>>>>> wrote:
>>>>> >
>>>>> > I don't want to go through the hassle of filling a bug with my
>>>>> vendor. I will just wait for you, guys, to update the stand
>>>>> implementation.
>>>>> Thank you for explaining to me what causes this issue.
>>>>>
>>>>> This issue is tracked in PR 265980 if you want to follow it.
>>>>> https://bugs.freebsd.org/265980
>>>>>
>>>>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I've been reading the documentation for loader.efi and it says this: "If there is no ConOut variable, both serial and video are attempted. loader.efi uses the "efi" console for the video (which may or may not work) and "comconsole" for the serial on COM1 at the default baud rate. The kernel will use a dual console, with the video console primary if a UEFI graphics device is detected, or the serial console as primary if not." I find this language confusing because I don't know what is meant by "a UEFI graphics device". In my situation, is my Intel Integrated Graphics card an UEFI graphics device? Does it mean that once i915kms is loaded, I no longer deal with UEFI graphics? I think lots of people whose native language is English will find the documentation describing loader.efi confusing. The documentation page also mentions this: "BUGS Systems that do not have a ConOut variable set are not conformant with the standard, and likely have unexpected results." But I think you guys already implied that the UEFI specification doesn't mandate having such a variable. On Fri, May 12, 2023 at 7:55 PM Oleg Lelchuk wrote: > I got it. Thanks. > > On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote: > >> On Fri, 12 May 2023 at 09:26, Oleg Lelchuk wrote: >> > >> > I don't want to go through the hassle of filling a bug with my vendor. >> I will just wait for you, guys, to update the stand implementation. Thank >> you for explaining to me what causes this issue. >> >> This issue is tracked in PR 265980 if you want to follow it. >> https://bugs.freebsd.org/265980 >> >
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I got it. Thanks. On Fri, May 12, 2023 at 7:45 PM Ed Maste wrote: > On Fri, 12 May 2023 at 09:26, Oleg Lelchuk wrote: > > > > I don't want to go through the hassle of filling a bug with my vendor. I > will just wait for you, guys, to update the stand implementation. Thank you > for explaining to me what causes this issue. > > This issue is tracked in PR 265980 if you want to follow it. > https://bugs.freebsd.org/265980 >
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I don't want to go through the hassle of filling a bug with my vendor. I will just wait for you, guys, to update the stand implementation. Thank you for explaining to me what causes this issue. On Fri, May 12, 2023, 8:02 AM Toomas Soome wrote: > > > On 12. May 2023, at 14:45, Oleg Lelchuk wrote: > > I run the latest uefi bios firmware available for my motherboard. So, in > your opinion, there is something wrong with it? Is this problem somehow > related to this problem: > https://www.mail-archive.com/stable@freebsd.org/msg00235.html ? As I > mentioned earlier, my motherboard is Asus Prime 7590-P Wifi. The PC is > connected to my monitor and there is absolutely nothing connected to the > PC's serial port. If there is a bug in my motherboard's UEFI > implementation, is it possible to add code to the stand implementation of > FreeBSD that will find a way around this bug?.. Please think of > something... I definitely want to see the graphical orb logo in the FreeBSD > boot menu! > > > The UEFI specification does describe those variables, but I have not seen > them noted to be required to be present. They *usually* are present. So, if > you have latest firmware and have option to file the bug with vendor, it is > good idea to do so. > > Anyhow, as Warner already wrote, we actually have option to check ConIn > for presence of serial port too, so we should do that - it will just take a > bit of time. > > rgds, > toomas > > On Fri, May 12, 2023, 6:55 AM Toomas Soome wrote: > >> >> >> On 12. May 2023, at 13:41, Oleg Lelchuk wrote: >> >> There is only one monitor connected to my PC. >> >> >> Multiple monitors is definitely not an issue in your case (the missing >> ConOut and the decision chain based on it is the root cause). What you can >> do, is to check if there is firmware update from system vendor, that may >> fix the missing ConOut. >> >> rgds, >> toomas >> >> >> >> On Fri, May 12, 2023, 1:06 AM Emmanuel Vadot >> wrote: >> >>> On Fri, 12 May 2023 00:20:47 +0300 >>> Toomas Soome wrote: >>> >>> > >>> > >>> > > On 12. May 2023, at 00:11, Oleg Lelchuk >>> wrote: >>> > > >>> > > Guys, there is something that I find puzzling. Why doesn't the EFI >>> boot loader want to display the graphical orb logo in its boot menu on an >>> Asus Prime 7590-P motherboard? Is there something quirky about this >>> particular motherboard that forces the FreeBSD EFI loader to display the >>> old style ASCII orb logo in its boot menu? Please explain to me the cause >>> of this problem and if possible, give me a solution to it. >>> > >>> > There can be two reasons. One is that resolution is low and there is >>> no space to put the image on. Second one is that the screen is forced to >>> use ?text? mode, which happens when system has configured to have serial >>> console (redirection). >>> > >>> > rgds, >>> > toomas >>> >>> There is a third reason : you have multiple screens and EFI firmware >>> output on all of them. Never took the time to dig into this one. >>> >>> -- >>> Emmanuel Vadot >>> >> >> >
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I run the latest uefi bios firmware available for my motherboard. So, in your opinion, there is something wrong with it? Is this problem somehow related to this problem: https://www.mail-archive.com/stable@freebsd.org/msg00235.html ? As I mentioned earlier, my motherboard is Asus Prime 7590-P Wifi. The PC is connected to my monitor and there is absolutely nothing connected to the PC's serial port. If there is a bug in my motherboard's UEFI implementation, is it possible to add code to the stand implementation of FreeBSD that will find a way around this bug?.. Please think of something... I definitely want to see the graphical orb logo in the FreeBSD boot menu! On Fri, May 12, 2023, 6:55 AM Toomas Soome wrote: > > > On 12. May 2023, at 13:41, Oleg Lelchuk wrote: > > There is only one monitor connected to my PC. > > > Multiple monitors is definitely not an issue in your case (the missing > ConOut and the decision chain based on it is the root cause). What you can > do, is to check if there is firmware update from system vendor, that may > fix the missing ConOut. > > rgds, > toomas > > > > On Fri, May 12, 2023, 1:06 AM Emmanuel Vadot > wrote: > >> On Fri, 12 May 2023 00:20:47 +0300 >> Toomas Soome wrote: >> >> > >> > >> > > On 12. May 2023, at 00:11, Oleg Lelchuk >> wrote: >> > > >> > > Guys, there is something that I find puzzling. Why doesn't the EFI >> boot loader want to display the graphical orb logo in its boot menu on an >> Asus Prime 7590-P motherboard? Is there something quirky about this >> particular motherboard that forces the FreeBSD EFI loader to display the >> old style ASCII orb logo in its boot menu? Please explain to me the cause >> of this problem and if possible, give me a solution to it. >> > >> > There can be two reasons. One is that resolution is low and there is no >> space to put the image on. Second one is that the screen is forced to use >> ?text? mode, which happens when system has configured to have serial >> console (redirection). >> > >> > rgds, >> > toomas >> >> There is a third reason : you have multiple screens and EFI firmware >> output on all of them. Never took the time to dig into this one. >> >> -- >> Emmanuel Vadot >> > >
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
There is only one monitor connected to my PC. On Fri, May 12, 2023, 1:06 AM Emmanuel Vadot wrote: > On Fri, 12 May 2023 00:20:47 +0300 > Toomas Soome wrote: > > > > > > > > On 12. May 2023, at 00:11, Oleg Lelchuk wrote: > > > > > > Guys, there is something that I find puzzling. Why doesn't the EFI > boot loader want to display the graphical orb logo in its boot menu on an > Asus Prime 7590-P motherboard? Is there something quirky about this > particular motherboard that forces the FreeBSD EFI loader to display the > old style ASCII orb logo in its boot menu? Please explain to me the cause > of this problem and if possible, give me a solution to it. > > > > There can be two reasons. One is that resolution is low and there is no > space to put the image on. Second one is that the screen is forced to use > ?text? mode, which happens when system has configured to have serial > console (redirection). > > > > rgds, > > toomas > > There is a third reason : you have multiple screens and EFI firmware > output on all of them. Never took the time to dig into this one. > > -- > Emmanuel Vadot >
Fwd: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
-- Forwarded message - From: Oleg Lelchuk Date: Thu, May 11, 2023 at 10:19 PM Subject: Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard? To: Warner Losh I see this output: efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn : PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x14,0x0)/USB(0x2,0x0) On Thu, May 11, 2023 at 9:54 PM Warner Losh wrote: > No ConOut variable -> we assume the widest possible amount of hardware. > which is why you see efi comconsole as the console. > > Can you send me the output of > efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > > It should look like: > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConIn > : > PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x0),/PciRoot(0x0)/Pci(0x1f,0x0)/Acpi(PNP0303,0x1) > > I've been putting-off falling back to ConIn to determine the default > console device. I'd like > to collect a few more examples before I start. > > Warner > > On Thu, May 11, 2023 at 4:49 PM Oleg Lelchuk > wrote: > >> Any, by the way, "show console" also shows "efi,comconsole", just like >> "kenv | grep efi" does. >> >> On Thu, May 11, 2023 at 6:40 PM Oleg Lelchuk >> wrote: >> >>> My ESP partition has EFI/BOOT/BOOTX64.efi . I copied /boot/loader.efi to >>> EFI/BOOT/BOOTX64.efi when I compiled stand after this commit was added to >>> the main branch: >>> https://cgit.freebsd.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 >>> . >>> I get this output: >>> kenv | grep efi >>> console="efi,comconsole" >>> efi-version="2.70" >>> efi_com_port="0" >>> efi_com_speed="0" >>> efi_max_resolution="1x1" >>> entropy_efi_seed="YES" >>> loader.efi="1" >>> >>> And in the attachment, you can see the output from the loader prompt. >>> >>> >>> On Thu, May 11, 2023 at 6:20 PM Toomas Soome wrote: >>> >>>> >>>> >>>> On 12. May 2023, at 01:09, Oleg Lelchuk wrote: >>>> >>>> kenv | grep screen produces this output: >>>> >>>> screensave_load="NO" >>>> screensave_name="green_saver" >>>> >>>> >>>> Yep, the screen is considered to be in text mode and only ascii art is >>>> used (see drawer.lua). >>>> >>>> on loader prompt, does ‘gop get’ or ‘gop list’ output anything? >>>> >>>> if gop does output reasonable data, make sure your loader.efi on ESP is >>>> up to date; if you have no ConOut and ConOutDev variables set (by >>>> firmware), older loader did default to serial port, recent loader does >>>> default to efi,comconsole (see show console on loader prompt). >>>> >>>> rgds, >>>> toomas >>>> >>>> >>>> On Thu, May 11, 2023 at 6:06 PM Toomas Soome wrote: >>>> >>>>> >>>>> >>>>> On 12. May 2023, at 00:57, Oleg Lelchuk wrote: >>>>> >>>>> kenv | grep boot shows me this: >>>>> >>>>> >>>>> Can you run kenv | grep screen ? in gfx mode, you should see >>>>> screen.depth, screen.height and screen.width >>>>> >>>>> rgds, >>>>> toomas >>>>> >>>>> >>>>> acpi_dsdt_name="/boot/acpi_dsdt.aml" >>>>> boot_verbose="YES" >>>>> bootenv_autolist="YES" >>>>> bootenvs[0]="zfs:DESKTOP/poudriere" >>>>> bootenvs_count="1" >>>>> bootfile="kernel" >>>>> cpu_microcode_name="/boot/firmware/ucode.bin" >>>>> entropy_cache_name="/boot/entropy" >>>>> entropy_cache_type="boot_entropy_cache" >>>>> if_re_name="/boot/modules/if_re.ko" >>>>> kernel_path="/boot/kernel" >>>>> kernelname="/boot/kernel/kernel" >>>>> loader_conf_dirs="/boot/loader.conf.d" >>>>> module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" >>>>> nextboot_conf="/boot/nextboot.conf" >>>>> ram_blacklist_name="/boot/blacklist.txt" >>>>> >>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
I meant to say "And", not "Any", at the start of the previous sentence. On Thu, May 11, 2023, 6:49 PM Oleg Lelchuk wrote: > Any, by the way, "show console" also shows "efi,comconsole", just like > "kenv | grep efi" does. > > On Thu, May 11, 2023 at 6:40 PM Oleg Lelchuk > wrote: > >> My ESP partition has EFI/BOOT/BOOTX64.efi . I copied /boot/loader.efi to >> EFI/BOOT/BOOTX64.efi when I compiled stand after this commit was added to >> the main branch: >> https://cgit.freebsd.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 >> . >> I get this output: >> kenv | grep efi >> console="efi,comconsole" >> efi-version="2.70" >> efi_com_port="0" >> efi_com_speed="0" >> efi_max_resolution="1x1" >> entropy_efi_seed="YES" >> loader.efi="1" >> >> And in the attachment, you can see the output from the loader prompt. >> >> >> On Thu, May 11, 2023 at 6:20 PM Toomas Soome wrote: >> >>> >>> >>> On 12. May 2023, at 01:09, Oleg Lelchuk wrote: >>> >>> kenv | grep screen produces this output: >>> >>> screensave_load="NO" >>> screensave_name="green_saver" >>> >>> >>> Yep, the screen is considered to be in text mode and only ascii art is >>> used (see drawer.lua). >>> >>> on loader prompt, does ‘gop get’ or ‘gop list’ output anything? >>> >>> if gop does output reasonable data, make sure your loader.efi on ESP is >>> up to date; if you have no ConOut and ConOutDev variables set (by >>> firmware), older loader did default to serial port, recent loader does >>> default to efi,comconsole (see show console on loader prompt). >>> >>> rgds, >>> toomas >>> >>> >>> On Thu, May 11, 2023 at 6:06 PM Toomas Soome wrote: >>> >>>> >>>> >>>> On 12. May 2023, at 00:57, Oleg Lelchuk wrote: >>>> >>>> kenv | grep boot shows me this: >>>> >>>> >>>> Can you run kenv | grep screen ? in gfx mode, you should see >>>> screen.depth, screen.height and screen.width >>>> >>>> rgds, >>>> toomas >>>> >>>> >>>> acpi_dsdt_name="/boot/acpi_dsdt.aml" >>>> boot_verbose="YES" >>>> bootenv_autolist="YES" >>>> bootenvs[0]="zfs:DESKTOP/poudriere" >>>> bootenvs_count="1" >>>> bootfile="kernel" >>>> cpu_microcode_name="/boot/firmware/ucode.bin" >>>> entropy_cache_name="/boot/entropy" >>>> entropy_cache_type="boot_entropy_cache" >>>> if_re_name="/boot/modules/if_re.ko" >>>> kernel_path="/boot/kernel" >>>> kernelname="/boot/kernel/kernel" >>>> loader_conf_dirs="/boot/loader.conf.d" >>>> module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" >>>> nextboot_conf="/boot/nextboot.conf" >>>> ram_blacklist_name="/boot/blacklist.txt" >>>> >>>> The efivar command shows me: >>>> >>>> efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>> efivar: fetching 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut: No such >>>> file or directory >>>> >>>> On Thu, May 11, 2023 at 5:43 PM Warner Losh wrote: >>>> >>>>> >>>>> >>>>> On Thu, May 11, 2023 at 3:21 PM Toomas Soome wrote: >>>>> >>>>>> >>>>>> >>>>>> > On 12. May 2023, at 00:11, Oleg Lelchuk >>>>>> wrote: >>>>>> > >>>>>> > Guys, there is something that I find puzzling. Why doesn't the EFI >>>>>> boot loader want to display the graphical orb logo in its boot menu on an >>>>>> Asus Prime 7590-P motherboard? Is there something quirky about this >>>>>> particular motherboard that forces the FreeBSD EFI loader to display the >>>>>> old style ASCII orb logo in its boot menu? Please explain to me the cause >>>>>> of this problem and if possible, give me a solution to it. >>>>>> >>>>>> There can be two reasons. One is that resolution is low and there is >>>>>> no space to put the image on. Second one is that the screen is forced to >>>>>> use “text” mode, which happens when system has configured to have serial >>>>>> console (redirection). >>>>>> >>>>> >>>>> I think the latter isn't the case (based on earlier email with Oleg), >>>>> but we can be sure if he provides: >>>>> (1) kenv (to make sure boot_xxx are set, maybe via a stray loader.conf) >>>>> (2) sudo efivar --device-path >>>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>>> >>>>> It should show something like: >>>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>>> : >>>>> PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x14,0x3)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() >>>>> >>>>> if there's redirect or something like >>>>> >>>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>>> : >>>>> PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>>>> >>>>> if not. >>>>> >>>>> Warner >>>>> >>>> >>>> >>>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
Any, by the way, "show console" also shows "efi,comconsole", just like "kenv | grep efi" does. On Thu, May 11, 2023 at 6:40 PM Oleg Lelchuk wrote: > My ESP partition has EFI/BOOT/BOOTX64.efi . I copied /boot/loader.efi to > EFI/BOOT/BOOTX64.efi when I compiled stand after this commit was added to > the main branch: > https://cgit.freebsd.org/src/commit/?id=c16e08e5f324aa119c85e10eaabacbd2abdb40e0 > . > I get this output: > kenv | grep efi > console="efi,comconsole" > efi-version="2.70" > efi_com_port="0" > efi_com_speed="0" > efi_max_resolution="1x1" > entropy_efi_seed="YES" > loader.efi="1" > > And in the attachment, you can see the output from the loader prompt. > > > On Thu, May 11, 2023 at 6:20 PM Toomas Soome wrote: > >> >> >> On 12. May 2023, at 01:09, Oleg Lelchuk wrote: >> >> kenv | grep screen produces this output: >> >> screensave_load="NO" >> screensave_name="green_saver" >> >> >> Yep, the screen is considered to be in text mode and only ascii art is >> used (see drawer.lua). >> >> on loader prompt, does ‘gop get’ or ‘gop list’ output anything? >> >> if gop does output reasonable data, make sure your loader.efi on ESP is >> up to date; if you have no ConOut and ConOutDev variables set (by >> firmware), older loader did default to serial port, recent loader does >> default to efi,comconsole (see show console on loader prompt). >> >> rgds, >> toomas >> >> >> On Thu, May 11, 2023 at 6:06 PM Toomas Soome wrote: >> >>> >>> >>> On 12. May 2023, at 00:57, Oleg Lelchuk wrote: >>> >>> kenv | grep boot shows me this: >>> >>> >>> Can you run kenv | grep screen ? in gfx mode, you should see >>> screen.depth, screen.height and screen.width >>> >>> rgds, >>> toomas >>> >>> >>> acpi_dsdt_name="/boot/acpi_dsdt.aml" >>> boot_verbose="YES" >>> bootenv_autolist="YES" >>> bootenvs[0]="zfs:DESKTOP/poudriere" >>> bootenvs_count="1" >>> bootfile="kernel" >>> cpu_microcode_name="/boot/firmware/ucode.bin" >>> entropy_cache_name="/boot/entropy" >>> entropy_cache_type="boot_entropy_cache" >>> if_re_name="/boot/modules/if_re.ko" >>> kernel_path="/boot/kernel" >>> kernelname="/boot/kernel/kernel" >>> loader_conf_dirs="/boot/loader.conf.d" >>> module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" >>> nextboot_conf="/boot/nextboot.conf" >>> ram_blacklist_name="/boot/blacklist.txt" >>> >>> The efivar command shows me: >>> >>> efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>> efivar: fetching 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut: No such >>> file or directory >>> >>> On Thu, May 11, 2023 at 5:43 PM Warner Losh wrote: >>> >>>> >>>> >>>> On Thu, May 11, 2023 at 3:21 PM Toomas Soome wrote: >>>> >>>>> >>>>> >>>>> > On 12. May 2023, at 00:11, Oleg Lelchuk >>>>> wrote: >>>>> > >>>>> > Guys, there is something that I find puzzling. Why doesn't the EFI >>>>> boot loader want to display the graphical orb logo in its boot menu on an >>>>> Asus Prime 7590-P motherboard? Is there something quirky about this >>>>> particular motherboard that forces the FreeBSD EFI loader to display the >>>>> old style ASCII orb logo in its boot menu? Please explain to me the cause >>>>> of this problem and if possible, give me a solution to it. >>>>> >>>>> There can be two reasons. One is that resolution is low and there is >>>>> no space to put the image on. Second one is that the screen is forced to >>>>> use “text” mode, which happens when system has configured to have serial >>>>> console (redirection). >>>>> >>>> >>>> I think the latter isn't the case (based on earlier email with Oleg), >>>> but we can be sure if he provides: >>>> (1) kenv (to make sure boot_xxx are set, maybe via a stray loader.conf) >>>> (2) sudo efivar --device-path >>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>> >>>> It should show something like: >>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>> : >>>> PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x14,0x3)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() >>>> >>>> if there's redirect or something like >>>> >>>> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >>>> : >>>> PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >>>> >>>> if not. >>>> >>>> Warner >>>> >>> >>> >>
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
kenv | grep screen produces this output: screensave_load="NO" screensave_name="green_saver" On Thu, May 11, 2023 at 6:06 PM Toomas Soome wrote: > > > On 12. May 2023, at 00:57, Oleg Lelchuk wrote: > > kenv | grep boot shows me this: > > > Can you run kenv | grep screen ? in gfx mode, you should see screen.depth, > screen.height and screen.width > > rgds, > toomas > > > acpi_dsdt_name="/boot/acpi_dsdt.aml" > boot_verbose="YES" > bootenv_autolist="YES" > bootenvs[0]="zfs:DESKTOP/poudriere" > bootenvs_count="1" > bootfile="kernel" > cpu_microcode_name="/boot/firmware/ucode.bin" > entropy_cache_name="/boot/entropy" > entropy_cache_type="boot_entropy_cache" > if_re_name="/boot/modules/if_re.ko" > kernel_path="/boot/kernel" > kernelname="/boot/kernel/kernel" > loader_conf_dirs="/boot/loader.conf.d" > module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" > nextboot_conf="/boot/nextboot.conf" > ram_blacklist_name="/boot/blacklist.txt" > > The efivar command shows me: > > efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > efivar: fetching 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut: No such file > or directory > > On Thu, May 11, 2023 at 5:43 PM Warner Losh wrote: > >> >> >> On Thu, May 11, 2023 at 3:21 PM Toomas Soome wrote: >> >>> >>> >>> > On 12. May 2023, at 00:11, Oleg Lelchuk wrote: >>> > >>> > Guys, there is something that I find puzzling. Why doesn't the EFI >>> boot loader want to display the graphical orb logo in its boot menu on an >>> Asus Prime 7590-P motherboard? Is there something quirky about this >>> particular motherboard that forces the FreeBSD EFI loader to display the >>> old style ASCII orb logo in its boot menu? Please explain to me the cause >>> of this problem and if possible, give me a solution to it. >>> >>> There can be two reasons. One is that resolution is low and there is no >>> space to put the image on. Second one is that the screen is forced to use >>> “text” mode, which happens when system has configured to have serial >>> console (redirection). >>> >> >> I think the latter isn't the case (based on earlier email with Oleg), but >> we can be sure if he provides: >> (1) kenv (to make sure boot_xxx are set, maybe via a stray loader.conf) >> (2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >> >> It should show something like: >> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >> : >> PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x14,0x3)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() >> >> if there's redirect or something like >> >> 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut >> : PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100) >> >> if not. >> >> Warner >> > >
Re: Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
kenv | grep boot shows me this: acpi_dsdt_name="/boot/acpi_dsdt.aml" boot_verbose="YES" bootenv_autolist="YES" bootenvs[0]="zfs:DESKTOP/poudriere" bootenvs_count="1" bootfile="kernel" cpu_microcode_name="/boot/firmware/ucode.bin" entropy_cache_name="/boot/entropy" entropy_cache_type="boot_entropy_cache" if_re_name="/boot/modules/if_re.ko" kernel_path="/boot/kernel" kernelname="/boot/kernel/kernel" loader_conf_dirs="/boot/loader.conf.d" module_path="/boot/kernel;/boot/modules;/boot/dtb;/boot/dtb/overlays" nextboot_conf="/boot/nextboot.conf" ram_blacklist_name="/boot/blacklist.txt" The efivar command shows me: efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut efivar: fetching 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut: No such file or directory On Thu, May 11, 2023 at 5:43 PM Warner Losh wrote: > > > On Thu, May 11, 2023 at 3:21 PM Toomas Soome wrote: > >> >> >> > On 12. May 2023, at 00:11, Oleg Lelchuk wrote: >> > >> > Guys, there is something that I find puzzling. Why doesn't the EFI boot >> loader want to display the graphical orb logo in its boot menu on an Asus >> Prime 7590-P motherboard? Is there something quirky about this particular >> motherboard that forces the FreeBSD EFI loader to display the old style >> ASCII orb logo in its boot menu? Please explain to me the cause of this >> problem and if possible, give me a solution to it. >> >> There can be two reasons. One is that resolution is low and there is no >> space to put the image on. Second one is that the screen is forced to use >> “text” mode, which happens when system has configured to have serial >> console (redirection). >> > > I think the latter isn't the case (based on earlier email with Oleg), but > we can be sure if he provides: > (1) kenv (to make sure boot_xxx are set, maybe via a stray loader.conf) > (2) sudo efivar --device-path 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > > It should show something like: > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > : > PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100),/PciRoot(0x0)/Pci(0x14,0x3)/Serial(0x1)/Uart(115200,8,N,1)/UartFlowCtrl(Hardware)/VenVt100Plus() > > if there's redirect or something like > > 8be4df61-93ca-11d2-aa0d-00e098032b8c-ConOut > : PciRoot(0x2)/Pci(0x1,0x2)/Pci(0x0,0x0)/Pci(0x0,0x0)/AcpiAdr(0x80010100) > > if not. > > Warner >
Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard?
Guys, there is something that I find puzzling. Why doesn't the EFI boot loader want to display the graphical orb logo in its boot menu on an Asus Prime 7590-P motherboard? Is there something quirky about this particular motherboard that forces the FreeBSD EFI loader to display the old style ASCII orb logo in its boot menu? Please explain to me the cause of this problem and if possible, give me a solution to it.
Re: Updating EFI boot loader results in boot hangup
Yes, Yasuhiro and I have the same error. On Sat, Aug 13, 2022, 10:09 PM Yasuhiro Kimura wrote: > From: Warner Losh > Subject: Re: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 20:01:03 -0600 > > > UFS or ZFS? > > > > Warner > > ZFS in my case. > > --- > Yasuhiro Kimura > >
Re: Updating EFI boot loader results in boot hangup
I don't understand what your command does. All I can see is that https://cgit.freebsd.org/src/commit/?id=ec9f3e776f39286ccec9915f38cca9729e6f9241 causes the error that we currently see, and the commit that precedes it https://cgit.freebsd.org/src/commit/?id=ad759c73522efb606135e2891ac03864926b80a3 causes a different kind of error. On Sat, Aug 13, 2022 at 8:58 PM Yasuhiro Kimura wrote: > From: Oleg Lelchuk > Subject: Re: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 20:28:09 -0400 > > > I can already see that commit > > > > c32dde3166922f55927764464d13f1bc9640f5f6 causes breakage, but the commit > that precedes it > > > > f197c0bf3e075286ccea32cd12023f3317474c5a doesn't cause breakage and the > system boots just fine with it. But > > the error that the c32dd commit causes is different from the error that > we see now, so maybe there is a > > possibility that one of the commits that follow it fixed the breakage, > but then yet another commit caused a > > different kind of breakage again. > > With the command `git bisect start --first-parent 9d16275c65b a69c0964625 > -- stand` > I got just same result. > > --- > Yasuhiro Kimura >
Re: Updating EFI boot loader results in boot hangup
I can already see that commit c32dde3166922f55927764464d13f1bc9640f5f6 <https://cgit.freebsd.org/src/commit/?id=c32dde3166922f55927764464d13f1bc9640f5f6> causes breakage, but the commit that precedes it f197c0bf3e075286ccea32cd12023f3317474c5a <https://cgit.freebsd.org/src/commit/?id=f197c0bf3e075286ccea32cd12023f3317474c5a> doesn't cause breakage and the system boots just fine with it. But the error that the c32dd commit causes is different from the error that we see now, so maybe there is a possibility that one of the commits that follow it fixed the breakage, but then yet another commit caused a different kind of breakage again. On Sat, Aug 13, 2022 at 7:41 PM Yasuhiro Kimura wrote: > From: Oleg Lelchuk > Subject: Re: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 19:32:16 -0400 > > > You can do make and make install in /usr/src/stand > > Thanks for letting me know. I'll try it. > > --- > Yasuhiro Kimura > >
Re: Updating EFI boot loader results in boot hangup
You can do make and make install in /usr/src/stand On Sat, Aug 13, 2022 at 7:31 PM Yasuhiro Kimura wrote: > From: Warner Losh > Subject: Re: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 16:59:55 -0600 > > > Any chance of a bisect of which revision starts to fail? > > > > Warner > > I'll try it. > > Is it possbile to build only loader.efi without doing buildworld? > I'd like to shorten the time to take for single step of bisect. > > --- > Yasuhiro Kimura >
Re: Updating EFI boot loader results in boot hangup
I experienced the same problem. I hope this bug will be fixed soon. On Sat, Aug 13, 2022 at 5:36 PM Yasuhiro Kimura wrote: > From: Yasuhiro Kimura > Subject: Updating EFI boot loader results in boot hangup > Date: Sat, 13 Aug 2022 01:54:26 +0900 (JST) > > > I made regular update of my 14-CURRENT amd64 system from > > main-n257134-a69c0964625 to main-n257316-9d16275c65b. I also updated > > EFI boot loader (/boot/efi/efi/freebsd/loader.efi) but it results in > > boot hangup as following. > > > > > https://people.freebsd.org/~yasu/FreeBSD-14-CURRENT-amd64-20220813-boot-hangup.png > > > > If I restore previous loader file (that is, loader.efi of > > main-n257134-a69c0964625 and kernel of main-n257316-9d16275c65b), then > > system boots successfully. > > I submitted the problem to FreeBSD Bugzilla. > > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=265825 > > Best Regards. > > --- > Yasuhiro Kimura > >
A kernel crash after compiling a fresh kernel
The 14-CURRENT running a fresh kernel crashes with these messages:
__curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
55 __asm("movq %%gs:%P1,%0" : "=r" (td) : "n" (offsetof(struct
pcpu,
(kgdb) #0 __curthread () at
/usr/src/sys/amd64/include/pcpu_aux.h:55
#1 dump_savectx () at /usr/src/sys/kern/kern_shutdown.c:401
#2 0x80be8ba5 in dumpsys (di=0x0)
at /usr/src/sys/x86/include/dump.h:87
#3 doadump (textdump=1) at /usr/src/sys/kern/kern_shutdown.c:430
#4 kern_reboot (howto=260) at /usr/src/sys/kern/kern_shutdown.c:537
#5 0x80be8fee in vpanic (fmt=,
ap=ap@entry=0xfe01042395a0) at
/usr/src/sys/kern/kern_shutdown.c:975
#6 0x80be8d53 in panic (fmt=)
at /usr/src/sys/kern/kern_shutdown.c:899
#7 0x810c0877 in trap_fatal (frame=0xfe0104239690, eva=0)
at /usr/src/sys/amd64/amd64/trap.c:942
#8 0x810c092b in trap_pfault (frame=0xfe0104239690,
usermode=false, signo=, ucode=)
at /usr/src/sys/amd64/amd64/trap.c:761
#9
#10 tcp_sack_output (tp=tp@entry=0xfe0187312140,
sack_bytes_rexmt=sack_bytes_rexmt@entry=0xfe010423983c)
at /usr/src/sys/netinet/tcp_sack.c:970
#11 0x80dd47a2 in tcp_default_output (tp=0xfe0187312140)
at /usr/src/sys/netinet/tcp_output.c:310
#12 0x80dcd240 in tcp_output (tp=tp@entry=0xfe0187312140)
at /usr/src/sys/netinet/tcp_var.h:407
#13 0x80dcc81a in tcp_do_segment (m=0xf80203467700,
th=0xf8001f190022, so=0xf80015d0fb40,
tp=0xfe0187312140,
drop_hdrlen=64, tlen=, iptos=0 '\000')
at /usr/src/sys/netinet/tcp_input.c:2788
#14 0x80dc8def in tcp_input_with_port (mp=,
offp=, proto=, port=port@entry
=0)
at /usr/src/sys/netinet/tcp_input.c:1397
#15 0x80dc9c8b in tcp_input (mp=0xf8011c764010, offp=0x4,
proto=-2128851986) at /usr/src/sys/netinet/tcp_input.c:1492
#16 0x80db8cd7 in ip_input (m=0x0)
at /usr/src/sys/netinet/ip_input.c:840
#17 0x80d3842f in netisr_dispatch_src (proto=1,
source=source@entry=0, m=0xf80203467700)
at /usr/src/sys/net/netisr.c:1153
#18 0x80d3878f in netisr_dispatch (proto=477511696,
m=0x811c4bee) at /usr/src/sys/net/netisr.c:1244
#19 0x80d1a7cc in ether_demux (ifp=ifp@entry=0xf80002873800,
m=0x4) at /usr/src/sys/net/if_ethersubr.c:925
#20 0x80d1be53 in ether_input_internal (ifp=0xf80002873800,
m=0x4)
at /usr/src/sys/net/if_ethersubr.c:711
#21 ether_nh_input (m=) at
/usr/src/sys/net/if_ethersubr.c:741
#22 0x80d3842f in netisr_dispatch_src (proto=proto@entry=5,
source=source@entry=0, m=m@entry=0xf80203467700)
at /usr/src/sys/net/netisr.c:1153
#23 0x80d3878f in netisr_dispatch (proto=477511696, proto@entry=5,
m=0x811c4bee, m@entry=0xf80203467700)
at /usr/src/sys/net/netisr.c:1244
#24 0x80d1ac89 in ether_input (ifp=0xf80002873800,
m=0xf80203467700) at /usr/src/sys/net/if_ethersubr.c:832
#25 0x808f41f7 in re_rxeof (sc=sc@entry=0xfe00e1cce000,
rx_npktsp=0x0) at /usr/src/sys/dev/re/if_re.c:2386
#26 0x808f1a16 in re_intr_msi (xsc=0xfe00e1cce000)
at /usr/src/sys/dev/re/if_re.c:2682
#27 0x80ba3d49 in intr_event_execute_handlers
(ie=0xf800020fde00,
p=) at /usr/src/sys/kern/kern_intr.c:1205
#28 ithread_execute_handlers (ie=0xf800020fde00, p=)
at /usr/src/sys/kern/kern_intr.c:1218
#29 ithread_loop (arg=arg@entry=0xf800020fbf80)
at /usr/src/sys/kern/kern_intr.c:1306
#30 0x80ba03e0 in fork_exit (
callout=0x80ba3ad0 ,
arg=0xf800020fbf80,
frame=0xfe0104239f40) at
/usr/src/sys/kern/kern_fork.c:1102
#31
14-CURRENT doesn't like it when kern.vt.splash_cpu is set to 1.
A 14-CURRENT system completely hangs in both the single and multi-user modes when kern.vt.splash_cpu=1. Did you guys notice it? 13-STABLE doesn't have this problem.
Re: HEADS-UP: OpenSSL 1.1.1 in 12.0
libtorrent still can't be built with the new openssl On Sat, Oct 13, 2018 at 4:40 AM Ronald Klop wrote: > On Sat, 13 Oct 2018 02:00:16 +0200, Don Lewis > wrote: > > > On 11 Oct, Don Lewis wrote: > >> On 11 Oct, Don Lewis wrote: > >>> On 11 Oct, freebsd.curr...@clogic.com.ua wrote: > On 2018-10-10 06:14, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > >> OpenSSL has been updated to version 1.1.1 as of r339270. > >> > >> It is important to rebuild third-party packages before running: > >> > >> # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > >> > >> Thank you for your patience while this work was in progress, and > >> thank > >> you to all involved for their hard work in getting things ready for > >> this > >> update. > > > > So far, I've found two ports that will no longer build. They are: > > > > net-mgmt/net-snmp > > security/opencryptoki > > > > I simply chose those that were linked to /usr/lib/libssl.so.8 where > > the > > openssl update creates libssl.so.9. There may be more I haven't found > > yet, > > > > imb > > You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to > use openssl from ports. > Anyway, I think apps from ports need to use openssl from ports. > >>> > >>> I've been doing this for a long time, but I still see a fair amount of > >>> breakage with the new base OpenSSL. I suspect that some ports are > >>> incorrectly stumbling across the new bits in base even though they > >>> shouldn't be looking there. > >> > >> security/p5-Net-SSLeay is hardwired to use base OpenSSL, so changing the > >> default version can't be done to unbreak p5-IO-Socket-SSL. > >> > >> devel/libsoup appears to allow the OpenSSL version to be set, but > >> doesn't > >> have an option for GSSAPI, so it attempts to use base GSSAPI with ports > >> OpenSSL which is not a valid combo. > >> > >> emulators/virtualbox-ose is hardwired to use base OpenSSL. > > > > I now think the problem with virtualbox-ose is not the port. Rather it > > is the fact that that the base libssl.so and the libssl.so installed by > > the security/openssl have the same shared library version number even > > though they are radically different OpenSSL versions. > > > I added this to libmap.conf: > cat /etc/libmap.conf > # $FreeBSD: head/libexec/rtld-elf/libmap.conf 338741 2018-09-18 00:25:00Z > brd $ > includedir /usr/local/etc/libmap.d > libssl.so.8 libssl.so.9 > libcrypto.so.8 libcrypto.so.9 > > This made pkg run again. And now I'm waiting for the next pkg build to > run > pkg upgrade -f and upgrade everything. > I guess that will solve all issues. > > Ronald. > ___ > 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" > ___ 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: HEADS-UP: OpenSSL 1.1.1 in 12.0
net-p2p/libtorrent also can't be built with the new openssl. On Thu, Oct 11, 2018 at 2:05 AM wrote: > On 2018-10-10 06:14, Michael Butler wrote: > > On 10/9/18 5:34 PM, Glen Barber wrote: > >> OpenSSL has been updated to version 1.1.1 as of r339270. > >> > >> It is important to rebuild third-party packages before running: > >> > >> # make -C /usr/src delete-old && make -C /usr/src delete-old-libs > >> > >> Thank you for your patience while this work was in progress, and thank > >> you to all involved for their hard work in getting things ready for > >> this > >> update. > > > > So far, I've found two ports that will no longer build. They are: > > > > net-mgmt/net-snmp > > security/opencryptoki > > > > I simply chose those that were linked to /usr/lib/libssl.so.8 where the > > openssl update creates libssl.so.9. There may be more I haven't found > > yet, > > > > imb > > You always can add DEFAULT_VERSIONS+=ssl=openssl to /etc/make.conf to > use openssl from ports. > Anyway, I think apps from ports need to use openssl from ports. > ___ > 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" > ___ 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: EFI issues
Yes, I also had the same issue until I followed the suggestions given in this email exchange. Thanks! On Sun, Jul 29, 2018 at 8:35 AM, O. Hartmann wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Am Sun, 29 Jul 2018 15:17:53 +0400 > Roman Bogorodskiy schrieb: > > > O. Hartmann wrote: > > > > > -BEGIN PGP SIGNED MESSAGE- > > > Hash: SHA512 > > > > > > Am Sun, 29 Jul 2018 12:09:58 +0400 > > > Roman Bogorodskiy schrieb: > > > > > > > O. Hartmann wrote: > > > > > > > > > -BEGIN PGP SIGNED MESSAGE- > > > > > Hash: SHA512 > > > > > > > > > > Am Sat, 28 Jul 2018 11:29:40 +0400 > > > > > Roman Bogorodskiy schrieb: > > > > > > > > > > > Hi, > > > > > > > > > > > > I have a test box that's updated to -CURRENT usually once in a > week or > > > > > > two. This box boots using UEFI. After a regular update about two > weeks > > > > > > ago it started to panic on boot frequently (not UEFI related), > but I > > > > > > could not get a crash dump because my swap partition was too > small. So I > > > > > > moved data to the backup drive, repartitioned the main drive and > boot > > > > > > again. This went fine, so I decided to upgrade to fresh -CURRENT > from > > > > > > ~Jul 27th. Booting with the new kernel went fine, but after > installworld > > > > > > machine stopped booting, and on the screen I see: > > > > > > > > > > > > FreeBSD/amd64 EFI loader, ... > > > > > > > > > > > > .. > > > > > > > > > > > > BootOrder: > > > > > > > > > > > > And then it gets stuck and nothing happens. > > > > > > > > > > > > As I already have a fresh backup, I decided that it'd be easier > to > > > > > > just re-install and copy data back over (maybe I messed up with > > > > > > repartitioning). So I've downloaded a fresh snapshot: > > > > > > > > > > > > FreeBSD-12.0-CURRENT-amd64-20180726-r336739-memstick.img > > > > > > > > > > > > And re-installed. In the installer I choose all the same > settings that > > > > > > were before: UEFI + GPT, default partition scheme it suggested > (efi > > > > > > followed by freebsd-ufs followed by freebsd-swap), just > increased the > > > > > > swap size. > > > > > > > > > > > > And the newly installed system won't boot just like a previous > one: > > > > > > > > > > > > https://people.freebsd.org/~novel/misc/freebsd_efi_lookup.jpg > > > > > > > > > > > > Is there a way to recover this? > > > > > > > > > > > > Roman Bogorodskiy > > > > > > > > > > Just curious: > > > > > > > > > > When I installed FreeBSD last time from the recent (2018-07-26) > USB flash drive > > > > > on a SSD, the freebsd-swap partition followed immediately after > the ESP and/or > > > > > freebsd-boot GPT loader partition. But in most cases I used to use > ZFS for > > > > > testing. > > > > > > > > When I reinstalled it yesterday from -CURRENT snapshot mentioned > above, > > > > in guided mode it suggested a similar partitioning schema that I use: > > > > > > > > =>40 1953525088 ada0 GPT (932G) > > > > 40 409600 1 efi (200M) > > > > 409640 1803550720 2 freebsd-ufs (860G) > > > > 1803960360 148897792 3 freebsd-swap (71G) > > > > 1952858152 666976- free - (326M) > > > > > > > > The only difference it that the freebsd-swap size was 3.5G (and > > > > therefore, freebsd-ufs is large), the order was the same. > > > > > > > > > Since I had my UEFI adventure of my own these days and received > valuable hints > > > > > from the development/maintenance team on some UEFI aspects, it > would be of > > > > > interest to know your recent hardware and, more importantly since > I see the boot > > > > > order presented in you screenshot, a dump of the efi variable > settings. Just for > > > > > curiosity. For that, you have to boot the recent USB flash drive > image with > > > > > UEFI-only, then logon as root and perform > > > > > > > > > > kldload efirt > > > > > > > > > > and then issue > > > > > > > > > > # efibootmgr -v > > > > > > > > > > In my case, it looks like > > > > > > > > > > [...] > > > > > [ohartmann]: sudo efibootmgr -v > > > > > BootCurrent: 0001 > > > > > Timeout: 3 seconds > > > > > BootOrder : 0001, 0002, 0003, 0004, 0005, > > > > > +Boot0001* FreeBSD-12 \ > > > > >HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/ > File(\efi\boot\BOOTx64.efi) > > > > > \ ada0p1:/efi/boot/BOOTx64.efi (null) > > > > > Boot0002* Hard Drive BBS(HD,,0x0) > > > > > Boot0003* CD/DVD Drive BBS(CDROM,,0x0) > > > > > Boot0004* USB BBS(USB,,0x0) > > > > > Boot0005* Network Card BBS(Network,,0x0) > > > > > Boot FreeBSD-12 > > > > > HD(1,GPT,e1460941-e2e9-11e5-b913-d0509907ef09,0x28,0x640)/ > File(\efi\boot\BOOTx64.efi) > > > > > ada0p1:/efi/boot/BOOTx64.efi (null) > > > > > > > > > > > > > > > Unreferenced Variables: > > > > > [...] > > > > > > > > > > Boot is the same as Boot0001 and is defined due to some "bug" > Warner Losh has > > > > > fixed recently, it is the same as Boot0001 > > > > > > > > M
Fwd: drm-next-kmod-4.11 and vaapi hardware acceleration
-- Forwarded message -- From: Oleg Lelchuk Date: Sat, Mar 3, 2018 at 1:12 AM Subject: Re: drm-next-kmod-4.11 and vaapi hardware acceleration To: Jan Beich Well, hopefully, this regression will be fixed soon. On Sat, Mar 3, 2018 at 12:14 AM, Jan Beich wrote: > Oleg Lelchuk writes: > > > I run 12-CURRENT-r330303. My cpu is Haswell. After compiling > > drm-next-kmod-4.11 and libva-intel-driver, I get garbled videos in both > mpv > > and vlc when the vaapi hardware acceleration is enabled. I had no such > > problem with the previous version of drm-next-kmod. Is it possible that > > libva-intel-driver-2.1 and drm-next-kmod-4.11 are not fully compatible > with > > one another? Please tell me what I should do to resolve this issue. > > See also https://github.com/FreeBSDDesktop/kms-drm/issues/32 > ___ 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"
drm-next-kmod-4.11 and vaapi hardware acceleration
I run 12-CURRENT-r330303. My cpu is Haswell. After compiling drm-next-kmod-4.11 and libva-intel-driver, I get garbled videos in both mpv and vlc when the vaapi hardware acceleration is enabled. I had no such problem with the previous version of drm-next-kmod. Is it possible that libva-intel-driver-2.1 and drm-next-kmod-4.11 are not fully compatible with one another? Please tell me what I should do to resolve this issue. ___ 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: Streaming live tv over the udp protocol causes problems
I just solved this problem! I had to tweak the tunables net.inet.udp.recvspace and kern.ipc.maxsockbuf . After setting them to a larger value, I had no more problems streaming live tv. But it's interesting that I never had to tweak those tunables on 10.3-STABLE. On Thu, Jun 2, 2016 at 5:49 PM, Oleg Lelchuk wrote: > I am a bit confused about this server/client thing. My networked tv tuner > Hdhomerun has a wired connection to my router. It has a program called > hdhomerun_config_gui. I open the program, choose a tv channel that I want > to watch, then vlc opens, but the video that starts streaming is broken. > Vlc shows me the message that the stream comes from udp://127.0.0.1:5000 > . So, in this particular case, the tv tuner is the server and my computer > is the client? If my computer is the client, then this is the output I get > from "iperf -f m -i 1 -s -u": > > Server listening on UDP port 5001 > Receiving 1470 byte datagrams > UDP buffer size: 0.04 MByte (default) > > As I said earlier, I had no problems streaming live tv on 10.3-STABLE. > > > On Thu, Jun 2, 2016 at 1:35 PM, Allan Jude wrote: > >> On 2016-06-01 23:03, Oleg Lelchuk wrote: >> > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp >> protocol, I >> > see a garbled and choppy video. This issue doesn't occur on >> 10.3-STABLE. I >> > am puzzled as to the cause of this 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" >> > >> >> Are both machines FreeBSD? >> >> Can you try running iperf in udp mode, something like this: >> >> pkg install iperf >> >> client: iperf -f m -i 1 -s -u >> server: iperf -f m -i 1 -t 20 -c -u -b 100m >> >> And give us the results >> >> -- >> Allan Jude >> ___ >> 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 >> " >> > > ___ 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: Streaming live tv over the udp protocol causes problems
I am a bit confused about this server/client thing. My networked tv tuner Hdhomerun has a wired connection to my router. It has a program called hdhomerun_config_gui. I open the program, choose a tv channel that I want to watch, then vlc opens, but the video that starts streaming is broken. Vlc shows me the message that the stream comes from udp://127.0.0.1:5000 . So, in this particular case, the tv tuner is the server and my computer is the client? If my computer is the client, then this is the output I get from "iperf -f m -i 1 -s -u": Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 0.04 MByte (default) As I said earlier, I had no problems streaming live tv on 10.3-STABLE. On Thu, Jun 2, 2016 at 1:35 PM, Allan Jude wrote: > On 2016-06-01 23:03, Oleg Lelchuk wrote: > > Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp > protocol, I > > see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. > I > > am puzzled as to the cause of this 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" > > > > Are both machines FreeBSD? > > Can you try running iperf in udp mode, something like this: > > pkg install iperf > > client: iperf -f m -i 1 -s -u > server: iperf -f m -i 1 -t 20 -c -u -b 100m > > And give us the results > > -- > Allan Jude > ___ > 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" > ___ 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"
Streaming live tv over the udp protocol causes problems
Hi. On 11-ALPHA1, when I use vlc to stream live tv over the udp protocol, I see a garbled and choppy video. This issue doesn't occur on 10.3-STABLE. I am puzzled as to the cause of this 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"
Compiling vlc-qt4 gives me an error
Hi. When I attempt to build /usr/ports/multimedia/vlc-qt4 , I get the following error: In file included from /usr/include/c++/v1/memory:616: /usr/include/c++/v1/atomic:823:1: error: expected unqualified-id kill_dependency(_Tp __y) _NOEXCEPT ^ ../include/vlc_atomic.h:45:7: note: expanded from macro 'kill_dependency' ((void)0) ^ This error occurs on 11-ALPHA1 r300997M. ___ 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"
