Hi!
Nigel Cunningham wrote:
> Hi.
>
> On Fri, 2005-02-04 at 09:54, Pavel Machek wrote:
>
>>Hi!
>>
>>
>>>>>Are you able to use framebuffer(radeonfb,1024x768) with this
>>>>>configuration or do you need to use plain vga-console for it to work?
>>>>
>>>>No.
>>>>For a working framebuffer console you would have to perform the steps
>>>>my script does *before* the kernel tries to access the framebuffer
>>>>console after resume. Since this is not yet possible, you're out of
>>>>luck. If
>>>>- the vbestate utility was a kernel module or
>>>
>>>OK, I managed to track this down further.
>>>"vbetool post" should be equivalent to "acpi_sleep=s3_bios", but there
>>>are some differences. For me, that's easy to explain: "vbetool post"
>>>segfaults because it wants to access parts of the video bios which
>>>are no longer available. "acpi_sleep=s3_bios" suffers from the same
>>>problem, but it runs in real mode and can't recover :-(
>>>
>>>To alleviate that problem, the kernel could run the video bios in
>>>vm86 mode (like vbetool does by using lrmi). This would simplify
>>>the asm wakeup code and make video POST more reliable.
>>>
>>>Pavel, what do you think?
>>
>>Well, calling BIOS using vm86 is going to be quite a lot of code. If
>>it is self-contained and not too huge, it is probably okay. It should
>>help with quite a lot of cards, but who knows...
>>
>>Yes, it is probably worth trying.
>
> I'd love to see it too. Pavel, even if you don't want to merge it for a
> while, we can always incorporate it in the Suspend2 patches so it gets
> some testing. I know I'd try it on my i830 based Omnibook.
Can we use call_usermodehelper at this early resume stage (before any
video access)? Calling vm86 directly is probably not going to fly
because we want to be shielded from any misbehaviour in the bios code
and it may be necessary to kill the process running the bios code.
Cases in point: My bios will cause the POSTing application to segfault.
Others have reported the POSTing application just hangs, but the
important things are done before the hang, so killing it after maybe
5 seconds would be ok.
Rough outline how to do that without adding tons of code:
We need a call_usermodehelper_from_ram_with_timeout for that.
Kernel: Userspace:
User wants to enter S3
init_mutex_locked(s3_sem)
call_usermodehelper("vesaposter")
vesaposter calls LRMI_init
vesaposter mlocks all its memory
vesaposter calls into kernel
and down(s3_sem)
suspend vesafb
User has triggered resume
run wakeup.S
thaw essential threads
set a timer of 5 seconds
up(s3_sem)
thaw and schedule vesaposter
wait for timer or vesaposter termination
vesaposter returns from kernel
vesaposter posts video card
vesaposter terminates
resume vesafb
continue resume
Problems with that approach:
- vesaposter has to be locked in memory to avoid disk accesses
- vesafb has to refrain from touching video until after POST
- the vesaposter thread has to be the first unfrozen and
scheduled and completed thread. Only after that we can resume
vesafb and other threads
- the locking will be tricky
Advantages:
- the problems all seem to be solvable easily
- security and stability are similar to the current userspace code
- we can use vesafb on such machines
- the kernel code won't be much more than two dozen lines
- the userspace POSTing code can be upgraded without the need
for kernel updates (no policy in the kernel)
What do you think?
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Hi.
On Fri, 2005-02-04 at 13:35, Carl-Daniel Hailfinger wrote:
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessary to kill the process running the bios code.
>
> Cases in point: My bios will cause the POSTing application to segfault.
> Others have reported the POSTing application just hangs, but the
> important things are done before the hang, so killing it after maybe
> 5 seconds would be ok.
Yuckkkkk!
> Rough outline how to do that without adding tons of code:
> We need a call_usermodehelper_from_ram_with_timeout for that.
>
> Kernel: Userspace:
> User wants to enter S3
> init_mutex_locked(s3_sem)
> call_usermodehelper("vesaposter")
> vesaposter calls LRMI_init
> vesaposter mlocks all its memory
> vesaposter calls into kernel
> and down(s3_sem)
> suspend vesafb
>
> User has triggered resume
> run wakeup.S
> thaw essential threads
> set a timer of 5 seconds
> up(s3_sem)
> thaw and schedule vesaposter
> wait for timer or vesaposter termination
> vesaposter returns from kernel
> vesaposter posts video card
> vesaposter terminates
> resume vesafb
> continue resume
>
> Problems with that approach:
> - vesaposter has to be locked in memory to avoid disk accesses
That's no biggie.
> - vesafb has to refrain from touching video until after POST
Which is why I think we should do the post asap (as you have). What is
counted as an essential thread?
> - the vesaposter thread has to be the first unfrozen and
> scheduled and completed thread. Only after that we can resume
> vesafb and other threads
All other threads will be frozen, and we don't have scheduler hooks that
will hang up our new kiddie, so we should be right there.
> - the locking will be tricky
But also simplified by the fact that everything else is frozen.
> Advantages:
> - the problems all seem to be solvable easily
> - security and stability are similar to the current userspace code
> - we can use vesafb on such machines
> - the kernel code won't be much more than two dozen lines
> - the userspace POSTing code can be upgraded without the need
> for kernel updates (no policy in the kernel)
>
> What do you think?
Show us some code :>
Nigel
--
Nigel Cunningham
Software Engineer, Canberra, Australia
http://www.cyclades.com
Ph: +61 (2) 6292 8028 Mob: +61 (417) 100 574
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.
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.
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.
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
--
Jon Smirl
[email protected]
On Fri, 04 Feb 2005 13:51:55 +1100, Nigel Cunningham
<[email protected]> wrote:
> > User has triggered resume
> > run wakeup.S
wakeup.S runs in real mode. Why can't it just call the VBIOS at
C000:0003 to reset the hardware before setting the mode?
--
Jon Smirl
[email protected]
Hi!
> > > User has triggered resume
> > > run wakeup.S
>
> wakeup.S runs in real mode. Why can't it just call the VBIOS at
> C000:0003 to reset the hardware before setting the mode?
We already try to do that, but it hangs on 70% of machines. See
Documentation/power/video.txt.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> 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.
Well, it is made more tricky by the fact that you are running during
resume -- hard to debug. Ideally you want to have video so you can
debug resume of ethernet, disk, etc... But you don't have video :-(.
But I agree, same code should be used.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> > I'd love to see it too. Pavel, even if you don't want to merge it for a
> > while, we can always incorporate it in the Suspend2 patches so it gets
> > some testing. I know I'd try it on my i830 based Omnibook.
>
> Can we use call_usermodehelper at this early resume stage (before any
> video access)? Calling vm86 directly is probably not going to fly
> because we want to be shielded from any misbehaviour in the bios code
> and it may be necessary to kill the process running the bios code.
>
> Cases in point: My bios will cause the POSTing application to segfault.
> Others have reported the POSTing application just hangs, but the
> important things are done before the hang, so killing it after maybe
> 5 seconds would be ok.
>
> Rough outline how to do that without adding tons of code:
> We need a call_usermodehelper_from_ram_with_timeout for that.
>
> Kernel: Userspace:
> User wants to enter S3
> init_mutex_locked(s3_sem)
> call_usermodehelper("vesaposter")
> vesaposter calls LRMI_init
> vesaposter mlocks all its memory
> vesaposter calls into kernel
> and down(s3_sem)
> suspend vesafb
>
> User has triggered resume
> run wakeup.S
> thaw essential threads
> set a timer of 5 seconds
> up(s3_sem)
> thaw and schedule vesaposter
> wait for timer or vesaposter termination
> vesaposter returns from kernel
> vesaposter posts video card
> vesaposter terminates
> resume vesafb
> continue resume
>
> Problems with that approach:
> - vesaposter has to be locked in memory to avoid disk accesses
> - vesafb has to refrain from touching video until after POST
> - the vesaposter thread has to be the first unfrozen and
> scheduled and completed thread. Only after that we can resume
> vesafb and other threads
> - the locking will be tricky
- it is ugly
What about simply blocking all video accesses before disk (etc) is
resumed, so that "normal" (not locked in memory) application can be
used?
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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.
Regards
Oliver
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/
On Friday 04 February 2005 11:32, Carl-Daniel Hailfinger wrote:
> 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
I wonder if this is related to a problem I have noted on some embedded
systems which only have a serial console (no video, and nothing to do with
ACPI).
If I set up the video console (through LILO), and talk to it using minicom
when the machine starts I am first talking to BIOS, that works fine, then to
LILO which also works, then the kernel starts and that works up to the point
where the proper serial console is loaded, when it picks some bizaar baud rate
and only corrects it when setserial is run.
I have recently noticed this on an SC1100 board, but it is not SC1100 specific
as another manufacturers SC1100 based board does not exhibit this behaviour.
Just a thought and probably no help in getting it solved. Sorry I do not have
any good contacts, although once when I had a problem with serial ports being
misdetected on an IBM MCA machine Alan Cox fixed it for me so he obviously
knows his way around the code and might be able to fix it for us.
David
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/
On Fri, 2005-02-04 at 13:17 +0100, Carl-Daniel Hailfinger wrote:
> Jon Smirl schrieb:
> > 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/
I'm planning on getting x86emu support into vbetool in the near future,
mostly because AMD64 doesn't have vm86 support. It's worth noting that
attempting to re-POST many (most?) laptops will fail miserably - the
code simply isn't available after boot. Saving/restoring state with VBE
code tends to be more reliable, but there are some machines that need
POSTing.
In the long run, it's the sort of thing that needs a hardware database,
which effectively requires it to be in userspace.
--
Matthew Garrett | [email protected]
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.
Xav
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!
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!
On Fri, 4 Feb 2005 17:30:19 +0100, Pavel Machek <[email protected]> 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
[email protected]
On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[email protected]> 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.
--
Jon Smirl
[email protected]
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
On Fri, 4 Feb 2005 10:10:12 -0800, Jesse Barnes <[email protected]> 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
[email protected]
> 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 :-)
On Fri, 4 Feb 2005 10:10:12 -0800, Jesse Barnes <[email protected]> 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
Can you build a no-op version of these that will run on the x86? That
would allow a single user space API for x86, ia64. Maybe the ppc
people will join too.
Why does this appear in /sys/class/pci_bus/0000:17/? For example on my
x86 system I have a single legacy space but if I do a dir of
/sys/class/pci_bus I show three buses. You wouldn't want the
legacy_io/mem attributes on each of these three buses since that
implies three independent address spaces.
[jonsmirl@jonsmirl pci_bus]$ ls /sys/class/pci_bus
0000:00 0000:01 0000:02
How would things be sorted out so that legacy_io/mem attributes only
appear on my root bridge chip 0000:00 and not on the child buses. I
guess this also means the user space app has to search through the bus
entries.
In order to know how many VGA many simultaneous VGA devices you can
have there needs to be some way to count the number of legacy address
spaces. Maybe there should be a /sys/class/legacy to describe the
legacy spaces. Is it possible to have the same legacy space aliased at
two different addresses depending on which root bus is used to get to
it?
I need to know how to answer these questions:
1) how many legacy spaces are there
2) how many VGA devices are in each space
3) how do I do VGA bus routing to access the VGA device
4) how do I address each of the devices.
--
Jon Smirl
[email protected]
On Friday, February 4, 2005 2:59 pm, Jon Smirl wrote:
> Can you build a no-op version of these that will run on the x86? That
> would allow a single user space API for x86, ia64. Maybe the ppc
> people will join too.
Shouldn't be too hard I think.
> Why does this appear in /sys/class/pci_bus/0000:17/? For example on my
> x86 system I have a single legacy space but if I do a dir of
> /sys/class/pci_bus I show three buses. You wouldn't want the
> legacy_io/mem attributes on each of these three buses since that
> implies three independent address spaces.
>
> [jonsmirl@jonsmirl pci_bus]$ ls /sys/class/pci_bus
> 0000:00 0000:01 0000:02
In that case they'll all point to the same memory and I/O space. On the
machines I coded it on, each bus has its own space.
> How would things be sorted out so that legacy_io/mem attributes only
> appear on my root bridge chip 0000:00 and not on the child buses. I
> guess this also means the user space app has to search through the bus
> entries.
We might have to add more arch code in that case, but I thought it might be
easiest for apps if they could just open the space for the bus they're
interested in and it would be routed correctly. I think that'll be ok so
long as two apps aren't trying to do stuff on the bus at the same time.
> In order to know how many VGA many simultaneous VGA devices you can
> have there needs to be some way to count the number of legacy address
> spaces. Maybe there should be a /sys/class/legacy to describe the
> legacy spaces. Is it possible to have the same legacy space aliased at
> two different addresses depending on which root bus is used to get to
> it?
>
> I need to know how to answer these questions:
> 1) how many legacy spaces are there
Depends on your platform.
> 2) how many VGA devices are in each space
Ditto since the number of spaces depends on the platform.
> 3) how do I do VGA bus routing to access the VGA device
This interface just deals with the whole legacy ISA space, not just VGA ports.
I guess some chipsets will do VGA only or split them up?
> 4) how do I address each of the devices.
Jesse
> 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.
> > /sys/class/pci_bus I show three buses. You wouldn't want the
> > legacy_io/mem attributes on each of these three buses since that
> > implies three independent address spaces.
> >
> > [jonsmirl@jonsmirl pci_bus]$ ls /sys/class/pci_bus
> > 0000:00 0000:01 0000:02
>
> In that case they'll all point to the same memory and I/O space. On the
> machines I coded it on, each bus has its own space.
If they all point to the same space, I can't tell whether I have three
legacy spaces or one. I need to know how many legacy spaces there are
in order to know how many VGA cards can simultaneously be enabled.
> We might have to add more arch code in that case, but I thought it might be
> easiest for apps if they could just open the space for the bus they're
> interested in and it would be routed correctly. I think that'll be ok so
> long as two apps aren't trying to do stuff on the bus at the same time.
>
> > In order to know how many VGA many simultaneous VGA devices you can
> > have there needs to be some way to count the number of legacy address
> > spaces. Maybe there should be a /sys/class/legacy to describe the
> > legacy spaces. Is it possible to have the same legacy space aliased at
> > two different addresses depending on which root bus is used to get to
> > it?
What I meant by the questions is how can my video reset program ask
these questions, it needs to know the answers in order to properly
reset the VGA hardware. There needs to be some way to figure out the
answers from sysfs info.
1) how many legacy spaces are there
no way to tell
2) how many VGA devices are in each space
no way to tell, you need to know which legacy space each card is in
3) how do I do VGA bus routing to access the VGA device
I've posted code that starts doing this
4) how do I address each of the devices.
The routing code I posted needs to be update to handle multiple spaces.
For example I might have a machine with 3 spaces, 2 vga in #1, 1 in #2
and zero in #3. In that case I can have two active VGA's. My home
machine has one space and 2 vga's so I can have one active. There
needs to be enough info available to figure this out.
Or maybe the answer is simpler, if the legacy_io/mem attributes exist,
then you can assume each bus has it's own legacy space. If they don't
exist then there is a single legacy space. Is this a safe assumption?
--
Jon Smirl
[email protected]
Jon Smirl schrieb:
> On Fri, 4 Feb 2005 08:44:54 +0100, Pavel Machek <[email protected]> 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/
> > 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 ;-(
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/
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/
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/
On Sat, 05 Feb 2005 01:52:23 +0100, Carl-Daniel Hailfinger
<[email protected]> 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
[email protected]
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 | [email protected]
On Sat, 05 Feb 2005 02:04:49 +0000, Matthew Garrett <[email protected]> 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 | [email protected]
>
>
--
Jon Smirl
[email protected]
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 | [email protected]
On Sat, 05 Feb 2005 02:17:22 +0000, Matthew Garrett <[email protected]> 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
[email protected]
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 | [email protected]
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....
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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!
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
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
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
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 | [email protected]
On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary
<[email protected]> 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
[email protected]
On Sat, 5 Feb 2005 10:37:40 +0100, Pavel Machek <[email protected]> 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
[email protected]
On Sat, 05 Feb 2005 08:15:35 +0000, Matthew Garrett <[email protected]> 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
[email protected]
Am Samstag, 5. Februar 2005 16:47 schrieb Jon Smirl:
> On Sat, 05 Feb 2005 12:53:37 +0100, Ondrej Zary
>
> <[email protected]> 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.
DID someone ask ATI or Nvidia for this? I have the impression that everyone
says ati doesn't help, but no one tried to get help so far.
The reset code of radeon card seems to be easy to reverse engineer. I have
started an attempt and I have 50-60% of my radeon M9 reset code implemented
in a 32 bit C program. I had to stop due to school reasons.
My radeonreset kernel module turns the backlight off and seems to reset the
card's memory. I consider it dangerous because I don't know what it really
does because I don't have the card's specs. A owner of an radeon M6 card
tried my code too and it worked in the same way as on my M9 card, so I think
the reset procedure is the same on all radeon cards. I think with some
comparison of the reset code and the specs that the DRI/X.org/XFree
developers have we can write a working reset code for radeon cards.
This won't help users of non-radeon cards of course :-(
ATI is aware of suspend/resume problems with their fglrx driver(see
http://www.ati.com/support/infobase/4746.html). I've written a few notes to
them, but I haven't got a reply so far(But they also told me not to expect
one). The power management code in radeon_pm.c seems to be written by ATI.
Alltogether I'd not call the situation hopeless.
Cheers,
Stefan
On Sat, 5 Feb 2005 17:48:43 +0100, Stefan D?singer
<[email protected]> wrote:
> The reset code of radeon card seems to be easy to reverse engineer. I have
> started an attempt and I have 50-60% of my radeon M9 reset code implemented
> in a 32 bit C program. I had to stop due to school reasons.
The problem with the radeon reset code is that there are many, many
variations of the radeon chips, including different steppings of the
same part. The ROM is matched to the paticular bugs of the chip. From
what I know ATI doesn't even have a universal radeon reset program.
--
Jon Smirl
[email protected]
> If they all point to the same space, I can't tell whether I have three
> legacy spaces or one. I need to know how many legacy spaces there are
> in order to know how many VGA cards can simultaneously be enabled.
You don't need to care about this, at least in userland. All you need
is proper primitives for locking/unlocking access to a given device.
Wether you have another one to arbitrate with on the same PCI bus or not
is almost irrelevant. That is, it is the job of the kernel driver that
ultimately will do this arbitration (we really need that), and we can
prefectly well survive a long time with a very simple implementation
taht always disable all other VGA devies in the system, not caring about
"simultaneous" access. That implementation can be then improved on
later.
My point is what we really need to define is the in-kernel and userland
API to do this basic VGA access arbitration in the first place. I though
you did something like that a while ago Jon, didn't you ?
I think it could be as simple as an additional sysfs entry
"legacy_enabled" added to all "VGA" devices in the system at the PCI
layer level. Toggling it triggers the "untoggling" of all others,
including VGA forwarding on bridges, and enables the path to that
device. For in-kernel users, a pci_* API would work.
The problem I see though is that it should all be synchronous &
spinlocked since the vgacon could want to grab at interrupt time (unless
it's locked by userland, in which case, vgacon should cache & trigger an
update later).
Ben.
After thinking about this for a while I believe the solution is for
bridges that implement a legacy space to export legacy_io/mem in
sysfs. So in the ia64 world, all bridges would export these attributes
since each bridge creates a unique legacy space.
In the x86 and I believe the ppc world, only host bridges create
legacy spaces and should have the legacy_io/mem attributes. All child
bridges should not export them.
This may be best handled by implementing bridge drivers. In my case I
need these:
Host needs to export a legacy io/mem space
8086:2578 - Host bridge: Intel Corp. 82875P/E7210 Memory Controller Hub
Child bridges do not export legacy space but implement VGA routing
8086:2579 - PCI bridge: Intel Corp. 82875P Processor to AGP Controller
8086:244e - PCI bridge: Intel Corp. 82801 PCI Bridge
I also have this..
8086:24d0 - ISA bridge: Intel Corp. 82801EB/ER (ICH5/ICH5R) LPC Interface Bridge
But this is implementing the devices in the legacy space, it's the
host bridge that is creating the space.
Some questions...
1) Does the IA64 have child bridges that don't implement legacy space?
If so then they need to support VGA routing. What about Cardbus?
2) Does an IA64 bridge supporting different legacy spaces alter the
VGA io request to remove the offset and then send it out onto the bus?
3) How does all of this work with Opteron and Hypertransport?
--
Jon Smirl
[email protected]
On Sun, 06 Feb 2005 09:42:32 +1100, Benjamin Herrenschmidt
<[email protected]> wrote:
> I think it could be as simple as an additional sysfs entry
> "legacy_enabled" added to all "VGA" devices in the system at the PCI
> layer level. Toggling it triggers the "untoggling" of all others,
> including VGA forwarding on bridges, and enables the path to that
> device. For in-kernel users, a pci_* API would work.
>
> The problem I see though is that it should all be synchronous &
> spinlocked since the vgacon could want to grab at interrupt time (unless
> it's locked by userland, in which case, vgacon should cache & trigger an
> update later).
This is my current code it adds a vga entry to all VGA devices in the system.
http://kerneltrap.org/mailarchive/1/message/15974/flat
Instead of toggle there are four states:
1) off
2) on - make sure everything else is off
3) turn off all VGA devices and remember the active one
4) restore the active one
States 3 and 4 and used for running the reset program. Set state 3 to
remember the active device and turn it off, reset the card which will
enable it's VGA, disable it, set state 4 to restore the saved device.
This thread is active too:
Reliable video POSTing on resume
Restart video after resume is the same problem as posting it in the first place.
--
Jon Smirl
[email protected]
On Saturday, February 05, 2005 4:07 pm, Jon Smirl wrote:
> After thinking about this for a while I believe the solution is for
> bridges that implement a legacy space to export legacy_io/mem in
> sysfs. So in the ia64 world, all bridges would export these attributes
> since each bridge creates a unique legacy space.
Except some ia64 platforms don't have one legacy space per host bus like sn2
does.
> Some questions...
> 1) Does the IA64 have child bridges that don't implement legacy space?
Yes, on sn2 each host<->pci bridge has two busses hanging off it, and each of
them has its own legacy space. Child bridges under that bus are routed
according to the child bridge, which may not route legacy accesses.
> If so then they need to support VGA routing. What about Cardbus?
No ia64 boxes that I know of support cardbus.
> 2) Does an IA64 bridge supporting different legacy spaces alter the
> VGA io request to remove the offset and then send it out onto the bus?
Pretty much, yes.
> 3) How does all of this work with Opteron and Hypertransport?
Don't know, Andi probably does.
Jesse
Am Samstag, 5. Februar 2005 18:38 schrieb Jon Smirl:
> On Sat, 5 Feb 2005 17:48:43 +0100, Stefan D?singer
>
> <[email protected]> wrote:
> > The reset code of radeon card seems to be easy to reverse engineer. I
> > have started an attempt and I have 50-60% of my radeon M9 reset code
> > implemented in a 32 bit C program. I had to stop due to school reasons.
>
> The problem with the radeon reset code is that there are many, many
> variations of the radeon chips, including different steppings of the
> same part. The ROM is matched to the paticular bugs of the chip. From
> what I know ATI doesn't even have a universal radeon reset program.
I don't think they differ a lot. Does anybody know how the Win32 driver resets
the card? If it calls 0xc000:3 it will also have the problem with overwritten
reset code, and if it has it's own reset routine the cards can't differ a
lot.
On Sad, 2005-02-05 at 09:35, Pavel Machek wrote:
> 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....
>
A small number of laptop systems are known to pull this trick. There are
other problems too - the video bios boot may make other assumptions
about access to PCI space, configuration, interrupts, timers etc.
Some systems (intel notably) appear to expect you to use the bios
save/restore video state not re-POST.
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).
Either way quite amazing feat that should bring LinuxBIOS closer
to desktop.
Jon Smirl wrote:
>On Sat, 5 Feb 2005 17:48:43 +0100, Stefan Dösinger
><[email protected]> wrote:
>
>
>>The reset code of radeon card seems to be easy to reverse engineer. I have
>>started an attempt and I have 50-60% of my radeon M9 reset code implemented
>>in a 32 bit C program. I had to stop due to school reasons.
>>
>>
>
>The problem with the radeon reset code is that there are many, many
>variations of the radeon chips, including different steppings of the
>same part. The ROM is matched to the paticular bugs of the chip. From
>what I know ATI doesn't even have a universal radeon reset program.
>
>
Maybe they could provide such a program, if asked?
Basically, a chip detect and a switch statement containing all
the bios reset sequences they have.
They may want to protect "trade secrets" about innovative
3D-pipelines and such. But the bios reset is probably not that
high-end, so perhaps they could provide source code for it?
Helge Hafting
On Sun, 2005-02-06 at 16:02 +0000, Alan Cox wrote:
> Some systems (intel notably) appear to expect you to use the bios
> save/restore video state not re-POST.
This works well in many cases, but there are some machines that freeze
if you attempt to make a VBE state save call. Sadly, I don't have any
access to an affected machine, so it's a bit awkward working out what
the problem is.
--
Matthew Garrett | [email protected]
Hi!
> > Some systems (intel notably) appear to expect you to use the bios
> > save/restore video state not re-POST.
>
> This works well in many cases, but there are some machines that freeze
> if you attempt to make a VBE state save call. Sadly, I don't have any
> access to an affected machine, so it's a bit awkward working out what
> the problem is.
Where do I find code to do VBE save state? I might get you some
testing...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Hi!
> >The problem with the radeon reset code is that there are many, many
> >variations of the radeon chips, including different steppings of the
> >same part. The ROM is matched to the paticular bugs of the chip. From
> >what I know ATI doesn't even have a universal radeon reset program.
> >
> >
> Maybe they could provide such a program, if asked?
> Basically, a chip detect and a switch statement containing all
> the bios reset sequences they have.
>
> They may want to protect "trade secrets" about innovative
> 3D-pipelines and such. But the bios reset is probably not that
> high-end, so perhaps they could provide source code for it?
Try asking them, then ;-)....
Asked the right way, they might even tell you. I believe right way is
"I'd like to buy 10000 cards, but I need suspend-to-RAM to work".
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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/
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 - http://www.grupopie.com
All that is necessary for the triumph of evil is that good men do nothing.
Edmund Burke (1729 - 1797)
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!
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
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
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.
Pavel Machek <[email protected]> writes:
> 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....
The state of current hardware has already been mentioned but let
me clarify. This is not a laptop problem anytime you have onboard
video you are unlikely to have a separate video ROM. This includes
many recent server boards as well as laptops. When the board boots
up there will be a video option ROM shadowed into the usually location
at C000h:0 but what becomes of it afterwards is a good question.
For server boards most commonly this seems to be a flavor of the ATI
Rage XL chip. It is a low end part that I doubt getting documentation
for will be very hard. And according to
Documentation/power/video.txt this is one of the cases that actually
works.
What is happening in those POST routines of a video card is typically
the code to initialize the memory controller on the video card. Plus
a little bit of code to set the video mode. If I read the
documentation correctly in a S3 power state only the RAM is preserved.
So it does look like the video post is needed.
Hmm. Looking at the ACPI 3.0 spec it appears there is a _ROM method
that can be called to get a copy of the ROM image for an onboard
video card. Has any one tried that method?
Eric
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....
>
> The state of current hardware has already been mentioned but let
> me clarify. This is not a laptop problem anytime you have onboard
> video you are unlikely to have a separate video ROM. This includes
> many recent server boards as well as laptops. When the board boots
> up there will be a video option ROM shadowed into the usually location
> at C000h:0 but what becomes of it afterwards is a good question.
>
> For server boards most commonly this seems to be a flavor of the ATI
> Rage XL chip. It is a low end part that I doubt getting documentation
> for will be very hard. And according to
> Documentation/power/video.txt this is one of the cases that actually
> works.
I do not see Rage XL mentioned in video.txt; can you give me details
and/or suggest a patch?
> What is happening in those POST routines of a video card is typically
> the code to initialize the memory controller on the video card. Plus
> a little bit of code to set the video mode. If I read the
> documentation correctly in a S3 power state only the RAM is preserved.
> So it does look like the video post is needed.
On some machines, video state is preserved over S3... Some BIOSes are
good enough to POST video for you...
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
Alan Cox wrote:
> On Sad, 2005-02-05 at 09:35, Pavel Machek wrote:
>
>>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....
>>
>
>
> A small number of laptop systems are known to pull this trick. There are
> other problems too - the video bios boot may make other assumptions
> about access to PCI space, configuration, interrupts, timers etc.
>
> Some systems (intel notably) appear to expect you to use the bios
> save/restore video state not re-POST.
Isn't that what it's there for? In any context other than save/restore I
wouldn't think using the BIOS was a good approach. But this is a special
case, and if there's a BIOS function which does the right thing, it
would seem to be easier to assume that the BIOS works than that the
driver can do every operation for a clean restart.
The problem is that while POST leaves the video in a known state, it may
not the known state you want, nor is it a given that you can get from
there to where you were on suspend. PC hardware isn't always that
dependable.
--
bill davidsen <[email protected]>
CTO TMR Associates, Inc
Doing interesting things with small computers since 1979
BTW it seems that old ATI cards use the BIOS to initialize secondary
adapters even under Windows.
See http://www.ati.com/support/infobase/3663.html.
--
Ville Syrj?l?
[email protected]
http://www.sci.fi/~syrjala/
Hi!
> >>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....
> >>
> >
> >
> >A small number of laptop systems are known to pull this trick. There are
> >other problems too - the video bios boot may make other assumptions
> >about access to PCI space, configuration, interrupts, timers etc.
> >
> >Some systems (intel notably) appear to expect you to use the bios
> >save/restore video state not re-POST.
>
> Isn't that what it's there for? In any context other than save/restore I
> wouldn't think using the BIOS was a good approach. But this is a special
> case, and if there's a BIOS function which does the right thing, it
> would seem to be easier to assume that the BIOS works than that the
> driver can do every operation for a clean restart.
>
> The problem is that while POST leaves the video in a known state, it may
> not the known state you want, nor is it a given that you can get from
> there to where you were on suspend. PC hardware isn't always that
> dependable.
Eh? POST leaves video in 80x25 text mode, and we know how to handle
that mode just fine... Historically that's what we ran our consoles
at, so X can handle it etc.
Pavel
--
People were complaining that M$ turns users into beta-testers...
...jr ghea gurz vagb qrirybcref, naq gurl frrz gb yvxr vg gung jnl!
On Thu, 2005-02-10 at 21:25 +0200, Ville Syrjälä wrote:
> BTW it seems that old ATI cards use the BIOS to initialize secondary
> adapters even under Windows.
> See http://www.ati.com/support/infobase/3663.html.
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.
--
Matthew Garrett | [email protected]
On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <[email protected]> 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.
--
Jon Smirl
[email protected]
On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <[email protected]> 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 | [email protected]
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 <[email protected]> wrote:
> On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
> > On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <[email protected]> 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 | [email protected]
>
>
--
Jon Smirl
[email protected]
On Thu, Feb 10, 2005 at 03:17:47PM -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <[email protected]> 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.
So you can suspend with one of these and the card gets resumed properly?
If so I wonder why they don't allow POSTing of secondary cards.
--
Ville Syrj?l?
[email protected]
http://www.sci.fi/~syrjala/
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 <[email protected]> wrote:
>
>>On Thu, 2005-02-10 at 15:17 -0500, Jon Smirl wrote:
>>
>>>On Thu, 10 Feb 2005 20:08:15 +0000, Matthew Garrett <[email protected]> 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 | [email protected]
>>
>>
>
>
>
--
Kendall Bennett
Chief Executive Officer
SciTech Software, Inc.
Phone: (530) 894 8400
http://www.scitechsoft.com
~ SciTech SNAP - The future of device driver technology! ~
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 | [email protected]
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! ~
On Thu, 10 Feb 2005 21:06:36 +0000, Matthew Garrett <[email protected]> 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
[email protected]
On Thu, 2005-02-10 at 16:28 -0500, Jon Smirl wrote:
> On Thu, 10 Feb 2005 21:06:36 +0000, Matthew Garrett <[email protected]> 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 | [email protected]
On Thu, 10 Feb 2005, Bill Davidsen wrote:
>> Some systems (intel notably) appear to expect you to use the bios
>> save/restore video state not re-POST.
>
> Isn't that what it's there for? In any context other than save/restore I
> wouldn't think using the BIOS was a good approach. But this is a special
> case, and if there's a BIOS function which does the right thing, it would
> seem to be easier to assume that the BIOS works than that the driver can do
> every operation for a clean restart.
Maybe with new cards it is different but a few years ago, most cards
that I tested had problems with those functions.
--
Matan Ziv-Av. [email protected]
Jon Smirl schrieb:
> On Thu, 10 Feb 2005 21:06:36 +0000, Matthew Garrett <[email protected]> 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?
Samsung P35 notebook with ATI Mobility Radeon 9700.
IIRC I saw the c000:xxxx jump on my machine.
Give me code to test and I'll mail you the results in a few minutes.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Li-Ta Lo schrieb:
> On Mon, 2005-02-07 at 09:01, Pavel Machek wrote:
>
>>>>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".
>
> 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.
Do you have a kernel patch against a recent kernel? I'd like to try
the in-kernel emulator. A userspace variant would also be fine, provided
it solves the "VGA BIOS calls normal BIOS" type of problem I'm seeing
on my machine (Samsung P35 laptop with ATI Radeon Mobility 9700).
Regards,
Carl-Daniel
--
http://www.hailfinger.org/