Bug#913141: workaround Re: beignet: Segmentation fault while running opencv_perf_dnn

[Sander Eikelenboom]

On 18/11/18 19:49, Rebecca N. Palmer wrote:
> This appears to be a crash in a loop unrolling optimization pass 
> (enabled only when -cl-fast-relaxed-math is set, hence only crashing then).
> 
> Disabling this pass unconditionally (see attached) avoids the crash, but 
> may reduce performance.
> 

Hi Rebecca,

Just tested the patch (on top of the debian-beignet-git-repo) with llvm 7. 
The workaround works for me, in a sense everything is better than a segfault! 

So the opencv_perf_dnn test now completes (although there are still some other
opencl related errors in part with build-options, but those could very well
be opencv bugs).

Thanks for the help and patch!

--
Sander

Bug#913141: [Pkg-opencl-devel] Bug#913141: Bug#913141: beignet: Segmentation fault while running opencv_perf_dnn

[Sander Eikelenboom]

On 10/11/18 16:09, Rebecca N. Palmer wrote:
> I am able to reproduce this by just compiling (and not running) that on 
> its own (as below, with the affected source in bug913141kernel.cl). 
> Hence, no further action is needed from you.>
> Switching to LLVM 7 (after fixing the other issue you noted) didn't 
> change anything.  Removing -cl-fast-relaxed-math fixes it, but probably 
> reduces performance.
> 
> (This "kernel" is actually several almost-entirely-separate kernels of 
> which one is selected by the -D KERNEL_* option, so it isn't really 
> relevant that the first one doesn't crash.)

Hi Rebecca,

Thanks, if you need more info or testing of a patch, don't hesitate to ask!

--
Sander

Bug#913141: [Pkg-opencl-devel] Bug#913141: beignet: Segmentation fault while running opencv_perf_dnn

[Sander Eikelenboom]

On 07/11/18 23:40, Rebecca N. Palmer wrote:
> That's a crash while trying to compile something.
> 
> Is this bug present in LLVM 7?  LLVM 3.9 has just been removed, so isn't 
> an option.
> 
> Do any of the tests (/usr/lib/x86_64-linux-gnu/beignet/utest_run from 
> the beignet-dev package) also crash?
> 
> Please install libllvm6.0-dbgsym and beignet-opencl-icd-dbgsym from the 
> debug symbols archive ( 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#debug-archive
>  
> ) and run the trace again.  If possible, also get the source it is 
> trying to compile (program->source in clBuildProgram, it will probably 
> be long enough that you need to adjust gdb's print settings).
> 

Hi Rebecca,

First of all, the tests from /usr/lib/x86_64-linux-gnu/beignet/utest_run, all 
run fine. 

Here is the output of an opencv_perf_dnn run with libllvm6.0-dbgsym and 
beignet-opencl-icd-dbgsym installed.
I added some code to dump the buildflags, source etc.

The interesting part is that the first test of the same source code (same 
source hash 2cdd81c1843105011ecb613a4f6f9e26) 
compiles ok. It's the second test that crashes. The difference is in the 
buildflags.

Working:
 -D TYPE=1 -D Dtype=float -D Dtype2=float2 -D Dtype4=float4 -D Dtype8=float8 -D 
Dtype16=float16 -D as_Dtype=as_float -D as_Dtype2=as_float2 -D 
as_Dtype4=as_float4 -D as_Dtype8=as_float8 -D KERNEL_WIDTH=3 -D KERNEL_HEIGHT=3 
-D STRIDE_X=1 -D STRIDE_Y=1 -D DILATION_X=1 -D DILATION_Y=1 -D KERNEL_BASIC 
-cl-fast-relaxed-math -D 
ConvolveBasic=BASIC_k3x3_cn576_g1_s1x1_d1x1_b1_in64x48_p1x1_num1_M512_activ0_eltwise0_FP32_4_1_1_1
 -D CHANNELS=576 -D APPLY_BIAS=1 -D OUTPUT_Z=512 -D ZPAR=1 -D INTEL_DEVICE

Crashing:
 -D TYPE=1 -D Dtype=float -D Dtype2=float2 -D Dtype4=float4 -D Dtype8=float8 -D 
Dtype16=float16 -D as_Dtype=as_float -D as_Dtype2=as_float2 -D 
as_Dtype4=as_float4 -D as_Dtype8=as_float8 -D KERNEL_WIDTH=3 -D KERNEL_HEIGHT=3 
-D STRIDE_X=1 -D STRIDE_Y=1 -D DILATION_X=1 -D DILATION_Y=1 -D INPUT_PAD_W=1 -D 
INPUT_PAD_H=1 -D INPUT_PAD_RIGHT=1 -D INPUT_PAD_BOTTOM=1 -cl-fast-relaxed-math  
-D GEMM_LIKE_CONV_32_1 -D 
Conv_Interleaved=U_GEMM_LIKE_CONV_k3x3_cn576_g1_s1x1_d1x1_b1_in64x48_p1x1_num1_M512_activ0_eltwise0_FP32_5_1_8_32_SIMD8
 -cl-mad-enable -D KERNEL_GEMM_LIKE -D INPUT_DEPTH=576 -D WIDTH1=512 -D 
OUT_PADDING_LEFT=0 -D OUT_PADDING_HEIGHT=0 -D OUT_DEPTH=512 -D NUM_BATCHES=1 -D 
DY=1 -D DX=32 -D KERNEL_WIDTH_DIV2=1 -D KERNEL_SLICE_DIV2=4 -D TILE_N_LAST=0 -D 
TILE_N_LAST_DIV8=0 -D APPLY_BIAS=1 -D INTEL_DEVICE

Below is a dump from the complete run until the crash in the second test and a 
backtrace.

--
Sander


root@t440s:/mnt/scratch/src/opencv/build/bin# gdb ./opencv_perf_dnn 
GNU gdb (Debian 8.1-4+b1) 8.1
Copyright (C) 2018 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later 
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-linux-gnu".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
.
Find the GDB manual and other documentation resources online at:
.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from ./opencv_perf_dnn...(no debugging symbols found)...done.
(gdb) run
Starting program: /mnt/scratch/src/opencv/build/bin/opencv_perf_dnn 
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".
[New Thread 0x7fffe0ada700 (LWP 15404)]
[New Thread 0x7fffe02d9700 (LWP 15405)]
[New Thread 0x7fffddad7700 (LWP 15406)]
[New Thread 0x7fffdd2d6700 (LWP 15407)]
[New Thread 0x7fffdcad5700 (LWP 15408)]
[New Thread 0x7fffdc6d4700 (LWP 15409)]
[New Thread 0x7fffd5ffe700 (LWP 15410)]
Time compensation is 0
[New Thread 0x7fffd53f2700 (LWP 15448)]
[Thread 0x7fffd53f2700 (LWP 15448) exited]
CTEST_FULL_OUTPUT
OpenCV version: 4.0.0-pre
OpenCV VCS version: 4.0.0-alpha-103-ga9c8a526c-dirty
Build type: Release
Compiler: /usr/bin/c++  (ver 8.2.0)
Parallel framework: tbb
CPU features: SSE SSE2 SSE3 *SSE4.1 *SSE4.2 *FP16 *AVX *AVX2 *AVX512-SKX?
Intel(R) IPP version: ippIP AVX2 (l9) 2017.0.3 (-) Jul 29 2017
OpenCL Platforms: 
Intel Gen OCL Driver
iGPU: Intel(R) HD Graphics Haswell Ultrabook GT2 Mobile (OpenCL 1.2 
beignet 1.3)
Current OpenCL device: 
Type = iGPU
Name = Intel(R) HD Graphics Haswell Ultrabook GT2 Mobile
Version = OpenCL 1.2 beignet 1.3
Driver version = 1.3
Address bits = 32
Compute units = 20
Max work group size = 512
Local memory size = 64 KB
Max memory allocation size = 1 GB 512 MB
Double support = No
Host unified memory = Yes
Device extensions:
cl_khr_global_int32_base_atomics

Bug#913141: [Pkg-opencl-devel] Bug#913141: beignet: Segmentation fault while running opencv_perf_dnn

[Sander Eikelenboom]

On 07/11/18 23:40, Rebecca N. Palmer wrote:
> That's a crash while trying to compile something.
> 
> Is this bug present in LLVM 7?  LLVM 3.9 has just been removed, so isn't 
> an option.
> 
> Do any of the tests (/usr/lib/x86_64-linux-gnu/beignet/utest_run from 
> the beignet-dev package) also crash?
> 
> Please install libllvm6.0-dbgsym and beignet-opencl-icd-dbgsym from the 
> debug symbols archive ( 
> https://www.debian.org/releases/stable/amd64/release-notes/ch-whats-new.en.html#debug-archive
>  
> ) and run the trace again.  If possible, also get the source it is 
> trying to compile (program->source in clBuildProgram, it will probably 
> be long enough that you need to adjust gdb's print settings).
> 

Hi Rebecca,

Compiling with LLVM 7 fails for me at the moment, see below.

I will rebuild with LLVM 6 to get the beignet debug symbol packages, since they 
are not in the Debian repos for the amd64 arch:

Package beignet-dev-dbgsym
sid (unstable) (debug): debug symbols for beignet-dev
1.3.2-4 [debports]: x32

Package beignet-opencl-icd-dbgsym
sid (unstable) (debug): debug symbols for beignet-opencl-icd
1.3.2-4 [debports]: x32

Will report back with the output of llvm-6 with debug symbols and running the 
utests.

Thanks so for !

--
Sander


/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp: In 
member function ‘{anonymous}::ValuePair 
{anonymous}::ConversionState::recordForwardPHI(llvm::Value*, llvm::PHINode*, 
llvm::PHINode*, unsigned int)’:
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:230:5: 
error: ‘DEBUG’ was not declared in this scope
 DEBUG(dbgs() << "\tRecording as forward PHI\n");
 ^
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:230:5: 
note: suggested alternative: ‘IF_DEBUG’
 DEBUG(dbgs() << "\tRecording as forward PHI\n");
 ^
 IF_DEBUG
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp: In 
member function ‘void 
{anonymous}::ConversionState::recordConverted(llvm::Instruction*, const 
ValuePair&)’:
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:237:5: 
error: ‘DEBUG’ was not declared in this scope
 DEBUG(dbgs() << "\tTo:  " << *To.Lo << "\n");
 ^
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:237:5: 
note: suggested alternative: ‘IF_DEBUG’
 DEBUG(dbgs() << "\tTo:  " << *To.Lo << "\n");
 ^
 IF_DEBUG
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp: In 
member function ‘void 
{anonymous}::ConversionState::recordConverted(llvm::Instruction*, 
llvm::Value*)’:
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:247:5: 
error: ‘DEBUG’ was not declared in this scope
 DEBUG(dbgs() << "\tTo:  " << *To << "\n");
 ^
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:247:5: 
note: suggested alternative: ‘IF_DEBUG’
 DEBUG(dbgs() << "\tTo:  " << *To << "\n");
 ^
 IF_DEBUG
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp: In 
member function ‘void {anonymous}::ConversionState::patchForwardPHIs()’:
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:256:11: 
error: expected primary-expression before ‘if’
 DEBUG(if (!ForwardPHIs.empty()) dbgs() << "Patching forward PHIs:\n");
   ^~
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:256:5: 
error: ‘DEBUG’ was not declared in this scope
 DEBUG(if (!ForwardPHIs.empty()) dbgs() << "Patching forward PHIs:\n");
 ^
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:256:5: 
note: suggested alternative: ‘IF_DEBUG’
 DEBUG(if (!ForwardPHIs.empty()) dbgs() << "Patching forward PHIs:\n");
 ^
 IF_DEBUG
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp: In 
function ‘void convertInstruction(llvm::Instruction*, 
{anonymous}::ConversionState&, const llvm::DataLayout&)’:
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:389:3: 
error: ‘DEBUG’ was not declared in this scope
   DEBUG(dbgs() << "Expanding Large Integer: " << *Inst << "\n");
   ^
/mnt/scratch/src/beignet-1.3.2/backend/src/llvm/ExpandLargeIntegers.cpp:389:3: 
note: suggested alternative: ‘IF_DEBUG’
   DEBUG(dbgs() << "Expanding Large Integer: " << *Inst << "\n");

Bug#890817: Ping ?

[Sander Eikelenboom]

L.S.,
A little ping since 3 weeks have passed by, without any response so far.

It would be helpful to respond and join the discussion on LKML,
so a consensus could be reached about if reverting the offending kernel patch 
or a change to make-kpkg script is the best solution , before the 4.16 kernel 
is released.

If you don't have the time to look into the problem or do not maintain the 
package anymore
that is fine too, but please indicate this, so some progression in the 
discussion can be made.
 
--
Sander

Bug#890817: kernel-package: make-kpkg stalls indefinitely on linux-4.16-rc* in silentoldconfig stage

[Sander Eikelenboom]

Package: kernel-package
Version: 13.018+nmu1
Severity: important

L.S.,

make-kpkg currently stalls indefinitely on linux-4.16-rc* in the 
silentoldconfig stage
(somewhere before asking the kconfig questions which are new).

I have bisected it and that leads to linux kernel commit
d2a04648a5dbc3d1d043b35257364f0197d4d868 "kconfig: remove check_stdin()".

I also reported this upstream on LKML, see thread:
http://lkml.iu.edu/hypermail/linux/kernel/1802.1/03207.html
but the package maintainers answers are awaited for by the kernel developers,
so please chime in on LKML to work out a fix in either the kernel or make-kpkg.

--
Sander


-- System Information:
Debian Release: buster/sid
  APT prefers testing
  APT policy: (900, 'testing')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 4.16.0-rc2-t440s-20180219 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8), 
LANGUAGE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages kernel-package depends on:
ii  bc   1.07.1-1
ii  binutils 2.30-4
ii  build-essential  12.4
ii  bzip21.0.6-8.1
ii  dpkg-dev 1.19.0.5
ii  file 1:5.32-1
ii  gettext  0.19.8.1-4
ii  kmod 25-1
ii  po-debconf   1.0.20
ii  xmlto0.0.28-2
ii  xz-utils [lzma]  5.2.2-1.3

Versions of packages kernel-package recommends:
ii  cpio   2.12+dfsg-6
ii  docbook-utils  0.6.14-3.3
ii  kernel-common  13.018+nmu1
pn  uboot-mkimage  

Versions of packages kernel-package suggests:
ii  libncurses5-dev [libncurses-dev]  6.0+20171125-1
pn  linux-source  

-- Configuration Files:
/etc/kernel-pkg.conf changed [not included]

-- no debconf information

Bug#804079: [Xen-devel] Kernel panic on Xen virtualisation in Debian

[Sander Eikelenboom]

Thursday, December 1, 2016, 2:59:36 PM, you wrote:

> On 01.12.2016 14:26, Wei Liu wrote:

>> This is still the same kernel log that was sent some time ago.
>> So, if you have built Xen with debug=y, could you try to set Xen log
>> level to the highest and capture "xl dmesg" when guest crashes?

> It's not the guest that crashes, it's dom0. So when the host crashes, 
> I'm not able to issue any commands anymore.

>> But I think this is increasingly likely to be a Linux kernel issue
>> because you've tried multiple versions of xen. Maybe it is time to try
>> different versions of Dom0 kernels (sorry if you've tried that, I can't
>> remember all the details over so many moons).

> Yes, indeed I have tried different kernels, but I can't remember details 
> as well... ;/


Hi Ingo,

Have you tried without enabling "ndisc" (QoS) and "ipv6" ?
They are both present in your log and i assume you are using a bridged network 
config ?
You wouldn't be the first to stumble over a more generic kernel network bug
while using Xen, due to less well tested combinations.
So it's worth testing if plain ipv4 and no QoS works.

--
Sander
 

Bug#843344: (no subject)

[Sander Eikelenboom]

I just updated my debian testing install and now also have a segfaulting 
pgadmin3 on startup:


[ 9125.914711] pgadmin3[17628]: segfault at 0 ip 55f397b6dda4 sp 
7ffdd201b3f0 error 4 in pgadmin3[55f3978ef000+b22000]
[ 9144.217358] pgadmin3[17673]: segfault at 0 ip 560f215c3da4 sp 
7ffe486b4650 error 4 in pgadmin3[560f21345000+b22000]
[12887.867480] pgadmin3[18415]: segfault at 0 ip 5632842ecda4 sp 
7ffc1e2df250 error 4 in pgadmin3[56328406e000+b22000]
[12899.781335] pgadmin3[18460]: segfault at 0 ip 56383a3c5da4 sp 
7fff8edca250 error 4 in pgadmin3[56383a147000+b22000]
[13148.994953] pgadmin3[18978]: segfault at 0 ip 557b9c7c7da4 sp 
7ffce7be9ff0 error 4 in pgadmin3[557b9c549000+b22000]


These are just normal Debian binary packages.
Hopefully it is resolved soon.

--
Sander Eikelenboom


Package: pgadmin3
Version: 1.22.1-2
Severity: normal

-- System Information:
Debian Release: stretch/sid
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: amd64 (x86_64)

Kernel: Linux 4.8.5-x220-20161028 (SMP w/4 CPU cores)
Locale: LANG=en_US.utf8, LC_CTYPE=en_US.utf8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: sysvinit (via /sbin/init)

Versions of packages pgadmin3 depends on:
ii  libc6 2.24-5
ii  libgcc1   1:6.2.0-10
ii  libpq59.6.1-2.pgdg80+1
ii  libssl1.0.2   1.0.2j-1
ii  libstdc++66.2.0-10
ii  libwxbase3.0-0v5  3.0.2+dfsg-2
ii  libwxgtk3.0-0v5   3.0.2+dfsg-2
ii  libxml2   2.9.4+dfsg1-2.1
ii  libxslt1.11.1.29-2
ii  pgadmin3-data 1.22.1-2
ii  zlib1g1:1.2.8.dfsg-2+b3

Versions of packages pgadmin3 recommends:
ii  pgagent3.4.1-3
ii  postgresql-client-9.6 [postgresql-client]  9.6.1-2.pgdg80+1

Versions of packages pgadmin3 suggests:
pn  postgresql-contrib  

-- no debconf information

Bug#788219: libclc: Request to package kernels for radeon card with 'amdgcn' codename.

[Sander Eikelenboom]

Source: libclc
Severity: wishlist

Dear Maintainer,

At present the Debian libclc package only packages kernels for AMD radeon cards 
with the 'r600' codename,
but newer radeon cards use the 'amdgcn' codename instead (for example for 
Radeon 7950 codename tahiti).
So probably a seperate package libclc-amdgcn should be created (or the 
libclc-r600 should be generalized to libclc-amd).

--
Regards,

Sander

-- System Information:
Debian Release: 8.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)

Kernel: Linux 4.1.0-rc7-20150609-linus+ (SMP w/6 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/bash
Init: sysvinit (via /sbin/init)


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#640789: Bug still not fixed in hd-media installation media (wheezy, jessie and sid)

[Sander Eikelenboom]

Hi,

I just stumbled over this bug as it is still not fixed in the hd-media 
initrd.gz.

I have tried wheezy, jessie and sid, manually patching initrd.gz (with the 
patch 
mentioned by Chris Tillman) made everything working again.

I suppose a lot of users can hit this bug, since a space in any path on any 
mountable
FS will cause this bug to trigger on installation and the error and error 
message
are rather cryptic.

Since the fix is already known for quite some time, limited in scope and very 
obviously correct, *please* fix this ASAP in all the installation media, this
could very well hinder Debian adoption since installation fails early for no 
apparent 
reason. 

Thanks,

Sander


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#628991: Bug still not fixed in hd-media installation media (wheezy, jessie and sid)

[Sander Eikelenboom]

Hi,

I just stumbled over this bug as it is still not fixed in the hd-media 
initrd.gz.

I have tried wheezy, jessie and sid, manually patching initrd.gz (with the 
patch 
mentioned by Chris Tillman) made everything working again.

I suppose a lot of users can hit this bug, since a space in any path on any 
mountable
FS will cause this bug to trigger on installation and the error and error 
message
are rather cryptic.

Since the fix is already known for quite some time, limited in scope and very 
obviously correct, *please* fix this ASAP in all the installation media, this
could very well hinder Debian adoption since installation fails early for no 
apparent 
reason. 

Thanks,

Sander


-- 
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org