Re: FreeBSD-13.0-CURRENT-amd64-20200409-r359731: drm-kmod failure?

[Niclas Zeising]

On 2020-04-11 08:09, Clay Daniels wrote:

I removed what I thought was FreeBSD-13.0-CURRENT-amd64-20200402-r359556
snapshot yesterday. It was working fine. I loaded the 20200409-r359731
snapshot, rebooted, installed drm-kmod, and it booted into the first
"flash" screen where there is a great light show as normal, but stalled out
there.

Today I cleaned up the partition and re-installed. I put the appropriate
line in /etc/rc.conf: kld_list='amdgpu" but DID_NOT use the line I have
been adding to /boot/loader.conf: hw.syscons.disable=1 . This time there
was more no nice graphics light show, but it stalled with db> debug prompt.
The section was where it tries to load drm-kmod & amdgpu.

Just now I reloaded r359556 from Apr 2. It works just fine. I will use this
until next weeks Thursday Current snapshot,, and see what happens.



How did you install the driver?
When using the drm drivers on current, you usually have to build them 
from ports rather than use the packages, this way the driver matches the 
kernel you are using.

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: Firefox and Cliqz tabs crashing at GOV.UK government pages

[Jan Beich]

Graham Perrin  writes:

> On 08/04/2020 20:23, Graham Perrin wrote:
>
>> Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk pages
>>
>> Most noticeable today at
>   . Screenshots available on request.
>>
>> AFAICT the same types of problem with 75.0_1,1 on both r357746 and
>   r359628.
>
> The problem persists with r359750, is reproducible with a different
> user account, is reproducible with Cliqz browser. As far as I can
> tell, only bugging UK.GOV government pages.

I could reproduce on Nightly, so have reported upstream.
https://bugzilla.mozilla.org/show_bug.cgi?id=1629231

> Occasionally a page will appear OK (e.g. the screen to the left at
> ), more often the page will appear 
> wrong (screen to the right, safe mode).

According to backtrace the crash happens in harfbuzz code which is
responsible how text is shaped. If it doesn't crash right away then
scrolling the page usually helps to trigger.

> Most often: the tab will crash before the screen can be read. Crashes
> seem to occur at load time, towards the tail end of content loading or 
> rendering.
>
> More shots of what appears to be mis-rendering, Firefox with a
> refreshed profile in safe mode:
>
> 
> 

Maybe report your findings on upstream bug.

>
> I have .core files from both Firefox and Cliqz, should I report a bug?
>
> (Also I'd like to take this opportunity to learn how to interpret
> parts of a .core file, I'll do what I can with man pages but might
> need to seek help in IRC.)

Try "lldb --core firefox.*.core /usr/local/bin/firefox" then run "bt all"
from (lldb) prompt. core(5) files are not portable across environments,
so after getting some basic info discard the files because they'd
quickly become unusable after rebuilding www/firefox or any of its
library dependencies.
___
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: Firefox and Cliqz tabs crashing at GOV.UK government pages

[Gary Jennejohn]

On Sat, 11 Apr 2020 09:49:09 +0300
Alexandr Krivulya  wrote:

> 11.04.20 03:34, Graham Perrin __:
> > On 08/04/2020 20:23, Graham Perrin wrote:
> >  
> > > Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk   
> > pages  
> > >
> > > Most noticeable today at .   
> > Screenshots available on request.  
> > >
> > > AFAICT the same types of problem with 75.0_1,1 on both r357746 and   
> > r359628.
> >
> > The problem persists with r359750, is reproducible with a different 
> > user account, is reproducible with Cliqz browser. As far as I can 
> > tell, only bugging UK.GOV government pages.
> >
> > Occasionally a page will appear OK (e.g. the screen to the left at 
> > ), more often the page will appear 
> > wrong (screen to the right, safe mode).
> >
> > Most often: the tab will crash before the screen can be read. Crashes 
> > seem to occur at load time, towards the tail end of content loading or 
> > rendering.
> >  
> 
> I can't reproduce it on my current (r359770, amd64, firefox-75.0_1,1), 
> this page loads fine, no any mis-rendering or crashing.
>

https://www.gov.uk/coronavirus works with r359798 also, of course.

I tried it with r359740 using firefox with a java script blocker installed.  The
site displayed just fine and only complained about cookies.  As soon as I
enabled any one of the two blocked java scripts the tab crashed. Seems
like the site is using some weird java scripts which tickle a bug in
older versions (< r359770) of FreeBSD.

-- 
Gary Jennejohn
___
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: Firefox and Cliqz tabs crashing at GOV.UK government pages

[Gary Jennejohn]

On Sat, 11 Apr 2020 11:01:52 +0200
Gary Jennejohn  wrote:

> On Sat, 11 Apr 2020 09:49:09 +0300
> Alexandr Krivulya  wrote:
> 
> > 11.04.20 03:34, Graham Perrin __:  
> > > On 08/04/2020 20:23, Graham Perrin wrote:
> > >
> > > > Firefox 75.0_1,1 tabs crashing or mis-rendering at some www.gov.uk 
> > > pages
> > > >
> > > > Most noticeable today at . 
> > > Screenshots available on request.
> > > >
> > > > AFAICT the same types of problem with 75.0_1,1 on both r357746 and 
> > > r359628.
> > >
> > > The problem persists with r359750, is reproducible with a different 
> > > user account, is reproducible with Cliqz browser. As far as I can 
> > > tell, only bugging UK.GOV government pages.
> > >
> > > Occasionally a page will appear OK (e.g. the screen to the left at 
> > > ), more often the page will appear 
> > > wrong (screen to the right, safe mode).
> > >
> > > Most often: the tab will crash before the screen can be read. Crashes 
> > > seem to occur at load time, towards the tail end of content loading or 
> > > rendering.
> > >
> > 
> > I can't reproduce it on my current (r359770, amd64, firefox-75.0_1,1), 
> > this page loads fine, no any mis-rendering or crashing.
> >  
> 
> https://www.gov.uk/coronavirus works with r359798 also, of course.
> 
> I tried it with r359740 using firefox with a java script blocker installed.  
> The
> site displayed just fine and only complained about cookies.  As soon as I
> enabled any one of the two blocked java scripts the tab crashed. Seems
> like the site is using some weird java scripts which tickle a bug in
> older versions (< r359770) of FreeBSD.
> 

Update - it turns out that I didn't wait long enough.  The firefox tab
still crashes after a few minutes.  So I guess there really is a problem
with firefox.

seamonkey sometimes crashes and sometimes works.  That's weird.

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

Bridge project update (Week of April 6th)

[Kristof Provost]

Hi,

There’s relatively little to report on this week.
The main patch is still pending review. I’ll give that another week or 
so, so there may not be much to report on next week either.


There is one new test ready to be committed:

 - https://reviews.freebsd.org/D24337

I initially expected not to be able to MFC these changes back to 12, but 
that may be possible after all.

There is an experimental patch set for stable/12 here:
https://people.freebsd.org/~kp/if_bridge/stable_12/

Best regards,
Kristof Provost
___
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"

(1629231) Firefox and Cliqz tabs crashing at GOV.UK government pages

[Graham Perrin]

Now upstream thanks to Jan Beich:

Mozilla bug 1629231 - Crash on gov.uk



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

Why is the console a graphic/bitmapped console, and not text/character by default

[Chris]

Sorry for the ling title. But wasn't sure how make my
question more concise.
Why did we begin making an initial console "graphics mode"
by default. My understanding has always been that (Free)BSD
has been a "Server by default", and a Desktop after an initial
install if that's one chosen target.
It's near impossible to perform initial configuration
in graphics mode, using a mouse to cut/copy/paste does *not*
work as intended. Which requires one to make the necessary
changes "breaking to the new system" after install completes
to change initiation to test-mode before bouncing the box.
While this "works" for long-time users. It's an *extra*, and
seemingly *unnecessary* step. It is also likely to behoove
first-time/new users -- except those already targeting a
Desktop.

Thanks for any insight into this! :)

--Chris


___
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: Why is the console a graphic/bitmapped console, and not text/character by default

[Toomas Soome]

You have UEFI setup? With UEFI, there is no text mode.

If mouse copy/paste is working is not a property of screen mode but it if the 
console driver does implement it or not.

Sent from my iPhone

> On 12. Apr 2020, at 07:41, Chris  wrote:
> 
> Sorry for the ling title. But wasn't sure how make my
> question more concise.
> Why did we begin making an initial console "graphics mode"
> by default. My understanding has always been that (Free)BSD
> has been a "Server by default", and a Desktop after an initial
> install if that's one chosen target.
> It's near impossible to perform initial configuration
> in graphics mode, using a mouse to cut/copy/paste does *not*
> work as intended. Which requires one to make the necessary
> changes "breaking to the new system" after install completes
> to change initiation to test-mode before bouncing the box.
> While this "works" for long-time users. It's an *extra*, and
> seemingly *unnecessary* step. It is also likely to behoove
> first-time/new users -- except those already targeting a
> Desktop.
> 
> Thanks for any insight into this! :)
> 
> --Chris
> 
> 
> ___
> 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: Why is the console a graphic/bitmapped console, and not text/character by default

[Chris]

On Sun, 12 Apr 2020 08:04:43 +0300 Toomas Soome tso...@me.com said


You have UEFI setup? With UEFI, there is no text mode.

If mouse copy/paste is working is not a property of screen mode but it if the
console driver does implement it or not.

Sent from my iPhone

> On 12. Apr 2020, at 07:41, Chris  wrote:
> 
> Sorry for the ling title. But wasn't sure how make my

> question more concise.
> Why did we begin making an initial console "graphics mode"
> by default. My understanding has always been that (Free)BSD
> has been a "Server by default", and a Desktop after an initial
> install if that's one chosen target.
> It's near impossible to perform initial configuration
> in graphics mode, using a mouse to cut/copy/paste does *not*
> work as intended. Which requires one to make the necessary
> changes "breaking to the new system" after install completes
> to change initiation to test-mode before bouncing the box.
> While this "works" for long-time users. It's an *extra*, and
> seemingly *unnecessary* step. It is also likely to behoove
> first-time/new users -- except those already targeting a
> Desktop.
> 
> Thanks for any insight into this! :)
> 
> --Chris
> 
> 

With (U)EFI firmware, you're in graphics until the kernel takes over.
Where you can switch/change/obtain text/character mode.

I'm not we're talking about the same thing here.

--Chris


___
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: FreeBSD-13.0-CURRENT-amd64-20200409-r359731: drm-kmod failure?

[Clay Daniels]

On Sat, Apr 11, 2020 at 2:06 AM Niclas Zeising 
wrote:

>
> How did you install the driver?
> When using the drm drivers on current, you usually have to build them
> from ports rather than use the packages, this way the driver matches the
> kernel you are using.
> Regards
> --
> Niclas
>

Thanks, Niclas. I guess I'm mostly too lazy and  drm-kmod has been working
well just using pkg install drm-kmod to bother with making the ports. But I
reloaded r359731 and went to /usr/ports/graphics and installed
drm-current-kmod which brought in gpu-firmware-kmod  and everything worked
fine. I then installed xorg (via pkg), rebooted, ran startx, and used the
xterm window in twm to install firefox, and write this reply.

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"