https://bugzilla.novell.com/show_bug.cgi?id=752296 https://bugzilla.novell.com/show_bug.cgi?id=752296#c Jan Beulich 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#c2 --- Comment #2 from Jan Beulich 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#c4 --- Comment #4 from Wolfgang Trier 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#c6 --- Comment #6 from Wolfgang Trier 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#c8 --- Comment #8 from Jan Beulich 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#c10 --- Comment #10 from Jan Beulich 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#c12 --- Comment #12 from Jan Beulich 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#c14 --- Comment #14 from Boris Ostrovsky 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#c16 --- Comment #16 from Jan Beulich 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#c18 --- Comment #18 from Wolfgang Trier 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#c20 --- Comment #20 from Jan Beulich 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#c22 Jan Beulich changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tiwai@suse.com --- Comment #22 from Jan Beulich 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#c24 --- Comment #24 from Conny Seidel 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#c26 --- Comment #26 from Wolfgang Trier 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#c28 --- Comment #28 from Jan Beulich 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#c30 --- Comment #30 from Jan Beulich 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#c32 --- Comment #32 from Wolfgang Trier 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.