Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Sig 11 on switching from X to console

1 view
Skip to first unread message

Michael

unread,
Feb 13, 2008, 5:06:23 AM2/13/08
to
I have posted something almost identical to this in the nVidia forum - I
am sorry if that counts as a cross-posting here. Also, I do feel that I
need the nVidia binary driver - it would be nice if no-one responds just
to tell me not to use closed source (it is the only closed-source software
I have).

Ok here goes :

Can anyone help me to get a handle on this problem - it may turn out to be
distro-specific (Arch Linux), but at the moment the distro forum is not
producing any ideas.

I have a GeForce FX 5500. I have just updated to my distro's packages of
the 169.09 driver and utils running under kernel 2.6.24 and X.Org X Server
1.4.0.90. I boot into a console and start X with "startx". Everything runs
perfectly until I drop back into a console while X is running (ctrl-alt-
f1). Usually (not always), this crashes X on a Sig 11 :

Backtrace:
0: /usr/bin/X(xf86SigHandler+0x7e) [0x80baf4e]
1: [0xb7fc1420]

Fatal server error:
Caught signal 11. Server aborting

I am not the only person to have this problem, but others don't see it at
all.

I upgraded the kernel at the same time as the nVidia stuff, so I have no
experience of the current driver under my previous kernel.

I don't know where to begin even in working out a test for how to isolate
or narrow down the problem.

Any ideas please?

phil-new...@ipal.net

unread,
Feb 13, 2008, 11:06:41 AM2/13/08
to

It sounds like a bug in the driver for that particular card. X is handling
the switch since it has to restore the video card register state back to
what it was as a console.

Does the switch to the console finish (e.g. the console is displaying in
the right console mode) before X crashes?

I switch in and out of X frequently (100 times or more a day) and I do not
see this problem. But my video card is different (Matrox MGA driver).

If you have a very different video card available, maybe you can test it
and see if it works better when that one and its driver is used. If it
still fails, the problem could be elsewhere.

--
|---------------------------------------/----------------------------------|
| Phil Howard KA9WGN (ka9wgn.ham.org) / Do not send to the address below |
| first name lower case at ipal.net / spamtrap-200...@ipal.net |
|------------------------------------/-------------------------------------|

Michael

unread,
Feb 13, 2008, 11:40:22 AM2/13/08
to
On Wed, 13 Feb 2008 16:06:41 +0000, phil-news-nospam wrote:

<snip>

> It sounds like a bug in the driver for that particular card. X is
> handling the switch since it has to restore the video card register
> state back to what it was as a console.
>
> Does the switch to the console finish (e.g. the console is displaying in
> the right console mode) before X crashes?

Thanks for that Phil. Yes the switch to console finishes and it can be a
few (say 2 - 5), seconds before the Sig 11 hits. I then see the usual
error reports as all my running X applications lose their connection to
the server. I can do startx immediately from the same console and X comes
back to life.

> I switch in and out of X frequently (100 times or more a day) and I do
> not see this problem. But my video card is different (Matrox MGA
> driver).

I do a lot of switching too. I use console mode as an elementary security
precaution (to stop casual observation of what I was doing), every time I
leave my desk. It won't be 100 times a day, but it must be at least 10 -
20 and I have never seen this problem before the upgrade. I have had this
same card for a couple of years now.

> If you have a very different video card available, maybe you can test it
> and see if it works better when that one and its driver is used. If it
> still fails, the problem could be elsewhere.

I could drop an old card in there is another nVidia lying around
somewhere, the problem is that just at the moment the box needs to be on
24/7. I wish that the kernel and nVidia upgrades had not been
simultaneous - maybe its some interaction between them.

Thanks again,

/M

George Peter Staplin

unread,
Feb 13, 2008, 3:23:47 PM2/13/08
to


My advice is to use the official Nvidia driver installer, rather than
distro packages, and build the module yourself with the installer. The
downside of this, if it does work, is that everytime you update your
kernel, you have to rebuild the module.

If that doesn't help then use the email address for nvidia driver bugs
on the nvidia site.


George

Michael

unread,
Feb 13, 2008, 4:10:22 PM2/13/08
to
On Wed, 13 Feb 2008 20:23:47 +0000, George Peter Staplin wrote:

><snip>

> My advice is to use the official Nvidia driver installer, rather than
> distro packages, and build the module yourself with the installer. The
> downside of this, if it does work, is that everytime you update your
> kernel, you have to rebuild the module.
>
> If that doesn't help then use the email address for nvidia driver bugs
> on the nvidia site.

Thanks George,

I always used the nVidia installer when I was running slackware and LFS
before that, and its true to say that I never had a problem. I even
started with it when I switched to Arch 6 months ago. The rolling update
system on Arch (with which I have been very impressed indeed), eventually
made it more attractive to go down this route because I began to see
conflicts with other things. I will go back to the nVidia installer if I
have to.

Incidentally, I have been looking hard at my Xorg logs and comparing them
with those on a backup drive which has not been used for a few weeks. To
be honest, I don't usually pay attention to that log, because X "just
works", but I can't see any trace in the old log of the way that, at
present, whenever I switch to the console I have :

(WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
(II) No APM support in BIOS or kernel
(II) NVIDIA(0): Setting mode "1440x900+0+0"
(II) PS/2 Mouse: ps2EnableDataReporting: succeeded

On those occasions when the switch causes X to crash, that is the last
entry in the log before the backtrace.

/M

Hactar

unread,
Feb 13, 2008, 7:07:18 PM2/13/08
to
In article <120293702...@iris.uk.clara.net>,

Michael <mi...@nospam.co.uk> wrote:
>
> Incidentally, I have been looking hard at my Xorg logs and comparing them
> with those on a backup drive which has not been used for a few weeks. To
> be honest, I don't usually pay attention to that log, because X "just
> works", but I can't see any trace in the old log of the way that, at
> present, whenever I switch to the console I have :
>
> (WW) Open ACPI failed (/var/run/acpid.socket) (No such file or directory)
> (II) No APM support in BIOS or kernel
> (II) NVIDIA(0): Setting mode "1440x900+0+0"
> (II) PS/2 Mouse: ps2EnableDataReporting: succeeded
>
> On those occasions when the switch causes X to crash, that is the last
> entry in the log before the backtrace.

Does ACPI or APM usually work? How about disabling them?

--
-eben QebWe...@vTerYizUonI.nOetP royalty.mine.nu:81

An idea that is not dangerous is unworthy of
being called an idea at all. -Oscar Wilde

Michael

unread,
Feb 14, 2008, 4:06:40 AM2/14/08
to
On Thu, 14 Feb 2008 00:07:18 +0000, Hactar wrote:
>
<snip>

> Does ACPI or APM usually work? How about disabling them?

I don't know much about ACPI. It does not run as a daemon and I am not
sure how I would actually switch it off. I have however :

(a) Put Option "ConnectToAcpid" "false" in my xorg.conf

(b) Confirmed my guess that those messages are in fact being written on
the *return* to X from the console, rather than when switching into
console mode.

Point (b) may mean that point (a) has no useful effect. Even so, I have
not yet seen X crash in the 6 times I have experimented since including
the Option. I am not very hopeful though - it has always happened at
random.

Thanks for taking an interest.

/M

0 new messages