From: Michael Roth <mdroth@linux.vnet.ibm.com>
To: lejeczek <peljasz@yahoo.co.uk>
Cc: qemu-devel@nongnu.org
Subject: Re: [Qemu-devel] a user here - pci-assign
Date: Tue, 2 Oct 2012 10:33:14 -0500 [thread overview]
Message-ID: <20121002153314.GF522@illuin> (raw)
In-Reply-To: <506A9BD8.8060405@yahoo.co.uk>
On Tue, Oct 02, 2012 at 08:46:32AM +0100, lejeczek wrote:
> rhel in general seem reluctant, I filed a bug a few days ago and
> although I believe there is problem with repo's version of seabios
> as soon as I mentioned VGA report was closed as 'wontfix'
> and I would still prefer them over Oracle, sometimes I wonder why..
If we can get it fixed upstream they'll pick it up eventually. Can you
confirm the problem exists with the latest upstream qemu code?
>
> On 01/10/12 14:51, Alex Williamson wrote:
> >On Mon, 2012-10-01 at 12:10 +0100, lejeczek wrote:
> >>hmm, still cannot get readon 5450 to work on win7-64, have
> >>changed -cpu to host but no fix
> >>no vfio in qemu-kvm-0.12.1.2-2.295.el6_3.2.x86_64
> >>yes, I do blacklist modules at grub level and later in
> >>modprobe also
> >You probably want to try newer upstream code. RHEL does not currently
> >support assignment of VGA.
> >
> >>is primary/secondary VGA setup somehow helped by
> >>qemu/components? in guest I can do anything since device is
> >>disabled.
> >>
> >>pci-assign.multifunction=on/off - that would be the case
> >>with VGAs like radeon and nvidia - audio part - is it
> >>optional or always has to be ON for such devices?
> >Optional
> >
> >>where one gets hold of information like: addr= ?
> >>I understand these are needed only! if pci-assign.host is
> >>not enough and qemu has no way of knowing/finding it, when
> >>may this happen?
> >This is not going to help you. It's a matter of finding a free slot,
> >which qemu can do fine on it's own if you don't want to specify.
> >Thanks,
> >
> >Alex
> >
> >>On 28/09/12 20:48, Alex Williamson wrote:
> >>>On Fri, 2012-09-28 at 19:46 +0100, lejeczek wrote:
> >>>>thanks Alex for your patience, appreciate it I do
> >>>>
> >>>>what would be the droids I need?
> >>>>I'm experiencing guests' "puzzling" behavior and was
> >>>>suggested that command line arguments were wrong/incomplete.
> >>>>
> >>>>same box/hardware and radeon 5450 and ...
> >>>>- winXP-32bit -> OK - I assumed getting the guest on a
> >>>>external computer monitor was an ultimate test
> >>>>- win7-64bit -> OS reports device as disabled cause the
> >>>>device reported an error
> >>>I've had this same card working with both of these guests. I believe
> >>>one trick on win7 was to use -cpu host. Also, don't try to disable the
> >>>emulated vga device, just set it up like a dual-head system. Once you
> >>>load the catalyst driver windows will switch to use the assigned device
> >>>exclusively. I was using the new vfio assignment driver, but someone
> >>>else recently report it working with the existing driver as well. The
> >>>5450 should be a secondary graphics card on the host system, trying to
> >>>assign the primary graphics is going to cause more problems. Also
> >>>blacklist the radeon driver on the host, we don't need any leftover
> >>>state from the Linux driver causing problems since most of these
> >>>graphics cards don't support a reset mechanism.
> >>>
> >>>>same box as above and geforce gt640 and ..
> >>>>for both XP and 7 report device with exclamation marks (thus
> >>>>did not even bother to connect any screens like in working
> >>>>case with XP & radeon)
> >>>I don't think we've seen any reports yet of Nvidia cards working,
> >>>there's another thread on the kvm list speculating at some of the
> >>>problems.
> >>>
> >>>>I'll try to get hold of ROMs of the cards, meanwhile, how
> >>>>can I troubleshoot it? how to get more verbose feedback and
> >>>>what to specifically look for?
> >>>ROMs are only going to help if you're getting errors trying to read the
> >>>ROM. Nvidia seems to have this problem, but I don't think radeons
> >>>typical do. There's a #define in the code that can be enabled to get
> >>>more logging, but it's not terribly useful unless you know what you're
> >>>looking at. VGA has plenty of issues with legacy PC address ranges that
> >>>are known problems, but there are also plenty of unknown problems that
> >>>make it a pretty difficult black box debugging project. Thanks,
> >>>
> >>>Alex
> >>>
> >>>
> >>>
> >>
> >
> >
> >
> >
>
>
next prev parent reply other threads:[~2012-10-02 15:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-09-28 9:54 [Qemu-devel] a user here - pci-assign lejeczek
2012-09-28 16:05 ` Alex Williamson
2012-09-28 18:46 ` lejeczek
2012-09-28 19:48 ` Alex Williamson
2012-10-01 11:10 ` lejeczek
2012-10-01 13:51 ` Alex Williamson
2012-10-02 7:46 ` lejeczek
2012-10-02 15:33 ` Michael Roth [this message]
2012-10-03 14:30 ` lejeczek
2012-10-03 14:46 ` Alex Williamson
2012-11-06 13:17 ` [Qemu-devel] a user here - pci-assign VGA lejeczek
2012-10-01 14:04 ` [Qemu-devel] a user here - pci-assign lejeczek
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20121002153314.GF522@illuin \
--to=mdroth@linux.vnet.ibm.com \
--cc=peljasz@yahoo.co.uk \
--cc=qemu-devel@nongnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.