similar to: pread and pwrite syscalls fix for 32bit arches, patch attached

Commit-ID: 75895304280f597f46551deb8b87c27ac18a013c Gitweb: http://git.kernel.org/?p=libs/klibc/klibc.git;a=commit;h=75895304280f597f46551deb8b87c27ac18a013c Author: Helge Deller <deller at gmx.de> AuthorDate: Wed, 6 Jan 2016 00:43:50 +0000 Committer: H. Peter Anvin <hpa at linux.intel.com> CommitDate: Tue, 5 Jan 2016 17:45:50 -0800 [klibc] Add pread and pwrite 32bit syscall

Helge Deller dixit: >On hppa/parisc we still need executable stacks for the signal >trampoline return code. Might your patch then maybe break fstype on >hppa? I didn't tested it... I think it only changed the assembly parts of the library to signal to the linker that there?s no need for an executable stack on their account, but the signal handling code should? add one on hppa then.

Not sure about the radeon issue, but "DRM: GPU lockup - switching to software fbcon" basically means "the CPU isn't able to submit commands, or the GPU isn't executing the commands". Basically the GPU can only have so many commands outstanding [well, command buffers], and we hit that limit. >From what I understand, PA-RISC has a "funny" architecture that

The very same option list, but for the "radeon" kernel module: http://xorg.freedesktop.org/wiki/RadeonFeature/#index4h2 Simone Mannori - Italy On 4 April 2016 at 05:56, Simone Mannori <simone.mannori at gmail.com> wrote: > Dear Ilia, > > this page summarize all the possible options of the "nouveau" kernel module: > >

On 01.09.20 18:21, Helge Deller wrote: > On 01.09.20 17:22, James Bottomley wrote: >> On Tue, 2020-09-01 at 16:05 +0100, Matthew Wilcox wrote: >>> On Tue, Sep 01, 2020 at 07:52:40AM -0700, James Bottomley wrote: >>>> I think this looks mostly OK, except for one misnamed parameter >>>> below. Unfortunately, the last non-coherent parisc was the 700

Dear Ilia, this page summarize all the possible options of the "nouveau" kernel module: https://nouveau.freedesktop.org/wiki/KernelModuleParameters/ I will test the options that you have suggested as soon as possible. Try a PCI video card is a very good advice because the AGP/FX1(chipset) is on the top of the "usual suspects" list; unfortunately the c8000 has 3.3 PCI slots

Here's an assortment of build and run-time fixes for various architectures that we've applied in Debian. Ben. Aurelien Jarno (1): ppc64: fix struct stat Ben Hutchings (2): MIPS: Update archfcntl.h syscalls: Override detection of direct socket syscalls on i386, m68k, s390 Helge Deller (1): Add pread and pwrite 32bit syscall wrappers for parisc Mauricio Faria de Oliveira

Dear "nouveau" developers, I know that many very competent guys have already spent a lot of time and efforts on this issue without success. I have started to play with "hppa" two weeks ago and, with the support of the linux-parisc mailing list people, now I have a - almost fully - working workstation (hp c8000). Everythings work perfectly BUT the video card. No matter the

On Tue, Jan 12, 2016 at 06:21:14PM +0100, Helge Deller wrote: > On 12.01.2016 12:10, Richard W.M. Jones wrote: > > On Tue, Jan 12, 2016 at 10:05:00AM +0000, Richard W.M. Jones wrote: > >> On Tue, Jan 12, 2016 at 07:57:03AM +0100, Hilko Bengen wrote: > >>> Helge, > >>> > >>> I have applied all the architecture-specific bits but not the bin2s

From: Sui Jingfeng <suijingfeng at loongson.cn> This patch adds the aperture_contain_firmware_fb() function to do the determination. Unfortunately due to the fact that apertures list will be freed dynamically, the location and size information of the firmware fb will be lost after dedicated drivers call aperture_remove_conflicting_devices(), aperture_remove_conflicting_pci_devices() or

On Tue, Sep 01, 2020 at 06:41:12PM +0200, Helge Deller wrote: > > I still have a zoo of machines running for such testing, including a > > 715/64 and two 730. > > I'm going to test this git tree on the 715/64: The 715/64 is a 7100LC machine though. I think you need to boot on the 730 to test the non-coherent path.

Hi everyone, One of my teammates here at HP uncovered this, and I thought it deserved proactive mention on the list: It covers non-HP builds of Samba, so HP CIFS Server (HP's version of Samba bundled with all 11.0 and above OS'es) customers are not directly affected but those of you on the list who might build Samba yourselves on 11.11 could be affected. Customers building their own

From: "Richard W.M. Jones" <rjones at redhat.com> In Linux, close (fd) closes the file descriptor even if it returns an error. --- daemon/file.c | 2 -- 1 files changed, 0 insertions(+), 2 deletions(-) diff --git a/daemon/file.c b/daemon/file.c index e0f8794..91746e0 100644 --- a/daemon/file.c +++ b/daemon/file.c @@ -483,7 +483,6 @@ pread_fd (int fd, int count, int64_t

If the plugin .pread method did not fill the buffer with data then the contents of the heap could be leaked back to the client. To avoid this create a thread-local data buffer which is initialized to zero and expanded (with zeroes) as required. This buffer is shared between pread and pwrite which makes the code a little bit simpler. Also this may improve locality by reusing the same memory for

On 4/23/19 10:09 AM, Richard W.M. Jones wrote: > If the plugin .pread method did not fill the buffer with data then the > contents of the heap could be leaked back to the client. To avoid > this create a thread-local data buffer which is initialized to zero > and expanded (with zeroes) as required. > > This buffer is shared between pread and pwrite which makes the code a >

It looks like libplugin_common.a is being linked into the shared object libxmms-flac.so. In that case, all of the objects in libplugin_common.a must be compiled with -fPIC. ----- Forwarded message from lamont+buildd@hp.com ----- Date: Sat, 28 Sep 2002 18:54:08 -0600 From: lamont+buildd@hp.com Resent-From: lamont+buildd@hp.com To: submit@bugs.debian.org Subject: Bug#162718:

https://bugzilla.samba.org/show_bug.cgi?id=3646 Summary: rsync: connection unexpectedly closed (3207118 bytes received so far) [generator] Product: rsync Version: 2.6.6 Platform: x86 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

I'm having a pretty serious rsync bug, which I've submitted to the Debian bug system. But as the rsync maintainer there seems to be a bit slow in fixing problems, I thought perhaps I should report it here as well. I'm using rsync 2.6.2 on a Debian woody system, with libc 2.2.5. I have rsync running daily to mirror the Debian archives, mainly for i386 files. The command I use is

Hi, I got the following bug report on the Debian rsync which has the ACL patch applied: On Fri 01 Dec 2006, Bryan Gartner wrote: > > When using the rltvz options to mirror files from a remote server, these > kinds of issues are reported: > > default_perms_for_dir: sys_acl_get_file(wallpaper, SMB_ACL_TYPE_DEFAULT): > Function not implemented, falling back on umask >

As a new co-maintainer of klibc, I have just released version 2.0.5. The git repository remains at: https://git.kernel.org/pub/scm/libs/klibc/klibc.git A tarball will be available from the usual place later, but I'm not currently able to upload there. This new release fixes various build and run-time failures with current versions of Linux, gcc, and binutils on mips, sparc and x86; and