Fatal trap 12: hda

[Alexander Motin]

On 23.09.2012 23:41, Andriy Gapon wrote:
> on 23/09/2012 23:10 Barbara said the following:
>> After updating src on RELENG_9 from r240236 to r240821 I have rebuilt
>> my world+kernel.
>> On reboot I had a kernel panic, "supervisor read, page not present"
>> for process swapper.
>> Trying to reboot in Single User Mode I accidentally disabled ACPI.
>> Luckily the machine booted succesfully but there was nothing new in
>> /var/crash.
>> Then I tried again with ACPI enabled: same kernel panic.
>> So I run nm on the instruction pointer of the panic and I noticed that
>> it was in hdaa_sense_init, in sys/dev/sound/pci/hda/hdaa.c.
>> BTW, I have "device sound" and "device snd_hda" in my KERNCONF, and
>> the sound hw detection happens before HDs, is that the reason why I
>> wasn't able to get a dump or dumping using DDB and the panicking
>> process is swapper? Is there any trick I'm missing for that?
>>
>> Booting in verbose mode and comparing the output with ACPI enabled
>> (where the panic happens) and disabled, I guessed that the problem was
>> where "No presence detection support at nid..." is printed, as it was
>> missing in the former case for nid 27 - Headphone (Green Jack). With
>> ACPI disabled the value was looking quite weird: 36765696.
>> So I made the following change:
>>
>> --------------------------------------------------------------------------------
>> --- sys/dev/sound/pci/hda/hdaa.c.orig	2012-09-22 20:06:20.000000000 +0200
>> +++ sys/dev/sound/pci/hda/hdaa.c	2012-09-23 20:39:32.000000000 +0200
>> @@ -627,7 +627,7 @@
>>   			    (HDA_CONFIG_DEFAULTCONF_MISC(w->wclass.pin.config) & 1) != 0) {
>>   				device_printf(devinfo->dev,
>>   				    "No presence detection support at nid %d\n",
>> -				    as[i].pins[15]);
>> +				    as->pins[15]);
>>   			} else {
>>   				if (w->unsol < 0)
>>   					poll = 1;
>> --------------------------------------------------------------------------------
>>
>> Maybe the fix is not correct, but at least the new kernel boots successfully.
>> Can someone review that?
>> I tried looking in svn commits between the two builds, but I don't
>> know what exposed the problem.
>> If anyone is interested in my verbose log, or doing some tests, please ask.
>
> Your patch looks correct, looks like a bug could have been introduced via
> copy+paste.

Good catch. Thank you. Slightly modified patch committed at r240884.

-- 
Alexander Motin