search for: scratch2

Skipped content of type multipart/alternative-------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: image/gif Size: 3088 bytes Desc: not available Url : http://lists.samba.org/archive/rsync/attachments/20080221/9cf0c512/attachment.gif

...(+), 1 deletion(-) diff --git a/xen/drivers/char/ns16550.c b/xen/drivers/char/ns16550.c index 5892eb7..9c2cded 100644 --- a/xen/drivers/char/ns16550.c +++ b/xen/drivers/char/ns16550.c @@ -503,7 +503,7 @@ static int __init check_existence(struct ns16550 *uart) { unsigned char status, scratch, scratch2, scratch3; -#ifdef HAS_IO_PORTS +#ifdef HAS_IOPORTS /* * We can''t poke MMIO UARTs until they get I/O remapped later. Assume that * if we''re getting MMIO UARTs, the arch code knows what it''s doing. -- 1.7.10.4

...d names = no preserve case = yes short preserve case = yes load printers = no [scratch] comment = Public Stuff path = /testpool/scratch writable = yes browsable = yes [scratch1] comment = Public Stuff 1 path = /testpool/scratch1 writable = yes browsable = yes [scratch2] comment = Public Stuff 2 path = /testpool/scratch2 writable = yes browsable = yes

...his may foreshadow disaster LustreError: 5080:0:(import.c:607:ptlrpc_connect_interpret()) data4-OST0000_UUID at 192.168.2.98@tcp changed handle from 0xfe51139158c6502c to 0xfe511392a35878c1; copying, but this may foreshadow disaster LustreError: 5080:0:(import.c:607:ptlrpc_connect_interpret()) scratch2-OST0003_UUID at 192.168.2.99@tcp changed handle from 0x9ee58a75fddf2834 to 0x9ee58a761d190470; copying, but this may foreshadow disaster LustreError: 5080:0:(import.c:607:ptlrpc_connect_interpret()) scratch1-OST0003_UUID at 192.168.2.99@tcp changed handle from 0x9ee58a75fddf2754 to 0x9ee58a761d...

Hello, We've found some undesirable behavior with respect to LoginGraceTime. A minor code change in session.c seems to clear it up, but now I'm asking for help in better understanding the problem and determining if there any unexpected side effects of the change. First, the code change: $ diff orig_session.c session.c 216c216,218 < alarm(0); --- >

...void mic_x100_reset_fw_ready(struct mic_device *mdev) +{ + mdev->ops->write_spad(mdev, MIC_X100_DOWNLOAD_INFO, 0); +} + +/* + * mic_x100_is_fw_ready - Check if firmware is ready. + * @mdev: pointer to mic_device instance + */ +static bool mic_x100_is_fw_ready(struct mic_device *mdev) +{ + u32 scratch2 = mdev->ops->read_spad(mdev, MIC_X100_DOWNLOAD_INFO); + return MIC_X100_SPAD2_DOWNLOAD_STATUS(scratch2) ? true : false; +} + +/** + * mic_x100_get_apic_id - Get bootstrap APIC ID. + * @mdev: pointer to mic_device instance + */ +static u32 mic_x100_get_apic_id(struct mic_device *mdev) +{ + u32...

...); + SAVE_STACK; + ALLOC(xx, n, opus_val16); + celt_assert(n>0); + celt_assert(overlap>=0); + for (i=0;i<n;i++) + xx[i] = x[i]; + + { + opus_val16 * xxbeg = xx; + opus_val16 * xxend = xx+n-1; + const opus_val16 * xbeg = x; + const opus_val16 * xend = x+n-1; + int scratch0, scratch1, scratch2, scratch3, scratch4; + __asm__ __volatile__( + "movs %6, %5, lsr #3;\n" + "beq .celt_autocorr_process8_done_%=;\n" + + /* Process 8 samples at a time */ + ".celt_autocorr_process8_%=:\n" + "subs %3, %3, #16;\n" + "subs %1, %1, #16;\n&...

...void mic_x100_reset_fw_ready(struct mic_device *mdev) +{ + mdev->ops->write_spad(mdev, MIC_X100_DOWNLOAD_INFO, 0); +} + +/* + * mic_x100_is_fw_ready - Check if firmware is ready. + * @mdev: pointer to mic_device instance + */ +static bool mic_x100_is_fw_ready(struct mic_device *mdev) +{ + u32 scratch2 = mdev->ops->read_spad(mdev, MIC_X100_DOWNLOAD_INFO); + return MIC_X100_SPAD2_DOWNLOAD_STATUS(scratch2) ? true : false; +} + +/** + * mic_x100_hw_reset - Reset the MIC device. + * @mdev: pointer to mic_device instance + */ +static void mic_x100_hw_reset(struct mic_device *mdev) +{ + u32 reset...

...); + SAVE_STACK; + ALLOC(xx, n, opus_val16); + celt_assert(n>0); + celt_assert(overlap>=0); + for (i=0;i<n;i++) + xx[i] = x[i]; + + { + opus_val16 * xxbeg = xx; + opus_val16 * xxend = xx+n-1; + const opus_val16 * xbeg = x; + const opus_val16 * xend = x+n-1; + int scratch0, scratch1, scratch2, scratch3, scratch4; + __asm__ __volatile__( + "movs %6, %5, lsr #3;\n" + "beq .celt_autocorr_process8_done_%=;\n" + + /* Process 8 samples at a time */ + ".celt_autocorr_process8_%=:\n" + "subs %3, %3, #16;\n" + "subs %1, %1, #16;\n&...

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. As before several of the patches are not to be applied because they can be done better using infrastructure from Julien''s "Allow Xen to boot with a raw Device Tree" patch. They are included for completeness. With

ChangeLog: ========= v2 => v3: a) Patch 1 data structure cleanups, header file include cleanups, IDA interface reuse and switching to device_create_with_groups(..) as per feedback from Greg Kroah-Hartman. b) Patch 7 signal documentation, sleep workaround removal and sysfs access API cleanups as per feedback from Michael S. Tsirkin. v1 => v2: @ http://lwn.net/Articles/563131/ a)

ChangeLog: ========= v2 => v3: a) Patch 1 data structure cleanups, header file include cleanups, IDA interface reuse and switching to device_create_with_groups(..) as per feedback from Greg Kroah-Hartman. b) Patch 7 signal documentation, sleep workaround removal and sysfs access API cleanups as per feedback from Michael S. Tsirkin. v1 => v2: @ http://lwn.net/Articles/563131/ a)

ChangeLog: ========= v2 => v3: a) Patch 1 data structure cleanups, header file include cleanups, IDA interface reuse and switching to device_create_with_groups(..) as per feedback from Greg Kroah-Hartman. b) Patch 7 signal documentation, sleep workaround removal and sysfs access API cleanups as per feedback from Michael S. Tsirkin. v1 => v2: @ http://lwn.net/Articles/563131/ a)

ChangeLog: ========= v2 => v3: a) Patch 1 data structure cleanups, header file include cleanups, IDA interface reuse and switching to device_create_with_groups(..) as per feedback from Greg Kroah-Hartman. b) Patch 7 signal documentation, sleep workaround removal and sysfs access API cleanups as per feedback from Michael S. Tsirkin. v1 => v2: @ http://lwn.net/Articles/563131/ a)

An Intel MIC X100 device is a PCIe form factor add-in coprocessor card based on the Intel Many Integrated Core (MIC) architecture that runs a Linux OS. It is a PCIe endpoint in a platform and therefore implements the three required standard address spaces i.e. configuration, memory and I/O. The host OS loads a device driver as is typical for PCIe devices. The card itself runs a bootstrap after

An Intel MIC X100 device is a PCIe form factor add-in coprocessor card based on the Intel Many Integrated Core (MIC) architecture that runs a Linux OS. It is a PCIe endpoint in a platform and therefore implements the three required standard address spaces i.e. configuration, memory and I/O. The host OS loads a device driver as is typical for PCIe devices. The card itself runs a bootstrap after

ChangeLog: ========= v1 => v2: a) License wording cleanup, sysfs ABI documentation, patch 1 refactoring into 3 smaller patches and function renames, as per feedback from Greg Kroah-Hartman. b) Use VRINGH infrastructure for accessing virtio rings from the host in patch 5, as per feedback from Michael S. Tsirkin. v1: Initial post @ https://lkml.org/lkml/2013/7/24/810 Description:

ChangeLog: ========= v1 => v2: a) License wording cleanup, sysfs ABI documentation, patch 1 refactoring into 3 smaller patches and function renames, as per feedback from Greg Kroah-Hartman. b) Use VRINGH infrastructure for accessing virtio rings from the host in patch 5, as per feedback from Michael S. Tsirkin. v1: Initial post @ https://lkml.org/lkml/2013/7/24/810 Description:

See http://www.gossamer-threads.com/lists/xen/devel/297170 for some information on how to get this going. I''ve rebased and addressed the review comments. With this rebase I''ve picked up some patches from Julien which were required to do things properly, so the gic v7 and device blacklisting patches have been changed to use the proper mechanisms. Previously I was able to boot

Hi Jan, After commit 2ca9fbd739b8a72b16dd790d0fff7b75f5488fb8 AMD IOMMU: allocate IRTE entries instead of using a static mapping, booting dom0 stalls several times. Sometimes this results in RCU stall warnings from the dom0 kernel, hitting the "any" key, on normal or serial console, makes the boot continue for a while but it stalls several times. (It also stalls on shutdown BTW) I have