> On Feb 16, 2016, at 11:45 PM, Seth Goldberg <seth.goldb...@oracle.com> wrote:
>
>
>
>> On Feb 16, 2016, at 7:24 PM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>
>> 17.02.2016 05:02, Eric Snowberg пишет:
>>>
>>>> On Feb 16, 2016, at 1:16 AM, Andrei Borzenkov <arvidj...@gmail.com> wrote:
>>>>
>>>> On Mon, Feb 15, 2016 at 10:11 PM, Eric Snowberg
>>>> <eric.snowb...@oracle.com> wrote:
>>>>> Fix the open firmware path property for sun4v SPARC systems. These
>>>>> platforms do not have a /sas/ within their path. Over time
>>>>> different OF addressing schemes have been supported. There
>>>>> is no generic addressing scheme that works across every HBA.
>>>>>
>>>>> Signed-off-by: Eric Snowberg <eric.snowb...@oracle.com>
>>>>> ---
>>>>> grub-core/osdep/linux/ofpath.c | 192
>>>>> +++++++++++++++++++++++++++++++++++++++-
>>>>> 1 files changed, 190 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/grub-core/osdep/linux/ofpath.c
>>>>> b/grub-core/osdep/linux/ofpath.c
>>>>> index a79682a..de51c57 100644
>>>>> --- a/grub-core/osdep/linux/ofpath.c
>>>>> +++ b/grub-core/osdep/linux/ofpath.c
>>>> ...
>>>>> @@ -444,6 +525,111 @@ of_path_of_scsi(const char *sys_devname
>>>>> __attribute__((unused)), const char *dev
>>>>> }
>>>>> else
>>>>> {
>>>>> +#ifdef __sparc__
>>>>> + int vendor = 0, device_id = 0;
>>>>> + check_hba_identifiers(sysfs_path, &vendor, &device_id);
>>>>> +
>>>>> + if (vendor == 0x1000) /* LSI Logic Vendor ID */
>>>>> + {
>>>>> + /* Over time different OF addressing schemes have been
>>>>> supported */
>>>>> + /* There is no generic addressing scheme that works across */
>>>>> + /* every HBA */
>>>>> + switch (device_id)
>>>>> + {
>>>>> + case 0x30: /* Rhea, Jasper 320, LSI53C1020/1030 */
>>>>> + case 0x50: /* SAS-1068E */
>>>>> + case 0x56: /* SAS-1064E */
>>>>> + case 0x58: /* Pandora SAS-1068E */
>>>>> + case 0x5d: /* Aspen, Invader, LSI SAS-3108 */
>>>>> + case 0x79: /* Niwot, SAS 2108 */
>>>>
>>>> That really does not scale. Can we enumerate device aliases and take
>>>> diskN and cdromN? So that we do not need to duplicate OBP logic?
>>>
>>> Do you have an idea in mind on how to do this differently to make it scale
>>> better? This patch will default to the old disk@N for unknown HBAs. I
>>> agree it doesn’t scale that well, but new HBAs for SPARC with OF support
>>> don't come out that often.
>>>
>>> Before this patch, there isn’t a single SAS HBA that is enumerated
>>> correctly on SPARC. I went back 10 years and believe I have added every
>>> HBA with OF support. This isn’t duplicating OBP logic. The final part of
>>> the device path is vendor specific. OBP does not control that part of the
>>> path, it just uses it. Unfortunately there isn’t a standard. This code
>>> only gets run during setup/install (not boot) to return the path for OBP to
>>> use.
>>>
>>> You mentioned cdroms being enumerated with cdromN. I believe that type of
>>> enumeration stopped with IDE drives. A USB cdrom would be enumerated
>>> something like this:
>>>
>>> /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
>>>
>>> So the function that runs during boot: check_string_removable does not
>>> identify the cdrom properly.
>>>
>>> I’m open to making any changes to this patch if you have some ideas in
>>> mind. I tried to base it off of what was already in ofpath.c and I have
>>> some follow on patches coming the rely on this path being correct.
>>
>> I mean to read device aliases created by OBP (those displayed by
>> devalias OBP command).
>>
>> disk0 /pci@308/pci@1/usb@0/hub@1/storage@1/disk@0
>
> Devaliases are not guaranteed to be there for all devices. It is highly
> dependent on the system vendor to create them and we certainly have systems
> with disk drives that have no aliases.
>
> —S
And we also have systems with pre-populated devaliases for disks that don’t
exist (that could be added in the future). This is part of the reason why it
can take 20 - 30 minutes to get to the grub menu on some SPARC systems. On
boot, grub builds a tree from the devaliases and then tries to open and close
disks that don’t exist. The HBA finally times out.
But we are getting ahead of things here, since the patch I submitted only
starts to solve this problem. This will be fixed in later patches.
>
>
>
>> ...
>>
>> _______________________________________________
>> Grub-devel mailing list
>> Grub-devel@gnu.org
>> https://lists.gnu.org/mailman/listinfo/grub-devel
>
> _______________________________________________
> Grub-devel mailing list
> Grub-devel@gnu.org
> https://lists.gnu.org/mailman/listinfo/grub-devel
_______________________________________________
Grub-devel mailing list
Grub-devel@gnu.org
https://lists.gnu.org/mailman/listinfo/grub-devel
