Re: i915 observations
On Thu, Jul 21, 2022 at 09:29:36PM +0200, Tobias Nygren wrote: > > Eventu?lly, the image tends to converge to the intended one (except > > maybe for the clock itself, which tends to lag behind all the time). > > I believe the effect you see is framebuffer contents written to > the CPU cache but not flushed out to memory. This is why the artefacts > lazily repair themselves when background jobs that cause frequent cache > line misses are run. (Note how the artefacts are always 1 pixel high, > 64-bytes wide and seemingly randomly positioned.) Why, yes, that sounds like a probable cause. I remember that the repairs were quicker when the system was under load, but I initially thought it was due to the copious output being displayed. Your explanation fits my observation that the repairs are still quick even if the terminal running the demanding command is hidden, or when the output is redirected to /dev/null. My conjecture was that the problem is connected with some power-saving states.
Re: i915 observations
On Thu, Jul 21, 2022 at 10:51:15AM +0200, Frank Kardel wrote: > Where do we collect i915 (-current) issues? We don't seem > to have many PRs in that area. I have a data point with a > Thinkpad T15p where i915 almost works but has flickering > dark dashes and massively delayed keyboard input. > Unfortunately I have to pass the notebook on to a > college. I believe I may have the same issue with ASUS EeeBox PC EB1037, which I’m not going to part with any time soon, although I would describe it differently. In my case, the dashes don’t flicker. I think the image is updated through seemingly randomly placed short horizontal segments. The less of the screen needs updating, the slower the update becomes. Full-screen updates are devoid of such glitches. I also wouldn’t call the keyboard input delayed. I would say that visual effects of keyboard input usually were delayed due to the fact that they tend to require just a small part of the screen updated. This is most visible when logging in with xdm. Once logged in, I have a clock displayed, which enforces an update every second, which also updates some of the remaining dashes. Eventuąlly, the image tends to converge to the intended one (except maybe for the clock itself, which tends to lag behind all the time). Perhaps such descriptions don’t illustrate the symptom well. I may try to record a screencast to see if it captures the glitches.
Re: bash job control broken?
On Wed, Apr 27, 2016 at 05:24:54PM +0200, Thomas Klausner wrote: > Hi! > > I see strange behaviour on NetBSD-current with bash (sh, zsh are > fine). Here's a simple test case: > > # cat /dev/zero >&/dev/null > CTRL-Z > [1]+ Stopped cat /dev/zero &> /dev/null > # bg > [1]+ cat /dev/zero &> /dev/null & > > and the prompt doesn't return. > > Neither CTRL-Z nor CTRL-C work. > > Ideas? > Thomas Hello. I confirm that sh is fine and bash does not behave as expected. Additionally, I observe similar behaviour both in shell/zsh (5.2) and wip/zsh-git. Sending a process to background with bg causes the input to be held (it is not even echoed like in bash case) until the command is killed (from another instance/shell), though the prompt is being displayed correctly. Works fine when sending to background immediately with &. I’m using NetBSD-current built three days ago. Considering zsh works fine for you, it might be just my problem, even though the timing is quite similar. I’m sorry if I’m just adding confusion. I have no idea why it happens. -- Mateusz Poszwa
