Hi,
Right- so, `gop set 0` should've immediately cleared your screen and
put it into 1920x1080, full stop. If it did not, I think that's
indicative of some kind of interestingly broken firmware...
Regardless! We're clearly bad at trying to set a mode before the
kernel starts, so r331904 sets the default max resolution in such a
way that we just don't change the resolution by default anymore and
interested parties can bump that up if they want to try it. This
Thursday's snapshots should have this included.
I think if we're going to change modes as a default, we should have
some way for vt/efifb to use EFIRT or be notified by EFIRT of
supported resolutions so that vt/efifb can hopefully just handle it
all and do it properly. This approach would be more similar I guess to
how KMS drivers operate, and less fragile than what we're seeing with
these different approaches we've taken.
Post by Zaphod Beeblebroxhttps://owncloud.towernet.ca/s/6K3pGknCyGTi7du
... but the long and short of it is that even though the loader is printing
in the center of the screen (text mode?), it sees the 1920x1080 mode as the
"mode 0" ... I even tried "gop set 0" ... which it accepted, but then
continuing to boot produced what you see in the video.
I think, since it's in the cetner of the screen, that we're looking at 80x25
text... which is ... 800 x 600 -ish? The kernel definately wants graphics
again ... but ... I dunno ... is it getting it? Is the 80x25 text mode
emulated on a bitmapped screen?
Post by Kyle EvansPost by Zaphod BeeblebroxPost by David NewHamletFixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI
Post by Tomoaki AOKIConfirmed both loader (with boot1) part and efirt.ko part.
Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
No benefit (VGA resolution) but no new harm (no panic nor silent
reboot).
*Maybe gracefully falling back to mode 0.
As I'm on x11/nvidia-driver, completely no test is done with
drm-next.
One more to mention.
I've cherry-picked r330868, r331241 and r331361 on stable/11 after
r331114, amd64 and works OK as on head.
Additional cherry-picking of r331365 is OK, too.
Without r330868, my ThinkPad silently reboots within about 10-60
minutes range, maybe by actual access to UEFI RS.
With r331241 without r331361 causes instant panic on loading efirt.ko.
So all 3 (4) revs should be MFC'ed together.
Sorry for delay.
On Thu, 22 Mar 2018 10:34:33 -0500
Post by Kyle EvansPost by Peter LeiPost by Tomoaki AOKIHi.
For problem 2, try reverting r331241 alone.
This worked for my ThinkPad T420.
I also hit this after updating to latest and was about to post when
I
saw this thread -
I build efirt into the kernel and it's now doing a panic on
boot.
It
appears to be due to this recent addition in dev/efidev/efirt.c by
Post by Tomoaki AOKIif (!efi_is_in_map(map, efihdr->memory_size /
efihdr->descriptor_size,
Post by Kyle EvansPost by Peter LeiPost by Tomoaki AOKIefihdr->descriptor_size,
(vm_offset_t)efi_runtime->rt_gettime))
{
Post by Kyle EvansPost by Peter LeiThe faulting address is for "efi_runtime->rt_gettime" (and is still
a
phys addr here).
The following patch [1] (I can't guarantee how long he'll keep it
available there) should fix this class of problems.
[1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
EFI-environment-before-check-the-GetT.patch
Post by Kyle EvansNow committed as of r331361.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org"
--
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
I've booted that image on my zbook 15. I show in the boot that I can
deliberately load efirt.ko ... and it doesn't help. I also show that I can
"type blind" after the system boots ... so everything but the screen is
working.
In case you can't quite make it out, I hit right cursor twice (move to the
"live cd" choice) and hit enter. Then I type "root" enter and then "reboot"
...
That is interesting indeed... that's perhaps the polar opposite of
what was being experienced before- it looks like it's setting a higher
resolution but the firmware isn't actually putting it into the higher
resolution. The firmware then lies to us about what resolution it's
actually in, so we tell the kernel the wrong thing.
You should be able to confirm this, as I recall, by bumping into the
loader prompt and inspecting the output of `gop get`. That should
report a higher resolution than it's actually in.
Post by Zaphod Beeblebroxhttp://youtu.be/tlmaVJ-3aq0
(The rock sound track is just free audio to mask a barking dog and a radio
in the background.)
This was a most enjoyable soundtrack.
Kyle Evans, Web/Database Developer
College of Engineering, Kansas State University
Post by Zaphod Beeblebroxhttps://owncloud.towernet.ca/s/6K3pGknCyGTi7du
... but the long and short of it is that even though the loader is printing
in the center of the screen (text mode?), it sees the 1920x1080 mode as the
"mode 0" ... I even tried "gop set 0" ... which it accepted, but then
continuing to boot produced what you see in the video.
I think, since it's in the cetner of the screen, that we're looking at 80x25
text... which is ... 800 x 600 -ish? The kernel definately wants graphics
again ... but ... I dunno ... is it getting it? Is the 80x25 text mode
emulated on a bitmapped screen?
Post by Kyle EvansPost by Zaphod BeeblebroxPost by David NewHamletFixed in: FreeBSD-12.0-CURRENT-amd64-20180329-r331740-disc1.iso
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=176694
On Mon, Apr 2, 2018 at 12:38 AM, Tomoaki AOKI
Post by Tomoaki AOKIConfirmed both loader (with boot1) part and efirt.ko part.
Working OK on my ThinkPad420 (with nvidia GPU) at r331864.
No benefit (VGA resolution) but no new harm (no panic nor silent
reboot).
*Maybe gracefully falling back to mode 0.
As I'm on x11/nvidia-driver, completely no test is done with
drm-next.
One more to mention.
I've cherry-picked r330868, r331241 and r331361 on stable/11 after
r331114, amd64 and works OK as on head.
Additional cherry-picking of r331365 is OK, too.
Without r330868, my ThinkPad silently reboots within about 10-60
minutes range, maybe by actual access to UEFI RS.
With r331241 without r331361 causes instant panic on loading efirt.ko.
So all 3 (4) revs should be MFC'ed together.
Sorry for delay.
On Thu, 22 Mar 2018 10:34:33 -0500
Post by Kyle EvansPost by Peter LeiPost by Tomoaki AOKIHi.
For problem 2, try reverting r331241 alone.
This worked for my ThinkPad T420.
I also hit this after updating to latest and was about to post when
I
saw this thread -
I build efirt into the kernel and it's now doing a panic on
boot.
It
appears to be due to this recent addition in dev/efidev/efirt.c by
Post by Tomoaki AOKIif (!efi_is_in_map(map, efihdr->memory_size /
efihdr->descriptor_size,
Post by Kyle EvansPost by Peter LeiPost by Tomoaki AOKIefihdr->descriptor_size,
(vm_offset_t)efi_runtime->rt_gettime))
{
Post by Kyle EvansPost by Peter LeiThe faulting address is for "efi_runtime->rt_gettime" (and is still
a
phys addr here).
The following patch [1] (I can't guarantee how long he'll keep it
available there) should fix this class of problems.
[1] https://people.freebsd.org/~andrew/0001-Enter-into-the-
EFI-environment-before-check-the-GetT.patch
Post by Kyle EvansNow committed as of r331361.
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
freebsd.org"
--
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
_______________________________________________
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to
I've booted that image on my zbook 15. I show in the boot that I can
deliberately load efirt.ko ... and it doesn't help. I also show that I can
"type blind" after the system boots ... so everything but the screen is
working.
In case you can't quite make it out, I hit right cursor twice (move to the
"live cd" choice) and hit enter. Then I type "root" enter and then "reboot"
...
That is interesting indeed... that's perhaps the polar opposite of
what was being experienced before- it looks like it's setting a higher
resolution but the firmware isn't actually putting it into the higher
resolution. The firmware then lies to us about what resolution it's
actually in, so we tell the kernel the wrong thing.
You should be able to confirm this, as I recall, by bumping into the
loader prompt and inspecting the output of `gop get`. That should
report a higher resolution than it's actually in.
Post by Zaphod Beeblebroxhttp://youtu.be/tlmaVJ-3aq0
(The rock sound track is just free audio to mask a barking dog and a radio
in the background.)
This was a most enjoyable soundtrack.