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
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"

Reply via email to