On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote:
> diff --git a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> b/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> index a6e0a16ae..0697d70f4 100644
> --- a/drivers/gpu/drm/amd/amdgpu/amdgpu_amdkfd_gpuvm.c
> +++ b/drivers/gp
On Wed, Nov 13, 2019 at 04:22:19PM +0100, Hans Petter Selasky wrote:
> On 2019-11-13 15:52, Steve Kargl wrote:
> > at /usr/src/sys/amd64/amd64/trap.c:743
> > #7 0x808b0468 in trap (frame=0xfe00b460e0c0)
> > at /usr/src/sys/amd64/amd64/trap.c:407
> > #8
> > #9 0x000
On 2019-11-13 15:52, Steve Kargl wrote:
at /usr/src/sys/amd64/amd64/trap.c:743
#7 0x808b0468 in trap (frame=0xfe00b460e0c0)
at /usr/src/sys/amd64/amd64/trap.c:407
#8
#9 0x in ?? ()
#10 0x817d2c0f in radeon_ttm_tt_to_gtt (ttm=0xf80061eeb248)
On Wed, Nov 13, 2019 at 09:10:06AM +0100, Hans Petter Selasky wrote:
> On 2019-11-13 01:30, Steve Kargl wrote:
> >
> > I installed the 2nd seqlock.diff, rebuilt drm-current-kmod-4.16.g20191023,
> > rebooting, and have been pounding on the system with workloads that are
> > similar to what the syst
On 2019-11-13 01:30, Steve Kargl wrote:
On Tue, Nov 12, 2019 at 06:48:22PM +0100, Hans Petter Selasky wrote:
On 2019-11-12 18:31, Steve Kargl wrote:
Can you open the radeonkms.ko in gdb83 from ports and type:
l *(radeon_gem_busy_ioctl+0x30)
% /boot/modules/radeonkms.ko
(gdb) l *(radeon_gem_
On Tue, Nov 12, 2019 at 06:48:22PM +0100, Hans Petter Selasky wrote:
> On 2019-11-12 18:31, Steve Kargl wrote:
> >> Can you open the radeonkms.ko in gdb83 from ports and type:
> >>
> >> l *(radeon_gem_busy_ioctl+0x30)
> >>
> > % /boot/modules/radeonkms.ko
> > (gdb) l *(radeon_gem_busy_ioctl+0x30)
On 2019-11-12 18:31, Steve Kargl wrote:
Can you open the radeonkms.ko in gdb83 from ports and type:
l *(radeon_gem_busy_ioctl+0x30)
% /boot/modules/radeonkms.ko
(gdb) l *(radeon_gem_busy_ioctl+0x30)
0xa12b0 is in radeon_gem_busy_ioctl
(/usr/ports/graphics/drm-current-kmod/work/kms-drm-2d2852
On Mon, Nov 11, 2019 at 10:34:23AM +0100, Hans Petter Selasky wrote:
> Hi,
>
> Can you open the radeonkms.ko in gdb83 from ports and type:
>
> l *(radeon_gem_busy_ioctl+0x30)
>
% /boot/modules/radeonkms.ko
(gdb) l *(radeon_gem_busy_ioctl+0x30)
0xa12b0 is in radeon_gem_busy_ioctl
(/usr/ports/g
On Mon, Nov 11, 2019 at 02:22:55PM +0100, Hans Petter Selasky wrote:
> On 2019-11-08 23:09, Steve Kargl wrote:
> > Here's 'procstat -kk' for the stuck process with the long line wrapped.
>
> Can you run this command a couple of times and see if the backtrace changes?
>
> --HPS
I was AFK for a fe
On 2019-11-08 23:09, Steve Kargl wrote:
Here's 'procstat -kk' for the stuck process with the long line wrapped.
Can you run this command a couple of times and see if the backtrace changes?
--HPS
___
freebsd-current@freebsd.org mailing list
https://li
On Mon, Nov 11, 2019 at 01:22:09PM +0100, Hans Petter Selasky wrote:
> On 2019-11-11 11:44, Hans Petter Selasky wrote:
> > Seems like we can optimise away one more write memory barrier.
> >
> > If you are building from ports, simply:
> >
> > cd work/kms-drm*
> > cat seqlock.diff | patch -p1
> >
On 2019-11-11 11:44, Hans Petter Selasky wrote:
Seems like we can optimise away one more write memory barrier.
If you are building from ports, simply:
cd work/kms-drm*
cat seqlock.diff | patch -p1
Hi,
Here is one more debug patch you can try. See if you get that print
added in the patch in
Seems like we can optimise away one more write memory barrier.
If you are building from ports, simply:
cd work/kms-drm*
cat seqlock.diff | patch -p1
--HPS
diff --git a/linuxkpi/gplv2/include/linux/reservation.h b/linuxkpi/gplv2/include/linux/reservation.h
index b975f792c..0ce922a0e 100644
--- a
On 2019-11-11 10:34, Hans Petter Selasky wrote:
Hi,
Can you open the radeonkms.ko in gdb83 from ports and type:
l *(radeon_gem_busy_ioctl+0x30)
Hi,
I suspect there is a memory race in the seqlock framework. Can you try
the attached patch and re-build?
Is this issue easily reproducible?
Hi,
Can you open the radeonkms.ko in gdb83 from ports and type:
l *(radeon_gem_busy_ioctl+0x30)
--HPS
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-cur
On Thu, Nov 07, 2019 at 03:32:23PM -0500, Mark Johnston wrote:
> On Thu, Nov 07, 2019 at 12:29:19PM -0800, Steve Kargl wrote:
> > I haven't seen anyone post about an unkillable process
> > (even by root), which consumes 100% cpu.
> >
> > last pid: 4592; load av
On Thu, Nov 07, 2019 at 03:32:23PM -0500, Mark Johnston wrote:
> On Thu, Nov 07, 2019 at 12:29:19PM -0800, Steve Kargl wrote:
> > I haven't seen anyone post about an unkillable process
> > (even by root), which consumes 100% cpu.
> >
> > last pid: 4592; load av
On Thu, Nov 07, 2019 at 12:29:19PM -0800, Steve Kargl wrote:
> I haven't seen anyone post about an unkillable process
> (even by root), which consumes 100% cpu.
>
> last pid: 4592; load averages: 1.24, 1.08, 0.74 up 13+20:21:20
> 12:26:29
> 68 processes: 2 run
I haven't seen anyone post about an unkillable process
(even by root), which consumes 100% cpu.
last pid: 4592; load averages: 1.24, 1.08, 0.74 up 13+20:21:20 12:26:29
68 processes: 2 running, 66 sleeping
CPU: 0.1% user, 0.0% nice, 12.6% system, 0.0% interrupt, 87.2% idle
Mem:
t;>>>> On Tue, Jan 18, 2011 at 03:16:27PM +0100, Beat G?tzi wrote:
>>>>>> Hi,
>>>>>>
>>>>>> I've a tinderbox which uses tmpfs to build ports. Every time I build a
>>>>>> port which executes lin
0, Beat G?tzi wrote:
> >>>> Hi,
> >>>>
> >>>> I've a tinderbox which uses tmpfs to build ports. Every time I build a
> >>>> port which executes linux ldconfig it results in an unkillable process
> >>>> which uses 100% CPU.
e a tinderbox which uses tmpfs to build ports. Every time I build a
>>>> port which executes linux ldconfig it results in an unkillable process
>>>> which uses 100% CPU. The problem is reproduceable without tinderbox:
>>>>
>>>> # uname -a
>&g
I build a
> >> port which executes linux ldconfig it results in an unkillable process
> >> which uses 100% CPU. The problem is reproduceable without tinderbox:
> >>
> >> # uname -a
> >> FreeBSD daedalus.network.local 9.0-CURRENT FreeBSD 9.0-CURRENT #3
> >&
On 18.01.2011 15:46, Kostik Belousov wrote:
> On Tue, Jan 18, 2011 at 03:16:27PM +0100, Beat G?tzi wrote:
>> Hi,
>>
>> I've a tinderbox which uses tmpfs to build ports. Every time I build a
>> port which executes linux ldconfig it results in an unkillable pro
On Tue, Jan 18, 2011 at 03:16:27PM +0100, Beat G?tzi wrote:
> Hi,
>
> I've a tinderbox which uses tmpfs to build ports. Every time I build a
> port which executes linux ldconfig it results in an unkillable process
> which uses 100% CPU. The problem is reproduceable without tin
Hi,
I've a tinderbox which uses tmpfs to build ports. Every time I build a
port which executes linux ldconfig it results in an unkillable process
which uses 100% CPU. The problem is reproduceable without tinderbox:
# uname -a
FreeBSD daedalus.network.local 9.0-CURRENT FreeBSD 9.0-CURRE
On Sat, Nov 30, 2002 at 06:24:06PM +0100, Michal Mertl wrote the words in effect of:
> Subject says it all.
>
> I wanted to make vnode-backed md(4) and forgot to specify size, thas it
> after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
> be killed. It's wchan ('ps axO wcha
In message <[EMAIL PROTECTED]>, Michal
Mertl writes:
>Subject says it all.
Fixed in md.c revision 1.74 - this was discussed here a few days
ago, but I was just waiting for approval to commit the fix.
Ian
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the bo
Subject says it all.
I wanted to make vnode-backed md(4) and forgot to specify size, thas it
after 'touch mdfile;mdconfig -a -t vnode -f mdfile' mdconfig process can't
be killed. It's wchan ('ps axO wchan|grep mdconf') is mddest.
--
Michal Mertl
[EMAIL PROTECTED]
To Unsubscribe: send mail to
ddb
ps (find address of proc)
cont
cd /sys/i386/compile/MYKERNEL
gdb -k kernel.debug /dev/mem
print *(struct proc *){address}
go to the thread..
do the same.
maybe others can tell you other things to look at while you are in
there
(if you can not get to ddb you may neet to traverse the
In the last episode (Jul 29), Mikhail Teterin said:
> KOffice's kword is stuck here... Can not be killed even with -9.
> Sits idle, with its window open, but not updating:
>
> UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
> 1042 88248 1 0 96 0 119296 28105 -
KOffice's kword is stuck here... Can not be killed even with -9.
Sits idle, with its window open, but not updating:
UID PID PPID CPU PRI NI VSZ RSS MWCHAN STAT TT TIME COMMAND
1042 88248 1 0 96 0 119296 28105 - WWs pm0:00,00 kword
/tmp/k
Machine is otherwise fin
32 matches
Mail list logo
