Re: [Xen-devel] Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel

[Michael D Labriola <mlabriol@xxxxxxxx>]

xen-devel-bounces@xxxxxxxxxxxxxxxxxxx wrote on 03/16/2010 03:18:01 AM:

> On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge <jeremy@xxxxxxxx> 
wrote:
> > On 03/15/2010 07:44 AM, Michael D Labriola wrote:
> >>
> >> Hmm... I just verified that this patch fixes KMS/Nouveau issues in 
Xen on
> >> my two primary test boxes (GeForce 6200, GeForce 7300).  However, on 
my
> >> really old machines (AGP GeForce2 MX200), this causes a new crash. 
 These
> >> old boxes were actually working fine in Xen prior to this patch, just
> >> w/out 3d acceleration.  Now I get the following messages in dmesg:
> >>
> >> [  129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1
> >> [  129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc:
> >> initialised FIFO 1
> >> [  129.643791] X: Corrupted page table at address 40412000
> >> [  129.643815] *pdpt = 0000000015216001 *pde = 0000000000000000
> >> [  129.643856] Bad pagetable: 000f [#1] SMP
> >> [  129.643897] last sysfs file:
> >> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga
> >> [  129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc 
raid1
> >> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 
snd_ac97_codec
> >> ac97_bus snd_seq_dummy he atm ttm drm_kms_helper snd_seq_oss
> >> snd_seq_midi_event sr_mod snd_seq cdrom drm serio_raw snd_seq_device
> >> snd_pcm_oss snd_mixer_oss snd_pcm e100 mii i2c_algo_bit snd_timer
> >> ata_generic snd pcspkr i2c_i801 i2c_core intel_rng soundcore 
i82860_edac
> >> snd_page_alloc pata_acpi edac_core parport_pc floppy parport 
dm_snapshot
> >> dm_zero dm_mirror dm_region_hash dm_log dm_mod raid0 ext3 mbcache jbd
> >> aic7xxx scsi_transport_spi ata_piix libata sd_mod scsi_mod
> >> [  129.644024]
> >> [  129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) 
P4DC6
> >> [  129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0
> >> [  129.644024] EIP is at 0x40394596
> >> [  129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 
00044000
> >> [  129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: 
bfe7f780
> >> [  129.644024]  DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b
> >> [  129.644024] Process X (pid: 3690, ti=ea1ce000 task=ea77f110
> >> task.ti=ea1ce000)
> >> [  129.644024]
> >> [  129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780
> >> [  129.644024] ---[ end trace 569eb18d737a8611 ]---
> >> [  129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: 
freeing
> >> fifo 1
> >>
> >>
> >> 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 mfnsand 
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?
> >
> >    J
> >
> Just wanted to emphasise that not updating vma->vm_page_prot after 
updating
> the flags correctly failed to provide the solution. Maybe forcing 
> this update in
> all places will show up new failures.

I'm not sure I follow, as I've gotten in a little over my head here.

 
> Also, maybe the final solution needs to 'or'  TTM_PL_SYSTEM also into
> the conditional.

I'll kick off a compile with TTM_PL_SYSTEM orred into the conditional and 
see which of my boxes are functional afterwards.

-Mike

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