Date: Wed, 5 Jan 2022 21:45:05 +0100 From: Stefan Blachmann <sblachmann@gmail.com> To: Warner Losh <imp@bsdimp.com> Cc: Joseph Mingrone <jrm@freebsd.org>, =?UTF-8?B?w5Z6a2FuIEtJUklL?= <ozkan.kirik@gmail.com>, Michael Schuster <michaelsprivate@gmail.com>, Kyle Evans <kevans@freebsd.org>, Karel Gardas <gardask@gmail.com>, FreeBSD Hackers <freebsd-hackers@freebsd.org> Subject: Re: 7.0 points 5.1 points Re: Call for Foundation-supported Project Ideas Message-ID: <CACc-My1HUgC9BJW0V0V8dOcB=LfyTmpCvVSEW1SkjqGmXj2nyQ@mail.gmail.com> In-Reply-To: <CANCZdfoRLM2VdGCGZAEeMF0Wt%2Bw0VZ20Zr1c0F14xLUcUFPPdg@mail.gmail.com> References: <861r36xzpe.fsf@phe.ftfl.ca> <61100a28-40ae-4458-d7d5-3bc9b13ba219@gmail.com> <CADqw_gKkii%2BBHk7_jPE0DV5ZdF86ydEq956WDtZOP1N9GBjAPw@mail.gmail.com> <CACNAnaH4GH_n8GVYN44op-VO7VZ5_GLP8SBj0SfoC5KoBSFDQw@mail.gmail.com> <CADqw_gJuU6_Wt-GEJduz_Tm0oQg4dDv-5XDz1bsgWqtCmp1R2w@mail.gmail.com> <CAAcX-AHCom%2B5Zf2ENf%2BcFxPDrCWY=e_EaXfRamd%2BwnynBn1-VQ@mail.gmail.com> <864k6qj6x6.fsf@phe.ftfl.ca> <86zgoihs64.fsf@phe.ftfl.ca> <CACc-My26b1GZ7_s93Jx-DgeA=8%2BdS_2MYSoCv_D6uzRihyNHNQ@mail.gmail.com> <CANCZdfq7s2ODPbrZRztXQ7q1aMeDtK-bsoEoW%2BZKDkiyktKUSQ@mail.gmail.com> <CACc-My1WHdgxidCiYDW2RrWxM4sKao7o_Tw-pZuuE_Y0WXC4JQ@mail.gmail.com> <CANCZdfpb=Oq1hgLRYk59duCRgVjVtu5bd4VAKR8wbgJdoi9vDg@mail.gmail.com> <CACc-My0NLTpH6Ttogcx6-XD1svsbVpg5kJaH5v8r=CiQ%2BXvMkg@mail.gmail.com> <CANCZdfoRLM2VdGCGZAEeMF0Wt%2Bw0VZ20Zr1c0F14xLUcUFPPdg@mail.gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
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 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 <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 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 <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 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 <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 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 <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, =C3=96zkan KIRIK <ozkan.kirik@gmai= l.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 >> >> >> > >> >> >> >> >> >> >> >> > >> >> >> > >> >> >> >
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?CACc-My1HUgC9BJW0V0V8dOcB=LfyTmpCvVSEW1SkjqGmXj2nyQ>