grub-devel
[Top][All Lists]
Advanced

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

Re: Big Endian fix patch


From: Vladimir 'φ-coder/phcoder' Serbinenko
Subject: Re: Big Endian fix patch
Date: Mon, 13 Sep 2010 21:54:53 +0200
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.11) Gecko/20100805 Icedove/3.0.6

On 07/28/2010 10:51 AM, Doug Nazar wrote:
>  On 2010-07-27 11:26 AM, Lennart Sorensen wrote:
>> On Mon, Jul 26, 2010 at 09:00:53PM -0400, Doug Nazar wrote:
>>
>>> I'll run it through the grinder in a bit.
>> So with my patch I am booting of the md raid1 very successfully (other
>> than manually having to fix grub-mkimage run since grub-install doesn't
>> understand the machine yet.  I am working on fixing that now.)
>
> Ok, finally made some progress. Ran into several issues, some of them
> obviously QEMU/OpenBios that I'm not sure if GRUB should work around.
> With your patch the raid mostly worked, small problem with too many
> devices because OpenBios creates several aliases for some devices.
> Also I think you missed the endianess when setting the level.
>
> This patch includes the following:
>
> - Fix the ofdisk_hash system. We weren't making a copy of the devpath
> so never found the cached item again.
> - Extend the ofdisk_hash to cache the disk size
> - Scan for a disk size using seek (probably want to set a different
> start size). Required for metadata 1.0 arrays
> - Optimize checking of raid level
> - If we find a duplicate disk (claims to be same index in the array),
> skip it or else level 0 arrays wont be found
> - QEMU/OpenBios doesn't seem to like if the prev & name parameters of
> ieee1275_next_property are the same pointer which caused no devices to
> be found
>
I merged ofdisk branch so I believe most of these fixes aren't necessary
anymore except determining the disk size. Some firmwares seem to react
badly to size scanning (like my Netra X-1 does). How long does it take
on your system? Perhaps we should introduce a separate function
-get_disk_size_really_need_it on disk device which is used for the case
like this when total_sectors is set to UNKNOWN but it's needed for
something more substantial then reporting to user or sanity checks.
Could you adjust your patch accordingly?
> The issues that I came across which are in QEMU/OpenBios:
>
> - The rows are misreported. screen-#rows is set to 75 when in fact
> there are only 60 rows. Worked around using -prom-env parameter
> - Aliases don't take into account the index (i.e. address@hidden). I ended up
> with
>     disk /pci/pci-ata/ata-1/disk
>     hd /pci/pci-ata/ata-1/disk
>     ide0 /pci/pci-ata/ata-1/disk
>     ide1 /pci/mac-io/ata-3/disk
>     ide2 /pci/mac-io/ata-3/disk
>
> when ide1 should be address@hidden and ide2 should be address@hidden
> - boot command hangs when passed wrong disk or used from boot-command.
> Worked around by using load & go
>
> Things do work, and fixing QEMU/OpenBios is a bit further down the
> rabbit hole than I want to go. ;-)
>
> Thanks,
> Doug
>
>
> _______________________________________________
> Grub-devel mailing list
> address@hidden
> http://lists.gnu.org/mailman/listinfo/grub-devel
>   


-- 
Regards
Vladimir 'φ-coder/phcoder' Serbinenko


Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]