lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Date: Sat, 13 Jan 2007 00:45:03 +0000 From: Frederik Deweerdt <deweerdt@...e.fr> To: Len Brown <lenb@...nel.org> Cc: Jiri Slaby <jirislaby@...il.com>, Andrew Morton <akpm@...l.org>, linux-kernel@...r.kernel.org, rui.zhang@...el.com, Michal Piotrowski <michal.k.k.piotrowski@...il.com> Subject: Re: Early ACPI lockup (was Re: 2.6.20-rc4-mm1) On Sat, Jan 13, 2007 at 01:08:46AM +0100, Michal Piotrowski wrote: > Jiri Slaby napisaĆ(a): > > Frederik Deweerdt wrote: > >> On Fri, Jan 12, 2007 at 05:53:08PM -0500, Len Brown wrote: > >>> On Friday 12 January 2007 05:20, Frederik Deweerdt wrote: > >>>> On Thu, Jan 11, 2007 at 10:26:27PM -0800, Andrew Morton wrote: > >>>>> ftp://ftp.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.20-rc3/2.6.20-rc4-mm1/ > >>>>> > >>>> Hi, > >>>> > >>>> The git-acpi.patch replaces earlier "if(!handler) return -EINVAL" by > >>>> "BUG_ON(!handler)". This locks my machine early at boot with a message > >>>> along the lines of (It's hand copied): > >>>> Int 6: cr2: 00000000 eip: c0570e05 flags: 00010046 cs: 60 > >>>> stack: c054ffac c011db2b c04936d0 c054ff68 c054ffc0 c054fff4 c057da2c > >>>> > >>>> Reverting the change as follows, allows booting: > >>>> Any ideas to debug this further? > >>>> diff --git a/drivers/acpi/tables.c b/drivers/acpi/tables.c > >>>> index db0c5f6..fba018c 100644 > >>>> --- a/drivers/acpi/tables.c > >>>> +++ b/drivers/acpi/tables.c > >>>> @@ -414,7 +414,9 @@ int __init acpi_table_parse(enum acpi_ta > >>>> unsigned int index; > >>>> unsigned int count = 0; > >>>> > >>>> - BUG_ON(!handler); > >>>> + if (!handler) > >>>> + return -EINVAL; > >>>> + /*BUG_ON(!handler);*/ > >>>> > >>>> for (i = 0; i < sdt_count; i++) { > >>>> if (sdt_entry[i].id != id) > >>> What do you see if on failure you also print out the params, like below? > > > > I get this: > > > > ACPI: RSDP (v000 GBT ) @ 0x000f6e80 > > ACPI: RSDT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3000 > > ACPI: FADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff3040 > > ACPI: MADT (v001 GBT AWRDACPI 0x42302e31 AWRD 0x01010101) @ 0x3fff7100 > > ACPI: DSDT (v001 GBT AWRDACPI 0x00001000 MSFT 0x0100000c) @ 0x00000000 > > ACPI: PM-Timer IO Port: 0x1008 > > ACPI: Local APIC address 0xfee00000 > > ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) > > Processor #0 15:2 APIC version 20 > > ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) > > Processor #1 15:2 APIC version 20 > > ACPI: LAPIC_NMI (acpi_id[0x00] dfl dfl lint[0x1]) > > ACPI: LAPIC_NMI (acpi_id[0x01] dfl dfl lint[0x1]) > > ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) > > IOAPIC[0]: apic_id 2, version 32, address 0xfec00000, GSI 0-23 > > ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) > > ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 9 high level) > > ACPI: IRQ0 used by override. > > ACPI: IRQ2 used by override. > > ACPI: IRQ9 used by override. > > Enabling APIC mode: Flat. Using 1 I/O APICs > > ACPI: acpi_table_parse(17, 00000000) HPET NULL handler! > > Using ACPI (MADT) for SMP configuration information > > > > ACPI: acpi_table_parse(17, 00000000) HPET NULL handler! So the BUG_ON is triggered by CONFIG_HPET_TIMER not being defined, causing acpi_parse_hpet to be NULL. Should the acpi_table_parse() called be ifdef'ed of is the previous behaviour (returning -EINVAL) just OK? Regards, Frederik - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists