xf86-video-amd: switching to a vcons fails

Please see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051 for patched drivers (xserver-xorg-core and xserver-xorg-video-amd) that might solve your issue.

I am using those patched drivers, and I have no issues switching vts on a Geode GX2 + GSW BIOS.

Martin thanks for your help still doesnt work.
I installed both xserver-xorg-core and xserver-xorg-video-amd. still crashes.

here is a strange line in x.log

Unable to open /dev/cpu/0/msr/ :2

if it helps
thanks

Joe, thank you for reporting on this X.log line. It gets us closer to finding the exact cause.

Could you attach these items to the bug:

1) The full X.log

2) The output of /usr/share/bug/xserver-xorg-core/script

Also, it would be useful to know the brand of BIOS your ALIX board is using and what sort of display is attached to it (CRT via VGA or TFT directly on the Geode's TFT controller).

Gideon, just for the record, could you tell us the brand and model of this GX2 unit?

I'm trying to make a table of all known Geode GX2/LX models on the X.org wiki, to help the developers track BIOS and hardware vendor -related issues.

Thanks!

I started looking into this. When we exit we attempt to execute INT 0x10 to restore the VGA mode.

On GSW BIOS I get this in the logs... c000:0282: A2 ILLEGAL EXTENDED X86 OPCODE!

I am going to watch the emulator a bit more closely and try to see where it goes wrong.

To follow up on yesterday's discovery of an x86emu ILLEGAL OPCODE message..

The opcode was 0F A2, or CPUID; it was not implemented in the emulator. I have created a simple patch that emulates this instruction by passing it the exact values of the instruction ran on the real hardware. Patch is attached. I have tested it on Gutsy (xorg 1.3.0.0). The patch applies cleanly if you put it last in the debian/patches queue.

This allows the video-amd driver to actually switch back to console mode... but only if that console mode was 80x25. I stated with "vga=ext" in my kernel command line. This still does not work. The result is a hybrid. The font renders correctly, but only the top 25 lines of the VT are displayed. I will continue to look at this.

Thanks to Symbio Technologies for funding my work, and ThinCan for providing hardware :)

I have the same problem, but can't solve it! Can anyone tell me how to apply patches???? i just have never done this before.

On Gutsy, the fewest number of steps would be to...

apt-get source xserver-xorg-core
sudo apt-get build-dep xserver-xorg-core fakeroot devscripts
cd xorg-server-1.3.0.0*/
./debian/rules patch
patch -s -p1 < ...path/to/the/patch/...
debuild -b -nc
sudo debi

Take note of the patch step -- it should not produce any errors. The last line installs the debs you just built.

Let me/us know if you have issues.

I should add that I got scolded on the X.org mailing list for producing a patch that is not x-platform. I had no idea that the x86emu was required on non-x86 platforms. So, I am extending the patch to return 486dx2 CPUID values on non-x86 platforms. More in this thread...

http://wiki.hungrycats.org/mediawiki/index.php/Bartman%27s_Question#and_the_result_is

A LUG-buddy offered to resurrect his old 486 to get me the right values.

http://wiki.hungrycats.org/mediawiki/index.php/Bartman%27s_Question#and_the_result_is

This another take at the patch that obsoletes the one posted on 2008-02-02. It is still against Gutsy sources (after all other patches were applied), but because it is more complex it does not apply on a clean 1.3.0.0 xorg tree. My instructions above should still work for you.

thank you for your help! but, i have a little problem while applying pacth.

on "patch -s -p1 <....>" process freezes and doesnt produce neither error messages nor success.
maybe i did something wrong? what patches must be applied before this one?

or this behavour is normal?

p.s. excuse me for my bad english. i haven't practiced it for a log time.

Romeo,

if I am reading your message correctly... you missed the < in applying the patch:

patch -s -p1 < file

...and not...

patch -s -p1 file

-Bart

yes, i've missed it =)

now compiling.....

one more question about patching:

if i need to obtain original source code (without patches applied) what should i do? simply tell "apt-get source xserver-xorg-core" again?

i just can't uderstand how the process of patching works. as i know, it replaces some pieces of original source code with new ones. but how it determines the version of source, finds position to write patch to?

can you give me any links to read more about it?

* Romeo <email address hidden> [080203 14:15]:
> if i need to obtain original source code (without patches applied) what
> should i do? simply tell "apt-get source xserver-xorg-core" again?

Yes, you could do that. You can also unapply the patch I have provided:

patch -s -p1 -R < ...thepatch...

The -R is for reverse.

> i just can't uderstand how the process of patching works. as i know, it
> replaces some pieces of original source code with new ones. but how it
> determines the version of source, finds position to write patch to?

Open the patch file in a browser. All the information is there.

Lines that start with --- and +++ start a new block and identify the
file to modify. The @@ line tells the patch program where to start
changing code. The + lines are added, the - lines are removed.

> can you give me any links to read more about it?

Well, you should know that the diff program generates diff files. The
most common diff format (of 3 that I know of) is "unified diff" for
which you would run: diff -u old-file new-file

Anyway, I googled, and skipped all the links that talked about microsoft
patches (which BTW are not patches at all) and came across this:

http://stephenjungels.com/jungels.net/articles/diff-patch-ten-minutes.html
http://www.linuxjournal.com/article/1237

Have fun.

-Bart

i've compiled and installed it. works perfectly, returns to text mode without any problems! thanx, Bart! great work! now reading material about that you gave me.

one more question. as i understood this patch has not been included in Gusty updates yet, so i don't need to update xorg-core from Gusty repository?

That's correct. This patch is very new and has not made its way into any repository or package.

Updating your xserver package will revert your system to the not working code-base.

That might have been confusing.

I meant to say that updating your xserver via apt to a Gutsy release of the package would overwrite the patched package you built and undo the fix. Although, if you see a new update from Gutsy, you could apply this patch to the new sources and build again.

On 2/4/08, bartman <email address hidden> wrote:
> That might have been confusing.
>
> I meant to say that updating your xserver via apt to a Gutsy release of
> the package would overwrite the patched package you built and undo the
> fix. Although, if you see a new update from Gutsy, you could apply this
> patch to the new sources and build again.

I will add this patch and upload packages into my PPA later this week.
For Gutsy and Hardy.

I will also upload new -AMD packages once we have added WXGA support
and closed remaining warnings reported by X, as listed on the X.org
wiki page for this driver.

--
Martin-Éric Racine
http://q-funk.iki.fi

Gutsy packages are uploaded to my PPA:

https://launchpad.net/~q-funk/+archive

On 2/3/08, bartman <email address hidden> wrote:
> I should add that I got scolded on the X.org mailing list for producing
> a patch that is not x-platform. I had no idea that the x86emu was
> required on non-x86 platforms. So, I am extending the patch to return
> 486dx2 CPUID values on non-x86 platforms. More in this thread...
>
> http://wiki.hungrycats.org/mediawiki/index.php/Bartman%27s_Question#and_the_result_is
>
> A LUG-buddy offered to resurrect his old 486 to get me the right values.
>
> http://wiki.hungrycats.org/mediawiki/index.php/Bartman%27s_Question#and_the_result_is

The build log for my PPA shows that the server fails to build on the
AMD64 platform when the CPUID patch is applied:

https://launchpad.net/~q-funk/+archive/+builds?build_text=&build_state=failed

It successfully built on LPIA and i386, though.

--
Martin-Éric Racine
http://q-funk.iki.fi

* Martin-?ric Racine <email address hidden> [080206 03:25]:
> The build log for my PPA shows that the server fails to build on the
> AMD64 platform when the CPUID patch is applied:
>
> https://launchpad.net/~q-funk/+archive/+builds?build_text=&build_state=failed
>
> It successfully built on LPIA and i386, though.

Thanks, I will address this later today. The problem is in the asm code
I added to work with __PIC__ on i386.

/tmp/ccO6wCzI.s: Assembler messages:
/tmp/ccO6wCzI.s:38815: Error: suffix or operands invalid for `push'
/tmp/ccO6wCzI.s:38818: Error: suffix or operands invalid for `pop'

amd64 doesn't have the __PIC__ restriction that i386 does, so it should
be an easy fix... but I'll actually test it on amd64 before posting the
patch again ;)

-Bart

--
    WebSig: http://www.jukie.net/~bart/sig/

Another repost of the CPUID patch for systems that don't need it :)

i've tried to compile kernel v2.6.24 with AMD GEODE family framebufer support (as described on http://ca.blog.360.yahoo.com/blog-RkGSoVA1brWtXrVH9Gr5CzgVujwwGg--?cq=1&tag=lx800 ) - the same behavour as described before =( is this related to xorg-core? or this is a kernel bug?

On 2/8/08, Romeo <email address hidden> wrote:
> i've tried to compile kernel v2.6.24 with AMD GEODE family framebufer
> support (as described on http://ca.blog.360.yahoo.com/blog-
> RkGSoVA1brWtXrVH9Gr5CzgVujwwGg--?cq=1&tag=lx800 ) - the same behavour as
> described before =( is this related to xorg-core? or this is a kernel
> bug?

This is an X core bug. Building the same AMD driver against an older X
release (up to 1.2) produces a driver that freely changes vcons.

--
Martin-Éric Racine
http://q-funk.iki.fi

Bart, this version fixed for amd64 works. My PPA successfully built 2:1.3.0.0.dfsg-12ubuntu12 on all 3 supported architectures. Ideally, I would like all 3 x86emu patches to be tested by Debian, to ensure that they work on all architectures, before we push for them to be merged upstream but, as far as Ubuntu goes, this finally works straight out of the box.

Martin-Éric Racine, I used your sources.list entries and it worked for me. I had to chroot to my LTSP root (/opt/ltsp/i386) and add the sources from there, apt-get update/dist-upgrade, ltsp-rebuild-image - and my Koolu thin client booted up into X (ldm).

I had to edit my lts.conf to allow higher color and resolution - but the X_MODE_O = 1024x768 isn't working. It still will only do 800x600 - I don't know if this is an issue with the driver or not.

Jordan, you'd need AMD driver 2.7.7.6 to raise the minimal color depth to 16-bit default. This should fix your resolution issue. However, if it doesn't, you'd have to investigate whether your Koolu client runs on a General software BIOS. If it does, it could very well be that the BIOS was compiled with TFT support enabled, which drastically reduces the number of available resolutions. It could also be that the BIOS was compiled without DDC support, which is a frequent side-effect of building a BIOS with RS232 support. In that case, I would suggest contacting Koolu for instructions on how to update your BIOS with a correct build.

Martin-Éric - Your PPA contains AMD driver 2.7.7.5 - are there updated packages (2.7.7.6) for Gutsy? I can't seem to locate them (besides for Hardy).

Martin-Éric, thank you - I saw you just uploaded 2.7.7.6 about an hour ago. What's weird is that my apt-get update && apt-get dist-upgrade (with your sources.list entries) did not pull down the newest version.

I did download the xserver-xorg-video-amd_2.7.7.6-1ubuntu2_i386.deb update and installed it manually into my chroot (which did, by default, detect 16-bit color with no lts.conf entries necessary on my Koolu thin client).

Unfortunately, X still detects a maximum screen resolution of 800x600. Any further pointers regarding this issue would be great.

Here are the BIOS specs on my test Koolu (http://www.koolu.com) thin-client:

---
Phoenix AwardBIOS v6.00PG
Version ADA07
11/08/2007-AMD-GX3-6A43AF0AC-00
---

Sincerely,
Jordan

Also, on the thin client, in /var/log/Xorg.6.log, I'm getting:

---
AMD(0): Not using default mode "1280x1024" (unknown reason)
AMD(0): Not using default mode "1280x1024" (bad mode clock/interlace/doublescan)
---

With different sets of resolutions.

This tells me that the BIOS in your Koolu client has broken or disabled DDC support. You'd need to contact Koolu and inform them of this and see if they provide any BIOS update service.

Just e-mailed Koolu support and referenced this bug. I'll get back once they return my e-mail.

This bug was fixed in the package xorg-server - 2:1.4.1~git20080131-1ubuntu3

---------------
xorg-server (2:1.4.1~git20080131-1ubuntu3) hardy; urgency=low

  [ Bryce Harrington ]
  * Add 150_edid_quirk_lp154w01.patch to fix font size on LGPhilipsLCD
    LP154W01-TLAE (LP: #127827)
  * Add 149_add_quirks_for_physical_screen_size_issues.patch to help
    address various common EDID issues (like monitors that report in
    centimeters instead of millimeters, etc.) (LP: #151311)

  [ Timo Aaltonen ]
  * Add 151_x86emu_handle_cpuid.patch to fix X86EMU CPUID handling.
    (LP: #180742)

 -- Timo Aaltonen <email address hidden> Tue, 19 Feb 2008 17:48:05 +0200

Closing the driver task. I assume this really is fixed now..