Re: linux-next: build failure after merge of the kunit-next tree
Hi Stephen, On 3/1/24 15:30, Shuah Khan wrote: Hi Stephen, On 3/1/24 13:46, Stephen Rothwell wrote: Hi Shuah, On Fri, 1 Mar 2024 09:05:57 -0700 Shuah Khan wrote: On 3/1/24 03:43, Stephen Rothwell wrote: Hi all, On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote: On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote: I can carry the fix through kselftest kunit if it works for all. I'm happy for this to go in with the KUnit changes if that's the best way to keep all of the printk formatting fixes together. Unfortunately you can't fix this in the kunit-next tree without pulling in Linus' tree (or the drm-fixes tree) - which seems excessive. I am pretty sure that the proper fix has been applied to the drm-fixes tree today (in the merge of the drm-misc-fixes tree). I misread your message. What's the commit id for this fix? I Would like to include the details in my pull request to Linus. My mistake, I misread the merge commit. It has not been fixed in the drm-misc-fixes tree or the drm-fixes tree (or Linus' tree since the drm-fixes tree has been merged there) :-( The problem in this case is not with the format string types, but with a missing argument i.e. there is another argument required by the format string. It really should be fixed in the drm-misc-fixes tree and sent to Linus post haste. Agreed. At least the change in the kunit-next tree will stop this happening in the future. I misread you message and asked David to send a fix. I will send pull request with the mention of your fix up to this error in your first message. thanks, -- Shuah
Re: linux-next: build failure after merge of the kunit-next tree
Hi Stephen,
On 2/28/24 21:26, Stephen Rothwell wrote:
Hi all,
After merging the kunit-next tree, today's linux-next build (x86_64
allmodconfig) failed like this:
In file included from drivers/gpu/drm/tests/drm_buddy_test.c:7:
drivers/gpu/drm/tests/drm_buddy_test.c: In function
'drm_test_buddy_alloc_range_bias':
drivers/gpu/drm/tests/drm_buddy_test.c:191:40: error: format '%u' expects a
matching 'unsigned int' argument [-Werror=format=]
191 |"buddy_alloc failed with
bias(%x-%x), size=%u, ps=%u\n",
|
^~~
include/kunit/test.h:597:37: note: in definition of macro '_KUNIT_FAILED'
597 | fmt,
\
| ^~~
include/kunit/test.h:662:9: note: in expansion of macro 'KUNIT_UNARY_ASSERTION'
662 | KUNIT_UNARY_ASSERTION(test,
\
| ^
include/kunit/test.h:1233:9: note: in expansion of macro
'KUNIT_FALSE_MSG_ASSERTION'
1233 | KUNIT_FALSE_MSG_ASSERTION(test,
\
| ^
drivers/gpu/drm/tests/drm_buddy_test.c:186:17: note: in expansion of macro
'KUNIT_ASSERT_FALSE_MSG'
186 | KUNIT_ASSERT_FALSE_MSG(test,
| ^~
drivers/gpu/drm/tests/drm_buddy_test.c:191:91: note: format string is defined
here
191 |"buddy_alloc failed with
bias(%x-%x), size=%u, ps=%u\n",
|
~^
|
|
|
unsigned int
cc1: all warnings being treated as errors
Caused by commit
806cb2270237 ("kunit: Annotate _MSG assertion variants with gnu printf
specifiers")
Thank you. I did allmodconfig build on kselftest kunit branch to make
sure all is well, before I pushed the commits.
interacting with commit
c70703320e55 ("drm/tests/drm_buddy: add alloc_range_bias test")
>
from the drm-misc-fixes tree.
I have applied the following patch for today (this should probably
actually be fixed in the drm-misc-fixes tree).
Danial, David,
I can carry the fix through kselftest kunit if it works
for all.
From: Stephen Rothwell
Date: Thu, 29 Feb 2024 15:18:36 +1100
Subject: [PATCH] fix up for "drm/tests/drm_buddy: add alloc_range_bias test"
Signed-off-by: Stephen Rothwell
---
drivers/gpu/drm/tests/drm_buddy_test.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/gpu/drm/tests/drm_buddy_test.c
b/drivers/gpu/drm/tests/drm_buddy_test.c
index 1e73e3f0d278..369edf587b44 100644
--- a/drivers/gpu/drm/tests/drm_buddy_test.c
+++ b/drivers/gpu/drm/tests/drm_buddy_test.c
@@ -188,7 +188,7 @@ static void drm_test_buddy_alloc_range_bias(struct kunit
*test)
bias_end, size,
ps,
,
DRM_BUDDY_RANGE_ALLOCATION),
- "buddy_alloc failed with bias(%x-%x),
size=%u, ps=%u\n",
+ "buddy_alloc failed with bias(%x-%x),
size=%u\n",
bias_start, bias_end, size);
bias_rem -= size;
thanks,
-- Shuah
Re: linux-next: build failure after merge of the kunit-next tree
Hi Stephen, On 3/1/24 13:46, Stephen Rothwell wrote: Hi Shuah, On Fri, 1 Mar 2024 09:05:57 -0700 Shuah Khan wrote: On 3/1/24 03:43, Stephen Rothwell wrote: Hi all, On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote: On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote: I can carry the fix through kselftest kunit if it works for all. I'm happy for this to go in with the KUnit changes if that's the best way to keep all of the printk formatting fixes together. Unfortunately you can't fix this in the kunit-next tree without pulling in Linus' tree (or the drm-fixes tree) - which seems excessive. I am pretty sure that the proper fix has been applied to the drm-fixes tree today (in the merge of the drm-misc-fixes tree). What's the commit id for this fix? I Would like to include the details in my pull request to Linus. My mistake, I misread the merge commit. It has not been fixed in the drm-misc-fixes tree or the drm-fixes tree (or Linus' tree since the drm-fixes tree has been merged there) :-( The problem in this case is not with the format string types, but with a missing argument i.e. there is another argument required by the format string. It really should be fixed in the drm-misc-fixes tree and sent to Linus post haste. At least the change in the kunit-next tree will stop this happening in the future. Thank you for looking into it. David, please send a fix in as you suggested earlier. I will apply it to avoid compile errors. thanks, -- Shuah
Re: linux-next: build failure after merge of the kunit-next tree
On 3/1/24 03:43, Stephen Rothwell wrote: Hi all, On Fri, 1 Mar 2024 15:15:02 +0800 David Gow wrote: On Thu, 29 Feb 2024 at 23:07, Shuah Khan wrote: I can carry the fix through kselftest kunit if it works for all. I'm happy for this to go in with the KUnit changes if that's the best way to keep all of the printk formatting fixes together. I am pretty sure that the proper fix has been applied to the drm-fixes tree today (in the merge of the drm-misc-fixes tree). What's the commit id for this fix? I Would like to include the details in my pull request to Linus. If this fix is going before the merge window - we are all set. thanks, -- Shuah
Re: [Intel-gfx] [PATCH 02/16] kselftests: Exercise hw-independent mock tests for i915.ko
On 12/07/2016 07:09 AM, Chris Wilson wrote: > On Wed, Dec 07, 2016 at 01:58:19PM +, Chris Wilson wrote: >> Although being a GPU driver most functionality of i915.ko depends upon >> real hardware, many of its internal interfaces can be "mocked" and so >> tested independently of any hardware. Expanding the test coverage is not >> only useful for i915.ko, but should provide some integration tests for >> core infrastructure as well. >> >> Loading i915.ko with mock_selftests=-1 will cause it to execute its mock >> tests then fail with -ENOTTY. If the driver is already loaded and bound >> to hardware, it requires a few more steps to unbind, and so the simple >> preliminary modprobe -r will fail. > > I changed the exit condition to return 0 after successfully completing > the mock tests (when passed mock_selftests=-1) so modprobe reports > success/fail clearly. > -Chris > Hi Chris, Is this patch slated to go in through drm tree with the other patches in the series. Just make sure you create .gitignore for any generated files that should be ignored by git thanks, -- Shuah ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [PATCH 02/16] kselftests: Exercise hw-independent mock tests for i915.ko
Hi Chris, On 12/08/2016 09:01 AM, Chris Wilson wrote: > On Thu, Dec 08, 2016 at 08:50:17AM -0700, Shuah Khan wrote: >> On 12/07/2016 07:09 AM, Chris Wilson wrote: >>> On Wed, Dec 07, 2016 at 01:58:19PM +, Chris Wilson wrote: >>>> Although being a GPU driver most functionality of i915.ko depends upon >>>> real hardware, many of its internal interfaces can be "mocked" and so >>>> tested independently of any hardware. Expanding the test coverage is not >>>> only useful for i915.ko, but should provide some integration tests for >>>> core infrastructure as well. >>>> >>>> Loading i915.ko with mock_selftests=-1 will cause it to execute its mock >>>> tests then fail with -ENOTTY. If the driver is already loaded and bound >>>> to hardware, it requires a few more steps to unbind, and so the simple >>>> preliminary modprobe -r will fail. >>> >>> I changed the exit condition to return 0 after successfully completing >>> the mock tests (when passed mock_selftests=-1) so modprobe reports >>> success/fail clearly. >>> -Chris >>> >> >> Hi Chris, >> >> Is this patch slated to go in through drm tree with the other patches >> in the series. Just make sure you create .gitignore for any generated >> files that should be ignored by git > > If you agree to having it turn up via the drm tree, then yes :) When there is a dependency, it makes sense for it to go through drm. Looks like there are no dependencies in this script. It is now applied to linux-kselftest next for 4.10-rc1 > > Is there any guideline on test behaviour I can read? Is there a > particular directory structure you like? I have a few selftests planned > for i915.ko and core drm.ko, and maybe a few other gpus will join in > over time (certainly should write a few for drivers/gpu/drm/vgem/vgem.ko as > well), is selftests/drivers/gpu/(drm.sh, i915.sh, vgem.sh, etc) > suitable? This test isn't hooked into kselftest run and install as is. I applied it anyway since it doesn't impact anything. If you want these tests run during kselftest run, then add a Makefile for run and install. Good examples for your case are: tools/testing/selftests/firmware tools/testing/selftests/net grep modprobe */* will show you other tests that depend on module being loaded. General guide is if a test can't be run because of module not being there then SKIP without impacting the run with a clear message that test is skipped because module isn't there is good. Kselftest lacks driver test support at the moment and any efforts to add tests is greatly appreciated. So please send patches. thanks, -- Shuah ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [regression] Re: Linux 4.3-rc1
On 09/23/2015 02:56 AM, Daniel Vetter wrote: > Another regression for Jairo to track. > -Daniel Saw the same problem in 4.3-rc2 as well. Not a one time deal and easily reproducible. thanks, -- Shuah > > On Tue, Sep 15, 2015 at 03:26:13AM +0200, Sedat Dilek wrote: >> Hi, >> >> I have reported the same issue in [0]... >> >> You write in [1]... >> >> [ cut here ] >> WARNING: CPU: 3 PID: 24 at drivers/gpu/drm/i915/intel_display.c:1377 >> assert_planes_disabled+0xe4/0x150 [i915]() >> plane A assertion failure, should be disabled but not >> ... >> >> I can confirm this was not seen in v4.2 here on Ubuntu/precise AMD64. >> >> Regards, >> - Sedat - >> >> [0] http://marc.info/?t=14417666342=1=2 >> [1] http://marc.info/?l=linux-kernel=144227950327112=2 > -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
[Intel-gfx] intel_check_page_flip() - WARN_ON(!in_interrupt())
I am seeing the following in the dmesg on 4.0.4 with rt patch [5.720319] [ cut here ] [5.720347] WARNING: CPU: 6 PID: 466 at drivers/gpu/drm/i915/intel_display.c:9748 intel_check_page_flip+0xaa/0xf0 [i915]() [5.720349] WARN_ON(!in_interrupt()) [5.720350] Modules linked in: [5.720376] binfmt_misc rfcomm bnep arc4 eeepc_wmi hid_generic asus_wmi sparse_keymap iwlmvm intel_powerclamp coretemp kvm_intel kvm mac80211 crct10dif_pclmul crc32_pclmul ghash_clmulni_intel aesni_intel aes_x86_64 lrw gf128mul dm_multipath glue_helper snd_hda_codec_hdmi scsi_dh ablk_helper cryptd microcode btusb iwlwifi bluetooth serio_raw cfg80211 i915 snd_hda_codec_realtek snd_hda_codec_generic lpc_ich snd_hda_intel snd_hda_controller snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_seq_midi_event snd_rawmidi drm_kms_helper snd_seq drm video snd_seq_device mac_hid snd_timer snd mei_me wmi mei shpchp soundcore i2c_algo_bit usbhid hid parport_pc ppdev lp parport autofs4 btrfs xor raid6_pq psmouse dm_mirror r8169 ahci dm_region_hash libahci mii dm_log [5.720379] CPU: 6 PID: 466 Comm: irq/32-i915 Not tainted 4.0.4-rt1+ #8 [5.720380] Hardware name: System76, Inc. Wild Dog Performance/H87-PLUS, BIOS 0705 12/05/2013 [5.720382] 0009 8803ea39bc98 817c0694 0002 [5.720383] 8803ea39bce8 8803ea39bcd8 81073d8a 0001 [5.720384] 8803eb184000 8800d7804800 [5.720385] Call Trace: [5.720390] [817c0694] dump_stack+0x4f/0x90 [5.720393] [81073d8a] warn_slowpath_common+0x8a/0xe0 [5.720395] [81073e26] warn_slowpath_fmt+0x46/0x50 [5.720410] [a040bdba] intel_check_page_flip+0xaa/0xf0 [i915] [5.720420] [a03d7888] ironlake_irq_handler+0x2e8/0x1000 [i915] [5.720423] [813e7787] ? debug_smp_processor_id+0x17/0x20 [5.720424] [81074512] ? pin_current_cpu+0x92/0x1d0 [5.720426] [810d0690] ? irq_thread_fn+0x50/0x50 [5.720428] [810d06b7] irq_forced_thread_fn+0x27/0x80 [5.720429] [810d0c4f] irq_thread+0x10f/0x160 [5.720430] [810d0740] ? wake_threads_waitq+0x30/0x30 [5.720432] [810d0b40] ? irq_thread_check_affinity+0x90/0x90 [5.720433] [81093d7b] kthread+0xbb/0xe0 [5.720434] [81093cc0] ? kthread_worker_fn+0x1a0/0x1a0 [5.720436] [817c6bd8] ret_from_fork+0x58/0x90 [5.720437] [81093cc0] ? kthread_worker_fn+0x1a0/0x1a0 [5.720437] ---[ end trace 0002 ]--- There seem to be few past bug reports on this issue. Has this been fixed? Should I be concerned about this? thanks, -- Shuah -- Shuah Khan Sr. Linux Kernel Developer Open Source Innovation Group Samsung Research America (Silicon Valley) shua...@osg.samsung.com | (970) 217-8978 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] [Intel-gift] Linux 3.10-rc7
On 07/10/2013 09:18 AM, Winkler, Tomas wrote: suspend complete. I can start bi-sect of this problem on intel-display scope if you would like me to. Please let me know if the bisect scope should be larger. -- Shuah I got finally an older system where this reproduces consistently, I'm trying to root cause that now. As soon I have something to test I will send it out. I'm not sure why but I'm not able to get the interrupt from the device until all the devices has resumed after that the mei reset is successful and device work as expected. I need to fix the state machine so the reset won't go crazy on resetting actually I did that and it reduces resets into two but I'm still trying to figure out what's going on. The regression coming from the fact that I've linearize the reset flow, it waits for interrupt to arrive, before that the flow gave up and has restarted directly from the interrupt thread. Thanks Tomas Tomas, This might be a shot in the dark. Commit mei: me: clear interrupts on the resume path (42f132febff3b7b42c6c9dbfc151f29233be3132), clears pending interrupts in mei_me_pci_resume(). Your comment about not seeing interrupt until mei reset is successful got me wondering, if clearing pending interrupts is causing this? I don't see mei_me_pci_suspend() calling mei_disable_interrupts() and pci_disable_msi(). I don't see a call to mei_enable_interrupts() from mei_me_pci_resume(). I don't think mei_enable_interrupts() is used anywhere. pci_dev_msi_enabled() enables the interrupts in mei_me_pci_resume() looks like. However, I did notice one thing, if pci_dev_msi_enabled() returns false, request_threaded_irq() is called with IRQF_SHARED. Again might just be fine, it leads me to the next question. mei_me_pci_suspend() has code that runs after disabling interrupts. Does this need to be split into suspend() and suspend_noirq() ops, since the IRQ could be shared? It is a possibility if pci_enable_msi() takes longer in resume path and pci_dev_msi_enabled() returns false, then IRQF_SHARED is requested. Don't know if this helpful, but I thought I would ask just in case, it helps you think of something you didn't before. Please let me know if you need help gathering data from my system. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.10-rc7
On 06/26/2013 04:24 PM, Shuah Khan wrote: On 06/26/2013 04:12 PM, Winkler, Tomas wrote: 42f132f mei: me: clear interrupts on the resume path 2753ff5 mei: nfc: fix nfc device freeing 5e85b36 mei: init: Flush scheduled work before resetting the device Are you sure you have these 3 in? Checked the git log and yes I have all three commits. It appears this problem is intermittent and hard to reproduce at least on 3.10-rc7. I tried several times yesterday to capture the log and couldn't reproduce. -- Shuah Tomas, I saw the mei_me problem again, however couldn't save the logs. I am getting into the habit of saving dmesg as soon as system gets resumed to catch the dmesg buffer prior to mei getting into this state. There is another difference in suspend sequence between 3.9.8 and 3.10-rc6 and rc-7. When I do echo disk state, Screen clears and instead of going into console mode like it does on 3.9.8, it will get back into graphics mode and show the screen exactly the way it was right after echo disk state command was issued. It stays in that state for good 60 seconds or more and then I see the suspend complete. I can start bi-sect of this problem on intel-display scope if you would like me to. Please let me know if the bisect scope should be larger. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.10-rc7
On 06/25/2013 02:06 PM, Jesse Barnes wrote: On Tue, 25 Jun 2013 19:59:28 + Shuah Khan shuah...@samsung.com wrote: On 06/25/2013 01:52 PM, Jesse Barnes wrote: On Tue, 25 Jun 2013 21:37:37 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Adding more lists to cc + Jesse since he's the guilty one for the vt-switchless state restore stuff. Yeah, looks like we don't fetch the PLL state on resume from hibernate, leading to this warning. The refcount is nonzero, indicating the pll is in use, but the active field is clear, which means we're missing an update somewhere. Shuah, just to confirm, does your resume actually work ok aside from the warning? I *think* it's harmless in this case, but does indicate a real bug in our state tracking... trying to come up with a patch now. Thanks, Resume works just fine. I see it take longer for it to suspend compared to 3.9.7 and then resumes just fine. Suspend taking longer very well could be because of this warn_on. Other than this warn_on I haven't noticed any other problems. Here's the patch I'm testing now, can you give it a try? Jesse, With this patch warn_on went away. Resume worked. I started seeing: [ 78.733062] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.733079] mei_me :00:16.0: reset: wrong host start response [ 78.733082] mei_me :00:16.0: unexpected reset: dev_state = RESETTING over and over again after resume from reboot mode suspend. dmesg filled up with these messages. I did suspend to disk shutdown mode right away. Resume worked, no warn_ons, and no mei_me messages. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.10-rc7
On 06/25/2013 01:52 PM, Jesse Barnes wrote: On Tue, 25 Jun 2013 21:37:37 +0200 Daniel Vetter daniel.vet...@ffwll.ch wrote: Adding more lists to cc + Jesse since he's the guilty one for the vt-switchless state restore stuff. Yeah, looks like we don't fetch the PLL state on resume from hibernate, leading to this warning. The refcount is nonzero, indicating the pll is in use, but the active field is clear, which means we're missing an update somewhere. Shuah, just to confirm, does your resume actually work ok aside from the warning? I *think* it's harmless in this case, but does indicate a real bug in our state tracking... trying to come up with a patch now. Thanks, Resume works just fine. I see it take longer for it to suspend compared to 3.9.7 and then resumes just fine. Suspend taking longer very well could be because of this warn_on. Other than this warn_on I haven't noticed any other problems. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.10-rc7
On 06/25/2013 02:57 PM, Tomas Winkler wrote: On Tue, Jun 25, 2013 at 11:51 PM, Shuah Khan shuah...@samsung.com wrote: With this patch warn_on went away. Resume worked. I started seeing: [ 78.733062] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.733079] mei_me :00:16.0: reset: wrong host start response [ 78.733082] mei_me :00:16.0: unexpected reset: dev_state = RESETTING over and over again after resume from reboot mode suspend. dmesg filled up with these messages. Can you please send me the log part when this starts? Thanks It rolled over and I don't have prior messages. I tried reproducing twice and didn't see it again. I will try a few more times and see if I can get it to happen again. This is what I could save before dmesg rolled over: [ 78.709014] mei_me :00:16.0: reset: wrong host start response [ 78.709016] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.709029] mei_me :00:16.0: reset: unexpected enumeration response hbm. [ 78.709031] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.709069] mei_me :00:16.0: reset: wrong host start response -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
Re: [Intel-gfx] Linux 3.10-rc7
On 06/26/2013 04:12 PM, Winkler, Tomas wrote: Can you please send me the log part when this starts? Thanks It rolled over and I don't have prior messages. I tried reproducing twice and didn't see it again. I will try a few more times and see if I can get it to happen again. This is what I could save before dmesg rolled over: [ 78.709014] mei_me :00:16.0: reset: wrong host start response [ 78.709016] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.709029] mei_me :00:16.0: reset: unexpected enumeration response hbm. [ 78.709031] mei_me :00:16.0: unexpected reset: dev_state = RESETTING [ 78.709069] mei_me :00:16.0: reset: wrong host start response So far I was able to positively reproduce it with 3.10-rc5 but not with 3.10-rc7 and above. There are 3 patches that went in to fix this issue 42f132f mei: me: clear interrupts on the resume path 2753ff5 mei: nfc: fix nfc device freeing 5e85b36 mei: init: Flush scheduled work before resetting the device Are you sure you have these 3 in? Checked the git log and yes I have all three commits. It appears this problem is intermittent and hard to reproduce at least on 3.10-rc7. I tried several times yesterday to capture the log and couldn't reproduce. -- Shuah Shuah Khan, Linux Kernel Developer - Open Source Group Samsung Research America (Silicon Valley) shuah...@samsung.com | (970) 672-0658 ___ Intel-gfx mailing list Intel-gfx@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/intel-gfx
