[Xen-devel] Fw: Start suse11 pv guest virtual machine, there han

华为技术有限公司

地址：深圳市龙岗区坂田华为基地邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

----- Original Message -----

From: linqaingmin

To: xen-devel@xxxxxxxxxxxxxxxxxxx

Sent: Wednesday, March 24, 2010 8:20 AM

Subject: Start suse11 pv guest virtual machine, there hang

hi all

My dom0 is suse11 + xen3.4.2, to create a pv guest, the operating system is suse11, start the virtual machine, execute the following command:

#xm start domname

Out of the system boot interface, and finally stopped at the "loop: module loaded";

I do not know anyone encountered such a situation, I now suspect that the file system is loaded, but through the

#xm create domname

commands can be started

华为技术有限公司

----- Original Message -----

From: xen-devel-request@xxxxxxxxxxxxxxxxxxx

To: xen-devel@xxxxxxxxxxxxxxxxxxx

Sent: Tuesday, March 23, 2010 8:48 PM

Subject: Xen-devel Digest, Vol 61, Issue 268

Send Xen-devel mailing list submissions to
xen-devel@xxxxxxxxxxxxxxxxxxx

To subscribe or unsubscribe via the World Wide Web, visit
http://lists.xensource.com/mailman/listinfo/xen-devel
or, via email, send a message with subject or body 'help' to
xen-devel-request@xxxxxxxxxxxxxxxxxxx

You can reach the person managing the list at
xen-devel-owner@xxxxxxxxxxxxxxxxxxx

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Xen-devel digest..."

Today's Topics:

   1. Re: [pvops dom0 xm save failed] (Pasi K?rkk?inen)
   2. Re: pvops-2.6.32 - Interrupt routing problem (Jan Beulich)
   3. Re: pvops-2.6.32 - Interrupt routing problem (Bastian Blank)
   4. Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops
      kernel (Michael D Labriola)

----------------------------------------------------------------------

Message: 1
Date: Tue, 23 Mar 2010 13:37:12 +0200
From: Pasi K?rkk?inen <pasik@xxxxxx>
Subject: Re: [Xen-devel] [pvops dom0 xm save failed]
To: ?????? <peb1611@xxxxxxxxx>
Cc: xen-devel@xxxxxxxxxxxxxxxxxxx
Message-ID: <20100323113712.GL1878@xxxxxxxxxxx>
Content-Type: text/plain; charset=iso-8859-1

On Tue, Mar 23, 2010 at 08:32:37PM +0900, ?????? wrote:
>    32bit.
>
>    CPU is Genuine Intel(R) CPU T2300 @ 1.66GHz.
>
>    any problem here??
>

Try using this config:
http://pasik.reaktio.net/fedora/config-2.6.32.9-70.fc12.i686.PAE

That's the default fedora 32bit kernel .config.
copy it as .config and then do "make oldconfig".

that worked for me with 2.6.32.9.

-- Pasi

>    2010/3/23 Pasi Kärkkäinen <[1]pasik@xxxxxx>
>
>      On Tue, Mar 23, 2010 at 08:27:46PM +0900, ?????? wrote:
>      >    this is my domU config file
>      >    there is nothing special....
>      >
>      >    ==============================================================
>      >    kernel = "/boot/vmlinuz-2.6.32.10-domU"
>      >    ramdisk = "/boot/initrd.img-2.6.32.10-domU"
>      >    memory = 1024
>      >    name = "ubuntu1"
>      >    vcpus = 1
>      >    vif = [ 'mac=00:16:3e:48:ef:5c, bridge=eth0' ]
>      >    disk = [
>      >
>       'file:/root/xen/domainU/ubuntu1/ubuntu1.img,xvda1,w','file:/root/xen/domainU/ubuntu1/ubuntu1_swap.img,xvda2,w'
>      >    ]
>      >    hostname= "ubuntu1"
>      >    root = "/dev/xvda1 ro"
>      >    extra = "console=hvc0 earlyprintk=xen"
>      >    ==============================================================
>      >
>      >    and I also used Ubuntu distribution .config file which was created
>      at
>      >    Ubuntu install time for domU build
>      >
>
>      Ok. Is it 32bit or 64bit?
>      -- Pasi
>
>      >    2010/3/23 Pasi Kärkkäinen <[1][2]pasik@xxxxxx>
>      >
>      >      On Tue, Mar 23, 2010 at 08:01:42PM +0900, ?????? wrote:
>      >      >    2.6.32.10 domU also failed with same error log..
>      >      >    Is it exactly domU problem??
>      >      >
>      >
>      >      For PV guests it is _usually_ a domU kernel problem.
>      >      >    Is there specific kernel configuration related to
>      save/restore??
>      >      >    any other comments??
>      >      >
>      >
>      >      I tested using 2.6.32.9 in the domU 1 month ago (or so),
>      >      and I could save/restore just fine.
>      >
>      >      I tried both 32bit and 64bit guests, and both single-vcpu and
>      >      multi-vcpu.
>      >      my .config was based on Fedora kernel .config.
>      >
>      >      Please paste your /etc/xen/<guest> cfgfile?
>      >
>      >      -- Pasi
>      >
>      >      >    2010/3/23 Pasi Kärkkäinen <[1][2][3]pasik@xxxxxx>
>      >      >
>      >      >      On Tue, Mar 23, 2010 at 05:04:59PM +0900, ?????? wrote:
>      >      >      >    when I command 'xm save [domainU] [filename]', save
>      process
>      >      does
>      >      >      not
>      >      >      >    complete with this error message
>      >      >      >
>      >      >      >    Error: /usr/lib/xen/bin/xc_save 34 2 0 0 0 failed
>      >      >      >    Usage: xm save [-c] <Domain> <CheckpointFile>
>      >      >      >
>      >      >      >    Save a domain state to restore later.
>      >      >      >      -c, --checkpoint               Leave domain running
>      after
>      >      >      >    creating
>      >      >      >                                     snapshot
>      >      >      >
>      >      >      >    and /var/log/xen/xend.log produced below error
>      message.
>      >      >      >
>      >      >      >    [2010-03-23 16:58:07 1023] DEBUG (DevController:643)
>      >      >      hotplugStatusCallback
>      >      >      >    1.
>      >      >      >    [2010-03-23 16:58:07 1023] DEBUG (DevController:139)
>      Waiting
>      >      for
>      >      >      devices
>      >      >      >    irq.
>      >      >      >    [2010-03-23 16:58:07 1023] DEBUG (DevController:139)
>      Waiting
>      >      for
>      >      >      devices
>      >      >      >    vfb.
>      >      >      >    [2010-03-23 16:58:07 1023] DEBUG (DevController:139)
>      Waiting
>      >      for
>      >      >      devices
>      >      >      >    pci.
>      >      >      >    [2010-03-23 16:58:07 1023] DEBUG (DevController:139)
>      Waiting
>      >      for
>      >      >      devices
>      >      >      >    vtpm.
>      >      >      >    [2010-03-23 16:58:07 1023] INFO (XendDomain:1182)
>      Domain
>      >      ubuntu1
>      >      >      (3)
>      >      >      >    unpaused.
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendCheckpoint:110)
>      >      [xc_save]:
>      >      >      >    /usr/lib/xen/bin/xc_save 34 3 0 0 0
>      >      >      >    [2010-03-23 16:58:42 1023] INFO (XendCheckpoint:417)
>      >      xc_save:
>      >      >      failed to
>      >      >      >    get the suspend evtchn port
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendCheckpoint:388)
>      >      suspend
>      >      >      >    [2010-03-23 16:58:42 1023] INFO (XendCheckpoint:417)
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendCheckpoint:113)
>      In
>      >      >      saveInputHandler
>      >      >      >    suspend
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendCheckpoint:115)
>      >      Suspending 3
>      >      >      ...
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendDomainInfo:511)
>      >      >      >    XendDomainInfo.shutdown(suspend)
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG
>      (XendDomainInfo:1709)
>      >      >      >    XendDomainInfo.handleShutdownWatch
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG
>      (XendDomainInfo:1709)
>      >      >      >    XendDomainInfo.handleShutdownWatch
>      >      >      >    [2010-03-23 16:58:42 1023] INFO (XendDomainInfo:1903)
>      Domain
>      >      has
>      >      >      shutdown:
>      >      >      >    name=migrating-ubuntu1 id=3 reason=suspend.
>      >      >      >    [2010-03-23 16:58:42 1023] INFO (XendCheckpoint:121)
>      Domain
>      >      3
>      >      >      suspended.
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG (XendCheckpoint:130)
>      >      Written done
>      >      >      >    [2010-03-23 16:58:42 1023] ERROR (XendCheckpoint:164)
>      Save
>      >      failed
>      >      >      on
>      >      >      >    domain ubuntu1 (3) - resuming.
>      >      >      >    Traceback (most recent call last):
>      >      >      >      File
>      >      >
>       "/usr/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
>      >      line
>      >      >      >    132, in save
>      >      >      >        forkHelper(cmd, fd, saveInputHandler, False)
>      >      >      >      File
>      >      >
>       "/usr/lib/python2.6/dist-packages/xen/xend/XendCheckpoint.py",
>      >      line
>      >      >      >    405, in forkHelper
>      >      >      >        raise XendError("%s failed" % string.join(cmd))
>      >      >      >    XendError: /usr/lib/xen/bin/xc_save 34 3 0 0 0 failed
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG
>      (XendDomainInfo:2788)
>      >      >      >    XendDomainInfo.resumeDomain(3)
>      >      >      >    [2010-03-23 16:58:42 1023] DEBUG
>      (XendDomainInfo:2829)
>      >      >      >    XendDomainInfo.resumeDomain: completed
>      >      >      >    [2010-03-23 17:01:10 1023] DEBUG
>      (XendDomainInfo:2732)
>      >      >      >    XendDomainInfo.destroy: domid=3
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2207)
>      >      Destroying
>      >      >      device
>      >      >      >    model
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2214)
>      >      Releasing
>      >      >      devices
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2227)
>      >      Removing
>      >      >      vif/0
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:1134)
>      >      >      >    XendDomainInfo.destroyDevice: deviceClass = vif,
>      device =
>      >      vif/0
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2227)
>      >      Removing
>      >      >      console/0
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:1134)
>      >      >      >    XendDomainInfo.destroyDevice: deviceClass = console,
>      device
>      >      =
>      >      >      console/0
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2227)
>      >      Removing
>      >      >      vbd/51713
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:1134)
>      >      >      >    XendDomainInfo.destroyDevice: deviceClass = vbd,
>      device =
>      >      vbd/51713
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2227)
>      >      Removing
>      >      >      vbd/51714
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:1134)
>      >      >      >    XendDomainInfo.destroyDevice: deviceClass = vbd,
>      device =
>      >      vbd/51714
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2212) No
>      >      device
>      >      >      model
>      >      >      >    [2010-03-23 17:01:11 1023] DEBUG
>      (XendDomainInfo:2214)
>      >      Releasing
>      >      >      devices
>      >      >      >
>      >      >      >    my system configuration ( 32bit machine )
>      >      >      >    xen 3.4.2, dom0( jeremy's pvops kernel 2.6.31.6),
>      domU(
>      >      vanilla
>      >      >      kernel
>      >      >      >    2.6.32 with paravirt enabled), distribution( ubuntu
>      9.10 )
>      >      >      >    It does not work well
>      >      >      >
>      >      >      >    what is the problem??
>      >      >      >    I think current system is quite stable, newtork,
>      disk, and
>      >      so on.
>      >      >      >    Is there anyone who know this or has experience??
>      >      >      >
>      >      >
>      >      >      You need to update your domU kernel to the latest stable
>      update
>      >      >      (2.6.32.10),
>      >      >      and that'll fix the problem. 2.6.32(.0) doesn't yet have
>      the
>      >      necessary
>      >      >      save/restore fixes.
>      >      >
>      >      >      -- Pasi
>      >      >
>      >      >    --
>      >      >    Eunbyung Park
>      >      >
>      >      > References
>      >      >
>      >      >    Visible links
>      >      >    1. mailto:[3][4]pasik@xxxxxx
>      >
>      >    --
>      >    Eunbyung Park
>      >
>      > References
>      >
>      >    Visible links
>      >    1. mailto:[5]pasik@xxxxxx
>      >    2. mailto:[6]pasik@xxxxxx
>      >    3. mailto:[7]pasik@xxxxxx
>
>    --
>    Eunbyung Park
>
> References
>
>    Visible links
>    1. mailto:pasik@xxxxxx
>    2. mailto:pasik@xxxxxx
>    3. mailto:pasik@xxxxxx
>    4. mailto:pasik@xxxxxx
>    5. mailto:pasik@xxxxxx
>    6. mailto:pasik@xxxxxx
>    7. mailto:pasik@xxxxxx

------------------------------

Message: 2
Date: Tue, 23 Mar 2010 11:37:56 +0000
From: "Jan Beulich" <JBeulich@xxxxxxxxxx>
Subject: Re: [Xen-devel] pvops-2.6.32 - Interrupt routing problem
To: "Bastian Blank" <waldi@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir
Fraser <keir.fraser@xxxxxxxxxxxxx>, Xiantao Zhang
<xiantao.zhang@xxxxxxxxx>, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx>
Message-ID: <4BA8B62402000078000366E8@xxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=US-ASCII

>>> Bastian Blank <waldi@xxxxxxxxxx> 21.03.10 22:47 >>>
>On Fri, Mar 19, 2010 at 01:13:41PM +0100, Bastian Blank wrote:
>> The real fix could be:
>> - Allow the hypervisor to lock interrupts it uses. Zero would be in it by
>>   default. The interrupt for the used serial interface would be added.
>>   All other pins are free to be programmed by the kernel once.
>> - Don't do register_gsi calls from the initial setup in the kernel if no
>>   ACPI override is present, only setup the rest.
>
>Okay, I think I found another problem. Currently the setup looks like
>this:
>- PHYSDEVOP_setup_gsi: set trigger and polarity, unmask pin

Where are you seeing this? Other than Linux' (unmasking edge
triggered IRQs), Xen's io_apic_set_pci_routing() always masks the
entry afaics.

>- PHYSDEVOP_map_pirq: map to pirq, set irq handler to guest
>
>If an interrupt fires between this two calles, what happens?

Since this is only for edge triggered IRQs, I believe the purpose is
to not lose an edge when first enabling the interrupt. When one
occurs before the handler got set up, the fact that there was one
is just getting latched into desc->status, and the IRQ gets
mask_ack_irq()-ed.

Jan

------------------------------

Message: 3
Date: Tue, 23 Mar 2010 13:37:56 +0100
From: Bastian Blank <waldi@xxxxxxxxxx>
Subject: Re: [Xen-devel] pvops-2.6.32 - Interrupt routing problem
To: Jan Beulich <JBeulich@xxxxxxxxxx>
Cc: Jeremy Fitzhardinge <jeremy@xxxxxxxx>,
"xen-devel@xxxxxxxxxxxxxxxxxxx" <xen-devel@xxxxxxxxxxxxxxxxxxx>, Keir
Fraser <keir.fraser@xxxxxxxxxxxxx>, Xiantao Zhang
<xiantao.zhang@xxxxxxxxx>, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx>
Message-ID: <20100323123756.GA6656@xxxxxxxxxxxxxxxxxxxxxxx>
Content-Type: text/plain; charset=utf-8

On Tue, Mar 23, 2010 at 11:37:56AM +0000, Jan Beulich wrote:
> >>> Bastian Blank <waldi@xxxxxxxxxx> 21.03.10 22:47 >>>
> >Okay, I think I found another problem. Currently the setup looks like
> >this:
> >- PHYSDEVOP_setup_gsi: set trigger and polarity, unmask pin
> Where are you seeing this? Other than Linux' (unmasking edge
> triggered IRQs), Xen's io_apic_set_pci_routing() always masks the
> entry afaics.

In the Linux kernel, xen_register_gsi (arch/x86/xen/pci.c). The io-apic
support in Xen is a copy of the Linux code and behaves similar.

> >- PHYSDEVOP_map_pirq: map to pirq, set irq handler to guest
> >If an interrupt fires between this two calles, what happens?
> Since this is only for edge triggered IRQs, I believe the purpose is
> to not lose an edge when first enabling the interrupt.

No. The interrupt setup is always done before the device setup. This is
core kernel functionality.

Please explain why you think this is restricted to edge triggered. This
is called from the PCI interrupt setup, and usualy used with level
triggered interrupts.

Bastian

--
I have never understood the female capacity to avoid a direct answer to
any question.
-- Spock, "This Side of Paradise", stardate 3417.3

------------------------------

Message: 4
Date: Tue, 23 Mar 2010 08:45:35 -0400
From: Michael D Labriola <mlabriol@xxxxxxxx>
Subject: Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on
Xen pv-ops kernel
To: Arvind R <arvino55@xxxxxxxxx>
Cc: xen-devel-bounces@xxxxxxxxxxxxxxxxxxx, Jeremy Fitzhardinge
<jeremy@xxxxxxxx>, xen-devel@xxxxxxxxxxxxxxxxxxx, Joanna Rutkowska
<joanna@xxxxxxxxxxxxxxxxxxxxxx>, Konrad Rzeszutek Wilk
<konrad.wilk@xxxxxxxxxx>
Message-ID:
<OF9410CED1.73CA16E8-ON852576EF.0044E054-852576EF.00461775@xxxxxxxx>
Content-Type: text/plain; charset="US-ASCII"

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/23/2010 02:21:31 AM:

> On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola <mlabriol@xxxxxxxx>
wrote:
> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/20/2010 02:01:54 AM:
> >
> >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola
<mlabriol@xxxxxxxx>
> > wrote:
> >> > xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/18/2010 02:09:08
AM:
> >> >
> >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
> > <mlabriol@xxxxxxxx>
> >> > wrote:
> >> >> > Konrad Rzeszutek Wilk <konrad.wilk@xxxxxxxxxx> wrote on
03/16/2010
> >> >> > 01:21:35 PM:
> >> >> >
> >> >> >> > > > And my X log ends abruptly after this line:
> >> >> >> > > > (II) NOUVEAU(0): Opened GPU Channel 1
> >> >> >> > > >
> >> >> >> > > > Any ideas?
> >> >> >> > > >
> >> >> >> > >
> >> >> >> > > Well, this is generally the symptom that someone is
confusing
> >> > mfns
> >> >> > and
> >> >> >> > > pfns, and therefore ends up incorrectly setting the
_PAGE_IO
> > flag
> >> > in
> >> >> >
> >> >> >> > > some pte. If you run it under strace, can you identify
which
> >> >> > mapping
> >> >> >> > > the fault is happening in?
> >> >> >> >
> >> >> >> > I've attached the output of 'strace -o strace-Xorg Xorg'.
> > Figuring
> >> >> > out
> >> >> >> > which mapping the fault is happening in is a little over my
> > head,
> >> > I'm
> >> >> >> > afraid. If you need different arguments to strace, let me
know
> > and
> >> >> > I'll
> >> >> >> > do it again.
> >> >> >>
> >> >> >> So just to be sure, you took the 2.6.32 (xen/next or
> >> >> >> xen/stable-2.6.32.x), copied the include and nouveu directory
from
> >> > ..?
> >> >> >> 2.6.33? and then ran this.
> >> >> >
> >> >> > I actually took a slightly more sadistic route than Arvind...
;-)
> > A
> >> > while
> >> >> > back, I backported the important stuff from the Nouveau kernel
git
> >> > tree
> >> >> > back to v2.6.31. Basically guessed at which commits were
> > important,
> >> > wrote
> >> >> > a script to cherry pick each and every one, and spent an entire
day
> >> >> > reading commit logs, resolving conflicts, and figuring out which
> > other
> >> >> > non-drm commits I needed. Sounds retarded, I know, but it was a
> >> > pretty
> >> >> > interesting way to get myself up to speed with the code base.
The
> >> >> > resulting 2.6.31-nouveau kernel runs like a champ on all my
> > hardware.
> >> >> >
> >> >> > Then I merged that into my clone of Jeremy's xen/master which I
use
> >> > with
> >> >> > Xen 3.4.2.
> >> >> >
> >> >> > Since then, I've been periodically cherry picking all new
commits
> > off
> >> > the
> >> >> > nouveau tree. Also had to rebuild Xorg 7.5 to use xorg-server
> > 1.7.5,
> >> > new
> >> >> > libdrm, mesa, and xf86-video-nouveau all from their respective
git
> >> > trees
> >> >> > as of yesterday. (drm and xf86-video-nouveau are on their
master
> >> >> > branches, mesa is on the 7.8 branch)
> >> >> >
> >> >> > This all works great using xen/master bare metal. It used to
work
> >> > fine on
> >> >> > my old GeForce2 MX based systems in Xen. Arvind's patch made it
> > work
> >> > on
> >> >> > my nice new systems in Xen, but broke it on the old ones.
> > Everything
> >> >> > still works fine bare metal.
> >> >> >
> >> >> >> Did you have to edit your xorg.conf file or
> >> >> >> it ran just fine?
> >> >> >
> >> >> > Well, I had to create an xorg.conf that looks like this:
> >> >> >
> >> >> > Section "Device"
> >> >> > Identifier "foo"
> >> >> > Driver "nouveau"
> >> >> > EndSection
> >> >> >
> >> >> > Otherwise it uses the 'nv' driver... and I haven't stumbled
onto
> > how
> >> > to
> >> >> > get nouveau to automatically get used (aside from uninstalling
the
> > nv
> >> >> > driver).
> >> >> >
> >> >> >
> >> >> >> Was this Fedora 13 or Fedora 12?
> >> >> >
> >> >> > This is all being done on a custom 32bit Linux distro that we
use
> > for
> >> > our
> >> >> > tightly configuration controlled system deliveries. It was
fedora
> >> > based a
> >> >> > looooooooong time ago (FC5), but is completely unrecognizable
now.
> >> >> >
> >> >> >
> >> >> >> Arvind explanation about the Nvidia driver pointed out that the
> >> > NVidia
> >> >> >> driver (drm/nouvue) can operate on different channels. Where
> > channel
> >> > 1
> >> >> >> is the framebuffer, and the other are for well, KMS, and other
> >> >> >> applications.
> >> >> >>
> >> >> >> I belive I was looking at the wrong section of the drivers (not
> > the
> >> >> >> drivers/video/gpu ones)- this certainly looks to be the issues
the
> >> >> >> Jeremy mentioned.
> >> >> >>
> >> >> >> Also I would suggest you load drm with the debug variable set
to
> > the
> >> > 255
> >> >> >> to get most of what his happening.
> >> >> >
> >> >> > I'll try that.
> >> >> >
> >> >> >
> >> >> >> Based on your strace, the last call is:
> >> >> >> 4000)                          = 0x9324000
> >> >> >> write(0, "(II) NOUVEAU(0): Opened GPU chan"..., 38) = 38
> >> >> >> ioctl(11, 0xc0106445, 0x930a908)        = 0
> >> >> >> ioctl(11, 0x400c6444, 0xbfd2a210)       = 0
> >> >> >> +++ killed by SIGKILL +++
> >> >> >>
> >> >> >> I cannot find what 0x45 is in the upstream Linux, so you must
be
> >> > using a
> >> >> >> different nouv* driver than that. The 0x44 is:
> >> >> >>
> >> >> >>   DRM_IOCTL_DEF(DRM_NOUVEAU_GEM_INFO, nouveau_gem_ioctl_info,
> >> > DRM_AUTH),
> >> >> >>
> >> >> >> Which looks to be pretty harmless. I presume it is the next
thing
> >> > (using
> >> >> >> the address returned) that the X driver tries to do that makes
it
> > go
> >> >> > boom.
> >> >> >
> >> >> I suspect that the ioctl is prior to a modeset operation. And the
> >> >> mode-setting is 'booming'.
> >> >> My kernel config has VGA console built-in fbcon as a module and I
do
> >> >> a switch to
> >> >> nouveaufb at runlevel 2. Also note that the default modeset
> >> >> parameter is -1 and
> >> >> if VGA-CONSOLE is enabled, then modeset is set to 0 in the driver
> >> >> initialisation
> >> >> - which maybe the problem. Do you have modeset=1 as module
parameter?
> >> >
> >> > I wasn't setting any module params for nouveau. Adding 'options
> > nouveau
> >> > modeset=1' to modprobe.conf didn't seem to make any difference.
> >> >
> >> > I've got the following in my .config:
> >> >
> >> > CONFIG_VGA_CONSOLE=y
> >> > CONFIG_FB=y
> >> > CONFIG_FB_VGA16=m
> >> > CONFIG_FB_VESA=y
> >> > CONFIG_FB_EFI=y
> >> > CONFIG_FB_NVIDIA=m
> >> > CONFIG_FB_NVIDIA_I2C=y
> >> > CONFIG_FB_NVIDIA_BACKLIGHT=y
> >> >
> >> - EMBEDDED - this will enable VGA_CONSOLE selection. Set sub-menu
> >> choices as needed
> >> - VGA_CONSOLE builtin
> >> - FB as module
> >> - FRAMEBUFFER_CONSOLE as a module. Enables late loading of nouveau
> >> * Foll. required to avoid cfb_copyarea, cfb_fillrectangle,
> >> cfb_imageblit linking problems with
> >>     out-of-tree nouveau builds
> >> - FB_VGA16 as module - supported by all nVidia cards.
> >>    or
> >> - FB_NVIDIA as module - only works for older cards.
> >>
> >> For out-of-tree nouveau builds, DO NOT select ANY accelerated drivers
> >> - that would enable
> >> the old in-tree DRM. New TTM / DRM modulesare in the new driver/gpu
> > tree.
> >>
> >> For in-tree builds, if nouveau is NOT in the initrd-image, system
will
> >> boot on vga console
> >> >
> >> > How do you force the nouveaufb switch at runlevel 2? My screen
> > obviously
> >> > switches into KMS mode while udev is starting up.
> >> You can switch to the accelerated framebuffer console by
> >> modprobe nouveau
> >> modprobe fbcon
> >> fbcon will take-over console from the built-in VGA. See
> >> Documenation/fb/fbcon.txt
> >
> > Ok, thanks. Now I've got everything compiled as modules and can load
them
> > post-boot to switch to the nouveau framebuffer console. That actually
> > didn't change the X behavior at all, though. I still get the exact
same
> > "X: Corrupted page table" messages in dmesg and my Xorg.log is just
ending
> > with "NOUVEAU(0): Opened GPU channel 1".
> This is strange - channel 1 is the console channel. This appears in
dmesg on
> nouveaufb initialisation before EDID probe to find connected outputs.
> Start X manually to avoid confusion of logs.

I've been testing this by booting to runlevel 3 and starting gdm. I'll
double check that I get the same results running Xorg by hand, although
gdm does something to give me my console back after the X crash...

> Have attached ttm_xen.patch which updates vm_page_prot after changing
flags.
> This is not done in the mainline drm-tree. But in the xen (old)
> drm-tree this is done in
> BOTH ttm_bo_mmap AND ttm_fbdev_mmap - and the attached patch does both,
> along with the conditional VM_IO in bo_mmap. And the second vm_page_prot
> update is for fbdev_mmap which corresponds to channel 1. Cross
> fingers and try!

I'll go try that.

> > If the old nvidiafb is loaded, nouveau cannot install (and vice-versa)
> >
> > Well, everything seems to load just fine. I get a nice teeny font and
> > dmesg messages saying I'm using nouveaufb.
> You should have got it earlier too - didn't you?

Yeah, I had that before.

> >> does NOT affect unaccelerated X on the older cards?
> >
> > Which accelerated modes are you refering to? My understanding was
that
> > the old GeForce2 cards should work for nouveaufb, the 2d xf86-nouveau
> > driver, and gallium's swrast_dri stuff (via AIGLX), but not gallium's
new
> > dri_nouveau stuff.
> Right. But gallium's swrast_dri AND dri_nouveau are still 'unsupported',
> to be tried at own risk. nouveau_dri was working enough to run fgfs with
> mesa-7.7, but now with mesa-7.9, glxgears works not fgfs - segfaults in
> libdrm_nouveau.

Correct. I've been having rather good luck with it until this. I can
recompile mesa and leave out the nouveau and swrast stuff to see if that
helps, but my impression was that this is crashing before any of that code
even gets used. And it does work bare-metal and did work in xen prior to
that last patch. What's the fallback if both gallium's nouveau and swrast
libs are missing, anyway?

> >> Xorg used to hang saying 'Opened Channel 2' and not 1.
> >
> > Now that's strange. Every single one of my boxes says Opened Channel
1,
> > with now reference to channel 2 at all.
> Channel 1 in dmesg/syslog; Xorg.log snippet:
> (II) LoadModule: "shadowfb"
> (II) Loading /usr/lib/xorg/modules/libshadowfb.so
> (II) Module shadowfb: vendor="X.Org Foundation"
>     compiled for 1.7.5, module version = 1.0.0
>     ABI class: X.Org ANSI C Emulation, version 0.4
> (--) Depth 24 pixmap format is 32 bpp
> (II) NOUVEAU(0): Opened GPU channel 2 <initial hang point>
> (II) NOUVEAU(0): [DRI2] Setup complete    <after patch>
> (II) NOUVEAU(0): GART: 512MiB available
> (II) NOUVEAU(0): GART: Allocated 16MiB as a scratch buffer
> (II) EXA(0): Driver allocated offscreen pixmaps
> (II) EXA(0): Driver registered support for the following operations:
> (II)         Solid
> (II)         Copy
> (II)         Composite (RENDER acceleration)
> (II)         UploadToScreen
> (II)         DownloadFromScreen
> (==) NOUVEAU(0): Backing store disabled
> (==) NOUVEAU(0): Silken mouse enabled
> (II) NOUVEAU(0): [XvMC] Associated with Nouveau GeForce 8/9 Textured
Video.
> (II) NOUVEAU(0): [XvMC] Extension initialized.
>
>
> Try with
> Option "ShadowFB" "true"
> in Device section of xorg.conf (turns off acceleration) to check. The
option
> also sets NoAccel on and X should use the FB device

Which should make it mind-bogglingly slow, right? I'll try this as well.

>
> So the cards that don't work are AGP cards?

Yes. GeForce2 MX200 AGP.

---
Michael D Labriola
Electric Boat
mlabriol@xxxxxxxx
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)

------------------------------

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

End of Xen-devel Digest, Vol 61, Issue 268
******************************************

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel

WARNING - OLD ARCHIVES

xen-devel

[Xen-devel] Fw: Start suse11 pv guest virtual machine, there hang