atomic changes break drm-next-kmod?

[Hans Petter Selasky]

On 07/05/18 20:59, Hans Petter Selasky wrote:
> On 07/05/18 19:48, Pete Wright wrote:
>>
>>
>> On 07/05/2018 10:10, John Baldwin wrote:
>>> On 7/3/18 5:10 PM, Pete Wright wrote:
>>>>
>>>> On 07/03/2018 15:56, John Baldwin wrote:
>>>>> On 7/3/18 3:34 PM, Pete Wright wrote:
>>>>>> On 07/03/2018 15:29, John Baldwin wrote:
>>>>>>> That seems like kgdb is looking at the wrong CPU.  Can you use
>>>>>>> 'info threads' and look for threads not stopped in 'sched_switch'
>>>>>>> and get their backtraces?  You could also just do 'thread apply
>>>>>>> all bt' and put that file at a URL if that is easiest.
>>>>>>>
>>>>>> sure thing John - here's a gist of "thread apply all bt"
>>>>>>
>>>>>> https://gist.github.com/gem-pete/d8d7ab220dc8781f0827f965f09d43ed
>>>>> That doesn't look right at all.  Are you sure the kernel matches the
>>>>> vmcore?  Also, which kgdb version are you using?
>>>>>
>>>> yea i agree that doesn't look right at all.  here is my setup:
>>>>
>>>> $ which kgdb
>>>> /usr/bin/kgdb
>>>> $ kgdb
>>>> GNU gdb 6.1.1 [FreeBSD]
>>>> $ ls -lh /var/crash/vmcore.1
>>>> -rw-------  1 root  wheel   1.6G Jul  3 15:03 /var/crash/vmcore.1
>>>> $ ls -l /usr/lib/debug/boot/kernel/kernel.debug
>>>> -r-xr-xr-x  1 root  wheel  87840496 Jul  3 13:54
>>>> /usr/lib/debug/boot/kernel/kernel.debug
>>>>
>>>> and i invoke kgdb like so:
>>>> $ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
>>>>
>>>> here's a gist of my full gdb session:
>>>> http://termbin.com/krsn
>>>>
>>>> dunno - maybe i have a bad core dump?  regardless, more than happy to
>>>> help so let me know if i should try anything else or patches etc..
>>> Can you try installing gdb from ports and using /usr/local/bin/kgdb?
>>>
>>
>> that seems to have done the trick, at least the output looks more 
>> encouraging.
>>
>>   --- trap 0, rip = 0, rsp = 0, rbp = 0 ---
>> KDB: enter: panic
>>
>> __curthread () at ./machine/pcpu.h:231
>> 231        __asm("movq %%gs:%1,%0" : "=r" (td)
>>
>>
>> here's my full kgdb session:
>> http://termbin.com/qa4f
>>
>> i don't see any threads not in "sched_switch" though :(
> 
> Hi,
> 
> The problem may be that the patch to enable atomic inlining of all 
> macros forgot to set the SMP keyword which means SMP is not defined at 
> all for KLD's so all non-kernel atomic usage is with MPLOCKED empty!
> 
> /*
>   * For userland, always use lock prefixes so that the binaries will run
>   * on both SMP and !SMP systems.
>   */
> #if defined(SMP) || !defined(_KERNEL)
> #define MPLOCKED        "lock ; "
> #else
> #define MPLOCKED
> #endif
> 
> Can you try to recompile the LinuxKPI /sys/modules/linuxkpi with 
> DEBUG_FLAGS="-DSMP" ?
> 
> and similarly the drm-next package?
> 

Also please find attached a patch for amd64.

--HPS

-------------- next part --------------
A non-text attachment was scrubbed...
Name: atomic.h.diff
Type: text/x-patch
Size: 656 bytes
Desc: not available
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20180705/43503a8b/attachment.bin>