Bug 840507
Summary: | grub2 gets stuck in an infinite loop on qemu | ||
---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | IBM Bug Proxy <bugproxy> |
Component: | grub2 | Assignee: | Peter Jones <pjones> |
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> |
Severity: | high | Docs Contact: | |
Priority: | unspecified | ||
Version: | 17 | CC: | dennis, gustavold, jkachuck, mads, pjones, wgomerin |
Target Milestone: | --- | ||
Target Release: | --- | ||
Hardware: | ppc64 | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | Bug Fix | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2013-01-20 16:42:52 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
IBM Bug Proxy
2012-07-16 14:01:06 UTC
------- Comment From bherren.com 2012-07-18 22:51 EDT------- So I'm going to use this bug as a place for a more complete discussion on the problem of having the appropriate unit addresses (the last @xxx part) in OFW path. Can somebody make sure we have the right grub2 people CCed on the redhat side ? So the unit address is more or less adapter specific. Each adapter firmware has its own way of encoding it unfortunately. We can start building specific knowledge about each adapter type in our grub2 configuration script (fortunately we have a limited number of supported adapters with OF firmwares on them), but it might be better to seek a solution involving the kernel drivers knowing about the methods used by the firmware for the specific adapters it drives. I'm adding Brian on CC who might help discuss that from a SCSI driver perspective. Ideally we'd want to add a "devspec" attribute to the sysfs nodes of the disks. So I've collected some info about a couple of common adapters. First VSCSI: The unit address for vscsi is the SRP "LUN" value (which is not the same as the SCSI LUN). The formula to calculate it can be found in the linux driver: static inline u16 lun_from_dev(struct scsi_device *dev) { return (0x2 << 14) | (dev->id << 8) | (dev->channel << 5) | dev->lun; } Currently, SLOF in qemu doesn't use the above formula however, but I will change it ASAP so grub2 doesnt have to deal with two different methods for vscsi. Then we have IPR/Obsidian. This itself falls into two categories, the newer "SIS64" variants, which you can recognize via the presence of an "ibm,sis64" property in the adapter device node, and the older "SIS32" variants which don't have this property. For SIS32, the unit address is a "resource address" of the form (bus << 16) | (id << 8) | lun However, bus can be 0xff when using HW RAID For SIS64, the unit address is the SAS WWN of the disk (though it might get appended a ",lun" when applicable, we need to double check that) So here we'll have to detect the adapter type, we'll also need to be careful that below the adpater PCI device in the device-tree can be a "functional" sub node to differenciate SAS from SATA which some of those support (for the optical drive). I don't know what the address encoding scheme is for SATA btw, I'll try to find it out later. Due to the above complexity, it's clearly a piece of logic that is best located in the IPR driver itself, which could either expose an ioctl to retrieve a disk unit address or better, would create sysfs devspec attributes in the disk sysfs directories, but that won't happen immediately. I'm still trying to get more info about other supported adapters such as our fiber channel ones. Additionally, there are some methods that our adapter firmwares provide that can be called within the OFW environment to retrieve lists of attached devices. Those are used by the SMS menu system, and would be handy for grub2 to be able to use as well in some cases, to display fallback menus of devices maybe, that sort of thing... I'm in the process of obtaining the documentation for these and will update this BZ when I have it. ------- Comment From bjking1.com 2012-07-18 23:04 EDT------- Is there any reason that grub2 can't use the ofpathname script that is included in powerpc-utils to translate from a logical device name (i.e. /dev/sda) to an OF path name? There are far too many different pieces of code trying to do this translation, which makes it nearly impossible to keep them all up to date when the OF binding changes. As for doing something in the ipr driver itself, the ipr driver does expose some attributes in sysfs that the ofpathname script uses in order to be able to build the OF path, but they still require some intelligence to know how to use them. However, I'm not convinced that adding a devspec to the ipr driver for each device is the right answer, since there are plenty of other I/O adapters that need special treatment as well - LSI SAS, QLogic FC, Emulex FC, VSCSI, VFC, and more... ------- Comment From pfsmorigo.com 2012-07-19 00:31 EDT------- I tested ofpathname here and it shows the id in the pHyp's OFW format: [root@localhost target0:0:0]# ofpathname /dev/sda1 /vdevice/v-scsi@1002/disk@8000000000000000 I discover that the boot-device was blank after the instalation: 0 > printenv ---environment variable--------current value-------------default value------ use-axon-ddr? true true real-mode? true true direct-serial? false false use-nvramrc? false false selftest-#megs 0 0 security-password security-mode 0 0 security-#badlogins 0 0 screen-#rows 200 200 screen-#columns 200 200 output-device oem-logo? false false oem-logo oem-banner? false false oem-banner nvramrc input-device fcode-debug? true true diag-switch? false false diag-file diag-device boot-command boot boot boot-file boot-device auto-boot? true true The device tree and the alias: 0 > ls 3e597a18 : /vdevice 3e597c98 : |-- vty@1000 3e597e70 : |-- l-lan@1001 3e5981f8 : +-- v-scsi@1002 3e5b7368 : |-- disk@0,0 3e5b7a58 : +-- cdrom@2,0 ok 0 > devalias scsi : /vdevice/v-scsi@1002 cdrom : /vdevice/v-scsi@1002/cdrom@2,0 disk : /vdevice/v-scsi@1002/disk@0,0 net : /vdevice/l-lan@1001 hvterm : /vdevice/vty@1000 ok I set the boot-device and the system booted: setenv boot-device disk ------- Comment From bherren.com 2012-07-19 01:10 EDT------- So to begin with, I wasn't even aware we had an ofpathname script in powerpc-utils :-) As for the problem with qemu vs. OFW using a different format for vscsi, as I said in my previous post, I will fix that in qemu/SLOF, hopefully later today. ------- Comment From bherren.com 2012-07-19 01:13 EDT------- BTW. We should also make yaboot use ofpathname instead of its own built-in ofpath.... might cause some "interesting" dependencies but probably the way to go, a single script to rule them all and in the darkness of forth bind them ! ------- Comment From bherren.com 2012-07-19 06:58 EDT------- I've now fixed qemu to behave like vscsi. I've also added a vscsi-report-luns method (which unlike OFW one supports multiple SCSI IDs which from what I can tell grub will parse properly). This makes grub2 works in qemu for me. I've pushed the fixes to github and will submit a qemu patch to get a new build of SLOF upstream. So can we close this out, then? |