From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: alsa-devel@alsa-project.org, Leon Romanovsky <leon@kernel.org>,
linux-kernel@vger.kernel.org,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Takashi Iwai <tiwai@suse.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>
Subject: Re: ALSA: intel8x0: div by zero in snd_intel8x0_update()
Date: Fri, 14 May 2021 20:16:45 +0900 [thread overview]
Message-ID: <YJ5cHdv6MVmAKD3b@google.com> (raw)
In-Reply-To: <s5hk0o18tio.wl-tiwai@suse.de>
On (21/05/14 13:05), Takashi Iwai wrote:
> > divide error: 0000 [#1] PREEMPT SMP NOPTI
> > RIP: 0010:snd_intel8x0_interrupt+0x121/0x279
> > Code: 42 8b 44 35 34 41 0f af c5 42 03 44 35 38 42 89 44 35 38 48 8b 0c 24 80 b9 60 03 00 00 00 78 0f 49 8d 0c 2e 48 83 c1 38 31 d2 <f7> 71 f4 89 11 42 8b 7c 35 48 44 01 ef 83 e7 1f 42 89 7c 35 48 48
> > RSP: 0000:ffff9a0a80108eb0 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: 0000000000000019 RCX: ffff90d8c5efc198
> > RDX: 0000000000000000 RSI: ffff9a0a80549016 RDI: ffff9a0a80549024
> > RBP: ffff90d8c5efc060 R08: 000000000000197a R09: 00000f604ed00191
> > R10: 00000000000001e0 R11: ffffffff9468e1d8 R12: 0000000000000020
> > R13: 0000000000000040 R14: 0000000000000100 R15: 0000000000000002
> > FS: 00007a75c397aff8(0000) GS:ffff90d912d80000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007a77945d1000 CR3: 000000015bf46002 CR4: 0000000000360ea0
> > Call Trace:
> > <IRQ>
> > __handle_irq_event_percpu+0xa0/0x1c0
> > handle_irq_event_percpu+0x2d/0x70
> > handle_irq_event+0x2c/0x48
> > handle_fasteoi_irq+0xa1/0x161
> > do_IRQ+0x51/0xd6
> > common_interrupt+0xf/0xf
> > </IRQ>
> > RIP: 0033:0x7a7856462c59
> > Code: 89 ca 48 2b 57 20 48 83 c2 10 31 c0 48 3b 57 28 48 0f 46 c1 c3 cc cc cc cc cc cc cc cc cc cc cc cc 64 48 8b 0c 25 00 00 00 00 <b8> f8 02 00 00 48 03 41 08 c3 cc cc cc cc cc cc cc cc cc cc cc cc
> > RSP: 002b:00007a75c39794e8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
> > RAX: 02fa413b24209c6c RBX: 0000017f19e1cf9e RCX: 00007a75c397aff8
> > RDX: 00007a7855792472 RSI: 00007a7855790aa0 RDI: 0000000000000005
> > RBP: 0000000000000005 R08: 0000000000000012 R09: 000000000000000d
> > R10: 00000000009f86d2 R11: 000000000000197a R12: 0000017f19e40e7d
> > R13: 000005ee937ae557 R14: 00007a7855790aa0 R15: 00007a7855792472
> > Modules linked in:
> > ---[ end trace 2ef6d63d0e3d757c ]---
> > RIP: 0010:snd_intel8x0_interrupt+0x121/0x279
> > Code: 42 8b 44 35 34 41 0f af c5 42 03 44 35 38 42 89 44 35 38 48 8b 0c 24 80 b9 60 03 00 00 00 78 0f 49 8d 0c 2e 48 83 c1 38 31 d2 <f7> 71 f4 89 11 42 8b 7c 35 48 44 01 ef 83 e7 1f 42 89 7c 35 48 48
> > RSP: 0000:ffff9a0a80108eb0 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: 0000000000000019 RCX: ffff90d8c5efc198
> > RDX: 0000000000000000 RSI: ffff9a0a80549016 RDI: ffff9a0a80549024
> > RBP: ffff90d8c5efc060 R08: 000000000000197a R09: 00000f604ed00191
> > R10: 00000000000001e0 R11: ffffffff9468e1d8 R12: 0000000000000020
> > R13: 0000000000000040 R14: 0000000000000100 R15: 0000000000000002
> > FS: 00007a75c397aff8(0000) GS:ffff90d912d80000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007a77945d1000 CR3: 000000015bf46002 CR4: 0000000000360ea0
> >
> > This corresponds to
> >
> > ichdev->position %= ichdev->size;
> >
> > in snd_intel8x0_update().
> >
> > A print out of that ichdev looks as follows
> >
> > snd_intel8x0 0000:00:18.0: lvi_frag = 0, frags = 0, size = 0, period_size = 0x0, period_size1 = 0x0
>
> This sounds like some spurious IRQ that casually hits during the
> resume. It's strange that, even if it's a spurious IRQ, it contains
> the proper update bits for the stream.
Yes, I found this to be strange as well. That's why I started dumping
ichdev fields and so on.
> Is that on a real hardware or
> on a VM?
VM.
> In anyway, the patch like below might cover enough.
I'll give it a try.
> --- a/sound/pci/intel8x0.c
> +++ b/sound/pci/intel8x0.c
> @@ -691,6 +691,9 @@ static inline void snd_intel8x0_update(struct intel8x0 *chip, struct ichdev *ich
> int status, civ, i, step;
> int ack = 0;
>
> + if (!ichdev->substream || ichdev->suspended)
> + return;
> +
> spin_lock_irqsave(&chip->reg_lock, flags);
> status = igetbyte(chip, port + ichdev->roff_sr);
> civ = igetbyte(chip, port + ICH_REG_OFF_CIV);
WARNING: multiple messages have this Message-ID (diff)
From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Takashi Iwai <tiwai@suse.de>
Cc: Sergey Senozhatsky <senozhatsky@chromium.org>,
Jaroslav Kysela <perex@perex.cz>, Takashi Iwai <tiwai@suse.com>,
"Gustavo A. R. Silva" <gustavoars@kernel.org>,
Leon Romanovsky <leon@kernel.org>,
alsa-devel@alsa-project.org, linux-kernel@vger.kernel.org
Subject: Re: ALSA: intel8x0: div by zero in snd_intel8x0_update()
Date: Fri, 14 May 2021 20:16:45 +0900 [thread overview]
Message-ID: <YJ5cHdv6MVmAKD3b@google.com> (raw)
In-Reply-To: <s5hk0o18tio.wl-tiwai@suse.de>
On (21/05/14 13:05), Takashi Iwai wrote:
> > divide error: 0000 [#1] PREEMPT SMP NOPTI
> > RIP: 0010:snd_intel8x0_interrupt+0x121/0x279
> > Code: 42 8b 44 35 34 41 0f af c5 42 03 44 35 38 42 89 44 35 38 48 8b 0c 24 80 b9 60 03 00 00 00 78 0f 49 8d 0c 2e 48 83 c1 38 31 d2 <f7> 71 f4 89 11 42 8b 7c 35 48 44 01 ef 83 e7 1f 42 89 7c 35 48 48
> > RSP: 0000:ffff9a0a80108eb0 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: 0000000000000019 RCX: ffff90d8c5efc198
> > RDX: 0000000000000000 RSI: ffff9a0a80549016 RDI: ffff9a0a80549024
> > RBP: ffff90d8c5efc060 R08: 000000000000197a R09: 00000f604ed00191
> > R10: 00000000000001e0 R11: ffffffff9468e1d8 R12: 0000000000000020
> > R13: 0000000000000040 R14: 0000000000000100 R15: 0000000000000002
> > FS: 00007a75c397aff8(0000) GS:ffff90d912d80000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007a77945d1000 CR3: 000000015bf46002 CR4: 0000000000360ea0
> > Call Trace:
> > <IRQ>
> > __handle_irq_event_percpu+0xa0/0x1c0
> > handle_irq_event_percpu+0x2d/0x70
> > handle_irq_event+0x2c/0x48
> > handle_fasteoi_irq+0xa1/0x161
> > do_IRQ+0x51/0xd6
> > common_interrupt+0xf/0xf
> > </IRQ>
> > RIP: 0033:0x7a7856462c59
> > Code: 89 ca 48 2b 57 20 48 83 c2 10 31 c0 48 3b 57 28 48 0f 46 c1 c3 cc cc cc cc cc cc cc cc cc cc cc cc 64 48 8b 0c 25 00 00 00 00 <b8> f8 02 00 00 48 03 41 08 c3 cc cc cc cc cc cc cc cc cc cc cc cc
> > RSP: 002b:00007a75c39794e8 EFLAGS: 00000246 ORIG_RAX: ffffffffffffffde
> > RAX: 02fa413b24209c6c RBX: 0000017f19e1cf9e RCX: 00007a75c397aff8
> > RDX: 00007a7855792472 RSI: 00007a7855790aa0 RDI: 0000000000000005
> > RBP: 0000000000000005 R08: 0000000000000012 R09: 000000000000000d
> > R10: 00000000009f86d2 R11: 000000000000197a R12: 0000017f19e40e7d
> > R13: 000005ee937ae557 R14: 00007a7855790aa0 R15: 00007a7855792472
> > Modules linked in:
> > ---[ end trace 2ef6d63d0e3d757c ]---
> > RIP: 0010:snd_intel8x0_interrupt+0x121/0x279
> > Code: 42 8b 44 35 34 41 0f af c5 42 03 44 35 38 42 89 44 35 38 48 8b 0c 24 80 b9 60 03 00 00 00 78 0f 49 8d 0c 2e 48 83 c1 38 31 d2 <f7> 71 f4 89 11 42 8b 7c 35 48 44 01 ef 83 e7 1f 42 89 7c 35 48 48
> > RSP: 0000:ffff9a0a80108eb0 EFLAGS: 00010046
> > RAX: 0000000000000000 RBX: 0000000000000019 RCX: ffff90d8c5efc198
> > RDX: 0000000000000000 RSI: ffff9a0a80549016 RDI: ffff9a0a80549024
> > RBP: ffff90d8c5efc060 R08: 000000000000197a R09: 00000f604ed00191
> > R10: 00000000000001e0 R11: ffffffff9468e1d8 R12: 0000000000000020
> > R13: 0000000000000040 R14: 0000000000000100 R15: 0000000000000002
> > FS: 00007a75c397aff8(0000) GS:ffff90d912d80000(0000) knlGS:0000000000000000
> > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> > CR2: 00007a77945d1000 CR3: 000000015bf46002 CR4: 0000000000360ea0
> >
> > This corresponds to
> >
> > ichdev->position %= ichdev->size;
> >
> > in snd_intel8x0_update().
> >
> > A print out of that ichdev looks as follows
> >
> > snd_intel8x0 0000:00:18.0: lvi_frag = 0, frags = 0, size = 0, period_size = 0x0, period_size1 = 0x0
>
> This sounds like some spurious IRQ that casually hits during the
> resume. It's strange that, even if it's a spurious IRQ, it contains
> the proper update bits for the stream.
Yes, I found this to be strange as well. That's why I started dumping
ichdev fields and so on.
> Is that on a real hardware or
> on a VM?
VM.
> In anyway, the patch like below might cover enough.
I'll give it a try.
> --- a/sound/pci/intel8x0.c
> +++ b/sound/pci/intel8x0.c
> @@ -691,6 +691,9 @@ static inline void snd_intel8x0_update(struct intel8x0 *chip, struct ichdev *ich
> int status, civ, i, step;
> int ack = 0;
>
> + if (!ichdev->substream || ichdev->suspended)
> + return;
> +
> spin_lock_irqsave(&chip->reg_lock, flags);
> status = igetbyte(chip, port + ichdev->roff_sr);
> civ = igetbyte(chip, port + ICH_REG_OFF_CIV);
next prev parent reply other threads:[~2021-05-14 15:44 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-05-14 8:17 ALSA: intel8x0: div by zero in snd_intel8x0_update() Sergey Senozhatsky
2021-05-14 8:17 ` Sergey Senozhatsky
2021-05-14 11:05 ` Takashi Iwai
2021-05-14 11:05 ` Takashi Iwai
2021-05-14 11:16 ` Sergey Senozhatsky [this message]
2021-05-14 11:16 ` Sergey Senozhatsky
2021-05-16 8:30 ` Sergey Senozhatsky
2021-05-16 8:30 ` Sergey Senozhatsky
2021-05-16 8:31 ` Sergey Senozhatsky
2021-05-16 8:31 ` Sergey Senozhatsky
2021-05-16 9:49 ` Takashi Iwai
2021-05-16 9:49 ` Takashi Iwai
2021-05-16 10:59 ` Sergey Senozhatsky
2021-05-16 10:59 ` Sergey Senozhatsky
2021-05-16 11:23 ` Sergey Senozhatsky
2021-05-16 11:23 ` Sergey Senozhatsky
2021-05-16 12:07 ` Takashi Iwai
2021-05-16 12:07 ` Takashi Iwai
2021-05-16 12:55 ` Sergey Senozhatsky
2021-05-16 12:55 ` Sergey Senozhatsky
2021-07-06 17:50 ` Max Filippov
2021-07-06 17:50 ` Max Filippov
2021-07-07 7:02 ` Takashi Iwai
2021-07-07 7:02 ` Takashi Iwai
2021-07-07 17:50 ` Max Filippov
2021-07-07 17:50 ` Max Filippov
2021-07-07 18:14 ` Takashi Iwai
2021-07-07 18:14 ` Takashi Iwai
2021-07-07 20:33 ` Max Filippov
2021-07-07 20:33 ` Max Filippov
2021-07-08 7:13 ` Takashi Iwai
2021-07-08 7:13 ` Takashi Iwai
2021-07-08 8:41 ` Max Filippov
2021-07-08 8:41 ` Max Filippov
2021-07-08 9:00 ` Takashi Iwai
2021-07-08 9:00 ` Takashi Iwai
2021-07-08 10:12 ` Sergey Senozhatsky
2021-07-08 10:12 ` Sergey Senozhatsky
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=YJ5cHdv6MVmAKD3b@google.com \
--to=senozhatsky@chromium.org \
--cc=alsa-devel@alsa-project.org \
--cc=gustavoars@kernel.org \
--cc=leon@kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=tiwai@suse.com \
--cc=tiwai@suse.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.