Re: Has anything changed from 11.2 to 12.0 in PCI MSI/MSIX path?

[Rajesh Kumar]

Thanks John. I tried building a kernel with these changes and things are
working good. I could able to boot without any tunables.

Thanks again.

On Fri, Nov 2, 2018 at 12:05 AM John Baldwin  wrote:

> On 10/30/18 1:22 AM, Rajesh Kumar wrote:
> > Hi John,
> >
> > Thanks for your updates.  I assume you are talking about having a
> unified intr_machdep.h compared to having seperate amd64 and i386 versions.
> >
> > Can you please update this thread once all changes are MFC complete or
> tag me in necessary place? So that I can give a try in my board once it's
> ready.
>
> I just committed r340016 which merges r338360 along with followup fixes to
> stable/11.
>
> > On Mon, Oct 29, 2018 at 11:08 PM John Baldwin  j...@freebsd.org>> wrote:
> >
> > On 10/25/18 10:24 AM, Rajesh Kumar wrote:
> > > Hi John,
> > >
> > > Thanks a lot. It helps. I backported the changes to 11.2 and tried
> booting in my board with success without any need for the said tunables.
> > >
> > > I see those changes are marked for MFC after 2 Weeks. But I don't
> see them still in stable/11 branch.  So, will it be taken into stable/11
> branch by any chance? If not, can the backported changes be submitted for
> review to take into stable/11 branch?
> >
> > I'm working on the MFC.  The current patch I've tested an MFC of is
> the one to
> > unify sys/x86/include/intr_machdep.h as a precursor to MFC'ing this
> change.
> >
> > > On Thu, Oct 25, 2018 at 1:17 AM John Baldwin   >>
> wrote:
> > >
> > > On 10/24/18 3:40 AM, Rajesh Kumar wrote:
> > > > Hi,
> > > >
> > > > I have a amd64 based board. When I tried to boot 11.1 (or)
> 11.2 in that, I
> > > > needed the following tunables to be set from loader prompt
> to get it booted
> > > > (otherwise machine reboots continuously).
> > > >
> > > > hw.usb.xhci.msi=0
> > > > hw.usb.xhci.msix=0
> > > > hw.pci.enable_msi=0
> > > > hw.pci.enable_msix=0
> > > >
> > > > But, when I tried with 12.0 - ALPHA4, I could able to get it
> booted without
> > > > any tunables.  So, has anything changed significantly on PCI
> MSI/MSI-X
> > > > path?
> > > >
> > > > Note: I have a forum topic with my observations about the
> issue on
> > > > 11.1/11.2 in the following thread
> > > >
> https://forums.freebsd.org/threads/freebsd-11-1-installation-fails-and-rebooting.65814/
> > > >
> > > > Let me know if you need any details.
> > >
> > > I believe this was fixed by r338360.
> > >
> > > --
> > > John Baldwin
> > >
> >
> >
> > --
> > John Baldwin
> >
>
>
> --
> John Baldwin
>
>
>
>
___
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: drm changes and updating to 12.0

[Kevin Oberman]

On Sun, Nov 4, 2018 at 12:15 PM Niclas Zeising  wrote:

> On 11/4/18 8:29 PM, Robert Huff wrote:
> >
> >   I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300
> > gpu) which will be updated from 11. to 12.0 once 12 is out
> > and the initial round of bugs are squashed.
> >   One system is being done now, to allow time to catch any major
> > problems and then plan the update process.
> >   Looking at src/UPDATING, the only thing I don't understand is the
> > whole drm-kmod change.  Is there an authoritative write-up on what's
> > going on, how to choose the right drivers for my hardware, and how to
> > do this from source without forcing a fresh install?
> >
>
> We are working on better documentation for this, but the main highlights
> are:  In most cases graphics/drm-kmod should suffice, especially on
> somewhat modern hardware.  You can also install any of the drm-*-kmod
> ports directly, if you want a specific version.  In general graphics
> hardware older than from 2013 requires drm-legacy-kmod instead.
> drm-kmod will also install drm-legacy-kmod on i386.
>
> The same drivers in drm-legacy-kmod is also available in base on 12, so
> you can use the base drivers.  This is deprecated however, and not the
> case for 13-CURRENT.
>
> You can install the drivers either from pkg, if you are using the
> GENERIC kernel, or build from ports if you have a customized kernel or
> if you are tracking for instance 12-STABLE or 13-CURRENT.
>
> If you are using drm-legacy-kmod or the base driver with AMD graphics
> cards you might also need to install xf86-video-ati-legacy rather than
> xf86-video-ati.
>
> Regards
> --
> Niclas Zeising


I'm curious where 2013 comes from. I know that Intel Sandy Bridge graphics
is supported with VAAPI acceleration by drm-stable-kmod, since it i working
on the system I am using to send this message. I bought it in 2011, the
year Sandy Bridge was introduced to production products.

In general, when in doubt, I'd try drm-stable-kmod for questionable devices
and fall back to drm-legacy-kmod it it fails. If y0ou use ports, I'd build
both paskages to make it easier to recover if drm-stable-kmod fails. Also,
be sure to make the proper adjustments to /etc/rc.conf as per the package
message.
--
Kevin Oberman, Part time kid herder and retired Network Engineer
E-mail: rkober...@gmail.com
PGP Fingerprint: D03FB98AFA78E3B78C1694B318AB39EF1B055683
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Rebecca Cran]

On Sunday, 4 November 2018 16:07:17 MST Warner Losh wrote:

> Finally, I have a /dev/efi/esp pseudo label support coded up for geom
> (along with /dev/efi/boot for the putative root device). There's some
> issues with it, so I set it aside some time ago to work on other higher
> priority things. We could assume that if there's a filesystem mounted on
> /dev/efi/esp, we should update the boot blocks there. We could, by default,
> mount it as /efi. A weaker test, though one also in keeping with tradition,
> would be to only install into /efi if it's a directory, and it's also a
> mount point. that would preserve the status quo and not even need my
> /dev/efi/esp code so would work out better from a number of assumptions
> point of view.

I wonder if we could coordinate our efforts and push to get this finished off 
in the next few months? 
I've been pushing my changes to 
https://github.com/bcran/freebsd/tree/efi-esp-generation .

-- 
Rebecca


___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Warner Losh]

On Sun, Nov 4, 2018 at 4:10 PM Rebecca Cran  wrote:

> On Sunday, 4 November 2018 15:56:25 MST Warner Losh wrote:
>
> > I think that's a really really bad idea. We should *NEVER* create them by
> > default. We are only sliding by on the coat-tails of compatibility by
> using
> > efi/boot/boot*.efi. We shouldn't use those at all, unless there's a
> > compelling reason (like BIOS bogosity) for doing so. I had no plans to
> > update or use those, at least by default. We should *ONLY* be using those
> > for *REMOVABLE* media, since that's the only place they are well defined
> in
> > the standard.
>
> Thanks, I had wrongly presumed it was in the spec for fixed storage as
> well
> given that Windows, Linux etc. creates them. Looking at the 2.7
> specification I
> can see I was wrong and agree we should only create files in efi/freebsd.
>

I don't know if I've mentioned this, but Benno registered /efi/freebsd with
the UEFI consortium, so we own everything in that directory as a result.

Warner
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Rebecca Cran]

On Sunday, 4 November 2018 15:56:25 MST Warner Losh wrote:

> I think that's a really really bad idea. We should *NEVER* create them by
> default. We are only sliding by on the coat-tails of compatibility by using
> efi/boot/boot*.efi. We shouldn't use those at all, unless there's a
> compelling reason (like BIOS bogosity) for doing so. I had no plans to
> update or use those, at least by default. We should *ONLY* be using those
> for *REMOVABLE* media, since that's the only place they are well defined in
> the standard.

Thanks, I had wrongly presumed it was in the spec for fixed storage as well 
given that Windows, Linux etc. creates them. Looking at the 2.7 specification I 
can see I was wrong and agree we should only create files in efi/freebsd.

-- 
Rebecca


___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Warner Losh]

On Sun, Nov 4, 2018 at 2:27 PM Allan Jude  wrote:

> On 2018-11-04 16:20, Rebecca Cran wrote:
> > I'm currently working on creating and updating the ESP (EFI System
> Partition)
> > for UEFI booting during installation and installworld.
> >
> > During installation, with my changes it gets mounted on /boot/efi and
> loader.efi
> > copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets
> added to
> > /etc/fstab as noauto.
> >
> > The issue comes during installworld, where we'll need to update the
> loader,
> > and I'm not sure how we should handle that.
> > If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the
> files then
> > unmount it? What should we do if NO_ROOT _is_ defined?
> >
>
> Previous to now, installworld has not updated the boot blocks. You've
> had to manually run 'gpart bootcode' to change the boot blocks.
>

That's not true. It always updated /boot/loader.


> However, those boot blocks mostly just loaded /boot/loader, which was
> updated by installworld.
>
> So I can see how this is not directly analogous.
>

I think you're mistaken. I think this is analogous. It used to be that the
boot code was basically unchanging for long periods of time. You can easily
load /boot/loader with a FreeBSD 2 era boot2 (well, off a UFS1 partition).
However, as things are changing more rapidly and as more functionality has
moved into /boot/loader, we need to update it more often. We've moved
support for ZFS into it, support for GELI into it, support for LUA and many
other things. There's no longer any 'boot blocks' at all to update with
gpart. UEFI has eliminated them by moving that functionality into the BIOS
itself.

Other systems update their files in the ESP when they upgrade. This is no
different than that as well. So from an industry perspective, there's a
bias towards updating.


> I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
> installworld randomly fobbing around in my EFI partition. Especially if,
> for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.
>

Yes. It was a huge mistake to *NOT* standardize on this back in the day
when UEFI support came in.

But we'd install it in both places (both /boot/loader*.efi and in
//EFI/FREEBSD/LOADER.EFI), so that would still work with your
rEFInd setup.

Finally, I have a /dev/efi/esp pseudo label support coded up for geom
(along with /dev/efi/boot for the putative root device). There's some
issues with it, so I set it aside some time ago to work on other higher
priority things. We could assume that if there's a filesystem mounted on
/dev/efi/esp, we should update the boot blocks there. We could, by default,
mount it as /efi. A weaker test, though one also in keeping with tradition,
would be to only install into /efi if it's a directory, and it's also a
mount point. that would preserve the status quo and not even need my
/dev/efi/esp code so would work out better from a number of assumptions
point of view.

tl;dr: EFIROOT?=/efi If ${EFIROOT} is a mount point, install loader*.efi
there.

Warner
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Warner Losh]

On Sun, Nov 4, 2018 at 2:43 PM Rebecca Cran  wrote:

> On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:
>
> > it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi
> is
> > hard one of course. But then again, it is problem only when we can not
> > setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
> > is not set up.
>
> Yes, I think we should only create efi/boot/boot{x64,ia32,aa64,arm}.efi if
> it
> doesn't already exist in which case we're likely the only OS on the system.
>

I think that's a really really bad idea. We should *NEVER* create them by
default. We are only sliding by on the coat-tails of compatibility by using
efi/boot/boot*.efi. We shouldn't use those at all, unless there's a
compelling reason (like BIOS bogosity) for doing so. I had no plans to
update or use those, at least by default. We should *ONLY* be using those
for *REMOVABLE* media, since that's the only place they are well defined in
the standard.

We should only create files in efi/freebsd and using efibootmgr(8) to point
at those. That was my end-goal and it was how to get there that tripped me
up and got me distracted from finishing things up.

Now, if people want to also create those files, to work around bogus BIOS
interpretations of the standard[*], that's fine. We shouldn't preclude
that. We maybe should have a script to do it even, but we shouldn't do it
by default. We should assume that things can be done the right way and only
enable fallbacks on an opt-in basis (and likely not part of installworld,
though I can see it is a tempting idea).

Warner

[*] I'm looking at you Supermicro
___
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: C.UTF-8 as default locale

[Yuri Pankov]

Baptiste Daroussin wrote:
> On Sun, Nov 04, 2018 at 09:35:48AM +0300, Yuri Pankov wrote:
>> Hi,
>>
>> Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
>> following entry:
>>
>> - Make C.UTF-8 the default locale (conrad, dteske(installer))
>>
>> As this sort of change is better done early, I have put togetger a
>> simple change introducing C.UTF-8 locale using the same common LC_CTYPE
>> map as other UTF-8 locales (and it's now the source of symlinks instead
>> of en_US one), and having all other components use C locale:
>>
>> https://reviews.freebsd.org/D17833
>>
>> With that in place, next step is likely to be updating 'default' entry
>> in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
>> changes to installer are likely to be not needed?
>>
> 
> 
> Hey I never thought it could be done in such an easy way! don't know why,
> I was always looking at it in a complex way, thus never started it.
> 
> Thank you very much, this looks fine to me! and that is imho a great addition

Thank you (and others) for the quick review.

I was also wondering, with this now in place, is anyone else working on
this?  Are there any known issues possibly preventing this from
happening now?



signature.asc
Description: OpenPGP digital signature

Re: UEFI: How to go about updating the ESP with loader.efi during installworld

[Oliver Pinter]

On 11/4/18, Rebecca Cran  wrote:
> On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:
>
>> it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi
>> is
>> hard one of course. But then again, it is problem only when we can not
>> setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
>> is not set up.
>
> Yes, I think we should only create efi/boot/boot{x64,ia32,aa64,arm}.efi if
> it
> doesn't already exist in which case we're likely the only OS on the system.

It's a totally working scenario to create OS specific directories on the ESP:

root@opn ~# efibootmgr -v
BootCurrent: 
Timeout : 0 seconds
BootOrder : , 0003, 0001
Boot0003* Windows Boot Manager
HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)/File(\EFI\Microsoft\Boot\bootmgfw.efi)

ada0p1:/EFI/Microsoft/Boot/bootmgfw.efi
/boot/esp//EFI/Microsoft/Boot/bootmgfw.efi
Boot* HardenedBSD 11-STABLE
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x,0x0)/HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)/File(\efi\hardenedbsd\boot1.efi)
ada0p1:/efi/hardenedbsd/boot1.efi
/boot/esp//efi/hardenedbsd/boot1.efi
Boot0001* UEFI: TOSHIBA MQ02ABF050H
PciRoot(0x0)/Pci(0x1f,0x2)/Sata(0x1,0x,0x0)/HD(1,GPT,86fcd8f6-3db7-11e8-ad9f-34e6d749b944,0x28,0x20)

VenHw(2d6447ef-3bc9-41a0-ac19-4d51d01b4ce6,20002000200020002000200020002000200020003100200053003800500054003500460054004b00)

The above is how my esp looks like. In EFI I have two entry: one for
HardenedBSD  and one for Windows. This functionality isn't yet
implemented in the installer, but it's possible to made them by hand.


>
> --
> Rebecca
>
>
> ___
> 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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Rebecca Cran]

On Sunday, 4 November 2018 14:36:13 MST Toomas Soome wrote:

> it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi is
> hard one of course. But then again, it is problem only when we can not
> setup EFI bootmanager variables ? the bootx64.efi is default when bootmgr
> is not set up.

Yes, I think we should only create efi/boot/boot{x64,ia32,aa64,arm}.efi if it 
doesn't already exist in which case we're likely the only OS on the system.

-- 
Rebecca


___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Toomas Soome]

> On 4 Nov 2018, at 23:25, Allan Jude  wrote:
> 
> On 2018-11-04 16:20, Rebecca Cran wrote:
>> I'm currently working on creating and updating the ESP (EFI System 
>> Partition) 
>> for UEFI booting during installation and installworld. 
>> 
>> During installation, with my changes it gets mounted on /boot/efi and 
>> loader.efi 
>> copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets 
>> added to 
>> /etc/fstab as noauto.
>> 
>> The issue comes during installworld, where we'll need to update the loader, 
>> and I'm not sure how we should handle that. 
>> If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files 
>> then 
>> unmount it? What should we do if NO_ROOT _is_ defined?
>> 
> 
> Previous to now, installworld has not updated the boot blocks. You've
> had to manually run 'gpart bootcode' to change the boot blocks.
> 
> However, those boot blocks mostly just loaded /boot/loader, which was
> updated by installworld.
> 
> So I can see how this is not directly analogous.
> 
> I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
> installworld randomly fobbing around in my EFI partition. Especially if,
> for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.
> 

I  would not add fstab entry at all. First of all, what should I have there for 
my 3+1 raidz1?;) 

it is reasonable to have efi/freebsd directory, the efi/boot/bootx64.efi is 
hard one of course. But then again, it is problem only when we can not setup 
EFI bootmanager variables — the bootx64.efi is default when bootmgr is not set 
up.

rgds,
toomas
___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Rebecca Cran]

On Sunday, 4 November 2018 14:25:26 MST Allan Jude wrote:

> I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
> installworld randomly fobbing around in my EFI partition. Especially if,
> for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.

I tend to agree. I have work planned in the near future to teach FreeBSD that 
EFI/BOOT may _not_ be FreeBSD and to play nice with other bootloaders, whether 
that be reFIND, GRUB, Windows etc. 

But yes, the big difference with this is there's much more code in loader.efi 
than we currently put in the bootblocks with boot0cfg or "gpart bootcode" and 
we might run into problems if we don't at least warn users that they'll need 
to update it.

-- 
Rebecca


___
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: UEFI: How to go about updating the ESP with loader.efi during installworld

[Allan Jude]

On 2018-11-04 16:20, Rebecca Cran wrote:
> I'm currently working on creating and updating the ESP (EFI System Partition) 
> for UEFI booting during installation and installworld. 
> 
> During installation, with my changes it gets mounted on /boot/efi and 
> loader.efi 
> copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets added 
> to 
> /etc/fstab as noauto.
> 
> The issue comes during installworld, where we'll need to update the loader, 
> and I'm not sure how we should handle that. 
> If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files 
> then 
> unmount it? What should we do if NO_ROOT _is_ defined?
> 

Previous to now, installworld has not updated the boot blocks. You've
had to manually run 'gpart bootcode' to change the boot blocks.

However, those boot blocks mostly just loaded /boot/loader, which was
updated by installworld.

So I can see how this is not directly analogous.

I wouldn't depend on the /etc/fstab entry existing. I am not sure I want
installworld randomly fobbing around in my EFI partition. Especially if,
for example, my EFI/BOOT is not FreeBSD, but rEFInd or something.

-- 
Allan Jude



signature.asc
Description: OpenPGP digital signature

UEFI: How to go about updating the ESP with loader.efi during installworld

[Rebecca Cran]

I'm currently working on creating and updating the ESP (EFI System Partition) 
for UEFI booting during installation and installworld. 

During installation, with my changes it gets mounted on /boot/efi and 
loader.efi 
copied into /boot/efi/EFI/FreeBSD and /boot/efi/EFI/BOOT. An entry gets added 
to 
/etc/fstab as noauto.

The issue comes during installworld, where we'll need to update the loader, 
and I'm not sure how we should handle that. 
If NO_ROOT isn't defined, do we just "mount /boot/efi", overwrite the files 
then 
unmount it? What should we do if NO_ROOT _is_ defined?

-- 
Rebecca


___
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: drm changes and updating to 12.0

[Niclas Zeising]

On 11/4/18 8:29 PM, Robert Huff wrote:


I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300
gpu) which will be updated from 11. to 12.0 once 12 is out
and the initial round of bugs are squashed.
One system is being done now, to allow time to catch any major
problems and then plan the update process.
Looking at src/UPDATING, the only thing I don't understand is the
whole drm-kmod change.  Is there an authoritative write-up on what's
going on, how to choose the right drivers for my hardware, and how to
do this from source without forcing a fresh install?



We are working on better documentation for this, but the main highlights 
are:  In most cases graphics/drm-kmod should suffice, especially on 
somewhat modern hardware.  You can also install any of the drm-*-kmod 
ports directly, if you want a specific version.  In general graphics 
hardware older than from 2013 requires drm-legacy-kmod instead. 
drm-kmod will also install drm-legacy-kmod on i386.


The same drivers in drm-legacy-kmod is also available in base on 12, so 
you can use the base drivers.  This is deprecated however, and not the 
case for 13-CURRENT.


You can install the drivers either from pkg, if you are using the 
GENERIC kernel, or build from ports if you have a customized kernel or 
if you are tracking for instance 12-STABLE or 13-CURRENT.


If you are using drm-legacy-kmod or the base driver with AMD graphics 
cards you might also need to install xf86-video-ati-legacy rather than 
xf86-video-ati.


Regards
--
Niclas Zeising
___
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"

unbound error: Undefined symbol "sldns_key_EVP_load_gost_id"

[Michael W. Lucas]

Hi,

Haven't seen this reported yet, so here it is. Found on last week's
world, rebuild last night and still there. Worth filing a bug?

storm~;uname -a
FreeBSD storm 13.0-CURRENT FreeBSD 13.0-CURRENT r339863 GENERIC  amd64

Trying to run unbound, and:

storm~;sudo unbound -dd
ld-elf.so.1: /usr/sbin/unbound: Undefined symbol "sldns_key_EVP_load_gost_id"

The voices in my head mutter it's something about OpenSSL. But they're
usually wrong.

Here's my unbound.conf, just in case:

---
root-hints: "named.cache"
access-control: 0.0.0.0/0 allow
---

Thanks,
==ml

-- 
Michael W. Lucashttps://mwl.io/
author of: Absolute OpenBSD, SSH Mastery, git commit murder,
Immortal Clay, PGP & GPG, Absolute FreeBSD, etc, etc, etc...
___
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 changes and updating to 12.0

[Robert Huff]

I have a set of older machines (e.g. AMD Phenom II, Radeon HD3300
gpu) which will be updated from 11. to 12.0 once 12 is out
and the initial round of bugs are squashed.
One system is being done now, to allow time to catch any major
problems and then plan the update process.
Looking at src/UPDATING, the only thing I don't understand is the
whole drm-kmod change.  Is there an authoritative write-up on what's
going on, how to choose the right drivers for my hardware, and how to
do this from source without forcing a fresh install?


Respectrfully,


Robert Huff

___
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: -current build failure after SVN r340130

[Michael Butler]

Confirmed to be fixed by SVN r340134 - thanks!

On 11/4/18 1:50 PM, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
> 
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
> 
> The broken function seems to call itself .. ??
> 
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
> 
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
> 
> return (0);
> }
> 
> ___
> 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: -current build failure after SVN r340130

[Mariusz Zaborski]

On Sun, Nov 04, 2018 at 01:50:31PM -0500, Michael Butler wrote:
> ===> libexec/dma/dma-mbox-create (all)
> Building
> /usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
> In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
> /usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
> error: all paths through this function will call itself
> [-Werror,-Winfinite-recursion]
> {
> ^
> 1 error generated.
> *** [dma-mbox-create.o] Error code 1
> 
> make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create
> 
> The broken function seems to call itself .. ??
> 
> static __inline int
> caph_fcntls_limit(int fd, uint32_t fcntlrights)
> {
> 
> if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
> return (-1);
> 
> return (0);
> }
Sorry, for that just fixed.

Thanks,
-- 
Mariusz Zaborski
oshogbo//vx | http://oshogbo.vexillium.org
FreeBSD committer   | https://freebsd.org
Software developer  | http://wheelsystems.com
If it's not broken, let's fix it till it is!!1


signature.asc
Description: PGP signature

-current build failure after SVN r340130

[Michael Butler]

===> libexec/dma/dma-mbox-create (all)
Building
/usr/obj/usr/src/amd64.amd64/libexec/dma/dma-mbox-create/dma-mbox-create.o
In file included from /usr/src/contrib/dma/dma-mbox-create.c:51:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/capsicum_helpers.h:161:1:
error: all paths through this function will call itself
[-Werror,-Winfinite-recursion]
{
^
1 error generated.
*** [dma-mbox-create.o] Error code 1

make[5]: stopped in /usr/src/libexec/dma/dma-mbox-create

The broken function seems to call itself .. ??

static __inline int
caph_fcntls_limit(int fd, uint32_t fcntlrights)
{

if (caph_fcntls_limit(fd, fcntlrights) < 0 && errno != ENOSYS)
return (-1);

return (0);
}

___
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: armv7 BETA3 panics when usb-disk inserted

[Warner Losh]

On Sun, Nov 4, 2018 at 12:55 AM Poul-Henning Kamp 
wrote:

> With the 12.0-BETA3 BEAGLEBONE image, I very often see this panic
> when I plug a USB attached SSD disk in.
>
...

>umass0 on uhub0
> umass0: 
> on usbus1
> umass0:  SCSI over Bulk-Only; quirks = 0x8100
> umass0:0:0: Attached to scbus0
> da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
> da0:  Fixed Direct Access SPC-2 SCSI
> device
> da0: Serial Number 2HC015KJ
> da0: 40.000MB/s transfers
> da0: 38166MB (78165359 512 byte sectors)
> da0: quirks=0x2
> panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device
> lock @ /usr/src/sys/cam/scsi/scsi_da.c:2123
> ...
> db_trace_self() at db_trace_self
>
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
> vpanic() at vpanic+0x16c
> doadump() at doadump
> __mtx_unlock_flags() at __mtx_unlock_flags
> __mtx_lock_flags() at __mtx_lock_flags+0xec
> daasync() at daasync+0x5c
>

This is line 2123


> xpt_async_process_dev() at xpt_async_process_dev+0x220
> xptdevicetraverse() at xptdevicetraverse+0xa4
> xpttargettraverse() at xpttargettraverse+0x7c
> $a.10() at $a.10+0x148
>

I love our new kang overlords. Glad I didn't vote for kodos...


> xpt_done_process() at xpt_done_process+0x3c4
> xpt_done_td() at xpt_done_td+0xec
>

So we're doing a walk of the scsi/sata namespace for the umass SIM and
we're calling daasync with a lock it expects to take out. The whole locking
stuff here is "a bit complicated" so I'll see why we're hitting this case
and at the same time simplify.

I'll see if I can recreate this bug here...

Warner
___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Konstantin Belousov]

On Sun, Nov 04, 2018 at 12:43:34AM -0700, Julian Elischer wrote:
> what's an ifunc?
> 
A special kind of relocation, controlled by the user code.
___
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: base/head r340113: usr.sbin/pkg fails to build, doesn't grok FreeBSD.conf

[Marie Helene Kvello-Aune]

> -Original Message-
> From: owner-freebsd-curr...@freebsd.org  curr...@freebsd.org> On Behalf Of Marie Helene Kvello-Aune
> Sent: søndag 4. november 2018 12:18
> To: freebsd-current@freebsd.org
> Subject: base/head r340113: usr.sbin/pkg fails to build, doesn't grok
> FreeBSD.conf
> 
> I'm trying to build -CURRENT, AMD64, r340113, but get an error when "make
> buildworld" tries to build usr.sbin/pkg.
> (...)

Ummm. My apologies, I was working on a dirty tree. It's not a problem with 
-CURRENT.

Marie Helene
___
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"

base/head r340113: usr.sbin/pkg fails to build, doesn't grok FreeBSD.conf

[Marie Helene Kvello-Aune]

I'm trying to build -CURRENT, AMD64, r340113, but get an error when "make 
buildworld" tries to build usr.sbin/pkg.

===
cc -O2 -pipe -I/usr/src/contrib/libucl/include -g -std=gnu99 
-fstack-protector-strong -Wsystem-headers -Werror -Wall -Wno-format-y2k -W 
-Wno-unused-parameter -Wstrict-prototypes -Wmis
ing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings 
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline 
-Wnested-externs -Wredundant-decl
 -Wold-style-definition -Wno-pointer-sign -Wmissing-variable-declarations 
-Wthread-safety -Wno-empty-body -Wno-string-plus-int -Wno-unused-const-variable 
-Qunused-arguments   -o pkg.f
ll pkg.o dns_utils.o config.o  -L/usr/obj/usr/src/amd64.amd64/lib/libarchive 
-larchive -L/usr/obj/usr/src/amd64.amd64/lib/libfetch -lfetch -lprivateucl 
-L/usr/obj/usr/src/amd64.amd64/
ib/libsbuf -lsbuf -L/usr/obj/usr/src/amd64.amd64/secure/lib/libcrypto -lcrypto 
-L/usr/obj/usr/src/amd64.amd64/secure/lib/libssl -lssl  

objcopy --only-keep-debug pkg.full pkg.debug

   
objcopy --strip-debug --add-gnu-debuglink=pkg.debug  pkg.full pkg   

   
gzip -cn /usr/src/usr.sbin/pkg/pkg.7 > pkg.7.gz 

   
make: don't know how to make FreeBSD.conf. Stop 

   


   
make: stopped in /usr/src/usr.sbin/pkg  

   
===

--
Marie Helene Kvello-Aune
free...@mhka.no
___
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: Waterfox: shared object "libicui18n.so.62" not found, required by "libxul.so"

[Graham Perrin]

On 03/11/2018 10:56, Jan Beich wrote:

> …
> Why not update? Mk/bsd.gecko.mk hasn't changed incompatibly yet.
> 1. Drop PORTREVISION line
> 2. Bump 56.2.3 to 56.2.5
> 3. Run "make makesum"
> 4. Run "make all deinstall install clean"

That's a pleasant surprise, I had no idea I could go with 56.2.5. It worked out 
fine.

>> Prior to that, I experimented briefly with waterfox@480899 copied to
>> /usr/local/poudriere/ports/default/www/waterfox
>> … wondering whether poudriere might be 'forced' to work with the deleted 
>> port. I guess not :-)
>
> Poudriere may not like:
> 1. MOVED entry i.e., remove waterfox line
> 2. Lack of waterfox in www/Makefile (only used by "bulk -a")
> 3. Non-default file permissions (check-sanity)

Yep, MOVED was an obstacle when I experimented (on the 29th), 
 line 33.

Thanks again!
___
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: svn commit: r339898 - head/lib/libc/amd64/sys

[Dimitry Andric]

On 4 Nov 2018, at 08:43, Julian Elischer  wrote:
> 
> what's an ifunc?

This is a GNU extension, an "indirect function".  It allows you to
provide multiple different implementations of the same function, for
instance optimized for specific CPU types, and choose between them at
dynamic link time (e.g. at run time).

See the following for more information:

https://sourceware.org/glibc/wiki/GNU_IFUNC
https://gcc.gnu.org/onlinedocs/gcc/Common-Function-Attributes.html#index-ifunc-function-attribute

-Dimitry



signature.asc
Description: Message signed with OpenPGP

Re: svn commit: r339898 - head/lib/libc/amd64/sys

[Julian Elischer]

what's an ifunc?


___
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: C.UTF-8 as default locale

[Baptiste Daroussin]

On Sun, Nov 04, 2018 at 09:35:48AM +0300, Yuri Pankov wrote:
> Hi,
> 
> Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
> following entry:
> 
> - Make C.UTF-8 the default locale (conrad, dteske(installer))
> 
> As this sort of change is better done early, I have put togetger a
> simple change introducing C.UTF-8 locale using the same common LC_CTYPE
> map as other UTF-8 locales (and it's now the source of symlinks instead
> of en_US one), and having all other components use C locale:
> 
> https://reviews.freebsd.org/D17833
> 
> With that in place, next step is likely to be updating 'default' entry
> in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
> changes to installer are likely to be not needed?
> 


Hey I never thought it could be done in such an easy way! don't know why,
I was always looking at it in a complex way, thus never started it.

Thank you very much, this looks fine to me! and that is imho a great addition

Best regards,
Bapt


signature.asc
Description: PGP signature

armv7 BETA3 panics when usb-disk inserted

[Poul-Henning Kamp]

With the 12.0-BETA3 BEAGLEBONE image, I very often see this panic
when I plug a USB attached SSD disk in.

login: ugen1.2:  at usbus1
umass0 on uhub0
umass0:  on 
usbus1
umass0:  SCSI over Bulk-Only; quirks = 0x8100
umass0:0:0: Attached to scbus0
da0 at umass-sim0 bus 0 scbus0 target 0 lun 0
da0:  Fixed Direct Access SPC-2 SCSI device
da0: Serial Number 2HC015KJ
da0: 40.000MB/s transfers
da0: 38166MB (78165359 512 byte sectors)
da0: quirks=0x2
panic: _mtx_lock_sleep: recursed on non-recursive mutex CAM device lock 
@ /usr/src/sys/cam/scsi/scsi_da.c:2123

cpuid = 0
time = 1541273846
KDB: stack backtrace:
db_trace_self() at db_trace_self
 pc = 0xc05c93f4  lr = 0xc0075dd8 (db_trace_self_wrapper+0x30)
 sp = 0xc35dca40  fp = 0xc35dcb58
db_trace_self_wrapper() at db_trace_self_wrapper+0x30
 pc = 0xc0075dd8  lr = 0xc029d624 (vpanic+0x16c)
 sp = 0xc35dcb60  fp = 0xc35dcb80
 r4 = 0x0100  r5 = 0x0001
 r6 = 0xc06d2cde  r7 = 0xc0a94fd8
vpanic() at vpanic+0x16c
 pc = 0xc029d624  lr = 0xc029d404 (doadump)
 sp = 0xc35dcb88  fp = 0xc35dcb8c
 r4 = 0x  r5 = 0xd1eb1474
 r6 = 0xc06ff75f  r7 = 0xc259b780
 r8 = 0xd1eb1464  r9 = 0xc259b780
r10 = 0x084b
doadump() at doadump
 pc = 0xc029d404  lr = 0xc0282c14 (__mtx_unlock_flags)
 sp = 0xc35dcb94  fp = 0xc35dcbf0
 r4 = 0xc029d404  r5 = 0xc35dcb94
__mtx_unlock_flags() at __mtx_unlock_flags
 pc = 0xc0282c14  lr = 0xc0282538 (__mtx_lock_flags+0xec)
 sp = 0xc35dcbf8  fp = 0xc35dcc20
 r4 = 0x  r5 = 0xd1eb1464
 r6 = 0xc06ff75f r10 = 0x084b
__mtx_lock_flags() at __mtx_lock_flags+0xec
 pc = 0xc0282538  lr = 0xc002f384 (daasync+0x5c)
 sp = 0xc35dcc28  fp = 0xc35dcc70
 r4 = 0xc0018574  r5 = 0xd375f940
 r6 = 0x0400  r7 = 0xc23ed900
 r8 = 0x  r9 = 0xc072ee95
r10 = 0xd375f940
daasync() at daasync+0x5c
 pc = 0xc002f384  lr = 0xc000f6e4 (xpt_async_process_dev+0x220)
 sp = 0xc35dcc78  fp = 0xc35dcca8
 r4 = 0xc0018574  r5 = 0xd375f940
 r6 = 0x0400  r7 = 0xc002f328
 r8 = 0xc2322320  r9 = 0xc072ee95
r10 = 0xc2322300
xpt_async_process_dev() at xpt_async_process_dev+0x220
 pc = 0xc000f6e4  lr = 0xc000e614 (xptdevicetraverse+0xa4)
 sp = 0xc35dccb0  fp = 0xc35dccd0
 r4 = 0xd376994c  r5 = 0xd1eb1474
 r6 = 0xc072ee95  r7 = 0xd1eb1000
 r8 = 0xd3769900  r9 = 0xd41a2800
r10 = 0xc000f4c4
xptdevicetraverse() at xptdevicetraverse+0xa4
 pc = 0xc000e614  lr = 0xc000e3a0 (xpttargettraverse+0x7c)
 sp = 0xc35dccd8  fp = 0xc35dccf8
 r4 = 0xd3769900  r5 = 0xd376994c
 r6 = 0xd3769800  r7 = 0xc091a140
 r8 = 0xd41a2800  r9 = 0xc000f458
r10 = 0xd375f940
xpttargettraverse() at xpttargettraverse+0x7c
 pc = 0xc000e3a0  lr = 0xc000b3f4 ($a.10+0x148)
 sp = 0xc35dcd00  fp = 0xc35dcdc0
 r4 = 0x  r5 = 0x0400
 r6 = 0xd3769900  r7 = 0xc091a140
 r8 = 0xd41a2800  r9 = 0xd375f944
r10 = 0xd375f940
$a.10() at $a.10+0x148
 pc = 0xc000b3f4  lr = 0xc000bbe8 (xpt_done_process+0x3c4)
 sp = 0xc35dcdc8  fp = 0xc35dcdd8
 r4 = 0xd41a2800  r5 = 0xc258ca80
 r6 = 0x  r7 = 0xc091a140
 r8 = 0x0001  r9 = 0x0100
r10 = 0xc35dcdfc
xpt_done_process() at xpt_done_process+0x3c4
 pc = 0xc000bbe8  lr = 0xc000dac4 (xpt_done_td+0xec)
 sp = 0xc35dcde0  fp = 0xc35dce20
 r4 = 0xc091a100  r5 = 0xc06d60c2
 r6 = 0x  r7 = 0xc091a140
xpt_done_td() at xpt_done_td+0xec
 pc = 0xc000dac4  lr = 0xc0262f88 (fork_exit+0xa0)
 sp = 0xc35dce28  fp = 0xc35dce40
 r4 = 0xc259b780  r5 = 0xc23f7390
 r6 = 0xc000d9d8  r7 = 0xc091a100
 r8 = 0xc35dce48  r9 = 0x
r10 = 0x
fork_exit() at fork_exit+0xa0
 pc = 0xc0262f88  lr = 0xc05cbcd4 (swi_exit)
 sp = 0xc35dce48  fp = 0x
 r4 = 0xc000d9d8  r5 = 0xc091a100
 r6 = 0x  r7 = 0x
 r8 = 0x r10 

C.UTF-8 as default locale

[Yuri Pankov]

Hi,

Looking through https://wiki.freebsd.org/DevSummit/201810, I noticed the
following entry:

- Make C.UTF-8 the default locale (conrad, dteske(installer))

As this sort of change is better done early, I have put togetger a
simple change introducing C.UTF-8 locale using the same common LC_CTYPE
map as other UTF-8 locales (and it's now the source of symlinks instead
of en_US one), and having all other components use C locale:

https://reviews.freebsd.org/D17833

With that in place, next step is likely to be updating 'default' entry
in /etc/login.conf to include 'charset=UTF-8' and 'lang=C.UTF-8', and
changes to installer are likely to be not needed?



signature.asc
Description: OpenPGP digital signature