@consused (Mate!)
I don’t know if I have a solution and IMO you are probably better placed with Intel stuff
Actually I am rather baffled that it just stopped working
@consused (Mate!)
I don’t know if I have a solution and IMO you are probably better placed with Intel stuff
Actually I am rather baffled that it just stopped working
@caf4926, Thank you for your confidence :). Sorry about “intended solution”, bad choice of words but my alternative sounded less hopeful. I had no intention of quitting this thread, but I didn’t want to confuse the OP by moving away from a line of investigation being followed. The progressively whitening screen is baffling. I think I ended up with a white screen at some point only ever once on my intel based notebook, when I experienced the Flash full-screen bug. However, the KDE desktop was already seriously broken after my attempts to exit the screen-lockup, with sections of the DE exhibiting strange effects randomly.
I’m not sure the “runlevel 3” and xorg.conf is the way to proceed. I need to re-read the first few posts, may need a bit more info from the OP. Anyway maintaining a DE/GUI on his HP will make feed back and configuration editing easier, for sure.
I have typed in nomodeset 3 in the boot options and logged in myself as user and then su.
The 'Xorg -configure" failed - it got a segment 11 and the server aborted.
There is a log at var/log/xorg.0.log, which is quite long. I can sent it if helpful.
Please wait for @consused
He has enviable experience with Intel
That’s fine. Earlier @consused asked about using 3 with normal boot and failsafe. I have removed all boot options in each and typed 3 - here they understandably both act the same with the progressive white screen. Using ‘nomodeset 3’ with normal boot and putting a 3 at the end of the failsafe boot options both work but the ‘Xorg -configure’ fails as mentioned earlier. I will wait for suggestions from @consused.
@dick222, Ok, sorry for the delay. BTW, are you using KDE or Gnome? If KDE did you originally ever look at “My Computer” (sysinfo:/), under “Display Info”, at “2D driver:” for name of the installed graphics driver?
According to your posted /var/log/zypp/history, last update was: “2010-11-11 19:46:33|install|GeneralUser|1.43-2.pm.2.1|noarch”
However, your posted /boot/grub/menu.lst shows it was modified after that date, since: “# Modified by YaST2. Last modification on Sun Nov 14 21:51:22 NZDT 2010”
What was that change to grub caused by? Was it the latest kernel update? Also note it contains duplicate entry for the latest kernel update, so something not right.
There is a log at var/log/xorg.0.log, which is quite long. I can sent it if helpful.
It’s actually /var/log/Xorg.0.log (at command line, you will need exact upper/lower case). Very useful log, but it gets overwritten at every reboot/restart X), so that one may not help much as it will only apply to that prior reboot. Take a look at it, and see if you can tell me which graphics driver was loaded? After successfully loading, the name will show repeatedly, on the left after a sequence number, for each driver related message.
This may be a repeat, but I seem to have trouble getting my replies posted.
I am using KDE, and I’m afraid I didn’t look at the 2D driver.
The update “2010-11-11 19:46:33|install|GeneralUser|1.43-2.pm.2.1|noarch” is still the last on the log.
I do not remember any further update, although I sometimes push buttons without much thought - lesson learnt.
It seems that a further update was made, however, and I am sorry for my forgetfulness - I was doing some heavy computer work at the time,though.
Looking at the /var/log/Xorg.O.log without me having any understanding may have little effect. However,the following occurs often:
16.195] (II) Loader magic: 0x7d5ba0
16.195] (II) Module ABI versions:
16.195] X.Org ANSI C Emulation: 0.4
16.195] X.Org Video Driver: 7.0
16.195] X.Org XInput driver : 9.0
16.195] X.Org Server Extension : 3.0
16.207] (–) PCI:(0:0:2:0) 8086:0046:103c:1423 Intel Corporation Core Processor Integrated Graphics Controller rev 2, Mem @ 0xd0000000/4194304, 0xc0000000/268435456, I/O @ 0x00005030/8
16.207] (II) Open ACPI successful (/var/run/acpid.socket)
16.207] (II) LoadModule: "extmod"16.195] (II) Loader magic: 0x7d5ba0
16.195] (II) Module ABI versions:
16.195] X.Org ANSI C Emulation: 0.4
16.195] X.Org Video Driver: 7.0
16.195] X.Org XInput driver : 9.0
16.195] X.Org Server Extension : 3.0
16.207] (–) PCI:(0:0:2:0) 8086:0046:103c:1423 Intel Corporation Core Processor Integrated Graphics Controller rev 2, Mem @ 0xd0000000/4194304, 0xc0000000/268435456, I/O @ 0x00005030/8
16.207] (II) Open ACPI successful (/var/run/acpid.socket)
16.207] (II) LoadModule: “extmod”
16.232] (II) Loading /usr/lib64/xorg/modules/extensions/libextmod.so
16.232] (II) Module extmod: vendor=“X.Org Foundation”
16.232] compiled for 1.8.0, module version = 1.0.0
16.232] Module class: X.Org Server Extension
16.232] ABI class: X.Org Server Extension, version 3.0
16.232] (II) Loading /usr/lib64/xorg/modules/extensions/libextmod.so
16.232] (II) Module extmod: vendor=“X.Org Foundation”
16.232] compiled for 1.8.0, module version = 1.0.0
16.232] Module class: X.Org Server Extension
16.232] ABI class: X.Org Server Extension, version 3.0
I am using normal boot with the option nomodeset. If this is no good, please let me know in more detail what you require.
Thanks for answers. I don’t need you to post any more of that Xorg.0.log, and the piece you posted looked ok. That section shows the early part of the module loading phase - there will be several modules loading. The loading of the graphics driver comes at the end of that module loading phase. Here is a small section of one of mine, for the “intellegacy” driver so you can see the repetitive name to the left of each driver message. For the “intel” driver (newer) it would show intel, and for “fbdev” driver it would show FBDEV, etc. Here intellegacy(0) is the repeated name:
24.548] (II) intellegacy(0)Creating default Display subsection in Screen section
"Default Screen" for depth/fbbpp 24/32
24.548] (==) intellegacy(0)Depth 24, (--) framebuffer bpp 32
24.548] (==) intellegacy(0)RGB weight 888
24.548] (==) intellegacy(0)Default visual is TrueColor
24.548] (II) intellegacy(0)Integrated Graphics Chipset: Intel(R) GM45
24.548] (--) intellegacy(0)Chipset: "GM45"
24.564] (II) intellegacy(0)Output VGA1 using monitor section Default Monitor
Assuming the one you are looking at is created by normal boot with nomodeset, what driver name appears in yours now?
BTW we may try the intellegacy driver next, but we will need to modify a file in /etc/X11/xorg.conf.d, and I will tell you how after I get your reply re the current driver name.
Before we try any other driver, there is one more thing we should try/eliminate. Since you run KDE (4.4.4 ?), are “desktop effects” enabled in System Settings>Desktop>Desktop Effects, and it’s a checkbox on the “General” tab?
If enabled, then disable/uncheck “desktop effects”, and reboot normally without using “nomodeset”. Report back as to whether the “white screen of death” occurs or not.
If that fails, you will need to reboot with nomodeset. After that reboot, Xorg.0.log for the failed boot should be saved as /var/log/Xorg.0.log.old, so immediately copy it to your home directory as we will need to look at that one.
On 2010-11-14 20:06, dick222 wrote:
>
> I have typed in nomodeset 3 in the boot options and logged in myself as
> user and then su.
No, in this mode (text) you are supposed to log in as root directly.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
On 2010-11-14 10:06, dick222 wrote:
> ``````````````````````````````````````````````````
> The log shows latest update was several days before the fault occurred
> (13 Nov), but it did affect the kernel:
Did you reboot at that point?
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)
With normal boot and nomodeset:
The 2D driver is fbdev
The #d driver is swrast (No 3D Acceleration) (7.8.2))
I am running 4.4.4 (KDE 4.4.4) "release 3"
Desktop effects have been disabled throughout and I have checked that the 'white screen of death" still happens without nomodeset.
```````````````````````````````````````````````````````nnot look at them now.
I have rebooted with nomodeset, saved copy of Xorg.0.log as Xorg.0.log.old in my home directory.
I notice there is also a file of the same name in /var/log but they both seem to be a backup format, so what software can open them?.
I cannot look at them now.
Have you run fsck on the partition? The fact that you got a seg fault when running xorg-conf may point to a bad sector some where.
Also try a new user since this happens after login it may be a config file problem.
The trouble is that I cannot remember exactly, since at that time things were going normaly and I was busy writing a database then. There is another problem in that the touchpad sometimes looses its configuration, so I sometimes reboot to sort that out (logout also works). So it is possible that I reboooted, but I don’t remember precisely.
Good, as expected.
Ok, noted.
No. We need to look at Xorg.0.log from a failed boot i.e. normal without using “nomodeset”. I assume you cannot access its log due to “white screen of death”, so you will then have to reboot normally but with nomodeset. That reboot will cause the system to overwrite previous Xorg.0.log (wanted for any error messages), but before doing so, it will save it as /var/log/Xorg.0.log.old (this one you should copy over to your home directory). You can open it with kwrite. Copy its contents to pastebin - collaborative debugging tool, submit it there, and post back here with the URL you are given.
I am about 13 hours behind you, it’s way past bedtime here so I will read it in morning, about 8 hours from now.
It’s not uncommon to get segmentation fault with “Xorg -configure”. He’s not “running xorg-conf” at that stage.
Happens after login? No, since the OP has said “the problem was there on bootup” and “I don’t think the boot finishes, since there is no startup sound and the software does not respond to keyboard input”.
I have made a normal boot (with the white death) and waited for long enough for it to finish. There is no evidence that this has happened, although it must have. I then copied Xorg.0.log.old to my home directory and pasted its contents to the debugging tool that you mentioned. This is a new facility and I havn’t figured out how to use it yet. It fails somehow. I could not get an URL, which somehow I have in my reply. It is late at night here, so I will investigate this tomorrow when I am more alert. Somehow the 13 hr difference between us is a factor!
I am following your lead at the moment, but notice @goglethorp’s comments about the possibility of a bad sector. I will look at that later if necessary.
The “white death” is the finish - death being the key word, that was the point to reboot.
Ok, but feel free to try anything that any other user posts here, it’s your system and your judgement call. I know it’s frustrating for you, but please try to remember that we are all volunteers helping out in our spare time. For example, if you haven’t provided specific details of your h/w because you don’t know, e.g the model/type of your integrated graphics adapter, then someone else has to do the extra research.
Having said that, a “segmentation fault” happens when a program fails to access a memory location, through a memory-access violation, the memory is not allocated and the task/program ends abnormally. There are several causes, mostly software problems. More often than not it’s buggy software, although a hardware problem cannot be ruled out, it’s less likely. However, don’t take my word for it, you can google for the explanations.
Sorry, late-night tiredness, my fault. I copied that link from another’s post in the forum. I did check the link, but didn’t test the site, and so it doesn’t work for me either! It appears there are several different pastebin sites. The one at pastebin.com #1 paste tool since 2002 looks easy, and worked for me. Copy and paste contents of that Xorg.0.log.old you saved. Select the maximum expiration time (hmm, only 1 month). Submit puts the new link in your browser address bar, copy and post back with the link.
Thanks.
On 2010-11-15 03:06, dick222 wrote:
>
> The trouble is that I cannot remember exactly, since at that time things
> were going normaly and I was busy writing a database then. There is
> another problem in that the touchpad sometimes looses its configuration,
> so I sometimes reboot to sort that out (logout also works). So it is
> possible that I reboooted, but I don’t remember precisely.
You can learn that by examining the log carefully. There is a distinct
pattern when the system boots. The thing is, if you updated the kernel and
did not reboot, the change is applied the moment you reboot. My hypothesis
is that the update did not write the correct options to the grub menu.
You could list the contents of “/boot/grub/menu*” and see if there is a
backup file older than kernel upgrade date. If there is, copy that file
somewhere else and have a good look at how the kernel was configured there,
and compare with the current configuration.
The other possibility is that there is something in this last update that
breaks yous video.
All that assuming you did not reboot immediately. If you did, then my
inferences are wrong.
–
Cheers / Saludos,
Carlos E. R.
(from 11.2 x86_64 “Emerald” at Telcontar)