From nobody Wed Jan 5 20:45:05 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 C659D193FE64 for ; Wed, 5 Jan 2022 20:45:09 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: from mail-lf1-x12f.google.com (mail-lf1-x12f.google.com [IPv6:2a00:1450:4864:20::12f]) (using TLSv1.3 with cipher TLS_AES_128_GCM_SHA256 (128/128 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256 client-signature RSA-PSS (2048 bits) client-digest SHA256) (Client CN "smtp.gmail.com", Issuer "GTS CA 1D4" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 4JThLs4dBRz4sM2; Wed, 5 Jan 2022 20:45:09 +0000 (UTC) (envelope-from sblachmann@gmail.com) Received: by mail-lf1-x12f.google.com with SMTP id j11so573531lfg.3; Wed, 05 Jan 2022 12:45:09 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=3BBC35hokbw3IJizJkcjHV7CwBJtvXV9kipfgysltVc=; b=AbZb6bo5+ll/5Mvpa8NnI90CkUGtY+4f92IsLqD3ZtjU8KmKH6ZzppJicUzlnMtEzH 1RZK+kMoLHiTMvg7vm4BDN2sjQiWADqpTZpxZCvsXXpN8lztV9TblKB31yhF16QzMntB vjabPWrzhDWy0llEN1CAXA3bwKTR9ekzSwMBuNJLP/6coPYghFXN7hyzUfiGjq7WJzVw zAiOg1NO7qyFgGYQejNRV4dHoy0PWiYGnz9O7h6ktTwpBOAU48t0JNgy5o+ms0fts5Lh u2kx2uYPFOMQ5U/zUKpXbRZqW6iCns0+exDl7Nomvp8NuchStbe2WYRx/bmF6A/GdLfH upew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=3BBC35hokbw3IJizJkcjHV7CwBJtvXV9kipfgysltVc=; b=QIgrl7Rm+78XBoIVde7yDneLkYCzwxr/9ztMT4We9KGiBhn8YUdKoVmyBmLU52qvkX WDg696rP6LL+KO9Xu833fvwRqAmNT2BJGg88jCPhHyMhEf9d0INzA86Kw2Cs1XeHt6p2 aFYSXCIsxmYqyNxhlAqIfbPasI3se9jZsOQXZ+eRR4IFyX0Ni8J4h/Nl/RamURt/8gjk lo7da2Hey/abqR1F0bqQN2+zNIrkM2V+QzshqZcHmAzZItBzOJwT1Pz/r674JKm6mDjd yqaRuzVEJihl/il5ZxRhcv8rpyD5W3mkGrhPtysh3/4BSsChKfXfb0rNBOSq+B5h6q6R i4eA== X-Gm-Message-State: AOAM530lCYbdSMHpnJWqpcDwT9thXIgbGu4EeaBLf6d8nJXTfefxK2O4 G9/Z1cOIOcJHBYM7Kn8PXMSfirIDCeb9UPi2jB8= X-Google-Smtp-Source: ABdhPJxRsZY6xglXYOS59cMOoP+h84BYqHwUg1EGiVDDhEV9Yc9yhXtsH1kaJOhxtDZO6CUlhVMvUFw05THMPVgI9g4= X-Received: by 2002:a05:6512:5c8:: with SMTP id o8mr48961440lfo.659.1641415506722; Wed, 05 Jan 2022 12:45:06 -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: Sender: owner-freebsd-hackers@freebsd.org MIME-Version: 1.0 Received: by 2002:a2e:920a:0:0:0:0:0 with HTTP; Wed, 5 Jan 2022 12:45:05 -0800 (PST) In-Reply-To: References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> From: Stefan Blachmann Date: Wed, 5 Jan 2022 21:45:05 +0100 Message-ID: Subject: Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas To: Warner Losh Cc: Joseph Mingrone , =?UTF-8?B?w5Z6a2FuIEtJUklL?= , Michael Schuster , Kyle Evans , Karel Gardas , FreeBSD Hackers Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Rspamd-Queue-Id: 4JThLs4dBRz4sM2 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-ThisMailContainsUnwantedMimeParts: N On 1/5/22, Warner Losh 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 i= t. 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=3D224069#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 updat= es. Cheers, Stefan On 1/5/22, Warner Losh wrote: > 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 X= 11 > 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 >> >> > 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 th= e >> >> > 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 G= PU 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 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 wit= h >> >> >> 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 th= e >> >> > 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 >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >