3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > It's actually more complicated than that. Old kernel images started
> > misbehaving from around 2.6.35-rc5 and any kernel older than that was
> > OK. When I recompiled the older kernels with squeeze gcc (migh have been
> > lenny gcc before, or different answers to make oldconfig), anything from
> > current git down to 2.6.33 is broken with radeon.modeset=1 and works (I
> 
> What releases of GCC were those?  I'm chasing an issue where compiling
> with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same 
> thing.

I do not remember when I upgraded from lenny to squeeze. It the previous 
gcc was lenny's, it was gcc version 4.3.2 (Debian 4.3.2-1.1). The gcc in 
current stable (squeeze) is gcc version 4.4.5 (Debian 4.4.5-8). Since 
the old laptop is somewhat slow for following unstable, I have not tried 
any newer gcc version on that machine, and it has been compiling its own 
kernels for stress-testing purposes.

So it's probably not related to gcc 4.6->4.7 changes.

-- 
Meelis Roos (mroos at linux.ee)

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > It's actually more complicated than that. Old kernel images started
> > misbehaving from around 2.6.35-rc5 and any kernel older than that was
> > OK. When I recompiled the older kernels with squeeze gcc (migh have been
> > lenny gcc before, or different answers to make oldconfig), anything from
> > current git down to 2.6.33 is broken with radeon.modeset=1 and works (I
> 
> What releases of GCC were those?  I'm chasing an issue where compiling
> with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same 
> thing.

I do not remember when I upgraded from lenny to squeeze. It the previous 
gcc was lenny's, it was gcc version 4.3.2 (Debian 4.3.2-1.1). The gcc in 
current stable (squeeze) is gcc version 4.4.5 (Debian 4.4.5-8). Since 
the old laptop is somewhat slow for following unstable, I have not tried 
any newer gcc version on that machine, and it has been compiling its own 
kernels for stress-testing purposes.

So it's probably not related to gcc 4.6->4.7 changes.

-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.5-rc5: radeon acceleration regression on Transmeta system

[valdis.kletni...@vt.edu]

On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said:

> It's actually more complicated than that. Old kernel images started
> misbehaving from around 2.6.35-rc5 and any kernel older than that was
> OK. When I recompiled the older kernels with squeeze gcc (migh have been
> lenny gcc before, or different answers to make oldconfig), anything from
> current git down to 2.6.33 is broken with radeon.modeset=1 and works (I

What releases of GCC were those?  I'm chasing an issue where compiling
with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same thing.
-- next part --
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 865 bytes
Desc: not available
URL: 

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

[valdis . kletnieks]

On Mon, 09 Jul 2012 14:30:40 +0300, Meelis Roos said:

> It's actually more complicated than that. Old kernel images started
> misbehaving from around 2.6.35-rc5 and any kernel older than that was
> OK. When I recompiled the older kernels with squeeze gcc (migh have been
> lenny gcc before, or different answers to make oldconfig), anything from
> current git down to 2.6.33 is broken with radeon.modeset=1 and works (I

What releases of GCC were those?  I'm chasing an issue where compiling
with 4.7.[01] breaks but 4.6.2 is OK, wondering if we're chasing the same thing.


pgpky9saflsmH.pgp
Description: PGP signature
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > > acceleration on this system at all. Full dmesg below.
> > 
> > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
> 
> That was a good question. I did some more tries, and it was not 
> repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, 
> no borders except when maximized, otherwise worked.

Re-tested 3.4.0-rc7 that I had availble from 3.4 times, it worked 4 out 
of 4 times.

> Initial windows border problem seems to have been introduced between 
> 2.6.37 and 2.6.38, bisect is slow.

It's actually more complicated than that. Old kernel images started 
misbehaving from around 2.6.35-rc5 and any kernel older than that was 
OK. When I recompiled the older kernels with squeeze gcc (migh have been 
lenny gcc before, or different answers to make oldconfig), anything from 
current git down to 2.6.33 is broken with radeon.modeset=1 and works (I 
get window titles) with radeon.modeset=0.

2.6.32 works and has kernel modesetting enabled from dmesg but I think I 
did not notice screen going fbcon during boot... maybe it only used the 
modesetting when X started.

So there are 2 different problems (maybe related), the new one above and 
the old one of not seeing some window borders when modesetting and 
acceleration are in use. Maximized windows do have borders.

-- 
Meelis Roos (mroos at linux.ee)

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > > acceleration on this system at all. Full dmesg below.
> > 
> > Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?
> 
> That was a good question. I did some more tries, and it was not 
> repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, 
> no borders except when maximized, otherwise worked.

Re-tested 3.4.0-rc7 that I had availble from 3.4 times, it worked 4 out 
of 4 times.

> Initial windows border problem seems to have been introduced between 
> 2.6.37 and 2.6.38, bisect is slow.

It's actually more complicated than that. Old kernel images started 
misbehaving from around 2.6.35-rc5 and any kernel older than that was 
OK. When I recompiled the older kernels with squeeze gcc (migh have been 
lenny gcc before, or different answers to make oldconfig), anything from 
current git down to 2.6.33 is broken with radeon.modeset=1 and works (I 
get window titles) with radeon.modeset=0.

2.6.32 works and has kernel modesetting enabled from dmesg but I think I 
did not notice screen going fbcon during boot... maybe it only used the 
modesetting when X started.

So there are 2 different problems (maybe related), the new one above and 
the old one of not seeing some window borders when modesetting and 
acceleration are in use. Maximized windows do have borders.

-- 
Meelis Roos (mr...@linux.ee)
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel

3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > acceleration on this system at all. Full dmesg below.
> 
> Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?

That was a good question. I did some more tries, and it was not 
repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, 
no borders except when maximized, otherwise worked.

Total 3 failures and 6 successes in intializing the card so far.

> if I had to guess something broke in the dma area elsewhere, but not sure.

Initial windows border problem seems to have been introduced between 
2.6.37 and 2.6.38, bisect is slow.

"Good" dmesg:

[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos at raamat) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0efd] usable
[0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data
[0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS
[0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] DMI 2.3 present.
[0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08  
02/24/2005
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c0098000] 98000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x0efd]
[0.00]  [mem 0x-0x003f] page 4k
[0.00]  [mem 0x0040-0x0ebf] page 2M
[0.00]  [mem 0x0ec0-0x0efd] page 4k
[0.00] kernel direct mapping tables up to 0xefd @ [mem 
0x017fa000-0x017f]
[0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ   )
[0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3   0108 MSFT 
0107)
[0.00] ACPI: FACS 0efeffc0 00040
[0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD  ACPIPST1 0001 PTL  
0001)
[0.00] 239MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0efe
[0.00]   low ram: 0 - 0efe
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0efd]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0001-0x0009bfff]
[0.00]   node   0: [mem 0x0010-0x0efd]
[0.00] On node 0 totalpages: 61292
[0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map 
cee00200
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3948 pages, LIFO batch:0
[0.00]   Normal zone: 448 pages used for memmap
[0.00]   Normal zone: 56864 pages, LIFO batch:15
[0.00] ACPI: PM-Timer IO Port: 0xff08
[0.00] PM: Registered nosave memory: 0009c000 - 000a
[0.00] PM: Registered nosave memory: 000a - 000e8000
[0.00] PM: Registered nosave memory: 000e8000 - 0010
[0.00] e820: [mem 0x0f10-0xffef] available for PCI devices
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 60812
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug 
radeon.modeset=1
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Initializing CPU#0
[0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k 
reserved, 984k data, 284k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xfffe4000 - 0xf000   ( 108 kB)
[0.00] vmalloc : 0xcf7e

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

> > In 3.4, radeon worked with a glitch - window titles were see-throug (not
> > drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> > acceleration on this system at all. Full dmesg below.
> 
> Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?

That was a good question. I did some more tries, and it was not 
repeatable. Sometimes it worked like 3.4 did - rv100 initialized fine, 
no borders except when maximized, otherwise worked.

Total 3 failures and 6 successes in intializing the card so far.

> if I had to guess something broke in the dma area elsewhere, but not sure.

Initial windows border problem seems to have been introduced between 
2.6.37 and 2.6.38, bisect is slow.

"Good" dmesg:

[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos@raamat) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0efd] usable
[0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data
[0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS
[0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] DMI 2.3 present.
[0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08  
02/24/2005
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c0098000] 98000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x0efd]
[0.00]  [mem 0x-0x003f] page 4k
[0.00]  [mem 0x0040-0x0ebf] page 2M
[0.00]  [mem 0x0ec0-0x0efd] page 4k
[0.00] kernel direct mapping tables up to 0xefd @ [mem 
0x017fa000-0x017f]
[0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ   )
[0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3   0108 MSFT 
0107)
[0.00] ACPI: FACS 0efeffc0 00040
[0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD  ACPIPST1 0001 PTL  
0001)
[0.00] 239MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0efe
[0.00]   low ram: 0 - 0efe
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0efd]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0001-0x0009bfff]
[0.00]   node   0: [mem 0x0010-0x0efd]
[0.00] On node 0 totalpages: 61292
[0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map 
cee00200
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3948 pages, LIFO batch:0
[0.00]   Normal zone: 448 pages used for memmap
[0.00]   Normal zone: 56864 pages, LIFO batch:15
[0.00] ACPI: PM-Timer IO Port: 0xff08
[0.00] PM: Registered nosave memory: 0009c000 - 000a
[0.00] PM: Registered nosave memory: 000a - 000e8000
[0.00] PM: Registered nosave memory: 000e8000 - 0010
[0.00] e820: [mem 0x0f10-0xffef] available for PCI devices
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 60812
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug 
radeon.modeset=1
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Initializing CPU#0
[0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k 
reserved, 984k data, 284k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xfffe4000 - 0xf000   ( 108 kB)
[0.00] vmalloc : 0xcf7e - 

3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

In 2.6.32, radeon worked fine.

In 3.4, radeon worked with a glitch - window titles were see-throug (not 
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables 
acceleration on this system at all. Full dmesg below.

Fujitsu Lifebook P series, 256M RAM, 239 usable.

[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos at raamat) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0efd] usable
[0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data
[0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS
[0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] DMI 2.3 present.
[0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08  
02/24/2005
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c0098000] 98000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x0efd]
[0.00]  [mem 0x-0x003f] page 4k
[0.00]  [mem 0x0040-0x0ebf] page 2M
[0.00]  [mem 0x0ec0-0x0efd] page 4k
[0.00] kernel direct mapping tables up to 0xefd @ [mem 
0x017fa000-0x017f]
[0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ   )
[0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3   0108 MSFT 
0107)
[0.00] ACPI: FACS 0efeffc0 00040
[0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD  ACPIPST1 0001 PTL  
0001)
[0.00] 239MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0efe
[0.00]   low ram: 0 - 0efe
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0efd]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0001-0x0009bfff]
[0.00]   node   0: [mem 0x0010-0x0efd]
[0.00] On node 0 totalpages: 61292
[0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map 
cee00200
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3948 pages, LIFO batch:0
[0.00]   Normal zone: 448 pages used for memmap
[0.00]   Normal zone: 56864 pages, LIFO batch:15
[0.00] ACPI: PM-Timer IO Port: 0xff08
[0.00] PM: Registered nosave memory: 0009c000 - 000a
[0.00] PM: Registered nosave memory: 000a - 000e8000
[0.00] PM: Registered nosave memory: 000e8000 - 0010
[0.00] e820: [mem 0x0f10-0xffef] available for PCI devices
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 60812
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug 
radeon.modeset=1
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Initializing CPU#0
[0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k 
reserved, 984k data, 284k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xfffe4000 - 0xf000   ( 108 kB)
[0.00] vmalloc : 0xcf7e - 0xfffe2000   ( 776 MB)
[0.00] lowmem  : 0xc000 - 0xcefe   ( 239 MB)
[0.00]   .init : 0xc1305000 - 0xc134c000   ( 284 kB)
[0.00]   .data : 0xc120de7e - 0xc13040c0   ( 984 kB)
[0.00]   .text : 0xc100 - 0xc120de7e   (2103 kB)
[0.00] Checking if this processor honours the WP bit even in supervisor 
mode...Ok.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] CPU 0 irqstacks, hard=ce

3.5-rc5: radeon acceleration regression on Transmeta system

[Dave Airlie]

On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos  wrote:
> In 2.6.32, radeon worked fine.
>
> In 3.4, radeon worked with a glitch - window titles were see-throug (not
> drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> acceleration on this system at all. Full dmesg below.

Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?

if I had to guess something broke in the dma area elsewhere, but not sure.

Dave.

3.5-rc5: radeon acceleration regression on Transmeta system

[Meelis Roos]

In 2.6.32, radeon worked fine.

In 3.4, radeon worked with a glitch - window titles were see-throug (not 
drawn). In 3.5-rc5, radeon driver seems to be more careful and disables 
acceleration on this system at all. Full dmesg below.

Fujitsu Lifebook P series, 256M RAM, 239 usable.

[0.00] Initializing cgroup subsys cpu
[0.00] Linux version 3.5.0-rc5-00098-g9e85a6f (mroos@raamat) (gcc 
version 4.4.5 (Debian 4.4.5-8) ) #61 Thu Jul 5 04:17:43 EEST 2012
[0.00] e820: BIOS-provided physical RAM map:
[0.00] BIOS-e820: [mem 0x-0x0009bfff] usable
[0.00] BIOS-e820: [mem 0x0009c000-0x0009] reserved
[0.00] BIOS-e820: [mem 0x000e8000-0x000f] reserved
[0.00] BIOS-e820: [mem 0x0010-0x0efd] usable
[0.00] BIOS-e820: [mem 0x0efe-0x0efefbff] ACPI data
[0.00] BIOS-e820: [mem 0x0efefc00-0x0efe] ACPI NVS
[0.00] BIOS-e820: [mem 0x0eff-0x0f0f] reserved
[0.00] BIOS-e820: [mem 0xfff0-0x] reserved
[0.00] Notice: NX (Execute Disable) protection missing in CPU!
[0.00] DMI 2.3 present.
[0.00] DMI: FUJITSU LifeBook P Series/FJNB164, BIOS Version 1.08  
02/24/2005
[0.00] e820: update [mem 0x-0x] usable ==> reserved
[0.00] e820: remove [mem 0x000a-0x000f] usable
[0.00] e820: last_pfn = 0xefe0 max_arch_pfn = 0x10
[0.00] initial memory mapped: [mem 0x-0x017f]
[0.00] Base memory trampoline at [c0098000] 98000 size 16384
[0.00] init_memory_mapping: [mem 0x-0x0efd]
[0.00]  [mem 0x-0x003f] page 4k
[0.00]  [mem 0x0040-0x0ebf] page 2M
[0.00]  [mem 0x0ec0-0x0efd] page 4k
[0.00] kernel direct mapping tables up to 0xefd @ [mem 
0x017fa000-0x017f]
[0.00] ACPI: RSDP 000f70a0 00014 (v00 FUJ   )
[0.00] ACPI: RSDT 0efedad0 0002C (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: FACP 0efefa92 00074 (v01 FUJMOMUS3   0108 FUJ  
1000)
[0.00] ACPI: DSDT 0efedafc 01F96 (v01 FUJMOMUS3   0108 MSFT 
0107)
[0.00] ACPI: FACS 0efeffc0 00040
[0.00] ACPI: SSDT 0efefb06 000FA (v01 PTLTD  ACPIPST1 0001 PTL  
0001)
[0.00] 239MB LOWMEM available.
[0.00]   mapped low ram: 0 - 0efe
[0.00]   low ram: 0 - 0efe
[0.00] Zone ranges:
[0.00]   DMA  [mem 0x0001-0x00ff]
[0.00]   Normal   [mem 0x0100-0x0efd]
[0.00] Movable zone start for each node
[0.00] Early memory node ranges
[0.00]   node   0: [mem 0x0001-0x0009bfff]
[0.00]   node   0: [mem 0x0010-0x0efd]
[0.00] On node 0 totalpages: 61292
[0.00] free_area_init_node: node 0, pgdat c12ff888, node_mem_map 
cee00200
[0.00]   DMA zone: 32 pages used for memmap
[0.00]   DMA zone: 0 pages reserved
[0.00]   DMA zone: 3948 pages, LIFO batch:0
[0.00]   Normal zone: 448 pages used for memmap
[0.00]   Normal zone: 56864 pages, LIFO batch:15
[0.00] ACPI: PM-Timer IO Port: 0xff08
[0.00] PM: Registered nosave memory: 0009c000 - 000a
[0.00] PM: Registered nosave memory: 000a - 000e8000
[0.00] PM: Registered nosave memory: 000e8000 - 0010
[0.00] e820: [mem 0x0f10-0xffef] available for PCI devices
[0.00] pcpu-alloc: s0 r0 d32768 u32768 alloc=1*32768
[0.00] pcpu-alloc: [0] 0 
[0.00] Built 1 zonelists in Zone order, mobility grouping on.  Total 
pages: 60812
[0.00] Kernel command line: 
BOOT_IMAGE=/boot/vmlinuz-3.5.0-rc5-00098-g9e85a6f root=/dev/sda1 ro debug 
radeon.modeset=1
[0.00] PID hash table entries: 1024 (order: 0, 4096 bytes)
[0.00] Dentry cache hash table entries: 32768 (order: 5, 131072 bytes)
[0.00] Inode-cache hash table entries: 16384 (order: 4, 65536 bytes)
[0.00] __ex_table already sorted, skipping sort
[0.00] Initializing CPU#0
[0.00] Memory: 239300k/245632k available (2103k kernel code, 5868k 
reserved, 984k data, 284k init, 0k highmem)
[0.00] virtual kernel memory layout:
[0.00] fixmap  : 0xfffe4000 - 0xf000   ( 108 kB)
[0.00] vmalloc : 0xcf7e - 0xfffe2000   ( 776 MB)
[0.00] lowmem  : 0xc000 - 0xcefe   ( 239 MB)
[0.00]   .init : 0xc1305000 - 0xc134c000   ( 284 kB)
[0.00]   .data : 0xc120de7e - 0xc13040c0   ( 984 kB)
[0.00]   .text : 0xc100 - 0xc120de7e   (2103 kB)
[0.00] Checking if this processor honours the WP bit even in supervisor 
mode...Ok.
[0.00] NR_IRQS:16 nr_irqs:16 16
[0.00] CPU 0 irqstacks, hard=ce806

Re: 3.5-rc5: radeon acceleration regression on Transmeta system

[Dave Airlie]

On Thu, Jul 5, 2012 at 8:00 AM, Meelis Roos  wrote:
> In 2.6.32, radeon worked fine.
>
> In 3.4, radeon worked with a glitch - window titles were see-throug (not
> drawn). In 3.5-rc5, radeon driver seems to be more careful and disables
> acceleration on this system at all. Full dmesg below.

Does it always do it the same? got the dmesg from 3.4 and/or 2.6.32?

if I had to guess something broke in the dma area elsewhere, but not sure.

Dave.
___
dri-devel mailing list
dri-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/dri-devel