Date: Mon, 22 Mar 2004 23:13:03 +0200 From: Ion-Mihai Tetcu <itetcu@apropo.ro> To: Nate Lawson <nate@root.org> Cc: acpi-jp@jp.FreeBSD.org Subject: Re: [acpi-jp 3129] ACPI (_PRS has invalid type 7) problem / regression Message-ID: <20040322231303.1256e87d@it.buh.cameradicommercio.ro> In-Reply-To: <20040322120722.E34213@root.org> References: <20040322192654.2f24ef17@it.buh.cameradicommercio.ro> <20040322111119.P33933@root.org> <20040322215656.6e460fa0@it.buh.cameradicommercio.ro> <20040322120722.E34213@root.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On Mon, 22 Mar 2004 12:09:46 -0800 (PST) Nate Lawson <nate@root.org> wrote: > On Mon, 22 Mar 2004, Ion-Mihai Tetcu wrote: > > On Mon, 22 Mar 2004 11:33:36 -0800 (PST) > > Nate Lawson <nate@root.org> wrote: > > > > The change must have happen between 2004_03_04 and 2004_03_18. > > > > > > I don't think it was the _PRS changes on 3/18 and 3/20. I'm suspecting > > > the ACPI-CA import of 0311. You can revert all changes to acpi_pcib.c by > > > copying this file over sys/dev/acpica/acpi_pcib.c and recompiling your > > > kernel: > > > > > > http://www.freebsd.org/cgi/cvsweb.cgi/~checkout~/src/sys/dev/acpica/acpi_pcib.c?rev=1.36&content-type=text/plain > > > > > > I suspect it won't change anything for you but please test this to be > > > sure. > > > > I'm doing it right now, thank you. > > (Recompiling the acpi.ko wouldn't be enough ?) > > Yes, recompiling just the acpi kernel module would be fine. Done. It's OK now, thanks. > > > Your ASL returns a different interrupt link resource based on an external > > > variable DEID. It may be thinking it's in PIC mode and returning the IRQ > > > resource instead of APIC mode and the Interrupt resource. See the section > > > for ALKC to see what I'm talking about. > > > > Where do I find this section ? > > Device (ALKC) in your ASL. > > One other thing you might try if reverting acpi_pcib.c doesn't help is to > set hw.acpi.serialize_method=0 at the loader prompt. If that doesn't > work, set hw.acpi.osi_name=0 at the prompt. Then try both. Makes no difference, both for the old (non-working) and new (patched, working). The dmesg's can be found at http://people.tecnik93.com/acpi/ dmesg_new_o_n=0 means old (sic!) kernel with hw.acpi.osi_name=0 dmesg_good_s_m=0 means patched kernel with hw.acpi.serialize_method=0 etc. What should I do next to help ? -- IOnut Unregistered ;) FreeBSD user
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20040322231303.1256e87d>