stuck with VESA & 1024x768 or worse on Sony VAIO with G86M [GeForce 8400M GT] (rev a1)

mrmazda · 09-11-2019, 12:26 AM

https://mobilespecs.net/laptop/Sony/...GN-AR730E.html seems to describe this non-Optimus laptop.

https://www.sony.com/electronics/sup...ies/vgn-ar730e seems to be the appropriate Sony support page, but I don't see any downloadable BIOS (original or update), or specifications there.

http://fm.no-ip.com/Tmp/Linux/Xorg/Nv/ is where I've been collecting Xorg logs, journals, lsmod, xrandr, inxi, and anything else trying to figure this thing out over the past three days. The filenames are chosen to try to make evident their content, such as kernel cmdline parameters tried, or OS from which generated.

Operating systems exhibiting similar/same trouble are openSUSE Tumbleweed, 15.1, 15.0; Knoppix 8.2 & 8.6, Linuxmint 19.0 and possibly Debian Buster. Newest kernel is TW's 5.2.11, oldest Knoppix's 4.15 and 15.0's 4.12 backported equivalent supposedly to 4.19.

Most obvious clue seems to be that 'hwinfo --monitor' produces null output whether or not KMS is enabled and neither external HDMI port nor external VGA port are connected, though hwinfo apparently works for the rest of the hardware. Video is normal when VESA is used in tty framebuffers or VESA or FBDEV are used in Xorg. Maximum resolution is 1024x768 in either X or ttys. To me this suggests absent required firmware, but I'm having no luck finding any relevant to NVidia that is not already present.

KMS kick-in point triggers black screen on ttys if vga= or video= are included on cmdline, even when video= attempts to enable or disable any of the crtcs. With the
older kernels, video= parameters scramble video output on the X screen unless nomodeset is also used.

These are some other errors that as yet have produced no fruit from web searches:

Code:

vaio kernel: pci 0000:01:00.0: BAR 6: no space for [mem size 0x00020000 pref]
vaio kernel: platform regulatory.0: Direct firmware load for regulatory.db failed with error -2
[    56.460] (EE) [drm] Failed to open DRM device for pci:0000:01:00.0: -19
[    56.460] (EE) open /dev/dri/card0: No such file or directory
[    56.461] (EE) Unable to find a valid framebuffer device
[    56.461] (EE) open /dev/fb0: No such file or directory

All suggestions other than discarding laptop or installing proprietary software welcome.

business_kid · 09-11-2019, 02:57 PM

Let's start with the obvious. From compiling kernels, I know that some tweaks are in there purely to accommodate the Sony Vaio's issues. From the 'Vista' originally supplied, I'm reckoning 2007/8? I would reinstall your favourite distro & fix it - preferably one that isn't a total bitch to fix. I would also stop feeding X any clue & let it sort itself out.

I don't know if you have your libraries in /usr/lib, or /usr/lib64. Try this

Code:

ls -l /usr/lib(64)/libGL*

Look at the version numbers. Here's my output

Code:

bash-5.0$ ls -l /usr/lib64/libGL*
lrwxrwxrwx 1 root root     14 Jul 24 12:30 /usr/lib64/libGL.so -> libGL.so.1.7.0
lrwxrwxrwx 1 root root     14 Jul 24 12:30 /usr/lib64/libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 root root 616704 Jun 22 20:37 /usr/lib64/libGL.so.1.7.0
lrwxrwxrwx 1 root root     21 Jul 24 12:30 /usr/lib64/libGLESv1_CM.so -> libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root     21 Jul 24 12:30 /usr/lib64/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0
-rwxr-xr-x 1 root root  47352 Jun 22 20:37 /usr/lib64/libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1 root root     18 Jul 24 12:30 /usr/lib64/libGLESv2.so -> libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root     18 Jul 24 12:30 /usr/lib64/libGLESv2.so.2 -> libGLESv2.so.2.1.0
-rwxr-xr-x 1 root root  80120 Jun 22 20:37 /usr/lib64/libGLESv2.so.2.1.0
lrwxrwxrwx 1 root root     16 Jan  1  2019 /usr/lib64/libGLEW.so -> libGLEW.so.2.1.0
lrwxrwxrwx 1 root root     16 Jan  1  2019 /usr/lib64/libGLEW.so.2.1 -> libGLEW.so.2.1.0
-rwxr-xr-x 1 root root 686056 Apr 13  2018 /usr/lib64/libGLEW.so.2.1.0
lrwxrwxrwx 1 root root     15 Jan  1  2019 /usr/lib64/libGLU.so -> libGLU.so.1.3.1
lrwxrwxrwx 1 root root     15 Jan  1  2019 /usr/lib64/libGLU.so.1 -> libGLU.so.1.3.1
-rwxr-xr-x 1 root root 510608 Apr 17  2018 /usr/lib64/libGLU.so.1.3.1
lrwxrwxrwx 1 root root     15 Jul 24 12:30 /usr/lib64/libGLX.so -> libGLX.so.0.0.0
lrwxrwxrwx 1 root root     15 Jul 24 12:30 /usr/lib64/libGLX.so.0 -> libGLX.so.0.0.0
-rwxr-xr-x 1 root root  72160 Jun 22 20:37 /usr/lib64/libGLX.so.0.0.0
lrwxrwxrwx 1 root root     16 Aug  2 18:14 /usr/lib64/libGLX_mesa.so -> libGLX_mesa.so.0
lrwxrwxrwx 1 root root     20 Aug  2 18:14 /usr/lib64/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rwxr-xr-x 1 root root 467760 Jul 10 05:28 /usr/lib64/libGLX_mesa.so.0.0.0
lrwxrwxrwx 1 root root     22 Jul 24 12:30 /usr/lib64/libGLdispatch.so -> libGLdispatch.so.0.0.0
lrwxrwxrwx 1 root root     22 Jul 24 12:30 /usr/lib64/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
-rwxr-xr-x 1 root root 633216 Jun 22 20:37 /usr/lib64/libGLdispatch.so.0.0.0

That's the o/p from Mesa libs. So libGL.so is a sumlink pointg at libGL.so.1.7.0. Those numbers change when you install nvidia drivers to the nvidia driver version. It's probably the nvidia-legacy you want.

For the memory assigned error, are we 32 bit or 64 bit? probably a silly question. I just don't know the cpu.

On the firmware error you posted, there was a kernel cleanout in 2015 that dumped 'all that old sh** that nobody uses any more.' I was using some of 'that old sh**,' and I gather you are too. Slackware's kernel firmware package still has it. There must be other ways to get it but I imagine that's your problem. Error 2 is a 'file not found' error.

You do not want framebuffer, vesa, or any of that crap. You want either

Nvidia Proprietary drivers
Nvidia 'nouveau' or other open source drivers.

The proprietary drivers have to be endured to get the best performance. You cannot install both, and they both hate the sight of each other (nvidia blacklists nouveau).

Lastly, from the /dev/dri/card0, I'm gathering that X saw no suitable drivers. The definitive file is /var/log/Xorg.0.log, unless your distro has hidden it somewhere. It's the record of your last boot to view with less or more. That lets you see what X was thinking. Use ctrl_alt_F2 and sign in to have a look even with X crashed.

mrmazda · 09-12-2019, 12:28 AM

Quote:

Originally Posted by business_kid

I would reinstall your favourite distro & fix it

Reinstalling an OS is what Windows users do, not me or other experienced FOSS users.

Quote:

I would also stop feeding X any clue & let it sort itself out.

I've already resolved in my mind it isn't X that's the problem, since vtty framebuffer, absent nomodeset, is just as fubar.

Quote:

I don't know if you have your libraries in /usr/lib, or /usr/lib64. Try this [CODE]ls -l /usr/lib(64)/libGL*/[code]Look at the version numbers.

More X?

You have more than I do, but the versions look the same. What your extras mean I have no idea, unless you have proprietary driver packages installed that put them there. This is from openSUSE Tumbleweed 20190907 with kernel 5.2.11:

Code:

# ls -Ggh /usr/lib/libG*
lrwxrwxrwx 1   14 Jul  9 07:38 /usr/lib/libGL.so.1 -> libGL.so.1.7.0
-rwxr-xr-x 1 418K Jul  9 07:38 /usr/lib/libGL.so.1.7.0
lrwxrwxrwx 1   21 Jul  9 07:38 /usr/lib/libGLESv1_CM.so.1 -> libGLESv1_CM.so.1.2.0
-rwxr-xr-x 1  34K Jul  9 07:38 /usr/lib/libGLESv1_CM.so.1.2.0
lrwxrwxrwx 1   18 Jul  9 07:38 /usr/lib/libGLESv2.so.2 -> libGLESv2.so.2.1.0
-rwxr-xr-x 1  58K Jul  9 07:38 /usr/lib/libGLESv2.so.2.1.0
lrwxrwxrwx 1   15 Jul  9 07:38 /usr/lib/libGLX.so.0 -> libGLX.so.0.0.0
-rwxr-xr-x 1  70K Jul  9 07:38 /usr/lib/libGLX.so.0.0.0
lrwxrwxrwx 1   16 Aug 26 08:00 /usr/lib/libGLX_indirect.so.0 -> libGLX_mesa.so.0
lrwxrwxrwx 1   16 Aug 26 08:00 /usr/lib/libGLX_mesa.so -> libGLX_mesa.so.0
lrwxrwxrwx 1   20 Aug 26 08:00 /usr/lib/libGLX_mesa.so.0 -> libGLX_mesa.so.0.0.0
-rwxr-xr-x 1 471K Aug 26 08:00 /usr/lib/libGLX_mesa.so.0.0.0
lrwxrwxrwx 1   22 Jul  9 07:38 /usr/lib/libGLdispatch.so.0 -> libGLdispatch.so.0.0.0
-rwxr-xr-x 1 314K Jul  9 07:38 /usr/lib/libGLdispatch.so.0.0.0

A different look:

Code:

# zypse libgl | grep -v 32bit
  | Mesa-libGLESv1_CM1        | package | 19.1.5-227.1 | x86_64 | OSS
  | Mesa-libGLESv2-2          | package | 19.1.5-227.1 | x86_64 | OSS
  | libGLC0                   | package | 0.7.2-2.13   | x86_64 | OSS
  | libGLw1                   | package | 8.0.0-4.6    | x86_64 | OSS
  | libGLwM1                  | package | 8.0.0-4.6    | x86_64 | OSS
  | libgl2ps1                 | package | 1.4.0-2.6    | x86_64 | OSS
  | libgladeui-2-6            | package | 3.22.1-1.8   | x86_64 | OSS
  | libgle3                   | package | 3.1.0-152.13 | x86_64 | OSS
  | libglfw2                  | package | 2.7.6-1.14   | x86_64 | OSS
  | libglfw3                  | package | 3.3-1.2      | x86_64 | OSS
  | libglibmm-2_60-1          | package | 2.59.1-1.5   | x86_64 | OSS
  | libglog0                  | package | 0.3.5-1.8    | x86_64 | OSS
  | libglom-1_32-0            | package | 1.31.6-4.9   | x86_64 | OSS
  | libgloox17                | package | 1.0.21-1.5   | x86_64 | OSS
  | libglpk40                 | package | 4.65-2.5     | x86_64 | OSS
  | libgltf-0_1-1             | package | 0.1.0-2.8    | x86_64 | OSS
  | libglue2                  | package | 1.0.12+v1    | x86_64 | OSS
  | libglusterfs0             | package | 5.5-2.4      | x86_64 | OSS
  | libglut3                  | package | 3.0.0-1.14   | x86_64 | OSS
  | libglyr1                  | package | 1.0.10-2.11  | x86_64 | OSS
i | Mesa-libGL1               | package | 19.1.5-227.1 | x86_64 | OSS
i | Mesa-libglapi0            | package | 19.1.5-227.1 | x86_64 | OSS
i | libGLEW2_1                | package | 2.1.0-1.7    | x86_64 | OSS
i | libGLU1                   | package | 9.0.1-1.1    | x86_64 | OSS
i | libglade-2_0-0            | package | 2.6.4-25.6   | x86_64 | OSS
i | libglib-2_0-0             | package | 2.60.6-1.1   | x86_64 | OSS
i | libglibmm-2_4-1           | package | 2.60.0-1.4   | x86_64 | OSS
i | libglslang-suse6          | package | 7.12.3352-1.1| x86_64 | OSS
i | libglvnd                  | package | 1.1.1-1.4    | x86_64 | OSS

Quote:

It's probably the nvidia-legacy you want.

Definitely not.

Quote:

For the memory assigned error, are we 32 bit or 64 bit? probably a silly question. I just don't know the cpu.

It's in the Xorg logs at the URL provided (64).

Quote:

On the firmware error you posted, there was a kernel cleanout in 2015 that dumped 'all that old sh** that nobody uses any more.' I was using some of 'that old sh**,' and I gather you are too. Slackware's kernel firmware package still has it. There must be other ways to get it but I imagine that's your problem. Error 2 is a 'file not found' error.

The actual problem is I'm trying to find out whether there is a hardware failure before trying to fix Windows on someone else's laptop. The SSD with 4 installed operating systems in this laptop now is mine, installed only for troubleshooting the hardware. That said, I have downloaded AntiX, in case I get ambitious enough to check on that dumped sh**.

Quote:

You do not want framebuffer, vesa, or any of that crap. You want either
Nvidia Proprietary drivers

Definitely not I.

Quote:

Nvidia 'nouveau' or other open source drivers.

Preferably the newer modesetting DDX, which is what works for all my own PCIe NVidia graphics cards. The reverse engineered nouveau DDX is ancient technology that is perpetually behind.

Quote:

The proprietary drivers have to be endured to get the best performance.

FOSS or nothing for me, but then this is not my PC.

Quote:

You cannot install both, and they both hate the sight of each other (nvidia blacklists nouveau).

You got that right, though I'm not sure in the latest tainting driver versions that the nouveau kernel driver necessarily must be blacklisted. Since I never use proprietary graphics drivers with Linux, I have only second hand experience with their foibles. I think only printers cause more trouble for Linux users than NVidia graphics (especially including Optimus).

Quote:

Lastly, from the /dev/dri/card0, I'm gathering that X saw no suitable drivers. The definitive file is /var/log/Xorg.0.log, unless your distro has hidden it somewhere. It's the record of your last boot to view with less or more. That lets you see what X was thinking.

There are currently 5 for your perusal on the URL provided. The newer ones are from boots including cmdline options required by Intel's instructions for video bug reporting.

Quote:

Use ctrl_alt_F2 and sign in to have a look even with X crashed.

The vttys don't work except in a half-scrambled 80x25 mode, or in a vesa 1024x768 mode after having booting using nomodest. I'm sure if I could get them to work with KMS the X problem would be solved as well. $TOPIC was not meant to suggest this is an X-only problem.

I appreciate your reply more than my responses might suggest. It's gotten me thinking outside the box more. Since the original owner's Windows trouble was different than what it morphed into after using CHKDSK on the NTFS partition, I'm leaning on Windows driver corruption and need to reinstall it. The trouble with that is Sony does not have a discoverable download link for the driver listed on its download page, nor does it have any download link for any BIOS version, even the original, which could have been corrupted by the overheating trouble I've apparently solved. I tried calling Sony's support number to discuss the bad downloads page, but its answering machine refers to another number that provides limited hours of operation that don't match Sony's website.

BTW, another inexplicable, from lsmod booted to openSUSE 13.1:

Code:

video                  18755  2 nouveau,i915

This is not supposed to be an Optimus laptop.

business_kid · 09-12-2019, 05:18 AM

It's not often I say this, but I'm not going to answer that.

You're clearly up a cul-de-sac, I offer practical help, only to find that you bite. Draw on your vast experience, read your own logs and sort yourself out.

mrmazda · 09-12-2019, 12:28 PM

FWIW, I installed AntiX last night on the remaining empty SSD partition. I tried booting AntiX only once before bed. It never finished trying, with very little of the 80x25 screen output usable. Just now, attempt #2 in over three minutes reported eth1 is up but little else legible and no login prompts anywhere, ending with "...neuwosking: 124;!kimm: Oo suci!process!" "CAD hung at "Applying power save settings..." Power switch worked. Next try using nomodset produced a GUI login screen on which both root and ordinary users' attempts to login are rejected with explanation "Failed to execute login command". Login on tty3 works, and viewing Xorg.0.log on 80x25 displays "...WESA)1)...1135x779.!)qiuci!1135)!" Xorg.0.log is at http://fm.no-ip.com/Tmp/Linux/Xorg/N...ix-3-nomodeset and dmesg http://fm.no-ip.com/Tmp/Linux/Xorg/N...sg-antix-1.txt. journalctl produces "-casi; jousoalcul:!commaoe nou found". Inxi -Gxxbaz output is at http://fm.no-ip.com/Tmp/Linux/Xorg/Nv/sd-inxi-antix.txt. startx -- :1 works, and:

Code:

# xrandr
xrandr: Failed to get size of gamma for output default
Screen 0: minimum 1024 x 768, current 1024 x 768, maximum 1024 x 768
default connected 1024x768+0+0 0mm x 0mm
   1024x768       76.00*

as expected from nomodeset. Another boot try, this time without nomodeset but with vga=791, stops screen output at "fb: switching to nouveaufb from VESA VGA", and kills keyboard. Another try adding module_blacklist=nouveaufb hangs at: "Disabling lock debugging due to kernel taint", half a screen after "fb: switching to nouveaufb from VESA VGA". The taint appears to be wl-related. There is no wireless here to use. Blacklisting also wl again hangs screen at "fb: switching to nouveaufb from VESA VGA".

Moved my SSD back to an Intel Eagle Lake PC, and its Intel video automagically works normally. Moved SSD to a Bearlake motherboard with PCIe GeForce 210 (GT218), and its video automagically works normally. Tried a HD with Mandriva 2008.1, which is pre-KMS, and boots to a normal vga=791, but X could take some time to figure out when time is available....

mrmazda · 09-14-2019, 10:52 AM

acpi=off stops the hangs, but doesn't help getting nouveau anywhere into lsmod output. None of acpi_backlight=[vendor,video,none,sony_acpi] have any effect either. modprobe nouveau returns no such device. modprobe nouveaufb returns not found in directory /lib/modules/....

mrmazda · 09-15-2019, 04:32 AM

I filed a kernel bug: https://bugzilla.kernel.org/show_bug.cgi?id=204851

mrmazda · 10-07-2019, 11:51 PM

Apparently this laptop has a 1440x900 display and no hardware issues. I changed SSDs, did a standard Windows 7 installation, and was able when complete to reboot and change display mode from 800x600 default to 1440x900 with no issues and no extra software installation required.