1_135417.jpg
https://www.bsdly.net/~peter/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
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 ha
working 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 mali
rade told 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://
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
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 will n
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
ome.nuug.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
c
-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
-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,
I got distracted by other things, but I can confirm that the next
snapshot dated 2016-04-02 17:50 installed and booted fine. Here's an
ltime 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 :)
Nice to hear it's all progressi
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 05/21/16 16:12, Stefan Sperling wrote:
> On Sat, May 21, 2016 at 04:04:35PM +0200, Peter N. M. Hansteen
> wrote:
>> The main reason I reported this was that I also had an episode of
>> lost link for long enough for me to notice
-yIEEE802_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 se
t; shots after the first handful are somewhat repetetive.
>>
>
> The machine serving the pictures is unbelievably slow, and the
> pictures are rather large... That's not fun at all.
>
>
- --
Peter N. M. Hansteen, member of the first RFC 1149 implementation team
h
shell and things 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&q
wnloading) and report back 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 seconds.
osts: No space left on device
This brings http://marc.info/?l=openbsd-misc&m=147941233118802&w=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, mem
/etc/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.n
nter until the prompt comes back to type reboot.
Then again, probably ignorable if nobody else is seeing anything similar.
- P
--
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 b
d to this thread.
>
> http://marc.info/?l=openbsd-tech&m=150133319108895&w=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.
--
Pete
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
_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
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,
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
> >
(%rbx),%rdx
0x0f09381e8797 <+311>: mov%r15d,%edi
0x0f09381e879a <+314>: mov%r14,%rsi
0x00000f09381e879d <+317>: callq 0xf09381f1300
0x0f09381e87a2 <+322>: mov%eax,%edi
0x0f09381e87a4 <+324>: callq 0xf09382067f0
Again thanks for 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.
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
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
9 <+473>: 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 <+48
ib c.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
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&m=168667722510843&am
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.
It looks like the original report got eaten somewhere or at least has
not yet reached the marc.info archive, so I am putting the sendbug -P
output with my explanatory comments at
https://nxdomain.no/~peter/sendbug-p-skapet_exim_20240818.txt
All the best,
Peter
--
Peter N. M. Hansteen, member
is change of
> behavior.
I'll try with a kernel from a fresh eu.opensbsd.org current checkout and
report back.
Thanks!
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/
"Re
all of the freshest flavors here :)
Anyway, I'll try tb@'s suggestion first (locally built kernel from fresh
-current checkout) and see if that solves the problem.
If it doesn't, the next step is of course a locally built exim 4.91.1.
All the best,
Peter
--
Peter N. M. Hansteen, member
On Sun, Aug 18, 2024 at 03:29:25PM +0200, Peter N. M. Hansteen wrote:
> If it doesn't, the next step is of course a locally built exim 4.91.1.
make that locally built 4.97.1 but I guess it was obvious.
Also, looking at the FAQ's recipe for building kernels, I assume a
common beg
.
Running with a kernel built from fresh head checkout did not change
things, unfortunately. On to rebuilding exim.
- 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 s
s tls mail flowing again, thanks!
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]:
r
> versions of exim and it was a little bit configuration dependent. It might
> be a good idea to work out with exim dev team directly if it doesn't work
> with the same snapshot as the one I tried.
There are no secrets in my config, so I can give you a copy if that helps
at all.
- Pe
disabled by default in 4.86+).
Yes, I can comment out that section. I was never entirely sure it adds any
actual value.
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/
"Rememb
On Mon, Aug 19, 2024 at 11:11:40AM +0200, Peter N. M. Hansteen wrote:
> On Mon, Aug 19, 2024 at 10:54:00AM +0200, Renaud Allard wrote:
> > Your configuration looks indeed very simple without anything unusual.
> > I added your tls_require_ciphers as this is the only thing
ith "openssl s_client
> -starttls smtp -connect localhost:25"?
[Mon Aug 19 11:38:45] peter@skapet:~/website$ openssl s_client -starttls smtp
-connect localhost:25
connect: Connection refused
connect:errno=61
and nothing logged by exim, for some strange reason.
- Peter
--
Peter N. M.
tiated
SSL-Session:
Protocol : TLSv1.3
Cipher: TLS_AES_256_GCM_SHA384
Session-ID:
Session-ID-ctx:
Master-Key:
Start Time: 1724060528
Timeout : 7200 (sec)
Verify return code: 0 (ok)
---
250 HELP
--
Peter N. M. Hansteen, member of the first RFC 1149 implementation
00 Message
accepted for delivery"
2024-08-19 11:43:39 1sfyvJ-Agd-40yI Completed
- 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 ne
able to dig out the git hash
used for the build?
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"
en_socket_count=,
accept_socket=) at daemon.c:562
#6 daemon_go () at daemon.c:2833
#7 0x00447e4b14f4 in main (argc=3, cargv=0x7cf6d42946e8) at exim.c:5176
(gdb) trace
Tracepoint 1 at 0x447e563155: file pdkim.c, line 673.
(gdb)
- Peter
--
Peter N. M. Hansteen, member of the first RFC 1149 im
nsure whether they match). Then
>
> # mkdir /var/crash/exim (i assume that is the process name; adjust if not)
> # sysctl kern.nosuidcoredump=3
>
> Trigger a crash, see if you get a /var/crash/exim/$PID.core and if so,
> point egdb at it.
I did a bit of that and it looks if I read thi
ge of your choice the next time we meet!
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"
deli
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 :))
- Pet
e thing has now 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
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 t
/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
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
o it 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
--
P
ome 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
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,
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
issue in case there is some un-initialized memory 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.
Type "show 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,
ibc/sys/w_poll.c:27
#2 0x02b14afd99cb in ospoll_wait () from /usr/X11R6/bin/Xorg
#3 0x02b14afd1726 in WaitForSomething () from /usr/X11R6/bin/Xorg
#4 0x000002b14ae3338c in Dispatch () from /usr/X11R6/bin/Xorg
#5 0x02b14ae3e5ec in dix_main () from /usr/X11R6/bin/Xorg
#6 0x02b14ae25180 in _
return (0);
209 }
(gdb) list
Line number 210 out of range; /usr/src/lib/libc/thread/rthread_cond.c has 209
lines.
(gdb) continue
Continuing.
Program received signal SIGSTOP, Stopped (signal).
[Switching to thread 269704]
futex () at /tmp/-:3
3 /tmp/-: No such file or directory.
t
206 (void *)cond, count);
207
208 return (0);
209 }
(gdb) list
Line number 210 out of range; /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]
fu
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
peter/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
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
est,
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 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
rev 0x20: 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. Hanste
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.
>
&
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: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
made 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 implemen
4804&w=2
I'll be more than 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 pe
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
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
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.no/
27;s laptop.
I can confirm that this works after a simple cut&paste 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/
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
Thanks for your 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 mal
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
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 May.
erience 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:/
f powered, 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.
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
84 matches
Mail list logo
