[Top][All Lists]

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

Re: Big Endian fix patch

From: Doug Nazar
Subject: Re: Big Endian fix patch
Date: Wed, 28 Jul 2010 11:52:00 -0400
User-agent: Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv: Gecko/20100713 Thunderbird/3.1.1

 On 2010-07-28 11:00 AM, Lennart Sorensen wrote:

OK, no idea how I got by without that.  It is currently working for me.

I only use raid1 of course, so that is all I tested with.

It only mattered for multipath. Which is a kind of raid1 setup. Grub doesn't handle it too well since the underlying device is the same and has the same disk number. Before we'd overwrite the old path with the last path found and incorrectly increase nr_devs. With my patch we just ignore additional drives. So we'll die if we lose the path while booting but otherwise it'll find at least one of the paths.
- Fix the ofdisk_hash system. We weren't making a copy of the devpath so
never found the cached item again.
Could this have anything to do with why I can't see disks without
devaliases assigned?

No. This would only affect the disk cache subsystem (since the hash struct pointer was used as the disk id) and we'd be comparing the devpath with random memory.

QEMU/openbios has many bugs unfortunately.  If I could make any sense
of the code I would try to fix some of them, but I simply can't follow
that code.

I've got a basic idea how it all hangs together internally and I started to fix a few things in OpenBios but discovered the current source doesn't work with QEMU 0.12.5. "boot" stopped working and if I used "load" it started to work then complained that it was trying to overwrite OpenBios. Since I have no idea how the memory is supposed to be laid out I kinda backed away. Besides, Forth is not my first choice of languages to figure out.

I will give this patch a try on top of mine then and see how it behaves.

Thanks for testing,

reply via email to

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