Hi,
Sorry this took so long,
On 6/15/23 06:49, Sebastien Marie wrote:
On Wed, Jun 14, 2023 at 10:49:32PM +0200, Peter N. M. Hansteen wrote:
A similar situation with hexchat, after a fresh sysupgrade and reinstall of
that package:
https://marc.info/?l=openbsd-ports=168667722510843=2 (I
97.0
@wantlib canberra.2.0
@wantlib crypto.51.0
@wantlib dbus-glib-1.5.0
@wantlib gdk-x11-2.0.2400.0
@wantlib gdk_pixbuf-2.0.3200.3
@wantlib gio-2.0.4200.17
@wantlib glib-2.0.4201.10
@wantlib gmodule-2.0.4200.17
[Wed Jun 14 22:46:53] peter@zaida:~$
All the best,
Peter
--
Peter N. M. Han
>: mov(%r14),%eax
--Type for more, q to quit, c to continue without paging--
0x0c3183c5739c <+476>: mov%r14,%rdi
0x0c3183c5739f <+479>: callq 0xc3185c6bf40
0x0c3183c573a4 <+484>: jmp0xc3183c57375
0x0c3183c573a6 <+486>: m
On Mon, Jun 12, 2023 at 06:52:00PM +0200, Sebastien Marie wrote:
> On Mon, Jun 12, 2023 at 06:28:55PM +0200, Peter N. M. Hansteen wrote:
> > On Mon, Jun 12, 2023 at 05:59:08PM +0200, Sebastien Marie wrote:
> > > the package is too old. the signature date is 2023-04-16, so it
On Mon, Jun 12, 2023 at 05:50:13PM +0100, Stuart Henderson wrote:
> On 2023/06/12 18:34, Peter N. M. Hansteen wrote:
> > On Mon, Jun 12, 2023 at 05:08:20PM +0100, Stuart Henderson wrote:
> > > Ah, the next thing I would have suggested in that cause would have
> > > b
r your patience and help.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
https://bsdly.blogspot.com/ https://www.bsdly.net/ https://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
0x0f09381e8797 <+311>: mov%r15d,%edi
0x0f09381e879a <+314>: mov%r14,%rsi
0x0f09381e879d <+317>: callq 0xf09381f1300
0x0f09381e87a2 <+322>: mov%eax,%edi
0x0f09381e87a4 <+324>: callq 0xf09382067f0
0x0f09381e
On Mon, Jun 12, 2023 at 03:51:10PM +0200, Sebastien Marie wrote:
> On Mon, Jun 12, 2023 at 03:40:26PM +0200, Peter N. M. Hansteen wrote:
> >
> > [Mon Jun 12 15:28:27] peter@zaida:~$ ls -l *core
> > -rw--- 1 peter peter 1701245120 Jun 8 17:55 thunderbird.core
> >
On Mon, Jun 12, 2023 at 03:31:37PM +0200, Sebastien Marie wrote:
> On Mon, Jun 12, 2023 at 02:44:04PM +0200, Peter N. M. Hansteen wrote:
> > >Synopsis: After snapshot upgrade, xfce4 session dies immediately after
> > >xenodm auth
> > >Category: Xorg, xenocara,
_ecdsa (peter@tietorevry-pc38887)
/usr/local/bin/startxfce4: X server already running on display :0
Illegal instruction (core dumped)
All identities removed.
Agent pid 63741 killed
"X server already running" and "Illegal instruction" both sound like something
very odd happened
t have that fix in it
(the latest available has files dated August 24th), but building and
installing a kernel from a fresh cvs up fixed it.
Thanks!
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ htt
ered, config 1, rev 1.00
driver: uhub0
Controller /dev/usb1:
addr 01: 8086: Intel, xHCI root hub
super speed, self powered, config 1, rev 1.00
driver: uhub1
addr 02: 13d3:56cb Azurewave, USB2.0 HD IR UVC WebCam
high speed, power 500 mA, config 1, rev 19.61, iSerial 200901010001
driver: uvideo0
driver: uvideo1
addr 03: 8087:0026 Intel, Bluetooth
full speed, self powered, config 1, rev 0.02
driver: ugen0
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
xperience with a recent laptop, see the
ASUS Zenbook S thread here and my writeup from a few weeks back
https://bsdly.blogspot.com/2021/07/the-impending-doom-of-your-operating.html
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.
On Thu, Jun 17, 2021 at 04:30:49PM +0200, Peter N. M. Hansteen wrote:
> For various non-interesting reasons I ran with the last sysupgraded
> snapshot + fresh drm510 kernel from May 10 until today when I did the
> sysupgrade plus kernel rebuild again.
Sorry, that was June 10, not
On 6/4/21 11:28 PM, Peter N. M. Hansteen wrote:
>
>
> On 6/4/21 11:03 PM, Bryan Steele wrote:
>> It is likely what ratchov@ describes here, the microphone on these
>> newer machines is no longer internally connected to the HD Audio device,
>> but instead some new In
ur help, I'll report back when I have something, as usual :)
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
d
explains the silent mic, but how to fix?
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah s
p.
I can confirm that this works after a simple cut to the two
scripts + chmod +x of same, followed by enabling and starting hotplugd.
Excellent, thanks!
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.ne
On 6/2/21 10:52 AM, Alexandre Ratchov wrote:
> sndiod_flags="-f rsnd/0 -F rsnd/1"
Yes, that worked. Excellent, thanks!
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.
e
(Enabled/Disabled)
Un-wonderful photos at https://photos.app.goo.gl/B1CZoS1QPdUXekiv5 and
https://photos.app.goo.gl/YEgZiKL8pEUdQMA59
That said, having support for using the thing without toggling obscure
BIOS options would be fine with me.
All the best,
Peter
--
Peter N. M. Hansteen, mem
un 2 10:30:46 zaida /bsd: uhidev0: iclass 3/0
Jun 2 10:30:46 zaida /bsd: uhid0 at uhidev0: input=1, output=0, feature=64
but audio output stays on the internal speaker.
Is there some (simple) tweak to enable switching audio outputs here?
All the best,
Peter
--
Peter N. M. Hansteen, member o
han happy to test stuff. As I said earlier, the machine now works
and is a lot better in almost all respects than its predecessor from 2017 (which
is still in the house but may be on its way elsewhere soon). I suspect this one
has a lot in common with what other people will be buying in the near future
the driver load and I am now using that to have the machine with no
extra parts and untethered.
Thanks for all your help!
I suspect the short patch may still be useful, though, so do consider
commiting that.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementatio
On Mon, May 31, 2021 at 06:59:55PM +0200, Peter N. M. Hansteen wrote:
> On Mon, May 31, 2021 at 06:44:44PM +0200, Marcus MERIGHI wrote:
> > Hello,
> >
> > pe...@bsdly.net (Peter N. M. Hansteen), 2021.05.31 (Mon) 18:10 (CEST):
> > > I was hoping one of the existing
On Mon, May 31, 2021 at 06:58:26PM +0200, Stefan Sperling wrote:
> On Mon, May 31, 2021 at 06:10:22PM +0200, Peter N. M. Hansteen wrote:
> > I was hoping one of the existing realtek wifi drivers might do the trick
> > but apparently not, as of right now.
> >
> > S
On Mon, May 31, 2021 at 06:44:44PM +0200, Marcus MERIGHI wrote:
> Hello,
>
> pe...@bsdly.net (Peter N. M. Hansteen), 2021.05.31 (Mon) 18:10 (CEST):
> > I was hoping one of the existing realtek wifi drivers might do the
> > trick but apparently not, as of right now.
>
&
msi
azalia0: codecs: Realtek/0x0294, Intel/0x2812, using Realtek/0x0294
audio0 at azalia0
and I have audio, just tested with a video off nrk.no (the national
public broadcaster).
Thanks! This improves life one significant increment :)
All the best,
Peter
--
Peter N. M. Hansteen, member
On Tue, May 25, 2021 at 09:48:44PM -0400, Bryan Steele wrote:
> On Wed, May 26, 2021 at 02:51:53AM +0200, Peter N. M. Hansteen wrote:
> Intel 11th Gen "Intel Rapid Storage" device which is not supported.
>
> vendor "Intel", unknown product 0x09ab (class system
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
The sendbug under fine high resolution X still runs, here are dmesg and
xdpyinfo output
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious ne
/20210526_024335.jpg
I will make some more attempts at catching real sendbug
output after I have caught a bit of sleep.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember t
I spoke too soon. I just had X freeze again.
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah s
e; /usr/src/lib/libc/thread/rthread_cond.c has 209
lines.
(gdb) continue
Continuing.
Thread 6 received signal SIGSTOP, Stopped (signal).
[Switching to thread 250540]
futex () at /tmp/-:3
3 /tmp/-: No such file or directory.
(gdb)
Again, it goes back to the same lines.
All the best,
Peter
inue
Continuing.
Program received signal SIGSTOP, Stopped (signal).
[Switching to thread 269704]
futex () at /tmp/-:3
3 /tmp/-: No such file or directory.
in /tmp/-
Current language: auto; currently asm
--
Peter N. M. Hansteen, member of the first RFC 1149 implementati
w warranty" for details.
This GDB was configured as "amd64-unknown-openbsd6.9"...
Attaching to program: /usr/X11R6/bin/Xorg, process 9354
trace
and it just does not a lot for quite a while
Again I may be missing something.
All the best,
Peter
--
Peter N. M. Hansteen, member of the f
access somewhere in
> the code...
That could certainly be. Let's see if I can extract any useful info with a
debug-enable system.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds.
On Thu, May 20, 2021 at 08:53:14AM +1000, Jonathan Gray wrote:
> On Wed, May 19, 2021 at 06:32:01PM +0200, Peter N. M. Hansteen wrote:
> > On Wed, May 19, 2021 at 04:43:44PM +0200, Peter N. M. Hansteen wrote:
> > > > outdated...)
> > >
> > > I tried the fir
On Wed, May 19, 2021 at 04:43:44PM +0200, Peter N. M. Hansteen wrote:
> > outdated...)
>
> I tried the first, that only seemed to have the effect of having
> the freeze come faster. So I commented out that part of the xorg.conf
> and I'm trying the steps in the README now, but
ze come faster. So I commented out that part of the xorg.conf
and I'm trying the steps in the README now, but for some reasons I
don't get any dumps in /var/crash as expected. Then again I could well
be missing some crucial step.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first
might be worth trying.
It doesn't, unfortunately. But I was thinking I would contact ASUS anyway
to see if an updated BIOS is available. So I stole most of that to input
in their support site's form.
Now I'll be looking forward to their response :)
All the best,
Peter
--
Peter N. M. Hansteen, memb
Hi Mark,
Are there other tests I could usefully perform for this one?
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious ne
/20210503_164616.jpg
https://www.bsdly.net/~peter/20210503_164624.jpg
https://www.bsdly.net/~peter/20210503_165327.jpg
https://www.bsdly.net/~peter/20210503_165335.jpg
still running with a disable acpicpu* kernel, FWIW
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation
On Sat, May 01, 2021 at 07:58:20PM +0200, Peter N. M. Hansteen wrote:
> On Fri, Apr 30, 2021 at 09:59:14PM +1000, Jonathan Gray wrote:
> >
> > Or perhaps boot -c and disable acpicpu* if that doesn't break anything.
>
> Doing the boot -c and disable acpicpu* did enable
had a sysupgrade and I've run fw_update (the thing now
connects via
wired, ure).
dmesg attached and at https://www.bsdly.net/~peter/dmesg.zelda
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Rem
n % access_size) == 0);
>
> pb = (uint8_t *)buffer;
I'm building with that now on the older machine. I wonder, is this change
small and non-intrusive enough that we could hope it makes it into an amd64
snapshot soon?
(I fully appreciate why developers want faster machines :))
- Peter
On Mon, Mar 01, 2021 at 02:16:26PM +0100, Peter N. M. Hansteen wrote:
> This is a partial report, the machine in question is now at the 'syncing
> disks' stage of 'boot dump' from ddb.
the dump never proceeded beyond that, so I did a cold reset.
The dmesg.boog has been preserved as
r/20210301/20210301_135459.jpg
When the machine comes back I should be able to extract more information
such as a fresh dmesg.
All the best,
Peter
[1] Still the same machine as described in
https://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html
--
Peter N. M. Hansteen, member of the
you so, based on checking
the $NEXT_VERSION directory on the preferred mirror. If you expected something
else to happen, you need to adjust that expectation, plain and simple.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.
ing as designed, and ended up demonstrating to (I assume) a
new user how OpenBSD release versions work.
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious netw
s like
pkg_add seem to resolve names slower than they used to.
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil bit on all malicious network traffic"
delilah sp
latest snapshot (bsd.rd dated Jul 31 16:47) boots
on my laptop here (yes, running EFIBOOT, see [1]) with no manual
intervention.
Thanks!
- Peter
[1] this is the system described in my recent blog post -
http://bsdly.blogspot.com/2017/07/openbsd-and-modern-laptop.html
--
Peter N. M. Hansteen, memb
d to this thread.
>
> http://marc.info/?l=openbsd-tech=150133319108895=2
This certainly would explain what I have seen here (and probably also
seen by others).
If I read those messages correctly there should be reason to hope that
the next snapshot will have the fix.
--
Peter N. M. Hanst
/shells) and append the shell's line to /etc/shells.
Would it be possible to have upgrade's automatic sysmerge run merge
/etc/shells?
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Rem
osts: No space left on device
This brings http://marc.info/?l=openbsd-misc=147941233118802=2 to mind,
very
similar symptoms at least (TL;DR: fatfingered dd of iso image created a regular
file in /dev/, the rest is predictable).
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 imp
On 08/07/16 13:43, Peter N. M. Hansteen wrote:
>> Synopsis:Running post-6.0 amd64 snapshots, thunderbird segfaults at
>> startup
With the 2016-08-13 snapshot and fresh packages, thunderbird works
again. Thanks!
--
Peter N. M. Hansteen, member of the first RFC 1149 impleme
On Sun, Aug 07, 2016 at 03:10:48PM +0200, Martin Natano wrote:
> On Sun, Aug 07, 2016 at 01:43:08PM +0200, Peter N. M. Hansteen wrote:
> >
> > /var/log/messages reports
> >
> > Aug 7 13:34:27 elke /bsd: thunderbird(10425): mmap W^X violation
>
> You wil
I just had another, pretty much identical panic, pics here
https://home.nuug.no/~peter/20160710/, transcript will follow in sendbug
output in a bit
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no
E802_11_RADIO -niiwm0 -l | grep -w csa
Ah, excellent! I'll do just that and tee it off somewhere useful. Thanks
!
- - Peter
- --
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
"Remember to set the evil
64
autoconf autoconfprivacy pltime 85623 vltime 604219
> You can force 11g (2 GHz) or 11a (5GHz) modes by running either:
>
> ifconfig iwm0 mode 11g
>
> or:
>
> ifconfig iwm0 mode 11a
Yes, I have at some times in the past forced 11a mode to enjoy the
relative quiet of 5GHz :)
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 04/02/16 15:49, Peter N. M. Hansteen wrote:
> dmesg will follow once I have the thing running again, the most
> recent one I could find in my backups is at
> http://home.nuug.no/~peter/20160402_crash/dmesg_elke_20160118.txt.
And afte
uug.no/~peter/20160402_crash/20160402_152334.jpg (ps part 1 of 3)
http://home.nuug.no/~peter/20160402_crash/20160402_152404.jpg (ps part 2 of 3)
http://home.nuug.no/~peter/20160402_crash/20160402_152440.jpg (ps part 3 of 3)
dmesg will follow once I have the thing running again, the most recent one I
could
not fun at all.
- --
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673 seconds
on results.
All the best,
Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
http://bsdly.blogspot.com/ http://www.bsdly.net/ http://www.nuug.no/
Remember to set the evil bit on all malicious network traffic
delilah spamd[29949]: 85.152.224.147: disconnected after 42673
63 matches
Mail list logo
