LinuxMCE Forums
General => Users => Topic started by: fearingsept on May 19, 2008, 05:01:52 pm
-
I was watching a dvd last night on my hybrid/core and noticed that the playback was starting to get a little choppy. I thought that this might be just an issue with the dvd but then I noticed it on regular TV and playback of recorded video.
Has anyone else had this issue?
If so, is there a work around?
-Dustin
-
Choppy? Do you mean the tearing-problem?
Probably if you have an nvidia card - I'm still baffled about this one.
-
It could be described as that... Its like whenever there is fast action there is this lag, but almost unnoticeable.
-
Yes, I see this every few days. Rebooting the core/hybrid temporarily solves the problem. I'm noticing the problem more since I upgraded TV from NTSC to 1080p. BTW, there are a couple of other threads currently going on this issue. You might want to try:
http://wiki.linuxmce.org/index.php/Nvidia_Card_Tweaks_For_Better_MythTV_and_UI_Performance (http://wiki.linuxmce.org/index.php/Nvidia_Card_Tweaks_For_Better_MythTV_and_UI_Performance)
HTH,
Roy
-
For completeness, I think "choppy" and tearing are quite different problems. I get choppiness, mostly - this is visible in big pans/zooms, lots of motion. It is irregular, but it looks like the image is "sticking" and then suddenly jumping to the new position in the pan/zoom without going through the intervening steps. So effectively missing frames which I know exist in the media (happens on media files, live TV, DVDs, etc). Doesn't appear to be CPU related as the CPU is very low. I have been completely unable to determine how much hardware acceleration LMCE is able to achieve out of my nVidia chipset - it should be more than capable, but just doesn't seem able to achieve it.
Tearing is more related to screen drawing, or flipping, not being sync'd with the vertical retrace of the TV, thus momentarily capturing two different images on screen at the same time, with a "tear" line being the join between them. When I turn off my vsync in nvidia-settings, I get vastly higher frame rates in glxgears (1100fps as opposed to 40fps) and the tearing starts (fairly minor), but the jerkiness/choppiness doesn't get any better! Completely stumped!
-
Tearing is more related to screen drawing, or flipping, not being sync'd with the vertical retrace of the TV, thus momentarily capturing two different images on screen at the same time, with a "tear" line being the join between them. When I turn off my vsync in nvidia-settings, I get vastly higher frame rates in glxgears (1100fps as opposed to 40fps) and the tearing starts (fairly minor), but the jerkiness/choppiness doesn't get any better! Completely stumped!
I think tearing better discribes my issue.
I really hope someone figures this out soon... I wish I knew more.
-
If its tearing for you, have you tried turning on the vsync options? That's the point of them - to sync screen drawing/flipping with the vertical retrace so that it is never drawing at the same time as refreshing the TV.
Also, are you using alpha blended mode? As you will see from all the commentary, this always displays some tearing and there's not much you can do about it as it relates to the lack of Linux support for various hardware acceleration features, currently. Do a search for totallymaxed's posts with the word tear, as he has plenty of experience of testing this. Drop back to masked mode...
-
I searched for totallymaxed's posts and I saw someone was also pointing to the UI-Alpha mode, but I don't completely get what's so special about this mode...
(I have all the vsyncing options turned on) I run compiz on another computer, with a newer card, but I don't have any tearing there. I also tried mythbuntu for a few days (for my DVB-S card) on the HTPC and I didn't have any tearing there, either! I even copied the monitor & screen related sections from the mythbuntu xorg.conf but still nothing.
Are the drivers in 0710 older then in Ubuntu 8.04?
-
The drivers for nVidia cards can be updated using ENVY -> http://albertomilone.com/nvidia_scripts1.html
But its not an issue of old drivers (I think the drivers used in ubuntu 0804 are the same as in LMCE)
With UI2 alpha there is a lot of graphics overhead for the transparancy element of the UI. Dropping to UI2 masked does get rid of tearing.
You will notice in mythbuntu 0804 etc that the UI is very simple and so not hardware demanding.
-
I will try to use UI2 without the alpha blending and see what happens.
Hopefully this will take care of it.
-
Tearing, stuttering and interlace issues all appear to go away when you use the DVI out rather than component or VGA out and input the DVI to a HDMI port on a good TV. The TV takes the data stream and converts it to video rather than require the video card in the computer to do this.
DVI out using 720P or 1080I resolution with transparancy off. Perfect picture.
-
You are lucky. nvidia 7600 GS DVI out to 1080p HDMI input on Hitachi P60X901, masked UI2, still stuttering here...
-
Same, nvidia 7050PV HDMI out to HDMI in, still stuttering...
-
I finially got around to turning of the Alpha blending and my issue was resolved.
Thanks for helping
-Dustin
-
*Update*
After changing to UI 2 I had to change back to UI 2 with alpha blending. For some reason when watching live tv my menu was not responding correctly. I would hit the menu button and it would be a good 30 seconds or more before the menu would actually appear.
I figured that a little tearing was ok compaired to delay in menu function. When I changed back to UI 2 with alpha blending the problem with the menu went away... Has anyone else had this issue?
-
;)
I noticed this as well. Using UI2 w/masking, my menu's became non-responsive. I changed back to UI2 Alpha Blending, and the issue went away completely. When I get home this evening, I am going to try removing "UseEvents" "True" to "False" and see if I get the same result. My alpha blended UI works exceptionally well, however, I noticed yesterday while playing some music, that it is very hard to see the track titles and such. This is what made me switch back to UI2 Masked. But I cannot handle the delay and latency of masked. It is much smoother and cleaner transition while using UI2 Alpha.
Just my experience.
Regards,
Seth
-
Hi,
For completeness, I think "choppy" and tearing are quite different problems. I get choppiness, mostly - this is visible in big pans/zooms, lots of motion. It is irregular, but it looks like the image is "sticking" and then suddenly jumping to the new position in the pan/zoom without going through the intervening steps. So effectively missing frames which I know exist in the media (happens on media files, live TV, DVDs, etc). Doesn't appear to be CPU related as the CPU is very low. I have been completely unable to determine how much hardware acceleration LMCE is able to achieve out of my nVidia chipset - it should be more than capable, but just doesn't seem able to achieve it.
This exactly descibes the problems I am having with my setup. See signature.
EDIT: interesting enough it offen happens at the same place in the recording ...
I would say it has something to do with xine.
I have tested with VDR and I am now pretty sure it has nothing to do with the xinelibout settings.
On the same MD system I did an default automatic install of EasyVDR on an IDE disk i attached and after that followed the instructions for adding a HD repack - both described here (click) (http://www.easy-vdr.de/forum/index.php?topic=6101.0).
Then I just did add a Modes line to xorg.conf like this :
Modes "1920x1080_50"
rebooted and entered the setup of xineliboutput under VDR and changed to use tvtime deinterlacer.
After that I had a very nice stutterfree replay of my videos on the same Hardware that is not able to play stutterfree on LinuxMCE. So the question is what is different and what can we do to fix it ?
Any ideas ?
Anyone tried 0810 if it is the same problem there ?
Is 0810 going to use VDPAU ?
Greetings
Viking
-
Hi,
Here some differences between EasyVDR and LinuxMCE :
- different kernel - 2.6.28.7 / 2.6.22-14
- kernel options :
EasyVDR CONFIG_HZ_1000=y
LinuxMCE CONFIG_HZ_250=y
- different Xine and Xineliboutput
- IRQ's are different :
Linuxmce# cat /proc/interrupts
CPU0 CPU1
0: 143 0 IO-APIC-edge timer
1: 4 170 IO-APIC-edge i8042
6: 1 4 IO-APIC-edge floppy
8: 1 6 IO-APIC-edge rtc
9: 0 1 IO-APIC-fasteoi acpi
12: 6 105 IO-APIC-edge i8042
14: 11 398 IO-APIC-edge ide0
16: 2484 444417 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, eth0, nvidia
17: 3923 217935 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, HDA Intel
18: 1 3 IO-APIC-fasteoi ehci_hcd:usb6
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb7
20: 2137 172294 IO-APIC-fasteoi saa7146 (0)
NMI: 0 0
LOC: 197824 197923
ERR: 0
MIS: 0
EasyVDR# cat /proc/interrupts
CPU0 CPU1
0: 125 2 IO-APIC-edge timer
1: 7 395 IO-APIC-edge i8042
6: 0 3 IO-APIC-edge floppy
9: 0 0 IO-APIC-fasteoi acpi
12: 16 106 IO-APIC-edge i8042
14: 133 18689 IO-APIC-edge ide0
15: 0 0 IO-APIC-edge ide1
16: 85 100439 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, HDA Intel
17: 3 143 IO-APIC-fasteoi ehci_hcd:usb1
18: 21 14418 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb2
22: 0 3 IO-APIC-fasteoi ohci1394
507: 4 4088 PCI-MSI-edge eth0
508: 0 0 PCI-MSI-edge ahci
511: 119536 0 HPET_MSI-edge hpet2
NMI: 0 0 Non-maskable interrupts
LOC: 111 137321 Local timer interrupts
RES: 15767 15248 Rescheduling interrupts
CAL: 123 885 Function call interrupts
TLB: 993 657 TLB shootdowns
TRM: 0 0 Thermal event interrupts
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0
and so on.
-
set your tvtime deinterlace setting for cheap_mode to 0
-
Hi Colin,
thanks for your reply.
Already did that, it makes the picture better, but does not fix the stuttering. I tried different settings for almost all TVtime settings - does not remove the stuttering.
Did it help on your system ?
Greetings
Viking
-
Well, the choppy playback finally got on my nerves a couple of months ago, so I solved the issue by switching to svn XBMC running on gentoo ~x86. Just created mirrored media directories with hard links from .dvd to .iso files, then mounted each of my NFS volumes on the new box and added them as sources.
I still have my LMCE box in place but am just using it for a firewall/DHCP server until I take the time to migrate those functions.
Have fun,
Roy
-
I was watching a dvd last night on my hybrid/core and noticed that the playback was starting to get a little choppy. I thought that this might be just an issue with the dvd but then I noticed it on regular TV and playback of recorded video.
Has anyone else had this issue?
If so, is there a work around?
-Dustin
Thats caused by a known bug in the version of libxine that is used by LinuxMCE-0710. It goes away in 0810 :-)
But for now you can usually fix the 'choppyness' by doing stopping the media playback and then doing a reload... not ideal but it does fix the problem.
All the best
Andrew
-
Andrew - do you happen to know which bug number this is? I would like to research it for other effects...
Col.
-
Andrew - do you happen to know which bug number this is? I would like to research it for other effects...
Col.
Hmmm... not off hand. But it was in the old pluto Mantis bug tracking DB I know for sure...I cant see it in Trac though currently... at least not based on the quick scan I just did ;-)
Andrew
-
Hi,
This stuttering is a very big showstopper - I (and my wife) can definetly not live with that :(
I now have got my Sattelite dish running and live TV is also choppy on big pans/zooms :(
If it can not be solved I will have to look for some other system even if I really like LinuxMCE - that would be very sad. And I assume others feel the same way.
I am quite sure that it has something with xine(liboutput) to do and I would really like to debug this error, but to do that I will need the sources for VDR and xineliboutput - as thay are changed in some ways. Amongst others vdr-sxfe is renamed to plutovdr and there are also other changes ...
So I need :
- VDR sources used in LinuxMCE (any version)
- Xineliboutput sources used LinuxMCE (any version)
- and maybe some help about the changes that have been made between normal VDR/xineliboutput and the LinuxMCE ones ... Who did the main work on the VDR implementation ? Burgiman ? posde ?
- Xine sources are in the SVN.
I have already used well above 30 hours trying to get different VDR versions running. But mostly it breaks when i compile my own xineliboutput :( so I did not get anywhere up til now :(
Please help me getting the sources so that I can recompile VDR / Xineliboutput and try some patches and other things to get this solved.
Greetings
Viking
-
why don't you get onto the IRC channel and ask there.
-
Hi Colin,
just posted in the VPDAU thread, I am now tired and will go to bed as I have to get up really early tomorrow.
Thanks, I might try IRC next time I find some time.
Greetings
Viking
-
Hi,
This stuttering is a very big showstopper - I (and my wife) can definetly not live with that :(
I now have got my Sattelite dish running and live TV is also choppy on big pans/zooms :(
If it can not be solved I will have to look for some other system even if I really like LinuxMCE - that would be very sad. And I assume others feel the same way.
I am quite sure that it has something with xine(liboutput) to do and I would really like to debug this error, but to do that I will need the sources for VDR and xineliboutput - as thay are changed in some ways. Amongst others vdr-sxfe is renamed to plutovdr and there are also other changes ...
So I need :
- VDR sources used in LinuxMCE (any version)
- Xineliboutput sources used LinuxMCE (any version)
- and maybe some help about the changes that have been made between normal VDR/xineliboutput and the LinuxMCE ones ... Who did the main work on the VDR implementation ? Burgiman ? posde ?
- Xine sources are in the SVN.
I have already used well above 30 hours trying to get different VDR versions running. But mostly it breaks when i compile my own xineliboutput :( so I did not get anywhere up til now :(
Please help me getting the sources so that I can recompile VDR / Xineliboutput and try some patches and other things to get this solved.
Greetings
Viking
Is the 'stutter' you see continuous or does it only happen briefly and then go away?
Does this only happen in vdr? ie if you play a DVD or a ripped DVD is playback ok?
Sorry to ask this if you've already mentioned it somewhere but what is your hardware setup?
My home systems Hybrid Core is an old MSI-945 board with a 3GHz Single Core Pentium, 2gig RAM and a PCI nVidia 9400 card. This happily and smoothly delivers live & recorded vdr material from DVB-T even when 5-6 recording are being simultaneously recorded/streamed to other MD's. It also plays DVD's & ripped DVD's ok too. I also have an Eee Box 202 and this also plays live & recorded TV and ripped DVD's smoothly. My home system is in no way 'shiny new' hardware with a hot processor so you should be able to get the same experience too :-)
So my instinct tells me that your hardware is probably not suitable in some way...
All the best
Andrew
-
Hallo Andrew,
Thanks for your interest :)
Is the 'stutter' you see continuous or does it only happen briefly and then go away?
It only happens on pan/zooms of VDR recordings as described by colin above. It sometimes happens once every 5-10 seconds, sometimes a bit more offen. What I have noticed, it offen happens at the same place in the recording. Meaning: I set an cutmark with VDR (with the remote 0 key) and then jump back to that (with the key 7) and then start replay at the same place everytime I test it. And then it stutters at the same place.
As soon as the movie is not moving much there is no stuttering anymore. As soon as it pans/zooms - it is back.
If I did not mention this before - Audio is always playing without any disturbance ! even while video is stuttering
I did not yet find any errors in syslog or /var/log/pluto/*VDR* saying that there were problems with the movie. And as said - with EasyVDR they all play smooth.
Maybe I could provide you with a piece of a recording that has got the problem and you can try it to see if it has something with my recordings to do ?
hmm, did not have time to watch a DVD yet - so I can't say if it also happens when watching DVD's.
Does this only happen in vdr? ie if you play a DVD or a ripped DVD is playback ok?
It also happens if I replay the same recording with the Video part of LinuxMCE.
Sorry to ask this if you've already mentioned it somewhere but what is your hardware setup?
It is listed in my signature and here :
http://wiki.linuxmce.org/index.php/User:Viking
So my instinct tells me that your hardware is probably not suitable in some way...
Might be. You mean - unsutable for LinuxMCE - as the same hardware works with EasyVDR.
Colin has the same problem, so maybe we should try to find out what is different to the rest of the systems working ...
Could it be that it has to do with IRQ sharing ?
@Colin
What IRQ's are shared on your system ?
Greetings
Viking
-
Hallo Andrew,
Thanks for your interest :)
Is the 'stutter' you see continuous or does it only happen briefly and then go away?
It only happens on pan/zooms of VDR recordings as described by colin above. It sometimes happens once every 5-10 seconds, sometimes a bit more offen. What I have noticed, it offen happens at the same place in the recording. Meaning: I set an cutmark with VDR (with the remote 0 key) and then jump back to that (with the key 7) and then start replay at the same place everytime I test it. And then it stutters at the same place.
As soon as the movie is not moving much there is no stuttering anymore. As soon as it pans/zooms - it is back.
If I did not mention this before - Audio is always playing without any disturbance ! even while video is stuttering
I did not yet find any errors in syslog or /var/log/pluto/*VDR* saying that there were problems with the movie. And as said - with EasyVDR they all play smooth.
Well taking the above onboard it would seem like the xorg setup under LinuxMCE is possibly incompatible with the performance of your hardware in someway. Under EasyVDR the xorg is configured in some way differently and works ok.
Maybe I could provide you with a piece of a recording that has got the problem and you can try it to see if it has something with my recordings to do ?
Sure send me a 20 sec chunk that you know has the playback problem.
hmm, did not have time to watch a DVD yet - so I can't say if it also happens when watching DVD's.
Does this only happen in vdr? ie if you play a DVD or a ripped DVD is playback ok?
It also happens if I replay the same recording with the Video part of LinuxMCE.
So this tends to point to xorg again possibly.
Sorry to ask this if you've already mentioned it somewhere but what is your hardware setup?
It is listed in my signature and here :
http://wiki.linuxmce.org/index.php/User:Viking
So my instinct tells me that your hardware is probably not suitable in some way...
Might be. You mean - unsutable for LinuxMCE - as the same hardware works with EasyVDR.
Well I guess I'm saying that under LinuxMCE your hardware is not getting configured correctly...unsuitable is not the correct phrase.
Colin has the same problem, so maybe we should try to find out what is different to the rest of the systems working ...
Could it be that it has to do with IRQ sharing ?
@Colin
What IRQ's are shared on your system ?
Greetings
Viking
If you look at the spec of my home system compared to your system... I would say that 'on paper'...your hardware is better apart from my nVidia 9400. However I have had 6200's and 7300's in my system too and it has never had the video problem your has.
The only thing I can say is that...we install vdr all the time and I know absolutely 100% that we dont see this problem. So its not and inherent bug in LinuxMCE or vdr.
All the best
Andrew
-
Hallo Andrew,
Well taking the above onboard it would seem like the xorg setup under LinuxMCE is possibly incompatible with the performance of your hardware in someway. Under EasyVDR the xorg is configured in some way differently and works ok.
Well, is this your experience with other mainboards that xorg could be the problem ?
So can I change something about the configuration to get things fixed or is it only fixed by new hardware ? Use another nvidia driver ? Or what can I try to change ?
How can I do a quick reload of X without rebooting ?
I just remebered that your company previously has tested the same mainboard GA-MA78GM-S2H in my MD that has got the problem:
http://forum.linuxmce.org/index.php?topic=6053.msg36430#msg36430
What was the result of those tests ?
I now tested DVD replay of a ripped DVD and it did also stutter the same way.
Now is DVD replay also using xine ?
Sure send me a 20 sec chunk that you know has the playback problem.
OK, per mail or have you got a place where i can upload it ?
EasyVDR is using xorg 7.1 by the way and LinuxMCE 7.2.
Greetings
Viking
-
Hi again,
after quite some hours I have found out what probably is the cause :)
IRQ-sharing or some kind of IRQ-misconfiguring.
On this board all important things are using the same interrupt with the 0710 kernel :(
The graphics card, The Network Card and USB.
I first disabled USB completely in the BIOS and it helped fixing the problem, but nothing works without USB, so I tried only disabling EHCI (USB 2.0) that worked partly - after the boot it was OK, but quite fast it did start stuttering again :(
So the solution I came up with is updating the kernel to 2.6.28.7 (the same EasyVDR is using) and it looks good. IRQ's are used different (see below) and replay is really smooth :)
I changed the Wiki for my Mainboard and noted it as not recommended.
Take a look at this, this are the interrups before Kernel upgrade :
Linuxmce# cat /proc/interrupts
CPU0 CPU1
0: 143 0 IO-APIC-edge timer
1: 4 170 IO-APIC-edge i8042
6: 1 4 IO-APIC-edge floppy
8: 1 6 IO-APIC-edge rtc
9: 0 1 IO-APIC-fasteoi acpi
12: 6 105 IO-APIC-edge i8042
14: 11 398 IO-APIC-edge ide0
16: 2484 444417 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, eth0, nvidia
17: 3923 217935 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, HDA Intel
18: 1 3 IO-APIC-fasteoi ehci_hcd:usb6
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb7
20: 2137 172294 IO-APIC-fasteoi saa7146 (0)
NMI: 0 0
LOC: 197824 197923
ERR: 0
MIS: 0
After Kernel upgrade to 2.6.28.7 it looks like this :
# cat /proc/interrupts
CPU0 CPU1
0: 124 0 IO-APIC-edge timer
1: 0 16 IO-APIC-edge i8042
4: 84 8761 IO-APIC-edge
6: 0 5 IO-APIC-edge floppy
9: 0 0 IO-APIC-fasteoi acpi
12: 12 100 IO-APIC-edge i8042
14: 8 539 IO-APIC-edge ide0
15: 0 0 IO-APIC-edge ide1
16: 8399 1288367 IO-APIC-fasteoi ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel
17: 0 6 IO-APIC-fasteoi ehci_hcd:usb1
18: 3898 516123 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb3
22: 0 3 IO-APIC-fasteoi ohci1394, ahci
508: 21497 3606180 PCI-MSI-edge eth0
511: 4546432 0 HPET_MSI-edge hpet2
NMI: 0 0 Non-maskable interrupts
LOC: 110 4546761 Local timer interrupts
RES: 534014 190887 Rescheduling interrupts
CAL: 9550 9215 Function call interrupts
TLB: 20053 4757 TLB shootdowns
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0
Colin, how are your interrupts shared ?
Greetings
Viking
-
Mine seem OK, but as I say, I suspect that may stuttering issue isn't exactly the same as yours...
CPU0 CPU1
0: 256 5081 IO-APIC-edge timer
1: 0 12 IO-APIC-edge i8042
6: 0 2 IO-APIC-edge floppy
8: 17715741 896660786 IO-APIC-edge rtc
9: 311 22667 IO-APIC-fasteoi acpi
14: 195629 12291822 IO-APIC-edge ide0
16: 2665544 144790915 IO-APIC-fasteoi ohci_hcd:usb1, eth0
17: 1537719 76970596 IO-APIC-fasteoi ohci_hcd:usb2, ahci
18: 21544 880713 IO-APIC-fasteoi ehci_hcd:usb3, nvidia
19: 70398 3734587 IO-APIC-fasteoi ehci_hcd:usb4, HDA Intel
20: 980860 68648116 IO-APIC-fasteoi ehci_hcd:usb5, ohci1394
21: 14788452 1123395046 IO-APIC-fasteoi uhci_hcd:usb7, eth1
22: 0 0 IO-APIC-fasteoi uhci_hcd:usb6
23: 1500453 102187452 IO-APIC-fasteoi nvidia
NMI: 0 0
LOC: 255690575 256749061
ERR: 1
MIS: 0
-
Hi again,
after quite some hours I have found out what probably is the cause :)
IRQ-sharing or some kind of IRQ-misconfiguring.
On this board all important things are using the same interrupt with the 0710 kernel :(
The graphics card, The Network Card and USB.
I first disabled USB completely in the BIOS and it helped fixing the problem, but nothing works without USB, so I tried only disabling EHCI (USB 2.0) that worked partly - after the boot it was OK, but quite fast it did start stuttering again :(
So the solution I came up with is updating the kernel to 2.6.28.7 (the same EasyVDR is using) and it looks good. IRQ's are used different (see below) and replay is really smooth :)
I changed the Wiki for my Mainboard and noted it as not recommended.
Take a look at this, this are the interrups before Kernel upgrade :
Linuxmce# cat /proc/interrupts
CPU0 CPU1
0: 143 0 IO-APIC-edge timer
1: 4 170 IO-APIC-edge i8042
6: 1 4 IO-APIC-edge floppy
8: 1 6 IO-APIC-edge rtc
9: 0 1 IO-APIC-fasteoi acpi
12: 6 105 IO-APIC-edge i8042
14: 11 398 IO-APIC-edge ide0
16: 2484 444417 IO-APIC-fasteoi ohci_hcd:usb3, ohci_hcd:usb4, ohci_hcd:usb5, eth0, nvidia
17: 3923 217935 IO-APIC-fasteoi ohci_hcd:usb1, ohci_hcd:usb2, HDA Intel
18: 1 3 IO-APIC-fasteoi ehci_hcd:usb6
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb7
20: 2137 172294 IO-APIC-fasteoi saa7146 (0)
NMI: 0 0
LOC: 197824 197923
ERR: 0
MIS: 0
After Kernel upgrade to 2.6.28.7 it looks like this :
# cat /proc/interrupts
CPU0 CPU1
0: 124 0 IO-APIC-edge timer
1: 0 16 IO-APIC-edge i8042
4: 84 8761 IO-APIC-edge
6: 0 5 IO-APIC-edge floppy
9: 0 0 IO-APIC-fasteoi acpi
12: 12 100 IO-APIC-edge i8042
14: 8 539 IO-APIC-edge ide0
15: 0 0 IO-APIC-edge ide1
16: 8399 1288367 IO-APIC-fasteoi ohci_hcd:usb2, ohci_hcd:usb4, HDA Intel
17: 0 6 IO-APIC-fasteoi ehci_hcd:usb1
18: 3898 516123 IO-APIC-fasteoi ohci_hcd:usb5, ohci_hcd:usb6, ohci_hcd:usb7, nvidia
19: 0 0 IO-APIC-fasteoi ehci_hcd:usb3
22: 0 3 IO-APIC-fasteoi ohci1394, ahci
508: 21497 3606180 PCI-MSI-edge eth0
511: 4546432 0 HPET_MSI-edge hpet2
NMI: 0 0 Non-maskable interrupts
LOC: 110 4546761 Local timer interrupts
RES: 534014 190887 Rescheduling interrupts
CAL: 9550 9215 Function call interrupts
TLB: 20053 4757 TLB shootdowns
SPU: 0 0 Spurious interrupts
ERR: 0
MIS: 0
Colin, how are your interrupts shared ?
Greetings
Viking
We have tested the GA-MA78GM-S2H under LinuxMCE-0710 and now are testing it under LinuxMCE-0810 Alpha's. As usual the ATI3200 poses a few challenges but these are expected.
We certainly do not see any of the issues you are experiencing under 0710 or 0810. As far as I know we have not made any changes in bios relating to Interrupts..I will check with one of our guys next week to be sure though.
Andrew
-
Hallo Andrew,
Thanks for checking :)
What are you doing to get the ATI 3200 running. I already tried the newer ATI drivers, but the OSD menues are really slow.
Greetings
Viking