[Bug 752296] New: on a AMD Phenom (tm) II X4 the kernel started by xen ends with panic before starting the GUI
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c0 Summary: on a AMD Phenom (tm) II X4 the kernel started by xen ends with panic before starting the GUI Classification: openSUSE Product: openSUSE 12.1 Version: Final Platform: x86 OS/Version: openSUSE 12.1 Status: NEW Severity: Normal Priority: P5 - None Component: Xen AssignedTo: jdouglas@suse.com ReportedBy: trier@rrz.uni-koeln.de QAContact: qa@suse.de CC: carnold@suse.com Depends on: 747920 Found By: --- Blocker: --- Created an attachment (id=481436) --> (http://bugzilla.novell.com/attachment.cgi?id=481436) Contains a README, /var/log, a backtrace as screenshot picture etc. +++ This bug was initially created as a clone of Bug #747920 +++ User-Agent: Mozilla/5.0 (X11; Linux i686; rv:9.0.1) Gecko/20100101 Firefox/9.0.1 The behavior of the system is the same as described in BUG 743985 for a 64-bit system. The screen is after some time black. The keyborard and mouse don't react. With the attached material I have tried the behavior to document. I hope it is enough. At my first try I dont't know that the attachment size is bounded (therefore a new attachment). And further that the answers of your questions must be done by comments. I hope that we come now to a result. Excuse my incompetence. Reproducible: Always Steps to Reproduce: 1. Start xen via grub. 2. Waiting of xdm. 3. Black screen and keyboard and mouse don't react. Actual Results: No furthcoming. Expected Results: xdm request to login. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c Jan Beulich <jbeulich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED CC|jbeulich@suse.com | Found By|--- |Community User AssignedTo|jdouglas@suse.com |jbeulich@suse.com -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c1 Jan Beulich <jbeulich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Priority|P5 - None |P3 - Medium Status|ASSIGNED |NEEDINFO InfoProvider| |trier@rrz.uni-koeln.de --- Comment #1 from Jan Beulich <jbeulich@suse.com> 2012-03-15 10:34:35 UTC --- As a workaround, disable (blacklist, rename, or some such) the DRM module (drm.ko), and configure X again. (The same effect might be achievable by disabling acceleration when configuring X, and I understand that using "nomodeset", possibly in combination with "x11failsafe", also allows X to come up.) As long as a serial port exists on (one of) the affected machine(s), we'd absolutely need to see Xen messages (with "loglvl=all guest_loglvl=all" in effect) too (not sure whether the non-X consoles are still usable after the crash - if so, "xm dmesg" could of course also be used to get at those). Further, kmsg_without_nomodeset_and_x11failsafe unfortunately appears to be incomplete - there are fragments of messages in there, and comparing with the -desktop kernel boot visible in /var/log/messages there are also DRM related messages missing (and it is hence left unclear what the reason for this is). The photo shows a panic that appears entirely unrelated (usage error on invoking init). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c2 --- Comment #2 from Jan Beulich <jbeulich@suse.com> 2012-03-15 10:38:44 UTC --- Further, please try booting with "mem=4G" added to the Xen command line. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c3 --- Comment #3 from Jan Beulich <jbeulich@suse.com> 2012-03-15 11:10:39 UTC --- Another thing that might help track down the order of operations in the DRM code would be to add "debug=7" to the drm.ko load options (ideally we could get both a native and a Xen run's outputs for comparison). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c4 --- Comment #4 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-18 10:31:36 UTC --- Created an attachment (id=481882) --> (http://bugzilla.novell.com/attachment.cgi?id=481882) /var/log of different boots -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c5 --- Comment #5 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-18 10:38:13 UTC --- (In reply to comment #1)
As a workaround, disable (blacklist, rename, or some such) the DRM module (drm.ko), and configure X again. (The same effect might be achievable by disabling acceleration when configuring X, and I understand that using "nomodeset", possibly in combination with "x11failsafe", also allows X to come up.)
As long as a serial port exists on (one of) the affected machine(s), we'd absolutely need to see Xen messages (with "loglvl=all guest_loglvl=all" in effect) too (not sure whether the non-X consoles are still usable after the crash - if so, "xm dmesg" could of course also be used to get at those).
Further, kmsg_without_nomodeset_and_x11failsafe unfortunately appears to be incomplete - there are fragments of messages in there, and comparing with the -desktop kernel boot visible in /var/log/messages there are also DRM related messages missing (and it is hence left unclear what the reason for this is).
The photo shows a panic that appears entirely unrelated (usage error on invoking init).
Thank you for your fast response. But I couldn't your proposed workaround start as you it described. I have renamed: /lib/modules/3.1.9-1.4-xen/kernel/drivers/gpu/drm/drm.orig.ko. I didn't the 'configure X again' because I didn't know what you mean. I haven't never configured X (this is right too for dissabling acceleration). Connsider I am a stupid user and not a specialist as you. Inspite I hope I can help the problem to solve. The /var/log files (also from a boot with loglvl=all guest_loglvl=all) are attached and some other material what perhaps can help. To the DRM related missing messages I can say only: The desktop version of openSUSE 12.1 works perfectly. The replies for the other comments follow in the next days. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c6 --- Comment #6 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-18 15:44:37 UTC --- Created an attachment (id=481895) --> (http://bugzilla.novell.com/attachment.cgi?id=481895) after crashed boot with mem=4G directory /var/log Also using of mem=4G doesn't solve the problem. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c7 --- Comment #7 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-18 18:10:56 UTC --- Created an attachment (id=481905) --> (http://bugzilla.novell.com/attachment.cgi?id=481905) /var/log after desktop boot and xen boot with drm.debug=7 I hope I have it made right with the debug param for drm.ko . -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c8 --- Comment #8 from Jan Beulich <jbeulich@suse.com> 2012-03-19 08:41:01 UTC --- (In reply to comment #5)
I have renamed: /lib/modules/3.1.9-1.4-xen/kernel/drivers/gpu/drm/drm.orig.ko. I didn't the 'configure X again' because I didn't know what you mean. I haven't never configured X (this is right too for dissabling acceleration).
Just running SaX2 again (as root) with drm.ko not loadable should be all you need (but you need to be aware that the resulting configuration will then also be used for the -desktop kernel, so you may want to save the original X configuration files in /etc/X11/).
The /var/log files (also from a boot with loglvl=all guest_loglvl=all) are attached and some other material what perhaps can help.
But you're aware that _no_ Xen message will ever show up anywhere in /var/log/, so the log level settings you say you added have no effect as long as you look only at log files in that directory? As said before, they will only show up on a serial console or, provided the system allows you to get to a prompt, as output of "xm dmesg". The fact that keyboard and mouse don't work with drm.ko renamed may be a different problem, and will definitely require seeing Xen messages (and possibly even sending debug keys from the serial console). "try_with_loglvl=all_guest_loglvl=all" is confusing - seems like you restored back drm.ko, yet got the same behavior as with it renamed. (In reply to comment #6)
Created an attachment (id=481895) --> (http://bugzilla.novell.com/attachment.cgi?id=481895) [details] after crashed boot with mem=4G directory /var/log
Also using of mem=4G doesn't solve the problem.
Okay, at least one possible reason we can exclude from the picture. (In reply to comment #7)
Created an attachment (id=481905) --> (http://bugzilla.novell.com/attachment.cgi?id=481905) [details] /var/log after desktop boot and xen boot with drm.debug=7
I hope I have it made right with the debug param for drm.ko .
Sorry, but there is not even a single instance of a Xen boot in either of the two /var/log/messages files. Something must have gone entirely wrong. May I ask that you briefly verify that the needed data is actually included in the quite big (and hence time consuming to look at) piles of files before you upload them? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c9 --- Comment #9 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-20 09:14:12 UTC --- (In reply to comment #8)
(In reply to comment #5)
I have renamed: /lib/modules/3.1.9-1.4-xen/kernel/drivers/gpu/drm/drm.orig.ko. I didn't the 'configure X again' because I didn't know what you mean. I haven't never configured X (this is right too for dissabling acceleration).
Just running SaX2 again (as root) with drm.ko not loadable should be all you need (but you need to be aware that the resulting configuration will then also be used for the -desktop kernel, so you may want to save the original X configuration files in /etc/X11/).
The /var/log files (also from a boot with loglvl=all guest_loglvl=all) are attached and some other material what perhaps can help.
But you're aware that _no_ Xen message will ever show up anywhere in /var/log/, so the log level settings you say you added have no effect as long as you look only at log files in that directory? As said before, they will only show up on a serial console or, provided the system allows you to get to a prompt, as output of "xm dmesg".
The fact that keyboard and mouse don't work with drm.ko renamed may be a different problem, and will definitely require seeing Xen messages (and possibly even sending debug keys from the serial console).
"try_with_loglvl=all_guest_loglvl=all" is confusing - seems like you restored back drm.ko, yet got the same behavior as with it renamed.
(In reply to comment #6)
Created an attachment (id=481895) --> (http://bugzilla.novell.com/attachment.cgi?id=481895) [details] [details] after crashed boot with mem=4G directory /var/log
Also using of mem=4G doesn't solve the problem.
Okay, at least one possible reason we can exclude from the picture.
(In reply to comment #7)
Created an attachment (id=481905) --> (http://bugzilla.novell.com/attachment.cgi?id=481905) [details] [details] /var/log after desktop boot and xen boot with drm.debug=7
I hope I have it made right with the debug param for drm.ko .
Sorry, but there is not even a single instance of a Xen boot in either of the two /var/log/messages files. Something must have gone entirely wrong. May I ask that you briefly verify that the needed data is actually included in the quite big (and hence time consuming to look at) piles of files before you upload them?
Indeed a mystery. The procedure was always: 1. Changes as required under openSUSE 12.1 booted with desktop kernel. 2. shutdown -h now 3. Boot of xen (s. sent menue.lst) 4. After crash: . power off . power on (because reboot by CTRL/ALT/DEL doesn't work correctly under openSUSE 12.1) 5. Boot of openSUSE 12.1 with desktop kernel. 6. Inspection of /var/log esp. file messages to find traces of xen boot. 7. Preparation of material for you and addition to bugzilla. What do I wrong? Because I could never find a trace of xen boot in file /var/log/messages I have uploaded the totaly directory /var/log (except directory YaST2 in it because of file size boundary of 10 MB) in the hope that you know where traces could be. I have checked the files again which I have uploaded. It is nothing to add. Inspite I upload the /var/log with content from now so that you can verify the other uploaded /var/log copies. They are now to find in /var/log/messages-20120319.xz . Traces of xen boot was to find only for me in the copies of /proc/kmsg (by changes of initrd...). From the uploaded files kmsg_without_nomodeset_and_x11failsafe and kmsg_with_nomodeset_and_x11failsafe (s. first attachment) contains the first one a message to a drm bug. Why is this not helpful? What can I do for you else? The answer of the other things of you come in the next time. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c10 --- Comment #10 from Jan Beulich <jbeulich@suse.com> 2012-03-20 09:25:24 UTC --- (In reply to comment #9)
Traces of xen boot was to find only for me in the copies of /proc/kmsg (by changes of initrd...). From the uploaded files kmsg_without_nomodeset_and_x11failsafe and kmsg_with_nomodeset_and_x11failsafe (s. first attachment) contains the first one a message to a drm bug. Why is this not helpful?
This was helpful in the sense that it pointed out that we need to enable debugging code in DRM. So with debug=7 set, you could make an attempt to collect the output that same way. (Whether kernel output makes it into /var/log/messages depends on when the kernel crash occurs - if too early, nothing will get written.)
What can I do for you else?
Start using a serial console (after so many hints in that direction and you not saying that your system doesn't have a serial port, I just have to conclude that it has but you're not making use of it). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c11 --- Comment #11 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-20 09:31:12 UTC --- Created an attachment (id=482116) --> (http://bugzilla.novell.com/attachment.cgi?id=482116) /var/log with messages-20120319.xz -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c12 --- Comment #12 from Jan Beulich <jbeulich@suse.com> 2012-03-20 10:54:37 UTC --- Please forgive me asking, but what new information am I to look for in this new upload? Please stop dumping irrelevant, unannotated data onto this bug - the amount is already pretty unmanageable, and we won't get closer to a resolution if significant amounts of time need to be spent on just locating relevant data (not to speak of actually analyzing it). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c13 Jan Beulich <jbeulich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |boris.ostrovsky@amd.com --- Comment #13 from Jan Beulich <jbeulich@suse.com> 2012-03-20 10:56:50 UTC --- Boris - any chance you could help either locating a system where the problem can be reproduced, or (even better) have someone at your end reproduce and analyze the problem (as this pretty certainly would be an issue with upstream Xen too)? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c14 --- Comment #14 from Boris Ostrovsky <boris.ostrovsky@amd.com> 2012-03-20 20:27:58 UTC --- I was able to reproduce this (although it's a bit difficult to be sure what "this" is) but nomodeset argument seems to fix the problem. Going over the comments I don't think this argument was ever tested. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c15 Conny Seidel <conny.seidel@amd.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |conny.seidel@amd.com --- Comment #15 from Conny Seidel <conny.seidel@amd.com> 2012-03-20 20:45:20 UTC --- I can reproduce the issue. BUT when I use nomodeset as kernel parameter the issue vanishes. Wolfgang are you sure you used nomodeset somewhere in your tests? I did a grep over your logfiles and didn't find it except in the failsave menu entries. If you haven't tried it yet, could you please check if that helps a little? Jan: I could give you the console output with debug options, if that helps you. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c16 --- Comment #16 from Jan Beulich <jbeulich@suse.com> 2012-03-21 08:15:32 UTC --- (In reply to comment #14)
I was able to reproduce this (although it's a bit difficult to be sure what "this" is)
"this" is a pretty clear and obvious BUG() instance visible in the logs: <2>[ 14.916183] kernel BUG at /home/abuild/rpmbuild/BUILD/kernel-xen-3.1.9/linux-3.1/drivers/gpu/drm/drm_irq.c:934! <0>[ 14.916185] invalid opcode: 0000 [#1] SMP <4>[ 14.916187] Modules linked in: ohci_hcd radeon(+) ttm drm_kms_helper drm i2c_algo_bit ehci_hcd i2c_core usbcore processor thermal_sys hwmon dm_mod xenblk cdrom xennet ata_generic pata_atiixp <4>[ 14.916193] <4>[ 14.916195] Pid: 173, comm: modprobe Not tainted 3.1.9-1.4-xen #1 MSI MS-7641/880GMA-E35(FX) (MS-7641) <4>[ 14.916197] EIP: 0061:[<edf4e17c>] EFLAGS: 00010246 CPU: 3 <4>[ 14.916206] EIP is at drm_vblank_put+0x4c/0x50 [drm] <4>[ 14.916208] EAX: 00000000 EBX: c1597780 ECX: c191ec00 EDX: c1597780 <4>[ 14.916209] ESI: 00000000 EDI: 00000000 EBP: c191ed70 ESP: c1ae58f0 <4>[ 14.916210] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 <0>[ 14.916212] Process modprobe (pid: 173, ti=c1ae4000 task=c1a4e1f0 task.ti=c1ae4000) <0>[ 14.916213] Stack: <4>[ 14.916214] c191ec00 edf4e4e1 e233c000 c191ec00 e22b1000 e233c000 ee3f44ba e233c000 <4>[ 14.916217] c191eea0 c191eea4 ee3f457a ee484de0 ede89a18 00000004 ede8baf7 ede8b448 <4>[ 14.916219] ede8b7cc 0000000c edf6d340 00000020 e223f290 c1ae5a40 c1ae5974 e223f280 <0>[ 14.916221] Call Trace: <4>[ 14.916240] [<edf4e4e1>] drm_vblank_post_modeset+0x81/0x90 [drm] <4>[ 14.916267] [<ee3f44ba>] atombios_crtc_dpms+0x5a/0x110 [radeon] <4>[ 14.916300] [<ee3f457a>] atombios_crtc_commit+0xa/0x20 [radeon] <4>[ 14.916322] [<ede89a18>] drm_crtc_helper_set_mode+0x248/0x310 [drm_kms_helper] <4>[ 14.916329] [<ede8a86a>] drm_crtc_helper_set_config+0x7ba/0x950 [drm_kms_helper] <4>[ 14.916335] [<ede88b17>] drm_fb_helper_set_par+0x57/0xc0 [drm_kms_helper] <4>[ 14.916341] [<c0281bdb>] fbcon_init+0x55b/0x5b0 <4>[ 14.916347] [<c02d9823>] visual_init+0xb3/0x160 <4>[ 14.916350] [<c02d9cf1>] bind_con_driver+0x1f1/0x420 <4>[ 14.916353] [<c02da06a>] take_over_console+0x4a/0x60 <4>[ 14.916356] [<c027ce38>] fbcon_takeover+0x68/0xc0 <4>[ 14.916359] [<c048b8f6>] notifier_call_chain+0x46/0x60 <4>[ 14.916363] [<c005f344>] __blocking_notifier_call_chain+0x44/0x70 <4>[ 14.916367] [<c005f387>] blocking_notifier_call_chain+0x17/0x20 <4>[ 14.916369] [<c02740e5>] do_register_framebuffer+0x175/0x270 <4>[ 14.916372] [<c02741f4>] register_framebuffer+0x14/0x30 <4>[ 14.916374] [<ede88cfd>] drm_fb_helper_single_fb_probe+0x17d/0x2e0 [drm_kms_helper] <4>[ 14.916379] [<ede88ee1>] drm_fb_helper_initial_config+0x81/0xa0 [drm_kms_helper] <4>[ 14.916397] [<ee41a6f8>] radeon_fbdev_init+0x88/0xf0 [radeon] <4>[ 14.916457] [<ee413df6>] radeon_modeset_init+0x126/0x160 [radeon] <4>[ 14.916510] [<ee3ed94b>] radeon_driver_load_kms+0xdb/0x140 [radeon] <4>[ 14.916533] [<edf52591>] drm_get_pci_dev+0x151/0x260 [drm] <4>[ 14.916548] [<c025eee2>] local_pci_probe+0x42/0xb0 <4>[ 14.916551] [<c025ff61>] pci_device_probe+0x71/0x90 <4>[ 14.916554] [<c02f07df>] really_probe+0x5f/0x210 <4>[ 14.916557] [<c02f0af4>] driver_probe_device+0x44/0xa0 <4>[ 14.916560] [<c02f0bc9>] __driver_attach+0x79/0x80 <4>[ 14.916562] [<c02ef9b1>] bus_for_each_dev+0x41/0x70 <4>[ 14.916564] [<c02f05d9>] driver_attach+0x19/0x20 <4>[ 14.916567] [<c02f0267>] bus_add_driver+0x187/0x280 <4>[ 14.916569] [<c02f107f>] driver_register+0x5f/0x100 <4>[ 14.916571] [<c025f82d>] __pci_register_driver+0x3d/0xb0 <4>[ 14.916574] [<c0004033>] do_one_initcall+0x33/0x180 <4>[ 14.916577] [<c0074ca7>] sys_init_module+0xa7/0x210 <4>[ 14.916580] [<c048866d>] syscall_call+0x7/0xb <4>[ 14.916583] [<b77c540e>] 0xb77c540d <0>[ 14.916584] Code: ed 85 d2 75 02 5b c3 69 c2 fa 00 00 00 ba d3 4d 62 10 8b 1d c0 60 7a c0 f7 e2 8d 81 88 01 00 00 c1 ea 06 01 da 5b e9 c4 b8 0f d2 <0f> 0b 66 90 55 57 89 cf 56 89 d6 53 b9 d0 80 00 00 83 ec 48 8b <0>[ 14.916595] EIP: [<edf4e17c>] drm_vblank_put+0x4c/0x50 [drm] SS:ESP 0069:c1ae58f0
but nomodeset argument seems to fix the problem. Going over the comments I don't think this argument was ever tested.
"nomodeset" was tried, albeit together with "x11failsafe", as indicated by the filenames (kmsg_with*_nomodeset_and_x11failsafe) in the attachment in the original description. (In reply to comment #15)
Jan: I could give you the console output with debug options, if that helps you.
Please do so for reference, although I have little hope that this helps (unless you had added drm.ko's "debug=7" option, and would include a similar log for the native kernel). I rather think that you or we need to debug it on an affected machine (possibly paired with identifying how far back in the kernel history the problem reaches, particularly whether e.g. SLE11 SP2's 3.0-based kernel is also affected). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c17 --- Comment #17 from Boris Ostrovsky <boris.ostrovsky@amd.com> 2012-03-21 10:48:54 UTC --- (In reply to comment #16)
(In reply to comment #14)
I was able to reproduce this (although it's a bit difficult to be sure what "this" is)
"this" is a pretty clear and obvious BUG() instance visible in the logs: ..
but nomodeset argument seems to fix the problem. Going over the comments I don't think this argument was ever tested.
"nomodeset" was tried, albeit together with "x11failsafe", as indicated by the filenames (kmsg_with*_nomodeset_and_x11failsafe) in the attachment in the original description.
Then what I (and I believe Conny) saw is different. There are way too many logs here to see what exactly is the problem. I saw a couple of screenshots that were similar to what I observed.
I rather think that you or we need to debug it on an affected machine (possibly paired with identifying how far back in the kernel history the problem reaches, particularly whether e.g. SLE11 SP2's 3.0-based kernel is also affected).
Is there a description of that system, other than looking at dmesgs? Like lspci and dmidecode? (Again, it may be already there and I just don't see it) (I am out of office until Monday) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c18 --- Comment #18 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-21 11:27:13 UTC --- (In reply to comment #16)
(In reply to comment #14)
I was able to reproduce this (although it's a bit difficult to be sure what "this" is)
"this" is a pretty clear and obvious BUG() instance visible in the logs:
<2>[ 14.916183] kernel BUG at /home/abuild/rpmbuild/BUILD/kernel-xen-3.1.9/linux-3.1/drivers/gpu/drm/drm_irq.c:934! <0>[ 14.916185] invalid opcode: 0000 [#1] SMP <4>[ 14.916187] Modules linked in: ohci_hcd radeon(+) ttm drm_kms_helper drm i2c_algo_bit ehci_hcd i2c_core usbcore processor thermal_sys hwmon dm_mod xenblk cdrom xennet ata_generic pata_atiixp <4>[ 14.916193] <4>[ 14.916195] Pid: 173, comm: modprobe Not tainted 3.1.9-1.4-xen #1 MSI MS-7641/880GMA-E35(FX) (MS-7641) <4>[ 14.916197] EIP: 0061:[<edf4e17c>] EFLAGS: 00010246 CPU: 3 <4>[ 14.916206] EIP is at drm_vblank_put+0x4c/0x50 [drm] <4>[ 14.916208] EAX: 00000000 EBX: c1597780 ECX: c191ec00 EDX: c1597780 <4>[ 14.916209] ESI: 00000000 EDI: 00000000 EBP: c191ed70 ESP: c1ae58f0 <4>[ 14.916210] DS: 007b ES: 007b FS: 00d8 GS: 0033 SS: 0069 <0>[ 14.916212] Process modprobe (pid: 173, ti=c1ae4000 task=c1a4e1f0 task.ti=c1ae4000) <0>[ 14.916213] Stack: <4>[ 14.916214] c191ec00 edf4e4e1 e233c000 c191ec00 e22b1000 e233c000 ee3f44ba e233c000 <4>[ 14.916217] c191eea0 c191eea4 ee3f457a ee484de0 ede89a18 00000004 ede8baf7 ede8b448 <4>[ 14.916219] ede8b7cc 0000000c edf6d340 00000020 e223f290 c1ae5a40 c1ae5974 e223f280 <0>[ 14.916221] Call Trace: <4>[ 14.916240] [<edf4e4e1>] drm_vblank_post_modeset+0x81/0x90 [drm] <4>[ 14.916267] [<ee3f44ba>] atombios_crtc_dpms+0x5a/0x110 [radeon] <4>[ 14.916300] [<ee3f457a>] atombios_crtc_commit+0xa/0x20 [radeon] <4>[ 14.916322] [<ede89a18>] drm_crtc_helper_set_mode+0x248/0x310 [drm_kms_helper] <4>[ 14.916329] [<ede8a86a>] drm_crtc_helper_set_config+0x7ba/0x950 [drm_kms_helper] <4>[ 14.916335] [<ede88b17>] drm_fb_helper_set_par+0x57/0xc0 [drm_kms_helper] <4>[ 14.916341] [<c0281bdb>] fbcon_init+0x55b/0x5b0 <4>[ 14.916347] [<c02d9823>] visual_init+0xb3/0x160 <4>[ 14.916350] [<c02d9cf1>] bind_con_driver+0x1f1/0x420 <4>[ 14.916353] [<c02da06a>] take_over_console+0x4a/0x60 <4>[ 14.916356] [<c027ce38>] fbcon_takeover+0x68/0xc0 <4>[ 14.916359] [<c048b8f6>] notifier_call_chain+0x46/0x60 <4>[ 14.916363] [<c005f344>] __blocking_notifier_call_chain+0x44/0x70 <4>[ 14.916367] [<c005f387>] blocking_notifier_call_chain+0x17/0x20 <4>[ 14.916369] [<c02740e5>] do_register_framebuffer+0x175/0x270 <4>[ 14.916372] [<c02741f4>] register_framebuffer+0x14/0x30 <4>[ 14.916374] [<ede88cfd>] drm_fb_helper_single_fb_probe+0x17d/0x2e0 [drm_kms_helper] <4>[ 14.916379] [<ede88ee1>] drm_fb_helper_initial_config+0x81/0xa0 [drm_kms_helper] <4>[ 14.916397] [<ee41a6f8>] radeon_fbdev_init+0x88/0xf0 [radeon] <4>[ 14.916457] [<ee413df6>] radeon_modeset_init+0x126/0x160 [radeon] <4>[ 14.916510] [<ee3ed94b>] radeon_driver_load_kms+0xdb/0x140 [radeon] <4>[ 14.916533] [<edf52591>] drm_get_pci_dev+0x151/0x260 [drm] <4>[ 14.916548] [<c025eee2>] local_pci_probe+0x42/0xb0 <4>[ 14.916551] [<c025ff61>] pci_device_probe+0x71/0x90 <4>[ 14.916554] [<c02f07df>] really_probe+0x5f/0x210 <4>[ 14.916557] [<c02f0af4>] driver_probe_device+0x44/0xa0 <4>[ 14.916560] [<c02f0bc9>] __driver_attach+0x79/0x80 <4>[ 14.916562] [<c02ef9b1>] bus_for_each_dev+0x41/0x70 <4>[ 14.916564] [<c02f05d9>] driver_attach+0x19/0x20 <4>[ 14.916567] [<c02f0267>] bus_add_driver+0x187/0x280 <4>[ 14.916569] [<c02f107f>] driver_register+0x5f/0x100 <4>[ 14.916571] [<c025f82d>] __pci_register_driver+0x3d/0xb0 <4>[ 14.916574] [<c0004033>] do_one_initcall+0x33/0x180 <4>[ 14.916577] [<c0074ca7>] sys_init_module+0xa7/0x210 <4>[ 14.916580] [<c048866d>] syscall_call+0x7/0xb <4>[ 14.916583] [<b77c540e>] 0xb77c540d <0>[ 14.916584] Code: ed 85 d2 75 02 5b c3 69 c2 fa 00 00 00 ba d3 4d 62 10 8b 1d c0 60 7a c0 f7 e2 8d 81 88 01 00 00 c1 ea 06 01 da 5b e9 c4 b8 0f d2 <0f> 0b 66 90 55 57 89 cf 56 89 d6 53 b9 d0 80 00 00 83 ec 48 8b <0>[ 14.916595] EIP: [<edf4e17c>] drm_vblank_put+0x4c/0x50 [drm] SS:ESP 0069:c1ae58f0
but nomodeset argument seems to fix the problem. Going over the comments I don't think this argument was ever tested.
"nomodeset" was tried, albeit together with "x11failsafe", as indicated by the filenames (kmsg_with*_nomodeset_and_x11failsafe) in the attachment in the original description.
(In reply to comment #15)
Jan: I could give you the console output with debug options, if that helps you.
Please do so for reference, although I have little hope that this helps (unless you had added drm.ko's "debug=7" option, and would include a similar log for the native kernel). I rather think that you or we need to debug it on an affected machine (possibly paired with identifying how far back in the kernel history the problem reaches, particularly whether e.g. SLE11 SP2's 3.0-based kernel is also affected).
(In reply to comment #16) I don't understand the last lines of this comment. Then I was demanded to produce this material. I have it done and uploaded under '/var/log after desktop boot and xen boot with drm.debug=7' (s. under attached files). In the messages files are a lot of drm messages. I have thought that this could help you mainly because there are possebilities for comparisions. Jan: With my question 'What can I do for you else?' I had in sense that I give you access to my system so that you can search needed information. There no secrets on my computer and I have full confidence in the openSUSE community (since release 6.3). You must say, however, I set up the access (remember: I am stupid user). Clearly, I upload nothing - it be you request it. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c19 Conny Seidel <conny.seidel@amd.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|Normal |Major --- Comment #19 from Conny Seidel <conny.seidel@amd.com> 2012-03-21 14:17:20 UTC ---
(In reply to comment #16) I don't understand the last lines of this comment. Then I was demanded to produce this material. I have it done and uploaded under '/var/log after desktop boot and xen boot with drm.debug=7' (s. under attached files). In the messages files are a lot of drm messages. I have thought that this could help you mainly because there are possebilities for comparisions.
I think that comment was meant for me. Alex Deucher said it could be fixed with the ttm patches from Oracle, which went into kernel v3.3. So I installed the XEN-Kernel-of-the-day 3.3 and the issue with the radeon/drm module is gone. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c20 --- Comment #20 from Jan Beulich <jbeulich@suse.com> 2012-03-21 14:54:12 UTC --- (In reply to comment #19)
Alex Deucher said it could be fixed with the ttm patches from Oracle, which went into kernel v3.3. So I installed the XEN-Kernel-of-the-day 3.3 and the issue with the radeon/drm module is gone.
Thanks, Conny, that's good to know. What patches are you referring to? (We'd have to have our video folks take a look in any case to determine whether backporting is reasonable.) Wolfgang - any chance you could give a newer kernel a try as well? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c21 --- Comment #21 from Conny Seidel <conny.seidel@amd.com> 2012-03-21 15:26:45 UTC --- I think Alex meant these TTM patches starting with: commit 2334b75ffbef6b8932f09ec4418b65ddb764ae99 Author: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com> Date: Thu Nov 3 16:46:34 2011 -0400 drm/ttm: provide dma aware ttm page pool code V9. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c22 Jan Beulich <jbeulich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #22 from Jan Beulich <jbeulich@suse.com> 2012-03-21 16:16:25 UTC --- Hmm, I'm afraid those wouldn't be acceptable for backporting - Takashi? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c23 --- Comment #23 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-21 16:42:34 UTC --- (In reply to comment #20)
(In reply to comment #19)
Alex Deucher said it could be fixed with the ttm patches from Oracle, which went into kernel v3.3. So I installed the XEN-Kernel-of-the-day 3.3 and the issue with the radeon/drm module is gone.
Thanks, Conny, that's good to know. What patches are you referring to? (We'd have to have our video folks take a look in any case to determine whether backporting is reasonable.)
Wolfgang - any chance you could give a newer kernel a try as well?
Clear if it serves the cause. But I need some time. Tonigth I set up a backup for the entire system. Then I would try to run an update to openSUSE 12.2 . I hope that the under openSUSE 12.2 offered kernel the kernel is that you mean as the'newer kernel'. If not then stop me and say which kernel I should install. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c24 --- Comment #24 from Conny Seidel <conny.seidel@amd.com> 2012-03-21 16:46:58 UTC --- I used this one: http://en.opensuse.org/openSUSE:Kernel_of_the_day -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c25 --- Comment #25 from Jan Beulich <jbeulich@suse.com> 2012-03-21 16:50:33 UTC --- Indeed I would not recommend updating anything but the kernel (and - not now, but from a theoretical pov - the hypervisor). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c26 --- Comment #26 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-24 16:25:29 UTC --- I have installed KOTD 3.3.0-3-default from http://en.opensuse.org/openSUSE:Kernel_of_the_day. Under openSUSE 12.1 it is running without problems. But how can I get or generate a Xen_kernel_of_the_day resp. a Xen_kernel based on 3.3? By the way xen,org doesn't offer a newer version of xen hypervisor as 4.1.2 (which I have always used). -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c27 --- Comment #27 from Conny Seidel <conny.seidel@amd.com> 2012-03-25 21:27:39 UTC --- Why didn't you install the target: kernel-xen from this repository? At least that's what I would have expected you to install. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c28 --- Comment #28 from Jan Beulich <jbeulich@suse.com> 2012-03-26 08:03:10 UTC --- (In reply to comment #26)
But how can I get or generate a Xen_kernel_of_the_day resp. a Xen_kernel based on 3.3?
It's not clear to me what you're trying to find out.
By the way xen,org doesn't offer a newer version of xen hypervisor as 4.1.2 (which I have always used).
4.1.2 is the newest released version of Xen - anything newer is development (unstable or testing) code only. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c29 --- Comment #29 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-03-26 14:18:22 UTC --- Excuse my boundless incompetence. I can well imagine how you were confused. The sentence on the page http://en.opensuse.org/openSUSE:Kernel_of_the_day 'There are various flavors ...' I didn't see to replace kernel-default through kernel-xen in the subsequent 'zypper install ...' statement. Thank you for your help. I have now installed vmlinuz-3.3.0-4-xen according to the above page. A boot shows the same problems: Ending with a screen of kernel messages, not starting xdm and no reaction of keyboard and mouse. Also there are no messages of xen and/or the kernel in /var/log/messages. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c30 --- Comment #30 from Jan Beulich <jbeulich@suse.com> 2012-03-26 14:29:50 UTC --- Then I'm afraid what the AMD folks "reproduced" above is a different issue, which means we're back to needing all the debugging info to come from you. (As to no Xen messages in /var/log/messages, I think I had pointed out before that those don't go there, but instead you'll need to set up a serial console.) -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c31 --- Comment #31 from Jan Beulich <jbeulich@suse.com> 2012-05-22 14:33:46 UTC --- Ping? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c32 --- Comment #32 from Wolfgang Trier <trier@rrz.uni-koeln.de> 2012-05-22 16:47:17 UTC --- They have taken the initiative out of my hand. Due to health problems I have the bug for a while lost something out of my eyes. I do not think that I bought from amazon as induvidual on the world a computer supplied by Shin Bee with AMD processors which runs under OpenSUSE and want to use XEN. And now? -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c33 Jan Beulich <jbeulich@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEEDINFO |CLOSED InfoProvider|trier@rrz.uni-koeln.de | Resolution| |NORESPONSE --- Comment #33 from Jan Beulich <jbeulich@suse.com> 2012-07-06 15:04:16 UTC --- I don't think there's anything we can do here then, unless we find a way to reproduce this. -- Configure bugmail: https://bugzilla.novell.com/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠novell.com