Number: 6491
Category: kernel
Synopsis: amd64 kernel sometimes fails to boot on Thinkpad T410s
Confidential: yes
Severity: serious
Priority: medium
Responsible:bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
The following reply was made to PR kernel/6615; it has been noted by GNATS.
From: Laurence Tratt lau...@tratt.net
To: gn...@openbsd.org
Cc: Joel Sing j...@sing.id.au
Subject: Re: kernel/6615: Latest snapshot not mounting root device
Date: Thu, 9 Jun 2011 17:32:09 +0100
Following a message
Synopsis: ahci timesout
Category: kernel
Environment:
System : OpenBSD 5.0
Details : OpenBSD 5.0-current (GENERIC.MP) #141: Fri Nov 25
00:16:26 MST 2011
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
Synopsis: synopsis of the problem (one line)
wpaakms status on iwn0 doesn't seem to be reset
Category: PR category (one line)
Environment:
System : OpenBSD 5.4
Details : OpenBSD 5.4-current (GENERIC.MP) #150: Thu Nov 14
00:30:57 MST 2013
Hello,
Yesterday, at the point that I did a mouse drag in gvim, my X session died,
and I was dumped into the console with the following message appearing a
split second later:
error: [drm:pid29704:i915_reset] *ERROR* Failed to reset chip: -60
At that point, the machine was completely locked
On Tue, Oct 04, 2016 at 01:13:42PM -0600, Theo de Raadt wrote:
Hello Theo,
>> However, if the new behaviour is preferred, it might be worth documenting
>> it somewhere.
> If this was mentioned in the INSTALL notes would you have seen it before
> running into it? Go ahead, look at the document.
On Tue, Oct 04, 2016 at 06:23:24PM +, Robert Peichaer wrote:
Hello Robert,
Thanks for your quick reply!
>> The last couple of snapshots seem to have changed the behaviour of
>> upgrading. If when asked "Location of sets?" I select "disk", and type in
>> an appropriate mounted location, the
>Synopsis: Upgrading from sets on a mounted disk no longer works
>Environment:
System : OpenBSD 6.0
Details : OpenBSD 6.0-current (GENERIC.MP) #2518: Sun Oct 2
21:41:07 MDT 2016
On Tue, Oct 04, 2016 at 04:58:36PM -0600, Theo de Raadt wrote:
Hello Theo,
> anyways, rpe and I have discussed and figured out a solution that will
> allow the old method to work. It is just unfortunate it takes so much
> effort to maintain old strange methods for everyone.
Thanks to Robert
>Synopsis: panic on resume in acpitz_setfan
>Category: kernel
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #1: Fri Aug 11 21:26:07
MDT 2017
>Synopsis: Kernel panic (possibly inteldrm related)
>Category: kernel
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #0: Sun Jul 23 11:17:14
BST 2017
On Sun, Jul 23, 2017 at 11:32:06PM +0100, Laurence Tratt wrote:
> extsmaild (http://tratt.net/laurie/src/extsmail/) appears to be causing
> the final panic, but given that it's just in a "wake every 60 seconds
> and see if new files have appeared in a directory"
On Thu, Jul 27, 2017 at 05:59:00PM +0200, Martin Pieuchot wrote:
Hello Martin,
> The only "leak" I'm seeing is the 'drmreq' pool. It grows until the
> application is closed. Note that with my fix the allocated size for
> 'drmreq' is divided by 4. So if that was the problem I might not be able
>Synopsis:
iwm: could not add MAC context
>Category:
kernel
>Environment:
System : OpenBSD 6.1
Details : OpenBSD 6.1-current (GENERIC.MP) #30: Mon Jul 31 22:48:24
MDT 2017
>Synopsis: digital audio out no longer working?
>Environment:
System : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #14: Thu Jun 14 23:55:47
MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
>Synopsis: kernel_lock not locked
>Category: kernel
>Environment:
System : OpenBSD 6.3
Details : OpenBSD 6.3-current (GENERIC.MP) #55: Mon Jun 25 23:01:52
MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
On Sat, Jun 23, 2018 at 06:43:04PM +0200, Alexandre Ratchov wrote:
Hello Alexandre,
>> As of the last two snapshots, digital audio out via S/PDIF on my machine
>> no longer works:
>>
>> $ doas mixerctl outputs.mode=digital
>> mixerctl: field outputs.mode does not exist
>>
On Mon, Aug 14, 2017 at 12:05:59AM +0100, Laurence Tratt wrote:
> The following panic happened immediately after a resume (the second since
> the machine was switched on) on the Aug 11th snapshot:
>
> uvm_fault(0x81b3ff8, 0x20003, 0, 1) -> e
>
>Synopsis: kernel crash in ffs_mapsearch
>Environment:
System : OpenBSD 6.4
Details : OpenBSD 6.4-beta (GENERIC.MP) #300: Tue Sep 18 02:27:17
MDT 2018
dera...@amd64.openbsd.org:/usr/src/sys/arch/amd64/compile/GENERIC.MP
On Fri, Oct 02, 2020 at 03:20:36PM +0100, Laurence Tratt wrote:
>> For the past couple of weeks I've been encountering a weird problem on
>> -current amd64 -- my screen intermittently blanks for around 2-4 seconds
>> when running xorg. At first I thought this was
On Wed, Sep 30, 2020 at 10:30:57PM +0100, Laurence Tratt wrote:
> For the past couple of weeks I've been encountering a weird problem on
> -current amd64 -- my screen intermittently blanks for around 2-4 seconds
> when running xorg. At first I thought this was a hardware problem (the
For the past couple of weeks I've been encountering a weird problem on
-current amd64 -- my screen intermittently blanks for around 2-4 seconds
when running xorg. At first I thought this was a hardware problem (the
machine isn't a spring chicken), but then ffmpeg caught the blanking while I
was
On Thu, Jul 02, 2020 at 01:54:52PM +0200, Marcus Glocker wrote:
Hello Marcus,
> Can you send me your cams USB device id again please?
Here's the relevant excerpt from usbdevs:
addr 04: 046d:0892 Logitech, HD Pro Webcam C920
high speed, power 500 mA, config 1, rev 0.19, iSerial
On Wed, Jun 24, 2020 at 08:51:37AM +0100, Laurence Tratt wrote:
> External webcams don't seem to work fully correctly with the uvideo driver
> and mjpeg? If I use this command as an example (since it's cross platform):
>
> $ ffmpeg -f v4l2 -input_format mjpeg -video_size 1280x720 -
On Sat, Jun 27, 2020 at 02:41:25AM +0200, Ingo Feinerer wrote:
Hello Ingo,
> Same behavior with an old MS LifeCam NX-6000 (which only supports
> MJPEG). It works up to 160x120 without problems on USB3 ports and up to
> the maximum resolution supported by the camera on USB2 ports (i.e., USB3
>
On Thu, Jun 25, 2020 at 11:21:51PM +0100, Laurence Tratt wrote:
> It seems this is because the Logitech C920 has been revised (mine has the
> USB ID 046d:0892) and no longer supports a separate H264 mode.
This turns out to be a total red herring -- modern FFmpeg deals with the
MJPEG fine a
The recent DRM update has fixed one long-ish-standing bug for me where Xorg
sometimes would get stuck while executing Xsession (I could never work out
why) which is really good!
However I've now had the following kernel panic several times:
kernel: page fault trap, code=0
Stopped at
I've been having an intermittent problem for some months with my X11 screen
blanking (i.e. going totally black -- however, the mouse still displays and
changes shape depending on what it's hovering over!). Switching to
Ctrl+Alt+F1 and back fixes it, though once in a while causes X11 to crash.
On Sat, Nov 21, 2020 at 10:16:23AM +0100, Antoine Jacoutot wrote:
Hello Antoine,
>> I've been having an intermittent problem for some months with my X11
>> screen blanking (i.e. going totally black -- however, the mouse still
>> displays and changes shape depending on what it's hovering over!).
On Sat, Nov 21, 2020 at 10:16:23AM +0100, Antoine Jacoutot wrote:
>> I've been having an intermittent problem for some months with my X11
>> screen blanking (i.e. going totally black -- however, the mouse still
>> displays and changes shape depending on what it's hovering over!).
>> Switching to
I've got a Ryzen 5900X machine with a Radeon Polaris 12 GPU. It's a basic
GPU, and has mostly worked for 5 months, but not fully:
1. Suspend/resume nearly always fails, with resume leading to a (generally
green) solid colour before automatically rebooting. Occasionally the
machine will
`man 7 term` contains the following:
Terminal type descriptions are stored as files of capability data
underneath /usr/share/terminfo. To browse a list of all terminal names
recognized by the system, do
toe | more
However, I cannot see a `toe` command on any of my OpenBSD boxes,
As of a kernel from a couple of days ago, iwx semi-regularly stops
associating with my wireless AP. An easy way to trigger this is "pkg_add
-u": at some point, downloading stops mid-package, and I need to "sh
/etc/netstart" to bring the interface back up.
My previous kernel was about a week old.
As of the last couple of days' snapshots, xorg is regularly crashing
(probably once every 1-2 hours on average) and dumping me back to xenodm.
This seems to happen only when I use Firefox though I guess this is related
to the xorg update? This is on amdgpu / amd64.
I can't see anything in the
On Tue, Nov 16, 2021 at 04:30:23PM +, Nicola Dell'Uomo wrote:
Hello Nicola,
> Maybe you should follow this thread:
>
> X.org segmentation fault - snapshot amd64
>
> I think it could be the same problem you're experiencing.
Yes, it does look like it's probably the same -- thanks! One extra
On Sun, Nov 21, 2021 at 06:06:33PM +0100, Stefan Sperling wrote:
Hello Stefan,
>> As of a kernel from a couple of days ago, iwx semi-regularly stops
>> associating with my wireless AP. An easy way to trigger this is "pkg_add
>> -u": at some point, downloading stops mid-package, and I need to "sh
I updated my amd64 machine from a snapshot from about 2 weeks ago to the Nov
2nd and then Nov 3rd snapshots. In both cases, as soon as I log into X,
start Firefox, and try and load a page the machine hard locks and has to be
power cycled.
I thought that the new amdgpu firmware might be the
On Thu, Nov 04, 2021 at 10:24:07PM +1100, Jonathan Gray wrote:
Hello Jonathan,
>> I updated my amd64 machine from a snapshot from about 2 weeks ago to the
>> Nov 2nd and then Nov 3rd snapshots. In both cases, as soon as I log into
>> X, start Firefox, and try and load a page the machine hard
For some years I've had a seemingly odd problem where logging in via xenodm
did not respect my login class. I've tried repeatedly to work out why, and
until now always failed -- it turns out that my ~/.xsession file was not
marked as executable and this caused our Xsession to run it via /bin/sh.
I seem to have an odd situation with sensor enumeration in sensorsd, but I'm
not sure if the real cause is in sensorsd, the relevant drivers (xhci and
friends, uhidpp), or the kernel. This is on amd64 -current.
My Logitech mouse attaches as uhidpp0 and exposes a battery sensor:
$ sysctl|grep
I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. Over
that time nearly all of the GPU related bugs have disappeared (thanks
Jonathan et al.!), except for the fact that I don't seem to be able to
reliably suspend/resume from X.
Resuming used to crash the machine 9 times out
On Sun, Jan 23, 2022 at 09:50:58PM +1100, Jonathan Gray wrote:
Hello Jonathan,
Thanks for your fast reply!
>> As of the last couple of weeks or so (at least), things are a little
>> better. I now seem to be able to semi-reliably suspend/resume from the
>> console. When I resume an odd white-ish
Across a few Intel machines I've had, I've often seen warnings about
"potential atomic update failures". On my current desktop with an
i5-13600K I've now seen actual failures:
drm:pid51847:intel_pipe_update_start *ERROR* [drm] *ERROR* Potential atomic
update failure on pipe A
On Tue, May 10, 2022 at 09:26:48PM +0100, Laurence Tratt wrote:
> Maybe! Would that device have some sort of interaction with X one way or
> another? Because it seems that I can reliably suspend/resume if xenodm is
> on the login page, but after I've logged in via xenodm, suspend rarel
One of my amd64-current boxes only suspends correctly about 50% of the time,
but gets completely stuck the rest of the time (i.e. I have to hard reboot
and fsck). I've now noticed a correlation between successful and
unsuccessful suspends and an xhci error. From /var/log/messages, here's a
On Sun, Jan 23, 2022 at 09:20:20AM +, Laurence Tratt wrote:
> I've had a Ryzen machine with a (basic!) Polaris GPU for about a year. Over
> that time nearly all of the GPU related bugs have disappeared (thanks
> Jonathan et al.!), except for the fact that I don't seem to be able to
&
On Tue, May 10, 2022 at 09:08:04PM +1000, Jonathan Gray wrote:
Hello Jonathan,
>>> I've had a Ryzen machine with a (basic!) Polaris GPU for about a year.
>>> Over that time nearly all of the GPU related bugs have disappeared
>>> (thanks Jonathan et al.!), except for the fact that I don't seem to
I've just got my sticky mits on a Framework 12th Gen Intel laptop. It
somewhat works, but regularly hits kernel panics and other oddities on
-current. I haven't worked out why yet, but uvm_faults seem to be frequent.
For example setting the keyboard encoding causes a uvm_fault.
$ doas wsconsctl
On Tue, Aug 02, 2022 at 11:54:48AM +1000, Jonathan Gray wrote:
Hello Jonathan,
>> I've just got my sticky mits on a Framework 12th Gen Intel laptop. It
>> somewhat works, but regularly hits kernel panics and other oddities on
>> -current. I haven't worked out why yet, but uvm_faults seem to be
On my Framework (gen 2) laptop I experience intermittent panics, most
without an obvious cause, with -current (this is a snapshot from last week,
with a stock kernel + Ulf's trackpad patch from [1], which seems unlikely to
be related to this panic). Here's my transcript (photo of the panic at [2])
On Wed, Aug 03, 2022 at 09:10:01AM +0100, Laurence Tratt wrote:
[Framework laptop keyboard encoding crashing]
> I did a bit more digging and I've confused myself considerably, possibly
> because I don't know how wscons works. If I boot the machine without the
> external keyboard attac
On Wed, Aug 03, 2022 at 07:17:27AM +0200, Anton Lindqvist wrote:
Hello Anton,
>> `disable ucc` has no effect (it doesn't attach normally, so I guess that's
>> not surprising?) -- I still get a kernel panic.
> ucc does attach according to your dmesg. However, while ucc attaches it
> sets it's own
On Tue, Aug 02, 2022 at 07:00:52PM +, Miod Vallat wrote:
Hello Miod,
> Do the uvm_fault errors disappear if you `boot -c' and `disable ucc'?
`disable ucc` has no effect (it doesn't attach normally, so I guess that's
not surprising?) -- I still get a kernel panic.
> Or if you `disable
On Tue, Aug 02, 2022 at 08:56:09PM +1000, Jonathan Gray wrote:
Hello Jonathan,
>> I'm also starting to understand a bit more about some of the random panics:
>> they seem to happen very soon after X starts. Sometimes the mouse appears as
>> a two inch square of weird colours (!) -- things only
On a new-ish Ryzen 7900X machine my USB webcam randomly fails to start
(normally after 1 or 2 times of working, though it can sometimes fail to
start even on the first attempt), leaving this in dmesg:
uvideo0: can't allocate mmap buffer!
Taking the device out and reinserting it doesn't fix the
On Tue, Nov 29, 2022 at 10:34:58AM +0100, Mark Kettenis wrote:
Hello Mark,
>> "AMDIF031" at acpi0 not configured
> That is some sort of new GPIO controller that we don't support yet.
> Not used on your machine though.
A quick look at the Linux driver suggests that they treat AMDIF031 as the
On Mon, Apr 03, 2023 at 09:56:20PM +0200, Stefan Sperling wrote:
Hello Stefan,
> This particular sysassert code (0x20002806) is a known issue since
> the -77 firmware update. I don't know what is triggering this error
> and so far I have failed to reproduce it. Apparently something is
> wrong
I built a new kernel this morning which includes a number of amdgpu patches.
I saw a bizarre situation where: the machine almost-but-not-quite ground to a
halt for quite a while, with the display not updating properly. Then the
display updated normally, the mouse continued working OK, but the
Upgrading to last night's snapshot I think updated amdgpu's firmware (to
amdgpu-firmware-20230625). I'm now getting lots of stutter (X freezes for
~0.5-1s, key presses dropped etc) and lots of these in dmesg:
[drm] *ERROR* Error waiting for DMUB idle: status=3
[drm] *ERROR* Error queuing DMUB
On Thu, Jun 29, 2023 at 07:17:03PM +1000, Jonathan Gray wrote:
Hello Jonathan,
> Paul de Weerd also reported problems with the firmware update.
> We tracked it down to
>
> amdgpu: DMCUB updates for DCN 3.1.4 and 3.1.5
>
In my `.xsession` I have:
xidle -no -program "/usr/X11R6/bin/xlock -mode fadeplot -dpmsstandby 180
-dpmssuspend 0 -dpmsoff 0" -timeout 500 -delay 100 &
So, after 8 minutes, `xidle` runs `xlock` and after another 3 minutes the
monitor is put into standby mode.
When the monitor is in
On Wed, Feb 14, 2024 at 12:34:17PM +0100, Mark Kettenis wrote:
Hello Mark,
>> It seems that I have two (at least) lm devices on my motherboard and
>> that it's random which attaches. Here are the two I've seen:
>>
>> lm0 at isa0 port 0x290/8: W83627DHG
>> lm0 at isa0 port 0x290/8: NCT6792D
On Tue, Feb 13, 2024 at 08:44:32AM +, Miod Vallat wrote:
>> Does this help?
>>
>> diff --git sys/dev/wscons/wskbd.c sys/dev/wscons/wskbd.c
>> index 7631cd5f701..dd65f61ce63 100644
>> --- sys/dev/wscons/wskbd.c
>> +++ sys/dev/wscons/wskbd.c
>> @@ -1229,7 +1229,10 @@ getkeyrepeat:
>>
>>
It seems that I have two (at least) lm devices on my motherboard and that
it's random which attaches. Here are the two I've seen:
lm0 at isa0 port 0x290/8: W83627DHG
lm0 at isa0 port 0x290/8: NCT6792D
The W83627DHG gives one fan reading, with an obviously incorrect value:
$ sysctl hw|grep
Perhaps 5-8 times in the past few weeks I've experienced X crashing.
Interestingly, each time it's happened has been while the monitor has
been in standby. Things seem to be fine until I wake the screen up by
pressing a key. Almost immediately Xorg crashes, and drops me back to
the console;
Yesterday my amd64 machine failed to `zzz` for the first time (with a
kernel built from yesterday with the now-commited "support Alder Lake-N and
Alder Lake-S" from jsg@). This might just be one of those random things
that we so love about computers but after reboot I had `uvn_flush` errors
and
On Tue, Nov 07, 2023 at 09:03:59AM +, Laurence Tratt wrote:
> Across a few Intel machines I've had, I've often seen warnings about
> "potential atomic update failures". On my current desktop with an
> i5-13600K I've now seen actual failures:
>
> drm:pid51847:intel
67 matches
Mail list logo
