s3_bios and lcall $0xc000,$3

s3_bios and lcall $0xc000,$3

[Bjorn Wesen]

Ok.. just checking: what exactly is the lcall $0xc000,$3 call supposed to do 
in the wakeup.S code ? It seems to be the only way to actually activate the 
TFT on the acer travelmate notebook, and I can print characters on the 
screen after the call, but when the code tries to load CR4, the CPU freezes 
(or at least it can't print characters anymore..).

I'm guessing that the bios call corrupt some data segment pointers, because 
if I print out any of the real_save_* values, they are all zero! WHich 
obviously causes a crash when you load up a zero GDT, zero CR0, zero CR4 
etc... 

I've tried to find the description of this bios call on the net somewhere 
but turned up zero..

/Bjorn




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

[PATCH] s3_bios and lcall $0xc000,$3

[Bjorn Wesen]

On Mon, 17 Feb 2003, Bjorn Wesen wrote:
> I'm guessing that the bios call corrupt some data segment pointers, because 
> if I print out any of the real_save_* values, they are all zero! WHich 
> obviously causes a crash when you load up a zero GDT, zero CR0, zero CR4 
> etc... 

Yup - the s3_bios triggered lcall corrupts DS (and possibly SS) as well. CS 
is still alive though so redoing the CS->DS duplicating worked.. the 
following is not in patch format but you get the idea :)

	lcall   $0xc000,$3

+       # reset the data and stack segments after possible bios tampering
+       movw    %cs, %ax
+       movw    %ax, %ds
+       movw    %ax, %ss

So now S3 resume works on the travelmate 630! :)

However, the IDE system (using DMA) seems to not survive the resume. WHat is 
the current status of fixing that ? (kernel 2.5.61)

/Bjorn




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Ducrot Bruno]

On Mon, Feb 17, 2003 at 04:53:16PM +0100, Bjorn Wesen wrote:
> On Mon, 17 Feb 2003, Bjorn Wesen wrote:
> > I'm guessing that the bios call corrupt some data segment pointers, because 
> > if I print out any of the real_save_* values, they are all zero! WHich 
> > obviously causes a crash when you load up a zero GDT, zero CR0, zero CR4 
> > etc... 
> 
> Yup - the s3_bios triggered lcall corrupts DS (and possibly SS) as well. CS 
> is still alive though so redoing the CS->DS duplicating worked.. the 
> following is not in patch format but you get the idea :)
> 
> 	lcall   $0xc000,$3
> 
> +       # reset the data and stack segments after possible bios tampering
> +       movw    %cs, %ax
> +       movw    %ax, %ds
> +       movw    %ax, %ss
> 
> So now S3 resume works on the travelmate 630! :)
> 
> However, the IDE system (using DMA) seems to not survive the resume. WHat is 
> the current status of fixing that ? (kernel 2.5.61)
> 

IMO this lcall should not be used at all.  This is used by the
BIOS only on POST stage in order to setup the VGA subsystem (not
reinitialize, which was first intented, I guess).

Actually, everything can happen, as to setup the MCH in order
to expose the VGA shadowing for example, which is completely
wrong at this stage, or else, kaboom.

Then, providing a workaround in order to prevent the kaboom
can work for you, but not for others.
Hum this workaround do not work for you?  Try this one.
But kill others.

Worst, in case of s4bios, since the whole POST is done
(and because I use the same wakeup code), then
we already know that the lcall is done.  Then, do I have to
provide a different wakeup code just for s4bios?

Pavel, really, we need to provide a better way to reinitialize
the VGA subsystem.

Cheers,

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Nigel Cunningham]

On Tue, 2003-02-18 at 06:16, Ducrot Bruno wrote:
> Pavel, really, we need to provide a better way to reinitialize
> the VGA subsystem.

And you need to make no assumptions about the state - on an i830 (and
others, no doubt), S4 == S5 for the video subsystem.

Regards,

Nigel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Pavel Machek]

Hi!

> > Pavel, really, we need to provide a better way to reinitialize
> > the VGA subsystem.
> 
> And you need to make no assumptions about the state - on an i830 (and
> others, no doubt), S4 == S5 for the video subsystem.

Are we talking swsusp here? No, subject says S3. So you have typo
there?

Anyway going without assumptions is pretty hard, as it requires
in-kernel support for all the video cards. And that's hard. [Power-on
initialization of cards is different; you have to setup memory timings
etc.]
 
								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Nigel Cunningham]

I'm talking about S3 (sorry typo before when I said S4==S5) - if I've
read the specs right (and experience does match this), the i830 video
card looses all state when switched to S3.

Regards,

Nigel

On Tue, 2003-02-18 at 12:55, Pavel Machek wrote:
> Hi!
> 
> > > Pavel, really, we need to provide a better way to reinitialize
> > > the VGA subsystem.
> > 
> > And you need to make no assumptions about the state - on an i830 (and
> > others, no doubt), S4 == S5 for the video subsystem.
> 
> Are we talking swsusp here? No, subject says S3. So you have typo
> there?
> 
> Anyway going without assumptions is pretty hard, as it requires
> in-kernel support for all the video cards. And that's hard. [Power-on
> initialization of cards is different; you have to setup memory timings
> etc.]
>  
> 								Pavel



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Nigel Cunningham]

On Tue, 2003-02-18 at 14:42, Nigel Cunningham wrote:
> I'm talking about S3 (sorry typo before when I said S4==S5) - if I've
> read the specs right (and experience does match this), the i830 video
> card looses all state when switched to S3.

Sorry about replying to myself, but here are some extracts. I'm not at
all an expert on drivers, so I'll freely admit that I might be
misunderstanding these.

Page 1:
Intel® 830 Chipset Family: 82830
Graphics and Memory Controller
Hub (GMCH-M)
Datasheet
January 2002
Order Number: 298338-003

Page 180 says:
G1/S3: Power and context lost to chipset.

Page 184 adds...

The final level of power savings for the Intel 830 Chipset family GMCH-M
is achievable when the Host Clock, Memory Group, and I/O clock group
clocks are shutdown and the GMCH-M is powered down. This occurs when the
system transitions to the S3 state. During transition to the S3 state,
first the STPCLK# is asserted and the Stop Grant cycle snooped by the
GMCH-M and forwarded over Hub interface where it is received by the
ICH3-M. At this point the GMCH-M is functioning in the C2 State. The
GMCH-M places all of the SDRAM components into the self-refresh mode.
After the GMCH-M has placed all of the SDRAM components in self refresh,
it is safe to enter the STR State. The ICH3-M will then assert a signal,
SLP_S1#, to the clock synthesizer to shutdown all of the clocks in the
Host and Memory Clock Groups. The GMCH-M will assume that no AGP,
AGP/PCI, or hub interface cycle (except special cycles) will occur while
the GMCH-M is in the C3 State. The processor cannot snoop its caches to
maintain coherency while in the C3 State. GMCH-M contains no isolation
circuitry and MUST be powered down once STR is reached. If GMCHM is
powered up and driving outputs to devices that are powered down,
component damage will result.

(You may remember me talking a while ago about lspci -vv not even
looking sane after resume. I guess this is the cause).

Hope this is helpful.

Regards,

Nigel




-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Pavel Machek]

Hi!

> > I'm talking about S3 (sorry typo before when I said S4==S5) - if I've
> > read the specs right (and experience does match this), the i830 video
> > card looses all state when switched to S3.
> 
> Sorry about replying to myself, but here are some extracts. I'm not at
> all an expert on drivers, so I'll freely admit that I might be
> misunderstanding these.
> 
> Page 1:
> Intel? 830 Chipset Family: 82830
> Graphics and Memory Controller
> Hub (GMCH-M)
> Datasheet
> January 2002
> Order Number: 298338-003
> 
> Page 180 says:
> G1/S3: Power and context lost to chipset.
> 
> Page 184 adds...
> 
> The final level of power savings for the Intel 830 Chipset family GMCH-M
> is achievable when the Host Clock, Memory Group, and I/O clock group
> clocks are shutdown and the GMCH-M is powered down. This occurs when the
> system transitions to the S3 state. During transition to the S3 state,
> first the STPCLK# is asserted and the Stop Grant cycle snooped by the
> GMCH-M and forwarded over Hub interface where it is received by the
> ICH3-M. At this point the GMCH-M is functioning in the C2 State. The
> GMCH-M places all of the SDRAM components into the self-refresh mode.
> After the GMCH-M has placed all of the SDRAM components in self refresh,
> it is safe to enter the STR State. The ICH3-M will then assert a signal,
> SLP_S1#, to the clock synthesizer to shutdown all of the clocks in the
> Host and Memory Clock Groups. The GMCH-M will assume that no AGP,
> AGP/PCI, or hub interface cycle (except special cycles) will occur while
> the GMCH-M is in the C3 State. The processor cannot snoop its caches to
> maintain coherency while in the C3 State. GMCH-M contains no isolation
> circuitry and MUST be powered down once STR is reached. If GMCHM is
> powered up and driving outputs to devices that are powered down,
> component damage will result.
> 
> (You may remember me talking a while ago about lspci -vv not even
> looking sane after resume. I guess this is the cause).

:-( This is too deep magic even for me.

								Pavel

-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Pavel Machek]

Hi!

> > > I'm guessing that the bios call corrupt some data segment pointers, because 
> > > if I print out any of the real_save_* values, they are all zero! WHich 
> > > obviously causes a crash when you load up a zero GDT, zero CR0, zero CR4 
> > > etc... 
> > 
> > Yup - the s3_bios triggered lcall corrupts DS (and possibly SS) as well. CS 
> > is still alive though so redoing the CS->DS duplicating worked.. the 
> > following is not in patch format but you get the idea :)
> > 
> > 	lcall   $0xc000,$3
> > 
> > +       # reset the data and stack segments after possible bios tampering
> > +       movw    %cs, %ax
> > +       movw    %ax, %ds
> > +       movw    %ax, %ss
> > 
> > So now S3 resume works on the travelmate 630! :)

Applied.

> > However, the IDE system (using DMA) seems to not survive the resume. WHat is 
> > the current status of fixing that ? (kernel 2.5.61)

I do hdparm -d 0 before suspend...

> IMO this lcall should not be used at all.  This is used by the
> BIOS only on POST stage in order to setup the VGA subsystem (not
> reinitialize, which was first intented, I guess).

Yes that lcall is a hack. No I do not know a better way. Yes I need it
on the s**o system.

> Actually, everything can happen, as to setup the MCH in order
> to expose the VGA shadowing for example, which is completely
> wrong at this stage, or else, kaboom.
> 
> Then, providing a workaround in order to prevent the kaboom
> can work for you, but not for others.
> Hum this workaround do not work for you?  Try this one.
> But kill others.

I need lcall on the s**o system, and I need to reset video mode on
toshiba 4030cdt.

> Worst, in case of s4bios, since the whole POST is done
> (and because I use the same wakeup code), then
> we already know that the lcall is done.  Then, do I have to
> provide a different wakeup code just for s4bios?

OTOH you know you need to reset the video mode, right? So I'd do
save_acpi_flags = acpi_flags; acpi_flags = 1; just before suspend and
acpi_flags = save_acpi_flags after that, or add parameter to
copy_wakeup_routine.

> Pavel, really, we need to provide a better way to reinitialize
> the VGA subsystem.

But ... can we do it without in-kernel support for all the videocards?

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Bjorn Wesen]

On Tue, 18 Feb 2003, Pavel Machek wrote:
> > Pavel, really, we need to provide a better way to reinitialize
> > the VGA subsystem.
> 
> But ... can we do it without in-kernel support for all the videocards?

It seems pretty bleak since for example the reason I needed s3_bios on the 
travelmate was because the TFT did not want to come on by just doing the int 
0x10h call or the VESA set video mode call. Some other magic was needed 
which apparently the lcall did. And we can't really have specific VGA wakeup 
codes for every possible card or laptop.. I tried searching the ralph brown 
irq list for that lcall but could not find any - what documentation did you 
dig up this magic call from ? :))

OTOH - if you suspend/wakeup from within X, I assume (??) that the X server 
will take care of proper card-specific reinitialization ? Haven't tried it 
since the PM support in the nvidia driver is #if 0'ed - but perhaps it 
works, who knows.. (it needs to be patched to survive 2.5 anyway). Does the 
OSS xf86 servers support PM properly BTW ?

/Bjorn



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Pavel Machek]

Hi!

> > > Pavel, really, we need to provide a better way to reinitialize
> > > the VGA subsystem.
> > 
> > But ... can we do it without in-kernel support for all the videocards?
> 
> It seems pretty bleak since for example the reason I needed s3_bios on the 
> travelmate was because the TFT did not want to come on by just doing the int 
> 0x10h call or the VESA set video mode call. Some other magic was needed 
> which apparently the lcall did. And we can't really have specific VGA wakeup 
> codes for every possible card or laptop.. I tried searching the ralph brown 
> irq list for that lcall but could not find any - what documentation did you 
> dig up this magic call from ? :))

Its call bios uses to initialize video roms. It really should be in
interrupt list somewhere. [Someone helped me with that].

> OTOH - if you suspend/wakeup from within X, I assume (??) that the X server 
> will take care of proper card-specific reinitialization ? Haven't
> tried it 

X-server is not able to do *this* hard reinitialization :-(.
									Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Charl P. Botha]

On Tue, 2003-02-18 at 12:19, Pavel Machek wrote:
> > OTOH - if you suspend/wakeup from within X, I assume (??) that the X server 
> > will take care of proper card-specific reinitialization ? Haven't
> > tried it 
> 
> X-server is not able to do *this* hard reinitialization :-(.

If the X server is not using DRI, the BIOS initialisation is mostly
sufficient, as X resets the correct video mode when one VT switches
back.  However, if one is using DRI, the BIOS initialisation is OFTEN
not even close, so you have to do something like I did to the Radeon
drivers: http://cpbotha.net/dri_resume.html

My changes do a re-initialisation of card-hardware every VT switch.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Bjorn Wesen]

On 18 Feb 2003, Charl P. Botha wrote:
> If the X server is not using DRI, the BIOS initialisation is mostly
> sufficient, as X resets the correct video mode when one VT switches

DOes the X server react to the pm events then and does this resetting when 
resuming, without having to switch manually to the console before and back 
after ?

> back.  However, if one is using DRI, the BIOS initialisation is OFTEN
> not even close, so you have to do something like I did to the Radeon
> drivers: http://cpbotha.net/dri_resume.html

Just if someone is interested...

I found this somewhat interesting PM code in the GPL part of the nvidia 
binary driver. I wonder what the comment is talking about wrgds to APM vs. 
ACPI and if it might work now. Haven't tried... (the rm_power_management 
functions are in the binary-only part).

    switch (rqst)
    {
#if 0
        /* XXX PM HACK!! for now, let's try this */

        // our video bios doesn't support APM, only ACPI
        // for now, return an error to try and keep the machine
        // from entering suspend/resume, so as to not lose any
        // user's data.
        case PM_RESUME:
            nv_printf(NV_DBG_INFO, "NVRM: received PM resume event\n");
            rm_power_management(NV_STATE_PTR(lnv), 0, rqst);
            break;

        case PM_SUSPEND:
            nv_printf(NV_DBG_INFO, "NVRM: received PM suspend event\n");
            rm_power_management(NV_STATE_PTR(lnv), 0, rqst);
            break;
#endif
        default:
            nv_printf(NV_DBG_INFO, "NVRM: received unknown PM event: 
0x%x\n", rq
st);

/Bjorn



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Charl P. Botha]

On Tue, 2003-02-18 at 14:29, Bjorn Wesen wrote:
> On 18 Feb 2003, Charl P. Botha wrote:
> > If the X server is not using DRI, the BIOS initialisation is mostly
> > sufficient, as X resets the correct video mode when one VT switches
> 
> DOes the X server react to the pm events then and does this resetting when 
> resuming, without having to switch manually to the console before and back 
> after ?

The current X code is not sensitive to all PM events: last  I checked
only APM.  However, currently the code is such that a suspend event
automatically switches to a text VT and resume switches back.  It makes
sense to have this kind of code in the VT switch handling, since an
application can do strange things to the video whilst we're switched
away from X, so technically, X should never assume any kind of state
when it switches back.

-- 
charl p. botha http://cpbotha.net/ http://visualisation.tudelft.nl/


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Patrick Mochel]

> I found this somewhat interesting PM code in the GPL part of the nvidia 
> binary driver. I wonder what the comment is talking about wrgds to APM vs. 
> ACPI and if it might work now. Haven't tried... (the rm_power_management 
> functions are in the binary-only part).

>         // our video bios doesn't support APM, only ACPI
>         // for now, return an error to try and keep the machine
>         // from entering suspend/resume, so as to not lose any
>         // user's data.

Makes sense - they want to save the framebuffer contents, and I imagine 
it's certainly a lot easier with a full 32-bit OS to work with than with a 
BIOS, even if it is running in protected mode..

	-pat



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Pavel Machek]

Hi!

> > > OTOH - if you suspend/wakeup from within X, I assume (??) that the X server 
> > > will take care of proper card-specific reinitialization ? Haven't
> > > tried it 
> > 
> > X-server is not able to do *this* hard reinitialization :-(.
> 
> If the X server is not using DRI, the BIOS initialisation is mostly
> sufficient, as X resets the correct video mode when one VT switches


Unfortunately, during S3 resume, BIOS initialisation may or may not
have been run, or maybe you have it in state you left in. You don't
know.

								Pavel
-- 
Casualities in World Trade Center: ~3k dead inside the building,
cryptography in U.S.A. and free speech in Czech Republic.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[David Woodhouse]

On Tue, 2003-02-18 at 11:19, Pavel Machek wrote:
> > It seems pretty bleak since for example the reason I needed s3_bios on the 
> > travelmate was because the TFT did not want to come on by just doing the int 
> > 0x10h call or the VESA set video mode call. Some other magic was needed 
> > which apparently the lcall did. And we can't really have specific VGA wakeup 
> > codes for every possible card or laptop.. I tried searching the ralph brown 
> > irq list for that lcall but could not find any - what documentation did you 
> > dig up this magic call from ? :))
> 
> Its call bios uses to initialize video roms. It really should be in
> interrupt list somewhere. [Someone helped me with that].

Not just video ROMS -- it's the way the BIOS handles _all_ BIOS
extensions -- SCSI drivers, network boot roms, etc. It scans from
0xC0000 up to 0xE0000 in steps of (IIRC) 0x2000, checking for a 
'0x55 0xaa' signature and jumping to offset 0003 in the relevant segment
if it finds such. Your video BIOS generally lives at segment 0xC000, and
when run it will initialise the hardware and install itself on the INT
10h vector for later use.

-- 
dwmw2


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Bjorn Wesen]

On Tue, 18 Feb 2003, Pavel Machek wrote:
> > > However, the IDE system (using DMA) seems to not survive the resume. WHat is 
> > > the current status of fixing that ? (kernel 2.5.61)
> 
> I do hdparm -d 0 before suspend...

Hm I tried this now, and it only worked partially - it seemed I could access 
the harddisk after the resume, but after a short while I started getting IDE 
error printouts (like, IDE commands failing), even though I was still in 
non-DMA mode. So I guess we need those retuning commands Alan was talking 
about yesterday..

Also, the 8139too.c driver (with the refrigerator fix in) also only 
partially survives suspend/resume - I could for example get a half completed 
DHCP handshake but then it started getting bad interrupts.

Possibly that patch someone posted yesterday about incorrectly resumed 8259 
modes in 2.4 would be necessary for 2.5 as well ? Or is it just the 8139too 
driver that needs better pm reactions...

/Bjorn



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: [PATCH] s3_bios and lcall $0xc000,$3

[Alan Cox]

On Mon, 2003-02-17 at 15:53, Bjorn Wesen wrote:
> However, the IDE system (using DMA) seems to not survive the resume. WHat is 
> the current status of fixing that ? (kernel 2.5.61)

When it comes back we need to retune the drives/chipset. All the drive 
functions exist to do that (its just like tuning it at boot) but I've
got more pressing things to fix first in the 2.5.x IDE.

Alan



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: s3_bios and lcall $0xc000,$3

[Ducrot Bruno]

On Mon, Feb 17, 2003 at 04:38:18PM +0100, Bjorn Wesen wrote:
> Ok.. just checking: what exactly is the lcall $0xc000,$3 call supposed to do 
> in the wakeup.S code ? It seems to be the only way to actually activate the 
> TFT on the acer travelmate notebook, and I can print characters on the 
> screen after the call, but when the code tries to load CR4, the CPU freezes 
> (or at least it can't print characters anymore..).
> 
> I'm guessing that the bios call corrupt some data segment pointers, because 
> if I print out any of the real_save_* values, they are all zero! WHich 
> obviously causes a crash when you load up a zero GDT, zero CR0, zero CR4 
> etc... 
> 
> I've tried to find the description of this bios call on the net somewhere 
> but turned up zero..

Just google for 'ralph brown list'.

-- 
Ducrot Bruno

--  Which is worse:  ignorance or apathy?
--  Don't know.  Don't care.


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf