similar to: swiotlb buffer is full

Displaying 20 results from an estimated 300 matches similar to: "swiotlb buffer is full"

2018 Feb 01
1
swiotlb buffer is full
On Wed, Jan 31, 2018 at 9:20 PM, Ilia Mirkin <imirkin at alum.mit.edu> wrote: > Yeah, a lot of people were getting that, as a result of some drm/ttm > hugepage usage. > > Christian, did a fix ever end up going out? If so, what kernel was it > included in? https://lkml.org/lkml/2018/1/16/106 Alex > > -ilia > > On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger
2018 Feb 01
0
swiotlb buffer is full
Yeah, a lot of people were getting that, as a result of some drm/ttm hugepage usage. Christian, did a fix ever end up going out? If so, what kernel was it included in? -ilia On Wed, Jan 31, 2018 at 11:05 AM, Ricardo Nabinger Sanchez <rnsanchez at gmail.com> wrote: > Hello, > > I've noticed firefox got randomly stuck, and as sometimes that leads to a > complete system
2017 May 28
4
[Bug 101215] New: Graphics Crash
https://bugs.freedesktop.org/show_bug.cgi?id=101215 Bug ID: 101215 Summary: Graphics Crash Product: Mesa Version: unspecified Hardware: x86-64 (AMD64) OS: Linux (All) Status: NEW Severity: major Priority: medium Component: Drivers/DRI/nouveau Assignee: nouveau at
2008 Jun 27
1
Performance of madvise / msync
Hi, I'm using py-rrdtool 0.2.1 with rrdtool 1.3.0 under 7.0-STABLE, and there's a couple of things about this new version of rrdtool that hurt performance under FreeBSD, but apparently help on whatever they tested on. For every update, the database file is opened, mapped into memory, madvise() is called, contents are modified, msync() is called, and the file is unmapped and closed:
2005 Nov 28
20
open/stat64 syscalls run faster on Xen VM than standard Linux
Dear all, When I debugged the execution performance of an application using strace, I found there are some system calls like open and stat64 which run faster on XenLinux than the standard Linux. The following is the output of running "strace -c /bin/sh -c /bin/echo foo" on both systems. An open call runs averagely 109 usec on standard Linux but only 41 usecs on XenLinux. An stat64
2005 Dec 01
3
Saving files with MS Word to samba3 server is very slow!
Hi! I'm currently hunting a strange problem and looking for help! I have a samba3 fileserver (currently samba-3.0.20b, but problem can be reproduced with samba-3.0.7, but _not_ with samba2 like 2.2.8a), and I see performance problems when writing files with MS word 2002 SP3 from a NT4.0 (SP6a) workstation. Saving even the smallest file takes more than 10 seconds! Copying files with Windows
2018 Dec 12
4
vfs_fruit causes delay in listing directories for Windows clients
Listing directories with many files (10000+) from a Windows client is nociceably slower when vfs_fruit is enabled on the samba server compared to the same setup without vfs_fruit. On my setup it's roughly 2.5 times slower. To me it looks like this is caused by the getxattr call which is only present with vfs_fruit activated and introduces an additional delay of ~ 0.00033 s per listed
2013 Feb 12
1
Can't get working nsswitch, specifically "wbinfo -u"
Hi, my environment: Win2003 AD + Samba4 as second RW DC on debian wheeze. Samba compiled from source: samba --version Version 4.1.0pre1-GIT-c932b13 Installed Samba4 according these: https://wiki.samba.org/index.php/Main_Page https://wiki.samba.org/index.php/Samba4/HOWTO/Join_a_domain_as_a_DC https://wiki.samba.org/index.php/Samba4/Winbind Everything went good according tutorial, until I try get
2017 Sep 18
1
Confusing lstat() performance
On 18/09/17 17:23, Ben Turner wrote: > Do you want tuned or untuned? If tuned I'd like to try one of my tunings for metadata, but I will use yours if you want. (Re-CC'd list) I would be interested in both, if possible: To confirm that it's not only my machines that exhibit this behaviour given my settings, and to see what can be achieved with your tuned settings. Thank you!
2023 Jun 13
1
Upssched 100% CPU after updating Debian 12
Thanks for the interesting puzzle to crunch! Looking at these few bread-crumbs, I wager an educated guess that this loops in `sendcmd()` (where CLI child processes talk to a daemonized copy which tracks the timers for events), around here: https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L583-L626 for the daemon and here for the child:
2023 Jun 13
1
Upssched 100% CPU after updating Debian 12
Thanks for the interesting puzzle to crunch! Looking at these few bread-crumbs, I wager an educated guess that this loops in `sendcmd()` (where CLI child processes talk to a daemonized copy which tracks the timers for events), around here: https://github.com/networkupstools/nut/blob/v2.8.0/clients/upssched.c#L583-L626 for the daemon and here for the child:
2015 Apr 23
2
Samba 4 slow write
Hi Jones, many thanks again four your help and your time. Thanks for the patch too - I'll check it up. On my Ubuntu, there is a Samba 4.1.6. I'll install the samba source package, and will try to apply the patch, then - I hope - the package will be compiled as well. I'll notify to you about the result. (First, I need to upgrade that server.) Thanks again, Ervin On Thu, Apr
2023 Jun 13
1
Upssched 100% CPU after updating Debian 12
Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,
2023 Jun 13
1
Upssched 100% CPU after updating Debian 12
Hi, I ran the strace command while upssched was 100% CPU hungry. This is what I got: 1686633611.702798 read(7, "", 1) = 0 <0.000004> 1686633611.702816 read(7, "", 1) = 0 <0.000004> 1686633611.702834 pselect6(11, [7 10], NULL, NULL, {tv_sec=1, tv_nsec=0}, NULL) = 1 (in [7], left {tv_sec=0, tv_nsec=999998800}) <0.000006> 1686633611.702862 read(7,
2018 Dec 12
0
vfs_fruit causes delay in listing directories for Windows clients
Hai, Can you tell the following that helps. OS ? Samba Version? ( pre-builded or source ) Kernel version? I think you need to wait for 4.9.4 if all patches ive seen on vfs_fruit are getting in. These might help. Go through bugzilla, you might find more about this here. Greetz, Louis > -----Oorspronkelijk bericht----- > Van: samba [mailto:samba-bounces at lists.samba.org]
2014 May 19
1
[PATCH 3/4] drm/nouveau: hook up cache sync functions
Am Montag, den 19.05.2014, 16:10 +0900 schrieb Alexandre Courbot: > From: Lucas Stach <dev at lynxeye.de> > > Signed-off-by: Lucas Stach <dev at lynxeye.de> > [acourbot at nvidia.com: make conditional and platform-friendly] > Signed-off-by: Alexandre Courbot <acourbot at nvidia.com> > --- > drivers/gpu/drm/nouveau/nouveau_bo.c | 32
2008 Apr 24
1
select() timeout on winbindd_privileged pipe
I have an issue where winbind will occasionally pause for 30 seconds. # strace -T -t ls -l /share 16:52:20 read(4, "/var/lib/samba/winbindd_privileg"..., 35) = 35 <0.000009> 16:52:20 lstat("/var/lib/samba/winbindd_privileged", {st_mode=S_IFDIR|0750, st_size=72, ...}) = 0 <0.000011> 16:52:20 lstat("/var/lib/samba/winbindd_privileged/pipe",
2015 May 02
2
Samba 4 slow write
Hi folks, On Fri, Apr 24, 2015 at 08:01:54AM +0800, Jones Syue wrote: > Hello Ervin, > > > I'll notify to you about the result. (First, I need to upgrade > > that server.) > > Sure! That will be great help me to understand if this patch > works on thast compiling case too, > thank you. I"ve downloaded the Ubuntu's Samba 4.1.6 deb source, and patch it
2012 Oct 20
3
system.time question
Hi : I looked at the help for system.time but I still have the following question. Can someone explain the output following output of system.time : user system elapsed 12399.681 5632.352 56935.647 Here's my take based on the fact that I was doing ps -aux | grep R off and on and the total amount of CPU minutes that got allotted before the job ended was about 5 hours and the
2014 May 19
8
[PATCH 0/4] drm/ttm: nouveau: memory coherency fixes for ARM
This small series introduces TTM helper functions as well as Nouveau hooks that are needed to ensure buffer coherency on ARM. Most of this series is a forward-port of some patches Lucas Stach sent last year and that are also needed for Nouveau GK20A support: http://lists.freedesktop.org/archives/nouveau/2013-August/014026.html Another patch takes care of flushing the CPU write-buffer when