| === frewsxcv23 is now known as frewsxcv | ||
| === knome_ is now known as knome | ||
| acmeinc | ailo, i have 8gb of memory if you need someone to do some testing | 20:53 |
|---|---|---|
| ailo | acmeinc: According to Ralph on the mailing list, there's some problem with his amd64 system, not getting access to all of his memory | 20:57 |
| ailo | He showed the output of the command uname -a, which indicated that he is running a amd64 system | 21:00 |
| acmeinc | i can confirm my home system recognized all 8gb when it was plugged in. I recently downgraded since my mobo isn't linux friendly, so I can double confirm that in a few days. | 22:08 |
| acmeinc | but, i can do any testing you'd need. | 22:08 |
| ailo | acmeinc: I assume there is no problem then. It would be strange, since it's not really a -lowlatency problem anyway | 22:09 |
| ailo | He probably has shared memory with his graphic card or something | 22:09 |
| acmeinc | agreed 2x | 22:09 |
| len-dt | ailo, odd that it seems only to be 64bit and 32 bit kernel is ok. It may be more interesting to fill up 4G on the same machine with a 32bit PAE and see if the video craps out.. | 22:13 |
| ailo | len-dt: At first I assumed it was the -pae the was the problem, but it doesn't seem like anyone has had any. If there was a problem with the -lowlatency version, I would suspect it was actually not a real -pae, like when -lowlatency was actually not a -lowlatency because of the wrong config | 22:14 |
| len-dt | ailo, ya, but he says the PAE is fine. | 22:15 |
| ailo | He does? | 22:15 |
| len-dt | "> I noticed that for another 64bit Linux on my machine too, while a 32bit | 22:16 |
| len-dt | > Linux with a PAE is ok. I searched the Internet and found out that | 22:16 |
| len-dt | > several people on different Linux have the same problem. | 22:16 |
| len-dt | > | 22:16 |
| len-dt | quote from the email... | 22:16 |
| len-dt | So if the 64bit kernel is correctly setting aside memory for the video, does that mean the PAE is willing to write over it? | 22:17 |
| len-dt | ailo, ^^ | 22:18 |
| ailo | At least it doesn't seem to be -lowlatency related :P | 22:19 |
| len-dt | nope. | 22:19 |
| ailo | According to some mail responses on the LAU list, there is such a thing as soft irq's which makes it possible to tune rtprio for individual devices on the same IRQW | 22:20 |
| ailo | IRQ* | 22:21 |
| ailo | And for some reason -lowlatency is not doing its' job | 22:21 |
| ailo | len-dt: Could you check something? I don't have ubuntu installed right now: cat /boot/config-<yourlowlatencykernel> | grep IRQ_FORCED_THREADING | 22:23 |
| ailo | Not sure exactly what leads to the irq threading, so if you like, grep all instances of IRQ | 22:23 |
| ailo | Which reminds me, I should see how the rtirq script works on this system. I'll be back later.. | 22:24 |
| ailo | I don't have any rtprio whatsoever :P. whopidoo | 22:30 |
| ailo | For me it makes no difference at all when it comes to performance though | 22:30 |
| ailo | len-dt: Actually, the problem is only with the soft irq. Supposedly, only the audio devices are supposed to get raised prio thanks to the rtirq script. On the other hand, they get high prio even without the script, so there's something else at play as well | 23:00 |
| ailo | That's all for me today. Until next time.. | 23:03 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!