>Synopsis: athn(4) AR9287 unstable and poor network quality
>Category: system amd64
>Environment:
System : OpenBSD 6.7
Details : OpenBSD 6.7 (GENERIC.MP) #1: Sat May 16 16:33:02 MDT 2020
r...@syspatch-67-amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/
GENERIC.MP
Architecture: OpenBSD.a
On Wed, May 20, 2020 at 10:06 AM Stefan Sperling wrote:
> On Tue, May 19, 2020 at 11:12:01PM +0200, stolen data wrote:
> > trying to transfer the same 440 MiB file but on 802.11n
> > ===
> >
> > the machine's
On Wed, May 20, 2020 at 1:42 PM Stefan Sperling wrote:
> On Wed, May 20, 2020 at 12:20:45PM +0200, stolen data wrote:
> > The antennas are just fine - as I mentioned, when rebooting the PC into
> > Linux (same hardware, same wireless access point etc.) this WiFi card
> > per
On Thu, May 21, 2020 at 9:11 AM Stefan Sperling wrote:
> On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
>
> ...
>
> > > You can try MCS1, MCS2, ..., all the way up to MCS15.
> >
> > Unfortunately no change. Some are unusable but none of the
On Sat, May 23, 2020 at 9:57 AM Stefan Sperling wrote:
> On Fri, May 22, 2020 at 05:12:23PM +0200, stolen data wrote:
> > On Thu, May 21, 2020 at 9:11 AM Stefan Sperling wrote:
> >
> > > On Thu, May 21, 2020 at 01:04:36AM +0200, stolen data wrote:
> > >
> &
I've noticed that inactive disks in my system are no longer entering
standby (spinning down) despite being issued "atactl setstandby
". These are backup drives, regular SATA drivers attached to the
internal SATA bus on the mainboard, and they see no activity whatsoever
outside of an isolated night
Trace from crash: https://imgur.com/a/qT1xd37
It happens every few boot attempts. The board has been running 6.8 (and
Debian 10) just fine for a long while. The problem showed up after a fresh
install of 6.9 using latest dtb/u-boot.
Apologies for bumping the thread. Just want to add that I tested everything
again on 7.6, and the bug persists with no change in behavior.
On Wed, Oct 2, 2024 at 6:40 PM stolen data wrote:
>
> I've dug a bit deeper into this and found that the interface outages occur
> when the
Pardon, forgot to mention that this is on fully updated 7.5/amd64.
On Wed, Sep 18, 2024 at 9:55 PM stolen data
wrote:
> dmesg:
>
> re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G \
> (0x4c00), msi, address 00:16:96:ec:88:51
> rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
>
> ...
>
dmesg:
re0 at pci1 dev 0 function 0 "Realtek 8168" rev 0x11: RTL8168G/8111G \
(0x4c00), msi, address 00:16:96:ec:88:51
rgephy0 at re0 phy 7: RTL8251 PHY, rev. 0
Can only survive heavy TCP traffic (e.g. large download or a test with
tcpbench/iperf) on mode "media: Ethernet 1000baseT full-dup
quot; rev 2.00/80.07 addr 3
uhidev3: no input interrupt endpoint
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
root on sd0a (9772e3eec596a51d.a) swap on sd0b dump on sd0b
amdgpu0: RENOIR GC 9.3.0 8 CU rev 0x00
amdgpu0: 1920x1080, 32bpp
wsdisplay0 at amdgpu0 mux 1: console (std, vt100 emulation), using wskbd0
wskbd1: connecting to wsdisplay0
wskbd2: connecting to wsdisplay0
wsdisplay0: screen 1-5 added (std, vt100 emulation)
On Wed, Sep 18, 2024 at 9:58 PM stolen data wrote:
>
> Pardon, forgot to mention that this is on fully updated 7.5/amd64.
>
p 19, 2024 at 1:06 PM stolen data wrote:
>
> To try rule out a hardware problem I booted a Linux distro (running Linux 6.8)
> on the machine, and there the interface is fully stable and performs well.
>
> Here's the complete dmesg:
>
> OpenBSD 7.5 (GENERIC.MP) #2: Mon
12 matches
Mail list logo
