Displaying 20 results from an estimated 21 matches for "u128".
Did you mean:
128
2018 Apr 26
2
windows ABI problem with i128?
...e, here is my test case (in zig code):
=================================================================
pub extern "kernel32" stdcallcc fn ExitProcess(exit_code: c_uint) noreturn;
export fn WinMainCRTStartup() noreturn {
@setAlignStack(16);
@setRuntimeSafety(false);
var a: u128 = 152313999999999991610955792383;
var b: u128 = 10000000000000000000;
var c = a / b; // this generates a call to __udivti3
if (c != b) {
@breakpoint();
}
ExitProcess(0);
}
export fn __udivti3(a: u128, b: u128) u128 {
@setRuntimeSafety(false);
return b;
}
====...
2018 Apr 26
0
windows ABI problem with i128?
...; =================================================================
>
> pub extern "kernel32" stdcallcc fn ExitProcess(exit_code: c_uint) noreturn;
>
> export fn WinMainCRTStartup() noreturn {
> @setAlignStack(16);
> @setRuntimeSafety(false);
>
> var a: u128 = 152313999999999991610955792383;
> var b: u128 = 10000000000000000000;
> var c = a / b; // this generates a call to __udivti3
>
> if (c != b) {
> @breakpoint();
> }
> ExitProcess(0);
> }
>
> export fn __udivti3(a: u128, b: u128) u128 {
>...
2018 Apr 26
1
windows ABI problem with i128?
...======================
> >
> > pub extern "kernel32" stdcallcc fn ExitProcess(exit_code: c_uint)
> noreturn;
> >
> > export fn WinMainCRTStartup() noreturn {
> > @setAlignStack(16);
> > @setRuntimeSafety(false);
> >
> > var a: u128 = 152313999999999991610955792383;
> > var b: u128 = 10000000000000000000;
> > var c = a / b; // this generates a call to __udivti3
> >
> > if (c != b) {
> > @breakpoint();
> > }
> > ExitProcess(0);
> > }
> >
> >...
2013 Dec 17
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...aa0
[<00000000003a2a0e>] kjournald+0xfe/0x2a0
[<00000000001786fc>] kthread+0xd8/0xe0
[<0000000000698fee>] kernel_thread_starter+0x6/0xc
2 locks held by kjournald/1984:
... and end up in hang situations ...
PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1"
#0 [1e2033e0] __schedule at 695ff2
#1 [1e203530] log_wait_commit at 3a28a6
#2 [1e2035a0] ext3_sync_fs at 328dea
#3 [1e2035d8] sync_filesystem at 2c785c
#4 [1e203600] fsync_bdev at 2d4650
#5 [1e203628] invalidate_partition at 3f80c8
#6 [1e203650] del_gendisk at 3f8f5c
#7 [1e2...
2013 Dec 17
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...aa0
[<00000000003a2a0e>] kjournald+0xfe/0x2a0
[<00000000001786fc>] kthread+0xd8/0xe0
[<0000000000698fee>] kernel_thread_starter+0x6/0xc
2 locks held by kjournald/1984:
... and end up in hang situations ...
PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1"
#0 [1e2033e0] __schedule at 695ff2
#1 [1e203530] log_wait_commit at 3a28a6
#2 [1e2035a0] ext3_sync_fs at 328dea
#3 [1e2035d8] sync_filesystem at 2c785c
#4 [1e203600] fsync_bdev at 2d4650
#5 [1e203628] invalidate_partition at 3f80c8
#6 [1e203650] del_gendisk at 3f8f5c
#7 [1e2...
2014 Jan 28
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...ystem Z code work with this?
>
> Rusty.
>
>
Sorry Rusty, I'm back as of today.
I applied your patch series and did some testing...
Removing a disk while reading from it mostly still ends up
in hangs as of below:
PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1"
#0 [163f72e0] __schedule at 6aa22c
#1 [163f7428] io_schedule at 6aab6c
#2 [163f7448] sleep_on_page at 22cbb2
#3 [163f7460] __wait_on_bit at 6ab394
#4 [163f74b0] wait_on_page_bit at 22cef4
#5 [163f7508] filemap_fdatawait_range at 22d0a6
#6 [163f75e8] filemap_write_and_wait at 2...
2014 Jan 28
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...ystem Z code work with this?
>
> Rusty.
>
>
Sorry Rusty, I'm back as of today.
I applied your patch series and did some testing...
Removing a disk while reading from it mostly still ends up
in hangs as of below:
PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1"
#0 [163f72e0] __schedule at 6aa22c
#1 [163f7428] io_schedule at 6aab6c
#2 [163f7448] sleep_on_page at 22cbb2
#3 [163f7460] __wait_on_bit at 6ab394
#4 [163f74b0] wait_on_page_bit at 22cef4
#5 [163f7508] filemap_fdatawait_range at 22d0a6
#6 [163f75e8] filemap_write_and_wait at 2...
2013 Dec 23
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...[<00000000001786fc>] kthread+0xd8/0xe0
>> [<0000000000698fee>] kernel_thread_starter+0x6/0xc
>> 2 locks held by kjournald/1984:
>>
>> ... and end up in hang situations ...
>>
>> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1"
>> #0 [1e2033e0] __schedule at 695ff2
>> #1 [1e203530] log_wait_commit at 3a28a6
>> #2 [1e2035a0] ext3_sync_fs at 328dea
>> #3 [1e2035d8] sync_filesystem at 2c785c
>> #4 [1e203600] fsync_bdev at 2d4650
>> #5 [1e203628] invalidate_partiti...
2013 Dec 23
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...[<00000000001786fc>] kthread+0xd8/0xe0
>> [<0000000000698fee>] kernel_thread_starter+0x6/0xc
>> 2 locks held by kjournald/1984:
>>
>> ... and end up in hang situations ...
>>
>> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1"
>> #0 [1e2033e0] __schedule at 695ff2
>> #1 [1e203530] log_wait_commit at 3a28a6
>> #2 [1e2035a0] ext3_sync_fs at 328dea
>> #3 [1e2035d8] sync_filesystem at 2c785c
>> #4 [1e203600] fsync_bdev at 2d4650
>> #5 [1e203628] invalidate_partiti...
2013 Dec 19
0
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...kjournald+0xfe/0x2a0
> [<00000000001786fc>] kthread+0xd8/0xe0
> [<0000000000698fee>] kernel_thread_starter+0x6/0xc
> 2 locks held by kjournald/1984:
>
> ... and end up in hang situations ...
>
> PID: 13 TASK: 1e3f8000 CPU: 0 COMMAND: "kworker/u128:1"
> #0 [1e2033e0] __schedule at 695ff2
> #1 [1e203530] log_wait_commit at 3a28a6
> #2 [1e2035a0] ext3_sync_fs at 328dea
> #3 [1e2035d8] sync_filesystem at 2c785c
> #4 [1e203600] fsync_bdev at 2d4650
> #5 [1e203628] invalidate_partition at 3f80c8
> #6 [1e2036...
2014 Jan 29
0
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...eue() doesn't exist. Your previous patch
did nothing in that path, which I suspect may leak memory. That may be
acceptable given that this Shouldn't Happen (often).
At this point, I ask Jens :)
Cheers,
Rusty.
>
> PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1"
> #0 [163f72e0] __schedule at 6aa22c
> #1 [163f7428] io_schedule at 6aab6c
> #2 [163f7448] sleep_on_page at 22cbb2
> #3 [163f7460] __wait_on_bit at 6ab394
> #4 [163f74b0] wait_on_page_bit at 22cef4
> #5 [163f7508] filemap_fdatawait_range at 22d0a6
> #6 [16...
2012 Oct 12
2
[LLVMdev] cmake+ninja build error for compiler-rt sources
...ib/ubsan/ubsan_value.h:27:18:
error: expected unqualified-id before ‘__int128’
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:35:9:
error: ‘s128’ does not name a type
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:36:9:
error: ‘u128’ does not name a type
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:148:3:
error: ‘SIntMax’ does not name a type
/local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:151:3:
error: ‘UIntMax’ does not name a type
/local/home/mahesha/s...
2014 Feb 18
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...be
> acceptable given that this Shouldn't Happen (often).
>
> At this point, I ask Jens :)
>
waiting for requests (e.g. in-flight requests) in blk_cleanup_queue() that
> Cheers,
> Rusty.
>
>>
>> PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1"
>> #0 [163f72e0] __schedule at 6aa22c
>> #1 [163f7428] io_schedule at 6aab6c
>> #2 [163f7448] sleep_on_page at 22cbb2
>> #3 [163f7460] __wait_on_bit at 6ab394
>> #4 [163f74b0] wait_on_page_bit at 22cef4
>> #5 [163f7508] filemap_fdatawait...
2014 Feb 18
2
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
...be
> acceptable given that this Shouldn't Happen (often).
>
> At this point, I ask Jens :)
>
waiting for requests (e.g. in-flight requests) in blk_cleanup_queue() that
> Cheers,
> Rusty.
>
>>
>> PID: 13 TASK: 163f8000 CPU: 0 COMMAND: "kworker/u128:1"
>> #0 [163f72e0] __schedule at 6aa22c
>> #1 [163f7428] io_schedule at 6aab6c
>> #2 [163f7448] sleep_on_page at 22cbb2
>> #3 [163f7460] __wait_on_bit at 6ab394
>> #4 [163f74b0] wait_on_page_bit at 22cef4
>> #5 [163f7508] filemap_fdatawait...
2012 Oct 13
2
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
...alified-id before ‘__int128’
> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:35:9:
> > error: ‘s128’ does not name a type
> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:36:9:
> > error: ‘u128’ does not name a type
> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:148:3:
> > error: ‘SIntMax’ does not name a type
> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:151:3:
> > error: ‘U...
2012 Oct 12
0
[LLVMdev] cmake+ninja build error for compiler-rt sources
...:18:
> error: expected unqualified-id before ‘__int128’
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:35:9:
> error: ‘s128’ does not name a type
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:36:9:
> error: ‘u128’ does not name a type
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:148:3:
> error: ‘SIntMax’ does not name a type
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:151:3:
> error: ‘UIntMax’ does not name a type
&...
2013 Dec 13
7
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th.
When an active virtio block device is hot-unplugged from a KVM guest,
affected guest user applications are not aware of any errors that occur
due to the lost device. This patch-set adds code to avoid further request
queueing when a lost block device is detected, resulting in appropriate
error info. Additionally a potential
2013 Dec 13
7
[PATCH v4 RFC 0/3] virtio: add 'device_lost' to virtio_device
Hi, here is my v4 patch-set update to the v3 RFC submitted on Nov 27th.
When an active virtio block device is hot-unplugged from a KVM guest,
affected guest user applications are not aware of any errors that occur
due to the lost device. This patch-set adds code to avoid further request
queueing when a lost block device is detected, resulting in appropriate
error info. Additionally a potential
2012 Oct 13
0
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
...gt; >
>> > /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:35:9:
>> > error: ‘s128’ does not name a type
>> >
>> > /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:36:9:
>> > error: ‘u128’ does not name a type
>> >
>> > /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:148:3:
>> > error: ‘SIntMax’ does not name a type
>> >
>> > /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_valu...
2012 Oct 13
2
[LLVMdev] [cfe-dev] cmake+ninja build error for compiler-rt sources
...ocal/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:35:9:
> >> > error: ‘s128’ does not name a type
> >> >
> >> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:36:9:
> >> > error: ‘u128’ does not name a type
> >> >
> >> >
> /local/home/mahesha/src/12th_Sep/llvm/projects/compiler-rt/lib/ubsan/ubsan_value.h:148:3:
> >> > error: ‘SIntMax’ does not name a type
> >> >
> >> >
> /local/home/mahesha/src/12th_Sep/llvm/projec...