Re: DRM Project report (week of August 10)

2020-08-17 Thread grarpamp
Thanks go to all the ongoing teams working the
things like gpgpu / compute, and graphics,
whether on-cpu-die or on-pci-card.

And even some things like BSD on Pinephone too.
https://www.pine64.org/pinephone
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


"panic: malloc(M_WAITOK) in non-sleepable context" when inserting usb stick

2020-08-17 Thread moridin
r364323, previously I think it was just a warning from witness.  Happens both 
on boot with stick already inserted, and when inserting the stick in booted 
system.

Looks like my swap partition is no longer big enough for dump, translating from 
screen:

umass0 numa-domain 0 on uhub4
umass0:2:0: Attached to scbus2
panic: malloc(M_WAITOK) in non-sleepable context

vpanic()
panic()
malloc()
disk_alloc()
daregister()
cam_periph_alloc()
daasync()
xpt_async_process_dev()
xpt_async_process()
xpt_done_process()
xpt_done_td()
fork_exit()
fork_trampoline()
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: ld: error: duplicate symbol:

2020-08-17 Thread Dimitry Andric
On 17 Aug 2020, at 15:42, O. Hartmann  wrote:
> 
> On CURRENT 9not necessarily most recent with LLVM11, but since noon of today 
> it
> is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) I'm
> faced with some very sticky and nasty micompilations in several essential
> ports, for instance
> 
> ports-mgmt/pkg
> devel/libunwind
> devel/binutils
> 
> In most cases somewhere in the (parallel) build the process fails with the 
> error
> 
> ld: error: duplicate symbol: 

This is because clang 11 (and gcc 10) now default to -fno-common. The
rationale is explained pretty well in
:

"GCC currently defaults to -fcommon.  As discussed in the PR, this is an ancient
C feature which is not conforming with the latest C standards.  On many targets
this means global variable accesses have a codesize and performance penalty.
This applies to C code only, C++ code is not affected by -fcommon.  It is about
time to change the default."

A quick fix is to add CFLAGS+=-fcommon to your make.conf, but that is
rather a big hammer. It is better to add it to just the ports that show
problems due to duplicated symbols. And ideally, those duplicated
symbols should be patched out of the ports.

For example, ports-mgmt/pkg already has such a patch:
https://github.com/freebsd/pkg/commit/7fbde60c4af4a1a07db7c5c36efbb2a495f7b1a4
but I have no idea why it is not yet in the ports tree.

-Dimitry



signature.asc
Description: Message signed with OpenPGP


Re: DRM Project report (week of August 10)

2020-08-17 Thread Jan Beich
Emmanuel Vadot  writes:

>  Hello,
>
>  5.4 was finilly reached !
>  For AMD users it means that Navi12/14, Arctarus and Renoir should work.
>  For Intel users it means that TigerLake should work too.
>
>  No ports update for now as I want to give current users a bit of time
> to update their base (as the ports needs recent addition to
> base linuxkpi) but if you have a current >= 364233 you can test
> directly the master branch of https://github.com/freebsd/drm-kmod/
>
>  I plan to commit the port update at the end of the week, and probably
> at the end of the month we will switch drm-current-kmod to 5.4.
>
>  It's now time to do 2 main things :
>  - Update stable/12 so it have all the needed code to run 5.4
>  - Remove the remaining GPLv2 code to start thinking of import into
> base.

Upstream v5.4 was tagged on 2019-11-24. Did you check linux-5.4.y (LTS)
doesn't require more LinuxKPI changes? For example, when drm-v5.0 was
the latest I've played with grafting linux-4.19.y only to discover
some commits had to be reverted due to missing LinuxKPI bits.
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: DRM Project report (week of August 10)

2020-08-17 Thread Pete Wright



On 8/17/20 1:46 AM, Emmanuel Vadot wrote:

  Hello,

  5.4 was finilly reached !
  For AMD users it means that Navi12/14, Arctarus and Renoir should work.
  For Intel users it means that TigerLake should work too.

  No ports update for now as I want to give current users a bit of time
to update their base (as the ports needs recent addition to
base linuxkpi) but if you have a current >= 364233 you can test
directly the master branch of https://github.com/freebsd/drm-kmod/

  I plan to commit the port update at the end of the week, and probably
at the end of the month we will switch drm-current-kmod to 5.4.
thanks Manu!  would it make sense to make this version available in 
graphics/drm-devel-kmod now to make it easier to test for people who 
update world/kernel more frequently?


-pete

--
Pete Wright
p...@nomadlogic.org
@nomadlogicLA

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: DRM Project report (week of August 10)

2020-08-17 Thread Emmanuel Vadot
On Mon, 17 Aug 2020 10:56:08 -0400
Ed Maste  wrote:

> On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot  wrote:
> >
> >  - Remove the remaining GPLv2 code to start thinking of import into
> > base.
> 
> How much GPLv2 code do we have left now?

~50% of what's in
https://github.com/freebsd/drm-kmod/tree/5.4-cleanup-lkpi/linuxkpi/gplv2/src

 + the includes + all the dma-buf.

 I have some dma-buf in my drmbase branch for arm that will help.

> ___
> freebsd-current@freebsd.org mailing list
> https://lists.freebsd.org/mailman/listinfo/freebsd-current
> To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


-- 
Emmanuel Vadot 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: DRM Project report (week of August 10)

2020-08-17 Thread Ed Maste
On Mon, 17 Aug 2020 at 04:46, Emmanuel Vadot  wrote:
>
>  - Remove the remaining GPLv2 code to start thinking of import into
> base.

How much GPLv2 code do we have left now?
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


ld: error: duplicate symbol:

2020-08-17 Thread O. Hartmann
On CURRENT 9not necessarily most recent with LLVM11, but since noon of today it
is FreeBSD 13.0-CURRENT #15 r364297: Mon Aug 17 14:39:06 CEST 2020 amd64) I'm
faced with some very sticky and nasty micompilations in several essential
ports, for instance

ports-mgmt/pkg
devel/libunwind
devel/binutils

In most cases somewhere in the (parallel) build the process fails with the error

ld: error: duplicate symbol: 

As a result, several ports or even the rebuild of the whole installed ports
fail to compile/recompile.

Compiling port devel/binutils, for example, fails with this error message from
linker:

[...]
cc -DHAVE_CONFIG_H -I.  -I. -I./../include -I./../elfcpp
-DLOCALEDIR="\"/usr/local/share/locale\"" -DBINDIR="\"/usr/local/bin\""
-DTOOLBINDIR="\"/usr/local/x86_64-portbld-freebsd13.0/bin\""
-DTOOLLIBDIR="\"/usr/local/x86_64-portbld-freebsd13.0/lib\""  -isystem
/usr/local/include -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow
-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -frandom-seed=mremap.o  -pthread -O2
-pipe  -fstack-protector-strong -isystem /usr/local/include
-fno-strict-aliasing  -MT mremap.o -MD -MP -MF .deps/mremap.Tpo -c -o mremap.o
mremap.c mv -f .deps/yyscript.Tpo .deps/yyscript.Po

libtool: link: cc -W -Wall
-Wstrict-prototypes -Wmissing-prototypes -Wshadow -O2 -pipe
-fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing
-fstack-protector-strong -o coffdump coffdump.o coffgrok.o bucomm.o version.o
filemode.o /usr/local/lib/libintl.so -Wl,-rpath -Wl,/usr/local/lib
../bfd/.libs/libbfd.a -L/usr/local/lib -lz ../libiberty/libiberty.a mv -f
.deps/mremap.Tpo .deps/mremap.Po

ld: error: duplicate symbol: program_name
>>> defined at coffdump.c
>>>coffdump.o:(program_name)
>>> defined at bucomm.c
>>>bucomm.o:(.bss+0x0)

What is going wrong here?

Thanks in advance

oh
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-17 Thread Alexandre Levy
For reference, below is the backtrace then further down I printed the
structures I could access :

#0  __curthread () at /usr/src/sys/amd64/include/pcpu_aux.h:55
#1  doadump (textdump=0) at /usr/src/sys/kern/kern_shutdown.c:394
#2  0x8049c26a in db_dump (dummy=,
dummy2=, dummy3=, dummy4=) at
/usr/src/sys/ddb/db_command.c:575
#3  0x8049c02c in db_command (last_cmdp=,
cmd_table=, dopager=1) at /usr/src/sys/ddb/db_command.c:482
#4  0x8049bd9d in db_command_loop () at
/usr/src/sys/ddb/db_command.c:535
#5  0x8049f048 in db_trap (type=, code=) at /usr/src/sys/ddb/db_main.c:270
#6  0x80c1b374 in kdb_trap (type=3, code=0, tf=) at
/usr/src/sys/kern/subr_kdb.c:699
#7  0x8100ca98 in trap (frame=0xfe00d7567300) at
/usr/src/sys/amd64/amd64/trap.c:576
#8  
#9  kdb_enter (why=0x811d5de0 "panic", msg=) at
/usr/src/sys/kern/subr_kdb.c:486
#10 0x80bd00be in vpanic (fmt=, ap=)
at /usr/src/sys/kern/kern_shutdown.c:902
#11 0x80bcfe53 in panic (fmt=0x81c8c7c8 
"\b\214\031\201\377\377\377\377") at /usr/src/sys/kern/kern_shutdown.c:839
#12 0x8100cee7 in trap_fatal (frame=0xfe00d7567600, eva=0) at
/usr/src/sys/amd64/amd64/trap.c:915
#13 0x8100c360 in trap (frame=0xfe00d7567600) at
/usr/src/sys/amd64/amd64/trap.c:212
#14 
#15 _rw_wowned (c=0x2659c92217d5aa52) at /usr/src/sys/kern/kern_rwlock.c:270
#16 0x80ec23ed in vm_page_busy_acquire (m=0xfe00040ff9e8,
allocflags=16) at /usr/src/sys/vm/vm_page.c:884
#17 0x82b4e980 in intel_plane_can_remap
(plane_state=0xf80315148300)
at
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/display/intel_display.c:2583
#18 0x82be1c5f in skl_ddb_get_pipe_allocation_limits (dev_priv=0x0,
cstate=0x1, total_data_rate=18446735292251509792, ddb=0xf80368501438,
alloc=0xf80315148300,
num_active=0xfe00eb0b6c58) at
/usr/ports/graphics/drm-devel-kmod/work/drm-kmod-drm_v5.3_4/drivers/gpu/drm/i915/intel_pm.c:3928
#19 0x82cb5ddf in ?? () at
/usr/src/sys/compat/linuxkpi/common/include/linux/kref.h:68 from
/boot/modules/i915kms.ko
#20 0x80ea9e8f in vm_pager_populate (object=0x2659c92217d5aa52,
pidx=18446741874754451944, fault_type=0, max_prot=0 '\000',
first=, last=)
at /usr/src/sys/vm/vm_pager.h:172
#21 vm_fault_populate (fs=) at /usr/src/sys/vm/vm_fault.c:444
#22 vm_fault_allocate (fs=) at
/usr/src/sys/vm/vm_fault.c:1028
#23 vm_fault (map=, vaddr=,
fault_type=, fault_flags=, m_hold=) at /usr/src/sys/vm/vm_fault.c:1338
#24 0x80ea98ee in vm_fault_trap (map=0xfe00c0f539e8,
vaddr=, fault_type=, fault_flags=0,
signo=0xfe00d7567ac4,
ucode=0xfe00d7567ac0) at /usr/src/sys/vm/vm_fault.c:585
#25 0x8100d0de in trap_pfault (frame=0xfe00d7567b00,
usermode=, signo=, ucode=0x81d1de80
)
at /usr/src/sys/amd64/amd64/trap.c:817
#26 0x8100c72c in trap (frame=0xfe00d7567b00) at
/usr/src/sys/amd64/amd64/trap.c:340
#27 
#28 0x00080296659a in ?? ()

(kgdb) frame 24
(kgdb) p *map
$35 = {
  header = {
left = 0xf802b72c4060,
right = 0xf803681965a0,
start = 140737488355328,
end = 4096,
next_read = 0,
max_free = 0,
object = {
  vm_object = 0x0,
  sub_map = 0x0
},
offset = 0,
eflags = 524288,
protection = 0 '\000',
max_protection = 0 '\000',
inheritance = 0 '\000',
read_ahead = 0 '\000',
wired_count = 0,
cred = 0x0,
wiring_thread = 0x0
  },
  lock = {
lock_object = {
  lo_name = 0x81183cec "vm map (user)",
  lo_flags = 36896768,
  lo_data = 0,
  lo_witness = 0xf8045f575780
},
sx_lock = 1
  },
  system_mtx = {
lock_object = {
  lo_name = 0x81136b96 "vm map (system)",
  lo_flags = 21168128,
  lo_data = 0,
  lo_witness = 0xf8045f575580
},
mtx_lock = 0
  },
  nentries = 172,
  size = 199905280,
  timestamp = 792,
  needs_wakeup = 0 '\000',
  system_map = 0 '\000',
  flags = 0 '\000',
  root = 0xf803686b1c00,
  pmap = 0xfe00c0f53b08,
  anon_loc = 34366283776,
  busy = 0
}
(kgdb) frame 15
#15 _rw_wowned (c=0x2659c92217d5aa52) at /usr/src/sys/kern/kern_rwlock.c:270
270 return (rw_wowner(rwlock2rw(c)) == curthread);
(kgdb) p/x c
$14 = 0x2659c92217d5aa52
(kgdb) up
#16 0x80ec23ed in vm_page_busy_acquire (m=0xfe00040ff9e8,
allocflags=16) at /usr/src/sys/vm/vm_page.c:884
884 locked = VM_OBJECT_WOWNED(obj);
(kgdb) p *m
$16 = {
  plinks = {
q = {
  tqe_next = 0x578491b51dd60510,
  tqe_prev = 0xd78c11bd9dde8518
},
s = {
  ss = {
sle_next = 0x578491b51dd60510
  }
},
memguard = {
  p = 6306325585301210384,
  v = 15531808720989095192
},
uma = {
  slab = 0x578491b51dd60510,
  zone = 0xd78c11bd9dde8518
}
  },
  listq = {
tqe_next = 0xd78c11bd9dde8518,
tqe_prev = 0x265bc92017d7aa38
  },
  object 

DRM Project report (week of August 10)

2020-08-17 Thread Emmanuel Vadot


 Hello,

 5.4 was finilly reached !
 For AMD users it means that Navi12/14, Arctarus and Renoir should work.
 For Intel users it means that TigerLake should work too.

 No ports update for now as I want to give current users a bit of time
to update their base (as the ports needs recent addition to
base linuxkpi) but if you have a current >= 364233 you can test
directly the master branch of https://github.com/freebsd/drm-kmod/

 I plan to commit the port update at the end of the week, and probably
at the end of the month we will switch drm-current-kmod to 5.4.

 It's now time to do 2 main things :
 - Update stable/12 so it have all the needed code to run 5.4
 - Remove the remaining GPLv2 code to start thinking of import into
base.

 I'll also start producing some usb image so people could test latest
current with 5.4 on their machine and starts reporting bug soon (this
is needed for making 5.4 default on 13-CURRENT and later 12.2).

 All this work is under sponsorship from the FreeBSD Foundation.

-- 
Emmanuel Vadot 
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Kernel crash during video transcoding

2020-08-17 Thread Hans Petter Selasky

On 2020-08-16 22:23, Alexandre Levy wrote:

(kgdb) p *m
$2 = {plinks = {q = {tqe_next = 0x578491b51dd60510, tqe_prev =
0xd78c11bd9dde8518}, s = {ss = {sle_next = 0x578491b51dd60510}}, memguard =
{p = 6306325585301210384,
   v = 15531808720989095192}, uma = {slab = 0x578491b51dd60510, zone =
0xd78c11bd9dde8518}}, listq = {tqe_next = 0xd78c11bd9dde8518, tqe_prev =
0x265bc92017d7aa38},
   object = 0x2659c92217d5aa3a, pindex = 2758957463725517354, phys_addr =
2758957463725517354, md = {pv_list = {tqh_first = 0x2e49c1321fc5a22a,
tqh_last = 0x3e4bd1300fc7b228},
 pv_gen = 265794104, pat_mode = 1046204704}, ref_count = 257405624,
busy_lock = 1054593440, a = {{flags = 4757, queue = 48 '0', act_count = 134
'\206'}, _bits = 2251297429},
   order = 98 'b', pool = 204 '\314', flags = 75 'K', oflags = 105 'i',
psind = -107 '\225', segind = 18 '\022', valid = 48 '0', dirty = 134 '\206'}


This "m" structure looks freed.

It looks like a use after free issue.

Can you enter this in GDB:

set print pretty on

Then dump some more structures you can get hold of?

--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"