Pkg xen devel - Sep 2013 - Bug#721946: Bug#721946: xen-hypervisor-4.1-amd64: dom0_mem cannot exceed some value

On Fri 06/Sep/2013 10:12:29 +0200 Ian Campbell wrote:
> On Thu, 2013-09-05 at 20:52 +0200, Alessandro Vesely wrote:
>> 
>> I tried GRUB_CMDLINE_XEN="dom0_mem=8192M":  that delivers
6964868K total, then
>> crashes when used=2837436K free=4127432K.
> 
> On a modern dom0 kernel you need to specify the maximum memory as well,
> i.e. dom0_mem=8192M,max:8192M
Nope, I tried the string you said, and got a crash.  I attach the log
file again, as there are some small differences between this boot and
the two ones in the previous attachment, that I am unable to
interpret.  The outstanding difference I see is:

BUG: unable to handle kernel paging request at ffff88013fc00000
Oops: 0002 [#1] SMP
BUG: scheduling while atomic: gimp-2.8/4922/0x10000001
BUG: unable to handle kernel paging request at ffff88013fe00000
Oops: 0002 [#2] SMP
BUG: scheduling while atomic: postgres/5960/0x10000001

Lines of those kind were present in the first log (dom0_mem=8192M) and
in this one (dom0_mem=8192M,max:8192M), but not in the second boot of
the first log (dom0_mem=2048M).  They are related to the black screen
behavior, correct?
> http://blog.xen.org/index.php/2012/04/30/memory-where-it-has-not-gone/
> has some background discussion.
Thanks for the pointer.  In the logs I find "register mmio base:
0xFEA30000".  Is that a byte address?  It would seem something could
change when passing from the 6G below it to higher values.  I only
tried 2G and 8G thus far.

Ale
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kern2.log
Type: text/x-log
Size: 112002 bytes
Desc: not available
URL:
<http://lists.alioth.debian.org/pipermail/pkg-xen-devel/attachments/20130906/35449506/attachment-0001.bin>

On Fri, 2013-09-06 at 16:39 +0200, Alessandro Vesely wrote:

Both sets of log contain stuff like:
> Sep  6 15:22:53 pcale kernel: [  126.828195] ata4.00: exception Emask 0x0
SAct 0x0 SErr 0x80000 action 0x6 frozen
> Sep  6 15:22:53 pcale kernel: [  126.828199] ata4: SError: { 10B8B }
> Sep  6 15:22:53 pcale kernel: [  126.828201] ata4.00: failed command: SMART
> Sep  6 15:22:53 pcale kernel: [  126.828205] ata4.00: cmd
b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0
> Sep  6 15:22:53 pcale kernel: [  126.828206]          res
40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
> Sep  6 15:22:53 pcale kernel: [  126.828207] ata4.00: status: { DRDY }
> Sep  6 15:22:53 pcale kernel: [  126.828211] ata4: hard resetting link
> Sep  6 15:22:54 pcale kernel: [  127.320197] ata4: SATA link up 3.0 Gbps
(SStatus 123 SControl 300)
> Sep  6 15:22:54 pcale kernel: [  127.321358] ata4.00: configured for
UDMA/133
> Sep  6 15:22:54 pcale kernel: [  127.336200] ata4: EH complete 
Is your disk dying?

Does this happen if you boot the exact same Linux kernel without Xen
underneath?

Ian.

On Fri 06/Sep/2013 17:05:15 +0200 Ian Campbell wrote:
> 
> Both sets of log contain stuff like:
> 
>> Sep  6 15:22:53 pcale kernel: [  126.828195] ata4.00: exception Emask
0x0 SAct 0x0 SErr 0x80000 action 0x6 frozen
>> Sep  6 15:22:53 pcale kernel: [  126.828199] ata4: SError: { 10B8B }
>> Sep  6 15:22:53 pcale kernel: [  126.828201] ata4.00: failed command:
SMART
>> Sep  6 15:22:53 pcale kernel: [  126.828205] ata4.00: cmd
b0/d8:00:00:4f:c2/00:00:00:00:00/00 tag 0
>> Sep  6 15:22:53 pcale kernel: [  126.828206]          res
40/00:ff:00:00:00/00:00:00:00:00/00 Emask 0x4 (timeout)
>> Sep  6 15:22:53 pcale kernel: [  126.828207] ata4.00: status: { DRDY }
>> Sep  6 15:22:53 pcale kernel: [  126.828211] ata4: hard resetting link
>> Sep  6 15:22:54 pcale kernel: [  127.320197] ata4: SATA link up 3.0
Gbps (SStatus 123 SControl 300)
>> Sep  6 15:22:54 pcale kernel: [  127.321358] ata4.00: configured for
UDMA/133
>> Sep  6 15:22:54 pcale kernel: [  127.336200] ata4: EH complete 
> 
> Is your disk dying?
Died already.  It was just an 80G Western Digital of 2005, but it
contained the Windows XP install that I wanted to run under Xen :-(
> Does this happen if you boot the exact same Linux kernel without Xen
> underneath?
Yes, but was never mounted.  Only update-grub reported read errors.