pregnant pauses in 2-D graphics; IRQ assignment?
Motherboard: supermicro P4DCE+,
dual 2GHz Xeon CPUs, 1GB RAM
Graphics card: tried both GF4 Ti4600 and GF4 MX400
Kernel: tried RH's 2.4.18-5smp,
RH's 2.4.18-3 smp bigmem,
kernel boot options: tried "noapic", "nosmp noapic" as well as default.
XFree86: 4.2.0 as shipped with RH7.3.
NVidia drivers: tried 2880 and 4363.
AGP access: tried Option "NvAGP" "0"
and default (which gave 4x AGP via agpgart).
I've tried many, many combinations of the
but always find the following problem:
Many attempts to do things requiring 2-D
bit-blitting -- e.g. dragging an xterm
or even painting text into an xterm or
painting buttons on a GUI -- are liable to
be extremely slow, such that the entire
X server will lock up for tens of seconds at
a time. This makes it hard to type,
let alone work normally.
Curiously, 3-D opengl graphics don't
seem to suffer from this problem.
A similar system (Supermicro P4DCE+,
dual 2GHz Xeons, 2GB RAM) doesn't
have this problem.
The problem also goes away if I use
the "nv" driver instead of "nvidia",
but we really need the 3-D acceleration.
Suspicion: on the troublesome system,
the nvidia card always shares a
PCI interrupt (16) with the ethernet controller. On the well-running system,
the nvidia card has IRQ 10 to itself.
I can't seem to change the IRQ assignment
with tweaks like (since 01:00.0 is the nv card)
setpci -v -s 01:00.0 interrupt_line=12
setpci -v -s 01:00.0 interrupt_pin=2
The Ethernet is on the motherboard,
so I can't just move it to a different slot.
Anyone seen such a problem?
If you (temporarily, of course) disable the onboard Ethernet card, does that help at all?
If you add Option "RenderAccel" "true" to your Device section in XF86Config-4, does that help the 2D speed at all? Careful, though -- RenderAccel isn't stable on all systems.
modprobe -r eepro100
and the system hung each time! At least, X hung, and with the network down
I couldn't test any other way.
I didn't get a chance to try it *before* starting X. But this behavior seems pretty weird to me,
and makes me think that the problem really might be IRQ-related.
neither the window manager (fvwm2)
nor xterm will be using the RENDER extension.
Also, even if it were a question of software vs. hardware acceleration,
the delays I'm seeing are far too slow for software anything. We get delays of
sometimes tens of seconds before a moved window appears in its new place,
or before a newly-mapped window appears on the screen.
XF86Config-4, and XFree86.0.log
Here I'm trying to attach XF86Config-4
and XFree86.0.log for one of the many
failing setups, one that exhibits these puzzling pauses that seem related to 2-D graphic ops.
Attachments didn't seem to work in previous
attempts (Browse allows choosing the file,
no error appears, but there's no "attachment" icon displayed after final posting).
Any better now?
Nope. Too bad. And the XFree86.0.log is too long to be pasted in-line. Moderator, can you guess why attachments are not working for me? I'm posting from Phoenix 0.5 browser under Linux.
When you hit preview, the attachment goes away. Maybe that's part of the issue?
Yes, RenderAccel still might help, even with fvwm and xterm. It accelerates all sorts of things. Try it.
And when I said "disable the Ethernet", I didn't mean unload the drivers. I meant go into your BIOS and turn it off, so it's not even available when you boot. You may get an error when your network init script runs, but just ignore that.
|All times are GMT -5. The time now is 02:21 PM.|
Powered by vBulletin® Version 3.7.1
Copyright ©2000 - 2014, Jelsoft Enterprises Ltd.
Copyright ©1998 - 2014, nV News.