From nobody Wed Jan 05 18:22:39 2022 X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mlmmj.nyi.freebsd.org (Postfix) with ESMTP id D1E8B1927DB7 for ; Wed, 5 Jan 2022 21:21:56 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from mail4.nevz.com (mail4.nevz.com [91.240.220.21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-SHA384 (256/256 bits)) (Client CN "mail4.nevz.com", Issuer "R3" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JTj9J0Vfjz57jm; Wed, 5 Jan 2022 21:21:56 +0000 (UTC) (envelope-from owner-freebsd-hackers@freebsd.org) Received: from Pickup by Srv032.nevz.com with Microsoft SMTP Server id 14.3.498.0; Wed, 5 Jan 2022 21:21:52 +0000 x-sender: freebsd-hackers+bounces-734-kozarenkoas=nevz.com@FreeBSD.org x-receiver: spam@vSrv021.nevz.com X-Virus-Scanned: amavisd-new at nevz.com X-Authentication-Warning: mailgate.nevz.com: Host [172.16.200.14] claimed to be tmh-chpt003 X-MTA-CheckPoint: {61D5E219-0-CC810AC-15F} X-Original-To: freebsd-hackers@mlmmj.nyi.freebsd.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bsdimp-com.20210112.gappssmtp.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=S1r1bhTuitAB4souaTTOHZGabHwzHyUbxUdW/Qe9yQ5O5cFFjhiAtS+0l49xPSILSt U3s7VDjMd+11xgLMRwV52+G+k5cy0OrN4vpUjNgCyqSf10qURCOOb0byhcZqDD97MZGh +TrgmH3kdmi0N97ZG3xhGGKfYbLywe6mRk1jZUETSVwMVKCy4mm+J9w8q0mSkKJ9cuir X8gEJy8VUvhUWnEp59CURSWqYaksZhZrue2obRJOoFderUN2lTQxd+IkX/TDbMacYutR 31PtASYSRwR+hOynwIlyHBaopZKCjk+KNcFiOTQWGvNJdZjrycFWqhc0Vnt+PCnzXotm mWTQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=4x+c3KSbbol9i4MQMRtgRyP8DQm5I3ApqGJ4ax67UFxKCDkaGHytYz+0ZOrGf6Ko0v hxxH5Whpc+EFrzxIeX8TB+DyddQHXm1zC5xarE8bj0TMW0W+bMfacb09NDEw92Imn664 JThIEeBuR4HuG5cgiVcdOScThsY7nCcRJ0+CX9t3bFJh9R/04Gcj5EYzIXp/zjVxsrCg IcK2EghKY6n2HnHVuBSx9/hUYDkpszABoyjSuz7fhQMCqqUEkRg3grVmkehuazk7WXaZ 4i3O8Mq7RTBGMyjbEkGV7VOpgHm0UJqQBb7806FrktgXqge5mDVIClEV3b+8OtQsLQj0 xCcw== X-Gm-Message-State: AOAM533t7w8j5UeH0BzovNnPVsy8nbt/7WsR7QDehjksfWfqR9SallY2 fLtrorb05b5Ba05IqY13YtgkTXlvtw8PorQsb6y9cVDUbOA= X-Google-Smtp-Source: ABdhPJxop6HmGNnvZGV90FoCzdGZu3N9k9pMRfBRkxQAurgYW3/FLOXUpcWjBtakLOIk55kX6eGUNyyN/pSnUTVs7rg= X-Received: by 2002:a67:f8cb:: with SMTP id c11mr17642619vsp.13.1641406970801; Wed, 05 Jan 2022 10:22:50 -0800 (PST) List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: List-Id: Technical discussions relating to FreeBSD List-Archive: https://lists.freebsd.org/archives/freebsd-hackers List-Help: List-Post: List-Subscribe: List-Unsubscribe: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> In-Reply-To: From: Warner Losh Date: Wed, 5 Jan 2022 11:22:39 -0700 Message-ID: Subject: 5.9 points Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Stefan Blachmann CC: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , "Kyle Evans" , Karel Gardas , FreeBSD Hackers Content-Type: multipart/alternative; boundary="0000000000006d458005d4d9d7ee" X-ThisMailContainsUnwantedMimeParts: N ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=freebsd.org; s=dkim; t=1641406997; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=mDhsGr0BzUB6hxfeopFAEMwPMyLDuPbXcyzO1YJTYto=; b=ZOBjnVpdipojm2iyOPwi3bF/0+DSea+sLho1Id4MUa9Sp6m9XIkQKz1CEdqvQdRQxePkIu Mwvq5RC9cyzqi8v6dqdBH4uMla7P2U4FaA9v0yw5MBl3UGzKR/7MA4EBlFcvv0dkHspen8 6K8TSXoqBLh216s8pCRTKcNaHboCAMIWEIzxwla1es4hEJSfOpAzuW8LbHAHKLTHtz32zg LEr2r1MG01U7nqriZOR/G/q3qI49sSsRe6bqV6I65TlqogVVs5jvETlarPBPdLtjWatV4p xCbJe5KOyyI1ZTE4ZzGdU89zYws+03DWsxRGF/PWaf/2/RJ3RKuwJvVTTM6Icw== ARC-Seal: i=1; s=dkim; d=freebsd.org; t=1641406997; a=rsa-sha256; cv=none; b=FF6tptZuG+RtIqHWZvNwO8a+ySWiY02Q2xJcNnhhYBVlhK85+TND76xPBgoFNvUvdIx/EB xlkvgez8qG0gJsbPXwLe2tocG8PB7R0vTfHMW6Mc628elXOSyPOMHTi16wH4w6QEIni5QD kAcd/MvgS54i8wuSeiCKr94lo7BJVz65ZcDIf61qmyEzJqKBJXMmOV9hN9bKod0KKaKxbI oJs7+nZg2KNddy2UACN3269tMjz3FI1kv1NQbDFZykr+B2JQg0cJix9PT+zfIESL58cEEl lPqSwQw4M2Ee+MZtBjM/eYtb3npu963RWDYxjONqENEA2ROIcpSeSSrET99EzQ== ARC-Authentication-Results: i=1; mx1.freebsd.org; none X-FEAS-DKIM: Valid X-FE-Last-Public-Client-IP: 96.47.72.81 X-FE-Envelope-From: freebsd-hackers+bounces-734-kozarenkoas=nevz.com@freebsd.org X-FE-Policy-ID: 1:1:1:nevz.com X-Greylist: internal networks OS Linux 3.11 and newer X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.6.4 (mailgate.nevz.com [172.17.206.231]); Wed, 05 Jan 2022 21:23:31 +0300 (MSK) X-Spam-Flag: YES X-Spam-Status: Yes, score=5.9 required=5.0 tests=BAYES_00=-1.9,DKIM_SIGNED=0.1,DKIM_VALID=-0.1,FSL_HELO_NON_FQDN_1=0.001,HEADER_FROM_DIFFERENT_DOMAINS=5,HTML_MESSAGE=1,MAILING_LIST_MULTI=-1,RAZOR2_CF_RANGE_51_100=1.886,RAZOR2_CHECK=0.922 mailgate.nevz.com; whitelist Reported 0 times. [96.47.72.84] [30 mx66.freebsd.org., 10 mx1.freebsd.org.] autolearn=no autolearn_force=no version=3.4.5 X-Spam-Orig-To: ORCPT=rfc822;kozarenkoas@nevz.com X-Spam-Report: * -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% * [score: 0.0000] * 0.0 FSL_HELO_NON_FQDN_1 No description available. * 5.0 HEADER_FROM_DIFFERENT_DOMAINS From and EnvelopeFrom 2nd level * mail domains are different * 1.0 HTML_MESSAGE BODY: HTML included in message * 0.1 DKIM_SIGNED Message has a DKIM or DK signature, not necessarily * valid * -0.1 DKIM_VALID Message has at least one valid DKIM or DK signature * 1.9 RAZOR2_CF_RANGE_51_100 Razor2 gives confidence level above 50% * [cf: 100] * 0.9 RAZOR2_CHECK Listed in Razor2 (http://razor.sf.net/) * -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list * manager X-Spam-Level: ***** X-Spam-Checker-Version: SpamAssassin 3.4.5 (2021-03-20) on mailgate.nevz.com X-OriginalArrivalTime: 05 Jan 2022 18:23:37.0663 (UTC) FILETIME=[5B70C4F0:01D80261] X-Rspamd-Queue-Id: 4JTj9J0Vfjz57jm X-Spamd-Bar: ---- Authentication-Results: mx1.freebsd.org; none X-Spamd-Result: default: False [-4.00 / 15.00]; TAGGED_RCPT(0.00)[]; REPLY(-4.00)[] X-Spam: Yes X-ThisMailContainsUnwantedMimeParts: N --0000000000006d458005d4d9d7ee Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Wed, Jan 5, 2022, 10:09 AM Stefan Blachmann wrote= : > On 1/4/22, Warner Losh 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 wrote: > > On Tue, Jan 4, 2022 at 12:14 AM Stefan Blachmann > > wrote: > > > >> On 1/4/22, Warner Losh wrote: > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > 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=C2=B4 CSM part. Just call the CSM BIOS init to set up GP= U 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 th= at > > 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 wrote: > >> > On Mon, Jan 3, 2022, 11:03 PM Stefan Blachmann > >> > 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 al= so > >> >> works on console-only computers? > >> >> > >> > > >> > Not without loading the xorg graphics stuff... graphics chips from t= he > >> last > >> > 15 or 20 years have lots of chip specific state that only the graphi= cs > >> > 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 wrote: > >> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone > >> >> > wrote: > >> >> > > >> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK > >> >> >> 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 > >> >> > > >> >> > >> >> > >> > > >> > > > > > --0000000000006d458005d4d9d7ee Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable


=
On Wed, Jan 5, 2022, 10:09 AM Stefan = Blachmann <sbl= achmann@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 someon= e who has been working on suspend / resume since I got my first Libretto 50= CT laptop in the FreeBSD 3.2 days, right? I'll assume not, because othe= rwise this is somewhat insulting. I wrote a lot of the original suspend/res= ume code. I worked on it with the transition to ACPI. I saw the code stop w= orking when the GPUs started needing more state restored than could be done= with INT10 interfaces. I tried to implement that on suspend/resume. I help= ed get workarounds for X11 on suspend/resume to switch to ttyv0 before susp= ending (which worked for a while, pre drm days). What you say here is factu= ally 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 mo= des.

Except th= at 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<= br> 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.

<= div>I'm going to disagree.

Why bother. Load th= e kms drm drivers. The suspend/resume code is in those
drivers. T= hey work console, X11 and wayland, more or less.=C2=A0 It's an absolute= ly
insane idea to spend limited funds on the crazy ideas presente= d in this thread.
They are known to be flakey, unreliable or tech= nically 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@gmai= l.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 lapto= ps 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 c= ould
> work
> for S3 sleep to disk where we actually reboot to restore the machine s= tate,
> but we don't have sleep to disk today :(
>
>
>> With non-UEFI or old UGA UEFI implementations possibly one could u= se
>> the dual BIOS=C2=B4 CSM part. Just call the CSM BIOS init to set u= p 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...=C2=A0 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 w= ho
>> 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 <sblachma= nn@gmail.com>
>> > wrote:
>> >
>> >> Implementing S3 suspend/resume was a sponsored project it= self.
>> >> However, it still does only work when at xorg graphics mo= de, 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 lapto= ps 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> wro= te:
>> >> > On Thu, 2021-12-30 at 14:15, Joseph Mingrone <jrm= @FreeBSD.org>
>> >> > wrote:
>> >> >
>> >> >> On Thu, 2021-12-30 at 08:05, =C3=96zkan KIRIK &l= t;ozkan.kirik@gmail.com>
>> >> >> wrote:
>> >> >>> I've ideas about enhancing the routing a= rchitecture. Is it
>> >> >>> possible
>> >> >>> to
>> >> >>> add to wiki?
>> >> >
>> >> >> Certainly.=C2=A0 Please do.
>> >> >
>> >> > The link again is https:= //wiki.freebsd.org/2021FoundationCFI
>> >> >
>> >>
>> >>
>> >
>>
>


--0000000000006d458005d4d9d7ee--