[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-users] UEFI Booting



On Thu, 2015-03-26 at 10:46 -0300, Carlos Gustavo Ramirez Rodriguez
wrote:
> Before trying to start from scratch and fixing another issue along the
> way, we hit, and now back at just One of this previously mentioned
> bugs.
> 
> 
> The first problem that stopped the Xen from working straight from the
> EFI option is now working, and xen is stuck at the same "second
> issue":
> 
> <> "
> <> [global]
> <> default=xen>
> <>
> <> [xen]
> <> options=console=vga loglvl=all noreboot
> <>
> <> kernel=vmlinuz-3.19.0-9-generic ignore_loglevel
> <
> <No root= etc? I'd expect this to include a bunch more stuff, which is
> <mostly the same as your native boot.
> 
> 
> I am still using these options, to boot, and they are based mostly on
> the http://xenbits.xenproject.org/docs/unstable/misc/efi.html page
> with a few diferences regarding console output to COM ports, what
> seems like a comment and the kernel version being used.

I think that those instructions are somewhat incomplete, you will
certainly need some sort of root= thing there, and most likely you will
need all the same parameters as if you were booting the kernel natively.


> <> Second Problem: After booting with the xen-4.5.1-pre.efi from
> REFIND
> <> Menu entry, the screen goes on loading drivers and everything goes
> <> right until these lines from dmesg (without timestamp, and skipping
> <> some entries:
> <> "
> <>
> <> ata10.00: failed to IDENTIFY (I/O error, err_mask=0x4)
> <> ...
> <> ata10: Link is slow to respond, please be patient (ready=0)
> <> ata10: COMRESET failed (errno=-16)
> <> ...
> <> ata10: limiting SATA link speed to 3.0 Gbps
> <> ata10: COMRESET failed (errno=-16)
> <> ata10: reset failed, giving up
> <
> <Do these happen on native boot too? Is ata10 the controller which
> <connects to your rootfs?
> 
> 
> Yes, the ata10 is the controller to my rootfs and, no, they don't
> happen on my native boot, the ata10 get it's ID correctly, and they
> don't fail with those COMRESET errors, from dmesg:

First step is to get the kernel command line to match your native case.

Then I wonder if you are seeing the same case as
http://lists.xen.org/archives/html/xen-devel/2014-04/msg01898.html and
that therefore pci-phantom=<something> is what is needed?

In the absence of complete logs I'm not sure what <something> is, but it
will be the PCI BDF of the problematic storage controller device.

Ian.



_______________________________________________
Xen-users mailing list
Xen-users@xxxxxxxxxxxxx
http://lists.xen.org/xen-users


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.