qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Weird Issue with IDE


From: Adhyas Avasthi
Subject: [Qemu-devel] Weird Issue with IDE
Date: Sun, 21 Nov 2010 21:37:26 -0800

I am doing something specific and slightly different than normal uses.
Would appreciate if someone can help me with a pointer as to what I
can do next. I am kinda stuck at this point.

My experiment is trying to move the PIIX4 chipset (which currently
resides on dev 1, func 0/1/2/3/) to dev 2 (same function sequence). I
have modified the ACPI tables to report the IRQ mapping accordingly,
which is probably not useful for IDE anyway as it just uses the legacy
IRQ14/15 interrupts.

Unfortunately, my Linux kernel fail to find the IDE device when I do
this simple change. I have compiled the kernel to dump code from its
ATA driver and it does tell me that the interrupt handler is invoked
for IRQ14 and IRQ15, so this may not be an interrupt routing issue
(which is what I first assumed it to be). Is there some other code in
qemu that resides on PCI slot location of the IDE controller? My
current modification to change the PCI slot is very simple (I just
change the pci_create_simple_multifunction call in i440fx_init to put
that on devfn 0x10, instead of default).

I am comparing the dmesg dump for normal kernel boot (with default
PIIX4 on dev 1) vs modified qemu boot (which just lands me to
initramfs shell if I choose console to ttyS0, as it complains it could
not find IDE disk). I tried to attach the the console output and the
dmesg output for the both cases, but the mail bounced back on me,
perhaps it does not accept 250K attachment.
In the latter case, the ports are disabled after recovery and validate routines
are called in ata driver code in the kernel.

I would appreciate if someone can give any pointers on what may be
going wrong with this simple change? And what more may be required in qemu
to change the PCI slot of the PIIX4 controller. I assumed this should
be a simple change, but apparently not so simple :-(

-- 
Adhyas
********************************************************************
Two types have compatible type if their types are the same.
    — ANSI C Standard, 3.1.2.6.
********************************************************************



reply via email to

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