Re: [RFC] Reliable video POSTing on resume

Re: [RFC] Reliable video POSTing on resume

[Bodo Eggert]

Kendall Bennett <kendallb@scitechsoft.com> wrote:

> Laptops are a little different as they will make calls from the Video
> BIOS into the system BIOS, so you need to make sure that the system BIOS
> is also available in the execution environment.

Any video BIOS (especially EGA) may call system BIOS functions, e.g. via the
old INT10 (which will get copied to INT42).

HGC and VGA are in the system BIOS. They don't need magic, but they need to
be initialized on order to keep the monitor from burning. On the other hand,
they used to be initialised correctly.

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Thu, 2005-02-10 at 16:28 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:06:36 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> > On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> > 
> > > So perhaps this problem is something similar?
> 
> What type of computer has the problem? Who makes it's video chips?

This one is an ECS G320 laptop, with an AMI BIOS and a VIA graphics
chipset. I've had similar reports from people with a variety of
different types of laptop hardware. 

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Thu, 10 Feb 2005 21:06:36 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> 
> > So perhaps this problem is something similar?

What type of computer has the problem? Who makes it's video chips?

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Kendall Bennett]

Matthew Garrett said the following on 2/10/2005 1:06 PM:
> On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:
> 
> 
>>So perhaps this problem is something similar?
> 
> 
> I don't think so - if I dd out of ROM, I get something that looks like a
> video BIOS (and, indeed, I can make VBE calls to and from it). The
> problem is jumping to c000:0003 and executing - this has the effect of
> turning off the backlight and giving an illegal instruction error
> (I /think/ - I may be getting the machine I have here confused with one
> a tester has...)

Laptops are a little different as they will make calls from the Video 
BIOS into the system BIOS, so you need to make sure that the system BIOS 
is also available in the execution environment. So if you are using an 
x86 emulator, you need to make sure the system BIOS is mapped into the 
emulator image and that any necessary resources it might need are available.

Regards,

-- 
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Thu, 2005-02-10 at 12:46 -0800, Kendall Bennett wrote:

> So perhaps this problem is something similar?

I don't think so - if I dd out of ROM, I get something that looks like a
video BIOS (and, indeed, I can make VBE calls to and from it). The
problem is jumping to c000:0003 and executing - this has the effect of
turning off the backlight and giving an illegal instruction error
(I /think/ - I may be getting the machine I have here confused with one
a tester has...)

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Kendall Bennett]

Hi Guys,

I have missed all the original emails in this thread. I was trying to 
re-subscribe to the lkml a few days ago (I just switched over to 
Thunderbird) but I haven't been getting any traffic. So I will try again.

The one thing I can say is that having worked extensively with ATI 
cards, there are some registers that have an effect on whether the BIOS 
image shows up on at the ROM BAR address or not. To get all the ATI 
cards we have working, we have had to massage some of those registers 
because after the POST has been run, they will cause the BIOS image to 
disappear (not intentionally on ATI's part, but a side effect I think).

Note that the cards that require this work just fine if they are in a 
cold boot state when you run the POST - they only have issues after the 
POST code has been run (which actually affects X drivers trying to read 
the BIOS PLL information too).

So perhaps this problem is something similar?

Regards,

Jon Smirl said the following on 2/10/2005 12:34 PM:
> I added Kendall from Scitech to the CC list. He is the expert on
> getting VBIOS's to post. Maybe he can help.
> 
> On Thu, 10 Feb 2005 20:29:47 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> 
>>On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
>>
>>>On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
>>>
>>>>It also explicitly states that Windows 2000 and XP don't support this,
>>>>which leads me to suspect that vendors no longer expect POSTing to be
>>>>possible after initial system boot.
>>>
>>>No, it means that some of my ATI cards don't function as secondary
>>>adapters on 2K and XP.
>>
>>And nor will any other card that requires POSTing (assuming that it
>>isn't just ATI being less than honest about driver shortcomings). And
>>we've certainly seen in the past that removing support for functionality
>>in Windows tends to result in hardware no longer supporting that
>>functionality.
>>
>>I have real, shipping hardware here that fails if you simply try to
>>execute the video BIOS POST code. If you think this is due to a
>>shortcoming in existing BIOS emulations, I'm more than happy to dump the
>>video and system BIOS regions and send them to you.
>>
>>--
>>Matthew Garrett | mjg59@srcf.ucam.org
>>
>>
> 
> 
> 

-- 
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com

~ SciTech SNAP - The future of device driver technology! ~

Re: [RFC] Reliable video POSTing on resume

[Adam Sulmicki]

On Mon, 7 Feb 2005, Carl-Daniel Hailfinger wrote:

> And how many competing implementations of video helpers/emulation code
> do we have now?
>
> - scitechsoft emu
> - linuxbios emu
> - etc. (I surely forgot some)

just a minor nit-pick. "linuxbios" is not an "emulator" but drop-in 
replacement for commerical bios (on motherboards that are supported).

 	http://www.linuxbios.org/

I belive Paulo Marques and Li-Ta Lo expands linuxbios with the emulator to 
run the VIDEOBIOS contained in it, but, it just an add on.

Re: [RFC] Reliable video POSTing on resume

[Li-Ta Lo]

On Mon, 2005-02-07 at 07:27, Paulo Marques wrote:
> I still don't have hard numbers from the work Li-Ta Lo is doing (I'm 
> CC'ing him on this thread to see if he can shed some light here), but I 
> guess that you could have the complete emulator for about 50kB of code.

The difference between the "uncompressed" romimage is 41376 bytes for
Tyan S2885 mainboard. The difference of compressed romimage is 16943 
bytes.

Ollie

Re: [RFC] Reliable video POSTing on resume

[Li-Ta Lo]

On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
> Hi!
> 
> > > 3 - it's always there and can be executed at *any* time: booting,
> > > returning from suspend, etc. Also it would allow the VESA framebuffer
> > > driver to change graphics mode at any time (for instance).
> > 
> > OK, and what would force you to do the above in the kernel? If the code
> > lives in initramfs, it can be called very early, too.
> 
> It will be easier to debug in kernel than in initramfs, for
> one. Kernel code is bad enough, but initramfs running while kernel is
> not even initialized is going to be even more "fun".
> 								Pavel

One good thing about the emulator is it is very portable. There is
virtually no stdlib dependency. We can freely move it between user
and kernel space. When integrating the emulator into LinuxBIOS,
we first tried to use it as an user space program and then "port" it
into "kernel" space. The porting was done in a few days and the most
of the time was spent fixing LinuxBIOS itself than doing any "porting".
Actually, the same emulator source were used in both user and kernel
space as a kind of regression test.

Ollie

Re: [RFC] Reliable video POSTing on resume

[Pavel Machek]

Hi!

> > 3 - it's always there and can be executed at *any* time: booting,
> > returning from suspend, etc. Also it would allow the VESA framebuffer
> > driver to change graphics mode at any time (for instance).
> 
> OK, and what would force you to do the above in the kernel? If the code
> lives in initramfs, it can be called very early, too.

It will be easier to debug in kernel than in initramfs, for
one. Kernel code is bad enough, but initramfs running while kernel is
not even initialized is going to be even more "fun".
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [RFC] Reliable video POSTing on resume

[Paulo Marques]

Carl-Daniel Hailfinger wrote:
> Paulo Marques schrieb:
>[...]
>>It seems to me that x86 emulation in the kernel is the way to go because:
>>
>>[...]
>>
>>3 - it's always there and can be executed at *any* time: booting,
>>returning from suspend, etc. Also it would allow the VESA framebuffer
>>driver to change graphics mode at any time (for instance).
> 
> 
> OK, and what would force you to do the above in the kernel? If the code
> lives in initramfs, it can be called very early, too.

Not as early, anyway, and it would make the setup for the initramfs (at 
boot) and the resume much more complex.

The line line between what should go in the kernel and what should live 
in user space as always been a fuzzy one, and it's been moving in a 
dangerous direction lately, IMHO.

In my opinion there are 3 major factors for something to go into the kernel:

1 - resource management between user space processes (this includes 
locking, etc.)

2 - performance

3 - hardware abstraction

This latest point is being more and more ignored by kernel developers.

In a previous thread about using the frame buffer accelerated operations 
from user space, Jammes Simmons wrote:

"You can mmap the mmio address space and program the registers yourself."

and just 3 minutes later, Geert Uytterhoeven wrote too:

"mmap() the MMIO registers to userspace, and program the acceleration 
engine from userspace, like DirectFB (and XF*_FBDev 3.x for Matrox and 
Mach64) does."

This is a even more horrid example, because the drivers in the kernel 
already have the code to do the accelerated functions, and we just don't 
have the interface for them to be called from user space.

It is another example of "this can be done from user space, so why put 
it in the kernel". To have a consistent interface for similar operations 
without having to know the underlying hardware, perhaps?

At least Helge Hafting wrote on the same thread:

"I believe you also can write a small driver that connects to the
framebuffer the same way the fbconsole does.  It could then
export all the operations so userspace actually can call them."

Which seemed a much better solution to me.

> And how many competing implementations of video helpers/emulation code
> do we have now?
> 
> - scitechsoft emu
> - linuxbios emu

I think these two are the same (or at least that is what Li-Ta Lo is 
working on)

> - etc. (I surely forgot some)

This one I've never heard of :)

Anyway, as it happens with anything in the kernel, several different 
solutions for the same problem get selected by "natural" selection, and 
evolve "genetically" into the final version.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Paulo Marques schrieb:
> Adam Sulmicki wrote:
> 
>>
>> hi all,
>>     I would like point to work done by Li-Ta Lo.
>>
>>     It allows you to completely initalize the VGA BIOS w/out using
>>     PC BIOS at all.
>>
>>    
>> http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html
>>     unforunatelly the information the web is somewhat sparse, but
>>     you can get more info by following the archive of the
>>     thread (which head I listed above) and perhaps by posting to
>>     linuxbios mailing list (Ollie, is somewhat buy those days with his
>>     new baby).
> 
> 
> I did some work on reducing the core x86 emulation code (and have my
> name mentioned in that thread for it). The code size went from 59kB to
> 38kB. This does not include emulation of BIOS functions or hardware
> (like the standard PC timer).
> 
> It seems to me that x86 emulation in the kernel is the way to go because:
> 
> [...]
> 
> 3 - it's always there and can be executed at *any* time: booting,
> returning from suspend, etc. Also it would allow the VESA framebuffer
> driver to change graphics mode at any time (for instance).

OK, and what would force you to do the above in the kernel? If the code
lives in initramfs, it can be called very early, too.


And how many competing implementations of video helpers/emulation code
do we have now?

- scitechsoft emu
- linuxbios emu
- etc. (I surely forgot some)


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[Paulo Marques]

Adam Sulmicki wrote:
> 
> hi all,
>     I would like point to work done by Li-Ta Lo.
> 
>     It allows you to completely initalize the VGA BIOS w/out using
>     PC BIOS at all.
> 
>     http://www.clustermatic.org/pipermail/linuxbios/2005-January/010236.html 
> 
>     unforunatelly the information the web is somewhat sparse, but
>     you can get more info by following the archive of the
>     thread (which head I listed above) and perhaps by posting to
>     linuxbios mailing list (Ollie, is somewhat buy those days with his
>     new baby).

I did some work on reducing the core x86 emulation code (and have my 
name mentioned in that thread for it). The code size went from 59kB to 
38kB. This does not include emulation of BIOS functions or hardware 
(like the standard PC timer).

It seems to me that x86 emulation in the kernel is the way to go because:

1 - it's portable. Can run on any architecture.

2 - runs in a controled environment. Every memory / io access is 
controlled by the emulator. We don't just "jump" into obscure BIOS code 
and hope everything goes well.

3 - it's always there and can be executed at *any* time: booting, 
returning from suspend, etc. Also it would allow the VESA framebuffer 
driver to change graphics mode at any time (for instance).

I still don't have hard numbers from the work Li-Ta Lo is doing (I'm 
CC'ing him on this thread to see if he can shed some light here), but I 
guess that you could have the complete emulator for about 50kB of code.

-- 
Paulo Marques - www.grupopie.com

All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 05 Feb 2005 08:15:35 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:
> 
> > I suspect the problem in that case is a compressed VBIOS. Some laptops
> > compress the VBIOS and the system BIOS into a single ROM and then
> > expand them at power on. Sounds like this is not happening on resume.
> > To get around the problem copy the image from C000:0 before suspend to
> > a place in preserved RAM where wakeup.S can find it and then copy it
> > back to C000:0 on resume. To test for this checksum C000:0 before
> > suspend and after and see if it has changed.
> 
> No, that's not what's happening. If you disassemble the code at
> c000:blah in a laptop, you'll often find that it jumps off to a
> completely different section of address space. During POST, that
> contains video BIOS. After POST, it may be something like USB boot
> support. Without reading it directly out of flash, it's not possible to
> recover that code.

If the copy left at C000:0 is jumping off to F000:xx (system BIOS)
that is a valid thing to do and the reset program may need more
emulation hooks. If it is jumping off somewhere else then I would
consider that a broken VBIOS since jumping to C000:3 for reset is part
of how VGA is supposed to work. If this is happening on an ATI or
Nvidia chip you're probably never going to get video resume working.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 5 Feb 2005 10:37:40 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> > > I do not understand how initramfs fits into picture... Plus lot of
> > > people (me :-) do not use initramfs...
> >
> > The final fix for this will include the video reset app on initramfs.
> > I already have code in the kernel for telling the primary video card
> > from secondary ones. When the kernel is initially booting and finds
> 
> Is initramfs preserved when system is running? I was under impression
> that it is freed when we mount real / fs.

It doesn't matter if it is mounted or unmounted. The reset program is
just an app and another copy can live in /sbin. It's only on initrams
so that it can initial the video during early boot allowing you to see
error messages at that stage.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary
<linux@rainbow-software.org> wrote:
> I wonder how this can work:
> a motherboard with i815 chipset (integrated VGA), Video BIOS is
> integrated into system BIOS
> a PCI card inserted into one of the PCI slots, configured as primary in
> system BIOS

The info needed to initialize Intel chips is public. The info needed
to initialize most Nvidia and ATI chips is not.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Sat, 2005-02-05 at 12:53 +0100, Ondrej Zary wrote:

> I wonder how this can work:
> a motherboard with i815 chipset (integrated VGA), Video BIOS is 
> integrated into system BIOS
> a PCI card inserted into one of the PCI slots, configured as primary in 
> system BIOS

The issue seems to be specific to laptops. Regardless, it's likely that
Windows knows how to initialise the card without needing to use the
BIOS.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Ondrej Zary]

Matthew Garrett wrote:
> On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:
> 
> 
>>I suspect the problem in that case is a compressed VBIOS. Some laptops
>>compress the VBIOS and the system BIOS into a single ROM and then
>>expand them at power on. Sounds like this is not happening on resume.
>>To get around the problem copy the image from C000:0 before suspend to
>>a place in preserved RAM where wakeup.S can find it and then copy it
>>back to C000:0 on resume. To test for this checksum C000:0 before
>>suspend and after and see if it has changed.
> 
> 
> No, that's not what's happening. If you disassemble the code at
> c000:blah in a laptop, you'll often find that it jumps off to a
> completely different section of address space. During POST, that
> contains video BIOS. After POST, it may be something like USB boot
> support. Without reading it directly out of flash, it's not possible to
> recover that code.

I wonder how this can work:
a motherboard with i815 chipset (integrated VGA), Video BIOS is 
integrated into system BIOS
a PCI card inserted into one of the PCI slots, configured as primary in 
system BIOS

During POST, the PCI card BIOS is initialized. I boot Windows 98SE - 
then the onboard VGA initializes and I can use 2 monitors.
So either:
1. The driver can initialize the onboard VGA on its own (without VGA BIOS)
or
2. There is a way how to get the onboard VGA BIOS code from system BIOS


-- 
Ondrej Zary

Re: [RFC] Reliable video POSTing on resume

[Ondrej Zary]

Pavel Machek wrote:
> Hi!
> 
> 
>>>We already try to do that, but it hangs on 70% of machines. See
>>>Documentation/power/video.txt.
>>
>>We know that all of these ROMs are run at power on so they have to
>>work. This implies that there must be something wrong with the
>>environment the ROM are being run in. Video ROMs make calls into the
>>INT vectors of the system BIOS. If these haven't been set up yet
>>running the VBIOS is sure to hang.  Has someone with ROM source and
>>the appropriate debugging tools tried to debug one of these hangs?
>>Alternatively code could be added to wakeup.S to try and set these up
>>or dump the ones that are there and see if they are sane.
> 
> 
> Rumors say that notebooks no longer have video bios at C000h:0; rumors
> say that video BIOS on notebooks is simply integrated into main system
> BIOS. I personaly do not know if rumors are true, but PCs are ugly
> machines....

On systems with integrated graphics chips, there is no separate ROM chip 
for Video BIOS. Instead, it's integrated into system BIOS (this is true 
for onboard SCSI and pseudo-RAID controllerss too). During early 
initialization, system BIOS decompresses and initializes these BIOSes 
(if these is a PCI vendor ID and device ID match). (There is nothing 
wrong with this - BIOSes on PCI cards should not be run directly from 
the card's ROM but copied to RAM and executed from there instead 
according to PCI spec.)
After the POST is complete, the BIOSes are shadowed in RAM so Video BIOS 
is at C000:0 - so you can run DOS for example.

-- 
Ondrej Zary

Re: [RFC] Reliable video POSTing on resume

[Nigel Cunningham]

Hi.

On Sat, 2005-02-05 at 20:37, Pavel Machek wrote:
> Hi!
> 
> > > I do not understand how initramfs fits into picture... Plus lot of
> > > people (me :-) do not use initramfs...
> > 
> > The final fix for this will include the video reset app on initramfs.
> > I already have code in the kernel for telling the primary video card
> > from secondary ones. When the kernel is initially booting and finds
> 
> Is initramfs preserved when system is running? I was under impression
> that it is freed when we mount real / fs.

I think the assumption is that it's never unmounted.

Nigel
-- 
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com

Ph: +61 (2) 6292 8028      Mob: +61 (417) 100 574

Re: [RFC] Reliable video POSTing on resume

[Pavel Machek]

Hi!

> > I do not understand how initramfs fits into picture... Plus lot of
> > people (me :-) do not use initramfs...
> 
> The final fix for this will include the video reset app on initramfs.
> I already have code in the kernel for telling the primary video card
> from secondary ones. When the kernel is initially booting and finds

Is initramfs preserved when system is running? I was under impression
that it is freed when we mount real / fs.
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Fri, 2005-02-04 at 21:30 -0500, Jon Smirl wrote:

> I suspect the problem in that case is a compressed VBIOS. Some laptops
> compress the VBIOS and the system BIOS into a single ROM and then
> expand them at power on. Sounds like this is not happening on resume.
> To get around the problem copy the image from C000:0 before suspend to
> a place in preserved RAM where wakeup.S can find it and then copy it
> back to C000:0 on resume. To test for this checksum C000:0 before
> suspend and after and see if it has changed.

No, that's not what's happening. If you disassemble the code at
c000:blah in a laptop, you'll often find that it jumps off to a
completely different section of address space. During POST, that
contains video BIOS. After POST, it may be something like USB boot
support. Without reading it directly out of flash, it's not possible to
recover that code.

> You can always do a simple test. If a program like vbios.vm86 or
> vbetool can reset the card, then there is no reason wakeup.S shouldn't
> be able to do it too if the environment is set up correctly.

These tools can cause machines to hang, even if run immediately after
boot (and without X running). On other machines, things are less bad -
they just switch the backlight off instead. On some machines (Thinkpads
are quite good in this respect), they'll work nicely.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 05 Feb 2005 02:17:22 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On laptops, it's frequently the case that c000:0003 will jump to a
> section of code that is no longer mapped into the address space.
> Instead, it's entirely possible that some other section of BIOS will be
> mapped there. The resulting behaviour is undefined, and can cause the
> hardware to hang.

I suspect the problem in that case is a compressed VBIOS. Some laptops
compress the VBIOS and the system BIOS into a single ROM and then
expand them at power on. Sounds like this is not happening on resume.
To get around the problem copy the image from C000:0 before suspend to
a place in preserved RAM where wakeup.S can find it and then copy it
back to C000:0 on resume. To test for this checksum C000:0 before
suspend and after and see if it has changed.

You can always do a simple test. If a program like vbios.vm86 or
vbetool can reset the card, then there is no reason wakeup.S shouldn't
be able to do it too if the environment is set up correctly.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Fri, 2005-02-04 at 21:09 -0500, Jon Smirl wrote:

> How does the hardware die? Are you sure that it is not simply a bug in
> the program doing the POST? Look at the scitech source and you will
> see many BIOS quirks that have to be emulated in order for the post to
> work. If your post program is missing any of these the post won't
> work. So far every time I have encountered a non-working post it was
> fixed by tweaking some things in the post program.

On laptops, it's frequently the case that c000:0003 will jump to a
section of code that is no longer mapped into the address space.
Instead, it's entirely possible that some other section of BIOS will be
mapped there. The resulting behaviour is undefined, and can cause the
hardware to hang.

-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 05 Feb 2005 02:04:49 +0000, Matthew Garrett <mjg59@srcf.ucam.org> wrote:
> On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote:
> 
> > Fixing this at kernel boot (resume) time will let user space apps
> > assume that all video cards are reset. That removes a lot of
> > complexity from the user space apps (like X).
> 
> This can't be the default on x86. I have hardware that will die if you
> attempt to POST it after the BIOS has started the OS. Non-x86 should be
> fine, though.

How does the hardware die? Are you sure that it is not simply a bug in
the program doing the POST? Look at the scitech source and you will
see many BIOS quirks that have to be emulated in order for the post to
work. If your post program is missing any of these the post won't
work. So far every time I have encountered a non-working post it was
fixed by tweaking some things in the post program.

> --
> Matthew Garrett | mjg59@srcf.ucam.org
> 
> 


-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Matthew Garrett]

On Fri, 2005-02-04 at 12:31 -0500, Jon Smirl wrote:

> Fixing this at kernel boot (resume) time will let user space apps
> assume that all video cards are reset. That removes a lot of
> complexity from the user space apps (like X).

This can't be the default on x86. I have hardware that will die if you
attempt to POST it after the BIOS has started the OS. Non-x86 should be
fine, though.
-- 
Matthew Garrett | mjg59@srcf.ucam.org

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Pavel Machek schrieb:
> 
> I do not understand how initramfs fits into picture... Plus lot of
> people (me :-) do not use initramfs...

Well, an initrd which is never unmounted should work, too. On SUSE,
"mkdir /initrd" and see what you've been missing. I don't know why
that directory doesn't exist by default except for the reason that
freeing the initrd frees some memory.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Xavier Bestel schrieb:
> Le vendredi 04 février 2005 à 00:03 -0500, Jon Smirl a écrit :
> 
>>Doing this in user space lets you have two reset
>>programs, vm86 and emu86 for non-x86 machines.
> 
> 
> Perhaps only emu86 should be used, to have a well-debugged codepath on
> all archs (amd64, ppc, ...)
> As it's usermode, the code size is less of a problem.

Well, if it has to live in initramfs, it better be really small.
An initramfs with a size of 8 megabytes isn't going to make you
many friends.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Sat, 05 Feb 2005 01:52:23 +0100, Carl-Daniel Hailfinger
<c-d.hailfinger.devel.2005@gmx.net> wrote:
> My problem (Samsung P35) is that the BIOS wants to call code which
> is no longer mapped because the BIOS is too big to fit into the
> standard area. Since that additional area has been overwritten, we
> are out of luck. Maybe if we did something like backing up all

Look at the scitech source code. There are a limited number of system
BIOS calls that need to be implemented. It is a fairly small number.
wakeup.S could supply implementations for these and patch them into
the right interrupt vectors while the VBIOS is being run. There is no
requirement that VBIOS run the actual system BIOS, it only has to
think that it is running on the system BIOS. This is the same scheme
used for running the ROMs in user space.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

James Simmons schrieb:
>>>int video_helper(struct video_actions *what_to_do)
>>
>>I do not know, synchronously executing userland code from kernel seems
>>like wrong thing to do.
> 
> I'm not a fan for this either. The good news is most graphics cards don't 
> require these tricks. The only ones that do are the ix86 cards. The real 
> solution would be if the hradware vendors open the parts of the spec to do 
> what we need. Many of the older cards could be supported in this way if we
> talk to the vendors. They shouldn't care if the specs are released anymore. 
> The problem would be the latest Radeon card and NVIDIA cards which 
> unfortunely are the most common cards for x86 platforms ;-(

Well, either you call userspace synchronously or you crash on resume.
I know what I prefer. And this synchronous call isn't so bad because
it comes with a timeout. So whatever the userspace program does, after
two seconds the kernel will continue unaffected. Once you execute the code
asynchronously, you get nondeterministic behaviour. That's sure fun for
filling up your random pool, but I wouldn't trust my data to such a system.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Jon Smirl schrieb:
> On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> 
>>We already try to do that, but it hangs on 70% of machines. See
>>Documentation/power/video.txt.
> 
> We know that all of these ROMs are run at power on so they have to
> work. This implies that there must be something wrong with the
> environment the ROM are being run in. Video ROMs make calls into the
> INT vectors of the system BIOS. If these haven't been set up yet
> running the VBIOS is sure to hang.  Has someone with ROM source and
> the appropriate debugging tools tried to debug one of these hangs?
> Alternatively code could be added to wakeup.S to try and set these up
> or dump the ones that are there and see if they are sane.

My problem (Samsung P35) is that the BIOS wants to call code which
is no longer mapped because the BIOS is too big to fit into the
standard area. Since that additional area has been overwritten, we
are out of luck. Maybe if we did something like backing up all
untouched real mode memory immediately after switching to protected
mode, it could work. But I don't know whether that is feasible on
boot. Anyways, you don't want to run possibly buggy closed source
bios code in an environment where a single random memory write
may corrupt the kernel without debuggability.

And sometimes there is BIOS code which is can't be run twice.
Period.
Don't believe that one? I have a machine where calling EDD code
in the BIOS twice will hang the second time. See boot parameter
edd=off for reference :-(

So I agree that we could try to preserve the state better, but
I also can guarantee you it won't help everywhere.


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[James Simmons]

> I would prefer to use hotplug for the user space call out but when I
> do I run into the framebuffer and DRM drivers. This having multiple
> drivers for the same piece of hardware is a pain. So hotplug on the
> standard device is not an option.

I know. It could be merged. The secert is a gradual move to /sys/graphics/
for both interfaces :-)

Re: [RFC] Reliable video POSTing on resume

[James Simmons]

> > int video_helper(struct video_actions *what_to_do)
> 
> I do not know, synchronously executing userland code from kernel seems
> like wrong thing to do.

I'm not a fan for this either. The good news is most graphics cards don't 
require these tricks. The only ones that do are the ix86 cards. The real 
solution would be if the hradware vendors open the parts of the spec to do 
what we need. Many of the older cards could be supported in this way if we
talk to the vendors. They shouldn't care if the specs are released anymore. 
The problem would be the latest Radeon card and NVIDIA cards which 
unfortunely are the most common cards for x86 platforms ;-(

Re: [RFC] Reliable video POSTing on resume

[James Simmons]

> Jon does your emulator sit on top of the new legacy I/O and memory APIs?  I 
> added them for this very reason, though atm only ia64 supports them.  There's 
> documentation in Documentation/filesystems/sysfs-pci.txt if you want to take 
> a look.  On kernels that support it, sysfs can be a one stop shop for all 
> your gfx programming needs, since it provides access to the rom, PCI 
> resources (i.e. MMIO ranges, fb memory, etc.) and legacy I/O ports and 
> memory.

Thanks for the info. Actually the is what /sys/bus/graphics is for. I'm 
working on some patchs to migrate the fbdev subsystem to using it.

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Fri, 4 Feb 2005 10:10:12 -0800, Jesse Barnes <jbarnes@engr.sgi.com> wrote:
> Jon does your emulator sit on top of the new legacy I/O and memory APIs?  I
> added them for this very reason, though atm only ia64 supports them.  There's
> documentation in Documentation/filesystems/sysfs-pci.txt if you want to take

The link I am posting is to the original scitech code which is free to
use. I have a bunch of versions on my local machine but none are up to
using all of the new sysfs APIs. Looking at the sysfs calls it is
simple to convert the reset app to use them. The reset app is already
trapping the io/out instructions.

Instead I have been concentrating on feeding new babies and getting
the last two pieces of kernel support in. We still need a solution for
VGA routing (I posted on but the design needs work) and making the
initial user space call out.

I would prefer to use hotplug for the user space call out but when I
do I run into the framebuffer and DRM drivers. This having multiple
drivers for the same piece of hardware is a pain. So hotplug on the
standard device is not an option.

Other options would be to directly call_usermodehelper() or create a
temporary class device for each VGA card as it is found. The temp VGA
device would trigger the reset app. They would be temp since there may
be multiple ones.

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Jesse Barnes]

On Friday, February 4, 2005 9:31 am, Jon Smirl wrote:
> For non-x86 systems put an emu version on initramfs. My statically
> linked against klibc x86 reset app is about 15K. The emu version is
> significantly bigger but there is no way to avoid it if you are using
> x86 hardware in a non-x86 box.

Jon does your emulator sit on top of the new legacy I/O and memory APIs?  I 
added them for this very reason, though atm only ia64 supports them.  There's 
documentation in Documentation/filesystems/sysfs-pci.txt if you want to take 
a look.  On kernels that support it, sysfs can be a one stop shop for all 
your gfx programming needs, since it provides access to the rom, PCI 
resources (i.e. MMIO ranges, fb memory, etc.) and legacy I/O ports and 
memory.

Jesse

Re: [RFC] Reliable video POSTing on resume

[Jon Smirl]

On Fri, 4 Feb 2005 17:30:19 +0100, Pavel Machek <pavel@ucw.cz> wrote:
> I do not understand how initramfs fits into picture... Plus lot of
> people (me :-) do not use initramfs...

The final fix for this will include the video reset app on initramfs.
I already have code in the kernel for telling the primary video card
from secondary ones. When the kernel is initially booting and finds
the secondary cards it will do a call_usermodehelper() and execute the
video reset app. This happens very early in the boot sequence so it
needs to be on initramfs. There are also a few embedded type systems
that don't even post their primary video hardware they need this
support too.

For non-x86 systems put an emu version on initramfs. My statically
linked against klibc x86 reset app is about 15K. The emu version is
significantly bigger but there is no way to avoid it if you are using
x86 hardware in a non-x86 box.

Fixing this at kernel boot (resume) time will let user space apps
assume that all video cards are reset. That removes a lot of
complexity from the user space apps (like X).

-- 
Jon Smirl
jonsmirl@gmail.com

Re: [RFC] Reliable video POSTing on resume

[Pavel Machek]

Hi!

> > 3) The user space reset programs have to be serialized because of the
> > rule about only a single VGA at a time. Calling vm86 from kernel mode
> > is not a good idea. Doing this in user space lets you have two reset
> > programs, vm86 and emu86 for non-x86 machines.
> 
> With the approach I detailed in the thread starter, this is easily
> possible. vesaposter can call the kernel function used to synchronize
> in an endless loop and this kernel function would not only be used
> to synchronize, but its return value would tell vesaposter what to do
> to which card. An alternative would be to restart vesaposter as soon
> as it has finished its job, which would make the POSTing reliable
> even if the BIOS code hangs or causes crashes. The kernel can simply
> store a list of video devices and their respective treatments and
> the kernel function called by vesaposter would just iterate through
> the list. Hmmm... why not call it
> 
> int video_helper(struct video_actions *what_to_do)

I do not know, synchronously executing userland code from kernel seems
like wrong thing to do.

> And the problem of locking all application memory: The current tool
> for POSTing and restoring video state (vbetool) uses only 27k on
> disk. If we put it in initramfs, we could maybe avoid mlock
> completely (if we can guarantee initramfs contents aren't swapped
> out). And it would be available early enough for initializing
> video hardware on boot.

I do not understand how initramfs fits into picture... Plus lot of
people (me :-) do not use initramfs...
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [RFC] Reliable video POSTing on resume

[Pavel Machek]

Hi!

> >>What about simply blocking all video accesses before disk (etc) is
> >>resumed, so that "normal" (not locked in memory) application can be
> >>used?
> > 
> > Very bad for debugging. Genuine serial ports are becoming rarer.
> 
> As a bonus, even genuine serial ports may be in undefined state after
> resume. I'm unfortunate enough to have a brand new notebook with
> serial port, but the serial console code will print garbage after
> resume until I do a
> echo foo >/dev/ttyS0

It seems that open helps here. Can you confirm with >/dev/ttyS0
(i.e. without echo foo?). If it helps, all you need to do is simulate
open/close from _resume() routine....
								Pavel
-- 
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Jon Smirl schrieb:
> Reseting a video card from suspend is essentially the same problem as
> reseting secondary video cards on boot. The same code can address both
> problems.
> 
> Some things to consider....
> 
> 1) With multiple video cards you have to ensure only a single VGA gets
> enabled. Running video reset on a card is going to turn on it's VGA
> emulation. So you have to ensure that VGA emulation on other cards is
> disabled first.

No problem. Let the kernel tell the userspace application which card
to reset.

> 2) I add the 'rom' parameter in sysfs so that you can get to the rom
> contents from a user space app. It's there to support running video
> reset code. "echo 1 >rom" to see the contents, it is not enabled by
> default.

That could be very helpful for secondary cards.

> 3) The user space reset programs have to be serialized because of the
> rule about only a single VGA at a time. Calling vm86 from kernel mode
> is not a good idea. Doing this in user space lets you have two reset
> programs, vm86 and emu86 for non-x86 machines.

With the approach I detailed in the thread starter, this is easily
possible. vesaposter can call the kernel function used to synchronize
in an endless loop and this kernel function would not only be used
to synchronize, but its return value would tell vesaposter what to do
to which card. An alternative would be to restart vesaposter as soon
as it has finished its job, which would make the POSTing reliable
even if the BIOS code hangs or causes crashes. The kernel can simply
store a list of video devices and their respective treatments and
the kernel function called by vesaposter would just iterate through
the list. Hmmm... why not call it

int video_helper(struct video_actions *what_to_do)

and it blocks until we have something to POST. It could contain
all the locking needed to serialize access to the video cards.
OTOH, if starting applications from initramfs at resume time is
easy, we could make video_helper non-blocking and start vesaposter
on demand.


And the problem of locking all application memory: The current tool
for POSTing and restoring video state (vbetool) uses only 27k on
disk. If we put it in initramfs, we could maybe avoid mlock
completely (if we can guarantee initramfs contents aren't swapped
out). And it would be available early enough for initializing
video hardware on boot.


> A starting place for a user space reset program:
> ftp://ftp.scitechsoft.com/devel/obsolete/x86emu/x86emu-0.8.tar.gz
> 
> This thread talks about the VGA routing code:
> http://lkml.org/lkml/2005/1/17/347

Thanks for the pointers! I'll have to compare it to our current
userspace reset and vesa register restoring program
http://www.srcf.ucam.org/~mjg59/vbetool/


Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/

Re: [RFC] Reliable video POSTing on resume

[Carl-Daniel Hailfinger]

Oliver Neukum schrieb:
> Am Freitag, 4. Februar 2005 08:48 schrieb Pavel Machek:
> 
>>What about simply blocking all video accesses before disk (etc) is
>>resumed, so that "normal" (not locked in memory) application can be
>>used?
> 
> Very bad for debugging. Genuine serial ports are becoming rarer.

As a bonus, even genuine serial ports may be in undefined state after
resume. I'm unfortunate enough to have a brand new notebook with
serial port, but the serial console code will print garbage after
resume until I do a
echo foo >/dev/ttyS0

I've already sent mail to linux-serial for that problem, but the
list appears to be dead. Any pointers to the right contact would
be appreciated.

Regards,
Carl-Daniel
-- 
http://www.hailfinger.org/