qemu-devel
[Top][All Lists]
Advanced

[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


From: Aurelien Jarno
Subject: Re: [Qemu-devel] qemu-system-ppc -m g3beige -hda is setting /dev/hdc on Linux.
Date: Sat, 13 Feb 2010 13:32:58 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

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
address@hidden                 http://www.aurel32.net




reply via email to

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