search for: 16bytes

On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code in TargetData.cpp: > > if

On Sep 18, 2012, at 3:11 AM, Richard Osborne <richard at xmos.com> wrote: >>> I want it to be configurable. On my target there is no advantage to aligning anything by more than a 4 bytes - it just wastes space. I'll try to put together a proposal for making it possible to set this per target. >> Ok, after considering this a bit more, how about we take a different approach:

On Thu, 20 Sep 2012 10:18:46 -0700 Chris Lattner <clattner at apple.com> wrote: > On Sep 18, 2012, at 3:11 AM, Richard Osborne <richard at xmos.com> wrote: > >>> I want it to be configurable. On my target there is no advantage > >>> to aligning anything by more than a 4 bytes - it just wastes > >>> space. I'll try to put together a proposal

On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow (e.g. the maximum preferred alignment across all

I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code in TargetData.cpp: if (GV->hasInitializer() && GVAlignment == 0) { if (Alignment < 16) { // If the global

On 06/09/12 20:24, Chris Lattner wrote: > On Sep 6, 2012, at 8:51 AM, Richard Osborne <richard at xmos.com> wrote: > >> I recently noticed that all globals bigger than 16 bytes are being 16 byte aligned by LLVM (assuming there isn't an explicitly requested alignment). I'd really rather avoid this, at least for the XCore backend. I tracked this down to the following code

On 07/09/12 18:13, Chris Lattner wrote: > On Sep 7, 2012, at 8:02 AM, Richard Osborne <richard at xmos.com> wrote: >>>> I was a bit surprised to see these numbers hardcoded in TargetData since everything else is taken from the datalayout string. I was wondering what the logic was behind the number 16. Would it make sense to derive this number from the other alignments somehow

Dear all, while playing around with openssh-4.1p1 (trying to add AFS token forwarding in SSH-2), I noticed that agressive rekeying (as e.g. employed by regress/rekey.sh, rekeying every 16bytes) seems to disturb the various forwardings (X11, agent) set up at the beginning of the session. These do not trigger regression test errors, since the client does not ask for confirmation from the server for these commands (except for remote port forwarding, and that one isn't set up by default)...

...oderateValueParent") + +mvp = h.node_get_child (root, "ModerateValueParent") +assert mvp + +moderate_value = "0123456789ABCDEF" + +values = [ + { "key": "3Bytes", "t": 3, "value": moderate_value[:3] }, + { "key": "16Bytes", "t": 3, "value": moderate_value }, + { "key": "30Bytes", "t": 3, "value": (moderate_value*2)[:30] }, + { "key": "31Bytes", "t": 3, "value": (moderate_value*2)[:31] }, + { "key&qu...

Hello all, I tried OpenSSH versions 2.1.1p4, 2.2.0p1 and the latest snapshot briefly on 64-bit Irix 6.5.7f an 6.5.9m. Both times, no matter what I do, I'll get 'PRNG initialization failed -- exiting'. This happens with ssh-keygen (the keys aren't even generated yet, ssh binary etc.) It's clear that Irix etc. don't have a proper entropy pool like *BSD and Linux do, but

Hi mabi, This is a likely issue where the last gfid entry in the quota.conf file is stale (because the directory was deleted with quota limit on it being removed) (https://review.gluster.org/#/c/16507/) To fix the issue, we need to remove the last entry (last 17 bytes/ 16bytes based on quota version) in the file. Please use the below work around for the same until next upgrade. you only need to change $vol to the name of volume. =============================== vol=<v5> qconf=/var/lib/glusterd/vols/$vol/quota.conf qconf_bk="$qconf".bk cp $qconf $qconf_bk...

...> > > Hi mabi, > This is a likely issue where the last gfid entry in the quota.conf file is stale (because the directory was deleted with quota limit on it being removed) > (https://review.gluster.org/#/c/16507/) > To fix the issue, we need to remove the last entry (last 17 bytes/ 16bytes based on quota version) in the file. > Please use the below work around for the same until next upgrade. > you only need to change $vol to the name of volume. > =============================== > > vol=<v5> > qconf=/var/lib/glusterd/vols/$vol/quota.conf > qconf_bk="$q...

I tried to re-create manually my quotas but not even that works now. Running the "limit-usage" command as showed below returns success: $ sudo gluster volume quota myvolume limit-usage /userdirectory 50GB volume quota : success but when I list the quotas using "list" nothing appears. What can I do to fix that issue with the quotas? > -------- Original Message -------- >

...afe and provides an easy way to avoid wasting space on a * uni-processor: */ # define SMP_CACHE_SHIFT 3 # define SMP_CACHE_BYTES (1 << 3) #endif For a UP system, SMP_CACHE_BYTES is only 8 bytes to save space. Then maybe several months ago, there''s such requirement to xmalloc a 16bytes aligned (legal on ia64 system like a long double) structure and then failed due to BUG_ON with an immediate lazy hack to add ifdef there. For now, such case seems disappearing after a quick test. However I think the preferred way is to increase SMP_CACHE_SHIFT to 4 to match maximum allowed alignme...

..., 512) = 64 654 time(NULL) = 1200921228 ... with some init stuff before (fd#3 is /dev/hiddev0). What it reads looks pretty much the same as the stuff returned by similar UPS connected over normal serial port (but 4x more - there are 4 identical blocks of data read, each of 16bytes in size). Here's the init stuff: 653 open("/dev/hiddev0", O_RDONLY) = 3 653 ioctl(3, HIDIOCAPPLICATION, 0) = -6291455 653 ioctl(3, HIDIOCAPPLICATION, 0) = -6291455 653 ioctl(3, HIDIOCGVERSION, 0xbfb09fdc) = 0 653 write(1, "hiddev driver version is 1.0.4\n&quo...

...in sambaNTPassword, I'm assuming NTLMv2 passwords need to be stored in this attribute as I don't see an alternative? When I try to login to a user account with an NTLMv2 hashed password, I get invalid password, but I think I've calculated the hash correctly, looking in LDAP, I stored a 16bytes HEX String ( sambaNTPassword: 47E53AD35D61DE8F419F272FFBC4F175 ). The password check is failing in ntlm_password_check (libsmb/ntlm_check.c). I've marked where the password check is failing in bold, NTSTATUS ntlm_password_check(....) { static const unsigned char zeros[8]; if (...

Hi, I think this has already been asked on the list, but I can''t seem to be able to find it again: currently, active record does some weird thing with its sql logs i.e.: [4;33mSQL (0.000000) [1;37mPRAGMA table_info(map_locations) how do I remove the "[4;35m" thx Jean

...* PVSCSI_FLAG_CMD_DIR_NONE: no DMA involved, > + * * PVSCSI_FLAG_CMD_DIR_TOHOST: transfer from device to main memory, > + * * PVSCSI_FLAG_CMD_DIR_TODEVICE: transfer from main memory to device, > + * * PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB: reserved to handle CDBs larger than > + * 16bytes. To be specified. > + * - vcpuHint: vcpuId of the processor that will be most likely waiting for the > + * completion of the i/o. For guest OSes that use lowest priority message > + * delivery mode (such as windows), we use this "hint" to deliver the > + * completion act...

...* PVSCSI_FLAG_CMD_DIR_NONE: no DMA involved, > + * * PVSCSI_FLAG_CMD_DIR_TOHOST: transfer from device to main memory, > + * * PVSCSI_FLAG_CMD_DIR_TODEVICE: transfer from main memory to device, > + * * PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB: reserved to handle CDBs larger than > + * 16bytes. To be specified. > + * - vcpuHint: vcpuId of the processor that will be most likely waiting for the > + * completion of the i/o. For guest OSes that use lowest priority message > + * delivery mode (such as windows), we use this "hint" to deliver the > + * completion act...

...dataAddr above, + * * PVSCSI_FLAG_CMD_DIR_NONE: no DMA involved, + * * PVSCSI_FLAG_CMD_DIR_TOHOST: transfer from device to main memory, + * * PVSCSI_FLAG_CMD_DIR_TODEVICE: transfer from main memory to device, + * * PVSCSI_FLAG_CMD_OUT_OF_BAND_CDB: reserved to handle CDBs larger than + * 16bytes. To be specified. + * - vcpuHint: vcpuId of the processor that will be most likely waiting for the + * completion of the i/o. For guest OSes that use lowest priority message + * delivery mode (such as windows), we use this "hint" to deliver the + * completion action to the proper vc...