The score so far with T-23, X-31 and lenovo G570 with 12.3 RC1

12.3 RC1 Live disk, 32 bit version

Well, the T-23 Think Pad with P III 1.2 GHZ W/1 GB ram, is a definite NO GO… The video driver is corrupted or non existent for the Savage 9 SIS chipset so you cannot set up an install or run a live disk. Text install fails also.

X-31 Think Pad w/1.4 ghz Pentium M, 2 gb ram and ati video chipset, installed and looked ok and then the menu bar vanished. After that other things acted strange and I had to wipe the drive to start over. Not looking good so far, maybe the final release will work.

lenovo g570 with i3 cpu, 8 gb ram and intel video chipset looks fine and sets up a running live disk and surfs with network manager with little effort.

So, for me, the SCORE is 1 out of 3 work well with 12.3 RC1, so far.

Anyone else have a t-23 or x-31 and having trouble?

cheers

It is nice you want to share the results of your 12.3 testing, But this is the wrong place to do so. As long as 12.3 is not released, you should discuss it in the Pre-Release/Beta forum.

I will move this there and it is closed for the momet.

Moved from Laptop and open again.

I note other distros have had problems with the T-23. For example: Kernel hangs on IBM Thinkpad T23 … I can not recall the liveCD options, but see if you can try with acpi disabled (and maybe noapic as well). I also can’t recall - is there a VESA selection in the liveCD ? Does booting with the ‘nomodest’ boot code help ? There may be a ‘nokms’ kernel option.

I note other distros have had problems with the X-31. For example the arch wiki gives some hints: ArchWiki:Archive - ArchWiki (and note they use a pretty old kernel with arch linux). If you can, try these boot codes:


nomodeset acpi_sleep=nonvs 

There may be a nokms kernel option in the liveCD boot menu ?

If that works, but the driver you get with nomodeset is undesireable, you could boot with ‘nomodeset’ and then specify your desired driver in /etc/X11/xorg.conf.d/50-devices.conf file (but that edit suggestion is only for an installed 12.3RC1 and not for a liveCD boot).

A major qualification to the above - I do not own this hardware.

The T-23 and the X-31 both work great with 12.2. I am wondering what was left out of the new release, especially for the T-23 with the SAVAGE Super 9 video chip set. I have had similar trouble with Mageia 3 beta for the T-23 so I am wondering if the video chips have been left behind. I tried VESA and text only installs. The install stalled after it got to the point that it was trying to start the x-11 driver and then just sat there with the small cursor dot blinking. I tried multiple times and it fails in the same place.

The X-31 installed fine but the anomalies that started after a bit of time with the menu bar going away after about 15 seconds made me erase the install. I have had no trouble with either laptop in the past with either Mandriva, Mageia, SUSE or Kubuntu installs. I tried Fedora 18 this time as well but the less said about that the better. (Very negative experience…)

I know many people still use a T-23 or X-31 because they sold a lot of them and they are tough so a lot of them will still be out there, I believe. I am hoping it will sort out after a bit of time.

cheers

Did you try nokms at the same time as trying the text/vesa modes ?

I am trying to visualize that location where you noted you had the problem. Is that after the 1st installation reboot (and after grub or grub2 has been installed ) ?

If so, did you try at that point (by rebooting) to type ‘nomodeset’ (if you selected the legacy grub boot manager) or press “E” (if using the grub2 boot manager) and then edit the appropriate boot line in grub2 by adding ‘nomodeset’ (no quotes) to see if that works ?

Does this happen using either the vesa or the fbdev graphic driver , or only with the radeon graphic driver ? Did you try nomodeset at the same time as trying those drivers ?

The X-31 install was whatever video driver the software would have chosen by default. I did not choose any special settings with that install. When the menu bar went away I was having trouble getting anything to open up as I wished and frustration with the problem lead to wiping the drive.

As for the T-23 it is not installed at the point of issue, it is trying to boot the LIVE DISK and fails. I always shut off the Plymouth boot screen by pressing ESC and watching the lines of code or commands go by. It is about halfway to getting a working desktop when it stops. I will boot it now as I am typing this with another laptop and tell you what the line says at the point of failure.

The final line before it stalls says REACHED TARGET GRAPHICAL INTERFACE and then it just sits there…

cheers

… please pardon me if I tell you something you already know, but given what I have read above it is not clear to me the rationale behind my recommendation is clear to you.

My understanding is the loading of the ‘default’ graphic drivers (to use your wording ‘default’ ) is initially controlled by the kernel using ‘kernel mode setting’ , also known as KMS. if one when booting the liveCD, or the DVD, goes to one of the menu items (I think it to be ‘kernel’ but I may have that wrong) and chose ‘nokms’ one is telling the kernel NOT to automatically try and chose the graphic driver. Typically that results in either the ‘vesa’ or ‘fbdev’ driver being run, instead of the ‘radeon’ driver (where I think your X-31 has AMD/ATI graphic hardware).

Now if this was a partial install (without grub but with the X config files in place) and this openSUSE GNU/Linux install on this PC no longer boots because the boot manager install did not complete, but if a liveCD boots, then you can always boot to the liveCD, and edit the /etc/X11/xorg.conf.d/50-device.conf file and remove selected comments and add entries to have it load the vesa driver. Then if you reboot the PC without the liveCD and if you chose the ‘nokms’ option you should be able to test booting specifically to that driver (specified in the 50-device.conf file). If your boot manager did install, then the idea is to add the ‘nomodeset’ kernel cheat code to the grub menu, or to the grub2 menu, which means different action dependant on what boot manager is in place. I gave guidance above as to how this can be done with the grub2 boot manager.

The idea is to test booting and force openSUSE GNU/Linux to boot to a specific fall back graphic mode.

ok, what I am saying is BEFORE the Plymouth boot screen (with the scrolling text behind it) shows up, but as soon as the boot selection menu shows up (which is earlier) in the ‘kernel’ option (I believe) choose ‘nokms’. Also with ‘nokms’ selected you can also chose the ‘text’ install or a ‘lower’ resolution and see if you can then force a different graphic driver and force different graphical settings, and not have it chosen by Kernel Mode Setting (KMS).

The above is no magic solution of course. I have tested 5 very different PCs with 12.3 RC1, and while 4 worked nicely, one with nvida FX5200 graphic hardware (NV34) did not work well. On the PC that did NOT work well, after comparing the symptoms with earlier openSUSE versions (that did work) and with Tumbleweed (which could be made to work or fail) and with other GNU/Linux distributions with the last 3.6.11 kernel and the latest 3.7.x kernels, I managed to deduce to my satisfaction that the nouveau graphic driver in the lastest kernel broke the nouveau driver for that specific NV34 hardware. I was able to boot a liveCD (and a desktop install) on the PC with the broken driver by using the techniques I noted above. I also then wrote a bug report on openSUSE-12.3 and also upstream on the 3.7.x kernel’s nouveau driver on the NV34 problem.

Thanks, that was not clear to me. I had the impression that you reached the language selection, and desktop selection, and geography selection … etc menu, and that the install had started, and that it was later during the install process that the problem occured.

Hi,

T-23
I tried no kms option with safe settings and it loaded most of the install kernel and then did a kernel panic and locked up the laptop. I think I am not going to get around this. I then tried text with safe settings and had a similar result.

Thanks anyway.

cheers
zxr250cc

It does read like the ‘savage’ graphic hardware on that T-23 may no longer be supported. Have you written a bug report on your experiences ?

Still, another credible possibility worth checking -> what is the CD/DVD writer (where the boot CD was burned) age difference compared to the CD/DVD reader on your T-23 ? If one is looking at more than 3 to 4 years difference in age (and that is a very rough inaccurate rule of thumb), then there could be a simple calibration difference between drives that is causing the T-23 to misread the CD resulting in a kernel-panic. In which case to confirm that is not the cause, try booting to an external CD/DVD drive on same T-23.

No I didn’t and I guess I should post a bug report for the T-23. It would be a shame to stop using that old but reliable laptop. It has XP pro on it as well and I intended to keep using it with Linux only when XP support service ends next year.

I used an external DVD-RW USB drive to burn the disk and then used it to try to do the install. I had noted errors previously with the internal dvd/cd-rw drive when trying to use the live disk so I used the external drive. It loads slower than the internal drive but it reads the disk properly. I am using that drive now to install RC1 on the X-31.

I loaded RC1 LIVE DISK on the X-31 this morning, turned off all desktop effects and then got it to work as a stable live desktop. I am doing an install now and will see how that goes. I wiped Mandriva 2011 to do the install. I never liked the graphic effects that the ROSA folks added to that anyway. What forum in here would be good to talk about desktop graphics and overall visual design? I ask that since I really am not liking the stark, black look in this release… I did like the look of 12.2 though.

Applications: https://forums.opensuse.org/english/get-technical-help-here/applications/ ONLY after openSUSE-12.3 is released. 12.3 has NOT been released yet.

The install for the T-23 was with an external DVD writer that was used to burn the disk. It is a USB drive and works well. I noticed errors when trying to use the internal DVD CDRW drive so I connected the USB drive for the install.

I tried to install on the X-31 and IT FAILED. I arrive at an emergency command line and it mentions systemctl reboot or -b or default commands to try. I wiped Mandriva 2011 to try to do that install. I guess I will reinstall 12.2 and see what comes along for the T-23 and the X-31 in the next little period of time. oh, well…

cheers

I’ll install 12.3 RC1 on my T23, 2647-8MU. It currently multi-boots Windows XP, Windows 98SE, and openSuSE 12.2. I’ll install 12.3 RC1 replacing 12.2, keeping the /home partition.

T23s have only USB 1.1 ports. Loading the install kernel takes about 10 minutes on that. I have a PCMCIA card with USB 2.0 ports that works well once an operating system has loaded drivers. BIOS does not see a USB stick in the PCMCIA card as an option to boot.

Does anyone know how to get a boot started that will load the PCMCIA card drivers, but then start the 12.3 RC1 installation from the flash drive in the card? The full install DVD is on the flash drive.

Thanks,
Howard

I installed 12.3 RC1 on my T-23 with a USB flash drive in the 1.1 port. (I tried to get PLOP boot manager working with PCMCIA, but was unsuccessful.) The first part of the install went normally. When it did the first reboot, it could not start the graphics, so did the rest of the install in the text-based mode. That completed OK, including on-line update to kernel 3.7.7-1.2-default.

With the installation finished, doing a normal boot stops at the same point zxr250cc saw:

Reached target Graphical Interface

It does boot into the advanced option recovery mode. This seems to give decent graphics, but slower than 12.2 ran on this machine. In that mode, the Yast hardware info for the display is:

24: PCI(AGP) 100.0: 0300 VGA compatible controller (VGA)
  [Created at pci.319]
  Unique ID: VCu0.jjzIPZ_Zra1
  Parent ID: vSkL.7ikikoAJ7O0
  SysFS ID: /devices/pci0000:00/0000:00:01.0/0000:01:00.0
  SysFS BusID: 0000:01:00.0
  Hardware Class: graphics card
  Model: "IBM ThinkPad T23"
  Vendor: pci 0x5333 "S3 Inc."
  Device: pci 0x8c2e "SuperSavage/IXC 64 SDR"
  SubVendor: pci 0x1014 "IBM"
  SubDevice: pci 0x01fc "ThinkPad T23"
  Revision: 0x05
  Memory Range: 0xc0100000-0xc017ffff (rw,non-prefetchable)
  Memory Range: 0xe8000000-0xebffffff (ro,non-prefetchable)
  Memory Range: 0xe4000000-0xe7ffffff (ro,non-prefetchable)
  Memory Range: 0xe0000000-0xe1ffffff (ro,non-prefetchable)
  Memory Range: 0xe2000000-0xe200ffff (ro,non-prefetchable,disabled)
  IRQ: 11 (1355 events)
  I/O Ports: 0x3c0-0x3df (rw)
  Module Alias: "pci:v00005333d00008C2Esv00001014sd000001FCbc03sc00i00"
  Driver Info #0:
    XFree86 v4 Server Module: savage
  Config Status: cfg=no, avail=yes, need=no, active=unknown
  Attached to: #15 (PCI bridge)

The video driver “xf86-video-savage” is installed.

Any idea why the normal boot is not working?
Thanks,
Howard

There is a workaround for the T23 display trouble at Mark Alford’s Fedora 17 GNU/Linux on an IBM Thinkpad T23

I did it on my T23 with 12.3 RC1, and normal boot now works.

Cheers,
Howard

The recovery mode likely is booting to either the vesa driver, or to the fbdev driver. In addition to ‘nomodeset’, it likely also has a parameter in its boot settings called ‘x11failsafe’ which is intended to force booting to a limited driver (probably the fbdev (basic frame buffer) graphic driver). The fbdev driver is typically compatible with all graphic devices, but as you pointed out its performance is slow.

I took a look at the factory xf86-video-savage-2.3.6-3.1.i586.rpm, and noted this in the change log:


oldcpu@corei7:~/temp> rpm -qp xf86-video-savage-2.3.6-3.1.i586.rpm --changelog
* Sun Sep 02 2012 zaitor@opensuse.org                                                                                                                  
- Update to version 2.3.6:
  + Make build with no xaa server.                                                                                                                     
- Changes since version 2.3.5:
  + i2c drop xf86Screens usage.                                                                                                                       
  + Port to new compat API                                                                                                                            
  + Refactor BIOS modes retrieval to call VBEGetVBEInfo only once.
    Otherwise, calling it twice would trigger a VBE bug when using
    xserver 1.12.

* Fri Jun 01 2012 sndirsch@suse.com
- remove hw supplements (bnc#764395)

* Wed May 23 2012 crrodriguez@opensuse.org
- Add proper "Supplements" so the driver is picked up by
  the package manager when the user has the proper hardware.

and I then looked at the change log for the openSUSE-12.2 xf86-video-savage-2.3.4-4.1.2.i586.rpm


oldcpu@corei7:~/temp> rpm -qp xf86-video-savage-2.3.4-4.1.2.i586.rpm --changelog
* Fri Jun 01 2012 sndirsch@suse.com
- remove hw supplements (bnc#764395)

* Wed May 23 2012 crrodriguez@opensuse.org
- Add proper "Supplements" so the driver is picked up by
  the package manager when the user has the proper hardware.

So factory has a Sun Sep 02 2012 update that openSUSE-12.2 does not have.

So if we assume that openSUSE-12.2 works with this hardware (and I do not know that as I do not have the hardware - someone with the hardware will need to confirm that) then that suggests that the 02-Sep-2012 update broke the driver.

I think a bug report is requried, but I also suspect that information on why the boot failed is needed for the bug report. There may be some information in the failed ‘Xorg.0.log’ file.

What you could do is boot normally. That will fail, but if it progresses far enough in the boot process, it will write the contents to a file called /var/log/Xorg.0.log.

So then reboot with the safe settings (which you called ‘recovery mode’ I assume). That will do 2 things (amongst many other things). It will rename the existing Xorg.0.log to Xorg.0.log.old. And it will create a new Xorg.0.log.

If there appears useful in the Xorg.0.log file, then attach the contents of the Xorg.0.log.old file to your bug report.

You could also copy the contents of the failed Xorg.0.log file to SUSE Paste , press create, and post here the web site URL, and some of our graphic gurus could take a look at it. But it may (or may not) yield sufficient information to help.

Good news.

It still may be worth while writing a bug report and pointing to the Mark Alford link as a work around. I don’t know, but its possible that information could then be used by SuSE-GmbH.

For zxr250cc, I think that means, if you can boot with safe settings, and then assuming you do not have an /etc/X11/xorg.conf file to edit, you could instead edit (with root permissions) the /etc/X11/xorg.conf.d/50-device.conf file, so that it reads something like:


Section "Device"
  Identifier "Default Device"

  Driver "savage"
  Option "DisableTile" 
EndSection

then reboot normally and hopefully that will work.

oldcpu,
You’re right on the edit to /etc/X11/xorg.conf.d/50-device.conf file. I moved the /etc/X11/xorg.conf file, and edited the 50-device.conf file as you wrote. Normal booting works. Thanks.

In the midst of the changes, I did a normal boot that stopped at the “Reached target Graphical Interface” point, then booted to recovery mode and copied the Xorg.0.log.old file to another partition. I’ll write a bug report including it. Should that be to openSuSE or Xorg, or both?

Regards,
Howard

Possibly both.

For example the 3.7.x kernel has a large change to the noveau open source graphic driver for nvidia hardware, which while superior for many nvidia devices, results in corruption for the old NV34 (nvidia FX5200) graphics hardware. Researching this I noted this bug impacted a number of other GNU/Linux distributions and not just openSUSE. Going to the nouvea driver web site for bugs I read

[quote="nouveau.freedesktop.org
"]
If you are using packages from your distribution, send the bug reports to your distribution and not directly to us.

[/quote]

So in the end I wrote:

I note for both radeon (DRI Wiki - Radeon and X.Org Wiki - radeon ) and savage ( DRI Wiki - S3Savage ) hardware sites that the freedesktop is likely an ok place to raise a bug report on those drivers. I did note other bugs written on the savage hardware in the freedesktop bug tracking tool.