similar to: Device majors incorrectly set to 0 during rsync

Hi. Here's a patch for copying the atimes of files when -t/--times is given. I bumped the protocol to 29 since it sends more data over the wire. It obviously does not send the atime if it's sending data to an older rsync version. It passes all the tests (including the added atime.test) for me on a: Linux Debian/3.0 gcc 2.95.4 (debian), glibc 2.2.5 system. Any questions/feedback? I

https://bugzilla.samba.org/show_bug.cgi?id=6280 Summary: (Bug incl. PATCH) Linux mknod does not work when syncing fifos and sockets from Solaris Product: rsync Version: 3.0.6 Platform: x64 OS/Version: Linux Status: NEW Severity: normal Priority: P3 Component: core AssignedTo:

Hello there I have been trying to install HP Storageworks DAT72 on CentOS 5 in vain. On system reboot, neither /dev/st not /dev/sg is available. May you please lead me through as this is my first time trying to do it lsmod Module Size Used by ipv6 267617 40 xfrm_nalgo 13381 1 ipv6 crypto_api 12609 1 xfrm_nalgo autofs4

Trying to compile rsync 2.5.2 after "./configure --prefix=/usr" I get the following make errors: gcc -I. -I. -g -O2 -DHAVE_CONFIG_H -Wall -W -c rsync.c -o rsync.o In file included from rsync.c:23: rsync.h:339: warning: no semicolon at end of struct or union rsync.h:339: parse error before `inode' rsync.h:341: parse error before `dev' rsync.h:341: warning: type

Hi, I am trying to load kernel 2.6.6 on a Soekris net4521 from the network using PXE. I built my initrd with mkinitrd. RedHat nash (while running linuxrc) hangs after mounting /proc and says "Creating block devices". I am using the pxelinux.0 from the syslinux-2.10 distribution and the kernel and initrd were built on redhat 9.0. I built my kernel with BLK_DEV_RAM, RAMFS, TMPFS,

Hiya, I can see it's a regular subject on this list. I, like others wanted to use rsync to synchronise two block devices (as it happens one lvm volume and one nbd device served by qemu-img on a remote host from a qcow2 disk image so that I can keep the old versions) As I couldn't find any report of it being done successfully, I'm just sharing my findings as it might benefit others.

Two patches: one to correct the spelling of permissions (in comments, but such typos disturb me as well), and one to cast inode and dev to unsigned long before comparing, to prevent gcc giving a warning "comparison between signed and unsigned". Paul Slootman -------------- next part -------------- diff -ru orig/rsync-2.5.6/generator.c rsync-2.5.6/generator.c ---

Hi List, I had a need recently to efficiently synchronise between some large LUNs (boot drive disks) at two different datacentres. Solutions like drbd and $proprietary_array_vendors_software were overkill - we only needed (wanted!) to periodically synchronise these LUNs whenever major changes were generated on the source. On the other hand however, re-sending the entire disk contents each time

Am 19.05.2014 15:35, schrieb Maarten Lankhorst: > op 19-05-14 14:30, Christian K?nig schreef: >> Am 19.05.2014 12:10, schrieb Maarten Lankhorst: >>> op 19-05-14 10:27, Christian K?nig schreef: >>>> Am 19.05.2014 10:00, schrieb Maarten Lankhorst: >>>> [SNIP] >>>> The problem here is that the whole approach collides with the way >>>>

Hi guys, Well let's face it AGP is a total headache to maintain and dead for at least 10+ years. We have a lot of x86 specific stuff in the architecture independent graphics memory management to get the caching right, abusing the DMA API on multiple occasions, need to distinct between AGP and driver specific page tables etc etc... So the idea here is to just go ahead and remove the support

Hi Christian Am 11.05.20 um 19:17 schrieb Christian K?nig: > AGP is deprecated for 10+ years now and not used any more on modern hardware. > > Old hardware should continue to work in PCI mode. > > Signed-off-by: Christian K?nig <christian.koenig at amd.com> > --- > drivers/gpu/drm/radeon/Makefile | 4 +- > drivers/gpu/drm/radeon/evergreen.c | 7 -

> -----Original Message----- > From: Maarten Lankhorst [mailto:maarten.lankhorst at canonical.com] > Sent: Wednesday, July 09, 2014 8:30 AM > To: airlied at linux.ie > Cc: thellstrom at vmware.com; nouveau at lists.freedesktop.org; linux- > kernel at vger.kernel.org; dri-devel at lists.freedesktop.org; > bskeggs at redhat.com; Deucher, Alexander; Koenig, Christian >

Am 02.06.2014 12:09, schrieb Maarten Lankhorst: > Changes since v1: > - Fixed interaction with reset handling. > + Use exclusive_lock, either with trylock or blocking. > + Bump sw irq refcount in the recovery function to prevent fiddling > with irq registers during gpu recovery. > - Add radeon lockup detection to the default fence wait function. First of all please

Am 19.05.2014 10:00, schrieb Maarten Lankhorst: > op 15-05-14 18:13, Christian K?nig schreef: >> Am 15.05.2014 17:58, schrieb Maarten Lankhorst: >>> op 15-05-14 17:48, Christian K?nig schreef: >>>> Am 15.05.2014 16:18, schrieb Maarten Lankhorst: >>>>> op 15-05-14 15:19, Christian K?nig schreef: >>>>>> Am 15.05.2014 15:04, schrieb

Am 15.05.2014 11:38, schrieb Maarten Lankhorst: > op 15-05-14 11:21, Christian K?nig schreef: >> Am 15.05.2014 03:06, schrieb Maarten Lankhorst: >>> op 14-05-14 17:29, Christian K?nig schreef: >>>>> + /* did fence get signaled after we enabled the sw irq? */ >>>>> + if >>>>>

Here's one final (I hope) question without a complete patch. Given that I already ensure that stubs.c invokes REQUIRE_ROOT_OR_RESOLVE_DEVICE just before calling do_umount, does this new version of do_umount look ok? /* Again, use the external /bin/umount program, so that /etc/mtab * is kept updated. */ int do_umount (const char *pathordevice) { int r; char *err; char *buf =

Am 02.06.2014 15:14, schrieb Maarten Lankhorst: > This makes it possible to wait for a specific amount of time, > rather than wait until infinity. > > Signed-off-by: Maarten Lankhorst <maarten.lankhorst at canonical.com> > --- > Splitted out version, I've noticed that I forgot to convert > radeon_fence_wait_empty to long r, fixed. >

Am 04.08.2014 um 17:09 schrieb Maarten Lankhorst: > op 04-08-14 17:04, Christian K?nig schreef: >> Am 04.08.2014 um 16:58 schrieb Maarten Lankhorst: >>> op 04-08-14 16:45, Christian K?nig schreef: >>>> Am 04.08.2014 um 16:40 schrieb Maarten Lankhorst: >>>>> op 04-08-14 16:37, Christian K?nig schreef: >>>>>>> It'a pain to deal

Joe Perches (2): drm: Use pr_cont where appropriate gpu: drm: Convert printk(KERN_<LEVEL> to pr_<level> drivers/gpu/drm/amd/amdgpu/amdgpu.h | 3 +- drivers/gpu/drm/amd/amdgpu/amdgpu_afmt.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_atpx_handler.c | 4 +- drivers/gpu/drm/amd/amdgpu/amdgpu_device.c | 4 +-

Am 23.07.2014 12:52, schrieb Daniel Vetter: > On Wed, Jul 23, 2014 at 12:13 PM, Christian K?nig > <christian.koenig at amd.com> wrote: >>> And the dma-buf would still have fences belonging to both drivers, and it >>> would still call from outside the driver. >> >> Calling from outside the driver is fine as long as the driver can do >> everything