From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NgHBH-0005SO-5K for qemu-devel@nongnu.org; Sat, 13 Feb 2010 07:33:03 -0500 Received: from [199.232.76.173] (port=36583 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NgHBG-0005S5-RE for qemu-devel@nongnu.org; Sat, 13 Feb 2010 07:33:02 -0500 Received: from Debian-exim by monty-python.gnu.org with spam-scanned (Exim 4.60) (envelope-from ) id 1NgHBE-0005jE-QJ for qemu-devel@nongnu.org; Sat, 13 Feb 2010 07:33:02 -0500 Received: from hall.aurel32.net ([88.191.82.174]:54175) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NgHBE-0005jA-GM for qemu-devel@nongnu.org; Sat, 13 Feb 2010 07:33:00 -0500 Date: Sat, 13 Feb 2010 13:32:58 +0100 From: Aurelien Jarno Subject: Re: [Qemu-devel] qemu-system-ppc -m g3beige -hda is setting /dev/hdc on Linux. Message-ID: <20100213123258.GE20140@hall.aurel32.net> References: <201002130202.01901.rob@landley.net> <50D45F60-AB94-4A1A-B4C8-5DA43D7F3ACD@suse.de> <20100213115823.GD20140@hall.aurel32.net> <3C58893A-479B-421E-9C9D-7F2EF98016D0@suse.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-15 Content-Disposition: inline In-Reply-To: <3C58893A-479B-421E-9C9D-7F2EF98016D0@suse.de> Sender: Aurelien Jarno List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Alexander Graf Cc: qemu-devel@nongnu.org On Sat, Feb 13, 2010 at 01:04:03PM +0100, Alexander Graf wrote: > > On 13.02.2010, at 12:58, Aurelien Jarno wrote: > > > On Sat, Feb 13, 2010 at 11:28:44AM +0100, 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. > >> > >> Please find a real G3 beige and see what's different on it. 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. > >> > > > > Exactly, that's the issue to fix here, make DBDMA work with CD-ROM so we > > can get rid of the cmd64x controller. > > Speaking of which - in my PPC64 enabling series I use MacIO for all 4 IDE devices. At least with recent kernels, Linux just detects DMA being broken on the CD-ROM and doesn't use it. > Same on PPC32, except that when DMA is not used, the VM freeze after a few accesses to the drive. -- Aurelien Jarno GPG: 1024D/F1BCDB73 aurelien@aurel32.net http://www.aurel32.net