Home

Xorg 7.2.0 on Evo T20

2007, May 10 - 10:23 — müzso
If you're using Ubuntu Feisty (eg. with LTSP-5) on a Compaq Evo T20, then you've probably already noticed that the NSC driver fails to load. The problem occurs only with the latest (2.8.2) version. Reverting back to v2.8.1 fixes it. Here's how to do that ...

If you try to start X with Xorg v7.2.0 and NSC driver v2.8.2, then you get the following error message in your Xorg log file (I'll put here just the tail of the log):
(...)
(II) Setting vga for screen 0.
(II) Loading sub module "vgahw"
(II) LoadModule: "vgahw"
(II) Loading /usr/lib/xorg/modules//libvgahw.so
(II) Module vgahw: vendor="X.Org Foundation"
        compiled for 7.2.0, module version = 0.1.0
        ABI class: X.Org Video Driver, version 1.1
(WW) System lacks support for changing MTRRs

Fatal server error:
xf86MapVidMem: Could not mmap framebuffer (0x00000000,0xfe280000) (Cannot allocate memory)

The fatal error occurs at the place where usually the first NSC log entries would appear. I tried to find a fix for this with Google, but failed. If somebody knows the answer, please share it with me by dropping a comment to this post.

The only fix I know about is going back to the previous version of the NSC driver (namely v2.8.1). I'll describe how to do that. You can run the following as root supposed you've your LTSP in /opt/ltsp/i386 and you've wget installed:
cd /opt/ltsp/i386/tmp
wget 'http://archive.ubuntu.com/ubuntu/pool/main/x/xserver-xorg-video-nsc/xserver-xorg-video-nsc_2.8.1-0ubuntu1_i386.deb'
mount --bind /dev /opt/ltsp/i386/dev
chroot /opt/ltsp/i386 /bin/bash
mount -t proc none /proc
mount -t sysfs none /sys
mount -t devpts none /dev/pts
export HOME=/root LC_ALL=C LTSP_HANDLE_DAEMONS=false
cd /tmp
dpkg --force-depends -r xserver-xorg-video-nsc
dpkg -i xserver-xorg-video-nsc_2.8.1-0ubuntu1_i386.deb
echo 'xserver-xorg-video-nsc hold' | dpkg --set-selections
umount /dev/pts
umount /sys
umount -lf /proc
exit
umount /opt/ltsp/i386/dev

The dpkg --set-selections command makes sure that a future update will not replace this older version by accident. You'll be notified during all updates of your LTSP tree that there's a newer version of xserver-xorg-video-nsc available, but it was not installed. Of course you can check from time to time whether the latest version of the driver is fixed on the Evo T20. Smiling And you could drop a comment here if it is ... Eye-wink

Comments

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
2007, June 28 - 16:11 — Steve-o (not verified)

How about rebuilding

How about rebuilding 1:2.8.2-2 from Gutsy? Includes a new upstream version:

http://packages.ubuntu.com/gutsy/x11/xserver-xorg-video-nsc

The problem is its dependency on 2:1.3.0.0 xserver-xorg-core though :/

Same problem with Geode based Starbox, I'm currently using a mix of Edgy MueKow and LTSP 4.2

http://www.cappuccinopc.com/star-466.asp

2007, July 29 - 16:12 — Markus (not verified)

Hi. After 2 days without

Hi.

After 2 days without any result I'm getting mad with the NSC driver. I built a uclibc T20 firmware image and everything is in place except this file. What I have done so far is:

- Downloaded the 2.8.2 and built it without any error againt uclibc.0.29
- Installed it and I get the same error as you
- Downloaded the 2.8.1 and it does not build at all.

Something seems to be strange here. I cannot explain how ubuntu was able to build this driver. The differences between the two versions can be viewed here: http://cgit.freedesktop.org/xorg/driver/xf86-video-nsc. Maybe anyone has a hint.

Markus

2007, July 29 - 18:22 — müzso

building NSC driver

Hi Markus!

I never tried to build the Xorg NSC driver on my own. You asked how the Ubuntu guys could build it and there I might be able to help. As far as I know the method described here should do exactly the same as Ubuntu did for making the Ubuntu-distributed binary versions of the packages. You could try this on the xserver-xorg-video-nsc package and see whether the driver it produces works for you. Of course you'll need an Ubuntu setup for this.

2007, July 29 - 21:02 — Markus (not verified)

Finally I found out what the

Finally I found out what the numbers want to tell us (implementing debugging messages can help quite a lot). The driver thinks that 0xfe280000 is the size of the framebuffer - this is far too much. The error occurs in nsc_regacc.c in function GetVideoMemSize(). To check the real size I activated framebuffer support in my 2.6.22.5 kernel and got the following output:

...
io scheduler cfq registered
PCI: Fixup for MediaGX/Geode Slave Disconnect Boundary (0x41=0x9c)
gx1fb 0000:00:12.4: 2560 Kibyte of video memory at 0x40800000
fb0: GX1 frame buffer device
Real Time Clock Driver v1.12ac
...

I modded the driver to tell it only to use 2MB but this does not help further. The fix in nsc_gx1_driver.c only resulted in an signal 11.

...
pGeode->FBSize = GetVideoMemSize();
/* experimental fix */
pGeode->FBSize = 0x200000;
...

As the framebuffer size detection code is exactly the same as in 2.8.1 I'm wondering why it should work with the previous driver release.

Markus

2007, July 29 - 21:09 — müzso

Re: Finally I found out ...

Maybe going through a diff of the two versions of nsc_regacc.c might help? Did you try what Steve-o suggested a few comments above (compiling the latest version of the NSC driver from Gutsy)?

2007, July 30 - 21:29 — Markus (not verified)

Again, one step

Again, one step further.

The driver seems to have problems when accessing the PCI bus. The function gfx_detect_cpu() in module gfx_init.c tries to read the vendor ID of the Geode graphic PCI device with the following code:

value = gfx_pci_config_read(0x80000000);
if (value == PCI_VENDOR_DEVICE_GXM) {
...
value = gfx_pci_config_read(0x80000800);
if (value == PCI_VENDOR_DEVICE_REDCLOUD) {
...

Obviously it uses the standard PCI access through ports 0x0CF8/0x0CFC. After implementing further debug messages I got the following X result:

...
DBG:gfx_pci_config_read(0x80000000)=0 but expected PCI_VENDOR_DEVICE_GXM=69752
DBG:gfx_pci_config_read(0x80000800)=0 but expected PCI_VENDOR_DEVICE_REDCLOUD=2625547
...

Both read request result in an 0 reply and not in vendor id as expected. As I'm no PCI expert at all, I guess it is not a driver problem but a general access problem when reading the PCI configuration.

Markus

2007, July 30 - 22:03 — müzso

Re: Again, one step

I've got the feeling that you'll dig as deep as necessary to find the answer. Smiling

2007, July 31 - 11:03 — Markus (not verified)

I just checkd the different

I just checkd the different NSC driver versions 2.8.0, 2.8.1 & 2.8.2 and the source of above mentioned ubuntu version. The only changes that were implemented are renaming of functions that had naming conflicts. This should not interfere with the behaviour of device detection.

After spending a bit more time in this I'm getting more and more confused. Every read access to the PCI or device ports results in an totally strange result. For example the total build in RAM of my T20 ist detected with about 20MB and the framebuffer address is detected with about 50MB. And with Videoram = TotalRAM - FramebufferBase = 20MB-50MB this results in -30MB (=0xFE280000).

The deeper I dig the more weired it gets.

Markus

2007, July 31 - 11:36 — müzso

Re: I just checked ...

But there must be something between 2.8.1 and 2.8.2 that makes a difference! Shocked Otherwise how would you explain that Xorg works with the 2.8.1 and does not with 2.8.2?

2007, July 31 - 12:12 — müzso

changes

I've downloaded the NSC 2.8.1 and 2.8.2 sources from the Ubuntu archive, applied the Ubuntu patches and made a diff of the source trees of the two versions. The diff got 550KB long! I suspect there must be a few changes between the two versions besides the resolution of naming conflicts. Shocked

Syndicate content