On Thursday 12 June 2008 03:10:04 pm Jiri Slaby wrote: > On 06/11/2008 09:03 PM, Bjorn Helgaas wrote: > > On Wednesday 11 June 2008 12:08:53 pm Jiri Slaby wrote: > >> On 06/10/2008 07:31 AM, Andrew Morton wrote: > >>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.26-rc5/2.6.26-rc5-mm2/ > >> I face problems after some of the pnp changes. If this is not known, I may > >> bisect it, it's 100% reproducible. I have no real logs, It panics prior to > >> network is woken up to see something on netconsole, I just captured a function > >> name and an offset of place where it oopses. > >> > >> pnpacpi_encode_resources, ACPI_RESOURCE_TYPE_DMA case, pnp_get_resource(dev, > >> IORESOURCE_DMA, dma) returns NULL, which is dereferenced at pnpacpi_encode_dma > >> at p->flags. > >> > >> It happens on resume after mem > /sys/power/state. > > > > Thanks for the report, I hadn't heard about this. > > > > We used to always have a resource from the static table to encode > > (assuming the table was big enough), even if that resource was > > disabled or unassigned. But now we don't keep those around, so > > we can end up with null pointers like you're seeing. > > > > Before you go to all the trouble of bisecting it, can you turn on > > CONFIG_PNP_DEBUG and try the following debug patch? I think this > > will prevent the oops, but it's just papering over the real problem, > > so please capture the complete dmesg log. > > ACPI: PCI interrupt for device 0000:00:02.0 disabled > serial 00:07: disabled > serial 00:06: disabled > ACPI handle has no context! > ACPI: PCI interrupt for device 0000:00:1d.7 disabled > ... > serial 00:06: no dma resource to encode! > serial 00:06: activated > serial 00:07: no dma resource to encode! > serial 00:07: activated > ACPI: PCI Interrupt 0000:00:02.0[A] -> GSI 16 (level, low) -> IRQ 16 Interesting. I wonder why a serial device would have a DMA resource. We encode resources by following a template from _CRS, so evidently that template had a DMA resource. Or something deeper is wrong. Can you send me the rest of that dmesg log? I take it that with the debug patch, your system is functional after resume? Bjorn -- To unsubscribe from this list: send the line "unsubscribe kernel-testers" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
