d be I can bring the machine up to
running current, and/or compile a custom kernel with any debug options
enabled that might be helpful.
Thanks.
On Sun, 22 Oct 2023 at 21:30, Ashton Fagg wrote:
>
> >Synopsis: amd64 system kernel panicking multiple times per hour - appears
> >netwo
>Synopsis: amd64 system kernel panicking multiple times per hour - appears
>networking related
>Category: bug
>Environment:
System : OpenBSD 7.4
Details : OpenBSD 7.4 (GENERIC.MP) #1397: Tue Oct 10 09:02:37 MDT 2023
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Stefan Sperling wrote:
> There is nothing actionable in your report, though it is good to know
> that there seems to be an issue which the driver could handle better.
>
> It is unclear to me why the device would suddenly stop generating
> interrupts, which is what leads to a "device timeout".
>Synopsis: iwx(4) device timeouts on 802.11ac networks
>Category: Bug/driver issue
>Environment:
System : OpenBSD 7.1
Details : OpenBSD 7.1 (GENERIC.MP) #458: Sun Apr 3 23:10:53 MDT
2022
Mark Kettenis writes:
> Sounds like Intel changed the way CPU frequency scaling is implemented
> on these new CPUs. Somebody will have to look into this, but many
> OpenBSD developers prefer to buy machines with AMD CPU which is
> probably why this hasn't happened yet.
For those joining us on
Hello,
I just experienced a freeze on my laptop (Thinkpad T14s) which required a
hard reboot.
Upon coming back up, unfortunately the only clues I could recover as to
what happened was (from /var/log/messages):
Jun 12 00:40:58 moon /bsd: [drm] *ERROR* ring sdma0 timeout, signaled
seq=136335,
>Synopsis: Thinkpad T14s hibernates successfully, but will not resume.
>Category: amdgpu issue?
>Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9-beta (GENERIC.MP) #419: Sat Mar 20 00:43:49
MDT 2021
>Synopsis: Laptop goes back to sleep immediately upon resuming
after opening lid.
>Category: acpi bug?
>Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9-beta (GENERIC.MP) #363: Fri Feb 26 22:34:19
MST 2021
Claudio Jeker writes:
> I actually wonder if this code should just return the various counts to
> iscsictl so it could display the status (if requested).
I had considered that - and also adding a "poll" command to the CLI for
iscsictl. Might be useful while I'm testing, so I'll do that. :-)
>
Ashton Fagg writes:
> Attached is my first attempt at a "proper" solution. I haven't tested it
> beyond building as I can't take my machine down for testing right now...
>
> But, I'd appreciate a sanity check that I'm on the right track.
Sorry for the noise. I think
Ashton Fagg writes:
> Yep, so just checked this out.
>
> Adding "sleep 5" to the rc.d script does indeed bring about a clean
> boot.
>
> I re-did my experiments and yes, it appears that the second start of
> iscsid fails with the device busy error - as e
Ashton Fagg writes:
> Ooh, yeah actually you are probably right.
>
> I also misread your initial email - you said "iscsictl should wait and
> fail", I read it as "iscsid should wait and fail". ;-)
>
> Sorry for the confusion. I'll experiment a bit and
Claudio Jeker writes:
> Isn't that the 2nd iscsid that is started? IIRC your pictures showed that
> once you exited single user mode that another iscsid was started (but
> maybe I just interpreted the images wrong).
Ooh, yeah actually you are probably right.
I also misread your initial email -
Claudio Jeker writes:
> I'm not sure. vscsi(4) is ready the moment the kernel starts init. So it
> should not result in any problem for iscsid. What made you think this is
> the issue?
Yeah, so in /var/log/daemon, you see this:
Feb 20 18:59:28 elara iscsid[52173]: startup
Feb 20 18:59:28 elara
Claudio Jeker writes:
> Looking at the screenshot it seems there is a timing issue. The fsck -N
> tries to run before the disk was actually attached. I guess the iscsid
> startup script should wait to ensure the disks are ready.
> You could probably add a 'sleep 5' to rc_start() in
>Synopsis: Mouting iSCSI disk at boot time causes machine to enter single
>user mode.
>Category: Bug.
>Environment:
System : OpenBSD 6.9
Details : OpenBSD 6.9-beta (GENERIC.MP) #346: Fri Feb 19 23:56:21
MST 2021
Brennan Vincent writes:
> On 10/21/20 9:56 PM, Ashton Fagg wrote:
>> Brennan:
>>
>> I've experienced this also. I'm using different hardware than you
>> (Thinkpad, with amdgpu). Here's my dmesg also in case it is useful.
>>
>> I would say it happens about
Stefan Sperling writes:
> You will need to narrow the problem down. So far, it's impossible to
> tell what's actually going on when you see the problem.
> Here's a few question that might or might not help with narrowing it down:
Stefan, thanks for your suggestions. I can answer a few of these
>Synopsis: Wifi gives out sporadically, unclear why
>Category: bug
>Environment:
System : OpenBSD 6.8
Details : OpenBSD 6.8-current (GENERIC.MP) #183: Tue Nov 17
14:35:35 MST 2020
Stuart Henderson writes:
> BTW on an Intel machine with smt cpu, htop's display is as expected,
> AMD machines identify their cores a bit differently and I think that may
> be relevant. If you can't figure it out yourself you'll probably need
> someone with an AMD SMT machine to take a look.
>
>
Otto Moerbeek writes:
> I do not know htop. Does top show the same? When reporting isses, use
> base tools as much as possible.
>
Thanks for your reply, Otto.
It appears I am confused - I had thought htop was part of the base
system (but it turns out it's just one of the first packages I
>Synopsis: Core 1, 3, 5 & 7 are always idle.
>Category: bug
>Environment:
System : OpenBSD 6.8
Details : OpenBSD 6.8-current (GENERIC.MP) #167: Sat Nov 7
00:10:46 MST 2020
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
bren...@umanwizard.com writes:
> When I close my lid, the system suspends, as expected. When I
> reopen the lid, the system _briefly_ unsuspends: I can see my
> desktop for about a split second. However, after that split second,
> the system sleeps again. I can then wake
t Thinkpad docks etc, so I'll keep working on that.
Ashton Fagg writes:
> Following up here - Brad Smith (cc'ed) suggested a patch off-list to
> register ALC257 as part of the Azalia codecs.
>
> I applied this patch, and susequently it did not work. I did some
> resarch into
Following up here - Brad Smith (cc'ed) suggested a patch off-list to
register ALC257 as part of the Azalia codecs.
I applied this patch, and susequently it did not work. I did some
resarch into how Linux's ALSA handles this chip, and it seems that it
treats it the same as an ALC 269.
The
joshua stein writes:
> Do the messages appear if you use the touchpad or just the keyboard?
> Your machine seems to be another that attaches a legacy pms(4)
> version of the touchpad in addition to the I2C version (imt/ims)
> which is probably sending conflicting messages to the devices/bus.
Jonathan Gray writes:
> To clarify the patch was for -current with linux 5.7 drm. We won't be
> backporting raven2 support to 6.7. It will be available in 6.8.
Ah. Understood, thanks for the clarification.
- ajf
Jonathan Gray writes:
> So it turns out Ryzen 3 3200U is handled as raven2 in the driver.
> We backported support for picasso but not raven2 into the 4.19 drm in
> 6.7. At least in this case raven2 shares a pci id with picasso with
> raven2 detected based on a revision.
>
> Here is a backport
Ashton Fagg writes:
> Jonathan:
>
> Thanks for your reply.
>
> Jonathan Gray writes:
>
>> This was really 0x1002:0x15d8 for picasso, amdgpu does not match on 0x1508
>
> Ah, yes, you are right.
>
>> 6.7 has drm based on linux 4.19. If you can try a snapsh
Jonathan:
Thanks for your reply.
Jonathan Gray writes:
> This was really 0x1002:0x15d8 for picasso, amdgpu does not match on 0x1508
Ah, yes, you are right.
> 6.7 has drm based on linux 4.19. If you can try a snapshot (which are
> post 6.8 at the moment) you will be using a driver based on
Hello,
I have an Acer Aspire 5 which has a Ryzen 3 3200 chip (with integrated
graphics).
I installed 6.7 release - all came up fine. Upon booting for the first
time, it suggested I run `syspatch`. I did this, and on the next reboot
the machine hangs with "Initializing kernel modesetting (RAVEN
31 matches
Mail list logo
