[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] qemu-system-ppc -m g3beige -hda is setting /dev/hdc on
Re: [Qemu-devel] qemu-system-ppc -m g3beige -hda is setting /dev/hdc on Linux.
Sat, 13 Feb 2010 12:27:21 -0600
KMail/1.11.2 (Linux/2.6.28-17-generic; KDE/4.2.2; x86_64; ; )
On Saturday 13 February 2010 04:28:44 Alexander Graf wrote:
> On 13.02.2010, at 09:02, Rob Landley wrote:
> > The -hda, -hdb, -hdc, and -hdd command line options for g3beige don't
> > match the order the kernel assigns the drives.
> > The reason is that the Linux kernel always initializes the cmd646 driver
> > before the pmac driver, thus if there's a cmd646 it gets /dev/hda and
> > /dev/hdb, and the pmac gets /dev/hdc and /dev/hdb.
> > If you only supply an -hda (and/or -hdb) with no -hdc or -hdd, then the
> > cmd646 driver never attaches to anything and only the pmac controller
> > shows up, thus -hda and -hdb set /dev/hda and /dev/hdb. But if you
> > specify a -hdc it shows up as /dev/hda every time, and kicks the -hda
> > entry to /dev/hdc.
> > Note that neither the kernel's CONFIG_BLK_DEV_IDE_PMAC_ATA100FIRST nor
> > CONFIG_IDEPCI_PCIBUS_ORDER made any difference, because those affect
> > multiple devices handled by the same driver, and this is a static driver
> > initialization order issue. When you statically link in both drivers,
> > cmd64x always probes before pmac due to the above hardwired device order
> > in the kernel, 100% reliable and deterministic. It's hardwired, and you
> > have to patch the kernel to change it.
> > Here's a patch to the Linux kernel that changes the device probe order so
> > the kernel behaves like g3beige is expecting it to:
> > --- a/drivers/ide/Makefile
> > +++ b/drivers/ide/Makefile
> > @@ -39,6 +39,7 @@
> > obj-$(CONFIG_BLK_DEV_AMD74XX) += amd74xx.o
> > obj-$(CONFIG_BLK_DEV_ATIIXP) += atiixp.o
> > obj-$(CONFIG_BLK_DEV_CELLEB) += scc_pata.o
> > +obj-$(CONFIG_BLK_DEV_IDE_PMAC) += pmac.o
> > obj-$(CONFIG_BLK_DEV_CMD64X) += cmd64x.o
> > obj-$(CONFIG_BLK_DEV_CS5520) += cs5520.o
> > obj-$(CONFIG_BLK_DEV_CS5530) += cs5530.o
> > @@ -76,8 +77,6 @@
> > obj-$(CONFIG_BLK_DEV_CMD640) += cmd640.o
> > -obj-$(CONFIG_BLK_DEV_IDE_PMAC) += pmac.o
> > -
> > obj-$(CONFIG_IDE_H8300) += ide-h8300.o
> > obj-$(CONFIG_IDE_GENERIC) += ide-generic.o
> > The problem is, the kernel guys will never take that patch upstream
> > because what they're currently doing isn't actually wrong. Their
> > behavior is consistent, the kernel's been probing the same devices in the
> > same order since the 90's, and they don't really care what order things
> > go in.
> > The problem is that the association between qemu's command line arguments
> > and the devices they refer to is somewhat arbitrary. On the other
> > targets I've used (arm, mips, x86, and so on), the device QEMU
> > initializes in response to "-hda" is the one the Linux kernel makes
> > /dev/hda (or /dev/sda), and the one it intializes in response to "-hdc"
> > is the one Linux makes /dev/hdc. But in this case, they don't match up,
> > and that's screwing up my same init/build script that works fine on all
> > the other tarets.
> > Here's a patch to QEMU that makes those arguments intialize the devices
> > the kernel expects them to. This doesn't change where any of the
> > hardware is on the board, just which command line arguments associate
> > with which drives:
> This is wrong. On my OpenSUSE 11.1 guest the devices come up in correct
> order. They also do so on Aurelien's Debian images (IIRC). I guess it
> mostly works fine when using modules instead of compiled in drivers.
When using modules the devices come up in the order the modules get inserted.
The first module inserted allocates /dev/hda and /dev/hdb, the second one
inserted allocates /dev/hdc and /dev/hdd. Also, udev can remap the suckers
arbitrarily if it wants to.
Of course this assumes you're using initramfs and a modular kernel, and not
all embedded systems want those extra layers.
In fact take that to its logical conclusion and there's no reason for qemu to
have separate -hda, -hdb, -hdc, and -hdd. It can just have "-disk image1.sqf
-disk image2.ext3 -disk image3.sqf" and let udev look for the magic in-band
signalling inside each image to determine what to mount via uuid.
> Please find a real G3 beige and see what's different on it.
It's not a question of hardware. That's why I showed the kernel patch that
can also reliably change this behavior. It's a question of:
A) The Linux kernel's device ordering being based on driver initialization
order when dealing with different types of controllers, which in the case of a
non-modular kernel is hardwired and always has been. (The first patch shows
changing that order within the kernel.)
B) The qemu command line options associating with different devices than the
Linux kernel is doing. The one -hda initializes is not the one the Linux
kernel uses as -hda when both sets of drivers are statically linked into the
kernel. (The second patch changes that ordering within qemu. It does NOT
alter where any devices are, it just alters which command line option goes
with which device.)
> I'd bet the
> real difference is that all 4 devices are attached to MacIO. But from what
> I remember DBDMA with cd-roms wasn't considered stable, hence the use of
> cmd64x on the second channel.
My use case is attaching three disk images to the system, not a CD or DVD
image, so I'd be happy if all 3 went through one controller. The /dev/hda is
a generic squashfs root filesystem image containing basic development tools.
The /dev/hdb is a writeable 2 gigabyte scratch disk. The /dev/hdc is another
squashfs containing build scripts and pre-extracted source tarballs.
I pondered merging them into a single partitioned image to work around this
issue, but they do very different things and have good reason to be orthogonal.
The hdb images are the only writeable ones, the other two are read only. The
hdc image is portable across architectures (it's just read-only source code
and shell scripts) while hda isn't, so I actually have arm, mips, and x86 all
building the same set of binaries sharing a single hdc file, but each with its
own hda and hdb images...
I also pondered writing a different qemu launch script that called qemu with "-
hdc root.sqf -hdd workspace.ext3 -hda build.sqf" but this is the only platform
I'd need to do that for. All the others work correctly with the same set of
arguments (with a couple $VARIABLES in there). This would need a special
case, because the g3beige behavior is different than the other platforms.
Latency is more important than throughput. It's that simple. - Linus Torvalds