Micro Devices, Inc. [AMD/ATI] Cezanne [Radeon Vega Series / Radeon
Vega Mobile Series] (rev c8)
I guess this will be supported if/when drm is next updated, but I have
patched amdgpu_drv.c below to start looking at it. The next issue is
"PSP load tmr failed" ...
--
Kind regards,
Yo
le to examine this image.
System panicked: trap
Backtrace from time of crash is available.
_KERNEL_OPT_GENFB_GLYPHCACHE() at 0
?() at bf014f2a
sys_reboot() at sys_reboot
vpanic() at vpanic+0x160
device_printf() at device_printf
startlwp() at startlwp
calltrap() at calltrap+0x19
ffs_sync() at ffs_sync+0x75
VFS_SYNC() at VFS_SYNC+0x22
sched_sync() at sched_sync+0x90
Could the first backtrace be a clue? Changes were made in this area after the
15th,
which is when pin still had a stable kernel.
--
Kind regards,
Yorick Hardy
Dear pin,
On 2021-12-28, pin wrote:
>
>
> Sent with ProtonMail Secure Email.
>
> ‐‐‐ Original Message ‐‐‐
>
> On Tuesday, December 28th, 2021 at 16:29, Yorick Hardy
> wrote:
>
> > Dear pin,
> >
> > On 2021-12-27, pin wrote:
> &g
ind which might be relevant was in
sys/kern/sys_generic.c 1.133, but that
was before 9.99.93, so I am not sure where to look.
--
Kind regards,
Yorick Hardy
On 2021-01-03, Yorick Hardy wrote:
> Dear matthew,
>
> On 2021-01-03, matthew green wrote:
> > Yorick Hardy writes:
> > > Dear current-users,
> > >
> > > Happy new year!
> >
> > happy new year yorick! and everyone.
> >
> > >
Dear matthew,
On 2021-01-03, matthew green wrote:
> Yorick Hardy writes:
> > Dear current-users,
> >
> > Happy new year!
>
> happy new year yorick! and everyone.
>
> > [ 659.839003] usbd_create_xfer() at netbsd:usbd_create_xfer+0x186
>
Dear current-users,
Happy new year!
On 2020-12-30, Yorick Hardy wrote:
> Dear current-users,
>
> Is anyone else seeing panics when opening a uhidev? (Generally from SDL.)
> I am using a custom kernel with a uintuos (not commited) Wacom, ukbd
> and ums hid devices. The panic onl
hidopen+0xe1
cdev_open() at cdev_open+0xae
spec_open() at spec_open+0x176
VOP_OPEN() at VOP_OPEN+0x3c
vn_open() at vn_open+0x130
do_open() at do_open+0x119
do_sys_openat() at do_sys_openat+0x74
sys_open() at sys_open+0x24
syscall() at syscall+0x1cc
--- syscall (number 5) ---
syscall+0x1cc:
--
Kind rega
s unusable/empty).
This is on current updated on 15 December. Unfortunately, I still do not know
the cause of the SIGSEGV.
Does glxgears work for anyone else (on i386+i915)?
--
Kind regards,
Yorick Hardy
$ gdb /usr/X11R7/bin/glxgears /tmp/yorick.glxgears.core
GNU gdb (GDB) 11.0.50.20200914
Dear Chuck,
On 2020-11-29, Chuck Silvers wrote:
> hi Yorick,
>
> On Sat, Nov 28, 2020 at 12:39:56AM +0200, Yorick Hardy wrote:
> > May I ask if you have an opinion on this patch? I have
> > not noticed any bad behaviour if it is omitted but, if I read
> > the co
Dear Chuck,
On 2020-11-27, Chuck Silvers wrote:
> Hi Yorick,
>
> On Fri, Nov 27, 2020 at 06:29:07PM +0200, Yorick Hardy wrote:
> >
> > I think that uvm_mremap did not keep pace with changes in uvm.
> > This patch seems to fix it for me, although I have only tested
&g
Dear Andrew and Leonardo,
On 2020-11-19, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-05-05, Andrew Doran wrote:
> > On Mon, May 04, 2020 at 03:54:57PM +0200, Leonardo Taccari wrote:
> > > Hello Yorick and Andrew,
> >
Dear Andrew,
On 2020-05-05, Andrew Doran wrote:
> On Mon, May 04, 2020 at 03:54:57PM +0200, Leonardo Taccari wrote:
> > Hello Yorick and Andrew,
> >
> > Yorick Hardy writes:
> > > > > > [...]
> > > > > >
> > > > &g
Thanks!
On 2020-05-24, Paul Ripke wrote:
> On Sun, May 24, 2020 at 06:56:54AM -0400, Greg Troxel wrote:
> > Yorick Hardy writes:
> >
> > (I realize you later say this isn't it.)
> >
> > >> @@ -4141,10 +4140,6 @@ sys_fdatasync(struct lwp *l, const
On 2020-05-24, Yorick Hardy wrote:
> Dear Greg and Paul,
>
> On 2020-03-25, Paul Ripke wrote:
> > On Mon, Mar 16, 2020 at 08:47:27AM -0400, Greg Troxel wrote:
> > > [lots of test reports about fdatasync patch]
> > >
> > > Thanks -- that's enough for
ust in
> case.
>
> Thanks for perservering on this. It takes many people to fix all the
> loose ends in an operating system!
I have been trying to find the cause of PR kern/55237. I am not at all
familiar with the code, so please forgive me for pointing fingers!
I think the call to fd_putfile results in a close of the fd, but that
does not happen anymore? Should it?
Apologies again if this has nothing to do with kern/55237.
--
Kind regards,
Yorick Hardy
Dear Andrew,
On 2020-04-19, Andrew Doran wrote:
> Hi Yorick.
>
> On Sat, Apr 18, 2020 at 11:00:02AM +0200, Yorick Hardy wrote:
>
> > > I just had the same panic with 9.99.55:
> > >
> > > Crash version 9.99.55, image version 9.99.55.
> > >
Dea Andrew,
On 2020-04-16, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-04-08, Yorick Hardy wrote:
> > Dear Andrew,
> >
> > On 2020-04-07, Yorick Hardy wrote:
> > > Dear Andrew,
> > >
> > > On 2020-04-07, Andrew Doran wrote:
> > &
Dear Andrew,
On 2020-04-08, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-04-07, Yorick Hardy wrote:
> > Dear Andrew,
> >
> > On 2020-04-07, Andrew Doran wrote:
> > > Hi Yorick.
> > >
> > > On Mon, Apr 06, 2020 at 11:16:37PM +0200, Yoric
Dear Andrew,
On 2020-04-07, Yorick Hardy wrote:
> Dear Andrew,
>
> On 2020-04-07, Andrew Doran wrote:
> > Hi Yorick.
> >
> > On Mon, Apr 06, 2020 at 11:16:37PM +0200, Yorick Hardy wrote:
> >
> > >Crash version 9.99.54, image version 9.99.54.
>
Dear Andrew,
On 2020-04-07, Andrew Doran wrote:
> Hi Yorick.
>
> On Mon, Apr 06, 2020 at 11:16:37PM +0200, Yorick Hardy wrote:
>
> >Crash version 9.99.54, image version 9.99.54.
> >crash: _kvm_kvatop(0)
> >Kernel compiled without options LOCKDEBUG.
x68
syscall() at syscall+0x227
--- syscall (number 411) ---
7f0af7842e9a:
crash>
--
Kind regards,
Yorick Hardy
Dear Tetsuya,
On 2020-03-20, Tetsuya Isaki wrote:
> At Fri, 20 Mar 2020 08:08:37 +0200,
> Yorick Hardy wrote:
> > It seems to be stuck in select (or poll, I did not check the source)
> > in portaudio.
>
> Yeah, I'm just looking this in this week.
> poll()/select()
(Oops: forgot to Cc the list.)
Dear Tetsuya,
On 2020-03-20, Tetsuya Isaki wrote:
> At Thu, 19 Mar 2020 21:36:00 +0200,
> Yorick Hardy wrote:
> > > > ffmpeg4 -f oss -i /dev/audio -channels 1 -sample_rate 48000
> > > > /tmp/test.wav
> > > >
> > &
Dear Tetsuya,
On 2020-03-19, Tetsuya Isaki wrote:
> At Sat, 14 Mar 2020 15:05:37 +0200,
> Yorick Hardy wrote:
> > Re: audacity (earlier in the thread), audacity hangs whenever I try to
> > record.
>
> Would you tell how to reproduce it?
First: my pkgsrc is not up t
Dear Tetsuya,
On 2020-03-19, Tetsuya Isaki wrote:
> At Tue, 10 Mar 2020 20:49:55 +0200,
> Yorick Hardy wrote:
> > ffmpeg4 -f oss -i /dev/audio -channels 1 -sample_rate 48000 /tmp/test.wav
> >
> > is completely garbled and too short. The file also seems to be 2
Dear nia,
On 2020-03-14, nia wrote:
> On Sat, Mar 14, 2020 at 12:20:11AM +0200, Yorick Hardy wrote:
> > You are correct. I threw together a NetBSD audio driver based on the oss
> > driver, but it had exactly the same problem. Strangely, I have been unable
> > to
>
C_KASLR, after perhaps 3 hours appeared
> stuck and unresponsive; I couldn't get into the debugger either. The
> other physical box is still working, though (and rebuilding).
>
> >
> > >
> > > Thomas
Maybe completely unrelated, but a kernel compiled yesterday hangs
while booting for me. After pressing the power button, the debugger
stops in "usb_disconnect_port".
--
Kind regards,
Yorick Hardy
r()
> uvm_fault_lower_enter()
> uvm_fault_internal()
> nvmm_ioctl()
> sys_ioctl()
> syscall()
>
> -Tobias
I think Maxime would like to be Cc'd on NVMM issues, so I am doing that here.
--
Kind regards,
Yorick Hardy
Dear nia,
On 2020-03-14, Yorick Hardy wrote:
> On 2020-03-14, Yorick Hardy wrote:
> > Dear nia,
> >
> > On 2020-03-14, nia wrote:
> > > On Sat, Mar 14, 2020 at 12:20:11AM +0200, Yorick Hardy wrote:
> > > > You are correct. I threw together a NetBSD au
On 2020-03-14, Yorick Hardy wrote:
> Dear nia,
>
> On 2020-03-14, nia wrote:
> > On Sat, Mar 14, 2020 at 12:20:11AM +0200, Yorick Hardy wrote:
> > > You are correct. I threw together a NetBSD audio driver based on the oss
> > > driver, but it had exactly the sam
Dear nia,
On 2020-03-13, nia wrote:
> On Tue, Mar 10, 2020 at 08:49:55PM +0200, Yorick Hardy wrote:
> > Can anyone else record audio correctly via ossaudio?
> > audiorecord seems to work as long as the frequency
> > divides the native frequency (see dmesg excerpt below)
>
not had time to
investigate. I need ffmpeg recording to work in case I have to make videos
for my classes :-)
--
Kind regards,
Yorick Hardy
On 2020-03-09, Chavdar Ivanov wrote:
> On Mon, 9 Mar 2020 at 19:52, Yorick Hardy wrote:
> >
> > Dear Chavdar,
> >
> > On 2020-03-08, Chavdar Ivanov wrote:
> > > Hi,
> > >
> > > On a -current (from today, but has happened before), when ru
the expected range.
>
> Any clues?
>
> Chavdar
Unfortunately, "me too". But I did not manage to see the logs or
track down the change which caused this behaviour (sorry).
I had panics for a while (in January?) when using nvmm, and once
that was fixed the "stalling" behaviour started.
--
Kind regards,
Yorick Hardy
Dear Tetsuya,
On 2019-11-04, Yorick Hardy wrote:
> Dear Tetsuya,
>
> On 2019-11-02, Tetsuya Isaki wrote:
> > At Sat, 26 Oct 2019 18:27:36 +0200,
> > Yorick Hardy wrote:
> > > [ 166.145911] panic: kernel diagnostic assertion "ring->used + n <=
> >
Dear Tetsuya,
On 2019-11-04, Yorick Hardy wrote:
> Dear Tetsuya,
>
> On 2019-11-02, Tetsuya Isaki wrote:
> > At Sat, 26 Oct 2019 18:27:36 +0200,
> > Yorick Hardy wrote:
> > > [ 166.145911] panic: kernel diagnostic assertion "ring->used + n <=
> >
Dear Tetsuya,
On 2019-11-02, Tetsuya Isaki wrote:
> At Sat, 26 Oct 2019 18:27:36 +0200,
> Yorick Hardy wrote:
> > [ 166.145911] panic: kernel diagnostic assertion "ring->used + n <=
> > ring->capacity" failed: file "/usr/src/local/sys/dev/au
nerama.so.2
This might be more pango fallout:
https://blogs.gnome.org/mclasen/2019/05/25/pango-future-directions/
"Using Harfbuzz for font loading means that we will lose support
for bitmap and type1 fonts. We think this is an acceptable trade-off,
but others might disagree. Note that Harfbuzz does support loading
bitmap-only OpenType fonts."
Kind regards,
--
Kind regards,
Yorick Hardy
dofileread() at netbsd:dofileread+0x8f
[ 166.155927] sys_read() at netbsd:sys_read+0x49
[ 166.155927] syscall() at netbsd:syscall+0x211
[ 166.155927] --- syscall (number 3) ---
[ 166.155927] 7047c3c42b7a:
[ 166.155927] cpu3: End traceback...
--
Kind regards,
Yorick Hardy
ons
which load libGL.so seem to fail due to missing symbols, I had to add
some dependencies as below. Is this correct?
--
Kind regards,
Yorick Hardy
Index: external/mit/xorg/lib/Makefile
===
RCS file: /cvsroot/src/external/mit/xorg/lib
On 2017-03-01, Martin Husemann wrote:
> On Wed, Mar 01, 2017 at 06:55:24PM +0900, Kimihiro Nonaka wrote:
> > Updated the patch.
>
> Still works fine for me!
>
> Martin
Also works fine for me on i386+intel and amd64+radeon.
Thanks!
--
Kind regards,
Yorick Hardy
On 2017-02-28, Kimihiro Nonaka wrote:
> Hi,
>
> 2017-02-28 4:10 GMT+09:00 Martin Husemann <mar...@duskware.de>:
>
> > On Mon, Feb 27, 2017 at 07:39:49PM +0100, Martin Husemann wrote:
> >> On Mon, Feb 27, 2017 at 08:29:10PM +0200, Yorick Hardy wrote:
> >&g
1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps 24Mbps
36Mbps 48Mbps 54Mbps
ubt0 at uhub1 port 1
ubt0: Broadcom Corp Broadcom Bluetooth 2.1 Device, rev 2.00/0.72, addr 2
wsdisplay0: screen 1 added (default, vt100 emulation)
wsdisplay0: screen 2 added (default, vt100 emulation)
wsdisplay0: screen 3 added (default, vt100 emulation)
wsdisplay0: screen 4 added (default, vt100 emulation)
--
Kind regards,
Yorick Hardy
hat symbol is defined in xsrc/external/mit/xinput/dist/src/xinput.c, but is
protected by a "#ifdef HAVE_XI2".
Did you clear out obj/external/mit/xorg/bin/xinput?
(It seems yes from your answer above.)
If it is broken, then I am responsible and will try to fix it.
--
Kind regards,
Yorick Hardy
es: 0x1f9<TS,TTP,HTC,STC,100,HWP,TSC>
cpu0: SVM Rev. 1
cpu0: SVM NASID 64
cpu0: SVM features 0xf<NP,LbrVirt,SVML,NRIPS>
cpu0: UCode version: 0x1c8
A wild guess is that this change is involved
http://cvsweb.netbsd.org/bsdweb.cgi/src/crypto/external/bsd/openssl/dist/crypto/bn/asm/x86_64-gf2m.pl.diff?r1=1.3=1.4
but I don't understand the change.
Any ideas what could be wrong?
--
Kind regards,
Yorick Hardy
Dear Christos,
On 2017-01-04, Christos Zoulas wrote:
> In article <20170104195823.GD26839@HOME>,
> Yorick Hardy <yorickha...@gmail.com> wrote:
> >Dear Martin,
> >
> >On 2017-01-04, Martin Husemann wrote:
> >> Can't you just use swap${.TARGET}.c instea
ref ${LINKFLAGS} -o ${.TARGET} \
- ${SYSTEM_OBJ:N*swap*${.TARGET}*} ${EXTRA_OBJ} vers.o \
+ ${SYSTEM_OBJ:Nswap*} ${EXTRA_OBJ} vers.o \
${OBJS:M*swap${.TARGET}.o}
TEXTADDR?= ${LOADADDRESS} # backwards compatibility
--
Kind regards,
Yorick Hardy
On 2017-01-04, Yorick Hardy wrote:
> On 2017-01-04, Yorick Hardy wrote:
> > Dear Martin,
> >
> > On 2017-01-04, Martin Husemann wrote:
> > > On Wed, Jan 04, 2017 at 07:28:19PM +0200, Yorick Hardy wrote:
> > > > Apologies, my "fix" broke your bu
On 2017-01-04, Yorick Hardy wrote:
> Dear Martin,
>
> On 2017-01-04, Martin Husemann wrote:
> > On Wed, Jan 04, 2017 at 07:28:19PM +0200, Yorick Hardy wrote:
> > > Apologies, my "fix" broke your build. I wonder why it worked before,
> > > probably becua
Dear Martin,
On 2017-01-04, Martin Husemann wrote:
> On Wed, Jan 04, 2017 at 07:28:19PM +0200, Yorick Hardy wrote:
> > Apologies, my "fix" broke your build. I wonder why it worked before,
> > probably becuase you have "netbsd" as part of your kernel nam
> ERROR: Failed to make all in
> "/d0/build/current/obj/mips64el/sys/arch/evbmips/compile/YEELOONG"
> *** BUILD ABORTED ***
>
>
> Perhaps this is an update-build issue? I'll wipe my ".../compile"
> directory and try again.
Apologies, my "fix" broke your build. I wonder why it worked before,
probably becuase you have "netbsd" as part of your kernel name?
Maybe the change should be reverted until the correct solution is found.
--
Kind regards,
Yorick Hardy
52 matches
Mail list logo
