Ubuntu

xf86-video-amd: fails to autoconfigure

Reported by Scott Balneaves on 2007-09-17
48
Affects Status Importance Assigned to Milestone
xf86-video-amd
Fix Released
Medium
xorg-server (Ubuntu)
High
Bryce Harrington
xserver-xorg-video-amd (Debian)
Invalid
Undecided
Unassigned
xserver-xorg-video-geode (Ubuntu)
High
Unassigned

Bug Description

Binary package hint: xserver-xorg-video-amd

As part of the LTSP project, we detect which video card is in the machine by running a Xorg -configure :1, and using the resulting file.

I have a ThinCan DBE61, http://www.artecgroup.com/thincan/ and am proving it with Ubuntu, as they wish to officially support Ubuntu with their product.

It has a geode video driver, but autodetection fails with a crash dump:

Crash dump and lspci -vv output pasted subsequently.

Scott

Related branches

Scott Balneaves (sbalneav) wrote :

Output of Xorg -configure :1 > /tmp/xorg-output 2>&1

Scott Balneaves (sbalneav) wrote :

lspci

Martin-Éric Racine (q-funk) wrote :

Can you try deleting /usr/lib/xorg/modules/drivers/ztv_drv.so and see if helps auto-configuration succeed?

Scott Balneaves (sbalneav) wrote :

Tried, no difference, other than the two EE lines regarding the ztv driver disappear.

I installed the xserver-xorg-driver-amd-dbg package in the chroot, hoping for something more than a hex address within the driver where it's failing, but no go. Am I missing something? Any way to get an indication as to where it's dying in the driver?

Scott

Bryce Harrington (bryce) wrote :

Scott,

How about trying an strace?

strace Xorg -configure :1 > /tmp/xorg-strace 2>&1

Changed in xserver-xorg-video-amd:
importance: Undecided → Medium
status: New → Confirmed
assignee: nobody → bryceharrington
Bryce Harrington (bryce) on 2007-09-25
Changed in xserver-xorg-video-amd:
assignee: bryceharrington → nobody
Scott Balneaves (sbalneav) wrote :

strace

Bryce Harrington (bryce) wrote :

Hmm, here's what it's doing immediately prior to printing the backtrace:

write(0, "(II) Loading /usr/lib/xorg/modul"..., 48) = 48
open("/usr/lib/xorg/modules//libvgahw.so", O_RDONLY) = 7
read(7, "\177ELF\1\1\1\0\0\0\0\0\0\0\0\0\3\0\3\0\1\0\0\0\320\21"..., 512) = 512
fstat64(7, {st_mode=S_IFREG|0644, st_size=27921, ...}) = 0
mmap2(NULL, 21848, PROT_READ|PROT_EXEC, MAP_PRIVATE|MAP_DENYWRITE, 7, 0) = 0xb780b000
mmap2(0xb7810000, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_FIXED|MAP_DENYWRITE, 7, 0x5) = 0xb7810000
close(7) = 0
write(0, "(II) Module vgahw: vendor=\"X.Org"..., 45) = 45
write(0, "\tcompiled for 1.3.0", 19) = 19
write(0, ", module version = 0.1.0\n", 25) = 25
write(0, "\tABI class: X.Org Video Driver, "..., 44) = 44
--- SIGSEGV (Segmentation fault) @ 0 (0) ---
rt_sigaction(SIGSEGV, {SIG_IGN}, {0x80c9500, [SEGV], SA_RESTART}, 8) = 0
write(2, "\nBacktrace:\n", 12) = 12
write(0, "\nBacktrace:\n", 12) = 12

Bryce Harrington (bryce) wrote :

So from the strace, it looks like it's failing while trying to load vgahw. Maybe it'd be worth adding `Disable "vgahw"` in the Modules section?

Of course, I wonder why it is trying to load vgahw - shouldn't it be attempting to load -amd? According to the strace, prior to the vgahw stuff, it does find the chipset as GeodeLX:

write(0, "(II) AmdProbe: Probing for suppo"..., 46) = 46
write(0, "(II) AmdProbe: Before MatchPciIn"..., 41) = 41
write(0, "(--) Chipset GeodeLX found\n", 27) = 27
...
write(0, "(II) AmdProbe: MatchPCI (1)!\n", 29) = 29
write(0, "(II) AmdProbe: CPUDetected 32!\n", 31) = 31
write(0, "(II) resource ranges after xf86C"..., 59) = 59
write(0, "\t[0] -1\t0\t0x00100000 - 0x0ffffff"..., 45) = 45
...
write(0, "(II) AMD(0): AmdProbe: result (1"..., 35) = 35
write(0, "(II) resource ranges after probi"..., 36) = 36

Then there's a bunch of hex stuff I don't grok, and it ends up deciding to use vga:

write(0, "(II) Setting vga for screen 0.\n", 31) = 31
lseek(6, 4, SEEK_SET) = 4
write(6, "\7\0 \2", 4) = 4
write(0, "(II) Loading sub module \"vgahw\"\n", 32) = 32
write(0, "(II) LoadModule: \"vgahw\"", 24) = 24

Looks like it also attempted to load fbdevhw:

open("/usr/lib/xorg/modules/linux/", O_RDONLY|O_NONBLOCK|O_LARGEFILE|O_DIRECTORY) = 7
...
stat64("libfbdevhw.so", 0xbfc1c24c) = -1 ENOENT (No such file or directory)

Any of this mean anything to you guys?

Martin-Éric Racine (q-funk) wrote :

Anti Sullin of artecdesign.ee made the following comments :

After a full day of debugging, the result is: we have a picture
(although as we don't support DDC monitor detection, it's defaulted to
800x600@60Hz 256colors; didn't look where that comes from). Still, the
system has some strange problems, things crash etc... But that may be a
problem of my edubuntu server.

X gets started twice. Once with -configure option, that autodetects
video HW and monitors and writes config file. Second run is started with
that config file.
On the first run, all drivers are probed. Those, that existed, are
preinit'ed to try to get monitor information (if not, then defaults are
probably used). (screen configuration is not there as it does not exist
yet).
On second run, the AMD driver is loaded and preinit is called. But at
that point, the screen information is already there and everything works.

The bug is that the screen information is not passed to the PreInit
function at probe run. (in AMD/geode LX case LXPreInit()). LXPreInit
loads vgahw module (for manipulating something via vga i/o addreses...
is this needed at all?) and then calls function vgaHWGetHWRec there.
That accesses scrp->confScreen->options, but scrp->confScreen is a null
pointer because we are on a probe run and we don't have any screens
yet... And BANG, segmentation fault. (Some more accesses of
scrp->confScreen are in LXPreInit, too... so removing vgahw doesn't help).

The gdb log about the crash, too.

Program received signal SIGSEGV, Segmentation fault.
0xb7816f6f in vgaHWGetHWRec (scrp=0x8227610)
  at ../../../../hw/xfree86/vgahw/vgaHW.c:1721
1721 ../../../../hw/xfree86/vgahw/vgaHW.c: No such file or directory.
      in ../../../../hw/xfree86/vgahw/vgaHW.c
(gdb) bt
#0 0xb7816f6f in vgaHWGetHWRec (scrp=0x8227610)
  at ../../../../hw/xfree86/vgahw/vgaHW.c:1721
#1 0xb7cc8a35 in LXPreInit (pScrni=0x8227610, flags=1) at
amd_lx_driver.c:488
#2 0x080bb72e in DoConfigure ()
  at ../../../../hw/xfree86/common/xf86Configure.c:985
#3 0x080a8b05 in InitOutput (pScreenInfo=0x8202a80, argc=3,
argv=0xbfac7dd4)
  at ../../../../hw/xfree86/common/xf86Init.c:388
#4 0x08076ceb in main (argc=3, argv=0xbfac7dd4, envp=0xbfac7de4)
  at ../../dix/main.c:370

Fix:
-------------
1) as on ati driver, the driver does not have to initialize anything IF
the PROBE_DETECT flag is present. We should detect monitor (but don't
have to). After that, we need just to return TRUE;
So for a quick fix without any monitor detection, I just added

if (flags & PROBE_DETECT) return TRUE;

to the LXPreInit beginning (after variable declarations). X comes up and
we have a picture... although 800x600@60Hz,256colors only.

2) maybe the vgahw should be removed as on ati :
http://lists.freedesktop.org/archives/xorg/2004-December/004951.html ?
Is it needed at all?

BastiBense (basti-bense) wrote :

I can confirm this problem with Ubuntu 7.04 and 7.10 running on a Linutop PC equipped with an Geode LX processor.
Is anyone working on a fix?

Bryce Harrington (bryce) on 2007-10-19
Changed in xserver-xorg-video-amd:
importance: Medium → High
status: Confirmed → Triaged
Guilherme Straioto (straioto) wrote :

I am with the same problem

I am using Edubuntu Server 10 Ltsp 5, with a thin client called Brazilian iclient description attached, it uses the video driver amd but not start the way of no X.

Martin-Éric Racine (q-funk) wrote :

Another comment from Anti Sullin:

> So for a quick fix without any monitor detection, I just added
>
> if (flags & PROBE_DETECT) return TRUE;
>
> to the LXPreInit beginning (after variable declarations).
> X comes up and we have a picture... although 800x600@60Hz, 256colors only.

Btw, this hack just makes the probe work, but it breaks DDC. The exact PROBE_DETECT check comes a bit later, but the code in between crashes.

I guess that the the existing PROBE_DETECT flag check with GeodeProbeDDC() call should be moved before vgahw module loading, but I haven't looked all dependencies how that could be implemented.

Actually, a good point of start would be to see what other drivers are doing - a lot of the drivers are using the vga/vesa bios for DDC information - so the beginning of the PreInit could probably just be copied from some other driver (i.e. I see a lot of similarities with ati r128_driver.c).

Martin-Éric Racine (q-funk) wrote :

Bernardo Innocenti recalls having fixed this particular issue in the OLPC fork. He suggests cherry-picking useful changes from:

http://dev.laptop.org/git?p=olpc-2.6

Martin-Éric Racine (q-funk) wrote :

In response to Bernardo's comment, here is the diff between

git://anongit.freedesktop.org/git/xorg/driver/xf86-video-amd.git

and

git://dev.laptop.org/xf86-amd-devel

Martin-Éric Racine (q-funk) wrote :

As a test, I built a driver against the OLPC tree. It freezes the whole system dead, as soon as X launches, presumably because it includes support for the OLPC DCON.

AMD's Jordan Crouse proposes the following patch.

Scott, can you apply it to the current package and see if it fixes it for you?

On 17/09/07 14:43 +0300, Martin-Éric Racine wrote:
> Greetings everyone,
>
> Can anyone reproduce the following bug?
>
> https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051

Patch is attached - just a trivial re-arranging of the first few
commands in PreInit.

[LX] Re-arrange PreInit to avoid segfaults in Xorg -configure

Re-arrange the early part of PreInit so that Xorg -configure can run
cleanly.
---

 src/amd_lx_driver.c | 44 +++++++++++++++++++++++++-------------------
 1 files changed, 25 insertions(+), 19 deletions(-)

diff --git a/src/amd_lx_driver.c b/src/amd_lx_driver.c
index c6600d4..7dbed87 100644
--- a/src/amd_lx_driver.c
+++ b/src/amd_lx_driver.c
@@ -471,39 +471,45 @@ LXPreInit(ScrnInfoPtr pScrni, int flags)
 {
     GeodePtr pGeode;
     ClockRangePtr GeodeClockRange;
+ EntityInfoPtr pEnt;
     OptionInfoRec *GeodeOptions = &LX_GeodeOptions[0];
     rgb defaultWeight = { 0, 0, 0 };
     int modecnt;
     char *s, *panelgeo = NULL;
+ Bool useVGA;

- pGeode = pScrni->driverPrivate = xnfcalloc(sizeof(GeodeRec), 1);
+ if (pScrni->numEntities != 1)
+ return FALSE;

- if (pGeode == NULL)
- return FALSE;
+ pEnt = xf86GetEntityInfo(pScrni->entityList[0]);

- /* Probe for VGA */
- pGeode->useVGA = TRUE;
- pGeode->VGAActive = FALSE;
+ if (pEnt->resources)
+ return FALSE;
+
+ useVGA = LXCheckVGA(pScrni);
+
+ if (flags & PROBE_DETECT) {
+ if (useVGA)
+ GeodeProbeDDC(pScrni, pEnt->index);

- if (xf86LoadSubModule(pScrni, "vgahw")) {
- if (vgaHWGetHWRec(pScrni))
- pGeode->useVGA = LXCheckVGA(pScrni);
+ return TRUE;
     }

- if (pGeode->useVGA)
- pGeode->vesa = xcalloc(sizeof(VESARec), 1);
+ pGeode = pScrni->driverPrivate = xnfcalloc(sizeof(GeodeRec), 1);

- if (pScrni->numEntities != 1)
- return FALSE;
+ if (pGeode == NULL)
+ return FALSE;

- pGeode->pEnt = xf86GetEntityInfo(pScrni->entityList[0]);
+ pGeode->useVGA = useVGA;
+ pGeode->VGAActive = FALSE;
+ pGeode->pEnt = pEnt;

- if (pGeode->pEnt->resources)
- return FALSE;
+ if (pGeode->useVGA) {
+ if (!xf86LoadSubModule(pScrni, "vgahw") ||
+ !vgaHWGetHWRec(pScrni))
+ pGeode->useVGA = FALSE;

- if (pGeode->useVGA && (flags & PROBE_DETECT)) {
- GeodeProbeDDC(pScrni, pGeode->pEnt->index);
- return TRUE;
+ pGeode->vesa = xcalloc(sizeof(VESARec), 1);
     }

     cim_rdmsr = LXReadMSR;

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

We essentially need to test for two things with this patch:

1) does it solve the crash everyone experiences?

2) does it help X auto-configure itself to the maximum resolution offered by the display?

Martin-Éric Racine (q-funk) wrote :

Test packages (Gutsy chroot in pbuilder) are available at

http://q-funk.iki.fi/debian/pool/x/xserver-xorg-video-amd/

The debdiff is attached.

On 11/5/07, Jordan Crouse <email address hidden> wrote:
> On 17/09/07 14:43 +0300, Martin-Éric Racine wrote:
> > Greetings everyone,
> >
> > Can anyone reproduce the following bug?
> >
> > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051
>
> Patch is attached - just a trivial re-arranging of the first few
> commands in PreInit.
>
> [LX] Re-arrange PreInit to avoid segfaults in Xorg -configure
>
> Re-arrange the early part of PreInit so that Xorg -configure can run
> cleanly.

I patched and repacked:
http://q-funk.iki.fi/debian/pool/x/xserver-xorg-video-amd/

I tested this with a ThinCan (http://www.thincan.com) running on a
Geode LX and while -configure doesn't crash, detection of the best
available resolution and color depth still fails. We end up in what
appears to be 640x480 @ 4 bit.

Can anyone else running on GX or LX hardware confirm or infirm the above result?

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

Jordan Crouse (jordan-crouse) wrote :

On 11/11/07 13:36 +0200, Martin-Éric Racine wrote:
> On 11/5/07, Jordan Crouse <email address hidden> wrote:
> > On 17/09/07 14:43 +0300, Martin-Éric Racine wrote:
> > > Greetings everyone,
> > >
> > > Can anyone reproduce the following bug?
> > >
> > > https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/140051
> >
> > Patch is attached - just a trivial re-arranging of the first few
> > commands in PreInit.
> >
> > [LX] Re-arrange PreInit to avoid segfaults in Xorg -configure
> >
> > Re-arrange the early part of PreInit so that Xorg -configure can run
> > cleanly.
>
> I patched and repacked:
> http://q-funk.iki.fi/debian/pool/x/xserver-xorg-video-amd/
>
> I tested this with a ThinCan (http://www.thincan.com) running on a
> Geode LX and while -configure doesn't crash, detection of the best
> available resolution and color depth still fails. We end up in what
> appears to be 640x480 @ 4 bit.

That would be really unfortunate, because we don't support 4 bit in the
AMD driver. Logs would be useful here.

Jordan

I installed the new driver but still not worked in my thin client, I am almost giving up, my thin client also runs AMD geode, http://www.brazilmkt.com.br/iclient/

Use Ubuntu Gusty upgraded from Feisty, LTSP 5.

Martin-Éric Racine (q-funk) wrote :

Scott reported a few days ago that auto-configuration no longer crashes (which suggests that Jordan's patch indeed does work), but that X fails to find the largest available resolution (which suggests a broken DDC support in X or in this driver.).

GideonRomm (gideon) wrote :

I don't know how Scotty got that. On my machine, this new deb causes the whole system to freeze after boot and become unresponsive....

Gutsy LTSP5 with xserver-xorg-viedo-amd-2.7.7.0-1ubuntu1 retrieved from MatrinEric's repo.

bartman (bart-jukie) wrote :

The discussion started here continued on the xorg mailing list. Here is the thread...

http://lists.x.org/archives/xorg-driver-geode/2007-December/000002.html

I have been debugging the problem on and off and made some headway recently...

http://lists.x.org/archives/xorg-driver-geode/2007-December/000074.html
http://lists.x.org/archives/xorg-driver-geode/2007-December/000075.html

In the last message I give links to a proposed fix to the xorg-server-1.3.0.0 Gutsy package...

http://www.jukie.net/~bart/patches/xorg-server/20071222/0001-X86EMU-blacklist-I-O-port-20-for-INT-10-emulation.patch

I have rebuilt the packages and they are available here:

http://www.jukie.net/~bart/debian/xorg/xserver-xorg-core_1.3.0.0.dfsg-12ubuntu8_i386.deb
http://www.jukie.net/~bart/debian/xorg/xserver-xorg-video-amd_2.7.7.3-1_i386.deb

The xorg-core includes my patch that just ignores reads/writes to IO port 0x20.
The xorg-video-amd includes Jordan's patch rebased onto 2.7.7.3.

If you have a change to try it, please let me know if it made any difference on your hardware. Note, however, that the xorg-core spits out a lot of port access messages... so it takes longer to start up. Also, it seems that DDC still does not work, but at least it does not freeze.

Martin-Éric Racine (q-funk) wrote :

Guilherme Straioto: you reported that the driver fails on a Brazilian-made thin client. Could you tell us which brand and version of BIOS is used to boot it? Thanks!

Martin-Éric Racine (q-funk) wrote :

Looking at the PDF that Guilherme attached to the bug, it appears that that Brazilian thin client boots off a General Software BIOS.

I've just discovered this bug report and reading it with interest. :-)

I have a Linuterm, which is also based on the ThinCan DBE61.
I'm trying to let it run LTSP on a Ubuntu "Gutsy" basis.

Bartman, I've just downloaded and installed your packages.
The Xorg server is able to start without crash or hang, in 800x600x8.

I've attached my xorg.conf, Xorg.0.log and xwininfo.
Let me know if you need any other information.

I'll try to use this from know and see how far it's usable.
Thanks for the research and packaging!

Oh... We can't attach more than one file at a time??

Great!
I'm able to use Xorg at 1280x1024x16 without any trouble! :-)

I just had to tune a few things manually, like:
- HorizSync & VertRefresh to allow full screen size
- DefaultDepth to get 16 bits depth
- Modes in SubSection "Display" to get the size I wanted

But we should be able to get most of this automagically.
See what "ddcprobe" gives:

vbe: VESA 2.0 detected.
oem: Advanced Micro Devices
memory: 16384kb
mode: 640x480x256
mode: 800x600x256
mode: 1024x768x256
mode: 1280x1024x256
mode: 640x480x32k
mode: 640x480x64k
mode: 640x480x16m
mode: 800x600x32k
mode: 800x600x64k
mode: 800x600x16m
mode: 1024x768x32k
mode: 1024x768x64k
mode: 1024x768x16m
mode: 1280x1024x32k
mode: 1280x1024x64k
mode: 1280x1024x16m
mode: 1600x1200x32k
mode: 1600x1200x64k
edid:
edidfail

From that we could guess horizontal & vertical data...

Martin-Éric Racine (q-funk) wrote :

I have uploaded packages based upon upstream 2.7.7.4 that should fix this issue for most hardware configurations.

A known exception is hardware booting off General Software BIOS, on which there are issues with X server 1.3 and newer, more specifically with the x86emu component of X server, that cause a complete hardware freeze. General Software has been notified through various channels.

Gutsy packages (source and binary) can be found at: http://q-funk.iki.fi/debian/pool/x/xserver-xorg-video-amd/

Hardy packages are being synchronized from Debian and should be available soon.

Martin-Éric Racine (q-funk) wrote :

xserver-xorg-video-amd (2.7.7.4-1gutsy1) gutsy; urgency=medium

  * Reverted 2.7.7.2-2 debian/control changes to produce Gutsy package.

xserver-xorg-video-amd (2.7.7.4-1) unstable; urgency=low

  * New upstream release:
    [GX][LX] PreInit fixes to avoid segfaults on X -configure.

    This is known to work on products with GeodeROM and Insyde BIOSes.

    On products with a General Software BIOS, a freeze occurs while X
    is probing VBE. The same issue occurs with LinuxBIOS and VGAROM,
    but not with LinuxBIOS omitting VGAROM.

    Both issues appear to be caused by X server core upgrading from
    vm86 to x86emu since X server release 1.3, which requires fixing
    x86emu, or the concerned BIOSes, or both.

xserver-xorg-video-amd (2.7.7.3-1) unstable; urgency=low

  * New upstream release.

xserver-xorg-video-amd (2.7.7.2-2) unstable; urgency=low

  * Bumped Build-Depends to X server 1.4 core as follow:
    + xserver-xorg-dev (>= 1:1.1.1) to (>= 2:1.4).
    + x11proto-randr-dev (no version) to (>= 1.2).
  * Bumped binary target Provides correspondingly as follow:
    xserver-xorg-video-1.0 to xserver-xorg-video-2.
  * Above changes break compatibility with Debian/Etch and Ubuntu/Gutsy,
    but restore ABI/API compatibility with X.org 7.3 (Closes: #443285).

xserver-xorg-video-amd (2.7.7.2-1) unstable; urgency=low

  * New upstream release.

xserver-xorg-video-amd (2.7.7.0-1) unstable; urgency=low

  * New upstream release:
    This is the first official upstream release to come out of GIT.
    Many thanks go to AMD's Jordan Crouse and to other OLPC developers
    for making this release happen.

joeblack (threetwinm) wrote :

I have an ALIX1c lx800 motherboard from pcengines, after a long effort I successed to be able run Xorg 1.3 with the latest driver amd_drv.so. Now I have a really strange problem. Xorg works perfect, I can easily manage dpms modes and resolutions, but whenever I want to go back to console w/o X the display shows a message "out of range" and it doesnt fix until restartx or reboot. eventually this happens when I reboot or shutdown too, it is obvious that the driver fails the console after killing X.

I have tried every single driver in the forum. no luck
I appreciate any help or suggestion.
best regards
Joe BLACK

bartman (bart-jukie) wrote :

More about the Geode LX crash with Generla Software BIOS...

There seems to be an inconsistency between what the x86emu gets from the
PCI handling code and by accessing hardware directly. x86emu relies on
a set of functions to emulate PCI access. When things goes wrong, the
emulator is asked to execute an OUT instruction on port 0x20.

I've put together a patch against xserver-xorg package that prevents
accesses to BAD registers. This turns a freeze into a segfault in X.

http://www.jukie.net/~bart/patches/xorg-server/20080111/0001-X86EMU-added-blacklist-for-I-O-port-in-0-0xFF-range.patch

It does not address the DDC not working, I hope that after fixing the
bugs in x86emu, things may improve.

Anyway, I am continuing to investigate the real cause of the PCI access
issue. To find out more read this thread:

http://lists.freedesktop.org/archives/xorg/2008-January/031811.html

-Bart

Martin-Éric Racine (q-funk) wrote :

There's actually 2 patches against x86emu found in X server >= 1.3 that need to be tested:

http://www.jukie.net/~bart/patches/xorg-server/20080111/0001-X86EMU-added-blacklist-for-I-O-port-in-0-0xFF-range.patch

and

http://www.jukie.net/~bart/patches/xorg-server/20080111/0001-X86EMU-pass-the-correct-bus-dev-fn-tag-to-pci-emula.patch

Ideally, these should be released to Gutsy as an update, to allow people to test and report on their success before Hardy is released, so that Ubuntu X maintainers have enough time to patch the server in Hardy too.

We need confirmation from as many of the users subscribed to this bug, before we can proceed with the release.

Eugene (kukachik) wrote :

I confirm this bug.

Martin-Éric Racine (q-funk) wrote :

I meant confirmation of whether these two x86emu patches fix the bug or not.

bartman (bart-jukie) wrote :

With reference to:

>> I meant confirmation of whether these two x86emu patches fix the bug or not.

My two patches do not solve the "DDC not working" bug. They fix two bugs in x86emu that cause the freeze.

I plan on working on the DDC/EDID issues later this week.

Bryce Harrington (bryce) wrote :

Actually, putting these into gutsy-proposed before Hardy is doing things in the wrong order; gutsy-proposed should only be used for patches known to fix issues, and where you are working towards getting them posted as an SRU. From the descriptions, these patches change the failure behavior but don't solve the issue, so I would expect the SRU reviewers to reject it.

Generally, the order I prefer is to produce a one-off deb and/or ppa package, get a few people to validate it, then upload to Hardy for moderately wider testing. If after a few days in Hardy, it hasn't caused any mayhem, *then* it would be appropriate to put into gutsy-proposed, and work towards an SRU.

I can take care of doing all of that packaging work.

If you do wish to get this into gutsy as an SRU, please file two bug reports (one for each patch), with the following information:
  - Add to description a statement explaining impact of the bug to
    justify the backport
  - Explain how the bug has been addressed in the development branch
  - Point at the (small, unobtrusive) patch being proposed
  - Add to description detailed steps for reproducing the issue
  - Discuss regression potential and how users could be affected

(The above is from the SRU process at wiki.ubuntu.com).

Martin-Éric Racine (q-funk) wrote :

I have built Gutsy packages of both xserver-xorg-core and xserver-xorg-vidoe-amd and uploaded them in my PPA:

https://launchpad.net/%7Eq-funk/+archive

By installing both, GX/LX users should get a functioning driver with DDC and automatic X configuration. Can subscribers to this bug test this and report on their results? Thanks!

Enrico (ezaffa) wrote :

I installed your packages and now my Lucida LT2610 thin client (LX Geode) works well.
Both ddc and automatic X configuration are ok.

DURAKOVIC Ahmedin (durakovic) wrote :

I installed it on Linutop board based with Geode LX 700, works well.

But it's still broken with GDM when return to console ctrl alt F1,

Martin-Éric Racine (q-funk) wrote :

Problems with console switching is a separate issue see https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/180742 instead.

GideonRomm (gideon) wrote :

The new patched debs fix DDC issues on:

GSW BIOS + GX2
GSW BIOS + LX

I have also tested the debs on non-Geode hardware (intel chipset) and there are no ill effects of the xorg patch on that driver. Great fix!!! Hope to see it in gutsy and hardy soon!

bartman (bart-jukie) wrote :

I am going to port the patches to Hardy's 1.4 debs. I have not started to build a development environment yet.

Can someone in the know, tell me if it's easy to build 1.4 debs under Gutsy, or if I have to setup Hardy.

Martin-Éric Racine (q-funk) wrote :

On a Linutop with General Software BIOS (build date: 2007-01-18), DDC works like a charm and X auto-configuration succeeds too.

Earlier BIOS releases for the Linutop had DDC support disabled and a serial console instead.

My X.log is attached.

Bryce Harrington (bryce) wrote :

Hardy debs are available for testing, with the two patches from bartman included:

http://people.ubuntu.com/~bryce/Testing/xorg-server/xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb

Can someone check that this does indeed address the issue on -amd (and doesn't break anything on non-amd)? If people can confirm it passes on both counts, I'll go ahead and upload it to main.

Bryce Harrington (bryce) wrote :

I booted it successfully (so far) on my laptop. Unfortunately I'm away from home this week, so can't test any further. If others could please check, it'd be appreciated.

Martin-Éric Racine (q-funk) wrote :

As previously reported, DDC works as expected when booting the X server and AMD driver available in my PPA on hardware booting from a hard-disk.

However, one thing I forgot to point out is that I get really psychedelic colors, presumably because the maximum color depth is not correctly detected.

On LTSP, adding the following option to lts.conf works well in a pinch:

X_COLOR_DEPTH=24

On a desktop based on the same chipset, adding the following option to the Screen section in /etc/X11/xorg.conf produces the same effect:

DefaultDepth 24

We're still investigating the cause of this failed maximum depth detection. Stay tuned.

Martin-Éric Racine (q-funk) wrote :

Here is the log I get on the workstation.

I have seen this, as well. Thought it was a GX thing, but I guess
not. In the logs, it seems to assume the color depth of the
framebuffer. Not sure why...

-Gadi

On Jan 25, 2008 4:27 PM, Martin-Éric Racine <email address hidden> wrote:
> As previously reported, DDC works as expected when booting the X server
> and AMD driver available in my PPA on hardware booting from a hard-disk.
>
> However, one thing I forgot to point out is that I get really
> psychedelic colors, presumably because the maximum color depth is not
> correctly detected.
>
> On LTSP, adding the following option to lts.conf works well in a pinch:
>
> X_COLOR_DEPTH=24
>
> On a desktop based on the same chipset, adding the following option to
> the Screen section in /etc/X11/xorg.conf produces the same effect:
>
> DefaultDepth 24
>
> We're still investigating the cause of this failed maximum depth
> detection. Stay tuned.
>
>
> --
> xf86-video-amd: fails to autoconfigure
> https://bugs.launchpad.net/bugs/140051
> You received this bug notification because you are a direct subscriber
> of the bug.
>

Bryce Harrington (bryce) wrote :

Can anyone test the debs I posted please?

Martin-Éric Racine (q-funk) wrote :

The bug was caused by a default pixel depth that was too low. The default is now 16-bit. An upstream 2.7.7.6 has been released to reflect this.

I have uploaded it to my PPA and received confirmation that it was accepted, except that the package has yet to be built by the archive, for some reason.

Martin-Éric Racine (q-funk) wrote :

Bryce, since the issue required patching xserver-xorg-core, rather than xf86-vidoe-amd, would it be appropriate to reassign this bug to source:xorg-server?

Martin-Éric Racine (q-funk) wrote :

Bryce, I tried xserver-xorg-core 1.4.1~git20080118-1ubuntu3 on my Hardy laptop (which uses xserver-xorg-vidoe-siliconmotion). No adverse effect so far.

bartman (bart-jukie) wrote :

Martin-Eric sent me a new Linutop (GeodeLX, General BIOS) to test on.
Booting vanilla Hardy on it froze the system (GeodeLX); shortly after DDC probing.
I then loaded up Bryce's deb's from 2008-01-23; it fixed the bug.

npinhao (nuno.pinhao) wrote :
Download full text (5.9 KiB)

I've tried to install Bryce's deb on Gutsy (Kubuntu + ltsp) with dpkg but found problems:
sudo chroot /opt/ltsp/i386/ dpkg -i /home/npinhao/xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb
dpkg: acerca de .../xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb contendo xserver-xorg-core:
 xserver-xorg-core em conflito com xserver-xorg-input
  xserver-xorg-input-kbd provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-mouse provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-elographics provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-evdev provides xserver-xorg-input and is present and instalado.

(sorry, some of the messages are in Portuguese...)
Then I've tried to force install:

sudo chroot /opt/ltsp/i386/ dpkg -i --force-conflicts /home/npinhao/xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb
dpkg: acerca de .../xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb contendo xserver-xorg-core:
 xserver-xorg-core em conflito com xserver-xorg-input
  xserver-xorg-input-kbd provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-mouse provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-elographics provides xserver-xorg-input and is present and instalado.
  xserver-xorg-input-evdev provides xserver-xorg-input and is present and instalado.
dpkg: aviso - a ignorar conflito, pode proceder de qualquer modo !
dpkg: acerca de .../xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb contendo xserver-xorg-core:
 xserver-xorg-core em conflito com xserver-xorg-video
  xserver-xorg-video-v4l provides xserver-xorg-video and is present and instalado.
dpkg: aviso - a ignorar conflito, pode proceder de qualquer modo !
dpkg: acerca de .../xserver-xorg-core_1.4.1~git20080118-1ubuntu3_i386.deb contendo xserver-xorg-core:
 xserver-xorg-core em conflito com xserver-xorg-video-1.0
  xserver-xorg-video-tseng provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-siliconmotion provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-ati provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-i740 provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-via provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-nv provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-i810 provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-intel provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-chips provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-tga provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-trident provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-s3 provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-vga provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-i128 provides xserver-xorg-video-1.0 and is present and instalado.
  xserver-xorg-video-mga...

Read more...

Martin-Éric Racine (q-funk) wrote :

NOTE: 1.3 is meant for Gutsy, while 1.4 is meant for the upcoming Hardy release.

npinhao (nuno.pinhao) wrote :

Hoops! Thank you for the clarification. So I got what I deserved :-(
I've just noticed that xorg has the code of a new version of the driver, I believe it includes you update. I guess the best thing to do is to download it and compile...

Bryce Harrington (bryce) on 2008-02-02
Changed in xserver-xorg-video-amd:
status: New → Invalid
Bryce Harrington (bryce) wrote :

Adding xserver component, since this bug requires patches against xserver

Changed in xorg-server:
assignee: nobody → bryceharrington
importance: Undecided → High
milestone: none → ubuntu-8.04-beta
status: New → In Progress
Martin-Éric Racine (q-funk) wrote :

Actually, credit for the patches really goes to Bart for finding the cure and to Bryce for adapting it for 1.4.

I personally had no involvement on this patch; I instead focused on improving the -amd driver itself.

Changed in xf86-video-amd:
status: Unknown → Confirmed
Martin-Éric Racine (q-funk) wrote :

Updated Gutsy packages are uploaded to my PPA:

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

Launchpad Janitor (janitor) wrote :
Download full text (3.3 KiB)

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

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

  [ Timo Aaltonen ]
  * Merge with Debian unstable, remaining changes:
  * debian/control:
    - Change maintainer address.
    - set Conflicts: xkb-data (<< 0.9), since xkb-path is
      different compared to Dapper.
    - xvfb Depends on xauth, xfonts-base.
  * debian/patches:
    - 101_fedora-apm-typedefs.patch:
      Temporary hack from Fedora for broken kernels that don't publish the
      /dev/apm_bios types.
    - 102_ubuntu_sharevts_load_cpu.patch:
      Close console fd only when using --sharevts.
    - 103_fedora_openchrome.patch:
      Patch from Fedora to use openchrome instead of via.
    - 104_fedora_init_origins_fix.patch
      Multihead initialization.
    - 105_reduce_wakeups_from_smart_scheduler.diff:
      Patch from upstream to reduce wakeups and improve battery life.
    - 106_ubuntu_fpic_libxf86config.patch
      Add -fPIC to makefiles for xfree86/parser.
    - 107_fedora_dont_backfill_bg_none.patch
      Disable backfilling of windows created with bg=none, which
      otherwise would force a framebuffer readback.
    - 110_fedora_no_move_damage.patch
      Disable damage notifications on move for manually redirected windows.
    - 120_fedora_xserver-xaa-evict-pixmaps.patch:
      New version of the hack to copy textures from video memory. Shouldn't
      break EXA anymore.
    - 121_only_switch_vt_when_active.diff
      Add a check to prevent the X server from changing the VT when
      killing GDM from the console.
    - 123_no_composite_for_xvfb_run.patch
      Use "-extension Composite" to fix xvfb-run crashing.
    - 133_psb_auto.patch
      Add automatic detection of Poulsbo hardware when running
      without a Device definition.
    - 139_fedora_xserver-1.3.0-document-fontpath-correctly.patch
      Fixes document fontpaths shown in the man page.
    - 142_fedora_xserver-1.3.0-no-pseudocolor-composite.patch
      Composite on 8bpp pseudocolor root windows appears to fail, so just
      disable it on anything pseudocolor for safety.
    - 144_fedora_xserver-1.3.0-xnest-exposures.patch:
      Only collect xnest exposures for xexposes with non-zero height and width.
  * 108_fedora_honor_displaysize.patch:
    - Patch from upstream/Fedora to honor the DisplaySize-setting.
      (LP: #135738, b.fd.o #9758)
  * Drop patch 100_avoid_acpi_insanity.diff, superseded by patch 45.

  [ Bart Trojanowski, Martin-Eric Racine ]
  * 146_X86EMU-added-blacklist-for-I-O-port-in-0-0xFF-range.patch
    - Restrict access to I/O ports in range 0-0xFF from x86emu.
    (LP: #140051)
  * 147_X86EMU-pass-the-correct-bus-dev-fn-tag-to-pci-emula.patch
    - Fix improper emulation of PCI access General Software BIOS.
    (LP: #140051)

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

  [ Brice Goglin ]
  * Add 45_only_XF86_APM_CAPABILITY_CHANGED_for_video_change_acpi_events.diff
    to prevent XF86_APM_CAPABILITY_CHANGED from being issued for all ACPI
    events, thanks Sjoerd Simons, closes: #461463.

  [ David Nusinow ]
  * Update Japanese translation from Hideki Yamane. closes:...

Read more...

Changed in xorg-server:
status: In Progress → Fix Released
Jordan Erickson (lns) wrote :

I can confirm the fix ( https://launchpad.net/%7Eq-funk/+archive ) for LTSP thin clients using the AMD Geode chipset, although it only allows me to boot into X11/LDM at 800x600 with what seems to be 16 colors. I cannot manually configure the client as X autoconfigures video every time a thin-client boots. The fixed package for the driver doesn't seem to help X autoconfigure. Unfortunately this leaves me at a standstill - I can manually configure color settings for all clients, but I cannot for resolution.

Any further troubleshooting/help would be greatly appreciated!! I can test any further updated packages with my Koolu thin client.

Martin-Éric Racine (q-funk) wrote :

On 2/13/08, Jordan Erickson <email address hidden> wrote:
> I can confirm the fix ( https://launchpad.net/%7Eq-funk/+archive ) for
> LTSP thin clients using the AMD Geode chipset, although it only allows
> me to boot into X11/LDM at 800x600 with what seems to be 16 colors. I
> cannot manually configure the client as X autoconfigures video every
> time a thin-client boots. The fixed package for the driver doesn't seem
> to help X autoconfigure. Unfortunately this leaves me at a standstill -
> I can manually configure color settings for all clients, but I cannot
> for resolution.
>
> Any further troubleshooting/help would be greatly appreciated!! I can
> test any further updated packages with my Koolu thin client.

Jordan, you have already reported this issue in
https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-amd/+bug/180742
where I asked you to investigates specific items. Can you please
respond to these questions and confirm which BIOS your Koolu hardware
runs, so that we may be able to help you resolve this?

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

Jordan Erickson (lns) wrote :

See that bug report - I am noting all of my further troubleshooting there.

Martin-Éric Racine (q-funk) wrote :

As we noticed during the course of fixing this, it really is an xserver-xorg-core issue, not an xserver-xorg-video-amd issue. 3 patches against the x86emu component of X core were produced and merged before the release of Ubuntu/Hardy, thus fixing it.

Marking the bug as invalid for xserver-xorg-video-amd, but leaving valid for xserver-xorg-core.

Changed in xserver-xorg-video-amd:
status: Triaged → Invalid
ckranich (office-kranich) wrote :

Hello Martin-Éric,

Thank you very much for the precompiled packets!
(With the help of them even a linux newbee like me was able to get it running)

Beside saying thank you I wanted to report back that Xorg starts successfully on
aValue ECM-LX800 3.5" CPU module (LX800 chipset and Phoenix Award Bios 6.00PG)

The only issue I got is that together with IceWM the button faces and window title bars show
garbage (or even a copy of the CPU load graphics!). But possibly this is an issue of my
IceWM setup (running on top of a Ubuntu Gutsy server for minimal footprint)
I will test other windowmanagers too to see if the issue is IceWm-specific

Kind Regards,

    Christian

Billy (vdr-hgm-bg) wrote :

Hello,

i have a problem with this driver on a subnotebook with a AMD Geode LX VGA on Ubuntu 8.04. It runs the VESA driver by default but as the LCD have a strange geometry (1024*600) i need to run that amd driver. Your help is welcome.

00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video (prog-if 00 [VGA controller])
        Subsystem: Advanced Micro Devices [AMD] Geode LX Video
        Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B-
        Status: Cap- 66MHz+ UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR-
        Latency: 0, Cache Line Size: 32 bytes
        Interrupt: pin A routed to IRQ 11
        Region 0: Memory at 90000000 (32-bit, non-prefetchable) [size=32M]
        Region 1: Memory at 8fffc000 (32-bit, non-prefetchable) [size=16K]
        Region 2: Memory at 8fff8000 (32-bit, non-prefetchable) [size=16K]
        Region 3: Memory at 8fff4000 (32-bit, non-prefetchable) [size=16K]
        Region 4: Memory at 8fff0000 (32-bit, non-prefetchable) [size=16K]

I'm new to Ubuntu, i'm used to work with Fedora, so please be patient with me ;)

Gruß
Billy

Martin-Éric Racine (q-funk) wrote :

Billy, can you please try the following:

1) add the following lines to /etc/apt/sources.list:

deb http://ppa.launchpad.net/q-funk/ubuntu hardy main
deb-src http://ppa.launchpad.net/q-funk/ubuntu hardy main

2) sudo apt-get install xserver-xorg-video-amd=2.7.7.8-0ubuntu1.
3) Edit /etc/X11/xorg.conf by adding " Driver "amd" " to the Device Section.
4) Reboot and the login screen should be at the maximum supported resolution.

Billy (vdr-hgm-bg) wrote :

Hmmm, i did, between Step 1 and 2 i did a "sudo apt-get update" and changed driver "vesa" to "amd".

But it still fails:
(II) GEODE: Driver for AMD Geode Chipsets: Geode LX, Geode GX
(II) Primary Device is: PCI 00:01:1
(II) AmdProbe: Probing for supported devices!
(II) AmdProbe: failed 1!
(EE) No devices detected.

but it still tells me that he uses 2.8.0, strange, how can i check the correct installation of a package on Ubuntu?
Is anyone able to give me a modeline for
1024*600@60Hz ?

Thanks for your fast response!

Gruß
Billy

Martin-Éric Racine (q-funk) wrote :

Revised instructions would be:

1) add the following lines to /etc/apt/sources.list:

deb http://ppa.launchpad.net/q-funk/ubuntu hardy main
deb-src http://ppa.launchpad.net/q-funk/ubuntu hardy main

2) sudo apt-get update
3) sudo dpkg -P --force-depends xserver-xorg-video-amd xserver-xorg-video-geode
4) sudo apt-get install xserver-xorg-video-amd=2.7.7.8-0ubuntu1
5) Edit /etc/X11/xorg.conf by adding " Driver "amd" " to the Device Section:

Section "Device"
 Identifier "Card0"
 Driver "amd"
 VendorName "Advanced Micro Devices [AMD]"
 BoardName "Geode LX Video"
 BusID "PCI:0:1:1"
EndSection

6) Reboot and the login screen should be at the maximum supported resolution.

Martin-Éric Racine (q-funk) wrote :

Billy, just to be safe, can you paste the result of the following command to this bug:

sudo lspci -v

Billy (vdr-hgm-bg) wrote :
Download full text (3.8 KiB)

Here we go:
00:01.0 Host bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge (rev 31)
 Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Host Bridge
 Flags: bus master, 66MHz, medium devsel, latency 248
 I/O ports at ac1c [size=4]
 I/O ports at 9e00 [size=8]

00:01.1 VGA compatible controller: Advanced Micro Devices [AMD] Geode LX Video (prog-if 00 [VGA controller])
 Subsystem: Advanced Micro Devices [AMD] Geode LX Video
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 11
 Memory at 90000000 (32-bit, non-prefetchable) [size=32M]
 Memory at 8fffc000 (32-bit, non-prefetchable) [size=16K]
 Memory at 8fff8000 (32-bit, non-prefetchable) [size=16K]
 Memory at 8fff4000 (32-bit, non-prefetchable) [size=16K]
 Memory at 8fff0000 (32-bit, non-prefetchable) [size=16K]

00:01.2 Entertainment encryption device: Advanced Micro Devices [AMD] Geode LX AES Security Block
 Subsystem: Advanced Micro Devices [AMD] Geode LX AES Security Block
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 11
 Memory at efe00000 (32-bit, non-prefetchable) [size=16K]

00:0d.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
 Subsystem: Realtek Semiconductor Co., Ltd. RT8139
 Flags: bus master, medium devsel, latency 64, IRQ 5
 I/O ports at df00 [size=256]
 Memory at efd00000 (32-bit, non-prefetchable) [size=256]
 Capabilities: [50] Power Management version 2

00:0e.0 CardBus bridge: Texas Instruments PCI1510 PC card Cardbus Controller
 Subsystem: Texas Instruments PCI1510 PC card Cardbus Controller
 Flags: bus master, medium devsel, latency 168, IRQ 7
 Memory at efc00000 (32-bit, non-prefetchable) [size=4K]
 Bus: primary=00, secondary=01, subordinate=04, sec-latency=176
 Memory window 0: 88000000-8bfff000 (prefetchable)
 Memory window 1: 94000000-97fff000
 I/O window 0: 00001000-000010ff
 I/O window 1: 00001400-000014ff
 16-bit legacy interface ports at 0001

00:0f.0 ISA bridge: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA (rev 03)
 Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] ISA
 Flags: 66MHz, medium devsel
 I/O ports at 6000 [size=8]
 I/O ports at 6100 [size=256]
 I/O ports at 6200 [size=64]
 I/O ports at 1800 [size=32]
 I/O ports at 9d00 [size=128]
 I/O ports at 9c00 [size=64]

00:0f.2 IDE interface: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE (rev 01) (prog-if 80 [Master])
 Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] IDE
 Flags: bus master, 66MHz, medium devsel, latency 248
 [virtual] Memory at 000001f0 (32-bit, non-prefetchable) [disabled] [size=8]
 [virtual] Memory at 000003f0 (type 3, non-prefetchable) [disabled] [size=1]
 [virtual] Memory at 00000170 (32-bit, non-prefetchable) [disabled] [size=8]
 [virtual] Memory at 00000370 (type 3, non-prefetchable) [disabled] [size=1]
 I/O ports at eff0 [size=16]

00:0f.3 Multimedia audio controller: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio (rev 01)
 Subsystem: Advanced Micro Devices [AMD] CS5536 [Geode companion] Audio
 Flags: bus master, 66MHz, medium devsel, latency 0, IRQ 5
 I/O ports at dc80 [size=128]

00:0f.4 USB Controller: Advanced Micro Devices [AMD] CS...

Read more...

Martin-Éric Racine (q-funk) wrote :

Billy, thanks for the lspci output.

Could you tell us what brand and model number that laptop is, so that we can look up the specifications ourselves?

Martin-Éric Racine (q-funk) wrote :

Jordan of AMD pointed out that, according to your Xorg.log, AmdProbe is calling xf86MatchDevice and that is failing. The only reasons he can think of this ever happening is whenever the BIOS has no VSA layer (or equivalent feature) and no /dev/cpu/0/msr.

Billy, as a test, can you perform the following steps:

1) sudo echo "msr" >> /etc/initramfs-tools/modules
2) sudo dpkg-reconfigure linux-image-2.6.24-16-generic
3) reboot
4) go into a console with CTRL+ALT+F1
5) sudo lsmod | grep msr

...and tell us if that improved anything?

Billy (vdr-hgm-bg) wrote :

Hi Martin-Éric!

Sorry for my late response, i have tried a lot things. First your version of the driver with that Device-Section worked. In the beginning i had no correct screen, so i had to fight with some modelines. The Notebook is a presample, so I'm not allowed to give out more information about manufacter etc.pp. . I finally managed to get it running but still have a problem with the display. If i do a 1024*768 (manual says max. res.) i can't see the bottom of the screen. If i do 1024*600 (supported res.) i still have no bottom of the screen and the display seems to be strechted. Tried it with virtual 1024 600 but no help. if i make a screencapture, it's in 1024*600. But i still can't see the bottom taskbar (only on the capture). Strange things. Is there a way to find out the correct resultion of the LCD monitor?

Now i'll do that msr stuff

Thanks anyway for your great help!

Gruß
Billy

Billy (vdr-hgm-bg) wrote :

I did the msr-stuff and it's loaded as module. I see no difference but i guess that was for activating the driver, which works all ready ;)
Funny thing is, that the software updater wants to install the new amd and geode drivers and xorg-core ;) Will there be a fixed one available soon?

Gruß
Billy

Martin-Éric Racine (q-funk) wrote :

Hardy-proposed now has both a newer X server core and GEODE driver available:

deb http://ee.archive.ubuntu.com/ubuntu/ hardy-proposed main universe restricted #multiverse
deb-src http://ee.archive.ubuntu.com/ubuntu/ hardy-proposed main universe restricted #multiverse

Please test and report your findings ASAP. If no major issue is reported within the next couple of weeks, this will be pushed into Hardy as an update.

PS: Intrepid already has both fixes uploaded since a few days too.

Billy (vdr-hgm-bg) wrote :

Hi Martin-Éric

it doesn't work for me. I tried it before and after applying that msr module, but it fails all the time. I'm still looking for the correct ModeLine entry for 1024x600@60.

See attached log

Gruß
Billy

Martin-Éric Racine (q-funk) wrote :

2.9.0-1ubuntu2 was just replaced by 2.9.0-1ubuntu3 to completely close this issue. It's already available in my PPA and should soon be uploaded to Hardy-proposed. For Intrepid, package 2.9.0-3 (pending import from Debian/unstable) includes the same fixes.

webworm (rudy-webworm) wrote :

Martin-Éric Racine wrote:
> 2.9.0-1ubuntu2 was just replaced by 2.9.0-1ubuntu3 to completely close
> this issue. It's already available in my PPA and should soon be
> uploaded to Hardy-proposed. For Intrepid, package 2.9.0-3 (pending
> import from Debian/unstable) includes the same fixes.
>

I have a linutop too. And experienced the same problem as above. I
hope I will have time to try with the newer packages tomorrow.

webworm (rudy-webworm) wrote :

webworm wrote:
> Martin-Éric Racine wrote:
>> 2.9.0-1ubuntu2 was just replaced by 2.9.0-1ubuntu3 to completely close
>> this issue. It's already available in my PPA and should soon be
>> uploaded to Hardy-proposed. For Intrepid, package 2.9.0-3 (pending
>> import from Debian/unstable) includes the same fixes.
>>
>
> I have a linutop too. And experienced the same problem as above. I
> hope I will have time to try with the newer packages tomorrow.
>

Please see the attached log file.

Billy (vdr-hgm-bg) wrote :

Hi Martin-Éric,

i tried your new version and it fails (sorry no log this time) but when i install the xserver-xorg-video-amd-2.7.7.8-0ubuntu1 with the same xorg.conf, it starts fine with the correct resolution. This is just an info for you ;)

Gruß
Billy

Billy (vdr-hgm-bg) wrote :

Just a question for the professionals here. I can't switch to the virtual console (ALT+CTRL+F1), it starts fading to white and then nothing happens. It does the same fading before X is starting and it takes a lot of time. Is there a possibilty to eliminate this fading/blending?

Gruß
Billy

bartman (bart-jukie) wrote :

I suggest that this become a different bug -- I thought I had fixed this
already :/

I would like to know more about your system. Do you know if you are
suing a framebuffer console? What is your BIOS?

Can you provide the versions of your related packages:

  dpkg -l xserver-xorg-video-geode xserver-xorg-video-amd xserver-xorg-core

If possible could you provide the X.*.log file that was generated while
the freeze to console occurred?

Cheers,
-Bart

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

Billy (vdr-hgm-bg) wrote :

Oh, i can pass the following informations. About framebuffer: I don't use splash as kernelparameter because my system refuses to do a reboot when splash is enabled. How can i provide the BIOS information?

geode: No information
amd: 2.7.7.8-0ubuntu1
core: 2:1.4.1~git20080131-1ubuntu1

Newer versions of xserver-xorg-video-amd don't work on my system (last one tested 2.9.0-1ubuntu3).
My system doesn't crash, it just fades and then nothing happens. I can switch back to the graphical console, but this one is really annoying, especially because the fading happens when the system is starting and when i try to switch to the text console and it takes about 20-25 seconds.

Any more information i can provide?

Thanks
Billy

Jordan Crouse (jordan-crouse) wrote :

I presume this is a TFT panel? If so, then this the different bug that Bart already fixed. Fading to white means that the the vsync and hsync were removed from the panel, but since you hit the vm86 bug, the VGA isn't getting control.

Billy (vdr-hgm-bg) wrote :

Oh, okay, do you have the bugnumber for that bug available for me?
Thanks in advance!

Gruß
Billy

Billy (vdr-hgm-bg) wrote :

I forget to mention that it is a notebook, so it has a TFT. What i found out so far: If i put splash on the bootoptions, i can s´witch to the text-console, but the notebook freezes, when a initiate a reboot. Without splash, i can't switch to the text-console but a reboot works. :(
I did all updates today besides the geode-driver.

Gruß
Billy

Billy (vdr-hgm-bg) wrote :

Hi, i tried it again with no luck! Same hardware but different TFT-panel!

See log

Gruß
Billy

Martin-Éric Racine (q-funk) wrote :

Is this issue fixed using either the hardy-updates or the more recent intrepid, jaunty or karmic packages?

Jordan Erickson (lns) wrote :

I have to say it is. My Hardy servers don't have the PPA in them (just -updates) and I've tested on Ibex with success as well.

ckranich (office-kranich) wrote :

Hello all,

I am sure the bug now is fixed in Hardy and Ibex. I tried once with a new
Ubuntu and it worked properly. I will have to get a system(not at hand
currently) and come back with the information since which version it
worked.

Best Regards,

   Christian

> I have to say it is. My Hardy servers don't have the PPA in them (just
> -updates) and I've tested on Ibex with success as well.
>
> --
> xf86-video-amd: fails to autoconfigure
> https://bugs.launchpad.net/bugs/140051
> You received this bug notification because you are a direct subscriber
> of the bug.
>
> Status in xf86-video-amd: Confirmed
> Status in ?xorg-server? package in Ubuntu: Fix Released
> Status in ?xserver-xorg-video-geode? package in Ubuntu: Invalid
> Status in ?xserver-xorg-video-amd? package in Debian: Invalid
>
> Bug description:
> Binary package hint: xserver-xorg-video-amd
>
> As part of the LTSP project, we detect which video card is in the machine
> by running a Xorg -configure :1, and using the resulting file.
>
> I have a ThinCan DBE61, http://www.artecgroup.com/thincan/ and am proving
> it with Ubuntu, as they wish to officially support Ubuntu with their
> product.
>
> It has a geode video driver, but autodetection fails with a crash dump:
>
> Crash dump and lspci -vv output pasted subsequently.
>
> Scott
>
> --
> This message has been scanned for viruses and
> dangerous content by MailScanner, and is
> believed to be clean.
>
>

--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.

Martin-Éric Racine (q-funk) wrote :

Disassociating this bug from freedesktop-bugs #14332. It is actually fixed, but upstream left the bug open because they intend upon eventually revisiting the issue to invent a cleaner way of performing this.

Anyhow, this no longer concerns Ubuntu; closing the bug as a result.

Changed in xf86-video-amd:
status: Confirmed → Invalid
Changed in xf86-video-amd:
status: Invalid → Confirmed
Changed in xf86-video-amd:
importance: Unknown → Medium
status: Confirmed → Fix Released
Changed in xf86-video-amd:
importance: Medium → Unknown
Changed in xf86-video-amd:
importance: Unknown → Medium
To post a comment you must log in.