[CentOS] Memory issue in kernel sctp implementation
Dear all, I'm running into a possible memory issue with the SCTP implementation in CentOS 6, using lksctp-tools. So far I've not seen the problem with other distributions yet. The problem is that whenever a SCTP client connection is initiated to a second host and port at which no SCTP server application is listening The scenario is simple: - call socket() to create a socket. - call sctp_connectx() to establish a connection. The last call is repeated periodically to retry to establish a connection. When looking on the wire using wireshark it shows that an SCTP INIT packet is sent to the second host, which replies with an SCTP ABORT. This is exactly according to the SCTP specification. However it appears ABORT isn't propagated into to application layer that calls sctp_connectx(). Furthermore, because reconnect attempts are made, a steady memory increasement occurs. Looking at /proc/meminfo, the increasement occurs in SUnreclaim, the kernel slab cache. Can you advice if this can be an issue with the SCTP implementation in the kernel? Maybe an issue solved upstream, but not (yet) backported into centos 6? It applies to the following package versions (also to older kernels): - kernel-2.6.32-504.8.1.el6.x86_64 - lksctp-tools-1.0.10-7.el6.x86_64 Regards, Danny Smit ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] race conditions in dbus-1.2
Hi everyone, I'm having some issue with a Qt application using D-Bus (Qt API) in a threaded appllication on CentOS 6. Searching for the cause has led me to the following issues in the dbus library: https://bugs.freedesktop.org/show_bug.cgi?id=857 https://bugs.freedesktop.org/show_bug.cgi?id=17754 It appears that there are threading issues with the dbus library version < 1.6. However there doesn't seem to be other version than 1.2 available for CentOS 6. Can someone advise what approach can be used to either work around or solve the issue? For instance, is it even possible to upgrade to a newer dbus version without side effects? Kind regards, Danny Smit ___ CentOS mailing list CentOS@centos.org http://lists.centos.org/mailman/listinfo/centos
[CentOS] icecc/icecream for CentOS 7
Hello everyone, I'm looking for a way to install icecc/icecream on CentOS 7 for distributed builds, preferably like any other package rpm a repository. I already found some effort done by someone else to create an rpm package for CentOS 7 and published in a private repository : https://copr-be.cloud.fedoraproject.org/results/mbriza/Icecream/epel-7-x86_64/ This package already seem to work. However, if possible, I prefer a solution that is used/available for the whole world to use. I noticed that with CentOS 6 a iceream package was provided by the epel repositories. With CentOS 7 this package is not included anymore. Does anyone know if there is a chance it will be included in the epel (or some other thirdparty) repository for CentOS 7 again? Or if there is a better place to ask this question? -- Thanks, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
1920x1200_60" is invalid. Note that with the previous driver (version 384.90), a valid value was detected for the 'maximum pixel clock': [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): connected [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): Internal TMDS [ 124.804] (--) NVIDIA(GPU-0): Philips 240S4 (DFP-0): 165.0 MHz maximum pixel clock Since it did work with version 384.90 and stopped working with version 384.98, it looks like a regression in the nvidia driver. What is the best way to report the issue and get an update in elrepo? Kind regards, Danny Smit ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On Thu, Jan 4, 2018 at 5:22 AM, Phil Perry wrote: > On 03/01/18 20:14, Zube wrote: >> >> I can confirm that this happens with the driver downloaded from NVIDIA. >> I had to fall back to the .90 driver to get it to work for all my >> NVS 315s (with dual DVI) running on 7.4 / 6.9. Thanks. For reference, I did the same test. With the driver downloaded from NVIDIA the issues also occurs in my case. > I couldn't find any reports upstream at nvidia so am unsure if they are > aware of the issue. Where do you look for this at nvidia, in the community forums? Or is there another publicly available bug tracking system? (which I was unable to find) > There is an updated version 387.34 short-lived branch driver available in > the elrepo testing repository that you could test to see whether the issue > has been fixed in this latest release (only available for el7 currently). Surprisingly, I couldn't reproduce the issue anymore. Therefore at first sight it seems to be fixed in the 387.34 driver. I posted a question at nvidia anyway: https://devtalk.nvidia.com/default/topic/1028268/linux/nvidia-maximum-pixel-clock-issue-in-kmod-nvidia-384-98/ (although I'm not sure it is the right place, still having some issues finding my way at nvidia.com, other suggestions or directions are welcome of course) Will short-lived drivers ever make it into the official elrepo repository? Or will only the long-lived drivers be included in the official repository? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On Thu, Jan 4, 2018 at 9:40 PM, Phil Perry wrote: > Normally elrepo only releases the long term branch for Enterprise Linux, on > the assumption EL users will welcome the implied stability over more > frequent and potentially buggy releases. > In this case I had built the current short lived release as a user requested > it for compatibility with the latest CUDA. However, as it is a short term > branch release, it will stay in the testing repository indefinitely and will > not be promoted to the main repository. Once it's been superseded by a > subsequent long term branch release I will likely just delete it from the > testing repo. That said, it should be fine to use (at your own risk). > Thanks, I normally certainly prefer the stability of the long-lived releases. I noticed an update was just released of the long-lived release: 384.111. The notes for this release say: > Fixed a regression that prevented displays connected via some types of > passive adapters (e.g. DMS-59 to VGA or DVI) from working correctly. The > regression was introduced with driver version 384.98. That sounds very much like my issue. I will verify next Monday if that solves it for me. Can I assume that new 384.111 release will make it into the main elrepo repository eventually? ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia maximum pixel clock issue in kmod-nvidia-384.98
On Sat, Jan 6, 2018 at 2:27 PM, Phil Perry wrote: > > I've just built and released 384.111 to the elrepo main repository, so it > should show up on the mirrors shortly. As expected, the 384.111 also solves the problem in my case. Thanks for the support everyone. Regards, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] CentOS 6: Yum downloadonly changes local source repositories
Hi All, I'm trying to use yum with the downloadonly option to collect a set of packages including dependencies. I noticed that even on CentOS 6 the downloadonly option is currently a default feature of the core of yum itself, which is nice. However something strange occurs when one of the repositories to download from is a local repository, like: [custom-repo] name=My custom repo baseurl=file:///repositories/mycustomrepo/ I added such a repo to my yum configuration and then executed: yum install -y --downloadonly --downloaddir=downloads custom_package When executing the above the package in question is suddenly renamed from: /repositories/mycustomrepo/x86_64/custom_package-1.1-2.el6.x86_64.rpm to /repositories/mycustomrepo/x86_64/custom_package-1.1-2.el6 Note that the architecture part and file extension are removed with the file in the local repo, where I wouldn't expect yum to even try to change something there. Also nothing is downloaded into the downloads dir as specified. Strangely when it concerns a package that comes from a repository that is configured as an http URL, the download option works flawlessly. Has anyone else seen this behavior? Is it a bug? Or is there a way around this? Actually I would even prefer not having to run yum as root for this, unfortunately yum to require write access to lock files in /var/. Platform: CentOS 6.9 (also not working with CentOS 7, then it keeps the file intact, but doesn't download either) Yum: 3.2.29-81.el6.centos Kind regards, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] CentOS 6: Yum downloadonly changes local source repositories (and CentOS 7)
For what its worth, I managed to get around the problem with a small patch on yum itself: --- ORIG/usr/lib/python2.6/site-packages/yum/yumRepo.py 2017-03-22 05:32:26.0 + +++ NEW/usr/lib/python2.6/site-packages/yum/yumRepo.py 2018-02-14 09:14:04.879902463 + @@ -863,6 +863,7 @@ class YumRepository(Repository, config.R text=text, cache=cache, size=package.size, +copy_local=1, ) def getHeader(self, package, checkfunc = None, reget = 'simple', Although newer versions of yum do not rename the local package anymore, it still does not copy/download the package into the desired "downloaddir". I will try to report that upstream. Regards, Danny On Tue, Feb 13, 2018 at 6:05 PM, Danny Smit wrote: > Hi All, > > I'm trying to use yum with the downloadonly option to collect a set of > packages including dependencies. I noticed that even on CentOS 6 the > downloadonly option is currently a default feature of the core of yum > itself, which is nice. > > However something strange occurs when one of the repositories to > download from is a local repository, like: > > [custom-repo] > name=My custom repo > baseurl=file:///repositories/mycustomrepo/ > > I added such a repo to my yum configuration and then executed: > > yum install -y --downloadonly --downloaddir=downloads custom_package > > When executing the above the package in question is suddenly renamed from: > > /repositories/mycustomrepo/x86_64/custom_package-1.1-2.el6.x86_64.rpm > > to > > /repositories/mycustomrepo/x86_64/custom_package-1.1-2.el6 > > Note that the architecture part and file extension are removed with > the file in the local repo, where I wouldn't expect yum to even try to > change something there. > Also nothing is downloaded into the downloads dir as specified. > > Strangely when it concerns a package that comes from a repository that > is configured as an http URL, the download option works flawlessly. > > Has anyone else seen this behavior? Is it a bug? Or is there a way around > this? > Actually I would even prefer not having to run yum as root for this, > unfortunately yum to require write access to lock files in /var/. > > Platform: CentOS 6.9 (also not working with CentOS 7, then it keeps > the file intact, but doesn't download either) > Yum: 3.2.29-81.el6.centos > > Kind regards, > Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] Nvidia-detect error with on HP Z4 (CentOS 6.9)
Hi all, I'm testing an installation of nvidia drivers on a HP Z4 workstation (nvidia Quadro P600) with CentOS 6.9. Running nvidia-detect with this setup gives the following output: # nvidia-detect Error getting device_class nvidia-detect also quits with exit-code 255. Could this be a bug in nvidia-detect? Or is it an unsupported configuration? The following hardware is detected, it seems some sort of unknown Intel device is detected by the OS: # lspci | grep VGA 00:1f.5 Non-VGA unclassified device: Intel Corporation Device a2a4 21:00.0 VGA compatible controller: NVIDIA Corporation Device 1cb2 (rev a1) # lspci -n | egrep '00:1f.5|21:00.0' 00:1f.5 : 8086:a2a4 21:00.0 0300: 10de:1cb2 (rev a1) Tested with the following version (with equal results): nvidia-detect-390.25-1.el6.elrepo.x86_64.rpm nvidia-detect-390.48-1.el6.elrepo.x86_64.rpm -- Regards, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia-detect error with on HP Z4 (CentOS 6.9)
On Fri, Apr 13, 2018 at 8:50 PM, Phil Perry wrote:
>
> Your device is supported:
>
> $ nvidia-detect -l | grep -i 1cb2
> [10de:1cb2] NVIDIA Corporation GP107GL [Quadro P600]
>
> Support was added in the 375.39 NVIDIA driver. I assume the driver works as
> expected for you?
Yes it works perfectly fine.
> If you are able to offer any more clues, please feel free to open a bug
> report on elrepo.org/bugs for us to track. Happy to help if I can.
>
I created a bugreport: http://elrepo.org/bugs/view.php?id=839
>># lspci | grep VGA
>>00:1f.5 Non-VGA unclassified device: Intel Corporation Device a2a4
>>21:00.0 VGA compatible controller: NVIDIA Corporation Device 1cb2 (rev a1
>>
>># lspci -n | egrep '00:1f.5|21:00.0'
>>00:1f.5 : 8086:a2a4
>>21:00.0 0300: 10de:1cb2 (rev a1)
This part makes me wander though, if I'm correct the second column in
the "lspci -n" output seems to be the class identification. If you
look at the first line of the lcpi output, lspci (or the kernel?)
doesn't seem to recognize the class of some other Intel device, that
probably has nothing to do with the nvidia device at all. It's numeric
class identification seems to be "" though (for unclassified?)
Could it be that in the piece of code below (from nvidia-detect), the
device_class is zero because of that line, and nvidia-detect exits?
if (!dev->device_class) {
fprintf(stderr, "Error getting device_class\n");
ret = -1;
goto exit;
}
--
Regards,
Danny
___
CentOS mailing list
CentOS@centos.org
https://lists.centos.org/mailman/listinfo/centos
Re: [CentOS] Nvidia-detect error with on HP Z4 (CentOS 6.9)
On Sat, Apr 14, 2018 at 1:51 PM, Phil Perry wrote: > > Anyway, I've fixed it and am just waiting for our build systems to be > available to rebuild and push a release for you (will be later today). I'll > update the bug report once that is done, and perhaps you could then confirm > it's working as expected for you. > I can confirm that it works now on the same hardware. nvidia-detect is able to detect the required driver version as expected. Thanks for the quick response! -- Regards, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
[CentOS] postgis-2.0.7-2.el7 still in epel7-testing?
Hi all, I'm looking for a fix in postgis, which seems to be fixed already in postgis-2.0.7-2.el7. However that package seems to be 'stuck' in the epel7-testing repository: https://koji.fedoraproject.org/koji/buildinfo?buildID=750618 https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2016-b6c229157e Is there a reason that the package is not pushed to stable yet? Or can it be pushed to stable? -- Kind regards, Danny ___ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
