Re: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/06/2018 03:15, Hans Petter Selasky wrote:

On 07/06/18 11:14, Johannes Lundberg wrote:

On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:


On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin mailto:j...@freebsd.org>> wrote:

 On 7/5/18 12:36 PM, Konstantin Belousov wrote:
  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky

wrote:

  >> 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!
  > Problem is that out-of-tree modules build does not have 
opt*.h

files

  > from the kernel.  UP config is a valid one, flipping some

option's

  > default value does not solve the problem.

 Yes, but using the lock prefix in a generic module is ok (it 
will

still
 work, just not quite as fast) whereas the lack of lock is 
fatal on
 SMP.  I would amend Hans' patch slightly to honor the opt_* 
setting

 for KLD_TIED (but that is only true if KLD_TIED means "built as

part of

 a kernel build, so has valid opt_foo.h headers" and not
 'a standalone module where someone put MODULES_TIED=1 on the

command

 line
 to make').


I agree with this default. It's sensible to default to (a) the most
popular thing and (b) thing that always works, especially when (a) 
and

(b) are identical.

Don't make me start the "Do we really need an SMP option, why not 
make

it always on" thread :) The number of relevant uniprocessor x86 boxes
that benefit from omitting SMP is so small as to be irrelevant, IMHO.

A

MP kernel runs just fine on them...

Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which 
means 4

days of all modern FreeBSD desktop systems being broken, and possibly
other systems with kernel modules from ports as well.


Another question, how hard would it be to expose how the kernel was
built to modules built from ports, so that they can figure out stuff
like SMP and others, that might affect the module build?

Point the KERNBUILDDIR 

Re: atomic changes break drm-next-kmod?

[Hans Petter Selasky]

On 07/06/18 11:14, Johannes Lundberg wrote:

On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:


On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin mailto:j...@freebsd.org>> wrote:

 On 7/5/18 12:36 PM, Konstantin Belousov wrote:
  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky

wrote:

  >> 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!
  > Problem is that out-of-tree modules build does not have opt*.h

files

  > from the kernel.  UP config is a valid one, flipping some

option's

  > default value does not solve the problem.

 Yes, but using the lock prefix in a generic module is ok (it will

still

 work, just not quite as fast) whereas the lack of lock is fatal on
 SMP.  I would amend Hans' patch slightly to honor the opt_* setting
 for KLD_TIED (but that is only true if KLD_TIED means "built as

part of

 a kernel build, so has valid opt_foo.h headers" and not
 'a standalone module where someone put MODULES_TIED=1 on the

command

 line
 to make').


I agree with this default. It's sensible to default to (a) the most
popular thing and (b) thing that always works, especially when (a) and
(b) are identical.

Don't make me start the "Do we really need an SMP option, why not make
it always on" thread :) The number of relevant uniprocessor x86 boxes
that benefit from omitting SMP is so small as to be irrelevant, IMHO.

A

MP kernel runs just fine on them...

Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which means 4
days of all modern FreeBSD desktop systems being broken, and possibly
other systems with kernel modules from ports as well.


Another question, how hard would it be to expose how the kernel was
built to modules built from ports, so that they can figure out stuff
like SMP and others, that might affect the module build?

Point the KERNBUILDDIR variable to the directory of the kernel build.
This is the 

Re: atomic changes break drm-next-kmod?

[Johannes Lundberg]

On Fri, Jul 6, 2018 at 9:49 AM Konstantin Belousov 
wrote:

> On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
> > On 07/06/18 00:02, Warner Losh wrote:
> > >
> > >
> > > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  > > > wrote:
> > >
> > > On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> > >  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky
> wrote:
> > >  >> 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!
> > >  > Problem is that out-of-tree modules build does not have opt*.h
> files
> > >  > from the kernel.  UP config is a valid one, flipping some
> option's
> > >  > default value does not solve the problem.
> > >
> > > Yes, but using the lock prefix in a generic module is ok (it will
> still
> > > work, just not quite as fast) whereas the lack of lock is fatal on
> > > SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> > > for KLD_TIED (but that is only true if KLD_TIED means "built as
> part of
> > > a kernel build, so has valid opt_foo.h headers" and not
> > > 'a standalone module where someone put MODULES_TIED=1 on the
> command
> > > line
> > > to make').
> > >
> > >
> > > I agree with this default. It's sensible to default to (a) the most
> > > popular thing and (b) thing that always works, especially when (a) and
> > > (b) are identical.
> > >
> > > Don't make me start the "Do we really need an SMP option, why not make
> > > it always on" thread :) The number of relevant uniprocessor x86 boxes
> > > that benefit from omitting SMP is so small as to be irrelevant, IMHO.
> A
> > > MP kernel runs just fine on them...
> > >
> > > 

Re: atomic changes break drm-next-kmod?

[Konstantin Belousov]

On Fri, Jul 06, 2018 at 09:52:24AM +0200, Niclas Zeising wrote:
> On 07/06/18 00:02, Warner Losh wrote:
> > 
> > 
> > On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  > > wrote:
> > 
> > On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> >  > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> >  >> 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!
> >  > Problem is that out-of-tree modules build does not have opt*.h files
> >  > from the kernel.  UP config is a valid one, flipping some option's
> >  > default value does not solve the problem.
> > 
> > Yes, but using the lock prefix in a generic module is ok (it will still
> > work, just not quite as fast) whereas the lack of lock is fatal on
> > SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> > for KLD_TIED (but that is only true if KLD_TIED means "built as part of
> > a kernel build, so has valid opt_foo.h headers" and not
> > 'a standalone module where someone put MODULES_TIED=1 on the command
> > line
> > to make').
> > 
> > 
> > I agree with this default. It's sensible to default to (a) the most 
> > popular thing and (b) thing that always works, especially when (a) and 
> > (b) are identical.
> > 
> > Don't make me start the "Do we really need an SMP option, why not make 
> > it always on" thread :) The number of relevant uniprocessor x86 boxes 
> > that benefit from omitting SMP is so small as to be irrelevant, IMHO. A 
> > MP kernel runs just fine on them...
> > 
> > Warner
> 
> Where are we on this?
> It is important to get it fixed, it's already been 4 days, which means 4 
> days of all modern FreeBSD desktop systems being broken, and possibly 
> other systems with kernel modules from ports as well.
> 
> 
> Another question, how hard would it be to expose 

Re: atomic changes break drm-next-kmod?

[Niclas Zeising]

On 07/06/18 00:02, Warner Losh wrote:



On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin > wrote:


On 7/5/18 12:36 PM, Konstantin Belousov wrote:
 > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
 >> 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!
 > Problem is that out-of-tree modules build does not have opt*.h files
 > from the kernel.  UP config is a valid one, flipping some option's
 > default value does not solve the problem.

Yes, but using the lock prefix in a generic module is ok (it will still
work, just not quite as fast) whereas the lack of lock is fatal on
SMP.  I would amend Hans' patch slightly to honor the opt_* setting
for KLD_TIED (but that is only true if KLD_TIED means "built as part of
a kernel build, so has valid opt_foo.h headers" and not
'a standalone module where someone put MODULES_TIED=1 on the command
line
to make').


I agree with this default. It's sensible to default to (a) the most 
popular thing and (b) thing that always works, especially when (a) and 
(b) are identical.


Don't make me start the "Do we really need an SMP option, why not make 
it always on" thread :) The number of relevant uniprocessor x86 boxes 
that benefit from omitting SMP is so small as to be irrelevant, IMHO. A 
MP kernel runs just fine on them...


Warner


Where are we on this?
It is important to get it fixed, it's already been 4 days, which means 4 
days of all modern FreeBSD desktop systems being broken, and possibly 
other systems with kernel modules from ports as well.



Another question, how hard would it be to expose how the kernel was 
built to modules built from ports, so that they can figure out stuff 
like SMP and others, that might affect the module build?


Regards
--
Niclas
___
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: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/05/2018 12:12, Hans Petter Selasky wrote:

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.



i have been running this patch for about 4hours.  previous uptime before 
this patch was under 1hr.  i've attached and detached HDMI displays and 
gone through several suspend/resume cycles as well without any issues.


to be clear - since i'm not sure this is was your intent - i applied the 
patch, rebuilt/installed a new kernel.  i did *not* use the "-DSMP" 
flags for linuxkpi or the drm-next module.


cheers,
-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: atomic changes break drm-next-kmod?

[Warner Losh]

On Thu, Jul 5, 2018 at 1:44 PM, John Baldwin  wrote:

> On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> > On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> >> 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!
> > Problem is that out-of-tree modules build does not have opt*.h files
> > from the kernel.  UP config is a valid one, flipping some option's
> > default value does not solve the problem.
>
> Yes, but using the lock prefix in a generic module is ok (it will still
> work, just not quite as fast) whereas the lack of lock is fatal on
> SMP.  I would amend Hans' patch slightly to honor the opt_* setting
> for KLD_TIED (but that is only true if KLD_TIED means "built as part of
> a kernel build, so has valid opt_foo.h headers" and not
> 'a standalone module where someone put MODULES_TIED=1 on the command line
> to make').
>

I agree with this default. It's sensible to default to (a) the most popular
thing and (b) thing that always works, especially when (a) and (b) are
identical.

Don't make me start the "Do we really need an SMP option, why not make it
always on" thread :) The number of relevant uniprocessor x86 boxes that
benefit from omitting SMP is so small as to be irrelevant, IMHO. A MP
kernel runs just fine on them...

Warner
___
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: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/5/18 12:36 PM, Konstantin Belousov wrote:
> On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
>> 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!
> Problem is that out-of-tree modules build does not have opt*.h files
> from the kernel.  UP config is a valid one, flipping some option's
> default value does not solve the problem.

Yes, but using the lock prefix in a generic module is ok (it will still
work, just not quite as fast) whereas the lack of lock is fatal on 
SMP.  I would amend Hans' patch slightly to honor the opt_* setting
for KLD_TIED (but that is only true if KLD_TIED means "built as part of
a kernel build, so has valid opt_foo.h headers" and not
'a standalone module where someone put MODULES_TIED=1 on the command line
to make').

-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[Konstantin Belousov]

On Thu, Jul 05, 2018 at 09:12:24PM +0200, Hans Petter Selasky wrote:
> 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!
Problem is that out-of-tree modules build does not have opt*.h files
from the kernel.  UP config is a valid one, flipping some option's
default value does not solve the problem.

The build invocation for such modules needs to provide KERNBUILDDIR
variable pointing to the kernel build directory, where all opt*.h files
are located.

> > 
> > /*
> >   * 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
> 

> Index: sys/amd64/include/atomic.h
> ===
> --- sys/amd64/include/atomic.h(revision 335974)
> +++ sys/amd64/include/atomic.h(working copy)
> @@ -132,7 +132,7 @@
>   * For userland, always use lock prefixes so that the binaries will run
>   * on both SMP and !SMP systems.
>   */
> -#if defined(SMP) || !defined(_KERNEL)
> +#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
>  #define  MPLOCKED"lock ; "
>  #else
>  #define  MPLOCKED
> @@ -354,7 +354,7 @@
>   */
>  #define  OFFSETOF_MONITORBUF 0x100
>  
> -#if defined(SMP)
> +#if defined(SMP) || defined(KLD_MODULE)
>  static __inline void
>  __storeload_barrier(void)
>  {

> ___
> 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"

___
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: 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

Index: sys/amd64/include/atomic.h
===
--- sys/amd64/include/atomic.h	(revision 335974)
+++ sys/amd64/include/atomic.h	(working copy)
@@ -132,7 +132,7 @@
  * For userland, always use lock prefixes so that the binaries will run
  * on both SMP and !SMP systems.
  */
-#if defined(SMP) || !defined(_KERNEL)
+#if defined(SMP) || !defined(_KERNEL) || defined(KLD_MODULE)
 #define	MPLOCKED	"lock ; "
 #else
 #define	MPLOCKED
@@ -354,7 +354,7 @@
  */
 #define	OFFSETOF_MONITORBUF	0x100
 
-#if defined(SMP)
+#if defined(SMP) || defined(KLD_MODULE)
 static __inline void
 __storeload_barrier(void)
 {
___
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: atomic changes break drm-next-kmod?

[Hans Petter Selasky]

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?

--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"

Re: atomic changes break drm-next-kmod?

[Pete Wright]

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 :(

-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: atomic changes break drm-next-kmod?

[John Baldwin]

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?

-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[Cy Schubert]

In message <20180703170223.266db...@thor.intern.walstatt.dynvpn.de>, 
"O. Hartma
nn" writes:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> Am Tue, 3 Jul 2018 10:19:57 -0400
> Michael Butler  schrieb:
>
> > It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
> > 
> > --- i915_drv.o ---
> > In file included from i915_drv.c:30:
> > In file included from
> > /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/inclu
> de/linux/acpi.h:26:
> > In file included from
> > /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/inclu
> de/linux/device.h:4:
> > In file included from
> > /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
> > In file included from
> > /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
> > In file included from /usr/src/sys/sys/systm.h:44:
> > ./machine/atomic.h:450:29: error: invalid operand for instruction
> > ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
> > ^
> > :1:7: note: instantiated into assembly here
> > andq $9223372036854775807,40672(%r14)
> >  ^
> > 1 error generated.
> > *** [i915_drv.o] Error code 1
> > 
> > make[3]: stopped in
> > /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
> > --- i915_gem.o ---
> > In file included from i915_gem.c:28:
> > In file included from
> > /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:3
> 8:
> > In file included from /usr/src/sys/sys/malloc.h:42:
> > In file included from /usr/src/sys/sys/systm.h:44:
> > ./machine/atomic.h:449:29: error: invalid operand for instruction
> > ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
> > ^
> > :1:6: note: instantiated into assembly here
> > orq $-9223372036854775808,40672(%r14)
> > ^~
> > 1 error generated.
> > *** [i915_gem.o] Error code 1
> > 
> > ___
> > 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"
>
>
> It breaks also graphics/drm-stable-kmod (see PR 229484,
> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you d
> escribed
> above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is
>  < r335873,
> those kmod compile well.

The virtualbox-ose-kmod issue is different. It's namespace pollution 
caused by the inclusion of sys/param.h in sys/systm.h when _KERNEL is 
defined. sys/param.h includes sys/priority.h if LOCORE is not defined. 
virtualbox typedefs PVM as a struct whereas sys/priority.h defines it 
as a constant. Virtualbox undefines PVM in some headers, usually after 
including sys/param.h. I haven't looked at it further than this with 
the limited time I have tonight but I suspect one of the #undef PVM 
statements needs to move.

> - -- 
> O. Hartmann
>
> Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
> Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
> -BEGIN PGP SIGNATURE-
>
> iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWzuQGgAKCRDS528fyFhY
> lKHnAf0fIVHnw1xBVHzogeQQo4v+he17R2ln6l25lNR/pUE1AZOsFzPDamAkqbY+
> f1+Usr+P5o7jn26Bh4ob3UmIj25DAf4tJZpeZS4iGZ374lrCAemYFb53+MJ1fClW
> aBLI6DVOiBiOt/UpLXZf1whl/dtQvo5yd1xywfYOwi9Jh8teHcNW
> =mtMH
> -END PGP SIGNATURE-
> ___
> 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"
>


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: atomic changes break drm-next-kmod?

[Cy Schubert]

In message , Niclas 
Zeising w
rites:
> On 07/03/18 17:02, O. Hartmann wrote:
> > -BEGIN PGP SIGNED MESSAGE-
> > Hash: SHA512
> > 
> > Am Tue, 3 Jul 2018 10:19:57 -0400
> > Michael Butler  schrieb:
> > 
> >> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
> >>
> >> --- i915_drv.o ---
> >> In file included from i915_drv.c:30:
> >> In file included from
> >> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/incl
> ude/linux/acpi.h:26:
> >> In file included from
> >> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/incl
> ude/linux/device.h:4:
> >> In file included from
> >> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
> >> In file included from
> >> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
> >> In file included from /usr/src/sys/sys/systm.h:44:
> >> ./machine/atomic.h:450:29: error: invalid operand for instruction
> >> ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
> >>  ^
> >> :1:7: note: instantiated into assembly here
> >>  andq $9223372036854775807,40672(%r14)
> >>   ^
> >> 1 error generated.
> >> *** [i915_drv.o] Error code 1
> >>
> >> make[3]: stopped in
> >> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
> >> --- i915_gem.o ---
> >> In file included from i915_gem.c:28:
> >> In file included from
> >> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:
> 38:
> >> In file included from /usr/src/sys/sys/malloc.h:42:
> >> In file included from /usr/src/sys/sys/systm.h:44:
> >> ./machine/atomic.h:449:29: error: invalid operand for instruction
> >> ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
> >>  ^
> >> :1:6: note: instantiated into assembly here
> >>  orq $-9223372036854775808,40672(%r14)
> >>  ^~
> >> 1 error generated.
> >> *** [i915_gem.o] Error code 1
> >>
> >> ___
> >> 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"
> > 
> > 
> > It breaks also graphics/drm-stable-kmod (see PR 229484,
> > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you
>  described
> > above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision 
> is < r335873,
> > those kmod compile well.

The vbox issue looks like namespace pollution.


-- 
Cheers,
Cy Schubert 
FreeBSD UNIX: Web:  http://www.FreeBSD.org

The need of the many outweighs the greed of the few.


___
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: atomic changes break drm-next-kmod?

[Pete Wright]

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..


-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: atomic changes break drm-next-kmod?

[Matthew Macy]

This seems like a clang inline asm bug. Could you try building the port
with a recent gcc against an unpatched HEAD?

On Tue, Jul 3, 2018 at 15:38 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
>
> cheers!
> -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"
>
___
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: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/3/18 3:40 PM, Matthew Macy wrote:
> This seems like a clang inline asm bug. Could you try building the port with 
> a recent gcc against an unpatched HEAD?

I've already committed the patch to HEAD, but using 'e' is from the GCC docs, 
not clang docs:

https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints

The disassembly of one of the functions from the kmod using one of the affected 
atomic ops would
show if it is working correctly (there should now be a mov with a 64-bit 
immediate into a register
followed by the atomic op using a register operand).  You could also try using 
just 'r' to always
force the use of a register.  It would be less optimal than "er" but should 
function correctly.

> On Tue, Jul 3, 2018 at 15:38 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
> 
> cheers!
> -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 
> "
> 


-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[John Baldwin]

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?

-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[Pete Wright]

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

cheers!
-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: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/3/18 3:20 PM, Pete Wright wrote:
> 
> 
> On 07/03/2018 15:12, Pete Wright wrote:
>>
>>
>> On 07/03/2018 14:17, Pete Wright wrote:
>>>
>>>
>>> On 07/03/2018 12:02, John Baldwin wrote:
 On 7/3/18 11:28 AM, Niclas Zeising wrote:
> On 07/03/18 17:02, O. Hartmann wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Am Tue, 3 Jul 2018 10:19:57 -0400
>> Michael Butler  schrieb:
>>
>>> It seems recent changes (SVN r335873?) may have broken 
>>> drm-next-kmod ..
>>>
>>> --- i915_drv.o ---
>>> In file included from i915_drv.c:30:
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
>>>  
>>>
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
>>>  
>>>
>>> In file included from
>>> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
>>> In file included from
>>> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
>>> In file included from /usr/src/sys/sys/systm.h:44:
>>> ./machine/atomic.h:450:29: error: invalid operand for instruction
>>> ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
>>>   ^
>>> :1:7: note: instantiated into assembly here
>>>   andq $9223372036854775807,40672(%r14)
>>>    ^
>>> 1 error generated.
>>> *** [i915_drv.o] Error code 1
>>>
>>> make[3]: stopped in
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
>>> --- i915_gem.o ---
>>> In file included from i915_gem.c:28:
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
>>>  
>>>
>>> In file included from /usr/src/sys/sys/malloc.h:42:
>>> In file included from /usr/src/sys/sys/systm.h:44:
>>> ./machine/atomic.h:449:29: error: invalid operand for instruction
>>> ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
>>>   ^
>>> :1:6: note: instantiated into assembly here
>>>   orq $-9223372036854775808,40672(%r14)
>>>   ^~
>>> 1 error generated.
>>> *** [i915_gem.o] Error code 1
>>>
>>> ___
>>> 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"
>>
>> It breaks also graphics/drm-stable-kmod (see PR 229484,
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same 
>> error as you described
>> above) and also emulators/virtualbox-ose-kmod. As long as CURRENT 
>> revision is < r335873,
>> those kmod compile well.
> We are looking into why both the drm ports fail.
> Regards
>
 I haven't yet tested an amd64 kernel with this, but I think this 
 change to sys/amd64/include/atomic.h
 might fix it:

 Index: atomic.h
 ===
 --- atomic.h    (revision 335896)
 +++ atomic.h    (working copy)
 @@ -446,10 +446,10 @@ ATOMIC_ASM(clear,    int,   "andl %1,%0", "ir", ~
   ATOMIC_ASM(add, int,   "addl %1,%0",  "ir",  v);
   ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
   -ATOMIC_ASM(set, long,  "orq %1,%0",   "ir",  v);
 -ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
 -ATOMIC_ASM(add, long,  "addq %1,%0",  "ir",  v);
 -ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
 +ATOMIC_ASM(set, long,  "orq %1,%0",   "er",  v);
 +ATOMIC_ASM(clear,    long,  "andq %1,%0",  "er", ~v);
 +ATOMIC_ASM(add, long,  "addq %1,%0",  "er",  v);
 +ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
     #define    ATOMIC_LOADSTORE(TYPE)    \
   ATOMIC_LOAD(TYPE);    \


>>>
>>> i've just built a kernel with this patch applied, rebooted into it 
>>> and was able to build the drm-next-kmod port.  i am also running X 
>>> without issues so far with this configuration.
>>>
>>
>>
>> oh neat - looks like this may have triggered a kernel panic. 
>> fortunately i was able to savecore.  here's the output of my info file:
>>
>> info:
>>   Version String: FreeBSD 12.0-CURRENT #7 d7ac1268f3a(master)-dirty: 
>> Tue Jul  3 13:53:50 PDT 2018
>> pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV 
>>
>>   Panic String: Duplicate free of 0xf8010ac59000 from zone 
>> 0xf800340935a0(i915_gem_request) slab 0xf8010ac43af0(0)
>>
>> i didn't build a kernel.debug file unfortunately, but here's the 
>> output of my core.txt file, not sure how helpful it is:
> 
> darn, hit send too 

Re: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/03/2018 15:12, Pete Wright wrote:



On 07/03/2018 14:17, Pete Wright wrote:



On 07/03/2018 12:02, John Baldwin wrote:

On 7/3/18 11:28 AM, Niclas Zeising wrote:

On 07/03/18 17:02, O. Hartmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:

It seems recent changes (SVN r335873?) may have broken 
drm-next-kmod ..


--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26: 


In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4: 


In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
  ^
:1:7: note: instantiated into assembly here
  andq $9223372036854775807,40672(%r14)
   ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38: 


In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
  ^
:1:6: note: instantiated into assembly here
  orq $-9223372036854775808,40672(%r14)
  ^~
1 error generated.
*** [i915_gem.o] Error code 1

___
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"


It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same 
error as you described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT 
revision is < r335873,

those kmod compile well.

We are looking into why both the drm ports fail.
Regards

I haven't yet tested an amd64 kernel with this, but I think this 
change to sys/amd64/include/atomic.h

might fix it:

Index: atomic.h
===
--- atomic.h    (revision 335896)
+++ atomic.h    (working copy)
@@ -446,10 +446,10 @@ ATOMIC_ASM(clear,    int,   "andl %1,%0", "ir", ~
  ATOMIC_ASM(add, int,   "addl %1,%0",  "ir",  v);
  ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
  -ATOMIC_ASM(set, long,  "orq %1,%0",   "ir",  v);
-ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
-ATOMIC_ASM(add, long,  "addq %1,%0",  "ir",  v);
-ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
+ATOMIC_ASM(set, long,  "orq %1,%0",   "er",  v);
+ATOMIC_ASM(clear,    long,  "andq %1,%0",  "er", ~v);
+ATOMIC_ASM(add, long,  "addq %1,%0",  "er",  v);
+ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
    #define    ATOMIC_LOADSTORE(TYPE)    \
  ATOMIC_LOAD(TYPE);    \




i've just built a kernel with this patch applied, rebooted into it 
and was able to build the drm-next-kmod port.  i am also running X 
without issues so far with this configuration.





oh neat - looks like this may have triggered a kernel panic. 
fortunately i was able to savecore.  here's the output of my info file:


info:
  Version String: FreeBSD 12.0-CURRENT #7 d7ac1268f3a(master)-dirty: 
Tue Jul  3 13:53:50 PDT 2018
pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV 

  Panic String: Duplicate free of 0xf8010ac59000 from zone 
0xf800340935a0(i915_gem_request) slab 0xf8010ac43af0(0)


i didn't build a kernel.debug file unfortunately, but here's the 
output of my core.txt file, not sure how helpful it is:


darn, hit send too soon - i was looking in wrong place for debug kernel 
- here is some hopefully more helpful info:


$ sudo kgdb /usr/lib/debug/boot/kernel/kernel.debug /var/crash/vmcore.1
Unread portion of the kernel message buffer:
WARNING !state->acquire_ctx failed at drm_atomic.c:634
WARNING !state->acquire_ctx failed at drm_atomic.c:270
WARNING !state->acquire_ctx failed at drm_atomic.c:634
WARNING !state->acquire_ctx failed at drm_atomic.c:634
WARNING !state->acquire_ctx failed at drm_atomic.c:634
WARNING !state->acquire_ctx failed at drm_atomic.c:270
WARNING !state->acquire_ctx failed at drm_atomic.c:634
WARNING !state->acquire_ctx failed at drm_atomic.c:270
WARNING !state->acquire_ctx failed at drm_atomic.c:270
WARNING !state->acquire_ctx 

Re: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/03/2018 14:17, Pete Wright wrote:



On 07/03/2018 12:02, John Baldwin wrote:

On 7/3/18 11:28 AM, Niclas Zeising wrote:

On 07/03/18 17:02, O. Hartmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:

It seems recent changes (SVN r335873?) may have broken 
drm-next-kmod ..


--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26: 


In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4: 


In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
  ^
:1:7: note: instantiated into assembly here
  andq $9223372036854775807,40672(%r14)
   ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38: 


In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
  ^
:1:6: note: instantiated into assembly here
  orq $-9223372036854775808,40672(%r14)
  ^~
1 error generated.
*** [i915_gem.o] Error code 1

___
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"


It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same 
error as you described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT 
revision is < r335873,

those kmod compile well.

We are looking into why both the drm ports fail.
Regards

I haven't yet tested an amd64 kernel with this, but I think this 
change to sys/amd64/include/atomic.h

might fix it:

Index: atomic.h
===
--- atomic.h    (revision 335896)
+++ atomic.h    (working copy)
@@ -446,10 +446,10 @@ ATOMIC_ASM(clear,    int,   "andl %1,%0", "ir", ~
  ATOMIC_ASM(add, int,   "addl %1,%0",  "ir",  v);
  ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
  -ATOMIC_ASM(set, long,  "orq %1,%0",   "ir",  v);
-ATOMIC_ASM(clear,    long,  "andq %1,%0",  "ir", ~v);
-ATOMIC_ASM(add, long,  "addq %1,%0",  "ir",  v);
-ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
+ATOMIC_ASM(set, long,  "orq %1,%0",   "er",  v);
+ATOMIC_ASM(clear,    long,  "andq %1,%0",  "er", ~v);
+ATOMIC_ASM(add, long,  "addq %1,%0",  "er",  v);
+ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
    #define    ATOMIC_LOADSTORE(TYPE)    \
  ATOMIC_LOAD(TYPE);    \




i've just built a kernel with this patch applied, rebooted into it and 
was able to build the drm-next-kmod port.  i am also running X without 
issues so far with this configuration.





oh neat - looks like this may have triggered a kernel panic. fortunately 
i was able to savecore.  here's the output of my info file:


info:
  Version String: FreeBSD 12.0-CURRENT #7 d7ac1268f3a(master)-dirty: 
Tue Jul  3 13:53:50 PDT 2018

pete@duke:/usr/obj/usr/home/pete/git/freebsd/amd64.amd64/sys/GENERIC-EVDEV
  Panic String: Duplicate free of 0xf8010ac59000 from zone 
0xf800340935a0(i915_gem_request) slab 0xf8010ac43af0(0)


i didn't build a kernel.debug file unfortunately, but here's the output 
of my core.txt file, not sure how helpful it is:


BFD: /bootpool/boot/kernel/kernel: invalid relocation type 37
BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail 
/usr/home/pete/git/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

BFD: /bootpool/boot/kernel/kernel: invalid relocation type 37
BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail 
/usr/home/pete/git/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

/dev/stdin:1: Error in sourced command file:
Cannot access memory at address 0x65657246
BFD: /bootpool/boot/kernel/kernel: invalid relocation type 37
BFD: BFD 2.17.50 [FreeBSD] 2007-07-03 assertion fail 
/usr/home/pete/git/freebsd/gnu/usr.bin/binutils/libbfd/../../../../contrib/binutils/bfd/elf64-x86-64.c:276

BFD: /bootpool/boot/kernel/kernel: invalid 

Re: atomic changes break drm-next-kmod?

[Pete Wright]

On 07/03/2018 12:02, John Baldwin wrote:

On 7/3/18 11:28 AM, Niclas Zeising wrote:

On 07/03/18 17:02, O. Hartmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:


It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..

--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
  ^
:1:7: note: instantiated into assembly here
  andq $9223372036854775807,40672(%r14)
   ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
  ^
:1:6: note: instantiated into assembly here
  orq $-9223372036854775808,40672(%r14)
  ^~
1 error generated.
*** [i915_gem.o] Error code 1

___
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"


It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < 
r335873,
those kmod compile well.

We are looking into why both the drm ports fail.
Regards


I haven't yet tested an amd64 kernel with this, but I think this change to 
sys/amd64/include/atomic.h
might fix it:

Index: atomic.h
===
--- atomic.h(revision 335896)
+++ atomic.h(working copy)
@@ -446,10 +446,10 @@ ATOMIC_ASM(clear,int,   "andl %1,%0",  "ir", ~
  ATOMIC_ASM(add,int,   "addl %1,%0",  "ir",  v);
  ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
  
-ATOMIC_ASM(set,	 long,  "orq %1,%0",   "ir",  v);

-ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
-ATOMIC_ASM(add, long,  "addq %1,%0",  "ir",  v);
-ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
+ATOMIC_ASM(set, long,  "orq %1,%0",   "er",  v);
+ATOMIC_ASM(clear,long,  "andq %1,%0",  "er", ~v);
+ATOMIC_ASM(add, long,  "addq %1,%0",  "er",  v);
+ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
  
  #define	ATOMIC_LOADSTORE(TYPE)	\

ATOMIC_LOAD(TYPE);  \




i've just built a kernel with this patch applied, rebooted into it and 
was able to build the drm-next-kmod port.  i am also running X without 
issues so far with this configuration.


cheers,
-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: atomic changes break drm-next-kmod?

[Jung-uk Kim]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 07/03/2018 15:23, Jung-uk Kim wrote:
> On 07/03/2018 15:02, John Baldwin wrote:
>> On 7/3/18 11:28 AM, Niclas Zeising wrote:
>>> On 07/03/18 17:02, O. Hartmann wrote:
 -BEGIN PGP SIGNED MESSAGE- Hash: SHA512
 
 Am Tue, 3 Jul 2018 10:19:57 -0400 Michael Butler 
  schrieb:
 
> It seems recent changes (SVN r335873?) may have broken 
> drm-next-kmod ..
> 
> --- i915_drv.o --- In file included from i915_drv.c:30: In 
> file included from 
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gp
lv2/include/linux/acpi.h:26:
>
>
> 
In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gp
lv2/include/linux/device.h:4:
>
>
> 
In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
>
>
> 
In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
>
>
> 
In file included from /usr/src/sys/sys/systm.h:44:
> ./machine/atomic.h:450:29: error: invalid operand for 
> instruction ATOMIC_ASM(clear,long,  "andq %1,%0", "ir",
> ~v); ^ :1:7: note: instantiated into assembly
> here andq $9223372036854775807,40672(%r14) 
> ^ 1 error generated. *** [i915_drv.o] 
> Error code 1
> 
> make[3]: stopped in 
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
>
>
> 
- --- i915_gem.o ---
> In file included from i915_gem.c:28: In file included from
>  
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm
/drmP.h:38:
>
>
> 
In file included from /usr/src/sys/sys/malloc.h:42:
> In file included from /usr/src/sys/sys/systm.h:44: 
> ./machine/atomic.h:449:29: error: invalid operand for 
> instruction ATOMIC_ASM(set,  long,  "orq %1,%0", "ir",
> v); ^ :1:6: note: instantiated into assembly
> here orq $-9223372036854775808,40672(%r14) 
> ^~ 1 error generated. *** [i915_gem.o] 
> Error code 1
> 
> ___ 
> 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"
 
 
 It breaks also graphics/drm-stable-kmod (see PR 229484, 
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, 
 same error as you described above) and also 
 emulators/virtualbox-ose-kmod. As long as CURRENT revision
 is < r335873, those kmod compile well.
>>> 
>>> We are looking into why both the drm ports fail. Regards
>>> 
>> 
>> I haven't yet tested an amd64 kernel with this, but I think this 
>> change to sys/amd64/include/atomic.h might fix it:
>> 
>> Index: atomic.h 
>> ===
>>
>>
>> 
- --- atomic.h  (revision 335896)
>> +++ atomic.h (working copy) @@ -446,10 +446,10 @@ 
>> ATOMIC_ASM(clear,int,   "andl %1,%0",  "ir", ~ 
>> ATOMIC_ASM(add,   int,   "addl %1,%0",  "ir",  v); 
>> ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
>> 
>> -ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v); 
>> -ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v); 
>> -ATOMIC_ASM(add,  long,  "addq %1,%0",  "ir",  v); 
>> -ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v); 
>> +ATOMIC_ASM(set,  long,  "orq %1,%0",   "er",  v); 
>> +ATOMIC_ASM(clear,long,  "andq %1,%0",  "er", ~v); 
>> +ATOMIC_ASM(add,  long,  "addq %1,%0",  "er",  v); 
>> +ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
>> 
>> #define  ATOMIC_LOADSTORE(TYPE)  \ 
>> ATOMIC_LOAD(TYPE);\
> 
> Isn't "Z" better than "e" in this case?

Never mind, brain fart.  These instructions are sign-extended.

Sorry for the noise.

Jung-uk Kim
-BEGIN PGP SIGNATURE-

iQEzBAEBCAAdFiEEl1bqgKaRyqfWXu/CfJ+WJvzb8UYFAls7zy8ACgkQfJ+WJvzb
8UYiOgf+PSb+Mv7UGCTUlftCiRmYYOW6ElMZSdr4tPinMocn4b/V9KJDqKOgO1SX
B2KCQHgSYt4Y+STiSrcCdhIkqCeIxdqJGHdTNpnpiUm7C+B50MrKgZo6n1xnlcCM
d4thqf0T/ZMaVaVEkZ42FTnmdXFo0L3jHNCHHYrpnXXXfRLJF6j5Q5Uetr1GEUJX
rpV2NIXMdk308qy4EvagLd0DEtT85QAjuG124nKh5FoSFD+5wBGFVrQWk4v4LVyd
rzBNM55JbTlEIFASlFjpiWJVhGvDzNVwN9XRxacYVgfEv23AMEibqhK12V48Lto/
X1/qHA0T9HC+gu/Eol+53AtU/P8ZyQ==
=cHxX
-END PGP SIGNATURE-
___
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: atomic changes break drm-next-kmod?

[Jung-uk Kim]

On 07/03/2018 15:02, John Baldwin wrote:
> On 7/3/18 11:28 AM, Niclas Zeising wrote:
>> On 07/03/18 17:02, O. Hartmann wrote:
>>> -BEGIN PGP SIGNED MESSAGE-
>>> Hash: SHA512
>>>
>>> Am Tue, 3 Jul 2018 10:19:57 -0400
>>> Michael Butler  schrieb:
>>>
 It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..

 --- i915_drv.o ---
 In file included from i915_drv.c:30:
 In file included from
 /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
 In file included from
 /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
 In file included from
 /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
 In file included from
 /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
 In file included from /usr/src/sys/sys/systm.h:44:
 ./machine/atomic.h:450:29: error: invalid operand for instruction
 ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
  ^
 :1:7: note: instantiated into assembly here
  andq $9223372036854775807,40672(%r14)
   ^
 1 error generated.
 *** [i915_drv.o] Error code 1

 make[3]: stopped in
 /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
 --- i915_gem.o ---
 In file included from i915_gem.c:28:
 In file included from
 /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
 In file included from /usr/src/sys/sys/malloc.h:42:
 In file included from /usr/src/sys/sys/systm.h:44:
 ./machine/atomic.h:449:29: error: invalid operand for instruction
 ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
  ^
 :1:6: note: instantiated into assembly here
  orq $-9223372036854775808,40672(%r14)
  ^~
 1 error generated.
 *** [i915_gem.o] Error code 1

 ___
 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"
>>>
>>>
>>> It breaks also graphics/drm-stable-kmod (see PR 229484,
>>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
>>> described
>>> above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision 
>>> is < r335873,
>>> those kmod compile well.
>>
>> We are looking into why both the drm ports fail.
>> Regards
>>
> 
> I haven't yet tested an amd64 kernel with this, but I think this change to 
> sys/amd64/include/atomic.h
> might fix it:
> 
> Index: atomic.h
> ===
> --- atomic.h  (revision 335896)
> +++ atomic.h  (working copy)
> @@ -446,10 +446,10 @@ ATOMIC_ASM(clear,int,   "andl %1,%0",  "ir", ~
>  ATOMIC_ASM(add,   int,   "addl %1,%0",  "ir",  v);
>  ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
>  
> -ATOMIC_ASM(set,   long,  "orq %1,%0",   "ir",  v);
> -ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
> -ATOMIC_ASM(add,   long,  "addq %1,%0",  "ir",  v);
> -ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
> +ATOMIC_ASM(set,   long,  "orq %1,%0",   "er",  v);
> +ATOMIC_ASM(clear,long,  "andq %1,%0",  "er", ~v);
> +ATOMIC_ASM(add,   long,  "addq %1,%0",  "er",  v);
> +ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
>  
>  #define  ATOMIC_LOADSTORE(TYPE)  \
>   ATOMIC_LOAD(TYPE);  \

Isn't "Z" better than "e" in this case?

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature

Re: atomic changes break drm-next-kmod?

[John Baldwin]

On 7/3/18 11:28 AM, Niclas Zeising wrote:
> On 07/03/18 17:02, O. Hartmann wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> Am Tue, 3 Jul 2018 10:19:57 -0400
>> Michael Butler  schrieb:
>>
>>> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
>>>
>>> --- i915_drv.o ---
>>> In file included from i915_drv.c:30:
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
>>> In file included from
>>> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
>>> In file included from
>>> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
>>> In file included from /usr/src/sys/sys/systm.h:44:
>>> ./machine/atomic.h:450:29: error: invalid operand for instruction
>>> ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
>>>  ^
>>> :1:7: note: instantiated into assembly here
>>>  andq $9223372036854775807,40672(%r14)
>>>   ^
>>> 1 error generated.
>>> *** [i915_drv.o] Error code 1
>>>
>>> make[3]: stopped in
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
>>> --- i915_gem.o ---
>>> In file included from i915_gem.c:28:
>>> In file included from
>>> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
>>> In file included from /usr/src/sys/sys/malloc.h:42:
>>> In file included from /usr/src/sys/sys/systm.h:44:
>>> ./machine/atomic.h:449:29: error: invalid operand for instruction
>>> ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
>>>  ^
>>> :1:6: note: instantiated into assembly here
>>>  orq $-9223372036854775808,40672(%r14)
>>>  ^~
>>> 1 error generated.
>>> *** [i915_gem.o] Error code 1
>>>
>>> ___
>>> 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"
>>
>>
>> It breaks also graphics/drm-stable-kmod (see PR 229484,
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
>> described
>> above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision 
>> is < r335873,
>> those kmod compile well.
> 
> We are looking into why both the drm ports fail.
> Regards
> 

I haven't yet tested an amd64 kernel with this, but I think this change to 
sys/amd64/include/atomic.h
might fix it:

Index: atomic.h
===
--- atomic.h(revision 335896)
+++ atomic.h(working copy)
@@ -446,10 +446,10 @@ ATOMIC_ASM(clear,int,   "andl %1,%0",  "ir", ~
 ATOMIC_ASM(add, int,   "addl %1,%0",  "ir",  v);
 ATOMIC_ASM(subtract, int,   "subl %1,%0",  "ir",  v);
 
-ATOMIC_ASM(set, long,  "orq %1,%0",   "ir",  v);
-ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
-ATOMIC_ASM(add, long,  "addq %1,%0",  "ir",  v);
-ATOMIC_ASM(subtract, long,  "subq %1,%0",  "ir",  v);
+ATOMIC_ASM(set, long,  "orq %1,%0",   "er",  v);
+ATOMIC_ASM(clear,long,  "andq %1,%0",  "er", ~v);
+ATOMIC_ASM(add, long,  "addq %1,%0",  "er",  v);
+ATOMIC_ASM(subtract, long,  "subq %1,%0",  "er",  v);
 
 #defineATOMIC_LOADSTORE(TYPE)  \
ATOMIC_LOAD(TYPE);  \


-- 
John Baldwin
___
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: atomic changes break drm-next-kmod?

[Niclas Zeising]

On 07/03/18 17:02, O. Hartmann wrote:

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:


It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..

--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
 ^
:1:7: note: instantiated into assembly here
 andq $9223372036854775807,40672(%r14)
  ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
 ^
:1:6: note: instantiated into assembly here
 orq $-9223372036854775808,40672(%r14)
 ^~
1 error generated.
*** [i915_gem.o] Error code 1

___
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"



It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < 
r335873,
those kmod compile well.


We are looking into why both the drm ports fail.
Regards
--
Niclas

___
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: atomic changes break drm-next-kmod?

[O. Hartmann]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Am Tue, 3 Jul 2018 10:19:57 -0400
Michael Butler  schrieb:

> It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..
> 
> --- i915_drv.o ---
> In file included from i915_drv.c:30:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
> In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
> In file included from
> /usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
> In file included from /usr/src/sys/sys/systm.h:44:
> ./machine/atomic.h:450:29: error: invalid operand for instruction
> ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
> ^
> :1:7: note: instantiated into assembly here
> andq $9223372036854775807,40672(%r14)
>  ^
> 1 error generated.
> *** [i915_drv.o] Error code 1
> 
> make[3]: stopped in
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
> --- i915_gem.o ---
> In file included from i915_gem.c:28:
> In file included from
> /usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
> In file included from /usr/src/sys/sys/malloc.h:42:
> In file included from /usr/src/sys/sys/systm.h:44:
> ./machine/atomic.h:449:29: error: invalid operand for instruction
> ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
> ^
> :1:6: note: instantiated into assembly here
> orq $-9223372036854775808,40672(%r14)
> ^~
> 1 error generated.
> *** [i915_gem.o] Error code 1
> 
> ___
> 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"


It breaks also graphics/drm-stable-kmod (see PR 229484,
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=229484, same error as you 
described
above) and also emulators/virtualbox-ose-kmod. As long as CURRENT revision is < 
r335873,
those kmod compile well.
- -- 
O. Hartmann

Ich widerspreche der Nutzung oder Übermittlung meiner Daten für
Werbezwecke oder für die Markt- oder Meinungsforschung (§ 28 Abs. 4 BDSG).
-BEGIN PGP SIGNATURE-

iLUEARMKAB0WIQQZVZMzAtwC2T/86TrS528fyFhYlAUCWzuQGgAKCRDS528fyFhY
lKHnAf0fIVHnw1xBVHzogeQQo4v+he17R2ln6l25lNR/pUE1AZOsFzPDamAkqbY+
f1+Usr+P5o7jn26Bh4ob3UmIj25DAf4tJZpeZS4iGZ374lrCAemYFb53+MJ1fClW
aBLI6DVOiBiOt/UpLXZf1whl/dtQvo5yd1xywfYOwi9Jh8teHcNW
=mtMH
-END PGP SIGNATURE-
___
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"

atomic changes break drm-next-kmod?

[Michael Butler]

It seems recent changes (SVN r335873?) may have broken drm-next-kmod ..

--- i915_drv.o ---
In file included from i915_drv.c:30:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/acpi.h:26:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/linuxkpi/gplv2/include/linux/device.h:4:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/device.h:35:
In file included from
/usr/src/sys/compat/linuxkpi/common/include/linux/types.h:37:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:450:29: error: invalid operand for instruction
ATOMIC_ASM(clear,long,  "andq %1,%0",  "ir", ~v);
^
:1:7: note: instantiated into assembly here
andq $9223372036854775807,40672(%r14)
 ^
1 error generated.
*** [i915_drv.o] Error code 1

make[3]: stopped in
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/i915
--- i915_gem.o ---
In file included from i915_gem.c:28:
In file included from
/usr/ports/graphics/drm-next-kmod/work/kms-drm-a753215/include/drm/drmP.h:38:
In file included from /usr/src/sys/sys/malloc.h:42:
In file included from /usr/src/sys/sys/systm.h:44:
./machine/atomic.h:449:29: error: invalid operand for instruction
ATOMIC_ASM(set,  long,  "orq %1,%0",   "ir",  v);
^
:1:6: note: instantiated into assembly here
orq $-9223372036854775808,40672(%r14)
^~
1 error generated.
*** [i915_gem.o] Error code 1

___
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"