HD 4850 + Catalyst 8.7 = hiccups

[DeX77]

I think we can outrule mtrr then, because this is identic in both your 32-bit and 64-bit system.

Can you perhaps try the following in your glitching 64-Bit system:
* switch to non x runlevel
* sudo modprobe -r fglrx
* mv fglrx.ko somewhere out of /lib/modules
* switch to runlevel with x

For me this gives a X without DRI support with hiccups.
Obviously the fglrx module isn't loaded.
Next thing: reboot

This results in my case in a system without DRI but also without hiccups!

Some othter thing I noticed in my Xorg.0.log is:

(II) fglrx(0):     Build-Kernel __SMP__:            no

CPU is a Athlon64 X2 so this sounds wrong for me. Perhaps different in your 32-bit 64-bit variants, too?

[jabbas]

Before checking forum i installed 64bit Ubuntu, installed ati drivers and i do not have hiccups here also...

Compiz works smoothly like hell...

I'll post it's mtrr, IRQs and stuff here...
Next I will try to check Your ideas (with unloading fglrx module and etc.) and after that I'll check differences between my (probably lame) and Ubuntu's kernel configs.

/proc/interrupts

           CPU0       CPU1       CPU2       CPU3       
  0:         99          0          0          1   IO-APIC-edge      timer
  1:          0          0          0          2   IO-APIC-edge      i8042
  8:          0          0          0          1   IO-APIC-edge      rtc
  9:          0          0          0          0   IO-APIC-fasteoi   acpi
 12:          0          0          0          4   IO-APIC-edge      i8042
 14:          0          0        350      29017   IO-APIC-edge      libata
 15:          0          0          0          0   IO-APIC-edge      libata
 16:          0          0          3       1262   IO-APIC-fasteoi   ohci_hcd:usb1, HDA Intel, HDA Intel
 17:          0          0          1       1486   IO-APIC-fasteoi   ohci_hcd:usb2, ohci_hcd:usb4
 18:          0          0         31      23439   IO-APIC-fasteoi   ohci_hcd:usb3, ohci_hcd:usb5
 19:          0          2        297     165870   IO-APIC-fasteoi   ehci_hcd:usb6, fglrx[0]@PCI:2:0:0
 20:          0          0          0         48   IO-APIC-fasteoi   saa7133[0], saa7133[0]
 21:          0          0          0          6   IO-APIC-fasteoi   eth0
 22:          0          0          0          0   IO-APIC-fasteoi   ahci
509:          0          0         38      16860   PCI-MSI-edge      eth1
NMI:          0          0          0          0   Non-maskable interrupts
LOC:      52977      33452      29642      81351   Local timer interrupts
RES:      28962      20999      17264      13783   Rescheduling interrupts
CAL:        267        347        350        144   function call interrupts
TLB:        790       1152       1892        771   TLB shootdowns
TRM:          0          0          0          0   Thermal event interrupts
THR:          0          0          0          0   Threshold APIC interrupts
SPU:          0          0          0          0   Spurious interrupts
ERR:          0

/proc/mtrr

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1

dmesg |grep IRQ

[    0.000000] ACPI: IRQ0 used by override.
[    0.000000] ACPI: IRQ2 used by override.
[    0.000000] ACPI: IRQ9 used by override.
[   27.499963] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500078] ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500191] ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500303] ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500414] ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500526] ACPI: PCI Interrupt Link [LNKF] (IRQs 9) *0, disabled.
[   27.500635] ACPI: PCI Interrupt Link [LNKG] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.500746] ACPI: PCI Interrupt Link [LNKH] (IRQs 3 4 5 7 10 11 12 14 15) *0, disabled.
[   27.503632] PCI: Using ACPI for IRQ routing
[   27.513077] hpet0: at MMIO 0xfed00000, IRQs 2, 8, 0, 0
[   28.186629] Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
[   29.492058] ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 16 (level, low) -> IRQ 16
[   29.652782] ACPI: PCI Interrupt 0000:00:13.1[B] -> GSI 17 (level, low) -> IRQ 17
[   29.816420] ACPI: PCI Interrupt 0000:00:13.2[C] -> GSI 18 (level, low) -> IRQ 18
[   29.980073] ACPI: PCI Interrupt 0000:00:13.3[B] -> GSI 17 (level, low) -> IRQ 17
[   30.143737] ACPI: PCI Interrupt 0000:00:13.4[C] -> GSI 18 (level, low) -> IRQ 18
[   30.307534] ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22
[   32.563018] ACPI: PCI Interrupt 0000:00:13.5[D] -> GSI 19 (level, low) -> IRQ 19
[   32.742643] ACPI: PCI Interrupt 0000:03:06.0[A] -> GSI 21 (level, low) -> IRQ 21
[   32.743575] eth0: RealTek RTL8139 at 0xe800, 00:0d:f3:05:33:dd, IRQ 21
[   32.745543] ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16
[   45.409704] ACPI: PCI Interrupt 0000:01:00.0[A] -> GSI 18 (level, low) -> IRQ 18
[   45.642319] ACPI: PCI Interrupt 0000:02:00.0[A] -> GSI 19 (level, low) -> IRQ 19
[   46.170905] ACPI: PCI Interrupt 0000:00:14.2[A] -> GSI 16 (level, low) -> IRQ 16
[   46.573276] ACPI: PCI Interrupt 0000:02:00.1[B] -> GSI 16 (level, low) -> IRQ 16
[   46.619282] ACPI: PCI Interrupt 0000:03:05.0[A] -> GSI 20 (level, low) -> IRQ 20

Strange for me is that mtrr's does not show any additional memory on my computer like on yours...

[DeX77]

/proc/mtrr

reg00: base=0x00000000 (   0MB), size=2048MB: write-back, count=1

Strange for me is that mtrr's does not show any additional memory on my computer like on yours...

Would be correct if you got 2Gb of RAM and no other virtual memorry device (which is wrong as your video card is such a device)
Although if I understood it correctly PAT and MTRR are two different ways to specifiy how the kernel does handle a mem range - or in case of pat - a single page.

The output from lspci -v should mention some memory offset for your ati card.
(And for me it shows wrong 256Mb VRAM.. hmm)

I did not find a way to check what the kernels pat is configured curently so far.

[jabbas]

Yep, for me it shows wrong amount as well:

02:00.0 VGA compatible controller: ATI Technologies Inc Device 9440 (prog-if 00 [VGA controller])
        Subsystem: ATI Technologies Inc Device 0502
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at d0000000 (64-bit, prefetchable) [size=256M]
        Memory at feaf0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at d000 [size=256]
        Expansion ROM at feac0000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Queue=0/0 Enable-
        Capabilities: [100] Vendor Specific Information <?>
        Kernel driver in use: fglrx_pci
        Kernel modules: fglrx

about PAT: I tried to pass nopat to the kernel but it didn't change anything, anyway if I pass noapic it seems that hiccups occur less often.

[jabbas]

About checking with and w/o module:

If I boot with loaded fglrx module and start X hiccups occur (You know that already)
If I stop X, remove fglrx module (rmmod, mv fglrx.ko somwhere, depmod -a), and then I start X system hangs totally
If I load system without module, X starts, there is no hiccups but (as You also know) speed is awful (due to the no hw accel i assume).

I think that this have something to do with /dev/dri/card0 (if it's available - system hangs).

[DeX77]

So you got exactly the same effects than me, this is bad for you but good for getting to the point of this all

I noticed some other user having similar issues from Arch:

http://bbs.archlinux.org/viewtopic.php?id=55558

So the bug is not limited to the 4xxx ATI series (was my first guess)

From what I've read in Documentation/x86/pat.txt somehow /dev/mem should represent what parts of mem are marked [uc] for uncached or [wc] for write-combined.

I'll check this at my box when I return.

[jabbas]

I loaded Ubuntu's kernel config and now compiling it without any changes. I'll get back after checking this too

After using Ubuntu's kernel config - no change

[DeX77]

Just to make things complete:

01:00.0 VGA compatible controller: ATI Technologies Inc RV770 [Radeon HD 4850] (prog-if 00 [VGA controller])
        Subsystem: ATI Technologies Inc Device 0502
        Flags: bus master, fast devsel, latency 0, IRQ 19
        Memory at c0000000 (64-bit, prefetchable) [size=256M]
        Memory at dfae0000 (64-bit, non-prefetchable) [size=64K]
        I/O ports at ee00 [size=256]
        [virtual] Expansion ROM at dfa00000 [disabled] [size=128K]
        Capabilities: [50] Power Management version 3
        Capabilities: [58] Express Legacy Endpoint, MSI 00
        Capabilities: [a0] Message Signalled Interrupts: Mask- 64bit+ Count=1/1 Enable-
        Kernel driver in use: fglrx_pci
        Kernel modules: fglrx

At least mine gets detected correctly as RV770.. Guess this is due to newer pciutils.

I did not find a way to check what exactly gets changed in pagetables in runtime. I guess I have to grep myself trough /usr/src/linux

Can you perhaps check on your working system if the total amount of VRAM gehts detected?

I think memory is the right direction because I noticed that most hiccups occour when large amounts of screen change. (Like scene switch while watching video or when rotating in FPS of choice)

I also noticed I get an higher amount of hiccups when enlarge my video player.
Perhaps I'll succedd in installing a very small (< 1Gb) base system with Kernel < 2.6.25 and fglrx > 8.7 in my swap.

[jabbas]

Just to make things complete:

At least mine gets detected correctly as RV770.. Guess this is due to newer pciutils.

I did not find a way to check what exactly gets changed in pagetables in runtime. I guess I have to grep myself trough /usr/src/linux

Can you perhaps check on your working system if the total amount of VRAM gehts detected?

Yes.
grep RAM /var/log/Xorg.0.log

(--) fglrx(0): Video RAM: 524288 kByte, Type: GDDR5

I think memory is the right direction because I noticed that most hiccups occour when large amounts of screen change. (Like scene switch while watching video or when rotating in FPS of choice)

I also noticed I get an higher amount of hiccups when enlarge my video player.

Yes I noticed that too.

Perhaps I'll succedd in installing a very small (< 1Gb) base system with Kernel < 2.6.25 and fglrx > 8.7 in my swap.

I figured out that Ubuntu have 1.4.0.90 xorg-server, but I have old 1.3.0. Is there a possibility that they optimized ati-drivers to the new XOrg? I'll try to install this version and check it out.

Also I noticed that when the hiccup occur the X process is eating 100% of CPU, but I noticed also that every process which belongs to X (it's forked or whatever) uses same processor core like X (which is CPU3 in my case)... even when I launch smp version of quake it uses only one core, I'll check kernel scheduler too...

[DeX77]

Yes.
grep RAM /var/log/Xorg.0.log

(--) fglrx(0): Video RAM: 524288 kByte, Type: GDDR5

Ok, I should have been more concrete: I meant the amount printed by lspci.

grep RAM /var/log/Xorg.0.log

(--) fglrx(0): Video RAM: 524288 kByte, Type: GDDR3

This is also what Catalyst Control Center tells me. Perhaps the difference in what the kernel thinks and what fglrx thinks results in our problems?

I figured out that Ubuntu have 1.4.0.90 xorg-server, but I have old 1.3.0. Is there a possibility that they optimized ati-drivers to the new XOrg? I'll try to install this version and check it out.

Good luck, but Xorg is heavily nested into system so I guess this will not succeed.
My xorg-server is version 1.4.2 BTW.

Also I noticed that when the hiccup occur the X process is eating 100% of CPU, but I noticed also that every process which belongs to X (it's forked or whatever) uses same processor core like X (which is CPU3 in my case)... even when I launch smp version of quake it uses only one core, I'll check kernel scheduler too...

Hmm.. I'm not quite sure, but it could be possible that something in X is forcing forked processes to be not migrated to other cpu.

Hot exactly did you check this?