[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion

2010-04-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27603

--- Comment #13 from Alex Buell  2010-04-14 12:49:04 
PDT ---
(In reply to comment #12)
> Can you try with NOUVEAU_VTXIDX_IN_VRAM=1 ?
> 
> There is a very recent regression that causes a huge performance drop for my
> agp card at least.
> By setting the above variable, it goes from 2-3fps to 10-15fps :)

Yes, that was a huge improvement with that variable set, thanks for that one!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion

2010-04-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27603

--- Comment #12 from Xavier  2010-04-14 12:19:03 PDT ---
Can you try with NOUVEAU_VTXIDX_IN_VRAM=1 ?

There is a very recent regression that causes a huge performance drop for my
agp card at least.
By setting the above variable, it goes from 2-3fps to 10-15fps :)

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 26733] Full-screen XV causes graphics lockup

2010-04-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=26733

--- Comment #13 from okias  2010-04-14 07:43:57 PDT ---
Created an attachment (id=35000)
 --> (https://bugs.freedesktop.org/attachment.cgi?id=35000)
dmesg_extended

dmesg with mwk's patches for verbose bugreporting

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


[Nouveau] [Bug 27603] [nouveau] Celestia 1.6.0 crashes with nv04_surface_copy_swizzle assertion

2010-04-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27603

Alex Buell  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution||FIXED

--- Comment #11 from Alex Buell  2010-04-14 05:47:07 
PDT ---
To resolve these issues with Celestia, it is necessary to compile and install
the origin/nvfx-next branch from the official mesa.git respository. It should
be noted, however that it is very slow but that's a different issue altogether
and can be addressed at some point in the future. 

I would like to see the work from the nvfv branch be merged into the official
mesa releases, maybe for 7.9.x? 

Thanks for all the help given!

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau


Re: [Nouveau] [PATCH] drm/nouveau: fix vbios load and check functions on PowerPC

2010-04-14 Thread Marcin Slusarz
On Tue, Mar 23, 2010 at 06:09:07PM +0100, tacco...@libero.it wrote:
> From: Andrea Tacconi 
> 
> Subject: [PATCH] drm/nouveau: fix vbios load and check functions on PowerPC
> 
> On PowerPC the Bios signature reports a wrong lenght of video rom.
> Fix this by reading the correct size from Open Firmware.
> 
> Set Pramin as primary vbios searching method, because it's the only working 
> method on PowerPC.
> 
> The nv_cksum function always fails.
> Fix this by Calculating and adding checksum byte at the end of vbios.
> 
> Signed-off-by: Andrea Tacconi 
> ---
> diff --git a/drivers/gpu/drm/nouveau/nouveau_bios.c 
> b/drivers/gpu/drm/nouveau/nouveau_bios.c
> index 6b6c303..c234b45 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_bios.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_bios.c
> @@ -69,12 +69,29 @@ static bool nv_cksum(const uint8_t *data, unsigned int 
> length)
>  static int
>  score_vbios(struct drm_device *dev, const uint8_t *data, const bool 
> writeable)
>  {
> + int bios_size = 0;
> +#if defined(__powerpc__)
> + struct device_node *dn = NULL;
> +#endif
> +
>   if (!(data[0] == 0x55 && data[1] == 0xAA)) {
>   NV_TRACEWARN(dev, "... BIOS signature not found\n");
>   return 0;
>   }
> +#if defined(__powerpc__)
> + /*
> +  * The Bios signature reports a wrong lenght of rom.
> +  * The correct size is read from Open Firmware.
> +  */
> + dn = pci_device_to_OF_node(dev->pdev);
> + of_find_property(dn, "NVDA,BMP", &bios_size);
> + /* added checksum byte */
> + bios_size++;
> +#else
> + bios_size = (data[2] * 512);
> +#endif
>  
> - if (nv_cksum(data, data[2] * 512)) {
> + if (nv_cksum(data, bios_size)) {

how about factoring bios_size calculation to another function?

#if defined(__powerpc__)
int fun()
{
}
#else
int fun()
{
}
#endif

>   NV_TRACEWARN(dev, "... BIOS checksum invalid\n");
>   /* if a ro image is somewhat bad, it's probably all rubbish */
>   return writeable ? 2 : 1;
> @@ -183,11 +200,22 @@ struct methods {
>   const bool rw;
>  };
>  
> +#if defined(__powerpc__)
> + /*
> +  * For now PRAMIN is the only working method on PowerPC
> +  */
> +static struct methods nv04_methods[] = {
> + { "PRAMIN", load_vbios_pramin, true },
> + { "PROM", load_vbios_prom, false },
> + { "PCIROM", load_vbios_pci, true },
> +};
> +#else
>  static struct methods nv04_methods[] = {
>   { "PROM", load_vbios_prom, false },
>   { "PRAMIN", load_vbios_pramin, true },
>   { "PCIROM", load_vbios_pci, true },
>  };
> +#endif

it pramin is the only method why do you need to redefine this array with 
different order?
doesn't it fallback to next method when earlier fails?

>  
>  static struct methods nv50_methods[] = {
>   { "PRAMIN", load_vbios_pramin, true },
> diff --git a/drivers/gpu/drm/nouveau/nouveau_state.c 
> b/drivers/gpu/drm/nouveau/nouveau_state.c
> index 58b4680..35d35cc 100644
> --- a/drivers/gpu/drm/nouveau/nouveau_state.c
> +++ b/drivers/gpu/drm/nouveau/nouveau_state.c
> @@ -607,19 +607,49 @@ int nouveau_firstopen(struct drm_device *dev)
>  static void nouveau_OF_copy_vbios_to_ramin(struct drm_device *dev)
>  {
>  #if defined(__powerpc__)
> - int size, i;
> - const uint32_t *bios;
> + /*
> +  * Copy BMP Bios to RAMIN, calculate its checksum and append it to Bios.
> +  */
> + int size, i, j, unread_bytes, size_int;
> + uint8_t sum = 0;
> + uint8_t checksum = 0;
> + uint32_t last_bytes = 0;
> + const uint32_t *bios = NULL;
>   struct device_node *dn = pci_device_to_OF_node(dev->pdev);
> - if (!dn) {
> - NV_INFO(dev, "Unable to get the OF node\n");
> - return;
> - }
>  
> + size_int = sizeof(uint32_t);
>   bios = of_get_property(dn, "NVDA,BMP", &size);
> + /* write bios data and sum all bytes */
>   if (bios) {
> - for (i = 0; i < size; i += 4)
> - nv_wi32(dev, i, bios[i/4]);
> - NV_INFO(dev, "OF bios successfully copied (%d bytes)\n", size);
> + for (j = 0, i = 0; j < (size / size_int); j++, i += 4) {

you are using uint32_t, nv_wi32, incrementing by 4, so why do you need size_int?

> + nv_wi32(dev, i, bios[j]);
> + sum += (bios[j] & 0xFF00) >> 24;
> + sum += (bios[j] & 0xFF) >> 16;
> + sum += (bios[j] & 0xFF00) >> 8;
> + sum += (bios[j] & 0xFF);
> + }
> + unread_bytes = size % size_int;

unwritten_bytes?

> + switch (unread_bytes) {
> + case 0:
> + /* all bytes were read, nothing to do */
> + break;
> + case 3:
> + sum += (bios[j] & 0xFF00) >> 8;
> + last_bytes |= (bios[j] & 0xFF00);
> + case 2:
> + sum += (bios[j] & 0xFF) >> 

[Nouveau] [Bug 27574] BUG: unable to handle kernel NULL pointer dereference at 0000000000000028

2010-04-14 Thread bugzilla-daemon
https://bugs.freedesktop.org/show_bug.cgi?id=27574

--- Comment #1 from Xavier  2010-04-14 02:49:02 PDT ---
Just for the record, Alex reported this bug to kernel bugzilla in the same time
:
https://bugzilla.kernel.org/attachment.cgi?id=25936

And also 2 months ago already on FDO, but mixed with other issues about s2ram
and s2disk :
http://bugs.freedesktop.org/show_bug.cgi?id=26521
Another user (Michal) caught the same trace there too :
http://bugs.freedesktop.org/attachment.cgi?id=34299

-- 
Configure bugmail: https://bugs.freedesktop.org/userprefs.cgi?tab=email
--- You are receiving this mail because: ---
You are the assignee for the bug.
___
Nouveau mailing list
Nouveau@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/nouveau