[agp] X.org does not initialize screen on IBM T20, T21, T22

I'm not sure what X.org.logs I should attach, let me know and I can generate some log files.

Try /var/log/Xorg.0.log first.

This Xorg.0.log is when the screen is initalized and everything is working.

This is the same log file when the X screen does not appear.

I have the same problem, using a Thinkpad T22. It will predictably freeze if I start Ubuntu after a reboot. However, if I turn off the laptop and remove the power plug for a moment before booting it always works fine. Probably this is related to some PCI configuration issue.

I never had this problem with any disto, including Breezy.

Upgraded to critical because this bug makes Dapper unusable for a lot of people. I hope this is ok...
See http://ubuntuforums.org/showthread.php?t=155805

Note my "Bug #39333:
Thinkpad T22 - X.org/GDM freeze GPU when docked (Flight 6 +)," which reported this on the T22.

I do notice two related issues that will (also) ruin one's experience trying to get gdm to load at boot:
-X.org socket cruft in /tmp doesn't appear to get cleaned by the boot process (possibly fixed already?), and
-When /tmp is missing, it may get recreated with the wrong permissions. (I'm pretty sure I did -not- do that manually, but, again, haven't been paying enough attention, don't have enough time to devote to the problem right now.)

After correcting those issues, I somehow managed to get X.org and gdm to come up on my last boot; for a while, it was equally toast even while undocked. I'm not sure if this has cured things or bought me a ticket in the one-time-in-four type crapshoot.

I would say that the note in the thread linked -- http://ubuntuforums.org/showpost.php?p=917923&postcount=12 -- adds fuel to the idea that this is a kernel issue, and on next boot I'll see if disabling the direct-rendering module improves anything.

I confirm this on my own laptop IBM T20, I fixed this issue by reconfiguring several times X.org with dpkg-reconfigure. There is still this bug in the Beta Live-cd but only when you select the first option ("Start Ubuntu"), it works fine if you select "Start ubuntu in safe mode graphics".

This appears to be a hardware bug. See http://www.thinkwiki.org/wiki/Problem_with_video_related_system_lockup and http://mailman.linux-thinkpad.org/pipermail/linux-thinkpad/2006-March/032672.html

Adding

Option "BusType" "PCI"
Option "DmaMode" "None"

to the "Device" section in xorg.conf fixed the issue for me.

If this is a hardware issue is there anything we can do?

I've got a problem that's a bit similar. It happens with an IBM T21, but the PC freezes totally. If somone has it too, please see the following bug:
https://launchpad.net/distros/ubuntu/+source/xorg/+bug/33368

Can you guys please add your xorg.conf ? perhaps we can special case the card in these 2 laptops to write down these options for you.

Fabio

This is the one that works on my Thinkpad T22

Note: This report was sent in using reportbug by martin.ferrari at gmail.com

Hi, a week ago installed Dapper, and when it finished, I stared at a
blank screen. Later I found out that X was crashing the video adapter.
Not even soft reboot would recover it, only power cycling. I learned
this is a rare problem, solved with the following option in xorg.conf:

        Option "BusType" "PCI"

Now it works, but I still have Oopses in the savage kernel module, and
the occassional freeze (as it's a total freeze, I cannot know what
causes it, but I'd bet on the savage). Maybe those symptoms are related.

I found some info on this on:
https://bugs.freedesktop.org/show_bug.cgi?id=3835

My system is a IBM Thinkpad portable. T20 series, model 2647.

report-hw output is included.

-- System Information:
Debian Release: testing/unstable
  APT prefers dapper-updates
  APT policy: (500, 'dapper-updates'), (500, 'dapper-security'), (500,
'dapper-backports'), (500, 'dapper')
Architecture: i386 (i686)
Shell: /bin/sh linked to /bin/bash
Kernel: Linux 2.6.15-21-386
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages xserver-xorg-driver-savage depends on:
ii libc6 2.3.6-0ubuntu17 GNU C Library: Shared libraries an
ii xserver-xorg-core 1:1.0.2-0ubuntu9 X.Org X server -- core server

xserver-xorg-driver-savage recommends no packages.

-- no debconf information

This is the reporthw output from Martin

i have the same problem also using a T20
i found 2 workarounds:
- use the vesa module instead of the savage
or
- reconf xserver-xorg using savage but deselect DRI
-> DRI seams to be the problem!

if there is solution for using T20 with 3D please let me know thx

I also have this problem with an IBM Thinkpad T21 laptop, savage video driver. I have been providing information about the problem in this bug report:

http://www.marryus.org/cityweddings.htm

How do I switch from savage to the vesa module? Is it just a case of replacing "savage" with "vesa" in xorg.conf?

Attaching xorg.conf for my IBM Thinkpad T21 that experiences this problem.

lshw for my IBM Thinkpad T21 that has this problem:

https://wiki.ubuntu.com/SeanHammond?action=AttachFile&do=get&target=taptaplshw.html

Here's a summary the different workarounds for this problem that people have suggested in this thread, which of these is my best bet, if I'm willing to reinstall Dapper on my laptop and try to workaround this problem?

- Use vesa module instead of savage. How do you do this? Just replace savage with vesa in xorg.conf?

- reconf xserver-xorg using savage but deselect DRI => DRI seams to be the problem!

- Add Option "BusType" "PCI" to xorg.conf

- Add

   Option "BusType" "PCI"
   Option "DmaMode" "None"

   to the "Device" section in xorg.conf

- reconfiguring several times X.org with dpkg-reconfigure

I think when I get round to it, I will probably attempt to just use the vesa module, that sounds simplest.

Attaching a couple of x logs from my laptop

Attaching a couple of x logs from my laptop:

Problem seen on my T20 too.

Fabio, do you have enough information now? If you want to explain more of what you had in mind to do the special casing I can try and make a patch.

Bug confirmed and the info requested is attached.

I re-installed Dapper from CD on my laptop that was experiencing this bug. The bug has now disappeared. In my case at least ubuntu seems to have special-cased my laptop all on its own. I installed from a boot of the live session in safe graphics mode, as normal mode failed to boot due to this very bug. After installation, it has set my video driver in xorg.conf to "vesa" rather than to "savage" as the previous install did. I'm pretty sure the previous install was an install from CD, not an upgrade to breezy. So I don't know what caused the change in driver choice, unless maybe it was the safe graphics live session, but to be honest, I think I was probably using that last time too. It's a mystery.

Anyway, I can confirm that switching Driver="savage" to Driver="vesa" in xorg.conf appears to fix the problem. At least, I haven't seen it in two days since I re-installed.

The use of "vesa" works but brings an unacceptable graphics performance. Easy to see if u scroll a website on your browser.

I found ann interessting experiment without any work: Download and start the newest version of Knoppix (5), that uses XOrg 7 and the savage driver.
The website scrolling there looks much better and you also have full hardware 3D-GL support. I already tried to use the xorg.conf from Knoppix in Ubuntu 6.06, without any success.

NO, have to correct myself: Also Knoppix shows sometimes the same behavior and does not start the xserver.
Incredible, that the savage driver sometimes works and sometimes not.
And I also tried out Efty Edge 6.10 without any improvements.

I have seen some anecdotal reports that the vga16fb module and the x.org Savage driver may be incompatible.

Unfortunately, I'm not well-versed in the Linux boot process. Please demonstrate the appropriate incantation to ensure the vga16fb module is never touched (and either vesafb or a dumber console driver is) and I will test this theory on my T21.

I can now confirm that disabling the dri module in X.org worksforme.

This is the xorg.conf I use on my T20 and it works ok with the savage driver and dri.

T20, kernel 2.6.15-26-386, savage driver

I tried your xorg.conf but got some errors concerning dri in /var/log/Xorg.0.log

I suggest to use Option "BusType" "PCI"
in Section "Device" ... rest unchanged!

testet with stellarium 0.71 (repos. universe, ...very nice program to illustrate the sky) ... using dri ... works fine!

T21, 2.6.15-26-686, savage driver

Shaw´s XORG.CONF does not work for me at all. "BusType" entry does not improve the situation.

i added those 2 lines to xorg.conf :
        Option "BusType" "AGP"
        Option "AGPMode" "2"

2 restarts and both worked very well
I didn't test with "DmaMode" "None" cause i dont want to turn off the dma

ps: do only mine's T20 bottom is so hot ? :/

Hi all,

I can confirm that this bug is still present in the Edgy beta. I tried out the savage driver again, graphics performance is **much** better than with vesa, but it has trouble initialising X.

The vesa driver graphics performance seems to have deteriorated a lot between dapper and edgy. In dapper, I didn't much notice the difference between savage and vesa, in edgy, vesa's rendering is almost unbearably slow.

T22 and Ubuntu 6.06 have worked together without any screen problems here.

I can Confirm this Bug with Edgy on T21. It works only if I deactivate DRI.

Rejecting unnecessary duplicate bug task, the bug remains active.

I confirm "Chombee"´s experiences also for Edgy Eft 6.10 RC on T21.

Savage driver works on a T21 with a new Edgy Eft (final) installation, if I take "load dri" in xorg.conf out.

=> better 2D-performance than using the "vesa"-driver

Confirmed, if I comment out "Load DRI" in "Section Module" in /etc/X11/xorg.conf then I can use the savage driver without problems with an IBM T21 running edgy.

Can you try with the soon-to-be-released Feisty Herd4 prerelease?

Timo Aaltonen wrote:
> Can you try with the soon-to-be-released Feisty Herd4 prerelease?
>

Seems to be working on a T20 in Herd4. I'll report if that changes.

It work on feisty herd4 partly. If i boot only with battery everything works, if i use the AC Adapter i get a black screen only, but i can then hear the desktops starting.
When i boot with battery only and attach AC adapter after booting into the desktop everthing work ok.
Sorry for my English i hope you understand what i am saying.

I have just downloaded the Ubuntu 7.04 beta, and tried to install. Problem still there as described. This has been in every version of Ubuntu since 6.06!!! For the general public, this makes Ubuntu completely unusable.

Works for me on T21 only if I deactivate DRI. (comment out load DRI in xorg.conf)

This failure was on all *buntu versions which I tryed and on all gentoo, SuSE and slackware versions. In my case it seems like a problem with the s3 graphic driver.

Can you please test the Option "BusType" "PCI" and leave DRI enabled?

I wrote Option "BusType" "Pci" into the Device Section of my graphic card in my Xorg.conf and uncomment load DRI. Unfortunately it freezed the hole computer after a reboot on the moment were X should start. Looks like it doesn't work for me and I've to comment out load DRI again. I'll attach the /var/log/Xorg.0.log which I've backuped on recovery console.

As you can see in your Xorg.0.log, you misspelled "PCI" (should be all caps):
(WW) SAVAGE(0): Invalid BusType option, using AGP DMA

Here's the xorg.conf I'm currently using with my T20 with good results on feisty. I get about 350fps with glxgears (default window size).

The only recent changes I did as noted above in this bug was to use:

Option "BusType" "PCI"

and the other thing that stands out is that I also use:

DefaultDepth 16

and I have 'savage' listed in my /etc/modules so it gets modprobed before X starts.

Great! It works! (300+ FPS with glxgears) I've tryed so many things over years and I was searching for for a solutions in many ways ... Thanks a lot Tormod Volden. :) I'll atach my xorg.conf.

Ok, now I found the solution on the web too:
http://www.thinkwiki.org/wiki/Problem_with_video_related_system_lockup
I don't know how I couldn't saw this link. Maybe it wasn't there when iI was searching. (Years ago)

This my card:
01:00.0 VGA compatible controller: S3 Inc. 86C270-294 Savage/IX-MV (rev 13)

And here's my xorg.conf:

Could you please also try Option "BusType" "AGP" (or leave out that option) together with Option "DmaType" "PCI" ? This to see if it's just the DMA transfers that break.

I tryed both and It doesn't work neither of them. I'll atach both X error logs.

If needed here's the lshw of this Laptop:
http://www.diener.li/info/ferunkel.html

Isn't your "First try" the same as in comment #51? I am afraid I was not so clear, what I wanted is that you take away the BusType option (default will be AGP) and use (only) Option "DmaType" "PCI".

Please attach xorg.conf each time as well.

Another thing to try: Do you have the option to configure AGP in the BIOS? Can you set AGP speed in BIOS to x1?

Thats my current xorg.conf, where the DmaType is commented out. The third try was with Bustype AGP and DmaType PCI. The second was without a BusType option and DmaType PCI. Both don't worked.

Second Try:
Section "Device"
 Identifier "S3 Inc. 86C270-294 Savage/IX-MV"
 Driver "savage"
 BusID "PCI:1:0:0"
 Option "DmaType" "PCI"
 Option "BusType" "AGP"
EndSection

Third Try:
Section "Device"
 Identifier "S3 Inc. 86C270-294 Savage/IX-MV"
 Driver "savage"
 BusID "PCI:1:0:0"
 Option "DmaType" "PCI"
# Option "BusType" "PCI"
EndSection

Load DRI in modules sections was alwas activated.

This is a testlaptop and I've saw your not far away from me. I'm from Winterthur. If you want and if it helps I can give you the laptop for some time.

Just tried with Feisty, got the same problem that I had with edgy and other releases: blank screen where X should start. After several reboots X does manage to start correctly.

I tried leaving Load "DRI" in the xorg.conf and adding BusType "PCI", but this caused X to fail also. Not in the same way though - I actually got an "X failed to start, would you like to see the logs?" error message. So removed BusType "PCI" and removed Load "DRI" just like I had with edgy and again all is fine.

Noticed that Feisty livecd did not boot (same blank screen where X should be) whereas I think the edgy livecd did work.

Seanh, we "would like to see the logs" :) It would be interesting to see why it would fail to start when you use Option "BusType" "PCI". You didn't forget the "Option" word? Removing DRI is not an acceptable solution for many people, since 3D acceleration will not work.

I recently helped upgrade a T20 and T21 from Edgy to Feisty, and we
didn't have this problem before or after. I don't have access to them
now, but I could check the "DRI" setting if that would be helpful.

   Mark

Hi!

Yesterday, I tried to install Xubuntu feisty fawn on a thinkpad T21. I had the same problem reported here : X hanged. I had to remove DRI to solve the problem, like explained here.

BUT!

I messed with my system, and I reinstalled it today.

AND

the problem is not here anymore... I have the savage driver and DRI working with the stock xorg.conf

The system was previously running Win98.

weird, isn't it?

I had a clean install of Ubuntu 7.04 using 'alternate' cd (text mode).

I had the same issue as everyone else, locked video on starting X.

I read the thread, and made one change to my /etc/X11/xorg.conf:

#in section:
Section "Device"
 Identifier "S3 Inc. 86C270-294 Savage/IX-MV"

# I added:
Option "BusType" "PCI"

It seems to have worked, no more locking - and I still have DRI!

T23

Riocard's fix (Option "BusType" "PCI") worked for me.

Oops - it's a T22

Do all these laptops have the "Intel 440BX/ZX/DX - 82443BX/ZX/DX" AGP bridge? Please check with: lspci | grep AGP

This could be a problem with all Savage/IX-MV cards, but it could also be the combination of card/chipset (involving savage.ko and intel-agp.ko).

My T21 has:
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)

Here's a link to the lshw: http://www.diener.li/info/ferunkel.html

----
id:
  pci
  description: PCI bridge
  product: 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge
  vendor: Intel Corporation
  physical id:
  1
  bus info:
  pci@00:01.0
  version: 03
  width: 32 bits
  clock: 66MHz
  capabilities: pci normal_decode bus_master
---

My T21 also has:
00:01.0 PCI bridge: Intel Corporation 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03)

Adding
Option "BusType" "PCI"

to the Device section of /etc/X11/xorg.conf fixed the problem.

Regards,
Niels Kristian

I installed Xubuntu Linux 7.4 (Feisty Fawn) on my teacher's Thinkpad model T20 2647-84U because it was running to slow with Windows 2000 that came installed with it by default. My teacher timed it and told me it would take seven minutes to reach to MS Windows desktop. So, I thought, there is no way that Windows XP can make things faster and I thought Xubuntu was a good choice since it was designed to run well on older systems.

After the install process everything worked nicely until I shut it down: I noticed the system would turn off but the screen would remain on with the Xubuntu logo. So, I held down the power button to turn it off and I pushed it again to start it. The Xubuntu logo appeared along with the progress bar, then the screen went blank as it does when before the desktop appears, but it didn't. It stayed a blank screen. I became worried because it's my teacher's Thinkpad and I am trying to get her into the Linux world. So I committed myself to give her a working Linux system.

At first I was frustrated and was about to give up. I wasn't getting a system that "just works" as the Ubuntu website claimed. After I chilled my frustration a bit, I decided to Google my problem and I found the site www.thinkwiki.org which deals, precisely. with installing Ubuntu on a Thinkpad:

http://www.thinkwiki.org/wiki/Problem_with_video_related_system_lockup

That site gave me the solution by just adding the line Option "BusType" "PCI" to yhr xorg.conf file. I have to thank Carlos Diener for posting his comment confirming that adding that line fixes the problem, since we both have the same Thinkpad.

Thanks to all the people who take the time to write detailed explanations and, also, thanks to those who by trial and error solved this problem for everyone.

I have a T21, T22 and a T23 all with a 1400x1050 screen, and at least the T21 has only 8Mb of display memory, which means that it's not enough to enable DRI with that resolution (X works otherwise). I tried with a lower one (1024x768) and I now get DRI enabled and X works.

This is with gutsy. Please try Tribe4 when it is released later this week.

Gutsy Tribe-4 live CD does not work on my T21 with 13.3" LCD (1024x768).

Regards,
Niels Kristian

I just saw this problem on a clean install of Feisty 7.04 on a T20 - it was intermittent while I was installing, so I did actually manage to install off the live CD. But after I enabled ACPI (by adding acpi=force to the boot options) X never started again, just hung with a blank screen.

Adding
 Option "BusType" "PCI"
to the xorg.conf file as described above fixed it for me.

As a side note: DRI also works (the bit depth in the default install is set to 16). Also, someone mentioned adding savage to /etc/modules, but I did not need to do this.

ALARMA!!!

My test of Gutsy Gibbon 7.10 (Beta) on a T21 the Savage driver does not seems to work at all. A XORG.CONF that works for me on Feisty (terminated DRI) does not help anymore. The only solution is the bad VESA driver here.

Paranoid, please try without any xorg.conf and attach the Xorg.0.log here. What exactly happens? "does not seems to work at all" :)

Okay Tormod,

I took xorg.conf completly out.
The system reaches the desktop. The Xorg.0.log says me it initializes the savage driver.

One problem is new now: On every start Gnome reports a program crash. It is about the displayconfig-gtk. I send this report to the Ubuntu team.

One correction:
Gnome only reports a crash when I start displayconfig manually.

Like this:

mobilux@mobilux:~$ displayconfig-gtk
fallback mode
Traceback (most recent call last):
  File "/usr/bin/displayconfig-gtk", line 75, in <module>
    app = DisplayConfig(options)
  File "/usr/lib/python2.5/site-packages/displayconfiggtk/DisplayConfig.py", line 188, in __init__
    self.xsetup = XSetup(xconfiginit,
UnboundLocalError: local variable 'xconfiginit' referenced before assignment

Paranoid, please file a bug on displayconfig-gtk.

Not necessary, problem solved automatically by updates yesterday.

What is happening with this bug? It is still not fixed in Gutsy RC.

Regards,
Niels Kristian

I am able to reproduce this problem routinely on a T20 laptop. If I boot "cold", the boot completes and the system runs normally. If I try booting while the machine is still "warm" from previous use (e.g. running Ubuntu), it hangs as described with the dark screen and just the "-" in the upper right portion of the screen. If I unplug the adapter and let it "cool" for a while, I can boot it successfully without any perceived problems.

I am funning version 7.10 and, although quite knowledgeable generally with computers, I have no prior experience with Linux.

Tormod,

Thank you very much for your prompt and helpful response on the problem that I was experiencing! This demonstrates the vibrancy and value of Open Source in general and Ubuntu in particular.

With some "fear", this "dumb user" made the change that you suggested after learning to use sudo and nano, and it worked!

Thank you very much!

John

John H. Taylor, LLC
5 Falcon Court
Limestone Hills
Wilmington, DE 19808-4317
Phone: (302) 234-2566
Pager: 888-432-8057 or <email address hidden>

----- Original Message ----
From: Tormod Volden <email address hidden>
To: <email address hidden>
Sent: Thursday, January 3, 2008 9:35:17 AM
Subject: [Bug 33617] Re: X.org does not initialize screen on IBM T20, T21, T22

** Description changed:

  On the IBM T20 laptop using the Savage drivers, when gdm starts X,
 the
  screen stays black with a "_". The sound is initialized (I can hear
 the
  startup sound) and I can login through SSH. The screen gets
 initalized
  every 3 to 4 times of startup but I can't decern a pattern. This has
  always worked in previous versions of Ubuntu.
+
+ Workaround: Add this to the Device section of xorg.conf:
+ Option "BusType" "PCI"

** Summary changed:

- X.org does not initialize screen on IBM T20, T21, T22
+ [agp] X.org does not initialize screen on IBM T20, T21, T22

--
[agp] X.org does not initialize screen on IBM T20, T21, T22
https://bugs.launchpad.net/bugs/33617
You received this bug notification because you are a direct subscriber
of the bug.

Looks like what this needs is a patch to set psav->IsPCI = TRUE when using this particular graphics card / AGP bridge combo:

        * S3 Inc. 86C270-294 Savage/IX-MV (rev 13)
         * chip 5333,8c12 card 1014,017f
         *
         * "Intel 440BX/ZX/DX - 82443BX/ZX/DX" AGP bridge

Well, here's a first cut at a patch. I don't know how to check the bridge ID for savage, so I've left that out for now.

Can someone experiencing this issue test this patch after removing the BusType option in xorg.conf to check that this fix actually does fix it, without having to specify that in xorg.conf?

  http://people.ubuntu.com/~bryce/Testing/savage/xserver-xorg-video-savage_2.1.3-5ubuntu1_i386.deb

If so, then we can find out how to verify the bridge as well, so we only apply the change for people with this particular hardware combination. (If it turns out that the problem is more widespread, we can open the fix up more, but for now all evidence suggests it's only these two things in combination.)

Just tried your patch without the BusType line on my T20, X wouldn't start but reported no errors either but was lacking the PCI bus line loading and all other things that come along when that loads. Network isn't coming up on it now or i'd post some logs but nothing that relevant except the difference between PCI bustype and not.

@Tom: Weird, and unexpected that it'd fail without reporting an error. Can you try again, and run X by first shutting off gdm (/etc/init.d/gdm stop), and then launch X via `startx > startx.log 2>&1`. Then post both the startx.log and /var/log/Xorg.0.log from right after it failed?

I'm guessing the reason the network didn't come up is because you're on wireless? The wireless manager runs inside X, so if X isn't starting up, that's a problem, but you can sometimes start it manually from the command line, or just use a wired connection (which works regardless of X), or even just copy onto a USB key.

Ok, it does this, I'm using the xorg.conf listed above in one of my comments. The system seems to continue on but it is frozen so I can't do anything except power off. From the syslog.

Mar 21 20:23:58 tom-thinkpad kdm[4767]: X server terminated: [1, 0, 127]
Mar 21 20:23:58 tom-thinkpad kdm[4767]: X server died during startup
Mar 21 20:23:58 tom-thinkpad kdm[4767]: Failed to start X server. Starting failsafe X server.

Failing Xorg.0.log attached.

Log when it's working.

Hmm, so it's failing in between these two lines. Ok, I'll investigate it more after the weekend.

(--) SAVAGE(0): AGP card detected
(**) SAVAGE(0): BusType set to PCI

I am impressed and happy to know that there is still Thinkpad users working on resolving this famous S3 Savage problem. I am a T22 owner since about 3 years and I used Linux on it since 1 year. I tried 3-4 different distros. However, with each distros, I always had problems with DRI enabled.

I tried many ways to make DRI fully functionnal and at max performance if possible. Because of the 8 Mb video RAM, I run at 16-bit colors to get 3D. I used Fedora for about 8 months and I always make it perfectly worked with DRI enabled but with the "BusType" "PCI" and "DmaMode" "None" options in xorg.conf. Great, everything worked but with limitations, slow performance (~200 fps in glxgears) and some 3D applications didn't render any textures or any graphics at all. I installed openSUSE 10.3 few weeks ago. What a distro!! Anyway, I had the same problems but I had more luck sometimes. By default, on installation, openSUSE don't detect 3D acceleration capability on the Savage (I learned that it was maybe a detection bug). However, to enable 3D acceleration, I had only to add

Load "dri"

in xorg.conf modules section. I only did this change and I reboot. Wow, everything boot fine and DRI was enabled. glxgears worked with no lock and many other 3D applications. I powered off the laptop, turn it back on and damn, the desktop wasn't initialized, with a "_" in the corner. I heard the start-up sounds, everything, but no image. Suddenly, I heard the hard disk stopped, the computer was totally locked. I powered it off holding the power button 4 seconds. I reboot in failsafe mode, modified xorg.conf to add the "BusType" "PCI" and "DmaMode" "None" options, reboot and everything was fine, desktop back. However, still the same slow DRI performance as with Fedora.

But I was curious why it fully worked during one session? I searched a lot on google and I found this thread. I already tried all xorg.conf modifications solutions and with no success. However, someone (taylorjh) noticed a "cold" "warm" boot problem with it. I was curious about this because I remembered whent I used Fedora that I had such problems. I remembered I installed Fedora one night and get black screen after installation and after 2-3 reboot. I only powered it off and went to sleep. Next morning, I powered it on and, voilà, everything shows up and worked fine! I could edit xorg.conf to make the bus type PCI and everything else to make it worked with DRI but I never thought that it could be associated with the boot after a night sleep. Now, today, I decided to make a little experience with my Thinkpad T22. Here's all my steps and what happened (not to decrease battery life, I always run my laptop with no battery installed and only AC adaptor):

1- made a fresh openSUSE 10.3 install with KDE
2- first boot in KDE, added the Load "dri" line in xorg.conf
3- reboot, xorg is black screen, hear start-up sounds
4- powered off the laptop, unplugged everything, let it cool while I watched 4 Simpsons episodes :P
5- replug power, powered it on, desktop boot fine! run glxgears at 497 fps with no lock during 10 minutes, make a copy of Xorg.0.log and xorg.conf
6- safely shut down the laptop via KDE for 2 minutes
...

I made another experience which could give more clues (I kept the same xorg.conf file and always without battery installed):

1- shutdown, unplugged everything for 1 minute, plugged the AC
2- powered it on, xorg desktop boots fine, glxgears during 30 minutes and other 3D apps without lock
3- safely reboot via KDE
4- xorg desktop boots fine again, run glxgears during 30 minutes and other 3D apps without lock
5- safely shutdown via KDE for 1 minute
6- powered it on, xorg is only a black screen, hear start-up sound
7- pressing the laptop power button to safely shutdown, the laptop shutdown completely by itself
8- let the laptop cool for about 1 hour but WITH AC adaptor still CONNECTED!
9- all laptop seems at the room temperature
10- powered it on, strange, xorg desktop boots fine and run glxgears without lock
11- safely shutdown via KDE for 10 minutes
12- powered it on, xorg is only a black screen, hear start-up sound, seems not freezing

With this experience, we could think that there is an overheating problem or some persistence in a chipset memory (AGP, BIOS, video...) that is "cleaned" with time or with complete power down. Maybe I am completely wrong... or maybe not.

Bryce, I believe you can read out the bridge ID like this (from SAVAGEDRIAgpInit() in src/savage_dri.c)
 vendor = drmAgpVendorId( psav->drmFD );
 device = drmAgpDeviceId( psav->drmFD );

Hmmm, you are still trying to force the driver to use PCI if it is in combination with the T22 Intel AGP bridge? I thought someone could try to fix the source of the problem and try to get back AGP. Forcing the driver to be with PCI, that would be an ugly patch. Is there someone here who is trying to get deep in the AGP problem?

I'm not looking to get in deep with this driver; it sounded like incorporating the PCI enforcement would be quick and easy to do. Since it seems some are not in consensus with doing that, I'll cease my efforts. If someone else comes up with a better patch, I'd be happy to review/upload though.

Where is the consensus being questioned? AGP is often so broken on savage cards (especially if you use hibernation and sleep) so forcing all savage cards to PCI would be a good thing IMHO. Even better, it should default to PCI and let people experiment with AGP if they want and know how.

I have been fighting and reporting AGP trouble for like 4 years now (ever since DRI was available) and given the age of these cards and the developer interest I don't have high hopes for seeing it fixed. I would not be surprised if there's a hardware bug in them, also XP was unstable the short time I ran it on my laptop (with Savage TwisterK).

Tormod Volden wrote:
> Where is the consensus being questioned? AGP is often so broken on
> savage cards (especially if you use hibernation and sleep) so forcing
> all savage cards to PCI would be a good thing IMHO. Even better, it
> should default to PCI and let people experiment with AGP if they want
> and know how.
>
> I have been fighting and reporting AGP trouble for like 4 years now
> (ever since DRI was available) and given the age of these cards and the
> developer interest I don't have high hopes for seeing it fixed. I would
> not be surprised if there's a hardware bug in them, also XP was unstable
> the short time I ran it on my laptop (with Savage TwisterK).

I agree wit this approach. T20's are now at age where they are dying
natural deaths (mine already died) and there will never be more
produced. While it's too bad this doesn't work well, the number of
developers and users with these models will only continue to decline.

   Mark

Ok, I agree with you. This card is now too old to support. Maybe the PCI enforcement should be implemented then. However, like Tormod said, there should be an option to enable AGP and let some people test it.

Unassigning myself, I have no further plans to put effort into this driver (#98 points out the hw is long dead anyway).

Here's my final take at this patch. Last time only Tom Shaw tested my patch and it didn't work, so I'm probably wasting my time. If it happens that the patch works well and there's a stronger consensus favoring adding it let me know and I can upload it. Otherwise, maybe it'll give someone else some ideas for a better patch. Good luck everyone.

[Declining distro task; unassigning self]

I'm about to attempt an install of Intrepid on a Thinkpad T22 and a T23 for some friends, so I disagree with the "this card is now too old to support" statement. What are you doing of Linux's reputation of running on old computers better than Windows XP? Nothing indicates these computers are dying, and my friends may be using them for the next 5 years. Will there be 10 more versions of Ubuntu with this bug?

Also, what about the green "re-using" approach (and poorer countries)? It's easy to get a T22 (or replacement parts) on eBay for under 100$, there are about a thousand listings: http://shop.ebay.com/items/_W0QQ_nkwZthinkpadQ20t22QQ_armrsZ1QQ_fromZR40QQ_mdoZ
So why buy a newer and much more expensive laptop just for word processing and email??

In conclusion, since apparently we are so close to a fix (or a least an automatic workaround), I strongly suggest that this patch and all alternative solutions be reviewed and implemented in an update to Intrepid. For instance, in time for the inevitable 8.10.1.

non-LTS releases don't get point-releases.

Intrepid works just fine on my T23, and I don't remember seeing any problems with the T21/T22's sitting idle on my desk. But I'll test intrepid live.

actually, now that I thought about it a bit more, all of these laptops have a 1400x1050 screen, which means that when using 24bit depth DRI is not used, so that's why they are stable. If 16bit is used, 3D-progs tend to hang the machine.. I haven't tried forcing PCI, but I take your word on it and support the idea of forcing it by default.

I have three laptops of this vintage - a T21 and two T23s. All run Dapper, and are to be upgraded to 8.04 shortly. They all see daily use.

On Thu, 13 Nov 2008 06:56:35 -0000
"Gabriel M." <email address hidden> wrote:

> I'm about to attempt an install of Intrepid on a Thinkpad T22 and a T23
> for some friends, so I disagree with the "this card is now too old to
> support" statement. What are you doing of Linux's reputation of running
> on old computers better than Windows XP? Nothing indicates these
> computers are dying, and my friends may be using them for the next 5
> years. Will there be 10 more versions of Ubuntu with this bug?

Gabriel,

I expressed those sentiments because the laptops are gradually disappearing,
especially among developers with time and interest to volunteer to fix the bug.
I expect Ubuntu and the broader Linux community would welcome you to fix the bug
yourself or hire someone else to fix it for you.

Demanding that someone else volunteer to fix it is unlikely to help, especially
when the potential volunteers no longer have access to the laptops.

I love the ThinkPad series. I currently use a T23, my wife uses a T22 and a
friend clings to a T21, no run with an external screen because the monitor
died. Of course I'd like to see the support improved for them and extended as
well. I see it is a reality of the volunteer-driven lifecycle of open source
software. You are welcome to alter cycle with your own time or financial
resources.

    Mark

Bryce proposed a patch in April, but since none of you have bothered to test it, don't expect much to happen. When developers don't have access to the hardware, they are depending on the affected users' participation.

@Mark: If I was a Linux system programmer, I'd be already fixing the bug. If I had money to spare, I would probably have already donated a Thinkpad T22 to a developer or paid him to fix the bug (or bought my friend a new computer with a preinstalled OS, if I didn't care about the environment). But frankly it's rather insulting to get the canned answer "do it yourself or pay someone to do it or shut up": how does saying that to someone help moving things forward?

You should rather test the patch since you have two of the computers at home.

@ Tormod: What do we have to do to test the patch, anyways? It seems an earlier version was provided in .deb format, but I assume for this one we have to get the src deb, patch, then hopefully a debian command can auto-compile and package the whole thing? If you give simple instructions I can follow in 15min, I'll try and test it when I do my test installs on Saturday. But as much as I'd like to, I can't spend hours digging through wiki pages.

I'm concerned about the number of manual fixes that might be required to get Intrepid working on this T22. Will I be able to tell it's user to apply critical updates when they come up, or will I constantly fear that the updates overwrite my fixes?

I have a T20 which is still in use and going strong. I came accross this during a fresh install and have tried the patch out but there were 2 problems:

1. The VENDOR_ID/DEVICE_ID calls need to be compared against.. well.. the vendor & device IDs not the subsystem IDs

2. drmAgpVendorId and drmAgpDeviceId calls both return 0 because the AGP fd has not yet been initialised.

I was able to fix 1 easily, but I'm not sure whether there is a good way to get the Agp device details before it has been initialised.

I've attached an updated patch with the Agp bits commented out and IDs corrected. With these, it works for me but I guess it needs the Agp bridge test again to make sure it doesn't any working hardware.

Reopen bug now a fix can be committed

@Gabriel M:
> @ Tormod: What do we have to do to test the patch, anyways? It seems an earlier version was provided in .deb format, but I assume for this one we have to get the src deb, patch, then hopefully a debian command can auto-compile and package the whole thing? If you give simple instructions I can follow in 15min, I'll try and test it when I do my test installs on Saturday. But as much as I'd like to, I can't spend hours digging through wiki pages.

How to build a driver is summarized on https://wiki.ubuntu.com/XorgOnTheEdge . I appreciate you don't have time to read wiki pages, but I won't repeat here what I already wrote in the wiki page.

> I'm concerned about the number of manual fixes that might be required to get Intrepid working on this T22. Will I be able to tell it's user to apply critical updates when they come up, or will I constantly fear that the updates overwrite my fixes?

If you have customized your xorg.conf, it won't be overwritten by a package update.

@Chris:
Thanks for trying the patch. IMO we should just default to PCI for the savage driver, and let people enable AGP in their xorg.conf if they want.

I second the motion to default to PCI and allow people to switch to AGP if they want.

I just spent 3 evenings after work trying to get Ubuntu/Xubuntu installed onto my old T-20. Once I found this bug it only took 30 minutes to get Xorg working.

These old thinkpads are great, I got a replacement motherboard for 25$ to bring mine back to life. Before the motherboard died, I installed one of the older versions of Xubuntu, back when 6.x something was the current release. I wasn't expecting this much trouble because Ubuntu had worked in the past.

I just confirmed that this bug is present the default Intrepid. Here's a recipe to workaround it, as tested with a T22:

1. Install from the Alternate install CD (which avoids graphics issues)
2. On first boot, press "escape" as you briefly pass through the GRUB bootloader stage, and select "Recovery Mode". From there, select the "root shell" option.
3. Fix the xorg.conf file:

 # sudo nano /etc/X11/xorg.conf
 scroll down to the "Device" section and add this line:
   Option "BusType" "PCI"

Control-X to save the file, and then type "exit" at the shell prompt to return the recovery console menu. You should be able now select "resume" and have the issue solved for good. (as long as the xorg.conf file isn't changed)

I tried to use Mark's workaround on Jaunty Alpha 4 but it did not work.

Please add the "PCI bus as default" patch to the jaunty driver soon so we can test it.

I have uploaded a Jaunty package with a "BusType PCI by default" patch to my PPA https://launchpad.net/~tormodvolden/+archive/ppa

I forgot explicitly to ask you all to test this package. Unless we get some testing and feedback, nothing will be done.

I'll test this patch when I upgrade to jaunty (once the beta is out) but I certainly can't put alpha software on a machine I use so much. Thanks for putting the time in.

I would appreciate if you test with a live CD. Boot with the "text" kernel parameter so X will not be automatically started. Then log in and update the driver (having it downloaded to an accessible drive*, or 1) configure xorg.conf to use the vesa driver 2) start X using startx 3) download the driver and log out again 4) remove vesa from xorg.conf again) and run startx.

Once beta is out, it will be much more difficult to get changes like this pulled in.

*) If your "live CD" is a USB stick, the easiest is to copy the driver there, it will be accessible under /cdrom.

Ok, I had given up on this a week ago because nothing would get X not to lockup but then I discovered bug #319210 and realized it was something else causing the lockup.

Anyway, after I got the network up I updated the system and I tested with the savage snapshot package above, a default xorg.conf with no driver or special settings specified and X starts up just fine on my T20. It's defaulting to BusType PCI, PCI DMA and using a default depth of 16 so 3D is enabled and these are the expected best settings for this hardware.

Patch looks good here.

Tormod, thanks, uploaded.

Please make sure to forward this patch upstream so they're aware of it. I suspect this works around the problem for many, but may cause regressions for anyone for whom AGP does happen to work properly.

Perhaps what would be a better solution would be to implement a quirking system for those cases where AGP is failing (I did something similarly for -ati a while back). But upstream will know best how to handle it.

This bug was fixed in the package xserver-xorg-video-savage - 1:2.2.1-4ubuntu1

---------------
xserver-xorg-video-savage (1:2.2.1-4ubuntu1) jaunty; urgency=low

  * Add debian/patches/10_bustype_pci_by_default.diff:
    Use BusType PCI by default (LP: #33617, #37218)

 -- Tormod Volden <email address hidden> Wed, 18 Mar 2009 18:51:22 +0100

I already discussed this patch on #xorg-devel (although Alex did not respond). The responses ranged from "who are using savage cards nowadays" to "fix AGP yourself". I am not sure upstream would like to disable a feature they have invested in just for the sake of stability and usability. I will post it on the list anyway, if only for other distributions to cherry-pick.

For quirking, you already proposed some patches earlier in this report, but the response was not conclusive. Anyway, the "regression" in terms of performance is hardly detectable IMO, for those things you can do with this card.

I can add, I will make a quirk system if I get proof that anyone having DRI enabled and working can resume correctly with AGP (I haven't heard of any) and if they can measure a substantial performance drop going from AGP to PCI :)

The bug has re-appeared on Karmic.

The package got synced with Debian and we lost debian/patches/10_bustype_pci_by_default.diff.

When can we expect it to be fixed in the Karmic development series?

I filed bug #429700 for a Karmic update.

This bug was fixed in the package xserver-xorg-video-savage - 1:2.3.0-1ubuntu1

---------------
xserver-xorg-video-savage (1:2.3.0-1ubuntu1) karmic; urgency=low

  [ Tormod Volden ]
  * Merge with Debian, remaining changes:
    - 10_bustype_pci_by_default.diff (LP: #33617, #37218)

 -- Timo Aaltonen <email address hidden> Mon, 21 Sep 2009 23:50:16 +0300