Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas

On 1/5/22, Warner Losh <imp@bsdimp.com> wrote:
> You do know you are talking to someone who has been working on suspend /
> resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days,
> right?

No I did not know this.
It was also not my intention to insult. I just believed another guy wrote it.
But after re-reading his comment, I see that that guy implemented that
for the amd64 platform only (proof:
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=224069#c5 ).
As I did not want to make you feel bad, I sincerely apologize, as I
highly respect yours, Kims and the others' work.

> Why bother. Load the kms drm drivers. The suspend/resume code is in those
> drivers. They work console, X11 and wayland, more or less.

This is good to know!
Because, it is *not* being communicated at all in any of the
suspend/resume wiki pages, guides etc that from some release on,
loading the drm-kmod stuff became necessary also  *if* suspend/resume
functionality is needed for console-only computers.

Yesterdays' post from @tech-lists about outdated/missing information
comes to my mind...
If this were communicated, it would have saved all of us a lot of time.

> ... the crazy ideas presented in this thread.
> They are known to be flakey, unreliable or technically just not possible.

Well, imho basically the only crazy idea was to enable the int 10h
interface/reinit hardware after exiting the UEFI boot service and when
resuming by hackingly calling the hybrid VGA BIOS init.
Infrastructure for real mode BIOS access definitely seems to exist,
and I guess I'll play around with it, and see how reliable it is.
If this works out, then this would be some sort of proof.

So I retract this proposal for a sponsored project.
Because, the best solution would imho be to update the documentation
(handbook suspend/resume section, man zzz acpiconf, maybe apm too,
wiki) so it mentions the necessity for kldloading the drm kmod drivers
to actually make resuming succeed on console-only computers.
I hope everybody agrees if I make the necessary PRs for documentation updates.

Cheers,
Stefan


On 1/5/22, Warner Losh <imp@bsdimp.com> wrote:
> On Wed, Jan 5, 2022, 10:09 AM Stefan Blachmann <sblachmann@gmail.com>
> wrote:
>
>> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > 15 or 20 years [...]
>> > main reason laptops stopped suspending in the early 2000s... [...]
>> > And the INT xx interface is unavailable on amd64 after we
>> > enter long mode
>>
>> First, you mentioned a hacking session in the "early 2000s".
>> This makes me wonder whether you might mistake some other thing from
>> the distance of time, as UEFI was no real thing until ~2010, and was
>> never a thing on platforms other than amd64 also. Suspend/resume on
>> FreeBSD only appeared much later, too.
>>
>
> You do know you are talking to someone who has been working on suspend /
> resume since I got my first Libretto 50CT laptop in the FreeBSD 3.2 days,
> right? I'll assume not, because otherwise this is somewhat insulting. I
> wrote a lot of the original suspend/resume code. I worked on it with the
> transition to ACPI. I saw the code stop working when the GPUs started
> needing more state restored than could be done with INT10 interfaces. I
> tried to implement that on suspend/resume. I helped get workarounds for X11
> on suspend/resume to switch to ttyv0 before suspending (which worked for a
> while, pre drm days). What you say here is factually inaccurate.
>
> Second, there is kernel functionality to call real mode interrupt
>> handlers from long mode, which manage switching to real mode and back.
>> Just an example, these are being used by vt (via vesa.ko) to switch vesa
>> modes.
>>
>
> Except that it's kinda unreliable and not enabled for vt because it doesn't
> work well with UEFI.
>
> So I do not see why this real mode access infrastructure could not
>> also be used to make a call to C000:(PCI PROM Programming interface
>> code offset), or the respective segment address where the actual VGA
>> BIOS is, to have it initialize the int 10h interface handler, if a
>> hybrid/dual graphics card BIOS is present.
>> I think a single function "InitializeVGABIOSifpresent" to enable
>> access to VGA/VESA BIOS functionality might actually be fairly easy to
>> implement.
>> Furthermore, there is no need at all to access hardware specific stuff
>> like you mentioned, as the necessary functionality is completely
>> covered by the int 10h
>
>
> Imho it could be worth to allocate a small part of the sponsoring
>> budget to put a bounty to motivate people (including possibly me) to
>> implement these improvements regarding suspend/resume and enhanced sc
>> and vt usability.
>>
>
> I'm going to disagree.
>
> Why bother. Load the kms drm drivers. The suspend/resume code is in those
> drivers. They work console, X11 and wayland, more or less.  It's an
> absolutely
> insane idea to spend limited funds on the crazy ideas presented in this
> thread.
> They are known to be flakey, unreliable or technically just not possible.
>
> Warner
>
>
> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann <sblachmann@gmail.com>
>> > wrote:
>> >
>> >> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> >> > Not without loading the xorg graphics stuff... graphics chips from
>> >> > the
>> >> last
>> >> > 15 or 20 years have lots of chip specific state that only the
>> >> > graphics
>> >> > stuff knows about... IIRC, it only knows about it because it put the
>> >> > graphics into a known state... it's the main reason laptops stopped
>> >> > suspending in the early 2000s... it looks to be a lot of work for a
>> >> > relatively rare use case...
>> >>
>> >> UEFI GOP seems to have the necessary functionalities
>> >> (https://wiki.osdev.org/GOP#Get_the_Current_Mode) so I guess the work
>> >> required would be limited (restore mode and redraw screen from
>> >> buffer).
>> >>
>> >
>> > UEFI GOP isn't available after we start the kernel, so this is a
>> > non-starter.
>> > It works great in the boot loader, but not so good after we boot. It
>> could
>> > work
>> > for S3 sleep to disk where we actually reboot to restore the machine
>> state,
>> > but we don't have sleep to disk today :(
>> >
>> >
>> >> With non-UEFI or old UGA UEFI implementations possibly one could use
>> >> the dual BIOS´ CSM part. Just call the CSM BIOS init to set up GPU and
>> >> the int 10h interface, and then set previously used mode+redraw.
>> >> BTW, doing that also could both enable vt(4) to change
>> >> modes/resolutions and using sc on UEFI computers.
>> >>
>> >
>> > Ah, if only things were really that simple...  I tried variations on
>> > that
>> > hack years ago when suspending broke due to video. And it
>> > works for some machines, but not others, was the quick assessment
>> > I made. And the INT xx interface is unavailable on amd64 after we
>> > enter long mode (I tried this out on my then-current FreeBSD laptop
>> > which was 32 bit only, so 15 years ago?).
>> >
>> > Warner
>> >
>> >
>> >> But I think you are right, there are probably not too many users who
>> >> would make use of that.
>> >>
>> >>
>> >> On 1/4/22, Warner Losh <imp@bsdimp.com> wrote:
>> >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann
>> >> > <sblachmann@gmail.com>
>> >> > wrote:
>> >> >
>> >> >> Implementing S3 suspend/resume was a sponsored project itself.
>> >> >> However, it still does only work when at xorg graphics mode, which
>> >> >> already was topic in this thread.
>> >> >> When using it from console, no matter sc or vt, it still hangs with
>> >> >> dark screen and unresponsive keyboard.
>> >> >> Could finishing the suspend/resume work be sponsored, so that it
>> >> >> also
>> >> >> works on console-only computers?
>> >> >>
>> >> >
>> >> > Not without loading the xorg graphics stuff... graphics chips from
>> >> > the
>> >> last
>> >> > 15 or 20 years have lots of chip specific state that only the
>> >> > graphics
>> >> > stuff knows about... IIRC, it only knows about it because it put the
>> >> > graphics into a known state... it's the main reason laptops stopped
>> >> > suspending in the early 2000s... it looks to be a lot of work for a
>> >> > relatively rare use case...
>> >> >
>> >> > Warner
>> >> >
>> >> >
>> >> >> On 12/30/21, Joseph Mingrone <jrm@freebsd.org> wrote:
>> >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm@FreeBSD.org>
>> >> >> > wrote:
>> >> >> >
>> >> >> >> On Thu, 2021-12-30 at 08:05, Özkan KIRIK <ozkan.kirik@gmail.com>
>> >> >> >> wrote:
>> >> >> >>> I've ideas about enhancing the routing architecture. Is it
>> >> >> >>> possible
>> >> >> >>> to
>> >> >> >>> add to wiki?
>> >> >> >
>> >> >> >> Certainly.  Please do.
>> >> >> >
>> >> >> > The link again is https://wiki.freebsd.org/2021FoundationCFI
>> >> >> >
>> >> >>
>> >> >>
>> >> >
>> >>
>> >
>>
>>
>>
>