HI - On CentOS 8 I see this in my X log
intel: waited 2020 ms for i915.ko driver to load
I find this:
find . | grep i915.ko
./4.18.0-147.5.1.el8_1.x86_64/kernel/drivers/gpu/drm/i915/i915.ko.xz
uname -r
4.18.0-147.5.1.el8_1.x86_64
Why might it not be loading ?
Thanks,
Jerry
_
Am 25.03.20 um 13:08 schrieb Jerry Geis:
HI - On CentOS 8 I see this in my X log
intel: waited 2020 ms for i915.ko driver to load
I find this:
find . | grep i915.ko
./4.18.0-147.5.1.el8_1.x86_64/kernel/drivers/gpu/drm/i915/i915.ko.xz
uname -r
4.18.0-147.5.1.el8_1.x86_64
Why might it not
Hi,
I've discovered a bug in rsync which leads to increased CPU usage and
slower transfers in many situations.
When syncing with compression (-z), certain file types should not be
compressed during the transfer because they are already compressed. The
file types which are not to be compressed can
On Wed, 25 Mar 2020 14:49:24 +0100
Simon Matter via CentOS wrote:
> Hi,
>
> I've discovered a bug in rsync which leads to increased CPU usage and
> slower transfers in many situations.
>
> When syncing with compression (-z)
Tbh, using -z with rsync is almost always a bad idea (unless you're on
Since you state that using -z is almost always a bad idea, could you provide
the rationale for that? I must be missing something.
From: CentOS on behalf of Peter Kjellström
Sent: Wednesday, March 25, 2020 9:34 AM
To: Simon Matter
Cc: centos@centos.org
Subjec
Hi,
Anyone else had any issues with CentOS 6.10 bind DNS server issues
this afternoon.
At 16:26 (GMT) had alerts for DNS failures against our CentOS 6.10 bind
DNS servers
from our monitoring system.
Sure enough DNS requests via the server was failing, checking the
named.log showed
dns
At Wed, 25 Mar 2020 17:03:23 + CentOS mailing list
wrote:
>
> Hi,
>
> ÃÂ ÃÂ ÃÂ Anyone else had any issues with CentOS 6.10 bind DNS server
> issues
Yes. The installed ISC DLV key installed with
bind-9.8.2-0.68.rc1.el6_10.3.x86_64 seems to have expired and there does not
appear t
Once upon a time, Robert Heller said:
> Yes. The installed ISC DLV key installed with
> bind-9.8.2-0.68.rc1.el6_10.3.x86_64 seems to have expired and there does not
> appear to be a new bind-9.8.2 RPM with a new key. I guess you can *manually*
> fetch a new key (look in the installed /etc/nam
On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
> Since you state that using -z is almost always a bad idea, could you
> provide the rationale for that? I must be missing something.
>
I think the "rationale" is that at some point the
compression/decompression takes longer than the time r
On Wed, 25 Mar 2020, Leroy Tennison wrote:
Since you state that using -z is almost always a bad idea, could you
provide the rationale for that? I must be missing something.
I can't speak to that, but the obvious workaround is to use ssh's
compression instead of rsync's:
rsync -av -e 'ssh -C'
> On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
>> Since you state that using -z is almost always a bad idea, could you
>> provide the rationale for that? I must be missing something.
>>
> I think the "rationale" is that at some point the
> compression/decompression takes longer than th
> On Wed, 25 Mar 2020, Leroy Tennison wrote:
>
>> Since you state that using -z is almost always a bad idea, could you
>> provide the rationale for that? I must be missing something.
>
> I can't speak to that, but the obvious workaround is to use ssh's
> compression instead of rsync's:
>
> rsync -
On Wed, 2020-03-25 at 19:15 +0100, Simon Matter via CentOS wrote:
> > On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
> > > Since you state that using -z is almost always a bad idea, could you
> > > provide the rationale for that? I must be missing something.
> > >
> > I think the "ratio
Would seem its foundl.
lsmod | grep i915
i915 2207744 13
intel_gtt 20480 1 i915
i2c_algo_bit 16384 1 i915
drm_kms_helper217088 1 i915
drm 524288 10 drm_kms_helper,i915
video 45056 1 i915
___
That's why I asked, I wanted to know if there was something inherently bad with
"-z". I had a situation where Postgresql was replicating 16M files every few
minutes ("log shipping") on approximately 10 systems, got behind which resulted
in almost continuous file transfer (of mostly null 16M fil
I appreciate the reply - it keeps me from wondering "is there something I
should be concerned about?". We use a co-location facility where we pay for
bandwidth utilization so it's still an issue.
From: CentOS on behalf of Pete Biggs
Sent: Wednesday, March 25,
Am 25.03.20 um 19:15 schrieb Simon Matter via CentOS:
On Wed, 2020-03-25 at 14:39 +, Leroy Tennison wrote:
Since you state that using -z is almost always a bad idea, could you
provide the rationale for that? I must be missing something.
I think the "rationale" is that at some point the
co
On Wed, Mar 25, 2020 at 02:49:24PM +0100, Simon Matter via CentOS wrote:
> Hi,
>
> I've discovered a bug in rsync which leads to increased CPU usage and
> slower transfers in many situations.
>
> When syncing with compression (-z), certain file types should not be
> compressed during the transfer
> On Wed, Mar 25, 2020 at 02:49:24PM +0100, Simon Matter via CentOS wrote:
>> Hi,
>>
>> I've discovered a bug in rsync which leads to increased CPU usage and
>> slower transfers in many situations.
>>
>> When syncing with compression (-z), certain file types should not be
>> compressed during the t
> I appreciate the reply - it keeps me from wondering "is there something I
> should be concerned about?". We use a co-location facility where we pay
> for bandwidth utilization so it's still an issue.
Hi,
You are right, bandwidth always costs, always.
Who pays for it can differ a lot, but ther
20 matches
Mail list logo
