You are not logged in.
I consistently get kernel panics [1] when running Gnome 3 DE in combination with gdm configured to run from an inittab runlevel setup.
I changed /etc/inittab back to default (runlevel 3), and setup Gnome to run from ~/.xinitrc. The kernel panics have stopped. What could be causing this? Where should I start looking?
Thanks, B
[1] - Partial screens of kernel panic information. All but the last are what was seen from ssh connection.
06/28/2011 09:41:01 - gdm | login to gnome
------------[ cut here ]------------
2011 Jun 28 09:31:32 localhost [ 114.779998] invalid opcode: 0000 [#1] PREEMPT SMP
2011 Jun 28 09:31:32 localhost [ 114.779998] last sysfs file: /sys/devices/virtual/dmi/id/bios_vendor
2011 Jun 28 09:31:32 localhost [ 114.779998] Process ck-history (pid: 1178, ti=f600c000 task=f4f58d20 task.ti=f4fbe000)
2011 Jun 28 09:31:32 localhost [ 114.779998] Stack:
2011 Jun 28 09:31:32 localhost [ 114.779998] Call Trace:
2011 Jun 28 09:31:32 localhost [ 114.779998] <IRQ>
2011 Jun 28 09:31:32 localhost [ 114.779998] Code: 26 00 00 00 00 69 c2 2c 01 00 00 ba d3 4d 62 10 8b 1d 40 3a 45 c1 f7 e2 8d 81 98 01 00 00 c1 ea 06 01 da e8 95 07 d4 c8 5b 5d c3 <0f> 0b 55 89 e5 57 56 53 83 ec 4c 3e 8d 74 26 00 89 45 e0 05 80
2011 Jun 28 09:31:32 localhost [ 114.779998] EIP: [<f831400e>] drm_vblank_put+0x5e/0x60 [drm] SS:ESP 0068:f600de9c
2011 Jun 28 09:31:32 localhost [ 114.779998] Process ck-history (pid: 1178, ti=f600c000 task=f4f58d20 task.ti=f4fbe000)
06/28/2011 09:47:05 - telinit 5 | gdm | login | launch chromium | new WS, launch gterm
------------[ cut here ]------------
2011 Jun 28 09:45:50 localhost [ 766.935475] invalid opcode: 0000 [#1] PREEMPT SMP
2011 Jun 28 09:45:50 localhost [ 766.935475] last sysfs file: /sys/devices/pci0000:00/0000:00:1e.0/0000:02:04.0/class
2011 Jun 28 09:45:50 localhost [ 766.935475] Process dbus-daemon (pid: 1089, ti=f600c000 task=f4d4e300 task.ti=f4cba000)
2011 Jun 28 09:45:50 localhost [ 766.935475] Stack:
2011 Jun 28 09:45:50 localhost [ 766.935475] Call Trace:
2011 Jun 28 09:45:50 localhost [ 766.935475] <IRQ>
2011 Jun 28 09:45:50 localhost [ 766.935475] Code: 26 00 00 00 00 69 c2 2c 01 00 00 ba d3 4d 62 10 8b 1d 40 3a 45 c1 f7 e2 8d 81 98 01 00 00 c1 ea 06 01 da e8 95 27 7e c8 5b 5d c3 <0f> 0b 55 89 e5 57 56 53 83 ec 4c 3e 8d 74 26 00 89 45 e0 05 80
2011 Jun 28 09:45:50 localhost [ 766.935475] EIP: [<f887200e>] drm_vblank_put+0x5e/0x60 [drm] SS:ESP 0068:f600de9c
2011 Jun 28 09:45:50 localhost [ 766.935475] Process dbus-daemon (pid: 1089, ti=f600c000 task=f4d4e300 task.ti=f4cba000)
2011 Jun 28 09:45:50 localhost [ 766.935475] Stack:
2011 Jun 28 09:45:50 localhost [ 766.935475] Call Trace:
2011 Jun 28 09:45:50 localhost [ 766.935475] Code: 8d b4 26 00 00 00 00 55 89 e5 83 ec 0c 89 5d f4 89 75 f8 89 7d fc 3e 8d 74 26 00 89 c7 89 d6 64 a1 ec 24 52 c1 8b 98 b4 02 00 00 <c7> 02 00 00 00 00 8b 03 83 f8 01 74 57 e8 1a 99 f8 ff 8b 43 04
06/28/2011 09:58:15 - gdm | login | launch gterm | user menu, settings
------------[ cut here ]------------
2011 Jun 28 09:56:24 localhost [ 178.383323] invalid opcode: 0000 [#1] PREEMPT SMP
2011 Jun 28 09:56:24 localhost [ 178.383323] last sysfs file: /sys/devices/virtual/dmi/id/bios_vendor
2011 Jun 28 09:56:24 localhost [ 178.383323] Process gnome-control-c (pid: 1159, ti=f600c000 task=f4cbabc0 task.ti=f4fca000)
2011 Jun 28 09:56:24 localhost [ 178.383323] Stack:
2011 Jun 28 09:56:24 localhost [ 178.383323] Call Trace:
2011 Jun 28 09:56:24 localhost [ 178.383323] <IRQ>
2011 Jun 28 09:56:24 localhost [ 178.383323] Code: 26 00 00 00 00 69 c2 2c 01 00 00 ba d3 4d 62 10 8b 1d 40 3a 45 c1 f7 e2 8d 81 98 01 00 00 c1 ea 06 01 da e8 95 a7 a7 c8 5b 5d c3 <0f> 0b 55 89 e5 57 56 53 83 ec 4c 3e 8d 74 26 00 89 45 e0 05 80
2011 Jun 28 09:56:24 localhost [ 178.383323] EIP: [<f85da00e>] drm_vblank_put+0x5e/0x60 [drm] SS:ESP 0068:f600de9c
2011 Jun 28 09:56:24 localhost [ 178.383323] Process gnome-control-c (pid: 1159, ti=f600c000 task=f4cbabc0 task.ti=f4fca000)
hand copied before reboot, ignored addresses/modules
------------[ cut here ]------------
WARNING : at kernel/watchdog.c:229 watchdog_overflow_callback+0xac/0xd0()
Hardware name: PU167A-ABA SR1020T NA580
Watchdog detected hard LOCKUP on cpu 1
Modules linked in:ipv6 .. scsi_mod [sic]
Pid: 775, comm: Xorg tainted: G D 2.6.39-ARCH #1
Call Trace:
[<>] warn_slowpath_common
[<>] ? watchdog_overflow_callback
[<>] ? watchdog_overflow_callback
[<>] touch_nmi_watchdog
[<>] warn_slowpath_fmt
[<>] watchdog_overflow_callback
[<>] __perf_event_overflow
[<>] i915_gem_object_set_to_display_plane
[<>] ? perf_event_update_userpage
[<>] ? x86_perf_event_set_period
[<>] perf_event_overflow
[<>] p4_pmu_handle_irq
[<>] ? drm_mode_page_flip_ioctl
[<>] perf_event_nmi_handler
[<>] notifier_call_chain
[<>] __atomic_notifier_call_chain
[<>] atomic_notifier_call_chain
[<>] notify_die
[<>] do_nmi
[<>] nmi_stack_correct
[<>] ? _raw_spin_lock_irqsave
[<>] drm_read
[<>] vfs_read
[<>] ? drm_poll
[<>] sys_read
[<>] sys_enter_do_call
---[ end trace 353a7cc3c4ea2f85 ]---
EDIT: Solved - UPDATE: running kernel26-lts resolved this problem.
Last edited by bsquared (2011-07-07 22:05:02)
(c}
Offline
please use code tags as opposed to quote tags.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Have you considered starting GDM as a daemon instead?
ᶘ ᵒᴥᵒᶅ
Offline
Have you considered starting GDM as a daemon instead?
The daemon approach does not allow starting in runlevel 3 as far as I recall, so I prefer the runlevel method. However, I could try it for testing purposes if that would be helpful in finding the cause. If it is suggested as merely an alternative then I would rather use the .xinitrc method.
Thanks, B
@Inxsible - I originally tried code blocks, but I must have typo'd cuz it didn't work. My bad...
(c}
Offline
Too good to be true. Tried to launch bluetooth discovery and kernel panic occurred again. This is copied from ssh session that was running. How can I capture the output of the kernel panic on the workstation so i don't have to type it in from frozen terminal?
Thanks,
B
/etc/rc.d/bluetooth start
:: Starting bluetooth subsystem: bluetoothd [DONE]
[root@bw-desktop ~]# 2011 Jun 28 14:07:29 localhost [12050.276233] ------------[ cut here ]------------
2011 Jun 28 14:07:29 localhost [12050.276233] invalid opcode: 0000 [#1] PREEMPT SMP
2011 Jun 28 14:07:29 localhost [12050.276233] last sysfs file: /sys/devices/pci0000:00/0000:00:1d.1/usb3/3-1/3-1:1.0/bluetooth/hci0/hci0:42/uevent
2011 Jun 28 14:07:29 localhost [12050.276233] Process bluetooth-wizar (pid: 17945, ti=f600c000 task=e9baf020 task.ti=f4ed2000)
2011 Jun 28 14:07:29 localhost [12050.276233] Stack:
2011 Jun 28 14:07:29 localhost [12050.276233] Call Trace:
2011 Jun 28 14:07:29 localhost [12050.276233] <IRQ>
2011 Jun 28 14:07:29 localhost [12050.276233] Code: 26 00 00 00 00 69 c2 2c 01 00 00 ba d3 4d 62 10 8b 1d 40 3a 45 c1 f7 e2 8d 81 98 01 00 00 c1 ea 06 01 da e8 95 b7 e4 c8 5b 5d c3 <0f> 0b 55 89 e5 57 56 53 83 ec 4c 3e 8d 74 26 00 89 45 e0 05 80
2011 Jun 28 14:07:29 localhost [12050.276233] EIP: [<f820900e>] drm_vblank_put+0x5e/0x60 [drm] SS:ESP 0068:f600de9c
2011 Jun 28 14:07:29 localhost [12050.276233] Process bluetooth-wizar (pid: 17945, ti=f600c000 task=e9baf020 task.ti=f4ed2000)
(c}
Offline
I ran pacman -Syu - no help. kernel panic fairly consistently on startx
~/.xinit
if [ -d /etc/X11/xinit/xinitrc.d ]; then
for f in /etc/X11/xinit/xinitrc.d/*; do
[ -x "$f" ] && . "$f"
done
unset f
fi
exec ck-launch-session gnome-session
I also commented the for loop, but no change.
(c}
Offline
Try
exec ck-launch-session dbus-launch gnome-session
Since the kernel panics occur irrespective of whether you start from gdm or .xinitrc, I am thinking this is probably not related to your inittab
EDIT: Moved from Newbie Corner...
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Try
exec ck-launch-session dbus-launch gnome-session
Since the kernel panics occur irrespective of whether you start from gdm or .xinitrc, I am thinking this is probably not related to your inittab
EDIT: Moved from Newbie Corner...
Apologies for cross posting, I considered it a different question. ie how do I capture the output of the panic?
I assume you meant to run "exec ck-launch-session dbus-launch gnome-session" from xinit, so I changed my ~/.xinitrc[1]. I was able start Gnome and add a bluetooth device, so I would have to say that your suggestion is a big improvement, Thanks...
Shouldn't the dbus-launch happen "automatically"?
What does this indicate as the source of the problem as it relates to to the initial GDM problem?
[1] - ~/.xinitrc
#!/bin/sh
#
# ~/.xinitrc
#
# Executed by startx (run your window manager from here)
exec ck-launch-session dbus-launch gnome-session
# end ~/.xinitrc
(c}
Offline
Shouldn't the dbus-launch happen "automatically"?
If you have dbus in your DAEMONS array in rc.conf, it will start dbus for the super-user (I think). The ~/.xinitrc is a user file and is started by the user account which is why you need to launch dbus for the user before starting your DE/WM
Now if you still want to start gdm via the inittab method, you can try this link : https://wiki.archlinux.org/index.php/St … .2Finittab. If it does not work, post your inittab so we can see what's going on.
If you are happy with the way things are working currently, then please mark the thread as [SOLVED] by editing your first post and prepending/appending [SOLVED] in your thread title.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Now if you still want to start gdm via the inittab method
If I use the daemon method to start GDM, can I stiil boot to console using runlevel parameter on kernel line in GRUB?
Thank you for your help. I would suggest a change may be in order for Xorg and Gnome wiki pages.
(c}
Offline
If I use the daemon method to start GDM, can I stiil boot to console using runlevel parameter on kernel line in GRUB?
I am not sure I completely follow, but you mean by adding gdm to the DAEMONS array in rc.conf? In any case, even if gdm starts up, you can always hit Ctrl+Alt+F1-6 to get to the tty and then login there.
Thank you for your help. I would suggest a change may be in order for Xorg and Gnome wiki pages.
You are welcome, and if you think the wiki pages need updating, please create an account and feel free to articulate those sections in a better way.
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Now if you still want to start gdm via the inittab method, you can try this link : https://wiki.archlinux.org/index.php/St … .2Finittab. If it does not work, post your inittab so we can see what's going on.
The referred page is about circumventing the display manager.
Another way of circumventing display managers and booting straight into a preferred window manager or desktop environment involves editing /etc/inittab, changing:
[...]
x:5:respawn:/usr/bin/xdm -nodaemon
[...]
x:5:once:/bin/su - -- PREFERRED_USER -l -c '/usr/bin/startx </dev/null >/dev/null 2>&1'
I want the display manager to run.
Any other ideas?
p.s. The daemon method of starting GDM is not compatible with runlevel parameters on GRUB's kernel line. Using iniitab and this parameter gives me the choice of booting to a runlevel (console or GDM). Loading GDM as a daemon does not.
(c}
Offline
https://wiki.archlinux.org/index.php/Di … ay_manager
Post your inittab.
Also you want the display manager (gdm) to run , but at the same time be able to log into console -- which you can do even with the daemon method I believe (by hitting ctrl+alt+F1-6) like I mentioned before. Am I missing something here?
There's no such thing as a stupid question, but there sure are a lot of inquisitive idiots !
Offline
Current inittab is not configured for GDM start-up, edited with changes needed for GDM as instructed on wiki pages Xorg & Gnome.
cat /etc/inittab
#
# /etc/inittab
#
## Only one of the following two lines can be uncommented!
## changed for GDM ##
## id:3:initdefault:
id:5:initdefault:
## end changed section ##
rc::sysinit:/etc/rc.sysinit
rs:S1:wait:/etc/rc.single
rm:2345:wait:/etc/rc.multi
rh:06:wait:/etc/rc.shutdown
su:S:wait:/sbin/sulogin -p
# -8 options fixes umlauts problem on login
c1:2345:respawn:/sbin/agetty -8 -s 38400 tty1 linux
c2:2345:respawn:/sbin/agetty -8 -s 38400 tty2 linux
c3:2345:respawn:/sbin/agetty -8 -s 38400 tty3 linux
c4:2345:respawn:/sbin/agetty -8 -s 38400 tty4 linux
c5:2345:respawn:/sbin/agetty -8 -s 38400 tty5 linux
c6:2345:respawn:/sbin/agetty -8 -s 38400 tty6 linux
# Serial Virtual Console for KVM and others VMs
#s0:2345:respawn:/sbin/agetty -8 -s 9600 ttyS0 linux
# Hypervisor Virtual Console for Xen and KVM
#h0:2345:respawn:/sbin/agetty -8 -s 38400 hvc0 linux
ca::ctrlaltdel:/sbin/shutdown -t3 -r now
## changed for GDM ##
x:5:respawn:/usr/sbin/gdm -nodaemon
## end changed section ##
# End of file
(c}
Offline
Unfortunately any feeling of success was fleeting...
Using startx plus ~/.xinitrc (exec ck-launch-session dbus-launch gnome-session), and I'm still getting kernel panics.
I read that the EIP line in the Stack Trace is key: EIP is at drm_vblank_put+0x5e/0x60 [drm]
This has been the case in every instance (see code in earlier posts).
lspci | grep VGA
00:02.0 VGA compatible controller: Intel Corporation 82915G/GV/910GL Integrated Graphics Controller (rev 04)
lsmod | grep drm
drm_kms_helper 24245 1 i915
drm 147653 2 i915,drm_kms_helper
i2c_core 16665 5 i915,drm_kms_helper,drm,i2c_i801,i2c_algo_bit
agpgart 22160 3 drm,intel_agp,intel_gtt
EDIT: removed code snippet, duplicated in previous posts.
Last edited by bsquared (2011-06-30 02:09:01)
(c}
Offline
Try
exec ck-launch-session dbus-launch gnome-session
FYI
I found that dbus-launch is sourced from /etc/X11/xinit/xinitrc.d/30-dbus in the for loop in ~/.xinitrc
Last edited by bsquared (2011-06-30 03:09:45)
(c}
Offline
kernel BUG at drivers/gpu/drm/drm_irq.c:923!
EIP: [<f820900e>] drm_vblank_put+0x5e/0x60 [drm] SS:ESP 0068:f600de9c
Using the information from these two lines, I was able to find what looks to be a bug in kernel drm driver.
Presently I can workaround by selecting - System Settings | System Info | Graphics | Forced Fallback Mode. I am able to run in this mode using GDM via inittab.
Should I rollback kernel packages to a more stable version (kernel26-lts 2.6.32.42-1)?
How difficult is that in Arch?
Thanks,
B
(c}
Offline
why don't you try this patch?
Offline
why don't you try this patch?
Thank you, I will consider that. I'm not sure if patching and building is the route I want to take as I am just familiarizing myself with Arch.
(c}
Offline
Should I rollback kernel packages to a more stable version (kernel26-lts 2.6.32.42-1)?
How difficult is that in Arch?
What is the downside?
Thanks,
B
(c}
Offline
it's not difficult, just install it and create the related entry in your bootloader configuration file, that's all. you still can keep the "current" kernel installed.
the problem is that this bug may have been backported...
I'd go with patching/testing/reporting to make the mainline kernel better for everyone and so you can benefit of all the latest improvements
Offline
I believe that drivers and headers require downgrading as well. I am marking this topic as solved as the issue is related to a kernel bug and I can search for the information I want regarding downgrading the kernel.
Thanks to posters for all the help.
(c}
Offline