From mboxrd@z Thu Jan 1 00:00:00 1970 From: Arvind R Subject: Re: Re: [Patch RFC] ttm: nouveau accelerated on Xen pv-ops kernel Date: Tue, 16 Mar 2010 12:48:01 +0530 Message-ID: References: <4B9EBF10.2030309@goop.org> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Return-path: In-Reply-To: <4B9EBF10.2030309@goop.org> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xensource.com Errors-To: xen-devel-bounces@lists.xensource.com To: Jeremy Fitzhardinge Cc: Konrad Rzeszutek Wilk , xen-devel@lists.xensource.com, Michael D Labriola , Joanna Rutkowska , xen-devel-bounces@lists.xensource.com List-Id: xen-devel@lists.xenproject.org On Tue, Mar 16, 2010 at 4:43 AM, Jeremy Fitzhardinge wrot= e: > On 03/15/2010 07:44 AM, Michael D Labriola wrote: >> >> Hmm... I just verified that this patch fixes KMS/Nouveau issues in Xen o= n >> my two primary test boxes (GeForce 6200, GeForce 7300). =A0However, on m= y >> really old machines (AGP GeForce2 MX200), this causes a new crash. =A0Th= ese >> old boxes were actually working fine in Xen prior to this patch, just >> w/out 3d acceleration. =A0Now I get the following messages in dmesg: >> >> [ =A0129.637319] [drm] nouveau 0000:01:00.0: Allocating FIFO number 1 >> [ =A0129.638853] [drm] nouveau 0000:01:00.0: nouveau_channel_alloc: >> initialised FIFO 1 >> [ =A0129.643791] X: Corrupted page table at address 40412000 >> [ =A0129.643815] *pdpt =3D 0000000015216001 *pde =3D 0000000000000000 >> [ =A0129.643856] Bad pagetable: 000f [#1] SMP >> [ =A0129.643897] last sysfs file: >> /sys/devices/pci0000:00/0000:00:01.0/0000:01:00.0/boot_vga >> [ =A0129.643916] Modules linked in: bridge stp ipv6 autofs4 sunrpc raid1 >> video output sbs sbshc pci_slot lp sg nouveau snd_intel8x0 snd_ac97_code= c >> 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 >> [ =A0129.644024] >> [ =A0129.644024] Pid: 3690, comm: X Not tainted (2.6.31.6-mdl5 #1) P4DC6 >> [ =A0129.644024] EIP: 0073:[<40394596>] EFLAGS: 00210206 CPU: 0 >> [ =A0129.644024] EIP is at 0x40394596 >> [ =A0129.644024] EAX: 40412000 EBX: 40396cd8 ECX: 0909ee98 EDX: 00044000 >> [ =A0129.644024] ESI: 00000034 EDI: 0909edd8 EBP: bfe7f798 ESP: bfe7f780 >> [ =A0129.644024] =A0DS: 007b ES: 007b FS: 0000 GS: 0033 SS: 007b >> [ =A0129.644024] Process X (pid: 3690, ti=3Dea1ce000 task=3Dea77f110 >> task.ti=3Dea1ce000) >> [ =A0129.644024] >> [ =A0129.644024] EIP: [<40394596>] 0x40394596 SS:ESP 007b:bfe7f780 >> [ =A0129.644024] ---[ end trace 569eb18d737a8611 ]--- >> [ =A0129.652216] [drm] nouveau 0000:01:00.0: nouveau_channel_free: freei= ng >> 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 mfns and pf= ns, > and therefore ends up incorrectly setting the _PAGE_IO flag in some pte. = =A0If > you run it under strace, can you identify which mapping the fault is > happening in? > > =A0 =A0J > Just wanted to emphasise that not updating vma->vm_page_prot after updating the flags correctly failed to provide the solution. Maybe forcing this upda= te in all places will show up new failures. Also, maybe the final solution needs to 'or' TTM_PL_SYSTEM also into the conditional.