You are not logged in.

#1 2010-03-02 00:30:24

gaunt
Member
Registered: 2009-12-13
Posts: 62

Some kind of lockup

Hi,

I think this is the right place to put this, but please correct me if it's not.  Anway:

I'm running Arch64 with an Nvidia card on a laptop.  Latest kernel (2.6.32) and Nvidia drivers (195.36.08-1 - I am using xorg.conf generated by nvidia-xconfig), though the problem has been occurring with older kernels and drivers.  Every so often, the computer will simply lock.  The screen continues to display, but does not accept any input (Ctrl-Alt-F1 does nothing), and the caps-lock light begins to flash.  I can't do anything other than do a hard reboot.  This occurs, I would estimate, about once every week or so of uptime.

When I check var/log/everything, I don't get anything out of the ordinary*.  The logs just stop - example:

//...
Mar  1 17:41:43 number15 dhcpcd: wlan0: leased 192.168.1.2 for 86400 seconds
Mar  1 17:41:43 number15 dhcpcd: forking to background
Mar  1 17:41:48 number15 kernel: wlan0: no IPv6 routers present
Mar  1 17:42:25 number15 kernel: warning: `VirtualBox' uses 32-bit capabilities (legacy support in use)
Mar  1 18:02:25 number15 -- MARK --
Mar  1 18:22:25 number15 -- MARK --
Mar  1 18:30:01 number15 crond[1868]: FILE /var/spool/cron/root USER root PID 4028 job sys-hourly
Mar  1 18:42:33 number15 kernel: CE: hpet increasing min_delta_ns to 15000 nsec
Mar  1 18:44:46 number15 kernel: CE: hpet increasing min_delta_ns to 22500 nsec

//Crash here - and I immediately reboot.  The whole crash-boot-login process couldn't have taken more than 4 minutes max.

Mar  1 18:51:10 number15 syslog-ng[1764]: syslog-ng starting up; version='3.0.4'
Mar  1 18:51:10 number15 kernel: Linux version 2.6.32-ARCH (tobias@T-POWA-LX) (gcc version 4.4.3 (GCC) ) #1 SMP PREEMPT Tue Feb 23 19:43:46 CET 2010
Mar  1 18:51:10 number15 kernel: Command line: root=/dev/disk/by-uuid/c3a3ff1f-4ef2-4ad7-9b3d-e67f1f1671c8 ro
//... and so on ...

This happens whether or not I am using VirtualBox, so I don't think the program itself is an issue, but I am not exactly zealous about building vbox_drv_module.

This has happened with older kernels and most certainly with older nvidia drivers.

* There is one unusual instance.  Most of the time the crash happens when I am doing something, but once I checked the computer after leaving it on at night and found the screensaver in state described above, though I am not sure whether it is the same incident.  Xorg.log.0 held this:

(II) Feb 24 19:22:54 NVIDIA(0): Setting mode "640x480"
(II) Feb 24 19:23:16 NVIDIA(0): Setting mode "nvidia-auto-select"
(WW) Feb 25 01:39:44 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00006b20)
(WW) Feb 25 01:39:51 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00006b20)
(WW) Feb 25 01:39:54 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00007044)
(WW) Feb 25 01:40:01 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00007044)
(WW) Feb 25 01:40:04 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00007550)
(WW) Feb 25 01:40:11 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00007550)
(WW) Feb 25 01:40:14 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00007a5c)
(WW) Feb 25 01:40:21 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00007a5c)
(WW) Feb 25 01:40:26 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00007f68)
(WW) Feb 25 01:40:33 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00007f68)
(WW) Feb 25 01:40:36 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x000095bc)
(WW) Feb 25 01:40:43 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x000095bc)
(WW) Feb 25 01:40:46 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00009ae0)
(WW) Feb 25 01:40:53 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00009ae0)
(WW) Feb 25 01:40:56 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00009fec)
(WW) Feb 25 01:41:03 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00009fec)
(WW) Feb 25 01:41:06 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000a4f8)
(WW) Feb 25 01:41:13 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000a4f8)
(WW) Feb 25 01:41:16 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000aa04)
(WW) Feb 25 01:41:23 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000aa04)
(WW) Feb 25 01:41:26 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000af10)
(WW) Feb 25 01:41:33 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000af10)
(WW) Feb 25 01:41:36 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000c564)
(WW) Feb 25 01:41:43 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000c564)
(WW) Feb 25 01:41:46 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000ca88)
(WW) Feb 25 01:41:53 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000ca88)
(WW) Feb 25 01:41:56 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000cf94)
(WW) Feb 25 01:42:03 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000cf94)
(WW) Feb 25 01:42:06 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000d4a0)
(WW) Feb 25 01:42:13 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000d4a0)
(WW) Feb 25 01:42:16 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000d9ac)
(WW) Feb 25 01:42:23 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000d9ac)
(WW) Feb 25 01:42:26 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000deb8)
(WW) Feb 25 01:42:33 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000deb8)
(WW) Feb 25 01:42:36 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000f50c)
(WW) Feb 25 01:42:43 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000f50c)
(WW) Feb 25 01:42:46 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000fa30)
(WW) Feb 25 01:42:53 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000fa30)
(WW) Feb 25 01:42:56 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000ff3c)
(WW) Feb 25 01:43:03 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000ff3c)
(WW) Feb 25 01:43:06 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x0000047c)
(WW) Feb 25 01:43:13 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x0000047c)
(WW) Feb 25 01:43:16 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00000988)
(WW) Feb 25 01:43:23 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00000988)
(WW) Feb 25 01:43:26 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00000e94)
(WW) Feb 25 01:43:33 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00000e94)
(WW) Feb 25 01:43:36 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x000024e8)
(WW) Feb 25 01:43:43 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x000024e8)
(WW) Feb 25 01:43:46 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00002a0c)
(WW) Feb 25 01:43:53 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00002a0c)
(WW) Feb 25 01:43:56 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00002f18)
(WW) Feb 25 01:44:03 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00002f18)
(WW) Feb 25 01:44:06 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00003424)
(WW) Feb 25 01:44:13 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00003424)
(WW) Feb 25 01:44:21 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00003930)
(WW) Feb 25 01:44:28 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00003930)
(WW) Feb 25 01:44:31 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00003e3c)
(WW) Feb 25 01:44:38 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00003e3c)
(WW) Feb 25 01:44:41 NVIDIA(0): WAIT (2, 6, 0x8000, 0x000054cc, 0x00005490)
(WW) Feb 25 01:44:48 NVIDIA(0): WAIT (1, 6, 0x8000, 0x000054cc, 0x00005490)
[mi] EQ overflowing. The server is probably stuck in an infinite loop.

Backtrace:
0: /usr/bin/X (xorg_backtrace+0x28) [0x45a8d8]
1: /usr/bin/X (mieqEnqueue+0x1f4) [0x454294]
2: /usr/bin/X (xf86PostMotionEventP+0xce) [0x46d1fe]
3: /usr/lib/xorg/modules/input/evdev_drv.so (0x7f1921900000+0x503f) [0x7f192190503f]
4: /usr/bin/X (0x400000+0x63477) [0x463477]
5: /usr/bin/X (0x400000+0xef923) [0x4ef923]
6: /lib/libpthread.so.0 (0x7f1956001000+0xee80) [0x7f195600fe80]
7: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x5dd70) [0x7f1952197d70]
8: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x5e145) [0x7f1952198145]
9: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x5e34a) [0x7f195219834a]
10: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0xa9b3a) [0x7f19521e3b3a]
11: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x346c3e) [0x7f1952480c3e]
12: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x347425) [0x7f1952481425]
13: /usr/lib/xorg/modules/drivers/nvidia_drv.so (0x7f195213a000+0x3475c4) [0x7f19524815c4]
14: /usr/bin/X (0x400000+0xacdd8) [0x4acdd8]
15: /usr/bin/X (0x400000+0x949fa) [0x4949fa]
16: /usr/bin/X (0x400000+0x95845) [0x495845]
17: /usr/bin/X (0x400000+0x46054) [0x446054]
18: /usr/bin/X (0x400000+0x219ec) [0x4219ec]
19: /lib/libc.so.6 (__libc_start_main+0xfd) [0x7f19552acb6d]
20: /usr/bin/X (0x400000+0x21599) [0x421599]

Anyway, this is most annoying, so I would really appreciate any help - even if it's just a 'google these terms' or 'you're looking at the wrong log' response (though I have looked in wiki/google).

Offline

#2 2010-03-03 00:06:34

gaunt
Member
Registered: 2009-12-13
Posts: 62

Re: Some kind of lockup

So the crash happened again, and this time I can provide a bit more information.  VirtualBox (& wine and a bunch of other stuff) was running, but this time I had made sure my kernel modules were newly built.  A few seconds before the crash my internet connection started to kind of die (I have the ath9k drivers and I use wicd), so I opened wicd-client.  Before the menu could populate, the crash occurred.  Again - no evidence in everything.log (or even Xorg.0.log).  wicd logs seem harmless, but I noticed this:

Most of the time, the message 'wicd initializing' comes after a normal shutdown and restart, with the message like:

...
2010/03/01 19:31:11 :: Daemon going down, killing wicd-monitor...
2010/03/01 19:31:11 :: Removing PID file...
2010/03/01 19:31:11 :: Shutting down...
2010/03/01 19:32:02 :: ---------------------------
2010/03/01 19:32:02 :: wicd initializing...
2010/03/01 19:32:02 :: ---------------------------
2010/03/01 19:32:02 :: wicd is version 1.7.0 552
2010/03/01 19:32:02 :: setting backend to external
...

But in instances when the crash occured, I get messages like this:

...
2010/03/01 17:41:43 :: 
2010/03/01 17:41:43 :: 
2010/03/01 17:41:43 :: DHCP connection successful
2010/03/01 17:41:43 :: not verifying
2010/03/01 17:41:43 :: Connecting thread exiting.
2010/03/01 17:41:45 :: Sending connection attempt result Success
//note time difference here.  Crash happened around 18:48-18:50 by my estimations
2010/03/01 18:51:19 :: ---------------------------
2010/03/01 18:51:19 :: wicd initializing...
2010/03/01 18:51:19 :: ---------------------------
2010/03/01 18:51:19 :: wicd is version 1.7.0 552
2010/03/01 18:51:19 :: setting backend to external
...

I'm not sure if this is simply statistically likely data being gathered before a crash or an omen, but in each crash instance when the internet has been in use connections have died a few seconds before everything else.

I have been up for an hour or so now with no suspicious activity.  I'm going to leave it on overnight running pretty much nothing and see if the problem manifests itself with no abnormal applications.

Last edited by gaunt (2010-03-03 00:13:19)

Offline

#3 2010-03-03 01:20:11

pielgrzym
Member
Registered: 2010-02-18
Posts: 49

Re: Some kind of lockup

Same setup here: 64bit arch, c2d processor, nvidia card. Everything up to date. The lockup happens when I want to use some 3d accel (like gl rendering engine in smplayer). How I hate proprietary drivers...

Offline

#4 2010-03-03 21:13:12

gaunt
Member
Registered: 2009-12-13
Posts: 62

Re: Some kind of lockup

pielgrzym wrote:

Same setup here: 64bit arch, c2d processor, nvidia card. Everything up to date. The lockup happens when I want to use some 3d accel (like gl rendering engine in smplayer). How I hate proprietary drivers...

This could seriously be my issue.  The crash during screensaver was a 3D rendered one, and every other time I think was running something that wanted my graphics card, from Virtualbox to dwarf fortress...

I may have to give up playing quake for a while and move to the opensource drivers and see if that fixes anything.

EDIT:  and since we think this is an nvidia issue, could a mod please move this to the appropriate subforum?

Last edited by gaunt (2010-03-03 21:15:42)

Offline

#5 2010-03-24 15:35:16

sean
Member
Registered: 2009-11-07
Posts: 5

Re: Some kind of lockup

Hello,

I do not agree that the issue is with nvidia.

I have exactly the same sort of issue with ATI + ath9k.

I find that whenever I download or upload ~300mb of data, my wifi will stop responding and icmp ping will display "no buffer space available".

When this happens I get some junk spewed in dmesg mostly relating to ath9k, mac80211 and aes modules.

Additionally, I find that if I leave it for about 2 minutes wifi will reconnect and the system will recover. If I grow impatient and bring up wicd the system will crash as explained in the other posts. The problem does not seem to lie with wicd as it happens even with a fully manual wifi connection!

My Atheros card is quite a recent addition to my system as I was having similar issues with my intel card... so I don't think it could even be specific to Atheros!

Does the problem lie with WPA2?

Unfortunately I don't have any of the usual output handy but I will try and update here as soon as I do.

Offline

#6 2010-03-24 16:22:31

gaunt
Member
Registered: 2009-12-13
Posts: 62

Re: Some kind of lockup

sean wrote:

I do not agree that the issue is with nvidia.

I have exactly the same sort of issue with ATI + ath9k.

If that is the case, it may be the wireless - I believe I have an atheros as well.

I find that whenever I download or upload ~300mb of data, my wifi will stop responding and icmp ping will display "no buffer space available".

When this happens I get some junk spewed in dmesg mostly relating to ath9k, mac80211 and aes modules.

Additionally, I find that if I leave it for about 2 minutes wifi will reconnect and the system will recover. If I grow impatient and bring up wicd the system will crash as explained in the other posts. The problem does not seem to lie with wicd as it happens even with a fully manual wifi connection!

I've never had this issue - whenever my wireless drops like that a hard crash follows.

My Atheros card is quite a recent addition to my system as I was having similar issues with my intel card... so I don't think it could even be specific to Atheros!

Does the problem lie with WPA2?

Unfortunately I don't have any of the usual output handy but I will try and update here as soon as I do.

I really doubt we have the same issue - yours only seems to affect wireless, whereas my issue brings the whole system down.

On a better note, I haven't had the issue in quite some time, so a recent update may have fixed it.

Offline

Board footer

Powered by FluxBB