Created attachment 619795 [details] xm dmesg Description of problem: This issue began appears after update to kernel 3.5.4-2.fc17.x86_64 attached all files with relative informations Attached all This issue begin Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 619796 [details] xm info
Created attachment 619797 [details] lshw witch hardware details
This looks like an issue with the xen code in the kernel, not the xen package.
Please provide the 'dmesg' output.
Created attachment 620323 [details] dmesg
Hi, Supplied as requested. thanks
(In reply to comment #5) > Created attachment 620323 [details] > dmesg I am not seeing the WARN that this BZ is for?
please, look at the attached file xm dmesg
Sorry, look at the attached file dmesg.err
I found the source of "warnings" This problem happens if we don't use dom0_mem=xyz. When I limit the use of dom0 memory, the "warnings" stop.
So can you attach the dmesg with the warnings pls?
Created attachment 915501 [details] Comment (This comment was longer than 65,535 characters and has been moved to an attachment by Red Hat Bugzilla).
Can you use 'log_buf_len=2M' on your Linux command line to capture the full log pls? Depending on the size you might need a bigger number (4M?)
take a look if is what you want. if don't let me know.
Created attachment 620760 [details] dmesg w/ log_buf_len=4M
<sigh> We are going back and forth on this. What I need in the failing case is an idea of this: 0.000000] Freeing 9b-100 pfn range: 101 pages freed [ 0.000000] 1-1 mapping on 9b->100 [ 0.000000] Freeing bffb0-100000 pfn range: 262224 pages freed [ 0.000000] 1-1 mapping on bffb0->100000 ===>[ 0.000000] Released 262325 pages of unused memory ===>[ 0.000000] Set 262325 page(s) to 1-1 mapping ===>[ 0.000000] Populating 1f0f83-231038 pfn range: 262325 pages added [ 0.000000] e820: BIOS-provided physical RAM map: [ 0.000000] Xen: [mem 0x0000000000000000-0x000000000009afff] usable and also the first the WARN and the last one. I am trying to figure where it starts to warn you about over-writing the MFNs.
Then, my dmesg shows exactly what I'm sending to you. I repeated the process a few 20 times and the result is always the same that already send to you. I'll continue trying to generate a log and sending best for you so you can.
Was there any further progress on this bug? Does it still happen with the 3.6.11 or newer kernel updates?
I am 99% sure it got fixed - but I can't find the commit that fixed :-(
(In reply to comment #19) > I am 99% sure it got fixed - but I can't find the commit that fixed :-( That's OK. Your word is good enough. Plus, we haven't had any further reports of it that I know of, so let's close this out.