Re: FreeBSD-provided .vhd with VirtualBox: gpart I/O errors after resizing the virtual hard disk

[Mark Millard via freebsd-current]

Graham Perrin grahamperrin at gmail.com wrote on
Mon Jan 25 22:08:53 UTC 2021 :

. . . omitted material, including steps 01..13 . . .

Your steps 01..13 make no mention of involving growfs
as indicated in "man 8 growfs". I'd guess that the
growfs step would be after step 8 (recover) and before
10 (show). (FYI: There is also a "man 7 growfs".)

> With FreeBSD-provided 'FreeBSD-12.1-RELEASE-amd64.vhd', things seem even 
> worse. Please see, for example, this screen recording:
> 
> 
> 
> What's going wrong?
> 
> Is it necessary to boot first from something _other_ than the resized 
> disk, for things such as gpart recover to proceed without I/O error for 
> the resized disk?

I looked at the screen recording's playback and . . .

You have made no mention of the cylinder checksum failure notices
or at what stage they first occurred. That might be important.
I've no clue if they might be an initial cause of issues vs.
them being an effect that might also contribute to later issues
when the checksums fail.

Unfortunately, it does not look like "man fsck_ffs" covers its
cylinder checksum failure handling:

** Phase 5 - Check Cyl groups

(At least I presume that phase is related to what the failure
notices are reporting.)

I'm afraid I'm of no general help but it looked like some extra
information might be appropriate --or the man 8 or 7 growfs
related activity being involved might avoid later getting cylinder
checksum failure notices.

I hope this proves of some help, but, if it is not, I'm unlikely
to have more information, sorry.

===
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"

Re: Can't fetch https://www.freebsd.org/releng/index.html

[Lev Serebryakov]

On 27.01.2021 3:40, KIRIYAMA Kazuhiko wrote:


I've been used https://www.freebsd.org/releng/index.html to know about
latest FreeBSD updateing status for my many applications. I found that
index.html can't fetch yesterday.

Is there anyone to tell me how to get latest FreeBSD updateing status
information with source file ?


  https://www.freebsd.org/releng/ ?

 But I'm disappointed, that new page doesn't conttain dates of all old releases 
in one neat table. I've used this table a lot :)

--
// Lev Serebryakov
___
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"

Can't fetch https://www.freebsd.org/releng/index.html

[KIRIYAMA Kazuhiko]

Hi all,

I've been used https://www.freebsd.org/releng/index.html to know about
latest FreeBSD updateing status for my many applications. I found that
index.html can't fetch yesterday.

Is there anyone to tell me how to get latest FreeBSD updateing status
information with source file ?
---
Kazuhiko Kiriyama 
___
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: FYI: Why META_MODE rebuilds so much for building again after installworld (no source changes)

[Mark Millard via freebsd-current]

On 2021-Jan-23, at 21:37, Mark Millard  wrote:

> On 2021-Jan-22, at 01:45, Mark Millard  wrote:
> 
>> Given an already built, installed and booted system version, I've
>> noted a big difference for META_MODE in 2 rebuild contexts (no
>> source updates involved):
>> 
>> *) Prior buildworld buildkernel, installkernel, installworld, boot
>>  presumed before (A) and before (B) below.
>> 
>> A) make . . . buildworld buildkernel
>>  make . . . buildworld buildkernel
>>  (the 2nd buildworld buildkernel in (A) builds far less than the first)
>>  (that means that the first built more than I would have guessed)
>> 
>> vs.
>> 
>> B) make . . . buildworld buildkernel
>>  make . . . installworld
>>  make . . . buildworld buildkernel
>>  (the 2nd buildworld buildkernel in (B) builds far more than it did in (A))
>>  (so, more like the 1st buildworld buildkernel in (A) and (B), given
>>   the specified prior context)
>> 
>> So I used make -dM for the commented buildworld buildkernel lines, logging
>> the build output and later diff'ing them.
>> 
>> Result that I noticed? Lots of lines uniquely from (B)'s case, ending with
>> one of:
>> 
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/awk'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cap_mkdb'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cat'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/cp'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/crunchgen'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/crunchide'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/dd'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/egrep'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/env'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/file2c'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/gencat'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/grep'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/gzip'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/jot'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/lex'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/ln'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/m4'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/mv'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/patch'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/rm'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/sed'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/sh'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/touch'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/truncate'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uudecode'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/uuencode'
>>  is newer than the target...
>> file 
>> '/usr/obj/amd64_clang/amd64.amd64/usr/fbsd/mm-src/amd64.amd64/tmp/legacy/usr/sbin/xargs'
>>  is newer than the target...
>> 
>> The lines with these lead to more files being updated and so causing more
>> indirect rebuild activity (that cascades).
>> 
>> Many/most/all(?) of these seem to me to be unlikely to actually need to
>> contribute to what needs to be rebuilt (just based on being newer). So

Re: fsck strange output

[Kirk McKusick]

> From: Rozhuk Ivan 
> Date: Tue, 26 Jan 2021 17:08:41 +0300
> To: Kirk McKusick 
> Cc: freebsd-current@freebsd.org
> Subject: Re: fsck strange output
> 
> On Mon, 25 Jan 2021 15:40:12 -0800
> Kirk McKusick  wrote:
> 
> 
>> Please try this patch to fsck_ffs and see if it fixes your problem.
>> 
>>  Kirk McKusick
>> 
>> =-=-=
>> 
>> *** sbin/fsck_ffs/inode.c.orig   2021-01-07 15:04:04.969086284
>> -0800 --- sbin/fsck_ffs/inode.c  2021-01-25 15:29:06.404803358
>> -0800 ***
>> *** 611,618 
>>  sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode)); readpercg = inosused / fullcnt;
>>  partialcnt = inosused % fullcnt;
>> !partialsize = partialcnt * ((sblock.fs_magic ==
>> FS_UFS1_MAGIC) ? !   sizeof(struct ufs1_dinode) :
>> sizeof(struct ufs2_dinode)); if (partialcnt != 0) {
>>  readpercg++;
>>  } else {
>> --- 611,619 
>>  sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode)); readpercg = inosused / fullcnt;
>>  partialcnt = inosused % fullcnt;
>> !partialsize = fragroundup(,
>> !partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
>> !sizeof(struct ufs1_dinode) : sizeof(struct
>> ufs2_dinode))); if (partialcnt != 0) {
>>  readpercg++;
>>  } else {
> 
> 
> https://github.com/rozhuk-im/freebsd/commit/5e8bfa01830e2b6ecb88e572064c6fffe5a2df2d
> (if I apply correct :) )
> 
> With this patch - seems no errors, thanks!

Thanks for your testing. It has also corrected the same problem in
Peter Holm's test suite. So, I am committed it as 8c22cf9. I will
also ensure that it gets MFC'ed into 13.0.

Kirk McKusick
___
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: loading drm crashes system

[Robert Huff]

Me:

>   Try September 26 as a reference date.

s/September 26/September 6/ ; src = r365372


Respectfully,


Robert "Gotcha, ya little bugger!" 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: loading drm crashes system

[Tijl Coosemans]

On Mon, 25 Jan 2021 22:21:16 -0500 Robert Huff 
wrote:
> Niclas Zeising asks:
> 
> >   Which version of drm-current-kmod?  
> 
>   5.4.62.g20210118
> 
> >   Can you try to remove it and build it directly from an updated ports 
> >   tree, without using PORTS_MODULES=, and see if that helps?  
> 
>   It does not.
> 
> >   > The GPU is a Radeon HD 3300, and at one point this used to 
> > work.  
> >   
> >   When did it stop working?  
> 
>   September ... I _think_.
>   After the switch from sc to vt+drm, things worked for a while
> ... then they didn't for several months ... then - September??? - they
> worked for about two weeks ... then they didn't again.

September 10 is when drm-current-kmod was updated from 4.16 to 5.4:
https://svnweb.freebsd.org/ports/head/graphics/drm-current-kmod/Makefile
There haven't been that many updates since then so you could test
ports r548210 with base system from the same date.  If that works try
r548601, r551266 and r554720.
___
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: loading drm crashes system

[Tijl Coosemans]

On Tue, 26 Jan 2021 13:42:45 +0100 Emmanuel Vadot
 wrote:
> On Tue, 26 Jan 2021 07:02:11 +
> Alexey Dokuchaev  wrote:
>> On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote:  
>>> Niclas Zeising asks:  
 When did it stop working?  
>>> 
>>> September ... I _think_.  
>> 
>> Yeah, that sounds about right.
>> 
>> There are known issues with Radeon cards, they were quite well supported
>> a year ago, then something got broken.  I've promised to bisect this and
>> find the cause, but there were several syscall-related changes in -CURRENT
>> though the course of the last year, so bisecting just the kernel is not
>> enough (machine won't get to login prompt if the userland does not match),
>> which cripples the process.
>> 
>> I still intend to take this quest, just not sure when. :(
> 
>  So back in November I applied a few commits from tijl@ related to
> radeon and i386 (added to cc) :
> https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org
> 
>  For me this fixed radeon so that gives some timeline if someone with
> non working hardware wants to bisect.
>  I know that bisecting drm-kmod is somewhat hard as you always need
> matching kernel code when we update it to use some new functionality in
> base linuxkpi but there is nothing that I can do about it.
>  It might work and be quicker to only bisect the kernel with a
> stable/12 userland (no need to recompile) so I would start by testing a
> kernel from early november and same date for drm-kmod.
> 
>  Tijl since you also reported a build failure a few days/weeks ago for
> radeon can you report if your radeon card works ? (And which one it is).

My card works (14.0-CURRENT from last Sunday) but it is an old radeon
9700 from 2004 so it doesn't have any fancy modern features and uses
only a small part of the radeon driver.
___
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: problem building virtualbox-ose-kmod

[Guido Falsi via freebsd-current]

On 26/01/21 13:29, Dima Panov wrote:

Moin!

Stefan, please add check for __FreeBSD_version and fill PR or commit it 
directly with ports-secteam approval.



There's a bug report for this:

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

And another one which is marked as a duplicate of this. In the duplicate 
I posted a patch including the __FreeBSD_version check.


Since you just gave approval for that I'll go ahead and commit, it 
should also be merged to 2021Q1, since it affects 13.


--
Guido Falsi 
___
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: fsck strange output

[Rozhuk Ivan]

On Mon, 25 Jan 2021 15:40:12 -0800
Kirk McKusick  wrote:


> Please try this patch to fsck_ffs and see if it fixes your problem.
> 
>   Kirk McKusick
> 
> =-=-=
> 
> *** sbin/fsck_ffs/inode.c.orig2021-01-07 15:04:04.969086284
> -0800 --- sbin/fsck_ffs/inode.c   2021-01-25 15:29:06.404803358
> -0800 ***
> *** 611,618 
>   sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
>   partialcnt = inosused % fullcnt;
> ! partialsize = partialcnt * ((sblock.fs_magic ==
> FS_UFS1_MAGIC) ? !sizeof(struct ufs1_dinode) :
> sizeof(struct ufs2_dinode)); if (partialcnt != 0) {
>   readpercg++;
>   } else {
> --- 611,619 
>   sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode)); readpercg = inosused / fullcnt;
>   partialcnt = inosused % fullcnt;
> ! partialsize = fragroundup(,
> ! partialcnt * ((sblock.fs_magic == FS_UFS1_MAGIC) ?
> ! sizeof(struct ufs1_dinode) : sizeof(struct
> ufs2_dinode))); if (partialcnt != 0) {
>   readpercg++;
>   } else {


https://github.com/rozhuk-im/freebsd/commit/5e8bfa01830e2b6ecb88e572064c6fffe5a2df2d
(if I apply correct :) )

With this patch - seems no errors, thanks!

___
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: svnlite behaviour changed?

[M - Krasznai András]

Thanks!

I did not make it very clear but the whole thing started when I used 
FreeBSD-CURRENT - that is sometime in December I observed that although the 
revision number is increased, there are no updates listed; the fact that the 
revision number is the revision of the whole repository and not the revision of 
the branch I follow explains. There was some kind of source freeze of the 
CURRENT branch if I recollect correctly the release schedule. A week ago I 
installed FreeBSD-12.2-RELEASE, but its source changes rather rarely so I again 
I got only increasing revision numbers.

Thanks again!

best regards

András Krasznai
 

 

From: David Wolfskill 
Sent: Tuesday, January 26, 2021 12:55 PM
To: M - Krasznai András
Cc: freebsd-current
Subject: Re: svnlite behaviour changed?

On Tue, Jan 26, 2021 at 09:52:15AM +, M - Krasznai András wrote:
> Good morning!
>
> I regularly sync my FreeBSD source tree with the central repository using svn 
> update. I use a one-lis script to synchonize, which  sends the output of svn 
> to a file, and also copies to the console. This list contained - according to 
> the 'svn help update' - one line for any item which was updated or inserted, 
> deleted etc and at the end it shows the (new) revision number of the 
> repository.
>
> Some time ago during december this changed: the svn output contained one line 
> only, which informed me the new revision number but I did not get listing of 
> the updated items. If there are no updated items then why is the revision 
> number increasing, or if there are updates the why aren't they listed?
>
> A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn 
> update changes the revision number of the source tree, and the newly compiled 
> kernel has that revision number, but no listing of updates.  svn checkout 
> listed the files as they were read from the central repository.
>
> Is this a change of svn while the help text remained the old one,  or there 
> is a change in the svn repositories, or is this part of the move to git?
> Üdvözlettel
>
> Krasznai András
> rendszermérnök

First, please note that this list is "freebsd-current@" -- by
definition, a "release" (such as FreeBSD-12.2-RELEASE) is not "current."

Second, the revision number at the end of "svn update" is the last
revision for the entire repository -- which is NOT the same thing as
"the last revision for the branch" (that you are using).

Thus, if there are changes to other branches (but not the one you are
tracking), the revision number reported will continue to go up, but
there will be no changes to the files in your branch.

Finally, please be aware that the svn repository is no longer the
"Source of Truth" for FreeBSD.  Rather, for (recent) stable branches (<=
12), committed changes to the Source of Truth are subsequently
"replayed" into the subversion repository.  As I understand it, there
are no plans to provide this for stable/13 or subsequent branches (or
for current).

Peace,
david
--
David H. Wolfskill  da...@catwhisker.org
Some "Republicans" seem bound and determined to turn the party known for
touting "law and order" into one that supports mob rule and insurrection.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.
___
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: loading drm crashes system

[Robert Huff]

Hello:

>   > Niclas Zeising asks:
>   > > When did it stop working?
>   > 
>   > September ... I _think_.
>   
>   Yeah, that sounds about right.
>   
>   There are known issues with Radeon cards, they were quite well
>   supported a year ago, then something got broken.  I've promised to
>   bisect this and find the cause, but there were several syscall-related
>   changes in -CURRENT though the course of the last year, so bisecting
>   just the kernel is not enough (machine won't get to login prompt if
>   the userland does not match), which cripples the process.
>   
>   I still intend to take this quest, just not sure when. :(

Expanding on "September ... I think":
Try September 26 as a reference date.  Sometime close to then I
a) updated world+kernel to the latest version of current, so also b)
updated to the latest drm-current-kmod and gpu-firmware.
Question: is there a way for the less sophisticated user 
to tell whether the cause is in the drm knod or the firmware kmod?


Hope this helps,


Robert Huff

-- 
Hello ... my name is SARS-CoV-2.
You are not wearing a mask?
Prepare to die!
___
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 and Radeon

[Marek Zarychta]

W dniu 26.01.2021 o 10:15, Toomas Soome pisze:



On 26. Jan 2021, at 10:18, Marek Zarychta 
> wrote:


W dniu 26.01.2021 o 08:58, Graham Perrin pisze:

On 26/01/2021 07:02, Alexey Dokuchaev wrote:
> Re: loading drm crashes system
> … There are known issues with Radeon cards, they were quite well
> supported a year ago, then something got broken. I've promised to
> bisect this and find the cause, but there were several
> syscall-related changes in -CURRENT though the course of the last
> year, so bisecting just the kernel is not enough (machine won't get
> to login prompt if the userland does not match), which cripples the
> process.
>
> I still intend to take this quest, just not sure when. :(
>
> ./danfe
Any cards in particular?
> 
– whilst I didn't mention Radeon there, for me it _was_ the Radeon 
story that seemed to improve a few months ago.
> AMD Thames 
[Radeon HD 7550M/7570M/7650M]




For example old RS880 [Radeon HD 4200]. After deprecation of 
graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 
12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While 
trying the driver from graphics/drm-fbsd12.0-kmod I was not able to 
use this card with gdm, only startx or x11/slim worked. On 13-ALPHA 
this card still works fine with deprecated graphics/drm-legacy-kmod.





Does X11 cliegdm start X in specific way? I mean, afaik, gdm is nt as 
any other, so the question would be, how does gdm get Xorg started, 
what is different compared to startx etc? Might it be about gdm user 
permissions to access drm devices?


my 2cents..
toomas


Thanks for the clue, I added user gdm to the group video, but nothing 
changed.


Gdm starts, after some delay, but there is no visible username/ password 
prompt or it's beyond the viewable area, on the other hand, the viewable 
area seems to fit the screen correctly. To start gdm I have to wait a 
while until something happens with the resolution of text in the 
console. I have to mention that with this driver, the vty console 
resolution changes a while after loading the driver and starting all 
services (usually it lasts one minute or less after services startup) 
and after this time the text on vty can be seen in a kind of window 
covering: on first monitor 50% of the screen in left upper corner and on 
the second monitor, the viewable area of text console exceeds screen 
dimensions, but on both the text in console looks blurry.


Please don't get it wrong it's nether  EFI nor boot loader problem since 
this is an old machine with BIOS only and I am booting FreeBSD on this 
with GRUB2 (booting, not chainloading). With /boot/kernel/radeonkms.ko 
or radeonks.ko from deprecated graphics/drm-legacy-kmod everything looks 
fine on vty on both monitors and login and password prompt for gdm 
appears correctly. So this is not only gdm issue.


I have tested drm-current-kmod with fresh 14-CURRENT sources and indeed, 
it panicked for me. I have installed deprecated drm-legacy-kmod and it 
works fine with this old HW and 14-CURRENT.


While writing this post I am using:

FreeBSD 14.0-CURRENT #3 main-c256281-g25cdacf79b0

drm-legacy-kmod-g20200825

gpu-firmware-kmod-g20201213


--
Marek Zarychta

___
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: loading drm crashes system

[Emmanuel Vadot]

On Tue, 26 Jan 2021 07:02:11 +
Alexey Dokuchaev  wrote:

> On Mon, Jan 25, 2021 at 10:21:16PM -0500, Robert Huff wrote:
> > Niclas Zeising asks:
> > > When did it stop working?
> > 
> > September ... I _think_.
> 
> Yeah, that sounds about right.
> 
> There are known issues with Radeon cards, they were quite well supported
> a year ago, then something got broken.  I've promised to bisect this and
> find the cause, but there were several syscall-related changes in -CURRENT
> though the course of the last year, so bisecting just the kernel is not
> enough (machine won't get to login prompt if the userland does not match),
> which cripples the process.
> 
> I still intend to take this quest, just not sure when. :(
> 
> ./danfe

 So back in November I applied a few commits from tijl@ related to
radeon and i386 (added to cc) :
https://github.com/freebsd/drm-kmod/commits/5.4-lts?author=t...@coosemans.org

 For me this fixed radeon so that gives some timeline if someone with
non working hardware wants to bisect.
 I know that bisecting drm-kmod is somewhat hard as you always need
matching kernel code when we update it to use some new functionality in
base linuxkpi but there is nothing that I can do about it.
 It might work and be quicker to only bisect the kernel with a
stable/12 userland (no need to recompile) so I would start by testing a
kernel from early november and same date for drm-kmod.

 Tijl since you also reported a build failure a few days/weeks ago for
radeon can you report if your radeon card works ? (And which one it is).

 Cheers,

-- 
Emmanuel Vadot 
___
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: problem building virtualbox-ose-kmod

[Dima Panov]

Moin!

Stefan, please add check for __FreeBSD_version and fill PR or commit it 
directly with ports-secteam approval.

--
Dima. (desktop, kde, x11, office, ports-secteam)@FreeBSD team
(flu...@freebsd.org, https://t.me/dima_panov)

> On Tuesday, Jan 26, 2021 at 8:37 PM, Stefan Esser  (mailto:s...@freebsd.org)> wrote:
> Am 26.01.21 um 07:34 schrieb monochrome:
> > having this issue building virtualbox-ose-kmod, its been like this for a
> > while but I deinstalled and forgot, for quite a while now, maybe over a
> > month. now that I've moved from 13-current to stable/13 I thought I
> > would try to put it back, but it still wont build. I haven't seen anyone
> > else with this problem, did I miss a memo?
>
> I have sent a patch to vbox@on 2020-01-16, but only received an
> automatic reply that it had to be accepted by the moderator of the
> list (and never got any further reply or reaction on it).
>
> The signature of vm_map_protect() has changed, but the port has not
> been updated.
>
> Here is the patch in case the attachment gets stripped (but probably
> with messed-up white-space):
>
> Index: files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> ===
> --- files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> (revision 561738)
> +++ files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
> (working copy)
> @@ -421,7 +421,8 @@
> @@ -826,6 +885,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(PRTR0MEMOBJINT
> ProtectionFlags |= VM_PROT_EXECUTE;
>
> - int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, FALSE);
> +- int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, FALSE);
> ++ int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);
> + IPRT_FREEBSD_RESTORE_EFL_AC();
> if (krc == KERN_SUCCESS)
> return VINF_SUCCESS;
>
> Seems that __FreeBSD_version has been bumped to 1300135 less than
> 2 hours before 0659df6faddfb27ba54a2cae2a12552cf4f823a0 and thus
> the patch could be made to depend on that __FreeBSD_version value,
> but I did not bother to add the condition since all my systems have
> been updated to newer versions.
>
> Regards, STefan
>
> > --- memobj-r0drv-freebsd.o ---
> > /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80:
> > error: too few arguments to function call, expected 6, have 5
> > int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
> > ProtectionFlags, FALSE);
> > ~~ ^
> > /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
> > int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
> > ^
> > 1 error generated.
> > *** [memobj-r0drv-freebsd.o] Error code 1


signature.asc
Description: PGP signature

Re: svnlite behaviour changed?

[David Wolfskill]

On Tue, Jan 26, 2021 at 09:52:15AM +, M - Krasznai András wrote:
> Good morning!
> 
> I regularly sync my FreeBSD source tree with the central repository using svn 
> update. I use a one-lis script to synchonize, which  sends the output of svn 
> to a file, and also copies to the console. This list contained - according to 
> the 'svn help update' - one line for any item which was updated or inserted, 
> deleted etc and at the end it shows the (new) revision number of the 
> repository.
> 
> Some time ago during december this changed: the svn output contained one line 
> only, which informed me the new revision number but I did not get listing of 
> the updated items. If there are no updated items then why is the revision 
> number increasing, or if there are updates the why aren't they listed?
> 
> A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn 
> update changes the revision number of the source tree, and the newly compiled 
> kernel has that revision number, but no listing of updates.  svn checkout 
> listed the files as they were read from the central repository.
> 
> Is this a change of svn while the help text remained the old one,  or there 
> is a change in the svn repositories, or is this part of the move to git?
> Üdvözlettel
> 
> Krasznai András
> rendszermérnök

First, please note that this list is "freebsd-current@" -- by
definition, a "release" (such as FreeBSD-12.2-RELEASE) is not "current."

Second, the revision number at the end of "svn update" is the last
revision for the entire repository -- which is NOT the same thing as
"the last revision for the branch" (that you are using).

Thus, if there are changes to other branches (but not the one you are
tracking), the revision number reported will continue to go up, but
there will be no changes to the files in your branch.

Finally, please be aware that the svn repository is no longer the
"Source of Truth" for FreeBSD.  Rather, for (recent) stable branches (<=
12), committed changes to the Source of Truth are subsequently
"replayed" into the subversion repository.  As I understand it, there
are no plans to provide this for stable/13 or subsequent branches (or
for current).

Peace,
david
-- 
David H. Wolfskill  da...@catwhisker.org
Some "Republicans" seem bound and determined to turn the party known for
touting "law and order" into one that supports mob rule and insurrection.

See https://www.catwhisker.org/~david/publickey.gpg for my public key.


signature.asc
Description: PGP signature

Re: fsck strange output

[Nilton Jose Rizzo]

> 
> 
> Rozhuk Ivan writes:
> 
> > Disk is 100% alive, got same on other HW.
> 
> A disk can be alive and still have individually unreadable sectors,
> that is, IMO, the most common failure mode.
> 
> Try:
>   recoverdisk -v /dev/whatever
> 
> That will attempt to read all sectors on the disk.
> 

   It's possible fisical crash.

   You can try a fsck -f

   And after try smarttools ( in ports ) to check a health of S.M.A.R.T

IHMO.
> -- 
> Poul-Henning Kamp   | UNIX since Zilog Zeus 3.20
> p...@freebsd.org | TCP/IP since RFC 956
> FreeBSD committer   | BSD since 4.3-tahoe
> Never attribute to malice what can adequately be explained by incompetence.
> ___
> 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: svnlite behaviour changed?

[Thomas Mueller]

Good morning!

> I regularly sync my FreeBSD source tree with the central repository using svn 
> update. I use a one-lis script to synchonize, which  sends the output of svn 
> to a file, and also copies to the console. This list contained - according to 
> the 'svn help update' - one line for any item which was updated or inserted, 
> deleted etc and at the end it shows the (new) revision number of the 
> repository.

> Some time ago during december this changed: the svn output contained one line 
> only, which informed me the new revision number but I did not get listing of 
> the updated items. If there are no updated items then why is the revision
number increasing, or if there are updates the why aren't they listed?

> A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn 
> update changes the revision number of the source tree, and the newly compiled 
> kernel has that revision number, but no listing of updates.  svn checkout
listed the files as they were read from the central repository.

> Is this a change of svn while the help text remained the old one,  or there 
> is a change in the svn repositories, or is this part of the move to git?
> Üdvözlettel

> Krasznai András
> rendszermérnök

I believe this is part of the switch to git; svn repository is no longer 
updated for stable/13 or main (which is HEAD).

I now no longer use svn on src or doc tree; am tracking stable/13 and main; not 
interested in stable/12 or anything < 12.

Tom

___
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: problem building virtualbox-ose-kmod

[Stefan Esser]

Am 26.01.21 um 07:34 schrieb monochrome:
having this issue building virtualbox-ose-kmod, its been like this for a 
while but I deinstalled and forgot, for quite a while now, maybe over a 
month. now that I've moved from 13-current to stable/13 I thought I 
would try to put it back, but it still wont build. I haven't seen anyone 
else with this problem, did I miss a memo?


I have sent a patch to vbox@on 2020-01-16, but only received an
automatic reply that it had to be accepted by the moderator of the
list (and never got any further reply or reaction on it).

The signature of vm_map_protect() has changed, but the port has not
been updated.

Here is the patch in case the attachment gets stripped (but probably
with messed-up white-space):

Index: files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
===
--- files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c 
(revision 561738)
+++ files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c 
(working copy)

@@ -421,7 +421,8 @@
 @@ -826,6 +885,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(PRTR0MEMOBJINT
  ProtectionFlags |= VM_PROT_EXECUTE;

- int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
ProtectionFlags, FALSE);
+-int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
ProtectionFlags, FALSE);
++int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
ProtectionFlags, 0, VM_MAP_PROTECT_SET_PROT);

 +IPRT_FREEBSD_RESTORE_EFL_AC();
  if (krc == KERN_SUCCESS)
  return VINF_SUCCESS;

Seems that __FreeBSD_version has been bumped to 1300135 less than
2 hours before 0659df6faddfb27ba54a2cae2a12552cf4f823a0 and thus
the patch could be made to depend on that __FreeBSD_version value,
but I did not bother to add the condition since all my systems have
been updated to newer versions.

Regards, STefan


--- memobj-r0drv-freebsd.o ---
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80: 
error: too few arguments to function call, expected 6, have 5
     int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
ProtectionFlags, FALSE);

   ~~    ^
/usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
     ^
1 error generated.
*** [memobj-r0drv-freebsd.o] Error code 1
Index: files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c
===
--- files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c   
(revision 561738)
+++ files/patch-src_VBox_Runtime_r0drv_freebsd_memobj-r0drv-freebsd.c   
(working copy)
@@ -421,7 +421,8 @@
 @@ -826,6 +885,7 @@ DECLHIDDEN(int) rtR0MemObjNativeProtect(PRTR0MEMOBJINT
  ProtectionFlags |= VM_PROT_EXECUTE;
  
- int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 
FALSE);
+-int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 
FALSE);
++int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, ProtectionFlags, 0, 
VM_MAP_PROTECT_SET_PROT);
 +IPRT_FREEBSD_RESTORE_EFL_AC();
  if (krc == KERN_SUCCESS)
  return VINF_SUCCESS;


OpenPGP_signature
Description: OpenPGP digital signature

svnlite behaviour changed?

[M - Krasznai András]

Good morning!

I regularly sync my FreeBSD source tree with the central repository using svn 
update. I use a one-lis script to synchonize, which  sends the output of svn to 
a file, and also copies to the console. This list contained - according to the 
'svn help update' - one line for any item which was updated or inserted, 
deleted etc and at the end it shows the (new) revision number of the repository.

Some time ago during december this changed: the svn output contained one line 
only, which informed me the new revision number but I did not get listing of 
the updated items. If there are no updated items then why is the revision 
number increasing, or if there are updates the why aren't they listed?

A week ago I installed FreeBSD-12.2-RELEASE, and now I saw the same: svn update 
changes the revision number of the source tree, and the newly compiled kernel 
has that revision number, but no listing of updates.  svn checkout listed the 
files as they were read from the central repository.

Is this a change of svn while the help text remained the old one,  or there is 
a change in the svn repositories, or is this part of the move to git?
Üdvözlettel

Krasznai András
rendszermérnök

[M_logo]
1136 Budapest, Pannónia utca 11.
Tel:  +36 1 703 2923
Mobil: +36 30 703 2923
Központ:  +36 1 703 2920
Fax:  +36 1 703 2949
email: krasznai.and...@mands.hu

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

tools/toos/{zfsboottest|bootparttest} build broken

[Sergey V. Dyatko]

Hi,

root@hostname:/usr/src/tools/tools/bootparttest # make 
[Creating objdir /usr/obj/usr/src/amd64.amd64/tools/tools/bootparttest...]
make: don't know how to make crc32.c. Stop

make: stopped in /usr/src/tools/tools/bootparttest

root@hostname:/usr/src/tools/tools/zfsboottest # make
ln -sf /usr/src/sys/i386/include machine
cc  -O1  -I/usr/src/stand/zfs  -I/usr/src/sys/cddl/boot/zfs  -I.
-fdiagnostics-show-option  -W -Wextra -Wno-sign-compare -Wno-unused-parameter
-m32   -g -MD  -MF.depend.zfsboottest.o -MTzfsboottest.o -std=gnu99
-Wno-format-zero-length -fstack-protector-strong -Wsystem-headers -Werror -Wall
-Wno-format-y2k -W -Wno-unused-parameter -Wstrict-prototypes
-Wmissing-prototypes -Wpointer-arith -Wreturn-type -Wcast-qual -Wwrite-strings
-Wswitch -Wshadow -Wunused-parameter -Wcast-align -Wchar-subscripts -Winline
-Wnested-externs -Wredundant-decls -Wold-style-definition -Wno-pointer-sign
-Wmissing-variable-declarations -Wthread-safety -Wno-empty-body
-Wno-string-plus-int -Wno-unused-const-variable  -Qunused-arguments-c
/usr/src/tools/tools/zfsboottest/zfsboottest.c -o zfsboottest.o
/usr/src/tools/tools/zfsboottest/zfsboottest.c:49:1: error: no previous
prototype for function 'pager_output' [-Werror,-Wmissing-prototypes]
pager_output(const char *line) ^
/usr/src/tools/tools/zfsboottest/zfsboottest.c:48:1: note: declare 'static' if
the function is not intended to be used outside of this translation unit int ^
static /usr/src/tools/tools/zfsboottest/zfsboottest.c:57:1: error: no previous
prototype for function 'ldi_get_size' [-Werror,-Wmissing-prototypes]
ldi_get_size(void *priv) ^ /usr/src/tools/tools/zfsboottest/zfsboottest.c:56:1:
note: declare 'static' if the function is not intended to be used outside of
this translation unit uint64_t ^ static In file included from
/usr/src/tools/tools/zfsboottest/zfsboottest.c:72: /usr/include/libzfs.h:37:10:
fatal error: 'libnvpair.h' file not found #include  ^
3 errors generated. *** Error code 1

Stop.
make: stopped in /usr/src/tools/tools/zfsboottest


--
wbr, Sergey

___
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 and Radeon

[Toomas Soome via freebsd-current]

> On 26. Jan 2021, at 10:18, Marek Zarychta  
> wrote:
> 
> W dniu 26.01.2021 o 08:58, Graham Perrin pisze:
>> On 26/01/2021 07:02, Alexey Dokuchaev wrote:
>> > Re: loading drm crashes system
>> > … There are known issues with Radeon cards, they were quite well
>> > supported a year ago, then something got broken. I've promised to
>> > bisect this and find the cause, but there were several
>> > syscall-related changes in -CURRENT though the course of the last
>> > year, so bisecting just the kernel is not enough (machine won't get
>> > to login prompt if the userland does not match), which cripples the
>> > process.
>> >
>> > I still intend to take this quest, just not sure when. :(
>> >
>> > ./danfe
>> Any cards in particular?
>> 
>>  – whilst I didn't mention Radeon there, for me it _was_ the Radeon story 
>> that seemed to improve a few months ago.
>>  AMD Thames [Radeon 
>> HD 7550M/7570M/7650M]
> 
> 
> 
> For example old RS880 [Radeon HD 4200]. After deprecation of 
> graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 
> 12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While trying 
> the driver from graphics/drm-fbsd12.0-kmod I was not able to use this card 
> with gdm, only startx or x11/slim worked. On 13-ALPHA this card still works 
> fine with deprecated graphics/drm-legacy-kmod.
> 
> 

Does gdm start X in specific way? I mean, afaik, gdm is X11 client as any 
other, so the question would be, how does gdm get Xorg started, what is 
different compared to startx etc? Might it be about gdm user permissions to 
access drm devices?

my 2cents..
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: fsck strange output

[Mark Millard via freebsd-current]

Rozhuk Ivan rozhuk.im at gmail.com wrote on
Tue Jan 26 00:58:07 UTC 2021 :

> This happen on 4 different systems, that:
> - based on Ryzen zen/zen+
> - FreeBSD 13
> 
> 2 systems have ECC that works and show no errors.

This is just a example-contexts note: I've seen
what appears to be the same type of "UNEXPECTED
SOFT UPDATE INCONSISTENCY" issue on an old
2-socket/2-cores-each PowerMac G5 powerpc64
configuration that was running main from after
5cc52631b3b8 .

So, in this case, I do not expect that the problem
is special to Ryzen or related 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"

Re: problem building virtualbox-ose-kmod

[Henri Hennebert via freebsd-current]

On 1/26/21 9:13 AM, Mark Millard via freebsd-current wrote:

monochrome monochrome at twcny.rr.com wrote on
Tue Jan 26 06:34:23 UTC 2021 :


. . . for quite a while now, maybe over a month . . .



--- memobj-r0drv-freebsd.o ---
/usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80:
error: too few arguments to function call, expected 6, have 5
  int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd,
ProtectionFlags, FALSE);
~~
 ^
/usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
  ^
1 error generated.
*** [memobj-r0drv-freebsd.o] Error code 1



The change from 5 parameters to 6 parameters is recent: main's 0659df6faddf
as of 2021-01-12 23:35:22 + (commit).  Its one line description is:

QUOTE
vm_map_protect: allow to set prot and max_prot in one go
END QUOTE

It added a "int flags" parameter.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252952 is about:

vm_map_protect manual page requires an update after 0659df6faddf . . .

(So if there was a problem about a month ago, there may be another
problem as well as the above that was something else, the above just
happens first now.)

Looks like emulators/virtualbox-ose-kmod needs to track the kernel
change(s).


See solution in https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252675

Henri
___
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 and Radeon

[Marek Zarychta]

W dniu 26.01.2021 o 08:58, Graham Perrin pisze:

On 26/01/2021 07:02, Alexey Dokuchaev wrote:


 > Re: loading drm crashes system


 > … There are known issues with Radeon cards, they were quite well
 > supported a year ago, then something got broken. I've promised to
 > bisect this and find the cause, but there were several
 > syscall-related changes in -CURRENT though the course of the last
 > year, so bisecting just the kernel is not enough (machine won't get
 > to login prompt if the userland does not match), which cripples the
 > process.
 >
 > I still intend to take this quest, just not sure when. :(
 >
 > ./danfe


Any cards in particular?

 
– whilst I didn't mention Radeon there, for me it _was_ the Radeon story 
that seemed to improve a few months ago.


 AMD Thames 
[Radeon HD 7550M/7570M/7650M]




For example old RS880 [Radeon HD 4200]. After deprecation of 
graphics/drm-fbsd12.0-kmod I found that it is still supported fine on 
12-STABLE with legacy /boot/kernel/radeonkms.ko from the base. While 
trying the driver from graphics/drm-fbsd12.0-kmod I was not able to use 
this card with gdm, only startx or x11/slim worked. On 13-ALPHA this 
card still works fine with deprecated graphics/drm-legacy-kmod.



--
Marek Zarychta
___
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: problem building virtualbox-ose-kmod

[Mark Millard via freebsd-current]

monochrome monochrome at twcny.rr.com wrote on
Tue Jan 26 06:34:23 UTC 2021 :

> . . . for quite a while now, maybe over a month . . .

> --- memobj-r0drv-freebsd.o ---
> /usr/ports/emulators/virtualbox-ose-kmod/work/VirtualBox-5.2.44/out/freebsd.amd64/release/bin/src/vboxdrv/r0drv/freebsd/memobj-r0drv-freebsd.c:887:80:
>  
> error: too few arguments to function call, expected 6, have 5
>  int krc = vm_map_protect(pVmMap, AddrStart, AddrEnd, 
> ProtectionFlags, FALSE);
>~~ 
> ^
> /usr/src/sys/vm/vm_map.h:517:5: note: 'vm_map_protect' declared here
> int vm_map_protect(vm_map_t map, vm_offset_t start, vm_offset_t end,
>  ^
> 1 error generated.
> *** [memobj-r0drv-freebsd.o] Error code 1


The change from 5 parameters to 6 parameters is recent: main's 0659df6faddf
as of 2021-01-12 23:35:22 + (commit).  Its one line description is:

QUOTE
vm_map_protect: allow to set prot and max_prot in one go
END QUOTE

It added a "int flags" parameter.

https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=252952 is about:

vm_map_protect manual page requires an update after 0659df6faddf . . .

(So if there was a problem about a month ago, there may be another
problem as well as the above that was something else, the above just
happens first now.)

Looks like emulators/virtualbox-ose-kmod needs to track the kernel
change(s).

===
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"