Help me debug snd_emu10k1 - Sound Blaster Audigy Series only working in 50% of the boots

[Takashi Iwai]

On Mon, 23 Nov 2020 18:01:53 +0100,
Micha wrote:
> 20:30:00 CET. --
> Nov 02 18:03:14 sysiphus kernel: snd_emu10k1 0000:0a:00.0: enabling
> device (0000 -> 0001)
> Nov 02 18:03:14 sysiphus kernel: snd_emu10k1 0000:0a:00.0: Audigy2
> value: Special config.
> Nov 02 18:03:15 sysiphus kernel: snd_emu10k1 0000:0a:00.0: AC'97 0 does
> not respond - RESET
> Nov 02 18:03:15 sysiphus kernel: snd_emu10k1 0000:0a:00.0: AC'97 0
> access is not valid [0x0], removing mixer.
> Nov 02 18:03:15 sysiphus kernel: snd_emu10k1: probe of 0000:0a:00.0
> failed with error -5

IIRC, this is a very long-standing problem, and it depends on the
motherboard.

I'd start trying to increase the delay in the probe.  Although I
thought that this didn't help in the past, maybe still worth to try.

Independently from the emu10k1 probe failure, the following Oops has
to be fixed:

> [  232.428668] snd_emu10k1 0000:0a:00.0: Audigy2 value: Special config.
> [  233.444961] snd_emu10k1 0000:0a:00.0: AC'97 0 does not respond -
> RESET
> [  233.444977] snd_emu10k1 0000:0a:00.0: AC'97 0 access is not valid
> [0x0], removing mixer.
> [  233.446714] snd_emu10k1: probe of 0000:0a:00.0 failed with error -5
> [  943.295169] BUG: kernel NULL pointer dereference, address:
> 0000000000000000
> [  943.295176] #PF: supervisor instruction fetch in kernel mode
> [  943.295179] #PF: error_code(0x0010) - not-present page
> [  943.295181] PGD 0 P4D 0 
> [  943.295187] Oops: 0010 [#1] SMP PTI
> [  943.295193] CPU: 1 PID: 7669 Comm: grep Not tainted 5.9.0-2-amd64 #1
> Debian 5.9.6-1
> [  943.295196] Hardware name: System manufacturer System Product
> Name/PRIME Z270-K, BIOS 1207 06/22/2018
> [  943.295201] RIP: 0010:0x0
> [  943.295206] Code: Unable to access opcode bytes at RIP
> 0xffffffffffffffd6.
> [  943.295209] RSP: 0018:ffffb76ac8f0fe40 EFLAGS: 00010203
> [  943.295213] RAX: 0000000000000000 RBX: 0000000000000000 RCX:
> 0000000000000030
> [  943.295216] RDX: fffffffffffecde8 RSI: 0000000000000001 RDI:
> ffff97b0d3b23348
> [  943.295218] RBP: ffffb76ac8f0ff10 R08: fffffffffffecde8 R09:
> ffffffffffffffff
> [  943.295221] R10: fffffffffffecde8 R11: 0000000000000000 R12:
> 0000000000000001
> [  943.295223] R13: ffff97b0d3b23370 R14: ffff97b0d3b23348 R15:
> ffff97b0d3b23380
> [  943.295227] FS:  00007f9abbdc4b80(0000) GS:ffff97b226c80000(0000)
> knlGS:0000000000000000
> [  943.295230] CS:  0010 DS: 0000 ES: 0000 CR0: 0000000080050033
> [  943.295233] CR2: ffffffffffffffd6 CR3: 000000028e3a6003 CR4:
> 00000000003706e0
> [  943.295236] DR0: 0000000000000000 DR1: 0000000000000000 DR2:
> 0000000000000000
> [  943.295238] DR3: 0000000000000000 DR6: 00000000fffe0ff0 DR7:
> 0000000000000400
> [  943.295240] Call Trace:
> [  943.295251]  seq_read+0xb4/0x460
> [  943.295258]  full_proxy_read+0x53/0x80
> [  943.295264]  vfs_read+0x9c/0x180
> [  943.295270]  ksys_read+0x5f/0xe0
> [  943.295277]  do_syscall_64+0x33/0x80
> [  943.295284]  entry_SYSCALL_64_after_hwframe+0x44/0xa9

I suppose this is something to do with emu10k1, but do you know what
file read triggers this?  If it always happens after the probe
failure, it should be easy to identify.


thanks,

Takashi