r354057 Weekly Snapshot Works - my report

[Clay Daniels Jr.]

clay@bsd13:~ $ uname -a
FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT #0 r354057: Fri Oct 25
05:24:01 UTC 2019
r...@releng1.nyi.freebsd.org:/usr/obj/usr/src/amd64.amd64/sys/GENERIC
 amd64

I will note that when I tried to do pkg install drm-kmod, it returned error
code 1 & failed. I reloaded the basic r354057 install, did a Pkg install
drm-kmod, and it worked with no problems. (With the new drm-current-kmod
dated 10-23-19)

This is my first good install since r353072 of Oct 4th. Thanks to all the
developers who work on this, and for answering all my ignorant questions.

Clay Daniels
___
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-current-kmod is still a problem at r353339

[Clay Daniels Jr.]

Niclas, my last working install of 13.0 Current was r353072 of Oct 4th. The
next week's r353427  of Oct 11th did not work and I reverted to r353072 for
a week. Then r353709 of Oct 18th did not work, and when I tried to revert
back to r353072 it does not work either. These were install from ports, not
pkg install.

I'm looking at the available Current amd64 snapshots and all I see are:
r352778 (which worked), r353072 (worked), r353427 (did not work for me), &
r353709 (did not work for me). I don't see a r353906?

I would like to provide the full backtrace from the panic, as well as the
output from kldstat -v, but the boot hangs at this point, and the first
line of the panic I quoted above was a pen & paper transcription. Not sure
how to get what you would like...

I will also note that I saw that the gpu-firmware-kmod package has a date
of 10-15-2019, but that may not have anything to do with this.

Thanks, Niclas. I really like FreeBSD, and I'm working on a little FreeBSD
project on efitools & secure boot, so I would like to get this working
again. But actually the new snapshot will come out the day after tomorrow,
so there's always hope.
Clay

On Wed, Oct 23, 2019 at 4:33 PM Niclas Zeising 
wrote:

> On 2019-10-23 21:50, Clay Daniels Jr. wrote:
> > r353709
> > Looked promising, but failed:
> >
> > Loaded r353709
> > make install drm-kmod, all 3 installed
> > (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod)
> > set /etc/rc.conf & /boot/loader.conf configs as usual
> > rebooted and looked good, video tingling
> > pkg install xorg
> > rebooted and ran startx
> >
> > panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive
> busy @
> > /usr/src/sys/vm/vm_page.c
> >
> > System: Ryzen 7 3700X, MSI 570 series motherboard & video card
>
> Hi!
> Did this used to work before the recent changes to current?  Can you
> please update past current r353906, which contains some fixes that was
> posted earlier in this thread.
>
> Can you also provide the full backtrace from the panic, as well as the
> output from kldstat -v.
>
> Thank you!
> Regards
> --
> Niclas
>
___
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-current-kmod is still a problem at r353339

[Clay Daniels Jr.]

sorry, should be
all 3 installed
(drm-kmod, drm-current-kmod, & gpu-firmware-kmod)

On Wed, Oct 23, 2019 at 2:50 PM Clay Daniels Jr. 
wrote:

> r353709
> Looked promising, but failed:
>
> Loaded r353709
> make install drm-kmod, all 3 installed
> (drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod)
> set /etc/rc.conf & /boot/loader.conf configs as usual
> rebooted and looked good, video tingling
> pkg install xorg
> rebooted and ran startx
>
> panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy
> @ /usr/src/sys/vm/vm_page.c
>
> System: Ryzen 7 3700X, MSI 570 series motherboard & video card
>
> Thanks for trying,
> Clay
>
> On Wed, Oct 23, 2019 at 3:42 AM Niclas Zeising <
> zeising+free...@daemonic.se> wrote:
>
>> On 2019-10-21 10:13, Niclas Zeising wrote:
>> > On 2019-10-17 23:05, Mark Johnston wrote:
>> >> On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote:
>> >>> On 2019-10-17 21:53, ma...@freebsd.org wrote:
>> >>>> On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
>> >>>>> On 2019-10-16 18:57, Neel Chauhan wrote:
>> >>>>>> While drm-current-kmod worked for a little while, it broke with
>> >>>>>> r353645.
>> >>>>>>
>> >>>>>> https://i.imgur.com/Q5nYZf2.jpg
>> >>>>>>
>> >>>>>> I'm using the same HP Spectre that I used earlier (where it worked
>> >>>>>> and
>> >>>>>> where it panicked).
>> >>>>>>
>> >>>>>
>> >>>>> That commit looks unrelated, it touches the wbwd and superio
>> drivers,
>> >>>>> nothing else.  Any chance you can bisect exactly which revision that
>> >>>>> caused the new issues?
>> >>>>
>> >>>> I believe it was the recent work on the vm page busy state, r353539
>> >>>> specifically.  This patch should fix it; we don't yet have a
>> >>>> __FreeBSD_version number bump on which to gate the patch.
>> >>>>
>> >>>> diff --git a/linuxkpi/gplv2/src/linux_page.c
>> >>>> b/linuxkpi/gplv2/src/linux_page.c
>> >>>> index e2b85c45c..060ae85ed 100644
>> >>>> --- a/linuxkpi/gplv2/src/linux_page.c
>> >>>> +++ b/linuxkpi/gplv2/src/linux_page.c
>> >>>> @@ -239,7 +239,7 @@ retry:
>> >>>>page = vm_page_lookup(devobj, i);
>> >>>>if (page == NULL)
>> >>>>continue;
>> >>>> -if (vm_page_sleep_if_busy(page, "linuxkpi"))
>> >>>> +if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
>> >>>>goto retry;
>> >>>>cdev_pager_free_page(devobj, page);
>> >>>>}
>> >>>
>> >>> Hi!
>> >>> Hopefully someone can confirm that this patch to drm-current-kmod or
>> >>> drm-devel-kmod fixes the issue.  I won't be able to work on this
>> before
>> >>> the weekend at the earliest, I'm afraid.
>> >>> Mark, is it possible to get a belated version bump for this fix, and
>> >>> what changed to require it?
>> >>
>> >> I committed the bump and verified the patch on amdgpu.  Here are some
>> >> PRs for the drivers:
>> >>
>> >> https://github.com/FreeBSDDesktop/kms-drm/pull/180
>> >> https://github.com/FreeBSDDesktop/kms-drm/pull/181
>> >
>> > Hi!
>> > I'm working on getting this into the versions that are in ports.  For
>> > drm-current-kmod it's fairly simple, but for drm-devel-kmod there are
>> > unrelated changes which I need to check if they are ready to go in or
>> > not, so it will take some more time.
>> >
>> > Looking at the mail list thread, there seems to be a patch needed for
>> > base as well, has this been committed?
>>
>> drm-devel-kmod and drm-current-kmod has been updated with the above fix.
>> If there are further issues, please let us know.
>> Regards
>> --
>> Niclas
>> ___
>> 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: DRM-current-kmod is still a problem at r353339

[Clay Daniels Jr.]

r353709
Looked promising, but failed:

Loaded r353709
make install drm-kmod, all 3 installed
(drm-devel-kmod, drm-current-kmod, & gpu-firmware-kmod)
set /etc/rc.conf & /boot/loader.conf configs as usual
rebooted and looked good, video tingling
pkg install xorg
rebooted and ran startx

panic: vm_page_assert_xbusied: page 0xfe0005057500 not exclusive busy @
/usr/src/sys/vm/vm_page.c

System: Ryzen 7 3700X, MSI 570 series motherboard & video card

Thanks for trying,
Clay

On Wed, Oct 23, 2019 at 3:42 AM Niclas Zeising 
wrote:

> On 2019-10-21 10:13, Niclas Zeising wrote:
> > On 2019-10-17 23:05, Mark Johnston wrote:
> >> On Thu, Oct 17, 2019 at 10:31:12PM +0200, Niclas Zeising wrote:
> >>> On 2019-10-17 21:53, ma...@freebsd.org wrote:
>  On Thu, Oct 17, 2019 at 03:03:51PM +0200, Niclas Zeising wrote:
> > On 2019-10-16 18:57, Neel Chauhan wrote:
> >> While drm-current-kmod worked for a little while, it broke with
> >> r353645.
> >>
> >> https://i.imgur.com/Q5nYZf2.jpg
> >>
> >> I'm using the same HP Spectre that I used earlier (where it worked
> >> and
> >> where it panicked).
> >>
> >
> > That commit looks unrelated, it touches the wbwd and superio drivers,
> > nothing else.  Any chance you can bisect exactly which revision that
> > caused the new issues?
> 
>  I believe it was the recent work on the vm page busy state, r353539
>  specifically.  This patch should fix it; we don't yet have a
>  __FreeBSD_version number bump on which to gate the patch.
> 
>  diff --git a/linuxkpi/gplv2/src/linux_page.c
>  b/linuxkpi/gplv2/src/linux_page.c
>  index e2b85c45c..060ae85ed 100644
>  --- a/linuxkpi/gplv2/src/linux_page.c
>  +++ b/linuxkpi/gplv2/src/linux_page.c
>  @@ -239,7 +239,7 @@ retry:
> page = vm_page_lookup(devobj, i);
> if (page == NULL)
> continue;
>  -if (vm_page_sleep_if_busy(page, "linuxkpi"))
>  +if (!vm_page_busy_acquire(page, VM_ALLOC_WAITFAIL))
> goto retry;
> cdev_pager_free_page(devobj, page);
> }
> >>>
> >>> Hi!
> >>> Hopefully someone can confirm that this patch to drm-current-kmod or
> >>> drm-devel-kmod fixes the issue.  I won't be able to work on this before
> >>> the weekend at the earliest, I'm afraid.
> >>> Mark, is it possible to get a belated version bump for this fix, and
> >>> what changed to require it?
> >>
> >> I committed the bump and verified the patch on amdgpu.  Here are some
> >> PRs for the drivers:
> >>
> >> https://github.com/FreeBSDDesktop/kms-drm/pull/180
> >> https://github.com/FreeBSDDesktop/kms-drm/pull/181
> >
> > Hi!
> > I'm working on getting this into the versions that are in ports.  For
> > drm-current-kmod it's fairly simple, but for drm-devel-kmod there are
> > unrelated changes which I need to check if they are ready to go in or
> > not, so it will take some more time.
> >
> > Looking at the mail list thread, there seems to be a patch needed for
> > base as well, has this been committed?
>
> drm-devel-kmod and drm-current-kmod has been updated with the above fix.
> If there are further issues, please let us know.
> Regards
> --
> Niclas
> ___
> 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: r353072 > r353427 > r353709

[Clay Daniels Jr.]

Thanks, Evilham. I had read the thread lightly and hope it was fixed. I am
not familiar with patching, and mostly just do pkg install, but I do on
occasion make install from ports.

Right now I am sitting at two computers.

On the new Ryzen 7 with a MSI x570 motherboard & a MSI RX570 graphics card,
I have the base install of 13.0 Current r353709, no drm-kmod or xorg, fresh
and ready. I'm down in /usr/ports/graphics looking at my choices...

On my trusty old 2014 HP Pavilion I have Ubuntu installed, and this is
where I am writing this email.

I looked the email thread, and at Mark Johnston's patch. I can copy it to a
thumbdrive, go to the freebsd  machine and try to install the patch, but I
have hopes I can just find what I need in the /usr/ports/graphics
collection.

When I did my failed pkg installations yesterday I saw that pkg install
drm-kmod installed 3 packages:
drm-kmod: g20190710
drm-currentkmod: 4.16.g20190927
gpu-firmware-kmod: g20191015

The gpu-firmware-kmod pkg may be my problem, as the other two did not
change. I just looked at Makefile on the gpu-firmware-kmod port and it is
still at 2019-10-15. I am patient, and will not rush into this.

Clay


On Sat, Oct 19, 2019 at 4:54 AM Evilham  wrote:

>
> On ds., oct. 19 2019, Clay Daniels, Jr. wrote:
>
> > r353709 of today 18 Oct has only gone down hill. I tried to load
> > it a half
> > dozen times, gave up and then tried re-installing r353072 which
> > was working
> > earlier today, but the problem is the drm-firmware-kmod is
> > different this
> > week, and even it will not run xorg.
>
> Have you seen the recent threads about this?
> Particularly this with some steps that worked-for-me (tm):
>
> https://lists.freebsd.org/pipermail/freebsd-current/2019-October/074660.html
> --
> Evilham
>
___
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"

r353072 > r353427 > r353709

[Clay Daniels Jr.]

r353072 from 4 Oct worked great!

r353427 from 11 Oct last week did not. It had some drm-kmod problems and I
quickly dumped it and reloaded r353072 as I was hot to work on a project of
my own. That only bought me a week, did not solve the problem.

r353709 of today 18 Oct has only gone down hill. I tried to load it a half
dozen times, gave up and then tried re-installing r353072 which was working
earlier today, but the problem is the drm-firmware-kmod is different this
week, and even it will not run xorg.

So right now I have installed the base r353709 from today, no xorg, and it
works fine as a console. I had similar problems in late Aug for a couple of
weeks until Greg & some others said to use hw.syscons.disable=1 in
/boot/loader.conf which worked fine until now. I have tried loading today's
snapshot both ways, with the loader.conf line & without.

My project does not require xorg, just console, so I will keep it, and can
save my work to files & thumbdrives, but it would be nice to have access to
the web. If anyone has any ideas, let me know.

My setup is a Ryzen 7/MSI X570 bios/motherboard using amdgpu.

Clay
___
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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[Clay Daniels Jr.]

Simon, please do elaborate more on your implementation. I suspect you are
talking about libsecureboot? I have played with the generation of certs
with OpenSSL & LibreSSL, but libsecureboot seems to take a different
approach. Please tell us more.

Clay

On Mon, Oct 14, 2019 at 1:52 PM Simon J. Gerraty via freebsd-security <
freebsd-secur...@freebsd.org> wrote:

> Tomasz CEDRO  wrote:
>
> > would be really nice also to get UEFI BOOT compatible with SECURE BOOT
> :-)
>
> Unless you are using your own BIOS, the above means getting Microsoft
> to sign boot1.efi or similar. Shims that simply work around lack of
> acceptible signature don't help.
>
> That would need to then verify loader.efi - which can be built to
> to verify all the modules and kernel.
>
> In my implementation (uses the non efi loader) trust anchors are
> embedded in loader but there is code in current to lookup trust anchors
> in /efi I think which would be more generally useful - I've not looked
> at the attack vectors that introduces though.
>
> --sjg
> ___
> freebsd-secur...@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-security
> To unsubscribe, send any mail to "freebsd-security-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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[Clay Daniels Jr.]

Grarpamp,Tomasz, and all:

Thanks for all the reference documents. I looked through them, and did some
more research myself:

Creating Secure Boot Keys
---
0.
https://wiki.freebsd.org/SecureBoot
A work in progress.
---
1.
http://www.rodsbooks.com/efi-bootloaders/controlling-sb.html
Need:
openssl - pkg on freebsd
efitools - not found freebsd, source available elswhere
Note that efitools is dependent upon sbsigntool (aka sbsigntools), so you
may need to install it, too.
sbsigntool - not found freebsd, source available elswhere
---
2.
https://www.linuxjournal.com/content/take-control-your-pc-uefi-secure-boot
Similar tools to Rod's, added osslsigncode as possible substitute for
sbsigntool
---
My situation in life does not really seem to demand secure boot as I can
always wipe the drive and rebuild. However it was pointed out that malware
can continue to hide in the bios cmos nvram, so there is really no hiding
and yes, we do need to consider shaping up.

I am a big fan of Rod Smith ( http://www.rodsbooks.com/ ) and use his
rEFInd boot loader on both my machines. It was a little trouble to set up
the first time, but well worth the effort. I suspect that creating secure
boot keys is a bit more complicated, but I'm going to look into it deeper.
Any help & suggestions would be appreciated.

My trusty old 2014 HP Pavilion has it's HP vendor platform keys, but they
are not enabled. I have it in CSM mode, not UEFI mode, hence no secure boot
as uefi must be enabled for secure boot.

My new Ryzen 7 3700X & MSI X570 motherboard has UEFI boot set, but secure
boot is not enabled. I have not even "enrolled" the vendor keys yet.

So I have a lab setup to play with two machines, old & new, and the time &
patience to play with this. I do welcome any suggestions and help

Clay


On Thu, Oct 3, 2019 at 7:01 PM grarpamp  wrote:

> >> Just whose secure keys do you suggest? I go to a lot of trouble to
> disable
> >> secure boot so I can load any operating system I want.
>
> Some motherboards have BIOS that allows you to both
> - Upload your own keys
> - Delete all the spooky Microsoft keys
>
> Read the UEFI Secure Boot specification document.
> Then paste all the key management specs into a ticket
> with your motherboard vendor and get on them to publish
> a BIOS release that has proper key management functions.
>
> Some BIOS makers have this as selectable options in their
> BIOS reference build routines... ie: the motherboard maker doesn't
> have to write any code, they just point and click, and the option
> appears in a BIOS release for mobo end user customers.
>
> Sometimes you have to bug and escalate the mobo makers
> and threaten to walk your next purchase to another mobo maker
> to get them to cut and post the new BIOS release.
>
> https://www.uefi.org/
> https://uefi.org/learning_center/papers
> https://uefi.org/specsandtesttools
> https://uefi.org/sites/default/files/resources/UEFI_Spec_2_8_final.pdf
>
>
> https://uefi.org/sites/default/files/resources/UEFI_Secure_Boot_in_Modern_Computer_Security_Solutions_2019.pdf
>
> https://uefi.org/sites/default/files/resources/UEFI%20Forum%20White%20Paper%20-%20Chain%20of%20Trust%20Introduction_2019.pdf
>
>
> > The goal would be not to disable secure boot and have FreeBSD running
> > with a secured bootloader :-)
> >
> > At the moment we have insecure boot + insecure kernel + possible
> > encrypted data partition..
>
> > would be really nice also to get UEFI BOOT compatible with SECURE BOOT
> :-)
>
> Yes.
> ___
> 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: AMD Secure Encrypted Virtualization - FreeBSD Status?

[Clay Daniels Jr.]

Just whose secure keys do you suggest? I go to a lot of trouble to disable
secure boot so I can load any operating system I want.

On Thu, Oct 3, 2019 at 11:10 AM Tomasz CEDRO  wrote:

> would be really nice also to get UEFI BOOT compatible with SECURE BOOT :-)
>
>
> --
> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
> ___
> 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"

CURRENT r352544 & new drm-current-kmod worked fine

[Clay Daniels Jr.]

I noticed a new : drm-current-kmod
Version: 4.16.g20190918

Worked fine with my AMD R7 and "amdgpu"
I needed the line in /boot/loader.conf
hw.syscons.disable=1

Note: I tried first without adding the loader.conf line.
Same story, cannot boot in framebuffer mode, but now I know the trick I
don't mind adding it. Seems to be an AMD thing, but I like AMD a lot.

Clay
___
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: Another X server start failure

[Clay Daniels Jr.]

Assuming you are running 13.0 Current, and already put the entry in
/etc/rc.conf:
kld_list="amdgpu"   #Yes, no path needed, just "amdgpu"

Having done that, try this in /boot/loader.conf

hw.syscons.disable=1  # then reboot

I'm not the expert here, but the cause is what I might call a "framebuffer
problem" with AMD graphics and drm-kmod. There were changes in August to
drm-current-kmod that  took me a while to overcome myself, but thanks to
the folks on this list, I'm back online with 13.0 Current.

Good luck,
Clay

On Thu, Sep 19, 2019 at 6:00 AM  wrote:

> Having a Raden 240 (sometimes 250) and an older AMDGPU. The older card is
> deactivated in BIOS but it is been found by the X -configure problem. X
> server
> did start one time with -config /root/xorg.conf.new, copied to /etc/X11/
> xorg.conf, never got back any "blank black grafic" screen. Rebuilt new
> world
> and the kern with WITNESS option on and option LOCK_PROFILING. Using llvm-
> devel is useless in that case, if it doesn't with the 8.0.X.
>
> Can't enter framebuffer mode, tells /var/log/x11_*.log,  no VESA, no xfcb.
> sddm tells: xauth: bad add command line, bad delete command line, bad add
> commandline. It used to work with even X -configure fatal error and sddm,
> so
> what to xrite in xauth; normally sddm autoconfigs.
>
> I guess it's the recognization from both cards, what is the option to
> really
> and finally deactivate this on-board card on an ASUS PRIME 350 board (I
> just
> mean NOT to cut the part of the board where grafics situatiated with a
> laser-
> cutter :-) )? This one has never been used as it been too old for good 3D-
> Gaming what has been a topic a year ago - not for me, but for a user.
>
> What's the state of art for 3D-virutal-glasses and gloves? I guess the
> same as
> with the AI! I guess freeBSD has other functions to do than beeing a
> desktop
> OS!
>
> Thx for help in advance,
> Yours, Miranda
>
>
> ___
> 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: AMD & 13.0 Current

[Clay Daniels Jr.]

I wanted to add that when I installed this weeks 13.0 snapshot, I tried it
first with only the kld_list="amdgpu" in /etc/rc.conf AND NO
/boot/loader.conf entry. It failed to load startx. I then made the
loader.conf entr, rebooted and startx loaded x windows, the nice little
screen with 3 xterminals and a clock.

On Sun, Sep 15, 2019 at 7:25 PM Clay Daniels Jr. 
wrote:

> Mark, the line added in /boot/loader.conf was shared by others on this
> list in August when I missed  my usual install of the weekly 13.0 Current
> snapshot. Turned out to be what could be called a "framebuffer problem" and
> by adding this line in loader.conf solved my problem. Later I did more
> looking and found we have a nice Wiki about graphics at:
>
> https://wiki.freebsd.org/Graphics
>
>
> You will see this about mid way down the page:
>
> "It is important to note that there is currently a conflict with both AMD
> drivers and the EFI frambuffer. The current workaround, when booting via
> UEFI on these systems, is to disable the framebuffer via /boot/loader.conf:
>
> hw.syscons.disable=1"
>
> As for FreeBSD 12.0 Stable, I have not installed it yet, and probably
> would have not considered that as I am pretty much into bsd13, but I will
> now plan to load their snapshot on Friday and give it a try.
>
> Clay
>
> On Sun, Sep 15, 2019 at 6:20 PM  wrote:
>
>> On Sun, Sep 15, 2019 at 05:29:36PM -0500, Clay Daniels Jr. wrote:
>> > I have built me a new computer, put it together, and being impatient did
>> > not even partition the 2TB WD HD, but just installed last weeks Current.
>> > Worked great!
>> > Now that I have these two to compare I will share the details and
>> results,
>> > particularly if you are using AMD CPR/Radeon Graphics.
>> >
>> > The older:
>> > Per Windows:
>> > HP Pavilion23 All-in-one PC
>> > Manufactured & bought 2014
>> > AMD E2-3800 APU with Radeon Graphics
>> > 1.30GHz CPU - 4.00 GB RAM
>> > Per either Linux or FreeBSD13:
>> > Graphics:
>> > Device-1: AMD Kabini [Radeon HD 8280 / R3 Series]vendor:Hewlett-Packard
>> > driver: radeon v: kernel bus ID: 00:01.0
>> > Display: x11 server: X.Org 1.19.2 driver: ati,radeon
>> > unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz
>> > OpenGL: renderer: AMD KABINI (DRM 2.50.0 4.19.0-5-amd64 LLVM 7.0.0)
>> > v: 4.5 Mesa 18.2.6 direct render: Yes
>> >
>> > The newer:
>> > R7_BSD-13
>> > clay@r7bsd:~ $ uname -a
>> > FreeBSD r7bsd 13.0-CURRENT FreeBSD 13.0-CURRENT r352265 GENERIC  amd64
>> > clay@r7bsd:~ $ gpart show -p
>> > =>34  3907029101ada0  GPT  (1.8T)
>> >   342014  - free -  (1.0M)
>> > 2048 1083392  ada0p1  ms-recovery  (529M)
>> >  1085440  204800  ada0p2  efi  (100M)
>> >  1290240   32768  ada0p3  ms-reserved  (16M)
>> >  1323008  1072420864  ada0p4  ms-basic-data  (511G)
>> >   1073743872  532480  ada0p5  efi  (260M)
>> >   1074276352  2824331256  ada0p6  freebsd-ufs  (1.3T)
>> >   3898607608 8388608  ada0p7  freebsd-swap  (4.0G)
>> >   3906996216   32919  - free -  (16M)
>> > Hardware:
>> > AMD Ryzen7 3700X CPU
>> > MSI MSI X570-A PRO Motherboard
>> > MSI Radeon RX 570 Video Card
>> > G.SKILL Ripjaws V Series 16GB SDRAM DDR4 3200 Memory
>> >
>> > The good thing is they both use the same drm-kmod "amdgpu".
>> > So I can see that a 2014 or later computer will probably use the same,
>> and
>> > not the legacy "radeonkms" in /etc/rc.conf.
>> >
>> > The other thing to note, is that for 13.0 Current they both need a line
>> in
>> > /boot/loader.conf:
>> > hw.syscons..disable=1
>>
>> Why is this line needed and for what purposes?
>>
>> Does the new hardware in this new build also work well in FreeBSD 12
>> stable branch? The FreeBSD current is for testing purposes so we are
>> very interested in how it the above mentioned new hardware work on
>> stable or production version.
>>
>> Mark
>>
>> >
>> > That's basically my report. I am enjoying my new machine.
>> > Clay
>> > ___
>> > 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: AMD & 13.0 Current

[Clay Daniels Jr.]

Mark, the line added in /boot/loader.conf was shared by others on this list
in August when I missed  my usual install of the weekly 13.0 Current
snapshot. Turned out to be what could be called a "framebuffer problem" and
by adding this line in loader.conf solved my problem. Later I did more
looking and found we have a nice Wiki about graphics at:

https://wiki.freebsd.org/Graphics


You will see this about mid way down the page:

"It is important to note that there is currently a conflict with both AMD
drivers and the EFI frambuffer. The current workaround, when booting via
UEFI on these systems, is to disable the framebuffer via /boot/loader.conf:

hw.syscons.disable=1"

As for FreeBSD 12.0 Stable, I have not installed it yet, and probably would
have not considered that as I am pretty much into bsd13, but I will now
plan to load their snapshot on Friday and give it a try.

Clay

On Sun, Sep 15, 2019 at 6:20 PM  wrote:

> On Sun, Sep 15, 2019 at 05:29:36PM -0500, Clay Daniels Jr. wrote:
> > I have built me a new computer, put it together, and being impatient did
> > not even partition the 2TB WD HD, but just installed last weeks Current.
> > Worked great!
> > Now that I have these two to compare I will share the details and
> results,
> > particularly if you are using AMD CPR/Radeon Graphics.
> >
> > The older:
> > Per Windows:
> > HP Pavilion23 All-in-one PC
> > Manufactured & bought 2014
> > AMD E2-3800 APU with Radeon Graphics
> > 1.30GHz CPU - 4.00 GB RAM
> > Per either Linux or FreeBSD13:
> > Graphics:
> > Device-1: AMD Kabini [Radeon HD 8280 / R3 Series]vendor:Hewlett-Packard
> > driver: radeon v: kernel bus ID: 00:01.0
> > Display: x11 server: X.Org 1.19.2 driver: ati,radeon
> > unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz
> > OpenGL: renderer: AMD KABINI (DRM 2.50.0 4.19.0-5-amd64 LLVM 7.0.0)
> > v: 4.5 Mesa 18.2.6 direct render: Yes
> >
> > The newer:
> > R7_BSD-13
> > clay@r7bsd:~ $ uname -a
> > FreeBSD r7bsd 13.0-CURRENT FreeBSD 13.0-CURRENT r352265 GENERIC  amd64
> > clay@r7bsd:~ $ gpart show -p
> > =>34  3907029101ada0  GPT  (1.8T)
> >   342014  - free -  (1.0M)
> > 2048 1083392  ada0p1  ms-recovery  (529M)
> >  1085440  204800  ada0p2  efi  (100M)
> >  1290240   32768  ada0p3  ms-reserved  (16M)
> >  1323008  1072420864  ada0p4  ms-basic-data  (511G)
> >   1073743872  532480  ada0p5  efi  (260M)
> >   1074276352  2824331256  ada0p6  freebsd-ufs  (1.3T)
> >   3898607608 8388608  ada0p7  freebsd-swap  (4.0G)
> >   3906996216   32919  - free -  (16M)
> > Hardware:
> > AMD Ryzen7 3700X CPU
> > MSI MSI X570-A PRO Motherboard
> > MSI Radeon RX 570 Video Card
> > G.SKILL Ripjaws V Series 16GB SDRAM DDR4 3200 Memory
> >
> > The good thing is they both use the same drm-kmod "amdgpu".
> > So I can see that a 2014 or later computer will probably use the same,
> and
> > not the legacy "radeonkms" in /etc/rc.conf.
> >
> > The other thing to note, is that for 13.0 Current they both need a line
> in
> > /boot/loader.conf:
> > hw.syscons..disable=1
>
> Why is this line needed and for what purposes?
>
> Does the new hardware in this new build also work well in FreeBSD 12
> stable branch? The FreeBSD current is for testing purposes so we are
> very interested in how it the above mentioned new hardware work on
> stable or production version.
>
> Mark
>
> >
> > That's basically my report. I am enjoying my new machine.
> > Clay
> > ___
> > 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"

AMD & 13.0 Current

[Clay Daniels Jr.]

I have built me a new computer, put it together, and being impatient did
not even partition the 2TB WD HD, but just installed last weeks Current.
Worked great!
Now that I have these two to compare I will share the details and results,
particularly if you are using AMD CPR/Radeon Graphics.

The older:
Per Windows:
HP Pavilion23 All-in-one PC
Manufactured & bought 2014
AMD E2-3800 APU with Radeon Graphics
1.30GHz CPU - 4.00 GB RAM
Per either Linux or FreeBSD13:
Graphics:
Device-1: AMD Kabini [Radeon HD 8280 / R3 Series]vendor:Hewlett-Packard
driver: radeon v: kernel bus ID: 00:01.0
Display: x11 server: X.Org 1.19.2 driver: ati,radeon
unloaded: fbdev,modesetting,vesa resolution: 1920x1080~60Hz
OpenGL: renderer: AMD KABINI (DRM 2.50.0 4.19.0-5-amd64 LLVM 7.0.0)
v: 4.5 Mesa 18.2.6 direct render: Yes

The newer:
R7_BSD-13
clay@r7bsd:~ $ uname -a
FreeBSD r7bsd 13.0-CURRENT FreeBSD 13.0-CURRENT r352265 GENERIC  amd64
clay@r7bsd:~ $ gpart show -p
=>34  3907029101ada0  GPT  (1.8T)
  342014  - free -  (1.0M)
2048 1083392  ada0p1  ms-recovery  (529M)
 1085440  204800  ada0p2  efi  (100M)
 1290240   32768  ada0p3  ms-reserved  (16M)
 1323008  1072420864  ada0p4  ms-basic-data  (511G)
  1073743872  532480  ada0p5  efi  (260M)
  1074276352  2824331256  ada0p6  freebsd-ufs  (1.3T)
  3898607608 8388608  ada0p7  freebsd-swap  (4.0G)
  3906996216   32919  - free -  (16M)
Hardware:
AMD Ryzen7 3700X CPU
MSI MSI X570-A PRO Motherboard
MSI Radeon RX 570 Video Card
G.SKILL Ripjaws V Series 16GB SDRAM DDR4 3200 Memory

The good thing is they both use the same drm-kmod "amdgpu".
So I can see that a 2014 or later computer will probably use the same, and
not the legacy "radeonkms" in /etc/rc.conf.

The other thing to note, is that for 13.0 Current they both need a line in
/boot/loader.conf:
hw.syscons..disable=1

That's basically my report. I am enjoying my new machine.
Clay
___
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: "cpuset -n prefer:?" --what values for "?" are supposed to be allowed? (only 1 is, despite two numa domains)

[Clay Daniels Jr.]

Mark, this is what I get on my machine:

root@new:~ # cpuset -g
pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15
pid -1 domain policy: first-touch mask: 0
root@new:~ #  cpuset -l0 -n prefer:0 COMMAND
cpuset: COMMAND: No such file or directory
root@new:~ # cpuset -l0 -n prefer:2 COMMAND
cpuset: setdomain: Invalid argument
root@new:~ # cpuset -l0 -n prefer:1 COMMAND
cpuset: setdomain: Invalid argument

>From dmesg:
FreeBSD 13.0-CURRENT r351901 GENERIC amd64
CPU: AMD Ryzen 7 3700X 8-Core Processor(3600.08-MHz K8-class CPU)

Similar,
Clay

On Wed, Sep 11, 2019 at 12:58 AM Mark Millard  wrote:

> In a context with:
>
> # cpuset -g
> pid -1 mask: 0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17,
> 18, 19, 20, 21, 22, 23, 24, 25, 26, 27
> pid -1 domain policy: first-touch mask: 0, 1
>
> I get:
>
> # cpuset -l0 -n prefer:0 COMMAND
> cpuset: setdomain: Invalid argument
>
> # cpuset -l0 -n prefer:2 COMMAND
> cpuset: setdomain: Invalid argument
>
> But one prefer:? value does allow the COMMAND
> to run:
>
> # cpuset -l0 -n prefer:1 COMMAND
>
> This seem odd to me. Am I missing something?
>
> For reference: I'm using a ThreadRipper 1950X
> with a head -r351227 based context for this
> activity. The above happens to have been run
> in a Windows 10 Pro HyperV session, instead
> of in a native-boot of the same media. (A
> native-boot would have had 32 CPUs.)
>
>
> ===
> Mark Millard
> marklmi at yahoo.com
> ( dsl-only.net went
> away in early 2018-Mar)
>
> ___
> 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: fusefs & ntfs-3g

[Clay Daniels Jr.]

Alan,  Michael, & Kevin, THANKS very much. This is kind of neat:

root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt
root@bsd13:/home/clay # cd /mnt
root@bsd13:/mnt # ls -al

total 2368276
drwxrwxrwx   1 root  wheel   0 Jul 17 16:40 $Recycle.Bin
drwxrwxrwx   1 root  wheel4096 Aug  6 02:08 .
drwxr-xr-x  19 root  wheel1024 Sep  8 19:25 ..
drwxrwxrwx   1 root  wheel   0 Aug 13 15:05 Config.Msi
lrwxrwxrwx   2 root  wheel  10 Jul 17 17:07 Documents and Settings
-> /mnt/Users
drwxrwxrwx   1 root  wheel   0 Mar 18 23:52 PerfLogs
drwxrwxrwx   1 root  wheel4096 Aug  4 16:11 Planetdance
drwxrwxrwx   1 root  wheel8192 Sep  3 18:55 Program Files
drwxrwxrwx   1 root  wheel8192 Aug 11 02:20 Program Files (x86)
drwxrwxrwx   1 root  wheel4096 Aug  6 02:01 ProgramData
drwxrwxrwx   1 root  wheel   0 Jul 17 15:42 Recovery
drwxrwxrwx   1 root  wheel4096 Sep  8 13:59 System Volume
Information
drwxrwxrwx   1 root  wheel4096 Jul 17 16:01 Users
drwxrwxrwx   1 root  wheel   16384 Aug 31 20:39 Windows
-rwxrwxrwx   1 root  wheel  1485533184 Sep  8 19:03 hiberfil.sys
-rwxrwxrwx   1 root  wheel   671088640 Sep  8 00:24 pagefile.sys
-rwxrwxrwx   1 root  wheel   268435456 Sep  8 00:24 swapfile.sys
root@bsd13:/mnt #

Clay


On Sun, Sep 8, 2019 at 7:19 PM Kevin Oberman  wrote:

> On Sun, Sep 8, 2019 at 4:46 PM Michael Butler 
> wrote:
>
>> On 9/8/19 7:09 PM, Alan Somers wrote:
>> > On Sun, Sep 8, 2019 at 5:00 PM Clay Daniels Jr. <
>> clay.daniels...@gmail.com>
>> > wrote:
>> >
>> >> I want to view my Windows C: drive on ata0p4.
>> >> This is what I have:
>> [...]
>> >> root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt
>> >> * Windows is hibernated, refused to mount.
>> >> The disk contains an unclean file system (0, 0).
>> >> Metadata kept in Windows cache, refused to mount.
>> >> Falling back to read-only mount because the NTFS partition is in an
>> unsafe
>> >> state. Please resume and shutdown Windows fully (no hibernation
>> >> or fast restarting.
>> >>
>> >> I'm having a roadblock here. Maybe someone knows the answer.
>> >>
>> >
>> > I'm assuming that you already ascertained that the Windows file system
>> was
>> > in fact clean?  If so, then this sounds like a problem with fusefs-ntfs,
>> > not with fuse in general.  I've CC'd its maintainer.  He may be able to
>> > help you.
>> > -Alan
>>
>> Windows-10 has a changed default; it does the equivalent of hibernation
>> to facilitate "fast start". ntfs-3g won't touch a partition for writing
>> in that mode :-(
>>
>> If I recall correctly, there is a setting you must change from in
>> Windows under control panel -> system -> power and sleep. From there you
>> should be able to disable the "fast start" option and, after shutting
>> down, ntfs-3g will allow a read/write mount,
>>
>
> I can confirm this. It is documented, but not obvious. You ave two choices:
> 1. Change the system setting, more or less as Michael suggests. I'm away
> from my only W10 system, so I can't check the exact details.
> 2. Force a full shutdown by starting a command window and entering
> "shutdown /s  /f /t 0". This is a one-time full shutdown.
> --
> 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"

fusefs & ntfs-3g

[Clay Daniels Jr.]

I want to view my Windows C: drive on ata0p4.
This is what I have:
FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351901 GENERIC  amd64
clay@bsd13:~ % pkg info -r fusefs-libs
fusefs-libs-2.9.9:
clay@bsd13:~ % pkg info -r fusefs-libs3
fusefs-libs3-3.6.2:
clay@bsd13:~ % cat /boot/loader.conf
hw.syscons.disable=1
fusefs_load="YES"
clay@bsd13:~ % kldstat
Id Refs AddressSize Name
 1   72 0x8020  2336f80 kernel
 21 0x8253800027990 fusefs.ko
 31 0x8272   2519c4 amdgpu.ko
 42 0x8297200077bd0 drm.ko
 55 0x829ea00012470 linuxkpi.ko
 63 0x829fd00012f30 linuxkpi_gplv2.ko
 72 0x82a1  8e0 lindebugfs.ko
 81 0x82a11000 f281 ttm.ko
 91 0x82a21000 23f7 radeon_kabini_pfp_bin.ko
101 0x82a24000 23f5 radeon_kabini_me_bin.ko
111 0x82a27000 23f5 radeon_kabini_ce_bin.ko
121 0x82a2a000 43f7 radeon_kabini_mec_bin.ko
131 0x82a2f000 2a77 radeon_kabini_rlc_bin.ko
141 0x82a32000 12e9 radeon_kabini_sdma_bin.ko
151 0x82a34000 12eb radeon_kabini_sdma1_bin.ko
161 0x82a3600038ea7 radeon_kabini_uvd_bin.ko
171 0x82a6f00018c47 radeon_kabini_vce_bin.ko
181 0x82a88000 2538 intpm.ko
191 0x82a8b000  a50 smbus.ko
201 0x82a8c000 1820 uhid.ko
211 0x82a8e000 2928 ums.ko
221 0x82a91000 1b00 wmt.ko
231 0x82a93000  acf mac_ntpd.ko
241 0x82a94000 a9f8 tmpfs.ko

clay@bsd13:~ % pkg info fusefs-ntfs-2017.3.23
fusefs-ntfs-2017.3.23
Name   : fusefs-ntfs
Version: 2017.3.23
Installed on   : Sun Sep  8 17:24:36 2019 CDT
Origin : sysutils/fusefs-ntfs
Architecture   : FreeBSD:13:amd64
Prefix : /usr/local
Categories : sysutils
Licenses   : GPLv2+
Maintainer : free...@dussan.org
WWW: https://www.tuxera.com/community/open-source-ntfs-3g/
Comment: Mount NTFS partitions (read/write) and disk images
Options:
DOCS   : on
LOCK   : on
UBLIO  : on
Shared Libs required:
libfuse.so.2
libuuid.so.1
libublio.so.1
Shared Libs provided:
libntfs-3g.so.88
Annotations:
FreeBSD_version: 1300044
repo_type  : binary
repository : FreeBSD
Flat size  : 1.93MiB
Description:
The ntfs-3g driver is an open source, freely available read/write NTFS
driver, which provides safe and fast handling of the Windows XP, Windows
Server 2003, Windows 2000, Windows Vista, Windows Server 2008, Windows 7
and Windows 8 NTFS file systems. Almost the full POSIX filesystem
functionality is supported, the major exceptions are changing the file
ownerships and the access rights.

root@bsd13:/home/clay # ntfs-3g -o default_permissons /dev/ada0p4 /mnt
* Windows is hibernated, refused to mount.
The disk contains an unclean file system (0, 0).
Metadata kept in Windows cache, refused to mount.
Falling back to read-only mount because the NTFS partition is in an unsafe
state. Please resume and shutdown Windows fully (no hibernation
or fast restarting.

I'm having a roadblock here. Maybe someone knows the answer.
___
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: FUSE & fusefs-*

[Clay Daniels Jr.]

Yes Alan that helps a lot! And am I to assume that the fuse ports in
/emulators have NOTHING to do with the fuse.fs ports in /sysutils?
Thanks,
Clay

On Fri, Aug 30, 2019 at 2:23 PM Alan Somers  wrote:

> In freebsd head, the driver is now called fusefs.ko.  Does that help?
>
> On Fri, Aug 30, 2019, 12:45 PM Clay Daniels Jr. 
> wrote:
>
>> I finally have a little time to play with the FUSE, and installed some
>> fusefs utilities I might like to try, for ntfs & ext. This is what I have:
>> ---
>> clay@bsd13:~ $ pkg info -r fusefs-libs
>> fusefs-libs-2.9.9:
>> fusefs-ntfs-2017.3.23
>> fusefs-ext2-0.0.10_2
>> fusefs-ext4fuse-0.1.3_1,1
>> clay@bsd13:~ $ pkg info -r fusefs-libs3
>> pkg: No package(s) matching fusefs-libs3
>> clay@bsd13:~ $ kldstat
>> Id Refs AddressSize Name
>>  1   70 0x8020  2336a10 kernel
>>  21 0x8272   250c44 amdgpu.ko
>>  32 0x8297100076e90 drm.ko
>>  45 0x829e800012470 linuxkpi.ko
>>  53 0x829fb00012f30 linuxkpi_gplv2.ko
>>  62 0x82a0e000  8e0 lindebugfs.ko
>>  71 0x82a0f000 f021 ttm.ko
>>  81 0x82a1f000 23f7 radeon_kabini_pfp_bin.ko
>>  91 0x82a22000 23f5 radeon_kabini_me_bin.ko
>> 101 0x82a25000 23f5 radeon_kabini_ce_bin.ko
>> 111 0x82a28000 43f7 radeon_kabini_mec_bin.ko
>> 121 0x82a2d000 2a77 radeon_kabini_rlc_bin.ko
>> 131 0x82a3 12e9 radeon_kabini_sdma_bin.ko
>> 141 0x82a32000 12eb radeon_kabini_sdma1_bin.ko
>> 151 0x82a3400038ea7 radeon_kabini_uvd_bin.ko
>> 161 0x82a6d00018c47 radeon_kabini_vce_bin.ko
>> 171 0x82a86000 2538 intpm.ko
>> 181 0x82a89000  a50 smbus.ko
>> 191 0x82a8a000 1820 uhid.ko
>> 201 0x82a8c000 2928 ums.ko
>> 211 0x82a8f000 1b00 wmt.ko
>> 221 0x82a91000  acf mac_ntpd.ko
>> 231 0x82a92000 a9f8 tmpfs.ko
>> clay@bsd13:~ $ kldload fuse
>> kldload: can't load fuse: Operation not permitted
>> clay@bsd13:~ $ su
>> Password:
>> root@bsd13:/home/clay # kldload fuse
>> kldload: can't load fuse: No such file or directory
>> ---
>> The information I have on FUSE & fusefs is mostly from these sources:
>>
>> https://forums.freebsd.org/threads/how-to-mount-ntfs-partition-from-same-hdd.62888/
>> http://kflu.github.io/2018/02/03/2018-02-03-freebsd-ntfs/
>>
>> They seem to indicate there is a fuse.ko driver module that can be loaded
>> much like the drm-kmod video drivers. I don't see this on my install:
>> FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351591 GENERIC  amd64
>>
>> I'm missing a few clues, and I don't understand the relation of the fuse
>> ports in the ports/emulators & ports/sysutil directories. There is nothing
>> mission critical, but any help would be a appreciated. I think it would be
>> handy to mount ntfs & ext partitions from my ufs FreeBSD partition.
>>
>> Clay Daniels
>>
>
___
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"

FUSE & fusefs-*

[Clay Daniels Jr.]

I finally have a little time to play with the FUSE, and installed some
fusefs utilities I might like to try, for ntfs & ext. This is what I have:
---
clay@bsd13:~ $ pkg info -r fusefs-libs
fusefs-libs-2.9.9:
fusefs-ntfs-2017.3.23
fusefs-ext2-0.0.10_2
fusefs-ext4fuse-0.1.3_1,1
clay@bsd13:~ $ pkg info -r fusefs-libs3
pkg: No package(s) matching fusefs-libs3
clay@bsd13:~ $ kldstat
Id Refs AddressSize Name
 1   70 0x8020  2336a10 kernel
 21 0x8272   250c44 amdgpu.ko
 32 0x8297100076e90 drm.ko
 45 0x829e800012470 linuxkpi.ko
 53 0x829fb00012f30 linuxkpi_gplv2.ko
 62 0x82a0e000  8e0 lindebugfs.ko
 71 0x82a0f000 f021 ttm.ko
 81 0x82a1f000 23f7 radeon_kabini_pfp_bin.ko
 91 0x82a22000 23f5 radeon_kabini_me_bin.ko
101 0x82a25000 23f5 radeon_kabini_ce_bin.ko
111 0x82a28000 43f7 radeon_kabini_mec_bin.ko
121 0x82a2d000 2a77 radeon_kabini_rlc_bin.ko
131 0x82a3 12e9 radeon_kabini_sdma_bin.ko
141 0x82a32000 12eb radeon_kabini_sdma1_bin.ko
151 0x82a3400038ea7 radeon_kabini_uvd_bin.ko
161 0x82a6d00018c47 radeon_kabini_vce_bin.ko
171 0x82a86000 2538 intpm.ko
181 0x82a89000  a50 smbus.ko
191 0x82a8a000 1820 uhid.ko
201 0x82a8c000 2928 ums.ko
211 0x82a8f000 1b00 wmt.ko
221 0x82a91000  acf mac_ntpd.ko
231 0x82a92000 a9f8 tmpfs.ko
clay@bsd13:~ $ kldload fuse
kldload: can't load fuse: Operation not permitted
clay@bsd13:~ $ su
Password:
root@bsd13:/home/clay # kldload fuse
kldload: can't load fuse: No such file or directory
---
The information I have on FUSE & fusefs is mostly from these sources:
https://forums.freebsd.org/threads/how-to-mount-ntfs-partition-from-same-hdd.62888/
http://kflu.github.io/2018/02/03/2018-02-03-freebsd-ntfs/

They seem to indicate there is a fuse.ko driver module that can be loaded
much like the drm-kmod video drivers. I don't see this on my install:
FreeBSD bsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r351591 GENERIC  amd64

I'm missing a few clues, and I don't understand the relation of the fuse
ports in the ports/emulators & ports/sysutil directories. There is nothing
mission critical, but any help would be a appreciated. I think it would be
handy to mount ntfs & ext partitions from my ufs FreeBSD partition.

Clay Daniels
___
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: Adding DRM modules to /etc/rc.conf for 13.0 Current r351363 (drm-current-kmod g20190814)

[Clay Daniels Jr.]

Oops, should be *hw.syscons.disable=1* in /boot/loader.conf

On Mon, Aug 26, 2019 at 8:56 PM Clay Daniels Jr. 
wrote:

> RE:
>   "In order to use these modules, you need to update the 'kld_list'
>lines in your rc.conf to just list the modules without a
>path, e.g. "kld_list=i915kms" just as you would for other
>modules.  This will prefer the module built with your kernel if
>one exists and fall back to the module in /boot/modules
>otherwise."
>
> WORKED GREAT, even with my kld_list="amdgpu" without the path, but I must
> add that I needed to add a line in /boot/loader.conf to work around the
> known AMD problem:
> hw.syscons/disable=1
>
> Clay Daniels
>
___
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"

Adding DRM modules to /etc/rc.conf for 13.0 Current r351363 (drm-current-kmod g20190814)

[Clay Daniels Jr.]

RE:
  "In order to use these modules, you need to update the 'kld_list'
   lines in your rc.conf to just list the modules without a
   path, e.g. "kld_list=i915kms" just as you would for other
   modules.  This will prefer the module built with your kernel if
   one exists and fall back to the module in /boot/modules
   otherwise."

WORKED GREAT, even with my kld_list="amdgpu" without the path, but I must
add that I needed to add a line in /boot/loader.conf to work around the
known AMD problem:
hw.syscons/disable=1

Clay Daniels
___
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: "amdgpu and radeonkms are known to fail with EFI Boot"

[Clay Daniels Jr.]

YES! YES! YES!

THANKS VERY, VERY MUCH EVERYONE, especially Greg & Evilham. It now works!!!

I had been fighting this problem for three weeks of 13.0 Current snapshots
and failed until now. I was never so glad to see that window load with the
three terminals & a clock. The rest is a piece of cake.

Thanks so much,
Clay Daniels

On Sat, Aug 24, 2019 at 3:14 PM Evilham  wrote:

>
> On ds., ag. 24 2019, Clay Daniels, Jr. wrote:
>
> > Greg, thanks for the wonderful suggestion. Where should I put
> > this line: "
> > hw.syscons.disable=1 "
> > I tried it in /etc/rc.conf and it booted into the console as
> > usual with
> > repeated messages:
> > /etc/rc.conf  hw.syscons.disable=1: not found
>
> I think that must go in /boot/loader.conf or just for one boot you
> can add it from the boot loader as a custom option with "set
> hw..." then "boot".
> --
> Evilham
> ___
> 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: "amdgpu and radeonkms are known to fail with EFI Boot"

[Clay Daniels Jr.]

Greg, thanks for the wonderful suggestion. Where should I put this line: "
hw.syscons.disable=1 "
I tried it in /etc/rc.conf and it booted into the console as usual with
repeated messages:
/etc/rc.conf  hw.syscons.disable=1: not found
I could login to the console as usual, but trying to run startx (as user)
still fails. Maybe there is some boot config file this goes in?

Thanks
Clay

On Sat, Aug 24, 2019 at 3:29 AM Greg V  wrote:

> On August 24, 2019 10:15:22 AM GMT+03:00, "Clay Daniels Jr." <
> clay.daniels...@gmail.com> wrote:
> >From the kmod ports, dated 20190814
> >
> >
> >/usr/ports/graphics/drm-current-kmod/pkg-descr
> >
> >"amdgpu and radeonkms are known to fail with EFI Boot"
> >
> >
> >/usr/ports/graphics/drm-current-kmod/pkg-message
> >
> >"some positive reports if EFI is not enabled"
> >
> >
> >Any practical suggestions on getting drm-current-kmod to work on an AMD
> >machine, including how to NOT enable EFI? I did not see that option on
> >the
> >install menu.
>
> "Not enabling" EFI means booting the installer in legacy more (CSM).
> Installer images are universal, so you'd have to instruct the firmware to
> ignore the EFI loader on there. Deleting the EFI partition might work I
> guess. rEFInd can force CSM boot a USB drive.
>
> I do not recommend this. Instead, there is a workaround for the EFI
> framebuffer conflict. If you have it (i.e. amdgpu fails to load, or hangs
> when starting GUI), boot with hw.syscons.disable=1. You won't see anything
> on the screen after the boot loader and before loading the driver :) but
> that's not a big deal when the driver autoloads successfully.
>
___
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"

"amdgpu and radeonkms are known to fail with EFI Boot"

[Clay Daniels Jr.]

>From the kmod ports, dated 20190814


/usr/ports/graphics/drm-current-kmod/pkg-descr

"amdgpu and radeonkms are known to fail with EFI Boot"


/usr/ports/graphics/drm-current-kmod/pkg-message

"some positive reports if EFI is not enabled"


Any practical suggestions on getting drm-current-kmod to work on an AMD
machine, including how to NOT enable EFI? I did not see that option on the
install menu.


Clay
___
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: HELP: UEFI/ZFS Boot failure: Ignoring Boot000A: Only one DP found

[Clay Daniels Jr.]

I would agree with Karl & Steffen about using rEFInd. It really gives you a
lot more control of your computers boot. Take a look at Rod Smith's pages:
http://www.rodsbooks.com/refind/

I use it to triple boot Windows 10, MX Linux, and FreeBSD.

Clay

On Wed, Aug 21, 2019 at 3:59 PM Karl Denninger  wrote:

> BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA256
> >
> > Am Wed, 21 Aug 2019 22:34:21 +0300
> > Toomas Soome  schrieb:
> >
> > >> On 21 Aug 2019, at 22:30, O. Hartmann  wrote:
> > >>
> > >> -BEGIN PGP SIGNED MESSAGE-
> > >> Hash: SHA256
> > >>
> > >> Am Wed, 21 Aug 2019 22:14:46 +0300
> > >> Toomas Soome mailto:tso...@me.com>> schrieb:
> > >>
> > >>> If you drop into efi shell, can you start efi/boot/bootx64.efi
> > manually? you should have
> > >>> fs0: or like for ESP.
> > >>>
> > >>> rgds,
> > >>> toomas
> > >>
> > >> Hello,
> > >>
> > >> I can't even stop to gain access to the shell; there is no
> > timeframe to hit any key to
> > >> stop by and access the efi shell.
> > >>
> > >> Kind regards,
> > >> oh
> >
> >
> > > hm? efi shell should be available from boot device menu, so you
> > mean, you can not even get
> > > into firmware setup?
> >
> > > rgds,
> > > toomas
> >
> > Sorry,
> > I confused loader prompt and EFI shell.
> >
> > I do not have a EFI shell on that type of laptop, not to know about
> > it. I can access the
> > firmware setup and already performed a reset and switched back to
> > default settings. No effect.
> >
> > I just downloaded the newest CURRENT mem stick and extracted both
> > boot1.efi and loader.efi and
> > installed those into the ESP as described, setting the efibootmgr env
> > accordingly. Still the
> > same error.
> >
> > It seems that there is indeed no EFI/UEFI shell. There are Lenovo
> > specific EFI boot options,
> > like "diagnostics" and so on, if selected, the UEFI boots into a
> > firmware embedded diagnostic
> > menu. I tried several from the list given via efibootmgr show -v, but
> > there is no shell from
> > which I could access/boot an alternative loader.
> >
> > How I'm supposed to achive the access to this EFI shell? I doubt that
> > on the E540 (beware of
> > the E, it is not a L or T model) does have such a shell.
> >
> > Regards,
> > oh
>
> I would see if you can get REFIND loaded and use that.  I have a Lenovo
> X1 Carbon Gen 6 and that's the answer I used, as it allows multi-boot
> (e.g. Win10 and FreeBSD) easily.
>
> I've not had trouble with 12.x on it, and I do use the
> geli-encrypted-aware loader.efi.
>
> If there's a way to get into the EFI shell on Lenovo's laptops from the
> BIOS during the boot I've not found it yet.  There's supposed to be on
> all EFI devices, but you know how "supposed to" works in many cases, right?
>
> --
> Karl Denninger
> k...@denninger.net 
> /The Market Ticker/
> /[S/MIME encrypted email preferred]/
>
>
>
___
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: Installing drm-current-kmod from ports

[Clay Daniels Jr.]

OK, making progress as it gives a new result:
Starts to load Xorg server
~
[drm] radeon kernel modesetting enabled
drmn0:  on vgapci0
panic: make_dev_alias_v: bad si_name
 (error=17, si_name=dri/renderD128)
cpuid=2
time=~
KDB: stackbacktrace
~
>db  [HALTS HERE - interactive mode]
 I entered help, it gave me a menu, I did a reboot there...

The fact I get a new result is an improvement. And I still see that "funny
fuzzy thick line" during bootup, which to me is a good sign too.

Like I say, I'm willing to back up and start again. I'm not going to give
up on this. It has worked for manyl weeks of 13.0-Current up until r350702.
I'm hooked on FreeBSD.

I was intending to load the LXDE desktop. I kind of like it as it's minimal
and I get to pick my own apps. But I have tried Gnome, KDE, & Xfce too. I
will probably try several more desktops. But if it doesn't work with the
basic Xorg page with the three Xterms & a clock, it will not load a fancy
desktop.

Thanks so much for your help, Graham

Clay

On Sun, Aug 18, 2019 at 3:59 PM Clay Daniels Jr. 
wrote:

> Graham, thanks for the reply. Since my original post on this thread last
> night, I went through the make install clean of the drm-current-kmod port.
> It didn't take too long, probably half an hour or so. It gave an exit
> message to put a line in /etc/rc.donf: kld_list="amdgpu" , which I did,
> rebooted and the same problem. I tried the complete path:
> kls_list="/boot/modules/amdgpu.ko"  but the same problem. I know that it's
> loading the amdgpu kmodule because when it is booting up and gets to the
> part of discovery of my Radeon/Kabini video it suddenly shows a "wide fuzzy
> line", right there in the console. The console message reads like I may
> have permissions issues, but that can't be true, because if I specify the
> older radeokms.ko it tries to load it and then hangs. So i have the right
> module.
>
> But what you just said about installing the xf86-video-ati sounds like
> good advice. The console error message is in /var/log/Xorg.0.~ and
> complains about being unable to load an "ati" module. I bet this might do
> it. My rather old computer is an HP Pavilion 23 all-in-one built & bought
> in 2014 with an AMD E2-3000 cpu with Radeon HD video. It's all clamped in a
> plastic frame and I've never looked inside myself. I intend to buy buy a
> new computer, and it will be in a tower case that you can easily get into,
> maybe with a clear glass or plastic side. I like to see the lights blink.
> And I have my heart set on a Threadripper...
>
> OK, I'm going to log off, re-boot into my FreeBSD partition, and try to
> install xf86-video-ati, probably from the ports, under graphics I guess.
>
> Thanks a lot,
> Clay
>
> On Sun, Aug 18, 2019 at 3:16 PM Graham Perrin 
> wrote:
>
>> On 18/08/2019 03:08, Clay Daniels Jr. wrote:
>> > … am I missing something else? …
>>
>> Re:
>> <
>> https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074074.html>
>>
>>
>>
>> If you haven't already done so, it's probably recommended to install
>> xf86-video-ati.
>>
>> What model is the HP?
>>
>> Will you use a desktop environment?
>>
>>
___
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: Installing drm-current-kmod from ports

[Clay Daniels Jr.]

Graham, thanks for the reply. Since my original post on this thread last
night, I went through the make install clean of the drm-current-kmod port.
It didn't take too long, probably half an hour or so. It gave an exit
message to put a line in /etc/rc.donf: kld_list="amdgpu" , which I did,
rebooted and the same problem. I tried the complete path:
kls_list="/boot/modules/amdgpu.ko"  but the same problem. I know that it's
loading the amdgpu kmodule because when it is booting up and gets to the
part of discovery of my Radeon/Kabini video it suddenly shows a "wide fuzzy
line", right there in the console. The console message reads like I may
have permissions issues, but that can't be true, because if I specify the
older radeokms.ko it tries to load it and then hangs. So i have the right
module.

But what you just said about installing the xf86-video-ati sounds like good
advice. The console error message is in /var/log/Xorg.0.~ and complains
about being unable to load an "ati" module. I bet this might do it. My
rather old computer is an HP Pavilion 23 all-in-one built & bought in 2014
with an AMD E2-3000 cpu with Radeon HD video. It's all clamped in a plastic
frame and I've never looked inside myself. I intend to buy buy a new
computer, and it will be in a tower case that you can easily get into,
maybe with a clear glass or plastic side. I like to see the lights blink.
And I have my heart set on a Threadripper...

OK, I'm going to log off, re-boot into my FreeBSD partition, and try to
install xf86-video-ati, probably from the ports, under graphics I guess.

Thanks a lot,
Clay

On Sun, Aug 18, 2019 at 3:16 PM Graham Perrin 
wrote:

> On 18/08/2019 03:08, Clay Daniels Jr. wrote:
> > … am I missing something else? …
>
> Re:
> <
> https://lists.freebsd.org/pipermail/freebsd-current/2019-August/074074.html>
>
>
>
> If you haven't already done so, it's probably recommended to install
> xf86-video-ati.
>
> What model is the HP?
>
> Will you use a desktop environment?
>
>
___
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"

Installing drm-current-kmod from ports

[Clay Daniels Jr.]

I've been reading the HEADSUP: drm-current-kmod thread, actually several
times, and since my pkg install of plain vanilla drm-kmod was a dud after
working for several weekly installs of 13.0-Current, it's clear I probably
need to make install from the ports, which I have installed, as well as the
sources. I must confess I have done pkg install xorg, but this can be
corrected if it needs to be make install xorg from ports.

Is simply navigating to /usr/ports/graphics/drm-current-kmod and running
"make install clean" the best next step, or am I missing something else?

I want to confess my relative ignorance, and thank Graham Perrin & Pete
Wright for their help on a previous post, 13.0 Current - r350702 exposed an
Xorg failure. I've moved on to this weeks r351067 and no longer think my
problem is with Xorg, but with my install of drm-*-kmod.

I'm willing to wipe my install & start fresh if need be. I sure like
gParted. It erases a lot of sins.

Clay
___
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: 13.0 Current - r350702 exposed a Xorg failure

[Clay Daniels Jr.]

Graham, I loaded yesterday's new 13.0 Current r351067 snapshot and
re-installed FreeBSD. The basic install went well, and I gave my user
operator, wheel, & video permissions. I loaded Xorg via the pkg install
route, all 172 packages. I installed the drm-kmod pkg too. I rebooted and
ran startx as user and it failed, basically did not create the .serverauth
file. I pressed forward and did the install of my desktop, LXDE, with it's
config files. Still no go. I have looked at your good suggestions and the
results are at the end of this message. I had to copy them to paper as best
I could.

I guess you saw John Baldwin's email of 13 Aug about the changes in
drm-kmod. I played with my /etc/rc.conf and set the line to leave out the
path (/boot/modules/), just "kld_list="amdgpu.ko". That didn't work either.
I was wondering at that point if Pete Wright may be on track with his
suggestion that the permissions were set to root, but I don't think so, as
it all seems to be user - user in the user home directory, root - wheel in
/usr/local/bin where start lives, and root-wheel in /boot/modules where the
kmod files are. Then I started playing with the /etc/rc.conf file and got
some interesting results.

My machine is an HP All in One thing manufactured in 2014. It has a AMD E3
processor with integrated Radeon graphics. I had been using the newer
"amdgpu.ko" module for some weeks, at least through installs of Gnome, KDE,
Xfce, and two or three weeks of LXDE and it worked fine. I tried first
using John Baldwin's sugestion to leave out the path. Thant didn't work,
and I really think this advice was for those who are 1. Installing from
ports, not pkg, and 2. Compiling these modules into their kernel. Neither
apply to me, at least not yet, but I'm always ready to try if needed.

This is where it gets real interesting: I tried the older "radeonkms.ko",
and rebooted. The loading messages did not look promising, but no real
errors either. When I ran startx, it tried to load. I got a white screen,
that changed to a blank one after "some" time, and was unresponsive. I had
to use the power button to shutdown  Bnd guess what? When I rebooted and
performed a post-mortum, it had created an .serverauth file. So it makes we
think the permissions are ok, but there are some problems with my machine
and the amd kmod files. I looked in /boot/modules and both amdgpu.ko &
radeonkms.ko had dates of Aug 11. So the problem keeps shifting, but I'm
working on it.

pkg info | grep kmod :
drm-current-kmod-4.16.g20190806 DRM Modules for the linuxkpi-base KMS
components
drm-kmod-g20190806 Metaport of DRM Modules for the linuxkpi-base KMS
components
gpu-firmware-g20190620

pciconf -lv | grep -C 3 display :
6 lines that confirm my video setup: Kabini/Radeon HD 8280/R3 series
AMD/ATI  VGA

grep PORTS_MODULES /etc/make.conf: FILE/DIRECTORY NOT FOUND

pkg rquery %e drm-kmod : Message about the basic DRM metaport, no hard
info, looks like a sales pitch :)

Anyway, I continue to work on this, one step at a time. Open to any & all
corrections and suggestions.

The base install of r351067 is good, and I installed ports this time, so I
may do a pkg delete drm-kmod and make it from the ports. Maybe it would
suit my machine better.

Clay

On Wed, Aug 14, 2019 at 3:09 AM Graham Perrin 
wrote:

> On 10/08/2019 04:56, Clay Daniels Jr. wrote:
> > drm-kmod was the same (g20190710)
>
> It's equally (if not more) important to consider what's installed by
> drm-kmod.
>
> Can you share output from these three commands?
>
> pkg info | grep kmod
>
> pciconf -lv | grep -C 3 display
>
> grep PORTS_MODULES /etc/make.conf
>
> Thanks.
>
> Also, FYI (to help understand the purpose of drm-kmod):
>
> pkg rquery %e drm-kmod
>
>
___
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-13.0-CURRENT 20190815-r351067 is online

[Clay Daniels Jr.]

 FreeBSD-13.0-CURRENT-amd64-20190815-r351067-disc1.iso.xz

___
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: 13.0 Current - r350702 exposed a Xorg failure

[Clay Daniels Jr.]

Thanks Pete, I did have the user in the video group, but I need to look
into the permissions issue. I have tried to install Xorg several times
since last Friday, including reverting to last weeks current, and never had
any luck. Right now the FreeBSD partition is wiped clean. The new snapshot
will be out day after tomorrow, but I may have time to try again before
that. I certainly will let you know when I get this solved. It may be I
would have better luck if I compiled the Xorg ports rather than just
installing the binaries. But thanks for the advice. It cheers me up.

Clay

On Mon, Aug 12, 2019 at 9:49 PM Pete Wright  wrote:

>
>
> On 8/9/19 8:56 PM, Clay Daniels Jr. wrote:
> > I was eager to load the new 13.0 Current snapshot yesterday as I wanted
> to
> > play with the new FUSE tools. I was running 13.0 Current r350491 from
> last
> > week and everything was going great. So last night, a little late I
> guess,
> > I wiped the older install and loaded r250702. Then I loaded Xorg, all 172
> > packages, and loaded the drm-kmod video driver kernel modules, and then
> ran
> > startx (as user of course). I got errors & it was late so today I looked
> > closer. It said:
> > "xauth: file .serverauth.1039 does not exist"
> >
> > Well, this file is apparently something created automatically. I played
> > with the half-running install for a long time. It ran fine in console
> mode.
> > Then I the wiped it and reloaded the same newer r350702. No Go.
> >
> > Wiped the new r350702 and reloaded the older r350491 that was working
> just
> > fine last night. Same Problemserverauth.xxx
> >
> > Now, I do know that the drm-kmod was the same (g20190710) that had worked
> > for me at least two times already. I do not know if the Xorg pkg is the
> > same. I couldn't find a date other than "latest". I'm writing this email
> > from my Linux partition.
> first thing that comes to mind, did you make sure to add your user to
> the "video" group?  this doesn't sound related though...this does sound
> like a local configuration issue.  iirc when i ran into this problem in
> the past it was due to permissions, either a .serverauth file owned by
> root or a UID that no longer exists.
>
> -p
>
> --
> Pete Wright
> p...@nomadlogic.org
> @nomadlogicLA
>
>
___
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"

13.0 Current - r350702 exposed a Xorg failure

[Clay Daniels Jr.]

I was eager to load the new 13.0 Current snapshot yesterday as I wanted to
play with the new FUSE tools. I was running 13.0 Current r350491 from last
week and everything was going great. So last night, a little late I guess,
I wiped the older install and loaded r250702. Then I loaded Xorg, all 172
packages, and loaded the drm-kmod video driver kernel modules, and then ran
startx (as user of course). I got errors & it was late so today I looked
closer. It said:
"xauth: file .serverauth.1039 does not exist"

Well, this file is apparently something created automatically. I played
with the half-running install for a long time. It ran fine in console mode.
Then I the wiped it and reloaded the same newer r350702. No Go.

Wiped the new r350702 and reloaded the older r350491 that was working just
fine last night. Same Problemserverauth.xxx

Now, I do know that the drm-kmod was the same (g20190710) that had worked
for me at least two times already. I do not know if the Xorg pkg is the
same. I couldn't find a date other than "latest". I'm writing this email
from my Linux partition.

Any ideas would be appreciated,

Clay Daniels
___
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: FUSE Call for Testing

[Clay Daniels Jr.]

Damjan, thanks for the suggestion. I did like Alan suggested and:

clay@bsd13:~ % pkg info -r fusefs-libs
pkg: No package(s) matching fusefs-libs
clay@bsd13:~ % pkg info -r fusefs-libs3
pkg: No package(s) matching fusefs-libs3

I'm sitting here looking at a pkg search fuse in LXTerminal and I see:
fusefs-ntfs-2017.3.23  Mount NTFS partitions (read/write) and disk
images
fusefs-ext2-0.0.10_2   FUSE module to mount ext2, ext3 and ext4
with read write support

I triple boot with MS Windows 10, MX Linux, and FreeBSD 13.0, so I could
certainly make use of those tools.

I just now copied all the files I wanted to save from this installation to
a thumbdrive, and now downloading r350702. I will report back later.

Clay

On Fri, Aug 9, 2019 at 12:25 AM Damjan Jovanovic 
wrote:

> NTFS-3G (sysutils/fusefs-ntfs) is probably the most widely used FUSE
> filesystem.
>
> On Fri, Aug 9, 2019 at 4:21 AM Clay Daniels Jr. 
> wrote:
>
>> Alan, I'm pretty much into 13.0 Current and most weeks install the newest
>> snapshot build. I don't know if I use FUSE or not, if you must know the
>> truth. I do some hobby coding, lurk here on the email lists and Forum, and
>> try to learn all I can. So do you have any specific suggestions for
>> programs to install and test FUSE? I kind of like the no-x console & the
>> Xterminal window too, and dabble with clang cc (strictly C, no C++) and
>> Python too. Let me know.
>>
>> Clay Daniels
>>
>> On Thu, Aug 8, 2019 at 1:36 PM Alan Somers  wrote:
>>
>> > The new FUSE driver has just landed in current. It raises the protocol
>> > level from 7.8 to 7.23, fixes many bugs, adds a test suite for the
>> > driver, and adds many new features. New features include:
>> >   * Optional kernel-side permissions checks (-o default_permissions)
>> >   * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
>> >   * Allow interrupting FUSE operations
>> >   * Support named pipes and unix-domain sockets in fusefs file systems
>> >   * Forward UTIME_NOW during utimensat(2) to the daemon
>> >   * kqueue support for /dev/fuse
>> >   * Allow updating mounts with "mount -u"
>> >   * Allow exporting fusefs file systems over NFS
>> >   * Server-initiated invalidation of the name cache or data cache
>> >   * Respect RLIMIT_FSIZE
>> >   * Try to support servers as old as protocol 7.4
>> >
>> >   Performance enhancements include:
>> >
>> >   * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
>> >   * Cache file attributes
>> >   * Cache lookup entries, both positive and negative
>> >   * Server-selectable cache modes: writethrough, writeback, or uncached
>> >   * Write clustering
>> >   * Readahead
>> >   * Use counter(9) for statistical reporting
>> >
>> > Now would be a good time for the community to test it.  If you are
>> > BCCed to this email, it's because you maintain a FUSE-related port.
>> > Please test your port on the latest FreeBSD CURRENT image and let me
>> > know if you have any problems or find any bugs.
>> >
>> > Even if you don't maintain a FUSE port, you can still help.  If you
>> > use current and commonly use any FUSE file systems, please try them
>> > out after upgrading to the latest image.
>> >
>> > Additionally, the following FUSE-related ports don't have maintainers.
>> > If you use one of them, or know somebody who does, please test them on
>> > current, and consider adopting the port:
>> > deskutils/kdeconnect-kde
>> > devel/gvfs
>> > devel/py-fusefs
>> > sysutils/fusefs-afuse
>> > sysutils/fusefs-chironfs
>> > sysutils/fusefs-cryptofs
>> > sysutils/fusefs-funionfs
>> > sysutils/fusefs-fusepak
>> > sysutils/fusefs-httpfs
>> > sysutils/fusefs-s3backer
>> > sysutils/fusefs-sqlfs
>> > sysutils/fusefs-zip
>> > sysutils/p5-Brackup
>> > sysutils/p5-Fuse
>> >
>> > VM images:
>> >
>> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/
>> > ISOs:
>> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/
>> >
>> > Thanks for any feedback you can give!
>> > -Alan
>> > ___
>> > 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
>> "
>>
>
___
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: FUSE Call for Testing

[Clay Daniels Jr.]

Alan, I'm pretty much into 13.0 Current and most weeks install the newest
snapshot build. I don't know if I use FUSE or not, if you must know the
truth. I do some hobby coding, lurk here on the email lists and Forum, and
try to learn all I can. So do you have any specific suggestions for
programs to install and test FUSE? I kind of like the no-x console & the
Xterminal window too, and dabble with clang cc (strictly C, no C++) and
Python too. Let me know.

Clay Daniels

On Thu, Aug 8, 2019 at 1:36 PM Alan Somers  wrote:

> The new FUSE driver has just landed in current. It raises the protocol
> level from 7.8 to 7.23, fixes many bugs, adds a test suite for the
> driver, and adds many new features. New features include:
>   * Optional kernel-side permissions checks (-o default_permissions)
>   * Implement VOP_MKNOD, VOP_BMAP, and VOP_ADVLOCK
>   * Allow interrupting FUSE operations
>   * Support named pipes and unix-domain sockets in fusefs file systems
>   * Forward UTIME_NOW during utimensat(2) to the daemon
>   * kqueue support for /dev/fuse
>   * Allow updating mounts with "mount -u"
>   * Allow exporting fusefs file systems over NFS
>   * Server-initiated invalidation of the name cache or data cache
>   * Respect RLIMIT_FSIZE
>   * Try to support servers as old as protocol 7.4
>
>   Performance enhancements include:
>
>   * Implement FUSE's FOPEN_KEEP_CACHE and FUSE_ASYNC_READ flags
>   * Cache file attributes
>   * Cache lookup entries, both positive and negative
>   * Server-selectable cache modes: writethrough, writeback, or uncached
>   * Write clustering
>   * Readahead
>   * Use counter(9) for statistical reporting
>
> Now would be a good time for the community to test it.  If you are
> BCCed to this email, it's because you maintain a FUSE-related port.
> Please test your port on the latest FreeBSD CURRENT image and let me
> know if you have any problems or find any bugs.
>
> Even if you don't maintain a FUSE port, you can still help.  If you
> use current and commonly use any FUSE file systems, please try them
> out after upgrading to the latest image.
>
> Additionally, the following FUSE-related ports don't have maintainers.
> If you use one of them, or know somebody who does, please test them on
> current, and consider adopting the port:
> deskutils/kdeconnect-kde
> devel/gvfs
> devel/py-fusefs
> sysutils/fusefs-afuse
> sysutils/fusefs-chironfs
> sysutils/fusefs-cryptofs
> sysutils/fusefs-funionfs
> sysutils/fusefs-fusepak
> sysutils/fusefs-httpfs
> sysutils/fusefs-s3backer
> sysutils/fusefs-sqlfs
> sysutils/fusefs-zip
> sysutils/p5-Brackup
> sysutils/p5-Fuse
>
> VM images:
> http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/VM-IMAGES/13.0-CURRENT/amd64/20190808/
> ISOs: http://ftp0.nyi.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/
>
> Thanks for any feedback you can give!
> -Alan
> ___
> 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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Clay Daniels Jr.]

Rodney, you are right that the .iso "should work", and a lot of other
projects, from Microsoft Windows 10 to Trident BSD only a furnish an iso,
and no img file. FreeBSD is one of the few that give you both choices. The
problem goes deeper than any one operating system. If you've ever used the
Rufus tool to make a bootable usb, which is all Rufus does, you may have
come across problems with "mount root". I found this article, answered by a
Rufus developer very enlightening.
https://superuser.com/questions/1170832/why-are-there-different-options-for-creating-bootable-usb-compared-to-a-cd

I have a collection of usb thumbdrives here at my desk, and use them a lot,
but I also bought me some blank dvd disks and use them too.

But I think you are right, Nick Wolff's problem may be a a bug to be
reported. All I know is I took the same file,
FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso

, burned it to a dvd, and I'm now writing this email from the FreeBSD
13.0-CURRENT r350322 partition of my computer.

Clay
___
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: Boot still broken from r349133-r349160 - Was re:(Problem with USB after r349133)

[Clay Daniels Jr.]

The .iso files are for a dvd install. If you want to use a usb, download
the .img files.

FreeBSD-13.0-CURRENT-amd64-20190725-r350322-memstick.img


( or get the .xz version and extract it on your machine - it's smaller)

This "mount root" problem got me too, so don't feel alone.

Clay
clay@fbsd13:~ $ uname -a
FreeBSD fbsd13 13.0-CURRENT FreeBSD 13.0-CURRENT r350322 GENERIC  amd64


On Mon, Jul 29, 2019 at 4:03 PM Nick Wolff  wrote:

> I just tested the snapshot from 20190725 and still am getting the root
> mount rating for "boot on boot. I think something deeper broke between
> r349133 and r349160 because even when I turn off wait for Root Mount on usb
> root via a loader variable boot just get's stuck later on in the process.
>
> This is all happening on an x11-dpi-nt board.
>
>
> http://ftp.freebsd.org/pub/FreeBSD/snapshots/ISO-IMAGES/13.0/FreeBSD-13.0-CURRENT-amd64-20190725-r350322-disc1.iso
>
> On Mon, Jul 22, 2019 at 12:57 PM Nick Wolff 
> wrote:
>
> > Hans,
> >
> > I'm building r350003  at the moment which is after the acpi change was
> > moved into an unloaded module.
> >
> >
> >
> > On Mon, Jul 22, 2019 at 12:13 PM Hans Petter Selasky 
> > wrote:
> >
> >> On 2019-07-22 17:23, Nick Wolff wrote:
> >> > Sorry for email spam but I was wrong. Just gets stuck now during
> >> reproping
> >> > a pci device after init happens(this is actually a trueos build which
> is
> >> > why you see openrc). That device it's getting stuck on is "Sky Lake-E
> >> CBDMA
> >> > Registers" which shouldn't have a driver attached.
> >> >
> >>
> https://drive.google.com/file/d/19NFI0Dcupu3ZcVxbcr2vYFZ-iDqiIzkx/view?usp=sharing
> >> >
> >> > Though it maybe something else getting stuck at this point and that
> just
> >> > happens to be the last thing on the screen.
> >> >
> >>
> >> There was a recent change to add an ACPI wrapper for the USB HUB driver,
> >> but that was a bit premature and introduced some bugs. For now the ACPI
> >> USB HUB wrapper is not enabled by default. Do you experience issues with
> >> the latest -current ?
> >>
> >> --HPS
> >>
> >>
> ___
> 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"