|
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 -----
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
******************************************
|
Home