I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able
to work with an HP ZR30w 30 2560x1600 display. I saw the following
messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
[1] drm-intel-next-queued branch at
git://people.freedesktop.org/~danvet/drm-intel
Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree
On Sat, Nov 03, 2012 at 11:21:58AM +0100, Daniel Vetter wrote:
Well, we know for sure that fdi link training is broken - it doesn't match
at all what the spec says we should do. I've been working on this lately,
since in quite a few circumstances the link train fails without the
relevent
On Fri, Nov 04, 2016 at 01:38:25PM -0700, Linus Torvalds wrote:
> On Wed, Nov 2, 2016 at 5:31 PM, Dave Airlie wrote:
> >
> > There are a set of fixes for an oops we've been seeing around MST
> > display unplug,
>
> Side note: I heard from a couple of people at the KS that said that
> they had
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
> On 2 September 2014 14:05, Theodore Ts'o wrote:
> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> > longer see the my Dell 30" monitor when it is connected via the
> > docking s
This morning, I was docked and using a Dell 30" monitor. I
reconfigured the X server to stop sending video to the external
monitor, suspended the laptop, and after it was suspended undocked it
and took it to work. Then I docked it at work, where it was connected
to a powered off Dell 24"
pful; if there's anything more debugging
information I can get, let me know!!
- Ted
On Tue, Sep 02, 2014 at 12:05:27AM -0400, Theodore Ts'o wrote:
> I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> longer see the my Dell 30" m
On Mon, Dec 08, 2014 at 12:32:01PM +1000, Dave Airlie wrote:
>
> I suspect a lot of the problems are just that xfce isn't sufficiently handling
> randr events, and it is getting out of sync, it is like hotplug networking
> before NetworkManager etc.
Yes, I've seen this on XFCE 4.11 (in Ubuntu),
On Mon, Aug 03, 2015 at 05:27:29PM +0200, Daniel Vetter wrote:
>
> Ok I updated fixes-stuff with just 2 patches which seem to be enough to
> fix it. Plus a patch to convert Linus' hack into something we can keep
> plus a drive-by WARNING fix in mst that got in the way for me.
>
> Seems to work
On Mon, Aug 03, 2015 at 10:24:53AM -0700, Linus Torvalds wrote:
> On Mon, Aug 3, 2015 at 9:25 AM, Theodore Ts'o wrote:
> >
> > I've just tried pulling in your updated fixes-stuff, and it avoids the
> > oops and allows external the monitor to work correctly.
>
> Good
I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
longer see the my Dell 30" monitor when it is connected via the
docking station using a Displayport connector. This worked using 3.16
kernel.
If I connect to the monitor using the mini-display, by passing the
docking station,
On Tue, Sep 02, 2014 at 02:15:39PM +1000, Dave Airlie wrote:
> On 2 September 2014 14:05, Theodore Ts'o wrote:
> > I recently upgraded to v3.17-rc3, and on my Lenovo T540p, I can no
> > longer see the my Dell 30" monitor when it is connected via the
> > docking s
On Tue, Sep 02, 2014 at 09:23:16PM +1000, Dave Airlie wrote:
>
> Interesting, I have the same combo of hw available on my desk at work,
> but it might be a couple of days before I can get to the office to
> debug it,
>
> can you boot with drm.debug=6 and get me the dmesg?
I'll do that when I
Ping?
On Tue, Oct 30, 2012 at 04:32:21PM -0400, Theodore Ts'o wrote:
> On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
> > > [1] drm-intel-next-queued branch at
> > > git://people.freedesktop.org/~danvet/drm-intel
> >
> > Hmm, actually not. Either
On Sat, Nov 03, 2012 at 11:21:58AM +0100, Daniel Vetter wrote:
>
> Well, we know for sure that fdi link training is broken - it doesn't match
> at all what the spec says we should do. I've been working on this lately,
> since in quite a few circumstances the link train fails without the
>
On Thu, Apr 10, 2014 at 12:14:27PM -0700, Andy Lutomirski wrote:
>
> This is the second time in a week that someone has asked for a way to
> have a struct file (or struct inode or whatever) that can't be reopened
> through /proc/pid/fd. This should be quite easy to implement as a
> separate
I recently upgraded to 3.6.3, and my Lenovo X230 has stopped being able
to work with an HP ZR30w 30" 2560x1600 display. I saw the following
messages in the dmesg:
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 1 fail!
[drm:ivb_manual_fdi_link_train] *ERROR* FDI train 2 fail!
.. which I
On Tue, Oct 30, 2012 at 01:57:27PM +0200, Jani Nikula wrote:
> > [1] drm-intel-next-queued branch at
> > git://people.freedesktop.org/~danvet/drm-intel
>
> Hmm, actually not. Either drm-intel-fixes branch, or Linus' master.
Confirmed, the drm-intel-fixes branch from Daniel's tree
Unfortunately the failure causes a series of recursive faults and I
haven't been able to capture the stack trace, but on 4.2-rcX kernels,
I can reliably cause the system to crash if my T540p is booted with
the docking station attached.
It will also crash if I boot the system first, and then
On Wed, Jul 29, 2015 at 08:49:37PM -0400, Theodore Ts'o wrote:
>
> Unfortunately the failure causes a series of recursive faults and I
> haven't been able to capture the stack trace, but on 4.2-rcX kernels,
> I can reliably cause the system to crash if my T540p is booted with
&
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> On Wed, Jul 29, 2015 at 10:18:16PM -0700, Linus Torvalds wrote:
> > drivers/gpu/drm/drm_atomic_helper.c | 8 +---
> > 1 file changed, 5 insertions(+), 3 deletions(-)
> >
> > diff --git a/drivers/gpu/drm/drm_atomic_helper.c
> >
On Thu, Jul 30, 2015 at 04:40:02PM +0200, Daniel Vetter wrote:
> I have 4 patches in git://people.freedesktop.org/~danvet/drm fixes-stuff
> but I couldn't test them yet since no dp mst here and I didn't find
> anything that would ship faster than 1-2 weeks yet. I'll try to get some
> other people
On Thu, Jul 30, 2015 at 11:50:29AM -0400, Theodore Ts'o wrote:
> I've tried pulling in your patches from fixes-stuff, onto Linus's tree
> (without Linus's fix), and the good news is that I'm no longer
> crashing on boot.
>
> The *bad* news is that (a) it breaks the external m
On Fri, Jun 21, 2019 at 08:59:48AM -0600, shuah wrote:
> > > ### But wait! Doesn't kselftest support in kernel testing?!
> > >
> > >
>
> I think I commented on this before. I agree with the statement that
> there is no overlap between Kselftest and KUnit. I would like see this
> removed.
On Thu, May 09, 2019 at 01:52:15PM +0200, Knut Omang wrote:
> 1) Tests that exercises typically algorithmic or intricate, complex
>code with relatively few outside dependencies, or where the dependencies
>are considered worth mocking, such as the basics of container data
>structures
On Thu, May 09, 2019 at 04:20:05PM -0600, Logan Gunthorpe wrote:
>
> The second item, arguably, does have significant overlap with kselftest.
> Whether you are running short tests in a light weight UML environment or
> higher level tests in an heavier VM the two could be using the same
>
On Thu, May 09, 2019 at 11:12:12AM -0700, Frank Rowand wrote:
>
>"My understanding is that the intent of KUnit is to avoid booting a kernel
> on
>real hardware or in a virtual machine. That seems to be a matter of
> semantics
>to me because isn't invoking a UML Linux just running
On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> However, the reply is incorrect. Kselftest in-kernel tests (which
> is the context here) can be configured as built in instead of as
> a module, and built in a UML kernel. The UML kernel can boot,
> running the in-kernel tests
On Tue, May 14, 2019 at 05:26:47PM -0700, Frank Rowand wrote:
> On 5/11/19 10:33 AM, Theodore Ts'o wrote:
> > On Fri, May 10, 2019 at 02:12:40PM -0700, Frank Rowand wrote:
> >> However, the reply is incorrect. Kselftest in-kernel tests (which
> >> is the context here)
On Thu, May 09, 2019 at 05:40:48PM -0600, Logan Gunthorpe wrote:
>
> Based on some of the other commenters, I was under the impression that
> kselftests had in-kernel tests but I'm not sure where or if they exist. If
> they do exists, it seems like it would make sense to convert those to kunit
>
On Thu, May 09, 2019 at 10:11:01PM -0700, Frank Rowand wrote:
> >> You *can* run in-kernel test using modules; but there is no framework
> >> for the in-kernel code found in the test modules, which means each of
> >> the in-kernel code has to create their own in-kernel test
> >> infrastructure.
>
On Wed, May 08, 2019 at 07:13:59PM -0700, Frank Rowand wrote:
> > If you want to use vice grips as a hammer, screwdriver, monkey wrench,
> > etc. there's nothing stopping you from doing that. But it's not fair
> > to object to other people who might want to use better tools.
> >
> > The reality
On Wed, May 08, 2019 at 05:58:49PM -0700, Frank Rowand wrote:
>
> If KUnit is added to the kernel, and a subsystem that I am submitting
> code for has chosen to use KUnit instead of kselftest, then yes, I do
> *have* to use KUnit if my submission needs to contain a test for the
> code unless I
On Wed, May 08, 2019 at 05:43:35PM -0700, Frank Rowand wrote:
> kselftest provides a mechanism for in-kernel tests via modules. For
> example, see:
>
> tools/testing/selftests/vm/run_vmtests invokes:
> tools/testing/selftests/vm/test_vmalloc.sh
> loads module:
> test_vmalloc
On Tue, May 07, 2019 at 10:01:19AM +0200, Greg KH wrote:
> > My understanding is that the intent of KUnit is to avoid booting a kernel on
> > real hardware or in a virtual machine. That seems to be a matter of
> > semantics
> > to me because isn't invoking a UML Linux just running the Linux
On Thu, Jun 17, 2021 at 10:16:57AM -0500, Alex Sierra wrote:
> v1:
> AMD is building a system architecture for the Frontier supercomputer with a
> coherent interconnect between CPUs and GPUs. This hardware architecture allows
> the CPUs to coherently access GPU device memory. We have hardware in
On Mon, May 10, 2021 at 02:49:44PM +0100, David Woodhouse wrote:
> On Mon, 2021-05-10 at 13:55 +0200, Mauro Carvalho Chehab wrote:
> > This patch series is doing conversion only when using ASCII makes
> > more sense than using UTF-8.
> >
> > See, a number of converted documents ended with weird
On Wed, May 12, 2021 at 02:50:04PM +0200, Mauro Carvalho Chehab wrote:
> v2:
> - removed EM/EN DASH conversion from this patchset;
Are you still thinking about doing the
EN DASH --> "--"
EM DASH --> "---"
conversion? That's not going to change what the documentation will
look like in the HTML
il.
>
> Signed-off-by: Ralph Campbell
> Signed-off-by: Alex Sierra
> Reviewed-by: Christoph Hellwig
Acked-by: Theodore Ts'o
On Fri, Mar 04, 2022 at 09:42:37AM +0900, Byungchul Park wrote:
>
> All contexts waiting for any of the events in the circular dependency
> chain will be definitely stuck if there is a circular dependency as I
> explained. So we need another wakeup source to break the circle. In
> ext4 code, you
On Fri, Mar 04, 2022 at 12:20:02PM +0900, Byungchul Park wrote:
>
> I found a point that the two wait channels don't lead a deadlock in
> some cases thanks to Jan Kara. I will fix it so that Dept won't
> complain it.
I sent my last (admittedly cranky) message before you sent this. I'm
glad you
On Sat, Mar 05, 2022 at 11:55:34PM +0900, Byungchul Park wrote:
> > that is why some of the DEPT reports were completely incomprehensible
>
> It's because you are blinded to blame at it without understanding how
> Dept works at all. I will fix those that must be fixed. Don't worry.
Users of DEPT
On Wed, Mar 16, 2022 at 11:26:12AM +0900, Byungchul Park wrote:
> I'm gonna re-add RFC for a while at Ted's request. But hard testing is
> needed to find false alarms for now that there's no false alarm with my
> system. I'm gonna look for other systems that might produce false
> alarms. And it'd
On Sun, Mar 06, 2022 at 07:51:42PM +0900, Byungchul Park wrote:
> >
> > Users of DEPT must not have to understand how DEPT works in order to
>
> Users must not have to understand how Dept works for sure, and haters
> must not blame things based on what they guess wrong.
For the record, I don't
On Thu, Feb 17, 2022 at 07:57:36PM +0900, Byungchul Park wrote:
>
> I've got several reports from the tool. Some of them look like false
> alarms and some others look like real deadlock possibility. Because of
> my unfamiliarity of the domain, it's hard to confirm if it's a real one.
> Let me add
On Mon, Feb 28, 2022 at 11:14:44AM +0100, Jan Kara wrote:
> > case 1. Code with an actual circular dependency, but not deadlock.
> >
> >A circular dependency can be broken by a rescue wakeup source e.g.
> >timeout. It's not a deadlock. If it's okay that the contexts
> >participating
On Thu, Feb 17, 2022 at 12:00:05PM -0500, Steven Rostedt wrote:
>
> I personally believe that there's potential that this can be helpful and we
> will want to merge it.
>
> But, what I believe Ted is trying to say is, if you do not know if the
> report is a bug or not, please do not ask the
On Thu, Mar 03, 2022 at 10:00:33AM +0900, Byungchul Park wrote:
>
> Unfortunately, it's neither perfect nor safe without another wakeup
> source - rescue wakeup source.
>
>consumer producer
>
> lock L
> (too much
On Thu, Mar 03, 2022 at 02:23:33PM +0900, Byungchul Park wrote:
> I totally agree with you. *They aren't really locks but it's just waits
> and wakeups.* That's exactly why I decided to develop Dept. Dept is not
> interested in locks unlike Lockdep, but fouces on waits and wakeup
> sources itself.
On Thu, Feb 10, 2022 at 06:30:23PM -0800, Qing Wang wrote:
> From: Wang Qing
>
> It is better to use time_is_xxx() directly instead of jiffies judgment
> for understanding.
Hi Wang,
"judgement" doesn't really make sense as a description to an English
speaker. The following a commit desription
On Fri, Mar 18, 2022 at 04:49:45PM +0900, Byungchul Park wrote:
>
> I guess it was becasue of the commit b1fca27d384e8("kernel debug:
> support resetting WARN*_ONCE"). Your script seems to reset WARN*_ONCE
> repeatedly.
I wasn't aware this was being done, but your guess was correct. The
On Wed, May 11, 2022 at 06:33:32AM -0700, Rob Clark wrote:
>
> And ofc we want the expectations to be in the kernel tree because
> there could be, for example, differences between -fixes and -next
> branches. (Or even stable kernel branches if/when we get to the point
> of running CI on those.)
On Thu, May 12, 2022 at 08:18:24PM +0900, Byungchul Park wrote:
> I have a question about this one. Yes, it would never been stuck thanks
> to timeout. However, IIUC, timeouts are not supposed to expire in normal
> cases. So I thought a timeout expiration means not a normal case so need
> to
I tried DEPT-v6 applied against 5.18-rc5, and it reported the
following positive.
The reason why it's nonsense is that in context A's [W] wait:
[ 1538.545054] [W] folio_wait_bit_common(pglocked:0):
[ 1538.545370] [] __filemap_get_folio+0x3e4/0x420
[ 1538.545763] stacktrace:
[ 1538.545928]
Oh, one other problem with DEPT --- it's SLOW --- the overhead is
enormous. Using kvm-xfstests[1] running "kvm-xfstests smoke", here
are some sample times:
LOCKDEP DEPT
Time to first test 49 seconds 602 seconds
ext4/0012 s 22
On Tue, May 10, 2022 at 09:32:13AM +0900, Byungchul Park wrote:
> Yes, right. DEPT has never been optimized. It rather turns on
> CONFIG_LOCKDEP and even CONFIG_PROVE_LOCKING when CONFIG_DEPT gets on
> because of porting issue. I have no choice but to rely on those to
> develop DEPT out of tree.
On Wed, Dec 14, 2022 at 05:21:17PM +0100, Stanislaw Gruszka wrote:
> On Wed, Dec 14, 2022 at 04:15:49PM +0100, Eric Dumazet wrote:
> > On Wed, Dec 14, 2022 at 1:34 PM Stanislaw Gruszka
> > wrote:
> > >
> > > On Mon, Dec 12, 2022 at 03:35:20PM +0100, Jason A. Donenfeld wrote:
> > > > Please CC me
Note: in the future, I'd recommend looking at the MAINTAINERS to
figure out a smaller list of people to ask this question, instead of
spamming everyone who has ever expressed interest in DEPT.
On Fri, Nov 04, 2022 at 02:56:32PM +0900, Byungchul Park wrote:
> Peterz (commit 34a3d1e8370870
58 matches
Mail list logo
