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