Re: [Call for testers] DRM device-independent code update to Linux 3.8

From: Miguel Clara <miguelmclara_at_gmail.com>
Date: Wed, 18 Feb 2015 19:35:56 +0000
On Wed, Feb 18, 2015 at 12:09 AM, Lundberg, Johannes <
johannes_at_brilliantservice.co.jp> wrote:

> Hi
>
> Good job! Will do some testing!  As for the i915 driver, what versions are
> supported?  Up until and including HD4000 Gen7 Ivy bridge?
>
> --
> Johannes Lundberg
> BRILLIANTSERVICE CO., LTD.
>
> On Wed, Feb 18, 2015 at 8:45 AM, Jean-Sébastien Pédron <
> dumbbell_at_freebsd.org
> > wrote:
>
> > Hi!
> >
> > An update to the DRM subsystem, not including the drivers, is ready for
> > wider testing!
> >
> > The patch against HEAD is here:
> > https://people.freebsd.org/~dumbbell/graphics/drm-update-38.f.patch
> >
> > I'm interested in success/failure reports for amd64, powerpc and
> > powerpc64 users, for i915 and Radeon GPUs. I already know there is a
> > build issue on i386, please wait for the next patch if you are in this
> > case.
> >
> > The changes brought by this patch are explained in a blog post:
> > http://blogs.freebsdish.org/graphics/2015/02/18/testing-the-drm-update/
> >
> > This is working well for some Radeon users for more than a year.
> > However, it only started to work with i915 a month ago, when the i915
> > refresh was committed.
> >
> > Try your day-to-day applications, try suspend/resume, try all output
> > connectors, try OpenGL stuff, try backlight controls, everything :)
>

Testing suspend/resume by closing/opening the LID works for me but  I did
get this:

lock order reversal:
 1st 0xfffffe0000e1c728 ath0 (ath0) _at_ /usr/src/sys/dev/ath/if_ath.c:6654
 2nd 0xfffffe0000fc1838 ath0_node_lock (ath0_node_lock) _at_
/usr/src/sys/net80211/ieee80211_node.c:1824
KDB: stack backtrace:
db_trace_self_wrapper() at db_trace_self_wrapper+0x2b/frame
0xfffffe0115c71790
witness_checkorder() at witness_checkorder+0xe45/frame 0xfffffe0115c71820
__mtx_lock_flags() at __mtx_lock_flags+0xa8/frame 0xfffffe0115c71870
ieee80211_node_delucastkey() at ieee80211_node_delucastkey+0x52/frame
0xfffffe0115c718c0
node_free() at node_free+0x25/frame 0xfffffe0115c718e0
ieee80211_tx_complete() at ieee80211_tx_complete+0x2c/frame
0xfffffe0115c71900
ath_tx_draintxq() at ath_tx_draintxq+0x22/frame 0xfffffe0115c71930
ath_edma_tx_drain() at ath_edma_tx_drain+0x10d/frame 0xfffffe0115c71970
ath_stop_locked() at ath_stop_locked+0x148/frame 0xfffffe0115c719a0
ath_ioctl() at ath_ioctl+0x223/frame 0xfffffe0115c719e0
taskqueue_run_locked() at taskqueue_run_locked+0xf0/frame 0xfffffe0115c71a40
taskqueue_thread_loop() at taskqueue_thread_loop+0x9b/frame
0xfffffe0115c71a70
fork_exit() at fork_exit+0x84/frame 0xfffffe0115c71ab0
fork_trampoline() at fork_trampoline+0xe/frame 0xfffffe0115c71ab0
--- trap 0, rip = 0, rsp = 0xfffffe0115c71b70, rbp = 0 ---


So something fails in the ath side, which I'm guesssing I should report to
the wireless list?


As for backlight I still have no control of that, unless I use
intel_backlight or the patch proposed a while back which adds
"hw.dri.0.i915_backlight"

The latptop I just tested is an Acer S3-391 Ivy Bridge and I only have the
single card (I have another with dual graphics that I'll test later) the
hardware keys for backlight control in this one are "Fn-Left/Right Arrow".



> >
> > Thank you!
> >
> > --
> > Jean-Sébastien Pédron
> >
> >
>
> --
Received on Wed Feb 18 2015 - 18:36:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:55 UTC