linqaingmin
2010-Mar-24 00:21 UTC
[Xen-devel] Fw: Start suse11 pv guest virtual machine, there hang
华为技术有限公司
地址：深圳市龙岗区坂田华为基地 邮编：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@lists.xensource.com
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
华为技术有限公司
地址：深圳市龙岗区坂田华为基地 邮编：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: xen-devel-request@lists.xensource.com
To: xen-devel@lists.xensource.com
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@lists.xensource.com
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@lists.xensource.com
You can reach the person managing the list at
xen-devel-owner@lists.xensource.com
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@iki.fi>
Subject: Re: [Xen-devel] [pvops dom0 xm save failed]
To: ?????? <peb1611@gmail.com>
Cc: xen-devel@lists.xensource.com
Message-ID: <20100323113712.GL1878@reaktio.net>
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@iki.fi>
>
> 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@iki.fi>
> >
> > 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@iki.fi>
> > >
> > > 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@iki.fi
> >
> > --
> > Eunbyung Park
> >
> > References
> >
> > Visible links
> > 1. mailto:[5]pasik@iki.fi
> > 2. mailto:[6]pasik@iki.fi
> > 3. mailto:[7]pasik@iki.fi
>
> --
> Eunbyung Park
>
> References
>
> Visible links
> 1. mailto:pasik@iki.fi
> 2. mailto:pasik@iki.fi
> 3. mailto:pasik@iki.fi
> 4. mailto:pasik@iki.fi
> 5. mailto:pasik@iki.fi
> 6. mailto:pasik@iki.fi
> 7. mailto:pasik@iki.fi
------------------------------
Message: 2
Date: Tue, 23 Mar 2010 11:37:56 +0000
From: "Jan Beulich" <JBeulich@novell.com>
Subject: Re: [Xen-devel] pvops-2.6.32 - Interrupt routing problem
To: "Bastian Blank" <waldi@debian.org>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, Keir
Fraser <keir.fraser@eu.citrix.com>, Xiantao Zhang
<xiantao.zhang@intel.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>
Message-ID: <4BA8B62402000078000366E8@vpn.id2.novell.com>
Content-Type: text/plain; charset=US-ASCII
>>> Bastian Blank <waldi@debian.org> 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@debian.org>
Subject: Re: [Xen-devel] pvops-2.6.32 - Interrupt routing problem
To: Jan Beulich <JBeulich@novell.com>
Cc: Jeremy Fitzhardinge <jeremy@goop.org>,
"xen-devel@lists.xensource.com"
<xen-devel@lists.xensource.com>, Keir
Fraser <keir.fraser@eu.citrix.com>, Xiantao Zhang
<xiantao.zhang@intel.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>
Message-ID: <20100323123756.GA6656@wavehammer.waldi.eu.org>
Content-Type: text/plain; charset=utf-8
On Tue, Mar 23, 2010 at 11:37:56AM +0000, Jan Beulich wrote:
> >>> Bastian Blank <waldi@debian.org> 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@gdeb.com>
Subject: Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on
Xen pv-ops kernel
To: Arvind R <arvino55@gmail.com>
Cc: xen-devel-bounces@lists.xensource.com, Jeremy Fitzhardinge
<jeremy@goop.org>, xen-devel@lists.xensource.com, Joanna Rutkowska
<joanna@invisiblethingslab.com>, Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com>
Message-ID:
<OF9410CED1.73CA16E8-ON852576EF.0044E054-852576EF.00461775@gdeb.com>
Content-Type: text/plain; charset="US-ASCII"
xen-devel-bounces@lists.xensource.com wrote on 03/23/2010 02:21:31 AM:
> On Tue, Mar 23, 2010 at 2:44 AM, Michael D Labriola
<mlabriol@gdeb.com>
wrote:
> > xen-devel-bounces@lists.xensource.com wrote on 03/20/2010 02:01:54
AM:
> >
> >> On Fri, Mar 19, 2010 at 8:59 PM, Michael D Labriola
<mlabriol@gdeb.com>
> > wrote:
> >> > xen-devel-bounces@lists.xensource.com wrote on 03/18/2010
02:09:08
AM:
> >> >
> >> >> On Wed, Mar 17, 2010 at 1:09 AM, Michael D Labriola
> > <mlabriol@gdeb.com>
> >> > wrote:
> >> >> > Konrad Rzeszutek Wilk
<konrad.wilk@oracle.com> 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@gdeb.com
401-848-8871 (desk)
401-848-8513 (lab)
401-316-9844 (cell)
------------------------------
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel
End of Xen-devel Digest, Vol 61, Issue 268
******************************************
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel