August 2020 - Alsa-devel - mailman.alsa-project.org

[PATCH] ALSA: hda: Refactor calculating SDnFMT according to specification
by Pawel Harlozinski 02 Sep '20

02 Sep '20

Fix setting SDnFMT based on High Definition Audio Specification Rev. 1.0a page 48. Bits per Sample (BITS): 000 = 8 bits. The data will be packed in memory in 8-bit containers on 16-bit boundaries. 001 = 16 bits. The data will be packed in memory in 16-bit containers on 16-bit boundaries. 010 = 20 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 011 = 24 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 100 = 32 bits. The data will be packed in memory in 32-bit containers on 32-bit boundaries. 101-111 = Reserved Set SDnFMT depending on which format was given, as maxbps only describes container size. Henceforth split cases for formats 20, 24, 32 bits. For format SNDRV_PCM_FORMAT_FLOAT_LE width is equal 32 so as previously it will end up with mask for 32 bits. Signed-off-by: Pawel Harlozinski <pawel.harlozinski(a)linux.intel.com> --- sound/hda/hdac_device.c | 11 +++++------ 1 file changed, 5 insertions(+), 6 deletions(-) diff --git a/sound/hda/hdac_device.c b/sound/hda/hdac_device.c index 333220f0f8af..2ccf79866f99 100644 --- a/sound/hda/hdac_device.c +++ b/sound/hda/hdac_device.c @@ -762,14 +762,13 @@ unsigned int snd_hdac_calc_stream_format(unsigned int rate, val |= AC_FMT_BITS_16; break; case 20: + val |= AC_FMT_BITS_20; + break; case 24: + val |= AC_FMT_BITS_24; + break; case 32: - if (maxbps >= 32 || format == SNDRV_PCM_FORMAT_FLOAT_LE) - val |= AC_FMT_BITS_32; - else if (maxbps >= 24) - val |= AC_FMT_BITS_24; - else - val |= AC_FMT_BITS_20; + val |= AC_FMT_BITS_32; break; default: return 0; -- 2.17.1

4 4

[bug report] 'ASoC: Intel: haswell: Power transition refactor' and PulseAudio
by Christian Bundy 01 Sep '20

01 Sep '20

After upgrading to Linux 5.8 I discovered an audio issue on my device that was introduced in 8ec7d6043263ecf250b9b7c0dd8ade899487538a [0]. I used 'git bisect' to identify the commit that introduced the bug and have confirmed that reverting the commit resolves the problem Reproduction: 1. Play any audio via PulseAudio. 2. Observe that the audio output is fuzzy and choppy. I can use programs like mpv to play audio without PulseAudio, and the audio is fine, but as soon as I open a process that uses PulseAudio it will ruin the audio output for all processes (including mpv) until I reboot. I'm using a 2015 Chromebook Pixel ("Samus") and have confirmed this problem with a friend who has the same device. Is there anything I can do to help debug this instead of sending a patch to revert the commit? Relevant lspci output: 00:03.0 Audio device: Intel Corporation Broadwell-U Audio Controller (rev 09) Subsystem: Intel Corporation Broadwell-U Audio Controller Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 50 Region 0: Memory at e1218000 (64-bit, non-prefetchable) [size=16K] Capabilities: [50] Power Management version 2 Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst- PME-Enable- DSel=0 DScale=0 PME- Capabilities: [60] MSI: Enable+ Count=1/1 Maskable- 64bit- Address: fee00378 Data: 0000 Capabilities: [70] Express (v1) Root Complex Integrated Endpoint, MSI 00 DevCap: MaxPayload 128 bytes, PhantFunc 0 ExtTag- RBE- FLReset+ DevCtl: CorrErr- NonFatalErr- FatalErr- UnsupReq- RlxdOrd- ExtTag- PhantFunc- AuxPwr- NoSnoop- FLReset- MaxPayload 128 bytes, MaxReadReq 128 bytes DevSta: CorrErr- NonFatalErr- FatalErr- UnsupReq- AuxPwr- TransPend- Kernel driver in use: snd_hda_intel Kernel modules: snd_hda_intel [0]: https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?h=…

4 7

[PATCH] soundwire: fix error handling
by trix＠redhat.com 01 Sep '20

01 Sep '20

From: Tom Rix <trix(a)redhat.com> clang static analysis flags this problem stream.c:844:9: warning: Use of memory after it is freed kfree(bus->defer_msg.msg->buf); ^~~~~~~~~~~~~~~~~~~~~~~ This happens in an error handler cleaning up memory allocated for elements in a list. list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; kfree(bus->defer_msg.msg->buf); kfree(bus->defer_msg.msg); } And is triggered when the call to sdw_bank_switch() fails. There are a two problems. First, when sdw_bank_switch() fails, though it frees memory it does not clear bus's reference 'defer_msg.msg' to that memory. The second problem is the freeing msg->buf. In some cases msg will be NULL so this will dereference a null pointer. Need to check before freeing. Fixes: 99b8a5d608a6 ("soundwire: Add bank switch routine") Signed-off-by: Tom Rix <trix(a)redhat.com> --- drivers/soundwire/stream.c | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/drivers/soundwire/stream.c b/drivers/soundwire/stream.c index 37290a799023..6e36deb505b1 100644 --- a/drivers/soundwire/stream.c +++ b/drivers/soundwire/stream.c @@ -717,6 +717,7 @@ static int sdw_bank_switch(struct sdw_bus *bus, int m_rt_count) kfree(wbuf); error_1: kfree(wr_msg); + bus->defer_msg.msg = NULL; return ret; } @@ -840,9 +841,10 @@ static int do_bank_switch(struct sdw_stream_runtime *stream) error: list_for_each_entry(m_rt, &stream->master_list, stream_node) { bus = m_rt->bus; - - kfree(bus->defer_msg.msg->buf); - kfree(bus->defer_msg.msg); + if (bus->defer_msg.msg) { + kfree(bus->defer_msg.msg->buf); + kfree(bus->defer_msg.msg); + } } msg_unlock: -- 2.18.1

5 8

[PATCH] ASoC: rt5682: Prefer async probe
by Douglas Anderson 01 Sep '20

01 Sep '20

The probe of rt5682 is pretty slow. A quick measurement shows that it takes ~650 ms on at least one board. There's no reason to block all other drivers waiting for this probe to finish. Set the flag to allow other drivers to probe while we're probing. Signed-off-by: Douglas Anderson <dianders(a)chromium.org> --- NOTE: I haven't done any analysis of the driver to see _why_ it's so slow, only that I have measured it to be slow. Someone could certainly take the time to profile / optimize it, but in any case it still won't hurt to be async. This is a very safe flag to turn on since: 1. It's not like our probe order was defined by anything anyway. When we probe is at the whim of when our i2c controller probes and that can be any time. 2. If some other driver needs us then they have to handle the fact that we might not have probed yet anyway. 3. There may be other drivers probing at the same time as us anyway because _they_ used async probe. While I won't say that it's impossible to tickle a bug by turning on async probe, I would assert that in almost all cases the bug was already there and needed to be fixed anyway. sound/soc/codecs/rt5682-i2c.c | 1 + 1 file changed, 1 insertion(+) diff --git a/sound/soc/codecs/rt5682-i2c.c b/sound/soc/codecs/rt5682-i2c.c index 85aba311bdc8..6b4e0eb30c89 100644 --- a/sound/soc/codecs/rt5682-i2c.c +++ b/sound/soc/codecs/rt5682-i2c.c @@ -294,6 +294,7 @@ static struct i2c_driver rt5682_i2c_driver = { .name = "rt5682", .of_match_table = rt5682_of_match, .acpi_match_table = rt5682_acpi_match, + .probe_type = PROBE_PREFER_ASYNCHRONOUS, }, .probe = rt5682_i2c_probe, .shutdown = rt5682_i2c_shutdown, -- 2.28.0.402.g5ffc5be6b7-goog

4 3

[PATCH 1/2] ASoC: wm8994: Skip setting of the WM8994_MICBIAS register for WM1811
by Sylwester Nawrocki 01 Sep '20

01 Sep '20

The WM8994_MICBIAS register is not available in the WM1811 CODEC so skip initialization of that register for that device. This suppresses an error during boot: "wm8994-codec: ASoC: error at snd_soc_component_update_bits on wm8994-codec" Signed-off-by: Sylwester Nawrocki <s.nawrocki(a)samsung.com> --- sound/soc/codecs/wm8994.c | 2 ++ sound/soc/codecs/wm_hubs.c | 3 +++ sound/soc/codecs/wm_hubs.h | 1 + 3 files changed, 6 insertions(+) diff --git a/sound/soc/codecs/wm8994.c b/sound/soc/codecs/wm8994.c index 038be66..b3ba053 100644 --- a/sound/soc/codecs/wm8994.c +++ b/sound/soc/codecs/wm8994.c @@ -4193,11 +4193,13 @@ static int wm8994_component_probe(struct snd_soc_component *component) wm8994->hubs.dcs_readback_mode = 2; break; } + wm8994->hubs.micd_scthr = true; break; case WM8958: wm8994->hubs.dcs_readback_mode = 1; wm8994->hubs.hp_startup_mode = 1; + wm8994->hubs.micd_scthr = true; switch (control->revision) { case 0: diff --git a/sound/soc/codecs/wm_hubs.c b/sound/soc/codecs/wm_hubs.c index 891effe..0c88184 100644 --- a/sound/soc/codecs/wm_hubs.c +++ b/sound/soc/codecs/wm_hubs.c @@ -1223,6 +1223,9 @@ int wm_hubs_handle_analogue_pdata(struct snd_soc_component *component, snd_soc_component_update_bits(component, WM8993_ADDITIONAL_CONTROL, WM8993_LINEOUT2_FB, WM8993_LINEOUT2_FB); + if (!hubs->micd_scthr) + return 0; + snd_soc_component_update_bits(component, WM8993_MICBIAS, WM8993_JD_SCTHR_MASK | WM8993_JD_THR_MASK | WM8993_MICB1_LVL | WM8993_MICB2_LVL, diff --git a/sound/soc/codecs/wm_hubs.h b/sound/soc/codecs/wm_hubs.h index 4b8e5f0..988b29e 100644 --- a/sound/soc/codecs/wm_hubs.h +++ b/sound/soc/codecs/wm_hubs.h @@ -27,6 +27,7 @@ struct wm_hubs_data { int hp_startup_mode; int series_startup; int no_series_update; + bool micd_scthr; bool no_cache_dac_hp_direct; struct list_head dcs_cache; -- 2.7.4

4 8

[PATCH 00/11] soundwire: intel: add multi-link support
by Bard Liao 01 Sep '20

01 Sep '20

This series enables multi-link support for Intel platforms. Bard Liao (1): soundwire: intel: Only call sdw stream APIs for the first cpu_dai Pierre-Louis Bossart (10): soundwire: intel: disable shim wake on suspend soundwire: intel: ignore software command retries soundwire: intel: add multi-link support soundwire: intel: add missing support for all clock stop modes soundwire: bus: update multi-link definition with hw sync details soundwire: intel: add multi-link hw_synchronization information soundwire: stream: enable hw_sync as needed by hardware soundwire: intel: add dynamic debug trace for clock-stop invalid configs soundwire: intel: pass link_mask information to each master soundwire: intel: don't manage link power individually drivers/soundwire/intel.c | 309 ++++++++++++++++++++++++++++----- drivers/soundwire/intel.h | 2 + drivers/soundwire/intel_init.c | 1 + drivers/soundwire/stream.c | 15 +- include/linux/soundwire/sdw.h | 6 + 5 files changed, 282 insertions(+), 51 deletions(-) -- 2.17.1

4 28

[PATCH 00/10] sound: convert tasklets to use new tasklet_setup()
by Allen Pais 01 Sep '20

01 Sep '20

From: Allen Pais <allen.lkml(a)gmail.com> Commit 12cc923f1ccc ("tasklet: Introduce new initialization API")' introduced a new tasklet initialization API. This series converts all the sound drivers to use the new tasklet_setup() API Allen Pais (10): sound: core: convert tasklets to use new tasklet_setup() API sound: firewire: convert tasklets to use new tasklet_setup() API sound: asihpi: convert tasklets to use new tasklet_setup() API sound: riptide: convert tasklets to use new tasklet_setup() API sound: rm9652: convert tasklets to use new tasklet_setup() API sound/soc: fsl_esai: convert tasklets to use new tasklet_setup() API sound/soc: sh: convert tasklets to use new tasklet_setup() API sound/soc: txx9: convert tasklets to use new tasklet_setup() API sound: midi: convert tasklets to use new tasklet_setup() API sound: ua101: convert tasklets to use new tasklet_setup() API sound/core/timer.c | 7 +++---- sound/firewire/amdtp-stream.c | 8 ++++---- sound/pci/asihpi/asihpi.c | 9 ++++----- sound/pci/riptide/riptide.c | 6 +++--- sound/pci/rme9652/hdsp.c | 6 +++--- sound/pci/rme9652/hdspm.c | 7 +++---- sound/soc/fsl/fsl_esai.c | 7 +++---- sound/soc/sh/siu_pcm.c | 10 ++++------ sound/soc/txx9/txx9aclc.c | 7 +++---- sound/usb/midi.c | 7 +++---- sound/usb/misc/ua101.c | 7 +++---- 11 files changed, 36 insertions(+), 45 deletions(-) -- 2.17.1

4 22

[PATCH v3 0/3] ASoC: soundwire: fix port_ready[] dynamic allocation
by Bard Liao 01 Sep '20

01 Sep '20

The existing code allocates memory for the total number of ports. This only works if the ports are contiguous, but will break if e.g. a Devices uses port0, 1, and 14. The port_ready[] array would contain 3 elements, which would lead to an out-of-bounds access. Conversely in other cases, the wrong port index would be used leading to timeouts on prepare. This can be fixed by allocating for the worst-case of 15 ports (DP0..DP14). In addition since the number is now fixed, we can use an array instead of a dynamic allocation. Changes in v3: - Add ASoC tag in the cover letter title. - Edit the title and commit message of the third patch for better understanding. Changes in v2: - Split patches into sdw and asoc patches. Please note that "soundwire: fix port_ready[] dynamic allocation in mipi_disco" and "ASoC: codecs: fix port_ready[] dynamic allocation in ASoC codecs" should be merged at the same time. Pierre-Louis Bossart (3): soundwire: add definition for maximum number of ports soundwire: fix port_ready[] dynamic allocation in mipi_disco ASoC: codecs: soundwire: remove port_ready[] usage from codecs. drivers/soundwire/mipi_disco.c | 18 +----------------- drivers/soundwire/slave.c | 4 ++++ include/linux/soundwire/sdw.h | 5 +++-- sound/soc/codecs/max98373-sdw.c | 15 +-------------- sound/soc/codecs/rt1308-sdw.c | 14 +------------- sound/soc/codecs/rt5682-sdw.c | 15 +-------------- sound/soc/codecs/rt700-sdw.c | 15 +-------------- sound/soc/codecs/rt711-sdw.c | 15 +-------------- sound/soc/codecs/rt715-sdw.c | 33 +-------------------------------- 9 files changed, 14 insertions(+), 120 deletions(-) -- 2.17.1

2 5

[PATCH 0/9] soundwire: use FIELD_{GET|PREP} in subsystem
by Vinod Koul 31 Aug '20

31 Aug '20

Use the FIELD_{GET|PREP} in soundwire subsytem and remove the local SDW_REG_SHIFT(). This makes code IMO look much neater Tested this on db845c board Bard, can you please verify this on intel boards. Vinod Koul (9): soundwire: define and use addr bit masks soundwire: bus: use FIELD_GET() soundwire: slave: use SDW_DISCO_LINK_ID() soundwire: stream: use FIELD_{GET|PREP} soundwire: qcom : use FIELD_{GET|PREP} soundwire: cadence: use FIELD_{GET|PREP} soundwire: intel: use FIELD_{GET|PREP} soundwire: intel_init: use FIELD_{GET|PREP} soundwire: remove SDW_REG_SHIFT() drivers/soundwire/bus.c | 6 +-- drivers/soundwire/cadence_master.c | 53 ++++++++++--------------- drivers/soundwire/intel.c | 40 +++++++------------ drivers/soundwire/intel_init.c | 2 +- drivers/soundwire/qcom.c | 22 ++++------ drivers/soundwire/slave.c | 2 +- drivers/soundwire/stream.c | 13 +++--- include/linux/soundwire/sdw.h | 21 ++++++---- include/linux/soundwire/sdw_registers.h | 7 ---- 9 files changed, 67 insertions(+), 99 deletions(-) -- 2.26.2

3 15

general protection fault in line6_midibuf_write
by syzbot 31 Aug '20

31 Aug '20

Hello, syzbot found the following issue on: HEAD commit: 3ed8e1c2 usb: typec: tcpm: Migrate workqueue to RT priorit.. git tree: https://git.kernel.org/pub/scm/linux/kernel/git/gregkh/usb.git usb-testing console output: https://syzkaller.appspot.com/x/log.txt?x=137be056900000 kernel config: https://syzkaller.appspot.com/x/.config?x=ccafc70ac3d5f49c dashboard link: https://syzkaller.appspot.com/bug?extid=b333bd4e812c1d42827a compiler: gcc (GCC) 10.1.0-syz 20200507 Unfortunately, I don't have any reproducer for this issue yet. IMPORTANT: if you fix the issue, please add the following tag to the commit: Reported-by: syzbot+b333bd4e812c1d42827a(a)syzkaller.appspotmail.com general protection fault, probably for non-canonical address 0xdffffc0000000019: 0000 [#1] SMP KASAN KASAN: null-ptr-deref in range [0x00000000000000c8-0x00000000000000cf] CPU: 1 PID: 21 Comm: kworker/1:1 Not tainted 5.9.0-rc1-syzkaller #0 Hardware name: Google Google Compute Engine/Google Compute Engine, BIOS Google 01/01/2011 Workqueue: usb_hub_wq hub_event RIP: 0010:midibuf_is_full sound/usb/line6/midibuf.c:44 [inline] RIP: 0010:line6_midibuf_write+0x30/0x3f0 sound/usb/line6/midibuf.c:91 Code: 49 89 f5 41 54 55 89 d5 53 48 89 fb 4c 8d 7b 18 48 83 ec 28 e8 11 68 5f fc 4c 89 fa 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 0a 03 00 00 44 8b 63 18 31 ff RSP: 0018:ffff8881db3099d8 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 00000000000000b0 RCX: ffffc900006a8000 RDX: 0000000000000019 RSI: ffffffff84e098af RDI: 00000000000000b0 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8734d643 R10: 0000000000000000 R11: 000000000004e017 R12: 00000000000000b0 R13: ffff8881d40aec80 R14: ffff8881d4464984 R15: 00000000000000c8 FS: 0000000000000000(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005629deed5130 CR3: 00000001d2254000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 Call Trace: <IRQ> line6_data_received+0x281/0x520 sound/usb/line6/driver.c:296 __usb_hcd_giveback_urb+0x32d/0x560 drivers/usb/core/hcd.c:1650 usb_hcd_giveback_urb+0x367/0x410 drivers/usb/core/hcd.c:1716 dummy_timer+0x11f2/0x3240 drivers/usb/gadget/udc/dummy_hcd.c:1967 call_timer_fn+0x1ac/0x6e0 kernel/time/timer.c:1413 expire_timers kernel/time/timer.c:1458 [inline] __run_timers.part.0+0x67c/0xa60 kernel/time/timer.c:1755 __run_timers kernel/time/timer.c:1736 [inline] run_timer_softirq+0x80/0x120 kernel/time/timer.c:1768 __do_softirq+0x1af/0x91c kernel/softirq.c:298 asm_call_on_stack+0xf/0x20 arch/x86/entry/entry_64.S:706 </IRQ> __run_on_irqstack arch/x86/include/asm/irq_stack.h:22 [inline] run_on_irqstack_cond arch/x86/include/asm/irq_stack.h:48 [inline] do_softirq_own_stack+0x73/0x90 arch/x86/kernel/irq_64.c:77 invoke_softirq kernel/softirq.c:393 [inline] __irq_exit_rcu kernel/softirq.c:423 [inline] irq_exit_rcu+0x107/0x1a0 kernel/softirq.c:435 sysvec_apic_timer_interrupt+0x43/0x90 arch/x86/kernel/apic/apic.c:1091 asm_sysvec_apic_timer_interrupt+0x12/0x20 arch/x86/include/asm/idtentry.h:581 RIP: 0010:arch_local_irq_restore arch/x86/include/asm/irqflags.h:85 [inline] RIP: 0010:console_unlock+0xa99/0xcd0 kernel/printk/printk.c:2509 Code: 00 89 ee 48 c7 c7 a0 0a 35 87 e8 12 b9 03 00 65 ff 0d 3b 48 d8 7e e9 87 f9 ff ff e8 f1 59 16 00 e8 dc f2 1b 00 ff 74 24 30 9d <e9> 20 fe ff ff e8 dd 59 16 00 48 8d 7d 08 48 89 f8 48 c1 e8 03 42 RSP: 0018:ffff8881da34f5e0 EFLAGS: 00000212 RAX: 00000000000d56ed RBX: 0000000000000200 RCX: 0000000000000006 RDX: 0000000000000000 RSI: 0000000000000000 RDI: ffffffff8129a6d4 RBP: 0000000000000000 R08: 0000000000000001 R09: ffffffff895c65e7 R10: fffffbfff12b8cbc R11: 0000000000003254 R12: ffffffff82b3d6f0 R13: ffffffff876fa450 R14: 0000000000000054 R15: dffffc0000000000 vprintk_emit+0x1b2/0x460 kernel/printk/printk.c:2029 dev_vprintk_emit+0x3eb/0x436 drivers/base/core.c:4133 dev_printk_emit+0xba/0xf1 drivers/base/core.c:4144 __dev_printk+0xcf/0xf5 drivers/base/core.c:4156 _dev_info+0xd7/0x109 drivers/base/core.c:4202 hub_port_init.cold+0x264/0x32f drivers/usb/core/hub.c:4628 hub_port_connect drivers/usb/core/hub.c:5140 [inline] hub_port_connect_change drivers/usb/core/hub.c:5348 [inline] port_event drivers/usb/core/hub.c:5494 [inline] hub_event+0x2191/0x4390 drivers/usb/core/hub.c:5576 process_one_work+0x94c/0x15f0 kernel/workqueue.c:2269 process_scheduled_works kernel/workqueue.c:2331 [inline] worker_thread+0x82b/0x1120 kernel/workqueue.c:2417 kthread+0x392/0x470 kernel/kthread.c:292 ret_from_fork+0x1f/0x30 arch/x86/entry/entry_64.S:294 Modules linked in: ---[ end trace 3dff073ad8b565c9 ]--- RIP: 0010:midibuf_is_full sound/usb/line6/midibuf.c:44 [inline] RIP: 0010:line6_midibuf_write+0x30/0x3f0 sound/usb/line6/midibuf.c:91 Code: 49 89 f5 41 54 55 89 d5 53 48 89 fb 4c 8d 7b 18 48 83 ec 28 e8 11 68 5f fc 4c 89 fa 48 b8 00 00 00 00 00 fc ff df 48 c1 ea 03 <0f> b6 04 02 84 c0 74 08 3c 03 0f 8e 0a 03 00 00 44 8b 63 18 31 ff RSP: 0018:ffff8881db3099d8 EFLAGS: 00010002 RAX: dffffc0000000000 RBX: 00000000000000b0 RCX: ffffc900006a8000 RDX: 0000000000000019 RSI: ffffffff84e098af RDI: 00000000000000b0 RBP: 0000000000000000 R08: 0000000000000000 R09: ffffffff8734d643 R10: 0000000000000000 R11: 000000000004e017 R12: 00000000000000b0 R13: ffff8881d40aec80 R14: ffff8881d4464984 R15: 00000000000000c8 FS: 0000000000000000(0000) GS:ffff8881db300000(0000) knlGS:0000000000000000 CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 CR2: 00005629deed5130 CR3: 00000001d2254000 CR4: 00000000001506e0 DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000 DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7: 0000000000000400 --- This report is generated by a bot. It may contain errors. See https://goo.gl/tpsmEJ for more information about syzbot. syzbot engineers can be reached at syzkaller(a)googlegroups.com. syzbot will keep track of this issue. See: https://goo.gl/tpsmEJ#status for how to communicate with syzbot.

1 0